Cycle en V

Le cycle en V (« V model » ou « Vee model » en anglais) est un modèle d’organisation des activités d’un projet qui se caractérise par un flux d’activité descendant qui détaille le produit jusqu’à sa réalisation, et un flux ascendant, qui assemble le produit en vérifiant sa qualité. Ce modèle est issu du modèle en cascade dont il reprend l’approche séquentielle et linéaire de phases.

Il l’enrichit cependant d’activités d’intégration de système à partir de composants plus élémentaires, et il met en regard chaque phase de production successive avec sa phase de validation correspondante, lui conférant ainsi la forme d’un V.

Issu de l’ingénierie système (en français : ingénierie des systèmes), le cycle en V est souvent considéré comme un cycle de projet, alors qu’ingénierie système et gestion de projet sont complémentaires. L’ingénierie système va se focaliser sur le développement du produit, alors que la gestion de projet va se concentrer sur l’atteinte des bénéfices attendus par le client ou l’utilisateur. Le cycle en V n’est donc pas un cycle de projet.

Principe

Vue d’ensemble

De manière simplifiée, le cycle en V comprend les grandes étapes que l’on retrouve, pour la plupart, dans le modèle en cascade:

Une première série d’étapes, le flux descendant, vise à détailler le produit jusqu’à sa réalisation. Il comprend l’expression des besoins, l’analyse, la conception, puis la mise en œuvre. Pour un logiciel, la mise en œuvre correspond essentiellement à la programmation. Pour le matériel c’est la réalisation d’un équipement. Pour des mesures organisationnelles, la mise en œuvre correspond à la rédaction de manuels de procédure.
Une deuxième série d’étapes, le flux ascendant, vise à valider le produit jusqu’à sa « recette », c’est-à-dire son acceptation par le client. Il comprend principalement une série de tests jusqu’à pouvoir valider que le produit répond au besoin et aux exigences.

Flux descendant

Exigences : les exigences font l’objet d’une expression des besoins. Le cas échéant, une étude de faisabilité peut être conduite avant d’engager les travaux;
Analyse : il s’agit, à partir de l’expression de besoin, d’établir le cahier des charges fonctionnel ou les spécifications fonctionnelles;
Conception générale, aussi appelé conception architecturale ou conception préliminaire : il s’agit de concevoir le système qui doit répondre aux exigences et de définir son architecture, et en particulier les différents composants nécessaires;
Conception détaillée: il s’agit de concevoir chaque composant, et la manière dont ils contribuent à la réponse aux besoins;

Palier

Mise en œuvre : il s’agit de réaliser chaque composant nécessaire. Pour les composants et systèmes logiciels, l’activité est essentiellement le codage;

Flux ascendant

Test unitaire : il s’agit de vérifier le bon fonctionnement et la conformité de chaque composant à sa conception détaillée;
Intégration et test d’intégration : il s’agit d’assembler le système à partir de tous ses composants, et de vérifier que le système dans son ensemble fonctionne conformément à sa conception générale;
Test système (anciennement « tests fonctionnels ») : vérification que le système est conforme aux exigences;
Test d’acceptation (également appelés « recette » dans le contexte de la sous-traitance) : validation du système par rapport à sa conformité aux besoins exprimés.

Rôles

Le cycle en V définit des étapes sans en définir les rôles ou les responsabilités. Toutefois certaines applications du modèle définissent une répartition des rôles entre l’organisme décideur (maitre d’ouvrage) et le sous-traitant ayant la charge de réaliser le projet (maitre d’œuvre).

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’équipe architecturale
- l’équipe de développement
- Titulaire de marché
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 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.

ND	Rôle	Besoin	Spécification	Conception Architectural	Conception Détaillé	Codage	Tests Unitaires	Tests d’intégration	Tests fonctionnels	Recette
Fonctionnel	MOA + AMOA	X								X
Système	MOE + MOED + AMOA		X						X
Technique & Metier	Équipe Architecturale			X				X
Composant	Équipe de Développement				X	X	X

Documents par phase

Besoin	Spécification	Conception Architectural	Conception Détaillé	Codage	Tests Unitaires	Tests d’intégration	Tests fonctionnels	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