Konzept: Metamodelle von UMA und RUP 2003 im Vergleich
Dieses Konzept beschreibt die Hauptunterschiede zwischen den Metamodellen von Unified Method Architecture und Rational Unified Process/Rational Process Workbench 2003.
Hauptbeschreibung

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.

Abbildung, die die Weiterentwicklung von Unified Method Architecture veranschaulicht

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