Quels sont les problèmes du modèle en cascade ?

Le modèle en cascade est une approche de conception séquentielle relativement linéaire pour certains domaines de la conception technique.

Dans le développement de logiciels, il a tendance à faire partie des approches les moins itératives et les moins flexibles, car les progrès s’écoulent principalement dans une direction vers le bas, comme une cascade, à travers les phases de conception, d’initiation, d’analyse, de conception, de construction, de test, de déploiement et de maintenance. Utilisées dans les projets de développement de logiciels, les phases ressemblent généralement à ceci :

1. Exigences

Si vous êtes dans le développement de logiciels ou dans tout type d’équipe de création de projet, vous voudriez connaître le contexte commercial de ce que vous essayez de créer – vous voulez définir le type de problèmes que vous essayez de résoudre et comment les gens réagiraient à votre produit fini. Après avoir défini toutes ces « exigences », vous avez l’entrée dont vous avez besoin pour passer à l’étape suivante.

2. Conception

Cette étape est composée de toutes les étapes dont vous avez besoin pour satisfaire toutes les exigences que vous avez déterminées précédemment. Dans le développement logiciel, c’est la partie où vous définissez toute l’architecture logicielle et matérielle, le langage de programmation, le stockage des données, etc. C’est aussi la partie où vous déterminez comment le projet serait utile à son utilisateur final.

3. Mise en œuvre

Dans cette étape, vous commencez à construire ce que vous avez conçu dans votre plan. Cette partie de la méthode Waterfall est dédiée au respect des normes que vous avez établies lors des étapes précédentes. C’est la partie où les membres de l’équipe de développement interviennent et font en sorte que toutes les choses discutées dans les étapes précédentes se produisent.

4. Vérification

C’est la partie de la méthode où les personnes chargées de l’assurance qualité entrent pour s’assurer que l’équipe de développement n’a commis aucune erreur. C’est aussi très probablement la partie où les gens réalisent ce qui fonctionne ou ne fonctionne pas dans leur plan.

Notez que

Lorsque tout est satisfait par les développeurs du projet, le client ou l’utilisateur final intervient et prend la décision finale si le projet est prêt à être lancé.

La méthode Waterfall met l’accent sur le fait que lorsque quelque chose ne va pas à une étape particulière, les gens peuvent revenir à la précédente pour voir ce qui n’a pas fonctionné. Par exemple, s’il y a un problème dans la mise en œuvre du plan et que les gens savent qu’ils ont simplement suivi le plan qui leur a été remis, alors les gestionnaires examinent leur plan et font leurs révisions à partir de là.

Quel est le problème de la cascade ?

Les clients peuvent ne pas savoir exactement quelles sont leurs exigences avant de voir un logiciel fonctionnel et ainsi modifier leurs exigences, ce qui entraîne une refonte, un redéveloppement et de nouveaux tests, ainsi qu’une augmentation des coûts.

Les développeurs peuvent ne pas être conscients des difficultés futures lors de la conception d’un nouveau produit logiciel ou d’une nouvelle fonctionnalité, auquel cas il est préférable de réviser la conception que de persister dans une conception qui ne tient pas compte des contraintes, exigences ou problèmes nouvellement découverts.

Ainsi, il n’y a aucune garantie que les exigences auxquelles l’organisation a pensé fonctionneraient réellement. À partir de là, vous vous rendriez compte que le modèle Waterfall présente les problèmes suivants :

1.  Les gens suivent aveuglément les plans.

Dans la méthode traditionnelle, les gens accordent plus d’attention à la façon dont les choses se passeront au bon moment sans se soucier si les choses se mettent vraiment en place. Bien que la planification soit importante, il est également important que les développeurs et les vérificateurs de qualité comprennent comment les choses doivent se passer, en particulier avec le client ou l’utilisateur final. Il est également important que toutes les personnes impliquées dans le projet puissent dire immédiatement comment une étape particulière de la réalisation du projet peut échouer sans avoir à attendre la phase de test.

2.  Le processus séquentiel et les changements deviennent coûteux

Cette approche ne tient pas compte de l’évolution des exigences définies au fur et à mesure de l’avancement du projet. Ainsi, il y a un grand potentiel que le logiciel ne réponde pas entièrement aux exigences de l’utilisateur, il sera inefficace et aura des fonctionnalités médiocres.

C’est inadéquat car les développeurs ne peuvent pas simplement revenir en arrière et changer quelque chose dans une phase précédente à mesure que les exigences des consommateurs changent, mais le développeur doit revenir là où l’exigence doit changer et recommencer toute cette phase. Ce n’est qu’une fois cette phase terminée qu’il peut passer à la phase suivante.

3.  Les utilisateurs finaux ne savent pas ce qu’ils veulent.

La plupart du temps, l’esprit d’un utilisateur final change constamment et la plupart des gens ont une vague idée de leurs besoins en logiciels et c’est au fur et à mesure que le logiciel se développe qu’ils spécifient leurs besoins.

Lorsqu’il est temps de remettre le produit fini à un client, il est probable qu’il n’aimera pas le résultat, bien qu’il ait délibérément dit le contraire lors des premières étapes. Il est facile pour les clients et les utilisateurs finaux de modifier ce qu’ils veulent au fil du temps. Le système Waterfall n’a pas encore de moyen de résoudre ce problème, sans avoir à réviser les plans et à refaire tout le projet.

4.  Les tests de qualité peuvent en souffrir.

Il est impossible de prédire avec précision les résultats d’un projet, et lorsque toute l’équipe est pressée par le temps, il est possible d’écourter la phase de test afin de respecter le délai.

5.  Vous ne saurez jamais à quelle étape vous vous trouvez vraiment.

Étant donné que le produit que vous essayez de créer ne sera pas produit avant la toute fin, vous ne savez pas vraiment si vous êtes toujours en train de planifier ou si vous êtes déjà en phase de développement. Cela signifie qu’il est également probable que vous passiez plus de temps sur une scène que ce à quoi vous vous attendiez en raison de cette mauvaise visibilité.

Au final, la méthode Waterfall peut être trop risquée car trop rigide. Afin que vous produisiez un produit qui fonctionne et qui soit suffisamment flexible pour vous aider à déterminer ce qui fonctionne ou non.

Ressources associées

• Agile & Scrum — Articles sur le développement logiciel ( Anglais ) ( Chinois ) ( Japonais )