Processus Unifié

Mthodologies de dveloppement
de logiciels de gestion
Chapitre 6
Le Processus unifi de dveloppement logiciel
Partie I
Les concepts
Prsentation ralise par P.-A. Sunier
Professeur la HE-Arc de Neuchtel
http://lgl.isnetne.ch
Rfrences
Ce document est rdig partir de la partie I de louvrage

[JBR-00]
Le processus unifi de dveloppement
Traduit par V. Zam de
The Unified Software Development Process
I. Jacobson, G. Booch, J. Rumbaugh
c/o Eyrolles, 2000

ISBN 2-212-09142-7
mai 2005 / p.-a. sunier
FCOO / $6 - Le processus unifi (UP)
Plan
Introduction
1. Le Processus unifi: pilot par les cas
dutilisation, centr sur larchitecture, itratif et
incrmental
2. Les 4 P : personnes, projet, produit et
processus
3. Un processus pilot par les cas dutilisation
4. Un processus centr sur larchitecture
5. Un processus itratif et incrmental
Introduction
... l'objectif sous-jacent que poursuit une entreprise

n'est videment pas de possder un bon systme
informatique, mais d'exploiter les processus
mtiers (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.
[JBR-00 p14]
1. Le processus unifi
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
[JBR-00 p16]
Problmatique
1. UP
Le processus doit:
dicter l'organisation des activits
diriger les tches
individuelles
de groupe, quipe...
spcifier les artefacts produire

proposer des critres de contrle
des produits du projet
des activits du projet
[JBR-00 p15]
1. UP
Pilot par les cas dutilisation
L'objectif d'un systme logiciel est de rendre

service ses utilisateurs. Pour russir la mise au
point d'un systme, il importe, par consquent, de
bien comprendre les dsirs et les besoins de
ses futurs utilisateurs.
Un cas d'utilisation est une fonctionnalit du
systme produisant un rsultat satisfaisant
pour l'utilisateur.
Les cas d'utilisation saisissent les besoins
fonctionnels et leur ensemble forme le modle
des cas d'utilisation qui dcrit les fonctionnalits
compltes du systme.
[JBR-00 p17]
1. UP
Centr sur larchitecture
Le rle de l'architecture logicielle est comparable

celle que joue l'architecte dans la construction d'un
btiment. Le btiment est envisag de diffrents
points de vue: structure, services, conduite de
chauffage, plomberie, 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.
[JBR-00 p18]
1. UP
Itratif et incrmental
Le dveloppement d'un produit logiciel destin la

commercialisation est une vaste opration qui peut
s'tendre sur plusieurs mois, voire sur une anne
ou plus. Il n'est pas inutile de dcouper le travail
en plusieurs parties qui sont autant de mini-projets
(Concept systmique de systme et soussystmes).Chacun d'eux reprsente une itration
qui donne lieu un incrment. Les itrations
dsignent des tapes de l'enchanement
d'activits, tandis que les incrments
correspondent des stades de
dveloppement du produit.
[JBR-00 p19]
1. UP
La vie du Processus unifi
[JBR-00 p21-25]
10
Un processus intgr
1. UP
bas sur les composants

utilisant la modlisation visuelle UML
reposant sur 3 notions matresses
les cas d'utilisation
l'architecture
le dveloppement itratif et incrmental
sappuyant sur un cadre gnral (framework) intgrant
les cycles
les phases
les enchanements d'activits
la rduction des risques
le contrle qualit
la gestion de configuration
[JBR-00 p25-26]
11
2. Les 4 P du dveloppement logiciel

Processus
Automatisation
Template
Participants
Personnes
Projet
Outils
Rsultat
Produit
[JBR-00 p28]
12
2. Les 4 P
Les personnes jouent un rle crucial
Diverses personnes sont impliques dans le

dveloppement dun produit logiciel tout au long de
son cycle de vie. Certains financent le produit,
tandis que dautres le planifient, le dveloppent, le
grent, le testent , lutilisent ou en bnficient. Le
processus guidant le dveloppement doit, par
consquent, tre orient vers les personnes, cest-dire convenir parfaitement ses utilisateurs.
[JBR-00 p28]
13
2. Les 4 P
Un projet ne se rsume pas du code
Qu'est-ce qu'un systme logiciel ?

Artefacts
Modles
Modle des
cas dutilisation
Modle
danalyse
Modle
dimplmentation
Modle
des tests
Modle de
conception
Modle de
dploiement
[JBR-00 p32-36]
14
2. Les 4 P
Les modles au cur du processus
[JBR-00 p32-36]
15
2. Les 4 P
Le processus dirige les projets
Dans le Processus unifi, le terme processus renvoie

lide de cadre ( template ) pouvant tre rutilis par la
cration dinstances de celui-ci Lexpression instance de
processus est synonyme de projet.
Dans cet ouvrage, un processus de dveloppement dfinit
les activits ncessaires la transformation des besoins des
utilisateurs en un ensemble cohrent dartefacts constituant
un produit logiciel et, plus tard, par la transformation des
volutions de ces besoins en un ensemble dartefacts tout
aussi cohrent.
[JBR-00 p37]
16
2. Les 4 P
Les outils font partie intgrante du

processus
Les processus actuels de dveloppement logiciel sont pris

en charge par des outils. Il est impensable, aujourdhui, de
mettre au point des logiciels sans recourir un processus
reposant sur des outils. Processus et outils sont livrs
ensemble, les outils faisant partie intgrante du processus.
[JBR-00 p41]
17
3. Le processus unifi pilot par les cas

dutilisations
L'objectif du Processus unifi est de guider les
dveloppeurs vers l'implmentation et le dploiement
efficaces de systmes rpondant aux besoins des clients.
Cette efficacit se mesure en termes de cots, de qualit et
de dlai de fabrication. Le passage de l'estimation des
besoins du client leur implmentation est loin d'tre
naturel. D'abord parce que les besoins des clients ne se
laissent pas si facilement apprhender. Il faut disposer
d'un moyen de les communiquer de faon claire toute
personne implique dans le projet. Il faut, ensuite, tre en
mesure de concevoir une implmentation oprationnelle
rpondant ces besoins. Il faut, enfin, vrifier la pleine
satisfaction de ces besoins en testant le systme. En
raison de sa complexit, le systme est dcrit sous forme
d'activits qui donnent peu peu naissance un systme
oprationnel.
[JBR-00 p47]
18
Enchanement dactivits
3. Pilot
Besoins
Modle des
cas dutilisation
Analyse
Modle
danalyse
Conception
Modle de
conception
Modle de
dploiement
Implmentation
Modle
dimplmentation
Tests
Modle
des tests
[JBR-00 p48]
19
3. Pilot
Pourquoi?
Pour apprhender les vrais besoins

Analyse de la valeur des fonctions envisages
Pour diriger le processus

Du besoin aux tests de la solution en crant tous les
artefacts et documents de traabilit ncessaires
Pour mettre au point l'architecture

Stabilisation de l'architecture lors des premires
itrations
[JBR-00 p51-54]
20
3. Pilot
Besoins fonctionnels
Le modle des cas d'utilisation aide le client, les

utilisateurs et les dveloppeurs s'accorder sur
l'utilisation du systme.
[JBR-00 p54-55]
21
Spcifications du systme
3. Pilot
Un cas d'utilisation spcifie une squence

d'actions, avec ses variantes, pouvant tre
effectue par le systme et produisant un rsultat
satisfaisant pour un acteur particulier.
Cas dutilisation Retirer de largent
1. Le Client de la banque sidentifie
2. Le Client de la banque choisit le compte duquel il veut effectuer son retrait et
spcifie le montant du retrait.
3. Le systme dduit le montant du compte et dlivre largent.
[JBR-00 p56-57]
22
3. Pilot
Ralisation en analyse
Un cas d'utilisation spcifie une squence d'actions, avec

ses variantes, pouvant tre effectue par le systme et
produisant un rsultat satisfaisant pour un acteur
particulier.
[JBR-00 p56-57]
23
3. Pilot
Diagramme de collaboration en analyse
[JBR-00 p60]
24
3. Pilot
Cration du modle de conception partir

du modle danalyse
Le modle de conception est d'abord cr partir

du modle d'analyse, avant d'tre adapt
l'environnement d'implmentation choisi; comme
un ORB, un kit de construction d'IHM ou un
systme de gestion de base de donnes.
[JBR-00 p62]
25
Modle de conception
Modle danalyse
3. Pilot
Dpendances entre classes de conception

et classes danalyse
Remarque: Les classes actives sont montres par un fond bleu

[JBR-00 p63]
26
3. Pilot
Diagramme de classes de conception ralisant un

cas dutilisation (Retirer de largent)
[JBR-00 p64]
27
3. Pilot
Diagramme de squence, instance dun cas

dutilisation (Retirer de largent)
[JBR-00 p65]
28
3. Pilot
Les sous-systmes regroupent les classes
Les classes sont rparties en sous-systmes qui

permettent le regroupement smantique de
classes et dautres sous-systmes. Chaque soussystme fournit et utilise lui-mme un ensemble
dinterfaces qui en dfinissent le contexte.
[JBR-00 p65-66]
29
Les sous-systmes regroupent les classes
3. Pilot
Au cours de l'enchanement d'activits de l'implmentation, sont

dvelopps tous les lments excutables ncessaires la production
d'un systme excutable: les composants, les composants fichiers
(code source, shell scripts, etc.), les composants tables (lments de
base de donnes) et ainsi de suite. Un composant est une partie
physique et remplaable d'un systme, conforme la ralisation
d'un ensemble d'interfaces qu'elle doit fournir.
Modle de conception
Modle dimplmentation
Gestionnaire
des clients
Alimentation
Chargeur
Guichet
espces
[JBR-00 p67]
30
3. Pilot
Tests des cas dutilisation
Les tests permettent de vrifier que le systme

implmente correctement sa spcification... Un
cas de test est un ensemble d'entres de test, de
conditions d'excution et de rsultats attendus
dtermin dans un objectif prcis...
Modle des cas dutilisation
Modle des tests
X
Retirer de largent
Retirer de largent
-Flot de base
[JBR-00 p68]
31
3. Pilot
Instance dun cas de test pour le cas

dutilisation Retirer de largent
Entres:
Le compte 12-121-1211 du Client de la banque montre un solde de 3500FS.

Le Client de la banque sidentifie correctement.
Le Client de la banque demande retirer 2000FS du compte 12-121-1211.
Il y a assez dargent (au moins 2000FS) dans le DAB.
Rsultat:
Le solde du compte 12-121-1211 du Client de la banque descend 1500FS.

Le Client de la banque reoit 2000Fs du DAB.
Conditions:
Aucun autre cas dutilisation (instance) nest autoris accder au compte

12-121-1211 pendant ce cas de test.
[JBR-00 p69]
32
4. Le processus unifi centr sur

larchitecture
Les cas d'utilisation ne suffisent pas. Pour
chafauder un systme oprationnel, il faut
quelque chose de plus. Ce "plus" c'est
l'architecture. On peut se reprsenter l'architecture
d'un systme comme la vision commune sur
laquelle doivent s'accorder tous les travailleurs
(c'est--dire les dveloppeurs et les autres
intervenants), ou qu'ils doivent au moins accepter.
L'architecture offre une perspective claire de tout
le systme, indispensable pour en matriser le
dveloppement.
[JBR-00 p71]
33
4. Centr
Dfinition de larchitecture
Ensemble des dcisions significatives concernant

l'organisation d'un systme logiciel, la slection des
lments structurels dont est compos le systme et de
leurs interfaces, ainsi que leur comportement tel qu'il est
spcifi dans les collaborations entre ces lments, la
composition de ces lments structurels et
comportementaux en sous-systmes, progressivement
plus importants, et le style architectural guidant cette
organisation: ces lments et leurs interfaces, leurs
collaborations, et leur composition. L'architecture logicielle
ne se soucie pas seulement de structure et de
comportement, mais aussi d'utilisation, de fonctions, de
performances, de capacit ragir aux changements, de
rutilisation, de clart, de contraintes et de compromis
conomiques et technologiques, enfin de proccupations
esthtiques.
[JBR-00 p468]
34
4. Centr
Pourquoi une architecture?
Il nous faut une architecture pour:

comprendre le systme
Complexit, complication, pluridisciplinarit
organiser le dveloppement
Besoin de communication de l'quipe
favoriser la rutilisation
Normalisation, standardisation des composants
logiciels
faire voluer le systme

Raction aux changements de l'environnement
[JBR-00 p75]
35
4. Centr
Cas dutilisation et architecture?
... l'architecture est influence par les cas d'utilisation

que nous voulons faire prendre en charge par le systme.
Ces cas d'utilisation agissent, en effet, comme des pilotes
pour l'architecture. Aprs tout, on veut obtenir une
architecture adapte l'implmentation des cas
d'utilisation retenus. On slectionne, dans les premires
itrations, quelques cas d'utilisation jugs indispensables
la cration de l'architecture. Parmi ces cas d'utilisation
pertinents pour l'architecture, figurent ceux dont les clients
ont le plus besoin pour la version venir et peut-tre pour
les versions suivantes.
[JBR-00 p78]
36
4. Centr
Facteurs dinfluence de choix architecturaux
Cas dutilisation
Contraintes et facteurs favorables:
Architecture
Logiciel systme
Middleware (y-compris les
frameworks)
Systmes existants
Standards et politiques
Besoins non fonctionnels
Besoins de distribution
Exprience:
Architectures prcdentes
Patterns (Modles) darchitecture
[JBR-00 p78]
37
4. Centr
Influence de larchitecture sur llaboration

de cas dutilisation
Les cas d'utilisation peuvent tre labors partir

des entres fournies par les clients et les
utilisateurs (concepteurs et dveloppeurs).
Cependant, ils sont galement influencs par
l'architecture dj en place.
Cas dutilisation
Entre des clients

Entre des utilisateurs
Architecture
[JBR-00 p80]
38
4. Centr
Influence rciproque de larchitecture et des

cas dutilisation
Les cas d'utilisation orientent le dveloppement de

l'architecture, tandis que l'architecture guide la
ralisation des cas d'utilisation
Cas dutilisation
Guide
Orientent
Architecture
[JBR-00 p81]
39
4. Centr
Mise au point de larchitecture
Il est fascinant de constater que l'on peut parfaitement

mettre au point une architecture stable pendant la phase
d'laboration du premier cycle de vie, alors mme que
seuls quelque 30% de la premire version du produit ont
t investis.
[JBR-00 p83]
40
4. Centr
Utilisation de patterns darchitecture
Les spcialistes dfinissent un pattern comme une

solution un problme rcurrent de
conception.
nous dfinirons un pattern comme une
collaboration gnrique pouvant tre spcialise
les patterns de conception deviennent , ainsi,
des collaborations entre classes et instances, dont
le comportement est expliqu par les diagrammes
dinteraction
[JBR-00 p84]
41
4. Centr
Pattern Couches (Layers)
Les composants dune couche ne peuvent faire

rfrence quaux composants de la couche situe
immdiatement au-dessous.
Couche spcifique lapplication
Couche gnrale aux applications
Couche de middleware
Couche de logiciels systme

[JBR-00 p85]
42
4. Centr
Description de larchitecture
...la description de l'architecture prsente les vues

des modles et comprend ainsi des cas
d'utilisation, des sous-systmes, des interfaces,
certains composants, des nuds et des
collaborations. Elle intgre galement les besoins
significatifs sur le plan architectural qui ne sont pas
dcrits par les cas d'utilisation. Les autres besoins,
non fonctionnels, sont formuls en tant
qu'exigences supplmentaires... La description de
l'architecture doit, en outre, contenir une brve
description de la plate-forme, des systmes
existants et des logiciels commerciaux utiliser.
[JBR-00 p84]
43
4. Centr
Cest larchitecte qui cre larchitecture
C'est l'architecte entour de quelques dveloppeurs qui

cre l'architecture...
C'est lui qui choisit parmi les patterns d'architecture,
slectionne les produits existants et organise les
dpendances de sous-systmes de faon srier les
problmes. "Srier les problmes" signifie, dans ce cas,
crer une conception vitant qu'un changement intervenant
sur un sous-systme ne se rpercute sur plusieurs autres
sous-systmes.
...Un architecte puise deux types de sources:
la connaissance du domaine
la connaissance du dveloppement logiciel
L'exprience acquise ... se rvlera galement prcieuse.

[JBR-00 p89-90]
44
4. Centr
Vue architecturale du modle des cas

dutilisation
La vue architecturale du modle des cas

dutilisation prsente les principaux acteurs et cas
dutilisation.
Vue architecturale du modle des cas dutilisation du DAB
Retirer de largent est le cas dutilisation le plus important
Pour dfinir larchitecture, larchitecte suggre donc de procder limplmentation
intgrale de ce seul cas dutilisation pendant la phase dlaboration..
La vue architecturale du modle des cas dutilisation devra donc montrer la
description complte du cas dutilisation Retirer de largent.
[JBR-00 p91]
45
4. Centr
Vue architecturale du modle de conception (1)
La vue architecturale du modle de conception

prsente les classificateurs de ce modle ayant une
importance cruciale pour l'architecture: les principaux
sous-systmes et interfaces, ainsi que quelques-unes
des classes primordiales, essentiellement les classes
actives.
Vue architecturale du modle de conception du DAB

nous avons identifi 3 classes actives (pour raliser le cas
dutilisation Retirer de largent)
Gestionnaire
de clients
Gestionnaire
de transactions
Gestionnaire
de comptes
[JBR-00 p91]
46
4. Centr
Diagramme de classes (pour raliser le cas dutilisation Retirer de

largent) dcrivant les sous-systmes et les interfaces qui les relient.
[JBR-00 p92]
47
4. Centr
Diagramme des sous-systmes collaborant lexcution du cas

dutilisation Retirer de largent
Pr-condition: le Client de la banque dispose dun compte en
banque oprationnel pour le DAB.
1. Lacteur Client de la banque choisit de retirer de largent et sidentifie
auprs de lInterface du DAB, par exemple en utilisant une carte
magntique ayant un numro et un code secret. Le Client de la banque
indique galement le montant du retrait et le compte partir duquel il
souhaite leffectuer
Remarque: A notre connaissance, il nest pas possible de montrer les paquetages dans un diagramme de
collaboration avec Rational Rose que nous avons utilis pour les illustrations pratiques
[JBR-00 p93]
48
4. Centr
Vue architecturale du modle de

dploiement (1)
Le modle de dploiement dfinit l'architecture

physique en termes de nuds connects. Ces
nuds sont des units matrielles sur lesquels
s'excutent les composants logiciels. Il est
frquent que l'on sache quoi ressemblera
l'architecture physique du systme avant de
commencer dvelopper le systme. Les nuds
et connexions peuvent alors tre modliss dans
le modle de dploiement ds l'enchanement
d'activits des besoins.
[JBR-00 p94]
49
4. Centr
Vue architecturale du modle de

dploiement (2)
Le modle de dploiement dfinit trois nuds:

Client du DAB
Serveur dapplication du DAB
Serveur de donnes du DAB
[JBR-00 p95]
50
5. Un processus itratif et incrmental

Parvenir un juste quilibre entre cas dutilisation et
architecture revient, grosso modo, harmoniser forme
et fond dans le dveloppement dun produit Savoir
ce qui vient en premier nous ramne au problme de
luf et de la poule Ce sont dinterminables
itrations, survenues tout au cours du long processus
dvolution qui ont donn naissance la poule et
luf. De la mme faon, au fil du processus de
dveloppement logiciel, les dveloppeurs recherchent
consciencieusement cet quilibre (entre cas
dutilisation et architecture) travers une srie
ditrations. Lapproche itrative et incrmentale du
dveloppement constitue bien, par consquent, le
troisime pivot du Processus unifi.
[JBR-00 p101]
51
5. Itratif
Pourquoi un dveloppement itratif et

incrmental
Prendre en main trs tt les risques importants

Proposer une architecture qui guidera le
dveloppement logiciel
Fournir une infrastructure prfabrique
(framework) capable de mieux prendre en
compte les exigences incontournables et les
autres changements
laborer progressivement le systme, de faon
incrmentale, au lieu de tout faire dun coup, la
fin, lorsque les changements cotent chers
Offrir un processus de dveloppement favorisant
la productivit en quipe
[JBR-00 p103]
52
5. Itratif
Rduire les risques
Le risque est inhrent lengagement de ressources

actuelles vers des attentes futures selon le prophte du
management Peter F. Drucker.
Cascade
Gravit des
risques
Itratif &
incrmental
Cration
laboration
Construction
Transition
Temps
[JBR-00 p103-105]
53
5. Itratif
Lapproche itrative est guide par la

rduction des risques
Un risque est une variable dun projet qui met en

danger, voire compromet totalement, la russite du
projet en question. Cest la probabilit selon laquelle
un projet peut tre confront des vnements
indsirables, comme des retards de calendrier, des
dpassements de budget ou une annulation pure et
simple .
on organise les itrations de faon rduire au
maximum les risques.
La rduction des risques est cruciale pour les
itrations menes dans les phases de cration et
dlaboration. Dans la phase plus tardive de
construction, les risques ont, dans lensemble, t
ramens un niveau normal
[JBR-00 p109-113]
54
5. Itratif
Besoins
Litration gnrique
Analyse
Conception
Une
itration
Implment.
Tests
Comprend en plus:
La planification de litration
Lvaluation de litration

[JBR-00 p113-114]
55
5. Itratif
Planifier les itrations
le cycle de vie itratif rclame plus de

planification et de rflexion que lapproche en
cascade.
Dans le modle en cascade tout est planifi
lavance, souvent avant que les risques aient
t rduits et larchitecture tablie. Les plans
qui en rsultent reposent donc sur une grande
part dincertitude
Lapproche itrative, en revanche, ne planifie
pas tout le projet en dtail au cours de la phase
de cration; elle sengage simplement sur les
premires tapes.
[JBR-00 p115]
56
5. Itratif
Une itration se traduit par un incrment
Un incrment est la diffrence entre la version

interne dune itration et la version interne de
litration suivante.
A la fin dune itration, lensemble des modle
reprsentant le systme se trouve dans un tat
particulier. Cet tat, ou tat davancement, est
appel rfrence.
[JBR-00 p116]
57
Itrations dans le cycle de vie
5. Itratif
Chacune des quatre phases se conclut par un

jalon majeur.
Jalon des
objectifs du
cycle de vie
Cration
itr. 1
Jalon de
larchitecture du
cycle de vie
Jalon de capacit
oprationnelle
initiale
laboration
itr. 2
Jalon de livraison
du produit
Construction
Transition
itr.
n-1
itr. n
[JBR-00 p118]
58
5. Itratif
Jalons et dcisions
Lobjectif de chaque jalon majeur est de

sassurer que les modles des diffrents
enchanements dactivits voluent de faon
quilibre. Par quilibre , nous entendons
que les dcisions essentielles influant sur ces
modles et celles concernant les risques,les
cas dutilisation et larchitecture doivent tre
prises au dbut du cycle de vie.
[JBR-00 p118]
59
Objectifs de la phase de cration
5. Itratif
Porte et rle du produit

Rduire les risques les plus importants
Etude rentabilit, viabilit commerciale
Jalon des
objectifs du
cycle de vie
Cration
itr. 1
Jalon de
larchitecture du
cycle de vie
Jalon de capacit
oprationnelle
initiale
laboration
itr. 2
Jalon de livraison
du produit
Construction
Transition
itr.
n-1
itr. n
[JBR-00 p118]
60
Objectifs de la phase dlaboration
5. Itratif
Crer larchitecture de rfrence

Saisir lessentiel des besoins
Rduire les risques de moindre gravit
Jalon des
objectifs du
cycle de vie
Cration
itr. 1
Jalon de
larchitecture
du cycle de vie
Jalon de capacit
oprationnelle
initiale
laboration
itr. 2
Jalon de livraison
du produit
Construction
Transition
itr.
n-1
itr. n
[JBR-00 p118]
61
Objectifs de la phase de construction
5. Itratif
Dvelopper le systme complet

Sassurer que le produit peut tre utilis par
les clients
Jalon des
objectifs du
cycle de vie
Cration
itr. 1
Jalon de
larchitecture du
cycle de vie
Jalon de capacit
oprationnelle
initiale
laboration
itr. 2
Jalon de livraison
du produit
Construction
Transition
itr.
n-1
itr. n
[JBR-00 p118]
62
Objectifs de la phase de transition
5. Itratif
Sassurer que lon dispose dun produit prt

tre livr lensemble des utilisateurs
Former les utilisateurs
Jalon des
objectifs du
cycle de vie
Cration
itr. 1
Jalon de
larchitecture du
cycle de vie
Jalon de capacit
oprationnelle
initiale
laboration
itr. 2
Jalon de livraison
du produit
Construction
Transition
itr.
n-1
itr. n
[JBR-00 p118]
63
5. Itratif
Les modles voluent partir des itrations
Incrment par incrment, les itrations

construisent les modles qui en rsultent.
Cration
laboration
Construction
Transition
UACD IT
UACD IT
UACD IT
UACD IT
Modles:
U Cas dutilisation, A Analyse, C Conception,
D Dploiement, I Implmentation, T - Test
[JBR-00 p120]
64
5. Itratif
Les itrations remettent en question

lorganisation
Les quipes de dveloppement souvent ne

rsistent pas la tentation de passer
directement lcriture de lignes de code,
facilement quantifiables par les chefs de
projet
Le passage un dveloppement itratif remet
en question ces pratiques Lattention doit, en
effet, se dtourner du nombre de lignes de
code pour se porter sur la rduction de risques
et la cration de fonctions architecturales de
rfrence.
[JBR-00 p121]
65

Processus Unifié

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Processus Unifié

Uploaded by

Copyright:

Available Formats

Mthodologies de dveloppement

Ce document est rdig partir de la partie I de louvrage

c/o Eyrolles, 2000

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

FCOO / $6 - Le processus unifi (UP)

... l'objectif sous-jacent que poursuit une entreprise

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

Les traits vritablement distinctifs du processus

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

spcifier les artefacts produire

FCOO / $6 - Le processus unifi (UP)

Pilot par les cas dutilisation

L'objectif d'un systme logiciel est de rendre

FCOO / $6 - Le processus unifi (UP)

Centr sur larchitecture

Le rle de l'architecture logicielle est comparable

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

Le dveloppement d'un produit logiciel destin la

FCOO / $6 - Le processus unifi (UP)

mai 2005 / p.-a. sunier

La vie du Processus unifi

FCOO / $6 - Le processus unifi (UP)

bas sur les composants

sappuyant sur un cadre gnral (framework) intgrant

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

2. Les 4 P du dveloppement logiciel

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

Les personnes jouent un rle crucial

Diverses personnes sont impliques dans le

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

Un projet ne se rsume pas du code

Qu'est-ce qu'un systme logiciel ?

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

mai 2005 / p.-a. sunier

Les modles au cur du processus

FCOO / $6 - Le processus unifi (UP)

Le processus dirige les projets

Dans le Processus unifi, le terme processus renvoie

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

Les outils font partie intgrante du

Les processus actuels de dveloppement logiciel sont pris

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

3. Le processus unifi pilot par les cas

FCOO / $6 - Le processus unifi (UP)

FCOO / $6 - Le processus unifi (UP)

Pour apprhender les vrais besoins

Pour diriger le processus

Pour mettre au point l'architecture

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

Le modle des cas d'utilisation aide le client, les

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)