Le document présente le modèle en V, une méthodologie linéaire de développement logiciel qui structure le processus en étapes distinctes de conception, réalisation et validation. Bien que ce modèle offre des avantages tels qu'une meilleure planification et un accent sur la qualité des tests, il présente également des inconvénients, notamment sa rigidité face aux changements et à l'analyse des risques. En conclusion, le modèle en V est largement utilisé, en particulier dans des projets de grande envergure, malgré ses limitations.

1. Département de
Mathématiques-Informatique
Exposé Génie Logiciel
Modéle en V
Prépare par G3 :
1-
2-
3-
4-
5-
6-
7-
INFO S4
2017-2018
Sous la Théme
Mourad Moulaye Ahmed C12220
Mohamed vall Jidou C11878
Mohamed Abderrahmane Babe Ebnou C11301
Fatma Mohamed Mahmoud C11999
Latiffa Mohamed Elhadramy C11741
Selmou Haibouna Haiballa C11267
Ishagh Ahmedou banba C11111

2. I. Introduction
II . Processus du modèle en V
III. Comparaison et Optimisation par rapport aux autres modéles
V. Avantages et Inconvenients
VI. Conclusion
IV. Rôle

3. I. Introduction
Le V-Model est une méthodologie de développement linéaire unique utilisée lors
d'un cycle de développement logiciel (SDLC).
Le V-Model se concentre sur une méthode typiquement en cascade qui suit des
phases strictes étape par étape. Alors que les étapes initiales sont des phases de
conception générales, les étapes progressent de façon de plus en plus granulaires,
menant à la mise en œuvre et au codage, et finalement, à travers toutes les étapes de
test avant la fin du projet. Dans cet article, nous examinerons exactement ce que le
V-Model implique réellement, et pourquoi il peut (ou pas) être adapté à certains
types de projets ou d'organisations..
Quand l’utiliser:
 Quand le produit à développer à de très hautes exigences de qualité
 Quand les besoins sont connus à l’avance
 Les technologies à utiliser sont connues à l’avance

4. Tout comme le modèle de cascade traditionnel, le modèle V spécifie une série d'étapes
linéaires qui devraient se produire tout au long du cycle de vie, une à la fois, jusqu'à ce
que le projet soit terminé. Pour cette raison, V-Model n'est pas considéré comme une
méthode de développement agile, et en raison de l'ampleur des étapes et de leur
intégration, la compréhension du modèle en détail peut être difficile pour tous les
membres de l'équipe, et encore moins les clients ou les utilisateurs. Pour commencer, il
est préférable de visualiser les étapes approximatives du V-Model, comme on le voit
dans le schéma ci-dessous
II - Le processus du modèle en V

5. Expression
De besoin
Spécifications
fonctionnelles
Conception
générale
Conception
Détaillée
Codage (Réalisation)
Test
unitaire
Test
D’intégration
Test
De validation
Test
De recette
Cas de test
Plan de test d’intégration
Plan de test du système
Plan de validation du système

6. La forme en V de la méthode V-Model représente les différentes étapes qui seront
transmises pendant le cycle de vie du développement logiciel.
À partir du stade supérieur gauche et au cours du temps, vers le haut-droit, les étapes
représentent une progression linéaire du développement similaire au modèle cascade.
Ci-dessous, nous discuterons brièvement de neuf étapes autour du V-Model typique et
de la manière dont elles se réunissent pour générer un produit fini
On peut y distinguer 3 grandes parties :
La phase de conception, la phase de réalisation (codage) et la phase de validation. Les
phases de conception et de validation se découpent en plusieurs parties. Chaque étape
ne peut être réalisée qu’une fois que l’étape précédente est terminée, ce qui diminue les
prises de risque sur le projet.
Ce qui est bien visible sur le diagramme, c’est que chaque étape de conception possède
son alter ego de validation. Il devient alors assez aisé de valider un projet, car le
référentiel de test est connu très précisément.II.

7. I. Expression de besoin :
Le client exprime son besoin, en décrivant les usages
correspondant au produit fini tel qu’il peut l’imaginer. Cela doit
répondre aux questions « Que veut-on ? » et « À quel coût ? ».
II. Spécifications fonctionnelles :
C’est le cahier des charges exact du produit final, tel que le désire le
client. Il doit couvrir l’intégralité
des cas d’utilisation du produit, en expliquant ce qu’il doit faire et
non pas comment il va le faire.
Les différentes étapes
III. Conception générale :
Au cours de cette étape, des spécifications sont élaborées et détaillent
comment l'application reliera tous ses différents composants, soit en
interne, soit via des intégrations extérieures. Souvent, cela s'appelle
design de haut niveau. Les tests d'intégration sont également
développés au cours de cette période

8. IV. Conception détaillée :
Cette phase consiste en toute la conception de bas niveau
du système, y compris des spécifications détaillées pour
la mise en œuvre de la logique métier fonctionnelle et
codée, tels que les modèles, les composants, les
interfaces, etc. Des tests unitaires devraient également
être créés pendant la phase de conception du module
V. Codage :
C’est la phase de réalisation à proprement parler,
pendant laquelle sont développées des briques qui sont
ensuite assemblées pour créer le produit fini.
VI. Tests unitaires :
Ces tests interviennent à un niveau « atomique »
Chaque brique logicielle a été modélisée puis
codée durant les étapes précédentes. Les tests
unitaires assurent que ces briques respectent de
manière individuelle leur cahier des charges

9. VII. Tests d’intégration
Ce sont là les premiers tests grandeur nature du
produit fini. On s’assure qu’il suit les indications
des spécifications techniques.
VIII. Validation :
Le produit est à ce moment testé en regard de la
spécification fonctionnelle. Toutes les utilisations qui y
ont été définies doivent pouvoir se vérifier dans les faits.
IX. Teste de recette :
Le produit est vérifié une dernière fois en pré-production, avant
d’être mis en production. Le client procède à la recette, pour vérifier
que son expression de besoin est respectée

10. III. Comparaison et Optimisation par rapport aux
autres Modéles
 Contrairement au modèle de la cascade, ce modèle fait apparaitre le fait que le
début du processus de développement conditionne ses dernières étapes.
 Avec toute décomposition doit être décrite la recomposition
 Toute description d’un composant est accompagnée de tests qui permettront de
s’assurer qu’il correspond a sa description
 Ceci rend explicite la préparation des derniéres phases (validation-vérification )
Par les premiéres (construction du logicial )
 C’est le cycle de vie le plus connu et certainement le plus utilisé
 Le cycle en V est le cycle qui a été normalisé
 Il est largement utilisé, notamment en informatique industrielle et télécoms

11. IV. Rôle
Dans le contexte des projets de grande envergure ont émergé
des rôles pour partager et désigner les responsabilités :
 Maîtrise d’ouvrage (MOA) qui regroupe les fonctions suivantes :
 le maître d’ouvrage stratégique (MOAS)
 le maître d’ouvrage délégué (MOAD)
 le maître d’ouvrage opérationnel (MOAO)
 L’assistant à maîtrise d’ouvrage (AMOA ou AMO)
 l’expert métier
 enfin l’utilisateur, au service duquel se trouvent toutes les autres fonctions.
 Maîtrise d’œuvre (MOE)
 Maîtrise d'œuvre déléguée (MOED)
 l'Équipe Architecturale
 l'Équipe de développement
 Titulaire de marché

12. Répartition des rôles en fonction des étapes
Niveau de
Détail Rôles
Besoins
et
Faisabilit
é
Spécification Conception
Architecturale
Conception
Détaillée
Codage
Test
unitaire
Test
d'intégrati
on
Test
fonctionnel
Test
d'acceptation
(recette)
Système MOA + AMOA X X
Fonctionnel MOE + MOED X X
Technique
et Métier
Équipe
Architecturale
X X
Composant
Équipe
de Développe
ment
X X X
On retrouve dans ce découpage le V, d'où le nom de ce modèle.

13. IV. Avantages et Inconvenients
 Ne gère pas les changements des spécifications
 Ne contient pas des activités d’analyse de risque.
 Ce modèle souffre toujours du problème de la vérification trop tardive du
bon fonctionnement du système.
 Ne gère pas les activités parallèles
 Chaque livrable doit être testable
 Facile à utiliser et planifier.
 Met l’accent sur lest tests et la validation et par conséquent,
ça accroît la qualité du logiciel
 Facile à planifier dans une gestion de projets
Les avantages :
Les inconvénients :

14. V. Conclusion
En termes de conclusion, il n’est pas facile de comparer ces différents cycles de vie.
Chacun a ses forces, ses faiblesses et un cadre d’utilisation bien déterminé.
Malgré tout, nous constatons une plus grande utilisation de cycle en V par la plupart
Des équipes de développement.