Le cycle en V

Le cycle en V est une méthode d’organisation très connue dont l’origine remonte à l’industrie et qui a été adaptée à l’informatique dans les années 80. C’est l’une des premières méthodes qu’on apprend à l’école après le cycle en cascade, et elle reste toujours d’actualité.

La grande force du cycle en V, c’est qu’il définit assez précisément la manière dont les choses devraient se passer.

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.

Les différentes étapes

Le cycle en V est constitué de 8 étapes qui ont toutes leur importance.

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 ? ».

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.

Spécifications techniques

C’est une traduction des spécifications fonctionnelles en termes techniques. C’est durant l’élaboration des specs techniques que sont choisies les technologies à mettre en oeuvre pour développer le produit, et qu’est conçue l’architecture logicielle du produit.

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.

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.

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.

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.

Mise en production et 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.

La pratique

Malheureusement, si le cycle en V est limpide d’un point de vue théorique, son application réelle est très difficile. Dans une grande majorité de cas, on voit des organisations qui ressemblent plutôt à ce schéma :

La phase de conception se réduit à 2 étapes.

• Les spécifications fonctionnelles, qui représentent l’ensemble des besoins du client et/ou définissent ce que doit faire le produit fini.
• Les spécifications techniques, qui détaillent comment le produit va être réalisé techniquement.

La phase de validation contient juste 3 étapes.

• Les tests d’intégration, pendant lesquels on vérifie que l’intégralité du produit est valide techniquement.
• Les tests de validation, qui sont un mélange de tests techniques et fonctionnels, et sur lesquels le client se base souvent pour décider du lancement du produit.
• La recette, qui est utilisée pour vérifier que le produit est valide par rapport aux spécifications fonctionnelles, mais qui a tendance à n’intervenir qu’après la mise en production (ou bien elle est tronquée en pré-production, ce qui aboutit à mettre des bugs en production).

Une telle organisation possède encore des avantages structurels assez convaincants, car elle définit toujours les différentes étapes de la réalisation d’un projet. Mais bien souvent, on se retrouve en réalité avec une organisation qui ressemble plutôt à quelque chose comme ça :

Notre avis

Nous ne pensons pas qu’appliquer cette méthode de manière stricte aujourd'hui soit encore envisageable, nous voyons le cycle en V comme étant un modèle standardisé, un fonctionnement idéal vers lequel on voudra tendre. Pour faire une analogie dans le domaine des réseaux, c’est un peu comme le modèle OSI, qui décrit 7 couches réseau (depuis la couche physique jusqu’à la couche applicative) ; alors que le protocole utilisé par les trames circulant sur les réseaux Ethernet n’est constitué que de 4 couches, qui reprennent à leurs comptes les mêmes fonctions que les 7 couches définies de manière théorique.

Le plus gros problème avec le cycle en V est que dans la réalité il est quasiment impossible d’obtenir des spécifications fonctionnelles (ou techniques) qui se suffisent à elles-mêmes et qui ne seront pas impactées par la suite. C’est souvent pendant l’implémentation du produit que l’on identifie les cas limites et les problèmes conceptuels. Dans ce cas, une stricte application de cette méthode forcerait à reprendre le cycle depuis le début, en intégrant au niveau fonctionnel les remontées d’ordre technique, ce qui implique des délais conséquents.

Le manque de souplesse est au final le grand problème de cette méthode. C’est pour cela que d’autres types d’organisations sont apparues, comme les cycles itératifs et les méthodes agiles.