Le Processus

Unifi
ou UP
Landoulsy Mouhamed Boubaker
DSI202
1

Sommaire
I. Definition
II. Objectif
III.Les activits
IV. Les phases

I. Dfinition
Le processus unifi est un processus de dveloppement
logiciel itratif, centr sur l'architecture, pilot par des
cas d'utilisation et orient vers la diminution des risques.
C'est un patron de processus pouvant tre adapt une
large classe de systmes logiciels, diffrents domaines
d'application, diffrents types d'entreprises, diffrents
niveaux de comptences et diffrentes tailles de
l'entreprise.
3

I-1. UP est itratif

L'itration est une rptition d'une
squence d'instructions ou d'une
partie de programme un nombre de
fois fix l'avance ou tant qu'une
condition dfinie n'est pas remplie,
dans le but de reprendre un
traitement
sur
des
donnes
diffrentes.

Une itration prend en compte un

certain nombre de cas d'utilisation et
traite en priorit les risques majeurs.
4

I-2. UP est centr sur

l'architecture
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.
5

I-3. UP est pilot par

les cas d'utilisation
d'UML
Le

but
principal
d'un
systme
informatique est de satisfaire les besoins
du client. Le processus de dveloppement
sera donc accs sur l'utilisateur.

Les

cas
d'utilisation
d'illustrer ces besoins.

permettent

Ils dtectent puis dcrivent les besoins

fonctionnels (du point de vue de
l'utilisateur), et leur ensemble constitue
le modle de cas d'utilisation qui dicte les
fonctionnalits compltes du systme.
6

II. Objectif
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.
7

 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.
En raison de sa complexit, le systme est dcrit sous
forme d'activits qui donnent peu peu naissance un
systme oprationnel.

III. Les activits

III-1. Expression des besoins

L'expression des besoins comme son nom l'indique, permet de
dfinir les diffrents besoins :
inventorier lesbesoins principauxet fournir une liste de leurs fonctions
recenser lesbesoins fonctionnels(du point de vue de l'utilisateur) qui
conduisent l'laboration des modles de cas d'utilisation

apprhender lesbesoins non fonctionnels(technique) et livrer une liste

des exigences.

Le modle de cas d'utilisation prsente le systme du point de vue

de l'utilisateur et reprsente sous forme de cas d'utilisation et
d'acteur, les besoins du client.
10

III-2. Analyse
L'objectif de l'analyse est d'accder une comprhension des
besoins et des exigences du client. Il s'agit de livrer des
spcifications pour permettre de choisir la conception de la
solution.
Un modle d'analyse livre une spcification complte des besoins
issus des cas d'utilisation et les structure sous une forme qui
facilite la comprhension (scnarios), la prparation (dfinition de
l'architecture), la modification et la maintenance du futur systme.
Il s'crit dans le langage des dveloppeurs et peut tre considr
comme une premire bauche du modle de conception.
11

III-3. Conception
La

conception permet d'acqurir une comprhension

approfondie
des
contraintes
lies
au
langage
de
programmation, l'utilisation des composants et au systme
d'exploitation.
Elle dtermine les principales interfaces et les transcrit
l'aide d'une notation commune.
Elle constitue un point de dpart l'implmentation :
elle dcompose le travail d'implmentation en sous-systme
elle cre une abstraction transparente de l'implmentation
12

III-4. Implmentation
L'implmentation est le rsultat de la conception pour
implmenter le systme sous formes de composants, c'est-dire, de code source, de scripts, de binaires,
d'excutables et d'autres lments du mme type.
Les objectifs principaux de l'implmentation sont de
planifier les intgrations des composants pour chaque
itration, et de produire les classes et les sous-systmes
sous formes de codes sources.
13

III-5. Test
Les tests permettent de vrifier des rsultats de
l'implmentation en testant la construction.
Pour mener bien ces tests, il faut les planifier pour
chaque itration, les implmenter en crant des cas de
tests, effectuer ces tests et prendre en compte le rsultat
de chacun.

14

IV. Les phases

15

IV-1. Analyse des besoins

L'analyse des besoins donne une vue du projet sous forme
de produit fini.
Cette phase porte essentiellement sur les besoins
principaux (du point de vue de l'utilisateur), l'architecture
gnrale du systme, les risques majeurs, les dlais et les
cots
On met en place le projet.
16

 Elle rpond aux questions suivantes :

que va faire le systme ? par rapport aux utilisateurs principaux,
quels services va-t-il rendre?
quelle va tre l'architecture gnrale (cible) de ce systme
quels vont tre : les dlais, les cots, les ressources, les moyens
dployer?

17

IV-2. Elaboration
L'laboration reprend les lments de la phase d'analyse
des besoins et les prcise pour arriver une spcification
dtaille de la solution mettre en uvre.
L'laboration permet de prciser la plupart des cas
d'utilisation, de concevoir l'architecture du systme et
surtout de dterminer l'architecture de rfrence.
Au terme de cette phase, les chefs de projet doivent tre
en mesure de prvoir les activits et d'estimer les
ressources ncessaires l'achvement du projet.

18

 Les taches effectuer dans la phase laboration sont les

suivantes :
crer une architecture de rfrence
identifier les risques, ceux qui sont de nature bouleverser le
plan, le cot et le calendrier
dfinir les niveaux de qualit atteindre

formuler les cas d'utilisation pour couvrir les besoins fonctionnels

et planifier la phase de construction
laborer une offre abordant les questions de calendrier, de
personnel et de budget

19

IV-3. Construction
La construction est le moment o l'on construit le produit.
L'architecture de rfrence se mtamorphose en produit
complet.
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.

20

IV-4. Transition
Le produit est en version bta. Un groupe d'utilisateurs
essaye le produit et dtecte les anomalies et dfauts.
Cette phase suppose des activits comme la formation des
utilisateurs clients, la mise en oeuvre d'un service
d'assistance et la correction des anomalies constates.

21

FIN.
Je vous remercie pour votre
attention

22