Cours sur le modèle en V. Gestion de projet numérique.

1. Le modèle de
développement en V
Membres du groupe:
ADJIKPE Emmanuel
GBENOU Euloge
GODE Michael
GUIDI Privael
HONFOVOU Alban
Sous la supervision de:
Mme Honorine DEDJINOU

2. PLAN
Introduction
I. Généralités
II. Fonctionnement du modèle en V
III. Etapes ou cycle de vie du modèle en V
IV. Quand utiliser le modèle en V ?
V. Avantages et Inconvénients du modèle en V
VI. Alternatives au modèle en V
Conclusion

3. Introduction
Dans un projet informatique, adopter la bonne méthode de gestion est d’une
importance capitale. Toutefois, choisir la bonne méthode de développement est
difficile pour de nombreuses entreprises et leurs ingénieurs. Peu d’entreprises
savent quels sont les critères pour apporter une valeur ajoutée à un projet. Ainsi,
dans cet exposé nous allons présenter le modèle de développement en V, quand
l’utiliser et quelques alternatives à ce dernier.

4. I. Généralités
 La méthode du « Cycle en V » provient initialement du secteur industriel, puis s’est
largement répandu aux projets informatiques dans les années 80. Mais son succès va
bien au-delà ! Car aujourd’hui, il s’agit du modèle de management par excellence,
celui que l’on enseigne majoritairement au sein des établissements scolaires.
Le cycle en V, ou V model en anglais, est une méthode de gestion de projets en deux
phases, une pour chaque branche du V. On retrouve ainsi une phase descendante, du
besoin exprimé par le client jusqu’à la réalisation du produit, et une phase ascendante,
du produit fini à la vérification de sa qualité. Mais les deux branches du V
communiquent et interagissent également entre elles. Ainsi, chaque phase de
production correspond à une phase de vérification, de validation. Ce jeu de renvoi
veille à la qualité du produit fini pour une satisfaction client assurée

5. I. Généralités(2)
 Le modèle du cycle en V est un modèle conceptuel de gestion de projet imaginé suite
au problème de réactivité du modèle en cascade. Il permet en cas d’anomalie, de
limiter un retour aux étapes précédentes.
 C’est une méthode de gestion aussi connue sous le nom de modèle de développement
logiciel de validation et de vérification (d’où le V). Bien que cette méthode de gestion
de projet ne soit considérée que comme une simple amélioration du modèle en
cascade. En effet, le processus est basé sur des étapes séquentielles descendantes de
manière linéaire (phases de vérification ou de conception). Cependant, il diffère du
modèle de gestion de projet en cascade, car les étapes montent après la réalisation
pour le processus de validation et forme ainsi un V. Cette forme en V démontre les
relations entre chaque phase du cycle de développement et la phase de test qui lui est
associée.

6. I. Généralités(3)
 Le cycle en V en gestion de projet découle du modèle en cascade théorisé
dans les années 1970, qui permet de représenter des processus de
développement de manière linéaire et en phases successives.
Ce mode de gestion de projet a été développé dans les années 1980 et
appliqué au champ des projets industriels, puis étendu aux projets
informatiques. Il a été remis en cause à partir du début des années 2000,
sous l’effet de l’accélération des changements technologiques, favorisant
davantage les méthodes dites « agiles ».
La lettre V fait référence à la vision schématique de ce cycle, qui prend la
forme d’un V : une phase descendante suivie d’une phase ascendante.
 Le cycle en V associe à chaque phase de réalisation une phase de
validation, comme l’illustre le schéma ci-dessous :

7. I. Généralités(4)
En gros il faut retenir que le
modèle en V ou cycle en V est un
modèle d’organisation des activités
d’un projet qui se caractérise par
un flux d’activité descendant qui
détaille le produit jusqu’à sa
réalisation, et un flux ascendant,
qui assemble le produit en
vérifiant sa qualité.

8. II. Fonctionnement du modèle en V
 De manière simplifiée, le cycle en V comprend les grandes étapes que l'on retrouve,
pour la plupart, dans le modèle en cascade :
Une première série d'étapes, le flux descendant, vise à détailler le produit jusqu'à sa
réalisation. Il comprend l'expression des besoins, l'analyse, la conception, puis la mise en
œuvre. Pour un logiciel, la mise en œuvre correspond essentiellement à la
programmation. Pour le matériel c'est la réalisation d'un équipement. Pour des mesures
organisationnelles, la mise en œuvre correspond à la rédaction de manuels de
procédure.
Une deuxième série d'étapes, le flux ascendant, vise à valider le produit jusqu'à sa «
recette », c'est-à-dire son acceptation par le client. Il comprend principalement une
série de tests jusqu'à pouvoir valider que le produit répond au besoin et aux exigences.

9. II. Fonctionnement du modèle en V
Toutefois, le cycle en V apporte une dimension supplémentaire, qui est
celle du système. Le produit du projet est alors considéré comme un «
système » fait de plusieurs éléments qui sont des modules ou
composants. Ceci requiert dans le flux descendant de distinguer une
conception générale du système dans son ensemble, et une conception
détaillée de chaque composant. La mise en œuvre se fait alors
composant par composant. Dans le flux ascendant, il convient de la
même façon d'effectuer des tests unitaires de chaque composant,
d'intégrer le système (c'est-à-dire d'assembler ses composants), puis de
faire un test d'intégration.

10. II. Fonctionnement du modèle en V(2)
 Le cycle en V apporte également une plus grande attention sur la vérification
et la validation. Les tests unitaires et les tests d'intégration vérifient que les
composants et le système fonctionnent conformément à la conception. Le
cycle en V enrichit ces étapes avec un test de validation du système, qui
confirme non seulement que le système répond à la conception, mais qu'il
répond aux exigences.
Le niveau de décomposition n'est pas figé. Certains modèles de cycle en V
décomposent les systèmes en sous-systèmes avant de les décomposer en
composant. Pour chaque niveau de complexité supplémentaire, s'ajoute alors
un étage dans le V.

11. III. Etapes ou cycle de vie du modèle
en V
Le cycle en V définit le déroulement d’un projet en phases distinctes qui sont tour à
tour détaillées. Ainsi, nous avons :
 La Conception
Analyse du besoin : recueil des besoins du client (produit souhaité, budget disponible…).
Cette étape peut aussi faire l’objet d’une étude de faisabilité ;
Spécifications : rédaction d’un cahier des charges fonctionnel (CDCF) à partir des
spécifications fonctionnelles du produit. Il s’agit d’un document résumant les objectifs du
projet, les parties prenantes, les contraintes techniques, les attentes… Cette étape peut
s’appuyer sur une analyse SWOT pour un diagnostic externe et interne complet de
l’entreprise ;

12. III. Etapes ou cycle de vie du modèle
en V
Conception générale (aussi appelée conception architecturale ou conception
préliminaire) : liste des moyens nécessaires à la réalisation du projet. Cette
étape permet d’appréhender les besoins techniques et financiers pour la
réalisation du projet. Si l’entreprise repère un point de blocage à cette étape,
elle peut, en accord avec le client, revoir le cahier des charges ;
Conception détaillée : détail des composants (étapes) indispensables à la
création du produit.
Mise en œuvre (aussi appelée réalisation ou intégration système) : création et
assemblage de tous les composants pour réaliser le produit final.

13. III. Etapes ou cycle de vie du modèle
en V(2)
 La validation
Tests unitaires : vérification du bon fonctionnement et de la conformité au cahier des
charges de chaque composant ;
Test d’intégration : vérification du fonctionnement du produit fini, une fois tous les
composants assemblés ;
Tests système (aussi appelés tests de validation) : mise en situation réelle pour vérifier la
conformité du produit au cahier des charges et aux spécifications du produit ;
Test d’acceptation (aussi appelé recette fonctionnelle) : validation du produit par
rapport aux besoins exprimés par le client lors de l’étape 1. Cette validation peut soit être
faite auprès d’un organisme de validation constitué d’experts, soit directement par le
client.

14. IV. Quand utiliser le modèle en V
 Ce qu’il faut savoir avant d’adopter le cycle en V comme méthode de gestion de projet
pour votre équipe, c’est qu’il s’agit d’un modèle de gestion considéré comme rigide. En
effet, il est difficile de revenir à une phase lorsqu’elle est terminée. Bien que cela
puisse être un handicap dans certains projets logiciels, qui demandent une certaine
flexibilité, le cycle en V peut être une méthode de gestion judicieuse ou la plus
adaptée dans d’autres projets logiciels. Par exemple, un projet qui doit répondre à
certaines exigences au niveau de la qualité du produit fini.
 On peut utiliser le cycle en V dans un projet dont le cahier de charges ne change pas en
cours de route. Par exemple dans des projets lancés à partir d’un appel d’offres ou le
client a documenté ses exigences très clairement.
 Pour choisir le cycle en V comme méthode de gestion d’un projet logiciel à utiliser, il
est recommandé que les conditions suivantes soient remplies, du moins la majorité :

15. IV. Quand utiliser le modèle en V
 La qualité finale du projet est importante
 Les exigences doivent être claires et figées
 La technologie choisie pour la réalisation est maitrisée et déjà utilisée par
l’équipe de développeurs dans le cadre de différents projets.
 Le projet ne peut être réalisé de manière itérative.
 Le coût de développement du projet est défini et fixe.

16. V. Avantages et inconvénients du
modèle en V
 Avantages du modèle en V
 Le principal avantage du cycle en V est qu’il évite de revenir en arrière incessamment
pour redéfinir les spécifications initiales, comme un cliquet. Chaque phase de
conception demande la rédaction d’une documentation précise et exhaustive, où
chaque point doit être validé par le produit final. Dès lors qu’une étape est validée, on
ne revient pas en arrière et on passe à l’étape suivante sur une base solide ; c’est la
principale force du cycle en V.
De par son aspect à la fois rigoureux et intuitif, le cycle en V demeure un processus
facile à mettre en œuvre. Le travail préalable de définition des spécifications en début
de projet fait que, une fois lancé, l’ensemble des étapes est connu des collaborateurs,
qui peuvent se repérer facilement dans la temporalité du projet et connaître la finalité
de leurs tâches. De la même manière, les documentations nécessaires à chaque étape
sont réplicables d’un projet sur l’autre dans leur structure (cahiers des charges, cahiers
de test…).

17. V. Avantages et inconvénients du
modèle en V
 En général, le cycle en V est plus adapté aux structures multisites, car il ne
demande pas de réunions quotidiennes, mais seulement des réunions de
pilotage actant le passage d’une phase à l’autre. Son aspect linéaire autorise
donc une organisation géographique éclatée, où le côtoiement des
collaborateurs n’est pas clé dans le processus.

18. V. Avantages et inconvénients du
modèle en V
 Inconvénients du modèle en V
 L’inconvénient principal du cycle en V se résume en deux mots : l’effet tunnel. Après
une phase de définition précise du produit auquel l’équipe doit aboutir, le projet est
lancé dans un « tunnel » constitué des phases évoquées plus haut. Mais que faire si les
spécifications initiales sont dépassées ? Si le besoin du client vient à changer, ou a été
mal exprimé ? Le cycle en V supporte donc mal les changements, ce qui est à la fois sa
force et sa principale faiblesse.

19. V. Avantages et inconvénients du
modèle en V
 Il offre ainsi moins de réactivité par rapport au contexte technologique et
économique, aux demandes du client, aux événements inopinés ; la prise de
risque s’en trouvera systématiquement limitée. L’effet tunnel est aussi induit
par le travail conséquent de production de la documentation en début de
projet, qui n’est plus rectifiable par la suite. Enfin, l’image du tunnel illustre
le temps (parfois très) long qui sépare l’expression du besoin de la recette du
produit final.

20. VI. Alternatives au modèle en V
 D’autres alternatives au modèle en V sont le modèle agile et le modèle en cascade.
 Modèle en V et la méthode agile
 La principale différence entre le modèle en V et la méthode agile repose sur les notions
d’adaptabilité et de flexibilité face aux changements.
 Et cela, en raison de l’organisation et de la vision du projet qui diffèrent totalement.
 Avec le cycle en V, vous placez le projet au centre en adoptant ainsi une vision
d’ensemble dès le commencement. Tout est alors géré d’un seul bloc, de l’expression
des besoins du client à la livraison du produit fini.

21. VI. Alternatives au modèle en V
 Avec l’agile, vous placez le produit au centre. Le projet n’est plus vu dans sa
globalité, mais par composants. Autrement dit, vous divisez le projet en
itérations, en sprint. Des livraisons sont alors faites à chaque fin de cycle
itératif au client afin qu’il puisse donner son avis et vérifier que tout
corresponde bien à ses attentes. L’autre plus grosse différence entre le cycle
en V et l’agile reste l’écoute et la compréhension. En effet, dans le cadre
d’une gestion agile, les réunions sont bien plus fréquentes qu’en cycle en V. A
la suite de ces séances, un rapport est envoyé au dirigeant qui en informe le
client. Autrement dit, il y a un véritable échange entre les différentes parties
prenantes, ce qui n’est pas le cas avec le cycle en V.
 Modèle en V et le modèle en cascade
 Le modèle en V découle du modèle en cascade. Ainsi, si la méthode en
cascade ne permet pas de retour aux étapes précédentes, le cycle en V rend
possible les retours en arrière grâce à la communication entre les deux
phases.
 Le cycle en V offre donc un peu plus de souplesse que la méthode en cascade.

22. Conclusion
Le modèle en V est le modèle de management par excellence. Il est caractérisé
par deux phases : la phase descendante ou la phase de la conception qui consiste
à recenser les besoins ou les spécifications du client dans leurs entièretés et
procéder à la conception et la phase ascendante ou la phase de validation qui
consiste à faire des tests jusqu’à ce que la réalisation soit validée. Il est donc
utilisé pour des projets à cahier de charge figé.