Au cours du cycle de vie d’un projet informatique, le cycle en V est une technique de développement linéaire unique en son genre. Il est basé sur une approche de type cascade qui suit des processus rigoureux. Alors que les premières phases sont des étapes de conception générale, le projet progresse à travers des étapes de plus en plus détaillées, menant à la mise en œuvre et au codage, puis repasse par toutes les étapes de test jusqu’à la conclusion.
Dans cet article, nous verrons en quoi consiste le cycle en V et pourquoi il peut convenir ou pas à certains projets.
Qu’est-ce que le cycle en V ?
L’idée principale du cycle en V est que les activités de développement et de test correspondent les unes aux autres. Chaque phase de développement doit être complétée par sa propre activité de test. Chacune de ces activités de test couvre un niveau d’abstraction différent : les composants logiciels, l’intégration des composants, le système logiciel complet et l’acceptation par l’utilisateur. Au lieu de se contenter de tester un logiciel monolithique à la fin du processus de développement, cette approche consistant à se concentrer sur différents niveaux d’abstraction facilite grandement le déclenchement, l’analyse, la localisation et la correction des défauts logiciels.
Le cycle en V décrit les phases de développement comme la branche gauche d’un « V », tandis que la branche droite représente les activités de test.
Les étapes du cycle en V en gestion de projet
Les différentes étapes qui seront franchies au cours du cycle de vie du projet sont représentées par la forme en V de la technique du cycle en V. Les étapes reflètent un flux linéaire de croissance. Les étapes reflètent un flux de croissance linéaire, partant de l’étape supérieure gauche et progressant vers l’extrémité supérieure droite au fil du temps, comme dans le modèle Waterfall.
Nous allons passer en revue chacune des neuf phases d’un cycle en V typique et la manière dont elles se rejoignent pour créer un produit final dans les sections ci-dessous.
L’analyse des besoins
Les exigences et l’analyse du système sont effectuées lors de cette phase afin d’établir l’ensemble des fonctionnalités et les demandes des utilisateurs. Il est important de consacrer suffisamment de temps et de produire une documentation détaillée des exigences de l’utilisateur au cours de cette phase, tout comme au cours de la même phase du modèle en cascade ou d’autres techniques comparables.
Une autre caractéristique unique du cycle en V est qu’à chaque étape de la conception, les tests qui seront utilisés ultérieurement dans les phases de test sont également conçus. Par conséquent, les tests d’acceptation sont créés pendant la phase de définition des besoins.
Les spécifications
Cette étape permet d’élaborer un document de spécification qui définira tous les composants techniques tels que les couches de données, la logique métier, etc., sur la base du retour d’information et des documents relatifs aux besoins des utilisateurs créés au cours de la phase de définition des besoins.
Au cours de cette étape, des tests du système sont également créés pour une utilisation ultérieure.
La conception de l’architecture
Au cours de cette phase, des spécifications sont rédigées pour décrire comment le programme connectera tous ses nombreux composants, soit en interne, soit par des intégrations externes. C’est ce qu’on appelle fréquemment la conception de haut niveau.
Pendant cette période, des tests d’intégration sont également réalisés.
La conception détaillée
Cette phase comprend toute la conception de bas niveau du système, comme les spécifications complètes de la façon dont toute la logique fonctionnelle codée, comme les modèles, les composants et les interfaces, sera mise en œuvre.
Pendant la phase de conception des modules, des tests unitaires doivent également être écrits.
Le codage
Le véritable codage et la mise en œuvre ont lieu à ce stade, qui se situe à mi-chemin du processus. Cette période doit être réservée à la transformation de tous les documents de conception et de spécification créés précédemment en un système codé et fonctionnel. Une fois que les phases de test commencent, cette étape doit être complètement terminée.
Les tests unitaires
Avec les tests inversés, la procédure remonte maintenant le long du cycle en V, en commençant par les tests unitaires générés pendant la phase de conception du module. Cette phase devrait, en théorie, éliminer la grande majorité des défauts et difficultés potentiels, et sera donc la phase de test la plus longue du projet.
Les tests unitaires ne peuvent pas (ou ne devraient pas) couvrir tous les problèmes concevables qui pourraient survenir dans le système, c’est pourquoi les phases de test moins granulaires qui suivent devraient combler les lacunes, comme elles le font avec d’autres modèles de développement.
Les tests d’intégration
Les tests sont effectués ici pour s’assurer que le système fonctionne sur tous les composants et intégrations tierces, comme prévu lors de la phase de conception architecturale.
Les tests de validation
Ensuite, les tests établis lors de la conception du système sont exécutés, en mettant l’accent sur les tests de performance et de régression.
La recette
Enfin, la phase de recette consiste t à mettre en œuvre tous les tests générés au cours de la phase de définition des exigences initiales dans un environnement réel avec des données réelles, afin de s’assurer que le système est prêt à être déployé.
Avantages et inconvénients de cette méthode
Les avantages :
- Facile à utiliser
- Les activités de test, comme la planification et la conception des tests, ont lieu bien avant le codage
- Gain de temps, rapidité
- Suivi proactif des défauts, c’est-à-dire que les défauts sont détectés à un stade précoce
- Évite le flux descendant des défauts
- Fonctionne bien pour les petits projets où les exigences sont facilement comprises
Les inconvénients :
- Très rigide
- Le logiciel est développé au cours de la phase de mise en œuvre, de sorte qu’aucun prototype précoce du logiciel n’est produit
- Si des changements interviennent à mi-parcours, les documents de test et les documents d’exigences doivent être mis à jour.
Risqué
