Modélisation et réalisation d’un processus d’ingénierie du logiciel
Adaptation et simplification du RUP
R APPORT DE S TAGE DE TROISIEME ANNEE AVRIL - SEPTEMBRE 2001
www.aubryconseil.com
Etudiant : Responsable entreprise :
Responsable IUP ISI :
Olivier DENIZON Claude AUBRY Henri MASSIE
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 "P rocess 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
Nouveau Processus
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 équipes
Evaluer
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
1 0..*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 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
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 la22
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 le s 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.
