INTRODUCCIN

Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se mueve un proyecto de desarrollo de software. El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70. Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya desde 10 a 15 aos atrs, el modelo cascada ha sido sujeto a numerosas crticas, debido a que es restrictivo y rgido, lo cual dificulta el desarrollo de proyectos de software moderno. En su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos que pretenden desarrollar software ms rpidamente, o ms incrementalmente o de una forma ms evolutiva, o precediendo el desarrollo a escala total con algn conjunto de prototipos rpidos.

CICLOS DE VIDA DE UN SOFTWARE

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 transicin asociadas 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, y Provee un espacio de trabajo para la definicin de un detallado proceso de desarrollo de software. As, los modelos por una parte suministran una gua para los ingenieros de software con el fin de ordenar las diversas actividades tcnicas en el proyecto, por otra parte suministran un marco para la administracin del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc. Las etapas principales a realizar en cualquier ciclo de vida son: 1. Anlisis: Construye un modelo de los requisitos 2. Diseo: A partir del modelo de anlisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario. 3. Codificacin: Construye el sistema. La salida de esta fase es cdigo ejecutable. 4. Pruebas: Se comprueba que se cumplen criterios de correccin y calidad. 5. Mantenimiento: En esta fase, que tiene lugar despus de la entrega se asegura que el sistema siga funcionando y adaptndose a nuevos requisitos. Las etapas constan de tareas. La documentacin 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 segn se muestra en la figura 1.

Algunos autores dividen la fase del diseo en dos partes: Diseo global o arquitectnico y diseo detallado. En el primero se transforman los requisitos en una arquitectura de alto nivel, se definen las pruebas que debe satisfacer el sistema en su conjunto, se esboza la documentacin y se planifica la integracin. En el detallado para cada mdulo se refina el diseo, se definen los requisitos del mdulo y su documentacin. Las formas de organizar y estructurar la secuencia de ejecucin de las tareas en las diferentes fases de cada uno de los mtodos pueden dar lugar a un tipo de ciclo de vida diferente. Los principales ciclos de vida que se van a presentar a continuacin realizan estas tareas. Cada uno de ellos tiene sus ventajas e inconvenientes.

MODELOS DE CICLOS DE VIDA DE UN SOFTWARE

Existen varios modelos de ciclos de vida para el desarrollo de un software, los principales se detallan a continuacin. 1. CICLO DE VIDA EN CASCADA 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 ingeniera. Es el primero de los propuestos y el ms ampliamente seguido por las organizaciones (se estima que el 90% de los sistemas han sido desarrollados as). La estructura se muestra en la figura 2.

1. Denominacin

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 diseo, lo cual significa que se harn los cambios necesarios en la codificacin y se tendrn 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. Despus de cada etapa se realiza una revisin para comprobar si se puede pasar a la siguiente.

Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento especfico. Idealmente, cada fase podra hacerla un equipo diferente gracias a la documentacin generada entre las fases. Los documentos son:

Anlisis: Toma como entrada una descripcin en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software Requirements Document). Diseo: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document) Codificacin: A partir del S.D.D. produce mdulos. En esta fase se hacen tambin pruebas de unidad. Pruebas: A partir de los mdulos probados se realiza la integracin y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar.

2. Ventajas.
La planificacin es sencilla. La calidad del producto resultante es alta. Permite trabajar con personal poco cualificado.

3. Desventajas.
Lo peor es la necesidad de tener todos los requisitos al principio.

Lo normal es que el cliente no tenga perfectamente definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas.
Si se han cometido errores en una fase es difcil volver atrs.

 No se tiene el producto hasta el final, esto quiere decir que: Si se comete un error en la fase de anlisis no lo descubrimos

hasta la entrega, con el consiguiente gasto intil de recursos.

El cliente no ver resultados hasta el final, con lo que puede

impacientarse .
No se tienen indicadores fiables del progreso del trabajo (sndrome

del 90%).
Es comparativamente ms lento que los dems y el coste es

mayor tambin. 4. Variaciones del Modelo de ciclo de vida en Cascada.

Como el modelo en cascada ha sido muy popular ha generado algunas variantes. Ahora veremos algunas.

4.1.

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. Su estructura est representada en la figura 3.

4.2.

Ciclo de vida de 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 comunicacin pueden surgir inconsistencias.

problemas

de

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. En la figura 4 se ha representado la estructura del ciclo de vida sashimi.

4.3. 5. 1.