Waterfall model

Le waterfall model (qu’on peut traduire en français par "modèle de la cascade") est une approche classique dans le développement logiciel qui décrit une méthode de développement linéaire et séquentielle. Il se compose de cinq à sept phases, structurant ainsi le développement d’un logiciel, d’une application ou d’une application web. Une fois qu’une étape est terminée débute la prochaine étape et les résultats de chaque phase précédente sont intégrés dans la phase suivante. Chaque phase se voit définie par différentes tâches et objectifs, l’intégralité des phases décrivant le cycle de vie du logiciel jusqu’à sa livraison.

Contexte

Le waterfall model a été la première méthode largement utilisée dans l’industrie du logiciel. En tant qu’approche traditionnelle, elle n’est pas répétitive, contrairement aux modèles agiles et leurs sprints respectifs, mais peut être complétée par des boucles de rétroaction et de rebouclages. Ce modèle est aujourd’hui encore utilisé sous diverses versions si les exigences et les caractéristiques d’un logiciel peuvent être clairement définies au cours de la phase conceptuelle.

Informations générales

La première fois que le modèle en cascade a été mentionné revient à Winston Royce. Dans son essai intitulé "Gestion du développement de grands systèmes logiciels" ("Managing the Development of Large Software Systems"), il décrit une méthode de développement pour les grands projets logiciels, qui est déjà en 1970 divisé en phases ou étapes. Critiquant cette approche, il propose une alternative qui ressemble à un prototype. Royce fait référence au modèle en neuf étapes de Herbert Benington, publié en 1956. Alors que Benington prévoyait 9 étapes, Royce les réduit à sept. Le terme “waterfall model” n’a été utilisé par aucun d’entre eux. Il se base sur un livre publié en 1976, qui traite principalement des prérequis pour les logiciels.

Comment ça fonctionne

Le modèle original de la cascade se compose de sept étapes successives :

• Prérequis du système : la première phase traite des prérequis qui ne sont pas liés au produit numérique lui-même, mais plutôt aux aspects commerciaux comme le prix ou la disponibilité. Les aspects de documentation et de sécurité sont également spécifiés. En général, c’est ici qu’on mentionne les prérequis non fonctionnels.
• Prérequis du logiciel : les prérequis fonctionnels sur logiciel sont définis au cours de la seconde phase. La question est de savoir ce que le logiciel est capable de faire : on le clarifie dans les "spécifications" ou cahier des charges, qui comprend également les résultats de la première phase.
• Analyse des prérequis : au cours de la phase d’analyse des prérequis, les fonctions du logiciel sont disséquées et structurées de sorte que les éléments individuels et les unités fonctionnelles puissent être séparés les uns des autres. L’analyse des besoins vise à examiner les fonctions pour leur faisabilité et leur importance. Les résultats de cette phases sont les susmentionnées spécifications ou cahier des charges, qui contiennent donc les prérequis qui doivent être développées.
• Design du programme : le design technique est ensuite mis en oeuvre à l’aide de ces spécifications de prérequis. Cette phase comprend également des décisions concernant l’architecture de l’information et les technologies appliquées, telles que les langages de programmation, les bibliothèques de classe et les séquences de programme. Le résultat du design du programme est habituellement enregistré dans des diagrammes décrivant le comportement théorique du logiciel.
• Exécution : lors de la mise en oeuvre, les structures et les flux de travail sont exécutés en tenant compte des conditions et des objectifs du cadre systémique. Le design du logiciel devient donc un programme directement lié à un système d’exploitation, à un ou plusieurs langages de programmation et à l’infrastructure. Il en résulte souvent un logiciel opérationnel, souvent en version beta.
• Test : la phase d’exécution est suivie du test de toutes les composantes du logiciel, modules et ensemble du système. L’intégration dans des systèmes d’exploitation spécifiques est également vérifiée. Si des erreurs et des conflits surviennent, ils doivent être immédiatement réparés. Cela pourrait entraîner une augmentation des coûts globaux, car des erreurs peuvent être attribuées à différentes phases et n’appartiennent pas forcément à la phase précédente.
• Lancement : le logiciel est exécuté après l’acceptation par le client. Les mises à jour et la maintenance peuvent être nécessaires avant que le produit n’entre dans un magasin ou ne soit livré au client.

Différentes équipes et experts travaillent à ces étapes. Les entrepreneurs, les responsables du projet et les développeurs sont généralement impliqués jusqu’à la phase de mise en oeuvre. Après cette dernière phase, les développeurs effectuent les tâches, tout en sachant que les tests logiciel sont fréquemment traités séparément, par exemple par des laboratoires de tests indépendants. Les experts en marketing sont aussi de la partie lors du lancement du produit. Dans les grandes entreprises et corporations, la méthode SDLC est employée (system development lifecycle), se basant sur le modèle en cascade. Il existe également d’autres versions de ce modèle, qui présentent par exemple des éléments répétitifs sous forme de boucles, dans le but de détecter et de corriger les erreurs et les bugs rencontrés dans les phases précédentes.

Avantages et inconvénients

Nous avons listé ici quelques avantages et inconvénients du waterfall model :

Avantages

• En raison de la structure logique du modèle, les erreurs conceptuelles peuvent être souvent évitées.
• Le modèle mène à une documentation technique étendue, ce qui est un soulagement pour les nouveaux programmeurs et développeurs, et aussi utile pour la phase de test.
• Les progrès peuvent être surveillés à l’aide de jalons.
• Le coût total peut être estimé avec une relative précision s’il n’y a pas de conflit.

Inconvénients

• Les conflits, bugs et erreurs de programme entraînent parfois une augmentation des coûts et une quantité considérable de temps. Il en va de même si les clients ne sont pas satisfaits.
• Les spécifications initialement formulées sont souvent difficiles à comprendre pour les clients, car elles sont plus abstraites que ce que le logiciel est supposé faire. Surtout dans le cadre de projets sous-traités, cela peut être un inconvénient décisif car la date de publication peut être reportée et le marché peut avoir changé pendant cette période.
• La livraison du logiciel peut prendre plus de temps car les services ne fonctionnent pas simultanément et chaque phase ne peut commencer que lorsque la phase précédente est terminée.

Ce que ça signifie pour la programmation

Le waterfall model est un des processus les plus connus dans le développement logiciel. Il a été utilisé avec succès pendant des décennies, mais aujourd’hui seulement pour les petits projets pour lesquels les spécifications sont claires. Les inconvénients mentionnés ci-dessus, cependant, ont également conduit les analystes et les développeurs à concevoir des modèles alternatifs appelés développement logiciel agile. Le problème principal du modèle en cascade est que les modifications et les révisions ne sont pas forcément prévues par les séquences logiques. Les commentaires des clients, des testeurs et des ingénieurs pendant le développement sont en partie manquants et l’intégration du logiciel dans un système déjà existant peut être compliquée ou tumultueuse. Ces inconvénients peuvent être évités en modifiant les phases du projet, comme c’est souvent le cas avec le modèle en spirale. Mais depuis quelques années, les méthodes agiles, qui utilisent d’autres éléments structurels, sont beaucoup plus populaires, notamment avec les rôles dans le scrum ou les principes de programmation extrême. En règle générale, elles sont plus économiques, conduisent à des résultats plus rapidement et sont plus transparentes pour les clients.

Liens web

• Le modèle en cascade, cycledeveloppementdunlogiciel.wordpress.com
• Les différents cycles de développement en informatique, responsive-mind.fr, 02.03.2015