Exposer sur le prossus

unifi.
Prsenter par:

Plant du travail:
I.

Dfinition

-1. UP est itratif

-2. UP est centr sur l'architecture
-3. UP est pilot par les cas d'utilisation d'UML
II. Vie du processus unifi
-1. L'architecture bidirectionnelle
III. Les activits
-1. Expression des besoins
-2. Analyse
-3. Conception
-4. Implmentation
-5. Test
IV. Les phases
-1. Analyse des besoins
-2. Elaboration
-3. Construction
-4. Transition
Conclusion:

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 adapte une large classe de systmes logiciels,
diffrents domaines d'application, diffrents types d'entreprises,
diffrents niveaux de comptences et diffrentes tailles de
l'entreprise.

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.
Elle qualifie un traitement ou une procdure qui excute un groupe
d'oprations de faon rptitive jusqu' ce qu'une condition bien
dfinie soit remplie.

I-1. UP est itratif

Une itration prend en compte un certain nombre de cas d'utilisation et traite en

priorit les risques majeurs

I-2. UP est centr sur

l'architecture

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 permettent d'illustrer ces besoins.
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.

I-3. UP est pilot par les cas

d'utilisation d'UML

II. Vie du processus unifi

L'objectif d'un processus unifi est de matriser la complexit des
projets informatiques en diminuant les risques.
UP est un ensemble de principes gnriques adapt en fonctions
des spcificits des projets. UP rpond aux proccupations
suivantes :
QUI participe au projet ?
QUOI, qu'est-ce qui est produit durant le projet ?
COMMENT doit-il tre ralis ?
QUAND est ralis chaque livrable ?

II-1. L'architecture
bidirectionnelle
UP gre le processus de dveloppement par deux axes.
L'axe vertical reprsente les principaux enchanements
d'activits, qui regroupent les activits selon leur nature. Cette
dimension rend compte l'aspect statique du processus qui
s'exprime en terme de composants, de processus, d'activits,
d'enchanements, d'artefacts et de travailleurs.
L'axe horizontal reprsente le temps et montre le droulement
du cycle de vie du processus; cette dimension rend compte de
l'aspect dynamique du processus qui s'exprime en terme de
cycles, de phases, d'itrations et de jalons.

II-1. L'architecture
bidirectionnelle

II-1. L'architecture
bidirectionnelle
UP rpte un certain nombre de fois une srie de cycle qui
s'articule autours de 4 phases :
Analyse des besoins.
laboration.
Construction.
Transition.

II-1. L'architecture
Pour mener efficacement un tel cycle, les dveloppeurs ont
bidirectionnelle

besoins de toutes les reprsentations du produit logiciel :

un modle de cas d'utilisation.

un modle d'analyse : dtailler les cas d'utilisation et procder

une premire rpartition du comportement.
un modle de conception : finissant la structure statique du
systme sous forme de sous systmes, de classes et interfaces.
un modle d'implmentation : intgrant les composants.
un modle de dploiement : dfinissant les nuds physiques des
ordinateurs.
un modle de test : dcrivant les cas de test vrifiant les cas
d'utilisation.
une reprsentation de l'architecture.

III. Les activits

III-1. Expression des besoins
L'expression des besoins comme son nom l'indique, permet de dfinir
les diffrents besoins :
inventorier les besoins principaux et fournir une liste de leurs
fonctions
recenser les besoins fonctionnels (du point de vue de l'utilisateur)
qui conduisent l'laboration des modles de cas d'utilisation
apprhender les besoins 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.

III. Les activits

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.

III. Les activits

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

III. Les activits

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.

III. Les activits

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.

IV. Les phases

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

IV. Les phases

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

IV. Les phases

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.

IV. Les phases

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 uvre d'un service d'assistance et la
correction des anomalies constates.

Conclusion: