Le modèle en cascade (waterfall model)

On appelle modèle en cascade un modèle de gestion séquentiel permettant de représenter les développements à travers des phases successives.

Le modèle en cascade (en anglais : waterfall model) est un modèle de gestion linéaire qui divise les processus de développement en phases de projet successives. Contrairement aux modèles itératifs, chaque phase est effectuée une seule fois. Les sorties de chaque phase antérieure sont intégrées comme entrées de la phase suivante. Le modèle en cascade est principalement utilisé dans le développement de logiciels.

On doit le développement du modèle en cascade classique à l’informaticien Winston Walker Royce. Royce n’en est toutefois pas l’inventeur. En effet, son essai publié en 1970 sous le titre « Managing the Development of Large Software Systems » présente plutôt une analyse critique des modèles linéaires. Royce proposait comme alternative un modèle itératif et incrémental dans lequel chaque phase reposerait sur la précédente et en vérifierait les résultats.

Il recommandait un modèle en sept phases qui se déroulaient en plusieurs étapes (itérations) :

1. Exigences système
2. Exigences logicielles
3. Analyse
4. Conception
5. Implémentation
6. Test
7. Exploitation

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 extensions du modèle en cascade simple viennent compléter le modèle de base avec des fonctions itératives, par exemple avec des retours en arrière permettant de comparer les résultats de chaque phase avec les hypothèses tirées de la phase précédente et ainsi de les vérifier.

Dans le modèle en cascade, les différentes phases d’un processus de développement s’enchaînent. Chaque phase se termine par un résultat intermédiaire (étape), par exemple avec un catalogue d’exigences sous la forme d’un cahier des charges, avec la spécification d’une architecture logicielle ou avec une application au stade alpha ou bêta.

Chaque projet logiciel commence par une phase d’analyse comprenant une étude de faisabilité et une définition des besoins. Les coûts, le rendement et la faisabilité du projet logiciel sont estimés lors de l’étude de faisabilité. Celle-ci permet de créer un cahier des charges (une description grossière des besoins), un plan de projet, une budgétisation 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éfinition 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 fonctionnalités et quelles propriétés le produit logiciel doit offrir afin de répondre aux besoins. La définition des besoins permet notamment d’obtenir un cahier des charges, une description détaillée de la façon dont les exigences du projet doivent être remplies ainsi qu’un plan pour le test d’acceptation.

Enfin, la première phase du modèle en cascade prévoit une analyse de la définition des besoins, au cours de laquelle les problèmes complexes sont décomposés en sous-tâches de moindre ampleur et des stratégies de résolution correspondantes sont élaborées.

La phase de conception sert à l’élaboration d’un concept de résolution concret sur la base des besoins, des tâches et des stratégies déterminées au préalable. Au cours de cette phase, les développeurs élaborent l’architecture logicielle ainsi qu’un plan de construction détaillé du logiciel et se concentrent ainsi sur les éléments concrets tels que les interfaces, les frameworks ou les bibliothèques. Le résultat de la phase de conception inclut un document de conception avec un plan de construction logicielle, ainsi que des plans de test pour les différents éléments.

L’architecture logicielle élaborée pendant la phase de conception est réalisée lors de la phase d’implémentation qui comprend la programmation du logiciel, la recherche d’erreurs et les tests de modules. Lors de la phase d’implémentation, le projet de logiciel est transposé dans la langue de programmation souhaitée. Les différents composants logiciels sont développés séparé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’implémentation 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’intégration du logiciel dans l’environnement cible souhaité. En règle générale, les produits logiciels sont tout d’abord livrés à une sélection d’utilisateurs 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éalablement définis à l’aide des tests d’acceptation développé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 à disposition.

Après avoir réussi la phase de tests, le logiciel est mis en production pour exploitation. La dernière phase du modèle en cascade inclut la livraison, la maintenance et l’amélioration du logiciel.

Le modèle en cascade offre une structure hiérarchique claire pour les projets de développement dans laquelle les différentes phases du projet sont clairement délimitées. Étant donné que chaque phase se termine par une étape, le processus de développement peut être suivi facilement. Le point fort du modèle se trouve dans la documentation des étapes du processus. Les connaissances acquises sont consignées dans les documents d’exigences et de conception.

En théorie, le modèle en cascade doit créer les conditions pour une réalisation rapide et peu coûteuse des projets par une planification minutieusement élaborée au préalable. Toutefois, les avantages du modèle en cascade sont sujets à controverse dans la pratique. D’une part, les phases du projet sont rarement délimitées clairement dans le développement logiciel. Pour les projets logiciels complexes notamment, les développeurs sont souvent confrontés au fait que les différents composants d’une application se trouvent dans différentes phases de développement au même moment. D’autre part, le déroulement linéaire du modèle en cascade ne correspond souvent pas aux conditions réelles.

Le modèle en cascade ne prévoit pas à proprement parler des adaptations en cours de projet. Un projet de logiciel, dans lequel l’ensemble des détails du développement sont déjà définis au début du projet, peut toutefois uniquement aboutir lorsque beaucoup de temps et d’argent ont été investis dès le départ dans l’analyse et la conception. S’y ajoute le fait que les projets logiciels plus vastes s’étendent parfois sur plusieurs années et sans un ajustement régulier aux développements actuels, ils fourniraient des résultats déjà obsolètes lors de leur introduction.

Le modèle en cascade est principalement 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 planification et pour lesquels on peut supposer que les hypothèses changeront peu tout au long du déroulement du projet. Les modèles de gestion strictement linéaires conviennent ainsi principalement aux projets logiciels plus petits, simples et clairement structurés. Royce était déjà parvenu à cette conclusion dans les années 1970. L’alternative au modèle de gestion linéaire qu’il proposait, plus tard connue sous le nom de modèle en cascade, comprenait par conséquent trois extensions essentielles :

D’après Royce, les résultats de chaque phase de projet doivent être comparés et vérifiés immédiatement à l’aide des documents élaborés au préalable. Il serait par exemple nécessaire de contrôler qu’un module répond aux exigences définies au préalable immédiatement après son développement et non uniquement à la fin du processus de développement.

Selon Royce, le modèle en cascade devrait être effectué au minimum à deux reprises : une première fois pour le développement d’un prototype et une seconde pour le développement du produit logiciel à proprement parler.

Comme troisième extension du modèle en cascade, Royce recommandait dans son essai une mesure qui fait aujourd’hui partie de la procédure standard dans le développement de produit : l’intégration de l’utilisateur final dans le processus de production. Royce proposait d’intégrer l’utilisateur à trois reprises dans le processus de développement logiciel : lors de la planification du logiciel dans le cadre de la phase d’analyse, entre la conception du logiciel et son implémentation et lors de la phase de test avant la mise à disposition du logiciel.

En raison du déroulement strictement linéaire des phases de projet qui se suivent de façon séquentielle, le modèle en cascade convient uniquement à de petits projets logiciels, si tant est qu’il convienne à un quelconque projet. En revanche, les processus complexes et à plusieurs niveaux ne sauraient être représentés avec ce modèle. C’est la raison pour laquelle différentes approches alternatives ont été développé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 considérés comme des améliorations du modèle en cascade classique, des concepts tels que l’« extreme programming », le développement logiciel agile ou le prototypage itératif reposent sur une tout autre approche et permettent généralement une adaptation flexible aux modifications actuelles et aux nouveaux besoins.