Il existe un grand nombre de méthodologies de développement de logiciels différentes qui ont été utilisées au cours de ces dernières décennies. Ils appartiennent généralement à l'une des deux catégories suivantes : poids lourd ou poids léger.

Les méthodologies lourdes (ou méthodes prédictives) telles que Waterfall, Spiral et le cycle en V, sont basées sur une approche linéaire, séquentielle et étape par étape du développement de logiciels. Elles sont généralement utilisées pour des cycles de développement plus longs qui peuvent durer plusieurs mois ou années. 

Les méthodologies légères (ou méthodes agiles), telles que Scrum, Lean et XP, sont flexibles et sont utilisées dans des cycles de développement courts (itérations) qui durent de deux à quatre semaines. Cela permet aux équipes de répondre rapidement aux demandes des clients qui changent constamment.

Les modèles prédictifs sont pour la plupart tombés en disgrâce et ont été remplacés par des méthodes agiles, mais cela ne veut pas dire que plus personne n'utilise de méthodes lourdes. Lorsque vous développez un nouveau logiciel, le modèle de développement que vous choisirez sera la clé de sa réussite. Et il n'y a pas une méthode spécifique qui fonctionne pour tout le monde dans toutes les situations.

Dans cet article, nous allons parler d'un modèle prédictif connu sous le nom de cycle en V (ou V-model en anglais). Nous vous expliquerons ce qu'est le cycle en V, comment il fonctionne et pourquoi vous pourriez vouloir l'utiliser à l'ère du développement agile.

Qu'est-ce qu'un cycle en V ?

Cette méthodologie de gestion de projet pour le développement de logiciels est une variante du modèle classique Waterfall. La différence est qu'avec Waterfall, chaque phase de développement passe en cascade à la suivante selon un processus linéaire simple. Avec le cycle en V, une phase de test se déroule parallèlement à chaque phase de développement. Chaque phase parallèle de développement et de test doit être terminée avant que la suivante ne puisse commencer. 

Ce modèle en V tire son nom de son objectif principal de vérification (conception) et de validation. De plus, lorsque ces phases parallèles de développement et de test sont représentées graphiquement, le diagramme qui en résulte ressemble à la forme d'une lettre V. 

Quelle est la différence entre la conception et la validation ?

Certaines personnes qui ne comprennent pas cette méthode pensent que la conception (vérification) et la validation sont essentiellement la même chose. Voyons donc quelles en sont les différences.

La conception est le processus qui permet de s'assurer que les exigences du projet sont respectées. Cela comprend la vérification de la documentation, de la conception et du code à un moment donné du développement du projet. Vous vous assurez que le projet soit développé correctement.

Par exemple, si vous développez une application de feuille de calcul, en cours de route, vous devez vérifier que les calculs mathématiques de base sont exacts avant de passer à un codage et à des formules plus complexes. Ce type de test est effectué parallèlement au développement du produit.

La validation est le processus qui consiste à s'assurer que vous développez le bon produit. Ce type de test intervient lorsque la phase de développement est terminée. Vous effectuez des tests pour vous assurer que le produit répond aux besoins de vos clients.

Comment fonctionne le cycle en V ?

Le cycle en V consiste en une série de phases linéaires qui se succèdent l'une après l'autre jusqu'à ce que le projet soit terminé. La partie gauche du cycle en V énumère les phases de conception et vérification du développement. La partie droite énumère les phases de validation parallèles du développement. Les phases de conception et de validation sont réunies au point du V.

Il existe plusieurs phases de conception et de validation dans le modèle en V pour l'ingénierie, comme décrit ci-dessous.

Les exigences

Pendant la phase des exigences, les collaborateurs et l'équipe analysent les besoins des clients et déterminent ce qui sera inclus dans l'ensemble des fonctionnalités. Prenez suffisamment de temps pour faire une analyse approfondie afin de ne rien manquer de ce qui est important pour vos clients. Créez également une documentation détaillée pour vous assurer que toutes les personnes concernées comprennent les exigences. Parallèlement, les tests d'acceptation sont planifiés et conçus.

Conception du système

À l'aide de vos documents d'exigences et des commentaires et avis de vos clients et des collaborateurs, déterminez les méthodes ou les techniques que vous pourriez utiliser pour mettre en œuvre ces exigences. Créez un document de spécification qui décrit l'organisation générale du système, les structures de menu, la logique commerciale, les couches de données, etc.

Sur la base des documents de conception du système, les tests du système sont planifiés et conçus au cours de cette phase.

Conception architecturale

Dans cette phase, documentez les spécifications qui détaillent la façon dont tous les divers composants du logiciel seront reliés et interagiront - par le biais d'intégrations internes ou externes. Cette phase est aussi parfois appelée conception de haut niveau (HLD).

Sur la base des informations documentées dans cette phase, les tests d'intégration sont développés en même temps.

Conception du module

Cette phase est également connue sous le nom de conception de bas niveau de votre système. Dans cette phase, détaillez la conception interne du système. Documentez les détails sur la façon dont les modèles, les composants, les interfaces, etc. seront mis en œuvre et fonctionneront avec d'autres modules du système.

Au cours de cette phase, les tests unitaires doivent être planifiés et créés. Les tests unitaires sont utilisés pour s'assurer que les composants individuels du module fonctionnent correctement.

Écriture du code

Nous sommes ici au point de la forme en V où le côté conception du modèle est relié au côté validation. Dans cette phase, vos développeurs travaillent sur le code en utilisant les directives et les normes qui sont détaillées dans les documents de conception. À l'aide des documents de conception et de spécification, votre équipe écrit le code et crée un système fonctionnel. Le code est revu et optimisé avant la construction finale. Les phases de test commenceront après la soumission de la version finale.

Tests unitaires

Les phases de validation du modèle V commencent par des tests unitaires. Les tests unitaires auraient dû être planifiés et conçus pendant la phase de conception du module. Ces tests sont exécutés par rapport au code des différents éléments du module. Les tests unitaires t'aident à trouver et à corriger les bogues et autres problèmes qui pourraient survenir.

Comme les tests unitaires sont très granulaires, cette phase est susceptible de prendre plus de temps que les autres phases de validation. Mais cette phase est très importante car elle t'aide à éliminer la majorité des bugs et problèmes potentiels afin que les phases de test qui suivent se déroulent plus facilement et plus rapidement.

Test d'intégration

Les plans de test pour cette phase devraient avoir été créés pendant la phase de conception architecturale. Les tests sont utilisés pour voir si le logiciel fonctionne bien et s'il communique avec les composants internes et externes du système.

Test du système

Les tests du système sont créés pendant la phase de conception du système. Ces tests sont principalement axés sur les performances globales afin de s'assurer que le nouveau logiciel fonctionne et communique correctement au sein du système. Le test du système peut vous aidez à trouver les problèmes de compatibilité des logiciels et du matériel.

Test d'acceptation

Le test d'acceptation est la dernière phase de test. Les tests d'acceptation se déroulent dans un environnement d'utilisateur. L'objectif est de s'assurer que le nouveau logiciel est compatible avec les autres systèmes de l'environnement de l'utilisateur et qu'il fonctionnera correctement dans un environnement réel.

Pourquoi utiliser un cycle en V ?

La plupart des entreprises travaillant dans un environnement agile, vous vous demandez pourquoi utiliser un cycle en V. Si la pandémie mondiale nous a appris quelque chose, c'est que pour réussir, les entreprises doivent s'adapter. S'adapter, ce n'est pas seulement permettre aux employés de travailler à la maison, au bureau ou dans un modèle hybride .Cela signifie également que de nombreuses organisations doivent opérer un changement dans la façon dont elles planifient et exécutent leurs projets. 

Le Project Management Institute (PMI) appelle ces entreprises des "gymnastic enterprises". Une "gymnastic enterprises" est plus axée sur les résultats et les effets. Cela signifie qu'elles sont plus ouvertes aux différents processus qui peuvent les aider à obtenir le résultat souhaité. Ainsi, en fonction du type de projet, de sa complexité et de la répartition de ses employés, cette entreprise peut décider qu'il est judicieux de développer un projet en utilisant parfois une méthode prédictive comme le cycle en V.      

Un cycle en V à aussi les avantages suivants :

• C'est relativement facile à comprendre et à mettre en œuvre. Comme chaque phase est terminée avant que la suivante ne commence, il est facile de rester sur la bonne voie et d'atteindre les objectifs.
• C'est facile à gérer. La nature linéaire du modèle vous permet de savoir où vous étiez, où vous êtes et où vous devez aller.
• Le cycle en V est linéaire, rigide et restrictif, ce qui ne semble pas être un avantage. Mais une approche linéaire et rigide fonctionne bien avec les projets dont le champ d'application est strict et dont le planning n'est pas flexible. 
• Le cycle en V est bon outil pour la gestion du temps. Ce modèle fonctionne très bien avec les projets qui doivent respecter un délai strict et franchir des étapes définies en cours de route.

 

Êtes-vous prêt à utiliser le cycle en V pour votre gestion de projet ?

Essayer Lucidchart