SOFTWARE

ste, aunque es más comúnmente conocido como modelo en cascada es también llamado «modelo clásico», «modelo tradicional» o «modelo lineal secuencial».
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 seraplicable a escasos y pequeños sistemas a desarrollar. 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 sin errores, no habrá en absoluto variantes futuras». Esto es utópico; ya que intrínsecamente el software es decarácter evolutivo,9 cambiante y difícilmente libre de errores, tanto durante su desarrollo como durante su vida operativa.6


Fig. 2 - Modelo cascada puro o secuencial para el ciclo de vida del software.
Algún cambio durante la ejecución de una cualquiera de las etapas en este modelo secuencial implicaría reiniciar desde el principio todo el ciclo completo, lo cual redundaría en altos costosde tiempo y desarrollo. La Figura 2 muestra un posible esquema de el modelo en cuestión.6
Sin embargo, el modelo cascada en algunas de sus variantes es uno de los actualmente más utilizados,10 por su eficacia y simplicidad, más que nada en software de pequeño y algunos de mediano porte; pero nunca (o muy rara vez) se lo usa en su "forma pura", como se dijo anteriormente. En lugar de ello,siempre se produce alguna realimentación entre etapas, que no es completamente predecible ni rígida; esto da oportunidad al desarrollo de productos software en los cuales hay ciertas incertezas, cambios o evoluciones durante el ciclo de vida. Así por ejemplo, una vez capturados y especificados los requisitos (primera etapa) se puede pasar al diseño del sistema, pero durante esta última fase lo másprobable es que se deban realizar ajustes en los requisitos (aunque sean mínimos), ya sea por fallas detectadas, ambigüedades o bien por que los propios requisitos han cambiado o evolucionado; con lo cual se debe retornar a la primera o previa etapa, hacer los reajuste pertinentes y luego continuar nuevamente con el diseño; esto último se conoce como realimentación. Lo normal en el modelo cascada seráentonces la aplicación del mismo con sus etapas realimentadas de alguna forma, permitiendo retroceder de una a la anterior (e incluso poder saltar a varias anteriores) si es requerido.
De esta manera se obtiene el «modelo cascada realimentado», que puede ser esquematizado como lo ilustra la Figura 3.


Fig. 3 - Modelo cascada realimentado para el ciclo de vida.
Lo dicho es, a grandes rasgos,la forma y utilización de este modelo, uno de los más usados y populares.6 El modelo cascada realimentado resulta muy atractivo, hasta ideal, si el proyecto presenta alta rigidez (pocos cambios, previsto no evolutivo), los requisitos son muy claros y están correctamente especificados.10
Hay más variantes similares al modelo: refino de etapas (más etapas, menores y más específicas) o inclusomostrar menos etapas de las indicadas, aunque en tal caso la faltante estará dentro de alguna otra. El orden de esas fases indicadas en el ítem previo es el lógico y adecuado, pero adviértase, como se dijo, que normalmente habrá realimentación hacia atrás.
El modelo lineal o en cascada es el paradigma más antiguo y extensamente utilizado, sin embargo las críticas a él (ver desventajas) han puesto enduda su eficacia. Pese a todo, tiene un lugar muy importante en la Ingeniería de software y continúa siendo el más utilizado; y siempre es mejor que un enfoque al azar.10
Desventajas del modelo cascada:6
Los cambios introducidos durante el desarrollo pueden confundir al equipo profesional en las etapas tempranas del proyecto. Si los cambios se producen en etapa madura (codificación o prueba)...