e Processus unifide
dveloppement logiciel
Ivar Jacobson Grady Booch James RumbaughUNIRED MODELING
LANGUAGE
DITIONS EYROLLES 61, Bld Saint-Germain 75240 Paris Cedex 05
www.editions-eyrolles.com
Table des matires
H lu, lion autorise de l'ouvrage en langue anglaise intitul I
Ongman, a Pearson Education Company, 1999, ISBN 0-201-57169-2
Traduit de l'anglais par Virginie Zam Validation technique : Jrme
Desquilbet
The Unified Software Development Process,
Avant propos Qu'est-ce qu'un processus de dveloppement logiciel
? Objectifs du livre qui s'adresse ce livre ? Approche du livre
Historique du Processus unifi L'approche Ericsson S D L : Langage
de spcification et de description Objectory L'approche de Rational
Processus Rational Objectory : 1995-1997 U M L : Unified Modeling
Language Rational Unified Process Remerciements
l 2 3 3 4 4 5 6 V 8 9 9 10 10
e r
Pour leur contribution cet ouvrage Pour leur collaboration fidle
depuis des annes Nous voudrions particulirement remercier Un
processus en marche
10 11 12 12
I proprit intellectuelle du 1 juillet 1992 interdit en effet
expressment la photocollcctif sans autorisation des ayants droit.
Or, cette pratique s'est gnralise notaml;iblissements
d'enseignement, provoquant une baisse brutale des achats de livres,
au Possibilit mme pour les auteurs de crer des uvres nouvelles et
de les faire diter BSl aujourd'hui menace. i de la loi du 11 mars
1957, i l est interdit de reproduire intgralement ou partielt
quelque support que ce soit, sans autorisation de l'diteur ou du
Centre Franais lopie, 20, rue des Grands Augustins, 75006 Paris, i
ducation Company, 1999 pour l'dition en langue anglaise our la
prsente dition, ISBN 2-212-09142-7
Table des matires
III 37 37 37 39 40
dessus unifi uoioppement logicielmu i,> 1.5.2 Les phases d'un
cycle
21 . 23
Un p r o c e s s u s pilot par l e s c a s d'utilisation 3.1 Le
dveloppement pilot par les cas d'utilisation en bref
47 49
Un processus intgrun ipiiiinr P du dveloppement logiciel : t o n
n e s , projet, produit et p r o c e s s u s I pri sonnes jouent un
rle crucial i i l es processus de dveloppement ont un impact m les
personnes i ' l r > . rles changent ' M l )CN ressources aux
travailleurs
25
27 28 28 29 30
3.2 Pourquoi les cas d'utilisation ? 3.2.1 Pour apprhender les
vritables besoins 3.2.2 Pour diriger le processus 3.2.3 Pour mettre
au point l'architecture et plus encore 3.3 Capture des cas
d'utilisation 3.3.1 Le modle des cas d'utilisation reprsente les
besoins fonctionnels 3.3.2 Les acteurs constituent l'environnement
du systme 3.3.3 Les cas d'utilisation spcifient le systme
51 51 52 54 54 54 55 56 57 57 62 62 65 67 68 70 70
| Tel projet, tel produit
32
I I lu produit ne se rsume pas du code | I Qu'es) ce qu'un
systme logiciel ? I..S.Z I .i\ artefacts i | l In systme dispose de
plusieurs modles i i H, isi-ce qu'un modle ? ( haque modle est une
vue autonome du systme ' i d Exploration d'un modle | / Relations
entre modles
32 33 33 34 35 35 36 36
3.4 L'analyse, la conception et l'implmentation pour la
ralisation des cas d'utilisation 3.4.1 Cration du modle d'analyse
partir des cas d'utilisation 3.4.2 Chaque classe doit assumer tous
ses rles de collaboration 3.4.3 Cration du modle de conception
partir du modle d'analyse 3.4.4 Les sous-systmes regroupent les
classes 3.4.5 Cration du modle d'implmentation partir du modle de
conception 3.5 Tests des cas d'utilisation 3.6 Rsum 3.7
Rfrences
Table des matires
Table des matires
V
CHAPITRE 4
Un p r o c e s s u s centr s u r l ' a r c h i t e c t u r e
,
5.3 L'approche itrative est guide par la rduction des risques
5.3.1 Les itrations attnuent lesrisquestechniques 5.3.2 Les
responsables ont la charge des risques non techniques 5.3.3 Traiter
les risques 5.4 L'itration gnrique 5.4.1 Qu'est-ce qu'une itration
? 5.4.2 Planifier les itrations 5.4.3 Squencer les itrations 5.5
Une itration se traduit par un incrment 5.6 Itrations dans le cycle
de vie
109 110 112 \YL 113 113 115 H6 116 117
4.1 L'architecture en bref 4.2 Pourquoi il nous faut une
architecture . 4.2.1 Comprendre le systme 4.2.2 Organiser le
dveloppement 4.2.3 Favoriser la rutilisation 4.2.4 Faire voluer le
systme
71 72 74 75 75 76 76 78 81 82 84 86 89
4.3 Cas d'utilisation et architecture 4.4 tapes d'laboration de
l'architecture 4.4.1 L'architecture de rfrence est un systme petit
et maigre 4.4.2 Utilisation des patterns d'architecture 4.4.3
Description de l'architecture 4.4.4 C'est l'architecte qui cre
l'architecture1
5.7 Les modles voluent partir des itrations 5.8 Les itrations
remettent en question l'organisation 5.9 Rfrences
120 121 122
PARTIE I I
4.5 Enfin, une description de l'architecture ! 4.5.1 Vue
architecturale du modle des cas d'utilisation . 4.5.2 Vue
architecturale du modle de conception 4.5.3 Vue architecturale du
modle de dploiement 4.5.4 Vue architecturale du modle
d'implmentation . . . 4.6 Trois concepts intressants 4.6.1
Qu'est-ce que l'architecture ? 4.6.2. Comment l'obtient-on ? 4.6.3
Comment la dcrit-on ? 4.7 RfrencesCHAPITRE 5
90 91 91 94 95 96 96 96 9697
Les enchanements d'activits principauxCHAPITRE 6
123125 126 127 127 132
Expression d e s besoins : de la vision aux besoins 6.1 Pourquoi
l'expression des besoins est-elle dlicate ? 6.2 Objectif de
l'enchanement d'activits des besoins 6.3 Prsentation gnrale de
l'expression des besoins
Un p r o c e s s u s itratif et incrmental 5.1 Le dveloppement
itratif et incrmental en bref 5.1.1 Procder par tapes modestes
5.1.2 Ce que n'est pas une itration
99 100 101 102
6.4 Rle des besoins dans le cycle de vie du logiciel 6.5
Comprhension du contexte du systme l'aide d'un modle du domaine
6.5.1 Qu'est-ce qu'un modle du domaine ? 6.5.2 laboration d'un
modle du domaine 6.5.3 Utilisation du modle du domaine 6.6
Comprhension du contexte du systme l'aide d'un modle du mtier 6.6.1
Qu'est-ce qu'un modle du mtier ? 6.6.2 laboration d'un modle du
mtier 6.6.3 Identification des cas d'utilisation partir d'un modle
du mtier
133 133 135 136 136 137 139 141
5.2 Pourquoi un dveloppement itratif et incrmental ? 5.2.1
Rduire les risques 5.2.2 Obtenir une architecture robuste 5.2.3
Grer les exigences de changement 5.2.4 Permettre des changements
tactiques 5.2.5 Parvenir une intgration continue 5.2.6 Accder trs
tt la connaissance
103 103 105 106 106 107 108
Table des matires
Table des matires
VII 195
6.7 Exigences supplmentaires 6.8 Rsum 6.9 RfrencesCHAPITRE 7
143 144 144
8.3 Rle de l'analyse dans le cycle de vie du logiciel
Expression d e s besoins s o u s forme de c a s d'utilisation .
. . 7.1 Introduction 7.2 Artefacts 7.2.1 Artefact : modle des cas
d'utilisation 7.2.2 Artefact : acteur 7.2.3 Cas d'utilisation 7.2.4
Artefact : description de l'architecture (vue du modle des cas
d'utilisation) 7.2.5 Artefact : glossaire 7.2.6 Artefact :
prototype d'interface utilisateur
147 147 149 149 150 151 155 155 156
8.4 Artefacts 8.4.1 Artefact : modle d'analyse 8.4.2 Artefact :
classe d'analyse 8.4.3 Artefact : ralisation-analyse de cas
d'utilisation 8.4.4 Artefact : paquetage d'analyse 8.4.5 Artefact :
description de l'architecture (vue du modle d'analyse) 8.5
Travailleurs 8.5.1 Travailleur : architecte 8.5.2 Travailleur :
ingnieur de cas d'utilisation 8.5.3 Travailleur : ingnieur de
composants 8.6 Enchanement d'activits 8.6.1 Activit : analyse
architecturale 8.6.2 Activit : analyser un cas d'utilisation 8.6.3
Activit : analyser une classe 8.6.4 Activit : analyser un paquetage
8.7 Rsum de l'analyse 8.8 RfrencesCHAPITRE 9
197 197 198 202 206 209 210 210 210 211 212 213 219 223 227 228
230
7.3 Les travailleurs 7.3.1 Travailleur : analyste systme 7.3.2
Travailleur : spcificateur de cas d'utilisation 7.3.3 Travailleur :
concepteur d'interface utilisateur 7.3.4 Travailleur :
architecte
156 156 157 158 158 159 160 169 170 176 182 186 187
Conception 9.1 Introduction 9.2 Rle de la conception dans le
cycle de vie du logiciel
231 231 232
7.4 Knchanement d'activits 7.4.1 Activit : identifier les
acteurs et les cas d'utilisation 7.4.2 Activit : dfinir un ordre de
priorit pour les cas d'utilisation 7.4.3 Activit : dtailler un cas
d'utilisation 7.4.4 Activit : prototyper l'interface utilisateur
7.4.5 Activit : structurer le modle des cas d'utilisation 7.5 Rsum
de l'enchanement d'activits des besoins 7.6 RfrencesCHAPITRE 8
233 233 234 237 240 242 243 244 245
Analyse 8.1 Introduction 8.2 L'analyse en bref 8.2.1 Pourquoi
l'analyse n'est ni la conception, ni l'implmentation... 8.2.2
Objectif de l'analyse : rsum 8.2.3 Quand employer l'analyse :
exemples concrets
189 189 192 193 194 194
9.3 Artefacts 9.3.1 Artefact : modle de conception 9.3.2
Artefact : classe de conception 9.3.3 Artefact :
ralisation-conception de cas d'utilisation 9.3.4 Artefact :
sous-systme de conception 9.3.5 Artefact : interface 9.3.6 Artefact
: description de l'architecture (vue du modle de conception) 9.3.7
Artefact : modle de dploiement 9.3.8 Artefact : description de
l'architecture (vue du modle de dploiement)
Table des matires
Table des matires
IX
CHAPITRE 11
Test 11.1 Introduction 11.2 Rle des tests dans le cycle de vie
du logiciel
311 311 312
9.4 Travailleurs 9.4.1 Travailleur : architecte 9.4.2
Travailleur : ingnieur de cas d'utilisation 9.4.3 Travailleur :
ingnieur de composants 9.5 Enchanement d'activits 9.5.1 Activit :
conception architecturale 9.5.2 Activit : concevoir un cas
d'utilisation 9.5.3 Activit : concevoir une classe 9.5.4 Activit :
concevoir un sous-systme 9.6 Rsum de la conception 9.7
RfrencesCHAPITRE 10
245 245 246 247 248 248 264 271 278 280 281 283
11.3 Artefacts 11.3.1 Artefact 11.3.2 Artefact 11.3.3 Artefact
11.3.4 Artefact 11.3.5 Artefact 11.3.6 Artefact 11.3.7 Artefact
: modle des tests : cas de test : procdure de test : composant
de test : plan des tests : anomalie : valuation des tests
313 313 314 316 317 318 318 318
Implmentation 10.1 Introduction < 10.2 Rle de l'implmentation
dans le cycle de vie du logiciel 10.3 Artefacts 10.3.1 Artefact :
modle d'implmentation 10.3.2 Artefact : composant 10.3.3 Artefact :
sous-systme d'implmentation 10.3.4 Artefact : interface 10.3.5
Artefact : description de l'architecture (vue du modle
d'implmentation) 10.3.6 Artefact : plan de construction des
intgrations 10.4 Travailleurs 10.4.1 Travailleur : architecte
10.4.2 Travailleur : ingnieur de composants 10.4.3 Travailleur :
intgrateur systme
283 284 285 285 285 288 289 291 291 293 293 294 294
11.4 Travailleurs 11.4.1 Travailleur 11.4.2 Travailleur 11.4.3
Travailleur 11.4.4 Travailleur
: concepteur de tests : ingnieur de composants : testeur
d'intgration : testeur systme
318 318 319 319 319 320 321 322 325 326 327 328 329 329
11.5 Enchanement d'activits 11.5.1 Activit : planifier les tests
11.5.2 Activit : concevoir les tests 11.5.3 Activit : implmenter
les tests 11.5.4 Activit : effectuer les tests d'intgration 11.5.5
Activit : effectuer les tests systme 11.5.6 Activit : valuer les
tests 11.6 Rsum des tests 11.7 Rfrences
PARTIE I I I
Un dveloppement itratif et incrmentalCHAPITRE 12
331333 334 335 335
10.5 Enchanement d'activits 10.5.1 Activit : implmenter
l'architecture 10.5.2 Activit : intgrer le systme 10.5.3 Activit :
implmenter un sous-systme 10.5.4 Activit : implmenter une classe
10.5.5 Activit : effectuer les tests unitaires 10.6 Rsum de
l'implmentation 10.7 Rfrences
295 296 298 301 304 305 309 309
Enchanement d'activits de l'itration gnrique 12.1 Le besoin
d'quilibre 12.2 Les phases constituent la premire division du
travail 12.2.1 La phase de cration tablit la faisabilit
Table des matires
Table des matires
XI
CHAPITRE 13
12.2.2 La phase d'laboration s'intresse la capacit de ralisation
12.2.3 La phase de construction construit le systme 12.2.4 La phase
de transition aborde l'environnement utilisateur . . . .
336 337 337 338 338 339 341 341 342 343 343
L a phase de cration lance le projet 13.1 L a phase de cration
en bref 13.2 Premiers stades de la phase de cration 13.2.1 Avant le
dbut de la phase de cration 13.2.2 Planifier la phase de cration
13.2.3 largir la vision du systme 13.2.4 Dfinir les critres
d'valuation 13.3 Enchanement d'activits de l'itration typique de
cration 13.3.1 Introduction aux cinq enchanements d'activits
principaux . . . 13.3.2 Adapter le projet l'environnement de
dveloppement 13.3.3 Identifier lesrisquescritiques
359 359 360 360 361 362 362 364 365 366 367
12.3 L'itration gnrique revisite 12.3.1 Les enchanements
d'activits principaux se rptent chaque itration 12.3.2 Les
travailleurs prennent part aux enchanements d'activits 12.4 La
planification prcde l'action 12.4.1 Planifier les quatre phases
12.4.2 Planifier les itrations 12.4.3 Penser long terme 12.4.4
Planifier les critres d'valuation
risques
345 345 346 346
13.4 Excuter les enchanements d'activits principaux : des
besoins aux tests 13.4.1 Formuler les besoins 13.4.2 Analyse 13.4.3
Conception 13.4.4 Implmentation 13.4.5 Tests 13.5 laborer l'tude de
rentabilit initiale 13.5.1 Tracer les grandes lignes de l'offre
13.5.2 Estimer le retour sur investissement 13.6 valuer les
itrations dans la phase de cration 13.7 Planifier la phase
d'laboration 13.8 lments livrer l'issue de la phase de
crationCHAPITRE 14
367 368 371 372 373 373 373 374 375 375 376 378
12.5 Lesrisquesaffectent la planification du projet 12.5.1 Grer
une liste des risques 12.5.2 Les risques affectent le plan des
itrations 12.5.3 Planifier les actions entreprendre face aux 12.6
Dfinition d'un ordre de priorit pour les cas d'utilisation 12.6.1
Risques spcifiques un produit particulier 12.6.2 Risques de crer
une architecture inadapte 12.6.3 Risque de ne pas bien comprendre
les besoins
347 348 348 349
12.7 Ressources ncessaires 12.7.1 Les projets diffrent normment
12.7.2 Voici quoi ressemble gnralement un projet 12.7.3 A projets
complexes, besoins suprieurs 12.7.4 Une nouvelle ligne de produits
exige de l'exprience 12.7.5 II faut payer le prix des ressources
utilises 12.8 valuer les itrations et les phases 12.8.1 Les critres
ne sont pas remplis 12.8.2 Les critres eux-mmes 12.8.3 L'itration
suivante 12.8.4 volution de l'ensemble des modles
350 351 352 352 353 354 355 356 356 356 357
L a phase d'laboration fabrique l'architecture de rfrence 14.1 L
a phase d'laboration en bref 14.2 Premiers stades de la phase
d'laboration 14.2.1 Planifier la phase d'laboration 14.2.2
Constituer l'quipe 14.2.3 Modifier l'environnement de dveloppement
14.2.4 Dfinir les critres d'valuation
379 379 380 380 381 381 381
Table des m a t i r e s
CHAPITRE 13 336 337 337 338 338 339
La phase de cration lance le projet13.1 L a phase de cration en
bref 13.2 Premiers stades de la phase de cration 13.2.1 Avant le
dbut de la phase de cration 13.2.2 Planifier la phase de cration
13.2.3 largir la vision du systme 13.2.4 Dfinir les critres
d'valuation 13.3 Enchanement d'activits de l'itration typique de
cration 13.3.1 Introduction aux cinq enchanements d'activits
principaux . . . 13.3.2 Adapter le projet l'environnement de
dveloppement 13.3.3 Identifier les risques critiques
359359 360 360 361 362 362 364 365 366 367
12.2.2 La phase d'laboration s'intresse la capacit de ralisation
12.2.3 La phase de construction construit le systme 12.2.4 La phase
de transition aborde l'environnement utilisateur . . . . 12.3
L'itration gnrique revisite 12.3.1 Les enchanements d'activits
principaux se rptent chaque itration 12.3.2 Les travailleurs
prennent part aux enchanements d'activits 12.4 L a planification
prcde l'action 12.4.1 Planifier les quatre phases 12.4.2 Planifier
les itrations 12.4.3 Penser long terme 12.4.4 Planifier les critres
d'valuation 12.5 Les risques affectent la planification du projet
12.5.1 Grer une liste des risques 12.5.2 Les risques affectent le
plan des itrations 12.5.3 Planifier les actions entreprendre face
aux risques 12.6 Dfinition d'un ordre de priorit pour les cas
d'utilisation 12.6.1 Risques spcifiques un produit particulier
12.6.2 Risques de crer une architecture inadapte 12.6.3 Risque de
ne pas bien comprendre les besoins
341 341 342 343 343 345 345 346 346 347 348 348 349
13.4 Excuter les enchanements d'activits principaux : des
besoins aux tests 13.4.1 Formuler les besoins 13.4.2 Analyse 13.4.3
Conception 13.4.4 Implmentation 13.4.5 Tests 13.5 laborer l'tude de
rentabilit initiale 13.5.1 Tracer les grandes lignes de 1 ' offre
13.5.2 Estimer le retour sur investissement 13.6 valuer les
itrations dans la phase de cration 13.7 Planifier la phase
d'laboration 13.8 lments livrer l'issue de la phase de cration
CHAPITRE 14
367 368 371 372 3733 7 3
373 374 375 375 376 378
12.7 Ressources ncessaires 12.7.1 Les projets diffrent normment
12.7.2 Voici quoi ressemble gnralement un projet 12.7.3 A projets
complexes, besoins suprieurs 12.7.4 Une nouvelle ligne de produits
exige de l'exprience 12.7.5 I I faut payer le prix des ressources
utilises ,
350 351 352 352 353 354
La phase d'laboration fabrique l'architecture de rfrence14.1 L a
phase d'laboration en bref 14.2 Premiers stades de la phase
d'laboration 14.2.1 Planifier la phase d'laboration 14.2.2
Constituer l'quipe 14.2.3 Modifier l'environnement de dveloppement
14.2.4 Dfinir les critres d'valuation
379379 380 380 381 381 381
12.8 valuer les itrations et les phases 12.8.1 Les critres ne
sont pas remplis 12.8.2 Les critres eux-mmes 12.8.3 L'itration
suivante 12.8.4 volution de l'ensemble des modles
355 356 356 356 357
Table des m a t i r e s
XIII
CHAPITRE 16 382 383 384 384 384 386 388 392 395 397 398 398 399
399 400 401
La phase de transition finalise le produit16.1 L a phase de
transition en bref 16.2 Premiers stades de la phase de transition
16.2.1 Planifier la phase de transition 16.2.2 Constituer l'quipe
de la phase de transition 16.2.3 Dfinir les critres d'valuation
16.3 Les enchanements d'activits principaux jouent un rle mineur
dans cette phase
419420 421 421 423 423 424
14.3 Enchanements d'activits de l'itration typique d'laboration
14.3.1 Formuler et affiner la plupart des besoins 14.3.2 Dvelopper
1 'architecture de rfrence 14.3.3 Procder des itrations tant que
l'quipe est rduite 14.4 Excuter les enchanements d'activits
principaux : des besoins aux tests 14.4.1 Formuler les besoins
14.4.2 Analyse 14.4.3 Conception 14.4.4 Implmentation 14.4.5 Tests
14.5 laborer l'tude de rentabilit 14.5.1 Prparer l'offre
commerciale 14.5.2 Actualiser le retour sur investissement 14.6
valuer les itrations de la phase d'laboration 14.7 Planifier la
phase de construction 14.8 Principaux lments livrer CHAPITRE 15
16.4 Activits de la phase de transition 16.4.1 Livrer la version
bta 16.4.2 Installer la version bta 16.4.3 Rpondre aux rsultats des
tests 16.4.4 Adapter le produit aux divers environnements
utilisateur 16.4.5 Finaliser les artefacts 16.4.6 Quand le projet
se termine-t-il ? 16.5 Achever l'tude de rentabilit 16.5.1 Matriser
la progression 16.5.2 Rviser le plan stratgique
425 425 426 426 427 429 429 429 430 430
La construction aboutit la capacit oprationnelle initiale15.1 L
a phase de construction en bref 15.2 Premiers stades de la phase de
construction 15.2.1 Constituer l'quipe de la phase 15.2.2 Dfinir
les critres d'valuation 15.3 Enchanements d'activits de l'itration
typique de construction
403403 404 405 405 406
16.6 valuer la phase de transition 16.6.1 valuer les itrations
et la phase 16.6.2 Post mortem du projet 16.7 Planifier la version
ou la gnration suivante 16.8 Principaux lments livrer CHAPITRE
17
430 431 431 432 432
Application optimale du Processus unifi17.1 L e Processus unifi
aide grer la complexit 17.1.1 Les objectifs du cycle de vie 17.1.2
L'architecture du cycle de vie 17.1.3 Capacit oprationnelle
initiale 17.1.4 Livraison du produit 17.2 Les principaux thmes
433433 434 434 435 435 435
15.4 Excuter les enchanements d'activits principaux : des
besoins aux tests 15.4.1 Besoins 15.4.2 Analyse 15.4.3 Conception
15.4.4 Implmentation 15.4.5 Tests 15.5 Matriser l'tude de
rentabilit 15.6 valuer les itrations et la phase de construction
15.7 Planifier la phase de transition 15.8 Principaux lments
livrer
408 409 410 411 413 414 416 416 417 417
17.3 Les responsables dirigent la transition vers le Processus
unifi 17.3.1 Les raisons d'agir 17.3.2 La directive de ringnierie
achve de convaincre 17.3.3 Mettre en uvre la transition
436 437 438 439
Table des m a t i r e s
17.4 Spcialiser le Processus unifi 17.4.1 Adapter le Processus
17.4.2 toffer l'infrastructure du Processus 17.5 largir le cercle
de ses interlocuteurs 17.6 Profiter des avantages qu'offre le
Processus unifi 17.7 Rfrences ANNEXE A
441 441 442 442 443 444
Avant-propos
Prsentation gnrale du langage UMLA . l Introduction A. 1.1
Vocabulaire A . 1.2 Mcanismes d'extensibilit
445445 446 446
Une croyance, qui a cours chez certains, veut que les
entreprises organisent leur activit autour d'un petit groupe
d'individus aux comptences suprieures. Ces personnes censes
connatre leur travail le feraient le plus naturellement du monde,
sans directives ni procdures internes !
A.2 Notation graphique A.2.1 lments structurels A.2.2 lments
comportementaux A.2.3 lments de regroupement A.2.4 lments
d'annotation A.2.5 Relations de dpendance A.2.6 Relations
d'association A.2.7 Relations de gnralisation A.2.8 Mcanismes
d'extensibilit A.3 Glossaire A. 4 Rfrences ANNEXE B
"
447 447 448 449 449 450 450 450 451 451 459
Croyance errone dans la plupart des cas, et qui se rvle
particulirement dommageable dans le cas du dveloppement logiciel.
Certes, les dveloppeurs logiciels connaissent leur affaire, mais la
profession est encore jeune. I l leur faut donc des directives
internes que nous dsignons, dans ce livre, sous le nom de processus
de dveloppement logiciel . En outre, le processus prsent dans ces
pages rsultant de l'association de plusieurs mthodes auparavant
indpendantes, nous nous estimons fonds le nommer Processus unifi .
Ce processus fusionne non seulement le travail des trois auteurs,
mais il intgre, en plus, les apports de nombreux autres
intervenants et entreprises ayant contribu l'laboration d'UML,
auxquels s'ajoutent un bon nombre de collaborateurs-cls de Rational
Software Corporation. Ce processus, enfin, s'enrichit, de
l'exprience du terrain de centaines d'entreprises qui utilisent
chaque jour les versions antrieures de ce processus sur des sites
clients.
Extensions du langage UML spcifiques au Processus unifi 461B. l
Introduction B.2 Strotypes B.3 Valeurs marques B.4 Notation
graphique B. 5 Rfrences ANNEEXE C 461 461 464 464 465 .
Prenons l'image d'un chef d'orchestre symphonique. Pendant un
concert, son rle se borne essentiellement donner le signal du dpart
aux musiciens et faire en sorte qu'ils restent ensemble. Mais cela
n'est possible, toutefois, que grce aux nombreuses rptitions et
parce que chacun des musiciens matrise parfaitement son instrument
et en joue indpendamment des autres musiciens de l'orchestre. De
manire plus significative pour le sujet qui nous occupe, chaque
musicien suit un processus tabli l'avance par le compositeur. C'est
la partition musicale qui fournit la base des politiques et
procdures guidant l'excution de l'uvre. Les dveloppeurs logiciels,
en revanche, ne jouent pas de faon indpendante. Ils sont en
interaction non seulement les uns avec les autres, mais aussi avec
les utilisateurs. Et ils n'ont aucune partition suivre... tant
qu'on ne leur fournit pas de processus.
Glossaire gnralC. l Introduction C.2 Termes
467467 467
Il est clair que le besoin de processus va se ressentir de plus
en plus fortement, en particulier dans les entreprises dont les
systmes informatiques jouent un rle stratgique : systmes
financiers, systmes de contrle du trafic arien, de dfense et de
tlcommunications, entre autres. Par stratgique , nous entendons que
la russite ou l'accomplissement de la mission de ces entreprises ou
services publics dpend du systme logiciel qui les sous-tend.
Avant-propos
3 Or, ces systmes se complexifient de jour en jour, alors mme
que leurs dlais de livraison ne cessent de s'amenuiser, ce qui
accrot d'autant la difficult de leur dveloppement. Toutes ces
raisons expliquent que l'industrie logicielle ait besoin d'un
processus capable de guider les dveloppeurs, tout comme un
orchestre se fonde sur la partition du compositeur pour donner des
concerts. loigns des automates sur lesquels Frederick W. Taylor
fondait sa gestion scientifique , i l y a un sicle. Le crateur du
processus doit adapter son processus notre poque, en particulier
aux ralits de l'organisation virtuelle du travail : le travail
distance par l'intermdiaire de lignes haut dbit ; la collaboration
d'actionnaires (dans les petites PME/start-ups), d'employs salaris,
de travailleurs indpendants et d'employs de SSII ; enfin, la pnurie
continuelle de dveloppeurs logiciels.
Su'est-ce qu'un processus de d v e l o p p e m e n t logiciel
?Un processus dfinit qui fait quoi quel moment et de quelle faon
pour atteindre un certain objectif. Dans le domaine de l'ingnierie
logicielle, le but consiste laborer un produit logiciel ou en
amliorer un existant. Un processus digne de ce nom doit fournir des
directives garantissant le dveloppement efficace de logiciels de
qualit et prsenter un ensemble de bonnes pratiques autorises par
l'tat de l'art. Ces dispositions permettent de rduire les risques
tout en amliorant la prvisibilit. I l s'agit, d'un point de vue
plus gnral, de promouvoir une vision et une culture communes.
Il est indispensable de trouver, entre ces quatre types de
facteurs, un quilibre capable de subsister dans le temps. Le
crateur du processus doit concevoir un processus volutif, tout
comme un dveloppeur logiciel doit faire en sorte que son systme
soit oprationnel non pas seulement aujourd'hui, mais dans les annes
venir. D'autant qu'un processus doit voluer plusieurs annes avant
d'atteindre le niveau de stabilit et de maturit qui lui permettra
de rsister la rigueur du dveloppement de produits commerciaux, tout
en maintenant un niveau raisonnable les risques lis son
utilisation. Le dveloppement d'un nouveau produit tant assez risqu
en soi, i l est inutile d'y ajouter les risques induits par un
processus insuffisamment test dans la ralit. Le processus doit donc
tre stable. Sans cet quilibre entre technologies, outils, personnes
et organisation, l'utilisation du processus serait prilleuse.
Un tel processus est indispensable et doit servir de fil
d'Ariane toutes les parties en prsence : clients, utilisateurs,
dveloppeurs et responsables. Toutefois, n'importe quel processus ne
fera pas l'affaire. I l faut absolument disposer de ce que
l'industrie est capable de produire de meilleur au moment du
dveloppement. Ce processus doit, par ailleurs, tre largement
accessible afin que toutes les personnes impliques puissent en
comprendre le rle dans le dveloppement en question. Un processus de
dveloppement logiciel doit galement pouvoir voluer pendant de
nombreuses annes, tout en hmitant sa porte ce que permet chaque
instant la ralit des technologies, des outils, des personnes et des
structures organisationnelles. Technologies. Le processus doit
reposer sur des technologies (langages de programmation, systmes
d'exploitation, systmes informatiques, capacits rseau,
environnements de dveloppement, etc.) exploitables au moment de
l'utilisation du processus. Par exemple, i l y a vingt ans, la
modlisation visuelle n'tait gure rpandue. Elle tait trop onreuse.
l'poque, la personne charge d'laborer le processus devait considrer
comme pratiquement acquis que les diagrammes seraient effectus la
main. Cette hypothse limitait considrablement les possibilits
d'intgration de la modlisation au sein du processus. Outils. Le
processus et les outils doivent tre dvelopps en parallle, ces
derniers faisant partie intgrante du processus. En d'autres termes,
un processus largement utilis peut supporter l'investissement
ncessaire la mise au point des outils le prenant en charge.
Personnes. Le crateur du processus doit limiter les comptences
ncessaires son utilisation celles que possdent dj les dveloppeurs
ou viser des comptences pouvant tre rapidement acquises. Dans bien
des domaines, i l est dsormais possible d'intgrer dans des outils
informatiss des techniques telles que la vrification de la cohrence
des modles graphiques qui rclamaient auparavant des comptences
tendues. Modles organisationnels. Si les dveloppeurs logiciels ne
jouissent pas de la mme indpendance que les membres d'un orchestre
symphonique, ils sont toutefois bien
Objectifs du livreCet ouvrage prsente le processus logiciel que
nous avions constamment l'esprit en mettant au point le langage UML
(Unified Modeling Language - Langage de modlisation unifi -). Si
UML fournit un moyen standard de visualiser, spcifier, construire,
documenter et communiquer les artefacts d'un systme logiciel
prpondrant, nous admettons, bien entendu, qu'un tel langage doit
tre utilis dans le cadre d'un processus logiciel complet. UML est
un moyen, ce n'est absolument pas une fin en soi. L'objectif est
d'obtenir une application logicielle robuste, rsistante et
volutive. Pour parvenir ce but, il faut la fois un processus et un
langage ; l'aspect processus est l'objet de cet ouvrage. L'annexe
sur UML fourme dans ce livre ne vise en aucune faon l'exhaustivit.
Vous trouverez une prsentation didactique dtaille d'UML dans Le
Guide de l'utilisateur d'UML [11], et pourrez constamment vous
rfrer au Manuel de rfrence d'UML [12].
qui s'adresse ce livre ?Le Processus unifi de dveloppement
logiciel peut tre utilis par toute personne prenant part au
dveloppement de logiciels. I l s'adresse avant tout aux membres de
l'quipe de dveloppement chargs des activits du cycle de vie que
sont la formulation des besoins, l'analyse, la conception,
l'implmentation et les tests ; en d'autres termes, des activits
produisant des modles UML. Cet ouvrage sera donc utile aux
analystes et utilisateurs finals (qui spcifient la structure et le
comportement souhaits d'un systme), aux dveloppeurs d'applications
(qui conoivent les systmes satisfaisant ces exigences), aux
programmeurs (qui transforment ces conceptions en code excutable),
aux testeurs (qui vrifient et valident la structure et le
comportement du systme), aux dveloppeurs de composants (qui crent
et cataloguent les composants), enfin aux chefs de projet et de
produit.
Avant-propos
Avant-propos
Figure P.1 Rational Unified Process 5.0
Il suppose une frquentation lmentaire des concepts orients
objet. Une exprience dans le dveloppement logiciel et la pratique
d'un langage de programmation orient objet, si elles sont
bienvenues, ne sont pas indispensables.
Vpproche du livre
Le dveloppement du Processus unifi (les versions du produit
figurent dans les rectangles).
Rational Objectory Process 4.1 1996-1997/
Plusieurs autres sources
L'approche de Rational Objectory Pr )cess 1.0-3.8 1987-
1995/
Cet ouvrage accorde une place prpondrante aux activits (besoins,
analyse et conception) sur lesquelles UML insiste en priorit. C'est
dans ce contexte que le processus permet d'tablir l'architecture de
systmes logiciels complexes. Le processus est, nanmoins, trait dans
sa totalit, bien que de faon moins dtaille. Mais c'est bien le
programme qui, en fin de compte, s'excute. Pour parvenir ce
rsultat, le projet rclame les efforts de chacun des membres de
l'quipe et le soutien des intervenants. Comme vous le verrez, ce
processus repose sur un ventail d'activits extrmement large. Un
grand nombre d'artefacts doivent tre produits et archivs, et il est
indispensable de grer toutes les activits.
UML
L'approche d'Ericsson
L'tude exhaustive du cycle de vie complet d'un processus dpasse
largement la porte d'un seul ouvrage. Pour atteindre son objectif,
un tel ouvrage devrait couvrir les directives de conception, les
modles d'artefacts, les indicateurs de qualit, la gestion de
projet, la gestion de configuration, les mtriques, et plus encore,
bien plus ! Grce l'expansion des accs en ligne, ce plus encore est
dsormais disponible et peut tre actualis sous la pression des
nouveaux dveloppements. Nous vous renvoyons donc au Rational
Unified Process, nouveau produit logiciel bas sur les technologies
du Web guidant les quipes de dveloppement vers des pratiques plus
efficaces. (Pour de plus amples informations, consultez le site
http://www.rational.com.) Parce qu'il traite intgralement le cycle
de vie logiciel, le Rational Unified Process tend le Processus
unifi au-del des questions abordes dans ce livre. I l propose, en
plus, des enchanements d'activits (workflows) qui ne sont que peu
ou pas voqus dans ces pages, comme la modlisation mtier, la gestion
de projet et la gestion de configuration.
L'approche EricssonLe Processus unifi s'enracine profondment
dans le pass. Pour reprendre les termes de Peter F. Drucker, i l
s'agit d'une innovation fonde sur des connaissances . Un vaste foss
temporel spare l'mergence d'une nouvelle technologie du moment o
elle devient utilisable , indique-t-il. I l s'coule ensuite une
longue priode avant que cette nouvelle technologie fasse son
apparition sur le march sous forme de produits, de processus ou de
services. L'une des raisons expliquant ce dcalage dans le temps est
que l'innovation fonde sur les connaissances repose prcisment sur
l'association de nombreuses connaissances et que cette maturation
demande du temps. D'autre part, les personnes charges de concrtiser
cette nouvelle ide ont, elles aussi, besoin de temps pour la digrer
et la diffuser aux autres. La premire tape de cette mise en lumire
du dveloppement progressif du Processus unifi nous ramne en 1967.
C'est cette poque qu'Ericsson modlisa le systme comme un ensemble
de blocs interconnects (appels sous-systmes en U M L et implments
sous forme de composants ). Les blocs de niveau infrieur taient
regroups en soussystmes de niveau suprieur afin d'amliorer la
capacit d'administration du systme. L'quipe d'Ericsson se fondait
sur les cas de trafic spcifis auparavant (dsormais nomms cas
d'utilisation ) pour identifier les blocs. On pouvait alors
identifier les blocs cooprant la ralisation de chacun de ces cas
d'utilisation et dterminer leur spcification propre partir de leurs
responsabilits connues. Le travail de conception se traduisait
ensuite par la mise au point d'un ensemble de diagrammes de blocs
statiques accompagns de leurs interfaces, et par leur regroupement
en sous-systmes. Ces diagrammes de blocs correspondaient
directement une version simplifie des diagrammes de classes ou
de
istorique du Processus unifiAboutissement de trois dcennies de
dveloppement et d'usage pratique, le Processus unifi doit son
quilibre cette longue volution. La figure P.l retrace la succession
des produits qui en sont issus, depuis le processus Objectory, dont
la premire version est sortie en 1987, jusqu'au Rational Unified
Process (sorti en 1998) en passant par le Rational Objectory
Process (1997). La mise au point du processus a subi diverses
influences que nous ne citerons pas toutes dans ces pages (pour la
simple raison que certaines nous sont inconnues) ; nous laissons
aux archologues du logiciel le soin de les identifier. En revanche,
nous dcrirons le retentissement qu'ont eu les approches Ericsson et
Rational sur le produit et ferons tat de plusieurs autres
sources.
Avant-propos
Avant-propos
packages UML, simplifie en ceci que les diagrammes ne montraient
que les associations utilises pour les communications.
tions de ce qu'UML appelle dsormais diagrammes de classes,
diagrammes d'activits, diagrammes de collaboration et diagrammes de
squence. SDL reprsentait donc un standard spcialis de modlisation
objet. Ce langage, rgulirement actualise, est encore utilise par
plus de 10 000 dveloppeurs et pris en charge par diffrents diteurs.
Mis au point i l y a plus de vingt ans, une poque o la modlisation
objet manquait de maturit, SDL tait trs en avance sur son temps. I
l est vraisemblable qu'il sera finalement supplant par UML,
standardis depuis novembre 1997.
Le premier produit des activits de conception tait une
description de l'architecture logicielle, fonde sur la comprhension
des besoins essentiels. Ce document dcrivait brivement tous les
blocs et leur regroupement en sous-systmes. Un ensemble de
diagrammes de blocs montrait les blocs et leurs interconnexions,
qui transmettaient des signaux, c'est-dire un type de message. Tous
ces messages taient dcrits un un dans une bibliothque de messages.
La description de l'architecture logicielle et la bibliothque des
messages constituaient les documents cls qui devaient, non
seulement guider le travail de dveloppement, mais galement prsenter
le systme aux clients. l'poque (1968), les clients n'avaient pas
l'habitude de dcouvrir un produit logiciel sous forme de plan
d'laboration. Pour chaque cas d'utilisation, les ingnieurs
prparaient soit un diagramme de squence, soit un diagramme de
collaboration. Ces diagrammes (amliors dans UML) montraient la faon
dont les blocs communiquaient dynamiquement pour raliser le cas
d'utilisation. Ils laboraient une spcification sous forme de graphe
d'tats (ne comprenant que les tats et les transitions). Cette
approche d'une conception fonde sur des blocs ayant une interface
parfaitement dfinie tait primordiale pour la russite des projets. I
l suffisait, ensuite, pour crer une nouvelle configuration du
systme (par exemple, pour un nouveau client), de remplacer un bloc
par un autre fournissant les mmes interfaces. Les blocs n'taient
pas de simples sous-systmes ni des composants base de code source.
Ils taient compils en blocs excutables, installs un un sur la
machine cible, et fonctionnaient avec les autres blocs excutables.
Chaque nouveau bloc excutable ou chaque bloc modifi devait pouvoir
tre install dans un systme relayant des appels tlphoniques, sans
ncessiter la moindre interruption de service. On ne peut en effet
raisonnablement pas interrompre un systme de ce type pour procder
de simples changements. Ce serait comme changer les pneus d'une
voiture lance 100 kilomtres l'heure. En substance, l'approche
utilise tait ce que l'on appelle aujourd'hui le dveloppement base
de composants. Ivar lacobson est l'origine de cette mthode de
dveloppement. C'est lui qui en a guid l'volution, au cours des
annes qui ont prcd la priode Objectory, pour en faire un processus
de dveloppement logiciel.
ObjectoryEn 1987, Ivar Jacobson quittait Ericsson pour fonder
Objectory AB Stockholm. Lui et ses associs passrent les huit annes
suivantes concevoir un processus en tant que produit, appel
Objectory (contraction de Object Factory ), qu'ils tendirent des
domaines autres que les tlcommunications et exportrent en dehors de
la Sude. S'il figurait dj dans les travaux effectus chez Ericsson,
le concept de cas d'utilisation reut alors son nom dfinitif
(introduit lors de la confrence OOPSLA de 1987). Une technique
d'laboration de diagrammes fut mise au point et cette notion fut
largie pour accueillir une large gamme d'applications. I l devint
alors vident que les cas d'utilisation devaient piloter le
dveloppement. De mme que s'imposa l'ide que c'est l'architecture
qui doit guider les dveloppeurs et permettre d'informer les divers
intervenants. Les enchanements d'activits successifs taient
reprsents par une srie de modles : modles des besoins avec des cas
d'utilisation, modles d'analyse, de conception, d'implmentation et
de test. Un modle offre un point de vue sur un systme. Les
relations unissant les diffrents modles taient capitales, car elles
permettaient aux dveloppeurs de suivre une caractristique d'un bout
l'autre d'une srie de modles. En fait, la traabilit devint un
pralable tout dveloppement pilot par les cas d'utilisation. Les
dveloppeurs pouvaient suivre l'volution d'un cas d'utilisation
travers toute la squence de modles jusqu'au code source et, en cas
de problme, revenir en arrire. Le dveloppement du processus
Objectory s'est traduit par une srie de versions, depuis Objectory
1.0 sorti en 1988, la premire version en ligne, Objectory 3.8, en
1995 (vous trouverez une prsentation d'Objectory dans [2]). Il est
important de noter que le produit Objectory en lui-mme fut bientt
envisag comme un systme. Cette faon de dcrire le processus comme un
produit systme facilitait considrablement la mise au point une
nouvelle version d'Objectory partir d'une version prcdente, et le
rendait plus modulable aux besoins particuliers de telle ou telle
entreprise. Le fait que le processus de dveloppement du logiciel
Objectory lui-mme faisait l'objet d'une conception rationnelle
suffisait le rendre unique. L'exprience acquise dans le
dveloppement d'Objectory permit galement de mieux comprendre
comment thoriser les processus sur lesquels repose un mtier quel
qu'il soit. Les mmes principes pouvaient s'appliquer et furent
intgrs dans un livre paru en 1995 [3].
>DL : Langage de spcification et de descriptionCette priode
fut marque par la sortie, en 1976, de SDL (Spcification and
Description Language - Langage de spcification et de description)
pour le comportement fonctionnel des systmes de tlcommunications.
Mis au point par le CCITT (organisme international charg de la
standardisation dans le domaine des tlcommunications) et nettement
influenc par l'approche Ericsson, ce standard dfinissait un systme
comme un ensemble de blocs interconnects communiquant les uns avec
les autres par l'intermdiaire exclusif de messages (nomms signaux
dans ce standard). Chaque bloc possdait un ensemble de processus ,
terme SDL pour dsigner les classes actives. De faon assez similaire
aux classes du paradigme orient objet, un processus tait dot
d'instances qui dialoguaient par le biais de messages. Cette mthode
proposait des diagrammes qui taient des spcialisa-
Avant-propos
Avant-propos
ipproche de RationalRational Software Corporation ayant acquis
Objectory AB l'automne 1995, la tche consistant unifier les
principes de base sous-jacents aux processus de dveloppement
logiciel existants s'est faite plus urgente. Rational avait mis au
point un certain nombre de pratiques de dveloppement logiciel, qui
compltaient, pour l'essentiel, celles dfinies dans Objectory.
Ainsi, en 1981, Rational s'est mis produire un environnement
interactif capable d'amliorer la productivit pour le dveloppement
de systmes informatiques d'envergure , rappelaient James E. Archer
et Michael T. Devlin en 1986 [4]. Us insistaient sur l'importance
des notions de conception oriente objet, d'abstraction, de masquage
des informations, de rutilisabilit et de prototypage. S'il existe
des dizaines d'ouvrages, d'articles et de documents internes
retraant les dveloppements de Rational depuis 1981, la contribution
majeure au processus est sans doute la prpondrance accorde
l'architecture et au dveloppement itratif. En 1990, Mike Devlin
rdigeait un article visionnaire dcrivant un processus de
dveloppement itratif pilot par l'architecture, tandis que Philippe
Kruchten, charg de la pratique architecturale au sein de Rational,
signait divers articles sur l'approche itrative et l'architecture.
Nous citerons l'un de ces papiers, qui envisageait une
reprsentation de l'architecture selon quatre points de vue :
logique, processus, physique et dveloppement, auxquels s'ajoutait
un autre point de vue illustrant les quatre prcdents l'aide de cas
d'utilisation ou de scnarios |6). L'intrt d'avoir une diversit de
points de vue au lieu de chercher tout intgrer dans un seul type de
diagramme, s'est impos Philippe Kruchten au gr de son exprience sur
d'importants projets. Cette multiplicit de points de vue permettait
aux intervenants comme aux dveloppeurs d'identifier, dans la vue
approprie, ce dont ils avaient besoin pour atteindre leurs
diffrents objectifs.
Processus Rational Objectory : 1995-1997 l'poque de la fusion,
Objectory 3.8 avait montr comment pouvait tre mis au point et
modlis un processus de dveloppement logiciel sous forme de produit,
jetant ainsi les bases de l'architecture originale d'un processus
de dveloppement logiciel. Un ensemble de modles avait t identifi,
qui devait recueillir les rsultats du processus. Si celui-ci tait
au point dans des domaines tels que la modlisation par les cas
d'utilisation, l'analyse et la conception, i l montrait quelque
faiblesse dans la gestion des besoins autre que les cas
d'utilisation, dans l'implmentation et les tests. Par ailleurs, i l
n'abordait que sommairement la gestion de projet et de
configuration, le dploiement et la prparation de l'environnement de
dveloppement (acquisition d'outils et de procds). Le fruit de
l'exprience de Rational et les pratiques mises en uvre, notamment
les phases et l'approche itrative contrle, sont venus s'ajouter
pour former le Rational Objectory Process 4.1. L'architecture y
faisait l'objet d'une description prcise (la bible de toute quipe
de dveloppement logiciel), occupait une place centrale dans le
systme lui-mme et tait dpeinte par les diffrentes vues
architecturales des modles. Le dveloppement itratif partait d'un
concept relativement gnral pour aboutir une approche guide par la
rduction des risques qui plaait l'architecture au premier plan.
UML, dont les auteurs du prsent ouvrage sont l'origine de la
cration, tait alors en cours de dveloppement et servait de langage
de modlisation au Rational Objectory Process. L'quipe de
dveloppement, dirige par Philippe Kruchten, compensa certaines des
faiblesses du Rational Objectory Process en renforant la gestion de
projet, notamment partir des contributions de Royce [8].
UML : Unified Modeling LanguageDepuis quelque temps dj, le
besoin d'un langage visuel uniforme et cohrent pour exprimer les
rsultats des mthodes orientes objet encore en usage dans les annes
1990 tait devenu vident.
Certains ont peru le dveloppement itratif comme quelque peu
chaotique, voire anarchique. Au contraire, l'approche en quatre
phases (cration , laboration, construction et transition) a t conue
pour permettre une meilleure structuration et un contrle plus
rigoureux de la progression pendant l'itration. Ces phases imposent
un ordre aux itrations. La planification dtaille des phases et
l'ordonnancement des itrations au sein de ces phases rsultent d'un
effort concert de Walker Royce et Rich Reitman, avec la
participation ininterrompue de Grady Booch et de Philippe
Kruchten.1
Aux avant-postes ds les dbuts de Rational, Grady Booch formula
dans l'un de ses ouvrages paru en 1996 deux principes premiers
reposant sur l'architecture et l'itration : Un style de
dveloppement guid par l'architecture est, en gnral, la meilleure
approche pour la cration de projets complexes logiciel prpondrant.
Pour russir, un projet orient objet doit suivre un processus
incrmental et itratif [7].
Au cours de la mme priode, Grady Booch mettait au point la
mthode Booch [9], tandis que James Rumbaugh laborait, au Centre de
recherche et de dveloppement de General Electric, la mthode OMT
(Object Modeling Technique) [10]. Lorsque ce dernier rejoignit
Rational en 1994, tous deux s'engagrent, en association avec des
clients de Rational, dans un processus d'unification de leurs
mthodes. La version 0.8 de la Mthode Unifie (Unified Method 0.8)
sortit en octobre 1995, l'poque o Ivar Jacobson intgrait son tour
Rational. Cette collaboration trois donna naissance la version 0.9
d'UML (Unified Modeling Language). D'autres spcialistes des mthodes
furent bientt mis contribution, ainsi que plusieurs socits, telles
qu'IBM, HP et Microsoft, qui participrent l'mergence de ce
standard. En novembre 1997, l'issue du processus de
standardisation, la version 1.1
ni appele phase d'inception
Avant-propos j Avant-propos
11
d'UML fut adopte comme standard par l'OMG (Object Management
Group). Pour de plus amples informations, consultez le Guide de
l'utilisateur [11] et le Manuel de rfrence [11]. UML a t utilis
pour tous les modles du Rational Objectory Process.
Patrik Jonsson a puis dans la documentation du Rational
Objectory Process et en a class les lments extraits selon l'ordre
des chapitres envisags. Il a galement pris part l'laboration des
exemples et a suggr nombre d'ides sur la meilleure faon de prsenter
le Processus unifi. Ware Myers a particip la rdaction de cet
ouvrage et en a traduit les premiers brouillons en une prose plus
lisible.
National Unified ProcessDans le mme temps, Rational se lanait
dans une politique de fusion-acquisition de socits ditrices de
logiciels. Chacune d'entre elles contribua, dans son champ
d'expertise, au dveloppement du processus Rational Objectory :
Requisite Inc. communiqua son exprience de la gestion des besoins ;
SQA Inc. avait mis au point un processus de tests accompagnant son
outil de test qui s'ajouta la longue exprience de Rational dans ce
domaine ; Pure-Atria apporta sa connaissance de la gestion de
configuration qui vint renforcer celle de Rational en la matire ;
Performance Awareness ajouta les tests de performances et de charge
; Enfin, Vigortech fournit ses comptences en matire d'ingnierie des
donnes. Le processus s'enrichit galement d'un nouvel enchanement
d'activits pour la modlisation mtier (cf. [3]) permettant de driver
les besoins partir des processus mtier que devait servir le
logiciel, et fut largi la conception d'interfaces utilisateur
guides par les cas d'utilisation ( partir de travaux effectus chez
Objectory AB). Ds le milieu de l'anne 1998, le Rational Objectory
Process tait devenu un processus complet, capable de prendre en
charge la totalit du cycle de vie du dveloppement logiciel. Ce
travail permit d'unifier les diverses contributions, non seulement
des trois auteurs de cet ouvrage, mais aussi des nombreuses sources
auxquelles ont puis Rational et UML. En juin, Rational lana une
nouvelle version du produit, Rational Unified Process 5.0 [13]. Un
grand nombre d'lments de ce processus propritaire entrent
aujourd'hui dans le domaine public grce au prsent ouvrage. Le
changement de nom rend compte du fait que l'unification s'est opre
deux niveaux : d'une part, unification des approches de
dveloppement l'aide d'UML, de l'autre, unification du travail de
nombreux spcialistes des mthodes, employs par Rational et sur les
centaines de sites clients ayant utilis le processus pendant
plusieurs annes.
Parmi les rviseurs, nous tenons avant tout remercier Kurt
Bittner, Cris Kobryn et Earl Ecklund, Jr., mais aussi Walker Royce,
Philippe Kruchten, Dean Leffingwell, Martin Griss, Maria Ericsson
et Bruce Katz pour la qualit et la pertinence de leurs
commentaires. L'quipe des rviseurs comprenait galement Pete
McBreen, Glenn Jones, Johan Galle, N. Venu Gopal, David Rine, Mary
Loomis, Marie Lenzi, Janet Gardner et quelques anonymes, qui nous
tmoignons notre reconnaissance. Nous remercions Terry Quatrani, de
Rational, qui a parfait le style des chapitres 1 5, ainsi que Karen
Tongish, qui a corrig les preuves de tout le livre. Enfin, nous
sommes redevables Stefan Bylund pour sa revue de dtail de l'ouvrage
et ses nombreuses suggestions formelles,finalementintgres dans le
livre. Son intervention a largement contribu l'amlioration de la
qualit du livre.
Pour leur collaboration fidle depuis des annes
emerciementsUn projet d'une telle ampleur ne peut qu'tre le
fruit d'un travail collectif et nous souhaitons rendre hommage
nommment tous ceux qui, nombreux, y ont contribu.
our leur contribution cet ouvrageBirgitte L0nvig a labor le
premier exemple de l'ouvrage, celui du systme interbancaire,
qu'elle a men son terme en en crant tous les modles.
Nous voulons galement manifester notre reconnaissance tous ceux
qui, aufildes annes, nous ont aid mettre sur pied le processus et
ont accompagn notre travail sous ses divers aspects. Nous
remercions en particulier les personnes suivantes : Stefan
Ahlquist, Ali Ali, Gunilla Andersson, Kjell S. Andersson, Sten-Erik
Bergner, Dave Bernstein, Kurt Bittner, Per Bjork, Hans Brandtberg,
Mark Broms, Stefan Bylund, Ann Carlbrand, Ingemar Carlsson,
Margaret Chan, Magnus Christerson, Geoff Clemm, Catherine Connor,
Hakan Dahl, Stphane Desjardins, Mike Devlin, Hakan Dyrhage, Suzanne
Dyrhage, Staffan Ehnebom, Christian Ehrenborg, Maria Ericsson,
Gunnar M . Eriksson, Iain Gavin, Carlo Goti, Sam Guckenheimer,
Bjorn Gullbrand, Sunny Gupta, Marten Gustafsson, Bjorn Gustafsson,
Lars Hallmarken, David Hanslip, Per Hedfors, Barbara Hedlund,
Jorgen Hellberg, Joachim Herzog, Kelli Houston, Agneta Jacobson,
Sten Jacobson, Paer Jansson, Hakan Jansson, Christer Johansson,
Ingemar Johnsson, Patrik Johnsson, Dan Jonsson, Bruce Katz, Kurt
Katzeff, Kevin Kelly, Anthony Kesterton, Per Kilgren, Rudi Koster,
Per Kroll, Ron Krubeck, Mikael Larsson, Bud Lawson, Dean
Leffingwell, Rolf Leidhammar, Hakan Lidstrom, Lars Lindroos,
Fredrik Lindstrom, Chris Littlejohns, Andrew Lyons, Jas Mahur,
Bruce Malasky, Chris McClenaghan, Christian Meck, Sue Mickel, Jorma
Mobrin, Christer Nilsson, Rune Nilsson, Anders Nodin, Jan-Erik
Nodin, Roger Oberg, Benny Odenteg, Erik Ornulf, Gunnar Overgaard,
Karin Palmkvist, Fabio Peruzzi, Janne Pettersson, Gary Pollice,
Tonya Prince, Leslee Probasco, Terry Quatrani, Anders Rockstrom,
Walker Royce, Goran Schefte, Jeff Schuster, John Smith, John Smith,
Kjell Sorme, Ian Spence, Birgitta Spiridon, Fredrik Stromberg,
Goran Sundelof, Per Sundquist, Per-Olof Thysselius, Mike Tudball,
Karin Villers, Ctirad Vrana, Stefan Wallin, Roland Wester, Lars
Wetterborg, Brian White, Lars Wiktorin, Charlotte Wranne et Jan
Wunsche.
Avant-propos
2
Nous dsirons aussi exprimer toute notre gratitude aux personnes
suivantes pour leur indfectible soutien depuis des annes : Dines
Bjorner, Tore Bingefors, Dave Bulman, Larry Constantine, Goran
Hemdal, Bo Hedfors, Tom Love, Nils Lennmarker, Lars-Olof Noren,
Dave Thomas et Lars-Erik Thorelli.
Partie
I
Nous voudrions particulirement
remercier
Mike Devlin, prsident de Rational Software Corporation, qui a
cru en l'intrt du processus Objectory pour tout type de
dveloppement logiciel et en l'utilisation d'un processus logiciel
efficace comme pierre de touche du dveloppement d'outils
informatiques. Enfin, nous adressons nos remerciements Philippe
Kruchten, directeur du Rational Unified Process, et tous les
membres de l'quipe du processus de Rational, qui ont su associer
les atouts d'Objectory aux bonnes pratiques de Rational et la
mthode UML, tout en prservant la valeur de chacun de ces lments.
Cet objectif serait demeur inaccessible sans l'engagement personnel
et la persvrance de Philippe Kruchten dans l'laboration de ce que
l'on peut, en toute modestie, qualifier de meilleur processus
logiciel existant ce jour.
L e de
P r o c e s s u s
u n i f i logiciel
d v e l o p p e m e n t
Chapitre 1.
Le Processus unifi : pilot par les cas d'utilisation, centr sur
l'architecture, itratif et incrmental Les quatre P du dveloppement
logiciel : personnes, projet, produit et processus Un processus
pilot par les cas d'utilisation Un processus centr sur
l'architecture Un processus itratif et incrmental
Un processus en marcheCet ouvrage et ceux qui viennent le
complter, les versions en ligne et les outils contribuent la
maturation du processus. Le Processus unifi s'inspire denombreuses
sources. Dj trs largement utilis, il fournit aux cadres de
direction, aux dveloppeurs et aux intervenants de toute sorte un
moyen de comprhension unique du processus.
Chapitre 2.
Chapitre 3. Chapitre 4. Chapitre 5.
Il reste, toutefois, beaucoup faire : i l faut que les
dveloppeurs harmonisent leurs techniques de travail, avec, bien
entendu, les encouragements des divers intervenants et
responsables. Pour beaucoup d'entreprises, cette petite rvolution
n'est qu'une perspective lointaine. A vous de la faire advenir.
Ivar Jacobson Palo Alto, Californie Dcembre 1998
[email protected]
La premire partie introduit les principales ides qui sont
exposes tout au long de ce livre. Dans le chapitre 1, nous dcrivons
brivement le Processus unifi de dveloppement logiciel, en insistant
sur le fait qu'il est pilot par les cas d'utilisation, centr sur
l'architecture, itratif et incrmental. Le processus dcrit dans ces
pages utilise le langage U M L (Unified Modeling Language), qui
gnre des graphiques comparables, par leur contenu, aux plans
d'laboration depuis longtemps en usage dans d'autres disciplines
techniques, et fait reposer l'essentiel d'un projet de dveloppement
sur des composants rutilisables, c'est--dire des fragments
logiciels disposant d'une interface clairement dfinie. Le chapitre
2 prsente la thorie des quatre P : personnes, projet, produit et
processus, et en dcrit les relations, absolument essentielles la
comprhension de cet ouvrage. De mme, le processus trait dans ce
livre ne saurait tre apprhend sans les concepts fondamentaux
d'artefact, de modle, de travailleur et d'enchanement
d'activits
( workfiow ). Le chapitre 3 aborde plus en dtail la notion de
dveloppement pilot par les cas d'utilisation. Les cas d'utilisation
constituent un moyen d'identifier les vritables besoins et de les
utiliser pour orienter tout le processus de dveloppement. Le rle de
l'architecture dans le Processus unifi est expliqu au chapitre 4 :
l'architecture tablit ce qui doit tre fait. Elle met en place les
diffrents niveaux de l'organisation du logiciel et s'attache crer
le squelette du systme. Le chapitre 5 insiste sur la ncessit
d'adopter une approche itrative et incrmentale pour le dveloppement
logiciel. Ce qui signifie, en pratique, de se confronter en premier
heu aux parties les plus incertaines du systme, de dfinir trs tt
une architecture stable, puis d'aborder les parties les plus
routinires par des itrations successives, chacune conduisant
l'laboration d'un incrment jusqu' la version finale. La deuxime
partie va plus en profondeur. Un chapitre est consacr chacun des
principaux enchanements d'activits : expression des besoins,
analyse, conception, implmentation et tests. Ces enchanements
formeront, dans la troisime partie, l'essentiel des activits
effectues au cours des diverses itrations des quatre phases qui
composent le processus. Dans la troisime partie, nous dcrivons de
faon concrte l'excution des tches dans chaque phase : laboration
d'une tude de rentabilit dans la phase de cration ; mise en place
de l'architecture et d'un plan dans la phase d'laboration;
transformation de l'architecture en un systme livrable dans la
phase de construction ; enfin, vrification du fonctionnement
correct du systme au sein de l'environnement utilisateur dans la
phase de transition. Nous rutilisons, dans cette partie, les
principaux enchanements d'activits, que nous associons de faon
spcifique chaque phase, afin de parvenir aux rsultats souhaits.
Le Processus unifi : pilot par les cas d'utilisation, centr sur
l'architecture, itratif et incrmentalLa tendance, aujourd'hui, en
matire de logiciel est la cration de systmes de plus en plus
imposants et complexes. Cette orientation s'explique, en partie,
par la rapide monte en puissance des ordinateurs, qui a pour effet
d'accrotre les attentes des utilisateurs. Autre influence
dterminante, l'utilisation croissante de l'Internet pour l'change
de toute sorte d'informations, du texte simple aux documents
multimdias, en passant par les diagrammes et le texte mis en forme
et dot d'images. Notre soif de logiciels de plus en plus
sophistiqus s'aiguise au gr des annonces prcdant les sorties de
produits : nous voulons des logiciels plus adapts nos besoins,
exigence qui, son tour, augmente la complexit du logiciel. En bref,
il nous en faut toujours plus. Il faut aussi que tout aille plus
vite. Le dlai de mise sur le march est un autre facteur dcisif.
Mais la satisfaction de tels objectifs n'est pas des plus simples.
Le mode de dveloppement des logiciels ne concorde pas avec nos
exigences de logiciels puissants et complexes. Aujourd'hui, la
plupart des entreprises dveloppent des logiciels en utilisant les
mmes mthodes qu'il y a vingt-cinq ans, ce qui pose videmment un
problme. On ne peut prtendre raliser les logiciels complexes que
rclament les clients sans actualiser les mthodes qui prsident leur
dveloppement. Tout le problme du dveloppement logiciel se rsume, en
fin de compte, la difficult qu'prouvent les dveloppeurs concilier
les diffrents aspects qu'implique tout projet informatique
d'envergure. Les quipes de dveloppement ont besoin d'une mthode de
travail contrle, d'un processus intgrant les diverses facettes du
dveloppement et d'une approche commune, c'est--dire d'un processus
capable : de dicter l'organisation des activits de l'quipe ;
Cependant, l'objectif sous-jacent que poursuit une entreprise
n'est videmment pas de possder un bon systme informatique , mais
d'exploiter les processus mtier (ou les systmes intgrs) pour
rpondre au mieux la demande du march et acclrer la production de
biens et de services de qualit un prix raisonnable. Les systmes
logiciels sont l'arme stratgique qui permet aux entreprises et
administrations de raliser de considrables conomies de cots et de
temps de production dans les secteurs secondaire et tertiaire. I l
est impossible de ragir promptement la dynamique du march sans
avoir, au pralable, mis en place des processus efficaces au sein de
l'entreprise. Dans une conomie mondialise, en marche vingt-quatre
heures sur vingt-quatre, sept jours sur sept, la plupart de ces
processus seraient inoprants sans logiciels. La matrise d'un
processus efficace de dveloppement logiciel est, par consquent,
devenue un facteur incontournable dans le succs d'une
entreprise.
lygU t L f l
Le Processus u n i f i de d v e l o p p e m e n t PARTIE I
logiciel
Le Processus u n i f i CHAPITRE 1 I
de diriger les tches de chaque individu et de l'ensemble de
l'quipe ; de spcifier les artefacts produire ; de proposer des
critres pour le contrle et l'valuation des produits et des activits
du projet.
P du dveloppement logiciel : personnes, projet, produit et
processus. Nous consacrerons, ensuite, un chapitre chacune des
trois ides fondamentales. Ces chapitres formeront la premire partie
de l'ouvrage. Les deuxime et troisime parties, qui constituent le
cur de l'ouvrage, dcriront en dtail les diffrents enchanements
d'activits du processus.
1.2 Le Processus unifi est pilot par les cas
d'utilisationL'objectif d'un systme logiciel est de rendre service
ses utilisateurs. Pour russir la mise au point d'un systme, i l
importe, par consquent, de bien comprendre les dsirs et les besoins
de ses futurs utilisateurs.
L'existence d'un processus clairement dfini et parfaitement gr
est l'un des lments cls opposant les projets ultra-productifs aux
projets infructueux. (Pour connatre les autres raisons de la
ncessit d'un processus, consultez la section 2.4.4.) Aboutissement
de plus de trente ans d'exprience, le Processus unifi de
dveloppement logiciel offre une solution au problme du dveloppement
informatique. Ce chapitre propose une vision d'ensemble du
Processus unifi, tandis que les chapitres suivants examinent en
dtail chacun de ses lments.
1.1 Le Processus unifi en brefAvant toute chose, le Processus
unifi est un processus de dveloppement logiciel, c'est-dire qu'il
regroupe les activits mener pour transformer les besoins d'un
utilisateur en systme logiciel (voir figure 1.1). Mais c'est plus
qu'un simple processus. C'est un framework de processus gnrique
pouvant tre adapt une large classe de systmes logiciels, diffrents
domaines d'application, diffrents types d'entreprises, diffrents
niveaux de comptence et diffrentes tailles de projets.
Le terme utilisateur ne dsigne pas seulement les utihsateure
humains, mais galement d'autreji^ystmes. Dans ce sens,
l'utilisateur reprsente une personne ou une chose (telle qu'un
systme autre que le systme propos) dialoguant avec le systme en
cours de dveloppement. D peut s'agir, par exemple, d'un tre humain
utilisant un distributeur automatique de billets (DAB). La personne
insre sa carte magntique, rpond aux questions que lui pose la
machine par l'intermdiaire de son cran de visualisation, et reoit
une somme d'argent liquide. Le systme ragit l'insertion de la carte
de l'utilisateur et ses rponses en effectuant une squence d'actions
(Annexe A) qui fournissent l'utilisateur un rsultat tangible, en
l'occurrence un retrait de liquide.
Figure 1.1 lin processus de dveloppement loyit ici.
Besoins de l'utilisateur
Processus de d v e l o p p e m e n t logiciel
Systme logiciel
Le Processus unifi est base de composants, ce qui signifie que
le systme logiciel en cours de fabrication est fait de composants
logiciels (Annexe A) relis les uns aux autres par des interfaces
clairement dfinies (Annexe A). Le Processus unifi utilise le
langage UML (Unified Modeling Language) pour la cration des plans
d'laboration et de construction du systme logiciel. En fait, UML
fait partie intgrante du Processus unifi : l'un et l'autre ont t
dvelopps de concert. Nanmoins, les traits vritablement distinctifs
du Processus unifi tiennent en trois expressions cls : pilot par
les cas d'utilisation, centr sur l'architecture, itratif et
incrmental. Voil ce qui en fait toute l'originalit.
Ce type d'interaction est appel cas d'utilisation (Annexe A ;
voir galement le chapitre 3). Un c^^^tOwationi est une
fonctionnalit du systme produisant un rsultat satisfaisant pour
l'utilisateur. Les cas d'utilisation saisissent les besoins
fonctionnels et leur ensemble constitue le modle des cas
d'utilisation (Annexe B ; voir aussi la section 2.3), qui dcrit les
fonctionnalits compltes du systme. Ce modle remplace la classique
spcification fonctionnelle du systme, qui rpondait la question
suivante : qu'est cens faire le systme ? On peut caractriser la
stratgie des cas d'utilisation en ajoutant la fin de cette question
les trois mots suivants : pour chaque utilisateur ? Ces trois mots
ont une implication majeure. Ils nous obligent rflchir en termes
d'avantages pour les utilisateurs et non plus simplement en termes
de fonctions dont il pourrait tre intressant de disposer. Mais les
cas d'utilisation ne sont pas un simple outil de spcification des
besoins du systme. Ils en guident galement la conception,
l'implmentation et les tests ; c'est--dire qu'ils guident le
processus de dveloppement. A partir du modle des cas d'utilisation,
les dveloppeurs crent une srie de modles de conception et
d'implmentation ralisant les cas d'utilisation. Chacun des modles
successifs est ensuite rvis pour en contrler la conformit par
rapport au modle des cas d'utilisation. Enfin, les testeurs testent
l'implmentation pour s'assurer que les composants du modle
d'implmentation mettent correctement en uvre les cas d'utilisation.
Ceux-ci ne se bornent donc pas enclencher le processus de
dveloppement : ils en garantissent la cohrence. Pilot par les cas
d'utilisation signifie que le processus de dveloppement suit une
voie spcifique, c'est--dire qu'il procde par une srie
d'enchanements d'activits drivs des cas d'utilisation. Les cas
d'utilisation sont spcifis, ils sont conus, et ils constituent la
source qui permettra aux testeurs d'laborer les cas de test. S'il
est vrai que les cas d'utilisation guident le processus, ils ne
sont pas slectionns de faon isole, mais doivent absolument tre
dvelopps en tandem avec l'architecture du
Dans les trois sections suivantes, nous allons dfinir ces trois
caractristiques, avant de passer un survol du processus : cycle de
vie, phases, versions, itrations, enchanements d'activits et
artefacts. L'objectif de ce chapitre est d'introduire les ides
matresses et de proposer une vue arienne du processus dans son
ensemble. Aprs lecture de ces quelques pages, vous saurez, sans
avoir ncessairement parfaitement compris, de quoi i l est question
dans le Processus unifi. La suite du livre compltera cette vue
d'ensemble en ajoutant tous les dtails ncessaires. Dans le chapitre
2, nous mettrons en contexte les quatre
UH
Le Processus u n i f i de d v e l o p p e m e n t logicielPARTIE
I
Le Processus u n i f i
J |
systme. Les cas d'utilisation guident l'architecture du systme,
qui influence, son tour, leur slection. L'architecture et les cas
d'utilisation voluent donc de faon parallle au cours du cycle de
vie du dveloppement.
sation du systme, mais ils sont les plus significatifs, ceux qui
constituent le cur mme des fonctions du systme. En clair :
1.3 Le Processus unifi est centr sur l'architectureLe rle de
l'architecture logicielle est comparable celui que joue
l'architecture dans la construction d'un btiment. Le btiment est
envisag de diffrents points de vue : structure, services, conduites
de chauffage, plomberie, lectricit, etc. Ce regard multiple dessine
une image complte du btiment avant le dbut de la construction. De
la mme faon, l'architecture d'un systme logiciel peut tre dcrite
comme les diffrentes vues du systme qui doit tre construit.
L'architecte cre une bauche grossire de l'architecture, en
partant de l'aspect qui n'est pas propre aux cas d'utilisation (par
exemple, la plate-forme). Bien que cette partie de l'architecture
soit indpendante des cas d'utilisation, l'architecte doit avoir une
comprhension globale de ceux-ci avant d'esquisser l'architecture. I
l travaille, ensuite, sur un sous-ensemble des cas d'utilisation
identifis, ceux qui reprsentent les fonctions essentielles du
systme en cours de dveloppement. Chaque cas d'utilisation slectionn
est dcrit en dtail et ralis sous forme de sous-systmes (Annexe A ;
voir galement la section 3.4.4), de classes (Annexe A) et de
composants (Annexe A). L'architecture se dvoile peu peu, au rythme
de la spcification et de la maturation des cas d'utilisation, qui
favorisent, leur tour, le dveloppement d'un nombre croissant de cas
d'utilisation. Ce processus se poursuit jusqu' ce que
l'architecture soit juge stable.
1.4 Le Processus unifi est itratif et incrmentalLe dveloppement
d'un produit logiciel destin la commercialisation est une vaste
entreprise qui peut s'tendre sur plusieurs mois, voire sur une anne
ou plus. I l n'est pas inutile de dcouper le travail en plusieurs
parties qui sont autant de mini-projets. Chacun d'entre eux
reprsente une itration qui donne lieu un incrment. Les itrations
dsignent des tapes de Tnchanement d'activits, tandis que les
incrments correspondent des stades de dveloppement du produit. Pour
garantir un maximum d'efficacit, i l est indispensable de contrler
les itrations : celles-ci doivent tre slectionnes et menes bien de
faon planifie. C'est la raison pour laquelle on les qualifie de
mini-projets. Le choix de ce qui doit tre implment au cours d'une
itration repose sut^eujtateurs. ^rfMremnf, une itration prend en
compte un certain nombre de cas d'utilisation qui, - ensemble,
amliorent l'utilisabilit du produit parvenu un certain stade de
dveloppement. Deuximement, l'itration traite en priorit les risques
majeurs. Les itrations successives exploitent les artefacts de
dveloppement dans l'tat o les a laisss l'itration prcdente et les
enrichissent progressivement. I l s'agit d'un mini-projet qui part
des cas d'utilisation, se prolonge par le travail de dveloppement
normal (analyse, conception, implmentation et tests) et ralise sous
forme de code excutable les cas d'utilisation dfinis au cours de
l'itration. Bien entendu, un incrment ne constitue pas
ncessairement un additif. Dans les premires phases du cycle de vie,
en particulier, i l n'est pas rare de remplacer une conception
superficielle par une autre plus dtaille ou plus complexe. Dans les
phases suivantes, en revanche, les incrments ne sont gnralement que
des additifs. chaque itration, les dveloppeurs identifient et
spcifient les cas d'utilisation pertinents, crent une conception en
se laissant guider par l'architecture choisie, implmentent cette
conception sous forme de composants et vrifient que ceux-ci sont
conformes aux cas d'utilisation. Ds qu'une itration rpond aux
objectifs qui lui sont fixs (ce qui est gnralement
Le concept d'architecture logicielle reprsente
les_aspects^statiques.et dynarmgj^Jes plus significatifs du systme.
L'architecture merge des besoins de l'entreprise, tels qu'ils sont
exprims par les utilisateurs et autres intervenants et tels qu'ils
sont reflts par les cas d'utilisation. Elle subit, nanmoins,
l'influence d'autres facteurs, tels que la plate-forme sur laquelle
devra s'excuter le systme (par exemple, l'architecture matrielle,
le systme d'exploitation, le systme de gestion des bases de donnes,
les protocoles de communication rseau), les briques de base
rutilisables disponibles pour le dveloppement (par exemple, une
infrastructure prfabrique (framework) (Annexe C) pour les
interfaces utilisateur graphiques), les considrations de
dploiement, les systmes existants et les besoins non fonctionnels
(par exemple, les performances, la fiabilit). L'architecture
propose une vue d'ensemble de la conception faisant ressortir les
caractristiques essentielles en laissant de ct les dtails
secondaires. Comme la dtermination de ce qui est important tient,
en partie, la capacit de jugement, elle-mme forge par l'exprience,
la valeur de l'architecture dpend troitement des personnes
auxquelles en est attribue la tche. Le processus aide, toutefois,
l'architecte s'attacher en priorit aux vrais objectifs que sont la
clart, la capacit de raction aux futurs changements et la
rutilisation. Quels sont les liens entre cas d'utilisation et
architecture ? Tout produit est la fois forme et fonction. L'une ou
l'autre isolment ne saurait suffire. Ces deux forces doivent
s'quilibrer pour crer un produit russi. Dans le cas qui nous
intresse, la fonction correspond aux cas d'utilisation et la forme
l'architecture. I l est indispensable qu'il y ait une interaction
entre les cas d'utilisation et l'architecture, ce qui revient au
problme classique de l'uf et de la poule . D'un ct, les cas
d'utilisation doivent, une fois raliss, trouver leur place dans
l'architecture. De l'autre, l'architecture doit prvoir la
ralisation de tous les cas d'utilisation ncessaires, dans le prsent
et l'avenir. En fait, l'architectore et les cas d'utilisation
doivent voluer de faon concomitante. Les architectes vont donc
couler le systme dans une forme. Cette forme (l'architecture) doit
tre conue de faon permettre l'volution du systme, non seulement
dans le cadre de son dveloppement initial, mais dans les annes et
les gnrations venir. Pour dterminer une telle forme, les
architectes doivent travailler partir d'une comprhension gnrale des
principales fonctions, c'est--dire des principaux cas
d'utilisation, du systme. Ces cas d'utilisation peuvent ne
reprsenter que 5 10% de tous les cas d'utili-
Le P r o c e s s u s u n i f i de d v e l o p p e m e n t
logicielPARTIE I
Le P r o c e s s u s u n i f i CHAPITRE 1
le cas), le dveloppement peut passer l'itration suivante. Si une
itration n'atteint pas ses objectifs, les dveloppeurs doivent
rtudier les dcisions prises et tenter d'adopter une nouvelle
approche.
1.5 La vie du Processus unifiLe Processus unifi rpte un certain
nombre de fois une srie de cycles constituant la vie d'un systme,
comme l'illustre la figure 1.2. Tout cycle se conclut par la
livraison d'une version du produit (Annexe C ; voir galement le
chapitre 5) aux clients et s'articule en quatre phases : cration,
laboration, construction et transition. Chacune d'entre elles se
subdivise son tour en itrations, comme nous l'avons indiqu plus
haut. Voir lafigure1.3. Naissance
Pour rentabiliser les efforts de dveloppement, chaque quipe
essaiera de ne slectionner que les itrations ncessaires pour
atteindre les objectifs du projet. Dans la mesure du possible, ces
itrations devront se succder selon un ordre logique. Un projet
russi suivra un droulement direct, tabli ds le dbut par les
dveloppeurs et dont i l ne s'loignera que de faon trs marginale.
Bien sr, si des problmes imprvus viennent ajouter des itrations ou
en bouleverser la squence prvue, le processus de dveloppement
ncessitera plus de travail et de temps. L'limination des problmes
imprvus fait partie des objectifs de rduction des risques.
L'utilisation d'un processus itratif contrl prsente de nombreux
avantages : Une itration contrle permet de limiter les cots, en
termes de risques, aux strictes dpenses lies une seule itration.
S'il faut reprendre l'itration, l'entreprise ne perd que le bnfice
des efforts mal orients sur une itration, et non la valeur du
produit dans son entier. Une itration contrle permet de limiter les
risques de retard de mise sur le march du produit dvelopp.
L'identification des risques ds les premiers stades de dveloppement
en permet la rsolution prcoce, un moment o les dveloppeurs sont
moins soumis la pression des dlais que dans les phases ultimes du
projet. Avec l'approche classique , qui ne fait apparatre les
problmes qu'au moment des tests du systme, le temps ncessaire leur
rsolution dpasse gnralement les dlais prvus et conduit presque
inexorablement un retard de livraison. Une itration contrle se
traduit par une acclration du rythme de l'ensemble du dveloppement,
car elle permet aux dveloppeurs de travailler plus efficacement
vers des objectifs clairs court terme, plutt qu'en fonction d'un
planning long terme soumis d'invitables dpassements. Enfin, une
itration contrle prend en compte une ralit souvent ignore : les
besoins des utilisateurs et les exigences correspondantes ne
peuvent tre intgralement dfinis l'avance et se dgagent peu peu des
itrations successives. Ce mode de fonctionnement facilite
l'adaptation l'volution des besoins. Ces concepts - dveloppement
pilot par les cas d'utilisation, centr sur l'architecture, itratif
et incrmental - sont d'gale importance. L'architecture fournit la
structure qui servira de cadre au travail effectu au cours des
itrations, tandis que les cas d'utilisation dfinissent les
objectifs et orientent le travail de chaque itration. L'abandon de
l'une ou l'autre de ces trois notions cls attnuerait
considrablement la valeur du Processus unifi. Comme un tabouret
auquel i l manquerait un pied, i l s'effondrerait. Maintenant que
nous avons introduit ces trois concepts, i l est temps de jeter un
il au processus dans son ensemble, son cycle de vie, ses artefacts,
ses enchanements d'activits, ses phases et ses itrations.
Figure 1.2 La vie d'un processus se dcompose en cycles allant de
sa naissance sa mort.
Temps
Cycles donnant naissance une version
Figure 1.3 Un cycle, avec ses phases et ses itrations.
Temps
1.5.1 Le produitChaque cycle se traduit par une nouvelle version
du systme, c'est--dire un produit prt la livraison. Ce produit se
compose d'un corps de code source rparti sur plusieurs composants
pouvant tre compils et excuts, et s'accompagne de manuels et de
produits associs. Toutefois, le produit fini doit prendre en compte
les besoins, non pas des seuls utilisateurs, mais de tous les
intervenants, c'est--dire de tous ceux qui seront amens
l'exploiter. Il ne peut, par consquent, se rsumer un simple code
machine excutable. Le produit fini comprend les besoins, les cas
d'utilisation, les spcifications non fonctionnelles et les cas de
test. I l englobe l'architecture et les modles visuels (les
artefacts modliss par UML). En fait, i l intgre tous les lments
abords dans ce chapitre, car ce sont eux qui permettent aux
intervenants (clients, utilisateurs, analystes, concepteurs,
programmeurs, testeurs et responsables) de spcifier, concevoir,
implmenter, tester et utiliser un systme.
Le Processus u n i f i de d v e l o p p e m e n t logiciel
Le Processus u n i f i CHAPITRE 1
Ce sont galement ces lments qui rendent possible l'utilisation
et la modification du systme sur plusieurs gnrations.
Modle des cas d'utilisation
spcifi par
Modle d'analyse
|""| impiment par vrifi par
Si les composants excutables sont indniablement les artefacts
les plus importants du point de vue de l'utilisateur, leur seule
prsence ne saurait suffire. Et cela pour la simple raison que
l'environnement change. Les systmes d'exploitation, de bases de
donnes et les machines sous-jacentes voluent. I l est possible,
alors mme que se prcise peu peu le cadre de la mission, que les
besoins eux-mmes se modifient et contraignent les dveloppeurs
entamer un nouveau cycle qui devra tre financ par la direction.
Pour mener efficacement le cycle suivant, les dveloppeurs ont
besoin de toutes les reprsentations du produit logiciel (figure
1.4) : un modle des cas d'utilisation exposant tous les cas
d'utilisation et leurs relations avec les utilisateurs ; un modle
d'analyse poursuivant deux objectifs : dtailler les cas
d'utilisation et procder une premire rpartition du comportement du
systme entre divers objets appropris ; un modle de conception
dfinissant (a) la structure statique du systme sous forme de
sous-systmes, classes et interfaces, et (b) les cas d'utilisation
raliss sous forme de collaborations (Annexe A ; voir galement la
section 3.1) entre les sous-systmes, les classes et les interfaces
; un modle d'implmentation intgrant les composants (reprsentant le
code source) et la correspondance entre les classes et les
composants ; un modle de dploiement dfinissant les nuds physiques
des ordinateurs et l'affectation de ces composants sur ces nuds ;
un modle de tests dcrivant les cas de test vrifiant les cas
d'utilisation ; et, bien sr, une reprsentation de l'architecture.
Il est possible que le systme dispose galement d'un modle du
domaine ou d'un modle du mtier dcrivant le contexte professionnel
du systme. Tous ces modles sont lis. Ensemble, ils reprsentent le
systme comme un tout. Les lments de chacun des modles prsentent des
dpendances de traabilit (Annexe A ; voir galement la section 2.3.7)
avant et arrire favorises par les liens existant avec les autres
modles. I l est, par exemple, possible de remonter un cas
d'utilisation (dans le modle des cas d'utilisation) partir de sa
ralisation (dans le modle de conception) ou d'un cas de test (dans
le modle de test), et inversement. La traabilit facilite la
comprhension et les modifications ultrieures.
BModle de conception
Figure 1.4 Modles du Processus unifi. La plupart des modles sont
lis par des dpendances. Par exemple, les dpendances entre le modle
des cas d'utilisation et les autres modles sont indiques.
Modle de dploiement
s Implmentation M dl oe D O
S'
i
YModle de tests
1.5.2 Les phases d'un cycleChaque cycle se droule sur une
certaine dure dcoupe en quatre phases, comme le montre la figure
1.5. Une squence de modles permet aux intervenants de visualiser ce
qui se passe durant ces phases. Pour chacune d'elles, les chefs de
projet ou dveloppeurs peuvent pousser la dcomposition du travail en
itrations et incrments qui en sont issus. Chaque phase s'achve par
un jalon (Annexe C ; voir galement le chapitre 5), qui se dfinit
par un ensemble d'artefacts : certains modles ou documents ont
atteint un niveau de ralisation fix au pralable. Les jalons servent
de nombreux objectifs, le principal tant de permettre aux chefs de
projet de prendre un certain nombre de dcisions cruciales avant de
passer la phase suivante du dveloppement. Ils permettent galement
aux responsables, et aux dveloppeurs euxmmes, de surveiller la
progression du travail en fonction de ces quatre points cls. Enfin,
l'archivage du temps et des efforts consacrs chaque phase constitue
un corpus de donnes qui se rvlent fort utiles pour valuer les
besoins en termes de dlais et de personnel sur d'autres projets,
planifier les besoins en personnel sur toute la dure d'un projet et
contrler l'avancement par rapport aux projections. La figure 1.5
indique les enchanements d'activits (formulation des besoins,
analyse, conception, implmentation et tests) dans la colonne de
gauche, tandis que les courbes reprsentent approximativement (ne
les considrez pas de faon trop littrale) le degr d'accomplissement
des enchanements d'activits dans chaque phase. N'oubliez pas que
chaque phase se dcompose en principe elle-mme en itrations, ou
mini-projets. Une itration couvre gnralement les cinq enchanements
d'activits, comme le montre la figure 1.5 dans la phase
d'laboration.
Le P r o c e s s u s u n i f i de d v e l o p p e m e n t
logicielPARTIE I
Le P r o c e s s u s u n i f i
j g
o^ATirREi^m
Phases
d'laboration, aboutit l'mergence d'une architecture de rfrence
(Annexe C ; voir galement la section 4.4). l'issue de la phase
d'laboration, le chef de projet est en mesure de prvoir les
activits et d'estimer les ressources ncessaires l'achvement du
projet. La question cl, ce stade, est la suivante : les cas
d'utilisation, l'architecture et les plans sont-ils assez stables
et les risques suffisamment matriss pour permettre la ralisation du
dveloppement dans le respect du contrat ?
Figure 1.5 Les cinq Principaux e n c h a n e m e n t s
enchanements d'activits d'activits (besoins, analyse, conception,
implmentation et Analyse tests) se droulent sur les quatre
Conception phases : cration, laboration, construction et
Implmentation transition.
iter. iter. #1 #2Itrations
... I Iter. I #n-1
iter. #n
La phase de cration (ou d'inception) traduit ce qui n'est, au
dpart, qu'une bonne ide en une vision du produit fini et prsente
une tude de rentabilit pour ce produit. Cette phase rpond
essentiellement aux questions suivantes : Que va faire, en
substance, le systme pour chacun de ses principaux utilisateurs ?
quoi peut ressembler l'architecture d'un tel systme ? Quels sont
l'organisation et les cots du dveloppement de ce produit ? Un modle
simplifi des cas d'utilisation regroupant les principaux cas
d'utilisation permettra de rpondre la premire question. A ce stade,
l'architecture est encore provisoire, elle n'est en gnral qu'une
bauche rvlant les principaux sous-systmes. C'est au cours de cette
phase que sont identifis et hirarchiss les risques majeurs, qu'est
planifie en dtail la phase d'laboration et qu'est livre une
estimation approximative du projet dans son ensemble. La phase
d'laboration permet de prciser la plupart des cas d'utilisation et
de concevoir l'architecture du systme. La relation existant entre
l'architecture d'un systme et le systme lui-mme est absolument
primordiale. Disons, pour faire simple, que l'architecture
s'apparente un squelette recouvert de peau, mais avec trs peu de
muscles (le logiciel), juste assez pour permettre au squelette
d'effectuer les mouvements les plus lmentaires. Le systme est ce
corps dans son entier : squelette, peau et muscles. L'architecture
doit donc tre exprime sous forme de vues de tous les modles du
systme qui, associes les unes aux autres, figurent le systme dans
son ensemble. Cela implique l'existence d'une vue architecturale de
chacun des modles de cas d'utilisation, de conception,
d'implmentation et de dploiement. La vue du modle d'implmentation
doit comprendre les composants tmoignant du caractre excutable de
l'architecture. Cette phase, au cours de laquelle sont raliss les
principaux cas d'utilisation identifis pendant la phase
Comme son nom l'indique, la phase de construction est le moment
o est construit le produit. En d'autres termes, le squelette
(l'architecture) s'toffe de muscles (le logiciel achev). Au cours
de cette phase, l'architecture de rfrence se mtamorphose en systme
complet. Notre vision du systme est dsormais celle d'un produit prt
tre transmis aux utilisateurs. Cette phase consomme l'essentiel des
ressources mobilises. Mais l'architecture du systme est stable, et
les dveloppeurs peuvent encore dcouvrir des moyens plus efficaces
de structurer le systme ou suggrer des modifications
architecturales mineures. l'issue de cette phase, le produit
contient tous les cas d'utilisation que les chefs de projet, en
accord avec les utilisateurs, ont dcid de mettre au point pour
cette version. Celle-ci risque, toutefois, de prsenter quelques
anomalies. D'autres seront dcouvertes et rsolues au cours de la
phase de transition. La question qui se pose alors est la suivante
: le produit satisfaitil suffisamment aux besoins des utilisateurs
pour que certains clients l'adoptent avant sa sortie officielle ?
La phase de transition couvre la priode au cours de laquelle le
produit passe en version bta. Un petit groupe d'utilisateurs
expriments essaient le produit en version bta et rendent compte des
anomalies et dfauts constats. Les dveloppeurs corrigent ensuite les
problmes signals et incorporent certaines des amliorations suggres
dans une version
