[Total : 0    Moyenne : 0/5]

Développé dans les années 1970, la méthode Waterfall est la première méthode de développement des logiciels.

Introduction

La première publication de cette méthode est créditée à Walter Royce dans un article de 19701. Il développa cette méthode qui représente sa vision du développement des logiciels complexes. Mais, le terme Waterfall ne fut introduit que plus tard, en 19762. C’est sans doute la méthode la plus utilisée dans le développement de logiciel. En fonction des entreprises et des contextes cette méthode a évolué, mais à l’initial, Royce avait défini un processus en 7 étapes qu’il appela « étapes d’implémentation pour développer un logiciel complexe à livrer au client ».

La méthode s’appuie sur un développement séquentiel des activités. A chaque étape du processus, nous avons une check-list représentant les critères d’acceptation pour passer à l’étape suivante.

Les inconvénients de la méthode

Développé dans les années 70, on comprend bien que ce qui était valable dans le contexte de l’époque ne l’est plus dans le contexte actuel. Désormais, tout va beaucoup plus vite et les clients demandent de plus en plus du spécifique et du sur-mesure. Ainsi, le développement de logiciel a beaucoup évolué et les méthodes d’organisation des années 70 ne sont plus suffisamment efficaces.

Ainsi, dans un monde de flexibilité et de rapidité, la méthode Waterfall présente les inconvénients suivants :

  • L’immuabilité des spécifications et des besoins fonctionnels : au regard des demandes d’évolutions toujours plus fréquentes, ce qui sera délivré via la méthode Waterfall sera en partie obsolète au moment de leur livraison.
  • Feedback trop tardif : on livre au client tout un ensemble, ce qui fait que nous n’avons son retour qu’au bout d’un délai important.
  • La sectorisation des intervenants : les équipes travaillent de manières compartimentées et non ensemble. En cas de problème, elles vont s’incriminer.
  • On oublie où se trouve la valeur ajoutée du projet et on se concentre sur le respect à la lettre des spécifications. Or celles-ci sont souvent mal comprises et évoluent.
  • La méthode demande de documenter lourdement l’ensemble des besoins et actions. Cela rajoute de la lourdeur dans les processus et rend plus difficile l’intégration des évolutions.

Source

1 – W. Royce (1970) – Managing the development of large software systems

2 – T. Bell et A. Thayer (1976) – Software requirements : are they really a problem

Share This