Modelo ciclo de vida

Al igual que en otros sistemas de ingeniería, los sistemas de software requieren un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado, se identifican varias etapas que en conjunto se denominan el ciclo de vida del software y en cada caso, en función de cuales sean las características del proyecto, se configurará el ciclo de vida de forma diferente. Usualmente se consideran las etapas: especificación y análisis de requisitos, diseño del sistema, implementación del software, aplicación y pruebas, entrega y mantenimiento
. Un aspecto esencial dentro de las tareas del desarrollo del software es la documentación de todos los elementos y especificaciones en cada fase. Dado que esta tarea siempre estará influida por la fase del desarrollo en curso, se explicará de forma distribuida a lo largo de las diferentes fases como un apartado especial para recalcar su importancia en el conjunto del desarrollo del software. Tal como ya hemos mencionado, las etapas principales a realizar en cualquier ciclo de vida son:

Análisis

Construye un modelo de los requisitos Diseño:
A partir del modelo de análisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario.

Codificación

Construye el sistema. La salida de esta fase es código ejecutable.

Pruebas

Se comprueba que se cumplen criterios de corrección y calidad.

Mantenimiento

En esta fase, que tiene lugar después de la entrega se asegura que el sistema siga funcionando y adaptándose a nuevos requisitos. Las etapas constan de tareas. La documentación es una tarea importante que se realiza en todas las etapas. Cada etapa tiene como entrada uno o varios documentos procedentes de las etapas anteriores y produce otros documentos de salida Las formas de organizar y estructurar la secuencia de ejecución de las etapas en las diferentes fases de cada uno de los métodos puede dar lugar a un tipo de ciclo de vida diferente. Los principales ciclos de vida que se van a presentar a continuación realizan estas tareas. Cada uno de ellos tiene sus ventajas e inconvenientes.

Ciclos de vida en cascada o clásico

El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras ramas de la ingeniería. Es el primero de los propuestos y el más ampliamente seguido por las organizaciones (se estima que el 90% de los sistemas han sido desarrollados así). Existen dos versiones, el modelo en cascada puro y el modelo en cascada con realimentación.El modelo en cascada puro difícilmente se utiliza tal cual, pues esto implicaría un previo y absoluto conocimiento de los requisitos, la no volatilidad de los mismos (o rigidez) y etapas subsiguientes libres de errores; ello sólo podría ser aplicable a escasos y pequeños desarrollos de sistemas. En estas circunstancias, el paso de una etapa a otra de las mencionadas sería sin retorno, por ejemplo pasar del Diseño a la Codificación implicaría un diseño exacto y sin errores ni probable modificación o evolución: «codifique lo diseñado que no habrán en absoluto variantes ni errores». Esto es utópico; ya que intrínsecamente el software es de carácter evolutivo, cambiante y difícilmente libre de errores, tanto durante su desarrollo como durante su vida operativa.

Descripción del modelo en cascada realimentado

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas. Cada etapa empieza cuando se ha terminado la fase anterior.Para pasar de una fase a la siguiente es necesario conseguir todos los objetivos de la fase previa. Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente. Trabaja en base a documentos, es decir, la entrada de cada fase es un tipo de documento específico y la salida de cada fase va a ser otro tipo de documento específico. Idealmente, cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases. Ventajas La planificación es sencilla.Para proyectos donde debe establecerse claramente una fecha de entrega determinada ya que permite una estimación temporal definida para cada una de las fases  La calidad del producto resultante es alta. Permite trabajar con personal poco cualificado (respecto a la visión global de proyecto). Inconvenientes Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que el cliente no sea capaz de transmitir perfectamente las especificaciones del sistema, o puede ser que surjan necesidades imprevistas. Si se han cometido errores en una fase es difícil volver atrás. Errores detectados tardíamente.Se tarda “mucho tiempo” en conseguir una pasada por todo el ciclo de desarrolloNo se tiene el producto hasta el final, esto quiere decir que: Si se comete un error en la fase de análisis no lo descubrimos hasta la entrega, con el consiguiente gasto inútil de recursos. El cliente no verá resultados hasta el final, con lo que puede impacientarse. -No se tienen indicadores fiables del progreso del trabajo (síndrome del 90%).-Es comparativamente más lento que los demás y el coste es mayor también. -Los proyectos raramente siguen el flujo secuencialTipos de proyectos para los que es adecuado Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniería. Se está desarrollando un tipo de producto que no es novedoso. Proyectos que se entienden bien desde el principio.

Modelo de ciclo de vida incremental

Descripción           

Cuando se utiliza un modelo incremental, el primer incremento a menudo es un producto esencial. Esdecir, se afrontan requisitos básicos pero muchas funciones suplementarias (algunas conocidas, otras no) quedan sin extraer. El cliente utiliza el producto central (o sufre la revisión detallada) para evaluar si se cumplen sus necesidades. Como un resultado de utilización y/o de evaluación, se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto central a fin de cumplir mejor las necesidades del cliente y la entrega de funciones, y características adicionales. Este proceso se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto completo.

El modelo de proceso incremental, como la construcción de prototipos yotros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción de prototipos, el modelo incremental se centra en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones «incompletas» del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación. El desarrollo incremental es particularmente útil cuando la dotación de personal no está disponible para una implementación completa en la fecha límite que se haya establecido para el proyecto.

Ventajas     

Corrige la necesidad de una secuencia no lineal

Inconvenientes     

Aunque este modelo permite el cambio continuo de requisitos, los errores se detectan tarde y su corrección es tan costosa como en el modelo en cascada.

Se exige la participación activa del cliente

Modelo de ciclo de vida con prototipo

Consiste en iterar en la fase de análisis tantas veces como sea necesario, mostrando prototipos al usuario para que pueda indicarnos de forma mas eficiente los requisitos del sistema. La iteración finalizará cuando el usuario de el visto bueno al prototipo.

 Ventajas    

El prototipo ayuda a los analistas a definir los requerimientos de los clientes

El prototipo ayuda a los desarrolladores a mejorar los productos

 Inconvenientes    

Cliente y analista se deben de poner de acuerdo en que el prototipo se construya únicamente con la finalidad de captar requerimientos.El cliente está viendo lo que parece ser una versión del software, lo que puede ocasionar que quiere el producto antes de tiempo.En el prototipo no se tiene en cuenta para nada la calidad del software global  Con la finalidad de tener el prototipo “lo antes posible”, el programador puede tomar decisiones de implementación poco convenientes (por ejemplo, decantarse por un lenguaje de programación incorrecto solo por el hecho de que proporciona un desarrollo más rápido)

Modelo de ciclo de vida en espiral

Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos o iteraciones que se repiten. Cada uno de estos ciclos o iteraciones tiene las mismas fases y cuando finaliza cada una de estas fases o iteraciones se genera un producto ampliado, es decir, con mayor funcionalidad con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseño, errores en la implementación, mantenimiento inadecuado, gestión inadecuada de recursos (personal), riesgo de mercado (que se adelante la competencia o que el producto no se venda bien), etc. En definitiva, un riesgo es todo aquello sobre lo que se debe actuar para conseguir la funcionalidad deseada.

Una representación típica de esta estructura en espiral se muestra en la figura:

En cada iteración, formada por cuatro pasos:

Planificación

Análisis del riesgo

Ingeniería

Evaluación del cliente

Boehm recomienda recopilar la siguiente lista de informaciones:

El primer paso (PLANIFICACIÓN), se debe de identificar:

Objetivos

La finalidad es obtener, por parte del cliente, la funcionalidad deseada, además de otros aspectos importantes como las restricciones asociadas, una mayor o menor necesidad de adaptación a cambios. Para ello, se suelen hacer entrevistas a los clientes, se les hace rellenar cuestionarios, etc.

Alternativas

Son las diferentes formas posibles de conseguir los objetivos. La finalidad es evaluar las alternativas a la hora de la implementación. Se consideran desde dos puntos de vista

• • Características del producto.
  • Formas de gestionar el proyecto.

Restricciones

Son las restricciones impuestas en función de las distintas alternativas que se están analizando:

• • Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc.
  • Desde el punto de vista organizativo: Coste, tiempo, personal, etc.

El segundo paso (ANÁLISIS DEL RIESGO), se debe de identificar:

Plantear los Riesgos

Lista de riesgos identificados. Ya se ha comentado anteriormente, que un riesgo puede ser desde un requisito/funcionalidad mal entendida por el analista, un error de implementación durante la fase de desarrollo, etc.

El tercer paso (INGENIERIA), se debe de identificar:

Resolver los riesgos

Si han aparecido riesgos en la etapa anterior, se debe de formular una estrategia efectiva en coste para resolver dichos riesgos. La técnica más usada es la construcción de prototipos., aunque también se utiliza la simulación o los bancos de pruebas, etc.

Resultados

Son los que realmente se han obtenido después de la resolución de riesgos.

El cuarto paso (EVALUACIÓN DEL CLIENTE), se debe de identificar junto con el cliente, si el prototipo que se ha generado cumple con la funcionalidad que se esperaba.

Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, también se verifica que funciona correctamente. El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo.

 Ventajas

No necesita una definición completa de los requisitos para empezar a funcionar.

Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.

El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteración (las anteriores iteraciones están bien).

El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.

Inconvenientes

Es difícil evaluar los riesgos, requiere de personal alterante experimentado.

Necesita de la participación continua por parte del cliente.

Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.

Dónde es adecuado

Sistemas de gran tamaño.

Proyectos donde sea importante el factor riesgo.

Cuando no sea posible definir al principio todos los requisitos.

Ciclos de vida orientados a objetos

Los tipos de ciclos de vida que se han visto hasta ahora son relativos al análisis y diseño estructurados, pero los objetos tienen una particularidad, y es que están basados en componentes que se relacionan entre ellos a través de interfaces, o lo que es lo mismo, son mas modulares y por lo tanto el trabajo se puede dividir en un conjunto de miniproyectos. Además, hoy en día la tendencia es a reducir los riesgos, y en este sentido, el ciclo de vida en cascada no proporciona muchas facilidades. Debido a todo esto, el ciclo de vida típico en una metodología de diseño orientado a objetos es iterativo e incremental.

En este texto sólo veremos un tipo de ciclo de vida orientado a objetos, que es además el más representativo, el modelo fuente.

Modelo fuente

Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientación a objetos y posiblemente el más seguido. Un proyecto se divide en las fases:

Planificación del negocio

Construcción: Es la más importante y se divide a su vez en otras cinco actividades

• Planificación
• Investigación
• Especificación
• Implementación
• Revisión

La primera y la tercera fase son independientes de la metodología de desarrollo orientado a objetos.

Además de las tres fases, existen dos periodos a tener en cuenta durante el desarrollo de SW basándose: -Crecimiento: Es el tiempo durante el cual se construye el sistema Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual que el periodo anterior, es decir, con las fases de Planificación del negocio, Construcción y Entrega.

Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una puede estar en una fase diferente en un momento cualquiera.
La ventaja es que permite un desarrollo solapado e iterativo. En la figura 1.7 se muestra un esquema de este tipo de ciclo de vida.