1.
Définition et historique
a) Définition :
Le modèle en cascade (Waterfall model) est un modèle de développement logiciel
linéaire et séquentiel. Il consiste à diviser le cycle de vie du logiciel en plusieurs phases
distinctes, qui doivent être réalisées l’une après l’autre, sans retour en arrière (ou avec un
retour très limité).
Chaque étape doit être terminée et validée avant de passer à la suivante.
b) Historique
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 . 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é.
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.
En 1985, le Département de la Défense des Etats-Unis a repris l'approche en cascade dans
sa norme DOD-STD-2167 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
2. Etapes du modèle Waterfall
Le modèle Waterfall comporte 6 étapes :
- Définition des besoins
L’expression des besoins (exigences) est cruciale pour établir une base solide pour le projet.
Elle implique de recueillir et de documenter en détail les attentes et exigences des parties
prenantes et des utilisateurs.
Ce processus, qui peut inclure des entretiens et des questionnaires, permet de comprendre les
besoins spécifiques et de les intégrer dans la planification du projet.
L'expression des besoins est dynamique, pouvant être mise à jour tout au long du projet pour
s'adapter aux changements et évolutions.
Elle guide la conception et la mise en œuvre du projet, en fournissant des orientations claires et
précises.
- Analyse des besoins
Dans cette phase, il est crucial de prendre en compte les contraintes de gestion de projet pour
orienter notre analyse.
On va maintenant examiner toutes les possibilités, en tenant compte de ces contraintes :
• Écarter toute solution ne correspondant pas aux exigences et aux contraintes de gestion de
projet identifiées.
• Affiner la sélection en considérant comment chaque option s'aligne avec ces contraintes.
• Détailler les options, en mettant l'accent sur la manière dont elles répondent ou s'adaptent
aux contraintes de gestion de projet.
• Préparer toutes les informations nécessaires, en tenant compte des contraintes de gestion de
projet, pour l’étape suivante.
- Conception du projet
Avant de passer à la rédaction de la charte de projet cette phase est dédiée à l'élaboration d'une
vision globale de l'initiative, sans entrer dans les détails techniques ou opérationnels.
La phase de conception ne se limite pas à la simple planification ; elle est essentielle pour aligner
les visions et attentes des différentes parties prenantes.
L’usage d’outils visuels dans cette étape établit une fondation solide et partagée pour le projet.
- Réalisation du projet
Cette phase, marquée par le développement de prototypes ou de versions bêta, intègre
également les contraintes de gestion de projet dans une collaboration intense entre les
différentes équipes.
Cela permet d'incorporer les retours des tests préliminaires dans le développement continu du
projet.
Elle met l'accent sur l'adaptation agile du projet aux retours et aux découvertes faites pendant
les tests, assurant ainsi que le produit final ou le résultat du projet soit de la plus haute qualité
et réponde au mieux aux besoins des utilisateurs, tout en respectant les contraintes de gestion
de projet.
- Contrôle et validation
La phase de contrôle et validation en gestion de projet implique un suivi continu et une
évaluation analytique des méthodes et résultats par rapport aux objectifs.
Cette étape permet d’identifier et corriger les ecarts.
Enfin, la clôture du projet marque la fin du cycle de vie du projet, avec un rapport final sur la
réussite globale à présenter au sponsor.
- Mise en service
La phase de mise en service comprend la préparation de la documentation finale et le transfert
des connaissances, essentiels pour une transition fluide vers l'exploitation normale.
Elle vise également à préparer toutes les parties prenantes au changement, assurant ainsi leur
préparation et leur adaptation au nouveau système ou processus.
Cette phase implique également l'évaluation de l'impact du projet sur l'organisation et ses
clients, garantissant ainsi une transition en douceur et efficace vers la nouvelle phase
d’exploitation ou de maintenance.
3. Avantages et inconvénients
Avantages du modèle en cascade
• Clarté et structure: Le modèle offre une structure hiérarchique claire, avec des étapes bien
définies qui facilitent le suivi du projet et la documentation.
• Documentation: Il met l'accent sur la documentation rigoureuse des exigences et des
décisions de conception, ce qui est un atout pour la traçabilité.
• Adapté aux projets simples: Il est bien adapté aux petits projets dont les exigences sont
claires, stables et connues dès le début du projet.
• Facilité de suivi : le planning et le budget sont plus faciles à estimer (chaque étape est connue à
l’avance).
Inconvénients et limites
• Manque de flexibilité: Le caractère séquentiel et non itératif du modèle le rend peu flexible,
rendant difficile la correction des erreurs ou l'adaptation aux nouvelles exigences en cours
de projet.
• Risque lié à la validation tardive: Les tests et l'intégration se font tard dans le processus, ce
qui signifie que les problèmes de conception ne sont détectés que lorsque le produit est déjà
bien avancé, ce qui rend les modifications coûteuses.
• Inadéquation avec la réalité des projets complexes: Pour les projets complexes, il est rare
que toutes les étapes soient aussi clairement délimitées, et les composants du projet peuvent
nécessiter différentes phases en même temps.
• Risque élevé d’échec : si les besoins initiaux sont mal compris, tout le projet peut être
compromis.
• L’utilisateur final est uniquement intégré dans le processus de production après la
programmation.
• Les erreurs sont parfois détectées uniquement à la fin du processus de développement.
En définitive, le modèle en cascade convient aux projets où les exigences sont stables, bien
définies, et où le budget et le calendrier sont rigides.
Une vérification après chaque phase de projet (pour améliorer)
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.
[Link]
[Link]
[Link]
[Link]
+cascade&sca_esv=7cb9f156b4b884f6&hl=fr&sxsrf=AE3TifPKh4Y8oJrTT1ldYORRP9hiPj
Bm1A%3A1758686739735&source=hp&ei=E27TaPKFK_-
HwbkP15mnWQ&iflsig=AOw8s4IAAAAAaNN8I-LkGbq-aIS7Ikro-
JM7orjm8QzZ&ved=0ahUKEwiy25DTwvCPAxX_QzABHdfMKQsQ4dUDCBc&uact=5&o
q=Modeles+de+mise+en+oeuvre+logicielle%2C+modele+en+cascade&gs_lp=Egdnd3Mtd2l6
IjdNb2RlbGVzIGRlIG1pc2UgZW4gb2V1dnJlIGxvZ2ljaWVsbGUsIG1vZGVsZSBlbiBjYX
NjYWRlMgUQIRigATIFECEYoAEyBRAhGKABMgUQIRigATIFECEYoAFIgZkBUABY
gZMBcAN4AJABBZgB9wygAc6UAaoBDzAuMS4xLjIuNi0zLjguNLgBA8gBAPgBAZgC
DqAC5lPCAgYQABgWGB7CAggQABgWGAoYHsICCBAAGIAEGKIEwgIFEAAY7wXC
AgQQIRgVwgIHECEYoAEYCsICBBAhGArCAgUQIRifBZgDAJIHDTMuMS4xLjIuNi0x
LjagB-dYsgcNMC4xLjEuMi42LTEuNrgH3lPCBwc0LjcuMi4xyAch&sclient=gws-wiz
Royce, W. W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE
WESCON.
