Modèle en cascade

Le modèle en cascade, ou « waterfall » en anglais, est une organisation des activités d'un projet sous forme de phases linéaires et séquentielles, où chaque phase correspond à une spécialisation des tâches et dépend des résultats de la phase précédente. Il comprend les phases d'exigences, de conception, de mise en œuvre et de mise en service.

Le modèle en cascade est un cycle de vie de projet issu des industries manufacturières et du secteur de la construction, où une conception préalable est nécessaire, compte tenu des fortes contraintes matérielles et des coûts élevés afférents aux changements de la conception en cours de réalisation. Il est utilisé notamment dans les domaines de l'ingénierie et du développement de logiciels.

Historique

La première présentation décrivant un modèle de phases pour le développement de logiciels, est celle de Herbert D. Benington[1] au « Symposium sur les méthodes de programmation avancées pour les calculateurs numériques » le . L'article avait pour contexte le développement d'un système militaire appelé SAGE. Il décrivait un processus de développement avec une phase de planification en amont, plusieurs phases de spécifications, une phase de programmation (« codage »), plusieurs phases successives de tests, et une phase de validation finale. L'article fut republié en 1983 avec une préface de Benington qui précisait que la séparation en phases correspondait à une logique de spécialisation par métier, et qui soulignait qu'il avait omis dans les activités un prototype préalable à la réalisation du projet[2].

La première description du modèle en cascade est souvent considérée comme étant celle de l'article de Winston W. Royce en 1970 [3]. L'article fournit une représentation graphique de la cascade sans toutefois jamais utiliser le terme. Ironiquement, la publication de Royce était une critique des insuffisances du modèle. C'est ainsi que le terme s'est généralisé[4].

La première citation avérée du terme « cascade » figure dans un article de 1976 de Bell et Thayer qui crédite Royce pour le terme[5].

En 1985, le Département de la Défense des États-Unis a repris l'approche en cascade dans sa norme DOD-STD-2167A qui spécifie les relations avec les sous-traitants pour le développement de logiciels, et qui précise que « le contractant devra mettre en œuvre un cycle de développement de logiciels qui inclut les six phases suivantes : conception préalable, conception détaillée, programmation, tests unitaires, intégration et tests». Cette norme sera remplacée en 1994 par la spécification MIL-STD-498 qui ne fait plus de référence au modèle en cascade et promeut à la place un procédé d'acquisition évolutives et des méthodes de développement itératives et incrémentales[6].

Principe
Modèle en cascade générique

Le modèle 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 analysées pour établir un cahier des charges fonctionnel ;
  3. Conception : le produit est conçu et spécifié de sorte à pouvoir être réalisé ;
  4. Mise en œuvre : le produit est réalisé sur la base des spécifications ;
  5. Validation : le produit est testé et vérifié et sa conformité aux exigences est validée ;
  6. Mise en service : le produit est installé, les préparatifs pour sa mise en service sont organisés, puis le produit est utilisé.

Chaque phase ne commence qu'une fois les résultats de la phase précédente validés. Le point fort de cette approche est de garantir l'existence d'une documentation bien structurée[3].

Plusieurs variantes du modèle existent, dont l'ajout d'une phase de planification en amont, la réalisation préalable d'un prototype, la décomposition de la phase de validation, et le retour aux phases précédentes en cas de défauts découverts en aval.

Dans le domaine du développement logiciel, la phase de conception détermine l'architecture du système, la mise en œuvre correspond principalement aux activités de programmation, et la phase de validation comprend pour une grande part des tests.

Critiques
Modèle en cascade générique avec les principaux livrables. La détection de défauts en aval nécessite des retours vers les étapes précédentes, jusqu'aux exigences si celles-ci sont erronées.

Dans son article fondateur, W.W. Royce critique le modèle en cascade[3]. Il remarque que chaque phase doit pouvoir nécessairement renvoyer à la phase précédente en cas de défauts constatés en aval (par exemple, en cas d'erreur découverte lors des tests, il est nécessaire de retourner à 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 à ces étapes est souvent nécessaire. Il recommande enfin le recours à une conception préliminaire. Son modèle révisé reste toutefois proche au modèle original.

Le modèle en cascade se base sur des exigences exprimées en début de projet. Toutefois les exigences et besoins peuvent se montrer incomplets ou de qualité insuffisante (ambiguïté, incohérence, etc.)[5]. De plus, le client peut ne pas être pleinement conscient de ses exigences avant d'avoir vu le logiciel fonctionner. Ceci peut conduire à revoir la conception, redévelopper une partie du logiciel, et retester le produit et donc augmenter les coûts[7]. C'est pourquoi le modèle en cascade est particulièrement adapté à des projets dont les exigences sont bien comprises et robustes réalisés avec une technologie bien maîtrisée[8].

La structuration des phases par spécialisation d'activité préconisé par le modèle en cascade est source de rigidité dans l'organisation des travaux, ne favorise pas suffisamment l'implication du client tout au long du projet, et décourage la prise en compte des changements[9]. Ce dernier point explique l'émergence dès les années 1980 d'une approche incrémentale du développement[10].

Évolutions

Le cycle en V utilise une décomposition de phase similaire à la cascade, mais en renforçant la validation[11]. Celle-ci se déroule en plusieurs étapes distinctes, chacune vérifiant par des tests appropriés la conformité d'une des phases en amont. La présentation graphique du modèle représente alors un V lorsqu'on met en regard des phases de validation avec les phases validées.

Les auteurs du Processus Unifié reconnaissent l'intérêt du phasage séquentiel du projet. Mais au lieu de séparer artificiellement les activités par phase, ils préconisent des activités intégrées, au sein de phases organisées par degré de maturation du produit: création[12] ( « inception » en anglais), elaboration[13], construction[14], et transition[15] et de découper chacune de ces phases en plusieurs itérations[16].

Voir aussi

Articles connexes

Notes et références
  1. (en) United States, Navy Mathematical Computing Advisory Panel, United States et Office of Naval Research, Symposium on advanced programming methods for digital computers : Washington, D.C., June 28, 29, 1956, Office of Naval Research, Dept. of the Navy, (OCLC 10794738, lire en ligne)
  2. Herbert D. Benington, « Production of Large Computer Programs », IEEE Annals of the History of Computing, vol. 5, no 4,‎ , p. 350–361 (ISSN 1058-6180, DOI 10.1109/MAHC.1983.10102, lire en ligne, consulté le )
  3. (en) W. W. Royce, « Managing the Development of Large Software Systems: Concepts and Techniques », Proceedings of the 9th International Conference on Software Engineering, IEEE Computer Society Press, iCSE '87,‎ , p. 328–338 (ISBN 9780897912167, lire en ligne, consulté le )
  4. (en) Conrad Weisert, « Waterfall Methodology: There's no such thing! », sur www.idinews.com (consulté le )
  5. (en) T. E. Bell et T. A. Thayer, « Software Requirements: Are They Really a Problem? », Proceedings of the 2Nd International Conference on Software Engineering, IEEE Computer Society Press, iCSE '76,‎ , p. 61–68 (lire en ligne, consulté le )
  6. (en) C. Larman et V. R. Basili, « Iterative and incremental developments. a brief history », Computer, vol. 36, no 6,‎ , p. 47–56 (ISSN 0018-9162, DOI 10.1109/MC.2003.1204375, lire en ligne, consulté le )
  7. (en) David Lorge Parnas et Paul C. Clements, « A rational design process: How and why to fake it », IEEE Transactions on Software Engineering, vol. SE-12, no 2,‎ , p. 251–257 (ISSN 0098-5589, DOI 10.1109/TSE.1986.6312940, lire en ligne, consulté le )
  8. (en) Barry Boehm et Frank Belz, « Experiences with the Spiral Model As a Process Model Generator », Proceedings of the 5th International Software Process Workshop on Experience with Software Process Models, IEEE Computer Society Press, iSPW '90,‎ , p. 43–45 (ISBN 9780818621048, lire en ligne, consulté le )
  9. (en) Daniel D. McCracken et Michael A. Jackson, « Life Cycle Concept Considered Harmful », SIGSOFT Softw. Eng. Notes, vol. 7, no 2,‎ , p. 29–32 (ISSN 0163-5948, DOI 10.1145/1005937.1005943, lire en ligne, consulté le )
  10. (en) Tom Gilb, « Evolutionary development », ACM SIGSOFT Software Engineering Notes, vol. 6, no 2,‎ , p. 17–17 (DOI 10.1145/1010865.1010868, lire en ligne, consulté le )
  11. « V-Model: Qu'est-ce que c'est et comment l'utiliser ? | SUPINFO, École Supérieure d'Informatique », sur www.supinfo.com (consulté le )
  12. « phase de création », sur www.granddictionnaire.com (consulté le )
  13. « phase d'élaboration », sur www.granddictionnaire.com (consulté le )
  14. « phase de construction », sur www.granddictionnaire.com (consulté le )
  15. « phase de transition », sur www.granddictionnaire.com (consulté le )
  16. (en) Kroll, Per., The rational unified process made easy : a practitioner's guide to the RUP, Addison-Wesley, (ISBN 0-321-16609-4 et 9780321166098, OCLC 51242053, lire en ligne)


  • Portail du management
  • Portail de l’informatique
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.