Processus Unifié (UP)

RUP Framework

Rania MZID
Institut Supérieur d’Informatique (ISI Ariana)

1
Processus Unifié
• Le "Processus unifié de développement logiciel " peut être utilisé
par toute personne prenant part au développement de logiciels

• Il s'adresse avant tout aux membres de l'équipe de

développement chargé des activités du cycle de vie qui sont la
formulation des besoins, l'analyse, la conception et les tests; en
d'autres termes, des activités produisant des modèles UML

2
Problématique
Le processus doit
• dicter l'organisation des activités
• diriger les tâches
• Individuelles
• de groupe, équipe...
• spécifier les artefacts à produire
• proposer des critères de contrôle
• des produits du projet
• des activités du projet

3
Processus Unifié
Les traits véritablement distinctifs du processus unifié tiennent en
trois expressions clés :
• piloté par les cas d'utilisation
• centré sur l'architecture
• itératif et incrémental

4
Le processus unifié est piloté par les cas d'utilisation

• Tout doit être fait en adoptant un point de vue utilisateur

Le développement d'un logiciel doit être centré sur l'utilisateur

• La principale qualité d'un logiciel est son utilité

Adéquation du service rendu par le logiciel avec les besoins des
utilisateurs

5
Le processus unifié est piloté par les cas
d'utilisation
Les cas d'utilisation sont le fil
conducteur de toutes les activités

A partir des cas d’utilisation, les

développeurs créent une série de
modèles UML

6
Le processus unifié est centré sur
l'architecture
• L’architecture regroupe les différentes vues du système qui doit être
construit

• Elle doit prévoir la réalisation de tous les cas d’utilisation

• Démarche à suivre:
• Créer une ébauche grossière de l’architecture.
• Travailler sur les cas d’utilisation représentant les fonctions essentielles.
• Adapter l’architecture pour qu’elle prenne en compte ces cas d’utilisation.
• Sélectionner d’autres cas d’utilisation et refaire de même.

• L’architecture et les cas d’utilisation évoluent de façon concomitante.

• Remarque: C’est le rôle de l’architecte de suivre l’évolution de la
architecture dans UP 7
Le processus unifié est centré sur
l'architecture
La description de l’architecture n’est pas monolithique,
elle est constitué de l’agrégation cohérente de différents
points de vue
Les vues sont enrichies de pour former l’architecture de
l’application façon itérative
UP préconise d’utiliser le modèle 4+1((Vues de P.
Krutchen)

8
Le processus unifié est itératif et
incrémental
• Segmentation du travail
• Découpe du projet en “mini-projet” :
• des ITÉRATIONS qui donnent lieu à un INCRÉMENT
• Concentration sur les besoins et les risques,
• Les premières itérations sont des prototypes
• expérimentation et validation des technologies,
• planification,
• Les prototypes définissent le noyau de l'architecture.

9
Itération et Incrément
• Une itération est un mini-projet, c’est à dire un déroulement plus
ou moins complet des principaux enchaînements d’activités,
aboutissant à une version livrée en interne.

• Un incrément est la différence entre la version interne d’une

itération et la version interne de l’itération suivante.

Un incrément est la différence entre deux références

successives (état d’avancement).

10
Itération et Incrément

Remarque: Une version peut être constituée

de plusieurs itérations (mini-projets), cela
dépend de la complexité du projet

11
Itérations
• A chaque itération, les développeurs spécifient les cas
d'utilisations pertinents, créent une conception en se laissant
guider par l'architecture choisie, implémentent cette
conception sous forme de composants et vérifient que ceux ci
sont conformes aux cas d'utilisation.

• Dès qu'une itération répond aux objectifs fixés le

développement passe à l'itération suivante.

• L'élimination des problèmes imprévus fait partie des objectifs

de réduction des risques.

12
Itérations

• Chaque itération comprend un certain nombre de cas

d’utilisation et doit traiter en priorité les risques majeurs.

• Une itération reprend les livrables dans l’état où les a laissé

l’itération précédente et les enrichit progressivement
(incrémental)

13
Bénéfice attendu des itérations
Une itération contrôlée :

• permet de limiter les coûts

• permet de limiter les risques de retard
• identification des risques et résolution des problèmes dès les
premiers stades de développement se traduit par une
accélération du rythme de développement
• grâce à des objectifs clairs à court terme
• facilite l'adaptation à l'évolution des besoins

14
La durée d’une itération
• La plupart des méthodes de développent itératifs recommandent
une durée de 2 á 6 semaines

• Durée < 2 semaines => travail insuffisant pour obtenir des résultats
et des retours d’informations significatifs

• Durée > 6 semaines => Complexité écrasante et le feed-back est

retardé. La brièveté est toujours préférable

 Il faut fixer la durée d’une itération et la respecter

15
Plan de phases, Plan d’itérations
• Dans un PU, il n’y a pas un plan détaillé du projet entier, il existe :

• Un plan de haut niveau, nommé plan de phases, qui permet

d’estimer la date de fin du projet et d’autres jalons majeurs,
sans que les étapes qui permettent d’aboutir a ces jalons
soient finement fixées

• Un plan détaillé, nommé plan d’itérations qui n’organise

qu’une itération á la fois. La planification détaillée est
effectuée de façon adaptative d’une itération a l’autre.

16
 Les 4 "P" du Processus unifié
• Personnes : les architectes, développeurs, testeurs, utilisateurs,
clients et autres intervenants sont les éléments moteurs de tout projet
logiciel.

• Projet : élément d'organisation à travers lequel est géré le

développement du logiciel. L’aboutissement d’un projet est le produit
livré sous forme de version.

• Produit : ensemble d'artefacts (modèles) créés au cours du cycle de

vie du projet, tels que les modèles, les codes sources, les exécutables
et la documentation

• Processus : fournit une définition de l'ensemble des activités requises

pour transformer en produit les besoins exprimés par les utilisateurs.
Un processus offre un cadre générique à la création de projets.

17
Les 4 "P" du Processus unifié

Remarque : Les outils sont les logiciels permettant d'automatiser les activités
définies par le processus
18
Variantes à Unified Process
• Agile Unified Process (AUP), a lightweight variation
• Rational Unified Process (RUP), the IBM / Rational Software
development process
• Entrprise Unified Process (EUP), an extension of the Rationnal
Unified Process
• Essential Uified Process (EssUP), a lightweight variation
• Rational Unified Process-System Engineering (RUP-SE), a version
of RUP tailored by Rational Software for System Engineering
• Open Unified Process (OpenUP), the Eclipse Process Framework
Software development process
• Oracle Unified Method (OUM), the Oracle development and
implementation process
• 2TUP, une variante du Unified Process
19
RUP : Rational Unified Process

20
Processus Unifié de Rational
• Rational Unified Process (RUP) : est un processus de
conception/développement de logiciel défini par Rational
Software.

• Le Processus Unifié de Rational est un processus générique,

itérative et incrémentale qui utilise UML comme langage de
modélisation.

• RUP est l’une des implémentations les plus connues de la

méthode UP permettant de donner un cadre au
développement logiciel.

21
Processus Unifié de Rational

• RUP est une instance de UP …

22
La vie de RUP

Le Processus unifié répète un certain nombre de fois une série de cycles constituant la vie
d'un système... 23
Les phases de RUP

• Pré-étude (Création ou inception): Définir rôle et portée du

produit : étude de rentabilité et objectifs du cycle de vie :
répond à la question le projet vaut il la peine d’être entrepris

24
Les phases d'un cycle

• Elaboration: Créer l’architecture de référence, estimer les coûts

et les risques, planifier la construction : Architecture du cycle
de vie

25
Les phases d'un cycle

Produit

• Construction: développer le système complet et s’assurer que

le produit peut commencer à être utilisé

26
Les phases d'un cycle

Produit

• Transition: livraison du produit aux utilisateurs

27
Quatre éléments de modélisation dans RUP

Membre est le qui : Chef de projet, Analyste, Testeur,

Utilisateur, architecte, etc.
Artéfact est le quoi : Document de l’architecture, Modèle des
cas d’utilisation, Fichier exécutable, etc.
Activité est le comment : Analyse de cas d’utilisation,
Conception de cas d’utilisation, etc.
Enchaînement d’activités est le quand : Modélisation de
métier, implémentation, test, etc.
RUP et vision par activités
1. La modélisation métier : possibilités du système et
besoins des utilisateurs
2. La modélisation des besoins : vision du système et
besoins détaillés des utilisateurs.
3. L’analyse et la conception : manière dont sera réalisé
le projet au cours de la phase 4.
4. L’implémentation : production et acquisition des
composants du système et des exécutables.
5. Les tests : vérification du système dans son ensemble.
6. Le déploiement : livraison du système et formation des
utilisateurs

29
Importance des activités dans chaque phase

30
UML et RUP
RUP est une démarche de développement qui est souvent utilisé
conjointement au langage UML

31
Projection de XP et de 2TUP sur la matrice de RUP

32
Bibliographie

• « The RUP, an Introduction »

P. Kruchten, Addison-Wesley 2000
• « The unified Software Developement Process »
I. Jacobson, G. Booch, J. Rumbaugh, Addison-Wesley 1999
• « Modélisation Objet avec UML »
P.-A. Muller, N. Gaertner, Eyrolles, 2002

http://www-306.ibm.com/software/rational/
• Rational Unified Process :
http://www-306.ibm.com/software/awdtools/rmc/
• Software Architect
http://www-306.ibm.com/software/awdtools/architect /swarchitect /

"Agile and Iterative Development: A Manager's Guide", Craig

Larman, Addison Wesley/Pearson Education, 2003
33
Bibliographie

• 1. P. Kruchten et P. Kroll : Guide pratique du RUP, Campus Press 2003

• 2. J.L Bénard et al. Gestion de projet Extreme Programming, Eyrolles
2002
• 3. T. Cros Maîtriser les projets avec l’Extreme Programming –Pilotage
par les tests-clienst, Cépaduès 2004.
• 4. P. Roques «UML2 –Modéliser une application web» Les Cahiers du
programmeur 3ème édition Eyrolles 2007

34