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.
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
|
|
|
|
|
|