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.

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

Dans le document Modélisation et réalisation d un processus d ingénierie du logiciel (Page 35-41)