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.

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é

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

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

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

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.