Méthode de conception

en génie logiciel :

Cycle en V

Écrit par :
Gildas SEDOU FOFE
Table des matières
1. Introduction ........................................................................................................................................................................................
2. Description du cycle en V .............................................................................................................................................................
2.1. Définition ....................................................................................................................................................................................
2.2. Étapes du cycle en V................................................................................................................................................................
a) Analyse des besoins et de faisabilité...............................................................................................................................
b) Spécifications ........................................................................................................................................................................
c) Conception préliminaire ou architecturale ....................................................................................................................
d) Conception détaillée ............................................................................................................................................................
e) Réalisation ..............................................................................................................................................................................
f) Tests Unitaires ...........................................................................................................................................................................
g) Tests d’intégration................................................................................................................................................................
h) Tests de validation ...............................................................................................................................................................
i) Tests des recettes ......................................................................................................................................................................
3. Comparaison entre Cycle en V et Méthode agile ....................................................................................................................
4. Conclusion ..........................................................................................................................................................................................
1. Introduction

Selon Wikipédia : « En ingénierie, une méthode d'analyse et de conception est un procédé qui a pour objectif
de permettre de formaliser les étapes préliminaires du développement d'un système afin de rendre ce
développement plus fidèle aux besoins du client. ».
C’est-à-dire, une méthode de conception est une technique permettant de structurer les étapes de création d’un
système (logiciel, site web, bâtiment, immeuble ….) qui résout des besoins d’un client. Ainsi le client
généralement appelé maitre d’ouvrage est porteur d’un besoin, il va donc à la rencontre d’un maitre d’œuvre,
ce dernier a pour rôle de superviser la réalisation du projet qui va satisfaire les besoins de du maitre d’ouvrage,
et pour cela il utilise une méthode de conception pour élaborer les différentes phases de réalisation de ce projet.
Parmi les différentes méthodes de conception qui existe nous avons « le modèle du cycle en V » parfois appelé
tout simplement « cycle en V ».
Selon Wikipédia le cycle en V est « issu du monde de l’industrie, et est devenue un standard de l’instructrice
logicielle depuis les années 1980 », même comme il n’est pas le plus utilisé dans le génie logiciel (car le plus
utilisé ce sont « les méthodes agiles », une autre méthode de conception), on verra que le cycle en V classé dans
la catégorie des méthodes de conceptions traditionnelles, possèdent de nombreux avantages qui peuvent
encore rivaliser avec les autres méthodes de conception en génie logiciel.

2. Description du cycle en V

Dans cette partie nous allons faire une brève description du cycle en V : méthode de conception de système
utilisé en génie logiciel.

2.1. Définition
Selon Wikipédia : « Le modèle du cycle en V est un modèle conceptuel de gestion de projet imaginé à la suite
du 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. Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis
lorsque des défauts sont détectés, afin d'améliorer le logiciel ».
C’est-à-dire, le cycle en V a été élaboré pour résoudre un problème que possédait un autre modèle : le modèle
en cascade. Cette dernière se réalisait en une succession d’étapes, chaque étape produisant un livrable (produit
final de l’étape) et si le livrable est défaillant, le modèle en
cascade ne prévoit aucune méthode de vérification de
l’efficacité des livrables.
Le cycle en V est donc venue résoudre ce problème de
validation de l’efficacité des livrables que possédait le
modèle en cascade

Schéma de la structure du Modèle en cascade source : Wikipédia

À présent nous allons décrire les étapes du cycle en V, et nous verrons que ce modèle de conception prend en
compte les validations de l’efficacité des livrables.

2.2. Étapes du cycle en V

a) Analyse des besoins et de faisabilité

Dans cette phase, le client (maitre d’ouvrage) décrit son besoin au maitre d’œuvre. Cela se passe généralement
par des interviews. Durant ces interviews c’est le client qui doit parler, il va :
- Décrire son besoin
- Dire pourquoi il a ce besoin
- Donner l’objectif du projet
- Décrire l’environnement où il a ce besoin, par EX : le client dit que les ordinateurs de son entreprise
utilise tous le système Linux
 Livrable :
le livrable ici, c’est l’élaboration de la première partie du cahier des charges (la seconde et dernière partie sera
complétée à la deuxième phase du cycle en V) dans cette première partie on mentionnera le contexte et
l’objectif du projet.

b) Spécifications

Cette phase possède deux grandes parties :

 Élaborations des spécifications fonctionnelles

Ici on répond à la question : qu’est-ce que le logiciel ou l’application doit faire ?
Donc on liste toutes les fonctionnalités de l’application.
Attention : ici on ne parle pas technique, on ne parle pas algorithmique. On dit simplement ce que le produit
doit être capable de faire, par Ex : le logiciel doit être capable d’exporter les bilans sous format Excel.
Et aussi on liste les fonctionnalités de façon consiste, par Ex : le client dit « je veux que l’application soit
capable de calculer rapidement les bilans par mois et par années et les afficher »
« rapidement » ne veut rien dire, cette spécification n’est pas concise. Le client doit préciser sa notion de
« rapidement », est ce que c’est 1seconde, 2 s ….

 Élaborations des spécifications non fonctionnelles

Ici on liste les spécifications non fonctionnelles, on a généralement :
- L’ergonomie : l’utilisabilité, lisibilité, rapidité, confort.
- La sécurité

 Livrables : les livrables ici sont :

  L’élaboration de la seconde et dernière partie du cahier des charges. On clôt le cahier des
charges avec la liste des spécifications
 Le PAQ (plan d’assurance qualité) : document qui liste les dispositions qui seront mise en
œuvre pour la réalisation d’un produit ou un service pour s’assurer de la qualité de ce dernier.
 Dossier de tests de recettes : dans ce dossier on décrit comment on fera les tests pour vérifier
que chaque fonctionnalité marche.

c) Conception préliminaire ou architecturale

Dans cette phase, plusieurs opérations seront effectuées :

- On décide de l’architecture qui sera utilisé pour notre projet. Ex : MVC, architecture 1 tier, 2 tiers ……
- on scinde le projet en module (chaque module peut être vu comme un regroupement de fonctionnalités
du système à concevoir), on représente le fonctionnement de chaque module et les différentes
interactions entre ces modules. Cela permet de savoir comment concevoir le projet par module, de sorte
que la réalisation d’un module ne gêne pas l’autre.
- On choisit les différentes technologies qu’on utilisera dans nôtre projet, et les structures de données qui
seront utilisées. Ex : fichiers, XML, Json , SQL
- On réalise les diagrammes UML d’analyse à savoir : diagramme de cas d’utilisation , séquence système,
activité, classe , Objet
- On réalise le modèle conceptuel et logique des données (MCD + MLD)

 Livrables : les livrables ici sont

 Dossier de conception préliminaire : qui contient les MCD, MLD, la liste des différents
modules, la liste des technologies à utiliser , les diagrammes UML d’analyses
 Dossier de test d’intégration : ici on décrit comment on vérifiera l’existence de chaque
module, l’interaction entre eux. On décrit comment on va vérifier qu’un module ne gêne pas un
autre.
 Références croisées: on fait un tableau a deux colonnes, où dans une colonne on a les
différentes fonctionnalités et dans l’autre les différents modules correspondants. Ceci permet de
savoir si on a oublié une fonctionnalité, et même de savoir si une fonctionnalité n’est dans
aucun module ou de savoir si un module est incomplet
 Plan d’intégration : on décrit comment on va implémenter les modules, les regrouper pour
former le produit final

d) Conception détaillée

Dans cette phase on prend les modules découpés en conception préliminaire, et on représente les diagrammes
UML de conception à savoir : les diagrammes de séquence technique, classe technique, communication, Vue
d’ensemble d’interaction, de temps. On écrit les différents algorithmes qu’on va implémenter.
 Livrables :
- cahier de conception détaillée : diagramme UML de conception + algorithme à implémenter
- dossier de tests unitaires : ici on retrouve les tests de chaque fonction de chaque classe de chaque
module. Pour vérifier que chaque classe du logiciel fonctionne comme on le veut.

NB : le terme « classe » est utiliser à titre indicatif, pour se référer au cas où on utilise une programmation
orientée objet.

e) Réalisation

Cette partie concerne le développeur, il transforme le pseudo code en vraie code dans un langage de
programmation, il implémente le MLD, il transforme les diagrammes UML en code.
 Livrables :
Ce sont les codes.

f) Tests Unitaires
On teste les fonctions des classes. Conformément au dossier des tests Unitaires. Si le test est un échec on revoit
les codes et la conception détaillée.

g) Tests d’intégration
On vérifie si les différentes classes des différents modules communiquent bien entre elles. Conformément au
dossier des tests d’intégrations. En cas d’échec on revoit la conception préliminaire.

h) Tests de validation
Ici on regarde si les différentes fonctionnalités définies dans les spécifications fonctionnelles que le client attend
fonctionnent. Ces tests seront faits par le maitre d’œuvre conformément au dossier des tests de recettes créer
dans la phase de spécifications. En cas d’échec, on revoit la phase des spécifications.

i) Tests des recettes

On donne le produit au client, il fait ses propres tests de recettes décrit dans la phase « spécification » dans son
entreprise. En cas d’échec, on doit revoir l’analyse des besoins du client et l’environnement de son entreprise.

Schéma de la structure d’un cycle en V le terme V vient de cette représentation en forme de V

3. Comparaison entre Cycle en V et Méthode agile

Éléments de comparaison Cycle en V Méthode agile

communication Pas assez de communication entre
les intervenants du projet
feedback Si le cahier des charges est
imparfait, et on se rend compte
lors des tests de recettes. Ce
feedback est trop tard
Cahier des charges statique
Mise en place et organisation Facile à mettre en place et à
organiser
Réactivité face au changement du Difficile
cahier des charges
Beaucoup de communication entre
les intervenants du projet
Feedback direct au maitre
d’ouvrage après chaque étape du
modèle.
dynamique
Cette méthode est difficile à
mettre en place
instantanée

Collaboration entre les moyenne forte

intervenants
4. Conclusion

En définitive, il était question d’exposer sur le modèle de conception en génie logiciel : Cycle en V. Il en ressort
que ce modèle a été élaborer pour résoudre le problème de manque de validation des tests sur le modèle en
cascade. Ce modèle facile à mettre en œuvre procède plusieurs étapes qui s’effectuent bien lorsque le cahier des
charges est statique et parfait. Mais si le cahier des charges est imparfait ce modèle est très mauvais. C’est pour
cela que de plus en plus ce modèle est abandonné pour les méthodes agiles qui non seulement gère le
dynamisme du cahier des charges mais aussi permet une forte collaboration entre les intervenants du projet.