Le modèle en cascade (waterfall model)

On appelle modèle en cascade un modèle de gestion sé­quen­tiel per­met­tant de re­pré­sen­ter les dé­ve­lop­pe­ments à travers des phases suc­ces­sives.

Le modèle en cascade (en anglais : waterfall model) est un modèle de gestion linéaire qui divise les processus de dé­ve­lop­pe­ment en phases de projet suc­ces­sives. Con­trai­re­ment aux modèles itératifs, chaque phase est effectuée une seule fois. Les sorties de chaque phase an­té­rieure sont intégrées comme entrées de la phase suivante. Le modèle en cascade est prin­ci­pa­le­ment utilisé dans le dé­ve­lop­pe­ment de logiciels.

On doit le dé­ve­lop­pe­ment du modèle en cascade classique à l’in­for­ma­ti­cien Winston Walker Royce. Royce n’en est toutefois pas l’inventeur. En effet, son essai publié en 1970 sous le titre « Managing the De­ve­lop­ment of Large Software Systems » présente plutôt une analyse critique des modèles linéaires. Royce proposait comme al­ter­na­tive un modèle itératif et in­cré­men­tal dans lequel chaque phase re­po­se­rait sur la pré­cé­dente et en vé­ri­fie­rait les résultats.

Il re­com­man­dait un modèle en sept phases qui se dé­rou­laient en plusieurs étapes (ité­ra­tions) :

1. Exigences système
2. Exigences lo­gi­cielles
3. Analyse
4. Con­cep­tion
5. Im­plé­men­ta­tion
6. Test
7. Ex­ploi­ta­tion

Le modèle de gestion que l’on appelle modèle en cascade est fondé sur les phases définies par Royce, mais prévoit une seule itération.

Dans son essai, Royce n’évoque pas une seule fois le terme cascade (waterfall).

Des ex­ten­sions du modèle en cascade simple viennent compléter le modèle de base avec des fonctions ité­ra­tives, par exemple avec des retours en arrière per­met­tant de comparer les résultats de chaque phase avec les hy­po­thèses tirées de la phase pré­cé­dente et ainsi de les vérifier.

Dans le modèle en cascade, les dif­fé­rentes phases d’un processus de dé­ve­lop­pe­ment s’en­chaî­nent. Chaque phase se termine par un résultat in­ter­mé­diaire (étape), par exemple avec un catalogue d’exigences sous la forme d’un cahier des charges, avec la spé­ci­fi­ca­tion d’une ar­chi­tec­ture lo­gi­cielle ou avec une ap­pli­ca­tion au stade alpha ou bêta.

Chaque projet logiciel commence par une phase d’analyse com­pre­nant une étude de fai­sa­bi­lité et une dé­fi­ni­tion des besoins. Les coûts, le rendement et la fai­sa­bi­lité du projet logiciel sont estimés lors de l’étude de fai­sa­bi­lité. Celle-ci permet de créer un cahier des charges (une des­crip­tion grossière des besoins), un plan de projet, une bud­gé­ti­sa­tion du projet et, le cas échéant, un devis pour le client.

Les besoins sont ensuite définis de façon détaillée. Cette dé­fi­ni­tion comprend une analyse réelle et un concept cible. Alors que les analyses réelles décrivent les problèmes, le concept cible permet de définir quelles fonc­tion­na­li­tés et quelles pro­prié­tés le produit logiciel doit offrir afin de répondre aux besoins. La dé­fi­ni­tion des besoins permet notamment d’obtenir un cahier des charges, une des­crip­tion détaillée de la façon dont les exigences du projet doivent être remplies ainsi qu’un plan pour le test d’ac­cep­ta­tion.

Enfin, la première phase du modèle en cascade prévoit une analyse de la dé­fi­ni­tion des besoins, au cours de laquelle les problèmes complexes sont dé­com­po­sés en sous-tâches de moindre ampleur et des stra­té­gies de ré­so­lu­tion cor­res­pon­dantes sont élaborées.

La phase de con­cep­tion sert à l’éla­bo­ra­tion d’un concept de ré­so­lu­tion concret sur la base des besoins, des tâches et des stra­té­gies dé­ter­mi­nées au préalable. Au cours de cette phase, les dé­ve­lop­peurs élaborent l’ar­chi­tec­ture lo­gi­cielle ainsi qu’un plan de cons­truc­tion détaillé du logiciel et se con­centrent ainsi sur les éléments concrets tels que les in­ter­faces, les fra­me­works ou les bi­blio­thèques. Le résultat de la phase de con­cep­tion inclut un document de con­cep­tion avec un plan de cons­truc­tion lo­gi­cielle, ainsi que des plans de test pour les dif­fé­rents éléments.

L’ar­chi­tec­ture lo­gi­cielle élaborée pendant la phase de con­cep­tion est réalisée lors de la phase d’im­plé­men­ta­tion qui comprend la pro­gram­ma­tion du logiciel, la recherche d’erreurs et les tests de modules. Lors de la phase d’im­plé­men­ta­tion, le projet de logiciel est transposé dans la langue de pro­gram­ma­tion souhaitée. Les dif­fé­rents com­po­sants logiciels sont dé­ve­lop­pés sé­pa­ré­ment, contrôlés dans le cadre de tests de modules et intégrés étape par étape dans le produit global. Le résultat de la phase d’im­plé­men­ta­tion est un produit logiciel qui sera testé pour la première fois en tant que produit global lors de la phase suivante (test alpha).

La phase de test comprend l’in­té­gra­tion du logiciel dans l’en­vi­ron­ne­ment cible souhaité. En règle générale, les produits logiciels sont tout d’abord livrés à une sélection d’uti­li­sa­teurs finaux sous la forme d’une version bêta (bêta-tests). Il est alors déterminé si le logiciel répond aux besoins préa­la­ble­ment définis à l’aide des tests d’ac­cep­ta­tion dé­ve­lop­pés lors de la phase d’analyse. Un produit logiciel ayant passé avec succès les bêta-tests est prêt pour la mise à dis­po­si­tion.

Après avoir réussi la phase de tests, le logiciel est mis en pro­duc­tion pour ex­ploi­ta­tion. La dernière phase du modèle en cascade inclut la livraison, la main­te­nance et l’amé­lio­ra­tion du logiciel.

Le modèle en cascade offre une structure hié­rar­chique claire pour les projets de dé­ve­lop­pe­ment dans laquelle les dif­fé­rentes phases du projet sont clai­re­ment dé­li­mi­tées. Étant donné que chaque phase se termine par une étape, le processus de dé­ve­lop­pe­ment peut être suivi fa­ci­le­ment. Le point fort du modèle se trouve dans la do­cu­men­ta­tion des étapes du processus. Les con­nais­sances acquises sont con­sig­nées dans les documents d’exigences et de con­cep­tion.

En théorie, le modèle en cascade doit créer les con­di­tions pour une réa­li­sa­tion rapide et peu coûteuse des projets par une pla­ni­fi­ca­tion mi­nu­tieu­se­ment élaborée au préalable. Toutefois, les avantages du modèle en cascade sont sujets à con­tro­verse dans la pratique. D’une part, les phases du projet sont rarement dé­li­mi­tées clai­re­ment dans le dé­ve­lop­pe­ment logiciel. Pour les projets logiciels complexes notamment, les dé­ve­lop­peurs sont souvent con­fron­tés au fait que les dif­fé­rents com­po­sants d’une ap­pli­ca­tion se trouvent dans dif­fé­rentes phases de dé­ve­lop­pe­ment au même moment. D’autre part, le dé­rou­le­ment linéaire du modèle en cascade ne cor­res­pond souvent pas aux con­di­tions réelles.

Le modèle en cascade ne prévoit pas à pro­pre­ment parler des adap­ta­tions en cours de projet. Un projet de logiciel, dans lequel l’ensemble des détails du dé­ve­lop­pe­ment sont déjà définis au début du projet, peut toutefois uni­que­ment aboutir lorsque beaucoup de temps et d’argent ont été investis dès le départ dans l’analyse et la con­cep­tion. S’y ajoute le fait que les projets logiciels plus vastes s’étendent parfois sur plusieurs années et sans un ajus­te­ment régulier aux dé­ve­lop­pe­ments actuels, ils four­ni­raient des résultats déjà obsolètes lors de leur in­tro­duc­tion.

Le modèle en cascade est prin­ci­pa­le­ment utilisé dans les projets pour lesquels les besoins et les processus peuvent être définis de façon précise dès la phase de pla­ni­fi­ca­tion et pour lesquels on peut supposer que les hy­po­thèses chan­ge­ront peu tout au long du dé­rou­le­ment du projet. Les modèles de gestion stric­te­ment linéaires con­vien­nent ainsi prin­ci­pa­le­ment aux projets logiciels plus petits, simples et clai­re­ment struc­tu­rés. Royce était déjà parvenu à cette con­clu­sion dans les années 1970. L’al­ter­na­tive au modèle de gestion linéaire qu’il proposait, plus tard connue sous le nom de modèle en cascade, com­pre­nait par con­sé­quent trois ex­ten­sions es­sen­tielles :

D’après Royce, les résultats de chaque phase de projet doivent être comparés et vérifiés im­mé­dia­te­ment à l’aide des documents élaborés au préalable. Il serait par exemple né­ces­saire de contrôler qu’un module répond aux exigences définies au préalable im­mé­dia­te­ment après son dé­ve­lop­pe­ment et non uni­que­ment à la fin du processus de dé­ve­lop­pe­ment.

Selon Royce, le modèle en cascade devrait être effectué au minimum à deux reprises : une première fois pour le dé­ve­lop­pe­ment d’un prototype et une seconde pour le dé­ve­lop­pe­ment du produit logiciel à pro­pre­ment parler.

Comme troisième extension du modèle en cascade, Royce re­com­man­dait dans son essai une mesure qui fait aujourd’hui partie de la procédure standard dans le dé­ve­lop­pe­ment de produit : l’in­té­gra­tion de l’uti­li­sa­teur final dans le processus de pro­duc­tion. Royce proposait d’intégrer l’uti­li­sa­teur à trois reprises dans le processus de dé­ve­lop­pe­ment logiciel : lors de la pla­ni­fi­ca­tion du logiciel dans le cadre de la phase d’analyse, entre la con­cep­tion du logiciel et son im­plé­men­ta­tion et lors de la phase de test avant la mise à dis­po­si­tion du logiciel.

En raison du dé­rou­le­ment stric­te­ment linéaire des phases de projet qui se suivent de façon sé­quen­tielle, le modèle en cascade convient uni­que­ment à de petits projets logiciels, si tant est qu’il convienne à un quel­conque projet. En revanche, les processus complexes et à plusieurs niveaux ne sauraient être re­pré­sen­tés avec ce modèle. C’est la raison pour laquelle dif­fé­rentes approches al­ter­na­tives ont été dé­ve­lop­pées au fil du temps.

Alors que des modèles comme le modèle en spirale ou le modèle du cycle en V sont con­si­dé­rés comme des amé­lio­ra­tions du modèle en cascade classique, des concepts tels que l’« extreme pro­gram­ming », le dé­ve­lop­pe­ment logiciel agile ou le pro­to­ty­page itératif reposent sur une tout autre approche et per­met­tent gé­né­ra­le­ment une adap­ta­tion flexible aux mo­di­fi­ca­tions actuelles et aux nouveaux besoins.