You are on page 1of 18

Rational Unified Process

Hafedh Mili

Rational Unified Process


1. Principes de base

2. Les phases

3. Les activités (workflows)

Copyright Hafedh Mili 2005 2

1
Rational Unified Process
• Processus de développement “unifié”
développé par Rational
• Combine les meilleurs idées émanant des
méthodologies des trois “amigos”
– Booch
– Jacobson
– Rumbaugh

Copyright Hafedh Mili 2005 3

Rational Unified Process


• La communauté (OMG) a été capable de
normaliser les notations (UML) mais pas le
processus
– Trop de chicanes
– Aucune valeur
• RUP™ est propriété de Rational Software
Corp/IBM

Copyright Hafedh Mili 2005 4

2
Rational Unified Process
• Une synthèse de beaucoup de bonnes
pratiques de développement de logiciel
– Itération, gestion de risque
• Générique
• Configurable
– Selon organisation, domaine, contraintes (e.g.
mise en marché), technologie

Copyright Hafedh Mili 2005 5

Rational Unified Process


• “use-case driven, architecture-centric,
Iterative, and incremental”
– Orienté cas d’utilisation
– Orienté architecture
– Itératif
– Incrémental

Copyright Hafedh Mili 2005 6

3
Rational Unified Process
• Une distinction entre phases du projet et activités
(workflows)
– On fait de tout, tout le temps
– Ce qui distingue les phases: la prépondérance des activités
• Pour chaque activité/workflow, RUP définit:
– Les livrables
– Les sous-activités
– Les intervenants
• À un certain niveau d’abstraction, RUP est
indépendant des méthodologies orientées objet
Copyright Hafedh Mili 2005 7

Rational™ Unified Process


Process workflows Inception Elaboration Construction Transition
Business modeling
Requirements
Analysis & design
Implementation

Test
Deployment
Config Management

Project management
Environment
Iterations Iter1 Iter2 Iter3 It4 It5 It6 It7 It8

Copyright Hafedh Mili 2005 8

4
RUP est “use-case driven”
• Use-case (cas d’utilisation): Une
fonctionalité du système qui apporte une
valeur pour l’utilisateur final du système
• Les cas d’utilisation sont une façon de
capturer les exigences

Copyright Hafedh Mili 2005 9

RUP est “use-case driven”


• Chaque cas d’utilisation représente une
unité de fonctionnalité du système
• Les cas d’utilisation constituent aussi:
– Des unités de développement: chaque
incrément doit implanter un nombre de cas
d’utilisation
– Des unités de test
– Des unités de réutilisation
Copyright Hafedh Mili 2005 10

5
RUP est orienté architecture
• Architecture: organisation du système
• L’architecture doit permettre d’implanter les
fonctionnalités exigées tout en:
– Répondant aux exigences de performance,
sécurité, fiabilité (propriétés observables à
l’exécution)
– Facilitant l’évolution, maintenance, et
réutilisation
Copyright Hafedh Mili 2005 11

RUP est orienté - architecture


• RUP est orienté architecture dans le sens suivant:
RUP vise la conception d’une architecture stable
du système dès les premiers incréments
• Comment?
– En s’attaquant aux use-cases qui éprouvent
l’architecture … ☺
• Accepter / planifier / prévoir que l’architecture se
stabilisera au bout de quelques itérations

Copyright Hafedh Mili 2005 12

6
RUP est incrémental
• Le produit final est livré en incréments
– Chaque incrément livre une fonctionnalité
ayant une valeur pour l’utilisateur final
– Chaque incrément consiste en un ensemble de
cas d’utilisation
– Les incréments doivent être de courte durée
(quelques semaines à quelques mois)
– Les incréments sont des mini-projets dans un
projet
Copyright Hafedh Mili 2005 13

RUP est itératif


• Accepter / planifier / prévoir que certains
livrables développés dans le cadre d’un
incrément puissent être révisés durant les
incréments suivants

Copyright Hafedh Mili 2005 14

7
Différence entre incrémental et
itératif

Incrémental

Itératif
Copyright Hafedh Mili 2005 15

Rational Unified Process


1. Principes de base

2. Les phases

3. Les activités (workflows)

Copyright Hafedh Mili 2005 16

8
Rational™ Unified Process
Process workflows Inception Elaboration Construction Transition
Business modeling
Requirements
Analysis & design
Implementation

Test
Deployment
Config Management

Project management
Environment
Iterations Iter1 Iter2 Iter3 It4 It5 It6 It7 It8

Copyright Hafedh Mili 2005 17

Quatre phases
• Inception

• Élaboration

• Construction

• Transition
Copyright Hafedh Mili 2005 18

9
Inception
• Objectif : justifications affaires du projet (build
the business case)
• Étapes:
– Délimiter le système (portée), et identifier ses interfaces
avec le monde externe
– Proposer ou esquisser une architecture plausible du
système
– Identifier les risques concernant la faisabilité du
système
– Montrer que le système qu’on veut construire peut
résoudre le problème d’affaires. Implique souvent le
développement d’un prototype/POC
Copyright Hafedh Mili 2005 jetable 19

“Élaboration” (développement)
• Développer une architecture/infrastructure qui
permettra d’implanter les fonctionnalités à impact
architectural
• Identifier les risques qui pourraient entraîner des
surcoûts, retards, etc.
• Spécifier les exigences de qualité
• Élicitation des cas d’utilisation pour la majeure
partie de la fonctionnalité (80%)
• Faire un plan de projet avec estimation de coût et
de ressources
Copyright Hafedh Mili 2005 20

10
Rational™ Unified Process
Process workflows Inception Elaboration Construction Transition
Business modeling
Requirements
Analysis & design
Implementation

Test
Deployment
Config Management

Project management
Environment
Iterations Iter1 Iter2 Iter3 It4 It5 It6 It7 It8

Copyright Hafedh Mili 2005 21

Construction
• Finir la capture des exigences (i.e. tous les
cas d’utilisation)
• Finir l’analyse, conception, implementation,
et test des cas d’utilisation
• Maintenir l’intégrité architecturale
(modifier en cas de nécessité)
• Surveiller les risques et les gérer

Copyright Hafedh Mili 2005 22

11
Transition
• Préparation de l’environnement de déploiement
• Production de documentation pour la “release”
(manuels usagers, manuels d’entretien)
• Ajustement du logiciel (fine-tuning) en fonction
de l’environnement opérationnel
• Correction d’erreurs découvertes en beta
• Étamper la version officielle, et dormir pendant
toute la fin de semaine

Copyright Hafedh Mili 2005 23

Phases, itérations, et activités


• Chaque phase peut comporter plusieurs
itérations
• Chaque itération impliquera les diverses
activités (exigences, analyse, conception,
implémentation, test)
• L’emphase sur les différentes activités
diffère d’une phase à une autre

Copyright Hafedh Mili 2005 24

12
Rational™ Unified Process
Process workflows Inception Elaboration Construction Transition
Business modeling
Requirements
Analysis & design
Implementation

Test
Deployment
Config Management

Project management
Environment
Iterations Iter1 Iter2 Iter3 It4 It5 It6 It7 It8

Copyright Hafedh Mili 2005 25

Rational Unified Process


1. Principes de base

2. Les phases

3. Les activités (workflows)

Copyright Hafedh Mili 2005 26

13
Les activités
• Deux types d’activités
– Activités de base, consistant en la production de
livrables:
• Exigences, analyse, conception, implementation, test
– Activités secondaires de support aux activités
de base:
• Gestion de configuration, mise en place de
l’environnement de développement, gestion de
projet
Copyright Hafedh Mili 2005 27

Exigences
• Objectif: que doit faire le logiciel?

• On convient de distinguer deux types d’exigences:


– Exigences fonctionnelles (quoi)
– Exigences non-fonctionnelles (comment)
• La distinction n’est pas toujours claire (ou utile)
– “le système doit produire un journal de transactions”
– “le système doit sauvegarder les données en moins de
2K” … quand “le système” est un logiciel de
compression de données
Copyright Hafedh Mili 2005 28

14
Exigences
• Lister les exigences potentielles / candidates
• Établir le contexte:
– Modèle du domaine (entités)
– Modèle du processus d’affaire
• Éliciter les exigences fonctionnelles (cas
d’utilisation)
• Éliciter les exigences non-fonctionnelles
(performance, fiabilité, réutilisabilité, etc.)
Copyright Hafedh Mili 2005 29

Analyse
• Traduire les exigences de l’usager en
spécifications du logiciel
• La conception et l’implémentation se
préoccuperont de comment réaliser les
spécifications

Copyright Hafedh Mili 2005 30

15
Analyse
• Activités et livrables
– Produire un modèle de classes
• Des classes qui correspondent aux descriptions d’entités du
domaine qui seront emmagasinées par le système
– Produire un modèle détaillé de cas d’utilisation
• Reprendre les cas d’utilisation et traduire leur comportement
sous forme (de diagrammes) d’intéractions entre objets
– Modulariser les cas d’utilisation et les classes en des
modules d’analyse (analysis packages)
– Produire une première architecture fonctionnelle

Copyright Hafedh Mili 2005 31

Conception
• Objectif: fournir un plan pour la réalisation
(l’implémentation)
• Prend en comptes les exigences non-
fonctionnelles

Copyright Hafedh Mili 2005 32

16
Activités et livrables
• Conception architecturale:
– Choisir style architectural
– Identifier composantes
– Spécifier interfaces des composantes
• Conception détaillée
– Modèle de classe – conception
– Modèle comportemental – conception
– Modèle de use-case - conception

Copyright Hafedh Mili 2005 33

Implémentation
• Activités
– Implémentation de l’architecture
– Implémentation de classe
– Effectuer tests unitaires
– Implémenter sous-systèmes
– Intégration de sous-systèmes

Copyright Hafedh Mili 2005 34

17
Test
• Planifier les tests
• Concevoir les tests
• Implémenter les tests
• Effectuer tests d’intégration
• Effectuer tests systèmes
• Évaluer les tests

Copyright Hafedh Mili 2005 35

18