Exemple: Un petit projet adopte le RUP
Cet exemple décrit un scénario dans lequel un petit projet a décidé d'adopter le processus RUP.
Relations
Description
Description principale

Pour obtenir plus d'informations sur la personnalisation du processus RUP pour un petit projet, voir Concept : Personnalisation d'un processus pour un petit projet.  Pour obtenir plus d'informations sur la personnalisation du processus RUP en général, voir Concept : Personnalisation du processus RUP.

Présentation du projet

Le scénario suivant décrit un projet de l'entreprise ABC, appelé Projet X. Le projet X dispose d'une équipe composée d'une responsable de projet, Jeanne, et de quatre programmeurs, Antoine, David, Susanne et Philippe.  La durée du projet est de quatre mois. 

Jeanne envisage d'utiliser RUP comme base pour le processus de développement logiciel de son projet. Elle installe RUP, qui installe par défaut la configuration de processus "Classic RUP". Ensuite, elle examine les éléments de Classic RUP pertinents du point de vue de la personnalisation d'un processus pour un projet.

Elle commence alors par évaluer, en consultation avec l'équipe, les besoins de son projet en matière de processus et en tire les conclusions suivantes :

  • Le processus et les outils existants pour la gestion de la configuration fonctionnent bien ; ils peuvent donc rester en l'état.
  • L'équipe possède une certaine expérience en matière de cas d'utilisation et d'architectures de composants, mais elle pourrait utiliser plus de conseils dans ces domaines.
  • Le projet tirerait profit d'une approche de développement itérative, qui permettrait de mieux gérer les risques.
  • Les parties prenantes entretiennent de bonnes relations de travail informelles avec l'équipe de développement et il n'est pas nécessaire d'effectuer des contrats ou revues formels. Elles ont une visibilité continue tout au long du développement.  De son côté, l'équipe est extrêmement compétente et disciplinée, et a montré par le passé sa capacité à réaliser des produits de qualité sans suivre un processus très formel.
  • Vu la brièveté des délais, l'ensemble d'outils ne subira que des changements mineurs.
  • Une activité parallèle distincte sera mise en oeuvre pour enquêter sur les avantages des outils et sur les possibilités de réutilisation, et pour repréciser le processus en vue de futurs projets.

Ensuite, Jeanne se charge de personnaliser un processus approprié que l'équipe devra suivre.

Personnalisation générale

Regroupement des actifs spécifiques au projet dans un plug-in

Le processus RUP existant est raisonnablement proche des besoins du projet, mais il ne l'est pas encore assez. Jeanne précise le projet en créant un plug-in spécifique au projet qui contient les actifs applicables spécifiques au projet.

Concrètement, elle lance le Rational Method Composer (RMC) et crée un nouveau plug-in de méthode qui contient :

  • des instructions pour les outils à utiliser sur le projet
  • des instructions réutilisées provenant d'un projet antérieur semblable, y compris des principes de conception et des instructions relatives à la gestion de la configuration et des changements
  • des instructions pour la revue et l'évaluation.

Après quoi, elle associe ces conseils aux éléments de méthode RUP appropriés et précise les vues de processus existantes pour y inclure ces conseils.

En outre, elle ajoute à la vue RUP Mise en route une page intitulée "Présentation du processus du projet X", où elle décrit la philosophie fondamentale du processus configuré. Par exemple, elle indique que les canevas inclus sont destinés à guider le contenu, mais que leur format est facultatif. Elle précise par ailleurs l'emplacement où se trouveront les versions en cours des produits clés du projet.

Pour plus d'informations sur la création d'un plug-in de méthode à l'aide du RMC, voir Guide d'utilisation de l'outil : Création d'un plug-in de méthode avec Rational Method Composer.  Pour plus d'informations sur l'ajout d'un contenu dans ce plug-in, voir Guide d'utilisation de l'outil : Développement d'un contenu de méthode avec Rational Method Composer.

Définition d'une configuration spécifique au processus et publication

Après avoir regroupé les actifs spécifiques au projet dans un plug-in, Jeanne peut développer une configuration RUP qui inclut le plug-in spécifique au projet.

Jeanne lance le Rational Method Composer (RMC) et sélectionne comme base une configuration pour petit projet. Elle copie cette configuration vers une nouvelle configuration qu'elle nomme "Projet X de ABC". 

Après quoi, elle ouvre la nouvelle configuration, puis sélectionne et désélectionne quelques packages et plug-ins de méthode pour profiler la configuration souhaitée.  Par exemple, elle désélectionne le package de méthode "Conception de la base de données", l'équipe n'ayant pas l'intention d'effectuer une modélisation de données sur ce projet, et elle sélectionne le plug-in spécifique au projet créé précédemment.

Ensuite, Jeanne crée un nouveau processus de livraison dans son plug-in de méthode à partir du processus de livraison fourni dans la configuration Small Project.  Elle édite ce nouveau processus de livraison en ajoutant certaines phases à chaque tâche et en en supprimant d'autres. Après quoi, elle publie les résultats.

Pour plus d'informations sur le développement de processus à l'aide du RMC, voir Guide d'utilisation de l'outil : Développement de processus avec Rational Method Composer.  Pour plus d'informations sur la publication de processus à l'aide du RMC, voir le  guide d'utilisation de l'outil : Publication d'une configuration de méthode à l'aide du RMC (Rational Method Composer).

Rôles et cycle de vie

Le projet X dispose d'une petite équipe ; chaque personne joue donc un éventail de rôles RUP. Jeanne décrit les responsabilités de chacun dans le plan de développement logiciel. Par exemple, sur le projet X, Jeanne joue elle-même les rôles de responsable de projet et de responsable de processus.

Revue

Jeanne soumet pour revue une ébauche du processus RUP configuré et le plan de développement logiciel à l'équipe et aux autres parties prenantes. L'équipe commence à suivre le processus. Des erreurs sont commises, le processus est précisé. Finalement, le projet est une réussite et l'équipe dispose d'un processus optimisé approprié qui est applicable aux projets à venir.