Cycle en V

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 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 :

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

[modifier] 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é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	Equipe Architecturale			X				X
Composant	Equipe de Développement				X	X	X

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

[modifier] 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 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 Test				Rapport de Tests d'Intégration
			Rapport de Conception Détaillée		Rapport de Tests Unitaires
				Code source

[modifier] Risques inhérents au Cycle en V

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 n'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.

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.

[modifier] 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.