En quoi consiste le cycle en V ?

Le cycle en V ou V model en anglais est un modèle utilisé dans dif­fé­rents processus de dé­ve­lop­pe­ment, notamment dans le dé­ve­lop­pe­ment de logiciels. Élaboré dans les années 90 sous sa forme originale, il est per­fec­tionné au fil des ans et adapté aux méthodes de dé­ve­lop­pe­ment con­tem­po­raines. L’idée de départ remonte cependant aux années 70 et a été imaginée comme une sorte de pro­lon­ge­ment du modèle en cascade.

Outre les dif­fé­rentes phases de dé­ve­lop­pe­ment d’un projet, le cycle en V définit pa­ral­lè­le­ment les démarches af­fé­rentes à mettre en place en termes d’assurance qualité et détaille la façon dont les dif­fé­rentes phases doivent interagir entre elles. Le cycle en V doit son nom à sa forme qui rappelle la lettre V.

Dans un premier temps, le cycle en V définit le dé­rou­le­ment d’un projet en phases dis­tinctes qui sont tour à tour dé­tail­lées :

• En début de projet, le modèle prévoit une analyse de l’ensemble des besoins relatifs au système envisagé.
• Le projet est ensuite enrichi par l’ex­pres­sion des besoins fonc­tion­nels et non fonc­tion­nels liés à l’ar­chi­tec­ture du système.
• Puis on passe à la phase de con­cep­tion du système, lors de laquelle les com­po­sants et les in­ter­faces du système sont planifiés.
• Une fois ces étapes franchies, on peut passer à la con­cep­tion de l’ar­chi­tec­ture lo­gi­cielle en détail.

On entre alors dans la phase effective de dé­ve­lop­pe­ment du logiciel en fonction de ce qui a été planifié. Ensuite ce sont les phases d’assurance qualité, qui se réfèrent toujours aux étapes du dé­ve­lop­pe­ment. Le modèle prévoit les tâches suivantes :

• Tests unitaires ;
• Tests d’in­té­gra­tion ;
• In­té­gra­tion système ;
• La « recette » (ou test d’ac­cep­ta­tion).

La lettre « V » provient du fait que le modèle associe chaque phase de dé­ve­lop­pe­ment avec la phase de va­li­da­tion qui lui cor­res­pond. Le bras gauche du « V » désigne les tâches relatives à la con­cep­tion et au dé­ve­lop­pe­ment du système, le bras droit les mesures d’assurance qualité qui lui sont associées. La phase de mise en œuvre du produit se trouve au centre des deux bras, entre les phases de dé­ve­lop­pe­ment et d'as­su­rance qualité. Dans le cas d’un projet in­for­ma­tique, on parlera plus vo­lon­tiers de pro­gram­ma­tion lo­gi­cielle.

Les tests unitaires per­met­tent de vérifier la bonne mise en œuvre de l’ar­chi­tec­ture lo­gi­cielle prévue. Lors de cette étape, on vérifie si les dif­fé­rents modules du logiciel répondent en tous points aux fonc­tion­na­li­tés requises et s’ils sont bien conformes aux résultats attendus. Dans l’idéal, ces modules de tests devraient être réalisés si possible pa­ral­lè­le­ment à la con­cep­tion, afin d’éviter les erreurs.

La con­cep­tion du système est soumise à des tests d’in­té­gra­tion. Il s’agit ici de vérifier si les dif­fé­rents com­po­sants in­te­ra­gis­sent comme prévu, et si par exemple, tous les processus génèrent les résultats attendus. À ce stade, des résultats non conformes peuvent mettre en avant des problèmes liés à certaines étapes.

Le test système vérifie si l’ensemble des exigences exprimées lors de la con­cep­tion de l’ar­chi­tec­ture système ont été res­pec­tées. En règle générale, les si­mu­la­tions ont lieu dans un en­vi­ron­ne­ment qui reproduit aussi fi­dè­le­ment que possible les si­tua­tions ren­con­trées par le client.

En fin projet, l’analyse des besoins de l’ensemble du système est comparée avec la réception du produit fini. Lors de la réception dé­fi­ni­tive, le client s’assure que ses exigences ont bien été prises en compte durant le fonc­tion­ne­ment. En règle générale, on teste uni­que­ment le fonc­tion­ne­ment du logiciel en surface, autrement dit, on teste ce que le client peut voir au quotidien lorsqu’il utilise son logiciel. On parle ici également de test de recette.

La dernière mo­di­fi­ca­tion du cycle en V date de 2006. L’objectif était de pouvoir intégrer de nouvelles démarches comme le dé­ve­lop­pe­ment agile. Cela a donné naissance à la mé­tho­do­lo­gie « V modell XT ». XT signifie ici « extreme tailoring » (« flexi­bi­lité extrême »). Cette approche explique comment modéliser le modèle sur mesure en fonction des dif­fé­rentes exigences liées au projet.

En con­ti­nuant à dé­ve­lop­per ce système, l’idée de base était de fournir un modèle qui puisse s’adapter fa­ci­le­ment à des projets d’en­ver­gures dif­fé­rentes. En effet, l’ancienne méthode s’est avérée ex­trê­me­ment coûteuse, notamment pour les petits projets et donc inef­fi­cace. Dans le cas de petits projets, le V modell XT permet de supprimer certaines phases qui né­ces­si­te­raient un in­ves­tis­se­ment trop élevé.

De plus, le nouveau modèle intègre des blocs de tâches qui font di­rec­te­ment référence au client. L’ancien modèle se con­ten­tait de faire piloter le projet par le pres­ta­taire avant la réception dé­fi­ni­tive. Le nouveau modèle implique le client de manière beaucoup plus directe.

Le modèle est mis à jour ré­gu­liè­re­ment afin de prendre en compte les nou­veau­tés en termes de processus de dé­ve­lop­pe­ment logiciel et d’améliorer la prise en main. La version 2.3 est la version actuelle du V modell XT.

Le V modell XT est une approche très répandue dans le secteur in­dus­triel. Le recours au cycle en V est presque même devenu la norme pour la plupart des appels d’offres des marchés publics relatifs à des projets in­for­ma­tiques. Par con­sé­quent, c’est un paramètre très important pour les en­tre­prises qui con­çoi­vent des logiciels pour les pouvoirs publics et les mi­nis­tères. Il convient aux projets in­for­ma­tiques de toute taille, que ce soit au niveau des en­tre­prises, de l’armée ou du secteur public. C’est un outil qui permet de faciliter l’or­ga­ni­sa­tion et la réa­li­sa­tion liées au dé­ve­lop­pe­ment, à la main­te­nance et au dé­ve­lop­pe­ment continu des dif­fé­rents systèmes d’in­for­ma­tion.

Le cycle en V peut également être utilisé dans d’autres secteurs de dé­ve­lop­pe­ment, comme par exemple les systèmes élec­tro­niques ou mé­ca­niques dans les domaines de la recherche et des sciences. Pour ces domaines d’ap­pli­ca­tion, il existe des versions lé­gè­re­ment modifiées qui tiennent compte des stades spé­ci­fiques propres à chaque secteur.

Cette démarche est largement répandue, car elle garantit avant tout un degré élevé de trans­pa­rence ainsi que des processus clai­re­ment définis et com­pré­hen­sibles. Vous trouverez ci-après un ré­ca­pi­tu­la­tif des avantages et des éléments de critique les plus im­por­tants.

• Op­ti­mi­sa­tion de la com­mu­ni­ca­tion entre les parties prenantes grâce à des modalités et des res­pon­sa­bi­li­tés clai­re­ment définies.
• Risques maîtrisés et meilleure pla­ni­fi­ca­tion grâce à des fonctions, des struc­tures et des résultats bien définis en amont.
• Amé­lio­ra­tion de la qualité du produit grâce à l’in­té­gra­tion de mesures liées à l’assurance qualité.
• Réduction des coûts grâce à un processus trans­pa­rent de l’ensemble du cycle de vie du produit.

Dans l’ensemble, ce modèle peut permettre d’éviter les ma­len­ten­dus ainsi que les tâches inutiles. De plus, il permet de s’assurer que toutes les tâches soient exécutées en temps voulu, dans le bon ordre en réduisant les temps morts au maximum.

Du point de vue des dé­ve­lop­peurs, cette démarche s’avère souvent trop simpliste, car elle ne reflète pas in­té­gra­le­ment le processus de dé­ve­lop­pe­ment. La gestion de projet occupe une place de plus en plus im­por­tante. En outre, la rigidité relative de la structure ne permet guère de réagir avec souplesse aux mo­di­fi­ca­tions en cours de dé­ve­lop­pe­ment et favorise donc un dé­rou­le­ment re­la­ti­ve­ment linéaire du projet. Pourtant, il est possible de pratiquer la méthode agile avec le cycle en V, si le modèle a bien été compris et est cor­rec­te­ment utilisé.

Il existe dif­fé­rents types d’approches propres au secteur du dé­ve­lop­pe­ment de logiciels qui peuvent convenir en fonction des projets et de la structure des équipes. Le choix des approches est re­la­ti­ve­ment large, même si le modèle en cascade ou le modèle en spirale sont par­ti­cu­liè­re­ment répandus. Le modèle en cascade est par­ti­cu­liè­re­ment adapté aux projets de petite envergure, à caractère linéaire, tandis que le modèle en spirale se prête plutôt à des projets itératifs.