Objet
  • Ajuster le processus de développement logiciel selon les besoins spécifiques du projet
  • Fournir une description de processus pertinente et accessible aux membres du projet
Rôle :  Ingénieur processus 
Fréquence : L'essentiel du travail se déroule au début du projet. A répéter si nécessaire dans toute itération
Etapes
Artefacts d'entrée :  Artefacts de sortie : 
Guides d'utilisation de l'outil : 
Plus d'informations : 

Détails sur l'enchaînement des activités : 

Analyser le projet Haut de la page

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

Pour assurer le succès du projet, le processus de développement doit absolument être pertinent pour le projet concerné, et être adapté à son ampleur et au formalisme requis. 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.

L'organisation du processus varie énormément selon les entreprises de développement. Certaines sont très mûres dans ce domaine, et possèdent des groupes de processus chargés de la définition et de l'amélioration du processus de développement de l'ensemble de l'entreprise. D'autres entreprises utilisent seulement des processus adaptés aux projets. Ces projets débutent généralement par une des configurations pré-définies incluses dans le produit RUP, le processus est ensuite instancié pour chaque projet. La méthode choisie pour adapter le processus au projet dépend de plusieurs facteurs, par exemple :

  • La maturité du processus de l'entreprise de développement.
  • L'ampleur du projet en termes de durée et du nombre de ressources de développement.
  • L'expérience préalable des membres du projet avec des processus similaires.
  • Le formalisme requis par le projet.

Voir Principes et conseils : Discriminants du processus pour plus d'informations.

Définir la portée du processus Haut de la page

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. Les domaines choisis pour être traités dans le processus dépendent dans une large mesure des compétences existantes des membres du projet et de la nature du projet concerné. 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.  Voir ../workflow/environm/co_iproj.htm#Improving Process and Tools -- This hyperlink in not present in this generated websiteConcepts : Implémenter un processus dans un projet, section "Améliorer les processus et les outils ", pour plus d'informations. 
  • 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. Voir ../workflow/environm/co_iproj.htm#Change Everything -- This hyperlink in not present in this generated websiteConcepts : Implémenter un processus dans un projet, section "Tout modifier", pour plus d'informations. 
  • 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.

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é. Nous vous recommandons d'implémenter RUP de façon itérative, comme cela est décrit dans la section ../workflow/environm/co_iproj.htm -- This hyperlink in not present in this generated websiteConcepts : Implémenter un processus dans un 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 connu des problèmes d'exigences obscures et/ou insuffisantes, ou si de nombreux utilisateurs se sont déclarés peu satisfaits par le produit livré.

Les compromis doivent être consignés afin de communiquer les décisions concernant la portée du projet aux parties prenantes externes. Lors de la définition de la configuration de RUP Builder, ces décisions peuvent être consignées en tant que description de la configuration et apparaîtront ainsi sur le site Web publié.

Etendre le cadre du processus (facultatif) Haut de la page

Objet :  Ajouter d'autres compétences au processus spécifique au projet, dans des domaines où la couverture de la structure RUP est considérée insuffisante pour le projet.

L'une des forces de la structure RUP est son applicabilité à une large gamme de projets et d'environnements. Mais cela peut être également considéré comme un inconvénient, car la description du processus devient ainsi quelque peu générique. La technologie de plug-in de RUP est conçue pour surmonter certains de ces problèmes en permettant aux fournisseurs d'outils ou de technologies et aux entreprises individuelles de créer des descriptions de processus plus spécifiques par le biais de plug-ins. Vous trouverez une liste mise à jour des plug-ins disponibles au téléchargement dans la section RUP section de developerWorks : Rational.

Le produit ../res_processworkbench.htm -- This hyperlink in not present in this generated websiteRational Process Workbench (RPW) permet de créer des extensions RUP en utilisant la technologie plug-in de RUP. Suivant les recommandations pour cette technologie, la structure RUP peut être étendue de deux manières. Vous pouvez créer un plug-in structurel afin d'étendre le modèle de processus RUP, ou créer des extensions permettant de fournir au projet les ressources réutilisables appropriées par le biais de plug-ins légers.

La création d'un plug-in RUP (structurel) doit être considérée comme un projet en tant que tel, avec des plans, un budget et des mécanismes de contrôles 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.

Voir ../workflow/environm/co_polpr.htm#Extend -- This hyperlink in not present in this generated websitePrincipes et conseils: Personnalisation RUP, section Etendre RUP, pour plus d'informations.

Configurer le processus Haut de la page

Objet :  Ajuster le processus pour répondre aux besoins exacts d'un projet.

La structure RUP est constituée d'une série de composants de processus et de plug-ins, chaque composant contenant une série d'éléments liés au processus. Pour créer une configuration RUP, vous devez choisir parmi une série de composants de processus. Sélectionner la série de composants adaptée pour un projet donné 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 la configuration RUP, voir

Préparer le processus pour le projetHaut de la page

Objet :  Définir comment le processus configuré est mis en application dans le projet.

Une description de processus configurée pour un projet n'est généralement pas assez détaillée pour être mise en application. Par exemple, le processus définit une série d'artefacts à utiliser selon une sélection de composants de processus pertinents (comme nous l'avons expliqué dans la section précédente Créer une configuration RUP), mais ne précise pas les exigences de planning et de formalisme des artefacts pour ce projet particulier. Les principes et conseils détaillés et les modèles d'artefacts partiellement instanciés sont aussi considérés comme partie prenante du processus personnalisé selon le projet. L'effort requis pour effectuer cette étape dépend en grande partie de la précision du processus configuré. Toute déviation par rapport au processus de base doit être justifiée et consignée en tant que partie du processus personnalisé selon le projet.

Sous-rubriques :

Définir une ventilation du cycle de vie Préparer le processus

L'instanciation du processus configuré comporte le choix d'un modèle de cycle de vie pour le projet, y compris la ventilation en phases et itérations. Pour cette partie du travail d'adaptation, l'ingénieur processus doit collaborer avec le chef de projet dans la mesure où le modèle de cycle de vie choisi posera 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.

Adapter les artefacts Haut de la page

Le processus configuré contient des descriptions des artefacts susceptibles d'être produits par le projet. Dans la mesure où la configuration est généralement définie pour correspondre à un certain type de projet, cette sélection doit être remise en question en tant que partie intégrante du processus d'instanciation. Ne prévoyez pas de produire un artefact si vous ne pouvez pas expliquer pourquoi vous en avez besoin. Les artefacts doivent être aussi accompagnés d'informations comme :

  • Dans quelle phase cet artefact sera créé ou mis à jour ?
  • Quel est le degré de formalisme nécessaire pour cet artefact (par exemple, le client doit-il le signer ?) ?
  • Quels outils doivent être utilisés pour le produire ?

Ces informations peuvent être consignées dans une feuille de calcul ou un document accessible à partir du site Web du processus, ou elles peuvent faire partie intégrante de la description du processus.

Préparer les ressources des artefacts Haut de la page

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 :

  • Principes et conseils communs pour la production de certains artefacts, par exemple principes et conseils pour la modélisation des cas d'utilisation.
  • 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 à la série de livrables et à la technologie choisie pour le projet.
  • Ressources réutilisables, comme les modèles de conception et les bibliothèques de code.

Au début du projet, le chef de projet travaille généralement avec l'ingénieur 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.

Présenter le processus aux membres du projet Haut de la page

Objet :  Rendre le processus personnalisé disponible aux membres du projet.

Une fois l'adaptation initiale effectuée, le processus obtenu doit être publié sous un format exploitable. RUP Builder permet de publier le processus configuré obtenu sur un site Web RUP contenant seulement les composants et ressources processus sélectionnés. L'ingénieur processus doit travailler avec le chef de projet afin de rendre public le processus personnalisé et décider comment former les membres du projet. Cela peut aller d'une présentation informelle de deux heures à une formation plus formelle, selon l'ampleur du projet et le degré de familiarité des membres du projet avec des processus de développement similaires. Chaque mise à jour significative du processus pendant le cycle de vie du projet doit être réintégrée dans le projet, en se concentrant sur les changements.

Le site Internet du processus personnalisé peut être publié sur un serveur Web du réseau de l'entreprise, ou bien installé sur les ordinateurs de chacun des membres de l'équipe. Si les membres du projet sont connectés au réseau la majorité du temps, il est recommandé de déployer le site Web RUP sur un serveur Web afin d'éviter les frais liés aux mises à jour faites au processus pendant le cycle de vie du projet.

Assurer la maintenance du processusHaut de la page

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. Les évaluations faites pendant le projet sont des données importantes pour l'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. Les problèmes plus complexes sont traités par le biais de demandes de changement. Ils sont généralement traités par un groupe processus extérieur au projet, chargé du processus de développement logiciel du point de vue organisationnel.

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

Le Process Engineering Process du produit ../res_processworkbench.htm -- This hyperlink in not present in this generated websiteRational Process Workbench contient des informations sur l'amélioration du processus dans un cadre organisationnel.



RUP (Rational Unified Process)   2003.06.15