GL2 / 1.

Processus / RUP    2016/2017
 
1.2 Rational Unified Process 

1.2.1 Introduction 

RUP (Rational Unified Process) est l'une des principales implémentations du processus unifié UP, 
adopté par l'OMG, développé par Rational Software d'IBM. C'est un framework de processus de 
développement  logiciels  itératif  et  incrémental,  centré  sur  le  modèle  objet  et  UML.  Cette 
particularité  de  framework  permet  à  l'organisation  de  développement  de  logiciels  d'adapter  ou 
d'étendre le RUP pour couvrir ses besoins spécifiques.  

RUP  saisit  les  meilleures  pratiques  du  développement  moderne  de  systèmes  logiciels  dans  une 
forme convenable pour une large classe de projets et d'organisations. Il couvre principalement les 
pratiques suivantes :  

ƒ Développement itératif  
ƒ Gestion des besoins 
ƒ Utilisation d'architectures à base de composants 
ƒ Modélisation visuelle 
ƒ vérification continue de la qualité du logiciel  
ƒ Contrôle des changements du logiciel 

1.2.2 Eléments de construction du RUP 

RUP  définit  des  blocs  et  des  éléments  de  construction  décrivant  ce  qu'il  faut  produire  (work 
products), les compétences nécessaires (roles) et la manière dont il faut procéder pour accomplir 
un travail (tasks) 

− Roles (who) : définit un ensemble de connaissances, compétences et responsabilités associées 
− Work products (what) : représente un résultat d'une tâche qui peut être des documents, des 
modèles, etc. 
− Tasks (how) : décrit  une unité de travail, affectée à un rôle, qui fournit  un résultat significatif.  

1.2.3 Organisation du RUP 

RUP  se  déploie  sur  deux  dimensions  :  dimension  dynamique  (les  phases  du  processus  et  leur 
ordre  temporel)  et  dimension  statique  (les  disciplines,  appelées  précédemment  workflows,  qui 
correspondent aux activités des développeurs et des autres acteurs).  

1.2.2.1. Dimension dynamique 

Cette dimension représente l'organisation dynamique du processus sur une échelle temporelle. Le 
cycle de vie du logiciel est décomposé en cycles de développement; chaque cycle travaillant sur 
une  nouvelle  génération  du  produit.  RUP  divise  un  cycle  de  développement  en  quatre  phases 
consécutives;  initialisation,  élaboration,  construction  et  transition.  La  fin  de  chaque  phase  est 
marquée par un repère bien défini indiquant que les objectifs clés ont été atteints.  

  12
 
GL2 / 1.Processus / RUP    2016/2017
 
Chaque phase peut être itérée plusieurs fois avant de passer à la phase suivante (micro‐itération) 
et  l'ensemble  des  phases  est  typiquement  itéré  plusieurs  fois  comme  tout  autre  modèle  itératif 
(macro‐itération). 

‐ Phase initialisation 

Correspond à l'étude de faisabilité et consiste à établir un business case pour le système et peut 
amener à l'abandon du projet 

‐ Phase élaboration 

Correspond à l'analyse des besoins et fait usage intensif des cas d'utilisation (et donc de scénarios) 
pour mieux comprendre le problème posé et expliciter les spécificités du domaine. Des prototypes 
sont  développés  pour  évaluer  concrètement  des  points  techniques  risqués;  le  RUP  préconise  le 
développement  préliminaire  d’une  architecture  exécutable,  c’est‐à‐dire  une  version  du  système 
avec un nombre très limité de fonctionnalités mais dont le “squelette” est fixé. 

‐ Phase construction 

Correspond  à  la  conception  et  au  développement  et  caractérisée  par  une  progression 
incrémentale  et  la  production  de  plusieurs  versions  du  système  résolvant  les  problèmes 
techniques à haut risque en priorité. 

‐ Phase transition 

Correspond à l'activité de déploiement et marque le début de la maintenance du logiciel et la mise 
en  place  du  système  auprès  de  ses  utilisateurs  (production  de  manuels  d'utilisation,  formation, 
etc.) ainsi que la préparation de futures évolutions. 

1.2.2.2 Dimension statique 

Sur  la  base  d'une  organisation  selon  le  contenu,  le  RUP  définit  des  disciplines  de  base  et  des 
disciplines de support. Les  disciplines de base sont : 

ƒ Business Engineering 
ƒ Requirements  
ƒ Analysis and design  
ƒ Implementation  
ƒ Test 
ƒ Deployment 

Les  disciplines de support sont : 

ƒ Configuration and change management 
ƒ Project management 
ƒ Environment   

  13
 
GL2 / 1.Processus / RUP    2016/2017
 

 
Fig. 1.1 Interaction Phases‐Disciplines 

  14