Oui, il est très vivant, mais aujourd'hui c'est le " modèle V " le plus courant qui est utilisé.
Dans les deux cas, le problème d'Agile est que la solution ne se termine presque jamais, le client peut continuer à demander des modifications et le développement continuera à les résoudre de manière itérative. Pour un projet basé sur le coût du temps et des matériaux, cela fonctionne très bien. Pour un projet qui a un coût fixe, ce n'est pas le cas.
Pour ces projets à coûts fixes, le client s'attend presque toujours à ce que des jalons prédéfinis démontrent les progrès, cependant, il s'agit davantage de la variété écrite formelle que du code de travail. Pour des clients comme celui-ci, les spécifications écrites deviennent le projet, celui où le développement logiciel est une considération secondaire (comme ils le supposent, si vous avez un projet bien défini, le logiciel devrait être facile à développer). Ces sociétés sont également celles qui font un usage intensif de ressources de développement externalisées bon marché.
Donc, si vous avez un pot d'argent ou de temps fixe, ne vous attendez pas à ce que les exigences changent ou n'êtes pas autorisé à changer les exigences, et vous êtes censé fournir un ensemble solide de documentation écrite, alors les modèles en cascade sont les seuls qui faire sens.
Agile peut être introduit au milieu de ces projets pour faire le développement, mais vous avez toujours une phase de montée en puissance où les spécifications sont créées à partir des exigences, et une phase de descente où le logiciel est installé et testé in situ. Agile ne répond pas bien à ces cas.