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 :
dont on peut donner la représentation graphique suivante :
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
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
Cette stratégie est appropriée quand :
-
le domaine du problème est nouveau ou non familier.
-
l'équipe est inexpérimentée.
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
Cette stratégie est appropriée quand :
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
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.
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.
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.
|