En quoi consiste le cycle en V ?

Le cycle en V ou V model en anglais est un modèle utilisé dans différents processus de développement, notamment dans le développement de logiciels. Élaboré dans les années 90 sous sa forme originale, il est perfectionné au fil des ans et adapté aux méthodes de développement contemporaines. L’idée de départ remonte cependant aux années 70 et a été imaginée comme une sorte de prolongement du modèle en cascade.

Outre les différentes phases de développement d’un projet, le cycle en V définit parallèlement les démarches afférentes à mettre en place en termes d’assurance qualité et détaille la façon dont les diffé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éroulement d’un projet en phases distinctes qui sont tour à tour détaillé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’expression des besoins fonctionnels et non fonctionnels liés à l’architecture du système.
• Puis on passe à la phase de conception du système, lors de laquelle les composants et les interfaces du système sont planifiés.
• Une fois ces étapes franchies, on peut passer à la conception de l’architecture logicielle en détail.

On entre alors dans la phase effective de développement 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éveloppement. Le modèle prévoit les tâches suivantes :

• Tests unitaires ;
• Tests d’intégration ;
• Intégration système ;
• La « recette » (ou test d’acceptation).

La lettre « V » provient du fait que le modèle associe chaque phase de développement avec la phase de validation qui lui correspond. Le bras gauche du « V » désigne les tâches relatives à la conception et au développement 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éveloppement et d'assurance qualité. Dans le cas d’un projet informatique, on parlera plus volontiers de programmation logicielle.

Les tests unitaires permettent de vérifier la bonne mise en œuvre de l’architecture logicielle prévue. Lors de cette étape, on vérifie si les différents modules du logiciel répondent en tous points aux fonctionnalité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 parallèlement à la conception, afin d’éviter les erreurs.

La conception du système est soumise à des tests d’intégration. Il s’agit ici de vérifier si les différents composants interagissent 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 conception de l’architecture système ont été respectées. En règle générale, les simulations ont lieu dans un environnement qui reproduit aussi fidèlement que possible les situations rencontré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éfinitive, le client s’assure que ses exigences ont bien été prises en compte durant le fonctionnement. En règle générale, on teste uniquement le fonctionnement 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 modification du cycle en V date de 2006. L’objectif était de pouvoir intégrer de nouvelles démarches comme le développement agile. Cela a donné naissance à la méthodologie « V modell XT ». XT signifie ici « extreme tailoring » (« flexibilité extrême »). Cette approche explique comment modéliser le modèle sur mesure en fonction des différentes exigences liées au projet.

En continuant à développer ce système, l’idée de base était de fournir un modèle qui puisse s’adapter facilement à des projets d’envergures différentes. En effet, l’ancienne méthode s’est avérée extrêmement coûteuse, notamment pour les petits projets et donc inefficace. Dans le cas de petits projets, le V modell XT permet de supprimer certaines phases qui nécessiteraient un investissement trop élevé.

De plus, le nouveau modèle intègre des blocs de tâches qui font directement référence au client. L’ancien modèle se contentait de faire piloter le projet par le prestataire avant la réception définitive. Le nouveau modèle implique le client de manière beaucoup plus directe.

Le modèle est mis à jour régulièrement afin de prendre en compte les nouveautés en termes de processus de développement 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 industriel. 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 informatiques. Par conséquent, c’est un paramètre très important pour les entreprises qui conçoivent des logiciels pour les pouvoirs publics et les ministères. Il convient aux projets informatiques de toute taille, que ce soit au niveau des entreprises, de l’armée ou du secteur public. C’est un outil qui permet de faciliter l’organisation et la réalisation liées au développement, à la maintenance et au développement continu des différents systèmes d’information.

Le cycle en V peut également être utilisé dans d’autres secteurs de développement, comme par exemple les systèmes électroniques ou mécaniques dans les domaines de la recherche et des sciences. Pour ces domaines d’application, il existe des versions légèrement modifiées qui tiennent compte des stades spécifiques propres à chaque secteur.

Cette démarche est largement répandue, car elle garantit avant tout un degré élevé de transparence ainsi que des processus clairement définis et compréhensibles. Vous trouverez ci-après un récapitulatif des avantages et des éléments de critique les plus importants.

• Optimisation de la communication entre les parties prenantes grâce à des modalités et des responsabilités clairement définies.
• Risques maîtrisés et meilleure planification grâce à des fonctions, des structures et des résultats bien définis en amont.
• Amélioration de la qualité du produit grâce à l’intégration de mesures liées à l’assurance qualité.
• Réduction des coûts grâce à un processus transparent de l’ensemble du cycle de vie du produit.

Dans l’ensemble, ce modèle peut permettre d’éviter les malentendus 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éveloppeurs, cette démarche s’avère souvent trop simpliste, car elle ne reflète pas intégralement le processus de développement. La gestion de projet occupe une place de plus en plus importante. En outre, la rigidité relative de la structure ne permet guère de réagir avec souplesse aux modifications en cours de développement et favorise donc un déroulement relativement 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 correctement utilisé.

Il existe différents types d’approches propres au secteur du développement de logiciels qui peuvent convenir en fonction des projets et de la structure des équipes. Le choix des approches est relativement large, même si le modèle en cascade ou le modèle en spirale sont particulièrement répandus. Le modèle en cascade est particulièrement 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.