Modèle en cascade

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 29 juin 1956. 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].

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.

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].

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].

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Waterfall model » (voir la liste des auteurs).