Tâche: Personnaliser le processus de développement pour le projet
Cette tâche explique comment personnaliser un processus de développement afin qu'il réponde aux besoins spécifiques du projet.
Disciplines: Environnement
Objet

Objectifs de cette tâche :

  • Ajuster le processus de développement logiciel aux besoins spécifiques du projet.
  • Mettre à la disposition des participants au projet suffisamment de conseils pertinents concernant le processus afin qu'ils puissent fournir un travail efficace et de qualité acceptable.
  • Fournir une description pertinente et accessible du processus aux participants au projet.
Relations
Description principale

Les tâches suivantes fournissent des informations sur le développement d'actifs de méthode spécifiques au projet. Elles sont effectuées conjointement avec les étapes de développement de méthode de cette tâche :

Lors de l'utilisation d'un plan de développement,  la Tâche : Création du plan de développement est effectuée conjointement avec cette tâche de personnalisation.

Etapes
Analyse du projet
Objet :  Comprendre le problème posé, et les ressources disponibles pour le projet.

Pour assurer le succès du projet, le processus de livraison doit absolument être pertinent pour le projet en question et adapté à ses exigences en terme de taille et de formalisme. Un processus trop marqué entrave souvent la créativité et  l'efficacité. Un processus pas assez marqué peut entraîner une situation chaotique, poussant par exemple des membres individuels du projet à prendre des décisions locales pouvant avoir des résultats peu efficaces, incohérents et imprévisibles.

Définition de la portée de l'effort de personnalisation
Objet :  Définir les domaines de processus à traiter lors du processus personnalisé selon le projet.

Les résultats de l'analyse des ressources du projet et de leur expérience dans des projets de développement logiciel similaires aident à identifier l'ampleur du travail d'adaptation. Un processus personnalisé selon le projet ne contient pas obligatoirement toutes les disciplines de RUP, et, à priori, il n'est pas non plus nécessaire de traiter tous les rôles définis dans RUP. Il faut garder à l'esprit le fait que RUP est un cadre de processus adapté à une large gamme de types de projets, et qu'il sera donc trop vaste pour un projet spécifique. La sélection des domaines devant être traités dans le processus du projet dépend fortement des compétences réelles des différents participants au projet et de la nature du projet en question. Vous trouverez ci-dessous certains des éléments à prendre en compte lorsque vous définissez la portée du travail d'adaptation.

  • Domaines dans lesquels les membres du projet possèdent déjà une méthode de travail commune, où il n'est pas nécessaire d'introduire un nouveau processus ou des outils. Par exemple, s'ils savent effectuer des tests, il serait judicieux de ne pas présenter la discipline test de RUP afin de limiter le nombre de nouveaux éléments. Vous pouvez vous concentrer sur certaines fonctions de RUP, afin de résoudre les problèmes de leur processus existant.  Pour plus d'informations, voir le Concept : Implémentation d'un processus dans un projet, section Amélioration du processus et des outils
  • Domaines (disciplines) dans lesquels le projet doit présenter un nouveau processus et de nouveaux outils, car il n'existe aucune méthode de travail existante. Dans certains cas il n'y a pas de processus ni d'outils existants sur lesquels se baser, et il est nécessaire de présenter l'essentiel du programme RUP, ainsi que ses outils de support. Pour plus d'informations, voir le Concept : Implémentation d'un processus dans un projet, section Tout changer
  • Problèmes dans le processus existant. Se concentrer sur l'amélioration de domaines dans lesquels l'entreprise a eu des problèmes.
  • Quels outils utiliser ? Si le projet requiert l'utilisation de certains outils, le processus de développement devrait traiter les domaines correspondants de RUP.
  • La capacité de changement du projet. Lorsque l'on traite les problèmes de l'entreprise, on a tendance à essayer de régler tous les problèmes à la fois, d'autant que beaucoup de ces problèmes ont lieu simultanément. Il s'agit d'un piège souvent fatal. Comme les personnes, les entreprises peuvent s'adapter au changement mais seulement dans une certaine mesure. Si la capacité de changement est faible, vous devrez aller plus lentement, et peut-être vous contenter de présenter une ou deux disciplines de RUP lors du premier projet.
  • Domaines dans lesquels les membres du projet manquent de connaissance, ou sont faibles. Confier le traitement de ces domaines au processus de développement. S'assurer qu'il est facile de trouver l'information souhaitée dans RUP.

Pour plus d'informations sur la définition de la portée de l'effort de personnalisation, voir les Instructions : Personnalisation de RUP

Pour obtenir une description des facteurs ayant une influence sur la personnalisation d'un processus pour un projet, voir les Instructions : Discriminants de processus.

Les domaines d'amélioration identifiés ne doivent pas obligatoirement être présentés pour la première fois dans le même projet. Réduire le nombre de facteurs inconnus et s'intéresser aux domaines dans lesquels l'entreprise de développement a eu le plus de mal dans le passé. Il est conseillé d'implémenter RUP de manière itérative, comme indiqué dans le Concept : Implémentation d'un processus dans un projet. Pour les petits projets, des conseils sont également à disposition dans l'Exemple : Adoption de RUP par un petit projet.

Bien qu'il puisse exister des besoins d'amélioration dans plusieurs disciplines, considérer l'option de les présenter de façon itérative lors de plusieurs projets, plutôt que de choisir une approche visant à tout changer en même temps. Un exemple de ce type de compromis consiste à présenter les exigences avec les cas d'utilisation et à retarder la présentation d'un nouveau processus de gestion de la configuration, si les projets préalables ont rencontré des problèmes d'exigences obscures et/ou insuffisantes ou si si de nombreux utilisateurs se sont déclarés peu satisfaits par le produit livré.

Les compromis effectués et la portée en résultant doivent être documentées en tant que partie du processus afin de communiquer aux parties prenantes externes les décisions relatives à la portée.

Développement du contenu spécifique au projet
Objet :  Créer de nouvelles "compétences de processus" dans les domaines pour lesquels la couverture de l'infrastructure RUP est jugée insuffisante pour le projet.

L'infrastructure de méthode RUP se manifeste dans un modèle de processus défini au moyen d'un métamodèle UML. Cette infrastructure est fondée sur un métamodèle appelé "Unified Method Architecture" (UMA). Les notions de base de l'UMA sont décrites dans le  Concept : Principales fonctions de l'architecture UMA

Vous pouvez étendre l'infrastructure RUP en ajoutant des rôles, des tâches et/ou des produits ou bien encore en ajoutant des conseils spécifiques au projet à l'infrastructure RUP existante.  

Dans le cadre de tout processus personnalisé selon le projet, une série de ressources disponibles adaptée doit fournir une aide spécifique et un matériel de référence visant à faciliter la production des artefacts. Des exemples de ces ressources sont :

  • Instructions communes pour la production de certains artefacts.
  • Modèles personnalisés pour être utilisés dans plusieurs projets. Ils seront partiellement instanciés avec les informations du projet.
  • Exemples d'artefacts pertinents par rapport à l'ensemble de livrables et à la technologie choisis pour le projet.
  • Actifs réutilisables, tels que des patterns de conception et des bibliothèques de codes.

Au début du projet, le responsable de projet travaille généralement avec l'responsable de processus pour sélectionner la série de ressources adaptée, et les rendre disponible aux membres du projet dans le cadre du processus personnalisé selon le projet. Le besoin en ressources additionnelles est réévalué au début de chaque itération.

Configuration du processus
Objet :  Ajuster le processus afin qu'il réponde parfaitement aux besoins d'un projet.

La configuration d'un processus implique de sélectionner le contenu de méthode (produits, tâches, rôles, etc.) devant être inclus dans le processus.  Pour obtenir des recommandations spécifiques sur les éléments de méthode à inclure pour chaque discipline, voir les instructions relatives aux "décisions clés dans <nom de la discipline>" fournies pour chacune des disciplines de RUP. La sélection de l'ensemble de contenu de méthode approprié pour le projet en question n'est pas une tâche négligeable. Pour être efficace, le processus doit être pertinent et adapté selon plusieurs caractéristiques, comme l'ampleur du projet (ressources et durée), le formalisme, les plates-formes technologiques, le domaine, etc.

Pour plus d'informations sur le système de classification permettant de déterminer l'importance de produits spécifiques et de décider s'ils seront utilisés, voir les Instructions : Classification des produits.

Définition du modèle de cycle de vie du projet
Objet :  Définir le modèle de cycle de vie du projet.

Une étape importante de la personnalisation d'un processus pour un projet consiste à choisir un modèle de cycle de vie pour le projet, y compris la répartition en phases et itérations. A ce stade, le responsable de processus doit travailler en étroite collaboration avec le responsable de projet car le modèle de cycle de vie choisi pose les bases du processus de planification du projet. Selon la nature du projet, il peut s'avérer nécessaire d'ajuster le cycle de vie RUP pour mieux répondre aux besoins spécifiques. Par exemple, le développement d'un nouveau projet exige généralement plus d'efforts en phase de création qu'un projet de maintenance. Ainsi, la description du cycle de vie doit être ajustée selon la nature du projet. Voir Concepts : Itérations pour une discussion sur les différents types de modèles de cycle de vie.

Une fois le modèle général de cycle de vie sélectionné, il est également important de décider de la façon d'exécuter les enchaînements d'activités associés à chaque discipline incluse dans l'effort de personnalisation, ainsi que de déterminer le moment du cycle de vie du projet où il sera judicieux de présenter les différentes parties de l'enchaînement d'activités des disciplines.  Choisir une méthode d'exécution de l'enchaînement d'activités implique de déterminer les activités à exécuter et l'ordre d'exécution.  Choisir le moment où les différentes parties de l'enchaînement d'activités seront exécutées implique de déterminer quand, dans le cycle de vie, (par exemple, à quelle phase) présenter les activités sélectionnées. Pour plus d'informations sur la personnalisation de l'enchaînement d'activités pour chaque discipline RUP, voir les notes d'utilisation des enchaînements d'activités de référence fournies pour chacune de ces disciplines.

A ce stade, vous pouvez également définir les exigences en termes de rythme et de formalisme des produits à différents moments du cycle de vie. Par exemple, la phase au cours de laquelle un produit est créé et/ou mise à jour et le niveau de formalisme requis pour le produit (par exemple, le client doit-il clôturer la session?).

Mise à disposition du processus pour les participants au projet
Objet :  Rendre le processus personnalisé disponible aux membres du projet.

Une fois la personnalisation initiale effectuée, le processus en résultant doit être mis à la disposition de l'équipe projet sous un format exploitable.

Une solution consiste à rendre le processus accessible via un site Web qui peut résider sur un serveur Web du réseau de l'organisation ou être installé sur l'ordinateur de chaque participant. Si les participants au projet sont connectés au réseau pratiquement en permanence, il est recommandé d'effectuer un déploiement sur un serveur Web afin d'éviter toute surcharge liée aux mises à jour du processus au cours du cycle de vie du projet.

Maintenance du processus

Bien que l'essentiel du travail d'adaptation soit effectué au début du projet, il doit être fréquemment mis à jour, à mesure que l'équipe du projet rencontre des obstacles et d'autres problèmes liés au processus.  Tout au long du déploiement du processus, des leçons peuvent être tirées, qui permettront ensuite au responsable de processus d'améliorer le processus à partir de ces retours d'informations. Les évaluations réalisées pendant le projet sont également des données importantes dans une optique d'amélioration du processus.

Les changements mineurs sont généralement gérés par l'équipe projet, et le processus personnalisé est mis à jour régulièrement afin de préparer l'environnement de développement de la prochaine itération.  Ces améliorations du processus entraîneront souvent des mises à jour du processus spécifique au projet (par exemple, amélioration des canevas et instructions liés au produit).  Les problèmes plus complexes sont traités par le biais de demandes de changement. 

Un des avantages principaux du développement itératif est de permettre aux équipes d'améliorer progressivement leur méthode de développement logiciel. Nous recommandons que tout projet comporte des micro-cycles d'ingénierie de processus comportant les étapes suivantes :

  • Définir le processus
  • Effectuer les tâches en fonction du processus défini
  • Evaluer votre travail
  • Affiner le processus


Illustrations
Considérations clés

Quel que soit le niveau de personnalisation , il convient d'enregistrer les résultats (et si possible la logique) de l'effort de personnalisation.  De plus, s'il est prévu de procéder ultérieurement à une nouvelle personnalisation du processus en cours de personnalisation (par exemple, le processus est personnalisé pour une organisation dans son ensemble et le processus organisationnel qui en résulte doit être de nouveau personnalisé pour chaque projet), il est également essentiel d'établir des instructions expliquant comment procéder à la personnalisation d'un processus de développement déjà personnalisé. Les décisions et recommandations relatives à la personnalisation peuvent être enregistrées dans un document indépendant ou faire partie intégrante du processus de développement.  Pour plus d'informations sur les niveaux de personnalisation, voir le Concept : Personnalisation de RUP.

Le plan de développement logiciel et l'organisation influent fortement sur le processus de développement, et inversement. La personnalisation du processus et le développement du planning de projet doivent s'effectuer de manière coordonnée. Par exemple, si le projet doit utiliser un ensemble de phases différent de celui défini dans RUP (Rational Unified Process), cela doit être enregistré dans le processus de développement personnalisé.  De plus, une fois la personnalisation du processus de développement effectuée, il convient de procéder à son instanciation en planning de projet susceptible d'être promulgué. Pour plus d'informations sur la planification de projet, voir la Tâche : Planifier les phases et les itérations et la Tâche : Développer un plan d'itération.


Il est conseillé de ne pas personnaliser immédiatement le processus dans son ensemble.  Mettez plutôt l'accent sur la prochaine discipline devant être appliquée dans le projet.  Pour plus d'informations sur la méthode itérative appliquée à l'implémentation de processus, voir le Concept : Implémentation d'un processus dans un projet

Une évaluation de l'organisation de développement, si elle est disponible, indique les domaines sur lesquels l'organisation dans son ensemble doit se concentrer. Une décision éclairée doit être prise afin de savoir quels domaines d'amélioration identifiés peuvent être ciblés pour le projet. Cette décision affecte directement la portée de l'effort de personnalisation.

La personnalisation du processus pour un projet doit être considérée comme un projet en tant que tel, avec des plans, un budget et des mécanismes de contrôle séparés. Vous devez lui définir une étude de rentabilité, basée sur une analyse du retour sur investissement. Le développement du plug-in sera favorisé par le suivi du cycle de vie et des disciplines de RUP. Nous vous recommandons d'effectuer un essai des principales caractéristiques du plug-in sur un véritable projet avant de commencer à développer le plug-in.

Un plan de développement peut être utilisé pour documenter les décisions de personnalisation (par exemple, quelles parties du processus RUP ont été personnalisées et pourquoi), ainsi que les instructions pour les futurs efforts de personnalisation. Selon le niveau de personnalisation réalisé, le plan de développement peut faire partie intégrante du processus de développement  ou servir uniquement à planifier, guider et documenter l'effort de personnalisation. Pour plus d'informations sur les niveaux de personnalisation, voir Concept : Personnalisation de RUP.

Alternatives
Il existe différents niveaux de personnalisation dans RUP.  Pour plus d'informations, voir le Concept : Personnalisation de RUP.
Plus d'informations