Hintergrund
Unified Method Architecture (UMA) wurde mit dem Ziel entwickelt, die Darstellungsschemata und die Terminologie aller
Methoden- und Prozess-Engineering-Lösungen bei IBM zu vereinheitlichen und die meisten bedeutenden Branchenstandards zu
unterstützen. Deshalb wurde UMA, wie in der folgenden Abbildung gezeigt, in Zusammenarbeit von den Architekten von IBM
Rational Unified Process (RUP), IBM Global Services Method (GS-Method) und IBM Rational Summit Ascendant entwickelt.
Zusätzlich zu dieser Kerngruppe von Architekten haben Interessenvertreter vieler anderer Entwicklungsprozessinitiativen
innerhalb und außerhalb der IBM die Spezifikation geprüft und dazu beigetragen. Die Spezifikation selbst wurde als
Entwurf für den Standard SPEM 2.0 an die OMG gesendet. Da das Metamodell von RUP 2003 basierend auf dem aktuellen
Standard SPEM 1.1 entwickelt
wurde, kann der Entwurf für SPEM 2.0 als bedeutende, aber fortlaufende Weiterentwicklung dieses Standards gesehen
werden.
Das Hauptziel dieser Vereinheitlichung war, Begriffe und Datenstrukturen festzulegen, mit denen alle diese Methoden und
Prozesse ausgedrückt werden können, ohne ihre Schlüsselmerkmale zu verlieren. Beispielsweise musste UMA so konzipiert
werden, das viele verschiedene Lebenszyklusmodelle unterstützt werden können: der iterative RUP-Entwicklungszyklus, die
inkrementellen GS-Method-Lebenszyklen sowie die Wasserfall- und iterativen Lebenszyklen von Summit Ascendant. Außerdem
mussten Terminologieabweichungen konsolidiert werden. Beispielsweise ist eine Aktivität in RUP eine Task in GS Method,
und was in RUP Artefakt genannt wird, heißt in Summit Ascendant Deliverable usw.
Änderungen in UMA für Benutzer von RUP 2003
Durch die Definition lediglich einer Datenstruktur und, was noch viel wichtiger ist, einer gemeinsamen Terminologie für
alle Lösungen, mussten von allen Interessenten Kompromisse und Änderungen hingenommen werden. Aktuelle RUP-Benutzer
werden diese Änderungen möglicherweise etwas verwirren, aber auf lange Sicht werden auch sie von der vereinheitlichten
Terminologie und dem standardisierten Ausdruck von Methodeninhalten und Prozessen und der damit einfacheren
Kommunikation über Prozesse und der einfacheren Wiederverwendung profitieren. In der folgenden Liste sind die
wichtigsten Änderungen im Metamodell von RUP 2003 zusammengefasst. Die Tabelle am Ende dieser Seite enthält einen
vollständigen Vergleich der Terminologie aller wichtigen Quellen für UMA.
-
Aktivitäten heißen jetzt Aufgaben: Um eine engere Verknüpfung von Prozessumsetzung und
Projektmanagement zu schaffen, wird die kleinste zuordnenbare Arbeitseinheit jetzt Aufgabe genannt, weil dieser
Begriff am häufigsten verwendet wird.
-
Workflowdetails heißen jetzt Aktivität: Workflows werden häufig in Hierarchien von
Aktivitätsdiagrammen ausgedrückt (z. B. in UML 2.0 definierte Aktivitätsdiagramme). RUP unterstützt zwar nur eine
Ebene des Strukturplans, aber UMA ist so konzipiert, dass auch mehrere Ebenen solcher Strukturen möglich sind. Da
das Wort Aktivität häufiger verwendet wird, um die Elemente von Aktivitätsdiagrammen sowie das Aktivitätsdiagramm
selbst zu beschreiben, wurde entschieden, den in RUP verwendeten Namen Workflowdetail durch den Namen Aktivität zu
ersetzen. Verständlicherweise kann diese Umstellung auf das Wort Aktivität Verwirrung bei den aktuellen Benutzern
von RUP auslösen. Ein wichtiges Ziel bei der Entwicklung von UMA war jedoch, Begriffe zu verwenden, die in
Standards und Industrie am häufigsten verwendet werden.
-
Aufgaben (früher RUP-Aktivitäten) können von vielen Rollen ausgeführt werden: In RUP 2003 wurde
eine Aktivität als Operation einer Rolle modelliert. Kundenrückmeldungen, ein Vergleich mit anderen Lösungen für
die Modellierung von Prozessen sowie die in UML 2.0 eingeführten Änderungen waren ein Hinweis darauf, dass dieser
Ansatz für die Modellierung menschlichen Verhaltens zu restriktiv war. Bei diesem Ansatz war es nicht möglich
auszudrücken, dass bestimmte Arbeiten durch Zusammenarbeit verschiedener Rollen erledigt werden mussten. UMA hat
eine Lösung für dieses Problem gefunden. In UMA wird die Aufgabe zu einem unabhängigen Modellelement, dem
ausführende Rollen als Ressourcen zugeordnet werden können. Deshalb erlaubt UMA jetzt, dass einer Aufgabe mehrere
Rollen zugeordnet werden können. Für die Abwärtskompatibilität können jedoch auch weiterhin eine primäre
ausführende Rolle (die für die Aufgabe verantwortlich ist) und mehrere zusätzliche ausführende Benutzer angegeben
werden.
-
Verbesserung des Konzepts Artefakt: RUP hat das Konzept Artefakt nur verwendet, um Dinge zu
definieren, die in einem Entwicklungsprojekt verwendet und erzeugt werden. UMA definiert eine erweiterte Taxonomie
für diese Konzepte. UMA definiert das allgemeine Konzept Arbeitsergebnis mit drei unterschiedlichen
Spezialisierungen (bestimmte Arbeitsergebnistypen): Artefakte (verwaltete Arbeitsergebnisse), Liefergegenstände
(gepackte Arbeitsergebnisse, die einem Interessenten zur Prüfung ausgeliefert werden) und Resultat (nicht
verwaltete, nicht formal definierte Arbeitsergebnisse).
-
Unterschiedliche Kategorisierungen von Arbeitsergebnissen und Rollen: In RUP wurden Artefakte und
Rollen nach Disziplin kategorisiert. Manchmal wurden Artefakte jedoch in mehreren Disziplinen verwendet, und die
Kategorisierung in genau eine Disziplin hat zu Verwirrung geführt. In UMA wurden unterschiedliche Kategorien für
Arbeitsdefinitionen definiert (Disziplin für Aufgaben und Aktivitäten), Arbeitsergebnisse (Domäne und Art des
Arbeitsergebnisses) und Rollen (Rollengruppen).
-
Prozesskomponenten heißen jetzt Methodenpaket: Das Konzept Komponente wird häufig in vielen
Standards und Technologien verwendet. Die meisten Anwendungen verbinden das Konzept Komponente mit der Abstraktion
von Kapselung, die eine Komponente als Blackbox definiert, die in klar strukturierten Schnittstellen verwendet
werden kann. RUP-Komponenten haben dieses Blackbox-Kriterium nicht erfüllt. Außerdem definiert der SPEM-Standard
Pakete und Komponenten. Für die Kompatibilität mit SPEM und der branchenüblichen Verwendung des Worts Komponente
wurde Prozesskomponente in Methodenpaket umbenannt. (Vom technischen Standpunkt aus ist es eine 'Methode', da es
Methodenelemente oder Prozesselement enthalten kann.)
-
Trennung von Methodeninhaltselementen und Prozesselementen: In RUP 2003 haben Sie einen neuen
Prozess erstellt, indem Sie eine neue Konfiguration definiert und in einem Entwicklungsfallartefakt die Änderungen
im Vergleich mit Standard-RUP manuell dokumentiert haben. UMA stellt für die Anpassung von Prozessen zusätzlich zum
Konzept Konfiguration erweiterte Konzepte bereit. In UMA können Sie in einem Modell für einen Prozess konkret
festlegen, welche Arbeiten, die im Methodeninhalt definiert sind, in jeder Phase tatsächlich ausgeführt werden
sollen. Dies ist möglich, weil Sie Elemente in der Prozesstruktur auf einfache Weise hinzufügen, entfernen und
verschieben und beliebige Elemente aus dem Methodeninhalt wiederverwenden können. Die Basis für diese Features ist
eine klarere Trennung von Methodeninhalt (z. B. für Disziplinen definierte Aufgaben) und der Anwendung des
Methodeninhalts im Prozess (ausgedrückt mit Aktivitätsdiagrammen und/oder Projektstrukturplänen) sowie der
Modellierung von Prozessen (d. h. Erstellen neuer oder angepasster Aktivitätsdiagramme bzw. neuer oder angepasster
Projektstrukturpläne). UMA führt verschiedene neue Konzepte wie einen Deskriptor ein, die diese Trennung
unterstützen und neue Funktionalität für die Verwaltung und Wiederverwendung vieler verschiedener Familien
alternativer Prozesse und Prozessteile innerhalb derselben Konfiguration bieten.
Terminologievergleich
Die folgende Tabelle zeigt die Zuordnung der UMA-Terminologie zu den Begriffen, die in anderen
Prozess-Engineering-Lösungen verwendet werden.
|
UMA/RMC
|
RUP 2003
|
SUMMIT
|
IGSM
|
SPEM 1.1
|
Grundlegende Methodenelemente
|
|
|
|
|
|
Rolle
|
Role
|
Role
|
Role
|
Process Role
|
Arbeitsergebnis
|
|
Deliverable
|
|
|
Arbeitsergebnis/Artefakt
|
Artifact
|
|
Work Product Description
|
Work Product
|
Arbeitsergebnis/Resultat
|
|
|
Task Outcome
|
|
Arbeitsergebnis/Liefergegenstand
|
|
|
Deliverable Content Description
|
|
Aufgabe
|
Activity
|
Activity
|
Task
|
Activity
|
Schritt
|
Step
|
Step
|
Subtask
|
Step
|
|
|
|
|
|
Prozessbezogen
|
|
|
|
|
|
Aktivität
|
Workflow Detail
|
Task
|
Activity
|
Work Definition
|
Iteration
|
Iteration
|
|
|
Iteration
|
Phase
|
Phase
|
Phase
|
Phase
|
Phase
|
Prozessmuster
|
|
|
Capability Pattern
|
(Process Component)
|
Bereitstellungsprozess
|
Lifecycle/Configuration
|
Route Map
|
Engagement Model
|
(Process)
|
|
|
|
|
|
Kategorisierung
|
|
|
|
|
|
Disziplin
|
Discipline
|
Module
|
|
Discipline
|
Domäne
|
(Artifact Set)
|
|
Domain
|
Work Product Kind
|
Rollengruppe
|
(Role Set)
|
|
|
|
Tool
|
Tool
|
|
|
|
|
|
|
|
|
Packen von Methoden
|
|
|
|
|
|
Methoden-Plug-in
|
Process Model Plug-in
|
|
|
Process
|
Methodenpaket
|
Process Component
|
|
|
Package
|
Methodenpaket/Inhaltspaket
|
|
|
|
Package
|
Methodenpaket/Prozesspaket
|
|
|
|
Package
|
Prozesspaket/Prozesskomponente
|
|
|
|
Process Component
|
|
|
|
|
|
Anleitungstypen
|
|
|
|
|
|
Richtlinie
|
Guideline
|
Reference Paper
|
Technique Paper
|
Guideline
|
Konzept
|
Concept
|
Reference Paper
|
|
|
White Paper
|
White Paper
|
Reference Paper
|
|
|
Prüfliste
|
Checklist
|
|
Technique Paper (V&V)
|
Checklist
|
Toolmentor
|
Tool Mentor
|
|
Tool Guide
|
Tool Mentor
|
Vorlage
|
Templates
|
Template
|
Template
|
Template
|
Bericht
|
Report
|
|
|
|
Schätzung
|
|
Estimate
|
Estimating Considerations
|
Estimate
|
Beispiel
|
Example
|
|
Reference Item/Example
|
|
Roadmap
|
Roadmap
|
Route Map Description
|
|
|
Begriffsdefinition
|
(Glossary)
|
(Glossary)
|
|
|
Verfahren
|
|
|
|
|
|