• Aucun résultat trouvé

UN EXEMPLE D’ILLUSTRATION DU PROCESSUS

Rôles 31 répartis en 5 catégories 9 (tous hérités) répartis en 3 catégories

7 UN EXEMPLE D’ILLUSTRATION DU PROCESSUS

7.1 OBJECTIF

Un exemple a été développé à partir des projets qui se sont terminés en mars 2001. Le sujet est un système de gestion des stages. Il se présente sous la forme d’un projet web intitulé EASYSTAGE. Ce projet web est une simulation de suivi de projet, destinée à fournir un exemple de mise en application d'un processus de développement.

Il présente des documents conformes aux plans types contenus dans le site du processus implémenté et permet ainsi aux lecteurs d’avoir une bonne illustration des résultats attendus lors de leur mise en application du processus pour leur projet.

Figure 28 Capture écran du site projet EasyStage

7.2 CONTENU

Ce site contient actuellement l’expression des besoins du client et les produits de la discipline d’Expression des exigences :

- le glossaire, - le document vision,

- le modèle des cas d’utilisation avec les spécifications détaillées de 6 cas d’utilisation. Le modèle produit à partir de Rose avec le Web Publisher est accessible.

- les spécifications supplémentaires.

7.3 TRAVAIL PERSONNEL SUR L’EXEMPLE

Dès le début du stage nous avions comme objectif de réaliser 3 sites : le processus lui-même, un site d’avancement du projet et un site exemple, permettant de constater la mise en application du processus sur un projet. J’ai personnellement participé à la réalisation du site exemple en :

44

- créant l’architecture du site (treebrowser…) et sa présentation (logo, style), - rédigeant la page de bienvenue sur le site

- étudiant les projets de logiciels de gestion de stages existants - rédigeant une première version du glossaire

- rédigeant des premières versions des documents de travail de l’expression des exigences : vision, spécifications supplémentaires

- créant la première version du modèle des cas d’utilisation.

45 8 BILANS

8.1 LE PROJET

Il ne s’achèvera qu’en fin septembre au lieu de fin août. Cependant on peut déjà constater que l’apprentissage du RPW et du RUP prend beaucoup temps la première fois.

La modélisation oblige à une réflexion très poussée, et nous pensons qu’il est préférable de bien faire une partie plutôt que d’essayer de définir un processus complet dès la première fois. Procéder par composants de processus, par exemple les disciplines, paraît une bonne approche pour réaliser et déployer des nouvelles pratiques dans les organisations. C’est ce que nous avons décidé en cours de projet en nous consacrant uniquement à 4 disciplines.

8.2 LE PRODUIT

Le déploiement du RUPS va commencer avec la formation et se poursuivra par l’utilisation du nouveau processus sur les projets de Bureaux d’Etudes à partir d’octobre 2001.

8.3 LE STAGE

Ce stage m’a permis, après avoir travaillé pour des PME, des grands comptes et des start-up de me familiariser avec un nouveau type de structure.

Ce travail en collaboration avec Claude AUBRY m’a conduit à faire preuve d’initiative et de rigueur dans mon travail, favorisant la communication (échange fréquent de mails, coups de téléphone…).

L’organisation du travail fonctionnait très bien avec des points d’avancement quasi hebdomadaires, et des réunions d’avancement avec des intervenants extérieurs (enseignants, Rational).

L’apprentissage du RPW, point essentiel de ce stage, a été sans doute plus complexe que nous l’avions imaginé mais je crois pouvoir dire que désormais nous maîtrisons très bien cet outil, ce qui est une grande fierté.

Cette utilisation du RPW a nécessité de porter une grande attention à la gestion de configuration en particulier lorsque l’on veut travailler simultanément sur le site du processus.

46 9 ANNEXES

9.1 BIBLIOGRAPHIE

Livres :

o The Rational Unified Process An Introduction, Second Edition de Philippe KRUCHTEN

édition ADDISON -WESLEY Object Technology Series http://www.aw.com/cseng/otseries

NB : Ce livre existe aussi en français chez Eyrolles, mais la traduction porte sur la première édition.

Articles :

o SPEM

Rapport du groupe de travail de l'OMG sur les processus de développement de logiciel qui définit le méta-modèle SPEM (Software Process Engineering Metamodel)

o iterative development

Un article de Philippe Kruchten sur les pièges du développement itératif.

Supports de cours Rational :

o Les fondamentaux du RUP

o Implémenter le RUP

9.2 GLOSSAIRE

Ce glossaire s'appuie sur celui fourni (en anglais) avec la version d’avril 2001 du SPEM . On rappelle que le SPEM définit le standard de représentation des processus. Un tableau comparatif montre les différences entre ce vocabulaire, celui utilisé dans le RUP et dans les standards ISO et IEEE.

Activité

Définition d'un travail décrivant ce qui est produit dans la cadre d'un Rôle . Les activités sont l'élément principal d'un travail (SPEM).

Composant de Processus

Un Composant de Processus est un regroupement cohérent d'Eléments de Modèle organisés de façon à obtenir une perspective intéressante, telle que la Discipline, par exemple le test, ou la production de certains Produits de travail, par exemple la gestion des exigences (SPEM).

Cycle

47

Un passage complet par les phases du cycle de vie (RUP).

Cycle de vie

Un cycle de vie pour un processus est défini comme une séquence de phases pour accomplir un but précis. Le cycle de vie définit le processus qui sera appliqué sur un projet donné (RUP).

Définition de travail

C'est un Elément de Modèle d'un processus qui décrit l'exécution, les opérations réalisées, et les transformations opérées sur les produits de travail dans le cadre d'un Rôle. Parmi les définitions de travail on trouve les Activités, les Itérations, les Phases et le cycle de vie (SPEM).

Dépendance

Une dépendance est une relation particulière, spécifique au processus, qui lie entre eux des Eléments de Modèle (SPEM).

Discipline

Une discipline est une unité du processus, organisée selon une perspective caractéristique de l'ingénierie du logiciel : Gestion de Configuration, Analyse et Conception, Gestion de Projet, etc (SPEM).

Elément de Modèle

C'est un élément qui décrit un aspect d'un processus (SPEM).

Etape

Une étape est une Définition de travail atomique, à grain fin, utilisée pour décomposer des Activités . Les Activités sont des ensembles d'étapes, partiellement ordonnées (SPEM).

Exécutant de processus

Elément du modèle qui décrit les rôles, les responsabilités et compétences d'un individu fournissant des Activités au sein du Processus, et responsable de certains produits de travail (SPEM).

Guide

Le Guide est un Elément de Modèle associé aux éléments principaux de définition de processus, qui contient des descriptions supplémentaires telles que des techniques, des méthodes, des profils UML, des procédures, des standards, des plans types de fournitures, des exemples de produits de travail , des définitions, etc (SPEM).

Guide de produit

48

C’est un Guide associé à un produit, qui fournit des règles et des recommandations pratiques sur la façon de créer et d’organiser le produit.

Guide de travail

C’est un Guide associé à une activité, qui fournit des techniques utiles pour la réalisation de l’activité (RUP).

Guide outil

C’est un Guide qui fournit une description détaillée sur la façon de réaliser une activité ou des étapes de l’activité, avec l’aide d’un outil.

Itération

Une Itération est une définition de travail, à gros grain, qui représente un ensemble d'Activités, visant au développement d'une portion du système, et qui s'achève par la fourniture (interne ou externe) d'un produit logiciel (SPEM).

Liste de contrôle

C’est un Guide qui contient une liste de points à contrôler pour évaluer la qualité d’un produit de travail (RUP).

Phase

Définition d'un travail à haut niveau, parachevé par un jalon (SPEM).

Plan type

C’est un Guide, qui fournit un document générique à un format standard pour un Produit de travail particulier.

Processus

Un Processus consiste en la description complète d'une méthodologie appliquée à l'ingénierie du logiciel, en termes de Rôles, de Définition de Travail, fourniture de produits de travail ou Artéfacts et de Guides associés (SPEM).

Produit de travail

Un produit de travail est un constituant informatif ou une entité physique (document, modèle UML, code exécutable, plan,...) produite ou utilisée par une Activité du processus d'ingénierie du logiciel (SPEM). Appelé Artifact dans le RUP

Rôle de processus Un rôle de processus est un Elément du Modèle qui décrit le propriétaire d'une Définition de Travail. Un Rôle de Processus est utilisé pour des Définitions de Travail qui ne peuvent pas être associées avec un Exécutant de processus, telles que le Cycle de Vie ou la Phase

49 (SPEM).

Documents relatifs