Les différents cycles de développement en informatique

Cycle itératif

En cascade, en V , itératif… tout le monde connait le nom de ces modèles de cycle de développement, mais savez-vous comment ils fonctionnent ?

Cet article sera un peu encyclopédique, il a pour but de montrer les grandes lignes, les forces et les faiblesses de ces différentes façons de s’organiser qui ont été mises en place depuis près de 50 ans maintenant. Bien sûr, chaque modèle pourrait mériter un article, voire un livre, mais je vous propose de commencer par cette piqûre de rappel, souvent nécessaire, que vous soyez code guru, chef de projet ou même client.

separateur

Cycle en cascade

Présenté par Winston W. Royce en 1970, le modèle en cascade originel est hérité du BTP. Il se base sur 2 idées fondamentales :

  • Une étape ne peut pas être débutée avant que la précédente ne soit achevée : inutile de monter les murs tant que les fondations ne sont pas coulées (ça arrive parfois mais nous ne sommes pas dans une émission de défense des droits du consommateur…) ;
  • La modification d’une étape du projet a un impact important sur les étapes suivantes.

Ce modèle comporte 7 phases : analyse des besoins, spécifications, conception de l’architecture, conception détaillée, implémentation, tests (validation) et enfin installation. Chacune de ces phases doit produire un ou plusieurs livrables définis à l’avance et a une date d’échéance fixée. On ne peut passer d’une étape à l’autre que lorsque les livrables de l’étape en cours sont jugés satisfaisants. Si tout se passe bien on passe à la phase suivante, sinon on remonte à la phase précédente, voire même en début de cycle si une anomalie critique est détectée.

Cycle en cascade

Cycle en cascade

Avantages du modèle en cascade : Le planning est établi à l’avance et le maître d’ouvrage sait précisément ce qui va lui être livré et quand il pourra en prendre livraison

Inconvénients du modèle en cascade : ils sont assez nombreux mais le principal inconvénient est la très faible tolérance à l’erreur (les anomalies sont détectées tardivement) qui induit automatiquement un coût important en cas d’anomalie.

Ce modèle a été présenté il y a plus de 40 ans comme étant imparfait et depuis, un grand travail a été fait pour trouver des modèles plus performants et plus robustes, c’est pourquoi je vous invite à ne pas l’utiliser, mais simplement à le comprendre et à l’accepter comme une base de départ. Je vous invite aussi à lire cet article du JDN qui est un bon plaidoyer pour l’abandon du cycle en cascade.

separateur

Cycle en V

Face aux problèmes de réactivité que pose l’approche en cascade, l’industrie informatique a adopté le cycle en v dans les années 80. Ce modèle ne se découpe plus en 7 mais en 9 phases qui se répondent 2 à 2 : à chaque étape de conception correspond une phase de test ou de validation, comme vous pouvez le voir ci-dessous.

Cycle en V

Cycle en V

Nos neufs phases du cycle en V sont arrivent donc comme ceci :

  • Etude et analyse : l’analyse ou la définition des besoins, la rédaction des spécifications, la conception architecturale, la conception détaillées
  • Codage : développement de l’application
  • Tests et validations : tests unitaires, test d’intégration, tests de validation et maintenance corrective. En tant que lecteurs assidus vous aurez bien sur reconnu dans ces phases de tests les étapes que je vous ai présentées lorsque nous parlions de recette il y a quelques mois.

Sur le schéma ci-dessus vous aurez constaté la présence de deux axes : le temps et le détail, c’est à cela qu’est dû l’appellation en V du cycle : plus on avance dans l’étude plus le niveau de détail est précis, ensuite on code, et plus on avance dans les tests moins le niveau de détails est précis.

Avantages du modèle en V : La stricte structure en V permet d’espérer que le livrable final sera parfait, puisque les étapes de test sont aussi nombreuses que les étapes de réflexion. De plus, il est facile de prévoir les tests à réaliser au moment où l’on conçoit une fonctionnalité ou une interface, le travail s’enchaîne donc de façon assez naturelle.

Inconvénients du modèle en V : Malheureusement ce modèle est rarement utilisé tel quel et le V est bien souvent déséquilibré, tantôt côté analyse, tantôt côté recette et la marge d’erreur est bien souvent proportionnelle à la marge de liberté prise par rapport au modèle théorique. Même si notre V de base diffère un peu, je vous invite à lire cet article qui explique bien les pourquoi et les comment de ces déséquilibres.

separateur

Cycle en spirale

Défini par Barry Boehm en 1988 dans son article “A Spiral Model of Software Development and Enhancement”, le cycle en spirale reprend les étapes du cycle en V, mais prévoit l’implémentation de versions successives, ce qui permet de mettre l’accent sur la gestion des risques, la première phase de chaque itération étant dédiée à ce poste. A ce point il est nécessaire de définir la notion de prototype. En effet, on ne fait pas des versions successives d’un même produit fini, corriger une liste de bugs permet de passer de la béta à la finale mais pas de la v1 à la v2… Le cycle en spirale prévoit donc la livraison de prototypes, c’est à dire de versions incomplètes du produit. Il peut s’agir d’une simple maquette ou même des wireframes sans aucune fonctionnalité (on parle alors de prototype horizontal) ou bien de sites partiellement fonctionnels : telle version implémentera la navigation de base, la suivante ajoutera l’espace membres, puis la zone de téléchargements… on parlera alors de prototype vertical.

Cycle en spirale

Cycle en spirale

Avantages du modèle en spirale : Le but premier de ce modèle étant la gestion des risques, ceux-ci sont logiquement limités. L’expertise du client croit à chaque itération du cycle, l’apprentissage se fait par touche et pas d’un seul bloc. Enfin, ce modèle est très adaptatif : si chaque prototype apporte des fonctionnalités indépendantes, il est possible de changer l’ordre de livraison des versions.

Inconvénients du modèle en spirale : Selon moi le principal défaut du cycle en spirale c’est qu’il n’est adapté qu’aux projets suffisamment gros, inutile de prévoir la livraison de 5 ou 6 prototypes pour un site vitrine sous WordPress (même si on peut considérer qu’une maquette puis le site en lui-même constituent 2 cycles complets). De plus l’évaluation des risques en elle-même et la stricte application du cycle de développement peut engendrer plus de coûts que la réalisation du logiciel. Enfin, ce type de cycle de développement est complexe, entre les étapes prévues en théorie et celles mises en pratique il y a une grande différence.

separateur

Cycle itératif

Simplifions un peu le modèle précédent en réduisant le nombre d’étapes du cycle et séparons les activités des artéfacts (c’est à dire les produits issus de ces activités). Nous arrivons logiquement au modèle itératif, que vous pouvez voir ci-dessous.

Cycle itératif

Cycle itératif

Tout commence par l’expression de besoin : le client explique ce qu’il veut, tout en sachant que ces besoins peuvent être modifiés par la suite du processus. Ensuite, on se lance dans le processus itératif en lui-même avec la rédaction des spécifications qui est suivie par le développement, puis la validation (c’est à dire les tests) et enfin une évaluation du travail qui servira d’information de départ pour le cycle suivant en dressant le bilan des difficultés rencontrées et des fonctionnalités abandonnées pendant le cycle. A l’issue de la validation on passe aussi au déploiement : les livrables (il peut s’agir d”une version du site ou logiciel, ou même d’une documentation) qui ont été validés sont déployés, c’est à dire mis à disposition.

Avantages du modèle itératif : Ce type de cycle de développement est le plus souple de tous ceux présentés ici : chaque itération permet de s’adapter à ce qui a été appris dans les itérations précédentes et le projet fini peut varier du besoin qui a été exprimé à l’origine. Comme dans le cycle en spirale, la mise à disposition de livrables à chaque cycle permet un apprentissage de l’utilisateur final en douceur.

Inconvénients du modèle itératif : A mes yeux le plus gros piège de ce modèle de développement c’est la confiance qui amène bien souvent à négliger les test d’intégration. Ainsi les développeurs livrent une nouvelle fonctionnalité sans se rendre compte qu’ils ont cassé une chose qui fonctionnait dans les cycles précédents. Il faut donc que le chef de projet soit particulièrement vigilant lors de la phase de tests.

separateur

 Cycle Agile

Eh non le développement Agile n’est pas une question de cycle, c’est surtout une question de philosophie, de culture, qui place la réactivité et l’implication du client en priorité. En fait les méthodes Agile se basent sur un modèle semi-itératif qui peut être défini soit par la structure du projet (modèle Top-Down), soit par les besoins exprimés (modèle Bottom-Up). Il serait inutile de tenter de définir le développement Agile en quelques mots alors sachez que je travaille à la rédaction d’un article qui y sera entièrement consacré dans les semaines à venir.

separateur

Comme je vous le disais en introduction le sujet est très vaste et chaque modèle de cycle de développement pourrait se voir consacrer des ouvrages entiers, entre la théorie pure (je pourrais même dire les théories puisque d’une source à l’autre les modèles varient un peu) et les innombrables mises en pratique et c’est d’ailleurs le moment pour vous ne nous parler de vos propres adaptations de ces modèles : le ou lesquels utilisez vous le plus souvent ? Sous quelle forme exactement ? La parole est à vous !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *