Le cycle de vie en V n'existe pas

J'entends parfois : les méthodes agiles c'est bien mais chez nous on utilise encore le cycle de vie en V alors...

Un cycle de vie est un ensemble ordonné de phases décrivant la vie d’un projet, la phase n ne pouvant commencer que si la phase n-1 est terminée. Dans la représentation graphique du V, les boites s'appellent Spécification, Conception, Codage, Test et Validation pour prendre la variante la plus simple[1]. La signification du nom de ces différentes boites est à peu prés claire : Spécification on décrit le quoi, Conception le comment etc... Il s'agit des disciplines classiques du développement de logiciel.

cycle en V

Les travaux ne sont jamais séquentiels

Considérer que les boites du V correspondent aussi à des phases d'un cycle de vie revient à dire qu'elles se déroulent en séquence stricte : d'abord toute la Spécification puis toute la Conception puis tout le Codage puis tout le Test... Evidemment aucun logiciel n'a jamais été développé de cette façon strictement séquentielle. Jamais. La preuve la plus évidente concerne les travaux de Test. Quand on trouve un bug (et on en trouve) dans la "phase" de test, le minimum est de refaire des travaux de codage. Dans quelle phase ? Les 2 possibilités débouchent sur une impasse :

  • revenir en arrière dans une phase précédente, ce serait remonter dans le temps !
  • considérer que pendant la "phase" de test on fait du codage, de la conception, de la spécification en plus du test alors que c'est le nom d'autres "phases" du V, ce serait utiliser le même terme avec 2 significations différentes[2].

Le V n'est pas un cycle de vie

Plutôt que de parler du cycle de vie en V, on devrait parler de modèle en V en considérant les boites non pas comme des phases mais uniquement comme des disciplines.

J'ai dû voir la représentation du V pour la première fois en 1989[3]. Autant qu'il me souvienne, l'idée de départ du V est de montrer que le résultat d'un travail de la branche de gauche sert en entrée d'un travail le la branche de droite du V. Exemple : le document de spécification est en entrée du travail de validation, en plus de servir pour le travail de conception.

De mon point de vue, c'est une erreur d'interpréter la représentation en V comme un cycle de vie, alors qu'elle montre simplement des dépendances [4]entre des disciplines.

Le RUP

On sait depuis longtemps qu'un développement de logiciel n'est pas une suite de travaux définis à l'avance et exécutés en séquence. C'est pour cela que sont apparus le cycle en spirale, puis le RUP, ça fait déjà plus de 10 ans.

Rational Unified Process

Le RUP fait explicitement la distinction entre :

  • le cycle de vie, avec des phases et des itérations
  • les disciplines, comportant la description des rôles, produits et tâches

Pour éviter de mélanger 2 notions différentes (comme expliqué ci-dessus), les auteurs du RUP ont volontairement choisi des noms particuliers pour les phases : Inception, Elaboration, Construction et Transition, alors que les disciplines portent des noms plus classiques comme Conception, Test... Le schéma de la page d'accueil du RUP montre l'importance de la discipline pour la phase[5].

Représentation des processus

Cette séparation entre les concepts de phases et de disciplines est maintenant largement adoptée. On la retrouve, notamment, dans le méta-modèle SPEM élaboré par l'OMG pour représenter les processus.

Cette distinction apparaît très explicitement dans l'outil de représentation des processus EPF/Composer, basé aussi sur le SPEM, et dans les processus documentés avec EPF comme OpenUP.

Agilité et cycle de vie

Chaque projet a son cycle de vie. Les managers ont besoin de savoir à tout moment où on en est dans ce cycle. Pour les processus Agiles, un cycle de vie est composé des itérations (ou sprints) successives.

Même ceux qui se croient éloignés des processus Agiles (et pensent suivre le cycle en V) utilisent probablement la notion de phase avec un jalon permettant de passer à la phase suivante.



Les différences entre un processus Agile et un autre qui ne l'est pas peuvent être définies selon cette notion de phase :

  • processus pas Agile
  1. une phase[6] est définie par un objectif généralement exprimé en termes d'états de produits (documents). Cela amène à un avoir un déroulement des disciplines globalement séquentiel, mais qui essaie de prendre en compte la réalité non séquentielle des développements. Par exemple pendant la phase de Définition des besoins on fait essentiellement de la Spécification mais on peut faire du codage, par exemple pour réaliser une maquette[7]. Autre exemple pendant la phase de Test en Vraie Grandeur, on fera de la Conception et du Codage en plus du Test.
  2. une phase dure assez longtemps (quelques mois) et la durée est variable (on s'arrête normalement quand les objectifs sont atteints)
  3. il y a peu de phases (à l'extrême une seule)
  4. les phases produisent uniquement de la documentation au début et jusque assez tard dans le développement. Le logiciel testé n'est produit qu'à la fin.
  • processus Agile comme Scrum
  1. une phase (itération ou sprint) a un objectif qui porte sur des fonctionnalités et contient du travail dans toutes les disciplines[8].
  2. elle dure de 1 à 4 semaines. La durée est fixée à l'avance (notion de bloc de temps et de rythme régulier).
  3. le nombre d'itérations n'est pas fixé et peut être important
  4. chacune produit un logiciel fonctionnel (testé).

En allant au-delà de la vue réductrice et à une seule dimension montrée par le V, la distinction entre phases et disciplines peut aider à mieux appréhender les motivations qui amènent à un processus Agile.

Notes

[1] celle de Wikipedia divise la conception en 2 travaux et ajoute bizarrement Analyse des besoins et faisabilité

[2] par exemple codage devrait être compris d'un côté comme une phase et de l'autre comme un travail inclus dans la phase de test

[3] Je travaillais pour la société Verilog dont le logo était un ... V

[4] dépendance signifiant qu'une sortie d'une discipline est une entrée pour une autre

[5] Malgré cette présentation il arrive que la phase d'Elaboration du RUP soit (mal) comprise comme étant le moment où l'on ne fait que de la spécification, et celle de Construction l'unique phase où on code

[6] La plupart des entreprises ne commettent pas l'erreur de nommer ces phases comme les disciplines, on parle de phase de Définition, d'Etude...

[7] entendu en buvant une Guinness lors d'un pot avec mes collègues

[8] il arrive même qu'une personne les déroule toutes dans une seule journée

Commentaires

1. Le vendredi 26 janvier 2007, 10:46 par Jean-Paul

Enfin une explication claire sur les fondamentaux du développement. Je pense que cet article mériterait une diffusion plus large. Bravo Claude.

2. Le samedi 24 février 2007, 12:02 par claude aubry

C'est ce billet qui est le plus lu parmi ceux de mon blog : 174 lectures. Cela montre que le cycle en V est encore populaire. J'espère que je vais contribuer à son déclin...

Mise à jour le 26 mars 2007 : 359 lectures.
3. Le lundi 26 février 2007, 10:16 par Matthieu

euh... personnellement je l'ai déjà lu plusieurs fois
est-ce que ça fausse les stats ? ;o)

4. Le mardi 06 mars 2007, 15:23 par Laurence

Surtout ne pas confondre cycle en V et cycle de vie d'un développement logiciel .Effectivement le cycle de vie en V n'a jamais existé (bien expliqué au debut de l'article).Nous parlons plus de cycle de vie type Waterfall ou cycle iteratif (mais qui n'a rien avoir avec Agile ).Normalement un cycle de vie on peut le visualiser à travers un planning de taches de développement .

5. Le mercredi 07 mars 2007, 00:21 par Oaz

"Normalement un cycle de vie on peut le visualiser à travers un planning de taches de développement."

Moi j'aimerais bien voir ça ! Et j'aimerais voir aussi le "cycle iteratif (mais qui n'a rien avoir avec Agile )" !

Pour ce qui est du Waterfall, je doute encore de son existence même si certains prétendent le contraire : www.waterfall2006.com/

6. Le lundi 27 avril 2009, 10:56 par DgD

Il va falloir que toute l'éducation nationnal revoit son programme d'après ce qui est dit la dedans. Ce modèle en V est efficace pour l'apprentissage de la méthode de gestion d'un projet. Je suis d'accord pour dire que c'est asbeen.

Nous sommes quelques-uns à faire en sorte que les étudiants soient formés à l'agilité, et pas qu'au cycle en V