Le modele en cascade , ou ≪  waterfall  ≫ en anglais, est une organisation des activites d'un projet sous forme de phases lineaires et sequentielles, ou chaque phase correspond a une specialisation des taches et depend des resultats de la phase precedente. Il comprend les phases d'exigences, de conception, de mise en œuvre et de mise en service.

Le modele en cascade est un cycle de vie de projet issu des industries manufacturieres et du secteur de la construction , ou une conception prealable est necessaire, compte tenu des fortes contraintes materielles et des couts eleves afferents aux changements de la conception en cours de realisation. Il est utilise notamment dans les domaines de l' ingenierie et du developpement de logiciels .

Historique [ modifier | modifier le code ]

La premiere presentation decrivant un modele de phases pour le developpement de logiciels, est celle de Herbert D. Benington ^{[ 1 ]} au ≪ Symposium sur les methodes de programmation avancees pour les calculateurs numeriques ≫ le 29 juin 1956 . L'article avait pour contexte le developpement d'un systeme militaire appele SAGE . Il decrivait un processus de developpement avec une phase de planification en amont, plusieurs phases de specifications, une phase de programmation (≪ codage ≫), plusieurs phases successives de tests, et une phase de validation finale. L'article fut republie en 1983 avec une preface de Benington qui precisait que la separation en phases correspondait a une logique de specialisation par metier, et qui soulignait qu'il avait omis dans les activites un prototype prealable a la realisation du projet ^{[ 2 ]} .

La premiere description du modele en cascade est souvent consideree comme etant celle de l'article de Winston W. Royce en 1970 ^{[ 3 ]} . L'article fournit une representation graphique de la cascade sans toutefois jamais utiliser le terme. Ironiquement, la publication de Royce etait une critique des insuffisances du modele. C'est ainsi que le terme s'est generalise ^{[ 4 ]} .

La premiere citation averee du terme ≪ cascade ≫ figure dans un article de 1976 de Bell et Thayer qui credite Royce pour le terme ^{[ 5 ]} .

En 1985, le departement de la Defense des Etats-Unis a repris l'approche en cascade dans sa norme DOD-STD-2167 qui specifie les relations avec les sous-traitants pour le developpement de logiciels, et qui precise que ≪ le contractant devra mettre en œuvre un cycle de developpement de logiciels qui inclut les six phases suivantes : conception prealable, conception detaillee, programmation, tests unitaires, integration et tests≫. Cette norme sera remplacee en 1994 par la specification MIL-STD-498 qui ne fait plus de reference au modele en cascade et promeut a la place un procede d'acquisition evolutives et des methodes de developpement iteratives et incrementales ^{[ 6 ]} .

Principe [ modifier | modifier le code ]

Le modele en cascade comprend les phases et les livrables suivants :

1. Exigences  : les exigences font l'objet d'une expression des besoins ;
2. Analyse  : les exigences sont analysees pour etablir un cahier des charges fonctionnel  ;
3. Conception : le produit est concu et specifie de sorte a pouvoir etre realise ;
4. Mise en œuvre  : le produit est realise sur la base des specifications ;
5. Validation : le produit est teste et verifie et sa conformite aux exigences est validee ;
6. Mise en service : le produit est installe, les preparatifs pour sa mise en service sont organises, puis le produit est utilise.

Chaque phase ne commence qu'une fois les resultats de la phase precedente valides. Le point fort de cette approche est de garantir l'existence d'une documentation bien structuree ^{[ 3 ]} .

Plusieurs variantes du modele existent, dont l'ajout d'une phase de planification en amont, la realisation prealable d'un prototype, la decomposition de la phase de validation, et le retour aux phases precedentes en cas de defauts decouverts en aval.

Dans le domaine du developpement logiciel, la phase de conception determine l' architecture du systeme, la mise en œuvre correspond principalement aux activites de programmation , et la phase de validation comprend pour une grande part des tests.

Critiques [ modifier | modifier le code ]

Dans son article fondateur, W.W. Royce critique le modele en cascade ^{[ 3 ]} . Il remarque que chaque phase doit pouvoir necessairement renvoyer a la phase precedente en cas de defauts constates en aval (par exemple, en cas d'erreur decouverte lors des tests, il est necessaire de retourner a la phase de programmation). Il constate en outre que les exigences et la conception influent sur toutes les phases en aval, de sorte qu'un retour a ces etapes est souvent necessaire. Il recommande enfin le recours a une conception preliminaire. Son modele revise reste toutefois proche au modele original.

Le modele en cascade se base sur des exigences exprimees en debut de projet. Toutefois les exigences et besoins peuvent se montrer incomplets ou de qualite insuffisante (ambiguite, incoherence, etc.) ^{[ 5 ]} . De plus, le client peut ne pas etre pleinement conscient de ses exigences avant d'avoir vu le logiciel fonctionner. Ceci peut conduire a revoir la conception, redevelopper une partie du logiciel, et retester le produit et donc augmenter les couts ^{[ 7 ]} . C'est pourquoi le modele en cascade est particulierement adapte a des projets dont les exigences sont bien comprises et robustes realises avec une technologie bien maitrisee ^{[ 8 ]} .

La structuration des phases par specialisation d'activite preconise par le modele en cascade est source de rigidite dans l'organisation des travaux, ne favorise pas suffisamment l'implication du client tout au long du projet, et decourage la prise en compte des changements ^{[ 9 ]} . Ce dernier point explique l'emergence des les annees 1980 d'une approche incrementale du developpement ^{[ 10 ]} .

Evolutions [ modifier | modifier le code ]

Le cycle en V utilise une decomposition de phase similaire a la cascade, mais en renforcant la validation ^{[ 11 ]} . Celle-ci se deroule en plusieurs etapes distinctes, chacune verifiant par des tests appropries la conformite d'une des phases en amont. La presentation graphique du modele represente alors un V lorsqu'on met en regard des phases de validation avec les phases validees.

Les auteurs du Processus Unifie reconnaissent l'interet du phasage sequentiel du projet. Mais au lieu de separer artificiellement les activites par phase, ils preconisent des activites integrees, au sein de phases organisees par degre de maturation du produit: creation ^{[ 12 ]} ( ≪  inception  ≫ en anglais), elaboration ^{[ 13 ]} , construction ^{[ 14 ]} , et transition ^{[ 15 ]} et de decouper chacune de ces phases en plusieurs iterations ^{[ 16 ]} .

Voir aussi [ modifier | modifier le code ]

Articles connexes [ modifier | modifier le code ]

• Cycle en V
• Modele en spirale
• Processus Unifie
• Methode agile
• DevOps
• Methode d'analyse et de conception orientees objet
• Developpement de logiciels
• Gestion de projet

Notes et references [ modifier | modifier le code ]

• (en) Cet article est partiellement ou en totalite issu de l’article de Wikipedia en anglais intitule ≪  Waterfall model  ≫ ( voir la liste des auteurs ) .

• Portail du management
• Portail de l’informatique