Instructions: Personnalisation de RUP
Ces instructions fournissent des recommandations pour la personnalisation du processus RUP pour une organisation ou un projet.
Description principale

Ces instructions décrivent certains éléments à prendre en compte pour la personnalisation du processus RUP. 

Pour obtenir une description du processus global de personnalisation de RUP, voir Concept : Personnalisation de RUP

Pour obtenir une description de certaines meilleures pratiques générales relatives à la personnalisation du processus, voir Instructions : Pratiques de personnalisation des processus.

Définition de la portée de l'effort de personnalisation

La définition de la portée de l'effort de personnalisation correspond au moment où vous identifiez les changements à effectuer et comment vous voulez les effectuer.

Afin de définir la portée de façon efficace, il est important de vous familiariser avec le processus RUP.  Pour plus d'informations, voir Introduction to RUP.

La fraction de processus que vous décidez de personnaliser et le niveau de personnalisation que vous décidez d'adopter dépendent tous deux d'un certain nombre de facteurs. Ces facteurs sont décrits dans Instructions : Discriminants du processus.  

Eléments variables dans les processus d'ingénierie logicielle

Cette section révise les constituants d'un processus susceptibles d'être modifiés, personnalisés, ajoutés ou supprimés dans le cadre d'un effort de personnalisation du processus RUP.

  • Disciplines
    Un projet logiciel ne sautera complètement une discipline comme l'analyse et la conception ou l'implémentation que rarement. Dans des cas exceptionnels, certaines disciplines, comme les exigences ou le déploiement, peuvent avoir été exécutées par d'autres organisations. Cependant, il est plus probable que des enchaînements d'activités spécifiques dans une discipline ou d'une discipline à l'autre soient modifiés.  
  • Produits
    Les projets sont bien plus susceptibles de différer selon les produits qu'ils doivent produire, mettre à jour et livrer. A une extrémité de la gamme, imaginez un projet sans papier qui maintient électroniquement un petit nombre de produits, est pris en charge par des outils tels que des feuilles de calcul, des outils de conception, de programmation et de test, et livre des logiciels et de la documentation uniquement sous forme électronique, sur disque, sur CD ou sur le Web. A l'autre extrême, certains projets doivent produire et maintenir un ensemble bien plus important de documents imprimés pour des raisons contractuelles, réglementaires ou organisationnelles. Dans certains cas, des modèles complets peuvent être omis.
  • Tâches
    Les activités peuvent varier pour au moins deux raisons. Les tâches qui utilisent des produits comme données d'entrée et produisent ou mettent à jour des produits comme données d'entrée sont influencées par la modification de ces produits. Plus particulièrement, si un produit ou un élément d'information d'un produit n'est plus nécessaire, les étapes correspondantes peuvent être supprimées ou modifiées de manière significative. Les tâches sont également modifiées pour introduire des techniques, des méthodes et des outils spécifiques qui appartiennent au domaine d'application ou à l'expertise de développement spécifique, comme les étapes de conception, les langages de programmation, les outils de génération automatique de code, les techniques de mesure, etc.

A un niveau plus détaillé, d'autres éléments de méthode peuvent être modifiés, ajoutés ou supprimés :

  • Rôles
  • Etapes dans les activités
  • Instructions et conseils pour les tâches
  • Notations, comme l'utilisation de sous-ensembles de l'UML ou de stéréotypes pour traiter un besoin spécifique pour certains modèles ou tous.
  • Listes de contrôle pour les revues
  • Support des outils permettant d'automatiser certaines tâches
  • Changements terminologiques, par exemple pour adapter le processus au contexte organisationnel

En résumé, le responsable de processus doit prendre des décisions très variées lors de la personnalisation du processus RUP. Un processus RUP peut devoir être ajusté pour bénéficier de certaines pratiques et standards d'entreprise bien établis, comme les documents, la terminologie, etc.



 

Scénarios de personnalisation difficiles

Certains scénarios de personnalisation sont difficiles à implémenter et doivent être étudiés attentivement. Par exemple :

  • Changements dans l'architecture de processus
    Un reconditionnement de grande envergure des tâches dans un autre ensemble de disciplines afin de correspondre à un processus ou à une organisation existante peut demander un grand effort pour un bénéfice très limité. Il est souvent plus pratique d'établir simplement un mappage afin de déterminer si tous les aspects sont couverts par le RUP. Souvenez-vous que les disciplines ne sont pas des phases exécutées de façon séquentielle - elles contiennent les tâches, et sont exécutées à chaque itération, souvent simultanément dans une même itération.
  • Changements de terminologie
    Bien qu'il semble trivial de remplacer un mot par un autre dans le traitement de texte, ces changements doivent être traités avec précaution. Dans le domaine de l'ingénierie logicielle, les organisations utilisent souvent le même mot avec des significations légèrement différentes, ou différents mots signifiant la même chose. Si vous effectuez des changements isolés dans le RUP vous pouvez obtenir un processus très difficile à comprendre. Une solution est de créer une table de conversion pour la terminologie pour établir des correspondances entre la terminologie RUP et la terminologie de l'organisation.

Exemples de mots pièges : système, phase, rôle, activité, tâche, modèle et document.

Si les résultats de processus sont consignés dans une langue autre que l'anglais, les problèmes de terminologie sont plus complexes car vous devez traduire les descriptions des tâches, des documents, des comptes-rendus et parfois d'autres parties du RUP dans cette autre langue.