Ciclos 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 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í). La estructura se muestra en la figura 1.2.

Figure 1.2: Ciclo de vida en cascada||
includegraphics[]{c1_cv_1.eps}
includegraphics[]{c1_cv_1.eps}
||

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.
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 y la salida de cada fase es un tipo de documento específico. Idealmente, cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases. Los documentos son:

  • Análisis: Toma como entrada una descripción en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software Requirements Document).
  • Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)
  • Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen también pruebas de unidad.
  • Pruebas: A partir de los módulos probados se realiza la integración y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar.


  • La planificación es sencilla.
  • La calidad del producto resultante es alta.
  • Permite trabajar con personal poco cualificado.


  • 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 difícil volver atrás.
  • No 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%).1.1
  • Es comparativamente más lento que los demás y el coste es mayor también.


  • 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 complejos que se entienden bien desde el principio.
Como el modelo en cascada ha sido muy popular ha generado algunas variantes. Ahora veremos algunas.

1.2.1.5 Ciclo de vida en V

Propuesto por Alan Davis, tiene las mismas fases que el anterior pero se considera el nivel de abstracción de cada una. Una fase además de utilizarse como entrada para la siguiente, sirve para validar o verificar otras fases posteriores. Su estructura está representada en la figura 1.3.

Figure 1.3: Ciclo de vida en V||
includegraphics[]{c1_cv_2.eps}
includegraphics[]{c1_cv_2.eps}
||

1.2.1.6 Ciclo de vida tipo sashimi

Según 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 diseño se comienza a implementar. El nombre ``sashimi'' deriva del modo del estilo de presentación de rodajas de pescado crudo en Japón. Una ventaja de este modelo es que no necesita generar tanta documentación como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases. Los problemas planteados son:

  • Es aún más difícil 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 comunicación pueden surgir inconsistencias.
La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios, tipo de tecnología y el tipo de ciclo de vida. El diseño arquitectónico es el de alto nivel, el detallado el de bajo nivel. En la figura 1.4 se ha representado la estructura del ciclo de vida sashimi.

Figure 1.4: Ciclo de vida sashimi||
includegraphics[]{c1_cv_5.eps}
includegraphics[]{c1_cv_5.eps}
||

1.2.1.7 Ciclo de vida en cascada con subproyectos

Si una vez que se ha llegado al diseño arquitectónico, se comprueba que el sistema se divide en varios subsistemas independientes entre sí, sería razonable suponer que a partir de ese punto cada uno se puede desarrollar por separado y en consecuencia en paralelo con los demás. Cada uno tendrá seguramente fechas de terminación 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 más gente trabajando en paralelo de forma eficiente. El riesgo es que existan interdependencias entre los subproyectos.

1.2.1.8 Ciclo de vida en cascada incremental

En este caso se va creando el sistema añadiendo pequeñas funcionalidades. Cada uno de los pequeños incrementos es parecido a lo que ocurre dentro de la fase de mantenimiento. La ventaja de este método es que no es necesario tener todos los requisitos en un principio. El inconveniente es que los errores en la detección de requisitos se encuentran tarde.
Hay dos partes en el ciclo de vida, similares al anterior. Por un lado está el análisis y el diseño global. Por otra parte están los pequeños incrementos, con las fases de diseño detallado, codificación y mantenimiento. En la figura 1.5 se puede ver su estructura.

Figure 1.5: Cascada incremental||
includegraphics[]{c1_cv_4.eps}
includegraphics[]{c1_cv_4.eps}
||

1.2.1.9 Ciclo de vida en cascada con reducción de riesgos

Como se ha comentado anteriormente, uno de los problemas del ciclo de vida en cascada es que si se entienden mal los requisitos esto sólo se descubrirá cuando se entregue el producto. Para evitar este problema se puede hacer un desarrollo iterativo durante las fases de análisis y diseño global. Esto consistiría en:

  1. Preguntar al usuario.
  2. Hacer el diseño global que se desprende del punto 1.
  3. Hacer un prototipo de interfaz de usuario, entrevistas con los usuarios, etc y volver con ello al punto 1 para identificar más requisitos o corregir malentendidos.
El resto es igual al ciclo de vida en cascada.

1.2.2 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 diseño, errores en la implementación, etc. Un representación típica de esta estructura se muestra en la figura 1.6.

Figure 1.6: Ciclo de vida en espiral||
includegraphics[]{c1_cv_3.eps}
includegraphics[]{c1_cv_3.eps}
||

En cada iteración 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
    • Características 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.
  • Resolución de riesgos: La técnica más usada es la construcción de prototipos.
  • Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.
  • Planes: Lo que se va a hacer en la siguiente fase.
  • Compromiso: Decisiones de gestión sobre como continuar.
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.


  • 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.


  • Es difícil evaluar los riesgos.
  • 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.


  • Sistemas de gran tamaño.
  • Proyectos donde sea importante el factor riesgo.
  • Cuando no sea posible definir al principio todos los requisitos.

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:

  1. Planificación del negocio
  2. 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
  3. Entrega
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:
  1. Crecimiento: Es el tiempo durante el cual se construye el sistema
  2. 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.

Figure 1.7: Ciclo de vida fuente||
includegraphics[]{c1_cv_6.eps}
includegraphics[]{c1_cv_6.eps}
||