Français
Menu

Modèle en cascade vs développement agile : déroulement, planification, changements, tests, projets adaptés

Le modèle en cascade est un modèle de développement qui enchaîne la définition des exigences, la conception, la programmation et les tests dans l’ordre, de l’amont vers l’aval, et ne passe en principe à la phase suivante qu’une fois les livrables de la phase précédente arrêtés. Comme le plan d’ensemble est fixé au départ, l’avancement et les coûts sont faciles à maîtriser, mais les erreurs d’exigences découvertes dans les phases tardives entraînent beaucoup de reprises. Le développement agile est un terme générique pour des approches qui répètent de courtes itérations de quelques semaines, produisent à chaque fois un logiciel qui fonctionne, intègrent les retours des utilisateurs et révisent le plan quand les exigences changent ; Scrum et l’extreme programming (XP) en sont des méthodes typiques. La cascade convient quand les exigences sont claires et stables, l’agilité quand elles changent facilement et qu’on veut livrer tôt des fonctions utilisables.

CritèreModèle en cascadeDéveloppement agile
Enchaînement des phasesExigences → conception → programmation → tests, chacune une seule fois, dans l’ordre depuis l’amontDe courtes itérations (les sprints de Scrum) comprenant planification, conception, implémentation et tests, répétées de nombreuses fois
PlanificationLe périmètre, le calendrier et le coût de tout le projet sont fixés au départ, et le travail suit ce planOn fixe une orientation générale, et le plan est révisé à chaque itération, en commençant par les éléments les plus prioritaires
Changements d’exigencesUn changement après l’arrêt des livrables de la phase précédente entraîne beaucoup de reprises et passe par une procédure de gestion des modificationsLe changement est attendu et s’intègre facilement au plan de l’itération suivante
Moment où un logiciel fonctionneSurtout vers la fin du développement ; livré d’un bloc après les testsChaque itération produit un logiciel qui fonctionne (un incrément, dans Scrum)
Moment des testsAprès la programmation : tests unitaires, d’intégration, système et de recette dans l’ordre (associés aux phases de conception dans le cycle en V)À chaque itération ; les changements sont souvent vérifiés à chaque fois par des tests automatisés et l’intégration continue
DocumentationLes spécifications des exigences, documents de conception, etc. sont rédigés pour chaque phase et arrêtés après revueLe logiciel qui fonctionne prime, et la documentation se limite souvent au nécessaire
Implication du clientSurtout lors de la définition initiale des exigences et de la recette finaleExamine le produit à chaque itération et donne son avis ; dans Scrum, le product owner fixe les priorités de ce qu’il faut développer
Suivi de l’avancementMesuré par les phases et livrables terminés ; facile à gérer avec une WBS et des diagrammes de GanttMesuré à chaque itération par les fonctions terminées et opérationnelles
Projets adaptésExigences claires et stables ; spécifications à figer tôt en même temps que le matériel ; contrats qui doivent fixer d’avance le périmètre et le coûtExigences susceptibles de changer, ou nouveaux services dont on veut vérifier l’accueil par les utilisateurs pendant le développement

Les valeurs indiquées sont des ordres de grandeur typiques et varient selon la génération de procédé et le produit.

Quand choisir l'un ou l'autre ?

Modèle en cascade
Lorsque les exigences sont claires dès le départ et peu susceptibles de changer, lorsque de nombreuses organisations sont impliquées et que des validations et des documents sont exigés à chaque phase, ou lorsque, comme pour les systèmes embarqués, la spécification doit être figée tôt pour s’accorder au matériel.
Développement agile
Lorsqu’on ne sait pas au départ ce qui aidera vraiment les utilisateurs, lorsqu’on veut modifier les priorités au gré du marché et des exigences, ou lorsqu’on veut livrer tôt des fonctions utilisables, même petit à petit. Cela suppose que les utilisateurs ou le client restent impliqués tout au long du développement.

Questions fréquentes

Le développement agile se passe-t-il de plans et de documents de conception ?

Non. Le développement agile planifie bel et bien ; au lieu de tout fixer en détail au départ, il révise le plan à chaque itération. Dans Scrum, la planification de sprint, au début de chaque sprint, décide de ce qui sera développé pendant ce sprint. Les documents nécessaires sont aussi rédigés.

Qu’est-ce que le Manifeste pour le développement agile de logiciels ?

Une déclaration des idées qui sous-tendent le développement agile, rédigée en 2001 par un groupe de développeurs de logiciels. Elle énonce quatre valeurs : les individus et leurs interactions plutôt que les processus et les outils, des logiciels opérationnels plutôt qu’une documentation exhaustive, la collaboration avec les clients plutôt que la négociation contractuelle, et l’adaptation au changement plutôt que le suivi d’un plan. Elle est formulée de façon à dire que, si les éléments de droite ont de la valeur, ceux de gauche en ont davantage.

En quoi Scrum et le développement agile diffèrent-ils ?

Le développement agile est un terme générique pour les idées et approches qui développent un logiciel par courtes itérations tout en s’adaptant au changement. Scrum est l’un des cadres typiques pour le mettre en pratique ; il définit trois rôles (product owner, Scrum master et développeurs) et des événements organisés au sein de sprints de durée fixe, d’un mois au plus.

Combine-t-on parfois cascade et agilité ?

Oui. Par exemple, on fixe d’abord les exigences d’ensemble et la conception générale, puis l’implémentation et les tests se déroulent par courtes itérations. Dans la tradition de la cascade aussi, on emploie depuis longtemps des techniques pour limiter les reprises, comme le prototypage pour confirmer les exigences et le modèle en spirale, qui répète les phases plusieurs fois.

Vérifier vos connaissances

Quelle est une caractéristique du modèle en cascade de développement logiciel ?

  1. ALes phases comme la définition des exigences, la conception, l'implémentation et les tests sont menées dans l'ordre, de l'amont vers l'aval, et en principe la phase suivante ne commence qu'une fois les livrables de la phase précédente arrêtés
  2. BOn répète de courtes itérations, chacune produisant un logiciel qui fonctionne et intégrant les retours des utilisateurs
  3. COn construit d'abord un prototype que l'on montre aux utilisateurs pour confirmer leurs exigences avant de lancer le développement proprement dit
Afficher la réponse et l'explication

Réponse : A. Les phases comme la définition des exigences, la conception, l'implémentation et les tests sont menées dans l'ordre, de l'amont vers l'aval, et en principe la phase suivante ne commence qu'une fois les livrables de la phase précédente arrêtés

Le modèle en cascade est un modèle de développement dans lequel les phases s'enchaînent dans l'ordre définition des exigences, conception, programmation et tests, comme de l'eau qui descend une pente. Comme les livrables de chaque phase sont arrêtés au moyen de revues, il est facile de planifier et de suivre l'avancement, mais une erreur dans les exigences découverte dans une phase ultérieure entraîne beaucoup de reprises. On l'utilise quand les exigences sont claires et peu susceptibles de changer, ou quand la spécification doit être figée tôt en même temps que le matériel. Intégrer les retours des utilisateurs par itérations est une caractéristique des approches itératives comme le développement agile, et confirmer les exigences avec un prototype est une caractéristique du modèle par prototypage.

Dans le cycle en V du développement logiciel, quel test correspond à la phase de définition des exigences et vérifie que ce qui a été décidé dans cette phase est satisfait ?

  1. ALe test unitaire
  2. BLe test d'intégration
  3. CLe test d'acceptation
Afficher la réponse et l'explication

Réponse : C. Le test d'acceptation

Le cycle en V est un modèle de développement qui place à gauche les phases qui descendent de la définition des exigences à l'implémentation en passant par la conception, place à droite les phases de test qui remontent, et relie chaque paire de phases correspondantes. Le test d'acceptation (test opérationnel) correspond à la définition des exigences, et à mesure que les phases de conception deviennent plus détaillées, le test système, le test d'intégration et le test unitaire leur correspondent tour à tour. La correspondance des phases intermédiaires varie légèrement selon les organisations et les manuels, et le test système est parfois aussi rattaché à la définition des exigences, mais tous s'accordent sur le fait que le test d'acceptation, qui vérifie les exigences du point de vue du client ou de l'utilisateur, correspond à la définition des exigences. Le point essentiel de ce modèle est de préparer les plans de test et les critères de réussite au moment de la phase de conception correspondante.

Dans Scrum, quel rôle est responsable du contenu et de l'ordre (la priorité) des éléments du Product Backlog, ainsi que de la maximisation de la valeur du produit ?

  1. ALe Scrum Master
  2. BLe Product Owner
  3. CLes Developers
Afficher la réponse et l'explication

Réponse : B. Le Product Owner

Une Scrum Team se compose de trois rôles : le Product Owner, le Scrum Master et les Developers. Le Product Owner gère le Product Backlog, la liste de ce qu'il faut réaliser, décide quels éléments sont réalisés en premier et est responsable de la maximisation de la valeur du produit. Le Scrum Master diffuse la façon de travailler de Scrum dans l'équipe et l'organisation et aide à lever les obstacles. Les Developers sont les personnes qui créent un Increment qui fonctionne à chaque Sprint.

  1. Dans Scrum, quel événement a lieu à la fin d'un Sprint pour présenter aux parties prenantes l'Increment terminé (le produit qui fonctionne), recueillir leurs retours et ajuster l'orientation future et le Product Backlog ?
  2. Dans les méthodes de développement agile comme l'Extreme Programming (XP), comment s'appelle l'activité qui réorganise la structure interne d'un programme pour la rendre plus facile à comprendre et à modifier, sans changer son comportement visible de l'extérieur ?
  3. Quelle description de l'intégration continue (CI) est correcte ?

Questions d'entraînement sur Développement logiciel et gestion de projet

Termes clés expliqués

Modèle en cascade (waterfall)
Modèle de développement logiciel dans lequel les phases comme la définition des exigences, la conception, la programmation et les tests sont menées dans l'ordre, de l'amont vers l'aval, la phase suivante ne commençant en principe qu'une fois les livrables de la phase précédente arrêtés. La planification et l'avancement sont faciles à maîtriser, mais une erreur dans les exigences découverte dans une phase ultérieure entraîne beaucoup de reprises.
Développement agile
Terme général désignant les façons de développer des logiciels qui répètent de courtes itérations de quelques semaines, produisent à chaque fois un logiciel qui fonctionne, intègrent les retours des utilisateurs et révisent le plan pour suivre l'évolution des exigences. Les méthodes représentatives sont Scrum et l'Extreme Programming (XP).
Scrum
Cadre de travail représentatif du développement agile. Avec trois rôles, le Product Owner, le Scrum Master et les Developers, et des événements tenus au sein de Sprints de durée fixe d'un mois au plus (Sprint Planning, Daily Scrum, Sprint Review et Sprint Retrospective), on construit petit à petit un produit qui fonctionne.
Cycle en V (modèle en V)
Modèle de développement qui dispose en forme de V les phases qui descendent de la définition des exigences à l'implémentation en passant par la conception, et les phases de test qui remontent du test unitaire au test d'acceptation, et qui associe les deux côtés : définition des exigences et test d'acceptation, conception et tests d'intégration et système, conception des modules et test unitaire, etc. L'association entre phases de conception et tests varie légèrement selon les organisations et les manuels.
Développement piloté par les tests (TDD)
Façon de développer des logiciels selon un cycle court et répété : on écrit d'abord un test pour la fonctionnalité à réaliser, puis le code minimal pour faire passer ce test, puis on refactorise en gardant les tests au vert. Elle s'est répandue comme pratique de l'Extreme Programming (XP).
CI/CD (intégration continue et livraison continue)
Nom regroupant l'intégration continue (CI), dans laquelle les développeurs fusionnent fréquemment leurs modifications dans une branche partagée et chaque fusion déclenche une compilation et des tests automatisés, et la livraison continue (CD), qui maintient les modifications testées prêtes à être mises en production à tout moment. Quand la mise en production elle-même est aussi automatisée, on parle de déploiement continu.
WBS (structure de découpage du projet)
Arborescence qui décompose, du niveau supérieur vers les niveaux inférieurs, les livrables d'un projet et le travail nécessaire pour les produire. Les éléments du niveau le plus bas s'appellent lots de travail (work packages) et sont les unités d'estimation, de planification, d'affectation des personnes et de suivi de l'avancement.

Comparatifs associés