¿El modelo en cascada (ingeniería de software) es adecuado para proyectos cuyos requisitos cambian constantemente o no se especifican correctamente y por qué?

Primero, quiero señalar que existe una idea errónea muy común de que existe una elección binaria y mutuamente excluyente entre “Ágil” y “Cascada” y ese no es el caso. Incluso las palabras “Ágil” y “Cascada” se usan muy libremente como si hubiera una metodología individual individual llamada “Ágil” y otra metodología discreta llamada “Cascada”.

Una mejor manera de pensar en esto es que hay un espectro de metodologías que van desde un plan fuertemente impulsado en un extremo hasta un gran nivel de adaptación en el otro extremo y el enfoque correcto es ajustar la metodología a la naturaleza del problema en lugar de un ajuste forzado un proyecto a alguna metodología predefinida.

El nivel de incertidumbre en los requisitos es un factor importante en la elección de la metodología adecuada para el problema; y, en general, un alto nivel de incertidumbre se adapta mejor a una metodología más adaptativa. Intentar forzar un proyecto con un alto nivel de incertidumbre a un modelo fuertemente planificado no sería una solución muy óptima.

EDITAR: La pregunta también preguntaba “¿Por qué?”, ​​La respuesta a eso debería ser evidente: si intenta forzar un proyecto a un enfoque fuertemente planificado (lo que mucha gente llama libremente “Cascada”), se verá obligado hacer muchas suposiciones para tratar de resolver algunas de las incertidumbres en el proyecto y muchas veces esas suposiciones serán incorrectas y pueden requerir una gran cantidad de reprogramaciones y modificaciones innecesarias. Otra razón es que si ajusta un proyecto con mucha incertidumbre a un enfoque fuertemente planificado, es más difícil adaptarse a los cambios una vez que el proyecto está en progreso y es menos probable que produzca una solución óptima.

Usted pregunta: ¿El modelo en cascada (ingeniería de software) es adecuado para proyectos cuyos requisitos cambian constantemente o no se especifican correctamente y por qué?

En general, no se considera adecuado, y la razón es bastante obvia: en el modelo en cascada, las decisiones más críticas se toman bastante temprano en el proceso para optimizar el resto del proceso, confiando en el hecho de que los requisitos son correctos y no cambiarán. Cualquier cambio en esas decisiones tempranas termina teniendo grandes impactos en todo el proceso, con costos y retrasos crecientes.

Para hacer una analogía, es la forma en que se diseñan y luego se construyen los rascacielos, y es bastante obvio que cualquier cambio radical de los planos originales termina con el costo final del edificio final mucho más de lo que inicialmente se esperaba y / o se completó mucho más tarde.

O tome por ejemplo aviones comerciales supersónicos operados comercialmente (por ejemplo, Concorde): entre los supuestos iniciales había combustible barato y la capacidad de volar a velocidad supersónica en la mayoría de las rutas. Pero entonces el combustible no se mantuvo barato (la crisis del petróleo de los años setenta), y muchos países también tuvieron que limitar el vuelo a velocidad supersónica en su territorio debido al auge supersónico, por lo que los aviones supersónicos se volvieron viables solo a altos costos y solo cuando sobrevolaban los océanos.

No, el modelo en cascada es un modelo secuencial interno diseñado para seguir un camino. Existe el modelo de cascada modificado por un nombre japonés de sashi que probablemente se deletrea mal. Este modelo permite el cambio. También tenga en cuenta que el modelo de cascada está diseñado para entregables. Entonces, a medida que avanza en el modelo, un cambio aumentará en el costo.

Cuando realice un cambio, debe ser ágil o la falta de aclaración de requisitos debe solicitar la información y si está utilizando ágil, actualice en la próxima iteración.

El modelo de cascada solo es adecuado cuando está facturando por hora y no le importa si el proyecto falla.