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.

Les phases du cycle en V

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

Historique

Issu du monde de l'industrie, le cycle en V est devenu un standard de fait l'industrie du logiciel depuis les années 1980[2],[3]. Depuis, avec l'apparition de l'ingénierie des systèmes[4], c'est devenu un standard conceptuel dans de nombreux domaines de l'Industrie.

Ce modèle s'est établi comme 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és aux systèmes complexes faits de plusieurs composants[5].

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[6]. 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[7] et est encore utilisé aujourd'hui.

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[8]. Depuis 1996 son utilisation devient la règle pour les projets de systèmes d'information de l'état fédéral[9]. 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)[10]. Il a été enrichi pour mieux prendre en charge l'intégration de systèmes et est de plus appuyé par un outil informatique[11]. 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 la gestion de projet et le cycle de vie, avec une répartition des rôles et responsabilités. Il est encore utilisé aujourd'hui.

De nombreux domaines industriels ont depuis adopté le cycle en V dans les pratiques ou normes sectorielles, comme l'aéronautique[12],[13].

Les phases à travers le temps et le niveau de détails

Principes

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[1] :

  • 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[6]. 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[5].

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

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[6]. Pour chaque niveau de complexité supplémentaire, s'ajoute alors un étage dans le V.

Synthèse des étapes
Etapes du cycle en V par niveau de décomposition

Les étapes du modèle sont alors :

  • 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écification fonctionnelle
  • Conception générale[14], aussi appelé conception architecturale[15] ou conception préliminaire[16]: 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[17];
  • Conception détaillée: il s'agit de concevoir chaque composant, et la manière dont ils contribuent à la réponse aux besoins[17];
  • Mise en œuvre[18]: 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[19];
  • 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[7].

Rôles
Cette section ne cite pas suffisamment ses sources (juin 2019). 
Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

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)[20].

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.[réf. nécessaire]
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 Tests
unitaires 		Tests
d'intégration 		Tests fonctionnels Tests d'acceptation (recette)
FonctionnelMOA + AMOA
X
X
SystèmeMOE + MOED + AMOA
X
X
Technique
et Métier		Équipe
Architecturale
X
X
ComposantÉquipe
de Développement
X
X
X

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

Documents par phase
Cette section ne cite pas suffisamment ses sources (juin 2019). 
Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

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

Risques inhérents au cycle en V
Différence entre la théorie (les spécifications) et la pratique (ce qui a été produit).
Cette section ne cite pas suffisamment ses sources (juin 2019). 
Pour l'améliorer, ajoutez des références de qualité et vérifiables (comment faire ?) ou le modèle {{Référence nécessaire}} sur les passages nécessitant une source.

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 logiciel[réf. 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 » dédié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 »). À noter que la société Microsoft pratique ce compromis avec art depuis plusieurs décennies[réf. nécessaire] : 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[21], en particulier pour les systèmes requérant une forte intégration[22]. Il est donc nécessaire de remédier à ces limitations d'une part par une approche interdisciplinaire[23] 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[24] (une idée déjà proposée par Royce en 1970 pour l'approche en cascade[25]). 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[26].

É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.
  • Cycle en V avec prototypage virtuel (1 et 2) et itérations basées sur la mise en œuvre des composants (3) et l'intégration des composants (4).
    des techniques de réduction de risques : on cherche alors à réduire les incertitudes et facteurs d'instabilité aussi tôt que possible dans le cycle. Plusieurs stratégies sont envisageables, par exemple une étude comparative des solutions potentielles en amont, un prototype pour valider les idées de la conception, des itérations pour la production (éventuellement incrémentale) des composants, voire, une phase pilote avant l'acceptation finale. Une approche particulière consiste à recourir pour la conception à des modèles permettant par des simulations à éprouver celle-ci (technique dit du « prototype virtuel »). On obtient ainsi plusieurs itérations de conception avant de passer à la mise en œuvre[27].
  • 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[1].

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[28] et IEC 82304-1 relative aux exigences générales pour la sécurité des logiciels de santé[29]: 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[30],[31].

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[32], 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)[33].

Notes et références
  1. Donald Firesmith, « Carnegie Mellon University - Software Engineering Institute Blogs - Using V Models for Testing », sur insights.sei.cmu.edu,
  2. Nicolas Desmoulins, Maîtriser le levier informatique : accroître la valeur ajoutée des systèmes d'information, Pearson Education France, (lire en ligne)
  3. (en) B.W. Boehm, « Verifying and Validating Software Requirements and Design Specifications », IEEE Software, vol. 1, no 1,‎ , p. 75–88 (ISSN 0740-7459, DOI 10.1109/ms.1984.233702, lire en ligne, consulté le )
  4. (en) Martin Eigner, Thomas Dickopf et Hristo Apostolov, « The Evolution of the V-Model: From VDI 2206 to a System Engineering Based Approach for Developing Cybertronic Systems », Product Lifecycle Management and the Industry of the Future, Springer International Publishing, iFIP Advances in Information and Communication Technology,‎ , p. 382–393 (ISBN 9783319729053, DOI 10.1007/978-3-319-72905-3_34, lire en ligne, consulté le )
  5. (en) Alan M. Davis, « A Comparison of Techniques for the Specification of External System Behavior », Commun. ACM, vol. 31, no 9,‎ , p. 1098–1115 (ISSN 0001-0782, DOI 10.1145/48529.48534, lire en ligne, consulté le )
  6. (en) Kevin Forsberg et Harold Mooz, « The Relationship of System Engineering to the Project Cycle », INCOSE International Symposium, vol. 1, no 1,‎ , p. 57–65 (ISSN 2334-5837, DOI 10.1002/j.2334-5837.1991.tb01484.x, lire en ligne, consulté le )
  7. (en) « California Division | Federal Highway Administration | Systems Engineering Guidebook for ITS », sur www.fhwa.dot.gov (consulté le )
  8. (en) Klaus Plögert, « The tailoring process in the German V-Model », Journal of Systems Architecture, special Issue: ESPITI, vol. 42, no 8,‎ , p. 601–609 (ISSN 1383-7621, DOI 10.1016/S1383-7621(96)00047-1, lire en ligne, consulté le )
  9. (de) « V-Modell », sur Projektmagazin (consulté le )
  10. (de) « IT-Beauftragter der Bundesregierung | V-Modell XT », sur www.cio.bund.de (consulté le )
  11. (de) Manfred Broy et Andreas Rausch, « Das neue V-Modell® XT: Ein anpassbares Modell für Software und System Engineering », Informatik-Spektrum, vol. 28, no 3,‎ , p. 220–229 (ISSN 0170-6012 et 1432-122X, DOI 10.1007/s00287-005-0488-z, lire en ligne, consulté le )
  12. « ARP4754A: Guidelines for Development of Civil Aircraft and Systems - SAE International », sur www.sae.org (consulté le )
  13. (en) « (PDF) Towards a Classification Schema for Development Technologies: an Empirical Study in the Avionic Domain », sur ResearchGate (consulté le )
  14. « La conception générale du logiciel - Bivi - Qualite », sur bivi.afnor.org (consulté le )
  15. « IATE - Fiche de terminoologie - Conception générale », sur iate.europa.eu
  16. « conception préliminaire », sur www.granddictionnaire.com (consulté le )
  17. (en-US) « Software Engineering Body of Knowledge (SWEBOK) | IEEE Computer Society » (consulté le )
  18. « mise en œuvre », sur www.granddictionnaire.com (consulté le )
  19. « Glossaire des termes utilisés en tests de logiciels » [PDF]
  20. Yanis Okba, La recette fonctionnelle d’un système d’information : enjeux, méthodes, outils et exemple d’application, dumas-01223463, (lire en ligne)
  21. (en) Jackson, Scott., Systems engineering for commercial aircraft : a domain-specific adaptation, Routledge, (ISBN 978-1-315-61171-6, 1315611716 et 9781317047193, OCLC 948603298, lire en ligne)
  22. (en) Federal Aviation Administration (FAA), Safety Issues with Requirements Definition, Validation, and Verification Processes (draft), (lire en ligne)
  23. (en) Tobias Bruckmann et Julian Hentze, « V-MODELS FOR INTERDISCIPLINARY SYSTEMS ENGINEERING », sur DS 92: Proceedings of the DESIGN 2018 15th International Design Conference, (consulté le )
  24. (en) « (PDF) Systems Engineering and the V-Model: Lessons from an Autonomous Solar Powered Hydrofoil », sur ResearchGate (consulté le )
  25. (en) W. W. Royce, « Managing the Development of Large Software Systems: Concepts and Techniques », Proceedings of the 9th International Conference on Software Engineering, IEEE Computer Society Press, iCSE '87,‎ , p. 328–338 (ISBN 9780897912167, lire en ligne, consulté le )
  26. S. M. Mitchell et C. B. Seaman, « A comparison of software cost, duration, and quality for waterfall vs. iterative and incremental development: A systematic review », 2009 3rd International Symposium on Empirical Software Engineering and Measurement,‎ , p. 511–515 (DOI 10.1109/ESEM.2009.5314228, lire en ligne, consulté le )
  27. (en) « (PDF) A Novel Approach on Virtual Systems Prototyping Based on a Validated, Hierarchical, Modular Library », sur ResearchGate (consulté le )
  28. ISO, « IEC 62304:2006 », sur ISO (consulté le )
  29. ISO, « IEC 82304-1:2016 », sur ISO (consulté le )
  30. Auteur Guillaume Promé Membre AFNOR S95B et Iso/Tc 210/Wg 1, « IEC 82304-1 - Logiciels de santé : Exigences générales pour la sécurité des produits. En bref. », sur Qualitiso, (consulté le )
  31. (en) Johner Institut, « Software Lifecycle », sur www.johner-institute.com (consulté le ) : « « [these standards] demand from medical device manufacturers to follow these life cycle processes. However, they do not enforce a particular life cycle model » »
  32. (en) « Blending Agile And Waterfall Keys To Successful Implementation », sur www.pmi.org (consulté le )
  33. « A Proposal for an Agile Development Testing V-Model> Business Analyst Community & Resources | Modern Analyst », sur www.modernanalyst.com (consulté le )

Voir aussi

Articles connexes

Sites externes
  • Portail de l’informatique
  • Portail du management
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.