- Cycle en V
-
Le modèle du cycle en V 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 étapes :
- Analyse des besoins et faisabilité
- Spécification logicielle
- Conception architecturale
- Conception détaillée
- Codage
- Test unitaire
- Test d'intégration
- Test de validation (Recette Usine, Validation Usine - VAU)
- Recette (Vérification d'Aptitude au Bon Fonctionnement - VABF)
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.
Sommaire
Rôles
Dans le contexte des projets de grande envergure ont émergé des rôles pour partager et désigner les responsabilités :
- Maîtrise d'ouvrage (MOA) qui regroupe les fonctions suivantes :
- le maître d’ouvrage stratégique (MOAS) ;
- le maître d’ouvrage délégué (MOAD) ;
- le maître d’ouvrage opérationnel (MOAO) ;
- l’assistant à maîtrise d’ouvrage (AMOA ou AMO) ;
- l’expert métier ;
- enfin l’utilisateur, au service duquel se trouvent toutes les autres fonctions.
- Maîtrise d'œuvre (MOE)
- Maîtrise d'œuvre déléguée (MOED)
- l'Equipe Architecturale
- l'Equipe de développement
- Titulaire de marché
Répartition des rôles en fonction des étapes Niveau de
DétailRôles Besoins
et FaisabilitéSpécification Conception
ArchitecturaleConception
DétailléeCodage Test
unitaireTest
d'intégrationTest
de ValidationRecette Système MOA + AMOA X X Fonctionnel MOE + MOED X X Technique
et MétierEquipe
ArchitecturaleX X Composant Equipe
de DéveloppementX X X On retrouve dans ce découpage le V, d'où le nom de ce modèle.
Documents par phase
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
ArchitecturaleConception
DétailléeCodage Test
unitaireTest
d'intégrationTest
de ValidationRecette Spécification des Besoins Utilisateur
Cahier des chargesRapport de Recette Spécifications Générales
Spécification Technique des BesoinsProcès Verbal de Validation Dossier de Définition du Logiciel
Dossier d'Architecture Technique
Plan de TestsRapport de Tests d'Intégration Rapport de Conception Détaillée Rapport de Tests Unitaires Code source Risques inhérents au Cycle en V
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 suite à 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
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.Voir aussi
Liens internes
Liens externes
Catégories :- Gestion de projet
- Développement logiciel
- Méthode de développement logiciel
Wikimedia Foundation. 2010.