Sí, está muy vivo, aunque hoy en día es el más común " V model " que se utiliza
En cualquier caso, el problema que tiene Agile es que la solución casi nunca termina, el cliente puede continuar solicitando cambios y el desarrollo continuará resolviéndolos de manera iterativa. Para un proyecto que se basa en costos de tiempo y materiales, esto funciona muy bien. Para un proyecto que tiene un costo fijo, no lo tiene.
Para estos proyectos de costo fijo, el cliente casi siempre espera que los hitos predefinidos demuestren progreso, sin embargo, estos son más de la variedad escrita formal en lugar del código de trabajo. Para clientes como este, las especificaciones escritas se convierten en el proyecto, uno donde el desarrollo del software es una consideración secundaria (como se supone, si tiene un proyecto bien definido, el software debería ser fácil de desarrollar). Estas empresas también son las que hacen un uso intensivo de recursos de desarrollo baratos y subcontratados.
Entonces, si tiene una cantidad fija de dinero o tiempo, no espere que los requisitos cambien o no se les permita cambiar ningún requisito, y se espera que proporcionen un conjunto sólido de documentación escrita, entonces los modelos de cascada son la Sólo los que tienen sentido.
Agile puede introducirse en medio de estos proyectos para realizar el desarrollo, pero aún tiene una fase de aceleración en la que se crean las especificaciones a partir de los requisitos, y una fase de rampa en la que el software se instala y prueba in situ. Agile no responde bien a estos casos.