You are on page 1of 65

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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[JBR-00 p19]

1. UP

mai 2005 / p.-a. sunier

La vie du Processus unifi

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

les cycles
les phases
les enchanements d'activits
la rduction des risques
le contrle qualit
la gestion de configuration

FCOO / $6 - Le processus unifi (UP)

[JBR-00 p25-26]

11

2. Les 4 P du dveloppement logiciel


Processus
Automatisation
Template

Participants
Personnes

Projet

Outils

Rsultat
Produit

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

Modle de
conception

FCOO / $6 - Le processus unifi (UP)

Modle de
dploiement

[JBR-00 p32-36]

14

2. Les 4 P

mai 2005 / p.-a. sunier

Les modles au cur du processus

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[JBR-00 p56-57]

23

3. Pilot

mai 2005 / p.-a. sunier

Diagramme de collaboration en analyse

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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


mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[JBR-00 p63]

26

3. Pilot

mai 2005 / p.-a. sunier

Diagramme de classes de conception ralisant un


cas dutilisation (Retirer de largent)

FCOO / $6 - Le processus unifi (UP)

[JBR-00 p64]

27

3. Pilot

mai 2005 / p.-a. sunier

Diagramme de squence, instance dun cas


dutilisation (Retirer de largent)

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

Retirer de largent
-Flot de base

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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


mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.


mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

Gestionnaire
de transactions

FCOO / $6 - Le processus unifi (UP)

Gestionnaire
de comptes

[JBR-00 p91]

46

4. Centr

Vue architecturale du modle de conception (2)

Diagramme de classes (pour raliser le cas dutilisation Retirer de


largent) dcrivant les sous-systmes et les interfaces qui les relient.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[JBR-00 p92]

47

4. Centr

Vue architecturale du modle de conception (3)

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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

Jalon de
larchitecture du
cycle de vie

Jalon de capacit
oprationnelle
initiale

laboration

itr. 2

Jalon de livraison
du produit

Construction

FCOO / $6 - Le processus unifi (UP)

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.

mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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

mai 2005 / p.-a. sunier

Jalon de
larchitecture du
cycle de vie

Jalon de capacit
oprationnelle
initiale

laboration

itr. 2

Jalon de livraison
du produit

Construction

FCOO / $6 - Le processus unifi (UP)

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

mai 2005 / p.-a. sunier

Jalon de
larchitecture
du cycle de vie

Jalon de capacit
oprationnelle
initiale

laboration

itr. 2

Jalon de livraison
du produit

Construction

FCOO / $6 - Le processus unifi (UP)

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

mai 2005 / p.-a. sunier

Jalon de
larchitecture du
cycle de vie

Jalon de capacit
oprationnelle
initiale

laboration

itr. 2

Jalon de livraison
du produit

Construction

FCOO / $6 - Le processus unifi (UP)

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

mai 2005 / p.-a. sunier

Jalon de
larchitecture du
cycle de vie

Jalon de capacit
oprationnelle
initiale

laboration

itr. 2

Jalon de livraison
du produit

Construction

FCOO / $6 - Le processus unifi (UP)

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
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[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.
mai 2005 / p.-a. sunier

FCOO / $6 - Le processus unifi (UP)

[JBR-00 p121]

65