Université Saad Dahleb BLIDA

Département Informatique
3eme année LMD
Année 2007/2008
Module : Système d’Information.
Prof : Mme ARKAM.

Exposé sur :

Le Processus De Développement Logiciel

" UP "
(Unified Process-Processus Unifié)

Réalisé Par : Hamizi Soumia & Nehab Wissam

"Le processus unifié est un processus de développement
logiciel, c'est-à-dire qu’il regroupe les activités à mener
pour transformer les besoins d’un utilisateur en système
logiciel’’.
 Partie « A »
Rappel

Cycle de développement d’un logiciel

1. cycle du développement de logiciel

Le but du développement de logiciel est de produire un

logiciel de qualité, de nombreux critères existent afin de
définir la qualité d'un logiciel:

ü Exactitude.
ü Portabilité
ü Extensibilité.
ü Réutilisabilité.
ü Vérifiabilité.
ü Intégrité.
ü Robustesse.
2. Cycle de développement du logiciel

ØDéterminer les besoins.

ØConception préliminaire.
ØConception détaillée.
ØImplémentation.
ØIntégration.
ØTest.
ØMaintenance.
 3.Modèle de cycle de développement

A chaque phase, des cycles doivent être soumis à des tests

afin d'assurer une certaine qualité qui est déterminante pour
le génie logiciel, de nombreux modèles existent pour cela,
les plus connus sont:
•Modèle en cascade.
•Modèle en V.
•Modèle par incrément.
•Modèle en spirale.
 Partie « B »
UP unified process
 1. Introduction Processus unifié « UP »

L’approche orientée objet de développement de système

d’information informatisé (SII) de gestion est actuellement
influencée par UP ou Unified Processus, en français ; nous
nommons « Processus Unifié » , le terme de processus choisi
par les auteurs et qui doit être compris comme « chemin
raisonné ».
 2. Son origine

Le terme "Unifié" est très approprié puisqu'il s'agit de la fusion des

travaux d'Ivar Jacobson, Grady Booch et de James Rumbaugh, enrichi
de nombreux apports issus d’UML, et du produit commercial RUP, sorti
en 1998 et toujours mis à jour par IBM.

Les 3 auteurs ont publié leur méthode sous le titre : « The Unified
Software Development Process » en 1999.
Figure 1 - Genèse du Processus unifié
 3.Modèle UP

Unified Process est une méthode générique de développement, C'est

une méthode qui permet l'évolution telle que le fait le modèle en
spirale, L'emphase de ce modèle et mise sur la réduction des risques,
Les risques sont sans cesse évalués à chaque cycle, Un cycle est
décomposé en étapes, il impose la création de beaucoup de
documentation, et donc UP est une méthode générique
itérative et incrémentale.
3.1 Modèle de développement itératif
Fréquemment, une version du logiciel est présentée au
client, une telle approche permet de réduire les risques,
ainsi La qualité peut à chaque fois être vérifiée.

3.2 Gestion des exigences

Énormément d'importance est mise au niveau des
exigences afin qu'elle soit complètement prise en
compte.

3.3 Utilisation de composant

La création du système en assemblant des composants
est privilégié, l'achat de composant permet une certaine
garantie de test.
3.4 Diagramme des exigences
Beaucoup de diagrammes sont disponibles, le client peut
ainsi plus aisément comprendre, la grande quantité de
diagrammes permettent de voir le système sous
différentes facettes.

3.5 Vérification de la qualité

La qualité est constamment vérifiée à chaque version du
logiciel, on s'approche progressivement des besoins du
client, le risque d'erreur est moindre.
3.6 Gestion des changements
Les demandes de changement sont enregistrées ensuite
on passe par une phase d'acceptation, les changements
sont ainsi mieux maîtrisé.
 4.Cycle de vie du processus unifié 

L'objectif d'un processus unifié est de maîtriser la complexité

des projets informatiques en diminuant Les risques.

UP est un ensemble de principes génériques adapté en

fonctions des spécificités des projets, il Répond aux
préoccupations suivantes :
- QUI participe au projet ?
- QUOI, qu'est-ce qui est produit durant le projet ?
- COMMENT doit-il être réalisé ?
- QUAND est réalisé chaque livrable ?
Quelques activités (disciplines) font parties de UP, ce
sont les éléments à gauche de l'image.
Besoin, Analyse, Conception, Implémentation , Test.
 4.1 activités
Besoin
Cette activité permet de connaître le domaine du système
qui doit être construit, ces informations permettront de
créer des cas d'utilisation, une liste d'entité et d'objets-
métier sont saisit.

Analyse
Les besoins et exigences du client doivent être
minutieusement compris afin de pouvoir arriver à faire
une conception du système, on raffine ces informations
afin d'arriver à une analyse plus précise, cette analyse
permet de faciliter davantage les étapes suivantes.
Conception
Cette activité permet de comprendre de façon plus
approfondie le système, les contraintes du système
doivent être définies : langage de programmation,
système d'exploitation, technologie utilisée, des
interfaces entre les sous-systèmes doivent être
déterminées, c'est l'endroit où tout le système est pensé
et analysé en vue de son implémentation, une excellente
planification du système doit être faite.
Implémentation
Cette activité utilise les étapes précédentes afin de construire un système
au niveau du code, à chaque itération, une intégration est faite, des tests
unitaires sont faits, les classes identifiées à la phase conception sont
implémentées.
Test
Cette activité permet de vérifier les résultats de la phase précédente.

Ainsi quatre phases composent UP:

§Création
§Élaboration
§Construction
§Transition
 4.2 Les phases
Création
Une idée du système est donnée, on identifie ce que le
système va faire, on établit l'architecture, on définit le
planning, les coûts et ressources nécessaires, une liste
des risques est identifiée, les limites du système sont
définies, c.à.d ce que le système fait et ce qu'il ne fait
pas.

Élaboration
Cette phase permet de concevoir et valider
l'architecture du système, les cas d'utilisations sont
Construction
précisés.
La construction du système est faite, les exigences
définies doivent être comblées.
Transition
Cette étape vérifie ce qui a été fait, le produit est
installé chez le client, les anomalies de dernières
minutes sont corrigées, le système est configuré.
 5.UP Mode d’emplois

Trois concepts centraux supportent toujours le Processus

unifié (UP) :

1• il est piloté par les cas d’utilisation:

ils permettent de décrire les services attendus par chacun des
futurs utilisateurs du système.

2• il est centré sur l’architecture:

l’architecture est l’ensemble des choix significatifs de
construction réalisés pendant la modélisation.
3• il est itératif et incrémental:

de par la complexité des organisations, des contraintes de

temps ou encore de nouveautés technologiques constantes de
nombreux risques mettre en péril un développement logiciel ;
une démarche itérative permet de réduire dans les premières
itérations les risques les plus élevés.
- Une itération est un sous-projet dérivé du projet
informatique, Le découpage du projet en plus
petite entité réduit la complexité et les risques,
un incrément est une version du système.
 6.Conclusion
Le processus unifié est un processus de développement
logiciel itératif, 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ée à une large
classe de systèmes logiciels, à différents domaines
d'application, à différents types d'entreprises, à différents
niveaux de compétences et à différentes tailles de
l'entreprise.

Ceci dit, ce modèle, comme tous les autres présentent

quelques défauts, il est coûteux à mettre en œuvre et à
personnaliser, l'emphase est mise au processus, peu de
place est accordée au développement, le codage ainsi
que la technologie n'occupent pas assez de place, les
systèmes ayant majoritairement que des algorithmes, peu
d'interaction avec des utilisateurs ne conviennent pas à
Merci pour Votre
Attention