modélisation et réalisation d’un processus d’ingénierie...
TRANSCRIPT
Modélisation et réalisation d’un processus d’ingénierie du logiciel
Adaptation et simplification du RUP
RAPPORT DE STAGE DE TROISIEME ANNEE
AVRIL-SEPTEMBRE 2001
www.aubryconseil.com
Etudiant :
Responsable entreprise :
Responsable IUP ISI :
Olivier DENIZON
Claude AUBRY
Henri MASSIE
aubryConseil – Stage Olivier Denizon
2
Remerciements
Je tiens à remercier Claude AUBRY pour m’avoir accordé sa confiance pour ce stage ambitieux.
Je veux également le remercier pour ses qualités de maître de stage et de gestionnaire de projet, ses
prises de décisions objectives lors des points d’avancement et constat de retard. Je le remercie aussi
pour ses qualités humaines, sa sympathie, et pour s’être montré conciliant.
Je tiens à remercier les professeurs qui se sont impliqués dans ce projet, Messieurs Henri MASSIE et
Bernard CHERBONNEAU pour avoir suivi ce projet, avoir fait l’effort de relecture des documents
produits et de participation a des réunions d’avancement.
... et sûrement pour l’effort sans doute conséquent qu’il leur faudra faire pour adapter leur
enseignement à ce nouveau processus de développement.
Je remercie Monsieur André ARICH de la société Rational de sa collaboration à ce projet, de s’être
déplacé à Toulouse pour des réunions de présentation et d’avancement du projet, et de nous avoir
gracieusement fourni une première version de l’outil RPW.
Je tiens également à remercier mes interlocuteurs du support technique de Rational, en particulier
Peter et Sara, pour leur aide concernant l’utilisation correcte de l’outil RPW.
Je remercie aussi Madame Wahiba BAHSOUN qui a bien voulu “tolérer” ma présence dans son
bureau.
aubryConseil – Stage Olivier Denizon
3
Contenu du document
Le document consiste en 8 chapitres :
• Le premier chapitre introduit le stage et le projet réalisé,
• Le deuxième chapitre présente la cadre du projet, la société d’accueil et l’organisation du
projet,
• Le troisième chapitre présente la modélisation des processus d’ingénierie du logiciel et le
méta-modèle SPEM,
• Le chapitre suivant présente les principes et éléments du processus réalisé, repris et adaptés
du Rational Unified Process (ou RUP) ,
• Le chapitre 5 présente le Rational Process Workbench (RPW) : outil de Rational permettant
la modélisation et la génération d’un site web de processus implémenté à partir d’un modèle
de processus,
• Le chapitre 6 détaille le travail effectué pour définir et produire le RUPS (RUP simplifié) qui
est le processus produit au cours du stage,
• Le chapitre 7 montre l’exemple réalisé pour illustrer le processus : EasyStage
• Le dernier chapitre fait le bilan du projet et du stage.
Des annexes apportent des compléments à la compréhension du domaine, du travail réalisé : le
glossaire, la bibliographie, …
Chaque chapitre se termine par un paragraphe personnel sur ma participation aux aspects présentés,
que ce soit pour montrer les difficultés d’apprentissage ou de réalisation ou pour présenter les produits
réalisés.
aubryConseil – Stage Olivier Denizon
4
Table des matières 1 Le sujet du stage ..................................................................................................................6
1.1 Objectif .......................................................................................................................... 6
1.2 Portée du projet............................................................................................................... 6
1.3 Cible du processus........................................................................................................... 7
1.4 Motivation personnelle pour le sujet ................................................................................. 7
2 Environnement du projet.....................................................................................................8
2.1 Présentation de la société ................................................................................................. 8
2.2 Organisation du projet ..................................................................................................... 8
2.3 Processus du projet.......................................................................................................... 9
2.4 Mon rôle dans le projet .................................................................................................. 10
3 Modélisation de processsus ................................................................................................11
3.1 Méthode et processus..................................................................................................... 11
3.2 Processus et Processus générique.................................................................................... 11
3.3 Intérêt d’un modèle ....................................................................................................... 11
3.4 Standard de modélisation ............................................................................................... 12
3.4.1 Modéliser avec UML.............................................................................................. 12
3.4.2 SPEM l’espoir d’un standard................................................................................... 12
3.4.3 Le meta-modèle SPEM........................................................................................... 13
3.5 Modelisation pour le projet ............................................................................................ 13
3.6 Mon rôle dans la modélisation........................................................................................ 14
4 Principes et éléments du processus .....................................................................................16
4.1 Bonnes pratiques d’ingénierie ........................................................................................ 16
4.2 Principes....................................................................................................................... 16
4.2.1 Adaptation au développement et à la maintenance .................................................... 16
4.2.2 Un processus a deux dimensions .............................................................................. 17
4.2.3 Cycle itératif et incrémental..................................................................................... 17
4.2.4 Phases.................................................................................................................... 18
4.3 Eléments du processus ................................................................................................... 20
4.3.1 Rôle....................................................................................................................... 21
4.3.2 Activité .................................................................................................................. 21
4.3.3 Etapes.................................................................................................................... 22
4.3.4 Guides de travail..................................................................................................... 22
4.3.5 Produits de travail................................................................................................... 23
4.3.6 Plan type ................................................................................................................ 25
4.3.7 Rapport.................................................................................................................. 25
4.3.8 Guides de produit et points de contrôle ..................................................................... 25
aubryConseil – Stage Olivier Denizon
5
4.3.9 Workflow............................................................................................................... 26
4.3.10 Discipline............................................................................................................... 27
4.3.11 Groupe d'activités ................................................................................................... 28
4.3.12 Guides outils .......................................................................................................... 29
4.3.13 Concepts................................................................................................................ 29
4.4 Travail personnel sur les principes et éléments ................................................................ 29
5 Rational Process Workbench (RPW) .................................................................................31
5.1 Pourquoi le RPW ?........................................................................................................ 31
5.2 Présentation du RPW..................................................................................................... 31
5.3 Composition du RPW.................................................................................................... 31
5.3.1 Le modèle de processus .......................................................................................... 31
5.3.2 Le modèle de composants ....................................................................................... 32
5.3.3 La "Process Content Library".................................................................................. 32
5.4 Travail personnel sur l’outil ........................................................................................... 33
6 Définition et réalisation du RUPS ......................................................................................35
6.1 Gestion de projet ........................................................................................................... 35
6.2 Environnement.............................................................................................................. 35
6.3 Définition du processus.................................................................................................. 35
6.4 Réalisation du processus ................................................................................................ 36
6.4.1 Modèle .................................................................................................................. 36
6.4.2 Librairies ............................................................................................................... 38
6.4.3 Génération du site ................................................................................................... 40
6.5 Le déploiement du processus.......................................................................................... 41
6.6 Quelques chiffres .......................................................................................................... 41
6.7 Travail personnel sur le RUPS........................................................................................ 42
7 Un exemple d’illustration du processus ..............................................................................43
7.1 Objectif ........................................................................................................................ 43
7.2 Contenu ........................................................................................................................ 43
7.3 Travail personnel sur l’exemple ...................................................................................... 43
8 Bilans .................................................................................................................................45
8.1 Le projet....................................................................................................................... 45
8.2 Le produit ..................................................................................................................... 45
8.3 Le stage ........................................................................................................................ 45
9 Annexes..............................................................................................................................46
9.1 Bibliographie ................................................................................................................ 46
9.2 Glossaire....................................................................................................................... 46
aubryConseil – Stage Olivier Denizon
6
1 LE SUJET DU STAGE
Le stage a consisté en une participation à un projet sur les processus d’ingénierie du logiciel. Un
processus est un ensemble d'étapes partiellement ordonnées dont l'exécution vise à produire un
logiciel.
1.1 OBJECTIF
Le projet a pour objectif de définir un nouveau processus pour une organisation qui développe des
logiciels. Le processus est réalisé par adaptation d’un processus générique, le RUP (Rational Unified
Process). Plus précisément on cherche à obtenir un processus :
• conforme aux standards dans le domaine,
• qui se présente sous forme de site Web,
• simplifié et en français,
• adapté à l’organisation cible,
• que l’on puisse faire évoluer facilement,
• avec un exemple en français permettant d'illustrer son utilisation sur un projet.
1.2 PORTEE DU PROJET
Le début du stage coïncide avec le début du projet. La fin du stage correspond à la production d’une
version du processus. Cela constitue la première étape du déploiement d’un processus dans une
organisation.
En effet, pour « implémenter un nouveau processus », il faut d’abord évaluer le processus actuel,
définir les évolutions, planifier leur réalisation, réaliser le nouveau processus, mais aussi former
l’organisation à son utilisation, essayer le processus sur un ou plusieurs projets pilote, faire une
évaluation de cette utilisation, et puis refaire un ou plusieurs de ces cycles.
Figure 1 L'implémentation d'un processus Le projet ne prétend pas "implémenter" complè tement un processus, et ne prend pas compte ni la
Evaluation du processus actuel
NouveauProcessus
Planifier l’implémentation du processus- au niveau “organisation”
Procéder à l’implémentation- Configurer le processus- Générer le processus (RPW)
- Former les équipesEvaluer l’implémentation du processus
aubryConseil – Stage Olivier Denizon
7
formation, ni l’exécution du processus. Ces activités se dérouleront dans une seconde phase du projet.
Pour cette première partie, on se consacre essentiellement à la maîtrise des risques majeurs liés à la
modélisation et la réalisation d’un processus.
1.3 CIBLE DU PROCESSUS
L'organisation qui va utiliser le nouveau processus est celle mise en place pour les projets de bureaux
d'études des étudiants de 2ème et 3ème année de l'IUP ISI.
L'IUP ISI est un Institut Universitaire Professionnalisé, spécialisé dans le génie logiciel et l'ingénierie
des systèmes informatiques. Les étudiants sont sensibilisés aux processus de développement et
mettent en œuvre les techniques enseignées sur des projets de 6 mois.
Cette organisation mise en place depuis plus de 5 ans place les étudiants dans un contexte industriel.
Le processus utilisé pour le développement des projets évolue d'année en année. Les projets achevés
en 2001 utilisaient en partie un processus itératif et guidé par les cas d'utilisation. Tous les projets
réalisés, et particulièrement les 8 projets de 2001, sont utilisés pour évaluer le processus actuel, et à
définir le nouveau processus.
Le RUP, dont l'IUP a fait l'acquisition en septembre 2000, a été présenté aux étudiants et il est
partiellement utilisé. Cependant le RUP tel quel est trop complexe dans ce contexte. C’est pourquoi le
processus produit sera un RUP simplifié, appelé RUPS. Il sera adapté à l’organisation des bureaux
d’études.
L’utilisation du RUPS sur les projets commencera en octobre 2001.
1.4 MOTIVATION PERSONNELLE POUR LE SUJET
J’ai choisi ce stage car il s’inscrit dans mon projet professionnel. Au sein de la formation en IUP ISI,
je me suis particulièrement épanoui dans la discipline du génie logiciel et j’accorde une grande
importance aux aspects qualité et gestion de projet lors d’un travail.
Ce stage porte sur un sujet qui m’est familier : le génie logiciel et les bureaux d’études ISI mais il fait
aussi appel à des aspects nouveaux ou que j’ai envie d’approfondir : l’utilisation du RUP, la
modélisation UML, l’utilisation de Rational Rose, les processus de développement logiciel.
aubryConseil – Stage Olivier Denizon
8
2 ENVIRONNEMENT DU PROJET
Le projet est réalisé par AubryConseil, en partenariat avec l’IUP ISI, et avec la participation de
Rational.
2.1 PRESENTATION DE LA SOCIETE
AubryConseil est un cabinet de conseil créé par Claude Aubry, spécialisé dans les techniques
d'ingénierie du logiciel et d'ingénierie système.
Depuis 8 ans, AubryConseil assiste les entreprises dans l’application des meilleures pratiques
disponibles, dans les disciplines suivantes :
• l’ingénierie métier,
• l'expression des besoins et exigences,
• l'analyse et la conception,
• la gestion de projet logiciel.
Les prestations réalisées consistent le plus souvent en du transfert de technologie, auprès des équipes
de développement, des nouvelles approches :
• les technologies objet,
• les cas d'utilisation et l’ingénierie des exigences,
• le développement itératif,
• les architectures à base de composants,
• les langages de modélisation visuelle (UML en général, SDL pour le temps réel),
• les outils de modélisation, simulation et génération de code associés.
La participation à de nombreux projets a permis de développer une compétence particulière dans les
processus. Ces dernières années, les processus modernes liés à UML, et particulièrement le processus
unifié (et le RUP) ont été mis en œuvre chez des clients. Cela permet de proposer aux entreprises des
services complets autour de composants d’un processus. Les services couvrent actuellement les
premières phases (lancement, élaboration) et des disciplines dites en amont du développement, c’est à
dire les parties de processus les plus concernées par la modélisation.
L’offre comporte également des formations et notamment des formations UML avec de nombreuses
formules, adaptées au rôle de chacun dans un projet.
Les clients sont des grandes entreprises : Aerospatiale, CNES, Bouygues Telecom, des éditeurs :
Rational, Telelogic et plus récemment des structures plus légères désireuses de passer à UML et de
mettre en place un processus.
2.2 ORGANISATION DU PROJET
Claude Aubry (AubryConseil) est le Responsable du Projet, et le tuteur du stage. L’équipe projet est
donc constituée de 2 personnes, avec la collaboration épisodique des enseignants de l’IUP ISI.
La connaissance de l’organisation cible est assurée : Claude Aubry participe lui-même aux
aubryConseil – Stage Olivier Denizon
9
enseignements et aux projets de Bureaux d’Etudes de l’IUP ISI. Des étudiants ayant participé aux
projets 2001 ont également été sollicités, notamment pour l’évaluation du processus actuel.
Pour faciliter la communication des travaux effectués dans l’équipe et à l’extérieur, un site projet a été
réalisé, à partir d’un exemple fourni dans le RUP. Ce site a été régulièrement alimenté avec tous les
documents de définition du projet, les documents de gestion du projet, les documents de réalisation et
de déploiement du processus, les présentations des travaux effectués, les références bibliographiques.
Figure 2 Site d’avancement du projet, accessible sur le web
2.3 PROCESSUS DU PROJET
Dans la mesure où cela s’appliquait, un processus très simplifié reprenant les principes du RUP a été
utilisé pour la fabrication du processus :
• gestion des risques
• définition des produits, des rôles et des activités,
• gestion de projet avec des points d’avancement réguliers et prise d’importantes décisions de
changements (disciplines non traitées, stratégie d’utilisation du RPW, de traduction des pages
web…)
• cycle itératif, avec une évaluation et une actualisation constante des produits de travail au
cours de revues, de réunions…
Le plan de développement initial comportait 5 itérations, chacune d’un mois avec les objectifs
suivants :
Itération 1
aubryConseil – Stage Olivier Denizon
10
o évaluation du processus actuel
o buts du nouveau processus
o liste des risques
o projet Web du RUPS en place
Itération 2
o utilisation réussie du RPW
o un RUPS implémenté avec la discipline d’Expression des exigences
o un exemple présenté comme projet Web pour Exigences
Itération 3
o un RUPS implémenté avec les disciplines Analyse et Conception et Gestion de projet
o un exemple présenté comme projet Web pour Analyse et Conception et Gestion de
projet
Itération 4
o un RUPS implémenté avec les disciplines Implémentation et Test
o un exemple présenté comme projet Web pour Implémentation et Test
Itération 5
o un RUPS implémenté avec les disciplines Déploiement et Environnement
o un exemple présenté comme projet Web pour Déploiement et Environnement
2.4 MON ROLE DANS LE PROJET
J’interviens principalement sur ce projet en tant qu’analyste et développeur : c’est moi qui ai la
responsabilité d’étudier et produire le nouveau processus de développement logiciel.
Pour cela, j’ai à :
o rendre compte de l’avancement de ce projet au travers du site projet (à mettre en
place)
o me familiariser avec les notions liées aux processus de développement logiciel
o étudier le processus existant
o modéliser le nouveau processus, déterminer quels éléments du RUP reprendre ou non
o apprendre à me servir des outils existants pour la modélisation et l’implémentation de
processus
o élaborer un site exemple mettant en application (à un projet de gestion des stages) les
principes évoqués dans le processus réalisé
o mettre en place le produit sur le site cible (local ou hébergeur web)
Pour ces raisons, j’interviens également comme quelqu’un qui connaît le processus actuel pour avoir
assumé différents rôles au cours de projets de bureaux d’études ISI : développeur, analyste,
responsable qualité…
aubryConseil – Stage Olivier Denizon
11
3 MODELISATION DE PROCESSSUS
3.1 METHODE ET PROCESSUS
Avant de parler de modélisation, notons que le terme processus est relativement nouveau dans le
domaine du logiciel : il y a quelques années on parlait de méthode. SADT, SA/RT, Hood et OMT se
présentaient comme des méthodes, parfois restreintes à l’analyse ou la conception.
Si on revient aux débuts d’UML, on se rappelle d’ailleurs que les premiers travaux en 1995 portaient
sur UM, la méthode unifiée, et que ce n’est qu’au bout de quelques mois que la décision de se
consacrer uniquement au langage de modélisation et d’abandonner le côté méthode a été prise. Cette
décision est à l’origine du succès d’UML et de sa diffusion rapide.
La raison évoquée pour séparer langage et méthode vaut toujours : il n’est pas possible, il n’est pas
question d’avoir une méthode unique utilisable sur tous les projets dans tous les domaines. C’est
comme pour la mondialisation : on peut faciliter les échanges, mais chacun doit conserver sa culture
et son savoir-faire. Un processus intellectuel comme celui des développements de logiciel est un bien
culturel d’une organisation.
Donc pas de méthode universelle, et même pas de méthode unique liée à la technologie objet et au
langage UML.
Les processus dits modernes sont apparus après la standardisation d’UML qui a débarrassé la
communauté du génie logiciel des problèmes de langage.
Le processus unifié et le RUP, Fusion, OPEN, à un degré moindre Catalysis, plus récemment et
différemment XP et les processus « agiles » se présentent comme des processus pour l’ingénierie du
logiciel.
La notion de processus est plus large que celle de méthode, elle se rapproche plutôt de méthodologie,
c’est-à-dire d’un tout couvrant l’ensemble des activités d’un projet logiciel. Les processus modernes
englobent par exemple la gestion de projet, et ne se cantonnent pas au développement.
3.2 PROCESSUS ET PROCESSUS GENERIQUE
Puisqu’il n’y a pas de méthode unifiée, pourquoi y aurait-il un processus unifié ?
Les processus évoqués plus haut ne sont pas applicables directement : ils définissent des principes et
une architecture, mais doivent être adaptés à l’organisation et au projet visés. Ce sont des processus
génériques.
C’est le cas du RUP, qui est d’ailleurs présenté comme un "framework". Nous utiliserons le terme
processus générique plutôt que processus unifié.
Le processus que nous avons développé, le RUPS, a été créé à partir du processus générique RUP.
3.3 INTERET D’UN MODELE
On ne débat pas ici de savoir s’il faut un processus pour développer du logiciel. Ni même de savoir si
le processus doit être lourd ou léger : c’est le travail nécessaire pour l’adaptation qui doit le dire,
aubryConseil – Stage Olivier Denizon
12
notamment l’évaluation de l’organisation actuelle.
Les arguments pour modéliser un processus sont les mêmes que ceux utilisés pour modéliser un
logiciel.
Il y a des inconvénients :
• Modéliser, c’est toujours difficile. Modéliser un processus, ça l’est encore plus : on s’attaque
à des activités humaines.
• Modéliser prend du temps et le cycle de validation est très long : il faut essayer le processus
sur un projet.
Le premier bénéfice est que le fait de réfléchir à un modèle permet de se poser des questions bien plus
précises. Les autres bénéfices viennent des facilités apportées pour la communication et la mise à jour
du processus, et sa génération automatique à partir du modèle. Ces bénéfices sont liés à l’existence
d’un langage standard pour décrire les processus et d’outils pour automatiser sa fabrication.
3.4 STANDARD DE MODELISATION
3.4.1 MODELISER AVEC UML
La communauté du logiciel a très vite adopté UML comme standard de modélisation pour le logiciel.
Il est tentant d’utiliser UML pour modéliser les processus d’ingénierie du logiciel. Le langage est
riche et permet d’être étendu facilement aux besoins d’un domaine avec les stéréotypes.
Cependant UML n’a pas été conçu pour cela. Il peut donc y avoir une grande diversité dans les
éléments de modélisation UML employés, et les stéréotypes mis en œuvre. Bref il y a un besoin d’une
certaine forme de standardisation sur l’adaptation d’UML à la modélisation des processus.
3.4.2 SPEM L’ESPOIR D’UN STANDARD
L’OMG (Object Management Group), à l’origine d’UML, a fait une RFP (Request For Proposal) sur
le « Software Process Engineering Management » en novembre 1999. Le résultat est le SPEM
(Software Process Engineering Metamodel). Nous faisons référence ici à la version ad 2001-03-08
diffusée le 2 avril 2001.
Les travaux de l’OMG ont été réalisés avec la collaboration des sociétés spécialistes des processus de
génie logiciel tels qu’IBM, Fujitsu, Unisys, Alcatel et bien entendu Rational. Ce qui explique que le
RUP soit déjà largement conforme au SPEM.
Le résultat des travaux est un méta-modèle pour la description des processus. Il présente l’utilisation
d’UML avec une approche orientée objet pour décrire des processus de logiciel. Cette utilisation
d’UML correspond à la notion de profil, qui sera un des axes d’évolution de la version 2.0.
L’objectif du SPEM est de définir un langage commun pour décrire des processus, mais aussi de
faciliter la communication entre les différents outils de fabrication de processus.
Le SPEM permet d’unifier le vocabulaire utilisé pour décrire les processus. Entre deux processus,
bien souvent le même terme est utilisé et compris de façon différente. Par exemple : activité, phase,
itération.
aubryConseil – Stage Olivier Denizon
13
Le glossaire fourni en annexe traduit et enrichit les définitions du SPEM.
3.4.3 LE META-MODELE SPEM
L’idée centrale du SPEM est qu’un processus est la collaboration entre des entités actives et abstraites
appelées Rôles qui réalisent des opérations appelées Activités sur des entités concrètes et tangibles
appelées Produits de travail.
La figure 3 ci-dessous montre ce concept fondamental avec la notation UML de la classe.
Role
activity1(WorkProduct1) activity2(WorkProduct2)
Figure 3 Description d’un rôle dans le SPEM au moyen de classe UML
A partir de ce modèle, on peut "réifier" activité et produit, pour aboutir au simple modèle (incomplet)
de la figure ci-dessous, base du méta-modèle.
Role
Activity 0..*
1
0..*
1
Performs
WorkProduct 0..* 1 0..* 1 IsResponsibleFor
0..*
0..*
0..*
input 0..*
Uses
0..*
0..*
0..*
output 0..*
Produces
Figure 4 Diagramme UML montrant les interactions existant entre rôles, activités et produits
Plusieurs rôles peuvent collaborer par l’échange de produits et le déclenchement de l’exécution de
certaines activités. Le but global de l’exécution d’un processus est de fournir un ensemble de produits
de travail dans un état bien défini.
Nous n’irons pas plus loin dans la description du méta-modèle. La plupart des concepts sont repris
dans la présentation du RUPS.
3.5 MODELISATION POUR LE PROJET
Notre objectif est de réaliser un processus à partir du RUP générique, et conforme aux standards. Le
SPEM est supporté par le Rational Process Workbench (RPW), qui est un outil de fabrication de
processus basé sur UML.
aubryConseil – Stage Olivier Denizon
14
Figure 5 Les niveaux de modèles Nous avons décidé d’utiliser le RPW qui fournit le modèle du RUP, conforme au SPEM. Une partie
du travail nécessaire pour produire le RUPS peut ainsi se faire au niveau du modèle. Notre travail de
modélisation a consisté à définir notre processus en supprimant, en réutilisant, ou en spécialisant des
parties du modèle du RUP. Notons que le RUPS est lui-même un modèle de processus pouvant être
« instancié » sur des projets.
3.6 MON ROLE DANS LA MODELISATION
Je me suis penché sur la modélisation de processus en étudiant d’abord les travaux de l’OMG sur la
méta-modélisation, qui m’ont permis de mieux comprendre les relations entre les divers éléments
constituant un processus (desquels nous avons tiré un glossaire en français, fourni en annexe, des
termes utilisés pour la modélisation de processus).
Pour en revenir à la modélisation, j’ai eu à modéliser notre processus au travers de l’outil RPW au
moyen de nombreux diagrammes UML : diagrammes de classes, diagrammes d’activités, diagrammes
de composants… organisés en paquetages.
Pour cela, j’ai utilisé les nombreux stéréotypes permettant de définir les différents éléments
constituant un processus : rôle, activité, modèles, documents...
La figure 6 ci dessous montre un des nombreux diagrammes UML réalisés. Il s’agit d’un diagramme
de classe, avec des associations entre rôles et documents et des généralisations entre les rôles.
SPEM RUP
RUPS
M é t a -m o d è l e
d e p r o c e s s u s
M o d è l e
d e p r o c e s s u s
R U P S
m i s e n o e u v r e
c o n f o r m e à
a d a p t é d e
g u i d é p a r
E x é c u t i o n
d e p r o c e s s u s
aubryConseil – Stage Olivier Denizon
15
Figure 6 Les rôles participant à une discipline
aubryConseil – Stage Olivier Denizon
16
4 PRINCIPES ET ELEMENTS DU PROCESSUS
Le RUPS est adapté du RUP. Il s’appuie sur les mêmes pratiques d’ingénierie, reprend la plupart de
ses principes et est composé des mêmes types d’éléments.
4.1 BONNES PRATIQUES D’INGENIERIE
Le RUP repose sur 6 « piliers » :
• développement itératif,
• gestion des exigences,
• modélisation visuelle,
• architecture basée sur des composants,
• vérification continuelle de la qualité,
• gestion des modifications et de la configuration.
4.2 PRINCIPES
4.2.1 ADAPTATION AU DEVELOPPEMENT ET A LA MAINTENANCE
Un processus est un ensemble d'étapes partiellement ordonnées dont l'exécution vise à atteindre un
objectif ; dans le domaine de l'ingénierie du logiciel cet objectif est la réalisation d'un produit logiciel
ou sa maintenance.
Exprimé en terme de modélisation, un processus d'ingénierie du logiciel est un processus métier dont
l'objectif est d'améliorer l'organisation qui développe des logiciels; le Rational Unified Process (RUP)
est un processus métier générique pour le développement logiciel orienté objet.
Le processus a pour but d'assurer la production d'un logiciel de qualité qui réponde aux besoins des
utilisateurs finaux, dans le respect des coûts et des délais; pour cela il repose sur des principes :
• il fournit une approche "disciplinée" de l’affectation des tâches et responsabilités à l'intérieur
de l'organisation de développement.
• il inclut ce qu'on appelle la maintenance. Lorsqu'un système logiciel est développé de bout en
bout, le développement est le processus de création d'un système à partir des exigences. Mais
une fois que le système a pris forme ( dès qu'il a dépassé le cycle de développement initial),
tout développement ultérieur est un processus de conformité du système à de nouvelles
exigences ou des exigences qui ont été modifiées. Ceci s'applique tout au long du cycle de vie
du système.
Figure 7 Objectif d’un processus
aubryConseil – Stage Olivier Denizon
17
4.2.2 UN PROCESSUS A DEUX DIMENSIONS
Figure 8 La présentation schématique du processus selon deux axes, dite graphe à bosses
Ce processus se décline sur deux axes :
• l’axe horizontal représentant la séquence de travail dans le temps : le cycle de vie du processus, et
l'exprime en termes de phases, itérations, et jalons
• l’axe vertical représentant l’organisation du travail en termes de composants de processus
(disciplines, workflows, groupes d’activités, produits de travail, activités, rôles…)
Cette distinction est fondamentale : elle permet de mettre réellement en place des itérations.
4.2.3 CYCLE ITERATIF ET INCREMENTAL
Le principal problème de cycle "en V" est qu’on repousse la gestion des risques très tard dans le
développement, de telle sorte que leur occurrence est très coûteuse parce qu’il s’agit de réparer des
erreurs des phases précédentes. Ceci conduit à des retards, des surcoûts, voire l’annulation du projet.
L’alternative est le cycle itératif et incrémental. Inspiré du modèle en spirale de Barry BOEHM, il est
basé sur l’identification des risques sur le projet très tôt dans le cycle de vie, lorsqu’il est encore
possible de les contenir, les atténuer, les contourner. Une autre caractéristique de ce cycle est
l’élaboration de produits tangibles (itérativement jusqu’à leur complétude) lors de chaque phase :
documents, prototypes, modèles, code, exécutables...
Cela permet de régler certains problèmes actuels du développement logiciel :
• Pas d’effet tunnel : on ne s’aperçoit plus trop tard que l’on n’était pas d’accord sur un point car les
éléments sont produits très tôt et vérifiés en fin d’itération ou de phase en non en fin de projet.
• Meilleure communication entre les développeurs et les utilisateurs finaux du logiciel au travers de
la discipline d’Expression des exigences.
• L’équipe de développement ne se concentre à un moment donné que sur les risques les plus
critiques.
aubryConseil – Stage Olivier Denizon
18
• Le test continuel des produits élaborés permet d’évaluer objectivement l’avancement du projet.
(ce qui d’ailleurs diminue la charge du test en fin de projet puisque le test est réparti sur toute la
longueur du projet)
• Les incohérences entre les exigences, la conception et l’implémentation sont détectées très tôt.
• L’équipe de développement améliore continuellement le processus au travers de son expérience et
des leçons tirées de ses projets passés.
• Les intervenants sur le projet sont mieux pris en considération.
• La souplesse de ce cycle de développement permet de gérer plus facilement et à tout moment les
demandes de modification ou l’occurrence des risques.
• Pas de « big bang » final ; l’effort de développement est relativement constant tout au long du
développement ; les éléments produits sont intégrés au fur et à mesure.
• Facilité de réutilisation par l’approche de décomposition en composants.
4.2.4 PHASES
Les itérations s’exécutent dans le cadre de phases. Toutes les phases ne sont pas identiques en termes
de durée ou d'effort.
Le cycle de vie est composé de 4 phases : lancement (« inception »), élaboration, construction et
transition. Selon une perspective de gestion de projet, chacune de ces 4 phases séquentielles est
conclue par un jalon important.
Figure 9 L’enchaînement des phases et des jalons
4.2.4.1 PHASE DE LANCEMENT
Le Lancement est la phase au cours de laquelle on décide de l’opportunité de réaliser ou non le projet.
Les objectifs principaux de la phase de Lancement sont de :
• définir une vision partagée du projet, avec ce que contient ou non le produit, et les critères
d'acceptation.
• déterminer les cas d'utilisation critiques du système, les scénarios donnant lieu aux principaux
points d'interrogation sur la conception.
• montrer, voire démontrer, au moins une architecture qui se plie à ces différents scénarios.
• estimer globalement les coûts et les délais du projet (plus de détails à venir en phase d'élaboration)
• estimer les risques potentiels (les sources de l'imprévisibilité).
aubryConseil – Stage Olivier Denizon
19
• préparer l'environnement de développement du projet
4.2.4.2 PHASE D’ELABORATION
L’élaboration est la phase au cours de laquelle on vise à obtenir une architecture stable du système
pour avoir une base solide lors de l'effort de conception et d'implémentation en phase de Construction.
L'architecture dépend :
• des exigences qui ont le plus d'impact sur l'architecture du système,
• de l'évaluation des risques.
La stabilité de l'architecture est démontrée au moyen d'un ou plusieurs prototypes d'architecture.
Les objectifs principaux de la phase d'élaboration sont de :
• s'assurer que l'architecture (à partir de scénarios significatifs), les exigences et les plans sont assez
stables, que les risques significatifs du point de vue de l'architecture sont suffisamment atténués
pour qu'on puisse élaborer des prévisions fiables pour les coûts et la durée du développement
restant.
• produire un prototype évolutif avec des composants de qualité, de même qu'un ou plusieurs
prototypes "exploratoires" jetables pour atténuer les risques (changements de conception,
d'exigences, réutilisation de composants, faisabilité du produit) ou faire des démonstrations à des
investisseurs, des clients ou de futurs utilisateurs
• démontrer que l'architecture supportera les exigences du système (dans des coûts et des délais
raisonnables).
• définir et mettre en place l'environnement de développement (rédaction d'un plan de cycle de vie
du projet, de plans types, de guides, et pré-configurer les outils).
4.2.4.3 PHASE DE CONSTRUCTION
La construction est la phase au cours de laquelle on réalise le système à partir de l'architecture
stabilisée. La phase de construction est en un sens l’étape de production, où l'accent est mis sur la
gestion des ressources et le contrôle des opérations pour optimiser les coûts, les délais et la qualité.
Les objectifs principaux de la phase de construction sont de:
• minimiser des coûts de développement par l'optimisation des ressources. Il est essentiel de
disposer d'une architecture robuste si l'on veut atteindre un haut degré de parallélisme de ces
ressources.
• atteindre la qualité adéquate rapidement.
• produire des versions utilisables (alpha, bêta, et autres versions de test) aussi vite que possible.
• compléter l'analyse, la conception, le développement et le test de toutes les fonctionnalités.
• développer itérativement et de façon incrémentale un produit complet prêt à la transition vers la
communauté des utilisateurs (cela implique la description des cas d'utilisation restants, d'étoffer la
conception, de compléter l'implémentation, et tester le logiciel).
aubryConseil – Stage Olivier Denizon
20
• décider si le logiciel, les sites et les utilisateurs sont prêts au déploiement de l'application.
4.2.4.4 PHASE DE TRANSITION
Lors de la phase de transition on s'assure que le logiciel est disponible pour les utilisateurs finaux.
La phase de transition peut s'étaler sur plusieurs itérations, inclure le test du produit avant sa sortie et
les ajustements mineurs basés sur les remarques faites par les utilisateurs (pour de petites
améliorations de la configuration, l'installation et les problèmes d'utilisation).
A la fin de la phase de transition, les objectifs doivent avoir été atteints et le projet doit être sur le
point d'être clos.
Les objectifs principaux de la phase de Transition sont :
• l'accord des intervenants sur le fait que le déploiement de la version de référence est terminé et
conforme aux critères d'acceptation du produit.
• le bêta test pour valider le nouveau système en fonction des attentes des utilisateurs.
• l'installation des bases de données opérationnelles.
• la formation des utilisateurs et responsables de la maintenance.
• la correction des bugs, l'amélioration des performances et de l'utilisabilité.
Il est aussi important d'atteindre l'autonomie de l'utilisateur sur le logiciel.
4.3 ELEMENTS DU PROCESSUS
Figure 10 Eléments du Rational Unified Process™ repris pour le RUPS
aubryConseil – Stage Olivier Denizon
21
Nous présentons les éléments du processus illustrés avec des extraits du site Web résultat. Nous
faisons également référence à des pages qui sont sur ce site.
4.3.1 ROLE
L’élément central du processus est le concept de rôle. Un rôle définit le comportement et les
responsabilités d'un individu ou d'un ensemble d'individus qui travaillent en équipe, dans le contexte
de l'organisation d'ingénierie du logiciel. La page Rôles et activités du site fournit des informations
supplémentaires sur les rôles.
Figure 11 Les rôles dans l'arborescence de navigation Les rôles ne sont PAS obligatoire ment individuels; ils décrivent comment les individus doivent se
comporter dans le domaine métier et leurs responsabilités. Les membres d'une organisation de
développement peuvent avoir à endosser plusieurs rôles. L'attribution des rôles revient au chef de
projet lors de l'organisation du projet et la planification (voir Activité : Accueillir de nouvelles
personnes), et permet à différentes personnes de jouer plusieurs rôles distincts, et peut également faire
en sorte qu'un rôle soit joué par plusieurs personnes à la fois.
4.3.2 ACTIVITE
Les Rôles réalisent des activités. Une activité est une unité de travail fournie par un rôle dans le
contexte du projet. Voir l'Activité : Capturer le vocabulaire commun pour un exemple d'activité.
Figure 12 Chaque rôle est suivi de ses activités dans l'arborescence de navigation Une activité a un objectif clair, en général exprimé en termes de création ou de mise à jour de
produits de travail, tels qu'un modèle, une classe, un plan. Chaque activité est placée sous la
aubryConseil – Stage Olivier Denizon
22
responsabilité unique d'un rôle. La granularité d'une activité varie en général de quelques heures à
quelques jours. Une activité est une unité élémentaire du planning.
Les activités peuvent être répétées à plusieurs reprises (par le même rôle mais pas nécessairement le
même individu) sur un même produit de travail, en particulier une activité est fréquemment exécutée à
chaque itération.
4.3.3 ETAPES
Les Activités sont décomposées en plusieurs étapes. Il existe 3 catégories principales pour les étapes :
• les étapes de réflexion : lorsque la personne qui occupe le rôle comprend la nature de sa
tâche, collecte et examine les produits de travail en entrée, et formule la sortie.
• les étapes de réalisation : lorsque la personne qui occupe le rôle crée ou met à jours certains
produits de travail.
• les étapes de revue : lorsque les produits créés et modifiés sont inspectés selon certains
critères.
Toutes ces étapes ne sont pas forcément nécessaires à chaque fois dans une activité, et peuvent être
formulées sous forme de flots.
Exemple : l' Activité Identifier acteurs et cas d'utilisation se décompose dans les étapes suivantes :
1. Trouver les acteurs
2. Trouver les cas d'utilisation
3. Décrire les interactions entre acteurs et cas d'utilisation
4. Former des paquetages de cas d'utilisation et acteurs
5. Présenter le modèle des cas d'utilisation sous forme de
diagrammes de cas d'utilisation
6. Rédiger un résumé du modèle des cas d'utilisation
7. Evaluer les résultats
La partie recherche [étape 1 à 3] nécessite de la réflexion ; la partie réalisation [étapes 4 à 6] consiste
à capturer le résultat de cette réflexion dans un modèle des cas d'utilisation ; la partie revue [étape 7]
est présente quand l'individu dont c'est le rôle évalue la complétude, la robustesse, l'intelligibilité et
les autres qualités du modèle de cas d'utilisation.
4.3.4 GUIDES DE TRAVAIL
Aux activités peuvent être associés des guides de travail, qui présentent le s techniques et conseils
pratiques qui sont utiles pour réaliser l'activité. Les guides de travail applicables sont matérialisés par
aubryConseil – Stage Olivier Denizon
23
des hyper-liens dans la page de description de l'activité elle -même. La Vue générale des guides de
travail résume aussi l'ensemble de guides de travail disponibles, et est accessible depuis l'arborescence
de navigation dans le nœud Pages tirées du RUP →→ guides de travail.
4.3.5 PRODUITS DE TRAVAIL
Les Activités possèdent des produits de travail en entrée et des produits de travail en sortie. Un
produit de travail est un élément tangible produit ou utilisé au cours du processus : les rôles utilisent
des produits de travail pour réaliser des activités, et produisent des produits de travail au cours de ces
mêmes activités. Les produits de travail sont sous la responsabilité d'un et un seul rôle selon l'idée que
chaque élément du processus doit être sous la responsabilité d'une personne spécifique. Bien qu'une
seule personne puisse "posséder" le produit de travail, de nombreuses autres peuvent avoir à l'utiliser,
voire même le mettre à jour ou le modifier s'ils en ont la permission.
Figure 13 Les produits de travail principaux du RUPS, et le flot d'information entre eux.
Le diagramme ci-dessus montre comment l'information circule tout au long du projet, au travers des
produits de travail; les flèches montrent comment les changements d'un produit de travail peuvent se
propager à d'autres produits de travail. Pour plus de clarté, de nombreux produits de travail ont été
omis (par exemple les produits constituant le modèle de conception : les classes, les paquetages n'ont
pas été représentés).
Pour simplifier l'organisation des produits de travail, on les organise selon des ensembles de produits
de travail qui ont tendance à être utilisés en même temps ou dans le même but. La Vue générale des
aubryConseil – Stage Olivier Denizon
24
produits de travail présente plus d'informations sur les produits de travail et les ensembles de produits
de travail.
Figure 14 Produits de travail et ensemble de produits de travail dans l'arborescence de navigation
Les produits de travail peuvent prendre plusieurs formes:
• Un modèle , tel que le Modèle des cas d'utilisation qui contient lui-même d'autres produits de
travail.
• Un élément de modèle , c'est à dire un élément qui fait partie intégrante du modèle, tel qu'un
Cas d'utilisation ou un Paquetage de cas d'utilisation.
• Un document, tel que le document de Vision ou le Document d'Architecture Logicielle.
• Le code source et les exécutables (sortes de Composants).
Les fournitures (produits livrables au client) ne sont qu'un sous-ensemble des produits de travail.
Les produits de travail ne sont pas obligatoirement des documents . Les processus traditionnels
encouragent de façon excessive la production de documents, et en particulier des documents papier.
Le RUPS désapprouve la production systématique de documents papier. L'approche la plus efficace et
la plus pragmatique pour gérer les produits de travail d'un projet est de maintenir les produits de
travail à l'intérieur de l'outil utilisé pour les créer. Lorsque c'est nécessaire, vous pouvez générer des
documents ("instantanés") à partir de ces outils, sur la base du "quand on en a besoin". Vous pouvez
également considérer la livraison des fournitures aux clients comme faisant partie intégrante de l'outil,
plutôt que de fournir du papier. Cette méthode garantit que les documents sont toujours à jour et basés
sur la version courante du projet, et ne nécessitent aucun effort de production supplémentaire.
Cependant, il y a tout de même des produits de travail qui doivent se trouver sous forme de documents
texte, dans le cas d'entrées externes au projet, où dans le simple cas consistant à décrire un élément.
Exemples de produits de travail :
• Un modèle des cas d'utilisation avec Rational Rose.
aubryConseil – Stage Olivier Denizon
25
• Un planning projet avec Excel.
• Une document Vision avec Word.
4.3.6 PLAN TYPE
Les plans types sont des "modèles" ou des prototypes. Associés avec la description d’un produit de
travail, ils sont utilisés pour le créer. Les plans types sont liés aux outils utilisés pour le produit.
Par exemple:
• Plans types Microsoft Word utilisés pour les produits de travail de type documents, et certains
rapports.
• Plans types Rational SoDA pour Microsoft Word pour extraire des informations d'outils tels
que Rational Rose.
Les plans types font partie des éléments qu'on adapte à une organisation. Les plans types du RUPS
sont dans ce cas.
Les plans types sont organisés dans l'arborescence de navigation sous chacun des produits de travail
auxquels ils sont associés. Ils sont également rassemblés dans un nœud de l'arborescence qui contient
la liste de tous les plans types.
Figure 15 Les différents formats de plans types du RUPS
4.3.7 RAPPORT
Les modèles et éléments de modèle peuvent être associés à des rapports. Un rapport extrait des
informations sur le modèle et ses éléments à partir d'un outil. Par exemple, un rapport présentant un
produit de travail ou un ensemble de produits de travail pour une revue. A la différence des produits
de travail réguliers, les rapports ne font pas l'objet de versions. Ils peuvent être reproduits n'importe
quand en retournant au produit de travail qui les a générés. Les rapports concernant un produit sont
placés sous le nœud de celui-ci dans l'arborescence de navigation.
4.3.8 GUIDES DE PRODUIT ET POINTS DE CONTROLE
On associe fréquemment aux produits de travail des guides et des points de contrôle qui présentent
des informations sur la façon de les créer ou les rédiger, de les évaluer et les utiliser. Une bonne partie
de la substance du processus est contenue dans les guides des produits de travail; les descriptions des
activités capturent l'essence de ce qui est fait, tandis que les guides capturent l'essence de l'art
d'accomplir ce travail. Les points de contrôle (checkpoints) fournissent une référence rapide pour
aider à évaluer la qualité d'un produit.
aubryConseil – Stage Olivier Denizon
26
Les guide et les points de contrôle sont utiles dans certains contextes : pour aider à décider quoi faire,
aider à le faire, et aider à vérifier le résultat. Les guides et les points de contrôles relatifs aux produits
de travail se situent sous le nœud du produit de travail dans l'arborescence de navigation.
Figure 16 Point de contrôle et guide associés au produit de travail "Classe d'analyse"
4.3.9 WORKFLOW
Une simple énumération de tous les rôles, activités et produits de travail ne constitue pas un processus
il faut décrire les séquences d'activités usuelles pour produire des résultats de qualité, et montrer les
interactions entre les rôles. Un workflow est une séquence d'activités qui produit un résultat
observable.
Le workflow d'une discipline est décrit par un diagramme d'activité UML. En fait ce diagramme
montre des groupes d'activités, présentés plus loin.
aubryConseil – Stage Olivier Denizon
27
Figure 17 Diagramme d'activité de la discipline Gestion de Projet
4.3.10 DISCIPLINE
Une discipline est un composant du processus, organisée selon une perspective caractéristique de
l'ingénierie du logiciel. Les noms de la discipline reprennent les termes habituellement utilisés dans
les cycles de vie en cascade ou en V.
Figure 18 Disciplines dans l'arborescence de navigation
Le workflow d'une discipline est la séquence semi-ordonnée d'activités réalisées pour atteindre un but
commun. La nature "semi-ordonnée" des workflows de discipline tient au fait qu'on ne peut pas
aubryConseil – Stage Olivier Denizon
28
représenter les nuances du cheminement intellectuel dans la vie de tous les jours sur les projets.
Cependant ils ont le mérite de permettre de comprendre le processus en le divisant en de
petites « zones d'intérêt ».
Chaque zone d'intérêt ou discipline est associée à un ou plusieurs modèles, qui sont composés de
produits de travail associés. Les produits de travail les plus importants sont les modèles que chaque
discipline produit : modèle de cas d'utilisation, modèle de conception, modèle d'implémentation, et
modèle de test.
Figure 19 Chaque discipline est associée à un ensemble particulier de modèles Pour chaque discipline, une vue générale des activités est également présentée. La vue générale des
activités montre toutes les activités de la discipline ainsi que le rôle qui réalise ces activités. La vue
générale des produits de travail montre tous les produits de travail et les rôles impliqués dans la
discipline.
A noter que les disciplines ne sont pas totalement indépendantes les unes des autres. Il existe des
produits de travail qui sont utilisés dans plusieurs disciplines (par exemple la vision entre Expression
des exigences et en gestion de projet).
4.3.11 GROUPE D'ACTIVITES
Le workflow d'une discipline ne montre pas directement les activités, mais des groupes d'activités,
montrant des regroupements d'activités qui sont souvent réalisées "ensemble". Chaque groupe
d'activité est lui-même décrit par un tableau montrant les rôles impliqués, les produits de travail en
entrée et en sortie, et les activités réalisées. Les groupes d'activités existent pour les raisons suivantes :
• Les activités du groupe ne sont ni réalisées en séquence, ni réalisées simultanément.
Typiquement le travail se fait en parallèle sur plusieurs activités, avec des produits de travail
en entrée.
• Il est trop complexe de montrer les documents en entrée et en sortie pour toutes les activités
d'une discipline en un seul diagramme. Le groupe d'activités permet de montrer à la fois les
activités et les produits de travail, pour une partie de la discipline à un moment donné.
aubryConseil – Stage Olivier Denizon
29
4.3.12 GUIDES OUTILS
Les activités, les étapes et les guides associés fournissent des indications à l'utilisateur du processus.
Pour continuer dans ce sens, les guides outils permettent de guider l'utilisateur sur la façon d'utiliser
un outil logiciel spécifique. Des guides outils sont fournis dans le RUPS pour Rose et SoDa.
Les guides outils permettent de rendre le reste du processus indépendant des outils. Seul le guide outil
encapsule les dépendances du processus sur les outils.
Figure 20 L'organisation des guides outils dans l'arborescence de navigation
4.3.13 CONCEPTS
Certains des concepts clés du processus, tels que les itérations, les phases, les risques sont introduits et
associés à la discipline qui convient.
Figure 21 L'organisation des concepts dans l'arborescence de navigation
4.4 TRAVAIL PERSONNEL SUR LES PRINCIPES ET ELEMENTS
Les premiers jours du stage ont été consacrés à une formation sur le s processus et le RUPS dispensée
par Claude AUBRY, en s’appuyant sur deux supports de cours Rational (en anglais) :
- « RUP fundamentals »,
- « RUP implementation ».
Au cours de ces formations j’ai pu apprendre les concepts majeurs véhiculés par le RUP : ce qu’est
une discipline, un workflow, un groupe d’activités…
J’étais déjà familier avec la première des 2 dimensions du processus : les notions de phases, de cycle
aubryConseil – Stage Olivier Denizon
30
de vie, de rôles et d’activités ; j’ai cependant découvert une nouvelle interprétation de la notion
d’itération faite par Rational avec la livraison ou au moins la démonstration systématique de produits
de travail lors de la fin d’une phase (diminuant l’effet tunnel) , l’importance accordée également à la
gestion de risques (qu’on doit sans cesse essayer de traiter et minimiser).
Ensuite et surtout, j’ai découvert la deuxième dimension du processus avec les disciplines, les
workflows et « workflow details » qui m’étaient jusqu’ici inconnus et que j’ai dû apprendre à
connaître.
J’ai également dû « apprendre à naviguer » avec le RUP. Malgré un bon système de navigation et un
système de recherche par mots clés, il n’est pas toujours aisé de se rappeler quelle séquence on a suivi
pour arriver sur une page dans un site qui en contient plus de 3000 !
A force d’utilisation, nous avons constaté que l’un des défauts du RUP est la grande quantité de liens
présents dans une page de description d’un élément du processus. On est en effet souvent tenté de
cliquer sur un lien alors que l’on n’a pas encore lu la page en entier ce qui à tendance à "perdre"
même un utilisateur initié du RUP.
Fort de cette constatation, nous avons décidé de limiter la quantité d’hyperliens dans les pages HTML
que nous avons modifiées.
aubryConseil – Stage Olivier Denizon
31
5 RATIONAL PROCESS WORKBENCH (RPW)
5.1 POURQUOI LE RPW ?
Au début du stage nous ne possédions pas l’outil, qui jusqu’en fin mai 2001, nécessitait une licence
spécifique. A l’issue du premier mois du stage, nous avons participé à une réunion de présentation du
projet dans les locaux de la société Rational à Toulouse. Cette réunion coïncidait avec la fin de la
phase de lancement du projet. Au cours de celle -ci, nous avons demandé à André ARICH, le
responsable du partenariat chez Rational, le prêt d’une licence pour évaluer le produit. L’évaluation,
bien que longue et chaotique, nous a convaincu de poursuivre son utilisation jusqu’à la fin du projet.
A noter que depuis la nouvelle version de juin 2001, le RPW est désormais inclus dans la Suite
Entreprise de Rational et n’est plus licencié de façon indépendante.
5.2 PRESENTATION DU RPW
Le Rational Process Workbench (RPW) est un outil qui permet de construire "vite et bien" un
processus de développement adapté aux besoins d'une organisation. Il est principalement destiné aux
ingénieurs processus, mais aussi aux chefs de projets. C’est le premier (?) outil du genre.
Le RPW s'appuie sur la modélisation UML et se présente sous la forme d'un add-in du logiciel
Rational Rose. Il est indispensable pour l'utilisateur de l'outil RPW, de posséder de solides
connaissances d'UML avec l'outil Rational Rose, et conseillé d’avoir des connaissances sur les
processus.
RPW s’appuie sur l’aspect graphique et sémantique apporté par la notation UML, pour définir et créer
un processus. Au travers de la modélisation de processus, on crée une représentation conceptuelle du
processus. Cette technique de représentation permet de disposer d'un espace de travail où le processus
peut être modélisé, discuté, revu et publié sans être décrit textuellement. A partir du modèle de
processus UML, lorsque celui-ci ne présente pas d'anomalies, on peut alors générer automatiquement
un site web présentant le processus (sous la même forme que le RUP).
Le RPW est livré avec le modèle du processus du RUP. Il est d’ailleurs conseillé par Rational de
s’appuyer sur le RUP pour modéliser un processus, dans la mesure où c’est un processus éprouvé ce
qui garantit ainsi une solution de qualité et permet de gagner du temps. Pour cela, il convient
d’organiser l'espace de travail et récupérer des éléments du RUP que l'on ne souhaite pas modifier ou
modifier légèrement. Cela présente, en plus, l’avantage de l’évolutivité dans la mesure où le RUP est
réactualisé environ tous les 6 mois.
5.3 COMPOSITION DU RPW
Le RPW crée un environnement pour la définition et la création de processus. Dans cet
environnement, 3 entités indispensables ont été introduites :
5.3.1 LE MODELE DE PROCESSUS
Paquetage de la logical view Rose stéréotypé "process model". A l'intérieur sont définis les éléments
aubryConseil – Stage Olivier Denizon
32
statiques du processus : des rôles, des activités, des disciplines etc, (classes avec des stéréotypes
spécifiques du RPW) et les associations entre ces différents éléments.
On y exprime aussi la dynamique avec des diagrammes d'activité qui décrivent les "workflows", c'est
à dire l'enchaînement des activités du processus.
5.3.2 LE MODELE DE COMPOSANTS
Paquetage de la component view Rose, le modèle de composants contient les définitions des différents
composants de processus. C’est ici que l'on choisit les éléments que l'on souhaite ajouter à son propre
processus.
5.3.3 LA "PROCESS CONTENT LIBRARY"
La librairie contient la collection de pages HTML et fichiers associés aux éléments du modèle de
processus (page web de description de l’élément, diagramme, icônes à insérer dans le
Treebrowser*…)
* treebrowser : arbre de navigation du site web généré.
N.B : Pour les raisons d’évolutivité évoquées plus haut, il est indispensable de créer un répertoire
Process Content Library pour son propre processus, distinct de celui du RUP fourni avec le R.P.W.
Lorsque ces trois éléments sont complets et cohérents (pas d’éléments du modèle non associés à un
fichier HTML, pas de produit de travail sans responsable …), on peut générer le site web du
processus.
Figure 22 Environnement de travail du RPW (add-in de Rational Rose)
Modèle conceptuel du RUP
fourni en référence
Modèle physique du RUP
fourni en référence
Modèle physique du
processus à réaliser
Modèle conceptuel du
processus à réaliser
aubryConseil – Stage Olivier Denizon
33
5.4 TRAVAIL PERSONNEL SUR L’OUTIL
Au cours du stage, j’ai beaucoup travaillé avec le RPW, dont j’étais le spécialiste sur le projet.
L'apprentissage de l'outil a occupé une bonne partie du temps de ce stage. La longueur de la prise en
main pour arriver à sa maîtrise a d’ailleurs nécessité un ajustement du plan de développement initial.
Le RPW est difficile à prendre en main, parce que :
- Etant très récent, il n’y a pas de retours d'expérience, et peu de documentation en dehors du
manuel d’utilisation.
- Il a encore quelques bugs.
- Il se situe au niveau "meta" : on ne modélise pas ici un logiciel mais une démarche de
développement.
- Il s'adresse à des spécialistes de l'UML et des processus.
- Il utilise de nombreux stéréotypes supplémentaires par rapport à Rational Rose standard
("workflow detail", "model", "model element", "document", "role","process").
- Il manipule des notions nouvelles (notion de "closure"...).
- La façon de procéder induit des enchevêtrements complexes entre tous les éléments.
- Les fonctionnalités ne sont pas très apparentes ; la plupart d’entre elles se trouvent derrière un
clic droit ("assess closure", "check files", "check syntax", "overview", "set template
directory", "set output directory", "publish"...).
- Il ne permet pas de traduire aisément tout ce que l’on souhaite (certains éléments sont générés
automatiquement, et bien sûr en anglais)
- Il ne permet pas de réutiliser des rôles du processus générique auxquels on veut enlever des
activités*.
* Suite au téléchargement du patch rpw.rn.sr2.exe en ligne sur le site de Rational à la fin du mois de
juillet, il nous a été enfin possible d'utiliser le stéréotype "noop" qui permet de supprimer une
opération qu'on ne souhaite pas conserver d'une classe héritée (rendant l’héritage d’éléments du RUP
légitime dans notre modèle de processus).
La principale raison reste que la modélisation d'un processus est une tâche très complexe qui nécessite
des re-vérifications constantes.
L’utilisation du RPW se poursuit et à l’heure actuelle nous disposons d’un modèle de processus
stable.
Produits de travail élaborés :
- 4 pages web sur le RPW pour le site projet : Présentation du RPW, Fonctionnement,
Stratégie d'implémentation et Difficultés d'apprentissage (disponibles sur le site projet)
- templates du RPW traduits (pages servant de squelette pour tous types de fichiers, contenant
des commandes RPW pour génération automatique de certains éléments)
aubryConseil – Stage Olivier Denizon
34
- modèle RPW du processus RUPS créé (fichier rups.mdl).
- manuel de génération du RUPS (éléments nécessaires et directives pour publier un site à
partir du modèle).
aubryConseil – Stage Olivier Denizon
35
6 DEFINITION ET REALISATION DU RUPS
Les activités réalisées et les produits élaborés pendant le projet sont regroupés par disciplines, par
analogie au RUP. On rappelle que le développement du RUPS est itératif et que les disciplines
présentées ne se déroulent pas de façon séquentielle.
6.1 GESTION DE PROJET
La gestion de projet a été présentée au début du document. Elle a consommé 1 Homme mois (sur les 8
HM du projet). Les objectifs et les plans ont été ajoutés au cours du projet en fonction des résultats
des itérations.
6.2 ENVIRONNEMENT
Cette discipline comprend la formation au domaine, ainsi que l’apprentissage des outils. On évalue à
2,25 Hommes mois le temps passé, avec une grosse partie due au RPW. Pour un nouveau
développement de processus, ce temps serait considérablement réduit.
6.3 DEFINITION DU PROCESSUS
Cette discipline a consommé environ 1,5 HM. Les 3 produits suivants ont été réalisés, disponibles sur
le site projet :
• Glossaire
• Evaluation du processus actuel
• Vision du nouveau processus
L’évaluation du processus actuel a permis d’en déterminer les caractéristiques, les points faibles afin
de voir sur quels aspects mettre l’accent dans le processus à réaliser (adopter un cycle plus itératif,
mieux gérer les risques, approfondir l’expression des exigences, mettre l’accent sur l’architecture), les
contraintes liées à l’organisation dont il faudra tenir compte (par exemple la séparation entre la
maîtrise d’ouvrage et l’équipe de réalisation).
La vision présente le processus à réaliser, avec ses principales caractéristiques et ses avantages.
Comme le processus est dérivé du RUP, la vision met en évidence les choix effectués pour la
simplification sur les éléments essentiels du processus : disciplines, rôles et produits. La vision prend
également en compte les particularités de l’organisation. Par exemple, les choix suivants ont une
grande influence sur le processus final :
• Non prise en compte des disciplines de modélisation métier et gestion de configuration.
• Regroupement des rôles de lecteurs, contrôleurs et intervenants en un rôle unique de
superviseur de projet.
• Mise en place des phases et itérations en définissant toutes les revues associées.
• Nouvelle approche de la qualité avec la suppression du produit plan assurance qualité et
incorporation dans les activités du processus.
aubryConseil – Stage Olivier Denizon
36
6.4 REALISATION DU PROCESSUS
La réalisation du processus s’est appuyée sur le RPW. Au fur et à mesure de l’apprentissage de l’outil
RPW, nous avons mis au point une façon de travailler en parallèle, et nous avons fixé des règles pour
la modélisation, la création, la modification des pages web.
Les activités de réalisation peuvent se décomposer en :
• Le travail de modélisation
• Le travail sur les librairies
• Le travail de génération du site
6.4.1 MODELE
La modélisation du processus a pris moins d’un homme mois, une fois que l’outil a été maîtrisé.
Le modèle du RUPS définit le nouveau processus, en réutilisant chaque fois que c’est possible le
modèle du RUP fourni avec le RPW. Les produits du RUPS sont un sous-ensemble de ceux du RUP;
il est donc possible de définir une dépendance vers les produits qui nous intéressent sans les créer
dans le modèle.
Nous avons supprimé un grand nombre de rôles et d’activités et nous en avons fusionné d’autres.
L’analyste système du RUP est par exemple la fusion du "system analyst" et du "use case specifier"
du RUP(cf. fig. 23).
Figure 23 Illustration de l’héritage et de la fusion de rôles
Rôle hérité
Rôle défini dans
le modèle RUP
Héritage multiple impossible
⇒ on attribue à l’analyste système
les mêmes responsabilités que le
« use case specifier »
aubryConseil – Stage Olivier Denizon
37
L’héritage multiple n’étant pas possible dans le RPW, nous avons dû procéder à l’héritage simple de
l’un des rôles : l’analyste système hérite du "system analyst" ; conjugué à l’attribution à ce rôle des
responsabilité du second que nous voulions hériter : comme le "use case specifier", nous avons rendu
notre analyste système "responsable" des produits de travail "use case" et "use case package".
Les rôles conservés dans le RUPS sont tous hérités du RUP et redéfinis dans le modèle RUPS. Les
activités sont modélisées comme des opérations sur les rôles et il est possible de :
- les hériter si les entrées et sorties du RUP conviennent,
- les redéfinir si les entrées ou sorties doivent être modifiées dans le RUPS,
- les supprimer si l’activité n’est pas nécessaire dans le RUPS (avec le stéréotype noop).
Figure 24 Illustration de l’héritage, de la suppression d’opérations et redéfinition Par rapport au RUP, des éléments modifiés radicalement sont les workflows des disciplines. C’est en
effet dans les workflows que l’on peut décrire la spécificité du RUPS, son adaptation à l’organisation
et son allègement par rapport au RUP :
Activités
supprimées
Activités héritées
et redéfinies Activité héritée
aubryConseil – Stage Olivier Denizon
38
Figure 25 Un workflow du RUP à gauche, celui du RUPS à droite Une conséquence de la suppression des disciplines de modélisation métier et de gestion de
configuration et de ces workfows différents est le gros travail à faire sur les activités, créées ou
redéfinies, pour que les produits de travail en entrée et en sortie soient cohérents.
6.4.2 LIBRAIRIES
Le travail sur les librairies a demandé environ 1,5 homme mois. Cela inclut la création de nouvelles
pages HTML et la traduction en français de pages du RUP.
L’utilisation de l'héritage (pour les outils et les rôles) nous a contraints à travailler avec 2 Process
Content Libraries (PCLs) :
- Une associée au modèle du RUP pour les rôles, les activités non redéfinies, les outils, et
les guides outils non redéfinis,
- Une autre associée au modèle RUPS pour les éléments créés ou rédéfinis.
Par conséquent, nous avons créé et associé au modèle du RUP une copie de la PCL du RUP où ces
éléments (rôles, disciplines, activités…), décrits sous forme de fichiers HTML, ont été modifiés
selon notre stratégie de traduction.
aubryConseil – Stage Olivier Denizon
39
Figure 26 Association d’une PCL à l’élément stéréotypé "process model"
Notre processus est donc structuré comme suit en ce qui concerne l’association aux Process Content
Libraries :
Figure 27 Schéma décrivant les associations du modèle aux 2 librairies
Espace de travail du RPW
Modèle de processus du RUP
Modèle de processus du RUPS
dépendance
Mémoire
PCL RUP
PCL RUPS
dupliqué et francisé
Eléments créés
ou hérités et
redéfinis
Eléments
hérités du
RUP nouvelle
association
éléments nouveaux
ou redéfinis, traduits
ou non traduits
PCL RUP francisée
Description des éléments
hérités non redéfinis (rôles,
activités, outils, guides outils)
aubryConseil – Stage Olivier Denizon
40
Toutes les pages ne sont pas traduites en français. Nous avons décidé de traduire :
• les pages de généralités (présentation des phases, des rôles, des produits, des
disciplines...)
• les disciplines, workflows et groupes d’activités ,
• les produits de travail (uniquement le tableau récapitulatif),
• les rôles,
• les activités (uniquement le tableau récapitulatif),
• tous les plans types.
Le reste est repris du RUP et ne sera pas traduit :
• les guides (sauf des guides que nous pourrions décider d'ajouter),
• les concepts (sauf des concepts que nous pourrions décider d'ajouter),
• les guides outils (tool mentors),
• les guides de travail (work guidelines),
• les pages blanches.
Le squelette du Treebrowser est traduit en français (fichier "tree.dat" dans le répertoire "applet"
de la Process Content Library)
Le site web de notre processus conserve la même arborescence de répertoires que le site du RUP.
Nous ne renommerons pas les pages que nous traduisons ou modifions dans la mesure où
l'élément décrit existait déjà dans la PCL du RUP. Par exemple, une page de description du produit
"Vision" existe dans le RUP et s'appelle "ar_vision.htm" dans le répertoire process/artifact. Il en est
de même pour la version francisée dans la PCL du RUPS. Cela nous permet de ne pas nous
préoccuper des liens qui existaient dans le texte des pages web que nous retravaillons.
Les pages relatives à un élément de processus nouveau par rapport au RUP, ou spécifique du
processus RUPS seront préfixées "RUPS_ " puis du préfixe RUP qui convient ("ar_" pour artifact,
"ac_" pour activity...comme dans le RUP) suivi d'un nom décrivant l'élément. Supposons que nous
voulions créer un élément de processus pour un "cahier de recette", on créerait dans la Content
Library une page intitulée "RUPS_ar_recette.htm"
6.4.3 GENERATION DU SITE
Cette partie a nécessité environ 0,75 Homme mois. Elle inclut les vérifications faites par le RPW sur
aubryConseil – Stage Olivier Denizon
41
le modèle (fermeture transitive), sur les librairies (vérification des fichiers associés) et la génération
du site.
Le manuel de génération présente les directives de publication à partir du modèle et des librairies.
6.5 LE DEPLOIEMENT DU PROCESSUS
Le déploiement du processus ne fait pas partie du projet. Seul un guide d’installation a été rédigé. Il
précise que pour une utilisation optimale du site RUPS, il est nécessaire d’avoir à sa disposition un
navigateur Internet, Microsoft Word et Rational Rose, afin de pouvoir utiliser les guides, les
documents et modèles de documents qu’il contient.
6.6 QUELQUES CHIFFRES
Tableau comparatif du RUP et du RUPS
RUP RUPS
Disciplines 9 4
tous les Workflows ont été modifiés.
Groupes d’activités (workflow details)
57 répartis sur les 9 disciplines 18 répartis sur les 4 disciplines réalisées
Concepts 71 répartis sur les 9 disciplines 25 (non traduits) répartis sur les 4
disciplines
Rôles 31 répartis en 5 catégories 9 (tous hérités) répartis en 3 catégories
(analystes, développeurs, gestionnaires)
Activités 136 activités pour les 31 rôles 42 activités pour les 9 rôles :
1 nouvelle activité créée
38 activités redéfinies
3 activités non redéfinies
28 «noop» (activités supprimées de l’héritage)
Outils 16 2 Rose et Soda
Guides outils 107 22 : 2 pour Soda et 20 pour Rose
Produits de travail 90 répartis sur les 9 disciplines 32 répartis sur les 4 disciplines réalisées
Guides de travail 14 14 identiques, non traduits
Plans types 42 HTML et 42 word mais
aussi SODA, Ms Project et
Framemaker
11 traduits en français en HTML et en
word, 1 template Soda de rapport des cas
d’utilisation.
Fichiers HTML près de 3000 449
Espace disque requis 32,8 Mo 16,5 Mo
Autres 1 projet web exemple d’application du
RUPS (voir chapitre suivant)
aubryConseil – Stage Olivier Denizon
42
6.7 TRAVAIL PERSONNEL SUR LE RUPS
Dans un premier temps j’ai eu à déterminer dans quelle mesure le RUP pouvait être adapté, quel sous-
ensemble du RUP nous voulions conserver pour établir notre processus simplifié. J’ai donc rassemblé
ces informations dans un document de vision (disponible sur le site projet) où sont répertoriés les
rôles et les produits de travail que nous allions conserver, fusionner, supprimer.
Ceci se passait à une époque où nous ne savions pas encore avec certitude que nous utiliserions l’outil
RPW pour adapter le RUP.
Par la suite, l’outil RPW m’a conduit à travailler à la fois sur le modèle du RUP et sur les pages web
qui le composent. J’ai eu alors à effectuer un travail d’analyse des pages qu’il serait pertinent de
garder voire de traduire.
Activités réalisées :
- création et vérification de la fermeture transitive (« closure ») du modèle
- collaboration à la customisation des workflows
- collaboration à la traduction de pages
- organisation du treebrowser
- création de pages (différences avec le RUP, nouveaux groupes d’activités)
Produits de travail élaborés :
- guide d’installation du RUPS
- pages web traduites en français (généralités, expression des exigences, produits de travail…)
aubryConseil – Stage Olivier Denizon
43
7 UN EXEMPLE D’ILLUSTRATION DU PROCESSUS
7.1 OBJECTIF
Un exemple a été développé à partir des projets qui se sont terminés en mars 2001. Le sujet est un
système de gestion des stages. Il se présente sous la forme d’un projet web intitulé EASYSTAGE.
Ce projet web est une simulation de suivi de projet, destinée à fournir un exemple de mise en
application d'un processus de développement.
Il présente des documents conformes aux plans types contenus dans le site du processus implémenté
et permet ainsi aux lecteurs d’avoir une bonne illustration des résultats attendus lors de leur mise en
application du processus pour leur projet.
Figure 28 Capture écran du site projet EasyStage
7.2 CONTENU
Ce site contient actuellement l’expression des besoins du client et les produits de la discipline
d’Expression des exigences :
- le glossaire,
- le document vision,
- le modèle des cas d’utilisation avec les spécifications détaillées de 6 cas d’utilisation. Le
modèle produit à partir de Rose avec le Web Publisher est accessible.
- les spécifications supplémentaires.
7.3 TRAVAIL PERSONNEL SUR L’EXEMPLE
Dès le début du stage nous avions comme objectif de réaliser 3 sites : le processus lui-même, un site
d’avancement du projet et un site exemple, permettant de constater la mise en application du
processus sur un projet. J’ai personnellement participé à la réalisation du site exemple en :
aubryConseil – Stage Olivier Denizon
44
- créant l’architecture du site (treebrowser…) et sa présentation (logo, style),
- rédigeant la page de bienvenue sur le site
- étudiant les projets de logiciels de gestion de stages existants
- rédigeant une première version du glossaire
- rédigeant des premières versions des documents de travail de l’expression des exigences :
vision, spécifications supplémentaires
- créant la première version du modèle des cas d’utilisation.
aubryConseil – Stage Olivier Denizon
45
8 BILANS
8.1 LE PROJET
Il ne s’achèvera qu’en fin septembre au lieu de fin août. Cependant on peut déjà constater que
l’apprentissage du RPW et du RUP prend beaucoup temps la première fois.
La modélisation oblige à une réflexion très poussée, et nous pensons qu’il est préférable de bien faire
une partie plutôt que d’essayer de définir un processus complet dès la première fois. Procéder par
composants de processus, par exemple les disciplines, paraît une bonne approche pour réaliser et
déployer des nouvelles pratiques dans les organisations. C’est ce que nous avons décidé en cours de
projet en nous consacrant uniquement à 4 disciplines.
8.2 LE PRODUIT
Le déploiement du RUPS va commencer avec la formation et se poursuivra par l’utilisation du
nouveau processus sur les projets de Bureaux d’Etudes à partir d’octobre 2001.
8.3 LE STAGE
Ce stage m’a permis, après avoir travaillé pour des PME, des grands comptes et des start-up de me
familiariser avec un nouveau type de structure.
Ce travail en collaboration avec Claude AUBRY m’a conduit à faire preuve d’initiative et de rigueur
dans mon travail, favorisant la communication (échange fréquent de mails, coups de téléphone…).
L’organisation du travail fonctionnait très bien avec des points d’avancement quasi hebdomadaires, et
des réunions d’avancement avec des intervenants extérieurs (enseignants, Rational).
L’apprentissage du RPW, point essentiel de ce stage, a été sans doute plus complexe que nous
l’avions imaginé mais je crois pouvoir dire que désormais nous maîtrisons très bien cet outil, ce qui
est une grande fierté.
Cette utilisation du RPW a nécessité de porter une grande attention à la gestion de configuration en
particulier lorsque l’on veut travailler simultanément sur le site du processus.
aubryConseil – Stage Olivier Denizon
46
9 ANNEXES
9.1 BIBLIOGRAPHIE
Livres :
o The Rational Unified Process An Introduction, Second Edition
de Philippe KRUCHTEN
édition ADDISON -WESLEY Object Technology Series
http://www.aw.com/cseng/otseries
NB : Ce livre existe aussi en français chez Eyrolles, mais la traduction porte sur la première
édition.
Articles :
o SPEM
Rapport du groupe de travail de l'OMG sur les processus de développement de logiciel
qui définit le méta-modèle SPEM (Software Process Engineering Metamodel)
o iterative development
Un article de Philippe Kruchten sur les pièges du développement itératif.
Supports de cours Rational :
o Les fondamentaux du RUP
o Implémenter le RUP
9.2 GLOSSAIRE
Ce glossaire s'appuie sur celui fourni (en anglais) avec la version d’avril 2001 du SPEM . On rappelle
que le SPEM définit le standard de représentation des processus. Un tableau comparatif montre les
différences entre ce vocabulaire, celui utilisé dans le RUP et dans les standards ISO et IEEE.
Activité
Définition d'un travail décrivant ce qui est produit dans la cadre d'un Rôle . Les activités
sont l'élément principal d'un travail (SPEM).
Composant de Processus
Un Composant de Processus est un regroupement cohérent d'Eléments de Modèle organisés
de façon à obtenir une perspective intéressante, telle que la Discipline, par exemple le test,
ou la production de certains Produits de travail, par exemple la gestion des exigences
(SPEM).
Cycle
aubryConseil – Stage Olivier Denizon
47
Un passage complet par les phases du cycle de vie (RUP).
Cycle de vie
Un cycle de vie pour un processus est défini comme une séquence de phases pour accomplir
un but précis. Le cycle de vie définit le processus qui sera appliqué sur un projet donné
(RUP).
Définition de travail
C'est un Elément de Modèle d'un processus qui décrit l'exécution, les opérations réalisées, et
les transformations opérées sur les produits de travail dans le cadre d'un Rôle. Parmi les
définitions de travail on trouve les Activités, les Itérations, les Phases et le cycle de vie
(SPEM).
Dépendance
Une dépendance est une relation particulière, spécifique au processus, qui lie entre eux des
Eléments de Modèle (SPEM).
Discipline
Une discipline est une unité du processus, organisée selon une perspective caractéristique de
l'ingénierie du logiciel : Gestion de Configuration, Analyse et Conception, Gestion de
Projet, etc (SPEM).
Elément de Modèle
C'est un élément qui décrit un aspect d'un processus (SPEM).
Etape
Une étape est une Définition de travail atomique, à grain fin, utilisée pour décomposer des
Activités . Les Activités sont des ensembles d'étapes, partiellement ordonnées (SPEM).
Exécutant de processus
Elément du modèle qui décrit les rôles, les responsabilités et compétences d'un individu
fournissant des Activités au sein du Processus, et responsable de certains produits de travail
(SPEM).
Guide
Le Guide est un Elément de Modèle associé aux éléments principaux de définition de
processus, qui contient des descriptions supplémentaires telles que des techniques, des
méthodes, des profils UML, des procédures, des standards, des plans types de fournitures,
des exemples de produits de travail , des définitions, etc (SPEM).
Guide de produit
aubryConseil – Stage Olivier Denizon
48
C’est un Guide associé à un produit, qui fournit des règles et des recommandations pratiques
sur la façon de créer et d’organiser le produit.
Guide de travail
C’est un Guide associé à une activité, qui fournit des techniques utiles pour la réalisation de
l’activité (RUP).
Guide outil
C’est un Guide qui fournit une description détaillée sur la façon de réaliser une activité ou
des étapes de l’activité, avec l’aide d’un outil.
Itération
Une Itération est une définition de travail, à gros grain, qui représente un ensemble
d'Activités, visant au développement d'une portion du système, et qui s'achève par la
fourniture (interne ou externe) d'un produit logiciel (SPEM).
Liste de contrôle
C’est un Guide qui contient une liste de points à contrôler pour évaluer la qualité d’un
produit de travail (RUP).
Phase
Définition d'un travail à haut niveau, parachevé par un jalon (SPEM).
Plan type
C’est un Guide, qui fournit un document générique à un format standard pour un Produit de
travail particulier.
Processus
Un Processus consiste en la description complète d'une méthodologie appliquée à
l'ingénierie du logiciel, en termes de Rôles, de Définition de Travail, fourniture de produits
de travail ou Artéfacts et de Guides associés (SPEM).
Produit de travail
Un produit de travail est un constituant informatif ou une entité physique (document, modèle
UML, code exécutable, plan,...) produite ou utilisée par une Activité du processus
d'ingénierie du logiciel (SPEM). Appelé Artifact dans le RUP
Rôle de processus
Un rôle de processus est un Elément du Modèle qui décrit le propriétaire d'une Définition de
Travail. Un Rôle de Processus est utilisé pour des Définitions de Travail qui ne peuvent pas
être associées avec un Exécutant de processus, telles que le Cycle de Vie ou la Phase
aubryConseil – Stage Olivier Denizon
49
(SPEM).
Comparatif du vocabulaire utilisé
On présente ci-dessous, à partir du standard SPEM, les termes utilisés par la version 2001 du RUP,
ainsi que ceux des standards ISO et IEEE sur les processus, puis la traduction française proposée.
SPEM ParticipantR
ole
Activity
Step
WorkProduct
Discipline Lifecycle Phase Iteration Guidance
Rational
Unified
Process
Role Activity
Step
Artifact Discipline Process Phase Iteration Guidelines
IEEE 1074-
1997
Activity Product Activity
group
Lifecycle
process
Phase
ISO/IEC
12207
Role Task Product Process Lifecycle
model
En français Rôle Activité
Etape
Produit de
travail Discipline Cycle de
vie
Phase Itération Guide
Traduction du RUP au RUPS
RUP RUPS Commentaires
Artifact Produit de travail Par simplification on utilise
Produit dans le RUPS
Artifact Guideline Guide produit
Work guideline Guide méthode
Tool mentor Guide outil
Template Plan type
Workflow detail Groupe d'activités Une discipline contient des
morceaux (les détails de
discipline) qui contiennent des
activités
Checkpoints Points de contrôle
aubryConseil – Stage Olivier Denizon
50