Cycle en V

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Wikilivres possède un ou plusieurs livres sur Programmation Cycle en V.
Les phases du cycle en V

Le modèle du cycle en V (en comparaison avec les méthodes dites Agile) est un modèle conceptuel de gestion de projet imaginé suite au 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.

Le cycle en V est devenu un standard de l'industrie logicielle depuis les années 1980 et 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
de Validation
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
de Validation
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. C'est la fameuse différence entre la théorie et la pratique : en théorie il n'y en a pas !

En pratique, il est difficile voire impossible de totalement détacher la phase de conception d'un projet de sa phase de réalisation. C'est souvent au cours de l'implémentation qu'on se rend compte 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). 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. La problématique des projets longue durée qui sont adaptés sur ce mode de gestion de projet est aussi souvent qu'ils 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 implémentation ou série d'implémentations. Voir par exemple à ce sujet : Développement rapide d'applications ou Méthode agile de gestion de projet.

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 de 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.

Articles connexes[modifier | modifier le code]