Rationaliser la conception participative

Logiciel
Logiciel Croissance en nombre
Logiciel Logiciel
Logiciel
Logiciel

Logiciel Croissance en taille

Croissance en
complexité
Rational Unified Process
Rational Unified Process (RUP) : est un
processus de conception/développement de logiciel
défini par Rational Software.

http://www.rational.com/
 Organisation séquentielle
Le risque est au début
• Les décideurs prennent le risque
• Les concepteurs assument…
• Les développeurs suivent…
Prérequis
R
I Conception
S
Q Développement
U
E Tests unitaires

Test système

TEMPS
Organisation participative
Le risque est partagé
Equipe
Inception

Conception
Risque

Construction

Transition

Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition Post-

Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration deployment

Temps
Développement itératif
– Les risques sont évalués avant
– Les premières itérations permettent
d’avoir des retours utilisateur
– Le test et l’intégration sont continus
– Les jalons permettent de fixer les objectifs
– Les avancées sont mesurées au fur et à
mesure de l’implémentation
– Des maquettes intermédiaires peuvent
être déployées
Accroître la productivité en
conception/développement
Tous les membres partagent
• Des bases de connaissance
• Une même méthode
Performance
• Une organisation du travail Engineer

• Un langage
Database
Administrator
Release
Engineer
Project
Leader

Analyst Designer / Tester

Developer
Le langage RUP : un modèle visuel
Activité

Oriente Se focalise

Guide

Travailleur

Automatisent Fédèrent

Instrumentent Accélèrent
Outils Services

Amplifient Utilisent
Quatre éléments de modélisation dans RUP

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

Testeur, Utilisateur, 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.
 Notations
Décrit une partie du
travail
Activité
Membre

Décrit un rôle
Use-Case
dans le Specifier
processus
Artéfact
Responsable de

Décrit une connaissance

ou une donnée
Use Case Use-Case
Package
 Exemple : rôles du concepteur
activité1 activité2

Concepteur Analyse de cas Conception de

d ’utilisation cas d ’utilisation

est responsable de produit

Connaissance
Réalisation de cas d ’utilisation Document
Planification des RH
R e s o u rc e Wo rk e r A c tiv itie s

Paul Designer Define Operations

...

Mary Us e-Case Specifier Des cribe a Use Cas e

...

Joe Us e-Case Designer Dis tribute Behavior

...

Sylvia Design Reviewer Review Us e-Cas e Model

...

Stefan Archite ct Define Us e-Case View

Define Logical Viiew
...

Chaque membre est

considéré comme un
acteur
Exemple d’un Workflow
RUP est itératif et incrémental
Exigences Analyse & conception

Implémentation
Gestion
Environnement
Planification initiale

Déploiement

Planification
Tests

Chaque itération a pour finalité une version exécutable.

Architecture bidirectionnelle
du RUP
 Enchaînement d’activités dans RUP

6 enchaînements
d'activités essentielles
• Modélisation du métier
3 enchaînements
• Gestion des exigences
d'activités de soutien
• Analyse et Conception
• Gestion de Projet
• Implémentation
• Gestion de la configuration
• Test et des changements
• Déploiement • Environnement
 Enchaînement d’activités dans RUP
Modélisation du métier

Il a pour but
• de décrire la structure et la dynamique de
l'organisation (ou de l ’équipe participative)

• de garantir que les clients, les utilisateurs finaux et les

développeurs partagent une vision commune de
l'organisation

• de réaliser une base d'information qui contiendra le

cahier des charges du produit et la planification des
tâches de l ’organisation.
 Enchaînement d’activités dans RUP
Gestion des exigences

Il a pour but

• de définir une vision du produit,

• de traduire cette vision en un modèle de cas d'utilisation,

(ce modèle, accompagné des spécifications externes,
constitue le cahier des charges logicielles),

• d’organiser et de gérer les exigences,

• de définir et de construire une maquette de l'interface

utilisateur.
 Enchaînement d’activités dans RUP
Analyse et conception

• L'objectif de l'analyse est de comprendre le cahier des

charges et d ’écrire les spécifications internes.  L'analyse
permet d'obtenir une vue interne du produit
• La conception a pour but de définir l'architecture du
système/produit

• L'analyse se concentre sur le "quoi faire", la conception se

concentre sur le "comment le faire".
Enchaînement d’activités dans RUP
Implémentation

• L'objectif est de créer les composants : sources,

scripts, puis exécutables... 
 Enchaînement d’activités dans RUP
Test

• La phase de test a pour objectif d'évaluer le niveau de

qualité atteint par le produit et d'en tirer les conclusions.
Elle s'appuie sur les cas d'utilisation et définit des cas de
test.
Enchaînement d’activités dans RUP
Déploiement

• Le but de l'enchaînement des activités de

déploiement est de livrer le produit aux utilisateurs
finaux.
Enchaînement d’activités dans RUP
Gestion de projet

• La planification d'un projet itératif

• La gestion des risques

• Le contrôle des progrès.

Enchaînement d’activités dans RUP
Gestion de la configuration et des changement

• Le but de la gestion de la configuration et des

changements est de garder la trace de tous les éléments
tangibles qui participent au développement, et de suivre
leur évolution.
Enchaînement d’activités dans RUP
Environnement

Il a pour but de fournir

• un processus de développement adapté au projet

• des outils de travail qui aident à réaliser les activités

et les artefacts du processus.
Phases dans RUP

Inception Conception Construction Transition

Jalon : Jalon : Jalon : Jalon :

objectifs et architecture du prototype livraison du
cycle de vie système produit

Temps
Inception

• Il s’agit de décrire quelle vision on a du

produit final et où on veut aller, de réaliser
une étude de rentabilité et de définir le
projet.
• La phase Inception se termine par le jalon
«  objectifs et cycle de vie »
Conception

• Il s’agit de
¤ planifier les activités et les ressources
nécessaires à la réalisation du projet
¤ spécifier les fonctionnalités
¤ concevoir l’architecture
• La phase de conception se termine par
le jalon «  architecture du système »
 Construction

• Il s’agit de construire le système et de faire

évoluer la vision, l ’architecture et les plans de
développement jusqu’à l ’obtention d’un
produit prêt à être testé.
• La phase construction se termine par le jalon
«  prototype »
Transition

• Il s’agit de soumettre le produit aux

utilisateurs (béta-test),
• La phase transition se termine par le
jalon « livraison du produit » ou par une
nouvelle itération
Ambition de RUP

• Faire face aux changements en

cours du projet qui restent les causes
principales de l’échec du projet.

• Par exemple :
¤ Les utilisateurs changent leurs exigences
¤ L’équipe de développement modifie
l’architecture du logiciel
Changement des exigences

• Au départ, les utilisateurs ne savent pas

quelles sont leurs exigences et comment
les spécifier de façon précise.
• Ils changent leurs exigences quand ils
voient les livrables

Effet: IKIWISI
I Know It When I See It - Je le saurai quand je l ’aurai vu
Bary Boehm - Université de Californie du Sud
Changements de l’architecture

• Les membres de l’équipe :

¤ n’ont peut-être pas bien compris le système
exigé
¤ n’ont peut-être pas partagé une même
compréhension du système
RUP est centré sur l’architecture
Programmeurs
Utilisateur final Gestion du logiciel
Fonctionnalité

Vue logique Analystes/Testeurs Vue

Vue pratique Comportement d'implémentation

Vue des cas

d'utilisation
Vue des processus
Vue déploiement

Intégrateurs Ingénieurs Système

système Topologie du système
Performance Livraison, installation
Capacité à grandir Communication
Débit d'information
Briques d’organisation

Management

Processus Modèle visuel Qualité Composants

itératif logiciels

Contrôle des changements

 RUP : tracer les changements

• RUP définit un enchaînement d’activités de

soutien : gestion des configurations et des
changements
• RUP est piloté par les cas d ’utilisation
 RUP est piloté par les cas
d’utilisation

Réalisé par Vérifié par

Implémenté par

Modèle de conception Modèle d’implémentation Modèle de test

Avantages

• RUP améliore la qualité du produit

• RUP augmente le taux de succès du projet
• RUP est supporté par les outils du Rational
Software
 RUP améliore la qualité du produit

• RUP améliore la compréhension du système

¤ RUP est itératif
¤ RUP reste centré sur l’architecture
¤ RUP utilise UML pour modéliser le logiciel
RUP améliore la qualité du produit

• RUP contrôle et trace le processus de

transformation de la compréhension du
système en produit
¤ RUP est piloté par les cas d’utilisation
¤ RUP contrôle l’avancement de travail à l ’aide des
livrables fournis dans les jalons
RUP augmente le taux de succès
du projet

RUP permet d’anticiper et de limiter les

risques. On peut mieux les traiter quand ils
sont petits...
RUP est intégré par les outils du Rational
Software
Apex Purify
Visual Studio
Quantify
PureCoverage

Rose

TeamTest

RequisitePro
ClearQuest

SoDA ClearCase
Interface
Présentation des rôles
Présentation des scénarios
Diagramme de la collaboration
Présentation des classes (UML)
Diagramme des états de transition
Diagramme des composants
Points faibles de RUP

• RUP ne supporte pas les multi-projets

• RUP exige des experts
• RUP est propriété de Rational Software
RUP est un cadre de processus

• RUP décrit qui, quoi, comment et quand faire à

l’aide d’un langage visuel
• RUP apporte des outils et une méthode
d’organisation pour l’ingénierie participative
• RUP apporte une vision unifiée sur le processus
qui peut être partagée par tous les acteurs