Modélisation et réalisation d un processus d ingénierie du logiciel

Transcription

1 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 Etudiant : Olivier DENIZON Responsable entreprise : Claude AUBRY Responsable IUP ISI : 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. 2

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

4 Table des matières 1 Le sujet du stage Objectif Portée du projet Cible du processus Motivation personnelle pour le sujet Environnement du projet Présentation de la société Organisation du projet Processus du projet Mon rôle dans le projet Modélisation de processsus Méthode et processus Processus et Processus générique Intérêt d un modèle Standard de modélisation Modéliser avec UML SPEM l espoir d un standard Le meta-modèle SPEM Modelisation pour le projet Mon rôle dans la modélisation Principes et éléments du processus Bonnes pratiques d ingénierie Principes Adaptation au développement et à la maintenance Un processus a deux dimensions Cycle itératif et incrémental Phases Eléments du processus Rôle Activité Etapes Guides de travail Produits de travail Plan type Rapport Guides de produit et points de contrôle

5 4.3.9 Workflow Discipline Groupe d'activités Guides outils Concepts Travail personnel sur les principes et éléments Rational Process Workbench (RPW) Pourquoi le RPW? Présentation du RPW Composition du RPW Le modèle de processus Le modèle de composants La "Process Content Library" Travail personnel sur l outil Définition et réalisation du RUPS Gestion de projet Environnement Définition du processus Réalisation du processus Modèle Librairies Génération du site Le déploiement du processus Quelques chiffres Travail personnel sur le RUPS Un exemple d illustration du processus Objectif Contenu Travail personnel sur l exemple Bilans Le projet Le produit Le stage Annexes Bibliographie Glossaire

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. Evaluation du processus actuel Planifier l implémentation du processus - au niveau organisation Nouveau Processus Evaluer l implémentation du processus Procéder à l implémentation - Configurer le processus - Générer le processus (RPW) - Former les équipes 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 6

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

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 8

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 9

10 Itération 2 Itération 3 Itération 4 Itération 5 o évaluation du processus actuel o buts du nouveau processus o liste des risques o projet Web du RUPS en place 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 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 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 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é 10

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, 11

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 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 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 Le résultat est le SPEM (Software Process Engineering Metamodel). Nous faisons référence ici à la version ad diffusée le 2 avril 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. 12

13 Le glossaire fourni en annexe traduit et enrichit les définitions du SPEM 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 1 IsResponsibleFor 0..* WorkProduct 1 input 0..* output 0..* Performs Uses Produces 0..* 0..* Activity 0..* 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. 13

14 Méta-modèle de processus Modèle de processus Exécution de processus SPEM conforme à RUP adapté de RUPS guidé par RUPS mis en oeuvre 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. 14

15 Figure 6 Les rôles participant à une discipline 15

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 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 16

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

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

19 préparer l'environnement de développement du projet 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) 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). 19

20 décider si le logiciel, les sites et les utilisateurs sont prêts au déploiement de l'application 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 20

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 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 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 21

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 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 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 22

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 fi guides de travail 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 23

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

25 Un planning projet avec Excel. Une document Vision avec Word 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 RAPPORT Figure 15 Les différents formats de plans types du RUPS 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 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. 25

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" 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. 26

27 Figure 17 Diagramme d'activité de la discipline Gestion de Projet 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 27

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

29 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 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 29

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

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 : 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 31

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 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 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. Modèle conceptuel du RUP fourni en référence Modèle conceptuel du processus à réaliser Modèle physique du RUP fourni en référence Modèle physique du processus à réaliser Figure 22 Environnement de travail du RPW (add-in de Rational Rose) 32

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

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

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

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 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). Rôle hérité Héritage multiple impossible on attribue à l analyste système les mêmes responsabilités que le «use case specifier» Rôle défini dans le modèle RUP Figure 23 Illustration de l héritage et de la fusion de rôles 36

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). Activités supprimées Activités héritées et redéfinies Activité héritée 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 : 37

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

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 : Espace de travail du RPW Mémoire Modèle de processus du RUP PCL RUP dupliqué et francisé Eléments PCL RUP francisée hérités du RUP dépendance nouvelle association Description des éléments hérités non redéfinis (rôles, activités, outils, guides outils) Modèle de processus du RUPS PCL RUPS Eléments créés ou hérités et redéfinis éléments nouveaux ou redéfinis, traduits ou non traduits Figure 27 Schéma décrivant les associations du modèle aux 2 librairies 39

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" GENERATION DU SITE Cette partie a nécessité environ 0,75 Homme mois. Elle inclut les vérifications faites par le RPW sur 40

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 57 répartis sur les 9 disciplines 18 répartis sur les 4 disciplines réalisées (workflow details) 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 : 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 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 Espace disque requis 32,8 Mo 16,5 Mo Autres 1 projet web exemple d application du RUPS (voir chapitre suivant) 41

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 sousensemble 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 ) 42

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 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 : 43

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

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

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 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 46

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 47

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 48

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 Activity WorkProduct Discipline Lifecycle Phase Iteration Guidance ole Step Rational Role Activity Artifact Discipline Process Phase Iteration Guidelines Unified Step Process IEEE Activity Product Activity Lifecycle Phase 1997 group process ISO/IEC Role Task Product Process Lifecycle model En français Rôle Activité Produit de Discipline Cycle de Phase Itération Guide Etape travail vie Traduction du RUP au RUPS RUP RUPS Commentaires Artifact Produit de travail Par simplification on utilise Produit dans le RUPS Artifact Guideline Work guideline Tool mentor Template Guide produit Guide méthode Guide outil 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 49

50 50