Modélisation et réalisation d’un processus d’ingénierie …yasr2002.free.fr/e/gl/glrapport-rup.pdf · Ces dernières années, les processus modernes liés à UML, et particulièrement

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.


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.


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


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


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


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.


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


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


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é…


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,


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.


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.


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


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



15

Figure 6 Les rôles participant à une discipline


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


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.


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é).


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).


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


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


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


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


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.


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.


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.


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


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é.


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


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.


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


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


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)


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).


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.


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 »


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


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.


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)


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


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)


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…)


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 :


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.


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.


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


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


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


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


50

Documents

Modélisation et réalisation d’un processus d’ingénierie …yasr2002.free.fr/e/gl/glrapport-rup.pdf · Ces dernières années, les processus modernes liés à UML, et particulièrement