Le cycle en V (« V model » ou « Vee model » en anglais) est un modèle d'organisation des activités de développement d'un produit 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<ref name=":0">Modèle:Lien web</ref>.
Issu de l'ingénierie système, 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<ref>Modèle:Ouvrage</ref>. Le cycle en V n'est donc pas un cycle de projet.
Ce modèle s'est établi comme une alternative plus réaliste au modèle en cascade, en raison de sa prise en compte d'étapes supplémentaires lors de la validation pour distinguer les tests unitaires, les tests d'intégration et les tests systèmes, ce qui s'avère plus adapté aux systèmes complexes faits de plusieurs composants<ref name=":1">Modèle:Article</ref>.
En 1991, sous l'égide du NCOSE (devenu depuis le INCOSE), le gouvernement américain développe le cycle en V pour un programme de satellites nécessitant des systèmes complexes. Le modèle retenu distingue le système, qui peut être composé de plusieurs segments, eux-mêmes composés d'éléments de configuration qui peuvent être matériels, logiciels ou organisationnels<ref name=":2">Modèle:Article</ref>. Les éléments de configuration peuvent eux-mêmes être un assemblage de composants fait de parties plus élémentaires. Le modèle précise en détail une cinquantaine d'étapes (dont certaines suivent des chemins parallèles). Le modèle a depuis été repris par certaines agences de l'état fédéral telles que le Département des Transports<ref name=":4">Modèle:Lien web</ref>.
En 1992, de façon indépendante mais concomitante, les autorités allemandes ont adopté le cycle en V, sous l'appellation « V-Modell », comme référence pour les développements informatiques du ministère de la défense<ref>Modèle:Article</ref>. Depuis 1996 son utilisation devient la règle pour les projets de systèmes d'information de l'état fédéral<ref>Modèle:Lien web</ref>. Il a été remplacé en 2005 par le « V-Modell XT », conçu pour une plus grande flexibilité (le suffixe XT signifiant « eXtreme Tailoring », c'est-à-dire « flexibilité extrême » en anglais)<ref>Modèle:Lien web</ref>. Il a été enrichi pour mieux prendre en charge l'intégration de systèmes et est de plus appuyé par un outil informatique<ref>Modèle:Article</ref>. Ce modèle couvre une dizaine d'étapes pour le cycle en V mais également une dizaine d'activités plus générales. Il est donc conçu comme un cadre de référence intégré pour le développement de produit ou système complexe dans le cadre d'un projet, avec une répartition des rôles et responsabilités.
De nombreux domaines industriels ont depuis adopté le cycle en V dans les pratiques ou normes sectorielles, comme l'aéronautique<ref>Modèle:Lien web</ref>,<ref>Modèle:Lien web</ref>.
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<ref name=":0" /> :
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<ref name=":2" />. 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.
Toutefois, le cycle en V apporte une dimension supplémentaire, qui est celle du système. Le produit du projet est alors considéré comme un « système » fait de plusieurs éléments qui sont des modules ou composants. Ceci requiert dans le flux descendant de distinguer une conception générale du système dans son ensemble, et une conception détaillée de chaque composant. La mise en œuvre se fait alors composant par composant. Dans le flux ascendant, il convient de la même façon d'effectuer des tests unitaires de chaque composant, d'intégrer le système (c'est-à-dire d'assembler ses composants), puis de faire un test d'integration<ref name=":1" />.
Le cycle en V apporte également une plus grande attention sur la vérification et la validation. Les tests unitaires et les tests d'intégration vérifient que les composants et le système fonctionnent conformément à la conception. Le cycle en V enrichit ces étapes avec un test de validation du système, qui confirme non seulement que le système répond à la conception, mais qu'il répond aux exigences<ref name=":0" />.
Le niveau de décomposition n'est pas figé. Certains modèles de cycle en V décomposent les systèmes en sous-systèmes avant de les décomposer en composant<ref name=":2" />. Pour chaque niveau de complexité supplémentaire, s'ajoute alors un étage dans le V.
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.
Conception générale<ref>Modèle:Lien web</ref>, aussi appelé conception architecturale<ref>Modèle:Lien web</ref> ou conception préliminaire<ref>Modèle:Lien web</ref>: 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<ref name=":3">Modèle:Lien web</ref>;
Conception détaillée: il s'agit de concevoir chaque composant, et la manière dont ils contribuent à la réponse aux besoins<ref name=":3" />;
Mise en œuvre<ref>Modèle:Lien web</ref>: il s'agit de réaliser chaque composant nécessaire. Pour les composants et systèmes logiciels, l'activité est essentiellement le codage;
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<ref>Modèle:Lien web</ref>;
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.
Une des différences entre la recette usine et la recette finale est essentiellement contractuelle. Aussi, il n'est pas rare que le 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.
Au niveau de la gestion de projet, les différentes étapes peuvent donner lieu à des phases distinctes sur l'axe horizontal du temps. Plusieurs étapes successives peuvent toutefois être regroupées au sein d'une phase plus large<ref name=":4" />.
Rôles
Modèle:Section à sourcer
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)<ref>Modèle:Ouvrage</ref>.
Dans le contexte des projets de grande envergure ont émergé des rôles pour partager et désigner les responsabilités :
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.Modèle:Référence nécessaire
On retrouve dans ce découpage le V, d'où le nom de ce modèle.
Documents par phase
Modèle:Section à sourcer
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
Tests unitaires
Tests d'intégration
Tests fonctionnels
Tests d'acceptation (Recette)
Spécification des Besoins UtilisateurCahier des charges
Rapport de Recette
Spécifications GénéralesSpécification Technique des Besoins
Procès-verbal de Validation
Dossier de Définition du LogicielDossier d'Architecture TechniquePlan de Tests
Fichier:Theorie-pratique.PNGDifférence entre la théorie (les spécifications) et la pratique (ce qui a été produit).
Modèle:Section à sourcer
Il y a un risque important de se rendre compte au cours de la mise en œuvre que les spécifications initiales étaient incomplètes, fausses, ou irréalisables. Il y a également un risque de voir de nouvelles fonctionnalités requise par les clients (risque de dérive des objectifs), ainsi que d'autres risques évoqués dans l'ouvrage « Le Mythe du mois-homme ». C'est principalement pour cette raison que le cycle en V n'est pas toujours adapté à un développement logicielModèle:Référence nécessaire. Si les projets longue durée sont adaptés à ce mode de gestion de projet, ce sont également souvent eux qui 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 mise en œuvre ou série de mises en œuvre. Voir par exemple à ce sujet : Développement rapide d'applications ou Méthode agile de gestion de projet. Par contre, ces méthodes manquent parfois de traçabilité ce qui nécessite d'impliquer le client à la fois en termes de conception et également en termes juridiques : avec un cycle en V, le client est censé recevoir ce qu'il a commandé alors qu'avec des méthodes « agiles », le client devient co-développeur et intervient donc au niveau du projet. Cette nuance peut avoir une importance en cas de désaccord entre le client et l'exécutant, notamment si le désaccord est porté devant un tribunal.
Un compromis consiste à appliquer un cycle en V le plus court possible et à faire évoluer le projet sous forme de versions, prenant ainsi en compte le fait que le projet ne sera pas parfait et qu'il sera amélioré au fil des versions. Cela permet également de bénéficier du retour d'expérience des versions précédentes. Ce compromis est particulièrement formateur au sein d'un projet, pour les équipes des phases « amont » consacrées à l'étude du besoin, aux spécifications et à la conception (la « théorie »), qui seront ainsi confrontées aux résultats concrets (la « pratique »). Modèle:Refnec : maîtriser la traçabilité et les délais à l'aide d'une succession de cycle en V les plus courts possibles, quitte à diffuser ultérieurement les mises à jour… Par exemple tous les systèmes d'exploitation Microsoft depuis Windows 2000).
Critiques
Le cycle en V est issu du modèle en cascade et en hérite les défauts liés à l'approche séquentielle et linéaire de phases. Ainsi, le cycle de vie dépend d'exigences identifiées en début de projet, qui peuvent être de qualité insuffisante ou instables et avoir un impact sur la qualité et les coûts des phases en aval. On peut également lui reprocher la rigidité qu'engendre la séparation de phases par activité : dans le domaine du logiciel il est ainsi difficile en pratique, voire impossible, de totalement détacher la conception d'un projet de sa réalisation.
Le cycle en V est reconnu pour son approche rigoureuse de développement de produit à partir d'exigences. Mais sa vue séquentielle et linéaire est réductionniste car elle ne tient pas suffisamment compte des interdépendances entre les éléments du système<ref>Modèle:Ouvrage</ref>, en particulier pour les systèmes requérant une forte intégration<ref>Modèle:Ouvrage</ref>. Il est donc nécessaire de remédier à ces limitations d'une part par une approche interdisciplinaire<ref>Modèle:Lien web</ref> de l'architecture, et d'autre part par des pratiques métiers assurant la cohérence des exigences et de la conception à travers les différentes étapes.
Par ailleurs, certains auteurs constatent que dans le domaine de l'ingénierie des systèmes, les itérations sont la règle et non l'exception. Ils suggèrent que la planification devrait en tenir compte, par exemple en prévoyant une étape de prototypage permettant de valider les principes de la conception<ref>Modèle:Lien web</ref> (une idée déjà proposée par Royce en 1970 pour l'approche en cascade<ref name=":02">Modèle:Article</ref>). Cette analyse est confirmée par des études dans le domaine du génie logiciel qui tendent à démontrer des performances supérieures pour les méthodes incrémentales et itératives<ref>Modèle:Article</ref>.
Évolutions
Des évolutions récentes cherchent à remédier à ces critiques par :
une approche incrémentale du cycle en V: La méthodologie « V-Modell XT » adoptée par le gouvernement allemand en 2005, prévoit ainsi la possibilité de choisir, parmi plusieurs stratégies de pilotage de projet, une approche incrémentale. Celle-ci permet alors de concevoir le projet sous forme de succession de projets partiels car la livraison finale ne pouvant se faire qu'après validation.
une variation de cette approche consiste en un double ou un triple V qui prévoit de tester toutes les étapes du flux descendant sur la base de modèles conceptuels<ref name=":0" />.
Une autre évolution consiste à interpréter les activités du modèle en V non plus comme des étapes distinctes strictement séquentielles, mais comme des processus interdépendants. Cette approche est utilisée par exemple dans les normes IEC 62304 relative aux logiciels de dispositifs médicaux<ref>Modèle:Lien web</ref> et IEC 82304-1 relative aux exigences générales pour la sécurité des logiciels de santé<ref>Modèle:Lien web</ref>: celles-ci sont souvent comprise comme imposant le cycle en V, alors qu'elles ne font qu'imposer des exigences de processus sans en fixer la chronologie<ref>Modèle:Lien web</ref>,<ref>Modèle:Lien web</ref>.
Enfin, des praticiens recommandent en outre de combiner le cycle en V avec des pratiques agiles (par exemple: exprimer les exigences sous forme de récit utilisateur<ref>Modèle:Lien web</ref>, programmer en binôme ou encore adopter le « TDD », cette dernière pratique pouvant être vue comme une approche de programmation se substituant à la planification des tests prévue dans le cycle en V)<ref>Modèle:Lien web</ref>.
