Cycle de vie RUP
Cette page décrit les phases et jalons du cycle de vie typique d'un projet RUP.
Relations
Description principale

Phases et jalons d'un projet

Du point de vue de la gestion de projet, le cycle de vie logiciel du processus RUP (Rational Unified Process) se décompose dans le temps en quatre phases séquentielles, chacune étant conclue par un jalon principal ; une phase correspond donc à un intervalle de temps entre deux jalons principaux. A chaque fin de phase, une évaluation est exécutée afin de déterminer si les objectifs de la phase ont été réalisés. Si le résultat de l'évaluation est satisfaisant, la phase suivante du projet peut commencer.

Planification des phases

Toutes les phases ne sont pas identiques en termes de calendrier et d'effort. En dépit d'importantes différences d'un projet à l'autre, un cycle de développement initial classique pour un projet de taille moyenne doit prévoir la répartition suivante de l'effort et du calendrier :

  création élaboration construction transition
Effort ~5 % 20 % 65 % 10%
Programme 10 % 30 % 50 % 10%

dont on peut donner la représentation graphique suivante :

Transition Construction Elaboration Création Cliquez sur une phase pour obtenir plus d'informations à son sujet

Cette répartition peut changer. Par exemple, des outils de création de code et de jeux d'essai peuvent raccourcir la phase de construction. Dans le cas d'un cycle d'évolution, les phases de création et d'élaboration sont aussi considérablement réduites puisqu'une vision basique et une architecture existent déjà.

Planification de stratégies

Cette section présente une série de patterns de cycle de vie correspondant à des profils de projets courants.

Pattern de cycle de vie : Incrémentiel

"La stratégie incrémentielle détermine les besoins des utilisateurs et définit les exigences du système, puis effectue le reste du développement en une série de constructions. La première construction intègre des parties des capacités prévues, la deuxième construction ajoute d'autres capacités, et ainsi de suite jusqu'à ce que le système soit terminé." [DOD94]

Les itérations suivantes sont caractéristiques :

  • une itération courte de création afin d'établir la portée et la vision et de définir l'étude de rentabilité
  • une seule itération d'élaboration, pendant laquelle les exigences sont définies et l'architecture établie
  • plusieurs itérations de construction, pendant lesquelles les cas d'utilisation sont réalisés et l'architecture développée en détails
  • plusieurs itérations de transition pour faire migrer le produit vers la communauté d'utilisateurs

Diagramme décrit dans le texte d'accompagnement.

Cette stratégie est appropriée quand :

  • le domaine du problème est familier.
  • les risques sont bien compris.
  • l'équipe projet est expérimentée.

Pattern de cycle de vie : Evolutif

"La stratégie évolutive diffère de la stratégie incrémentielle car elle reconnaît que les besoins des utilisateurs ne sont pas complètement compris et que toutes les exigences ne peuvent être définies dès le départ, mais qu'elles sont affinées lors de chaque construction successive." [DOD94]

Les itérations suivantes sont caractéristiques :

  • une itération courte de création afin d'établir la portée et la vision et de définir l'étude de rentabilité
  • plusieurs itérations d'élaboration, pendant lesquelles les exigences sont affinées à chaque itération
  • une seule itération de construction, pendant laquelle les cas d'utilisation sont réalisés et l'architecture étendue
  • plusieurs itérations de transition pour faire migrer le produit vers la communauté d'utilisateurs

Diagramme décrit dans le texte d'accompagnement.

Cette stratégie est appropriée quand :

  • le domaine du problème est nouveau ou non familier.
  • l'équipe est inexpérimentée.

Pattern de cycle de vie : Livraison incrémentielle 

Certains auteurs présentent également les livraisons graduelles de fonctionnalités incrémentielles au client [GIL88]. Cela peut être nécessaire lorsque le délai de mise sur le marché est serré et qu'une livraison rapide de certaines fonctions clés peut entraîner des avantages commerciaux significatifs.

Selon l'approche phase-itération, la phase de transition commence tôt et possède le plus d'itérations. Cette stratégie nécessite une grande stabilité d'architecture, ce qui est difficile à obtenir dans un cycle de développement initial, pour un système "sans précédent".

Les itérations suivantes sont caractéristiques :

  • une itération courte de création afin d'établir la portée et la vision et de définir l'étude de rentabilité
  • une seule itération d'élaboration, pendant laquelle une architecture stable est configurée
  • une seule itération de construction, pendant laquelle les cas d'utilisation sont réalisés et l'architecture développée en détails
  • plusieurs itérations de transition pour faire migrer le produit vers la communauté d'utilisateurs

Diagramme décrit dans le texte d'accompagnement.

Cette stratégie est appropriée quand :

  • le domaine du problème est familier :

    • l'architecture et les exigences peuvent être stabilisés tôt dans le cycle de développement.
    • le problème ne présente qu'un faible degré de nouveauté.
  • l'équipe est expérimentée.
  • les versions incrémentielles de fonctionnalité ont une grande valeur pour le client.

Pattern de cycle de vie : "Grande conception"

L'approche traditionnelle en cascade peut être vue comme un cas dégénéré dans lequel il n'existe qu'une itération dans la phase de construction. On l'appelle "grande conception" dans [DOD94]. En pratique, il est difficile d'éviter des itérations supplémentaires dans la phase de transition.

Les itérations suivantes sont caractéristiques :

  • une itération courte de création afin d'établir la portée et la vision et de définir l'étude de rentabilité
  • une seule itération de construction, très longue, pendant laquelle les cas d'utilisation sont réalisés et l'architecture développée en détails
  • plusieurs itérations de transition pour faire migrer le produit vers la communauté d'utilisateurs

Diagramme décrit dans le texte d'accompagnement.

Cette stratégie est appropriée quand :

  • un petit incrément d'une fonctionnalité bien définie est ajouté à un produit très stable.
  • la nouvelle fonctionnalité est bien définie et bien comprise.
  • l'équipe est expérimentée, à la fois dans le domaine du problème et par rapport au produit existant.

Pattern de cycle de vie : Stratégies hybrides

En pratique, peu de projets suivent strictement une seule et unique stratégie. Vous obtenez souvent un hybride, une évolution au départ, une construction incrémentielle et plusieurs livraisons. L'un des avantages du modèle phase-itération est qu'il permet d'adopter une approche hybride simplement en augmentant la longueur et le nombre d'itérations dans des phases spécifiques :

  • Dans le cas de domaines de problème complexes ou non familiers, où existe un degré élevé d'exploration : augmentez le nombre d'itérations dans la phase d'élaboration, ainsi que sa longueur.
  • Dans le cas de problèmes de développement plus complexes, dans lesquels la traduction de la conception au code est complexe : augmentez le nombre d'itérations dans la phase de construction, ainsi que sa longueur.
  • Pour livrer des logiciels en une série de versions incrémentielles : augmentez le nombre d'itérations dans la phase de transition, ainsi que sa longueur.


Passage d'un cycle à un autre

En passant par les quatre phases, on obtient un cycle de développement ; chaque passage par les quatre phases produit une génération du logiciel. Si le produit ne "meurt" pas, il évolue et passe à la génération suivante en répétant la même séquence des phases de création, d'élaboration, de construction et de transition, mais en ne mettant pas cette fois l'accent sur les mêmes phases. Ce type de cycle est appelé cycle d'évolution. A chaque cycle du produit, une nouvelle génération est produite.

Représentation du développement initial

Les cycles d'évolution peuvent être déclenchés par des améliorations suggérées par l'utilisateur, des changements dans le contexte utilisateur ou dans la technologie sous-jacente, une réaction à la concurrence, etc. Dans les cycles d'évolution, les phases de création et d'élaboration sont en général beaucoup plus courtes, car la définition et l'architecture du produit de base ont été déjà été déterminées au cours des précédents cycles de développement.   Certains cycles d'évolution font exception à la règle car ils contiennent une redéfinition importante du produit ou de l'architecture.