Prozessmodellintegration - Am Beispiel einer RUP ... - ftp.uni-kl.de.

Prozessmodellintegration 

Hochschule Reutlingen 

Reutlingen University 

Fachbereich Informatik 

Studiengang Wirtschaftsinformatik 

Diplomarbeit 


Am Beispiel einer RUP-Erweiterung durch das 

V-Modell XT 

Markus Grundmann 

Matrikel-Nr: 002584 

Betreut durch: 

Dipl.-Inform. H. Biskup 

IBM Rational Software 

Prof. Dr. rer. nat. A. Zimmermann 

Hochschule Reutlingen 

Fachbereich Informatik 24. Januar 2005 


Am Beispiel einer RUP-Erweiterung durch das V-Modell XT 

>>


Danksagung 

Ich möchte allen recht herzlich danken, die zum Gelingen dieser 

Diplomarbeit beigetragen haben. Insbesondere bei: 

• Hubert Biskup als Betreuer bei IBM Rational Software für sein 

Engagement trotz seines hohen Arbeitsaufwands. 

• Prof. Dr. rer. nat. Alfred Zimmermann, der die Arbeit am 

Fachbereich Informatik der Hochschule Reutlingen betreut hat. 

• Prof. Philippe Kruchten von der University of British 

Columbia, Kanada, für die fruchtbaren Diskussionen. 

• Dr. Gerd Sauermann, Volker Kopetzky, Stefan Schmelz, 

Andrew Lyons und Ingo Lachner von IBM Rational Software, 

die immer ein offenes Ohr für meine Fragen hatten. 

• J. Prof. Dr. Rausch, TU Kaiserslautern, und Michael Gnatz, TU 

München, für den Zugang zu Vorabinformationen und die 

Unterstützung in V-Modell Angelegenheiten. 

• Allen Mitarbeitern bei IBM Rational Software in München für 

die freundliche Aufnahme und Unterstützung. 

• Meinen Eltern und meiner Freundin für die Unterstützung. 



>> 

I 

I


Abstract 

Anhaltende Probleme bei der Realisierung von IT-Projekten, laut 

Standish Group waren weniger als 30 Prozent im Jahr 2000 

erfolgreich, führen zu einer Vielzahl an Prozessmodellen am Markt. 

Sie sollen die Fehlerquote verringern, haben jedoch alle ihre Stärken 

und Schwächen, weshalb sich bis jetzt kein Prozessmodell als 

alleiniger Standard etablieren konnte. 

Thema dieser Arbeit ist es, den Sinn und Nutzen einer Integration 

zweier Prozessmodelle zu untersuchen und durchzuführen. Die Wahl 

fällt dabei auf eine Erweiterung des Rational Unified Process (RUP) 

durch eine Integration mit dem neuen V-Modell XT. Dabei handelt es 

sich um ein neues Vorgehensmodell, das am 4. Februar 2005 

veröffentlicht wird und das vorgeschriebene Prozessmodell im Bereich 

der Öffentlichen Hand ist 

Um diese Integration durchführen zu können, wird eine Methodik 

vorgestellt, die globale Ziele zunächst auf einzelne Elemente der 

verwendeten Modelle präzisiert. Anschließend führt sie eine 

qualitative Einschätzung des zu erwartenden Ergebnisses durch. 

Letztlich werden durch die Untersuchung ein Synthesemodell und 

Synthesematrizen gewonnen, die eine Implementierung der Ergebnisse 

erlauben. 

Der Prototyp zeigt, wie die methodisch gewonnenen Ansatzpunkte in 

einen Workflow eingebettet und in der Prozessdokumentation des RUP 

zur Verfügung gestellt werden können. 

Eine im Anschluss vorgenommene CMMI Bewertung des Ergebnisses 

zeigt, dass eine Integration dazu verwendet werden kann, die Stärken 

eines Prozessmodells einem anderen durch eine Integration nutzbar zu 

machen. 

In der abschließenden Bewertung des V-Modells werden seine 

Novitäten und Eigenheiten nochmals diskutiert. In dieser Betrachtung 

zeigt sich, dass das V-Modell gute neuartige Ansätze enthält, wie eine 

eingegliederte Auftragnehmer - Auftraggeber Schnittstelle, aber an 

anderen Punkten auch Probleme, wie beispielsweise bei der agilen 

Projektdurchführungsstrategie, aufweist. 



>> 

II 

II


Tabellenverzeichnis 

Tabelle 1: Synthesematrix des quantitativen Ziels der Einrichtung von 

Schulungsmaßnahmen....................................................... 58 

Tabelle 2: Synthesematrix des quantitativen Ziels des Managements 

von Lieferantenvereinbarungen......................................... 59 

Tabelle 3: Synthesematrix des qualitativen Ziels der V-Modell 

Kompatibilität aus Auftraggeber-Sicht ............................. 61 

Tabelle 4: CMMI Bewertung der Integration des Zulieferer 

Managements .................................................................... 98 

Tabelle 5: CMMI Bewertung der Integration der Generischen Praktik 

Train People ...................................................................... 99 

Tabelle 6: RUP CMMI Maturity Level 2 Assessment:.................... 119 

Tabelle 7: RUP CMMI Maturity Level 3 Assessment ..................... 124 



Abbildungsverzeichnis 

Abbildung 1: Projekterfolgsquoten ..................................................... 1 

Abbildung 2: Grundkonzept des Wasserfallmodells......................... 17 

Abbildung 3: Vergleich der Prozessabläufe bei zyklischer 

Entwicklung und Wasserfall Vorgehensweise............ 18 

Abbildung 4: Wasserfall- und zyklisches Vorgehen im Vergleich ... 19 

Abbildung 5: Risikoverlauf eines Projektes: iteratives und 

Wasserfallvorgehen im Vergleich............................... 20 

Abbildung 6: Organisation des RUP ................................................. 21 

Abbildung 7: Phasen des RUP und ihre Meilensteine....................... 21 

Abbildung 8: RUP Disziplin am Beispiel der Business Modeling 

Discipline .................................................................... 22 

Abbildung 9: Workflow Detail am Beispiel von Assess Business 

Status ........................................................................... 23 

Abbildung 10: Entscheidungspunkte des V-Modell XT..................... 25 

Abbildung 11: Projektdurchführungsstrategien .................................. 26 

Abbildung 12: Komponentenbasierte Systementwicklung eines 

Auftragnehmers........................................................... 27 

Abbildung 13: Agile Systementwicklung eines Auftragnehmers....... 27 



>> 

III 

III


Abbildung 14: Auftraggeber - Auftragnehmer Schnittstelle............... 28 

Abbildung 15: Übersicht der Vorgehensbausteine des V-Modell XT 29 

Abbildung 16: Vertikale Struktur eines Prozessmodells nach SPEM. 33 

Abbildung 17: Packaging Übersicht ................................................... 34 

Abbildung 18: Metamodell des RUP .................................................. 35 

Abbildung 19: Second-Class Elements des RUP................................ 36 

Abbildung 20: Definition eines Vorgehensbausteins.......................... 37 

Abbildung 21: Definition Projektdurchführungsstrategie................... 37 

Abbildung 22: Zustände eines Produktes............................................ 37 

Abbildung 23: Metamodelle im Vergleich.......................................... 38 

Abbildung 24: CMMI Maturity Level von V-Modell XT und RUP... 45 

Abbildung 25: V-Modell XT Beurteilung nach SCAMPI und SPA im 

Vergleich ..................................................................... 47 

Abbildung 26: Synthesemodell ........................................................... 56 

Abbildung 27: V-Modell XT Editor.................................................... 68 

Abbildung 28: V-Modell XT Projektassistent - Projekttyp ................ 69 

Abbildung 29: V-Modell XT Projektassistent - Anwendungsprofil ... 70 

Abbildung 30: V-Modell XT Projektassistent - Detaillierte 

Konfiguration .............................................................. 71 

Abbildung 31: Rational XDE Modeler - Dependencies des Plugins .. 73 

Abbildung 32: RUP Organizer - Assoziation der Inhalte auf die UML 

Elemente...................................................................... 74 

Abbildung 33: RUP Builder - Zusammenführung von Plugin und Basis 

..................................................................................... 75 

Abbildung 34: RUP Builder - Anlegen der Views.............................. 76 

Abbildung 35: Überblick RUP mit V-Modell XT Integration............ 78 

Abbildung 36: Beschreibung des Plugins ........................................... 80 

Abbildung 37: Workflow der V-Modell Integration Disziplin ........... 81 

Abbildung 38: Workflow Detail Prepare V-Modell Environment...... 82 

Abbildung 39: Workflow Detail Train People.................................... 83 

Abbildung 40: Workflow Detail Establish Supplier Agreements....... 84 

Abbildung 41: Workflow Detail Satisfy Supplier Agreements .......... 85 

Abbildung 42: Workflow Detail Assess Work ................................... 87 

Abbildung 43: Workflow Detail Migrate RUP Artifacts to V-Modell 

XT Products................................................................. 89 

Abbildung 44: Workflow Detail Manage V-Modell XT Products ..... 90 

Abbildung 45: Artifact Offer Evaluation ............................................ 91 

Abbildung 46: Integriertes Produkt Angebotsbewertung.................... 92 



>> 

IV 

IV


Abbildung 47: Integriertes Thema Bewertung der Angebote ............. 93 

Abbildung 48: Product - Artifact Matching Table Template.............. 94 

Abbildung 49: Integriertes V-Modell XT Template ........................... 95 

Abbildung 50: Iterationsplan einer initialen Inception Phase ............. 96 

Abbildung 51: Reifegrad der prototypischen Integration ................. 100 

Abbildung 52: Dependencies des RUP V-Modell XT Integration 

Plugins....................................................................... 134 

Abbildung 53: Workflow des Plugins............................................... 135 

Abbildung 54: Aktivitäten und Artefakte der V-Modell Process 

Engineer Rolle........................................................... 136 

Abbildung 55: Aktivitäten und Artefakte der Supplier Agreement 

Manager Rolle........................................................... 137 

Abbildung 56: Aktivitäten und Artefakte der Trainer of Staff Rolle 137 



>> 

V 

V


Inhaltsverzeichnis 

1 Einleitung ..................................................................................... 1 

1.1 Ziele....................................................................................... 5 

1.2 Vorgehensweise .................................................................... 5 

1.3 Gliederung............................................................................. 7 

2 Anforderungen ............................................................................. 8 

2.1 Anforderungen an die Modelle ............................................. 8 

2.2 Anforderungen an die Integration ......................................... 9 

2.2.1 Funktionale Anforderungen ........................................ 10 

2.2.2 Benutzbarkeit .............................................................. 10 

2.2.3 Zuverlässigkeit ............................................................ 10 

2.2.4 Performanz .................................................................. 11 

2.2.5 Wartbarkeit.................................................................. 12 

2.3 Anforderungen an die Integration als Prozessmodell ......... 12 

2.3.1 Vollständigkeit ............................................................ 12 

2.3.2 Modularität.................................................................. 13 

2.3.3 Systematik ................................................................... 13 

2.3.4 Allgemeingültigkeit..................................................... 13 

2.3.5 Anpassbarkeit.............................................................. 14 

2.3.6 Maschinelle Unterstützung.......................................... 14 

3 Prozessmodelle........................................................................... 16 

3.1 Analyse der verwendeten Prozessmodelle .......................... 19 

3.1.1 Rational Unified Process............................................. 20 

3.1.2 V-Modell XT............................................................... 24 

3.2 Analyse der Life-Cycles...................................................... 30 

3.3 Analyse der Metamodelle.................................................... 33 

3.3.1 Rational Unified Process............................................. 33 

3.3.2 V-Modell XT............................................................... 36 

3.3.3 Fazit der Metamodell Vorstellung............................... 38 

3.4 Synthese .............................................................................. 40 

3.4.1 Feststellen des Integrationsziels .................................. 41 

3.4.1.1 Qualitative Ziele...................................................... 42 

3.4.1.2 Quantitative Ziele.................................................... 43 

3.4.2 Verifikation und Präzision von Ziel und Weg ............ 48 

3.4.2.1 Machbarkeit der Integration.................................... 49 

3.4.2.2 Gewinn der Integration............................................ 49 

3.4.2.3 Ziel der Integration.................................................. 49 



>> 

VI 

VI


3.4.2.4 Qualität der Zielmenge............................................ 51 

3.4.2.5 Definition der Interfaces.......................................... 55 

3.4.2.6 Verhältnis der Interfaces zur Zielmenge ................. 55 

3.4.3 Synthesemodell ........................................................... 56 

3.4.4 Synthesematrizen ........................................................ 57 

3.5 Alternative Synthesansätze ................................................. 65 

4 Werkzeugumgebungen............................................................... 67 

4.1 V-Modell XT....................................................................... 67 

4.2 Rational Unified Process..................................................... 72 

4.3 Fazit der Toolvorstellung .................................................... 76 

5 Prototyp ...................................................................................... 78 

6 Bewertung der Integration nach CMMI..................................... 98 

7 Zusammenfassung.................................................................... 101 

7.1 Fazit Prototyp .................................................................... 102 

7.2 Fazit V-Modell XT............................................................ 105 

7.3 Erkenntnisse der Arbeit..................................................... 108 

7.4 Ausblick ............................................................................ 109 

8 Anlagen .................................................................................... 111 

8.1 Quellen .............................................................................. 111 

8.2 Abkürzungsverzeichnis ..................................................... 115 

8.3 Eidesstattliche Erklärung................................................... 116 

Anhang A: CMMI Assessment Rational Unified Process ................ 117 

Anhang B: Modelle des Prototypen .................................................. 132 

Anhang C: V-Modell XT Metamodell.............................................. 138 



>> 

VII 

VII

Einleitung 

1 Einleitung 

Weniger als 30% aller IT-Projekte sind erfolgreich, wie der Chaos 

Report der Standish Group zeigt: 

Abbildung 1: Projekterfolgsquoten (Quelle: [Standish 2001]) 

Bei der Quelle handelt es sich zwar um eine amerikanische Studie, 

[Krempel 2004] legt aber nahe, dass es um deutsche Projekte nicht 

besser steht. 

Die Gründe dafür sind ein der IT-Entwicklung nicht angemessenes 

Vorgehen im Projekt. In einer Wissenschaft bzw. einem 

Industriezweig, in dem das Mooresche Gesetz gilt und neue Versionen 

eines Programms unter Umständen im Halb-Jahres-Zyklus 

veröffentlicht werden, ist der technische Fortschritt so rasant, 

• dass die Anforderungen sich bei entsprechend großen Projekten 

über die Laufzeit ändern. 

• dass keine fehlerfreien Modelle existieren, mit denen sich das 

Verhalten einer Software, ähnlich dem statischen Verhalten 

einer Brücke, beschreiben lässt, auch wenn dies nur an der 

unüberschaubaren Komplexität und nicht unbedingt an den 

Modellen an sich liegt. 



1 

Mooresches Gesetz: 

de.wikipedia.org/wiki/M 

ooresches_Gesetz 

>> 

1

Einleitung 

• dass wichtige Projekte selten „me too“-Projekte sind, in denen 

bekannte Technologien und Vorgehensweisen verwendet 

werden können. 

Diese Dynamiken führen dazu, dass Vorgehensweisen, wie sie in der 

Architektur, den Ingenieurwissenschaften oder der produzierenden 

Industrie über die Zeit entwickelt wurden, nicht oder nur sehr 

eingeschränkt auf IT- Projekte übertragbar sind. 

Die daraus resultierenden Entwicklungen brachten eine heutige 

Situation, die Parallelen zum „Methodenkrieg der 

Softwareentwicklung“ [Jeckle et al. 2004], der in der Spezifikation der 

Unified Modeling Language (UML) gemündet hat, aufweist. 

Es existiert eine Vielzahl von Prozessmodellen am Markt, die teils 

unterschiedlichen Grundphilosophien und Zielrichtungen folgen, teils 

vergleichbar sind: 

• Wasserfall-Modell 

• Rational Unified Process, UPEDU 

• V-Modell 97, V-Modell XT 

• CMM, CMMI 

• DSDM, Adaptive Development, Crystal, Extreme 

Programming, Scrum 

• AQAP 150, AQAP 2110 (NATO Standard) 

• ISO 9001:2000 

• CPM (Verfahrensvorschrift der Bundeswehr) 

• ISO 15288, ISO 12207 

• Spice 

• Prince2 

• Personal Software Process (PSP) 

Die Auflistung erhebt keinen Anspruch auf Vollständigkeit. Die 

Anzahl von mindestens 21 Prozessmodellen, die sich zur selben Zeit 

am Markt befinden, zeigt eindrucksvoll, welche Vielfalt hier herrscht - 

zumal die Methodiken der Systemintegratoren wie Accenture, IBM 

oder Cap Gemini dabei außen vor gelassen wurden. Dass sich aus 

dieser Mannigfaltigkeit auch Probleme ergeben, zeigt sich in einem 

Vortrag für das US Department of Defense (DoD) in [DeWeese, 

Boutin 1997]. 



>> 

2 

2

Einleitung 

Die Erfahrungen bei der Bildung von Standards in der IT, wie z.B. bei 

der UML oder die Probleme mit der Vielzahl an inkompatiblen 

proprietären Formaten, die zu dem Erfolg der Extended Markup 

Language (XML) beigetragen haben, legen einen zukünftigen 

Konsolidierungsprozess nahe. An seinem Ende werden nur einer oder 

nur wenige Standards überleben, die sich durch eindeutige Merkmale 

voneinander abgrenzen und gleichzeitig ein breites Einsatzspektrum 

abdecken. 

Allistair Cockburns Dissertation [Cockburn 2003] ist an diesem Punkt 

sehr interessant, da sie die oben angesprochene Theorie untersucht. 

Er kommt zu dem Ergebnis, dass es unendlich verschiedene 

Methodologies geben wird. Der Grund ist, dass eine Methodology 

nach Cockburns Definition 1 zwar einem Prozessmodell sehr ähnelt, 

aber nicht den generischen Framework Charakter aufweist, den die 

hier aufgeführten Modelle haben. 

Nach der hier verwendeten Definition weisen Prozessmodelle eine 

gewisse Allgemeingültigkeit auf und sind damit zum Beispiel in 

Projekten verschiedener Größe und formaler Anforderungen 

einsetzbar. 

Schließlich empfiehlt Cockburn das Einführen einer generischen 

Komponente als Lösung. Eine von vier vorgeschlagenen 

Möglichkeiten ist die Verwendung des Rational Unified Process, um 

das Problem seiner gegen Unendlich strebenden Anzahl an 

Methodologies in den Griff zu bekommen. 

Selbst wenn eine Konsolidierung nicht eintritt, so wird es umso 

wichtiger sein, dass bei der Verwendung ähnlicher Prozessmodelle 

eine gewisse Konformität zu den „Nachbar-Standards“ möglich ist, da 

der Einsatz verschiedener Modelle einen nicht unerheblichen 

Implementierungs- und Optimierungsaufwand nach sich zieht. 

1 [Cockburn 2003] S.6: "Let's get clear what we mean by methodology. It is 

the roles, teams, skills, processes, techniques, tools, and standards used by the project 

team." 



>> 

3 

3

Einleitung 

Die Wahl der in dieser Arbeit verwendeten Prozessmodelle fällt dabei 

auf den Rational Unified Process (RUP) und das V-Modell XT aus 

folgenden Gründen: 

• IBM Rational in München und das V-Modell XT Team kennen 

sich sehr gut. 

• Beide Parteien haben ein Interesse an der Arbeit und sehen 

darin einen wirtschaftlichen Nutzen, weshalb sie ihre 

Unterstützung für das Projekt zugesagt haben. 

• Das V-Modell ist der gesetzlich vorgeschriebene IT- 

Entwicklungsstandard im Umfeld der Öffentliche Hand, 

immerhin der größte Arbeitgeber in Deutschland, und wird in 

der deutschen Industrie, beispielsweise von Siemens, ebenfalls 

eingesetzt. 

• Das V-Modell XT ist in der deutschen Hochschullandschaft 

entwickelt worden: Die Technische Universität in München hat 

dafür den Auftrag erhalten. 

• Der RUP ist der defacto Standard in der kommerziellen 

Softwareentwicklung. Er kommt beispielsweise bei Ericsson, 

Lockheed-Martin, Xerox, Intel, Visa, Merrill Lynch, CAP 

Gemini Ernst & Young und Deloitte & Touche zum Einsatz 

[Kruchten 2004]. 

Die Überschrift Prozessintegration dieser Arbeit adressiert den 

Aspekt der Machbarkeit und des Nutzens eines solchen Unterfangens 

im Allgemeinen. Der Untertitel Am Beispiel einer RUP-Erweiterung 

durch das V-Modell XT erläutert die Rahmenbedingungen, unter 

denen die Untersuchung der Integrationsmöglichkeit stattgefunden hat. 

In der Implementierung des Prototypen dient der Rational Unified 

Process als Basis und soll um Eigenschaften des V-Modell XT ergänzt 

werden. 

Die Arbeit liefert somit Ergebnisse, die allgemeine Aussagen 

betreffend einer Integration erlauben. Durch die Verwendeten Modelle 

werden zusätzlich spezielle Erkenntnisse über die beiden verwendeten 

Modelle gewonnen. 

Diese Arbeit und das entwickelte Plugin sind auf 

www.MarkusGrundmann.de veröffentlicht. 



Technische 

Universität 

München: 

www.tum.de 

>> 

4 

4

Einleitung 

1.1 Ziele 

Aus der Themenstellung „Prozessmodellintegration am Beispiel einer 

RUP-Erweiterung durch das V-Modell XT“ lassen sich mehrere 

Aufgaben und damit Ziele der Arbeit ableiten: 

1. Das Erarbeiten einer Methodik, um ähnliche Prozessmodelle zu 

verknüpfen. 

2. Prototypische Implementierung der Verknüpfung des V-Modell 

XT in den Rational Unified Process. 

3. Die Implementierung soll zeigen, wie man das V-Modell XT 

nutzen kann, um Projekte nach Maßgabe des Bundes mit Hilfe 

des RUP durchzuführen. 

4. Da auf Grund der Novität des V-Modell XT wenig über dieses 

neue Prozessmodell bekannt ist, soll zusätzlich eine 

Einschätzung des Modells auf Basis der durch die Integration 

gewonnenen Ergebnisse abgeben werden. 

1.2 Vorgehensweise 

Die Vorgehensweise in dieser Arbeit lässt sich in drei Teile gliedern: 

1. Analyse der Modelle 

2. Synthese der Modelle 

3. Implementierung der Syntheseergebnisse 

Zu Beginn der Analyse setzt sich die Arbeit zunächst mit den 

verwendeten Prozessmodellen auseinander, um die benötigten 

Grundlagen zu schaffen. Später erfolgt eine Analyse der Metamodelle, 

um tiefergehende strukturelle Informationen bezüglich der beiden 

Modelle zu erhalten. 

Um eine Verknüpfung der Prozessmodelle zu erstellen, muss zunächst 

eine geeignete Methodik hergeleitet werden, da hier noch kein 

Standardvorgehen existiert. 



>> 

5 

5

Einleitung 

Sie soll nach einer genauen Zieldefinition über ein allgemein gültiges 

Synthesemodell zu spezifischen Synthesematrizen führen. Letztere 

zeigen die Integration der einzelnen Elemente des V-Modells in den 

RUP und bilden die Basis für die anschließend erfolgende 

Implementierung. 

Die Implementierung setzt die Synthesematrizen in einem Workflow 

um. Dazu ist es notwendig, sie um wichtige Aktivitäten, Rollen und 

Artefakte (Arbeitsergebnisse des RUP) zu erweitern, um eine in sich 

stimmige Umsetzung zu gewährleisten. 

Dabei ist darauf zu achten, dass keine unbeabsichtigte und eventuell 

fehlerhafte Nachbildung des einen Prozessmodells mit den Mitteln des 

anderen erfolgt. Das sorgt, solange referentielle Integrität auf Basis der 

Dateinamen gewahrt wird, gleichzeitig für eine nachhaltige 

Nutzbarkeit der Arbeit über Versionsgrenzen hinaus. Zum anderen 

wird damit auch die Konformität der integrierten Elemente der 

Gesamtlösung zu den Vorgaben des Bundes gewährleistet. 

Abschließend wird eine Überprüfung der durch die Methodik 

gewonnenen quantitativen Ziele vorgenommen, da sie gut messbar 

sind und eine eindeutige Aussage über den Erfolg der Lösung 

erlauben. 

Zusammenfassend wird letztlich die integrierte Lösung bewertet, die 

Erkenntnisse zusammengefasst und eine Einschätzung des V-Modells 

abgegeben. 



>> 

6 

6

Einleitung 

1.3 Gliederung 

Aus der Vorgehensweise ergibt sich folgende Gliederung: 

Zunächst werden die 

2. Anforderungen 

erläutert. Sie stellen die Rahmenbedingungen der Arbeit dar und 

ergeben sich aus den Zieldefinitionen. Im Anschluss erfolgen die 

Analyse und die Synthese der verwendeten 

Diese werden mittels der im Kapitel 

3. Prozessmodelle. 

4. Werkzeugumgebungen 

vorgestellten Tools implementiert. Der daraus resultierende 

5. Prototyp 

wird im gleichnamigen Kapitel vorgestellt. Er bettet die Ergebnisse der 

Synthese in eine entsprechende Umgebung ein. Das Resultat wird in 

6. Bewertung der Integration nach CMMI 

auf das Erreichen der definierten quantitativen Ziele überprüft. In der 

7. Zusammenfassung 

erfolgt eine Resümee der gesammelten Erkenntnisse, eine kritische 

Betrachtung der Integrationsergebnisse des Prototypen und eine 

Einschätzung des V-Modells XT auf Basis der während der Arbeit 

gewonnen Erkenntnisse. 



>> 

7 

7

Anforderungen 

2 Anforderungen 

Aus den Zielen der Arbeit lässt sich eine Reihe von Anforderungen 

ableiten. Sie spezifizieren die Voraussetzungen und 

Rahmenbedingungen und lassen sich in drei Kategorien unterteilen: 

1. Anforderungen an die Modelle: Sie müssen von den 

verwendeten Prozessmodellen, hier RUP und V-Modell XT, 

erfüllt sein, damit die Integration stattfinden kann. 

2. Anforderungen an die Integration: Hierbei handelt es sich um 

Anforderungen allgemeiner Art an die vorzunehmende Arbeit. 

3. Anforderungen an die integrierte Lösung als Prozessmodell: Da 

die entwickelte Lösung wiederum ein Prozessmodell darstellt, 

hat sie zusätzlich zu den allgemeinen eine Reihe an speziellen 

Anforderungen zu erfüllen. 

2.1 Anforderungen an die Modelle 

Die Prozessmodelle müssen eine ähnliche 

• Zielsetzung 

verfolgen, hier die Systementwicklung, sowie einer vergleichbaren 

oder austauschbaren 

• Entwicklungs-Philosophie 

o Wasserfall 

o Spiralmodell 

o Zyklisches Modell 

folgen. Nur so sind per Definition unüberbrückbare Differenzen 

zwischen den Modellen an sich zu vermeiden. 



>> 

8 

8


Zudem ist es ein großer Vorteil, wenn sie sich auf Grund ihrer 

• technologischen Beschaffenheit (zum Beispiel in Form von 

Html-Seiten realisiert) 

grundsätzlich für eine Integration eignen. Ansonsten müsste das 

Wissen des einen Modells extrahiert und in dem anderen implementiert 


Da eine Integration immer nur Sinn macht, wenn das Basismodell 

durch die Fähigkeiten oder Vorteile des anderen Modells erweitert 

wird, sollten sie sich inhaltlich z.B. in der Detaillierung oder vom 

Umfang her unterscheiden. Optimal ist eine unterschiedliche 

Schwerpunktsetzung, da man dann potenziell gute Synergieeffekte 

durch die Kopplung der beiden Modelle erzielen kann. 

2.2 Anforderungen an die Integration 

An die Integration der beiden Modelle stellen sich bestimmte 

Anforderungen. Sie bestehen aus den den Besonderheiten der 

verwendeten Modelle und allgemeinen Anforderungen an 

Entwicklungen in der Informatik. Zu ihrer Definition hat sich das 

FURPS 2 Modell etabliert, das Anforderungen wie folgt kategorisiert: 

• Funktionale Anforderungen (Functional Requirements) 

• Benutzbarkeit (Usability) 

• Zuverlässigkeit (Reliability) 

• Performanz (Performance) 

• Wartbarkeit (Supportability) 

2 Das FURPS Modell beschreibt die grundsätzlichen Anforderungen, die 

Entwicklungen in der Informatik erfüllen sollen. FURPS steht für: Functional, 

Usability, Reliability, Performance und Supportability Requirements. 



>> 

9 

9


2.2.1 Funktionale Anforderungen 

Der Rational Unified Process ist ein Industriestandard und unterliegt 

somit keinen normativen und gesetzlichen Eingrenzungen. Er ist 

deshalb grundsätzlich flexibler, wobei natürlich bei der Änderung von 

bestimmenden Charakteristika die Frage zu stellen ist, in wie weit es 

sich noch um den RUP oder um ein neues Prozessmodell handelt. 

Bei dem V-Modell XT handelt es sich um ein Prozessmodell zur IT- 

Entwicklung im Bereich der Öffentlichen Hand der Bundesrepublik 

Deutschland; ein Erlass als europäischer Standard ist angestrebt. 

Die funktionale Anforderung an die Integration ist, dass sie die 

Konformität zum V-Modell Standard wahren soll. Das bedeutet, dass 

die Ausprägung der Erzeugnisse konform zur verabschiedeten 

originären Form des V-Modells sein sollen. 

2.2.2 Benutzbarkeit 

Beide Modelle liegen in Form von HTML Seiten vor, die eine einfache 

Benutzbarkeit garantieren. Die Integration soll diese Benutzbarkeits- 

Aspekte berücksichtigen und soll die Navigation von einem Modell in 

das Andere auf HTML Basis ermöglichen 

2.2.3 Zuverlässigkeit 

Die Integration erfüllt den Anspruch der Zuverlässigkeit auf 

technischer Ebene durch die Verwendung eines HTML Browsers als 

Wiedergabemedium der Inhalte. Die Verknüpfung soll in einer Art und 

Weise erfolgen, die eine eindeutige Zuordnung der einzelnen Elemente 

zu einem Ablauf ermöglichen. Dadurch wird dem Anspruch an 

Vorhersagbarkeit und Wiederholbarkeit der Ergebnisse Rechnung 

getragen. 



>> 

10 

10


Die verwendete Synthese-Methodik soll außerdem Aussagen über die 

Qualität und damit die Zuverlässigkeit der erstellten Mappings 

ermöglichen. Dies bedeutet, dass Aussagen getroffen werden, ob die 

gegenübergestellten Objekte identischer Natur sind oder ob sie 

lediglich eine gewisse inhaltliche Verwandtschaft besitzen. 

2.2.4 Performanz 

Zwei Modelle zu vereinen, bedeutet auch beide Modelle zu 

beherrschen. Dies wiederum erfordert automatisch einen Mehraufwand 

durch zusätzliche Rollen und Aktivitäten, die durch diese ausgeführt 

werden. Im vorliegenden Fall der Integration von V-Modell XT und 

RUP bedeutet dies, dass eine Person oder ein Team für die externe, V- 

Modell konforme Wahrnehmung verantwortlich ist. Dies setzt ein für 

dieses Modell spezifisches Wissen und eine passende Vorgehensweise 

voraus. 

Das restliche Team arbeitet für die Entwicklung des 

Auftragsgegenstandes nach dem RUP, wofür hier ein dementsprechend 

implementierter Prozess, in einer dem Projekt gemäßen Ausprägung, 

Vorraussetzung ist. 

Durch einen integrierten Workflow soll gewährleistet werden, dass die 

Performanz der kombinierten Lösung besser ist als die Erstellung des 

Erfüllungsgegenstandes mittels RUP und die davon getrennte 

Erstellung der V-Modell konformen Dokumentation. 

Der dennoch auftretende Effizienzverlust gegenüber dem Einsatz eines 

alleinigen Modells soll durch einen verbesserten CMMI Reifegrad 

zumindest teilweise wieder wettgemacht werden. 



>> 

11 

11


2.2.5 Wartbarkeit 

Jede Lösung muss gewartet werden, um aktuelle Entwicklungen oder 

Fehlerkorrekturen umsetzen zu können. Bei den hier verwendeten 

Prozessmodellen sind dies getrennte Zyklen. Die auf dem RUP 

basierende Lösung soll einfach mit neuen zukünftigen Inhalten des V- 

Modells gewartet werden können. 

Aus diesem Grund ist vom Zusammenführen einzelner Inhalte der 

beiden Modelle in neue Seiten abzusehen. Die Verknüpfung hat durch 

HTML-Links zu erfolgen, so dass aktualisierte Inhalte des V-Modells 

einfach über die bestehenden Dateien kopiert werden können. Die 

Integration wird damit automatisch auf den neusten Stand gebracht. 

2.3 Anforderungen an die Integration als 

Prozessmodell 

[Walmüller 2001] definiert unter anderem Anforderungen an 

Prozessmodelle, die aus der Perspektive des Qualitätsmanagements zu 

erfüllen sind. Sie ergänzen die im vorherigen Kapitel vorgestellten 

Anforderungen, da sie die im Laufe der Arbeit entstehende integrierte 

Lösung nicht im Sinne eines Produktes, sondern als ein Prozessmodell 

betrachten. 

2.3.1 Vollständigkeit 

Das integrierte Prozessmodell soll alle Phasen und Iterationen der 

Entwicklung umfassen. Das Projektmanagement soll das gesamte 

Projekt begleiten. 

Diese Anforderungen werden erfüllt, da der RUP das zu erweiternde 

Basismodell ist. Er wird den aufgestellten Anforderungen gerecht. 



>> 

12 

12


2.3.2 Modularität 

Der Ablauf soll in getrennte Abschnitte gegliedert sein. Diese 

umfassen Ergebnisbeschreibungen und sollen in einzelne 

Aktivitätsgruppen unterteilt sein. 

Die Anforderung werden durch die Disziplinen des RUP, ihre 

Artefakte und die Gruppierung der einzelnen Aktivitäten zu Workflow 

Details erfüllt. Die integrierte Lösung soll sich diese Strukturen zu 

eigen machen und nutzen. 

2.3.3 Systematik 

Die verwendeten Begrifflichkeiten sollen einheitlich, treffend und gut 

verständlich sein. 

Diese Anforderung wird erfüllt, in dem die integrierte Lösung die 

bereits durch den RUP eingeführten und weit verbreiteten Termini 

nutzt. Zusätzlich werden die Begrifflichkeiten des V-Modells 

verwandt, wenn der RUP keine Entsprechung aufweist. Um die 

Übersichtlichkeit zu fördern wird bei den Erzeugnissen des V-Modells 

der ihm eigene Begriff des Produktes verwendet, während für die 

Ergebnisse des RUP der von ihm verwendete Term des Artefaktes zum 

Einsatz kommt. 

2.3.4 Allgemeingültigkeit 

Es soll sich eine Vielzahl von Projekten durch das integrierte 

Prozessmodell realisieren lassen. Dies umfasst auch ausdrücklich 

kleine Projekte und Sonderprojekte. 

Der RUP wird in seinem vollen Umfang für die vorliegende Arbeit 

verwendet. Das V-Modell in der hier vorgenommenen Integration 



>> 

13 

13


ebenfalls vollständig verwendet. Es ist etwas breiter einsetzbar als der 

RUP, da es zusätzlich die Hardware-Entwicklung umfasst. Dieser 

Bestandteil geht durch die Integration mit dem RUP als Basisprozess 

verloren. Die Anforderung wird durch die integrierte Lösung dennoch 

erfüllt, da beide Prozessmodelle in Projekten unterschiedlicher Größe 

und Form eingesetzt werden können. Die Anpassbarkeit (Tailoring) 

auf Projektspezifika bleibt erhalten. 

2.3.5 Anpassbarkeit 

Die integrierte Lösung soll sich leicht an verschiedene 

Einsatzumstände anpassen lassen. Das umfasst softwaretechnische 

Fortschritte, sowie Anpassungen an Firmenumgebungen und Projekte. 

Die Anforderung wird durch den Tailoring-Mechanismus des RUP 

erfüllt. Neuerungen des V-Modells können in das entsprechende V- 

Modell-Verzeichnis der integrierten Lösung kopiert werden. 

2.3.6 Maschinelle Unterstützung 

Es soll eine Werkzeugunterstützung für die intergierte Lösung 

vorhanden sein, die den gängigen Anforderungen an Softwarelösungen 

entspricht. Sie soll weiterhin direkt aus der Prozessumgebung 

aufrufbar sein. 

Der RUP verfügt über eine Werkzeugunterstützung durch die Rational 

Toolsuite. Die detallierten Anleitungen zu ihrer Benutzung sind bei 

den einzelnen Aktivitäten und Artefakten hinterlegt. Die Werkzeuge 

sind jedoch nicht direkt aus dem RUP ausführbar. Das V-Modell 

verfügt über keinerlei spezifische Werkzeugunterstützung. Damit 

erfüllt die integrierte Lösung diese Anforderung nur teilweise, da die 

Werkzeuge nicht direkt aus der Prozessumgebung ausführbar sind. Die 

Integration der Produkte des V-Modells erfolgt so, dass ihre Templates 

direkt in der Prozessumgebung bearbeitbar sind. Dies ist eine 



>> 

14 

14


Verbesserung gegenüber dem urpsrünglichen V-Modell, das dieses 

Feature nicht bietet. 



>> 

15 

15

Prozessmodelle 

3 Prozessmodelle 

Die inhaltliche Definition eines Prozessmodells ist nach [Rechenberg, 

Pomberger 1999], folgende: 

„Vorgehensmodelle […] dienen zur Benennung und Ordnung von 

produktbezogenen Tätigkeiten bei der Softwareentwicklung.“ 

Es soll nochmals explizit betont werden, dass Prozessmodelle eine 

generische Komponente, die für eine Allgemeingültigkeit innerhalb 

gewisser Rahmenbedingungen sorgt, umfassen. Dies ist eigentlich 

durch das Wort Modell und der damit einhergehenden Abstraktion der 

Realität im Namen automatisch definiert. Die oben stehende Definition 

ließe sich aber auch auf einen Prozess an sich anwenden. 

Den Inhalt einer Definition ohne die damit verfolgten Ziele zu 

betrachten, wäre aber ebenso falsch wie die Beschreibung der 

Medikation ohne die damit zu heilenden Symptome in der Medizin. 

Der Grund für den Einsatz von Vorgehensmodellen liegt darin, 

Projekte oder Produktentwicklungen möglichst zuverlässig innerhalb 

des definierten Zeitrahmens, mit den veranschlagten Ressourcen und 

damit im Budgetrahmen zu realisieren. 

Es existieren drei stark unterschiedliche Philosophien, die in Modellen 

zur Softwareproduktion zurzeit eingesetzt werden: 

• Das Phasen- oder Wasserfallmodell ist ein lineares 

Vorgehensmodell. 

• Das zyklische Modell adressiert die Dynamiken, Komplexität 

und Unvorhersehbarkeiten, welche die moderne IT- 

Entwicklung kennzeichnen. Modelle, die dieses Konzept 

implementieren, werden als iterativ oder inkrementell 

bezeichnet [Rechenberg, Pomberger 1999]. 

• Eine Weiterentwicklung des Spiralmodells in Form des agilen 

Konzeptes. 

Das Wasserfallmodell gilt in der heutigen Zeit als überholt und wird 

daher immer seltener verwendet. Es ist allerdings noch in der Praxis in 



>> 

16 

16


verschiedenen Variationen anzutreffen. Der grundsätzliche Ablauf ist 

wie folgt: 

Abbildung 2: Grundkonzept des Wasserfallmodells 

Oben stehende Grafik soll nur den Grundgedanken vermitteln und 

keine Festlegung auf die Bezeichnung sein, wie viele Schritte zu 

erfolgen haben oder ob es zu Rückschritten kommen kann, da in der 

Fachliteratur keine allgemein gültige Definition zu finden ist (vgl. 

[Rechenberg, Pomberger 1999], [Steinbuch, Steinbuch 1999] und 

[Kruchten 2004]). 

Das Problem bei dieser Vorgehensweise ist, dass Unzulänglichkeiten, 

z.B. bei den Anforderungen, der Architektur oder der 

Implementierung, unter Umständen erst zum Zeitpunkt von Integration 

und Test erkannt werden. Wie in [Grundmann, Alth 2003] geschildert, 

kann das bei architektonischen Problemen bedeuten, zurück in den 

Produktentwurf gehen zu müssen oder das Ergebnis fehlerhaft zu 

liefern. Daneben existieren weiterhin die in der Einleitung 

angesprochenen Probleme, wie beispielsweise die sich ändernde 

Einsatzumgebung bei Projekten mit langer Laufzeit oder die 

unbekannte Komplexität. 

Aus den angesprochenen Problemen folgt als logische Konsequenz der 

Einsatz robusterer Vorgehensmodelle, da man nicht davon ausgehen 

darf, dass das Ergebnis unumstößlich richtig ist, wenn Berechnung, 

Erkenntnisse, Annahmen oder Anforderungen fehlerhaft sein können. 



>> 

17 

17


Der zyklische Ansatz in Form des iterativ/inkrementellen Modells 

berücksichtigt das: 

• Er versucht nicht, alles auf einmal zu erfassen und damit 

Entscheidungen zu treffen, die eventuell noch gar nicht möglich 

sind. 

• Er versucht, Änderungen und Unwägbarkeiten bestmöglich zu 

berücksichtigen, indem er über den kompletten Lebenszyklus 

hinweg offen und flexibel für neue Erkenntnisse und Probleme 

bleibt. 

Der Projektablauf ändert sich durch die Umstellung von einem 

sequenziellen auf einen zyklischen Ablauf folgendermaßen: 

Abbildung 3: Vergleich der Prozessabläufe bei zyklischer Entwicklung und 

Wasserfall Vorgehensweise 

Zusammenfassend ein plakatives Beispiel für den Unterschied 

zwischen einem zyklischen Prozess und einem Wasserfall-Prozess am 

Beispiel des Fahrradfahrens: 



>> 

18 

18


Abbildung 4: Wasserfall- und zyklisches Vorgehen im Vergleich 

3.1 Analyse der verwendeten 


Aufgabe dieser Arbeit ist es, zwei Vertreter des iterativ/inkrementellen 

Ansatzes zu verknüpfen. Sie entsteht auf der Basis des Rational 

Unified Process in der Version 2003.06.13 und dem V-Modell XT in 

der Version 0.9. Dies ist eine Vorabversion, die nach der Abnahme 

durch das Bundesministerium des Inneren veröffentlicht wurde und 

dazu dient, Interessenten einen Blick vorab zu gewähren, sowie Fehler 

in einem „Public Review“ auszumerzen. 



>> 

19 

19


3.1.1 Rational Unified Process 

Der Rational Unified Process ist eine Implementierung des Unified 

Process, der in „The Unified Software Development Process” 

[Jacobson, Booch, Rumbaugh 1999] vorgestellt wird. 

Die wesentlichen Eigenschaften des RUP sind damit: 

• Iterativ und risikogesteuert: 

Iterationen werden auf Grundlage der größten Risiken geplant. 

Sie werden dadurch zuerst angegangen und das Projektrisiko 

sinkt. 

Abbildung 5: Risikoverlauf eines Projektes: iteratives und 

Wasserfallvorgehen im Vergleich 

• Use Case getrieben, da sie die Anforderungen an das System 

dokumentieren und es im Kontext der Umgebung abbilden. Sie 

sind die Grundlage des Entwicklungszyklusses. 

• Architekturzentrisch: Das Software Architecture Document ist 

das zentrale Artefakt. Es dient dazu, das System zu 

konzeptionieren, zu verwalten, zu bauen und 

weiterzuentwickeln. Es stellt verschiedene Sichten zur 

Verfügung, um den Ansprüchen der verschiedenen Stakeholder 

gerecht zu werden. 



>> 

20 

20


Der RUP ist zweidimensional organisiert: 

Abbildung 6: Organisation des RUP (Quelle: [RUP 2003]) 

Auf der vertikalen Achse finden sich die als „Disciplines“ 

bezeichneten Aufgabengebiete wieder. Horizontal abgebildet ist der 

zeitliche Projektverlauf. Er untergliedert sich in Phasen und 

Iterationen, wobei eine Phase 1+n Iterationen umfasst. 

Eine Phase wird durch das Erreichen eines Meilensteins 

abgeschlossen: 

Abbildung 7: Phasen des RUP und ihre Meilensteine 

Die Disziplinen dienen als Container, um die Aktivitäten eines 

Prozesses zu organisieren. Sie ordnen die beinhalteten „Workflow 

Details“ und setzen sie in einen zeitlichen Zusammenhang. Ihr „Core 

Workflow“ beschreibt den Ablauf der Tätigkeiten auf hohem Niveau: 



>> 

21 

21


Abbildung 8: RUP Disziplin am Beispiel der Business Modeling Discipline 

(Quelle: [RUP 2003]) 

Die einzelnen Aktivitäten werden in diesem Diagramm als „Workflow 

Details“ bezeichnet. Sie enthalten die einzelnen Aktivitäten mitsamt 

einer Artefakt- und Rollen-Zuordnung: 



>> 

22 

22


Abbildung 9: Workflow Detail am Beispiel von Assess Business Status (Quelle: 

[RUP 2003]) 

An der Darstellung, insbesondere der Disziplinen, zeigt sich sehr gut, 

dass der RUP Aktivitäten orientiert ist. Die Gliederung des kompletten 

Prozessmodells erfolgt dadurch aufgaben- und tätigkeitsbezogen. Die 

erzeugten Artefakte sind keine Zielvorgabe, sondern die 

Dokumentation des durchlaufenen Prozesses und der gewonnenen 

Erkenntnisse. 

Der Inhalt des RUP wurde in Projekten über 20 Jahre gesammelt (vgl. 

[Kruchten 2004]) und baut durch die Betonung auf seine „Best 

Practices“ stark auf dieses Wissen. Dies ist nicht nur innerhalb von 

Rational gesammeltes Wissen, sondern implementiert auch 

Erkenntnisse anerkannter Institutionen wie dem Software Program 

Manager’s Network (vgl. [Kruchten 2004]). Dies ist aber kein 

abgeschlossener Prozess, sondern ein Konzept, das sicherstellt, dass 

der RUP auf dem aktuellen Stand der Dinge und offen für kommende 

Entwicklungen und Erkenntnisse bleibt. Auf der openArchitecture 

Konferenz Anfang Dezember 2004 führt Philippe Kruchten in seiner 

Key Note beispielsweise aus, wie zukünftig Methoden (ATAM, 

SAAM) des Software Engineering Institute zur Evaluierung von 

Software Architekturen auf Basis qualitativer Eigenschaften, 

Anwendungsszenarien und anderen Techniken in den RUP integriert 




23 

Software Program 

Manager’s network: 

www.spmn.com 

Software 

Engineering Institute 

(SEI): 

www.sei.cmu.edu 

>> 

23


3.1.2 V-Modell XT 

Das V-Modell XT ist eine Weiterentwicklung des V-Modell 92 (1992) 

und des V-Modell 97 (1997). Die beiden Vorgänger waren 

wasserfallorientiert. Mit der Version XT wurde eine 

Weiterentwicklung in Auftrag gegeben, die die aktuellen Erkenntnisse 

in puncto Prozessmodellen und die Erfahrung, die man aus der Historie 

gewonnen hat, zusammenführt. Um dies zu ermöglichen, wurde das 

Modell im Aufbau komplett überarbeitet und ist von den Abläufen und 

Möglichkeiten nicht mit den Vorgängern vergleichbar. 

Die wesentlichen Eigenschaften des V-Modell XT sind: 

• Vertikal unabhängig und integriert, da es sowohl auftraggeberwie 

auftragnehmerseitig eingesetzt werden kann und diese 

Projekttypen eine eingegliederte Schnittstelle zum anderen Typ 

besitzen. 

• Flexibel im Ablauf, da sowohl inkrementelle als auch agile 

Vorgehensweisen berücksichtigt werden. 

• Modular: Fallspezifisch kann es verschiedene als 

Vorgehensbausteine bezeichnete Entwicklungs-Komponenten 

umfassen und auftraggeber- oder auftragnehmerseitig 

eingesetzt werden. 

Das V-Modell ist über Entscheidungspunkte genannte Meilensteine 

organisiert: 



>> 

24 

24


Abbildung 10: Entscheidungspunkte des V-Modell XT (Quelle: [V-Modell XT 

2004]) 

Diese Meilensteine sind verschiedenen Projekttypen zugeordnet. Sie 

definieren somit die Menge der zu erarbeitenden Produkte, während 

die zeitliche Anordnung den Projektdurchführungsstrategien obliegt. 

Damit existiert mindestens eine Strategie pro Typ, auf Seiten der 



>> 

25 

25


Systementwicklung auf Auftragnehmerseite sogar fünf, wovon sich 

drei mit der Entwicklung neuer Systeme beschäftigen: 

Abbildung 11: Projektdurchführungsstrategien (Quelle: [V-Modell XT 2004]) 

Führt man all dies zusammen, ergibt sich beispielsweise für die 

Komponentenbasierte Systementwicklung eines Auftragnehmers 

folgender Entwicklungsumfang und Ablauf: 



>> 

26 

26


Abbildung 12: Komponentenbasierte Systementwicklung eines Auftragnehmers 

(Quelle: [V-Modell XT 2004]) 

Der Unterschied zwischen einer Inkrementellen 

Projektdurchführungsstrategie und einer Komponentenbasierten 

besteht darin, dass bei letzterer die Bestandteile nicht zwangsläufig 

selber entwickelt werden müssen, sondern fertige Module in das 

System integriert werden können. 

Ein großer Unterschied besteht bei der Agilen Entwicklungsstrategie, 

die nicht top-down, sondern bottom-up vorgeht: 

Abbildung 13: Agile Systementwicklung eines Auftragnehmers (Quelle: [V- 

Modell XT 2004]) 

Der Meilenstein „Änderungsplan festgelegt“ dient als Schnittstelle 

zwischen Auftragnehmer und Auftraggeber. Hier wird der 

Projektstatus berichtet und Entscheidungen getroffen, die seitens des 

Kunden zustimmungspflichtig sind. 



>> 

27 

27


Abbildung 14: Auftraggeber - Auftragnehmer Schnittstelle (Quelle: [V-Modell 

XT 2004]) 

Die Vorgehensbausteine dienen dazu, sowohl die Produkte als auch die 

Aktivitäten zu deren Erzeugung und die beteiligten Rollen zu bündeln 

und festzulegen. Der Formalismus der Entwicklung ist durch das 

Auswählen verschiedener Vorgehensbausteine steuerbar. Eine 

Empfehlung wird seitens des V-Modell Projektassistenten anhand 

verschiedener Projektmerkmale ausgesprochen. Um V-Modell 

konform zu sein, ist lediglich die Verwendung des V-Modell Kerns 

verpflichtend. Dieser besteht aus vier Bausteinen. Die anderen 



28 

V-Modell Projektassistent: 

www.kbst.bund.de/V 

-Modell/V-Modell- 

XT- 

,306/Projektassisten 

t.htm 

>> 

28


dreizehn sind optional und teils auch nur in bestimmten Projekttypen 

verwendbar. 

Abbildung 15: Übersicht der Vorgehensbausteine des V-Modell XT 

Das V-Modell XT ist im Gegensatz zum RUP produktzentrisch: 

„Produkte stehen im Mittelpunkt des V-Modells. Sie sind die zentralen 

Projektergebnisse.“ 3 . Dies ist notwendig, um den Anspruch „als 

Vertragsgrundlage, Arbeitsanleitung und Kommunikationsbasis“ 4 zu 

erfüllen. 

3 Quelle: [V-Modell XT 2004], Teil 1, S.19 

4 Quelle: [V-Modell XT 2004], Teil 1, S.5 



>> 

29 

29


Eine Besonderheit ist, dass es das Vorgehensmodell für IT- 

Entwicklungen von und für die Öffentliche Hand ist. Der bindende 

Erlass soll Anfang 2005 erfolgen. Die finale Version des V-Modell XT 

soll am 4. Februar 2005 veröffentlicht werden. 

3.2 Analyse der Life-Cycles 

Prozessmodelle kennen grundsätzlich zwei Dimensionen: 

• Die horizontale Struktur: Sie bezeichnet den Life-Cycle 

genannten zeitlichen Ablauf. 

• Die vertikale Struktur: Der architektonische Aufbau von einem 

abstrakten Metamodell zu den mit Wissen gefüllten Entitäten 

und deren konkrete Instanzierung zu einem Prozess. 

Die in den vorherigen Kapiteln bereits kurz angesprochenen Begriffe 

des zyklischen Modells und seiner iterativen und inkrementellen 

Vorgehensweise sollen hier, wegen ihrer gemeinsamen Einordnung in 

dasselbe Lebenszyklusmodell, genauer beleuchtet werden. Es gilt 

dabei die Gemeinsamkeiten und Unterschiede der beiden Varianten 

festzustellen. Dies soll eine Aussage erlauben, ob der Teil des 

Lebenszyklus des V-Modells, der sich mit der Entwicklung 

beschäftigt, durch den Lebenszyklus des RUP ersetzt werden kann. 

Eine Einordnung des Agilen Konzeptes wird hier nur am Rande, 

soweit für die vorliegende Arbeit interessant, vorgenommen. 

Das zyklische Modell definiert, dass die Entwicklung in mehreren 

wiederholenden Abläufen stattfindet. 

In der Vorstellung der beiden Modelle wurde dargelegt, dass der RUP 

von sich sagt, er sei iterativ und inkrementell, während das V-Modell 

eine inkrementelle oder agile Vorgehensweise vorsieht. 

Eine einheitliche Abgrenzung der Begriffe iterativ und inkrementell 

mit der Herausarbeitung der Unterschiede ist in der Literatur nicht zu 

finden. Darum soll hier eine Klärung vorgenommen werden, die 



>> 

30 

30


zumindest für die verwendeten Modelle Gültigkeit hat. Dazu wurden 

zwei maßgebliche Autoren der Prozessmodelle befragt. 

Prof. Philippe Kruchten (Ph. D, P. Eng.), Professor für Software 

Engineering an der University of British Columbia und ehemals als 

Director of Process Development für die Entwicklung des RUP 

verantwortlich, führt aus, dass iterative Entwicklung bedeute, eine 

Menge an Aktivitäten wiederholt innerhalb des kompletten 

Entwicklungszyklusses auszuführen. Das hätte zur Folge, dass die 

Ergebnisse in Form von Artefakten nicht endgültig seien, da sie die 

Erkenntnisse der jeweils abgelaufenen Aktivitäten wiederspiegeln. 

Weiterhin sagt er, der RUP sei inkrementell, da durch das wiederholte 

Durchlaufen derselben Aktivitäten den Artefakten weiterer Inhalt 

hinzugefügt würde. Wäre dies nicht der Fall, so würden sie in jeder 

Iteration neu erstellt werden. 

Da die Artefakte somit keine Zieldefinition darstellen, sind andere 

Metriken erforderlich, um ein bestimmtes Entwicklungsstadium zu 

definieren und den Ablauf steuern zu können. Dies wird im RUP durch 

das Eliminierung von Risiken und die graduelle Vervollständigung der 

Anforderungen und Architektur realisiert. 

J. Prof. Dr. Andreas Rausch, der das V-Modell XT federführend 

entworfen hat, beschreibt die in dem Prozessmodell verwendete 

Definition für die Inkrementelle und Komponentenorientierte 

Projektdurchführungsstrategie wie folgt: 

Inkrementell bedeute, der Kern der Anforderungen sei definiert und 

fixiert. Für die folgende Entwicklung sei damit die Dimension der zu 

erledigenden Arbeit bekannt und sie ist anschließend in Teilstücken zu 

realisieren. 

Die „Agile Prozessdurchführungsstrategie“ hat laut Rausch das 

Konzept keiner fest definierten Anforderungen mittels einer 

evolutionären Entwicklungsphilosophie implementiert. 

Man kann an den beiden Aussagen und an der Organisation der 

Modelle sehr gut sehen, dass hier grundsätzlich unterschiedliche 

Sichtweisen aufeinanderprallen. Prof. Kruchten bezieht sich auf 

Abläufe, während J. Prof. Dr. Rausch von Arbeitsergebnissen und 



31 

University of British 

Columbia 

www.ubc.ca 

>> 

31


deren Definition spricht. Die Modelle sind dementsprechend 

organisiert: 

• Im RUP wird der Ablauf über Disziplinen definiert, die 

einzelne Aktivitäten in einen Zusammenhang setzen. 

• Beim V-Modell werden die Abläufe über Meilensteine, die eine 

gewisse Menge an Produkten und deren Fertigstellungsgrade 

definieren, festgelegt. 

Was bedeutet das nun für die vorzunehmende Arbeit der Integration? 

Zunächst ist sehr interessant, dass das V-Modell verschiedene 

Entwicklungskonzepte anbietet. Im Umkehrschluss bedeutet dies, dass 

es nicht auf ein Grundmodell festgelegt ist. Prinzipiell ist das eine 

hervorragende Voraussetzung für eine Integration und erlaubt damit 

automatisch eine Einbindung des RUP-Lebenszyklusses. Zudem ist 

gerade die unterschiedliche Schwerpunktlegung ein Vorteil, da sie 

meistens besonders elementar ist und hierdurch Konflikte vermieden 


Im Endeffekt sind die Definitionen sogar sehr ähnlich, denn auch die 

beim V-Modell verwendete Definition von inkrementell erfordert das 

wiederholte Durchlaufen einzelner Tätigkeiten. 

Ein kleiner Konflikt tut sich beim Anforderungsmanagement auf. Der 

RUP erfasst in seiner orginären Form Anforderungen während der 

Inception Phase so gut wie möglich, um sie in den darauffolgenden 

Iterationen zu präzisieren und anzupassen. Er nimmt damit einen Platz 

zwischen dem inkrementellen und dem agilen Modell des V-Modells 

ein. Um diese Flexibilität zu erhalten, müssen die Anforderungen im 

Lastenheft nur auf den Kern beschränkt werden. Ansonsten muss der 

RUP diese als gegeben hinnehmen und kann eines der häufigsten 

Probleme in der Entwicklung, das der sich über die Projektlaufzeit 

ändernden Anforderungen, nicht mehr adressieren. 

Die Integration ist somit von Seiten der Life-Cycles kein Problem. Die 

Flexibilität des Entwicklungsprozesses ist jedoch nicht nur eine Frage 

der Philosophie, sondern hängt auch vom vertraglichen Rahmen ab. 



>> 

32 

32


3.3 Analyse der Metamodelle 

Metamodelle zeigen die den Prozessmodellen zugrundeliegenden 

Strukturen. Die Object Management Group (OMG) spezifiziert in der 

Software Process Engineering Metamodel (SPEM) Specification 

verschiedene Ebenen der Modellierung [SPEM 2002]. Die hier 

vorgestellten Modelle wurden bis jetzt auf der Ebene M1 besprochen. 

Abbildung 16: Vertikale Struktur eines Prozessmodells nach SPEM (Quelle: 

[SPEM 2002]) 

Dieses Kapitel stellt im Folgenden die auf der Ebene M2 liegenden 

Grundstrukturen der Modelle vor. 

3.3.1 Rational Unified Process 

Der RUP bedient sich zur Definition seines Metamodells der UML. 

Dies ist naheliegend, da der Unified Software Development Process in 

[Jacobson, Booch, Rumbaugh 1999] dies so vorgibt. In der Realität hat 

dies einige Vorteile, da die UML dazu geschaffen wurde, Beziehungen 

und das Verhalten von Objekten zu beschreiben und zu visualisieren. 

Das Format ist in der Informatik weit verbreitet und wird von vielen 

Leuten für Analyse und Design von Modellen eingesetzt. 



OMG: 

www.omg.org 

>> 

33 

33


Das „Process Model“ besteht zunächst aus einer Komposition 

mindestens einer Komponente, die sich wiederum in eine Komposition 

aus mindestens einem Element untergliedert. Per Vererbung werden 

hieraus strukturelle und verhaltensorientierte Elemente klassifiziert. 

Diese Ordnung dient hauptsächlich der Organisation des RUP oder 

eines Plugins: 

Abbildung 17: Packaging Übersicht (Quelle: [RUP 2003]) 

Die „First Class Elements“ genannten Prozesselemente bilden die 

Grundlage für die Wissensbasis. Ihre Beziehungen spezifizieren 

Navigationsmöglichkeiten, Verantwortlichkeiten und in großem Maße 

auch die Informationstypen, die in dem daraus gebildeten 

Prozessmodell abrufbar sein müssen. 



>> 

34 

34


Abbildung 18: Metamodell des RUP (Quelle: [RUP 2003]) 

Eine Rolle führt hier eine Ansammlung von Aktivitäten aus. Einer 

Aktivität sind ein oder mehrere Eingangs- und Ausgangsartefakte 

zugeordnet. Einem Artefakt ist wiederum genau eine Rolle in 

verantwortlicher Position zugewiesen, während beliebig viele Rollen 

es verändern können. Alle verwendeten Assoziationen sind 

ungerichtet, weshalb alle Aussagen auch im Umkehrsatz gültig sind. 

Der RUP hat weiterhin eine Anzahl an „Second-Class Elements“. Sie 

unterstützen den gelebten Prozess durch ein Vielzahl an 

Hilfestellungen und Vorlagen. 



>> 

35 

35


Abbildung 19: Second-Class Elements des RUP (Quelle: [RUP 2003) 

Oben stehendes Diagramm zeigt für welche Entitäten Elemente 

zweiter Klasse zur Verfügung stehen. 

3.3.2 V-Modell XT 

Das dem V-Modell zugrunde liegende Format ist ein XML Schema 

(XSD). Es ist auf Grund des Umfangs als Diagramm im Anhang C 

abgedruckt. Das XSD beinhaltet in Relation zum benötigten 

Seitenumfang wenige Informationen und ist zudem für Menschen nicht 

intuitiv verständlich. Deshalb transformiert das V-Modell XT Team in 

seiner Dokumentation Teile des XSDs in eine UML Darstellung, um 

die zugrundeliegenden Strukturen zu erläutern. Sie werden an dieser 

Stelle gezeigt. Leider sind sie durch die Erweiterung der Produkte um 



36 

XSD: 

www.w3.org/XML/Sc 

hema 

>> 

36


zusätzliche Parameter nicht vollständig UML konform. Diese 

Parameter sind: 

• I: Initial. Diese Produkte werden nur einmalig erstellt, und 

nicht verändert. 

• E: Extern. Diese Produkte werden von außerhalb eingebracht 

und unterliegt nicht dem vom V-Modell definierten Prozess. 

Ein Vorgehensbaustein regelt maßgeblich den Umfang der 

Entwicklung, da alle Bausteine zusammen die Rollen, Produkte und 

Aktivitäten der Entwicklung definieren. 

Abbildung 20: Definition eines Vorgehensbausteins (Quelle: [V-Modell XT 

2004]) 

Die Projektdurchführungsstrategie ordnet die Meilensteine an, die 

durch eine Anzahl von Produkten im Zustand „fertig gestellt“ definiert 

sind. 

Abbildung 21: Definition Projektdurchführungsstrategie (Quelle: [V-Modell XT 

2004]) 

Diesen Zustand erlangen die Produkte nach folgendem Ablauf: 

Abbildung 22: Zustände eines Produktes (Quelle: [V-Modell XT 2004]) 



>> 

37 

37


3.3.3 Fazit der Metamodell Vorstellung 

Die folgende Darstellung ist der Übersichtlichkeit halber auf die hier 

wesentlichen Elemente beschränkt. Ein vollständiges Diagramm des 

V-Modell Metamodells ist im Anhang C abgedruckt, das RUP 

Metamodell ist in Kapitel 3.3.1 RUP Metamodell abgebildet. 

Eine Umformung der beiden Metamodelle lässt die Ähnlichkeiten gut 

erkennen: 

Abbildung 23: Metamodelle im Vergleich 



>> 

38 

38


Der bedeutendste Unterschied ist, wie bereits in den vorherigen 

Kapiteln angesprochen, die Produktzentrierung des V-Modells, die 

sich auch hier widerspiegelt: 

Der RUP ordnet Aktivitäten, Artefakte und Rollen sich gegenseitig zu, 

während beim V-Modell ausschließlich vom Produkt ausgehend eine 

Rollen- und Aktivitätenzuordnung vorgenommen werden kann. Dies 

zeigt sich auch in der Prozessumgebung (SPEM Ebene M1): Das V- 

Modell bietet keine Möglichkeit, die Aktivitäten einer Rolle 

festzustellen, es sei denn man navigiert das Produkt an und lässt sich 

dessen Aktivitäten ausgeben. 

Weiterhin kennt das V-Modell Teilaktivitäten und Themen eines 

Produktes. Diese Untereinheiten werden im RUP nicht extra 

modelliert, da alle Informationen einer Activity oder eines Artifacts 

mittels HTML-Verknüpfungen innerhalb der jeweiligen Seite 

erreichbar sind. 

Das Workflow Detail ähnelt auf Metamodell Ebene der 

Aktivitätsgruppe, während eine Disziplin gleich einem 

Vorgehensbaustein zu sein scheint. Letzterer ist in der Dokumentation 

des Prozessmodells jedoch nicht verfügbar und damit auch nicht 

verknüpfbar. Eine gesonderte Gliederung der Produkte zu einer 

Produktgruppe findet beim RUP nicht statt. 

Die einzelnen Attribute der Klassen sind in Abbildung 23 nicht 

abgebildet. Aus den beiden vorhergehenden Kapiteln ist jedoch 

ersichtlich, dass das Metamodell des RUP in der derzeitigen Version, 

im Gegensatz zum V-Modell, keine definierten Bearbeitungszustände 

von Artefakten umfasst. Eine Qualitätssicherung durch Review- 

Aktivitäten und die Test-Disziplin sichert das Erreichen eines 

gewünschten Zustandes zum Ende einer Iteration. Ein Nicht-Erreichen 

würde entsprechend in der nächsten Iteration thematisiert werden. Das 

Ergebnis der Prüfung wird somit nicht im Artefakt selbst hinterlegt, 

sondern spiegelt sich im Ablauf der nächsten Iteration oder anderen 

Artefakten, wie der Risk List beispielsweise, wieder. 

Weiterhin sind die Konzepte der initialen und externen Produkte nicht 

auf Metaebene der RUP implementiert. 



>> 

39 

39


Die unterschiedlichen Projektdurchführungsstrategien sind für den 

RUP auf Metamodelle Ebene ebenfalsl kein Thema, hier wurde die 

iterative Strategie fest implementiert (Abbildung 18). 

Was bedeutet das für die vorzunehmende Arbeit der Integration? 

Das Wissen der Prozessmodelle liegt überwiegend auf der Ebene der 

Artefakte/Produkte, Aktivitäten und Rollen. Die Hauptaufgabe der 

darüberliegenden Elemente gliedernder Natur. 

Damit empfehlen sich als Anknüpfungspunkt vom RUP in das V- 

Modell die Produkte, Aktivitäten und Rollen gleichermassen. Sie alle 

weisen kleine Unterschiede auf, sind aber im Wesentlichen und vor 

allem in semantischer Hinsicht identisch. Der RUP unterteilt die 

Aktivität-Artefakt-Assoziation zusätzlich in „input“ und „output“, 

während das V-Modell ihre Produkte noch in Produktgruppen gliedert. 

Die Granularität auf V-Modell Seite ist bei den Aktivitäten und 

Produkten zwar etwas feiner, die aggregierten Klassen sind jedoch bei 

einer Integration auf der übergeordneten Produkt- bzw. Aktivitäten- 

Ebene eindeutig zuordbar und stellen somit kein Problem dar. 

3.4 Synthese 

Da in der, dem Autor bekannten, einschlägigen wissenschaftlichen 

Literatur noch nie eine Integration zweier Prozessmodelle 

vorgenommen wurde, muss hier zunächst eine geeignete Methodik 

erarbeitet werden. Dazu ist es hilfreich, zunächst die genaue 

Bedeutung dieses oft verwendeten, aber selten genau verstandenen 

Wortes klarzustellen: 

Methodik kommt aus dem Griechischen (methodike) und bezeichnet 

die „Kunst des planmäßigen Vorgehens“ [Duden 2003]. 



>> 

40 

40


Daraus lässt sich ableiten, was eine Methodik leisten soll: 

• Das Resultat ist wiederholbar durch eine definierte Abfolge an 

Arbeiten. 

• Das Endergebnis ist durch den Weg zu selbigem 

nachvollziehbar. 

• Probleme und Erweiterungsmöglichkeiten durch die einzelnen 

Arbeiten und deren Zusammenhänge nachvollziehbar machen. 

Auf hohem Niveau lässt sich eine Methodik für die Integration 

folgendermaßen umreißen: 

1. Feststellung der genauen Ziele. 

2. Überprüfung, ob Anforderungen verletzt werden und ob und 

wie die Ziele erreichbar sind. 

3. Aufstellung eines Korrelationsmodells, das den oder die 

Anknüpfungspunkte verbindet. 

4. Deduktiver Schluss, der zu Verknüpfungsmatrizen der 

einzelnen Elemente führt. 

Diese Vorgehensweise findet im Folgenden seine Anwendung, wobei 

zur Bearbeitung der einzelnen Punkte jeweils eigene, dem 

Aufgabengebiet entsprechende, Methoden verwendet werden. 

3.4.1 Feststellen des Integrationsziels 

Eine Integration dient generell dazu, die verwendeten Modelle durch 

Zusammenführen und das Ausnutzen dabei entstehender 

Synergieeffekte zu verbessern. Damit sind die Ziele qualitativer Natur. 

Wenn die Ergebnisse zusätzlich messbar sind, so werden sie weiter zu 

quantitativen Zielen präzisiert. Diese Ziele sind in Zahlen erfassbar, 

wodurch das Erreichen sehr gut zu überprüfen ist. 



>> 

41 

41


3.4.1.1 Qualitative Ziele 

Es lassen sich zunächst Ziele bezüglich des Anwendungsgebietes und 

der Werkzeugunterstützung definieren: 

Sowohl das V-Modell, als auch der RUP, können beide frei eingesetzt 

werden. Das V-Modell ist darüber hinaus, wie bereits in den 

vorherigen Kapiteln dargelegt, im öffentlichen Sektor in Deutschland 

zur Verwendung vorgeschrieben. Es ist daher ein Ziel 

• den RUP einsatzfähig für Projekte der Öffentlichen Hand zu 

machen. 

Das V-Modell wiederum verfügt nicht über denselben 

Detaillierungsgrad des RUP im Sinne von Checklisten, Beispielen und 

Leitfäden für einzelne Erzeugnisse und Aktivitäten (vgl. Abbildung 

19). Der RUP wird hingegen durch eine Toolsuite seitens IBM 

Rational direkt unterstützt. Sie erlauben die Automatisierung vieler 

Aufgaben wie des Requirements Tracking oder des Testens. Damit ist 

ein weiteres Ziel, 

• den Produkten und Aktivitäten des V-Modells die 

Unterstützung durch Tools und weiterführende Hilfen des RUP 

zur Verfügung zu stellen. 

Diese Ziele sind nicht in Zahlen ausgedrückt und damit qualitativer 

Natur. 

Zusätzlich zu dem Einsatzspektrum der Lösung und der Unterstützung 

durch Werkzeuge und detaillierte methodische Anleitungen, ist als 

drittes Ziel die potenzielle Effizienz der Prozessmodelle interessant: 

• Die integrierte Lösung soll eine mindestens gleichgute 

Performanz aufweisen wie ein alleiniges Modell. 

Dieses Ziel lässt sich unter Verwendung des Capability Maturity 

Model Integration (CMMI) als Zahlwert formulieren und messen. 



>> 

42 

42


Dieses qualitative Ziel wird darum im nachfolgenden Kapitel in ein 

quantitatives Ziel überführt und verfeinert. 

3.4.1.2 Quantitative Ziele 

Die Qualität eines Prozesses wird in Reifegraden gemessen. Der 

Standard für Reifegradbestimmungen in der Softwareentwicklung ist 

das CMMI. Eine detaillierte Einführung sprengt allerdings den 

Umfang dieser Arbeit. Eine gute Einführung ist in [Kranz 2004] auf 

S.22ff. zu finden. Hier wird der CMMI Bewertung des V-Modell XT 

eine eigene Diplomarbeit gewidmet. Als weiterführende Literatur ist 

[Ahern, Clouse, Turner 2003] empfehlenswert. 

Um den Reifegrad des V-Modells mit dem des RUP vergleichen zu 

können, wird für ersteres auf die gewonnen Erkenntnisse aus [Kranz 

2004] zurückgegriffen. Der Rational Unified Process wurde im 

Rahmen dieser Arbeit bewertet; die detaillierte Beurteilungs-Matrix ist 

im Anhang A abgedruckt. 

Zum Einsatz kommt die Version „CMMI for Systems Engineering and 

Software Engineering“ (CMMI-SE/SW, V1.1), dokumentiert in 

[CMMI 2001]. Sie unterteilt in der „staged“ Variante Prozesse in fünf 

verschiedene Reifegrade (Maturity Levels): 

1. Initial: Der Prozess ist nur schlecht vorhersagbar, kontrollierbar 

und reaktiv. 

2. Managed: Der Prozess ist für Projekte definiert und meist 

reaktiv. 

3. Defined: Der Prozess ist an die jeweilige Umgebung angepasst 

und proaktiv. 

4. Quantitatively Managed: Der Prozess wird anhand quantitativer 

Daten gemessen und gesteuert. 

5. Optimizing: Der Prozess ist durch kontinuierliche 

Verbesserung selbstoptimierend. 



>> 

43 

43


Die Bewertungen des RUP und des V-Modell XT beziehen sich beide 

auf diese Sicht. 

Als Anhaltspunkt für die Verbesserungen, die durch eine Aufwertung 

von Maturity Level 1 auf 3 zu erwarten sind, kann man eine Aussage 

von [Reitzig, Miller, West et al. 2003] heranziehen. Sie bezieht sich 

allerdings auf das alte „Capability Maturity Model for Software 

Engineering“ (CMM-SW): 

„Software Organisationen, die auf [CMM-SW] Maturity Level 3 

arbeiten, sind 65% produktiver, produzieren zu 20% geringeren 

Projektkosten, die Laufzeit verringert sich um 20% und die Lösungen 

enthalten 80% weniger Fehler gegenüber denen auf Maturity Level 1. 

Des Weiteren sind die Kosten- und Zeitrahmen-Vorhersagen dieser 

Organisationen besser.“ 5 

Die von beiden Arbeiten verwendete Methode ist an die „Standard 

CMMI Appraisal Method for Process Improvement“ (SCAMPI) 

[SCAMPI 2001] angelehnt. Es handelt sich hierbei um eine Methode, 

die den „Appraisal Requirements for CMMI“ (ARC) der Klasse A 

entspricht. Diese Methoden stellen die höchsten Anforderungen und 

sind alleinig dazu geeignet, Ratings zu Benchmarking Zwecken zu 

generieren ([ARC 2001]). 

Wichtig ist, dass es sich bei SCAMPI eigentlich um eine Assessment 

Methode für Organisationen und deren gelebte Prozesse handelt. Es 

können im Folgenden also nur die potenziellen Möglichkeiten des 

Prozessmodells in einer neutralen Umgebung erörtert werden. Das 

bedeutet, dass das Modell durch organisationsspezifische Anpassungen 

weder verbessert, noch verschlechtert wird und die Organisation 

bestrebt ist, einen CMMI Reifegrad mit dem Modell zu erlangen. 

5 Vom Autor aus dem Englischen übersetzt: “Software organizations operating at 

SW-CMM Maturity Level 3 are 65% more productive than those at SW-CMM ML 1, 

reduce project costs and schedule by 20%, and deliver 80% less defects. CMM ML 3 

organizations also deliver projects with better cost and schedule predictability.” 

Quelle: [Reitzig, Miller, West et al. 2003], S.5 



>> 

44 

44


Unterstützt werden vier Erfüllungsgrade der zu bewertenden Praktiken 

[SCAMPI 2001]: 

1. Fully Implemented: Die Anforderungen sind voll erfüllt. 

2. Largely Implemented: Die Anforderungen sind größtenteils 

erfüllt. 

3. Partially Implemented: Die Anforderungen sind ungenügend 

erfüllt. 

4. Not Implemented: Die Anforderungen sind nicht umgesetzt. 

Eine Praktik gilt als abgedeckt, wenn sie mindestens mit Largely 

Implemented bewerted wird. Die Praktiken werden zu Zielen 

gebündelt, diese wiederum zu Prozessgebieten zusammengefasst. Eine 

Ansammlung an Prozessgebieten ergibt einen Maturity Level. Ist nur 

ein Ziel, und damit ein Prozessgebiet, nicht vollkommen abgedeckt, so 

gilt es als nicht erfüllt. Die Zuordnung lässt sich aus nachstehender 

Grafik entnehmen, in der die Ergebnisse des V-Modells und des RUP 

gegenüber gestellt werden. 

Abbildung 24: CMMI Maturity Level von V-Modell XT und RUP 

Bei den mit „(GG)“ gekennzeichneten Einträgen handelt es sich um 

„Generic Goals“. Sie unterscheiden sich von den spezifischen 

Prozessgebieten darin, dass die generischen Ziele mehreren Gebieten 



>> 

45 

45


zugeordnet werden können. Alle Prozessgebiete einer Ebene müssen 

erfüllt sein, um den entsprechenden Maturity Level zu erreichen. 

Bewertung Rational Unified Process 

Der RUP erfüllt 6 von 8 Prozessgebiete für Maturity Level 2 und 6 von 

12 für Stufe 3. Er bekommt damit einen Maturity Level 1 bescheinigt. 

Die Probleme auf Level 2 liegen in dem Gebiet des Mangements von 

Lieferantenvereinbarungen („Supplier Agreement Management“), das 

schlicht nicht implementiert ist (es ist als ein Feature der nächsten 

Produktversion geplant) und der generischen Praktik 2.5 „Train 

People“, die für das Erfüllen des generischen Zieles „Institutionalize a 

Managed Process“ erfüllt sein müsste. 

Bewertung V-Modell XT 

Die in [Kranz 2004] vorgenommene Bewertung des V-Modell XT 

basiert, ebenso wie diese Arbeit, auf einer Vorabversion. Nach den 

Aussagen von Michael Gnatz, dem Projektleiter des V-Modell Teams 

am Lehrstuhl von Prof. Dr. Dr. Broy an der Technischen Universität in 

München, sind die in der Arbeit von Michael Kranz empfohlenen 

Verbesserungen zum 2. Dezember 2004 noch nicht implementiert. 

Letztlich sei aber eine Ebene 3 Konformität angestrebt. 

Das V-Modell XT unterstützt je eine Praktik in zwei Prozessgebieten, 

die für Level 2 erforderlich sind, nicht bzw. lediglich teilweise und 

bekommt damit Maturity Level 1 bescheinigt. Insgesamt wird 

festgestellt, dass lediglich 9 der 22 Prozessgebiete, die zur Erreichung 

des CMMI Level 5 erforderlich wären, abgedeckt sind. 

Eine zweite auf CMMI basierende Methode, die von Kranz verwendet 

wird, Siemens Process Assessment (SPA), kommt zu einem höheren 

Wert, da sie unvollständige Prozessgebiete mitzählt und lediglich die 

entsprechenden Praktiken mit Null bewertet: 



46 

Technische 

Universität 

München, Lehrstuhl 

Prof. Dr. Dr. Broy: 

www4.in.tum.de 

>> 

46


Abbildung 25: V-Modell XT Beurteilung nach SCAMPI und SPA im Vergleich 

(Quelle: [Kranz 2004]) 

Es handelt sich deshalb nicht um eine ARC Klasse A Methode und ist 

daher für Benchmarkings zwischen Prozessen nicht einsetzbar. 

Methoden wie SPA können nur aussagen, wie nahe man an der 

Erreichung eines bestimmten Reifegrades ist. Es ist wichtig zu wissen, 

dass eine SPA Bewertung von 2,75 trotzdem lediglich einen ARC 

Klasse A Maturity Level 1 darstellen kann (wie beim V-Modell), da 

ein oder mehrere Prozessgebiete auf Ebene 2 nicht erfüllt sind. 

Wenn beispielsweise ein Auto „nur“ Probleme mit den Bremsen hat, 

so ist das Fahren immer noch gefährlich, ganz gleich ob das Leck im 

Benzintank bereits repariert wurde oder nicht. Wenn ein Projekt 

beispielsweise „nur“ wegen fehlerhaftem Anforderungsmanagement 

scheitert, so ist es letztlich nicht erfolgreich gewesen. Ob alle 

weiterführenden Prozessgebiete abgedeckt wurden ist dann irrelevant. 

Quantitatives Ziel 

Betrachtet man die Daten zu Maturity Level 2 in Abbildung 24, stellt 

man fest, dass beide Modelle jeweils die Lücken des anderen schließen 

können. Die jeweiligen Stärken können also potenziell die jeweiligen 

Schwächen in Maturity Level 2 ausgleichen. Auf Ebene 3 sind bei 



>> 

47 

47


beiden Modellen erhebliche Lücken festzustellen, die mit Hilfe einer 

Integration auch nicht geschlossen werden können. Das präzisierte 

quantitative Ziel ist somit: 

• Die Integrierte Lösung soll den potenziellen Reifegrad 

gegenüber den einzelnen Modellen um eine Stufe auf Maturity 

Level 2 anheben. 

3.4.2 Verifikation und Präzision von Ziel und Weg 

Ziel dieses Kapitels ist, die Machbarkeit der im vorigen Kapitel 

aufgestellten potenziellen Integrationswege (Ziele) zu überprüfen. 

Dafür wird im Folgenden ein Regelwerk vorgestellt und angewendet, 

das erlaubt die Verknüpfung von Prozessmodellen zu bewerten sowie 

die Machbarkeit zu beurteilen. 

Es gilt: 

A={Elemente des RUP: Artefakte, Aktivitäten, Rollen, 

Toolmentoren, Guidelines, Checklists,… } 

B={Elemente des V-Modells: Produkte, Aktivitäten, 

Rollen, Methoden Referenzen,…} 

Z={Elemente, die das Ziel der Integration sind} 

S={Elemente, die das Interface zwischen den Modellen 

A und B definieren} 

Bei der Betrachtung von Mengen und Elementen auf Metaebene 

(SPEM Ebene M2) ist in diesem Teil der Arbeit nicht die Verknüpfung 

im Metamodell entscheidend, sondern die Semantik der Metaelemente, 

da sie den Inhalt der auf SPEM Ebene M1 implementierten 

Wissensentitäten definieren. 



>> 

48 

48


3.4.2.1 Machbarkeit der Integration 

Eine grundsätzliche Anforderung an die verwendeten Modelle ist, dass 

sie auf SPEM Ebene M2 nicht disjunkt sein dürfen. Die Metamodelle 

dürfen nicht elementfremd sein, da sonst kein äquivalentes Element für 

eine Verknüpfung vorhanden ist: 

• Die beiden Metamodelle von A und B auf SPEM Ebene M2 

( Ameta und Bmeta ) dürfen nicht disjunkt sein: A meta ∩ Bmeta 

≠ 0 . 

Diese Anforderung erfüllen die beiden Modelle wie Abbildung 23 

zeigt. 

3.4.2.2 Gewinn der Integration 

Ein möglichst großer Unterschied auf SPEM Ebene M1 ist 

wünschenswert, da eine Integration dann Sinn macht, wenn sie Inhalte 

aus einem Modell in das andere transferiert. Daraus folgt: 

• A und B dürfen keine Teilmenge des jeweilig anderen Modells 

sein, da das Ziel der Erweiterung (Ergänzen um Neues) sonst 

nicht erfüllt ist ( A ⊄ B) 

∧ ( B ⊄ A) 

. 

Dies ist für die verwendeten Modelle per Definition gegeben, da keines 

der Ursprung des Anderen ist und ebenfalls keines der beiden Modelle 

mit lediglich anderen Mitteln implementiert wurde. Deutlich wird das 

an unterschiedlichen Produkten/Artefakten, Rollen, Aktivitäten und 

unterschiedlichen Gliederungen der Prozessmodelle. 

3.4.2.3 Ziel der Integration 

In Kapitel 3.4.2.2 wurde ausgeschlossen, dass es sich bei A und B um 

Teilmengen handeln darf. Dies ist gegeben, wenn nur ein a ∈ A 

ausserhalb B oder ein b ∈ B ausserhalb von A liegt. Diese Aussage 



>> 

49 

49


bezieht aber nicht das Ziel der Integration ein. So wäre unter den 

bisherigen Bedingungen eine Menge Z mit der 

Eigenschaft Z = { z | z ∈ A} 

ein gültiges Integrationsziel für B mit A als 

Basis. Das macht natürlich keinen Sinn, weshalb alle Mengen Z 

zusätzlich folgender, erweiterter Definition genügen müssen: 

• Alle gewinnbringenden Zielmengen Z gilt: 

⎧⎪( Z ⊄ A) ∧( Z ⊂ B) Z = ⎨ 

⎪⎩( Z ⊄ B) ∧( Z ⊂ A) für den Fall, für den Fall, dass A Basis ist⎫⎪ 

⎬ 

dass B Basis ist⎪⎭ 

Für diese Arbeit ist der RUP die Basis und das V-Modell stellt die zu 

integrierenden Elemente. Es kommt damit zur Anwendung der ersten 

Definition. 

Die in Kapitel 3.4.1.1 und 3.4.1.2 definierten drei Ziele können wie 

folgt präzisiert und formalisiert werden: 

• Den RUP einsatzfähig für Projekte der Öffentlichen Hand zu 

machen. Die Produkte bilden, wie in Kapitel 3.1.2 dargelegt, 

die Vertragsgrundlage und dienen ebenso als Arbeitsanleitung 

wie als Kommunikationsbasis. Daraus folgt, dass der RUP 

durch die Integration der Produkte die geforderte Eigenschaft 

erhält. Das erste Ziel ist damit: 

Z ={V-Modell XT Produkte, die die Auftragnehmer- 

qualitativ1 

Auftraggeber Kommunikation ermöglichen} 

• Die Produkte des V-Modells durch die zusätzlichen 

Hilfestellungen und Werkzeuganbindungen des RUP zu 

unterstützen. Das zweite Ziel ist: 

Z ={Toolanbindungen und Hilfestellungen des RUP den 

qualitativ2 

Produkten des V-Modells zugänglich machen} 

• Integration des Managements von Lieferantenvereinbarungen 

zur Erreichung des CMMI Reifegrades Ebene 2. Dies umfasst 

Aktivitäten und Produkte, womit das dritte Ziel festgehalten 

werden kann: 

Z ={V-Modell XT Aktivitäten und Produkte, die das 

quantitativ1 

Management von Lieferantenvereinbarungen realisieren} 

• Integration der Aktivitäten und Produkte, die die Generische 

Praktik „Train People“ des CMMI Reifegrades Ebene 2 



>> 

50 

50


erfüllen. Das vierte Ziel ist damit: 

Z ={V-Modell XT Aktivitäten und Produkte, die die 

quantitativ2 

Generische CMMI Praktik „Train People“ erfüllen} 

Z qualitativ1 

erfüllt die geforderten Bedingungen, Zqualitativ2 

jedoch nicht. 

Das Ziel Z ist auf einer globaleren Ebene valide; es ist an dieser 

qualitativ2 

Stelle aber durch die Wahl des RUP als Basis und der breiten 

Anbindung der Produkte, die das Ergebnis der Tools und 

Hilfestellungen sind, bereits impliziert. Damit sind keine zusätzlichen 

Arbeiten im Sinne einer Synthese auszuführen. Dieses Ziel wird 

automatisch bei Erreichen von Zqualitativ1 

als „Synergieeffekt“ erfüllt. 

Z und Z sind nach der verwendeten Definition gültige 

quantitativ1 

quantitativ2 

Ziele, da sie beidesmal Inhalte des V-Modells in den RUP 

transferieren, die nicht bereits vorhanden waren. 

3.4.2.4 Qualität der Zielmenge 

Nachdem die Ziele präzisiert wurden, interessiert als nächstes die 

Qualität. Sie sagt aus, wie und unter welchem Aufwand die Integration 

erfolgen kann und ob eventuelle Reibungsverluste beim 

Zusammenspiel der Modelle auftreten können. 

Es gilt, dass die einzelnen Elemente a von A und z von Z wiederum 

eine Menge an Wissen definieren. Es gelten folgende Qualitätsstufen, 

wobei A als das Basis-Modell, B als das erweiternde Modell und Z als 

die Mengen der zu integrierenden Eigenschaften (Ziele) definiert ist: 

1. Sehr Gut: Die Zielelemente sind ausschließlich inhaltlich neu. 

Alle Elemente haben ein identisches Element a und es 

zmeta meta 

existiert kein Element z , das bereits in A enthalten ist. 

� Die Integration ist automatisch perfekt. 

2. Gut: Die Zielelemente sind inhaltlich entweder detaillierter 

oder auf höherem Niveau als die bereits existierenden bzw. 

inhaltlich neu. 

Alle Elemente haben ein identisches Element a . Es 

zmeta meta 

gibt mindestens ein Element z , das eine Obermenge oder 



>> 

51 

51


Teilmenge eines Elements a ist. Alle restlichen Elemente z 

haben kein identisches Element a . 

6 

� Die Integration erfolgt mit Hilfe eines „Mappings “ unter 

objektiven Gesichtspunkten. 

3. Ausreichend: Die Zielelemente aus B haben inhaltlich 

teilweise leicht andere Ausrichtungen (als Funktion erfasst) als 

die bereits in A existierenden. Sie fassen teils mehrere 

Elemente des Ursprungsmodells zusammen, sind teils 

detaillierter, teils auf höherem Niveau oder inhaltlich neu. 


zmeta meta 

gibt mindestens ein Element z , das mehrere a zusammenfasst 

oder inhaltlich verwandt ist, jedoch eine unterschiedliche 

Funktion hat. Alle restlichen Elemente z haben kein 

identisches a , sind Obermenge oder Teilmenge eines Elements 

a . 

7 

� Die Integration erfolgt mit Hilfe eines „Matchings “ unter 

subjektiven Gesichtspunkten, da das Entsprechen bei 

abweichenden Schwerpunkten, ohne klar an das Element 

definierte Anforderungen, immer auf der persönlichen 

Auffassung fußt. 

4. Mangelhaft: Das von Z formulierte Ziel ist nicht auf einzelne 

Elemente abbildbar, da es jeweils immer nur Auszüge 

übermässig vieler Elemente betrifft oder in den grundlegenden 

Mechanismen des Modells verankert ist. 


zmeta meta 

gibt mindestens ein Element z , das nur Bruchstücke mehrerer 

a zusammenfasst oder das Ziel ist in einem Mechanismus von 

Modell B enthalten und nicht als Element z mit einem 

entsprechenden z definierbar. Alle restlichen Elemente z 

meta 

haben kein entsprechendes a , sind Obermenge oder Teilmenge 

eines Elements a , fassen mehrere a zusammen oder sind 

inhaltlich verwandt, haben jedoch eine unterschiedliche 

Funktion. 

� Da das Ziel nicht klar greifbar ist, kann es nicht durch ein 

alleiniges Matching integriert werden. Als Vorgehensweise ist 

6 Mapping: Gegenüberstellung auf SPEM Ebene 1 identischer Objekte. 

7 Matching: Abgleich inhaltlich verwandter Objekte 



>> 

52 

52


das manuelle Erstellen der nicht fassbaren Aktivitäten oder 

Produkte möglich. Die greifbaren Elemente können 

entsprechend ihrer eigenen Qualität integriert werden. 

5. Nicht Abbildbar: Mindestens ein Zielelement ist von 

grundsätzlich anderer Struktur, so dass es unvergleichbar und 

nicht abbildbar ist. 

∃zmeta 

∉ Ameta 

Es gibt mindestens ein Element zmeta 

, das kein entsprechendes 

hat. 

ameta 

� Eine Integration kann nicht mit Hilfe eines Mappings oder 

Matchings stattfinden, da die technischen Vorraussetzungen für 

eine Abbildung nicht gegeben sind. Es ist jedoch möglich, 

diese Elemente über die Verwendung von Interfaces 

anzubinden. Ihre Verwendung wird im darauf folgenden 

Kapitel erläutert. 

Eine interessante Eigenschaft der Qualitätsstufen ist, dass es einen 

Bezug von Stufe „Nicht Abbildbar“ zu Stufe „Sehr Gut“ gibt: 

Wenn man die fehlende Struktur mittels eines Werkzeugs der 

Prozessmodell-Basis im Modell implementieren kann, erhalten diese 

Elemente automatisch eine sehr gute Qualität. 

Derselbe Weg ist auch bei der Bewertung mit „Mangelhaft“ möglich: 

Wenn man die, durch eine Funktion des Modells ausgeführte, Aktivität 

oder sehr verstreut vorliegenden Aktivitäten oder Produkte 

implementiert, so erhalten diese die Bewertung sehr gut. Die eventuell 

verbleibenden Elemente des Ziels können gemäß ihrer Qualität 

integriert werden. 

Für die folgenden Ausführungen ist die Differenzierung von 

„Mapping“ und „Matching“ wichtig: 

Die Integration auf der Qualitätsstufe „Gut“ erfolgt durch ein 

„Mapping“. Das bedeutet, dass Objekte mit derselben Bedeutung auf 

SPEM Ebene M1 gegenübergestellt werden. Dies wäre z.B. für das 

Artefakt „Work Order“ (RUP) und das Produkt „Arbeitsauftrag“ (V- 

Modell) möglich. 

Die Integration auf der Qualitätsstufe „Ausreichend“ erfolgt durch eine 

„Matching“ Tabelle. Das bedeutet, dass hier inhaltlich verwandte 

Objekte gegenübergestellt werden. Ein Beispiel wäre hier die 



>> 

53 

53


„Unterstützungssystemarchitektur“ (V-Modell) und die „Test 

Automation Architecture“ (RUP). Sie sind nicht gleichbedeutend und 

damit nicht austauschbar, die Test Automation Architecture ist aber 

eine Architektur eines unterstützenden Systems weshalb sie inhaltlich 

verwandt sind. 

Die Qualität des Ziels Z ist als ausreichend einzustufen. Die 

qualitativ1 

Produkte bilden klar abgegrenzte Elemente, jedoch haben sie RUPseitige 

Entsprechungen, die von unterschiedlicher Ausrichtung sind 

und einen unterschiedlichen Detaillierungsgrades aufweisen. 

Die Qualität des Ziele und Z ist zunächst „Nicht 

Zquantitativ1 quantitativ2 

Abbildbar“, da die Metastrukturen für die Teilaktivitäten und Themen 

RUP-seitig nicht existieren. Die anschließenden zwei Kapitel zeigen, 

dass die Aktivitäten und Produkte als Interfaces fungieren können. Sie 

geben den im RUP unbekannten Elementen eine Bedeutung und eine 

Funktion. Unter Berücksichtigung dieser Erkenntnisse kann eine 

erneute Bewertung der quantitativen Ziele erfolgen. 

Die Qualität des Ziels Z ist nun mangelhaft, da die „Generic 

quantitativ1 

Practice“ „Execute Supplier Agreement“ des CMMI nicht durch 

einzelne Aktivitäten oder Produkte erfüllt werden kann; sie ist in dem 

kompletten Projektmanagement des V-Modells implementiert. Damit 

Z trotzdem erfüllt werden kann, müssen die Aktivitäten und 

quantitativ1 

Produkte dieser Praktik im RUP neu implementiert werden. Die 

restlichen Elemente erfüllen den Qualitätsgrad sehr gut, da sie im 

Rational Unified Process bisher nicht abgehandelt wurden. Durch diese 

Neuausrichtung von Z erreicht es insgesamt die Qualitätsstufe 

quantitativ1 

sehr gut. 

Das Ziel Z ist ebenfalls von Mangelhafter Qualität, da die 

quantitativ2 

Durchführung der Trainings in den Mechanismen des V-Modells 

verankert wird. Diese Funktion wird im RUP als eigene Aktivität 

implementiert. Das verbleibende Element der Erstellung von 

Trainingsunterlagen hat eine sehr gute Qualität, da es im RUP bis jetzt 

nicht abgedeckt wird. 



>> 

54 

54


3.4.2.5 Definition der Interfaces 

Um den Übergang von einem Modell in das andere gestalten zu 

können, bedarf es einer Schnittmenge, die auf der SPEM Ebene M2 

liegt. Ihre Existenz wurde in Kapitel 3.4.2.1 festgestellt. Mögliche 

Anknüpfungspunkte liegen in der Menge S meta : 

• Die Schnittmenge der beiden Prozessmodelle, aus denen das 

Interface für die Integration gebildet wird, definiert sich wie 

folgt: S meta = { Ameta 

∩ Bmeta} 

. Als Anknüpfungspunkt kann 

jedes s ∈ S dienen. 

meta 

meta 

Die Aktivitäten und Produkte bilden somit die Interfaces für die 

zugeordneten Teilaktivitäten und Themen. 

3.4.2.6 Verhältnis der Interfaces zur Zielmenge 

Ziel der gefundenen Schnittmengen ist die Anbindung der gefundenen 

Zielmengen Z . Das Verhältnis der Schnittmenge S zur Zielmenge Z 

n 

muss damit folgender Definition genügen: 

• Prädikat: „ hat eine Verknüpfung zu z .“ Dieses 

smeta meta 

Prädikat muss für mindestens ein Element von S anwendbar 

sein damit die Schnittstelle ihre Bestimmung erfüllt: 

∃smetaP( 

smeta 

) 

Diese Bedingung ist nur für Ziele der Qualitätsstufe „Nicht Abbildbar“ 

wichtig, da alle anderen Ziele diese Anforderung per Definition bereits 

erfüllen. Sie stellen gleichzeitig das Interface auf Metamodell-Ebene 

und in ihrer Gesamtheit das Ziel auf SPEM Ebene M1 dar. 



>> 

55 

55


3.4.3 Synthesemodell 

Die definierten qualitativen und quantitativen Ziele der Integration 

sind beide machbar, wie die Kapitel 3.4.2.1 bis 3.4.2.6 zeigen. Die Art 

und Weise hat sich hier ebenfalls präzisiert und kann zu folgendem 

Modell verdichtet werden: 

Abbildung 26: Synthesemodell 

Die Integration der Aktivitäten, Teilaktivitäten, Produkte und Themen 

des Managements von Lieferantenvereinbarungen und der Erstellung 

von Schulungsunterlagen geschieht als Realisierung einer Activity 

bzw. eines Artefaktes durch Integration Activities bzw. Integration 

Artifacts. Sie müssen im Plugin RUP-seitig angelegt werden. Da die 



>> 

56 

56


Teilaktivitäten und Themen in der Prozessumgebung nicht aus den 

jeweiligen Aggregationsklassen navigiert werden können, muss eine 

beidseitige Anbindung an die Aktivtäten und deren Teilaktivitäten 

bzw. an die Produkte und deren Themen erfolgen. Wegen der sehr 

guten Qualität der Ziele, die Elemente von mangelhafter Qualität 

werden implementiert statt integriert, wird die Integration über eine 

Dependency modelliert. Sie stellt sicher, dass Änderungen des V- 

Modells sich sofort wiederspiegeln. Die Dependency erlaubt nicht das 

Modellieren von Kardinalitäten; es ist jedoch nötig mehrere 

Aktivitäten, Teilaktivitäten, Produkte oder Themen in einer Integration 

Activity bzw. einem Integration Artifact zusammenzufassen. Hiermit 

wird das quantitative Ziel, das Erreichen des CMMI Levels 2, 

modelliert. 

Für das qualitative Ziel der V-Modell Konformität auf Produktebene 

des RUP, muss auf Grund der befriedigenden Qualität der 

Zielelemente die Integration mittels einer Assoziationsklasse erfolgen. 

Diese „Matching Table“ übernimmt die Abbildung verwandter V- 

Modell Produkte und RUP Artefakte. Es muss zusätzlich ein 

Workflow erstellt werden, der dafür sorgt, dass Produkte, die über den 

Bestand an Artefakten hinausgehen, erstellt werden. Dies gewährleistet 

die volle Erstellung aller im V-Modell enthaltenen Produkte durch 

einen RUP-Prozess, soweit dies in einem Projekt nötig ist. Durch die 

damit einhergehende Abdeckung des kompletten V-Modell Produkt- 

Spektrums wird die Auftraggeber-Auftragnehmer-Kommunikation 

integriert und das qualitative Ziel des erweiterten Einsatzgebietes 

möglich. 

3.4.4 Synthesematrizen 

Das Ziel Z , das die Integration des Managements von 

quantitativ1 

Lieferantenvereinbarungen beinhaltet, benötigt keine Mapping oder 

Matching Matrix, da die zu verknüpfenden Elemente eine sehr gute 

Qualität besitzen. Es beinhaltet aber, wie in Kapitel 3.4.2.4 festgestellt, 

selbst zu entwickelnde Elemente. Die Synthesematrix zeigt die 



>> 

57 

57


Elemente, welche im RUP angelegt werden, und wie diese Elemente 

des V-Modell XT integrieren: 

Tabelle 1: Synthesematrix des quantitativen Ziels der Einrichtung von 

Schulungsmaßnahmen 

RUP V-Modell XT 

Activity 

Create Training Materials 

Aktivität, Teilaktivität, Steps einer 

Activity 

Ausbildungsunterlagen erstellen 

Lehrpläne erstellen 

Daten für Ausbildungsunterlagen 

akquirieren 

Ausbildungsunterlagen didaktisch 

aufbereiten 

Ausbildungsunterlagen 

zusammenstellen und integrieren 

Provide Training Perform Training 

Artifact Produkt, Thema 

Ausbildungsunterlagen 

Lehrplan 

Training Materials Dozentenunterlagen 

Teilnehmerunterlagen 

Durchführungsunterlagen 

Das zweite quantitative Ziel ( Z ), die Einrichtung von 

quantitativ2 

Schulungsmaßnahmen, besteht ebenfalls aus selbst entwickelten und 

integrierten Elementen: 



58 

Activity/Aktivität oder 

Artifact/Produkt 

Teilaktivität oder Thema 

eines Produkts 

Als „Step“ einer Activity 

implementiert und nicht 

integriert 

(Kein V-Modell Inhalt) 

>> 

58


Tabelle 2: Synthesematrix des quantitativen Ziels des Managements von 

Lieferantenvereinbarungen 

RUP V-Modell XT 

Aktivität, Teilaktivität, Steps einer 

Activity 

Activity 

Lieferung überprüfen 

Accept the Acquired Product Benutzbarkeit verifizieren 

Benutzbarkeit validieren 

Make-or-Buy Entscheidung durchführen 

Determine Acquisition Type 

Analysen durchführen 

Fertigprodukte evaluieren 

Ergebnis bewerten 

Establish Supplier Agreement 

Vertrag abschliessen 

Revise Project Plan 

Monitor 

Execute the Supplier Agreement Review 

Execute corrective actions 

Marktsichtung für Fertigprodukte 

Review COTS Product 

durchführen 

Kriterienkatalog für die 

Select Suppliers Angebotsbewertung erstellen 

Angebot bewerten und auswählen 

Transition deliverable 

Transition Products Ensure training and awareness to 

license issues 



59 







integriert 


>> 

59


Fortsetzung Tabelle 2: 

Artifact Produkt, Thema 

Contract 

Vertrag 

Rechtlicher Vertragsteil 

Vertragsanhang 1: Anforderungen an 

das zu erstellende (Teil-)System 

Vertragsanhang 2: Vertragsrelevante 

Teile des Projekthandbuchs (AN) 

Vertragsanhang 3: Vertragsrelevante 

Teile des QS-Handbuchs (AN) 

Criterias for offer evaluation Kriterien für die Angebotsbewertung 

Make or Buy Decision 

Make-or-Buy-Entscheidung 

Strategische Analyse 

Wirtschaftliche Analyse 

Evaluierung der Fertigprodukte 

Bewertung und Ergebnis 

Overview of COTS Products Marktsichtung für Fertigprodukte 

Offer Evaluation 

Review of deliverable 

Angebotsbewertung 

Eingegangene Angebote 

Bewertung der Angebote 

Entscheidung für ein Angebot 

Prüfprotokoll Lieferung 

Prüfobjekt 

Prüfergebnisse 

Ergebnisanalyse und 

Korrekturvorschläge 

Das nachfolgende Matching der verwandten V-Modell Produkte und 

RUP Artefakte wird mittels einer Tabelle realisiert. Sie ist die 

Implementierung der Assoziationsklasse und zeigt, wie Produkte 

inhaltlich zu Artefakten korrespondieren. Die farbig hervorgehobenen 

Zeilen kennzeichnen jeweils den, die Elemente beinhaltenden, 

Vorgehensbaustein oder die beinhaltende Disziplin. Es ist wichtig, hier 

nochmals zu betonen, dass die Elemente der linken Seite nicht 

zwangsläufig eine genaue Entsprechung der rechten Seite sind, da 

dieses Integrationsziel lediglich der Qualitätsstufe „Ausreichend“ 

entspricht. 



60 







integriert 


>> 

60


Tabelle 3: Synthesematrix des qualitativen Ziels der V-Modell Kompatibilität 

aus Auftraggeber-Sicht 

V-Modell XT Produkt RUP Artefakt 

Planung und Steuerung Projectmanagement 

Iteration Assessment , Review Record 

Projektfortschrittsentscheidung der Aktivität Lifecycle Milestone Review 

Projekthandbuch Development Case 

QS-Handbuch n.a. 

Configuration Management Plan, 

Projektmanagementinfrastruktur Development Infrastructure 

Schätzung n.a. 

Risikoliste Risk List 

Projektplan Software Development Plan 

Arbeitsauftrag Work Order 

Kaufmännische Projektkalkulation Business Case 

Berichtswesen 

Besprechungsdokument n.a. 

Projektstatusbericht (von AN) Status Assessment 

Projektabschlussbericht (von AN) n.a. 

Projekttagebuch n.a. 

Messdaten Project Measurements 

Metrikauswertung Project Measurements 

Kaufmännischer 

Projektstatusbericht Business Case 

Projektstatusbericht Status Assessment 

QS-Bericht n.a. 

Projektabschlussbericht n.a. 

Konfigurations- und 

Änderungsmanagement Configuration & Changemanagement 

Produktbibliothek Project Repository 

Produktkonfiguration n.a. 

Problemmeldung/Änderungsantrag Change Request 

Problem-/Änderungsbewertung Change Request 

Änderungsentscheidung Change Request 

Änderungsstatusliste n.a. 

Prüfung Test 

Prüfspezifikation Dokument n.a. 

Prüfprotokoll Dokument n.a. 

Prüfspezifikation Prozess n.a. 

Prüfprotokoll Prozess Iteration Assessment 

Test Strategy (unter Verwendung von 

Prüfspezifikation Benutzbarkeit Usability Testing) 

Prüfprotokoll Benutzbarkeit Test Results 

Prüfspezifikation Systemelement Test Strategy 

Prüfprozedur Systemelement Test Case 

Prüfprotokoll Systemelement Test Results 



>> 

61 

61



Prüfspezifikation Lieferung n.a. 

Prüfprotokoll Lieferung n.a. 

Nachweisakte n.a. 

Angebots- und Vertragswesen 

Ausschreibung (von AG) n.a. 

Bewertung der Ausschreibung n.a. 

Angebot n.a. 

Vertrag (von AG) n.a. 

Vertragszusatz (von AG) n.a. 

Lieferung Product 

Abnahmeerklärung (von AG) n.a. 

Anforderungen und Analysen Requirements 

Anwenderaufgabenanalyse Storyboard 

Gefährdungs- und 

Systemsicherheitsanalyse n.a. 

Projektvorschlag (extern) Vision 

Anforderungen (Lastenheft) Software Requirements Specification 

Anforderungsbewertung n.a. 

Altsystemanalyse n.a. 

Marktsichtung für Fertigprodukte n.a. 

Make-or-Buy-Entscheidung n.a. 

Systemspezifikationen 

Gesamtsystemspezifikation 

Analysis & Design 

(Pflichtenheft) n.a. 

Systemspezifikation n.a. 

Externe-Einheit-Spezifikation n.a. 

HW-Spezifikation n.a. 

Software Requirements Specification, 

SW-Spezifikation 

Software Architecture Document 

Systementwurf Analysis & Design 

Systemarchitektur n.a. 

Unterstützungssystemarchitektur Test Automation Architecture 

Mensch-Maschine-Schnittstelle Navigation Map, User Interface 

(Styleguide) 

Prototype 

HW-Architektur n.a. 

SW-Architektur Software Architecture Document, 

Datenbankentwurf 

Implementierungs-, Integrations- 

Data Model 

und Prüfkonzept System 

Implementierungs-, Integrationsund 

Prüfkonzept 

n.a. 

Unterstützungssystem 

Implementierungs-, Integrationsn.a. 

und Prüfkonzept HW n.a. 

Implementierungs-, Integrations- Design Model, Integration Build Plan, 

und Prüfkonzept SW 

Test Strategy 

Migrationskonzept n.a. 



>> 

62 

62



Logistische Konzeption 

Spezifikation logistische 

Unterstützung n.a. 

Logistisches 

Unterstützungskonzept n.a. 

Logistische Berechnungen und 

Analysen n.a. 

Systemelemente 

System Deployment Unit 

Unterstützungssystem n.a. 

Segment Implementation Subsystem 

Externe Einheit n.a. 

HW-Einheit n.a. 

SW-Einheit Implementation Subsystem 

HW-Komponente n.a. 

SW-Komponente Implementation Subsystem 

HW-Modul n.a. 

SW-Modul Implementation Element 

Logistikelemente 

Nutzungsdokumentation End-User Support Material 

Instandhaltungsdokumentation End-User Support Material 

Instandsetzungsdokumentation n.a. 

Ersatzteilekatalog n.a. 

Ausbildungsunterlagen Training Materials 

Logistische 

Unterstützungsdokumentation n.a. 

Die Qualität der in Tabelle 1 und 2 vorgenommenen Integration ist 

sehr gut. Hier wird gezeigt, welche V-Modell Elemente mittels der 

Dependency in den RUP übertragen werden. Bei den RUP Elementen 

handelt es sich um die „Integrations Klassen“ des Synthesemodells, die 

die jeweiligen V-Modell Elemente in das Prozessmodell einbinden. 

Die Qualität der in Tabelle 3 vorgenommenen Integration ist auf 

Grund der Qualität der Zielelemente von subjektiver Natur. Hier wird 

in dem Matching eine Einschätzung der Verwandtschaft verschiedener 

Erzeugnisse vorgenommen. Ob sich diese in jedem Fall in der Praxis 

deckt ist nicht zweifelsfrei zu beantworten, da die Beschreibungen der 

Prozessmodelle abstrakter Natur sind und in der Praxis verschiedene 

Ausprägungen aufweisen können. Das hängt unter anderem von den 



>> 

63 

63


Inhalten eines Projektes und der Umsetzung des Matchings durch das 

Team ab. 

Auf die Inhalte der Projekte kann hier kein Einfluss genommen 

werden. Was aber getan werden kann, ist die konzeptionelle 

Ausarbeitung eines Workflows, der die Umsetzung skizziert. Hier gibt 

es zwei Varianten: 

1. Die Abfolge der Elemente des innerhalb Workflows ihrer 

Disziplin. 

2. Die Einbettung in einen Iterationsplan eines Beispielprojektes, 

das auch das Zusammenspiel mit den anderen Disziplinen 

verdeutlicht. 

Dies ist aber keine Aufgabe der Synthese. Sie ist an dieser Stelle 

abgeschlossen. In Kapitel 5 Prototyp wird das für diese Arbeit 

entwickelte, die Syntheseergebnisse einbettende, Umfeld in Form einer 

eigenen Disziplin zusammen mit einem beispielhaften Iterationsplan 

vorgestellt. 



>> 

64 

64


3.5 Alternative Synthesansätze 

Die in den vorherigen Kapiteln vorgenommen Ziele haben zu einem 

Ergebnis in Form von Matrizen geführt. Um dieses zu erreichen, 

wurde aus einer Reihe von Optionen der als am besten geeignet 

erscheinende Weg beschritten. Dies bedeutet aber auch, dass es 

alternative Ansätze gibt. 

Zu Beginn von Kapitel 3.4 wird das Vorgehen bei einer Integration auf 

hohem Niveau wie folgt beschrieben: 

1. Feststellen des genauen Ziels. 

2. Überprüfung ob Anforderungen verletzt werden und ob und 

wie das Ziel erreichbar ist. 

3. Aufstellen eines Korrelationsmodells, das den oder die 

Anknüpfungspunkte verbindet. 

4. Deduktiver Schluss, der zu einer Verknüpfungsmatrix der 

einzelnen Elemente führt. 

Die Wissenschaft kennt zwei Möglichkeiten der logischen 

Argumentation: Der induktive Schluss und der deduktive Schluss. 

Hier wird vom Allgemeinen auf das Spezielle deduktiv vorgegangen. 

Die Schritte drei und vier können auch umgekehrt als induktiver 

Schluss begangen werden. 

Die interessantesten Möglichkeiten für ein alternatives Vorgehen 

innerhalb der Schritte liegen im Gebiet der Zieldefinition: 

Es wurden die am wichtigsten erscheinenden Ziele angegangen, die 

den Einsatzbereich und die Unterstützung durch Werkzeuge betreffen. 

Das V-Modell bietet noch weitere Bereiche, die der RUP nicht 

abgedeckt hat, wie beispielsweise die Hardware Entwicklung oder das 

Ausschreibungs- und Vertragswesen. 

Die quantitativen Ziele werden mit den Methoden SCAMPI und 

CMMI erarbeitet. Dies ist nahe liegend, da in [Kranz 2004] eine 

Einschätzung des V-Modells vorgenommen wird, die für einen 

Vergleich herangezogen werden kann. 



>> 

65 

65


Als Alternativen können hier auch Betrachtungen beispielsweise 

mittels dem Zachmann Framework, Six Sigma, der Goal-Question- 

Metrik (GQM) oder SWOT- bzw. GAP-Analysen angestellt werden. 

Der zweite Aufgabenteil der Überprüfung und Zielpräzisierung wurde 

mittels einer abstrakten Betrachtung unter Zuhilfenahme der 

Mengenlehre und der Logik der Mathematik beschritten. Da keine 

wissenschaftliche Methodik für die Integration von Prozessmodellen 

besteht, wurde hier Wert auf eine möglichst losgelöste Betrachtung 

von den realen Modellen gelegt. Das ist nötig um ein Ziel dieser 

Arbeit, das der Erarbeitung einer Methodik zur 

Prozessmodellintegration, zu erfüllen. Es ist allgemein definiert und 

erfordert eine ebensolche Methodik. 

Handelt es sich alleinig um zwei spezifische Modelle, und die 

Ergebnisse der Integration sollen nicht übertragbar sein, so hilft an 

dieser Stelle auch eine detaillierte Analyse der Metamodelle auf 

Gemeinsamkeiten. Jede vergleichbare Klasse ist ein potenzieller 

Anknüpfungspunkt. Man verliert aber, ohne eine Betrachtung der 

Prozessmodelle als Mengen, eine begründbare Prognose der Qualität 

der Integration. Auch dies ist ein Ziel dieser Arbeit, das der 

Untersuchung von Machbarkeit und Nutzen, und von daher sind die 

gewonnen Aussagen hier nötig. 

Die Erstellung eines Synthesemodells ist mit anderen Mitteln als der 

UML machbar. So ist das V-Modell Metamodell beispielsweise als 

XSD definiert Auf seiner Basis ist die Darstellung einer Verknüpfung 

ebenfalls möglich. Die UML bietet für die Modellierung unschätzbare 

Vorteile und ist das Standardinstrument für diese Arbeiten, weshalb sie 

hier zum Einsatz kommt. 

Die Darstellung der Synthesematrizen in tabellarischer Form ist eine 

rein gestalterische Entscheidung. Die Inhalte der Matrizen können 

auch in Form einer anderen sinnvollen Gliederung wiedergegeben 




>> 

66 

66

Werkzeugumgebungen 

4 Werkzeugumgebungen 

Die Prozessmodelle sind, wie der Name auch bereits nahe legt, 

allgemeiner als die konkrete Prozess-Ausprägung. In den Ebenen des 

SPEM ausgedrückt bedeutet das: 

Prozessmodelle liegen auf der SPEM Ebene M1. Die realen Prozesse, 

die daraus instanziert werden, befinden sich auf der Ebene M0. 

Das Modell soll möglichst umfänglich die Schritte, Erzeugnisse, 

Verantwortlichkeiten und deren Abhängigkeiten beschreiben. Der reale 

Prozess dient der Entwicklung eines Gegenstandes, so dass die 

relevanten Modellelemente ausgewählt und werden müssen, um eine 

möglichst gut passende Prozessbeschreibung zu erhalten. Für diesen 

Vorgang gibt es bei beiden hier verwendeten Modellen Werkzeuge, die 

den Prozessverantwortlichen beim Zurechtschneiden (Tailoring) und 

bei der Modifikation unterstützen. Sie werden nachfolgend vorgestellt 

und ihre Verwendung für die Integration erläutert. 

4.1 V-Modell XT 

Die Werkzeuge des V-Modell XT sind als Plugin für Eclipse in 

Version 2 realisiert. Es existieren zwei Werkzeuge zur Bearbeitung des 

V-Modell XT: 

1. „V-Modell XT Editor“ für die Pflege des Inhalts. 

2. „V-Modell Projektassistent“ für das Tailoring des 

Prozessmodells. 

Der Einsatz der beiden Tools erfolgt unabhängig von einander. Der V- 

Modell XT Editor basiert auf dem Open Source Projekt 4EverEdit. Das 

Programm dient der formularbasierten Bearbeitung von XML Inhalten. 

Der V-Modell XT Editor stellt Eingabemasken und 

Navigationsmöglichkeiten bereit, um das V-Modell zu bearbeiten. Dies 

geschieht auf der Basis des strukturbeschreibenden Schemas und der 

V-Modell XML Datei, welche die Inhalte enthält. 



67 

V-Modell XT 

Werkzeuge: 

http://www.kbst.bu 

nd.de/V-Modell/- 

,293/V-Modell- 

XT.htm 

4EverEdit: 

http://now-portal.clab.de/projects/four 

everedit/ 

>> 

67


Abbildung 27: V-Modell XT Editor 

Die Änderungen werden wiederum im XML Dokument abgespeichert. 

Das gesamte Prozessmodell kann auch als PDF oder HTML exportiert 


Für das Projekttailoring kommt der V-Modell XT Projektassistent zum 

Einsatz. Im ersten Register werden der Projekttyp und der Einsatzort 

(Auftraggeber oder Auftragnehmer) des Projektes festgelegt: 



>> 

68 

68


Abbildung 28: V-Modell XT Projektassistent - Projekttyp 

Im zweiten Register „Anwendungsprofil“ sind detailliertere Angaben 

zu den gewünschten Prozesseigenschaften möglich: 



>> 

69 

69


Abbildung 29: V-Modell XT Projektassistent - Anwendungsprofil 

Das dritte Register zeigt die von dem beschriebenen Projektprofil 

benötigten Vorgehensbausteine: 



>> 

70 

70


Abbildung 30: V-Modell XT Projektassistent - Detaillierte Konfiguration 

Wie aus dem letzten Screenshot ersichtlich, können die 

Vorgehensbausteine und Strategien hier auch direkt gewählt werden. 

Sie dürfen allerdings in keinem Widerspruch zum Anwendungsprofil 

stehen, weshalb die Auswahlmöglichkeiten mit zunehmender 

Detaillierung des Anwendungsprofils abnehmen. 



>> 

71 

71


4.2 Rational Unified Process 

Zur Bearbeitung des RUP kommen drei Werkzeuge zur Anwendung 

1. „RUP Modeler“: Hierbei handelt es sich um ein Rational XDE 

Plugin zur Modellierung des Prozesses. 

2. „RUP Organizer“: Für die Verwaltung und Erstellung der 

Inhalte. 

3. „RUP Builder“: Tailoring des RUP und Zusammenführen von 

Basis und Plugins. 

Die Editiermöglichkeiten des RUP unterscheiden sich von denen des 

V-Modells dahingehend, dass der RUP eine vom Nutzer 

unveränderliche Basis darstellt. Soll der RUP erweitert oder 

anderweitig verändert werden, so geschieht dies mittels Plugins. 

Hiervon gibt es zwei Varianten: 

1. Das „Structured Plugin“: Hiermit können unter Zuhilfenahme 

des RUP Modeler neue Prozesselemente auf SPEM Ebene M1 

angelegt oder alte modifiziert werden. 

2. Das „Thin Plugin“: Hiermit können unter Verwendung des 

RUP Organizer einzelne Seiten bereits existierender Strukturen 

überarbeitet werden. Dies ist z.B. sinnvoll, wenn man eine 

Aktivität genauer beschreiben oder ein Artefakt-Template 

durch eine CI konforme Vorlage ersetzen möchte. 

Der RUP Modeler dient der Verknüpfung der RUP Basis mit dem 

entwickelten Plugin und dem Anlegen der Strukturen, auf die dann der 

Inhalt abgebildet wird: 



>> 

72 

72


Abbildung 31: Rational XDE Modeler - Dependencies des Plugins 

Das UML Modell wird mittels des RUP Organizer eingelesen und als 

Baumstruktur visualisiert: 



>> 

73 

73


Abbildung 32: RUP Organizer - Assoziation der Inhalte auf die UML Elemente 

In der linken Hälfte ist die „Content Base“ zu sehen. Sie enthält die 

textuellen Inhalte der Prozessbeschreibung. Sie werden auf die 

entsprechenden Knoten abgebildet. Zusätzlich können Elemente des 

RUP deaktiviert und mit neuen Inhalten überlagert werden, hier am 

Beispiel des „Inception Lifecycles“ gezeigt. 

Diese Änderungen finden aber nur innerhalb des Plugins statt. Der 

originäre RUP wird dadurch nicht modifiziert. 



>> 

74 

74


Das nun entstandene Plugin wird durch den RUP Builder mit der RUP 

Basis zu einem Prozessmodell zusammengeführt: 

Abbildung 33: RUP Builder - Zusammenführung von Plugin und Basis 

Der RUP bietet in seinem Browser Fenster die Möglichkeit, die RUP- 

Inhalte in Views zu organisieren, um unterschiedlichen Nutzergruppen 

den Zugang zu erleichtern. Diese Sichten auf das Prozessmodells 

können mittels des RUP Builder im nächsten Schritt vorkonfiguriert 




>> 

75 

75


Abbildung 34: RUP Builder - Anlegen der Views 

Für die Integration kann solch eine View verwendet werden, um die 

Inhalte dieser neuen Disziplin an einem Punkt gesammelt zur 

Verfügung zu stellen. 

4.3 Fazit der Toolvorstellung 

Das Toolkonzept des V-Modells ist für eine Integration zweier 

Prozessmodelle weniger geeignet, da es die Änderungen in die V- 

Modell Basis aufnimmt. Bei Aktualisierungen selbiger geht damit die 

Integration verloren. 

Der RUP ist als Basis für die Integration durch die Verwendung von 

Plugins wie geschaffen. Die Anforderung der Wartbarkeit wird durch 

dieses Konzept erfüllt. 



>> 

76 

76


Ein weiterer Vorteil ist, dass die Verknüpfung der HTML-Seiten vom 

RUP Builder automatisch anhand des UML Modells vorgenommen 

werden. Diese Separation von Inhalt und Struktur ist bei Änderungen, 

wie beispielsweise der verantwortlichen Rolle, sehr von Vorteil. So 

muss nicht jeder abhängige XML Knoten oder jede zu modifizierende 

HTML Seite geöffnet und geändert werden, sondern dies wird bei 

einem neuerlichen Export automatisch reflektiert. 

Die Werkzeugumgebung des RUP bietet damit eine gute 

Unterstützung für die Entwicklung des Prototypen. Einzig für die 

Erzeugung der Workflow Grafiken und beispielhafter Iterationspläne 

wird keine Toolunterstützung geboten, so dass diese aufwändig von 

Hand erzeugt werden müssen, wenn man das CI der 

Prozessbeschreibung wahren will. 



>> 

77 

77

Prototyp 

5 Prototyp 

Die in Kapitel 3.4 erarbeiteten Synthesematrizen werden mittels der im 

vorherigen Kapitel vorgestellten Werkzeuge prototypisch als Plugin 

für den Rational Unified Process implementiert. 

Dies geschieht durch das Einführen einer neuen Disziplin „V-Modell 

XT Integration“. 

Abbildung 35: Überblick RUP mit V-Modell XT Integration 



>> 

78 

78

Prototyp 

Die Arbeitsaufwände sind eine grobe Angabe. Sie kommen dadurch zu 

Stande, dass zu Beginn einer Phase eine Zielsetzung der zu 

erzeugenden V-Modell XT Produkte abgegeben werden muss. Da die 

verwendeten Prozessmodelle grundsätzlich nach demselben Schema 

(iterativ/inkrementell) ablaufen, unterscheiden sie sich im Hinblick auf 

die Erzeugnisse lediglich im Grad des Formalismus und der zu 

dokumentierenden Themen. Die erfassten Informationen fallen damit 

aus Sicht des Prozesses in den meisten Fällen so oder so an und 

werden lediglich unterschiedlich erfasst. Da die eigentliche Arbeit 

immer noch den Vorgaben des RUP folgt, werden die Ergebnisse 

gegen Ende der Phase in V-Modell konforme Produkte überführt, was 

wiederum einen erhöhten Arbeitsaufwand in der Disziplin erzeugt. 

Wechselt man im Navigationframe auf die Sicht „V-Modell 

Integration“, so enthält diese eine thematische Gliederung der Inhalte 

des Plugins. Der Hauptknoten gibt weiterhin eine kurze Beschreibung 

der Ziele, Inhalte und Abgängigkeiten wieder: 



>> 

79 

79

Prototyp 

Abbildung 36: Beschreibung des Plugins 

In oben stehender Abbildung ist zu erkennen, dass den drei Zielen der 

Integration jeweils eine verantwortliche Rolle zugeteilt wurde. Die 

Umsetzung der quantitativen Ziele ist bereits in den Synthesematrizen 

auf Basis von Aktivitäten erfolgt, die sich ihnen untergeordnet wieder 

finden. Das qualitative Ziel der V-Modell Kompatibilität aus 

Auftraggeber-Sicht führt zu einer Synthesematrix der Produkte und 

Artefakte. Da das dort durchgeführte Matching keine direkte 

Abbildung der Elemente ist und das V-Modell zusätzliche Produkte 

kennt, die keine RUP-seitige Entsprechung haben, werden zusätzliche 

Aktivitäten definiert, die eine Transformation entsprechender Inhalte 

und eine Sammlung zusätzlicher Informationen während der 



>> 

80 

80

Prototyp 

Iterationen erlauben. Die Aktivitäten werden in Workflow Details 

zusammengefasst und ihr Ablauf im Workflow definiert: 

Abbildung 37: Workflow der V-Modell Integration Disziplin 

Als erstes muss in einem Projekt die V-Modell Umgebung vorbereitet 

werden: 

Zunächst wird das V-Modell XT auf das Projekt angepasst, woraufhin 

eine Untersuchung angestellt wird, welche Artefakte auf Produkte 

abbildbar sind. Dies führt zu einer projektspezifischen „Product – 

Artifact Matching Table“. Sie ist die auf das Projekt angepasste 

Synthesematrix des qualitativen Ziels. Es sollten nur Produkte 



>> 

81 

81

Prototyp 

aufgenommen werden, die eine vertragliche Relevanz haben, um den 

zusätzlichen Aufwand zu minimieren. 

Abbildung 38: Workflow Detail Prepare V-Modell Environment 

Dieses Workflow Detail wird normalerweise nur einmal zu Beginn des 

Projektes durchlaufen. 

Für den restlichen Ablauf wird zunächst nach den Rollen parallelisiert, 

da ihre Aktivitäten unabhängig voneinander ausgeführt werden. 

„Train People“ ist dem „Trainer of Staff“ zugeordnet: 



>> 

82 

82

Prototyp 

Abbildung 39: Workflow Detail Train People 

Dieser Rolle obliegt es, interne Trainingsunterlagen zu erstellen und 

notwendigen Schulungen für das Projektteam zu planen und 

auszuführen. Das ist eine Forderung des CMMI-SE/SW Maturity 

Level 2 und damit die Implementierung des ersten quantitativen Ziels. 

Das zweite quantitative Ziel, die Integration des Managements von 

Lieferantenvereinbarungen, wird durch den rechten Ablauf des 

Workflows realisiert: 



>> 

83 

83

Prototyp 

Abbildung 40: Workflow Detail Establish Supplier Agreements 

Hier ist das Ziel, eine Kooperation mit einem Zulieferer zu 

vereinbaren. Grundlegend muss als erstes eine Make-or-Buy- 

Entscheidung getroffen werden. Anschließend erfolgt die Auswahl der 

Lieferanten. Das Endergebnis ist ein Vertrag mit dem Zulieferer. 

Das zweite Workflow Detail der Zulieferer Management Integration 

beschäftigt sich mit der Erfüllung des abgeschlossenen Vertrags: 



>> 

84 

84

Prototyp 

Abbildung 41: Workflow Detail Satisfy Supplier Agreements 

Hier besteht zunächst die Möglichkeit, COTS 8 -Produkte zu evaluieren. 

Da für den Kauf eines Fertigproduktes ein geringerer Umfang an 

Arbeiten nötig ist als für eine Zusammenarbeit mit einem Zulieferer, 

wird es hier bei der Erfüllung eines Zuliefererverhältnisses und nicht 

bei der Anbahnung selbigen abgehandelt. 

Alternativ erfolgt eine Überwachung des Zuliefererprojekts anhand der 

vertraglich geregelten Details. Sollten sich hierbei Probleme auftun, so 

werden sie in die Risikoliste aufgenommen und finden damit Eingang 

in die Planung der nächsten Iteration. 

8 COTS: Commercial off the Shelf, Bezeichnung für Fertigprodukte 



>> 

85 

85

Prototyp 

Die Überprüfung des Liefergegenstandes wird in einem Protokoll 

erfasst und der gelieferte Gegenstand als „Implementation Subsystem“ 

abgelegt. Dieses wird anschließend durch die Aktivität „Transition 

Products“ als implementiertes Teilsystem in das Projekt übernommen. 

Das quantitative Ziel der V-Modell Kompatibilität wird durch eine 

entsprechende Dokumentation der Projekterzeugnisse erreicht. Der 

mittlere Ablauf des Workflows (Abbildung 37) modelliert das nötige 

Vorgehen. Die geforderten V-Modell XT Produkte sind in der Product 

– Artifact Matching Table enthalten, so dass zunächst eine 

Einschätzung der in der aktuellen Iteration zu gewinnenden Daten 

abzugeben ist. 



>> 

86 

86

Prototyp 

Abbildung 42: Workflow Detail Assess Work 

Bei der Aktivität „Assess Work“ geht es darum, eine Einschätzung der 

anfallenden Arbeiten zu erhalten. Hierbei wird untersucht 

• Welche V-Modell Produkte fertig gestellt werden müssen 

(terminlich). 

• Welche Artefakte sich geändert haben und Änderungen an 

Produkten nach sich ziehen. 

Produkte und damit Themengebiete, die bisher nicht bearbeitet 

wurden, werden in die Risklist aufgenommen. Damit ist sichergestellt, 

dass das Projektteam in der nächsten Iteration die benötigten 



>> 

87 

87

Prototyp 

Informationen sammeln kann, um das Produkt zu bearbeiten. Dies 

gewährleistet einen effizienten Prozess, in dem Daten nicht mehrfach 

erarbeitet werden müssen. 

Die nachfolgende Aktivität entscheidet, ob das Produkt durch 

Migration eines Artefaktes erstellt werden kann oder kein 

entsprechendes Artefakt existiert und das Produkt neu erstellt werden 

muss. 

Bei einer Migration wird zunächst untersucht, welche Ergänzungen am 

Artefakt für eine Konvertierung vorzunehmen sind. Diese werden 

ausgeführt und das damit erzeugte „V-Modell XT Product“ im 

nächsten Schritt in der „V-Modell XT Product Base“ abgelegt. Sie 

stellt das zentrale V-Modell XT Produkt Repository dar. 

Der Sachverhalt wird in untenstehender Abbildung 43 dargestellt: 



>> 

88 

88

Prototyp 

Abbildung 43: Workflow Detail Migrate RUP Artifacts to V-Modell XT 

Products 

Etwas komplizierter ist der Sachverhalt im parallelen Workflow Detail 

„Manage V-Modell XT Products“. Es hat zur Aufgabe, vertraglich 

relevante V-Modell XT Produkte zu erzeugen, die nicht durch 

Artefakte des RUP abgedeckt werden. 

Da diese Produkte sich ebenfalls auf der Risikoliste befunden haben, 

kann in der darauf folgenden Iteration in Zusammenarbeit mit den 

entsprechenden Rollen die notwendigen Informationen erarbeitet 




>> 

89 

89

Prototyp 

Abbildung 44: Workflow Detail Manage V-Modell XT Products 

Anschließend wird das V-Modell Produkt erstellt und ebenfalls in der 

V-Modell XT Product Base abgelegt. 

Nachdem der Workflow erläutert wurde, soll nun exemplarisch gezeigt 

werden wie die Integration einzelner Seiten des V-Modells erfolgt. Es 

handelt sich dabei um die Implementierungen der Synthesematrizen, 

weshalb hier nicht jeder Fall einzeln erläutert wird. Das nachfolgende 

Beispiel bezieht sich auf die Integration eines Produktes. Die 

Umsetzung der Synthese von Aktivitäten und ihren Teilaktivitäten ist 

analog geschehen. 



>> 

90 

90

Prototyp 

Das Artefakt der „Offer Evaluation“ des Zulieferer Managements wird 

auf das Produkt „Angebotsbewertung“ des V-Modells und seiner 

assoziierten Themen abgebildet: 

Abbildung 45: Artifact Offer Evaluation 

Die Verknüpfungen unter „Purpose“ führen direkt zu den V-Modell 

Inhalten. Sie beziehen sich auf eine komplette HTML Dokumentation 

des V-Modells, so dass sie einfach mit einer neuen Version aktualisiert 




>> 

91 

91

Prototyp 

Abbildung 46: Integriertes Produkt Angebotsbewertung 

Das Produkt umfasst drei Themen (vgl. Abbildung 45). Diese sind 

vom Produkt aus nicht navigierbar, sondern lediglich über eine 

Javascript Navigation des V-Modells, ähnlich dem Navigator des RUP 

im linken Frame. Darum werden sie hier in der Beschreibung des 

Artefaktes unterhalb des Produktes als Verknüpfung aufgeführt. Ihre 

Integration sieht damit wie folgt aus: 



>> 

92 

92

Prototyp 

Abbildung 47: Integriertes Thema Bewertung der Angebote 

Für die Synthesmatrix des qualitativen Ziels wird das Artefakt 

„Product - Artifact Matching Table“ implementiert. Es erläutert ebenso 

wie das Artefakt „Offer Evaluation“ aus Abbildung 45 die Ziele, 

Verantwortlichkeiten und Eigenschaften des Erzeugnisses. 

Die Product - Artifact Matching Table wird, wie eingangs geschildert, 

zu Beginn des Projektes im Workflow Detail Prepare Environment 

erstellt. Das ist nötig, da je nach Projekt unterschiedliche Produkte eine 

vertragliche Relevanz haben. Daher wird die Synthesematrize als 

Template des Artefaktes realisiert. Sie gewährleistet die 



>> 

93 

93

Prototyp 

Navigierbarkeit der entsprechenden Produkte und Artefakte und ist 

eine Starthilfe für das Erstellen der projektspezifischen Matching 

Tabelle. 

Abbildung 48: Product - Artifact Matching Table Template 

Eine Klick auf die „Risikoliste“ zeigt das V-Modell Produkt, ein Klick 

auf die entsprechende „Risk List“ das RUP Artefakt. Die Themen der 

Produkte sind in einem alphabetischen Listing der Produkte durch 

einen Klick auf „V-Modell XT Products“ erreichbar. 

Zusätzlich werden in der Matching Tabelle die Templates zur 

Produkterstellung verlinkt. Sie sind im V-Modell selbst nicht 



>> 

94 

94

Prototyp 

verknüpft, da das Ziel hier aber die Konformität auf Produkt Ebene ist, 

stellen sie ein wichtiges Arbeitsmittel dar und werden angezeigt. Ein 

Klick öffnet das Dokument zur Bearbeitung. 

Abbildung 49: Integriertes V-Modell XT Template 

Abschliessend folgt nun ein beispielhafter Iterationsplan für ein 

mittleres Projekt unter Verwendung der V-Modell Integration 

Disziplin: 



>> 

95 

95

Prototyp 

Abbildung 50: Iterationsplan einer initialen Inception Phase 

Hier ist ein globaler Ablauf aller Disziplinen innerhalb einer 

beispielhaften initialen Iteration der Inception Phase skizziert. Das 

Projekt startet zunächst mit der Vorbereitung der V-Modell Umgebung 

und der Erstellung der Product - Artifact Matching Table; anschließend 

wird das RUP Projekt initialisiert. 

Nun findet in allen weiteren Iterationen die parallele Bearbeitung der 

V-Modell Produkte während der Entwicklung statt. Dieser Plan und 

die beispielhaften Pläne für die anderen Phasen sind im Prototypen 

hinterlegt und durch einen Klick auf die jeweilige Phase der 

Überblicksgrafik (Abbildung 35) erreichbar. 

Die Darstellung bezieht sich auf ein dem Projekt angepassten RUP mit 

V-Modell Plugin. Das bedeutet, dass nicht alle Workflow Details 



>> 

96 

96

Prototyp 

durchlaufen werden, da der Formalismus nicht benötigt wird oder das 

aktuelle Projektstadium diese nicht benötigt. Auf Seiten des Plugins 

kommt hier nur der mittlere parallele Strang zum Einsatz, da das 

Projekt von Beginn an eine V-Modell konforme Dokumentation 

erzeugen soll. Das Projekt entwickelt damit eine Software nach dem 

RUP und verhält sich zum Auftraggeber V-Modell konform auf Basis 

der Produkte. 

Soll später zusätzlich noch das Managements von 

Lieferantenvereinbarungen oder das interne Training berücksichtigt 

werden, so sind sie analog in die entsprechenden Iterationspläne mit 

aufzunehmen. Sollten sie auch in den nachfolgenden Iterationen nicht 

berücksichtigt werden, so ist der Gesamtprozess nicht konform zu den 

Forderungen des CMMI Maturity Level 2. 



>> 

97 

97

Bewertung der Integration nach CMMI 

6 Bewertung der Integration nach 

CMMI 

Die Integration von RUP und V-Modell durch den Prototyp hat als 

quantitatives Ziel, einen CMMI-SE/SW Maturity Level 2 zu erreichen. 

Zur Bewertung der Zielerreichung wird hier wiederum ein CMMI 

Assessment durchgeführt. Es kommt dabei dieselbe Vorgehensweise 

wie in Kapitel 3.4.1.2 Quantitative Ziele zum Einsatz. Die Bewertung 

unterliegt denselben Einschränkungen und sagt lediglich etwas über 

das Potenzial der Integration und nicht über real in einem 

Unternehmen erreichte CMMI Maturity Levels aus. 

Da dieselbe Methode zum Einsatz kommt, werden die Daten aus dem 

Anhang A wieder verwendet. Das Prozessgebiet Supplier Agreement 

Mangement und das Generische Ziel „Institutionalize a Generic 

Process“ werden neu bewertet, da sie durch die Implementierung im 

Prototypen adressiert werden. 

Tabelle 4: CMMI Bewertung der Integration des Zulieferer Managements 

Processarea - Goal - Implementation Levels 

Practice (Specific) 

Supplier Agreement 

Not Partially Largely Fully 

Management 

Establish Supplier 

x 

SP1 Agreements x 

SG1.1 Determine Acquisition Type x 

SG1.2 Select Suppliers 

Establish Supplier 

x 

SG1.3 Agreements x 

SG2 Satisfy Supplier Agreements x 

SP2.1 Review COTS Products 

Execute the Supplier 

x 

SP2.2 Agreement x 

SP2.3 Accept the Acquired Product x 

SP2.4 Transition Products x 

Die integrierte Lösung erfüllt die Anforderungen des CMMI. 

Abgewertet werden die Spezifischen Ziele SG1.2 & SG2.1, da das 

CMMI eine Risikobewertung empfiehlt, die im V-Modell XT nicht 

stattfindet. Diese Bewertung wird auch durch den Prototypen nicht 

eingeführt. 



98 

Prozessgebiet 

Ziel 

Praktik 

>> 

98


Zusammenfassend wird das erste quantitative Teilziel der Integration 

des Managements von Lieferantenvereinbarungen erfüllt, da die 

schlechteste Bewertung Largely Implemented ist. 

Das andere quantitative Teilziel ist die Erfüllung des Generischen Ziels 

Instiutionalize a Managed Process. Es wurde nicht erfüllt, da die 

generische Praktik Train People im RUP nicht implementiert war. Die 

Bewertung der integrierten Lösung ist wie folgt: 

Tabelle 5: CMMI Bewertung der Integration der Generischen Praktik Train 

People 

Processarea - Goal - Implementation Levels 

Practice (Generic) 

Generic Goals & 

Not Partially Largely Fully 

Practices 

Institutionalize a Managed 

x 

GG2 Process 

(CO 1) Establish an 

x 

GP2.1 Organizational Policy x 

GP2.2 (AB 1) Plan the Process x 

GP2.3 (AB 2) Provide Ressources x 

GP2.4 (AB 3) Assign Responsibility x 

GP2.5 (AB 4) Train People 

(DI 1) Manage 

x 

GP2.6 Configurations 

(DI 2) Identify and Involve 

x 

GP2.7 Stakeholders 

(DI 3) Monitor and Control 

x 

GP2.8 the Process 

(VE 1) Objectively Evaluate 

x 

GP2.9 Adherence 

(VE 2) Review Status with 

x 

GP2.10 Higher Level Management x 

Es wurde eine interne Trainingsmöglichkeit durch das Anlegen einer 

Rolle und die Integration der entsprechenden Produkte und Aktivitäten 

geschaffen, welche dieses Ziel erfüllen. Zusätzliche wird in dem 

Prototypen noch die Aktivität „Provide Training“ modelliert, welche 

die Schulungen explizit ausführt. 

Damit ist auch das zweite Teilziel erfüllt. 



99 

Prozessgebiet 

Ziel 

Praktik 

>> 

99


Insgesamt wird das gesetzte quantitative Ziel 

• Die integrierte Lösung soll den potenziellen Reifegrad 

gegenüber den einzelnen Modellen um eine Stufe auf Maturity 

Level 2 anheben. 

erreicht, so dass sich das folgende Bild über das Potenzial der 

integrierten Lösung im Hinblick auf CMMI ergibt: 

Abbildung 51: Reifegrad der prototypischen Integration 



>> 

100 

100

Zusammenfassung 

7 Zusammenfassung 

Die Prozessmodelle Rational Unified Process und V-Modell XT 

werden in dieser Arbeit erfolgreich integriert. Es kann dadurch aus der 

Umgebung des RUP auf relevante Inhalte des V-Modells zugegriffen 


Eine maßgebliche Schwierigkeit der Arbeit besteht darin, dass eine 

Integration von Prozessmodellen in der dem Autor bekannten Literatur 

noch nicht stattgefunden hat. Ein Kernaspekt ist daher, eine Methodik 

und angebrachte Werkzeuge für die einzelnen Schritte zu definieren, 

deren Implementierbarkeit und die dadurch erreichbaren Ziele zu 

überprüfen. 

Erarbeitung einer Methodik zur Prozessmodellintegration 

Sie wird im Kapitel 3.4 vorgestellt und umfasst die folgenden 

übergeordneten Schritte: 

• Zieldefinition 

• Abschätzung des Ergebnisses in Qualitätsstufen 

• Synthesemodell 

• Synthesematrizen 

Die einzelnen Teilaufgaben stützen sich dabei soweit dies möglich ist 

auf Methoden und Werkzeuge, die auf ihrem Gebiet den „State of the 

Art“ darstellen: 

• CMMI 

• SCAMPI 

• SPEM 

• UML 

Jede Methodik braucht jedoch einen gewissen Reifeprozess, um 

Schwachstellen und Ungenauigkeiten zu adressieren. So war die 

Unified Method und CMM nicht frei von Makel und die UML oder 

CMMI werden ebenfalls kontinuierlich weiterenwickelt. Die hier 



>> 

101 

101


vorgestellte Methode wird ebenfalls Punkte aufweisen, die eine 

Präzisierung erfordern. Sie stellt vielmehr einen ersten Ansatzpunkt 

zur methodengestützten Analyse von Verbesserungsprotenzialen, zur 

qualitativen Vorhersage eines Integrationsergebnisses und zur 

Erarbeitung eines Integrationspfads dar. 

Prototypische Implementierung 

Die erstellten Synthesematrizen werden um verantwortliche Rollen, 

sowie Artefakte und Aktivitäten soweit nötig, ergänzt. Der 

Gesamtzusammenhang wird in einem Workflow modelliert und als 

Disziplin in den Rational Unified Process auf Basis eines Plugins 

integriert. 

Der Prototyp zeigt dabei wie es möglich ist, Projekte nach Richtlinien 

des Bundes mittels des RUP durchzuführen, indem er die 

Dokumentation nach Maßgabe des V-Modell XT erstellt und wie eine 

Verbesserung der CMMI Einstufung dabei erreicht werden kann. 

7.1 Fazit Prototyp 

Die Erweiterung des RUP durch Elemente des V-Modell XT bedeutet 

auch, dass eine Spezialisierung des V-Modells im Bereich der 

Softwareentwicklung stattgefunden hat. Ihm stehen nun detaillierte 

und in der Praxis bewährte Erfahrungen auf diesem Gebiet durch den 

RUP zur Verfügung, was zu Lasten der Hardwareentwicklung des V- 

Modells geht. Sie ist durch den RUP nicht abgedeckt und geht durch 

den Austausch der V-Modell Life-Cycles gegen den Software 

zentrischen RUP Life-Cycle verloren. 

Zielerreichung 

Das erste qualitative Ziel der V-Modell Konformität auf Produktebene 

gegenüber dem Auftraggeber wird durch die Verwendung von V- 

Modell Produkten und die Transformation von RUP Artefakten in 



>> 

102 

102


diese gelöst. Das ist durch den Workflow und das Matching elegant 

gelöst, da nur zusätzliche Arbeiten anfallen, wenn über den Umfang 

des RUP hinausgehende Produkte erstellt werden müssen. Diese 

Arbeiten sind jedoch kein Mehraufwand, da sie in einem V-Modell 

Prozess nun mal anfallen und sogar vertraglich vorgeschrieben sind. 

Nur diese Produkte werden durch die integrierte Lösung mittels des 

Plugins erstellt. 

Das zweite qualitative Ziel der Bereitstellung der Hilfestellungen und 

Werkzeuganbindungen des RUP wird dadurch ebenfalls erreicht. Sie 

sind an den entsprechenden Stellen des RUP hinterlegt und können 

somit bei den relevanten Artefakten und den Aktivitäten zu ihrer 

Erstellung abgerufen werden. Da die integrierte Lösung die im RUP 

Entwicklungsprozess gewonnenen Informationen in eine V-Modell XT 

konforme Dokumentation überträgt und die Zielelemente an den 

entsprechenden Stellen des Basisprozesses verfügbar sind, ist das Ziel 

erfüllt. 

Das quantitative Ziel wird ebenfalls erfüllt. Die prototypische 

Integration erfüllt die Anforderungen des CMMI-SE/SW Maturity 

Level 2, wie das Kapitel 6 zeigt. 

Bewertung der Integration im Prototypen 

Die Integration der quantitativen Ziele ist gut gelungen, da hier 

eindeutige Ziele gegeben und diese durch die Quantifizierung auch 

sehr gut überprüfbar sind. 

Das Matching der Produkte und Artefakte ist problematischer, da es 

subjektiver Natur ist. Wenn des öfteren Projekte auf V-Modell Basis 

bearbeitet werden sollen, wäre hier der Einsatz „integrierter“ Produkte 

interessant. Dazu müssten die Artefakt-Beschreibungen und Templates 

der RUP Artefakte bearbeitet werden, so dass sie die Inhalte des V- 

Modells direkt wiedergeben. Dies bietet sich in Verbindung mit 

organisationsspezifischen Anpassungen an und kann sehr gut graduell 

erfolgen. Damit werden die wichtigsten V-Modell Produkte 

automatisch durch den RUP Prozess erzeugt. Hierbei ist allerdings 

kritisch zu prüfen, ab wann der direkte Einsatz des V-Modells nicht 

effizienter wäre. 



>> 

103 

103


Ein Problem bleiben die Initialen Produkte des V-Modells (Abbildung 

20). Sie werden nur einmalig erstellt und dürfen nicht mehr modifiziert 

werden. Der RUP sieht einen solchen Zustand für ein Artefakt nicht 

vor. Einige Produkte, die dieses Tag tragen haben keine Entsprechung 

im RUP wie beispielsweise die „Ausschreibung“. Andere wie die 

„Anforderungen“ oder der „Projektplan“ könnten durch den RUP sehr 

wohl geändert werden. Da dies in einem V-Modell konformen Projekt 

nicht passieren darf, dürfen Änderungen hier nicht stattfinden - auch 

wenn sie angebracht wären. Es besteht aber die Möglichkeit den 

inhaltlichen Umfang dieser initialen Produkte gering zu halten, wie es 

z.B. die Agile Projektdurchführungsstrategie des V-Modells vorsieht. 

In Abhängigkeit von der Vertragsgestaltung eines Projektes verliert der 

RUP durch die Integration damit möglicherweise ein Teil seiner 

Flexibilität. 

Abschließend ist festzustellen, dass eine Integration eines neuen 

Prozessgebietes sich als relativ unproblematisch und vielversprechend 

erweist. Dies ist im Prototyp durch die quantitativen Ziele erfolgt. 

Eine Integration mit dem Ziel der Emulation eines anderen Prozesses 

ist weitaus komplizierter. Ein Mapping wird sich nur in wenigen Fällen 

erstellen lassen. Meist ist man auf ein Matching angewiesen, da keine 

genaue Übereinstimmung der Quell- und Zielelemente gegeben ist. 

Diese Matchings sind per Definition subjektiver Natur und erfordern 

immer einen Mehraufwand durch manuelle Abgleichungen. Dies 

wurde hier versucht durch entsprechende Aktivitäten und eine 

frühzeitige Ausrichtung des Prozesses über die Risklist möglichst 

effizient zu gestalten, ist aber im Endeffekt immer manuelles 

„Flickwerk“. Hier macht eine Integration nur Sinn, wenn der 

Basisprozess wesentliche Vorteile gegenüber dem zu integrierenden 

Prozess bietet. Dies können beispielsweise eine bereits erfolgte 

Implementierung des Basisprozesses oder seine größere 

Zweckmässigkeit für das Entwicklungsziel sein. 



>> 

104 

104


7.2 Fazit V-Modell XT 

Das V-Modell XT hat einige sehr gute Eigenschaften. So sind die 

Werkzeuge zur Bearbeitung als Open Source Projekte realisiert und 

auch das Prozessmodell an sich ist kostenfrei beziehbar. Es orientiert 

sich zudem nicht allzu stark an Werkzeugen eines bestimmten 

Herstellers, was dem RUP ab und an vorgeworfen wird. Leider sind 

die Beschreibungen der einzelnen Aktivitäten teilweise etwas kurz 

geraten. Die dort referenzierten „Methodenreferenzen“ teilen das selbe 

Schicksal. So wird beispielsweise die Anforderungsmodellierung 

durch Use Cases auf einer viertel Seite abgehandelt. Der RUP bietet an 

dieser Stelle eine mehrere Seiten umfassende Guideline, eine 

Checkliste und mehrere Beispiele. Beim derzeitigen Detaillierungsgrad 

des V-Modells ist zu befürchten, dass sich Projektbeteiligte an 

manchen Stellen etwas allein gelassen fühlen. 

Die Neuerung der Vorgehensbausteine ist als sehr gut zu bewerten. 

Zwar kennen andere Modelle wie der RUP mit den Disziplinen 

ähnliche Konzepte, der Grad der Modularisierung und die Einfachheit 

der Handhabung ist jedoch unerreicht. 

Die Flexibilität in Bezug auf den Lebenszyklus ist eine weitere 

Novität, die sehr interessant ist. Die Auswahl zwischen einem 

iterativen und einem agilen Vorgehen eröffnet neue Möglichkeiten, 

Projekte unterschiedlichster Größe und Innovationsgrades zu 

realisieren. Da es sich damit auch im Umkehrschluss nicht auf eine 

Philosophie festlegt, kann der Auslieferungszustand auch als 

Referenzimplementierung betrachtet werden. Damit steht der 

Integration von weiteren (zukünftigen) Lebenszyklen nichts im Wege. 

Bei genauer Betrachtung der Umsetzung dieses an und für sich sehr 

guten Konzeptes, sind auftretende Probleme leider nicht vollständig 

gelöst worden: 

Die Benennung einer „rückwärts“ ablaufenden Implementierung, die 

über Meilensteine definiert ist (vgl. Abbildung 13), als agile 

Vorgehensweise ist sehr fragwürdig. 



>> 

105 

105


Agile Konzepte begründen sich per Definition auf das Agile Manifesto 

[AgileManifesto 2004]. Einer der vier Leitsätze ist: 

• Die Reaktion auf Änderungen hat Vorrang vor der Verfolgung 

eines Plans. 9 

Man kann die Anordnung der Abläufe eines Entwicklungsprozesses 

über Meilensteine als Plan betrachten, da diese Zeitpunkte und Inhalte 

festlegen. Dagegen würde die V-Modell Implementierung verstoßen 

und dürfte sich damit nicht mehr agil nennen. Wenn man die agile Idee 

noch weiter denkt, könnte man sogar zu dem Schluss kommen, dass 

man zu Beginn des Projektes auch nicht wüsste, welche 

Vorgehensbausteine man benötigen würde. Diese würden dann nach 

Bedarf eingebunden werden. Im V-Modell ist das aber nicht so ohne 

weiteres möglich, da die Vorgehensbausteine auch eine gewisse 

vertragliche Relevanz besitzen. Weiterhin ist in diesem 

Zusammenhang die Markierung von Produkten als „initial“ 

problematisch, da sie nicht mehr geändert werden dürfen. Dies betrifft, 

wie bereits im vorherigen Kapitel erwähnt, beispielsweise den 

„Projektplan“ oder die „Anforderungen“. Das agile Konzept sieht hier 

eine größere Flexibilität vor. 

Insgesamt kann man sich dem Eindruck nicht verschließen, dass hier 

zwar eine Reihe an guten Konzepten existiert, an manchen Stellen 

jedoch unpräzise gearbeitet wurde: 

• Das V-Modell visualisiert die Vorgehensbausteine und ihre 

Zusammenhänge mittels einer „Vorgehensbausteinlandkarte“. 

Leider weist sie eine Fülle von Redundanzen auf und wird 

damit unübersichtlich, weshalb sie für diese Arbeit nicht 

verwendet wurde. Der Zusammenhang wird hier verständlicher 

in Abbildung 15 dargestellt. 

• Ein Thema eines Produktes und eine Teilaktivität einer 

Aktivität wäre im Metamodell besser als Rekursion modelliert 

worden. Es gibt hier keinen erkennbaren Grund ein neues 

9 Vom Autor aus dem Englischen übersetzt: „Responding to change over following a 

plan.“ Quelle: [AgileManifesto 2004] 



>> 

106 

106


Objekt zu definieren, da nur die „Beschreibung“ ein zwingend 

vorgeschriebenes Feld ist. Im übergeordneten Objekt ist dies 

das Feld „Sinn_und_Zweck“ (vgl. Anhang C: V-Modell 

Metamodell). 

• Es werden mehrere Vorgehensstrategien eingeführt, die aber 

nicht zwangsläufig die bestimmende Philosophie des 

namensgebenden Lifecycles widerspiegeln, sondern lediglich 

Meilensteine anders abarbeiten. 

Die Produkte sind im V-Modell XT sehr wichtig, da sie 

Dokumentation und Erfüllungsgegenstand des Auftragnehmers 

gegenüber dem Auftraggeber sind. Sehr schön zu sehen ist dies an der 

Definition des Projektfortschrittes über Meilensteine und Darstellung 

der Auftragnehmer - Auftraggeber Kommunikation in Abbildung 14. 

Aristoteles definiert die Essenz als das Wesen einer Sache, das nicht 

geändert werden kann, ohne den Charakter der Sache zu ändern. Der 

Rest ist als Akzidenz definiert, das Beiwerk. Die Essenz des V- 

Modells liegt auf den Produkten. Sie sind vertraglich wichtig und ihre 

Erstellung ist das Ziel des V-Modells. Sie sind sogar durch den 

deutschen Gesetzgeber Pflicht für IT-Entwicklungen der Öffentlichen 

Hand. Dafür, dass der Rest Akzidenz ist, spricht die Austauschbarkeit 

der Lifecycles oder auch die weniger detaillierten Aktivitäten. 

Die Essenz eines Prozessmodells ist aber die Bezeichnung und 

Anordnung einer Folge von Tätigkeiten, ihrer Ergebnisse und der 

verantwortlichen Rollen. 

Das wichtigste am V-Modell ist somit auch das produktbasierte 

Kommunikationsprotokoll, welches eine möglichst gute Verständigung 

zwischen Auftragnehmer und Auftraggeber gewährleistet. Das ist eine 

wichtige und überfällige Entwicklung auf dem Gebiet der IT- 

Entwicklungsprozesse. So schreibt Michael Hammer im Harvard 

Businessmanager [Hammer 2002]: 

„Sobald Aufgaben und Daten zwischen zwei Unternehmen hin- und 

hergehen, kommt es gewöhnlich zu Ungereimtheiten, Fehlern und 

Missverständnissen, was zur Verschwendung weiterer Arbeitsstunden 

führt“. 

Als Beispiel führt er unter anderem an, dass Hewlett-Packard durch 

eine Integration der Zuliefererprozesse im Stande war, „die Zeit für das 



>> 

107 

107


Ausführen eines Auftrags über einen Computermonitor […] um 25 

Prozent“ zu senken. Das V-Modell XT ist das erste Prozessmodell bei 

dem diese Ineffizienzen durch eine vertikale Integration direkt 

adressiert werden. 

7.3 Erkenntnisse der Arbeit 

Die Arbeit bringt eine Reihe interessanter Erkenntnisse, die an dieser 

Stelle nochmals kurz zusammengefasst werden sollen: 

• Es ist möglich zwei Prozessmodelle zu verknüpfen, so dass die 

integrierte Lösung weniger Problempunkte als ein alleiniges 

Modell aufweist bzw. eine breitere Einsatzfähigkeit erhält. 

• Die Vorstellung einer Methodik zur Abschätzung von Sinn und 

Potenzial einer Integration bevor diese implementiert wird. 

• Der RUP wie auch das V-Modell sind ohne Veränderungen 

gemäß CMMI auf der Stufe „Initial“ als chaotischer Prozess zu 

bewerten. Mittels der hier entwickelten Anpassungen wird die 

integrierte Lösung zu einem „Managed Process“, da sie die 

Anforderungen des CMMI an ein grundlegendes 

Projektmanagement erfüllt. 

• Das V-Modell XT könnte eine Diversifikation am 

Prozessmodellmarkt einleiten. Es gibt bereits Modelle wie 

CMMI, die ausschließlich sagen was zu tun ist. 

Produktzentrische Vorgehensmodelle könnten den 

entsprechenden Gegenpart liefern und einen Standard über die 

Dokumentationsweise der Prozessergebnisse schaffen. 

• Die im V-Modell XT erfolgte Integration von Auftragnehmern 

und Auftraggebern in ein Prozessmodell ist eine Novität, die 

große Gewinne für beide Parteien verspricht. 



>> 

108 

108


7.4 Ausblick 

Die Arbeit und der dabei entstandene Prototyp bieten einige 

interessante Ansatzpunkte und Erweiterungsmöglichkeiten, die im 

Rahmen einer weiterführenden Arbeit untersucht bzw. umgesetzt 

werden könnten: 

• Detaillierung der bestehenden Lösung: 

Die Entwicklung integrierter Produkttemplates und die 

Anpassung der dazugehörigen Aktivitäten und 

Artefaktbeschreibungen für überwiegend identische Produkte 

und Artefakte. Das vereinfacht den Entwicklungsprozess und 

kann somit diesen auch eventuell effizienter gestalten, da die 

Inhalte und Ziele besser ersichtlich sind. 

• Erweiterung der bestehenden Lösung: 

Die entwickelte Lösung wieder in das V-Modell integrieren. Es 

umfasst eine Ausschreibungs- bzw. Angebotsphase, die das 

Projekt einleitet. Dabei könnte man die Product-Artifact 

Matching Table der relevanten Produkte durch eine 

Schnittstelle des V-Modell Projektplanungswerkzeuges 

automatisch erzeugen. 

• Anwendung der Erkenntnisse der vorgestellten Methodik um 

zu untersuchen welche Prozessmodelle konsolidiert werden 

könnten: 

In den Kapitel 3.4.2.1 und 3.4.2.2 wird geschildert, dass eine 

Integration Erfolg versprechend ist, wenn die verwendeten 

Modelle auf SPEM Level M2 eine möglichst große 

Übereinstimmung haben und auf SPEM Level M1 möglichst 

große Unterschiede aufweisen. Die Integration ist dann relativ 

unproblematisch und verspricht einen großen Synergieeffekt, 

da die Modelle stark unterschiedliche Inhalte haben. Es wäre 

interessant eine Untersuchung durchzuführen, welche 

Prozessmodelle diese Anforderungen erfüllen und somit ein 

„super“ Prozessmodell bilden könnten. Dies könnte einen Weg 

aufzeigen wie der in der Einführung angesprochene 

Konsolidierungsprozess erfolgen könnte. 



>> 

109 

109


• Quantifizierung der Auswirkungen der verschiedenen 

Qualitätsstufen auf eine integrierte Lösung: 

Im Kapitel 3.4.2.4 werden Qualitätsstufen der Integration 

definiert. Im Zuge einer weiterführenden Untersuchung 

könnten beispielsweise Effizienzabfälle der Qualitätsstufen 

aufgezeigt werden, die quantitative Aussagen über den Gewinn 

der Implementierung ermöglichen könnten. 



>> 

110 

110

Anlagen 

8.1 Quellen 

[AgileManifesto 

2004] 

[Ahern, Clouse, 

Turner 2003] 

8 Anlagen 

Manifesto for Agile Development, 

www.agilemanifesto.org, Abfragedatum: 

11.01.2005 

CMMI Distilled: A Practical Guide to Integrated 

Process Improvement, Second Edition, Addison 

Wesley, 2003 

[ARC 2001] Carnegie Mellon University, Software Engineering 

Institute, Appraisal Requirements for CMMI, 

Version 1.1 (ARC 1.1), 

http://www.sei.cmu.edu/publications/documents/ 

01.reports/01tr034.html, Abfragedatum: 

13.12.2004 

[CMMI 2001] Carnegie Mellon University, Software Engineering 

Institute, CMMI for Systems Engineering and 

Software Engineering, CMMI-SE/SW, V1.1, 2001, 

http://www.sei.cmu.edu/publications/documents/ 

02.reports/02tr002.html, Abfragedatum: 

13.12.2004 

[Cockburn 

2003] 

Allistair Cockburn, People and Methodologies in 

Software Development, Dissertation, Universität 

Oslo, 2003, 

http://alistair.cockburn.us/crystal/books/pamisd/pe 

opleandmethodologiesinsoftwaredevelopment.pdf, 

Abfragedatum: 3.12.2004 



>> 

111 

111

Anlagen 

[DeWeese, 

Boutin 1997] 

Perry DeWeese, Daniel Boutin, Single Software 

Process Framework, STC Track 1, DOD Software 

Policy, 1997, http://www.stc-online.org/cdrom/1997/track1.pdf, 

S.40ff, Abfragedatum: 

3.12.2004 

[Duden 2003] Duden Deutsches Universalwörterbuch, 

Bibliographisches Institut, Mannheim, 2003 

[Grundmann, 

Alth 2003] 

[Hammer 

2002] 

[Jacobson, 

Booch, 

Rumbaugh 

1999] 

[Jeckle et al. 

2004] 

p.a.m., Prototypen Entwicklung eines 

Objektorientierten Projektmanagement Tools, FH 

Reutlingen, 2003, 

http://www.MarkusGrundmann.de/images/stories/ 

articles/pam/pam dokumentation.pdf, 


Michael Hammer, Der Weg zum supereffizienten 

Unternehmen, Manager Magazin 

Verlagsgesellschaft, Harvard Business Manager 

02/2002 

Ivar Jacobson, Grady Booch, James Rumbaugh, 

The Unified Software Development Process, 

Addison-Wesley, 1999 

Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara 

Zengler, Stefan Queins, UML 2 glasklar, Carl 

Hanser Verlag, 2004 



>> 

112 

112

Anlagen 

[Kranz 2004] Michael Kranz, Bewertung des neuen V-Modell 

XT aus Sicht von Capability Model Integration 

(CMMI), Diplomarbeit, Technische Universität 

München, 2004, 

http://www.kbst.bund.de/Anlage305544/ 

Bewertung+des+neuen+V- 

Modells+XT+aus+Sicht+von+Capability+Maturity 

+Model+Integration+%281%2c2+MB%29.pdf, 


[Krempel 2004] Stefan Krempl, Das Chaos Prinzip, Warum so viele 

IT-Großprojekte scheitern, Heise Verlag, c’t 2004, 

Heft 23, S. 218 ff. 

[Kruchten 

2004] 

[Rechenberg, 

Pomberger 

1999] 

[Reitzig, Miller, 

West et al. 

2003] 

Philippe Kruchten, The Rational Unified Process, 

An Introduction, 3. Ausgabe, Pearson Education, 

2004 

Peter Rechenberg, Gustav Pomberger, Informatik 

Handbuch, 2., aktualisierte und erweiterte Auflage, 

Carl Hanser Verlag, 1999 

Rolf Reitzig, John Miller, Dave West, Raymond 

Kile, Achieving Capability Maturity Model 

Integration (CMMI) Maturity Level 2 Using IBM 

Rational Software’s Solutions, Rational Software 

Whitepaper, 2003, 

http://www3.software.ibm.com/ibmdl/pub/ 

software/rational/web/whitepapers/2003/ 

govt/proc-change-mang.pdf, Abfragedatum: 

13.12.2004 

[RUP 2003] Rational Unified Process, Version 2003.06.13, 

Testversion erhältlich unter 

http://www.ibm.com/software/awdtools/ 

rup/index.html, Abfragedatum: 29.11.2004 



>> 

113 

113

Anlagen 

[SCAMPI 

2001] 

Carnegie Mellon University, Software Engineering 

Institute, Standard CMMI Appraisal Method for 

Process Improvement (SCAMPI), Version 1.1: 

Method Definition Document, 2001 

http://www.sei.cmu.edu/publications/ 

documents/01.reports/01hb001.html, 


[SPEM 2002] Object Management Group (OMG), Software 

Process Engineering Metamodel Specification, 

http://www.omg.org/cgi-bin/doc?formal/2002-11- 

14, Abfragedatum: 1.12.2004 

[Standish 2001] Extreme CHAOS, the 2001 update of the CHAOS 

report, The Standish Group International, Inc., 

2001, 

http://www.standishgroup.com/sample_research/ 

PDFpages/extreme_chaos.pdf, Abfragedatum: 

3.12.2004 

[Steinbuch, 

Steinbuch 

1999] 

[V-Modell XT 

2004] 

[Wallmüller 

2001] 

Pitter Steinbuch, Andreas Steinbuch, 

Programmorganisation und Software Engineering, 

Kiehl Verlag, 1999 

V-Modell XT 2004, Version 0.9, Prozessmodell 

Dokumentation, 

http://www.kbst.bund.de/Anlage305462/ 

Dokumentation_komplett.pdf, Abfragedatum: 

3.12.2004 

Dr. Ernst Wallmüller, Software 

Qualitätsmanagement in der Praxis, Software- 

Qualität durch Führung und Verbesserung von 

Software-Prozessen, 2. Ausgabe, Carl Hanser 

Verlag, 2001 



>> 

114 

114

Anlagen 

8.2 Abkürzungsverzeichnis 

CMMI Capability Maturity Model Integration 

DoD US Department of Defense 

FURPS Functional, Usability, Reliability, Performance 

und Supportability Requirements 

GQM Goal Question Metric 

HTML Hyper Text Markup Language 

OMG Object Management Group 

RUP Rational Unified Process 

SCAMPI Standard CMMI Appraisal Method for Process 

Improvement 

SEI Software Engineering Institute der Carnegie 

Mellon University 

SPEM Software Process Engineering Metamodel 

SWOT Strength, Weaknesses, Opportunities und Threats 

UML Unified Modeling Language 

XML Extended Markup Language 



>> 

115 

115

Eidesstattliche Erklärung 

8.3 Eidesstattliche Erklärung 

Ich versichere, dass ich diese Diplomarbeit selbstständig verfasst, 

keine anderen als die angegebenen Quellen und Hilfsmittel benutzt 

sowie alle wörtlich oder sinngemäß übernommenen Stellen in der 

Arbeit gekennzeichnet habe. Die Arbeit wurde noch keiner 

Kommission zur Prüfung vorgelegt und verletzt in keiner Weise 

Rechte Dritter. 

_______________________________ den ___________________ 

______________________________________________________ 



>> 

116 

116

Anhang A: CMMI Assessment RUP 

9 Anhang A: CMMI Assessment 

Rational Unified Process 

Anhang A 

CMMI Assessment Rational Unified Process 


Am Beispiel 

einer RUP-Erweiterung durch das V-Modell XT 

>> 

117 

117


Vorwort zum CMMI Assessment 

Die vorgenommene Bewertung des Rational Unified Process bezieht 

sich auf die potenziellen Möglichkeiten des Prozessmodells. Das 

bedeutet, dass eine Organisation, die das Prozessmodell implementiert, 

nicht automatisch zu diesen Ergebnissen gelangt. 

Die Bewertung beurteilt das Vorhandensein gewisser von CMMI 

geforderter Mechanismen. Sind diese vorhanden, so wird die jeweilige 

Praktik als bestanden eingestuft. Es obliegt der das Prozessmodell 

implementierenden Organisation die Aktivitäten oder Artefakte so 

auszugestalten, dass die vom CMMI gestellten Anforderungen 

tatsächlich erfüllt werden. 

Dies ist eine sehr wichtige Rahmenbedingung für die Interpretation der 

Ergebnisse. Oft werden in Prozessmodellen z.B. Reviews generisch 

dargestellt. Die einzelnen Review Anforderungen an den 

verschiedenen Stellen des CMMI werden als abgedeckt bewertet, wenn 

der RUP die beteiligten Rollen oder Review-Techniken beschreibt. 

Dies ist auf Grund der unterschiedlichen Gliederung der 

Prozessgebiete notwendig, um eine Bewertung durchführen zu können. 



118 

>> 118

119 


Prozessgebiet 

Tabelle 6: RUP CMMI Maturity Level 2 Assessment 

Maturity Level 2: Managed 

Ziel 

Processarea - Goal - Practice (Specific and Generic) 

Not 

Implementation Levels 

Partially Largely Fully 

Requirements Management x 

SG1 Manage Requirements x 

SP1.1 Obtain an Understanding of Requirements x 

SP1.2 Obtain Commitment to Requirements x 

SP1.3 Manage Requirements Changes x 

SP1.4 Maintain Bidirectional Traceability of Requirements x 

SP1.5 Identify Inconsistencies between Project Work and Requirements x 

Project Planning x 

SG1 Establish Estimates x 

SP1.1 Estimate the Scope of the Project x 

SP1.2 Establish Estimates of Work Product and Task Attributes x 

SP1.3 Define Project Life Cycle x 

SP1.4 Determine Estimates of Effort and Cost x 

SG2 Develop a Project Plan x 

SP2.1 Establish the Budget and Schedule x 

SP2.2 Identify Project Risks x 

SP2.3 Plan for Data Management x 

SP2.4 Plan for Project Resources x 

SP2.5 Plan for Needed Knowledge and Skills x 

Praktik 

119 

>> 


Am Beispiel einer RUP-Erweiterung durch das V-Modell XT

120 


Prozessgebiet 

Ziel 


Not 



SP2.6 Plan Stakeholder Involvement x 

SP2.7 Establish the Project Plan x 

SG3 Obtain Commitment to the Plan x 

SP3.1 Review Plans that Affect the Project x 

SP3.2 Reconcile Work and Resource Levels x 

SP3.3 Obtain Plan Commitment x 

Project Monitoring and Control x 

SG1 Monitor Project Against Plan x 

SP1.1 Monitor Project Planning Parameters x 

SP1.2 Monitor Commitments x 

SP1.3 Monitor Project Risks x 

SP1.4 Monitor Data Management x 

SP1.5 Monitor Stakeholder Involvement x 

SP1.6 Conduct Progress Reviews x 

SP1.7 Conduct Milestone Reviews x 

SG2 Manage Corrective Action to Closure x 

SP2.1 Analyze Issues x 

SP2.2 Take Corrective Action x 

SP2.3 Manage Corrective Action x 

Supplier Agreement Management x 

SG1 Establish Supplier Agreements x 

SP1.1 Determine Acquisition Type x 

Praktik 

120 

>> 



121 


Prozessgebiet 

Ziel 


Not 



SP1.2 Select Suppliers x 

SP1.3 Establish Supplier Agreements x 

SG2 Satisfy Supplier Agreements x 

SP2.1 Review COTS Products x 

SP2.2 Execute the Supplier Agreement x 

SP2.3 Accept the Acquired Product x 

SP2.4 Transition Products x 

Measurement and Analysis x 

SG1 Align Measurement and Analysis Activities x 

SP1.1 Establish Measurement Objectives x 

SP1.2 Specify Measures x 

SP1.3 Specify Data Collection and Storage Procedures x 

SP1.4 Specify Analysis Procedures x 

SG2 Provide Measurement Results x 

SP2.1 Collect Measurement Data x 

SP2.2 Analyze Measurement Data x 

SP2.3 Store Data and Results x 

SP2.4 Communicate Results x 

Process and Product Quality Assurance x 

SG1 Objectively Evaluate Processes and Work Products x 

SP1.1 Objectively Evaluate Processes x 

SP1.2 Objectively Evaluate Work Products and Services x 

Praktik 

121 

>> 



122 


Prozessgebiet 

Ziel 


Not 



SG2 Provide Objective Insight x 

SP2.1 Communicate and Ensure Resolution of Noncompliance Issues x 

SP2.2 Establish Records x 

Configuration Management x 

SG1 Establish Baselines x 

SP1.1 Identify Configuration Items x 

SP1.2 Establish a Configuration Management System x 

SP1.3 Create or Release Baselines x 

SG2 Track and Control Changes x 

SP2.1 Track Change Requests x 

SP2.2 Control Configuration Items x 

SG3 Establish Integrity x 

SP3.1 Establish Configuration Management Records x 

SP3.2 Perform Configuration Audits x 

Generic Goals & Practices 

GG2 Institutionalize a Managed Process 

GP2.1 (CO 1) Establish an Organizational Policy x 

GP2.2 (AB 1) Plan the Process x 

GP2.3 (AB 2) Provide Ressources x 

GP2.4 (AB 3) Assign Responsibility x 

GP2.5 (AB 4) Train People x 

GP2.6 (DI 1) Manage Configurations x 

Praktik 

122 

>> 



123 


Prozessgebiet 

Ziel 


Not 



GP2.7 (DI 2) Identify and Involve Stakeholders x 

GP2.8 (DI 3) Monitor and Control the Process x 

GP2.9 (VE 1) Objectively Evaluate Adherence x 

GP2.10 (VE 2) Review Status with Higher Level Management x 

Praktik 

123 

>> 



124 


Prozessgebiet 


Maturity Level 3: Defined 

Ziel 


Not 



Requirements Development x 

SG1 Develop Customer Requirements x 

SP1.1 Elicit Needs x 

SP1.2 Develop the Customer Requirements x 

SG2 Develop Product Requirements x 

SP2.1 Establish Product and Product-Component Requirements x 

SP2.2 Allocate Product Component-Requirements x 

SP2.3 Identify Interface Requirements x 

SG3 Analyze and Validate Requirements x 

SP3.1 Establish Operational Concepts and Scenarios x 

SP3.2 Establish a Definition of Required Functionality x 

SP3.3 Analyze Requirements x 

SP3.4 Analyze Requirements to Achieve Balance x 

SP3.5 Validate Requirements with Comprehensive Methods x 

Technical Solution x 

SG1 Select Product-Component Solutions x 

SP1.1 Develop Detailed Alternative Solutions and Selection Criteria x 

SP1.2 Evolve Operational Concepts and Scenarios x 

Praktik 

124 

>> 



125 


Prozessgebiet 

Ziel 


Not 



SP1.3 Select Product-Component Solutions x 

SG2 Develop the Design x 

SP2.1 Design the Product or Product Component x 

SP2.2 Establish a Technical Data Package x 

SP2.3 Design Interfaces Using Criteria x 

SP2.4 Perform Make, Buy or Reuse Analyses x 

SG3 Implement the Product Design x 

SP3.1 Implement the Design x 

SP3.2 Develop Product Support Documentation x 

Product Integration x 

SG1 Prepare for Product Integration x 

SP1.1 Determine Integration Sequence x 

SP1.2 Establish the Product Integration Environment x 

SP1.3 Establish Product Integration Procedures and Criteria x 

SG2 Ensure Interface Compatibility x 

SP2.1 Review Interface Descriptions for Completeness x 

SP2.2 Manage Interfaces x 

SG3 Assemble Product Components and Deliver the Product x 

SP3.1 Confirm Readiness of Product Components for Integration x 

SP3.2 Assemble Product Components x 

SP3.3 Evaluate Assembled Product Component x 

SP3.4 Package and Deliver the Product or Product Component x 

Praktik 

125 

>> 



126 


Prozessgebiet 

Ziel 


Not 



Verification x 

SG1 Prepare for Verification x 

SP1.1 Select Work Products for Verification x 

SP1.2 Establish the Verification Environment x 

SP1.3 Establish Verification Procedures and Criteria x 

SG2 Perform Peer Reviews x 

SP2.1 Prepare for Peer Reviews x 

SP2.2 Conduct Peer Reviews x 

SP2.3 Analyze Peer Review Data x 

SG3 Verify Selected Work Products x 

SP3.1 Perform Verification x 

SP3.2 Analyze Verification Results and Identify Corrective Action x 

Validation x 

SG1 Prepare for Validation x 

SP1.1 Select Products for Validation x 

SP1.2 Establish the Validation Environment x 

SP1.3 Establish Validation Procedures and Criteria x 

SG2 Validate Product or Product Components x 

SP2.1 Perform Validation x 

SP2.2 Analyze Validation Results x 

Praktik 

126 

>> 



127 


Prozessgebiet 

Ziel 


Not 



Organizational Process Focus x 

SG1 Determine Process-Improvement Opportunities x 

SP1.1 Establish Organizational Process Needs x 

SP1.2 Appraise the Organization’s Processes x 

SP1.3 Identify the Organization's Process Improvements x 

SG2 Plan and Implement Process-Improvement Activities x 

SP2.1 Establish Process Action Plans x 

SP2.2 Implement Process Action Plans x 

SP2.3 Deploy Organizational Process Assets x 

SP2.4 Incorporate Process-Related Experiences into the Organizational Process Assets x 

Organizational Process Definition x 

SG1 Establish Organizational Process Assets x 

SP1.1 Establish Standard Processes x 

SP1.2 Establish Life-Cycle Model Descriptions x 

SP1.3 Establish Tailoring Criteria and Guidelines x 

SP1.4 Establish the Organization’s Measurement Repository x 

SP1.5 Establish the Organization’s Process Asset Library x 

Organizational Training x 

SG1 Establish an Organizational Training Capability x 

SP1.1 Establish the Strategic Training Needs x 

Praktik 

127 

>> 



128 


Prozessgebiet 

Ziel 


Not 



SP1.2 Determine Which Training Needs Are the Responsibility of the Organization x 

SP1.3 Establish an Organizational Training Tactical Plan x 

SP1.4 Establish Training Capability x 

SG2 Provide Necessary Training x 

SP2.1 Deliver Training x 

SP2.2 Establish Training Records x 

SP2.3 Assess Training Effectiveness x 

Integrated Project Management x 

SG1 Use the Project’s Defined Process x 

SP1.1 Establish the Project’s Defined Process x 

SP1.2 Use Organizational Process Assets for Planning Project Activities x 

SP1.3 Integrate Plans x 

SP1.4 Manage the Project Using the Integrated Plans x 

SP1.5 Contribute to the Organizational Process Assets x 

SG2 Coordinate and Collaborate with Relevant Stakeholders x 

SP2.1 Manage Stakeholder Involvement x 

SP2.2 Manage Dependencies x 

SP2.3 Resolve Coordination Issues x 

Risk Management x 

SG1 Prepare for Risk Management x 

SP1.1 Determine Risk Sources and Categories x 

SP1.2 Define Risk Parameters x 

Praktik 

128 

>> 



129 


Prozessgebiet 

Ziel 


Not 



SP1.3 Establish a Risk Management Strategy x 

SG2 Identify and Analyze Risks x 

SP2.1 Identify Risks x 

SP2.2 Evaluate, Categorize and Prioritize Risks x 

SG3 Mitigate Risks x 

SP3.1 Develop Risk Mitigation Plans x 

SP3.2 Implement Risk Mitigation Plans x 

Decision Analysis and Resolution x 

SG1 Evaluate Alternatives x 

SP1.1 Establish Guidelines for Decision Analysis x 

SP1.2 Establish Evaluation Criteria x 

SP1.3 Identify Alternative Solutions x 

SP1.4 Select Evaluation Methods x 

SP1.5 Evaluate Alternatives x 

SP1.6 Select Solutions x 

Generic Goals & Practices 

GG3 Institutionalize a Defined Process 

GP3.1 Establish a Defined Process x 

GP3.2 Collect Improvement Information x 

Praktik 

129 

>> 



130 


Prozessgebiet 


Maturity Level 4: Quantitively Managed 

Ziel 


Not 



Organizational Process Performance x 

SG1 Establish Performance Baselines and Models x 

SP1.1 Select Processes x 

SP1.2 Establish Process Performance Measures x 

SP1.3 Establish Quality and Process-Performance Objectives x 

SP1.4 Establish Process Performance Baselines x 

SP1.5 Establish Process Performance Models x 

Quantitative Project Management x 

SG1 Quantitatively Manage the Project x 

SP1.1 Establish the Project’s Objectives x 

SP1.2 Compose the Defined Process x 

SP1.3 Select the Subprocesses that Will Be Statistically Managed x 

SP1.4 Manage Project Performance x 

SG2 Statistically Manage Subprocess Performance x 

SP2.1 Select Measures and Analytic Techniques x 

SP2.2 Apply Statistical Methods to Understand Variation x 

SP2.3 Monitor Performance of the Selected Subprocesses x 

SP2.4 Record Statistical Management Data x 

Praktik 

130 

>> 



131 

Anhang 

A: CMMI Assessment RUP 

Prozessgebiet 


Maturity Level 5: Optimizing 

Ziel 


Not 



Organizational Innovation and Deployment x 

SG1 Select Improvements x 

SP1.1 Collect and Analyze Improvement Proposals x 

SP1.2 Identify and Analyze Innovations x 

SP1.3 Pilot Improvements x 

SP1.4 Select Improvements for Deployment x 

SG2 Deploy Improvements x 

SP2.1 Plan the Deployment x 

SP2.2 Manage the Deployment x 

SP2.3 Measure Improvement Effects x 

Causal Analysis and Resolution x 

SG1 Determine Causes of Defects x 

SP1.1 Select Defect Data for Analysis x 

SP1.2 Analyze Causes x 

SG2 Address Causes of Defects x 

SP2.1 Implement the Action Proposals x 

SP2.2 Evaluate the Effect of Changes x 

SP2.3 Record Data x 

Praktik 

131 

>> 



Anhang B: Modelle des Prototypen 

10 Anhang B: Modelle des 

Prototypen 

Anhang B 

Modelle des Prototypen 




>> 

132 

132


Vorwort zu den Modellen des Protoypen 

Dieser Anhang zeigt die wesentlichen Diagramme der 

Prototypenmodellierung. Sie wurden mit dem RUP Modeler (siehe 

Kapitel 4 Werkzeugumgebungen) erstellt und sind stereotypisierte 

Klassendiagramme. Der Workflow in Abbildung 53 ist eine 

Ausnahme, hierbei handelt es sich um ein stereotypisiertes 

Aktivitätsdiagramm. 

Die Zuordnung der Aktivitäten zu den einzelnen Workflow Details 

geschieht im RUP Modeler über Dialoge. Da hierzu kein 

Überblicksdiagramm existiert, wird von der Darstellung abgesehen. 

Die Zusammenhänge gehen aus der Vorstellung des Prototypen in 

Kapitel 5 hervor. 




>> 

133 

133


Abbildung 52: Dependencies des RUP V-Modell XT Integration Plugins 




>> 

134 

134


Abbildung 53: Workflow des Plugins 




>> 

135 

135


Abbildung 54: Aktivitäten und Artefakte der V-Modell Process Engineer Rolle 




>> 

136 

136


Abbildung 55: Aktivitäten und Artefakte der Supplier Agreement Manager 

Rolle 

Abbildung 56: Aktivitäten und Artefakte der Trainer of Staff Rolle 




>> 

137 

137

Anhang C: V-Modell XT Metamodell 

11 Anhang C: V-Modell XT 

Metamodell 

Anhang C 

V-Modell XT Metamodell 




>> 

138 

138


Vorwort zum V-Modell XT Metamodell 

Bei dem V-Modell XT Metamodell handelt es sich um ein XML 

Schema. Da dieses Format für Menschen nicht sehr gut lesbar ist, 

wurde das XSD der Übersichlichkeit halber in eine bessere Form 

gebracht und ist als Diagramm abgedruckt. Ansonsten haben keine 

Modifikationen stattgefunden. 




>> 

139 

139





>> 

140 

140

Prozessmodellintegration - Am Beispiel einer RUP ... - ftp.uni-kl.de.

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?