Modelo en cascada

Hay veces en las que los requerimientos para cierto problema se comprenden bien. Esta situación se encuentra en ocasiones cuando deben hacerse adaptaciones o mejoras bien definidas a un sistema ya existente (por ejemplo, una adaptación para software de facturación que es obligatorio hacer debido a cambios en las regulaciones gubernamentales). También ocurre en algunos nuevos esfuerzos de desarrollo, pero sólo cuando los requerimientos están bien definidos y tienen poca probabilidad de que cambien. Es aquí donde aplicar un modelo de proceso secuencial guiado por un plan sea la mejor opción para llevar a cabo la gestión de un proyecto de software.

El modelo en cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque sistemático y secuencial para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado. Debido al paso de una fase en cascada a otra, este modelo se conoce como “modelo en cascada”.

Es un ejemplo de un proceso dirigido por un plan; en principio, se debe planear y programar todas las actividades del proceso, antes de comenzar a trabajar con ellas.

Actividades del modelo

Las principales etapas del modelo en cascada reflejan directamente las actividades fundamentales del desarrollo:

1- Análisis y definición de requerimientos

Los servicios, las restricciones y las metas del sistema se establecen mediante consulta a los usuarios del sistema. Luego, se definen con detalle y sirven como una especificación del sistema.

2- Diseño del sistema y del software

El proceso de diseño de sistemas asigna los requerimientos, para sistemas de hardware o de software, al establecer una arquitectura de sistema global. El diseño del software implica identificar y describir las abstracciones fundamentales del sistema de software y sus relaciones.

3- Implementación y prueba de unidad

Durante esta etapa, el diseño de software se rea liza como un conjunto de programas o unidades del programa. La prueba de unidad consiste en verificar que cada unidad cumpla con su especificación.

4- Integración y prueba de sistema

Las unidades del programa o los programas individuales se integran y prueban como un sistema completo para asegurarse de que se cumplan los requerimientos de software. Después de probarlo, se libera el sistema de software al cliente.

5- Operación y mantenimiento

Por lo general (aunque no necesariamente), ésta es la fase más larga del ciclo de vida, donde el sistema se instala y se pone en práctica. El mantenimiento incluye corregir los errores que no se detectaron en etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema e incrementar los servicios del sistema conforme se descubren nuevos requerimientos.

Un poco de la turbulenta historía del modelo en cascada

El pobre Winston Royce pagó todos los platos rotos ....

Críticas al modelo

El modelo de la cascada es el paradigma más antiguo de la ingeniería de software . Sin embargo, en las últimas tres décadas, las críticas hechas al modelo han ocasionado que incluso sus defensores más obstinados cuestionen su eficacia.

Entre los problemas que en ocasiones surgen al aplicar el modelo de la cascada se encuentran los siguientes:

• Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Aunque el modelo lineal acepta repeticiones, lo hace en forma indirecta. Como resultado, los cambios generan confusión conforme el equipo del proyecto avanza.
• A menudo, es difícil para el cliente enunciar en forma explícita todos los requerimientos. El modelo de la cascada necesita que se haga y tiene dificultades para aceptar la incertidumbre natural que existe al principio de muchos proyectos.
• El cliente debe tener paciencia. No se dispondrá de una versión funcional del(de los) programa(s) hasta que el proyecto esté muy avanzado. Un error grande sería desastroso si se detectara hasta revisar el programa en funcionamiento.

En un análisis interesante de proyectos reales, se encontró que la naturaleza lineal del ciclo de vida clásico llega a “estados de bloqueo” en los que ciertos miembros del equipo de proyecto deben esperar a otros a fin de terminar tareas interdependientes. En realidad, ¡el tiempo de espera llega a superar al dedicado al trabajo productivo! .

Hoy en día, el trabajo de software es acelerado y está sujeto a una corriente sin fin de cambios (en las características, funciones y contenido de información). El modelo en cascada suele ser inapropiado para ese tipo de labor. No obstante, sirve como un modelo de proceso útil en situaciones en las que los requerimientos son fijos y el trabajo avanza en forma lineal hacia el final .