B3T1 - Modelos de Ciclo de Vida (PDF)

Bloque 3 - Tema 1 CONCEPTO DEL CICLO DE VIDA DE LOS SISTEMAS Y FASES. MODELOS DE CICLO DE VIDA P rep arac ión Opos ic ion es GESTIÓN DE SISTEMAS E INFORMÁTICA DEL ESTADO B3T1 MODELOS DE CICLO DE VIDA...

Bloque 3 - Tema 1 CONCEPTO DEL CICLO DE VIDA DE LOS SISTEMAS Y FASES. MODELOS DE CICLO DE VIDA P rep arac ión Opos ic ion es GESTIÓN DE SISTEMAS E INFORMÁTICA DEL ESTADO B3T1 MODELOS DE CICLO DE VIDA GSI ÍNDICE Í N D I C E......................................................................................................................................................... 2 1. EL SOFTWARE............................................................................................................................................ 3 1. Definición del software........................................................................................................................ 3 2. Componentes del software.................................................................................................................. 3 3. Características del software................................................................................................................. 4 4. Tipos de software................................................................................................................................. 6 5. Aplicaciones del software..................................................................................................................... 6 2. INGENIERÍA DEL SOFTWARE...................................................................................................................... 9 1. Historia................................................................................................................................................. 9 2. Crisis del software.............................................................................................................................. 10 3. Etapas................................................................................................................................................ 12 4. Objetivo principal de la Ingeniería del Software................................................................................ 13 5. Principios de la Ingeniería del Software............................................................................................. 14 6. Elementos clave de la Ingeniería del Software................................................................................... 15 3. CICLOS DE VIDA DE DESARROLLO SOFTWARE......................................................................................... 16 4. MODELOS DE CICLO DE VIDA DEL SOFTWARE......................................................................................... 17 1. Modelo code and fix........................................................................................................................... 18 2. Modelo en cascada............................................................................................................................ 18 3. Modelo en V....................................................................................................................................... 20 4. Modelo iterativo o evolutivo.............................................................................................................. 21 5. Modelo de desarrollo incremental..................................................................................................... 22 6. Modelo en espiral............................................................................................................................... 23 7. Modelo de prototipos......................................................................................................................... 26 8. Modelos basados en transformaciones............................................................................................. 27 9. Modelo orientado a objetos............................................................................................................... 28 5. DESARROLLO ITERATIVO E INCREMENTAL.............................................................................................. 29 1. Rapid Application Development (RAD)............................................................................................... 30 2. Proceso Unificado de Desarrollo Software (PUDS)............................................................................. 31 6. ISO/IEC 12207......................................................................................................................................... 34 PABLO ARELLANO www.theglobeformacion.com Página 2 B3T1 MODELOS DE CICLO DE VIDA GSI 1. EL SOFTWARE Cuando un software se desarrolla con éxito, cuando satisface las necesidades de las personas que lo utilizan; cuando funciona de forma impecable durante mucho tiempo; cuando es fácil de modificar o incluso es más fácil de utilizar, puede cambiar todas las cosas y de hecho cambiar para mejor. Ahora bien, cuando un software falla, cuando los usuarios no quedan satisfechos, cuando es propenso a errores, cuando es difícil de cambiar e incluso más difícil de utilizar, pueden ocurrir y de hecho ocurren verdaderos desastres. Todos queremos desarrollar un software que haga bien las cosas, evitando que esas cosas malas aparezcan. Para tener éxito al diseñar y construir un software necesitaremos disciplina. Es decir, necesitaremos un enfoque de ingeniería. 1. Definición del software En primer lugar, se va a tratar un concepto tan importante como es el software. Es importante entender este concepto para poder pasar a definir a continuación lo que es la ingeniería del software. Algunas definiciones de software: - IEEE Std. 610 define el software como “programas, procedimientos y documentación y datos asociados, relacionados con la operación de un sistema informático” - Según el Webster’s New Collegiate Dictionary (1975), “software es un conjunto de programas, procedimientos y documentación relacionada asociados con un sistema, especialmente un sistema informático”. El software se puede definir como el conjunto de tres componentes: - Programas (instrucciones): este componente proporciona la funcionalidad deseada y el rendimiento cuando se ejecute. - Datos: este componente incluye los datos necesarios para manejar y probar los programas y las estructuras requeridas para mantener y manipular estos datos. - Documentos: este componente describe la operación y uso del programa. 2. Componentes del software Es importante contar con una definición exhaustiva del software ya que de otra manera se podrían olvidar algunos componentes. Una percepción común es que el software sólo PABLO ARELLANO www.theglobeformacion.com Página 3 B3T1 MODELOS DE CICLO DE VIDA GSI consiste en programas. Sin embargo, los programas no son los únicos componentes del software. Programas: los programas son conjuntos de instrucciones que proporcionan la funcionalidad deseada cuando son ejecutadas por el ordenador. Están escritos usando lenguajes específicos que los ordenadores pueden leer y ejecutar (ensamblador, C, Java, Python…). Los programas también pueden ser generados usando generadores de programas. Datos: los programas proporcionan la funcionalidad requerida manipulando datos. Usan datos para ejercer el control apropiado en lo que hacen. El mantenimiento y las pruebas de los programas también necesitan datos. El diseño del programa asume la disponibilidad de las estructuras de datos tales como bases de datos y archivos que contienen datos. Documentos: además de los programas y los datos, los usuarios necesitan también una explicación de cómo usar el programa. Documentos como manuales de usuario y de operación son necesarios para permitir a los usuarios operar con el sistema. Los documentos también son requeridos por las personas encargadas de mantener el software para entender el interior del software y modificarlo, en el caso en que sea necesario. 3. Características del software A lo largo de los años, se han evolucionado muchas formas de producir bienes de mejor calidad en el sector de las manufacturas. Este conocimiento puede extenderse a la construcción de productos software de mejor calidad si los profesionales del software entienden las características propias del software. Para poder comprender lo que es el software (y consecuentemente la ingeniería del software), es importante examinar las características del software que lo diferencian de otras cosas que el hombre puede construir. El software es esencialmente un conjunto de instrucciones (programas) que proporcionan la funcionalidad requerida, los datos relacionados y documentos. Por lo tanto, el software es un elemento lógico y se diferencia del hardware, un elemento físico, en sus características. El software se desarrolla, no se fabrica en el sentido clásico. Aunque existen similitudes entre el desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente distintas. Cada producto software es diferente porque se construye para cumplir los requisitos únicos de un cliente. Cada software necesita, por lo tanto, ser construido usando un enfoque de ingeniería. Construir un producto software implica entender qué es necesario, diseñar el producto para que cumpla los requisitos, implementar el diseño usando un lenguaje de programación y comprobar que el producto cumple con los requisitos. Todas estas actividades se llevan a PABLO ARELLANO www.theglobeformacion.com Página 4 B3T1 MODELOS DE CICLO DE VIDA GSI cabo mediante la ejecución de un proyecto software y requiere un equipo trabajando de una forma coordinada. El proceso usado para construir software es diferente de la fabricación del hardware, donde las máquinas se usan para producir partes y cada trabajador sólo necesita realizar la tarea asignada o usar una máquina. En el software, el recurso principal son las personas. No es siempre posible acelerar la construcción de software añadiendo personas porque la construcción de software requiere un esfuerzo en equipo. El equipo tiene que trabajar de forma coordinada y compartir un objetivo de proyecto común. Se necesita comunicación efectiva dentro del equipo. Un nuevo miembro del equipo no es inmediatamente productivo y necesita la iniciación adecuada al equipo y la formación para realizar el trabajo. Esto requiere una inversión de tiempo y esfuerzo por parte de los miembros del equipo existentes y les puede distraer de su propio trabajo. Otra característica del software es que no se estropea. Los defectos no detectados harán que falle el programa durante las primeras etapas de su vida. Sin embargo, una vez que se corrigen (suponiendo que no se introducen nuevos errores) los fallos disminuyen. El software no se estropea, pero se deteriora. Durante su vida, el software sufre cambios (mantenimiento). Conforme se hacen los cambios, es bastante probable que se introduzcan nuevos defectos, lo que hace que el software se vaya deteriorando debido a los cambios. Otro aspecto del software es que, debido a que la industria del software es nueva, el software se diferencia del hardware en el aspecto de uso de componentes. Aunque la mayoría de la industria tiende a ensamblar componentes, la mayoría del software se construye a medida. Los componentes reutilizables se han creado para que el ingeniero pueda concentrarse en elementos verdaderamente innovadores de un diseño. En el mundo del software es algo que sólo ha comenzado a lograrse en productos lanzados a gran escala. El componente software debería diseñarse e implementarse para que pueda volver a ser reutilizado en muchos programas diferentes. Hoy en día, se ha extendido la visión de la reutilización para abarcar tanto algoritmos como estructuras de datos, permitiendo al ingeniero del software crear nuevas aplicaciones a partir de las partes reutilizables. El hardware usa componentes estándar con funciones e interfaces bien definidas. El uso de estos componentes ayuda a evitar reinventar la rueda. La fase de diseño en el ciclo de vida de un producto hardware implica seleccionar los componentes disponibles más adecuados y decidir el enfoque para montarlos. Los componentes de hardware estándar son útiles porque conducen a: - Reducir el coste y el tiempo de lanzamiento al mercado. - Buena calidad. PABLO ARELLANO www.theglobeformacion.com Página 5 B3T1 MODELOS DE CICLO DE VIDA GSI - Ingeniería rápida. - Fácil mantenimiento. - Fácil mejora. El software se crea normalmente desde cero. Con frecuencia se construye de acuerdo a los requisitos específicos de un cliente y no se crea por la unión de componentes existentes. Como la industria del hardware, la industria del software está intentando adoptar el mecanismo de reutilizar para hacer más fácil y más rápida la construcción. Las ventajas de la reutilización de software están siendo entendidas y apreciadas. Existen algunos elementos reutilizables a través de librerías de funciones y objetos reutilizables que combinan funciones y datos. Mientras que la reutilización y el montaje basado en componentes se están incrementando, la mayoría del software continúa siendo construido de forma personalizada, y los niveles de reutilización actuales están lejos de los que deberían ser. Además, la tarea de identificar componentes reutilizables potenciales es difícil porque cada producto software es único y distinto. La industria del software tiene procesos bien definidos para la reutilización de componentes. Esto incluye procesos para la construcción de componentes, almacenamiento de los mismos en librerías de donde se pueden extraer para su reutilización y entonces incorporarlos. A lo largo de los años, la industria del software espera crear componentes reutilizables específicos a dominios de aplicación particulares. 4. Tipos de software El software puede dividirse en dos grandes categorías: - Software de aplicaciones: se usan para proveer servicios a clientes y ejecutar negocios de forma más eficiente. El software de aplicaciones puede ser un sistema pequeño o uno grande integrado. Como ejemplos de este tipo de software están: un sistema de cuentas, un sistema de planificación de recursos… - Software de sistemas: el software de sistemas se usa para operar y mantener un sistema informático. Permite a los usuarios usar los recursos del ordenador directamente y a través de otro software. Algunos ejemplos de este tipo de software son: sistemas operativos, compiladores y otras utilidades del sistema. 5. Aplicaciones del software El software puede aplicarse en cualquier situación en la que se haya definido previamente un conjunto específico de pasos procedimentales, es decir, un algoritmo (excepciones notables a esta regla son el software de los sistemas expertos y de redes neuronales). El PABLO ARELLANO www.theglobeformacion.com Página 6 B3T1 MODELOS DE CICLO DE VIDA GSI contenido y determinismo de la información son factores importantes a considerar para determinar la naturaleza de una aplicación software. El contenido se refiere al significado y a la forma de la información de entrada y salida. Por ejemplo, muchas aplicaciones bancarias usan unos datos de entrada muy estructurados (una base de datos) y producen informes con determinados formatos. El software que controla una máquina automática (por ejemplo: un control numérico) acepta elementos discretos con una estructura limitada y produce órdenes concretas para la máquina en rápida sucesión. El determinismo de la información se refiere a la predictibilidad del orden y del tiempo de llegada de los datos. Un programa de análisis de ingeniería acepta datos que están en un orden predefinido, ejecuta algoritmos de análisis sin interrupción y produce los datos resultantes en un informe o formato gráfico. Un sistema operativo multiusuario, por otra parte, acepta entradas que tienen un contenido variado y que se producen en instantes arbitrarios, ejecuta algoritmos que pueden ser interrumpidos en condiciones externas y produce una salida que depende de una función del entorno y del tiempo. Las aplicaciones con estas características se dice que son indeterminadas. Algunas veces es difícil establecer categorías genéricas para las aplicaciones del software que sean significativas. Conforme aumenta la complejidad del software, es más difícil establecer compartimentos nítidamente separados. Las siguientes áreas del software indican la amplitud de las aplicaciones potenciales: - Software de sistemas: el software de sistemas es un conjunto de programas que han sido escritos para servir a otros programas. Algunos programas de sistemas (por ejemplo: compiladores, editores y utilidades de gestión de archivos) procesan estructuras de información complejas pero determinadas. Otras aplicaciones de sistemas (por ejemplo: ciertos componentes del sistema operativo, utilidades de manejo de periféricos, procesadores de telecomunicaciones) procesan datos en gran medida indeterminados. En cualquier caso, el área del software de sistemas se caracteriza por una fuerte interacción con el hardware de la computadora; una gran utilización por múltiples usuarios; una operación concurrente que requiere una planificación, una compartición de recursos y una sofisticada gestión de procesos; unas estructuras de datos complejas y múltiples interfaces externas. - Software de tiempo real: el software que coordina/analiza/controla sucesos del mundo real conforme ocurren. Entre los elementos del software de tiempo real se incluyen: un componente de adquisición de datos que recolecta y da formato a la información recibida del entorno externo, un componente de análisis que transforma la información según lo requiera la aplicación, un componente de control/salida que responda al entorno externo y un componente de monitorización que coordina todos los demás componentes, de forma que pueda mantenerse la respuesta en tiempo real. - Software de gestión: el proceso de la información comercial constituye la mayor de las áreas de aplicación del software. Los sistemas discretos (por ejemplo: nóminas, cuentas de haberes-débitos, inventarios, etc.) han evolucionado hacia el software de sistemas de información de gestión (SIG) que accede a una o más bases de datos que contienen información comercial. Las aplicaciones en esta área reestructuran los datos existentes para facilitar las operaciones comerciales o gestionar la toma de decisiones. Además de las tareas convencionales de procesamiento de datos, las aplicaciones de software de PABLO ARELLANO www.theglobeformacion.com Página 7 B3T1 MODELOS DE CICLO DE VIDA GSI gestión también realizan cálculo interactivo (por ejemplo: el procesamiento de transacciones en puntos de venta). - Software de ingeniería y científico: este tipo de software está caracterizado por los algoritmos de manejo de números. Las aplicaciones van desde la astronomía a la vulcanología, desde el análisis de la presión de los automotores a la dinámica orbital de las lanzaderas espaciales y desde la biología molecular a la fabricación automática. Sin embargo, las nuevas aplicaciones del área de ingeniería/ciencia se han alejado de los algoritmos convencionales numéricos. El diseño asistido por computadora (CAD), la simulación de sistemas y otras aplicaciones interactivas, han comenzado a coger características del software de tiempo real e incluso de software de sistemas. - Software empotrado: los productos inteligentes se han convertido en algo común en casi todos los mercados de consumo e industriales. El software empotrado reside en memoria de sólo lectura y se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas (por ejemplo: el control de las teclas de un horno microondas) o suministrar una función significativa y con capacidad de control (por ejemplo: funciones digitales en un automóvil, tales como control de la gasolina, indicadores en el salpicadero, sistemas de frenado, etc.) - Software de computadoras personales: el mercado del software de computadoras personales ha germinado en las pasadas décadas. El procesamiento de textos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimiento, gestión de bases de datos, aplicaciones financieras, de negocios y personales y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones. - Software basado en web: las páginas web buscadas por un explorador son software que incorpora instrucciones ejecutables y datos. - Software de inteligencia artificial: el software de inteligencia artificial hace uso de algoritmos no numéricos para resolver problemas complejos para los que no son adecuados el cálculo o el análisis directo. Los sistemas expertos, también llamados sistemas basados en el conocimiento, reconocimiento de patrones (imágenes y voz), redes neuronales artificiales, prueba de teoremas y los juegos son representativos de las aplicaciones de esta categoría. PABLO ARELLANO www.theglobeformacion.com Página 8 B3T1 MODELOS DE CICLO DE VIDA GSI 2. INGENIERÍA DEL SOFTWARE El término ingeniería de software se define en el DRAE (Diccionario de la Real Academia Española) como: 1) Conjunto de conocimientos y técnicas que permiten aplicar el saber científico a la utilización de la materia y de las fuentes de energía. 2) Profesión y ejercicio del ingeniero Y el término ingeniero se define como: 1) Persona que profesa o ejerce la ingeniería. De igual modo, la Real Academia de Ciencias Exactas, Físicas y Naturales de España define el término Ingeniería como: conjunto de conocimientos y técnicas cuya aplicación permite la utilización racional de los materiales y de los recursos naturales, mediante invenciones, construcciones u otras realizaciones provechosas para el hombre. Otras definiciones: - Ingeniería del Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas de software (Zelkovitz, 1978). - Ingeniería del Software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar (funcionar) y mantenerlos. Se conoce también como desarrollo de software o producción de software (Bohem, 1976). - Ingeniería del Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable que sea fiable y trabaje en máquinas reales (Bauer, 1972). - La aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software (IEEE, 1993). La definición de IEEE describe la ingeniería del software como un enfoque sistemático cubriendo los aspectos del desarrollo, operación y mantenimiento. Este enfoque es disciplinado y cuantificable. 1. Historia El término ingeniería del software apareció por primera vez en la conferencia de ingeniería de software de la OTAN en 1968 y fue mencionado para provocar el pensamiento sobre la crisis de software del momento. Desde entonces, ha continuado como una profesión y campo de estudio dedicado a la creación de software de alta calidad, barato, con capacidad de mantenimiento y rápido de construir. Debido a que el campo es todavía relativamente joven comparado con otros campos de la ingeniería, hay todavía mucho trabajo y debate PABLO ARELLANO www.theglobeformacion.com Página 9 B3T1 MODELOS DE CICLO DE VIDA GSI sobre qué es realmente la ingeniería del software, y si se merece el título de ingeniería. Ha crecido orgánicamente fuera de las limitaciones de ver el software sólo como programación. Desde principio el desafío principal fue desarrollar el hardware de los ordenadores de forma que se redujera el coste del procesamiento y almacenamiento de los datos. Sin embargo, a partir de la revolución microelectrónica de los años ochenta la capacidad de proceso de las máquinas ha aumentado considerablemente y han disminuido casi en la misma proporción los costes, lo que ha hecho que el reto principal de la informática se haya trasladado a reducir el coste y mejorar la calidad de las soluciones que se implementan con el software. El contexto en que se ha desarrollado el software está muy ligado a la evolución histórica de los sistemas informáticos. Siguiendo a Pressman, se puede contemplar la evolución del software en las siguientes cuatro épocas: - 1ª época (1950 a 1960-65). El software se orienta al trabajo por lotes, apenas hay una distribución comercial del mismo y, prácticamente, todo el software se desarrolla a medida y generalmente sin ninguna planificación ni metodología sistemática. - 2ª época (1960-65 a 1975). Es la época del software orientado a los trabajos interactivos y en tiempo real y en la que aparece la primera generación de los sistemas de gestión de base de datos (SGBD). El software comienza a producirse comercialmente por distintas empresas y empieza a tomar importancia su mantenimiento, con el consiguiente gasto de recursos. Es el comienzo de la “crisis del software”. - 3ª época (1975 a 1985-90). El software se orienta a los sistemas distribuidos, las redes de área local y las comunicaciones comienzan a adquirir gran importancia y se demanda un software que sea capaz de acceder rápidamente a los datos. Es la época del despegue de la informática; desciende el coste del hardware, aparecen los primeros ordenadores personales con el correspondiente desarrollo de paquetes para los mismos y en definitiva, el software adquiere un gran impacto en el consumidor. - 4ª época (a partir de 1990). es la época del software para sistemas expertos y del software de inteligencia artificial. Por otra parte, las tecnologías orientadas a objetos, las técnicas de cuarta generación (T4G) y la tecnología CASE comienzan a desplazar a otras técnicas de desarrollo del software en muchas áreas de aplicación. Se agudiza la «crisis del software» debido a la complejidad del mismo y a la creciente demanda y en paralelo a ello se potencia la ingeniería del software como disciplina tendente a minimizar la crisis. 2. Crisis del software La rápida expansión de la Informática llevó a la escritura de millones de líneas de código antes de que se empezaran a plantear de manera seria metodologías para el diseño y la construcción de sistemas software y métodos para resolver los problemas de mantenimiento, fiabilidad, etc. Esta expansión sin control tuvo como consecuencia la denominada “crisis del software”. PABLO ARELLANO www.theglobeformacion.com Página 10 B3T1 MODELOS DE CICLO DE VIDA GSI La “crisis del software” es el nombre genérico que se ha acuñado para referirse a un conjunto de problemas que se han ido encontrando en el desarrollo del software. Esta problemática no sólo se limita al software que no funciona adecuadamente, sino que abarca otros aspectos como: - La forma de desarrollar el software. - El mantenimiento de un volumen creciente de software existente. - La forma de satisfacer la demanda creciente de software. Los síntomas que hacen palpable la aparición, de la “crisis del software” son, entre otros, los siguientes: - Expectativas: los sistemas no responden a las expectativas que de ellos tienen los usuarios. - Fiabilidad: los programas fallan demasiado a menudo. - Costo: los costos del software son muy difíciles de prever y, frecuentemente, son muy superiores - a lo esperado. - Plazos: el software se suele entregar tarde y con menos prestaciones de las ofertadas. - Portabilidad: es difícil cambiar un programa de su entorno hardware, aun cuando las tareas a realizar son las mismas. - Mantenimiento: la modificación del software es una tarea costosa, compleja y propensa a errores. - Eficiencia: los esfuerzos que se hacen para el desarrollo del software no hacen un aprovechamiento óptimo de los recursos disponibles (personas, tiempo, dinero, herramientas, etc.). La solución a la “crisis del software” se centra, pues, en abordar y resolver los siguientes problemas principales: - La planificación del proyecto software y la estimación de los costes de desarrollo, que son muy imprecisos. - La productividad de las personas, que no se corresponde con la demanda de sus servicios. - La calidad del producto software, que es, en muchos casos, inadecuada. No hay una receta única que solucione la «crisis del software», sin embargo, se pueden combinar una serie de métodos para todas las fases del desarrollo del software que disciplinen el mismo. Surge así la Ingeniería del Software. PABLO ARELLANO www.theglobeformacion.com Página 11 B3T1 MODELOS DE CICLO DE VIDA GSI 3. Etapas La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes: 1) Análisis de requisitos Extraer los requisitos de un producto software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el software tiene que hacer, se requiere habilidad y experiencia en la ingeniería del software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento Especificación de Requisitos. Asimismo, se define un diagrama de entidad/relación, en el que se plasman las principales entidades que participarán en el desarrollo de software. La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, se habla de la Ingeniería de Requisitos. La IEEE Std. 830-1998 normaliza la creación de las especificaciones de requisitos software. 2) Especificación Es la tarea de escribir detalladamente el software a ser desarrollado, en una forma matemáticamente rigurosa. En la realidad, la mayoría de las buenas especificaciones han sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Las especificaciones son más importantes para las interfaces externas, que deben permanecer estables. 3) Diseño y arquitectura Se refiere a determinar cómo funcionará el software de forma general sin entrar en detalles. Consisten en incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se definen los casos de uso para cubrir las funciones que realizará el sistema, y se transformarán las entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a la programación orientada a objetos. 4) Programación Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería del software, pero no necesariamente es la que demanda mayor trabajo ni la más complicada. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados, así como al diseño previamente realizado. 5) Prueba Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación del problema. Una técnica de prueba es probar por separado cada módulo del software y luego probarlo de forma integral, para así llegar al objetivo. Se considera PABLO ARELLANO www.theglobeformacion.com Página 12 B3T1 MODELOS DE CICLO DE VIDA GSI una buena práctica que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó. 6) Mantenimiento Mantener y mejorar el software para solventar errores descubiertos y tratar con nuevos requisitos. El mantenimiento puede ser de cuatro tipos: - PERFECTIVO: mejorar la calidad interna de los sistemas. - EVOLUTIVO: incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambio en las necesidades del usuario). - ADAPTATIVO: modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, software de base, gestores de base de datos, comunicaciones. - CORRECTIVO: corrección de errores. Estas etapas se pueden agrupar en tres fases genéricas: - Fase de DEFINICIÓN: dar respuesta a la pregunta “¿qué hacer?”, por tanto, en esta fase se han de identificar los requerimientos clave del sistema y del software. La fase de definición comprende: el análisis global del sistema, la planificación del proyecto software y el análisis de los requerimientos del software. - Fase de DESARROLLO: dar respuesta a la pregunta “¿cómo hacerlo?”. Dependiendo del paradigma utilizado varían los métodos de llevar a cabo el desarrollo del software, pero, de cualquier manera, han de producirse siempre tres pasos concretos: el Diseño del Software, la Codificación y las Pruebas del Software. - Fase de MANTENIMIENTO: La fase de mantenimiento se centra en la cuestión ¿qué hay que cambiar? El mantenimiento del software se enfoca sobre el cambio que va asociado a una corrección de errores, a nuevas adaptaciones requeridas por la evolución del entorno del software o a modificaciones debidas a los cambios de requerimientos del cliente. La fase de mantenimiento reaplica los pasos de las fases de definición y desarrollo del software. 4. Objetivo principal de la Ingeniería del Software Hemos visto que todas las definiciones de la ingeniería del software se centran en el uso de un enfoque sistemático para la construcción de software. El objetivo primario de la ingeniería del software es construir un producto de alta calidad de una manera oportuna. Trata de conseguir este objetivo primario usando un enfoque de ingeniería. La ingeniería implica un conjunto de principios fundamentales que deberían seguirse siempre. Incluyen actividades explícitas para el entendimiento del problema y la comunicación con el cliente, métodos definidos para representar un diseño, mejores PABLO ARELLANO www.theglobeformacion.com Página 13 B3T1 MODELOS DE CICLO DE VIDA GSI prácticas para la implementación de la solución y estrategias y tácticas sólidas para las pruebas. Si se siguen los principios básicos, esto resulta en productos de alta calidad. Para conseguir el objetivo de construir productos de alta calidad dentro de la planificación, la ingeniería del software emplea una serie de prácticas para: - Entender el problema. - Diseñar una solución. - Implementar la solución correctamente. - Probar la solución. - Gestionar las actividades anteriores para conseguir alta calidad. La ingeniería del software representa un proceso formal que incorpora una serie de métodos bien definidos para el análisis, diseño, implementación y pruebas del software y sistemas. Además, abarca una amplia colección de métodos y técnicas de gestión de proyectos para el aseguramiento de la calidad y la gestión de la configuración del software. 5. Principios de la Ingeniería del Software Entre los principios más destacados de la ingeniería del software, podemos señalar los siguientes: - Haz de la calidad la razón de trabajar. - Una buena gestión es más importante que una buena tecnología. - Las personas y el tiempo no son intercambiables. - Seleccionar el modelo de ciclo de vida adecuado. - Entregar productos al usuario lo más pronto posible. - Determinar y acotar el problema antes de escribir los requisitos. - Realizar un diseño. - Minimizar la distancia intelectual. - Documentar. - Las técnicas son anteriores a las herramientas. - Primero hazlo correcto, luego hazlo rápido. - Probar, probar y probar. - Introducir las mejoras y modificaciones con cuidado. - Asunción de responsabilidades. - La entropía del software es creciente. - La gente es la clave del éxito. - Nunca dejes que tu jefe o cliente te convenza para hacer un mal trabajo. PABLO ARELLANO www.theglobeformacion.com Página 14 B3T1 MODELOS DE CICLO DE VIDA GSI - La gente necesita sentir que su trabajo es apreciado. - La educación continua es responsabilidad de cada miembro del equipo. - El compromiso del cliente es el factor más crítico en la calidad del software. - Tu mayor desafío es compartir la visión del producto final con el cliente. - La mejora continua de tu proceso de desarrollo de software es posible y esencial. - Tener procedimientos escritos de desarrollo de software puede ayudar a crear una cultura compartida de buenas prácticas. - La calidad es el principal objetivo; la productividad a largo plazo es una consecuencia de una alta calidad. - Haz que los errores los encuentre un colaborador, no un cliente. - Una clave en la calidad en el desarrollo de software es realizar iteraciones en todas las fases del desarrollo excepto en la codificación. - La gestión de errores y solicitud de cambios es esencial para controlar la calidad y el mantenimiento. - Si mides lo que haces puedes aprender a hacerlo mejor. - Haz lo que tenga sentido; no recurras a los dogmas. - No puedes cambiar todo de una vez. Identifica los cambios que se traduzcan en los mayores beneficios, y comienza a implementarlos. 6. Elementos clave de la Ingeniería del Software El enfoque de ingeniería del software cuenta con un compromiso organizacional con la calidad porque no es posible incorporar la ingeniería del software en una organización que no está centrada en conseguir calidad. La ingeniería del software es una tecnología multicapa. Se puede ver como un conjunto de componentes estratificados, que reposan sobre ese enfoque de calidad. Estos componentes que forman parte de la ingeniería del software son: - Procesos: un marco de trabajo que ayuda al jefe de proyecto a controlar la gestión del proyecto y las actividades de ingeniería. - Métodos: las actividades técnicas requeridas para la creación de productos de trabajo. - Herramientas: la ayuda automatizada para los procesos y métodos (por ejemplo, CASE). PABLO ARELLANO www.theglobeformacion.com Página 15 B3T1 MODELOS DE CICLO DE VIDA GSI 3. CICLOS DE VIDA DE DESARROLLO SOFTWARE El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado (muere). También se denomina a veces paradigma. Entre las funciones que debe tener un ciclo de vida se pueden destacar: - Determinar el orden de las fases del proceso de software. - Establecer los criterios de transición para pasar de una fase a la siguiente. - Definir las entradas y salidas de cada fase. - Describir los estados por los que pasa el producto. - Describir las actividades a realizar para transformar el producto. - Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollar… Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas que se pueden planificar. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones a los resultados intermedios que se van produciendo (realimentación). - Fases: una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales). - Entregables: son los productos intermedios que generan las fases. Pueden ser materiales o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos. Es importante no confundir el concepto de ciclo de vida con el de metodología. Mientras que el ciclo de vida indica QUÉ actividades hay que realizar y en qué orden, la metodología indica CÓMO avanzar en la construcción del sistema, esto es, con qué técnicas, y entre sus características está la de determinar los recursos a utilizar o las personas implicadas en cada actividad. PABLO ARELLANO www.theglobeformacion.com Página 16 B3T1 MODELOS DE CICLO DE VIDA GSI 4. MODELOS DE CICLO DE VIDA DEL SOFTWARE La ingeniería del software establece y se vale de una serie de modelos que establecen y muestran las distintas etapas y estados por los que pasa un producto software, desde su concepción inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les denomina “Modelos de ciclo de vida del software”. Los modelos de ciclo de vida del software describen las fases del ciclo de software y el orden en que se ejecutan las fases. Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociados entre estas etapas. Un modelo de ciclo de vida del software: - Describe las fases principales de desarrollo de software. - Define las fases primarias esperadas de ser ejecutadas durante esas fases. - Ayuda a administrar el progreso del desarrollo. - Provee un espacio de trabajo para la definición de un proceso detallado de desarrollo de software. En cada una de las etapas de un modelo de ciclo de vida, se pueden establecer una serie de objetivos, tareas y actividades que lo caracterizan. Existen distintos modelos de ciclo de vida, y la elección de un modelo para un determinado tipo de proyecto es realmente importante; el orden es uno de estos puntos importantes. Existen varias alternativas de modelos de ciclo de vida. A continuación, se muestran algunos de los modelos tradicionales y más utilizados. Los MVC tradicionales son: - modelo en cascada, - modelo en V, - modelo iterativo, - modelo de desarrollo incremental, - modelo en espiral, - modelo de prototipos, - modelo basado en transformaciones, - modelo orientado a objetos. PABLO ARELLANO www.theglobeformacion.com Página 17 B3T1 MODELOS DE CICLO DE VIDA GSI 1. Modelo code and fix Consiste en no aplicar ningún modelo de ciclo de vida y, por lo tanto, no es recomendable. Se comienza a codificar inmediatamente, se prueba para detectar errores y éstos se van corrigiendo sobre la marcha según aparecen. No existe documentación y supone grandes costes de mantenimiento a largo plazo. 2. Modelo en cascada Presentado en 1.970 por Royce, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. El modelo en cascada (o waterfall) es un proceso de desarrollo secuencial, en el que el desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida. En el modelo original de Royce, existían las siguientes fases: - Especificación de requisitos. - Diseño. - Construcción (Implementación o codificación). - Integración. - Pruebas. - Instalación. - Mantenimiento. Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma puramente secuencial. PABLO ARELLANO www.theglobeformacion.com Página 18 B3T1 MODELOS DE CICLO DE VIDA GSI Desde su presentación, el modelo en cascada ha tenido un papel fundamental en el desarrollo de proyectos software. Ha sido, y todavía sigue siendo, el más utilizado, tanto que este modelo se conoce con el nombre de “ciclo de vida clásico”, si bien incorporando infinidad de variaciones que eliminan el carácter simplista del mismo. Aun así, existen una serie de limitaciones que justifican la necesidad de definir otros modelos. Ventajas - Las etapas están organizadas de un modo lógico. - Cada etapa incluye cierto proceso de revisión, y se necesita una aceptación del producto antes de que la salida de la etapa pueda usarse. El modelo del ciclo de vida en cascada está regido por la documentación, es decir, la decisión del paso de una fase a la siguiente se toma en función de si la documentación asociada a dicha fase está completa o no. - El ciclo es iterativo, esto es, aunque el flujo básico es de arriba hacia abajo, los problemas encontrados en las etapas inferiores afectan a las decisiones de las etapas superiores. Inconvenientes Las principales críticas o limitaciones del modelo en cascada se centran en sus características básicas de secuencialidad y necesidad de utilizar los resultados de una fase como arranque de la siguiente, de manera que el sistema sólo se puede validar cuando está terminado. - Respecto a la secuencialidad se aduce que existen muchos proyectos para los cuales el orden que propone el modelo en cascada es inviable. - Respecto al segundo inconveniente se argumenta que el modelo, en su formulación pura, no prevé revisiones o validaciones intermedias por parte del usuario y los resultados sólo se ven al final de una serie de fases y tareas, de forma que si se produce un error en las primeras fases, éste sólo se detectará al final y su corrección tendrá un costo muy elevado. - Por último, una limitación más es que el modelo en cascada asume que los requisitos de un sistema pueden ser congelados antes de comenzar el diseño, lo que, para sistemas totalmente nuevos, es poco realista y, además, requiere seleccionar previamente el hardware. Variantes Existen muchas variantes de este modelo. En respuesta a los problemas percibidos con el modelo en cascada puro, se introdujeron muchos modelos de cascada modificados. Estos modelos pueden solventar algunas o todas las críticas del modelo en cascada puro. De hecho muchos de los modelos utilizados tienen su base en el modelo en cascada. El modelo SASHIMI (llamado así porque tiene fases solapadas, como el pescado japonés sashimi) fue creado originalmente por Peter DeGrace. A veces se hace referencia a él como el modelo en cascada con fases superpuestas o el modelo en cascada con retroalimentación. Ya que las fases en el modelo sashimi se superponen, lo que implica que PABLO ARELLANO www.theglobeformacion.com Página 19 B3T1 MODELOS DE CICLO DE VIDA GSI se puede actuar durante las etapas anteriores. Por ejemplo, ya que las fases de diseño e implementación se superpondrán en el modelo sashimi, los problemas de implementación se pueden descubrir durante las fases de diseño e implementación del proceso de desarrollo. Esto ayuda a aliviar muchos de los problemas asociadas con la filosofía del modelo en cascada. 3. Modelo en V El modelo en V se desarrolló para terminar con algunos de los problemas que se vieron utilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se introducían hasta el final del proyecto. El modelo en V establece que las pruebas necesitan empezarse lo más pronto posible en el ciclo de vida. También muestra que las pruebas no son sólo una actividad basada en la ejecución. Hay una variedad de actividades que se han de realizar antes del fin de la fase de codificación. Estas actividades deberían ser llevadas a cabo en paralelo con las actividades de desarrollo, y los técnicos de pruebas necesitan trabajar con los desarrolladores y analistas de negocio de tal forma que puedan realizar estas actividades y tareas y producir una serie de entregables de pruebas. Los productos de trabajo generados por los desarrolladores y analistas de negocio durante el desarrollo son las bases de las pruebas en uno o más niveles. El modelo en V es un modelo que ilustra cómo las actividades de prueba (verificación y validación) se pueden integrar en cada fase del ciclo de vida. Dentro del modelo en V, las pruebas de validación tienen lugar especialmente durante las etapas tempranas, por ejemplo, revisando los requisitos de usuario y después, por ejemplo, durante las pruebas de aceptación de usuario. El modelo en V es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. Describe las actividades y resultados que han de ser producidos durante el desarrollo del producto. La parte izquierda de la V representa la descomposición de los requisitos y la creación de las especificaciones del sistema. El lado derecho de la V representa la integración de las partes y su verificación. V significa “Validación y Verificación”. PABLO ARELLANO www.theglobeformacion.com Página 20 B3T1 MODELOS DE CICLO DE VIDA GSI Realmente las etapas individuales del proceso pueden ser casi las mismas que las del modelo en cascada. Sin embargo hay una gran diferencia. En vez de ir para abajo de una forma lineal las fases del proceso vuelven hacia arriba tras la fase de codificación, formando una V. La razón de esto es que para cada una de las fases de diseño se ha encontrado que hay un homólogo en las fases de pruebas que se correlacionan. Como ventaja principal destaca una alta oportunidad de éxito sobre el modelo en cascada debido al desarrollo de planes de prueba en etapas tempranas del ciclo de vida. Respecto a los inconvenientes o críticas resaltar que: es un modelo muy rígido como el modelo en cascada, el software se desarrolla durante la fase de implementación por lo que no se producen prototipos del software y el modelo no proporciona caminos claros para problemas encontrados durante las fases de pruebas 4. Modelo iterativo o evolutivo Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos. Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El cliente es quien después de cada iteración evalúa el producto y lo corrige o propone mejoras. Estas iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del cliente. Es muy similar al modelo de desarrollo incremental. La principal diferencia está en que en el modelo incremental se presupone que todos los requisitos son conocidos al comienzo, en el modelo evolutivo se asume que NO todos los requerimientos son conocidos desde el primer momento. PABLO ARELLANO www.theglobeformacion.com Página 21 B3T1 MODELOS DE CICLO DE VIDA GSI Una de las principales ventajas que ofrece este modelo es que no hace falta que los requisitos estén totalmente definidos al inicio del desarrollo, sino que se pueden ir refinando en cada una de las iteraciones. El no ser necesario tener los requisitos definidos desde el principio, puede verse también como un inconveniente ya que pueden surgir problemas relacionados con la arquitectura. 5. Modelo de desarrollo incremental El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Se basa en la filosofía de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. El modelo incremental parte de la hipótesis de que inicialmente se conocen todos los requisitos y éstos se van incorporando al sistema en versiones sucesivas. Cada vez que se desarrolla una nueva versión es una versión anterior sin cambios, más un número de nuevas funciones. Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto esencial, sólo con los requisitos básicos. Este modelo se centra en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del PABLO ARELLANO www.theglobeformacion.com Página 22 B3T1 MODELOS DE CICLO DE VIDA GSI producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación. Se pueden citar como ventajas de este modelo: se genera software operativo de forma rápida y en etapas tempranas del ciclo de vida del software, es más fácil probar y depurar en una iteración más pequeña, es más fácil gestionar riesgos y cada iteración es un hito gestionado fácilmente. Respecto a los inconvenientes destacan: se requiere una experiencia importante para definir los incrementos y distribuir en ellos las tareas de forma proporcionada, cada fase de una iteración es rígida y no se superponen con otras y pueden surgir problemas referidos a la arquitectura del sistema porque no todos los requisitos se han reunido, ya que se supone que todos ellos se han definido al inicio. 6. Modelo en espiral El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado de forma generalizada en la ingeniería del software. Las actividades de este modelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgos, comenzando por el bucle anterior. El modelo de ciclo de vida en espiral tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las posibles alternativas de desarrollo, se opta por la de riesgos más asumibles y se hace un ciclo de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelven a evaluar las nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, así hasta que llegue un momento en el que el producto software desarrollado sea aceptado y no necesite seguir mejorándose con otro nuevo ciclo. PABLO ARELLANO www.theglobeformacion.com Página 23 B3T1 MODELOS DE CICLO DE VIDA GSI Este modelo de desarrollo combina las características del modelo de prototipos y el modelo en cascada. El modelo en espiral está pensado para proyectos largos, caros y complicados (como por ejemplo, la creación de un sistema operativo). Este modelo básicamente consiste en una serie de ciclos que se repiten en forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada ciclo de la espiral se sigue un modelo en cascada, pero no necesariamente ha de ser así. Tareas Para cada ciclo habrá cuatro actividades: 1. Determinar o fijar objetivos: a. Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario. b. Fijar las restricciones. c. Identificación de riesgos del proyecto y estrategias alternativas para evitarlos. d. Hay una cosa que solo se hace una vez: planificación inicial o previa. 2. Análisis del riesgo: a. Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos. 3. Desarrollar, verificar y validar (probar): a. Tareas de la actividad propia y de prueba. b. Análisis de alternativas e identificación de resolución de riesgos. c. Dependiendo del resultado de la evaluación de riesgos, se elige un modelo para el desarrollo, que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así, por ejemplo, si los riesgos de la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. 4. Planificar: a. Revisamos todo lo que hemos hecho, evaluándolo y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad. El proceso empieza en la posición central. Desde allí se mueve en el sentido de las agujas del reloj. PABLO ARELLANO www.theglobeformacion.com Página 24 B3T1 MODELOS DE CICLO DE VIDA GSI Las cuatro regiones del gráfico son: - La tarea de determinación de objetivos/PLANIFICACIÓN: para definir los requisitos y las restricciones para el producto y definir las posibles alternativas. - La tarea de ANÁLISIS DE RIESGOS: para evaluar riesgos tanto técnicos como de gestión. - La tarea de INGENIERÍA: para diseñar e implementar uno o más prototipos o ejemplos de la aplicación. - La tarea de evaluación del cliente/PLANIFICACIÓN: para definir recursos, responsabilidades, hitos y planificaciones. La dimensión radial indica los costes de desarrollo acumulativos, mientras que la dimensión angular indica el progreso hecho en cumplimentar cada fase. Ventajas del modelo: el análisis de riesgos se hace de forma explícita y clara reduciendo riesgos del proyecto, incorpora objetivos de calidad, integra el desarrollo con el mantenimiento, se produce software en etapas tempranas del ciclo de vida y suele ser adecuado para proyectos largos de misión crítica. Inconvenientes: es un modelo que genera mucho trabajo adicional, al ser el análisis de riesgos una de las tareas principales exige un alto nivel de experiencia y cierta habilidad en los analistas de riesgos. Además se desaconseja su uso para sistemas pequeños al ser poco operativo. Variante: modelo en espiral WIN WIN. Se basa en el modelo en espiral e incorpora negociación inicial (conjunto de actividades de negociación al principio de cada paso alrededor de la espiral), también introduce 3 hitos en el proceso llamados "puntos de fijación", que ayudan a establecer la completitud de un ciclo de la espiral, y proporcionan hitos de decisión antes de continuar el proyecto de desarrollo del software. Las mejores negociaciones se fuerzan en obtener «Victoria & Victoria» (Win & Win), es decir, que el PABLO ARELLANO www.theglobeformacion.com Página 25 B3T1 MODELOS DE CICLO DE VIDA GSI cliente gane obteniendo el producto que lo satisfaga y el desarrollador también gane consiguiendo presupuesto y fecha de entrega realista. 7. Modelo de prototipos Un cliente, a menudo, define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficiencia de un algoritmo, de la calidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombre-máquina. En estas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque. El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un diseño rápido. El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer. Este modelo se suele usar como parte de la tarea de especificación de requisitos o justo antes de la misma. Existen varios modelos derivados del uso de prototipos: - Prototipo CLÁSICO. Es un prototipo desechable, que se usa para ayudar al cliente a identificar los requisitos, y en el que se implantan sólo aquellos aspectos del sistema que se entienden mal o son desconocidos. - Prototipo EVOLUTIVO. Aporta a los usuarios una representación física de las partes clave del sistema antes de la implantación. Una vez definidos todos los requisitos, el prototipo evolucionará hacia el sistema final. En los prototipos evolutivos se implantan aquellos requisitos y necesidades que son claramente entendidos, utilizando análisis y diseño en detalle así como datos reales. PABLO ARELLANO www.theglobeformacion.com Página 26 B3T1 MODELOS DE CICLO DE VIDA GSI Dentro del prototipado evolutivo es importante destacar el modelo RAD (Rapid Application Development). Las principales ventajas son las siguientes: - Los requisitos de los usuarios son más fáciles de determinar, y la implantación del sistema es más sencilla debido a que los usuarios conocen lo que esperan. Además, el sistema resultante es el sistema deseado y necesita pocos cambios. - Los sistemas se desarrollan más rápidamente, y el esfuerzo de análisis y programación y, por tanto, el coste de desarrollo se reduce. - El prototipado facilita la comunicación con los usuarios, en concreto, mejora la comunicación entre usuario y analista y los sistemas son más fáciles de aprender y utilizar por los usuarios finales. En cuanto a los principales inconvenientes, cabe citar los siguientes: - El prototipado crea incorrectas expectativas en el usuario, que puede ver el prototipo como sistema final. - Se producen inconsistencias entre el prototipo y el sistema final, ya que el prototipo sólo es un paso intermedio y no tiene por qué ser idéntico al sistema final. - EI prototipado no es apto para proyectos muy grandes a largo plazo, ni incluso para aplicaciones pequeñas de menos de un mes de tiempo de desarrollo. EL tiempo medio de desarrollo estimado para éxitos del prototipado es en aplicaciones o proyectos de tamaño medio cuya duración pueda estar fijada entre tres y cinco meses. 8. Modelos basados en transformaciones Se basan en la posibilidad de convertir automáticamente una especificación formal de un producto software en un programa que satisfaga las especificaciones, utilizando herramientas de 4G (cuarta generación). De todos los modelos basados en transformaciones tal vez los más conocidos son: - El modelo basado en TÉCNICAS de 4G: propuesto por Pressman. Comienza con la fase de definición de requisitos. A continuación, se definen junto con el cliente una estrategia de diseño software. Determinados los requisitos y la estrategia de diseño, la utilización de un lenguaje de cuarta generación no procedimental (L4G) permitirá que la representación de los resultados deseados se traduzca automáticamente en el código fuente que produce esos resultados y conducirá a la implementación del sistema. - El modelo de TRANSFORMACIÓN: propuesto por McClure. Se basa en la utilización de herramientas CASE. El ciclo de vida del software puede ser considerado como una serie sucesiva de transformaciones, las cuales, gracias a la utilización de herramientas CASE, se producirán, en su mayor parte, de forma automática. Fases: especificación, diseño lógico, diseño físico y codificación. PABLO ARELLANO www.theglobeformacion.com Página 27 B3T1 MODELOS DE CICLO DE VIDA GSI 9. Modelo orientado a objetos Modelo de AGRUPAMIENTO Propuesto por Bertrand Meyer. El concepto clave es el agrupamiento (cluster): un grupo de clases relacionadas o, recursivamente, clusters relacionados. Cada cluster tiene su propio subciclo de vida estando formado por las siguientes fases: especificación, diseño, implementación, verificación/validación y generalización. Las características de este modelo son: la eliminación de las fronteras entre fases, el desarrollo iterativo e incremental y la combinación con modelos tradicionales. El sistema se divide en un conjunto de particiones que se van desarrollando e integrando de forma incremental. Modelo FUENTE Definido por Henderson-Sellers y Edwards. Representa gráficamente el alto grado de iteración y solapamiento que hace posible la tecnología de objetos. Propone dos modelos de ciclo de vida, uno para el sistema completo y otro para cada clase o módulo. El modelo permite la integración del análisis de dominio: identificación, análisis y especificación de requisitos comunes de un dominio de aplicación específico. Otros modelos que se encuadran dentro de los orientados a objetos son: el modelo REMOLINO y el modelo PINBALL. PABLO ARELLANO www.theglobeformacion.com Página 28 B3T1 MODELOS DE CICLO DE VIDA GSI 5. DESARROLLO ITERATIVO E INCREMENTAL El desarrollo iterativo e incremental es un proceso de desarrollo de software cíclico desarrollado en respuesta a la debilidad del modelo en cascada. Empieza con una planificación inicial y termina con el despliegue, con la iteración cíclica en el medio. Para apoyar al desarrollo de proyectos por medio de este modelo se han creado distintos frameworks, entornos de trabajo, como puede ser el Rational Unified Process/PUDS. El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworks de desarrollo rápido de software. El desarrollo iterativo e incremental es una pieza central de RUP, de DSDM, XP y generalmente de las metodologías de desarrollo de software ágil. Los dos términos se pusieron en práctica a mediados de los 90. Los autores del Proceso Unificado (UP) y el proceso unificado Rational (RUP) seleccionaron el término desarrollo iterativo e iteraciones para hacer referencia de forma general a cualquier combinación de desarrollo incremental e iterativo. La mayoría de las personas que dicen desarrollo iterativo quieren decir que hacen ambos desarrollo incremental e iterativo. La idea básica detrás de la mejora iterativa es desarrollar un sistema software incrementalmente, permitiendo al desarrollador aprovechar lo que va a ir aprendiendo durante el desarrollo de versiones anteriores, incrementales y entregables del sistema. El aprendizaje viene tanto del desarrollo como del uso del sistema, donde sea posible. Pasos clave en el proceso son empezar con una implementación simple de un subconjunto de requisitos del software y mejorar iterativamente la secuencia evolutiva de versiones hasta que se implementa el sistema entero. En cada iteración, se hacen modificaciones del diseño y se añaden nuevas capacidades. El procedimiento en sí consiste en el paso de Inicialización, el paso de Iteración y la lista de control del proyecto. El paso de inicialización crea una versión base del sistema. El objetivo de esta implementación inicial es crear un producto ante el que los usuarios puedan reaccionar. Debería ofrecer un muestreo de los aspectos clave del problema y proponer una solución que sea lo suficientemente simple de entender e implementar fácilmente. Para guiar el proceso de iteración, se crea una lista de control de proyecto que contiene un registro de todas las tareas que necesitan ser realizadas. Incluye elementos como pueden PABLO ARELLANO www.theglobeformacion.com Página 29 B3T1 MODELOS DE CICLO DE VIDA GSI ser nuevas características a ser implementadas y áreas de rediseño de la solución existente. La lista de control se revisa constantemente como resultado de la fase de análisis. La iteración implica el rediseño y la implementación de una tarea de la lista de control del proyecto, y el análisis de la versión actual del sistema. El objetivo del diseño e implementación de cualquier iteración es simple, sencillo y modular, soportando el rediseño en esta etapa o tarea añadida a la lista del control del proyecto. El nivel de detalle del diseño no está establecido por el enfoque iterativo. En un proyecto iterativo de poco peso el código puede representar la mayor fuente de documentación del sistema; sin embargo, en un proyecto iterativo de misión crítica se debe usar un documento de diseño de software formal. El análisis de una iteración se basa en la retroalimentación del usuario y las facilidades de análisis del programa disponibles. Esto implica análisis de la estructura, modularidad, usabilidad, fiabilidad, eficiencia y éxito de los objetivos. La lista de control del proyecto se modifica en vista de los resultados del análisis. El desarrollo iterativo divide el valor de negocio entregable (funcionalidad del sistema) en iteraciones. En cada iteración se entrega una parte de la funcionalidad a través de un trabajo multidisciplinar, empezando por el modelo/requisitos hasta las pruebas/despliegue. El proceso unificado agrupa las iteraciones en fases: inicio, elaboración, construcción y transición. - El inicio identifica el alcance del proyecto, los riesgos y los requisitos (funcionales y no funcionales) a un alto nivel en suficiente detalle para que se pueda estimar el trabajo. - La elaboración entrega una arquitectura de trabajo que mitiga los riesgos altos y cumple los requisitos no funcionales. - La construcción reemplaza incrementalmente la arquitectura con código listo para producción del análisis, diseño, implementación y pruebas de los requisitos funcionales. - La transición entrega el sistema al entorno operativo de producción. 1. Rapid Application Development (RAD) La modelo de desarrollo rápido de aplicaciones (RAD), creada por James Martin, se desarrolló para responder a la necesidad de entregar sistemas muy rápido. El enfoque de RAD no es apropiado para todos los proyectos. El alcance, el tamaño y las circunstancias, todo ello determina el éxito de un enfoque RAD. El método RAD tiene una lista de tareas y una estructura de desglose de trabajo diseñada para la rapidez. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y rapidez de ejecución. RAD requiere el uso interactivo de técnicas estructuradas y prototipos para definir los requisitos de usuario y diseñar el sistema final. Usando técnicas estructuradas, el desarrollador primero construye modelos de datos y modelos PABLO ARELLANO www.theglobeformacion.com Página 30 B3T1 MODELOS DE CICLO DE VIDA GSI de procesos de negocio preliminares de los requisitos. Los prototipos ayudan entonces al analista y los usuarios a verificar tales requisitos y a refinar formalmente los modelos de datos y procesos. El ciclo de modelos resulta a la larga en una combinación de requisitos de negocio y una declaración de diseño técnico para ser usado en la construcción de nuevos sistemas. 2. Proceso Unificado de Desarrollo Software (PUDS) En realidad es una metodología que propone un modelo de ciclo de vida. Está desarrollada por tres padres de la IS moderna: Yourdon, Booch y Rumbaugh. Plantea un modelo de ciclo de vida iterativo e incremental, centrado en una arquitectura que guía el desarrollo del sistema, cuyas actividades están dirigidas por casos de uso y soporta las técnicas orientadas a objetos. PUDS impulsa un control de calidad y una gestión de riesgos objetivos y continuos. El proceso fue diseñado con las mismas técnicas con las que el equipo solía diseñar software; tenía un modelo orientado a objetos subyacente, usando UML (Unified Modeling Language). También se conoce como RUP (Rational Unified Process). Las características de PUDS son: - Proceso iterativo e incremental. - Dirigido por los casos de uso: los casos de uso se utilizan para capturar los requisitos funcionales y para definir los objetivos de las iteraciones. En cada una, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseño usando la arquitectura como guía, implementan el diseño en componentes y verifican que los componentes satisfacen los casos de uso. - Centrado en la arquitectura. Desde el principio se establece una arquitectura software robusta que guía el desarrollo del sistema. - Es flexible para adaptarse a cambios de requisitos. - Enfocado en los riesgos: para disminuir la posibilidad de fallo en las iteraciones o incluso la de cancelación del proyecto, se deben llevar a cabo sucesivos análisis de riesgos durante todo el desarrollo. Por supuesto, los riesgos principales deben ser identificados en una etapa temprana del ciclo de vida. Fases, iteraciones y ciclos PUDS se compone de fases, iteraciones y ciclos. Una fase es el intervalo de tiempo entre dos hitos importantes del proceso durante la cual se cumple un conjunto bien definido de objetivos, se completan entregables y se toman las decisiones sobre si pasar o no a la siguiente fase. PABLO ARELLANO www.theglobeformacion.com Página 31 B3T1 MODELOS DE CICLO DE VIDA GSI Estas fases permiten que el proceso sea presentado a alto nivel de una forma similar a como sería presentado un proyecto basado en un estilo en cascada, aunque en esencia la clave del proceso recae en las iteraciones de desarrollo dentro de todas las fases. También, cada fase tiene un objetivo clave y un hito al final que denota que el objetivo se ha logrado. Las cuatro fases en las que divide el ciclo de vida del proyecto son: - INICIACIÓN: se define el alcance del proyecto. Termina con el hito objetivos del desarrollo. - ELABORACIÓN: se analizan las necesidades del negocio en mayor detalle y se define sus principios arquitectónicos. Termina con el hito arquitectura del sistema. - CONSTRUCCIÓN: se crea el diseño de la aplicación y el código fuente. Termina con el hito obtención de una funcionalidad completa. - TRANSICIÓN: se entrega el sistema a los usuarios y se llevan a cabo la formación a usuarios finales y las pruebas de aceptación del sistema. Termina con el hito publicación del producto. Cada fase e iteración se centra en disminuir algún riesgo y concluye con un hito bien definido. Cada una de las fases es, a su vez, dividida en una serie de iteraciones que ofrecen como resultado un incremento del producto desarrollado, que añade o mejora las funcionalidades del sistema en desarrollo. Es decir, un “incremento” no implica necesariamente una ampliación de dicho sistema. Cuando a la ejecución de los incrementos se les asigna un periodo de tiempo fijo, se está aplicando la práctica denominada “timeboxing”. El paso a través de las 4 fases constituye un ciclo de desarrollo y produce una generación de software. El primer ciclo es el inicial y después serán ciclos de evolución del sistema. Durante cada una de estas iteraciones se realizarán a su vez las actividades definidas en el ciclo de vida clásico (flujos de trabajo): requisitos, análisis, diseño, implementación, prueba PABLO ARELLANO www.theglobeformacion.com Página 32 B3T1 MODELOS DE CICLO DE VIDA GSI e implantación. Aunque todas las iteraciones suelen incluir trabajo en casi todas estas actividades, el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. Por ejemplo, en la fase de inicio se centrarán más en la definición de requisitos y en el análisis, y durante la de construcción quedarán relegadas en favor de la implementación y las pruebas. Dentro de cada iteración, las tareas se categorizan en nueve disciplinas: - Seis disciplinas de ingeniería: modelaje de negocio, requisitos, análisis y diseño, implementación, pruebas, despliegue. - Tres disciplinas de soporte: gestión de la configuración y del cambio, gestión de proyectos y entorno. PABLO ARELLANO www.theglobeformacion.com Página 33 B3T1 MODELOS DE CICLO DE VIDA GSI 6. ISO/IEC 12207 Esta norma establece un marco de referencia común para los procesos del ciclo de vida del software, con una terminología bien definida a la que puede hacer referencia la industria del software. Contiene procesos, actividades y tareas para aplicar durante la adquisición de un sistema que contiene software, un producto software puro o un servicio software, y durante el suministro, desarrollo, operación y mantenimiento de productos software. La ISO/IEC 12207 define un modelo de ciclo de vida como un marco de referencia que contiene los procesos, actividades y tareas involucradas en el desarrollo, operación y mantenimiento de un producto software, y que abarca toda la vida del sistema, desde la definición de sus requisitos hasta el final del uso. Esta norma agrupa las actividades que pueden llevarse a cabo durante el ciclo de vida del software en cinco procesos principales, ocho procesos de apoyo y cuatro procesos organizativos. Cada proceso del ciclo de vida está dividido en un conjunto de actividades; cada actividad se subdivide a su vez en un conjunto de tareas. - Procesos PRINCIPALES: son cinco procesos que dan servicio a las partes principales durante el ciclo de vida del software. Una parte principal es la que inicia o lleva a cabo el desarrollo, operación y mantenimiento de productos software. Los procesos principales son: o Proceso de adquisición. o Proceso de suministro. o Proceso de desarrollo. o Proceso de operación. o Proceso de mantenimiento. - Procesos de APOYO: son procesos que apoyan a otros procesos como parte esencial de los mismos, con un propósito bien definido, y contribuyen al éxito y calidad del proyecto software. Un proceso de apoyo se emplea y ejecuta por otro proceso según sus necesidades. Los procesos de apoyo son: o Proceso de documentación. o Proceso de gestión de la configuración. o Proceso de verificación. o Proceso de validación. o Proceso de revisiones conjuntas. o Proceso de auditoría. o Proceso de solución de problemas. PABLO ARELLANO www.theglobeformacion.com Página 34 B3T1 MODELOS DE CICLO DE VIDA GSI - Procesos ORGANIZATIVOS: se emplean por una organización para establecer e implementar una infraestructura construida por procesos y personal asociado al ciclo de vida, y para mejorar continuamente esta estructura y procesos. o Proceso de gestión. o Proceso de infraestructura. o Proceso de mejora. o Proceso de formación. PABLO ARELLANO www.theglobeformacion.com Página 35