MODELOS DE CICLO DE VIDA

Las principales diferencias entre los distintos modelos de ciclo de vida estn divididas en tres grandes visiones: Alcance del ciclo de vida: Hasta donde queremos llegar con el proyecto La cualidad y la cantidad de las etapas: Es decir en que dividiremos el ciclo de vida, segn el que adptemos. Estructura y sucesin de las etapas: Es decir si hay realimentacin o tenemos la libertad de repetirlas. En los modelos de ciclo de vida existentes siempre hay riesgo, que esta catalogado como la probabilidad de retomar etapas anteriores, perdiendo tiempo, dinero y esfuerzo. Modelo Lineal Secuencial Tambin llamado "Ciclo de vida bsico" o "Modelo de cascada" tiene su origen en el "Modelo de cascada" ingeniado por Winston Royce, sugiere un enfoque sistemtico o ms bien secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin, pruebas y mantenimiento. El MLS tiene las siguientes actividades: * Anlisis de los requerimientos del software: es la fase en la cual se renen todos los requisitos que debe cumplir el software. En esta etapa es fundamental la presencia del cliente que documenta y repasa dichos requisitos. * Diseo: es una etapa dirigida hacia la estructura de datos, la arquitectura del software, las representaciones de la interfaz y el detalle procedimental (algoritmo). En forma general se hace un esbozo de lo solicitado y se documenta hacindose parte del software. * Generacin del cdigo: es la etapa en la cual se traduce el diseo para que sea comprensible por la mquina. Esta etapa va a depender estrechamente de lo detallado del diseo. * Pruebas: esta etapa se centra en los procesos lgicos internos del software, asegurando que todas las sentencias se han comprobado, y en la deteccin de errores. * Mantenimiento: debido a que el programa puede tener errores, puede no ser del completo agrado del cliente o puede necesitar, eventualmente acoplarse a los cambios en su entorno. Esto quiere decir que no se rehace el programa, sino que sobre la base de uno ya existente se realizan algunos cambios. El MLS es el paradigma de desarrollo de software ms antiguo que existe, sin embargo esto no ha impedido que se haya creado una desconfianza alrededor de l basada en los siguientes errores reales:

* Los proyectos raramente siguen el paradigma secuencial que propone el proyecto. * A menudo es difcil que el cliente exponga exactamente todos los requisitos. * El cliente debe tener paciencia. * Los responsables del desarrollo de software siempre se retrasan innecesariamente.

Modelo de ciclo de vida en V Propuesto por Alan Davis, tiene las mismas fases que el anterior pero se considera el nivel de abstraccin de cada una. Una fase adems de utilizarse como entrada para la siguiente, sirve para validar o verificar otras fases posteriores.

Modelo de ciclo de vida tipo Sashimi Segn el modelo en cascada puro una fase solo puede empezar cuando ha terminado la anterior. En este caso sin embargo, se permite un solapamiento entre fases. Por ejemplo, sin tener terminado del todo el diseo se comienza a implementar. El nombre ``sashimi'' deriva del modo del estilo de presentacin de rodajas de pescado crudo en Japn. Una ventaja de este modelo es que no necesita generar tanta documentacin como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases. Los problemas planteados son: Es an ms difcil controlar el progreso del proyecto debido a que los finales de fase ya no son un punto de referencia claro. Al hacer cosas en paralelo si hay problemas de comunicacin pueden surgir inconsistencias. La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios, tipo de tecnologa y el tipo de ciclo de vida. El diseo arquitectnico es el de alto nivel, el detallado el de bajo nivel.

Modelo de ciclo de vida en cascada con subproyectos Si una vez que se ha llegado al diseo arquitectnico, se comprueba que el sistema se divide en varios subsistemas independientes entre s, sera razonable suponer que a partir de ese punto cada uno se puede desarrollar por separado y en consecuencia en paralelo con los dems. Cada uno tendr seguramente fechas de terminacin distintas. Una vez que han terminado todos se integran y se prueba el sistema en su conjunto. La ventaja es que se puede tener a ms gente trabajando en paralelo de forma eficiente. El riesgo es que existan interdependencias entre los subproyectos. Modelo de ciclo de vida de Desarrollo iterativo Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada.

Modelo de ciclo de vida por Prototipos Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humanomquina. Las maquinas simples pueden ser palanca,plano inclinado entre otros El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intencin de crear un prototipo de forma rpida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su funcin. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertira en un prototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementacin poco convenientes (por ejemplo, elegir un lenguaje de programacin incorrecto porque proporcione un desarrollo ms

rpido). Con el paso del tiempo, el desarrollador puede olvidarse de la razn que le llev a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

Modelo de ciclo de vida en Espiral Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado 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 diseo, errores en la implementacin, etc. En cada iteracin Boehm recomienda recopilar la siguiente lista de informaciones: Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc. Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista Caractersticas del producto. Formas de gestionar el proyecto. Restricciones: 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. Riesgos: Lista de riesgos identificados. Resolucin de riesgos: La tcnica ms usada es la construccin de prototipos. Resultados: Son lo que realmente ha ocurrido despus de la resolucin de riesgos. Planes: Lo que se va a hacer en la siguiente fase. Compromiso: Decisiones de gestin sobre como continuar.

Al terminar una iteracin se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, tambin se verifica que funciona correctamente. El propio cliente evala 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.

Modelo de ciclo de vida Cascada Incremental

En este caso se va creando el sistema aadiendo pequeas funcionalidades. Cada uno de los pequeos incrementos es parecido a lo que ocurre dentro de la fase de mantenimiento. La ventaja de este mtodo es que no es necesario tener todos los requisitos en un principio. El inconveniente es que los errores en la deteccin de requisitos se encuentran tarde. Hay dos partes en el ciclo de vida, similares al anterior. Por un lado est el anlisis y el diseo global. Por otra parte estn los pequeos incrementos, con las fases de diseo detallado, codificacin y mantenimiento.