Cycle en V

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Les phases du cycle en V

Le modèle du cycle en V (en comparaison avec les méthodes dites agiles) est un modèle conceptuel de gestion de projet imaginé à la suite du problème de réactivité du modèle en cascade. Il permet, en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des défauts sont détectés, afin d'améliorer le logiciel.

Issu du monde de l'industrie, le cycle en V est devenu un standard de l'industrie logicielle depuis les années 1980[1]. Depuis, l'apparition de l'ingénierie des systèmes est devenu un standard conceptuel dans tous les domaines de l'Industrie. Le monde du logiciel ayant de fait pris un peu d'avance en termes de maturité, on trouvera dans la bibliographie courante souvent des références au monde du logiciel qui pourront s'appliquer au système.

Les phases à travers le temps et le niveau de détails

Les étapes :

Une des différences entre la recette usine et la recette finale est essentiellement contractuelle. Aussi, il n'est pas rare que le MOA (maître d'ouvrage) délègue la validation auprès d'un organisme de validation, cet organisme étant bien souvent constitué d'experts afin de diminuer les erreurs de validation.

Rôles[modifier | modifier le code]

Dans le contexte des projets de grande envergure ont émergé des rôles pour partager et désigner les responsabilités :

Répartition des rôles en fonction des étapes
Niveau de
Détail
Rôles Besoins
et Faisabilité
Spécification Conception
Architecturale
Conception
Détaillée
Codage Test
unitaire
Test
d'intégration
Test fonctionnel Test d'acceptation (recette)
Système MOA + AMOA
X
X
Fonctionnel MOE + MOED
X
X
Technique
et Métier
Équipe
Architecturale
X
X
Composant Équipe
de Développement
X
X
X

On retrouve dans ce découpage le V, d'où le nom de ce modèle.

Documents par phase[modifier | modifier le code]

Pour une bonne communication entre les différents partenaires du projet, il est nécessaire d'établir des documents de référence.

Documents en fonction des étapes
Besoins
et Faisabilité
Spécification Conception
Architecturale
Conception
Détaillée
Codage Test
unitaire
Test
d'intégration
Test fonctionnel Test d'acceptation (Recette)
Spécification des Besoins Utilisateur
Cahier des charges
Rapport de Recette
Spécifications Générales
Spécification Technique des Besoins
Procès Verbal de Validation
Dossier de Définition du Logiciel
Dossier d'Architecture Technique
Plan de Tests
Rapport de Tests d'Intégration
Rapport de Conception Détaillée Rapport de Tests Unitaires
Code source

Risques inhérents au Cycle en V[modifier | modifier le code]

Différence entre la théorie (les spécifications) et la pratique (ce qui a été produit).

Une fois l'ensemble des besoins capturés et les spécifications établies, il arrive que dès le niveau de l'architecture, voire en phase de conception détaillée ou de codage, des difficultés d'ordre de cohérence, technique et humain interviennent.

En pratique, il est difficile voire impossible de totalement détacher la phase de conception d'un projet de sa phase de réalisation. On se rend compte souvent au cours de la mise en œuvre que les spécifications initiales étaient incomplètes, fausses, ou irréalisables, sans compter les ajouts de nouvelles fonctionnalités par les clients (scope creep (en)). Lire à ce sujet Le Mythe du mois-homme. C'est principalement pour cette raison que le Cycle en V n'est pas toujours adapté à un développement logiciel. Si les projets longue durée sont adaptés à ce mode de gestion de projet, ce sont également souvent eux qui risquent de ne plus « coller » aux besoins qui évoluent dans le temps.

D'autres modèles permettent plus facilement des modifications (parfois radicales) de la conception initiale à la suite d'une première mise en œuvre ou série de mises en œuvre. Voir par exemple à ce sujet : Développement rapide d'applications ou Méthode agile de gestion de projet. Par contre, ces méthodes manquent parfois de traçabilité ce qui nécessite d'impliquer le client à la fois en termes de conception et également en termes juridiques : avec un cycle en V, le client est censé recevoir ce qu'il a commandé alors qu'avec des méthodes « agiles », le client devient co-développeur et intervient donc au niveau du projet. Cette nuance peut avoir une importance en cas de désaccord entre le client et l'exécutant, notamment si le désaccord est porté devant un tribunal.

Un compromis consiste à appliquer un cycle en V le plus court possible et à faire évoluer le projet sous forme de versions, prenant ainsi en compte le fait que le projet ne sera pas parfait et qu'il sera amélioré au fil des versions. Cela permet également de bénéficier du retour d'expérience des versions précédentes. Ce compromis est particulièrement formateur au sein d'un projet, pour les équipes des phases « amont » dédiées à l'étude du besoin, aux spécifications et à la conception (la « théorie »), qui seront ainsi confrontées aux résultats concrets (la « pratique »). À noter que la société Microsoft pratique ce compromis avec art depuis plusieurs décennies[réf. nécessaire] : maîtriser la traçabilité et les délais à l'aide d'une succession de cycle en V les plus courts possibles, quitte à diffuser ultérieurement les mises à jour… Par exemple tous les systèmes d'exploitation Microsoft depuis Windows 2000).

Comité de pilotage[modifier | modifier le code]

Pour améliorer le suivi du projet sur le plan de l'observation et des choix à effectuer, il se constitue généralement une équipe transversale au projet : le comité de pilotage. Ce comité de pilotage est généralement constitué d'un membre de chaque catégorie de rôle. Ce comité joue en quelque sorte le rôle de gaine de protection autour du V. Ce comité analyse les métriques issues des activités de chaque phase afin de réaliser la jonction entre la MOE et la MOA.

Notes et références[modifier | modifier le code]

  1. Nicolas Desmoulins, Maîtriser le levier informatique : accroître la valeur ajoutée des systèmes d'information, Pearson Education France, (lire en ligne)
  2. « Glossaire des termes utilisés en tests de logiciels » [PDF]

Articles connexes[modifier | modifier le code]

Sur les autres projets Wikimedia :