Concept: Comparaison entre l'architecture UMA et le métamodèle RUP 2003
Ce concept décrit les principales différences entre l'architecture UMA et le métamodèle Rational Unified Process / Rational Process Workbench 2003.
Description principale

Généralités

L'architecture UMA a été développée dans le but d'unifier le schéma conceptuel de la représentation et la terminologie de toutes les méthodes et de toutes les approches de processus chez IBM. Elle a aussi pour but de prendre en charge les standards les plus importants de l'industrie.Comme le montre la figure ci-dessous, l'architecture UMA a été mise au point dans un effort de collaboration entre les architectes d'IBM Rational Unified Process (RUP), d'IBM Global Services Method (GS Method) et d'IBM Rational Summit Ascendant.En plus de ce groupe d'architectes, les parties prenantes de beaucoup d'autres initiatives de processus de développement, appartenant ou non à IBM, ont contribué à sa spécification.La spécification a elle-même été soumise au groupe OMG , en tant que proposition pour le standard SPEM 2.0. Le métamodèle RUP 2003 ayant été développé d'après le standard SPEM 1.1 actuel, cette ébauche de proposition de SPEM 2.0 peut être vue comme une évolution importante mais dans la continuité de ce standard.

Image indiquant l'évolution de l'architecture UMA

Le principal but de cette unification était d'aboutir à un ensemble de termes et de structures de données permettant à ces méthodes et à ces processus d'être exprimés sans perdre leurs caractéristiques clés.Par exemple, l'architecture UMA a été mise au point pour prendre en charge plusieurs modèles de cycles de vie : le cycle de vie de développement itératif RUP, les cycles de vie incrémentiels GS Method et les cycles de vie en cascade et itératifs Summit Ascendant.De plus, les différences de terminologie devaient être résolues : ce que RUP appelait une activité s'appelait une tâche dans GS Method ; lorque RUP parlait d'artefacts, Summit Ascendant parlait de livrables etc.

Changements dans UMA pour les utilisateurs de RUP 2003

Le fait de définir une structure de données unique, mais surtout une terminologie commune pour toutes ces approches, impliquait un certain nombre de compromis et de changements devant être acceptés par toutes les parties prenantes. Bien que ces changements puissent être perturbants pour les utilisateurs de RUP, sur le long terme ils bénéficieront d'une terminologie largement unifiée, d'une manière standardisée d'exprimer le contenu de méthode et les processus, améliorant la communication sur les processus et facilitant la réutilisation.La liste suivante résume les changements les plus importants apportés au métamodèle RUP 2003.Le tableau à la fin de cette page vous donne une comparaison terminologique complète des principales sources de l'architecture UMA.

  • Les "activités" s'appellent désormais "tâches" : pour créer un lien plus étroit entre la description de processus et la gestion de projet, nous avons renommé l'unité de travail affectable la plus basse "tâche", parce que c'est le terme le plus couramment utilisé.
  • Les "détails de l'enchaînement d'activités" s'appellent désormais "activités" : les enchaînements d'activités sont souvent exprimés sous forme de hiérarchies de diagrammes d'activité (comme, par exemple, les diagrammes d'activité définis dans UML 2.0).Alors que RUP ne fournissait qu'un niveau de répartition d'enchaînement d'activités, l'architecture UMA est faite pour fournir plusieurs niveaux de ce type de répartition. Comme le mot activité était plus souvent utilisé pour exprimer les éléments des diagrammes d'activité ou le diagramme d'activité lui-même, nous avons décidé de remplacer le nom "détails de l'enchaînement d'activités" utilisé dans RUP par le nom "activité".Nous savons que ce changement d'utilisation du mot "activité" peut entraîner des confusions chez les utilisateurs de RUP.Cependant, un des principaux buts du projet UMA était d'utiliser les termes de la façon dont ils sont le plus utilisés dans les standards et dans l'industrie. 
  • Les tâches (anciennement appelées activités RUP) peuvent être réalisées par plusieurs rôles : Dans RUP 2003, une activité était modélisée comme l'opération d'un rôle.Le retour d'informations des utilisateurs, l'observation des approches de modélisation ainsi que les changements introduits dans UML, ont indiqué que c'était une façon trop restrictive de modéliser le comportement humain. Cette approche ne permettait pas d'exprimer qu'une partie du travail était réalisée comme une collaboration de différents rôles.L'architecture UMA règle ce problème en faisant de la tâche un élément de modèle indépendant auquel des rôles d'exécution peuvent être attribués comme des ressources.L'architecture UMA permet donc que plusieurs rôles soient attribués à une tâche.Pour la compatibilité amont, un rôle d'exécution principal peut toujours être identifié (il est alors responsable de la tâche), ainsi que plusieurs exécutants supplémentaires.
  • Amélioration du concept d'artefact : RUP n'utilisait le concept d'artefact que pour définir les choses utilisées et produites par un projet de développement.L'architecture UMA définit une taxinomie différente pour ces concepts.Elle définit le concept général de produit, qui a trois spécialisations différentes (des types de produits spécifiques) : des artefacts (produits gérés), des livrables (produits regroupés en package qui seront livrés à une partie prenante pour être révisés) et un résultat (produits intangibles et non gérés).
  • Catégorisations différentes pour les produits et les rôles : Dans RUP, les artefacts et les rôles étaient catégorisés par discipline.Cependant, les artefacts étaient parfois utilisés dans plusieurs disciplines et la catégorisation dans une seule discipline n'était pas claire.Dans l'architecture UMA, différentes catégories ont été définies pour les définitions du travail (discipline pour tâches et activités), les produits (domaine et type de produit) et les rôles (ensemble de rôles). 
  • Les "composants de processus" sont désormais appelés "packages de méthode" : le concept de composant est utilisé de manière courante dans de nombreux standards et technologies. La plupart des applications du composant le relient à l'abstraction de l'encapsulation en le définissant comme une boîte noire pouvant être utilisée grâce à des interfaces bien définies. Les composants RUP ne répondaient pas à ce critère de boîte noire. Le standard SPEM définit aussi bien des packages que des composants. Pour être conforme au standard SPEM et à l'usage industriel du mot composant, un "composant de processus" s'appelle désormais un "package de méthode". (C'est une méthode d'un point de vue technique car elle peut contenir des éléments de méthode ou des éléments de processus.)
  • Séparation des éléments du contenu de méthode et des éléments de processus : Dans RUP 2003, on créait un nouveau processus en définissant une nouvelle configuration et en documentant manuellement dans un artefact de plan de développement les changements apportés au processus RUP standard. L'architecture UMA fournit des concepts étendus en plus du concept de configuration pour la personnalisation des processus.Cela vous permet de modéliser concrètement pour un processus quel travail défini dans le contenu de méthode vous souhaitez réellement effectuer dans chaque phase. Vous pouvez en effet facilement ajouter, supprimer et réorganiser les éléments dans la structure du processus, en réutilisant ce que vous souhaitez du contenu de la méthode. Ce résultat est atteint grâce à une séparation plus claire du contenu de la méthode (par exemple, les tâches définies pour les disciplines), et de l'application du contenu de la méthode dans le processus (exprimé à l'aide de diagrammes d'activité et/ou de structures de répartition), ainsi que de la modélisation de processus (comme la création de diagrammes d'activité nouveaux ou adaptés ou de structures de répartition nouvelles ou adaptées).De nouveaux concepts sont introduits, comme le descripteur, qui prennent en charge cette séparation et remplissent de nouvelles fonctions permettant d'entretenir et de réutiliser de nombreuses autres familles de processus alternatifs, ainsi que des parties de processus, dans la même configuration.

Comparaison terminologique

Le tableau suivant indique la façon dont la terminologie UMA correspond aux termes utilisés dans les autres approches d'ingénierie de processus.

  UMA/RMC RUP 2003 SUMMIT IGSM SPEM 1.1
Eléments de méthode de base        
  Rôle Rôle Rôle Rôle Rôle de processus
Produit   Livrable    
Produit/Artefact Artefact   Description du produit Produit
Produit/Résultat     Résultat de tâche  
Produit/Livrable     Description du contenu de livrable  
Tâche Activité Activité Tâche Activité
Etape Etape Etape Sous-tâche Etape
         
Associé au processus        
  Activité Détail de l'enchaînement d'activité Tâche Activité Définition du travail
prél. prél.     prél.
Phase Phase Phase Phase Phase
Pattern de capacité     Pattern de capacité (Composant du processus)
Processus de livraison Cycle de vie/Configuration Carte itinéraire Modèle de mission (Processus)
         
Catégorisation        
  Discipline Discipline Module   Discipline
Domaine (Ensemble d'artefacts)   Domaine Type du produit
Ensemble de rôles (Ensembles de rôles)      
Outil Outil      
         
Package de méthode        
  Plug-in de méthode Plug-in de modèle de processus     Processus
Package de méthode Composant de processus     Package
Package de méthode/Package de contenu        Package
Package de méthode/Package de processus       Package
Package de processus/Composant de processus       Composant de processus
         
Types de conseils        
  Instructions Instructions Article référence Article technique Instructions
Concept Concept Article référence    
Livre blanc Livre blanc Article référence    
Liste de contrôle Liste de contrôle   Article technique (V&V) Liste de contrôle
Guide d'utilisation de l'outil Guide d'utilisation de l'outil   Guide de l'outil Guide d'utilisation de l'outil
Canevas Canevas Canevas Canevas Canevas
Compte-rendu Compte-rendu      
Evaluation   Evaluation Evaluation des considérations Evaluation
Exemple Exemple   Article/Exemple référence  
Feuille de route  Feuille de route Description de la feuille de route    
Définition du terme (Glossaire) (Glossaire)    
Pratique