Modèle en V (Exposé UML 2)

Le cycle en V est une méthode de gestion de projet classique que l’on oppose généralement aux
méthodes dites Agile. Mise au point dans les années 80, elle a pendant longtemps été utilisée dans le
secteur de l’industrie logicielle.
Le cycle en V ressemble à la méthode en cascade. Cependant, il y a tout de même quelques
différences. Ainsi, la méthode en cascade ne permet pas de retour aux étapes précédentes. Par
contre, le cycle en V rend possible le retour en arrière et ce, même lorsque l’étape a été validée. Le
cycle en V permettrait donc d’apporter un peu de souplesse au modèle en cascade.

Traditionnellement, le cycle en V découpe le projet en 3 grosses phases, à savoir la conception, puis

la réalisation et enfin la validation.
 La conception (la partie descendante) : analyse des besoins et étude de faisabilité,
spécifications, conception générale/architecturale et conception détaillée ;
 La réalisation ;
 La validation (la partie ascendante) : tests unitaires, tests d’intégration, validation et recette.
Les neuf étapes peuvent être regroupées en trois phases : ainsi, nous saisissons mieux le
cheminement du projet :

Les étapes de conception

 L’expression du besoin : cette première étape est indispensable afin de comprendre les
besoins du client, ce qu’il imagine du produit fini. Le client va exprimer sa demande, une
analyse est faite par la suite par l’équipe, pour pouvoir présenter une solution intéressante
au client.

 La définition des spécifications fonctionnelles : Les spécifications fonctionnelles sont un

cahier des charges permettant de décrire de manière complète le produit, les différents cas
d’utilisation du produit, ses différentes fonctionnalités. Généralement, elles sont faites par le
chef du projet tout en restant en contact avec le client pour pouvoir valider les fonctions du
produit. Il rédige un cahier des charges. Celui-ci doit comprendre l’ensemble des cas
d’utilisation du produit final. Un cahier de recette est rédigé en parallèle avec les
spécifications fonctionnelles.

 L’identification des spécifications techniques : on traduit les spécifications fonctionnelles

dans les termes techniques nécessaires aux développeurs pour la réalisation du produit. On
établit la conception détaillée, on définit également l’architecture logicielle du produit lors
de cette étape pour le client afin de valider la version finale pour que les développements
commencent.

L’étape de réalisation

 Le codage (ou développement) : l’équipe commence les développements des fonctionnalités

du produit tout en respectant les spécifications détaillées (Spécifications fonctionnelles +
Maquettes), afin de respecter le contrat avec le client et réaliser la demande du client. On
entre dans la phase de réalisation. On développe les briques. On assemble ensuite ces
dernières pour devenir le produit fini.

Les étapes de validation

 Les tests unitaires : Après les développements des fonctionnalités du produit, l’équipe réalise
les tests unitaires, techniquement parlant, les tests de chaque méthode qui fait un
 traitement spécifique. On teste chaque brique afin de vérifier l’adéquation par rapport au
cahier des charges.

 Les tests d’intégration : on teste les briques afin de contrôler le respect des spécifications
techniques.

 Les tests de validation : on ne peut valider le produit fini qu’à partir du moment où les
spécifications fonctionnelles ont toutes été vérifiées. Ils permettent de vérifier si toutes les
exigences client décrites dans le document de spécification d'un logiciel, écrit à partir de la
spécification des besoins, sont respectées. Les tests de validation se décomposent
généralement en plusieurs phases :

o Validation fonctionnelle : les tests fonctionnels vérifient que les différents modules
ou composants implémentent correctement les exigences client. Ce sont des tests
qui se font sur tout une fonctionnalité, ils peuvent passer par plusieurs méthodes
pour assurer le bon résultat.

o Validation solution : les tests solutions vérifient les exigences client d'un point de vue
cas d'utilisation (use cases). Généralement ces tests sont des tests en volume.
Chaque grand cas d'utilisation est validé isolément ; puis tous les cas d'utilisation
sont validés ensemble. L'intérêt est de valider la stabilité d'une solution par rapport
aux différents modules qui la composent, en soumettant cette solution à un
ensemble d'actions représentatif de ce qui sera fait en production.

 Validation performance, robustesse : les tests de performance vont vérifier la conformité de

la solution par rapport à ses exigences de performance, alors que les tests de robustesse
vont essayer de mettre en évidence des éventuels problèmes de stabilité et de fiabilité dans
le temps (fuite mémoire par exemple, résistance au pic de charge, augmentation de la
volumétrie des données, ...).

 La mise en production et la recette : après une dernière vérification en préproduction, on

met le produit fini en production, le produit est terminé et celui-ci doit répondre à
l’ensemble des besoins spécifiés en début de projet. Le cahier de recette (réalisé en parallèle
avec les spécifications fonctionnelles), contient les descriptions des fonctionnalités des
spécifications fonctionnelles, l’équipe utilise ce cahier pour tester ces fonctionnalités sur le
produit pour pouvoir détecter les bugs, pour les corriger, afin d’assurer formellement que le
produit est conforme aux spécifications.
Avantages

L'intérêt principal du cycle en V est qu'il nécessite une formalisation des fonctionnalités du
produit et de ce qui sera fait sur le projet. Il permet ainsi de bien réfléchir et de se poser les
bonnes questions au début du projet, autant du côté client que du côté du prestataire.
Comme autres avantages :

 Il permet de préparer en amont les phases de spécification qui sont trop souvent négligées.
 Il propose plusieurs phases de tests (souvent négligées elles aussi) en relation avec la
description des besoins initiaux, ce qui assure une meilleure qualité du produit final. Il
apporte plus de précisions durant sa phase de test.
 Il permet de définir avec clarté le périmètre des rôles et des étapes.
 Il évite les allers-retours durant le cycle de vie du projet : si des problèmes sont rencontrés,
chaque étape de la partie ascendante peut s’appuyer sur la documentation produite lors de
l’étape de la partie descendante correspondante (voir l’illustration ci-dessus).
 Il nécessite juste quelques réunions régulières pour le pilotage du projet et le suivi
budgétaire. Quant à la documentation, elle peut être créée à partir de templates déjà
existants.
 Il requiert moins de formation et de prérequis pour son application que d’autres méthodes
telles que Scrum.
 Il s’adapte facilement aux projets impliquant des structures multisites, contrairement aux
modèles de gestion de projet nécessitant des réunions quotidiennes.

Inconvénients

L’un des inconvénients est qu’il n’envisage pas que les spécifications initiales puissent être modifiées
après leurs validations. Il est trop loin de la réalité de l’entreprise. Un retour en arrière demande
théoriquement de recommencer le cycle, mais dans la pratique, les changements sont appliqués en
cours de cycle, mais leur encadrement n’est pas prévu par la méthodologie. Comme autres
inconvénients :
  Il manque de souplesse : chaque phase doit être terminée (spécification, conception,
développement...) avant de passer à la suivante. Chacune des étapes va durer plus
longtemps et donc coûter plus chère, une méthodologie Scrum est dans ce cas plus
adaptée.
 La péremption du produit : sur de gros projets dont la durée de réalisation est de
plusieurs années, le cycle en V classique est à éviter. Nous préconisons la mise en
place d'un cycle en W ou en spirale.
 La recherche de l'idéal : en utilisant ce cycle, il faut être attentif au temps passé sur la
phase de démarrage du projet. La solution développée doit répondre aux besoins du
client. Pentalog High Tech vous assiste et vous conseille dans la phase de
spécifications du projet.
 Il tolère mal les changements de par sa construction séquentielle et linéaire. Pourtant, il n’est
pas rare de rencontrer des problèmes conceptuels lors de la phase de réalisation et de
validation.
 Il nécessite une documentation importante, perçue par certains comme une lourde perte de
temps. De plus, si elle s’avère imparfaite, nous ne pouvons pas la rectifier lors d’étapes
intermédiaires prévues à cet effet.
 Il s’adapte difficilement à certains types de projets. Le développement logiciel, par exemple,
supporte difficilement le manque de réactivité et la séparation entre la conception et la
réalisation des activités.
 Il peut être long. On court alors le risque que le produit dans sa version finale ne soit pas
adapté aux évolutions apparues au cours de sa conception. C’est là tout le paradoxe d’un
modèle qui n’admet pas le changement, alors que sa durée ne permet pas de l’éviter.

Exemples

Alors quand faut-il appliquer le cycle en V ?

 Pour des entreprises ayant l’habitude d’externaliser leurs projets (offshore sur la phase de
développement).
 Pour de petits projets (moins de 1 an pour un cycle complet).
 Pour des projets à faible risque : éviter les projets trop techniques ou les projets qui risquent
d’évoluer.

QCM

1. Quelles sont les trois phases principales du modèle en V ?

a. Analyse – Conception – Déploiement

b. Conception – Réalisation – Validation
c. Modélisation – Réalisation – Implémentation

2. Le modèle en V est composé de :

a. 9 étapes
b. 8 étapes
c. 11 étapes
3. Le modèle en V permet d’apporter plus de souplesse au :

a. Modèle en cascade
b. Modèle en W
c. Modèle exploratoire

4. Pour vérifier la conformité de la solution, on utilise :

a. Les tests de performance

b. Les tests solution
c. Les tests fonctionnels

5. Le maître d’œuvre s’occupe essentiellement :

a. Des spécifications et les tests de validation

b. Du cahier de charges et du cahier de recettes
c. De la conception détaillée, des tests unitaires et de la réalisation

6. Les tests d’intégration permettent de :

a. Vérifier que le système répond aux besoins

b. Tester les composants ou les sous-systèmes de bas niveau
c. Tester le bon fonctionnement des sous-systèmes entre eux

Bibliographie :

 https://fr.wikipedia.org/wiki/Cycle_en_V
 http://www.Chedequipe.fr/méthodes/le-cycle-en-v/
 http://www.geek-directeur-technique.com/2009/02/04/le-cycle-en-v
 https://fr.wikibooks.org/wiki/Programmation_Cycle_en_V
http://blog.dcube.fr/blog/2014/04/28/scrum-vs-cycle-en-v/
 http://www.igm.univmlv.fr/~dr/XPOSE2002/Site_Vaubourg_Stephane_IR3/html/
cycleV.htm