Objectifs de nos articles

Nos articles visent à partager avec nos lecteurs les méthodes et les pratiques que Lato Sensu Management applique tous les jours à la conduite des projets dans les secteurs bancaire, des télécoms et de la pharmacie. Ils ambitionnent également de susciter le dialogue et l'échange d'idées.

Lorsqu'un article est affublé de l'avertissement « à paraître » cela indique qu'il n'est pas disponible ou qu'il n'est pas encore finalisé.

Le « modèle en V », appliqué à l'informatique

ajax,XMLHttpRequest,asynchrone,javascript

2008-12-06 – 10:00

2008-12-31 – 20:00

2008-12-19 – 20:36

Le « modèle en V » est un modèle conceptuel d'approche à la création de logiciels. Ce modèle met en relation les différentes phases de construction des logiciels avec les phases visant à s'assurer que les exigences de départ soient parfaitement remplies.

Ce modèle est appelé « modèle en V » parce qu'il est représenté visuellement comme deux branches obliques se rejoignant à la base, à l'instar de la lettre « V ».

Sur la barre oblique descendante, à gauche, on représente les phases d'étude et d'analyse, de conception et de développement (dans certaines représentations, la phase de développement est mentionnée à la base du V).

Sur la barre oblique remontante, à droite, on représente les phases de test et d'acceptation finale.

Cycle de modèle en V

Les différentes phases représentées sur le « modèle en V » peuvent faire {{—}} font {{—}} l'objet d'une découpe plus fine qui est propre à chaque méthodologie. Dès lors, il n'est pas étonnant qu'on retrouve, dans chaque entreprise, une individualisation du « modèle en V », par exemple en découpant encore la phase des tests système en tests d'intégration au sens restreint et tests système propres, ou encore en découpant la phase de tests d'acceptation fonctionnelle en tests d'intégration au sens large et tests fonctionnels propres.

Puisque le « modèle en V » n'est rien d'autre que la liaison entre étude, réalisation et vérification, il est applicable à toute industrie. C'est une forme particulièrement didactique de la roue de Deming : P, D, C, A … Plan, Do, Check, Act, dont voici une illustration tirée de Wikipedia :

Modèle PDCA de Edward Deming empruntée à Wikipedia

Le « modèle en V » : la branche de gauche

Comme indiqué ci-avant, la branche de gauche comporte essentiellement les phases d'étude, d'analyse et de développement.

Spécification des exigences

Il s'agit de décrire ce que le système doit réaliser, ce qui doit être construit, et les contraintes qui doivent être respectées. On s'intéresse donc au what et on délaisse le how.

Les contraintes que le projet doit respecter sont également importantes à développer. Si par exemple, le système doit être construit en fonction d'une plateforme matérielle bien précise, il faut le mentionner : mainframe, Unix, Windows, … Autre type de contraintes, les contraintes légales ! Par exemple, il est peut-être impératif de terminer le projet pour respecter une date imposée par l'entrée en vigueur de nouvelles lois.

On décrit donc ce qui doit être fait et le cadre dans lequel cela doit fonctionner, au sens le plus large possible, mais de manière extensive.

À cette phase de collecte des exigences correspondra, sur la branche de droite, une phase de vérification que toute exigence est rencontrée : la phase de Tests de réception définitive (User Acceptance).

Sur une ligne de temps, on peut commencer à rédiger les tests à effectuer dès que les exigences sont décrites. Dans le cas de projets importants, si la formulation des exigences d'une partie est terminée, on peut commencer la rédaction des cas de tests (du moins si un accord est intervenu pour la partie relative au financement du projet … ce qui n'est pas nécessairement le cas).

Pour en savoir plus sur la manière qu'a Lato Sensu Management de gérer les exigences, veuillez vous reporter à l'article qui lui est consacré : Requirements Management {{—}} Gestion des exigences.

Spécifications fonctionnelles et arhitecturales

Les spécifications techniques : Le Design Study

Le développement (codage)

Cet article doit être terminé.

Le « modèle en V » : la branche de droite

Les tests unitaires

Les tests techniques

Les tests fonctionnels

Les tests d'acceptance