1. WebApps
1.1. Entre 1990 y 1995 los sitios web consistían en poco más que un conjunto de archivos de hipertexto vinculados que presentaban la información con el empleo de texto y gráficas limitadas.
1.2. En la actualidad, las webapps se han convertido en herramientas sofisticadas de cómputo que no sólo proporcionan funciones aisladas al usuario final, sino que también se han integrado con bases de datos corporativas y aplicaciones de negocios.
1.3. Los sistemas y aplicaciones basados en web involucran una mezcla entre las publicaciones impresas y el desarrollo de software, entre la mercadotecnia y la computación, entre las comunicaciones internas y las relaciones exteriores, y entre el arte y la tecnología, segun Powell [Pow98].
1.4. La mayoria de las WebApps estan compuestas por los siguientes atributos:
1.4.1. Uso Intensivo de Redes.
1.4.1.1. Una webapp reside en una red y debe atender las necesidades de una comunidad diversa de clientes.
1.4.2. Concurrencia.
1.4.2.1. A la webapp puede acceder un gran número de usuarios a la vez. En muchos casos, los patrones de uso entre los usuarios finales varían mucho.
1.4.3. Carga Impredecible.
1.4.3.1. El número de usuarios de la webapp cambia en varios órdenes de magnitud de un día a otro.
1.4.4. Rendimiento.
1.4.4.1. Si un usuario de la webapp debe esperar demasiado (para entrar, para el procesamiento por parte del servidor, para el formado y despliegue del lado del cliente), él o ella quizá decidan irse a otra parte.
1.4.5. Disponibilidad.
1.4.5.1. Aunque no es razonable esperar una disponibilidad de 100%, es frecuente que los usuarios de webapps populares demanden acceso las 24 horas de los 365 días del año.
1.4.6. Orientada a Datos.
1.4.6.1. La función principal de muchas webapp es el uso de hipermedios para presentar al usuario final contenido en forma de texto, gráficas, audio y video.
1.4.6.1.1. Las webapps se utilizan en forma común para acceder a información que existe en bases de datos que no son parte integral del ambiente basado en web.
1.4.7. Contenido Sensible
1.4.7.1. La calidad y naturaleza estética del contenido constituye un rasgo importante de la calidad de una webapp.
1.4.8. Evolucion Continua.
1.4.8.1. A diferencia del software de aplicación convencional que evoluciona a lo largo de una serie de etapas planeadas y separadas cronológicamente, las aplicaciones web evolucionan en forma continua.
1.4.9. Inmediatez.
1.4.9.1. Se define necesidad apremiante de que el software llegue con rapidez al mercado
1.4.9.1.1. Aunque la inmediatez es una característica en muchos dominios de aplicación, es frecuente que las webapps tengan plazos de algunos días o semanas para llegar al mercado.
1.4.10. Seguridad.
1.4.10.1. Debido a que las webapps se encuentran disponibles con el acceso a una red se deben implementar medidas estrictas de seguridad a través de la infraestructura de apoyo de una webapp y dentro de la aplicación misma.
1.4.11. Estetica.
1.4.11.1. Parte innegable del atractivo de una webapp es su apariencia y percepción.
2. Ingenieria de Software.
2.1. El software se ha incrustado profundamente en casi todos los aspectos de nuestras vidas y, como consecuencia, el número de personas que tienen interés en las características y funciones que brinda una aplicación específica ha crecido en forma notable.
2.1.1. Se debe hacerse un esfuerzo concertado para entender el problema antes de desarrollar una aplicación de software.
2.2. La complejidad de estos nuevos sistemas y productos basados en computadora demanda atención cuidadosa a las interacciones de todos los elementos del sistema.
2.2.1. Por lo tanto el diseño se ha vuelto una actividad crucial.
2.3. Los individuos, negocios y gobiernos dependen cada vez más del software para tomar decisiones estratégicas y tácticas.
2.3.1. Por lo tanto el software debe tener alta calidad.
2.4. A medida que aumenta el valor percibido de una aplicación específica se incrementa la probabilidad de que su base de usuarios y longevidad también crezcan.
2.4.1. El software debe tener facilidad para recibir mantenimiento.
2.5. La ingeniería de software es una tecnología con varias capas.
2.5.1. La ingeniería de software incluye un proceso, métodos y herramientas para administrar y hacer ingeniería con el software.
2.5.1.1. El proceso de ingeniería de software es el aglutinante que une las capas de la tecnología y permite el desarrollo racional y oportuno del software de cómputo.
2.5.1.1.1. El proceso define una estructura que debe establecerse para la obtención eficaz de tecnología de ingeniería de software.
2.5.1.2. Los métodos de la ingeniería de software proporcionan la experiencia técnica para elaborar software.
2.5.1.2.1. Los métodos de la ingeniería de software se basan en un conjunto de principios fundamentales que gobiernan cada área de la tecnología e incluyen actividades de modelación y otras técnicas descriptivas.
2.5.1.3. Las herramientas de la ingeniería de software proporcionan un apoyo automatizado o semiautomatizado para el proceso y los métodos.
2.6. Esencia de la Practica.
2.6.1. 1. Entender el problema (comunicación y análisis).
2.6.1.1. Es conveniente dedicar un poco de tiempo a responder algunas preguntas sencillas:
2.6.1.1.1. ¿Quiénes tienen que ver con la solución del problema? Es decir, ¿quiénes son los participantes?
2.6.1.1.2. ¿Cuáles son las incógnitas? ¿Cuáles datos, funciones y características se requieren para resolver el problema en forma apropiada?
2.6.1.1.3. ¿Puede fraccionarse el problema? ¿Es posible representarlo con problemas más pequeños que sean más fáciles de entender?
2.6.1.1.4. ¿Es posible representar gráficamente el problema? ¿Puede crearse un modelo de análisis?
2.6.2. 2. Planear la solución (modelado y diseño del software).
2.6.2.1. Se recomienda que antes que se haga nada se haga un pequeño diseño:
2.6.2.1.1. ¿Ha visto antes problemas similares? ¿Hay patrones reconocibles en una solución potencial? ¿Hay algún software existente que implemente los datos, funciones y características que se requieren?
2.6.2.1.2. ¿Ha resuelto un problema similar? Si es así, ¿son reutilizables los elementos de la solución?
2.6.2.1.3. ¿Pueden definirse problemas más pequeños? Si así fuera, ¿hay soluciones evidentes para éstos?
2.6.2.1.4. ¿Es capaz de representar una solución en una forma que lleve a su implementación eficaz? ¿Es posible crear un modelo del diseño?
2.6.3. 3. Ejecutar el plan (generación del código).
2.6.3.1. A pesar de que pueden haber desvios en el camino, se tiene un diseño generado que tiene que responder a las siguientes preguntas:
2.6.3.1.1. ¿Se ajusta la solución al plan? ¿El código fuente puede apegarse al modelo del diseño?
2.6.3.1.2. ¿Es probable que cada parte componente de la solución sea correcta? ¿El diseño y código se han revisado o, mejor aún, se han hecho pruebas respecto de la corrección del algoritmo?
2.6.4. 4. Examinar la exactitud del resultado (probar y asegurar la calidad).
2.6.4.1. Como se hizo en anteriores veces, hay que responder las siguientes preguntas para comprobar que su resultado es satisfactorio
2.6.4.1.1. ¿Puede probarse cada parte componente de la solución? ¿Se ha implementado una estrategia razonable para hacer pruebas?
2.6.4.1.2. ¿La solución produce resultados que se apegan a los datos, funciones y características que se requieren? ¿El software se ha validado contra todos los requerimientos de los participantes?
2.7. Principios Generales.
2.7.1. Primer principio: La razón de que exista todo.
2.7.1.1. Un sistema de software existe por una razón: dar valor a sus usuarios. Todas las decisiones deben tomarse teniendo esto en mente.
2.7.1.1.1. Preguntese: “¿Esto agrega valor real al sistema?”
2.7.2. Segundo principio: MSE (Mantenlo sencillo, estúpido…)
2.7.2.1. Todo diseño debe ser tan simple como sea posible, pero no más.
2.7.2.1.1. Esto facilita conseguir un sistema que sea comprendido más fácilmente y que sea susceptible de recibir mantenimiento, lo que no quiere decir que en nombre de la simplicidad deban descartarse características o hasta rasgos internos.
2.7.3. Tercer principio: Mantener la visión.
2.7.3.1. Una visión clara es esencial para el éxito de un proyecto de software. Sin ella, casi infaliblemente el proyecto terminará siendo un ser “con dos [o más mentes]”.
2.7.3.1.1. Comprometer la visión de la arquitectura de un sistema de software debilita y, finalmente hará que colapsen incluso los sistemas bien diseñados.
2.7.4. Cuarto principio: Otros consumirán lo que usted produce.
2.7.4.1. Siempre establezca especificaciones, diseñe e implemente con la seguridad de que alguien más tendrá que entender lo que usted haga. La audiencia para cualquier producto de desarrollo de software es potencialmente grande.
2.7.4.1.1. Codifique pensando en aquellos que deben dar mantenimiento y ampliar el sistema.
2.7.5. Quinto principio: Ábrase al futuro.
2.7.5.1. Un sistema con larga vida útil tiene más valor, los sistemas deben ser fáciles de adaptar a ésos y otros cambios.
2.7.5.1.1. Nunca diseñe sobre algo iniciado. Siempre pregunte: “¿qué pasa si…?” y prepárese para todas las respuestas posibles mediante la creación de sistemas que resuelvan el problema general, no sólo uno específico.14 Es muy posible que esto lleve a volver a usar un sistema completo.
2.7.6. Sexto principio: Planee por anticipado la reutilización.
2.7.6.1. La reutilización ahorra tiempo y esfuerzo.
2.7.6.1.1. La reutilización del código y de los diseños se ha reconocido como uno de los mayores beneficios de usar tecnologías orientadas a objetos. Sin embargo, la recuperación de esta inversión no es automática.
2.7.7. Séptimo principio: ¡Piense!
2.7.7.1. Pensar en todo con claridad antes de emprender la acción casi siempre produce mejores resultados.
2.7.7.1.1. Si usted piensa en algo y aun así lo hace mal, eso se convierte en una experiencia valiosa.
3. Mitos del Software
3.1. Un mito aparecen con enunciados razonables (a veces contienen elementos de verdad), tienen una sensación intuitiva y es frecuente que los manifiesten profesionales experimentados que “conocen la historia”.
3.1.1. Mitos de la administración.
3.1.1.1. No es raro que un gerente de software sostenga la creencia en un mito del software si eso disminuye la presión a que está sujeto (incluso de manera temporal).
3.1.1.1.1. Mito: Tenemos un libro lleno de estándares y procedimientos para elaborar software. ¿No le dará a mi personal todo lo que necesita saber?
3.1.1.1.2. Realidad: Tal vez exista el libro de estándares, pero ¿se utiliza? ¿Saben de su existencia los trabajadores del software? ¿Refleja la práctica moderna de la ingeniería de software? ¿Es completo? ¿Es adaptable? ¿Está dirigido a mejorar la entrega a tiempo y también se centra en la calidad? En muchos casos, la respuesta a todas estas preguntas es “no”.
3.1.2. Mitos del cliente.
3.1.2.1. El cliente sostiene mitos sobre el software porque los gerentes y profesionales de éste hacen poco para corregir la mala información.
3.1.2.1.1. Mito: Para comenzar a escribir programas, es suficiente el enunciado general de los objetivos —podremos entrar en detalles más adelante.
3.1.2.1.2. Realidad: Aunque no siempre es posible tener el enunciado exhaustivo y estable de los requerimientos, un “planteamiento de objetivos” ambiguo es una receta para el desastre. Los requerimientos que no son ambiguos (que por lo general se obtienen en forma iterativa) se desarrollan sólo por medio de una comunicación eficaz y continua entre el cliente y el desarrollador.
3.1.3. Mitos del profesional.
3.1.3.1. Los mitos que aún sostienen los trabajadores del software han sido alimentados por más de 50 años de cultura de programación.
3.1.3.1.1. Mito: Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado.
3.1.3.1.2. Realidad: Alguien dijo alguna vez que “entre más pronto se comience a ‘escribir el código’, más tiempo tomará hacer que funcione”. Los datos de la industria indican que entre 60 y 80% de todo el esfuerzo dedicado al software ocurrirá después de entregarlo al cliente por primera vez.
4. El Concepto de Software
4.1. El software de computadora es el producto que construyen los programadores profesionales y al que después le dan mantenimiento durante un largo tiempo.
4.2. El software distribuye el producto más importante de nuestro tiempo: información.
4.3. El software es elemento de un sistema lógico y no de uno físico. Por tanto, tiene características que difieren considerablemente de las del hardware:
4.3.1. 1. El software se desarrolla o modifica con intelecto; no se manufactura en el sentido clásico.
4.3.1.1. La manufactura de hardware y software requieren la construcción de un “producto”, pero los enfoques son distintos.
4.3.1.1.1. Los costos del software se concentran en la ingeniería. Esto significa que los proyectos de software no pueden administrarse como si fueran proyectos de manufactura.
4.3.2. 2. El software no se “desgasta”.
4.3.2.1. El software no es susceptible a los problemas ambientales que hacen que el hardware se desgaste. Por tanto, en teoría, la curva de la tasa de fallas adopta la forma de la “curva idealizada”.
4.3.2.1.1. Durante su vida, el software sufrirá cambios. Es probable que cuando éstos se realicen, se introduzcan errores que ocasionen que la curva de tasa de fallas tenga aumentos súbitos.
4.3.3. 3. Aunque la industria se mueve hacia la construcción basada en componentes, la mayor parte del software se construye para un uso individualizado.
4.3.3.1. Un componente de software debe diseñarse e implementarse de modo que pueda volverse a usar en muchos programas diferentes.
4.4. Actualmente los dominios de Software son siete:
4.4.1. 1. Software de Sistemas.
4.4.1.1. Conjunto de programas escritos para dar servicio a otros programas.
4.4.1.1.1. Como por ejemplo: compiladores, editores, herramientas para administrar archivos, componentes de sistemas operativos, manejadores, software de redes, procesadores de telecomunicaciones
4.4.2. 2. Software de Aplicacion.
4.4.2.1. Programas aislados que resuelven una necesidad específica de negocios.
4.4.2.1.1. Las aplicaciones en esta área procesan datos comerciales o técnicos en una forma que facilita las operaciones de negocios o la toma de decisiones administrativas o técnicas.
4.4.3. 3. Software de Ingenieria y Ciencias
4.4.3.1. Se ha caracterizado por algoritmos “devoradores de números”
4.4.3.1.1. Sin embargo, las aplicaciones modernas dentro del área de la ingeniería y las ciencias están abandonando los algoritmos numéricos convencionales.
4.4.4. 4. Software Incrustado.
4.4.4.1. Reside dentro de un producto o sistema y se usa para implementar y controlar características y funciones para el usuario final y para el sistema en sí.
4.4.5. 5. Software de Linea de Productos.
4.4.5.1. Diseñado para proporcionar una capacidad específica para uso de muchos consumidores diferentes.
4.4.5.1.1. Se centra en algún mercado limitado y particular o se dirige a mercados masivos de consumidores.
4.4.6. 6. Aplicaciones Web.
4.4.6.1. Las webapps son poco más que un conjunto de archivos de hipertexto vinculados que presentan información con uso de texto y gráficas limitadas.
4.4.7. 7. Software de Ingeligencia Artifical.
4.4.7.1. Hace uso de algoritmos no numéricos para resolver problemas complejos que no son fáciles de tratar computacionalmente o con el análisis directo.
4.4.7.1.1. Las aplicaciones en esta área incluyen robótica, sistemas expertos, reconocimiento de patrones (imagen y voz), redes neurales artificiales, demostración de teoremas y juegos.
4.5. En ciertos casos se elaboran sistemas nuevos, pero en muchos otros se corrigen, adaptan y mejoran aplicaciones ya existentes.
4.5.1. Las generaciones pasadas de los trabajadores del software dejaron un legado en cada una de las categorías mencionadas.
4.5.1.1. Computacion en un Mundo Abierto.
4.5.1.1.1. Desarrollo de software de sistemas y aplicación que permiten a dispositivos móviles, computadoras personales y sistemas empresariales comunicarse a través de redes enormes.
4.5.1.2. Construccion de Redes.
4.5.1.2.1. Son arquitecturas sencillas por ejemplo, planeación financiera personal y aplicaciones sofisticadas que proporcionen un beneficio a mercados objetivo de usuarios finales en todo el mundo.
4.5.1.3. Fuente Abierta.
4.5.1.3.1. Elaborar código fuente que sea autodescriptivo, y también, lo que es más importante, desarrollar técnicas que permitirán tanto a los consumidores como a los desarrolladores saber cuáles son los cambios hechos y cómo se manifiestan dentro del software.
4.6. Software Heredado
4.6.1. Algunos programas son más viejos y a estos se les denomina software heredado, han sido centro de atención y preocupación continuas desde la década de 1960.
4.6.1.1. Además, el software heredado se caracteriza por su longevidad e importancia crítica para el negocio.
4.6.1.1.1. Sin embargo otra característica presente en el software heredado: mala calidad.
4.6.2. Si el software heredado satisface las necesidades de sus usuarios y corre de manera confiable, entonces no falla ni necesita repararse. Sin embargo, conforme pase el tiempo será frecuente que los sistemas de software evolucionen por una o varias de las siguientes razones:
4.6.2.1. 1. El software debe adaptarse para que cumpla las necesidades de los nuevos ambientes del cómputo y de la tecnología.
4.6.2.2. 2. El software debe ser mejorado para implementar nuevos requerimientos del negocio.
4.6.2.3. 3. El software debe ampliarse para que sea operable con otros sistemas o bases de datos
4.6.2.4. 4. La arquitectura del software debe rediseñarse para hacerla viable dentro de un ambiente de redes.
4.6.3. Debe hacerse la reingeniería del sistema heredado para que sea viable en el futuro.
4.6.3.1. La meta de la ingeniería de software moderna es “desarrollar metodologías que se basen en el concepto de evolución.
4.6.3.1.1. Todo ingeniero de software debe reconocer que el cambio es natural. No trate de evitarlo.