Bewertung-des-neuen-V-Modells-XT-aus-Sicht - ftp.uni-kl.de.

Technische Universität München
Fakultät für Informatik
Diplomarbeit
Bewertung des neuen V-Modells XT aus Sicht von
Capability Maturity Model Integration (CMMI®)
A CMMI® Based Evaluation of the V-Modell XT
Michael Kranz

Technische Universität München
Fakultät für Informatik
Diplomarbeit
Bewertung des neuen V-Modells XT aus Sicht von
Capability Maturity Model Integration (CMMI®)
A CMMI® Based Evaluation of the V-Modell XT
Michael Kranz
Aufgabensteller: Prof. Dr. Dr. h.c. Manfred Broy
Betreuer: Michael Gnatz (TU München)
Doris Rauh (Siemens AG)
Dr. Winfried Rußwurm (Siemens AG)
Abgabedatum: 16.08.2004
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 2 von 129

Ehrenwörtliche Erklärung
Ich versichere, dass ich diese Diplomarbeit selbständig verfasst und nur die angegebenen Quellen
und Hilfsmittel verwendet habe.
(Ort, Datum) (Unterschrift)
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 3 von 129

Danksagung
An dieser Stelle danke ich allen herzlich, die zum Gelingen dieser Diplomarbeit beigetragen haben.
Insbesondere möchte ich mich bedanken bei:
• Prof. Dr. Dr. h.c. Manfred Broy, Inhaber des Lehrstuhls für Software & Systems Engineering
an der Fakultät für Informatik der TU München, für die Betreuung als Aufgabensteller,
• Michael Gnatz für sein Engagement als Betreuer an der TU,
• Doris Rauh als Betreuerin für Fragen des V-Modells XT bei der Firma Siemens, die trotz
des hohen Arbeitsaufwands im Projekt, genug Zeit für meine Betreuung fand und für
meine Fragen und Verbesserungsvorschläge immer zugänglich war,
• Dr. Winfried Rußwurm als Betreuer für Fragen des CMMI® bei der Firma Siemens für
die zahlreichen Verbesserungsvorschläge und die gute Betreuung in der Endphase trotz
regelmäßiger Dienstreisen und hoher Arbeitsbelastung,
• Sabine Mittrach, Marion Wittmann und Günter Böckle, die für meine Fragen immer ein
offenes Ohr hatten und den Arbeitsplatz mit mir teilten,
• allen Mitarbeitern der Abteilungen CT SE 3 und CT SE 4 der Siemens AG für viele Gespräche,
Ratschläge und ihr Interesse an meiner Arbeit,
• meinem Vater, der sich für Fragen und Diskussionen immer Zeit genommen und viele
Verbesserungsvorschläge gemacht hat,
• meiner Mutter und meiner Freundin Carmen für die Unterstützung bei meiner Arbeit.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 4 von 129

Zusammenfassung
In der vorliegenden Diplomarbeit wurde das V-Modell XT mittels des Prozessmodells „Capability
Maturity Model Integration (CMMI®)“ und den Bewertungsverfahren „Standard CMMI Appraisal
Method for Process Improvement (SCAMPI®)“ und Siemens Process Assessment (SPA)
bewertet.
Das Vorgehensmodell wurde im Sommer 1992 von den Bundesbehörden als Software-
Entwicklungsstandard für Systeme der Informationstechnologie offiziell erlassen und 1997 durch
eine verbesserte Version als so genanntes „V-Modell 97“ überarbeitet herausgegeben. Damit war
ein Standard geschaffen, der sich im deutschsprachigen Europa sowohl im zivilen als auch im
militärischen Bereich durchgesetzt hat. Mit der Weiterentwicklung zum so genannten
V-Modell XT wird ein im Anwendungsbereich erweiterter, an den neuesten Stand der Technologie
angepasster moderner Systementwicklungsstandard geschaffen. Dieser eignet sich für die
Entwicklung integrierter Systeme mit Hardware, Software und logistischen Anteilen. Sein Anwendungsbereich
erstreckt sich von der Anforderungsanalyse über die eigentliche Entwicklungsphase
bis zur konzeptionellen Auslegung der nach Entwicklungsende folgenden
Produktlebenszyklusphasen Fertigung, Betrieb, Wartung und Stilllegung.
Einleitend werden die Konzepte von V-Modell XT und CMMI® erklärt. Dazu setzt die Diplomarbeit
auf dem Stand des V-Modells XT vom 30. Juni 2004 auf. Auf diesem Stand wird untersucht,
durch welche Elemente des V-Modells XT die Praktiken des CMMI® erfüllt werden.
Dabei werden die Schwächen und der Erfüllungsgrad jeder Praktik herausgearbeitet. Aus den
gewonnenen Ergebnissen wird eine Bewertung des V-Modells XT mit den zwei verschiedenen
Methoden, SCAMPI® und SPA durchgeführt. Die durch die beiden Bewertungsmethoden erzielten
Reifegrade werden diskutiert und Maßnahmen für die Verbesserung des V-Modells XT herausgearbeitet.
Die Bewertung beschränkt sich auf die Dokumentation des V-Modells XT, es wird
also nicht wie in einem echten Assessment das Leben in den Projekten beurteilt.
Das Ergebnis der Bewertung nach SCAMPI® ergab den Reifegrad 1. Bei genauerer Analyse
zeigt sich jedoch, dass der Reifegrad 3 schon fast erreicht ist, da im V-Modell XT die wesentlichen
Vorgehensweisen angelegt sind. Die Bewertung nach SPA bestätigt diese Beurteilung und
ergibt einen Reifegrad von 2,75. Aus den Schwächen wurden achtzehn verhältnismäßig einfach
umsetzbare Maßnahmen erarbeitet, die zu einer Verbesserung in Richtung von Reifegrad 3 führen
würden.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 5 von 129

Inhaltsverzeichnis Seite
1 Einleitung.....................................................................................................9
1.1 Motivation............................................................................................................. 9
1.2 Ziel der Arbeit....................................................................................................... 9
1.3 Vorgehen ............................................................................................................ 10
2 Überblick ...................................................................................................11
2.1 Das V-Modell XT..................................................................................................11
2.1.1 Historie......................................................................................................11
2.1.2 Ziele und Zielgruppen............................................................................... 12
2.1.3 Struktur des V-Modells XT ........................................................................ 13
2.1.4 Vorgehensbausteine (VB)......................................................................... 14
2.1.5 Produkt, Produktgruppe, Thema............................................................... 16
2.1.6 Produktabhängigkeit................................................................................. 18
2.1.7 Rollen....................................................................................................... 19
2.1.8 Aktivität, Aktivitätsgruppe, Teilaktivität ...................................................... 20
2.1.9 Projektdurchführungsstrategien................................................................ 21
2.1.10 Entscheidungspunkte ............................................................................... 22
2.2 CMMI® (Capability Maturity Model Integration)............................................... 22
2.2.1 Motivation für die Entwicklung des CMMI® .............................................. 23
2.2.2 Aufbau des CMMI®.................................................................................. 24
2.2.3 Stufenförmige Darstellung ........................................................................ 24
2.2.4 Kontinuierliche Darstellung....................................................................... 27
2.2.5 Bewertung der Darstellungen ................................................................... 29
2.3 Gemeinsamkeiten von V-Modell XT und CMMI® ............................................. 29
2.4 Unterschiede zwischen V-Modell XT und CMMI®............................................ 29
3 Das V-Modell XT aus Sicht des CMMI®...................................................31
3.1 Requirements Management (Maturity Level 2) ................................................ 32
3.1.1 Manage Requirements ............................................................................. 32
3.2 Project Planning (Maturity Level 2) .................................................................. 33
3.2.1 Establish Estimates .................................................................................. 34
3.2.2 Develop a Project Plan............................................................................. 34
3.2.3 Obtain Commitment to the Plan................................................................ 36
3.3 Project Monitoring and Control (Maturity Level 2) .......................................... 36
3.3.1 Monitor Project Against Plan..................................................................... 37
3.3.2 Manage Corrective Action to Closure ....................................................... 38
3.4 Supplier Agreement Management (Maturity Level 2) ...................................... 39
3.4.1 Establish Supplier Agreements................................................................. 39
3.4.2 Satisfy Supplier Agreements..................................................................... 40
3.5 Measurement and Analysis (Maturity Level 2)................................................. 41
3.5.1 Align Measurement and Analysis Activities............................................... 41
3.5.2 Provide Measurement Results.................................................................. 42
3.6 Process and Product Quality Assurance (Maturity Level 2) ........................... 43
3.6.1 Objectively Evaluate Processes and Work Products................................. 43
3.6.2 Provide Objective Insight.......................................................................... 44
3.7 Configuration Management (Maturity Level 2)................................................. 44
3.7.1 Establish Baselines .................................................................................. 45
3.7.2 Track and Control Changes...................................................................... 45
3.7.3 Establish Integrity..................................................................................... 46
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 6 von 129

3.8 Requirements Development (Maturity Level 3)................................................ 46
3.8.1 Develop Customer Requirements............................................................. 47
3.8.2 Develop Product Requirements................................................................ 47
3.8.3 Analyze and Validate Requirements ......................................................... 48
3.9 Technical Solution (Maturity Level 3) ............................................................... 49
3.9.1 Select Product-Component Solutions....................................................... 49
3.9.2 Develop the Design.................................................................................. 50
3.9.3 Implement the Product Design ................................................................. 51
3.10 Product Integration (Maturity Level 3).............................................................. 51
3.10.1 Prepare for Product Integration ................................................................ 51
3.10.2 Ensure Interface Compatibility.................................................................. 52
3.10.3 Assemble Product Components and Deliver the Product ......................... 53
3.11 Verification (Maturity Level 3) ........................................................................... 53
3.11.1 Prepare for Verification............................................................................. 54
3.11.2 Perform Peer Reviews.............................................................................. 54
3.11.3 Verify Selected Work Products ................................................................. 55
3.12 Validation (Maturity Level 3).............................................................................. 56
3.12.1 Prepare for Validation............................................................................... 56
3.12.2 Validate Product or Product Components................................................. 57
3.13 Organizational Process Focus (Maturity Level 3)............................................ 57
3.13.1 Determine Process-Improvement Opportunities ....................................... 57
3.13.2 Plan and Implement Process-Improvement Activities ............................... 58
3.14 Organizational Process Definition (Maturity Level 3)...................................... 59
3.14.1 Establish Organizational Process Assets.................................................. 59
3.15 Organizational Training (Maturity Level 3) ....................................................... 60
3.15.1 Establish an Organizational Training Capability........................................ 61
3.15.2 Provide Necessary Training...................................................................... 62
3.16 Integrated Project Management (Maturity Level 3).......................................... 62
3.16.1 Use the Project’s Defined Process ........................................................... 63
3.16.2 Coordinate and Collaborate with Relevant Stakeholders .......................... 64
3.17 Risk Management (Maturity Level 3) ................................................................ 65
3.17.1 Prepare for Risk Management.................................................................. 65
3.17.2 Identify and Analyze Risks........................................................................ 66
3.17.3 Mitigate Risks........................................................................................... 66
3.18 Decision Analysis and Resolution (Maturity Level 3)...................................... 67
3.19 Organizational Process Performance (Maturity Level 4) ................................ 67
3.20 Quantitative Project Management (Maturity Level 4) ...................................... 68
3.21 Organizational Innovation and Deployment (Maturity Level 5) ...................... 69
3.22 Causal Analysis and Resolution (Maturity Level 5)......................................... 69
3.23 Generic Goals .................................................................................................... 70
3.23.1 Institutionalize a Managed Process (GG 2) .............................................. 70
3.23.2 Institutionalize a Defined Process (GG 3)................................................. 72
4 Bewertung des V-Modells XT...................................................................73
4.1 Methoden der Bewertung.................................................................................. 73
4.1.1 Standard CMMI Appraisal Method for Process Improvement (SCAMPI®) 73
4.1.2 Siemens Process Assessment (SPA) ....................................................... 74
4.2 Auswertung der Ergebnisse ............................................................................. 79
4.2.1 Auswertung nach SCAMPI®-Verfahren.................................................... 80
4.2.2 Auswertung nach SPA.............................................................................. 83
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 7 von 129

4.3 Endergebnisse nach SCAMPI® und SPA......................................................... 90
4.4 Ansätze für Verbesserungsmaßnahmen.......................................................... 91
5 Ausblick.....................................................................................................94
Anhang...............................................................................................................95
A Ergänzende Informationen, Tabellen und Abbildungen ........................96
A.1 CMMI®-Erfüllungsgrade des V-Modells XT in der Übersicht .......................... 96
A.2 Bewertung der Prozessgebiete nach SPA ......................................................110
A.3 Konventionsabbildung im V-Modell XT: CMMI®-Abbildung des
V-Modells XT (Version 30.06.04) ......................................................................114
Einleitung............................................................................................................114
Requirements Management................................................................................115
Project Planning .................................................................................................116
Project Monitoring and Control............................................................................116
Supplier Agreement Management.......................................................................117
Measurement and Analysis.................................................................................117
Process and Product Quality Assurance .............................................................117
Configuration Management.................................................................................118
Requirements Development................................................................................118
Technical Solution...............................................................................................119
Product Integration .............................................................................................119
Verification......................................................................................................... 120
Validation........................................................................................................... 121
Organizational Process Focus ........................................................................... 121
Organizational Process Definition...................................................................... 121
Organizational Training...................................................................................... 122
Integrated Project Management......................................................................... 122
Risk Management.............................................................................................. 123
Decision Analysis and Resolution ...................................................................... 123
Organizational Process Performance................................................................. 123
Quantitative Project Management...................................................................... 124
Organizational Innovation and Deployment........................................................ 124
Causal Analysis and Resolution......................................................................... 124
Institutionalize a Managed Process ................................................................... 125
Institutionalize a Defined Process...................................................................... 125
B Quellenverzeichnis .................................................................................126
C Abbildungsverzeichnis...........................................................................127
D Tabellenverzeichnis ................................................................................129
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 8 von 129

1 Einleitung
Im Folgenden werden dem Leser die Motivation für diese Diplomarbeit, deren Ziele und die
Vorgehensweise vorgestellt.
1.1 Motivation
Das V-Modell 97 ist mittlerweile für viele Unternehmen und Behörden ein Standardwerk für die
Organisation und Durchführung von IT-Vorhaben. Es verbessert die Produktqualität und die Kooperation
zwischen Firmen und Behörden bei gemeinsamen Entwicklungen. Darüber hinaus soll
es auch kleinen und mittelständischen Unternehmen die Möglichkeit bieten, auf öffentlich finanzierte
Vorgaben zur Einführung und Verbesserung von Entwicklungs- und Managementprozessen
zurückzugreifen.
Nach der Fertigstellung des V-Modells im Jahr 1997 ist keine Fortschreibung mehr erfolgt. Vor
diesem Hintergrund wurde die Weiterentwicklung des Entwicklungsstandards für IT-Systeme des
Bundes auf Basis des V-Modells 97 beschlossen. Der Arbeitstitel des neuen Modells lautet
V-Modell XT.
Organisationen orientieren sich aber auch immer mehr an den Anforderungen des System-
Modells Capability Maturity Model Integration (CMMI®) des Software Engineering Institute
(SEI) der Carnegie Mellon University (CMU), wobei eine Bewertung der Prozessreife z.B. durch
Assessments immer öfter durchgeführt wird und sich beispielsweise ein Reifegrad 3 als Wettbewerbsvorteil
erweist.
Damit ergibt sich in Zukunft folgendes Spannungsfeld: In Organisationen werden praktische
Vorgehensweisen nach V-Modell XT existieren, gleichzeitig aber Prozessanforderungen nach
CMMI® zu erfüllen sein.
1.2 Ziel der Arbeit
Ziel der Diplomarbeit ist es, das V-Modell XT mit dem Capability Maturity Model Integration
v1.1 staged SE/SW (CMMI®) [CMMI02] zu bewerten, um dessen Qualität beurteilen zu können.
Dazu ist es nötig, die Konzepte beider Modelle darzustellen, sowie die verschiedenen Begriffe
aufeinander abzubilden. Um einschätzen zu können, welchen CMMI®-Reifegrad man durch die
Benutzung des V-Modells XT erreicht, soll ein simuliertes Assessment durchgeführt werden.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 9 von 129

EINLEITUNG
Dadurch können Verbesserungsvorschläge für das in der Entstehung befindliche V-Modell XT
herausgearbeitet werden, die möglicherweise noch eingearbeitet werden können.
1.3 Vorgehen
In Kapitel 2 werden zunächst beide Modelle vorgestellt, wobei besonderer Wert auf die wesentlichen
Konzepte und Begriffe gelegt wird. Anschließend werden die Unterschiede und Gemeinsamkeiten
von V-Modell XT und CMMI® bezüglich Philosophie, Zielsetzung und Struktur
herausgearbeitet.
Im dritten Kapitel wird untersucht, welche Elemente des V-Modells XT die einzelnen Forderungen
des CMMI® umsetzen. Dabei erfolgt gleichzeitig auch eine detaillierte Bewertung, in welchem
Maße die Forderungen erfüllt sind. Während in der CMMI®-Konventionssicht des
V-Modells XT die Beziehungen auf der Ebene der Ziele des CMMI® hergestellt werden, geht
die Bewertung in dieser Diplomarbeit eine Ebene tiefer auf die einzelnen Praktiken des CMMI®
ein. Dem Detaillierungsgrad entsprechend werden diese bis hinunter auf die Ebene der Themen
und Teilaktivitäten dem V-Modell XT gegenübergestellt.
Ziel des Kapitels 4 ist eine vergleichende Bewertung des V-Modells XT mit dem CMMI®-
Bewertungsverfahren (SCAMPI®) und dem Verfahren der Siemens AG (Siemens Process Assessment).
Dazu werden zunächst die verwendeten Methoden der Bewertung beschrieben. Danach
folgt die Auswertung nach den beiden erwähnten Verfahren. Diese soll als Ergebnis den
CMMI®-Reifegrad des V-Modells XT ermitteln, sowie die Stärken und Schwächen des
V-Modells XT aufzeigen. Die beiden Endergebnisse werden einander gegenübergestellt und Ansätze
für die Verbesserung des V-Modells XT erarbeitet.
Im letzten Kapitel wird ein Ausblick auf weiterführende Arbeiten gegeben.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 10 von 129

2 Überblick
Im Folgenden werden die Konzepte und grundlegenden Elemente von V-Modell XT und
CMMI® erklärt, die für das Verständnis der weiteren Arbeit benötigt werden.
2.1 Das V-Modell XT
In diesem Kapitel werden die grundlegenden Elemente des V-Modells XT [VMxt04] beschrieben.
Es geht hier nicht darum die gesamte Funktionalität des V-Modells XT sondern die wichtigsten
Elemente zu erklären, die in Kapitel 3 benutzt werden.
2.1.1 Historie
In den 70er und 80er Jahren des 20. Jahrhunderts nahm die Bedeutung der Software bei der Entwicklung
von Produkten ständig zu. Ebenso stieg der Anteil der Software in den Entwicklungsprojekten.
Die drei wichtigen Projektziele:
• Einhaltung der Kosten,
• Einhaltung der Zeit und
• Gewährleistung der Qualität
konnten jedoch in der praktischen Projektarbeit bis heute nur teilweise erreicht werden [STA02].
Seit der so genannten „Softwarekrise“ Ende der 60er Jahre wurde daher versucht, durch geeignete
Prozessmodelle die Softwareentwicklung in den Projekten zu verbessern [Bau93][ Schu99]. In
der Folge entstanden Entwicklungsstandards wie DOD-MIL 2167A, ISO 12207, GAM T 17,
ANSI/IEE 1498 oder ISO 9001.
Korrespondierend mit diesen Standards wurde Ende der 80er Jahre das Vorgehensmodell entwickelt,
im Folgenden als V-Modell bezeichnet. Es wurde ursprünglich im Auftrag des Bundesministeriums
für Verteidigung (BMVg) und in Zusammenarbeit mit dem Bundesamt für
Wehrtechnik und Beschaffung (BWB) in Koblenz von der Industrieanlagen-Betriebsgesellschaft
mbH (IABG) in Ottobrunn bei München erstellt. Im Sommer 1992 wurde es vom Bundesministerium
des Inneren (BMI) auch für den Bereich der Bundesverwaltung übernommen.
Dieses auch als „VM92“ [VM92] bezeichnete V-Modell war als Standard für Softwareentwicklung
für die Informationstechnologie (IT) gedacht. Zusammen mit der Herausgabe des VM92
wurde ein Gremium gegründet, welches dessen Verbesserung im Rahmen von Änderungsmanagement
zum Ziel hatte – die so genannte Änderungskonferenz (Äko).
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 11 von 129

ÜBERBLICK
Auf Anregung vieler Anwender wurde das VM92 gesteuert durch die Äko dann weiter verbessert
und 1997 als „VM97“ überarbeitet herausgegeben [VM97]. Eines der Ziele war damals die Erweiterung
zu einem Systemstandard für Softwareentwicklung im IT-Bereich.
Seitdem wurde das V-Modell 97 nicht mehr fortgeschrieben, beinhaltet daher nicht in allen Bereichen
den aktuellen Stand der Technologie. Zwar wurden im Umgang mit dem V-Modell 97
umfangreiche Erfahrungen gesammelt, die im Rahmen einer Weiterentwicklung zur Verbesserung
der Qualitätseigenschaften beitragen sollten, diese konnten aber nicht umgesetzt werden.
Des Weiteren sind inzwischen neue Standards entstanden, an welche das V-Modell angepasst
werden muss. So wird gerade an einem neuen Lebenszyklusstandard, ISO 15288, gearbeitet.
Auch die ISO 9001 wurde inzwischen in Richtung auf Prozesse überarbeitet. Daneben wurden
neue Verfahren entwickelt, Entwicklungsvorgehen zu bewerten, wie CMM oder CMMI®.
Software ist heute oft eingebettet in die Hardware bzw. in Systeme, welche auch aus Hardware -
gemeint ist hier Elektronik und Mechanik - bestehen. Dabei steuert die Software mehr und mehr
die Funktionalität des Systems. Betrachtet werden dann nicht nur reine IT-Systeme sondern allgemeine
Systeme, welche aus Software und Hardware bestehen. Ein gutes Beispiel dafür ist die
Entwicklung im Automobilsektor, wo die Software schon heute einen großen Teil der Funktionalität
übernommen hat, welche früher nur in Hardware realisiert wurde.
Wie das Beispiel zeigt, nehmen allgemeine Systeme an Bedeutung zu. Daraus entstand die Forderung,
Software- und Hardware-Prozesse zu synchronisieren und das V-Modell zu einem integrierten
Systementwicklungsprozess zu erweitern.
Diese Forderungen und Rahmenbedingungen waren die Basis für die Idee, das V-Modell 97
grundlegend zu überarbeiten. Sie sollen im Rahmen des Projektes WEIT (Weiterentwicklung des
Entwicklungsstandards für IT Systeme des Bundes auf Basis des V-Modell-97) realisiert werden.
Die Forderungen an ein künftiges Vorgehensmodell sind also kurz zusammengefasst:
Erweiterung des Anwendungsbereiches und Ausweitung zum allgemeinen Systementwicklungsstandard,
bessere Unterstützung der Anpassbarkeit, Anwendbarkeit, Skalierbarkeit sowie Änder- und
Erweiterbarkeit des V-Modells,
Anpassung an den neuesten Stand der Technologie (Aktualisierung, sowie technologische,
methodische Weiterentwicklung),
Anpassung an aktuelle (Quasi-)Standards, Vorschriften und Normen, beispielsweise die ISO
15288 oder das CMMI®
Daraus wurden im Rahmen der Phase 1 des Projektes WEIT die Anforderungen abgeleitet
[WEIT03].
2.1.2 Ziele und Zielgruppen
Genau wie das V-Modell 97 ist auch das V-Modell XT ein Leitfaden zum Planen und Durchführen
von Projekten. Neben den vorher erwähnten Anforderungen werden natürlich auch weiterhin
die drei Projektziele Einhaltung der Kosten und der Zeit sowie Gewährleistung der Qualität verfolgt.
Dabei werden die folgenden Ziele verfolgt [VMxt04]:
2.1.2.1 Minimierung der Projektrisiken
Durch die Vorgabe von standardisierten Vorgehensweisen sowie die Beschreibung der zugehörigen
Ergebnisse und der verantwortlichen Rollen erhöht das V-Modell XT die Projekttransparenz,
verbessert die Planbarkeit von Projekten und erleichtert die Projektdurchführung. Planungsab-
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 12 von 129

ÜBERBLICK
weichungen und Risiken werden bereits frühzeitig erkannt. Prozesse lassen sich besser steuern
und damit das Projektrisiko eindämmen.
2.1.2.2 Verbesserung und Gewährleistung der Qualität
Ein standardisiertes Vorgehensmodell stellt sicher, dass die zu liefernden Ergebnisse vollständig
und von der gewünschten Qualität sind. Definierte Zwischenergebnisse können frühzeitig geprüft
werden. Einheitliche Produktinhalte machen die Ergebnisse besser lesbar, verständlicher
und leichter überprüfbar.
2.1.2.3 Eindämmung der Gesamtkosten über den Systemlebenszyklus
Durch das standardisierte Vorgehensmodell lassen sich der Aufwand für die Entwicklung, Herstellung,
Betrieb, Pflege und Wartung eines Systems auf transparente Weise kalkulieren, abschätzen
und steuern. Die erzeugten Ergebnisse sind einheitlich und besser nachvollziehbar. Dies
verringert die Abhängigkeit des Auftraggebers vom Auftragnehmer und führt zu vermindertem
Aufwand in anschließenden Aktivitäten und Projekten.
2.1.2.4 Verbesserung der Kommunikation zwischen allen Beteiligten
Die standardisierte und einheitliche Beschreibung aller relevanten Bestandteile und Begrifflichkeiten
des Vorgehensmodells, wie die Kooperation zwischen Auftraggeber und Auftragnehmer,
ist die Basis des wechselseitigen Verständnisses aller Projektbeteiligten. So werden Reibungsverluste
zwischen Nutzer, Auftraggeber, Auftragnehmer und Entwickler reduziert.
2.1.2.5 Zielgruppen
Das V-Modell XT wendet sich an alle Beteiligten von Entwicklungsprojekten, sowohl auf der
Auftraggeber- als auch auf der Auftragnehmerseite und beinhaltet folglich ein Vorgehen für beide
Seiten. Als Vorgehensmodell zur Führung von Projekten richtet es sich dabei besonders an alle
Projektleiter und Führungskräfte, die Vorhaben beabsichtigen, durchführen und begleiten. Das
V-Modell XT unterstützt die Abwicklung von Projekten in Unternehmen und Einrichtungen des
öffentlichen und militärischen Bereichs, beispielsweise bei den Behörden und Dienststellen des
Bundes und der Bundeswehr.
Im Folgenden werden kurz die wesentlichen Konzepte und Begriffe des V-Modells XT vorgestellt.
Dabei werden die entsprechenden Inhalte aus dem V-Modell XT auszugsweise wiedergegeben,
da sie nur dem Verständnis der folgenden Gegenüberstellung zum CMMI® dienen sollen.
Weitere Details sind in [VM-XT04] zu finden.
2.1.3 Struktur des V-Modells XT
Ein Überblick über die Struktur des V-Modells XT ist in Abbildung 1 dargestellt.
Das V-Modell XT soll für möglichst alle in der Praxis vorkommenden Projektarten anwendbar
sein. Abhängig von ihren charakteristischen Eigenschaften lassen sich diese in Projekttypen einteilen.
Für die verschiedenen Projekttypen werden Projektdurchführungsstrategien definiert, in
denen der Projektablauf festgelegt ist. Für jeden Projekttyp ist außerdem definiert, welche Vorgehensbausteine
verwendet werden müssen und welche zusätzlich ausgewählt werden können.
Ein Vorgehensbaustein deckt eine konkrete Aufgabenstellung ab, die im Rahmen eines
V-Modell-Projektes auftreten kann. Festgelegt werden dabei die innerhalb dieser Aufgabenstellung
zu erarbeitenden Produkte, die Aktivitäten, durch welche die einzelnen Produkte erstellt
werden, sowie die an den einzelnen Produkten mitwirkenden Rollen. Die einzelnen Vorgehensbausteine
sind jeweils in sich abgeschlossen. Abhängigkeiten und Querbeziehungen zwischen
den Vorgehensbausteinen sind explizit definiert.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 13 von 129

Abbildung 1: Struktur und sichtenbasierte Darstellung des V-Modells XT
ÜBERBLICK
Eine Projektdurchführungsstrategie beinhaltet eine Folge von Entscheidungspunkten, welche jeweils
Projektfortschrittsstufen mit dem aktuell evaluierten Stand im Projektablauf darstellen.
Abhängig von dem Ergebnis dieser Evaluation entscheiden die Projektverantwortlichen über den
weiteren Projektverlauf und legen gegebenenfalls korrigierende Maßnahmen fest.
Um ein Mindestmaß an Projektdurchführungsqualität zu gewährleisten müssen einige Vorgehensbausteine
und Entscheidungspunkte in jedem Projekt angewendet werden. Diese verbindlich
anzuwendenden Vorgehensbausteine und Entscheidungspunkte bilden den V-Modell-Kern.
Neben den bisher beschriebenen Elementen gibt es so genannte Konventionsabbildungen. Diese
setzen die Begriffe eines (Quasi-)Standards, einer Norm oder einer Vorschrift mit den Inhalten
des V-Modells XT in Beziehung. Beispiele für Konventionsabbildungen sind die CMMI®-
Abbildung und die ISO 15288-Abbildung auf das V-Modell XT.
Spezifische Sichten einzelner Anwendergruppen werden durch die Gliederung der Dokumentation
in V-Modell-Referenzen realisiert. So beschreibt beispielsweise die V-Modell-Referenz Tailoring
speziell die Erstellung eines projektspezifischen V-Modells.
In den folgenden Kapiteln werden die gerade angesprochenen einzelnen Elemente des
V-Modells XT nochmals genauer textlich und bildlich beschrieben.
2.1.4 Vorgehensbausteine (VB)
Die wesentlichen Inhalte des V-Modells XT sind in den modularen, aufeinander aufbauenden
Vorgehensbausteinen enthalten. Jeder Vorgehensbaustein ist eine eigenständige Einheit und einzeln
änder- bzw. erweiterbar. Ein Vorgehensbaustein realisiert eine konkrete Aufgabe, die im
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 14 von 129

ÜBERBLICK
Rahmen eines V-Modell-Projektes auftreten kann, wie beispielsweise das Projektmanagement
oder die Softwareentwicklung. Wie Abbildung 2 schematisch zeigt, kapselt dabei ein Vorgehensbaustein
diejenigen Produkte, Aktivitäten und Rollen, die für die Erfüllung dieser Aufgabenstellung
relevant sind und damit inhaltlich zusammengehören.
Abbildung 2: Vorgehensbausteine und ihre Bestandteile
Thema Vorgehensbaustein
Projekt
Entwicklung
Organisation
Produktgruppe Aktivitätsgruppe
#
Angebotserstellung und Vertragserfüllung(AN)
Auftragsvergabe, Projektbegleitung und Abnahme(AG)
Konfigurationsmanagement
Problem- und Änderungsmanagement
Projektmanagement
Qualitätssicherung
Anforderungsfestlegung
Benutzbarkeit und Ergonomie
Evaluierung von Fertigprodukten
HW-Entwicklung
Logistische Unterstützung
SW-Entwicklung
Systemerstellung
Systemsicherheit
Weiterentwicklung und Migration von Altsystemen
Einführung und Pflege eines organisationsspezifischen
Vorgehensmodells
Kaufmännisches Projektmanagement
Messung und Analyse
"
Tabelle 1: Übersicht über die Vorgehensbausteine
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 15 von 129
!
#

ÜBERBLICK
Vorgehensbausteine sind das zentrale Grundkonzept im V-Modell XT. Sie können inhaltlich nach
den drei Themen Projekt(management), Entwicklung und Organisation eingeteilt werden
(Tabelle 1). Sie stellen in etwa die einzelnen Prozessmodule dar, welche im Rahmen eines Entwicklungsprojektes
ablaufen. Im Gegensatz zu den Submodellen des V-Modells 97 enthalten sie
die oben dargestellten Aktivitäten und Produkte nicht in einer logischen Reihenfolge. Diese wird
wie vorher erwähnt erst durch die Projekttypen, die Projektdurchführungsstrategie, die Entscheidungspunkte
und die Auswahl der Produkte im Vorgehensbaustein festgelegt.
Das Tailoring, d.h. die projektspezifische Anpassung des V-Modells, wird daher im V-Modell XT
auf der Basis der Vorgehensbausteine durchgeführt. Ein Vorgehensbaustein kann unter Umständen
nur in Verbindung mit anderen Vorgehensbausteinen verwendet werden. Diese Abhängigkeiten
zwischen Vorgehensbausteinen werden in der Vorgehensbausteinlandkarte festgehalten, wie
in Abbildung 3 skizziert.
Abbildung 3: Landkarte der Vorgehensbausteine
In jedem V-Modell XT konformen Projekt muss eine gewisse Menge von Vorgehensbausteinen
verwendet werden, die im V-Modell-Kern festgelegt sind (siehe Abbildung 3). Der V-Modell-
Kern garantiert ein Mindestmaß an Projektdurchführungsqualität.
2.1.5 Produkt, Produktgruppe, Thema
Innerhalb der Vorgehensbausteine sind die Produkte eines der zentralen Elemente. Als Produkte
werden im V-Modell XT die zu erarbeitenden Ergebnisse und Zwischenergebnisse bezeichnet.
Dies können beispielsweise die Systemelemente (System, Segment, HW-Einheit, SW-Einheit)
oder auch Dokumente sein. Das Endergebnis eines V-Modell XT-Projektes ist das Gesamtsystem
bestehend aus dem eigentlichen technischen System und allen Unterstützungssystemen inklusive
der logistischen Unterstützung. Der Begriff „Produkt“ hat damit im V-Modell XT eine ganz spe-
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 16 von 129

ÜBERBLICK
zielle Bedeutung, welche von der landläufigen Definition eines Produktes im Sinne eines Wirtschaftsgutes
abweicht. Da das CMMI® den Produktbegriff im landläufigen Sinn verwendet,
wird dieser im Folgenden mit System übersetzt, um Verwechslungen zu vermeiden.
Inhaltlich eng zusammengehörende Produkte werden zu Produktgruppen zusammengefasst. Sie
bilden die oberste Ebene des Produktmodells. Produktgruppen gliedern die Produkte nach inhaltlichen
Aspekten und sind hilfreich, einen Überblick über die Produkte des V-Modells XT zu gewinnen.
Die Produktgruppen können in die drei Bereiche Projekt(management), Entwicklung
und Organisation eingeteilt werden (Abbildung 4). Darüber hinaus kann ein komplexes Produkt
gegliedert sein in mehrere Themen. Durch diese Mechanismen wird die Gesamtheit aller Produkte
hierarchisch strukturiert. Ein Produkt kann explizit als initiales Produkt oder als externes Produkt
ausgewiesen werden.
. ! !,
.
1 2 34
. !
2 " !,
. *
+ ! . !,
, ! * " ! 5
!
5 * , !
, ! * " ! "
" * , !
, ! * " ! 0 "
0 " * , !
, ! * " ! 2 6
, !* " 2 6
2 6 * , !
, ! * " ! ( !
( ! * , !
& !,
/
0 * !,
/ !
+ ! .
.
. !,
1 2 30
+ !,
. )
( ! !
Abbildung 4: Beispiel für Produktgruppen zur Kategorie Projekt
) $ & '
" " ) $ & '
" $% & '
Als initial werden diejenigen Produkte bezeichnet, die in jedem V-Modell-Projekt immer und
genau einmal erstellt werden müssen, beispielsweise das Projekthandbuch oder der Projektplan.
Produkte, die nicht im Rahmen des betrachteten V-Modell-Projektes erstellt, sondern als Eingabe
an das V-Modell-Projekt übergeben werden, werden als externe Produkte bezeichnet. Die Struktur
und die inhaltlichen Anforderungen an diese externen Produkte sind jedoch bereits im
V-Modell XT vorgegeben.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 17 von 129
" * !
) $ - '
" " ) $ - '
7
7
7
7 !,
!

ÜBERBLICK
2.1.6 Produktabhängigkeit
Die einzelnen Produkte können voneinander abhängig sein. Eine solche Produktabhängigkeit beschreibt
eine Konsistenzbedingung zwischen zwei oder mehreren Produkten. Dabei kann eine
Produktabhängigkeit sowohl innerhalb eines Vorgehensbausteins als auch zwischen Produkten
verschiedener Vorgehensbausteine bestehen. Man unterscheidet zwischen strukturellen und erzeugenden
Produktabhängigkeiten.
2.1.6.1 Strukturelle Produktabhängigkeit
Ein System kann aus beliebig vielen ineinander geschachtelten Segmenten bestehen. Segmente,
die nicht in weitere Segmente unterteilt sind, bestehen aus SW-Einheiten und HW-Einheiten
(siehe Abbildung 5). SW-Einheiten und HW-Einheiten unterteilen sich in SW-Komponenten
bzw. HW-Komponenten und diese wiederum in SW-Module bzw. HW-Module. Externe Einheiten
können auf jeder Ebene der Hierarchie vorkommen.
Die Strukturierung des Unterstützungssystems ist der des Systems gleich, während die logistische
Unterstützungsdokumentation nach den einzelnen Dokumentations-Produkten des Vorgehensbausteins
„Logistische Unterstützung“ gegliedert ist (Abbildung 5).
2 6
2 3
+ * 3
/
4 8 3
4 8 3+ *
4 8 3+ *
4 8 3/
2
2
2 6
2 8 3
2 8 3+ *
2 8 3+ *
2 8 3/
(
% , "
% , " 6
Abbildung 5: Strukturelle Produktabhängigkeit im V-Modell XT
2.1.6.2 Erzeugende Produktabhängigkeit
Eine erzeugende Produktabhängigkeit beschreibt, in welchen Produktexemplaren der so genannten
initialen Ausgangsprodukte die Bedingungen für die Erstellung von Produktexemplaren der
Zielprodukte festgelegt werden (Abbildung 6).
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 18 von 129
& "
"
"
4 8 3
4 8 3+ *
4 8 3+ *
4 8 3/
2
2
2 8 3
2 8 3+ *
2 8 3+ *
2 8 3/

. . * 1 2 34
. !
+ ! .
ÜBERBLICK
Abbildung 6: Erzeugende Produktabhängigkeiten der Managementprodukte im Überblick
Die erzeugenden Produktabhängigkeiten sind somit eine wesentliche Menge von Regeln, die bei
der Planung und Ausgestaltung eines V-Modell-Projektes entsprechende Hilfestellung bieten.
Beispielsweise werden die Projektmanagementprodukte gemäß den Vorgaben des Projekthandbuches
und des Projektplans erstellt (linke Auflistung in Abbildung 6). Die Qualitätssicherungsprodukte
sind entsprechend den Vorgaben des QS-Handbuches und des Projektplans zu erstellen.
2.1.7 Rollen
Die Zuordnung von Produkten zu Personen wird im V-Modell XT über Rollen vorgenommen.
Dabei beschreiben Rollen geforderte Kenntnisse und Fähigkeiten, die ein Rolleninhaber für die
Erfüllung der ihm zugeordneten Aufgaben und Befugnisse besitzen muss. Zu jeder Rolle gibt es
ein Fähigkeitsprofil, nach dem der geeignete Projektmitarbeiter ausgewählt werden kann. Falls
für die Besetzung der Rolle besondere Randbedingungen zu beachten sind, ist dies unter „Rollenbesetzung“
angegeben.
Durch dieses Vorgehen bleibt die Rollenbeschreibung im V-Modell XT organisationsneutral. Im
spezifischen Projekt werden die einzelnen Rollen dann mit konkreten Personen oder Organisationseinheiten
besetzt.
Jedem Produkt wird nur eine verantwortliche Rolle zugeordnet, es können jedoch mehrere Rollen
mitwirken.
Bei der Zuordnung der Rollen zu Produkten gilt immer:
.
. !
+ ! .
0 *
7
7
/
.
3 7
.
2 "
/
7
!
Alle Rollen für die erforderlichen Produkte im Rahmen eines Projektes sind zu besetzen.
Eine Rolle ist manchmal durch mehrere Personen zu besetzen.
Eine Person kann mehrere Rollen in einem Projekt ausführen.
!
, ! * " ! "
, !* "
, ! * " ! 5
, !* 5
Über die als „mitwirkend“ dargestellten Rollen hinaus können weitere Know-How-Träger beratend
zugezogen werden. Alle im Laufe eines Produktlebens involvierten Fachdisziplinen sollen
so früh wie nötig eingebunden werden.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 19 von 129
&
1 2 30

ÜBERBLICK
2.1.8 Aktivität, Aktivitätsgruppe, Teilaktivität
Produkte werden im V-Modell XT jeweils von Aktivitäten bearbeitet und fertig gestellt. Es besteht
also ein direkter Zusammenhang zwischen Aktivitäten und Produkten. Die inhaltlich orientierte
Zusammenfassung der Produkte in die drei Bereiche Projekt(management), Entwicklung
und Organisation eingeteilt findet sich analog in der Gruppierung der Aktivitäten zu Aktivitätsgruppen
wieder. Das Gleiche gilt für die Produktgruppen und Aktivitätsgruppen innerhalb eines
Themas, wie beispielsweise hier innerhalb des Themas Projekt (vergleiche Abbildung 7 mit
Abbildung 4).
Abbildung 7: Beispiel für Aktivitätsgruppen zum Thema Projekt
Darüber hinaus lassen sich Aktivitäten gliedern in Teilaktivitäten. Eine Teilaktivität ist vergleichbar
mit einer Arbeitsanleitung, die geschlossen durchzuführen ist und dabei ein oder mehrere
Themen eines Produktes bearbeitet. Die Teilaktivitäten innerhalb einer Aktivität folgen logisch
aufeinander und werden im V-Modell XT in so genannten Ablaufdarstellungen präsentiert. Ein
Beispiel für eine Ablaufdarstellung ist die Strukturierung der Aktivität Projekt planen in ihre
Teilaktivitäten (Abbildung 8).
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 20 von 129

. !, *
. *
. *
, !* 5
, !*
3
"
*
, !* 2 6
. !, *
* *
3 *
* *
. * .
" * , ! *
ÜBERBLICK
Abbildung 8: Ablaufstruktur mit Strukturierung der Aktivität „Projekt planen“ in Teilaktivitäten
2.1.9 Projektdurchführungsstrategien
Die Vorgehensbausteine im V-Modell XT machen bewusst keinerlei Vorgaben und Einschränkungen
bezüglich einer möglichen Reihenfolge der Durchführung von Aktivitäten oder der Erstellung
von Produkten, wenn man von den gerade erwähnten Teilaktivitäten absieht. Die
geordnete und nachvollziehbare Durchführung eines Projektes wird im V-Modell XT über die so
genannten Projektdurchführungsstrategien gesteuert. Für jeden Projekttyp bietet das V-Modell
mindestens eine geeignete Projektdurchführungsstrategie an. Die für das Projekt geeignete Produktdurchführungsstrategie
lässt sich anhand des Projektmerkmals Systemlebenszyklusausschnitt
ermitteln. Abbildung 9 zeigt die derzeit verfügbaren Projektdurchführungsstrategien in
Abhängigkeit des Systemlebenszyklusausschnittes.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 21 von 129

9 . :
!
2 6 * .
!
5 !,
2 6 * .
2 6
+ *
2 6
! 8
8 !
2 6
Abbildung 9: Projektdurchführungsstrategien
ÜBERBLICK
2.1.10 Entscheidungspunkte
Jede Projektdurchführungsstrategie gibt eine Reihenfolge von im Projekt zu erreichenden Projektfortschrittsstufen
vor. Das Erreichen einer Projektfortschrittsstufe wird im V-Modell XT
durch einen Entscheidungspunkt markiert (Abbildung 7). Ein Entscheidungspunkt ist ein Meilenstein
im Projektablauf, an dem der aktuelle Stand des Projektes evaluiert wird. Für jeden Entscheidungspunkt
bildet eine gewisse Menge von Produkten, die am Ende der
Projektfortschrittsstufe fertig gestellt sein müssen, eine so genannte Baseline. Auf der Basis dieser
Produkte entscheidet das übergeordnete Management, ob die Projektfortschrittsstufe mit Erfolg
erreicht wurde und ob der nächste Projektabschnitt freigegeben wird.
. !, 3 ! ! 3 ;
*
2 6
2 6 * . ! * " !
Abbildung 10: Projektdurchführungsstrategie, Entscheidungspunkte und Produkte
In allen Projekttypen und damit auch in allen Projektdurchführungsstrategien werden die Entscheidungspunkte
Projekt genehmigt, Projekt definiert, Änderungsplan festgelegt und Projekt
abgeschlossen verwendet. Der Projekttyp Systementwicklungsprojekt eines Auftraggebers umfasst
beispielsweise noch zusätzlich die Entscheidungspunkte Anforderungen festgelegt, Projekt
ausgeschrieben, Projekt beauftragt und Abnahme erfolgt.
2.2 CMMI® (Capability Maturity Model Integration)
In den folgenden Unterkapiteln wird zunächst kurz die Motivation für die Entwicklung des
CMMI® (Kapitel 2.2.1) erläutert. Danach folgen der Aufbau des CMMI® mit seinen Prozessgebieten
sowie den dazugehörigen Zielen und Praktiken (Kapitel 2.2.2). Die für die Bewertung
nach CMMI® verwendeten unterschiedlichen Darstellungsformen „stufenförmige Darstellung“
und „kontinuierliche Darstellung“ sind in Kapitel 2.2.3 bzw. Kapitel 2.2.4 näher beschrieben.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 22 von 129
8
8
/
/
6
9 :
!, !
* " !
9 < =! >:

ÜBERBLICK
2.2.1 Motivation für die Entwicklung des CMMI®
Das Capability Maturity Model Integration® in Version 1.1 (im Folgenden kurz CMMI® genannt)
wurde vom Software Engineering Institut (SEI) der Carnegie Mellon Universität (CMU)
in Pittsburgh entworfen, um interdisziplinäre Entwicklungen, vor allem Software- und Systementwicklungsprojekte
schneller und günstiger abzuwickeln und dabei qualitativ hochwertigere
Produkte zu erhalten. Dabei wurden vorher getrennt vorhandene Modelle für Softwareentwicklung,
Systementwicklung, integrierte Produkt- und Prozessentwicklung und Lieferantenmanagement
in ein gemeinsames Modell integriert.
Der Vorgänger des CMMI® war das Capability Maturity Model (CMM®), welches auf Software-Entwicklung
konzentriert war. Dieses entstand 1991 im Auftrag des amerikanischen Verteidigungsministeriums,
welches damit die anfangs erwähnten Probleme hinsichtlich Kosten,
Terminen und Qualität bei der Vergabe komplexer Softwareentwicklung lösen wollte. In der Folge
stellte sich der große Nutzen heraus, welchen auch der Auftragnehmer von der Anwendung
des CMM für Prozessverbesserung hat. Dies führte dazu, dass viele Unternehmen das CMM anwendeten.
So entstanden aufgrund der gewonnenen Erfahrungen viele, auch über den Anwendungsbereich
hinausgehende Verbesserungsvorschläge. Dies veranlasste das amerikanische
Verteidigungsministerium, die Weiterentwicklung des CMM zu beauftragen, welche im Jahr
2002 mit der Veröffentlichung des CMMI® abgeschlossen wurde.
% of Organisations
100,00%
90,00%
80,00%
70,00%
60,00%
50,00%
40,00%
30,00%
20,00%
10,00%
0,00%
9,50%
29,70%
27,70%
5,40%
Initial Managed Defined Quantitatively
Managed
on most recent appraisal of 148 organizations reporting a maturity level rating
Source: Carnegie Mellon University, Software Engineering Institute March 2004
Abbildung 11: Reifegrad von Organisationen [SEI04]
27,70%
Optimizing
Auch dieses Modell wird, obwohl gerade erst herausgegeben, bereits in vielen Organisationen
zur Prozessbewertung angewendet (Abbildung 11).
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 23 von 129

ÜBERBLICK
2.2.2 Aufbau des CMMI®
In den folgenden Kapiteln wird der allgemeine Aufbau des CMMI® mit Prozessgebieten, Zielen
und Praktiken dargestellt.
2.2.2.1 Prozessgebiete
Das CMMI® mit den Disziplinen SE/SW besteht aus 22 verschiedenen Themen, den so genannten
Prozessgebieten. Diese fassen die vom CMMI® an eine Organisation gestellten Anforderungen,
beispielsweise die Anwendung von Risikomanagement, strukturiert zusammen. Die
Prozessgebiete sind abhängig von der Darstellung des CMMI® unterschiedlich angeordnet, nach
Reifegraden in der stufenförmigen Darstellung bzw. nach Kategorien in der kontinuierlichen
Darstellung. Untergliedert sind die Prozessgebiete in Ziele, die zur erfolgreichen Bewältigung
des Themas erreicht werden müssen. Zu jedem Ziel gehören meist mehrere Praktiken, die zur
Bewältigung des Ziels durchgeführt werden. Im Gegensatz zu den Zielen, welche vom CMMI®
gefordert werden, werden die Praktiken nur erwartet. Das bedeutet, dass eine Organisation ein
Ziel auch durch alternative Vorgehensweisen gegenüber den in den Praktiken beschriebenen erfüllen
kann. Sie kann jedoch nicht ein Prozessgebiet erfüllen, ohne alle Ziele des Prozessgebiets
erreicht zu haben.
2.2.2.2 Spezifische Ziele und spezifische Praktiken
Die spezifischen Ziele und spezifischen Praktiken eines Prozessgebiets gelten nur für das jeweilige
Prozessgebiet. Sie dienen der Strukturierung des Themas in Teilgebiete. Zur vollständigen
Erfüllung des Prozessgebiets müssen alle spezifischen Ziele erreicht werden. Sie bestehen aus
einem beschreibenden Text und spezifischen Praktiken, welche sich als Anleitung verstehen, wie
man das Ziel erreichen kann. Die Praktiken bestehen aus einem beschreibenden Text, einer Auflistung
typischer Arbeitsprodukte und meist mehreren Unterpraktiken. Die Unterpraktiken sind
wie Arbeitsanweisungen formuliert und oft mit Beispielen erläutert.
2.2.2.3 Generische Ziele und generische Praktiken
Die generischen Ziele und generischen Praktiken gelten für alle Prozessgebiete, da sie der Institutionalisierung
der Prozessgebiete dienen. Auch hier gilt wieder: für das Erfüllen des Prozessgebietes
ist das Erreichen aller generischen Ziele nötig. Dies kann wie auch bei Kapitel 2.2.2.2
entweder durch die Durchführung der Praktiken oder durch alternatives Vorgehen geschehen.
Aus der Historie der in Kapitel 2.2.1 erwähnten Ursprungsmodelle ergaben sich zwei strukturell
unterschiedliche Darstellungen, die stufenförmige und die kontinuierliche. Beide Darstellungen
beruhen auf denselben Prozessgebieten und spezifischen Zielen.
2.2.3 Stufenförmige Darstellung
In der Abbildung 12 ist die Struktur der stufenförmigen Darstellung zu erkennen.
Die 22 vorhandenen Prozessgebiete sind eindeutig einem der Reifegrade (Maturity Level) 2 bis 5
zugeordnet. Ein Reifegrad stellt die Qualität des Vorgehens einer Organisation dar. Es gibt die
fünf in Tabelle 2 dargestellten Reifegrade initial (1), managed (2), defined (3), quantitatively
managed (4), optimizing (5). Den Reifegrad 1 hat jede Organisation, da er keine Voraussetzungen
fordert, somit jedoch auch keine Leistung darstellt. Für das Erreichen eines höheren Reifegrades
ist es nötig, alle spezifischen Ziele der dem Reifegrad zugeordneten Prozessgebiete sowie
aller Prozessgebiete niedrigerer Reifegrade zu erfüllen. Außerdem ist das generische Ziel 2 „Institutionalize
a Managed Process“ für jedes Prozessgebiet zu erfüllen, falls man Reifegrad 2 oder
höher erlangen möchte. Für Reifegrad 3 oder höher ist es zusätzlich unerlässlich, das generische
Ziel 3, „Institutionalize a Defined Process“, für jedes Prozessgebiet zu erfüllen.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 24 von 129

Common Features
Maturity Levels
Process Area 1 Process Area 2 Process Area m
Specific Goals Generic Goals
Specific Practice 1 Specific Practice k
Generic Practice 1
Specific Practice 2
Commitment
to Perform
Ability
to Perform
Directing
Implementation
Abbildung 12: Struktur der stufenförmigen Darstellung
ÜBERBLICK
Verifying
Implementation
Generic Practice 3 Generic Practice 5 Generic Practice n
Generic Practice 2 Generic Practice 4 Generic Practice 6
In der folgenden Tabelle 2 sind die Reifegrade, deren kurze Beschreibung sowie die zugehörigen
Prozessgebiete in Deutsch und Englisch aufgelistet.
Ab Kapitel 2.3 wird nur die stufenförmige Variante berücksichtigt, da sie den Reifegrad einer
Organisation über alle Prozessgebiete hinweg ermittelt und somit mehr der Absicht des
V-Modells XT entspricht.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 25 von 129

Reifegrad
Fokus
english deutsch
5 Optimizing
4
Quantitatively
Managed
3 Defined
2 Managed
Kontinuierliche
Prozessverbesserung
Quantitatives
Management
Standardisierung
des
Prozesses
Grundlegendes
Projektmanagement
Prozessgebiete
Organizational Innovation and
Deployment
Tabelle 2: Reifegrade und Prozessgebiete des CMMI® v1.1 staged SE/SW
ÜBERBLICK
Organisationsweite Innovation und
Verbreitung
Causal Analysis and Resolution Ursachenanalyse und Problemlösung
Organizational Process
Performance
Performanz der organisationsweiten
Prozesse
Quantitative Project Management Quantitatives Projektmanagement
Requirements Development Anforderungsentwicklung
Technical Solution Technische Umsetzung
Product Integration Produktintegration
Verification Verifikation
Validation Validation
Organizational Process Focus Organisationsweiter Prozessfokus
Organizational Process Definition Organisationsweite Prozessdefinition
Organizational Training Organisationsweites Training
Integrated Project Management Integriertes Projektmanagement
Risk Management Risikomanagement
Decision Analysis and Resolution Entscheidungsanalyse und –findung
Requirements Management Anforderungsmanagement
Project Planing Projektplanung
Project Monitoring and Control Projektverfolgung und –steuerung
Supplier Agreement Management
Management von
Lieferantenvereinbarungen
Measurement and Analysis Messung und Analyse
Process and Product Quality
Assurance
Prozessgebiete nach Ralf Kneuper
[Kneu03]
Qualitätssicherung von Prozessen
und Produkten
Configuration Management Konfigurationsmanagement
1 Initial „chaotisch“ -- --
Da die Reifegrade die Fähigkeiten einer Organisation darstellen, ist es essentiell, die verschiedenen
Stufen zu verstehen und gegeneinander abgrenzen zu können. Deshalb folgt nun eine Beschreibung
der 5 Reifegrade.
2.2.3.1 Reifegradstufe 1 – Initial
Auf Reifegradstufe 1 sind die Prozesse meist nicht existent, „chaotisch“ oder entstehen aus dem
Stehgreif. Das bedeutet, dass es zwar Prozesse geben kann, diese werden aber weder projektspezifisch
noch unternehmensweit eingesetzt. Der Erfolg des Unternehmens hängt also von der
Kompetenz und dem „Heldentum“ der einzelnen Personen ab. Organisationen mit Reifegradstufe
1 überschreiten deshalb häufig die Kosten und die Zeit. Erfolge durch gute Produkte sind
möglich, hängen jedoch von der individuellen Leistung einiger weniger Personen ab und können
oft nicht wiederholt werden.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 26 von 129

ÜBERBLICK
2.2.3.2 Reifegradstufe 2 – Managed
In Organisationen mit Reifegradstufe 2 ist es Aufgabe der Projekte, dass Anforderungen verwaltet
und die Prozesse geplant, gesteuert, verwaltet und überprüft werden. Die bei Reifegradstufe 2
betrachteten Prozessgebiete gewährleisten, dass vorhandene Verfahren auch in Zeiten großer Belastung
angewendet werden. Zu bestimmten Zeitpunkten können die Fortschritte vom Management
nachvollzogen werden. Die Arbeitsergebnisse werden überprüft und überwacht und sie
erfüllen die geforderten Anforderungen, Normen und Ziele. Zwar sind die grundsätzlichen Projektmanagement-Praktiken
in allen Projekten vorhanden, allerdings laufen die Prozesse unterschiedlich
ab. Dies bedeutet, dass die Projekte normalerweise nicht voneinander lernen können,
so dass die gleichen Fehler immer wieder gemacht werden.
2.2.3.3 Reifegradstufe 3 – Defined
Ein Unternehmen mit Reifegradstufe 3 hat einen organisationsweit festgelegten Standardprozess,
der ständig weiterentwickelt und von den Projekten durch Tailoring angepasst wird. Dieser enthält
Vorgehensweisen für Entwicklung, Integration, Prüfung, Risikomanagement und andere
Prozessgebiete. Neben der Prozessbeschreibung werden z.B. Werkzeuge, Erfahrungen und Metriken
aus einer organisationsweiten Sammlung von den einzelnen Projekten genutzt. Damit die
Mitarbeiter des Unternehmens die Prozesse anwenden können, wird der Standardprozess organisationsweit
eingeführt und durch Weiterbildungsmaßnahmen vermittelt. Während der Nutzung
ist es wichtig, dass Verbesserungspotential der Prozesse in den Projekten erkannt und durch entsprechende
Maßnahmen eingearbeitet wird.
2.2.3.4 Reifegradstufe 4 – Quantitatively Managed
Eine Organisation mit Reifegrad 4 muss den Bereich Messung und Analyse, vor allem die organisationsweite
Metrikdatenbank stark ausbauen. Es sind Informationen zu sammeln, die nicht nur
qualitativ sondern auch statistisch und quantitativ ausgewertet werden können. Dazu wird die
Leistung wichtiger Teilprozesse gemessen, die signifikant zur Performanz der Prozesse beitragen.
Dabei erkennt man Fehler, deren Ursache außerplanmäßige Variationen der Prozesse sind.
Auf Grundlage der gewonnen Erkenntnisse werden die Prozesse verbessert. In den Projekten
werden sowohl die Prozesse als auch die Ziele von denen der Organisation abgeleitet und unter
statistische/quantitative Kontrolle gestellt.
2.2.3.5 Reifegradstufe 5 – Optimizing
Organisationen mit Reifegradstufe 5 verbessern ihre Prozessperformanz kontinuierlich. Ausgehend
von den Zielen der Organisation und Geschäftswerten liefern die Prozesse voraussagbare
Ergebnisse, sodass das Unternehmen sehr schnell auf Chancen und Veränderungen reagieren
kann. Ein anderer Aspekt der Reifegradstufe 5 ist die kontinuierliche Fehleranalyse. Hierbei erkennt
man Fehler, deren Ursache regelmäßige Variationen der Prozesse sind. Aufgrund der Ergebnisse
gilt es, die Fehlerursachen zu erkennen und zu beheben.
2.2.4 Kontinuierliche Darstellung
Die oben genannten Prozessgebiete sind in der kontinuierlichen Darstellung in folgende vier Kategorien
aufgeteilt:
• Prozessmanagement: behandelt organisationsweite Prozesse
• Projektmanagement: thematisiert das Management im Projekt
• Ingenieurdisziplinen: behandeln klassische Entwicklungsthemen und Prüfung
• Unterstützung: erfasst alle Themen, die übergreifend benötigt werden
In der folgenden Tabelle 3 ist die Zuordnung der Prozessgebiete zu den Kategorien dargestellt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 27 von 129

Kategorie Process Area Prozessgebiet
Prozessmanagement
Projektmanagement
Ingenieurdisziplinen
Unterstützung
ÜBERBLICK
Tabelle 3: Prozessgebiete des CMMI® v1.1 continuous SE/SW nach Kategorien sortiert
Jedes der 22 Prozessgebiete wird einzeln bewertet und erhält einen der sechs Fähigkeitsgrade aus
Tabelle 4. Die Fähigkeitsgrade ähneln den Reifegraden der stufenförmigen Darstellung, da sie
Aussagen über die Qualität der Prozesse eines Prozessgebiets treffen.
Voraussetzungen für das Erreichen
0 unvollständig kein Voraussetzungen
1 durchgeführt Spezifische Ziele erreicht
2 gemanagt Gemanagter Prozess institutionalisiert
3 definiert Definierter Prozess institutionalisiert
4
Organizational Process Focus Organisationsweiter Prozessfokus
Organizational Process Definition Organisationsweite Prozessdefinition
Organizational Training Organisationsweites Training
Organizational Process Performance
Organizational Innovation and
Deployment
Project Planing Projektplanung
Fähigkeitsgrad
quantitativ
gemanagt
Quantitativ gemanagter Prozess
institutionalisiert
Performanz der organisationsweiten
Prozesse
Organisationsweite Innovation und
Verbreitung
Project Monitoring and Control Projektverfolgung und –steuerung
Supplier Agreement Management
Management von
Lieferantenvereinbarungen
Integrated Project Management Integriertes Projektmanagement
Risk Management Risikomanagement
Quantitative Project Management Quantitatives Projektmanagement
Requirements Management Anforderungsmanagement
Requirements Development Anforderungsentwicklung
Technical Solution Technische Umsetzung
Product Integration Produktintegration
Verification Verifikation
Validation Validation
Configuration Management Konfigurationsmanagement
Process and Product Quality Assurance
Qualitätssicherung von Prozessen und
Produkten
Measurement and Analysis Messung und Analyse
Decision Analysis and Resolution Entscheidungsanalyse und –findung
Causal Analysis and Resolution Ursachenanalyse und Problemlösung
5 optimierend Optimierender Prozess institutionalisiert
Tabelle 4: Die sechs verschiedenen Fähigkeitsgrade (Capability Level)
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 28 von 129

ÜBERBLICK
Wie man aus der Tabelle 4 sieht, sind für Fähigkeitsgrad 0 keine Vorraussetzungen nötig. Für das
Erreichen von Fähigkeitsgrad 1 oder höher in einem Prozessgebiet, muss das generische Ziel des
Fähigkeitsgrades und aller niedrigeren Fähigkeitsgrade erfüllt sein. Dann sind immer die spezifischen
Ziele des Prozessgebiets erfüllt. Die Ziele sind wiederum in Praktiken unterteilt, welche
zum Erreichen des jeweiligen Ziels anzuwenden sind.
In der stufenförmigen Darstellung unterscheidet man nun in der Kategorie Ingenieurdisziplinen
zwischen einer großen Zahl an Basispraktiken, die für Fähigkeitsgrad 1 anzuwenden sind, und
einer geringen Zahl an fortgeschrittenen Praktiken, welche einem höheren Fähigkeitsgrad zugeordnet
sind.
2.2.5 Bewertung der Darstellungen
In der kontinuierlichen Darstellung ist eine wesentlich feinere Beschreibung der Fähigkeit eines
Projekts oder einer Organisation möglich, da es mehr Fähigkeitsgrade gibt als Reifegrade in der
stufenförmigen Darstellung vorhanden sind. Außerdem wird für jedes Prozessgebiet ein eigener
Fähigkeitsgrad vergeben. Dadurch ist es leichter, Verbesserungspotential zu erkennen und Maßnahmen
zu ergreifen.
Andererseits will das Management oft eine Beurteilung der gesamten Organisation haben bzw.
Teilorganisationen miteinander vergleichen können. Dazu ist die stufenförmige Darstellung besser
geeignet, weil sie die Beurteilung einer gesamten Organisation hinsichtlich ihrer Reife ermöglicht.
Außerdem ist hier der Weg für Verbesserungen klarer vorgezeichnet.
2.3 Gemeinsamkeiten von V-Modell XT und CMMI®
Sowohl CMMI® als auch das V-Modell XT haben das Ziel, die interdisziplinäre Entwicklung
von Systemen, bestehend aus Software, Hardware und extern erstellten Einheiten zu vereinheitlichen
und somit zu erleichtern. Durch die Einführung unternehmensweit einheitlicher Vorgehensweisen
werden die Entwicklungsergebnisse verbessert.
2.4 Unterschiede zwischen V-Modell XT und CMMI®
Das Prozessmodell CMMI® umfasst eine Menge von Anforderungen an die Prozesse einer Organisation,
welche dazu dienen, diese zu beurteilen und aufgrund der Ergebnisse Verbesserungsvorschläge
zu machen. Das V-Modell XT hingegen ist ein im Projekt anzuwendender Prozess.
CMMI® beschreibt im Wesentlichen, was zu tun ist und welche Ergebnisse erwartet werden.
Das V-Modell XT geht darüber hinaus und beschreibt sogar, wie etwas zu tun ist bzw. wie die
Ergebnisse aussehen sollen. Es bietet beispielsweise fertige Vorlagen für Dokumente oder enthält
Vorschläge für einzusetzende Methoden und Werkzeuge, überlässt jedoch dem Anwender die
Wahl der Methode. Dem gegenüber stellt das Prozessmodell CMMI® abstrahierte Best Practices
zur Verfügung und schreibt an manchen Stellen die Methode vor, beispielsweise die Peer Reviews.
Dadurch dass hinter dem V-Modell XT ein komplexes Modell mit Abhängigkeiten zwischen
den Elementen steht, sind einige Anforderungen des CMMI® im V-Modell XT nicht direkt
durch individuelle Produkte oder Aktivitäten abgedeckt sondern durch vielfach anwendbare Produkte/Aktivitäten,
Automatismen des Modells oder allgemeine Regelungen, die meist in den einführenden
Kapiteln beschrieben sind. Beispiele hierfür sind:
• Die Einbeziehung der Stakeholder (Stakeholder Involvement und Commitment) wird im Wesentlichen
durch das Rollenmodell abgedeckt. Zu einigen Punkten (z.B. Projektplan) wird zusätzlich
noch explizit das Einverständnis aller Stakeholder eingeholt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 29 von 129

ÜBERBLICK
• die Prüfung zum Beispiel von KM-Aktivitäten erfolgt im Rahmen der generischen Aktivität
„Prozess prüfen“
• der Methodenpool ist bei der Einführung des V-Modells XT in der operativen Umgebung von
der Prozessgruppe auszuarbeiten
• durch ein Produktzustandsmodell wird gewährleistet, dass nach Umsetzung von Änderungen
alle direkt von der Änderung betroffenen Produkte und zusätzlich alle von diesen Produkten
abhängige Produkte erneut einer Prüfung unterzogen werden.
Ein weiterer entscheidender Unterschied ist, dass das V-Modell XT zwischen Auftraggeber- und
Auftragnehmerprojekten unterscheidet.
Auf die Unterschiede hinsichtlich des Begriffes „Produkt“ wurde schon in Kapitel 2.1.5 hingewiesen.
Der Produktbegriff im Sinne des CMMI® wird im Folgenden auch weiterhin mit System
übersetzt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 30 von 129

3 Das V-Modell XT aus Sicht des CMMI®
Dieses Kapitel ordnet die spezifischen Praktiken der Prozessgebiete von Level 2 und 3 auf die
Elemente des V-Modells XT zu. Größtenteils wird versucht, auf Produkte oder deren Themen
bzw. auf Aktivitäten und Teilaktivitäten abzubilden, aber an einigen Stellen ist es nötig auf ganze
Vorgehensbausteine, Methodenreferenzen, Kapitel oder Rollen zu verweisen.
Der Aufbau des CMMI® mit Prozessgebieten, Zielen und Praktiken spiegelt sich in den Kapiteln
dieses Abschnitts wie folgt wieder:
• Prozessgebiete werden durch die Kapitelüberschriften (2. Ebene) gebildet
(beispielsweise Kapitel 3.1 Requirements Management),
• die Ziele sind in den Unterkapiteln der 3. Ebene dargestellt
(beispielsweise Kapitel 3.1.1 Manage Requirements),
• die Praktiken finden sich dann auf der 4. Ebene der Unterkapitel
(beispielsweise Kapitel 3.1.1.1 Obtain an Understanding of Requirements).
Die Prozessgebiete enthalten jeweils eine zusammenfassende Beschreibung, um welche Themen
es dabei im CMMI® geht und wie das V-Modell XT diese generell behandelt.
Die eigentliche Bewertung wird anhand der Praktiken im Detail durchgeführt. Im Text zu den
Praktiken erläutert der erste Absatz jeweils, wie die Anforderungen des CMMI® zu verstehen
sind. Der zweite Absatz beschreibt, wie das V-Modell XT diese Anforderung erfüllt. Falls das
V-Modell XT ein Thema nicht voll erfüllt, wird dies im dritten Absatz jeweils explizit angegeben.
Die Erfüllungsgrade der Praktiken werden nach den in Tabelle 5 definierten vier Kriterien bewertet
und orientieren sich am SCAMPI® (Standard CMMI Appraisal Method for Process Improvement),
das im Kapitel 4.1.1 genauer erläutert wird.
SCAMPI-Erfüllungsgrade
Implementation Level Grad der Erfüllung
Interpretation
fully implemented voll erfüllt keine wesentlichen Schwächen
largely implemented größtenteils erfüllt richtiges Konzept, aber deutliche Schwächen
partially implemented teilweise erfüllt ungenügendes Konzept, aber erkennbarer Ansatz
not implemented nicht erfüllt keine der obigen Voraussetzungen
Tabelle 5: Erfüllungsgrade und Interpretation
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 31 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Die Bewertung der Praktiken, Ziele und Prozessgebiete ist in Tabelle 19 im Anhang A.1 zusammengefasst
dargestellt. In den Konventionssichten (siehe Anhang A.3) wurde der Inhalt dieses
Kapitels in verdichteter Form in das neue V-Modell XT eingearbeitet.
3.1 Requirements Management (Maturity Level 2)
Das Prozessgebiet Requirements Management beschäftigt sich mit dem Management aller Anforderungen
an Systeme und Teilsysteme (dies sind Produkte und Teilprodukte im Sinne des
CMMI®). Dabei sollen auch Inkonsistenzen zwischen Anforderungen, Plänen und Ergebnissen
aller Art erkannt werden. Besonders am Anfang des Projektes ist es wichtig, dass alle Beteiligten
ein gemeinsames Verständnis der Anforderungen entwickeln und sich verbindlich auf diese festlegen.
Im weiteren Verlauf des Projekts müssen Änderungen verwaltet und die bidirektionale
Verfolgbarkeit der Anforderungen über alle Ebenen sichergestellt werden. Dadurch wird es auch
möglich, Abweichungen zwischen Plänen, Arbeitsergebnissen und Anforderungen zu erkennen
und entsprechende Gegenmaßnahmen einzuleiten.
Da das V-Modell XT im Gegensatz zum CMMI® eine strikte Trennung zwischen Auftraggeber-
und Auftragnehmerprojekten vornimmt, verteilen sich die Aktivitäten auf zwei Projekte. Für die
Anforderungen (Lastenheft), die Vertragsbestandteil sind, ist im V-Modell XT der Auftraggeber
zuständig. Der Auftragnehmer leitet daraus die technische Sicht ab, ergänzt diese eventuell durch
weitere Anforderungen der eigenen Organisation und dokumentiert diese Anforderungen in der
Gesamtsystemspezifikation (Pflichtenheft).
3.1.1 Manage Requirements
Beim Management der Anforderungen geht es in erster Linie um das einvernehmliche Verständnis
und die Verfolgung der Anforderungen sowie deren Änderungen. Dabei ist vor allem die Verfolgbarkeit
in beide Richtungen wichtig.
3.1.1.1 Obtain an Understanding of Requirements
Der Auftraggeber muss zur Erstellung der Ausschreibung seine Anforderungen (Lastenheft) erarbeiten,
der Auftragnehmer muss für die Abgabe eines Angebotes die Anforderungen des Auftraggebers
verstehen. Im Vertrag legen sich Auftraggeber und Auftragnehmer auf gemeinsame
Anforderungen fest. Es ist die Aufgabe des Auftragnehmers die Anforderungen soweit zu verfeinern,
dass er daraus ein System entwerfen kann. Dies ist ein iterativer Prozess, der als Ergebnis
die Spezifikationsprodukte der Produktgruppe Systemspezifikation hat.
Das explizite Verständnis der Anforderungen, so wie im CMMI® gefordert, wird zwar nicht explizit
im V-Modell XT angesprochen, aber durch die Mechanismen der Vorgehensbausteine Angebotserstellung
und Vertragserfüllung (AN) sowie Auftragsvergabe, Projektbegleitung und
Abnahme(AG) sowie das Rollenmodell sollten immer alle relevanten Beteiligten einbezogen und
das Verständnis vorhanden sein.
3.1.1.2 Obtain Commitment to Requirements
Ist das gemeinsame Verständnis für die Anforderungen erreicht, so folgt im nächsten Schritt die
einvernehmliche Vereinbarung dieser Anforderungen zwischen den Beteiligten.
Im V-Modell XT wird die Verbindlichkeit der Anforderungen zwischen Auftragnehmer (AN) und
Auftraggeber (AG) im Vertrag festgehalten. Die Beteiligten des AN hingegen haben die Gesamtsystemspezifikation
erarbeitet und sich auf diese festgelegt. Dies ist als Zustimmung zu sehen.
Bei der Verfeinerung der Gesamtsystemspezifikation entstehen beim Auftragnehmer in mehreren
Iterationsschritten die verschiedenen Spezifikationen. Da durch das Rollenkonzept alle relevan-
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 32 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
ten Beteiligten beim Erarbeiten der Spezifikationen mitwirken, ist auch ihre Zustimmung gegeben.
3.1.1.3 Manage Requirements Changes
In der Folge kann Änderungsbedarf an den Anforderungen entstehen. Die notwendigen Änderungen
sind zwischen Auftraggeber und Auftragnehmer einvernehmlich zu regeln.
Da Änderungen der Anforderungen normalerweise dem Problem- und Änderungsmanagement
unterliegen, sorgt dieser Vorgehensbaustein dafür, dass die Änderungen in alle abhängigen Produkte
übernommen werden. Dies führt zum Beispiel zum V-Modell XT Produkt Vertragszusatz
oder zu Änderungen der Anforderungen (Lastenheft) und Änderungen der Gesamtsystemspezifikation
(Pflichtenheft). Wenn sich innerhalb des Auftragnehmerprojekts Anforderungen ändern,
müssen die Spezifikationen und die davon abhängigen Produkte überarbeitet werden.
3.1.1.4 Maintain Bidirectional Traceability of Requirements
Als zentrale Forderung des CMMI® ist die bidirektionale Verfolgbarkeit der Anforderungen zu
sehen. Diese bedeutet, dass Anforderungen beispielsweise sowohl vom Lastenheft auf einzelne
Systemelemente verfolgbar sein müssen als auch umgekehrt.
Die Verfolgbarkeit der Anforderungen durch die verschiedenen Ebenen ist im V-Modell XT in
der Anforderungsverfolgung abgebildet, die als Thema in allen Spezifikationen der Produktgruppe
Systemspezifikationen enthalten ist. Jedoch ist nur ein uni-direktionales Tracing der Anforderungen
realisiert. Somit ist es zwar möglich von einer übergeordneten zu allen davon
abgeleiteten verfeinerten Anforderungen zu gelangen, nicht aber von der speziellen Anforderung
zur allgemeinen.
Durch die fehlende bidirektionale Verfolgbarkeit ist diese Praktik nur teilweise erfüllt.
3.1.1.5 Identify Inconsistencies between Project Work and Requirements
Aufgrund des Tracing sollen Inkonsistenzen zwischen den Arbeitsergebnissen und den Anforderungen
identifizierbar sein.
Widersprüchlichkeiten zwischen Anforderungen und Arbeitsergebnissen werden im
V-Modell XT durch reguläre Prüfungen erkannt und zusammen mit Lösungsvorschlägen in Prüfprotokollen
niedergeschrieben. Ändert sich aufgrund der erfassten Probleme der Zustand eines
Produkts, ändert sich durch das Produktzustandsmodell auch automatisch der Zustand von allen
abhängigen Produkten. Im Thema Prüfplan des Projektplans werden die zu prüfenden Elemente
und die Zeitpunkte der Prüfungen aufgeführt.
3.2 Project Planning (Maturity Level 2)
Die Aufgabe der Projektplanung ist es, Schätzungen und Pläne zu erstellen, die Pläne zu aktualisieren
und die Zustimmung zu den Plänen von allen Beteiligten zu erreichen. Unter der Zuhilfenahme
der erarbeiteten Anforderungen werden Aufwand, Umfang und Kosten abgeschätzt sowie
die Einteilung des Projektablaufes in geeignete Phasen gewählt. Der Projektplan enthält in der
Regel neben Budget und Risiken auch Pläne für Zeit, Ressourcen, Schulungen, Datenverwaltung
und Mitwirkung der Beteiligten. Bevor man von allen Beteiligten die Zustimmung zum Plan
einholt, muss der Plan von allen Beteiligten überprüft und die Ressourcen abgestimmt werden.
Der Projektplan bildet die Grundlage für die Durchführung und Steuerung eines Projektes.
Die Projektplanung ist im V-Modell XT hauptsächlich im Vorgehensbaustein Projektmanagement
angesiedelt, außer einigen Aspekten, die im Kaufmännischen Projektmanagement zu finden
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 33 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
sind. Die Ermittlung der Schätzung erfolgt in der integrierten Planung, in den Entscheidungspunkten,
der Umfangsschätzung und der Aufwandsschätzung. Dabei hilft der Projektdurchführungsplan
bei der Auswahl der richtigen Projektphasen. Die Projektplanung hat als Ergebnis
neben der Kaufmännischen Projektkalkulation, der Risikoliste und Teilen der Projektmanagementinfrastruktur
hauptsächlich den Projektplan und das Projekthandbuch. Die Verpflichtung zur
Einhaltung der Pläne regelt man in den Teilaktivitäten „Projektplan mit allen Beteiligten abstimmen“
und „Projekthandbuch mit allen Beteiligten abstimmen“.
3.2.1 Establish Estimates
Im Rahmen der Projektplanung sollen auf der Basis des Projektstrukturplans Umfang, Aufwand,
Ablauf und Kosten der Arbeitspakete abgeschätzt werden.
3.2.1.1 Estimate the Scope of the Project
In dieser Forderung des CMMI® geht es um die Abschätzung der grundsätzlichen Projektparameter,
die sich in einem Projektstrukturplan niederschlagen.
Der Projektstrukturplan wird beim V-Modell XT im Thema Integrierte Planung des Projektplans
aufgezeichnet. Von wem die einzelnen ermittelten Arbeitspakete umgesetzt werden, ob durch einen
Unterauftragnehmer, die Wiederverwendung eines bestehenden Produktes oder durch Eigenentwicklung,
entscheidet sich bei der Durchführung einer Make-Or-Buy-Entscheidung. Die
einzelnen Arbeitspakete werden dann als Arbeitsauftrag vergeben.
3.2.1.2 Establish Estimates of Work Product and Task Attributes
Auf der Basis des Projektstrukturplanes sollen Umfang und Arbeitsaufwand für die Arbeitspakete
abgeschätzt werden.
In dem Produkt Schätzung des V-Modells XT sind alle für die Projektplanung nötigen Schätzungen
zusammengefasst. Es sind sowohl Umfänge als auch Aufwendungen enthalten.
3.2.1.3 Define Project Life Cycle
Nach Planung des Aufwandes sind grobe Aussagen über Reihenfolge und Dauer der Arbeiten
möglich, so dass hier nach Projektphasen gefragt wird, welche sich an logischen Entscheidungspunkten
orientieren.
Im V-Modell XT werden durch die Auswahl der passenden Projektdurchführungsstrategien beim
Erstellen des Projekthandbuchs die Entscheidungspunkte des Projektes und damit die Phaseneinteilung
festgelegt. Die verschiedenen Projektdurchführungsstrategien bieten ausreichend Informationen
über den Ablauf des Projektes.
3.2.1.4 Determine Estimates of Effort and Cost
Abgeleitet aus den vorher ermittelten Werten sind in dieser Praktik Aufwand und Kosten abzuschätzen.
Die Aufwendungen werden durch die Schätzung ermittelt, die Kosten durch die Kaufmännische
Projektkalkulation abgeleitet. Dabei werden alle Kosten von der Entwicklung bis zur Fertigung
betrachtet, unter anderem auch die Kosten für Logistik, Unterstützungssystem und Risiken.
3.2.2 Develop a Project Plan
Dieses Ziel enthält die Entwicklung des Projektplanes ausgehend vom Projektbudget über die
das Projektbudget, die Zeitplanung, die Risken die Planung der Ressourcen und der Einbindung
der Beteiligten bis zur Etablierung der Projektplanung.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 34 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.2.2.1 Establish the Budget and Schedule
Basierend auf den Schätzungen müssen jetzt das Projektbudget und der Zeitplan festgelegt werden.
Da die Kosten für das Projekt in der Kaufmännischen Projektkalkulation des V-Modells XT ermittelt
wurden, ist ein Budget für die verschiedenen Arbeitspakete festgelegt. Im Thema Integrierte
Planung des Projektplans werden alle Pläne zusammengefasst, d.h. neben Terminplan unter
anderem auch Ressourcenplan, Produktstrukturplan und Projektstrukturplan. In letzterem werden
Entscheidungspunkte festgelegt, an denen der Projektfortschritt beurteilt und daraufhin über die
Zukunft des Projektes entschieden wird. Jedem Entscheidungspunkt sind zu erfüllende Arbeitspakete
zugeordnet, die wiederum in durchzuführende Aktivitäten unterteilt sind.
3.2.2.2 Identify Project Risks
Diese Forderung des CMMI® verlangt, Risiken zu identifizieren und zu analysieren.
Die Identifizierung und Analyse der Risiken des Projekts wird im V-Modell XT im Produkt Risikoliste
und in der Teilaktivität „Risiken und Maßnahmen identifizieren“ dokumentiert.
3.2.2.3 Plan for Data Management
Diese Anforderung richtet sich an die Planung aller im Projekt zu verwaltenden Daten.
Projektweite Festlegungen sind im V-Modell XT im Projekthandbuch niedergeschrieben. Dazu
gehören die hier geforderten Festlegungen, welche Projektdaten erfasst und weitergegeben werden
sollen. Auch die Projektmanagementinfrastruktur und die Richtlinien für Datenschutz und
Datensicherheit werden dort festgelegt. Alle Daten, die dem Konfigurationsmanagement unterstehen,
müssen entsprechend der Vorgaben des Konfigurationsmanagements behandelt werden.
3.2.2.4 Plan for Project Resources
Entsprechend dieser Praktik sind im Projekt die Personal- und Material-Ressourcen zu planen.
Im Thema des V-Modells XT Organisation und Vorgaben zum Projektmanagement werden die
Projektbeteiligten und Verantwortlichkeiten festgelegt. Die Ressourcenplanung von Personal und
Material befindet sich in der Integrierten Planung des Projektplans.
3.2.2.5 Plan for Needed Knowledge and Skills
Ziel der Praktik ist es, die für die erfolgreiche Bewältigung des Projekts nötigen Kenntnisse und
Fähigkeiten zu identifizieren und Pläne zu erstellen, wie die Projektbeteiligten diese erlangen.
In der Erfahrungsdatenbasis des V-Modells XT wird aufgezeichnet, wer welche Schulungen erfolgreich
absolviert hat. Dieses Wissen wird bei der Erstellung des Ausbildungsplans genutzt, in
dem alle Maßnahmen zur Qualifizierung der Projektmitarbeiter geplant werden.
3.2.2.6 Plan Stakeholder Involvement
Diese Praktik soll sicherstellen, dass die Einbeziehung aller Beteiligter geplant wird.
Alle im Projekthandbuch identifizierten Beteiligten werden im V-Modell XT durch das Rollenmodell
erfasst. Jedem Produkt ist genau eine verantwortliche und eine oder mehrere mitwirkende
Rollen zugewiesen. Da alle Mitwirkenden im Projekthandbuch erfasst werden und alle Produkte
im Projektplan geplant werden, wird somit auch die Einbeziehung der Beteiligten geplant. Zusätzlich
gibt es im Projekthandbuch noch das Thema „Mitwirkungen und Beistellungen des Auftraggebers“,
in dem explizit nochmals die Einbeziehung des Auftraggebers in das
Auftragnehmerprojekt festgelegt ist.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 35 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.2.2.7 Establish the Project Plan
Als Ergebnis der oben genannten Praktiken wird die Etablierung dieser Projektplanung gefordert.
Im Projekthandbuch des V-Modells XT sind die grundsätzlichen Vorgaben für die Organisation,
Planung und Durchführung des Projektes beschrieben. Im Projektplan werden die in regelmäßigen
Abständen zu aktualisierenden Themen wie beispielsweise Termine oder Arbeitsfortschritt
behandelt. Er wird im V-Modell XT durch die Aktivität „Projekt planen“ initiiert und dient der
Steuerung des Projektes.
3.2.3 Obtain Commitment to the Plan
Um wirksam zu sein, erfordern Pläne das Einverständnis der Beteiligten. Deshalb sollten sie von
ihnen geprüft und mit ihnen abgestimmt werden.
3.2.3.1 Review Plans that Affect the Project
Die gesamte Projektplanung besteht aus vielen Einzelplänen, deren Prüfung diese Praktik fordert.
Da im Projektplan des V-Modells XT die verschiedenen geforderten Pläne in einem integrierten
Plan zusammengefasst und somit aufeinander abgestimmt sind, ist ein Review für die Abstimmung
der verschiedenen Pläne nicht nötig. Durch das Produktzustandsmodell ist außerdem automatisch
festgelegt, dass der Projektplan geändert werden muss, falls im Verlauf des Projekts
eine gravierende Planabweichung auftritt.
3.2.3.2 Reconcile Work and Resource Levels
In dieser Praktik geht es um den Ausgleich von Differenzen zwischen der Schätzung und den zur
Verfügung stehenden Ressourcen.
Dieser Aspekt wird im V-Modell XT durch die Teilaktivität „Schätzergebnisse konsolidieren“ erfüllt.
3.2.3.3 Obtain Plan Commitment
Diese Praktik verlangt, die Zustimmung aller internen und externen Beteiligten am Projekt sicher
zu stellen.
In der Teilaktivität „Projektplan mit allen Projektbeteiligten abstimmen“ wird das geforderte Ziel
erfüllt, die Zustimmung zu dem Plan von allen Betroffenen einzuholen und zu dokumentieren.
Da durch das Rollenkonzept alle Betroffenen schon bei der Erstellung der Pläne einbezogen
wurden, ist auch ein automatischer Mechanismus vorhanden, sodass kein Betroffener übersehen
werden kann.
3.3 Project Monitoring and Control (Maturity Level 2)
Das Prozessgebiet Project Monitoring and Control überwacht die Durchführung des Projektes
nach den Vorgaben der Planung, identifiziert Abweichungen und leitet bei Abweichungen vom
Plan korrigierende Maßnahmen ein. Dabei werden neben Parametern der Projektplanung, den
Risiken und dem Datenmanagement auch die Einbindung und Verpflichtung der Beteiligten überwacht.
Besonders wichtig ist die regelmäßige Überprüfung des Projektfortschrittes und der
Projektergebnisse unter anderem durch die Festlegung von Meilensteinen. Steuernde und korrigierende
Maßnahmen sind wenn nötig einzuleiten und zu verwalten.
Das Prozessgebiet Projektverfolgung und -steuerung ist im V-Modell XT durch die Vorgehensbausteine
Projektmanagement, kaufmännisches Projektmanagement, Konfigurationsmanagement
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 36 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
und Problem- und Änderungsmanagement erfüllt. Die Produkte „Projektstatusbericht“ und
„Kaufmännischer Projektstatusbericht“ dienen im V-Modell XT der Projektkontrolle und Projektsteuerung.
In ihnen sind unter anderem die Themen Projektergebnis, Qualitätsbewertung,
Planungsabweichung, „aktuelle Risiken und Risikomaßnahmen“, „Planung für den nächsten Berichtszeitraum“,
„Abweichung der Projektkosten“, „Abweichung der Herstellkosten“ und „Ergebnisabweichung“
erfasst. Die Steuerung der Projektrisiken wird durch die Aktivität „Risiken
und Maßnahmen überwachen“ wahrgenommen. Außer diesen Produkten ist noch die Projektfortschrittsentscheidung
für die Steuerung entscheidend. Die Umsetzung erfolgt über den Projektplan.
Mit Hilfe des Vorgehensbausteins Problem- und Änderungsmanagement werden alle
wichtigen Probleme erfasst und abgearbeitet.
3.3.1 Monitor Project Against Plan
In diesem Ziel ist die Überwachung von Terminen, Kosten, Aufwendungen, Ressourcen und Ergebnissen
gefordert.
3.3.1.1 Monitor Project Planning Parameters
Diese Praktik betrifft die Überwachung des Projektfortschritts, d.h. letztlich der in der Projektplanung
geplanten Parameter (siehe Kapitel 3.2.2).
In den Aktivitäten „Projektstatusbericht erstellen“ und „kaufmännischen Projektstatusbericht
erstellen“ werden die Soll/Ist-Vergleiche hinsichtlich Terminen, Kosten, Aufwendungen, Ressourcen
und Ergebnissen durchgeführt. Ebenso werden alle Abweichungen und Risiken aufgezeichnet
und Korrekturmaßnahmen eingeleitet. Allein die Kontrolle von Kenntnissen und
Fähigkeiten der am Projekt Beteiligten fehlt im V-Modell XT.
Somit ist diese Praktik größtenteils erfüllt.
3.3.1.2 Monitor Commitments
Bei diesem Thema geht es um die Überwachung der in Kapitel 3.2.3 eingegangenen Verpflichtungen.
Die Kontrolle der Verpflichtungen ist im V-Modell XT nicht explizit umgesetzt. Implizit erfolgt
sie durch das Rollenkonzept und die Projektstatusberichte.
Daraus ergibt sich eine teilweise Erfüllung der Praktik.
3.3.1.3 Monitor Project Risks
Die in der Planung festgestellten Risiken sind in regelmäßigen Abständen zu überwachen.
Die Projektrisiken werden durch die Aktivität „Risiken und Maßnahmen überwachen“ und die
beiden Projektstatusberichte sehr gut kontrolliert und kommuniziert.
3.3.1.4 Monitor Data Management
Das CMMI® verlangt hier die Überwachung aller im Projekt entstehenden Informationen und
Daten inklusive ihrer Archivierung.
Im V-Modell XT wird durch das Projekthandbuch festgelegt, welche Produkte und Teilprodukte
dem Konfigurationsmanagement unterstehen. Es gibt jedoch auch Informationen wie beispielsweise
Schriftwechsel, welche nicht dem Konfigurationsmanagement unterstehen. Diese werden
im V-Modell XT nicht explizit kontrolliert.
Daher ist diese Praktik größtenteils erfüllt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 37 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.3.1.5 Monitor Stakeholder Involvement
Gemeint ist in diesem Punkt die Überwachung, dass alle Beteiligten einbezogen werden.
Die Kontrolle der Einbeziehung aller Betroffenen erfolgt im V-Modell XT bei der Erstellung des
Projektstatusberichts. Dabei werden auch Probleme erkannt und analysiert.
3.3.1.6 Conduct Progress Reviews
Zur Information der relevanten Beteiligten soll der Projektfortschritt im Rahmen von Reviews
überwacht werden.
Bei der Überprüfung von Projektfortschritt, Projektperformanz und offenen Punkten, werden im
Projektstatusbericht Abweichungen und Probleme aufgezeichnet. Wichtige Probleme und deren
Lösung werden über das Problem- und Änderungsmanagement abgewickelt.
3.3.1.7 Conduct Milestone Reviews
Zu den Meilensteinen wird ein Review des Projektstatus im geeigneten Personenkreis verlangt.
Im V-Modell XT werden im Projektplan Entscheidungspunkte festgelegt, an denen Projektfortschrittsentscheidungen
durchgeführt werden. In jedem Entscheidungspunkt wird über das Erreichen
der anstehenden Projektfortschrittsstufe entschieden und das Ergebnis in der
Projektfortschrittsentscheidung dokumentiert. Durch Einbeziehung der Rolle Lenkungsausschuss
wird die Beteiligung der relevanten Entscheidungsträger gesichert.
3.3.2 Manage Corrective Action to Closure
Falls der Projektfortschritt nicht der Planung entspricht, sind entsprechende Korrekturmaßnahmen
einzuleiten.
3.3.2.1 Analyze Issues
Die Praktik verlangt die Sammlung und Analyse der Planungsabweichungen.
Im Thema Planungsabweichung des Projektstatusberichts werden Abweichungen erfasst und
ausgewertet. Sie bilden die Grundlage für projektsteuernde Maßnahmen im Thema „Planung für
den nächsten Berichtszeitraum“.
3.3.2.2 Take Corrective Action
Hier geht es darum, bei Problemen Korrekturmaßnahmen festzulegen und mit den Beteiligten
abzustimmen.
Da der Projektleiter als Verantwortlicher für das Thema „Planung für den nächsten Berichtszeitraum“
die Kompetenz hat, tief greifende Änderungen am Projektplan einzuleiten, ist es ihm
möglich, korrigierende Maßnahmen zu planen und die Zustimmung aller Betroffenen einzuholen.
Die Änderungen der Verpflichtungen der einzelnen Beteiligten und die Einholung von deren
Zustimmung zu den Maßnahmen werden im V-Modell XT nicht explizit gefordert.
Deshalb ist diese Praktik größtenteils erfüllt.
3.3.2.3 Manage Corrective Action
Ziel dieser Praktik ist die Kontrolle der korrigierenden Maßnahmen und die Analyse ihrer Ergebnisse.
Da durch die korrigierenden Maßnahmen im V-Modell XT eine geänderte Planung für den
nächsten Berichtszeitraum aufgestellt wird, welche bei der nächsten Erstellung eines Projektsta-
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 38 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
tusberichts überprüft wird, sind die vom CMMI® gewünschten Informationen vorhanden. Sie
werden nur nicht zwingend nach den geforderten Gesichtspunkten ausgewertet.
Diese Praktik ist also größtenteils erfüllt.
3.4 Supplier Agreement Management (Maturity Level 2)
Das Management von Lieferantenvereinbarungen beschäftigt sich mit der Auswahl und Einbindung
von Systemen, die von extern beschafft werden. Dabei kann es sich um Fertigprodukte,
komplette Entwicklungen durch Unterauftragnehmer oder um Mischformen handeln. In diesem
Prozessgebiet geht es nicht nur um die fundierte Auswahl des richtigen Systems und Lieferanten,
sondern auch um die Planung der Einbindung in das Gesamtsystem und stetige Zusammenarbeit
mit den Lieferanten. Dies endet in der Abnahme und in der Übernahme des Systems in das eigene
Projekt.
Das Management der Lieferantenvereinbarungen ist im V-Modell XT über die Vorgehensbausteine
„Systemerstellung“, „Auftragsvergabe, Projektbegleitung und Abnahme (AG)“, „Evaluierung
von Fertigprodukten“ und „Projektmanagement“ verteilt. Beim Festlegen der
Lieferantenvereinbarungen entscheidet man sich mit Hilfe der Make-or-Buy-Entscheidung für
eine Art der Beschaffung. Anschließend wählt man den Anbieter aufgrund des Angebots, des
Kriterienkatalogs und der Angebotsbewertung. Mit dem Vertrag endet die Auswahl eines Anbieters.
Der zweite Teil dieses Prozessgebietes behandelt die Erfüllung der Lieferantenvereinbarungen.
Die Überprüfung der COTS-Produkte geschieht in der Marktsichtung für Fertigprodukte
und in der Make-or-Buy-Entscheidung. Die kontinuierliche Überprüfung der Lieferantenvereinbarungen
läuft im normalen Rahmen des Projektmanagements ergänzt von Vertragszusätzen. Der
Auftraggeber akzeptiert das gekaufte Produkt durch die Abnahmeerklärung, die er aufgrund positiver
Prüfprotokolle und den dazugehörigen erfüllten Prüfspezifikationen unterzeichnen kann.
Die Einbindung des Produktes in das eigene Projekt wird im V-Modell XT in „Externe Einheit
übernehmen“ ausgeführt.
3.4.1 Establish Supplier Agreements
Dieses Ziel beschreibt, wie man einvernehmliche Vereinbarungen mit den Lieferanten erreicht
und wird in den folgenden Kapiteln detailliert.
3.4.1.1 Determine Acquisition Type
Diese Praktik fordert, dass für alle Systemelemente festgelegt wird, ob sie als Fertigprodukte zugekauft,
als Unterauftrag vergeben oder selbst entwickelt werden sollen.
Diese Aufgabe erfüllt im V-Modell XT die Make-or-Buy-Entscheidung vollständig.
3.4.1.2 Select Suppliers
Um den richtigen Lieferanten zu finden, sind Auswahl-Kriterien festzulegen, die möglichen Auftragnehmer
zu identifizieren, Risiken für eine Zusammenarbeit mit vorgeschlagenen Lieferanten
abzuschätzen und sowohl die Angebote als auch die Fähigkeiten der Lieferanten zu bewerten.
Wenn im V-Modell XT eine Ausschreibung erstellt wird, aufgrund derer mögliche Auftragnehmer
ihre Angebote abgeben können, stellt man einen Kriterienkatalog für die Angebotsbewertung
auf. Mit Hilfe der darin enthaltenen Kriterien ist eine objektive Bewertung der
eingegangenen Angebote durch die Angebotsbewertung möglich und es kann der beste Lieferant
gewählt werden. In den Themen Projekterfahrung und Erfahrungen mit dem Auftragnehmer wird
im Projekttagebuch explizit eine Aufzeichnung von Informationen über die Lieferanten gefordert.
Diese werden dann dem Einkäufer zur Pflege der Auftragnehmerdatenbasis zur Verfügung
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 39 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
gestellt und/oder in die Erfahrungsdatenbasis eingefügt. Da der Einkäufer beim Kriterienkatalog
und der Angebotsbewertung mitwirkt, stehen die nötigen Informationen über die potentiellen
Auftragnehmer zur Verfügung. Eine Risikoanalyse bezüglich der Zusammenarbeit mit den verschiedenen
Auftragnehmern wird im V-Modell XT jedoch nicht explizit durchgeführt.
Daher ist diese Praktik größtenteils erfüllt.
3.4.1.3 Establish Supplier Agreements
Nach der Auswahl des besten Lieferanten wird zwischen Auftragnehmer und Auftraggeber ein
Vertrag geschlossen. Darin müssen die Anforderungen an das Produkt, die Aufgaben des Auftraggebers
und die Verpflichtungen beider Vertragspartner enthalten sein. Außerdem ist es nach
der Auftragsvergabe nötig, die Pläne des Projektes anzupassen.
Im V-Modell XT stehen alle relevanten Informationen im Vertrag. Das Thema „Mitwirkungen
und Beistellungen des Auftraggebers“ im Projekthandbuch des Auftragnehmerprojekts erhält automatisch
vom Auftraggeberprojekt die Inhalte. Durch die Mitwirkung des Projektkaufmanns am
Vertrag ist sichergestellt, dass auch rechtliche Aspekte beim Vertragsabschluss beachtet werden.
Da im V-Modell XT eine strikte Trennung zwischen Auftraggeberprojekt und Auftragnehmerprojekt
existiert, wird der Projektplan des Auftragnehmers erst hinterher erstellt, der Projektplan des
Auftraggebers wird entsprechend des Vertrags angepasst.
3.4.2 Satisfy Supplier Agreements
In dieser Anforderung geht es darum, dass die Vereinbarungen mit den Lieferanten einvernehmlich
geregelt werden. Dies wird in den folgenden Unterkapiteln im Detail beschrieben.
3.4.2.1 Review COTS Products
Wenn Fertigprodukte im Projekt eingesetzt werden sollen, sieht das CMMI® vor, das beste Fertigprodukt
durch folgende Schritte auszuwählen: Entwicklung von Kriterien für die Auswahl,
Beurteilung der verschiedenen Fertigprodukte, Beurteilung der Auswirkungen auf das Projekt,
Beurteilung der Lieferanten, Identifikation der Risiken, Auswahl des Fertigprodukts und Instandhaltung
des Fertigprodukts.
Im V-Modell XT werden diese Informationen in der Make-or-Buy-Entscheidung und der Marktsichtung
für Fertigprodukte gesammelt. Auch hier fehlt die explizite Analyse der Risiken für das
Projekt.
Diese Praktik ist also größtenteils erfüllt.
3.4.2.2 Execute the Supplier Agreement
Diese Praktik dient dazu, dass der Auftraggeber über den Verlauf des Auftragnehmerprojekts auf
dem Laufenden gehalten wird, wenn nötig korrigierende Maßnahmen ergreifen und die durch
das Auftragnehmerprojekt entstehenden Risiken abschätzen kann.
Diese Aufgabe erfüllen im V-Modell XT die Projektstatusberichte, welche sowohl intern als auch
extern genutzt werden und somit dem Auftraggeber als Informationsquelle dienen. Falls Änderungen
im Vertrag nötig werden, kann dies mit Vertragszusätzen geschehen.
3.4.2.3 Accept the Acquired Product
Bei dieser Praktik geht es darum, die Einhaltung aller Vertragsbedingungen sicherzustellen, bevor
das Produkt vom Auftragnehmer übernommen wird.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 40 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Vor der Abnahmeerklärung wird daher im V-Modell XT vom Auftraggeber anhand der Prüfspezifikation
Lieferung die Lieferung des Auftragnehmers geprüft und die Ergebnisse im Prüfprotokoll
Lieferung festgehalten.
3.4.2.4 Transition Products
Ziel dieser Praktik ist die geplante Überführung des beschafften Produktes in das eigene Projekt.
Dazu gehört die Bereitstellung von Lagermöglichkeiten, Mitarbeiterschulung für das neue Produkt
und Einhaltung der Vertragsbedingungen.
Da im V-Modell XT ein beschafftes Produkt als Externe Einheit im Projekt von Anfang an eingeplant
ist, wird genauso vorgegangen als hätte man diese Einheit selbst produziert. Die nötige
Dokumentation und Schulung der Mitarbeiter des Auftraggebers erfolgt jedoch durch die Logistische
Unterstützung, welche Teil des Auftragnehmerprojekts ist.
3.5 Measurement and Analysis (Maturity Level 2)
Das Prozessgebiet Messung und Analyse dient der Sammlung und Aufbereitung von numerisch
messbaren Projektinformationen, die das Management bzw. die Verantwortlichen für die Prozessgebiete
zum Treffen von Entscheidungen benötigen. Hierbei müssen nach Auswahl der
Messziele die passenden Metriken definiert werden. Für die Sammlung, Speicherung und Analyse
der zu den Metriken gehörigen Messdaten sind geeignete Verfahren zu entwickeln. Im Projekt
werden diese Verfahren angewendet und die Messergebnisse in anschaulicher Form dargestellt.
Das Prozessgebiet Measurement and Analysis ist vollständig im Vorgehensbaustein Messung und
Analyse enthalten. Die Vorbereitung (Align Measurement and Analysis Activities) ist durch das
„Projekthandbuch“ abgedeckt und zwar durch das Thema „Organisation und Vorgaben zu Messung
und Analyse“. Die Durchführung wird durch die Aktivität „Messdaten erfassen“, die Auswertung
und Weiterverarbeitung durch die Aktivität „Metrik berechnen und auswerten“ erfüllt
und die entstehenden Produkte sind „Messdaten“ und „Metrikauswertung“.
3.5.1 Align Measurement and Analysis Activities
Die spezifischen Praktiken unter diesem Ziel befassen sich zunächst mit dem Zweck der Messung
und gehen dann auf deren Spezifikation ein.
3.5.1.1 Establish Measurement Objectives
Die Praktik umfasst die Ermittlung und Pflege der Messziele. Wichtig sind dabei die Priorisierung,
Anpassung und Verfolgbarkeit der Messziele.
Im V-Modell XT werden die Metriken im Thema „Organisation und Vorgaben zu Messung und
Analyse“ des Projekthandbuchs den Projektzielen zugeordnet. Die Metriken sind im organisationsweiten
Metrikkatalog nach Messzielen geordnet und können somit passend ausgesucht werden.
Wegen der fehlenden Priorisierung des Informationsbedarfs ist die Praktik im V-Modell XT
größtenteils erfüllt.
3.5.1.2 Specify Measures
Hierbei geht es um die Festlegung der im Projekt zu nutzenden Metriken. Dabei ist es wichtig
die passenden Metriken aus dem organisationsweiten Metrikkatalog auszuwählen und wenn nötig
an die Gegebenheiten des Projektes anzupassen. Falls passende Metriken fehlen, sind diese zu
erstellen.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 41 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Dokumentiert wird die Festlegung der Metriken im V-Modell XT im Thema „Organisation und
Vorgaben zu Messung und Analyse“.
3.5.1.3 Specify Data Collection and Storage Procedures
Das CMMI® verlangt an dieser Stelle die Definition von Methoden zur Sammlung und Speicherung
der Messdaten.
Da im V-Modell XT dem Projekt ein organisationsweiter Metrikkatalog zur Verfügung steht, in
dem die Vorgehensweisen für Sammlung und Archivierung der Messdaten schon festgelegt sind,
müssen vom Projekt nur Methoden für fehlende oder angepasste Metriken erstellt werden. Dies
geschieht angelehnt an die im Metrikkatalog schon vorhandenen Methoden. Dokumentiert werden
die Methoden im Thema „Organisation und Vorgaben zu Messung und Analyse“. Die Tools
zur Erfassung und Auswertung der Messdaten werden durch die Projektmanagementinfrastruktur
zur Verfügung gestellt.
3.5.1.4 Specify Analysis Procedures
In dieser Praktik wird festgelegt, wie die gesammelten Messdaten analysiert und kommuniziert
werden sollen.
Dabei werden im V-Modell XT die Erfahrungsdatenbasis und der Metrikkatalog zur Hilfe genommen.
Es wird genau festgelegt, welche Metrikauswertung in welchem Bericht kommuniziert
wird. Dokumentiert wird die Festlegung der Vorgehensweisen im Thema „Organisation und Vorgaben
zu Messung und Analyse“.
3.5.2 Provide Measurement Results
In diesem Ziel geht es um die eigentliche Durchführung der Sammlung, Analyse und Speicherung
von Messdaten und deren Präsentation an die Zielgruppen.
3.5.2.1 Collect Measurement Data
Hier werden die Messdaten erfasst.
Die Erfassung der Messdaten erfolgt im V-Modell XT in der Teilaktivität „Messdaten erfassen“
und wird im Produkt Messdaten dokumentiert.
3.5.2.2 Analyze Measurement Data
CMMI® fordert hier die Analyse der Messdaten, ihre Interpretation und das Review mit den Beteiligten.
Um die Messdaten den Zielgruppen vorstellen zu können werden sie in der Aktivität „Metrik berechnen
und auswerten“ analysiert und ausgewertet. Daraus entsteht die Metrikauswertung, welche
zum Beispiel zur Information des Managements genutzt wird.
Da der Review mit den Beteiligten nicht ausdrücklich gefordert wird, ist diese Praktik im
V-Modell XT größtenteils erfüllt.
3.5.2.3 Store Data and Results
Die Praktik verlangt die Speicherung der Daten und Ergebnisse. Dazu gehören insbesondere die
Spezifikationen und die eigentlichen Messdaten aber auch die Analyse- und Präsentationsergebnisse.
Da bei der Speicherung aller Informationen und Ergebnisse die Vorgaben aus dem Thema „Organisation
und Vorgaben zu Messung und Analyse“ und die Tools aus der Projektmanagementinfrastruktur
genutzt werden, ist eine korrekte und ausschließlich sachgemäße Nutzung der
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 42 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Informationen sichergestellt. Im V-Modell XT wird zudem ausdrücklich auf Datenschutz und
Datensicherheit hingewiesen. Die Speicherung der Messdaten erfolgt durch die Aktivität „Messdaten
erfassen“, die Aufzeichnung der Ergebnisse durch die Aktivität „Metrik berechnen und
auswerten“. Die Metrikauswertung stellt die Ergebnisse der Messdatenerfassung dar.
3.5.2.4 Communicate Results
Besonders wichtig ist schließlich das Kommunizieren der Metrikergebnisse an die Zielgruppen.
In der Aktivität „Metrik berechnen und auswerten“ wird ausdrücklich gefordert, die gewonnenen
Informationen den Zielgruppen vorzustellen und die zugehörigen Berichte zu kommunizieren.
Somit ist diese Praktik vollständig erfüllt.
3.6 Process and Product Quality Assurance (Maturity Level 2)
Das Prozessgebiet Qualitätssicherung von Prozessen und Produkten befasst sich mit der Überprüfung
von Prozessvorgaben und Arbeitsergebnissen, um den Mitarbeitern und dem Management
einen objektiven Einblick in Prozesse und zugehörige Arbeitsergebnisse zu geben. Prozesse
und Arbeitsergebnisse müssen dazu objektiv gegenüber den zugehörigen Prozessbeschreibungen,
Standards und Vorgehensweisen beurteilt werden. Dabei erkannte Abweichungen gegenüber den
Vorgaben werden dokumentiert, objektiv an die Beteiligten kommuniziert, berichtet und aufgelöst.
Die Qualitätssicherung von Prozessen und Produkten wird komplett vom Vorgehensbaustein
Qualitätssicherung abgedeckt. Die objektive Beurteilung von Prozessen und Zwischenergebnissen
geschieht im V-Modell XT in den verschiedenen Prüfspezifikationen und Prüfprotokollen ergänzt
von Nachweisakte, QS-Bericht und QS-Handbuch. Die Aufzeichnung und Kommunikation
der Ergebnisse erfolgt im QS-Bericht, die Fehlerverfolgung mittels des Vorgehensbausteins
Problem- und Änderungsmanagement.
3.6.1 Objectively Evaluate Processes and Work Products
In diesem Ziel werden die Einhaltung der beschriebenen Prozesse verfolgt und die dazugehörigen
Arbeitsergebnisse ausgewertet.
3.6.1.1 Objectively Evaluate Processes
Zunächst werden die realisierten Abläufe mit den geplanten Prozessen verglichen und bewertet.
Das V-Modell XT hat für die Beurteilung der Prozesse genaue Vorgehensweisen. Dazu werden
im QS-Handbuch die zu überwachenden Prozesse festgelegt und im Projektplan geplant. Es werden
Prüfspezifikationen für jeden Prozess erstellt, die dann beim Prüfen des Prozesses angewendet
werden. Die Ergebnisse werden im Prüfprotokoll Prozess aufgezeichnet. Im QS-Bericht
werden neben den Problemen auch mögliche Maßnahmen beschrieben.
3.6.1.2 Objectively Evaluate Work Products and Services
Als nächster Schritt werden die Arbeitsergebnisse bewertet.
Da im V-Modell XT die Prüfung eine generische Vorgehensweise ist, ähneln die Vorgehensweisen
denen der Beurteilung der Prozesse und sind ebenso konsequent durchgezogen. Im QS-
Handbuch sind die zu prüfenden Arbeitsprodukte aufgelistet, wobei nicht zwischen Dienstleistungen
und Entwicklungen unterschieden wird. Zu jedem zu prüfenden Produkt, ob Dokument,
Benutzbarkeit, Lieferung oder Systemelement, wird im V-Modell XT eine Prüfspezifikation erstellt,
die bei der Durchführung der Prüfung eingesetzt wird. Die Ergebnisse werden in Prüfpro-
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 43 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
tokollen aufgezeichnet. Falls es sich um vom Auftraggeber geforderte Nachweise handelt, werden
die gesamten Informationen der Prüfung auch noch in der Nachweisakte aufgezeichnet.
Auch hier werden wieder Probleme und Maßnahmen im QS-Bericht beschrieben.
3.6.2 Provide Objective Insight
Die Behandlung von Qualitätsproblemen ist in diesem Ziel verankert.
3.6.2.1 Communicate and Ensure Resolution of Noncompliance Issues
Qualitätsprobleme zu verfolgen, ihre Lösung sicher zu stellen und beides zu kommunizieren, ist
in dieser Praktik festgelegt.
Die Verfolgung von Qualitätsproblemen bis zur Lösung des Problems wird im V-Modell XT
nicht explizit beschrieben. Durch das Produktzustandsmodell ist jedoch ein automatischer Mechanismus
vorhanden, der alle schon fertigen abhängigen Produkte wieder in den Zustand „in
Bearbeitung“ setzt. Auch der Projektplan wird automatisch bei gravierenden Problemen geändert.
Kommuniziert werden die Probleme durch Nachweisakte, QS-Bericht, Projektabschlußbericht
und Projekttagebuch.
Diese Praktik ist größtenteils erfüllt.
3.6.2.2 Establish Records
Die Ergebnisse sollen aufgezeichnet werden.
Die nötigen Informationen werden in QS-Berichten aufgezeichnet und verwaltet. In ihnen werden
das Qualitätsgeschehen und die Ergebnisse der Maßnahmen dokumentiert.
3.7 Configuration Management (Maturity Level 2)
Ziel des Konfigurationsmanagements ist es, die Integrität von Arbeitsergebnissen zu erreichen
und aufrechtzuerhalten. Vorbereitend werden die Arbeitsergebnisse ausgewählt, die dem Konfigurationsmanagement
unterstehen sollen, sowie ein System für Konfigurations- und Änderungsmanagement
eingeführt. Es werden Konfigurationen geschaffen, auf denen weiter
aufgebaut und auf die jederzeit zurückgegriffen werden kann. Dies wird erreicht durch die Aufzeichnung
der Konfigurationen und deren Änderungen, durch Management der Änderungen sowie
durch regelmäßige Prüfungen. Prinzipiell werden Änderungen an jeglichen
Arbeitsergebnissen, die unter Konfigurationsmanagement stehen, verfolgt und regelmäßig überprüft.
Das Konfigurationsmanagement hat im CMMI® und V-Modell XT denselben Namen und auch
sehr ähnliche Inhalte. Zum Einrichten von Baselines gehört zuerst die Bestimmung der Elemente,
die unter Konfigurationsmanagement stehen sollen. Dies ist im Projekthandbuch im Thema
Organisation und Vorgaben zum Konfigurationsmanagement festgelegt. Der Aufbau des Konfigurationsmanagementsystems
erfolgt in Produktbibliothek und Änderungsstatusliste. Die Baselines
werden in „Integrierte Planung“ zentral verwaltet. Änderungsanträge werden mit Hilfe der
„Problemmeldung/Änderungsantrag“ gestellt und in der Änderungsstatusliste verwaltet. Die
Produkte werden in der Produktbibliothek verwaltet, archiviert und kontrolliert.
Die Verpflichtung des CMMI® zu Audits, welche die Aktivitäten des Konfigurationsmanagement
überprüfen, erscheint im V-Modell XT nicht.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 44 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.7.1 Establish Baselines
Baselines werden durch Produktkonfigurationen gebildet, welche zu definierten Meilensteinen
im Projekt geplant werden.
3.7.1.1 Identify Configuration Items
In dieser Praktik geht es um die Festlegung der Elemente, die unter Konfigurationsmanagement
stehen werden. Es gehört nicht nur dazu die Elemente auszuwählen, sondern auch ihnen eindeutige
Namen zuzuweisen, einen Verantwortlichen festzulegen, Charakteristika jedes Elements
aufzuzeichnen und den Beginn des Konfigurationsmanagements für jedes Element festzulegen.
Im V-Modell XT erfolgen die Festlegung einer Namenskonvention und die Auswahl der Produkte
im Thema „Organisation und Vorgaben zum Konfigurationsmanagement“ des Projekthandbuchs.
Da jeder Produktkonfiguration immer automatisch ein Verantwortlicher zugewiesen ist,
ist eine getrennte Festlegung nicht nötig. Der Beginn des Konfigurationsmanagements ist durch
den Beginn der von der Produktkonfiguration abhängigen Arbeitspakete festgelegt, d.h. sie werden
von Anfang an verwaltet.
3.7.1.2 Establish a Configuration Management System
Diese Praktik fordert die Einrichtung eines Konfigurationsmanagementsystems mit den dazugehörigen
Verfahren und Werkzeugen.
Das Konfigurationsmanagementsystem wird im V-Modell XT durch die Produktkonfigurationen
realisiert, welche in der Produktbibliothek verwaltet werden. In der dazugehörenden Aktivität
„Produktbibliothek verwalten“ sind alle Vorgehensweisen beschrieben, die für die Verwaltung
der Produktkonfigurationen nötig sind. Im Rahmen der Festlegungen zum Thema „Organisation
und Vorgaben zum Konfigurationsmanagement“ im Projekthandbuch sind die Verfahren und
Werkzeuge definiert.
3.7.1.3 Create or Release Baselines
Die zu einer Baseline gehörenden Produkte sind festzulegen.
Baselines sind im V-Modell XT die Produktkonfigurationen. Sie werden im Projektplan festgelegt
und im Verlauf des Projekts durch die Aktivität „Produktkonfiguration verwalten“ verwaltet.
3.7.2 Track and Control Changes
Die spezifischen Praktiken in diesem Ziel stellen die Produktkonfiguration sicher.
3.7.2.1 Track Change Requests
Das Ziel dieses Themas ist die Verfolgung von Änderungen an Produkten und Produktkonfigurationen.
Dafür gibt es im V-Modell XT einen eigenen Vorgehensbaustein, das Problem- und Änderungsmanagement.
Es bietet eine klare Vorgehensweise, die alle Schritte von der Erstellung eines Änderungsantrags
bis zur Lösung des Problems beinhaltet. Unter anderem werden gewünschte
Änderungen bewertet und der Status der Änderungen überwacht.
3.7.2.2 Control Configuration Items
Die unter Konfigurationsmanagement stehenden Produkte sollen gelenkt werden.
Die Überwachung der zu konfigurierenden Produkte geschieht im V-Modell XT mit Hilfe des
Problem- und Änderungsmanagements, der Produktkonfiguration selbst und einigen grundlegenden
Mechanismen. Änderungen an Produkten und deren Produktkonfigurationen werden wie im
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 45 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
letzten Kapitel erwähnt durch das Problem- und Änderungsmanagement, speziell durch die Änderungsstatusliste
verwaltet. Dass diese Änderungen Einfluss auf die Produktkonfiguration als
Ganzes haben, dafür sorgt das Produktzustandsmodell, da es abhängige Komponenten automatisch
wieder in den Zustand „in Bearbeitung“ setzt. Um eine Produktkonfiguration freizugeben,
müssen alle enthaltenen Komponenten geprüft sein. Somit werden alle relevanten Komponenten
bei Änderungen automatisch nochmals geprüft. Die Änderungen, deren Gründe und die gefällte
Entscheidung werden in der Änderungsentscheidung dokumentiert.
3.7.3 Establish Integrity
Die Integrität der Baselines soll durch diese Praktik sichergestellt werden.
3.7.3.1 Establish Configuration Management Records
Die Produktkonfigurationen, ihre Historie und ihre Konfigurationsmerkmale werden aufgezeichnet.
Berichte zur Darstellung des aktuellen Standes der Konfigurationen werden durch die Teilaktivität
„KM-Berichte erstellen“ der Aktivität „Produktbibliothek verwalten“ generiert. Sie enthalten
neben Statuslisten der Konfigurationen auch Informationen zu den Änderungsvorgängen. Somit
ist diese Praktik erfüllt.
3.7.3.2 Perform Configuration Audits
Um die Integrität der Baselines aufrecht zu erhalten, werden Konfigurationsaudits durchgeführt.
Da im V-Modell XT grundsätzlich keine Methoden vorgeschrieben sind, gibt es auch die hier geforderte
Verpflichtung zu Audits nicht. Es existieren dafür Methodenreferenzen, aus denen bei
Projektbeginn Methoden ausgewählt und im Projekthandbuch dokumentiert werden. Das Ziel der
Überprüfung der Baselines wird durch das generische Vorgehen durch die Aktivitäten „Prozess
prüfen“ und „Dokument prüfen“ erreicht. Das Produktzustandsmodell stellt sicher, dass nur fertige
und geprüfte Elemente Teil einer Baseline werden.
Die nach CMMI® erforderlichen Audits sind im V-Modell XT nicht vorgeschrieben, sondern als
eine der möglichen Methoden angegeben. Deshalb ist dieser Bereich größtenteils erfüllt.
3.8 Requirements Development (Maturity Level 3)
Die Anforderungsentwicklung beschäftigt sich mit den Vorgehensweisen der proaktiven Identifizierung
und Analyse der Anforderungen. Dies beginnt beim Hinterfragen der Anforderungen,
Erwartungen, Randbedingungen und Schnittstellen des Kunden, bis sie vollständig verstanden
werden. Die gewonnenen Informationen werden in Kundenanforderungen umgesetzt. Aus den
Kundenanforderungen werden nun die technisch orientierten Anforderungen an das System erarbeitet
und seinen Elementen zugeordnet. Im nächsten Schritte findet die Ermittlung der Schnittstellenanforderungen
zwischen diesen verschiedenen Systemelementen statt. Um die
verschiedenen bisher festgelegten Anforderungen überprüfen zu können, werden Betriebskonzepte,
dazugehörige Szenarien und eine Definition der geforderten Funktionalität ermittelt und
gepflegt. Nach der Analyse der Anforderungen müssen die Anforderungen und Randbedingungen
von allen Betroffenen in Einklang gebracht und schließlich eine ausführliche Validierung
durchgeführt werden, sodass die Anforderungen zu einem System führen, das in der Nutzungsumgebung
funktioniert.
Die Anforderungsentwicklung ist im V-Modell XT über die Vorgehensbausteine Anforderungsfestlegung,
Systemerstellung, SW-Entwicklung, HW-Entwicklung und Qualitätssicherung verteilt,
mit Schwerpunkt auf Anforderungsfestlegung. Die Entwicklung der Kundenanforderungen
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 46 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
endet hierbei im Produkt Anforderungen und muss beim V-Modell XT vom Auftraggeber durchgeführt
werden. Demgegenüber müssen die Produktanforderungen vom Auftragnehmer ermittelt
werden und zwar sind hierbei alle Produkte der Produktgruppe Systemspezifikation nötig. Diese
Rollentrennung wird beim CMMI® nicht vorgenommen. Die Festlegung auf Konzepte und die
Analyse der Anforderungen erfolgt im V-Modell XT in Anforderungen und Anforderungsbewertung.
Im Methodenkatalog stehen auch Use-Cases zur Verfügung, die dazu genutzt werden können.
Diese Methode kann auch zum Bestimmen der erforderlichen Funktionalität benutzt
werden, welche in der Schnittstellenbeschreibung verwirklicht wird. Die Validierung der Anforderungen
erfolgt in der Designabsicherung und durch die Prüfung der Dokumente.
Da die Ermittelung der Anforderungen im V-Modell XT in zwei verschiedenen Projekten, dem
des Auftraggebers und dem des Auftragnehmers, durchgeführt wird, ist das vom CMMI® geforderte
proaktive Vorgehen nicht möglich. Es geht darum, die Anforderungen gemeinsam zu erarbeiten,
damit beide Parteien das gleiche Verständnis von der Bedeutung der Anforderungen
haben.
3.8.1 Develop Customer Requirements
Ziel der folgenden Praktiken ist die proaktive Ermittlung der Anforderungen, Erwartungen,
Randbedingungen und Schnittstellen der Beteiligten. Diese Informationen müssen in Kundenanforderungen
umgesetzt werden.
3.8.1.1 Elicit Needs
Ziel der Praktik ist die proaktive Ermittlung der Forderungen, die der Kunde an das Produkt
stellt. Diese sollen Auftraggeber und Auftragnehmer gemeinsam erarbeiten, damit beide das gleiche
Verständnis für die Anforderungen gewinnen.
Da im V-Modell XT eine strikte Trennung zwischen Auftraggeberprojekt und Auftragnehmerprojekt
besteht, ist dieses Vorgehen nicht vorgesehen. Es ist die Aufgabe des Auftragnehmers mit
Hilfe entsprechender Fachleute seine Anforderungen präzise festzulegen. Aufgabe des Auftragnehmers
ist es die vom Auftraggeber übernommenen Anforderungen (Lastenheft) in seine eigenen
Anforderungen, genannt Gesamtsystemspezifikation (Pflichtenheft), zu integrieren. Dabei
kommen noch Anforderungen der Organisation oder des eigenen Prozesses hinzu.
Die Praktik ist nur teilweise erfüllt.
3.8.1.2 Develop the Customer Requirements
Hierbei geht es um die Umwandlung der im Kapitel 3.8.1.1 gewonnenen Kundenanforderungen
in niedergeschriebene Anforderungen, die Grundlage eines Vertrages sein können.
Da die Abgrenzung im V-Modell XT nicht so exakt gemacht wird, sind diese Dokumente wiederum
die Anforderungen (Lastenheft) und die Gesamtsystemspezifikation (Pflichtenheft). Die
hier geforderten Randbedingungen für Verifikation und Validierung sind in den Anforderungen
zu finden.
3.8.2 Develop Product Requirements
Aus den Kundenanforderungen werden die Anforderungen an das System und seine Elemente
abgeleitet.
3.8.2.1 Establish Product and Product-Component Requirements
Die Praktik fordert die Umsetzung der Anwenderanforderungen in Anforderungen an das System
und seine Systemelemente, d. h. in eine technische Sicht.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 47 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Diese Forderung wird im V-Modell XT bei der Erstellung der verschiedenen Spezifikationsdokumente
erfüllt; funktionale wie nichtfunktionale Anforderungen aus der Gesamtsystemspezifikation
werden als Grundlage dafür genommen.
3.8.2.2 Allocate Product Component-Requirements
Ziel der Praktik ist es, die Anforderungen auf die Systemelemente zuzuordnen. Damit wird die
Verfolgbarkeit der Anforderungen bezweckt, die im Kapitel 3.1 gefordert wird.
Diese Aufgabe erfüllen im V-Modell XT die verschiedenen Architekturprodukte und das Thema
Anforderungsverfolgung der diversen Spezifikationsprodukte.
3.8.2.3 Identify Interface Requirements
In dieser Praktik sollen alle Schnittstellen identifiziert und die Anforderungen an sie festgelegt
werden.
Eine Übersicht über alle Schnittstellen entsteht bei der Erstellung der Architekturprodukte im
Thema Schnittstellenübersicht. Die präzisen Definitionen der Schnittstellen, die alle ihre Eigenschaften
festlegen, sind im V-Modell XT in den Themen Schnittstellenbeschreibung und Schnittstellenrealisierung
der Spezifikationen zu finden.
3.8.3 Analyze and Validate Requirements
Hier erfolgt die Analyse und Validierung der Anforderungen sowie eine Definition der geforderten
Funktionalität.
3.8.3.1 Establish Operational Concepts and Scenarios
In dieser Praktik sollen Betriebskonzepte erarbeitet werden, die der Einsatzumgebung des Systems
entsprechen, um später die Anforderungen validieren zu können.
Dies erfolgt im V-Modell XT im Thema Funktionale Anforderungen des Produkts Anforderungen
(Lastenheft). Unterstützend gibt es in der Methodenreferenz passende Methoden.
3.8.3.2 Establish a Definition of Required Functionality
Durch eine Funktionsanalyse soll die vom Endbenutzer benötigte Funktionalität analysiert, gruppiert
und den Anforderungen zugeordnet werden.
Dies ist im V-Modell XT in den Spezifikationsprodukten abgebildet, in denen explizit eine Matrix
zwischen Anforderungen und den umzusetzenden Elementen erzeugt wird.
3.8.3.3 Analyze Requirements
Diese Praktik will sicherstellen, dass die Anforderungen nochmals analysiert werden, damit sie
auch zu dem von den Beteiligten gewünschten System führen. Dabei sind unter anderem die
technische Machbarkeit und die Betriebskonzepte zu beachten.
Im V-Modell XT übernimmt diese Aufgabe die Teilaktivität „Qualität der Anforderungen analysieren“,
die bei der Erstellung der Anforderungen durchgeführt wird.
3.8.3.4 Analyze Requirements to Achieve Balance
Eine Ausgewogenheit zwischen Anwenderanforderungen und Randbedingungen muss in dieser
Praktik gefunden werden, um Risiken zu minimieren und doch die gewünschte Funktionalität zu
erhalten.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 48 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Im V-Modell XT werden die Anforderungen in der Anforderungsbewertung zum Beispiel einer
Kosten-Nutzen-Abwägung unterzogen.
3.8.3.5 Validate Requirements with Comprehensive Methods
Diese Praktik verlangt die Validierung der Anforderungen, um die Vollständigkeit der Anforderungen
und die korrekte Funktion in der Einsatzumgebung sicherzustellen.
Dazu dient im V-Modell XT neben dem Thema „Designabsicherung und Prototypentwicklung“
in den Architekturdokumenten das generische Vorgehen der Prüfungen. Da eine Prüfung für alle
Produkte vorgesehen ist und diese sowohl Verifikation als auch Validierung beinhaltet, können
dadurch auch die Anforderungen überprüft werden.
3.9 Technical Solution (Maturity Level 3)
Die technische Umsetzung setzt Anforderungen mit Hilfe von Design und Implementierung in
Systeme und Systemelemente um. Aus den verschiedenen, detailliert untersuchten Lösungsansätzen
wird mit Hilfe von Entscheidungskriterien die beste Variante ausgewählt. Das Hauptaugenmerk
dieses Prozessgebiets liegt auf der Entwicklung des Designs des zu erzeugenden
Systems bzw. seiner Elemente. Die gesammelten Designdokumente werden zusammen mit den
Anforderungsdokumenten im so genannten technischen Datenpaket zusammengefasst. Mit Hilfe
dieser Informationen kann die Entscheidung getroffen werden, ob das ganze oder Teile des Systems
zugekauft, neu entwickelt oder bestehende Systeme wieder verwendet werden. Die gefällten
Entscheidungen werden umgesetzt, indem das Design implementiert wird und die
dazugehörige Dokumentation verfasst wird. Die fertigen Module werden vor der Weiterverwendung
auf Funktionsfähigkeit getestet.
Die technische Umsetzung wird in den Vorgehensbausteinen Systemerstellung, HW-Entwicklung
und SW-Entwicklung abgewickelt, die Entwicklung der unterstützenden Dokumentation im
Rahmen der logistischen Unterstützung. Sie ergibt das Produkt Logistische Unterstützungsdokumentation.
Die Auswahl von Lösungen für Systemelemente erfolgt in den Architekturprodukten
des Systementwurfs. Die Entscheidung, ob man das System selbst entwickelt, kauft oder ein
schon bestehendes System weiterentwickelt fällt in der Make-or-Buy-Entscheidung. Auch bei
der Erarbeitung des Designs sind neben den Spezifikationen für Hard- und Software wieder die
Architekturprodukte des Systementwurfs nötig. Die Implementierung des Designs endet in den
Systemelementen.
3.9.1 Select Product-Component Solutions
Ziel dieser Aktivität ist die Auswahl des besten Lösungsansatzes für die Systemelemente, wobei
verschiedene Alternativen erstellt und anhand von Auswahlkriterien die beste Variante gewählt
wird.
3.9.1.1 Develop Detailed Alternative Solutions and Selection Criteria
Ziel dieser Praktik ist es, alternative Lösungen zu entwickeln und Kriterien für die Auswahl der
besten Lösung aufzustellen.
Im Thema „Architekturprinzipien und Entwurfsalternativen“ der Architekturprodukte werden die
verschiedenen Alternativen im V-Modell XT dargestellt.
Da eine Festlegung von Kriterien für die Auswahl einer Alternative im V-Modell XT fehlt, ist
dieser Teil größtenteils erfüllt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 49 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.9.1.2 Evolve Operational Concepts and Scenarios
In dieser Praktik sollen Betriebskonzepte und Szenarien entwickelt werden, um die Bedingungen,
Betriebsarten und Betriebszustände aller Systemelemente beschreiben zu können.
Dazu dienen im V-Modell XT das Thema „Designabsicherung und Prototypentwicklung“ in den
Architektur- und Spezifikationsdokumenten.
3.9.1.3 Select Product-Component Solutions
Die Auswahl der besten Lösung für jedes einzelne Systemelement soll im CMMI® aufgrund der
vorher festgelegten Kriterien erfolgen. Dazu ist es nötig, die verschiedenen Alternativen zu beurteilen,
Probleme abzuschätzen und das gesamte Vorgehen zu dokumentieren.
Diese Informationen befinden sich beim V-Modell XT in den verschiedenen Architekturdokumenten
von System, Hardware und Software.
Da es im V-Modell XT keine Kriterien für die Auswahl, sondern nur die alternativen Lösungsansätze
gibt, ist diese Praktik nur teilweise erfüllt.
3.9.2 Develop the Design
Nachdem durch einen Auswahlprozess der beste Lösungsansatz ausgewählt wurde, wird im folgenden
Kapitel das Design dafür entwickelt.
3.9.2.1 Design the Product or Product Component
Neben der Entwicklung des Designs von Systemen und Systemelementen fordert diese Praktik
vom Projekt die Erarbeitung von Kriterien, anhand derer das Design beurteilt werden kann.
Die Umsetzung erfolgt im V-Modell XT in den Architekturdokumenten. Die Kriterien werden in
der Teilaktivität „Bewertungskriterien festlegen“ erarbeitet.
3.9.2.2 Establish a Technical Data Package
Das CMMI® verlangt die Erstellung eines Technischen Datenpaketes, welches im Wesentlichen
die gesamte Entwicklungsdokumentation umfasst. Dazu gehören unter anderem die Anforderungen,
die Architektur, die Spezifikation und die Schnittstellenanforderungen.
Diese Dokumente existieren im V-Modell XT alle, jedoch nicht in einem gemeinsamen Paket. Zu
finden sind die verschiedenen Informationen in den Architekturdokumenten, den Spezifikationsdokumenten,
den verschiedenen Prüfspezifikationen und den Produktkonfigurationen.
3.9.2.3 Design Interfaces Using Criteria
In dieser Praktik geht es um die Erstellung der Schnittstellen unter Berücksichtigung der Merkmale
der Schnittstellen.
Die Umsetzung erfolgt im V-Modell XT im Thema Schnittstellenbeschreibung der Architekturdokumente.
3.9.2.4 Perform Make, Buy or Reuse Analyses
In dieser Aktivität sollen Kriterien entwickelt werden, aufgrund derer man entscheiden kann,
welches System oder welches Systemelement zugekauft, selbst entwickelt oder aus einem wieder
verwendbaren System erstellt wird.
Hierfür gibt es im V-Modell XT die Make-or-Buy-Entscheidung. Am Namen des Produktes erkennt
man schon, dass die Wiederverwendung bereits vorhandener Produkte nicht betrachtet
wird, d. h. Reuse wird im V-Modell XT nicht betrachtet.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 50 von 129

Deshalb ist die Aktivität größtenteils erfüllt.
DAS V-MODELL XT AUS SICHT DES CMMI®
3.9.3 Implement the Product Design
Dieses Ziel setzt das Design in ein fertiges System um, unterzieht es einer Prüfung und erstellt
die Dokumentation.
3.9.3.1 Implement the Design
In dieser Praktik geht es um die Umsetzung des Designs in ein Systemelement. Die anschließende
Verifikation des Systemelements erfolgt analog zum Prozessgebiet Verifikation.
Im V-Modell XT entstehen bei der Implementierung des Designs die Produkte der Produktgruppe
Systemelement. Die Prüfungen erfolgen wie bei der Verifikation beschrieben.
3.9.3.2 Develop Product Support Documentation
Ziel dieser Praktik ist die Erstellung der Nutzungsdokumentation, die das Betriebshandbuch, das
Nutzerhandbuch, das Servicehandbuch und die Schulungsunterlagen enthält.
Diese Dokumente werden durch den Vorgehensbaustein Logistische Unterstützung erzeugt.
3.10 Product Integration (Maturity Level 3)
Aufgabe der Systemintegration ist das Zusammensetzen des Systems aus seinen Elementen, die
richtige Funktion des Systems sicherzustellen und das System zu liefern. In der Vorbereitung
werden die Reihenfolge der Integration der Systemelemente festgelegt, die Umgebung und Vorgehensweisen
für die Durchführung der Integration geschaffen sowie die Kriterien für den Beginn
der Integration festgelegt. In einem weiteren Schritt wird die Kompatibilität der
Schnittstellen sichergestellt, indem die Schnittstellenbeschreibungen „gemanagt“ und auf Vollständigkeit
überprüft werden. Abschließend muss das System iterativ aus seinen Komponenten
zusammengesetzt und ausgeliefert werden. Dazu müssen die zuvor festgelegten Bedingungen für
den Beginn der Integration erfüllt sein, um die Elemente zu integrieren, dann das Ergebnis mit
Hilfe von Verifikation und Validation zu evaluieren und das fertige System oder Systemelement
zu liefern.
Die Systemintegration wird in den Vorgehensbausteinen Systemerstellung, HW-Entwicklung und
SW-Entwicklung, unterstützt durch Qualitätssicherung, Konfigurationsmanagement und „Angebotserstellung
und Vertragserfüllung(AN)“ durchgeführt. Die Vorbereitung endet in den Konzeptprodukten
des Systementwurfs. Die für die Integration nötige Umgebung muss in einem
eigenen Unterstützungssystem entwickelt werden. Die Schnittstellenkompatibilität wird durch
die Prüfung der Konzeptdokumente des Systementwurfs sichergestellt. Durch die Produktkonfiguration
und die Konzepte des Systementwurfs wird sichergestellt, dass erst fertige Teilprodukte
integriert werden. Bei der Durchführung der Integration und der anschließenden Beurteilung entstehen
die Produkte der Produktgruppe Systemelement. Die Lieferung ist das Endprodukt, welches
dem Kunden übergeben wird.
3.10.1 Prepare for Product Integration
Dieses Ziel verlangt die Festlegung der Reihenfolge der Integration, die Entwicklung einer Integrationsumgebung,
die Definition von Vorgehensweisen und die Festlegung von Erfolgskriterien.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 51 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.10.1.1 Determine Integration Sequence
In dieser Praktik geht es um die Festlegung der Reihenfolge der Integration. Hierzu ist es nötig,
die zu integrierenden Systemkomponenten zu ermitteln, verschiedene Reihenfolgen zu erarbeiten
und aus den Alternativen dann die beste auszuwählen.
Im V-Modell XT ist das im Thema „Vorgaben zur Integration und Integrationsbauplan“ der
Implementierungs-, Integrations- und Prüfkonzepte von System, Unterstützungssystem, Hardware
und Software umgesetzt.
Da eine Erarbeitung von alternativen Reihenfolgen für die Integration im V-Modell XT nicht
vorgesehen ist, wird diese Praktik größtenteils erfüllt.
3.10.1.2 Establish the Product Integration Environment
Ziel dieser Praktik ist die Einrichtung einer Integrationsumgebung. Dazu sind die Anforderungen
an die Umgebung zu erarbeiten, Verifikationskriterien und Vorgehensweisen festzulegen, sowie
zu entscheiden, ob die Integrationsumgebung gekauft werden kann oder selbst entwickelt werden
muss.
Im V-Modell XT wird normalerweise für die Integrationsumgebung ein eigenes Unterstützungssystem
entwickelt. Da es Teil des Gesamtsystems ist, wird es genauso behandelt wie jede andere
Systemkomponente. Somit unterliegt es beispielsweise auch der Prüfung. Falls kein Unterstützungssystem
nötig ist, gibt es die oben genannten Integrationskonzepte.
3.10.1.3 Establish Product Integration Procedures and Criteria
Diese Praktik soll ein Vorgehen für die Integration, Kriterien für Erfolg, Validierung und Auslieferungsbeginn
erarbeiten.
Die Umsetzung erfolgt im V-Modell XT in den verschiedenen Implementierungs-, Integrations-
und Prüfkonzepten.
3.10.2 Ensure Interface Compatibility
Dieses spezifische Ziel soll sicherstellen, dass die implementierten Schnittstellen vollständig und
kompatibel sind.
3.10.2.1 Review Interface Descriptions for Completeness
Die Vollständigkeit und Übereinstimmung der Schnittstellenbeschreibungen soll mittels dieser
Praktik überprüft werden.
Im V-Modell XT stehen die Vorgehensweisen für die Prüfung in den Implementierungs-, Integrations-
und Prüfkonzepten. Die Prüfungen werden durch den generischen Prozess der Prüfung von
Dokumenten durchgeführt. Als Ergebnis gibt es ein Prüfprotokoll, in dem die Ergebnisse aufgezeichnet
sind.
3.10.2.2 Manage Interfaces
Zum geforderten Management der Schnittstellen gehört es, dass die Kompatibilität der Schnittstellen
zwischen zwei Systemkomponenten über die ganze Lebenszeit des Systems sichergestellt
ist, Probleme gelöst werden und allen Projektbeteiligten eine Schnittstellenübersicht zur Verfügung
gestellt wird.
Durch den Vorgehensbaustein Problem- und Änderungsmanagement nimmt das V-Modell XT
Problemmeldungen auf und bringt Änderungen ein. Die Schnittstellenübersicht befindet sich als
Thema in der Systemarchitektur. Das Schnittstellen-Management ist durch die grundlegenden
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 52 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Konzepte des V-Modells XT in den Vorgehensbausteinen Projektmanagement, Konfigurationsmanagement
und Problem- und Änderungsmanagement erfüllt.
3.10.3 Assemble Product Components and Deliver the Product
In den nächsten Praktiken geht es um die Durchführung der Integration, die anschließende Überprüfung
der Schnittstellenkompatibilität und die Auslieferung des Systems an den Kunden.
3.10.3.1 Confirm Readiness of Product Components for Integration
Das CMMI® will mit dieser Praktik sicherstellen, dass die zu integrierenden Systemkomponenten
alle fertig gestellt sind, ihren Beschreibungen entsprechen und zur Verfügung stehen.
Im V-Modell XT gibt es keine explizite Überprüfung der Teilprodukte vor der Integration, da
dies alles über die Konfigurationskonzepte, die Produktbibliothek und das Produktstatusmodell
abgefangen wird.
Deshalb ist die Praktik nur teilweise erfüllt.
3.10.3.2 Assemble Product Components
Aufgrund der entwickelten Integrationsreihenfolge und der definierten Vorgehensweisen sollen
die Systemelemente zum System integriert werden.
Für die Durchführung der Integration gibt es im V-Modell XT einige Aktivitäten, wie „Zum System
integrieren“, „Zur HW-Komponente integrieren“ oder „Zur SW-Einheit integrieren“. Als Ergebnis
liefern diese Aktivitäten die Produkte der Produktgruppe Systemelement.
3.10.3.3 Evaluate Assembled Product Component
Die fertigen Systemelemente werden in dieser Praktik einer Prüfung unterzogen.
Da im V-Modell XT jedes Produkt anhand seiner Prüfkonzepte einer Prüfung durch die Aktivität
„Systemelement prüfen“ unterzogen werden muss, ist dieser Aspekt erfüllt. Die Ergebnisse sind
im Prüfprotokoll Systemelement dokumentiert.
3.10.3.4 Package and Deliver the Product or Product Component
In dieser Praktik geht es um die Auslieferung des fertigen Systems an den Kunden. Dazu gehört
neben der eigentlichen Ausführung, das korrekte Verpacken und die Installation beim Kunden.
Im V-Modell XT ist die Lieferung als Produkt definiert, in dem entsprechend den Vorgaben des
Vertrages auch alle Teillieferungen summiert sind. Das Produkt wird durch die Aktivität „Lieferung
erstellen und ausliefern“ an den Kunden ausgeliefert.
Da die Verpackung und die Installation beim Kunden nicht explizit beschrieben sind, ist die
Praktik nur teilweise erfüllt.
3.11 Verification (Maturity Level 3)
Die Verifikation soll sicherstellen, dass ausgewählte Arbeitsergebnisse an sie gestellte Anforderungen
erfüllen. Die Vorbereitung besteht aus der Auswahl der zu verifizierenden Arbeitsergebnisse,
der Einrichtung der Verifikationsumgebung, der Festlegung von Bedingungen für
Korrektheit und der Festlegung von Vorgehensweisen für die Verifikation. Als Methode bei der
Durchführung der Verifikation ist das Peer Review (Partnerreview) im CMMI® festgelegt. Das
ist ein Review durch Gleichgestellte, welches regelmäßig ausgeführt und dadurch möglichst früh
durch die inhaltliche Prüfung eines Fachmanns Fehler erkennen soll. Es wird die Einhaltung der
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 53 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Anforderungen nach Fertigstellung des Systems oder des Systemelements überprüft. Peer Reviews
werden vorbereitet, durchgeführt und die Ergebnisse analysiert. Falls korrigierende Maßnahmen
nötig sind, werden sie eingeleitet.
Die Verifikation wird durch die Produkte der Gruppe Prüfung und durch die Prüfkonzepte der
Gruppe Systementwurf umgesetzt. Bis auf die später erwähnten Reviews und die Auswahl der zu
verifizierenden Produkte, welche durch die Prüfkonzepte und das QS-Handbuch festgelegt werden,
stehen alle Informationen in den Produkten der Gruppe Prüfung.
Im V-Modell XT sind zwar auch Reviews durchzuführen, jedoch sind die nach CMMI® erforderlichen
Peer Reviews nicht vorgeschrieben, sondern als eine der möglichen Reviewmethoden
angegeben. Deshalb ist dieser Bereich größtenteils erfüllt.
3.11.1 Prepare for Verification
Dieses Ziel fordert die Vorbereitung der Verifikation. Das beinhaltet, die Auswahl der zu verifizierenden
Systemelemente, die Einrichtung der Verifikationsumgebung und die Definition der
Methoden, Prozeduren und Erfüllungskriterien für die Verifikation.
3.11.1.1 Select Work Products for Verification
In dieser Praktik geht es um die Auswahl der Systemelemente, die einer Prüfung unterzogen
werden, und die Festlegung von Verifikationsmethoden für jedes einzelne Systemelement.
Im V-Modell XT wird im Thema „Zu prüfende Produkte“ des QS-Handbuchs festgelegt, welche
Typen von Produkten geprüft werden müssen. Die Themen „Zu prüfende Systemelemente“, „Zu
prüfende SW-Elemente“ und „Zu prüfende HW-Elemente“ der verschiedenen Prüfkonzepte legen
fest, welche Produkte einer Prüfung unterzogen werden. Die Methoden werden im Thema
Prüfstrategie der Prüfspezifikationen und im Thema „Vorgehen zu Prüfung und Prüfstrategie“
der verschiedenen Implementierungs-, Integrations- und Prüfkonzepte festgelegt.
3.11.1.2 Establish the Verification Environment
Hier ist die Erstellung einer Verifikationsumgebung gefordert. Dazu gehört es, die Anforderung
an die Umgebung zu erarbeiten, mögliche wieder verwendbare Umgebungen zu ermitteln und
nötige Werkzeuge und Anlagen zu beschaffen.
Im Thema Prüfumgebung der verschiedenen Prüfspezifikationen werden im V-Modell XT die
Prüfumgebungen spezifiziert. Die Erstellung der Umgebung kann in einem eigenen Unterstützungssystem
oder in einem gesonderten Projekt erfolgen.
3.11.1.3 Establish Verification Procedures and Criteria
Ziel dieser Praktik ist die Erstellung von Verifikationsprozeduren und Kriterien für eine erfolgreiche
Verifikation.
Die Umsetzung erfolgt im V-Modell XT in den verschiedenen Prüfspezifikationen und der
„Prüfprozedur Systemelement“.
3.11.2 Perform Peer Reviews
Dieses spezifische Ziel fordert die Durchführung von Peer Reviews.
Da das Peer Review eine Methode ist, wird diese im V-Modell XT nicht vorgeschrieben. Peer
Reviews sind in den Methodenreferenzen beschrieben und können vom Projekt als eine der möglichen
Methoden für die Verifikation ausgewählt und benutzt werden.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 54 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Somit ist streng genommen das gesamte Ziel nicht erfüllt. Falls projektspezifisch im Projekthandbuch
oder dem QS-Handbuch Peer Reviews vorgeschrieben werden, ist das Ziel erfüllt.
3.11.2.1 Prepare for Peer Reviews
Diese Praktik bereitet die Durchführung des Peer Reviews vor. Dabei werden Anforderungen,
Ein- und Ausgangskriterien, Zeitplan und Rollenverteilung festgelegt.
Die Vorbereitungen erfolgen im V-Modell XT wie in Kapitel 3.11.1.1 und 3.11.1.3.
Falls Peer Reviews im Projekt vorgeschrieben sind, ist die Praktik erfüllt, andernfalls nicht erfüllt.
3.11.2.2 Conduct Peer Reviews
Vom CMMI® wird die Durchführung von Peer Reviews gefordert. Dabei müssen die Ergebnisse
inklusive der Korrekturmaßnahmen aufgezeichnet und an die relevanten Beteiligten weitergegeben
werden.
Umgesetzt wird dies im V-Modell XT in den Teilaktivitäten „Systemelement verifizieren“, „Dokument
verifizieren“, „Prozess verifizieren“, „Benutzbarkeit verifizieren“ und „Lieferung verifizieren“.
Dokumentiert wird es in den verschiedenen Prüfprotokollen. Die Weitergabe der
Informationen ist im V-Modell XT nicht explizit angesprochen, sollte aber im Rahmen von Projektstatusbericht
und QS-Bericht erfolgen.
Falls Peer Reviews im Projekt vorgeschrieben sind, ist die Praktik wegen der nicht festgelegten
Weitergabe der Informationen größtenteils erfüllt, sonst nicht erfüllt.
3.11.2.3 Analyze Peer Review Data
In dieser Praktik werden die im Peer Review gesammelten Informationen ausgewertet und für
die weitere Nutzung gespeichert. Dabei ist auf den Datenschutz zu achten.
Die Analyse erfolgt im Thema „Ergebnisanalyse und Korrekturvorschläge” der verschiedenen
Prüfprotokolle. Für die Nachwelt werden die Informationen in der Organisationsweiten Erfahrungsdatenbasis
gespeichert, die auch auf die Einhaltung des Datenschutzes hinweist.
Falls Peer Reviews im Projekt vorgeschrieben sind, ist die Praktik erfüllt, sonst nicht erfüllt.
3.11.3 Verify Selected Work Products
In diesem Thema wird die Verifikation durchgeführt, analysiert und Korrekturmaßnahmen ermittelt.
3.11.3.1 Perform Verification
Die Praktik führt die Verifikation durch, zeichnet die gewonnenen Ergebnisse auf und ermittelt
die sich ergebenden Maßnahmen.
Umgesetzt wird dies im V-Modell XT in den Teilaktivitäten „Systemelement verifizieren“, „Dokument
verifizieren“, „Prozess verifizieren“, „Benutzbarkeit verifizieren“ und „Lieferung verifizieren“.
Dokumentiert wird es in den verschiedenen Prüfprotokollen.
3.11.3.2 Analyze Verification Results and Identify Corrective Action
Ziel dieser Praktik ist die Analyse der Ergebnisse der Verifikation und der Festlegung von korrigierenden
Maßnahmen.
Die geforderten Aspekte sind im V-Modell XT im Thema „Ergebnisanalyse und Korrekturvorschläge”
der verschiedenen Prüfprotokolle beschrieben. Die darin enthaltenen Korrekturvor-
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 55 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
schläge werden zwar dokumentiert und berichtet, müssten aber möglicherweise in einen „Problem-
und Änderungsantrag“ eingebracht werden. Dies ist nicht explizit beschrieben.
Daher ist diese Praktik größtenteils erfüllt.
3.12 Validation (Maturity Level 3)
Mit der Validierung soll erreicht werden, dass ein System oder ein Systemelement in seiner geplanten
Zielumgebung wie gewünscht funktioniert. Vorbereitend werden die zu validierenden
Systeme oder Systemelemente ausgewählt, die Validierungsumgebung eingerichtet, Bedingungen
für Korrektheit der Ergebnisse und Vorgehensweisen für die Durchführung der Validierung
festgelegt. Nach der Durchführung der Validierung werden die Ergebnisse analysiert und mit Hilfe
der zuvor festgelegten Bedingungen Schwachstellen ermittelt. Diese können durch die Einreichung
und Umsetzung von Änderungsanträgen korrigiert werden.
Das Prozessgebiet Validierung wird hauptsächlich durch die Produkte der Gruppe Prüfung erfüllt.
Die Auswahl der zu validierenden Produkte wird wie bei der Verifikation in den Prüfkonzepten
der Gruppe Systementwurf und dem QS-Handbuch festgelegt. Die benötigte Umgebung
sollte wiederum von einem Unterstützungssystem zur Verfügung gestellt werden. Die Auswahl
der Prüfkriterien und Prüfprozeduren erfolgt in den Prüfspezifikationen und der Prüfprozedur
Systemelement. Die Durchführung und Auswertung hat als Ergebnis die Prüfprotokolle der Produktgruppe
Prüfung.
3.12.1 Prepare for Validation
Dieses Ziel fordert die Vorbereitung der Validierung. Das beinhaltet die Auswahl der zu validierenden
Systemelemente, die Einrichtung der Validierungsumgebung und die Definition der Methoden,
Prozeduren und Erfüllungskriterien für die Validierung.
3.12.1.1 Select Products for Validation
In dieser Praktik geht es um die Auswahl der Systemelemente, die einer Validierung unterzogen
werden, und die Festlegung von Validierungsmethoden für jedes einzelne Systemelement.
Im V-Modell XT wird im Thema „Zu prüfende Produkte“ des QS-Handbuchs festgelegt, welche
Typen von Produkten geprüft werden müssen. Die Themen „Zu prüfende Systemelemente“, „Zu
prüfende SW-Elemente“ und „Zu prüfende HW-Elemente“ der verschiedenen Prüfkonzepte legen
fest, welche Produkte einer Prüfung unterzogen werden. Die Methoden werden im Thema
Prüfstrategie der Prüfspezifikationen und im Thema „Vorgehen zu Prüfung und Prüfstrategie“
der verschiedenen Implementierungs-, Integrations- und Prüfkonzepte festgelegt.
3.12.1.2 Establish the Validation Environment
Hier ist die Erstellung einer Validierungsumgebung gefordert. Dazu gehört es, die Anforderung
an die Umgebung zu erarbeiten, mögliche wieder verwendbare Umgebungen zu ermitteln und
nötige Werkzeuge und Anlagen zu beschaffen.
Im Thema Prüfumgebung der verschiedenen Prüfspezifikationen werden im V-Modell XT die
Prüfumgebungen spezifiziert. Die Erstellung der Umgebung erfolgt meist in einem eigenen Unterstützungssystem
oder in einem extra Projekt.
3.12.1.3 Establish Validation Procedures and Criteria
Ziel dieser Praktik ist die Erstellung von Validierungsprozeduren und Kriterien für eine erfolgreiche
Validierung.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 56 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Die Umsetzung erfolgt im V-Modell XT in den verschiedenen Prüfspezifikationen und der
„Prüfprozedur Systemelement“.
3.12.2 Validate Product or Product Components
In diesem Thema wird die Validierung durchgeführt, analysiert und Korrekturmaßnahmen ermittelt.
3.12.2.1 Perform Validation
Die Praktik führt die Validierung durch und zeichnet die gewonnenen Ergebnisse auf.
Umgesetzt wird dies im V-Modell XT in den Teilaktivitäten „Systemelement validieren“, „Dokument
validieren“, „Prozess validieren“, „Benutzbarkeit validieren“ und „Lieferung validieren“.
Dokumentiert wird es in den verschiedenen Prüfprotokollen.
3.12.2.2 Analyze Validation Results
Ziel dieser Praktik ist die Analyse der Ergebnisse der Validierung und die Stellung von Änderungsanträgen,
falls korrigierende Maßnahmen nötig sind.
Die Analyse ist beim V-Modell XT im Thema „Ergebnisanalyse und Korrekturvorschläge” der
verschiedenen Prüfprotokolle beschrieben. Die darin enthaltenen Korrekturvorschläge werden
zwar dokumentiert und berichtet, müssten aber in einen „Problem- und Änderungsantrag“ eingebracht
werden. Dies ist nicht explizit beschrieben.
Daher ist diese Praktik größtenteils erfüllt.
3.13 Organizational Process Focus (Maturity Level 3)
Dieses Prozessgebiet dient vorrangig der Identifizierung, Planung und Umsetzung von Prozessverbesserungen
innerhalb der eigenen Organisation basierend auf einem fundierten Verständnis
für die Stärken und Schwächen der organisationsweiten Prozesse. Um die Möglichkeiten für
Prozessverbesserungen zu ermitteln, werden die Bedürfnisse der Organisation an ihre Prozesse
ermittelt und die aktuellen Prozesse bewertet. Nach der Auswahl der umzusetzenden Verbesserungsmaßnahmen
werden diese geplant und durchgeführt. Die Verbesserungen bestehen nicht
nur aus neuen oder geänderten Prozessen und deren Beschreibungen, sondern z.B. auch aus
Schulungsunterlagen und unterstützenden Werkzeugen. Diese Elemente werden unternehmensweit
eingeführt.
Der Organisationsweite Prozessfokus des CMMI® wird im V-Modell XT im Vorgehensbaustein
ORG umgesetzt. Die Möglichkeiten der Prozessverbesserung werden im Verbesserungskonzept
und der Bewertung des Vorgehensmodells niedergeschrieben. Die Planung und Umsetzung von
Verbesserungen werden im Verbesserungskonzept und dem Organisationsspezifischen Vorgehensmodell
beschrieben. Da auch die Verbesserungen in einem eigenen Projekt laufen sollten,
wird dabei ein Projektplan erstellt und die Erfahrungen aus den Projekttagebüchern alter Projekte
können eingearbeitet werden.
3.13.1 Determine Process-Improvement Opportunities
Ziel ist es, Verbesserungspotential bei den Prozessen zu erkennen. Dazu sind die Anforderungen
an die Prozesse und die Ziele der Organisation zu erarbeiten, sowie die Stärken und Schwächen
der existierenden Prozesse zu analysieren.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 57 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.13.1.1 Establish Organizational Process Needs
In dieser Praktik geht es um die Erarbeitung der Ziele der Organisation und der Anforderungen,
welche die Organisation an ihre Prozesse hat.
Umgesetzt ist dies im V-Modell XT im Thema „Zielsetzung und Managementunterstützung“ des
Produkts „Verbesserungskonzept für ein Vorgehensmodell“.
3.13.1.2 Appraise the Organization’s Processes
Um Verbesserungspotential bei den Prozessen erkennen zu können, muss regelmäßig der Prozess
der Organisation beurteilt werden. Dieses Vorgehen wird geplant und dokumentiert. Als Ergebnis
werden Verbesserungsvorschläge für die Prozesse erwartet.
Im V-Modell XT gibt es für die Verbesserung der Prozesse einen eigenen Projekttyp mit dem
Namen „Entwicklung eines organisationsspezifischen Vorgehensmodells“. Darin werden die
momentan angewendeten Prozesse beurteilt und im Produkt „Bewertung eines Vorgehensmodells“
Stärken, Schwächen und Maßnahmen formuliert. Da das Vorgehen im Rahmen eines extra
Projekts realisiert ist, wird auch ein Projektplan erstellt.
3.13.1.3 Identify the Organization's Process Improvements
In dieser Aktivität wird eine Liste der möglichen Prozessverbesserungen erarbeitet, Prioritäten
darin gesetzt und schließlich die Liste der umzusetzenden Verbesserungen festgelegt.
Im Thema Anforderungen des Produkts „Verbesserungskonzept für ein Vorgehensmodell“ werden
aus der in der Bewertung gewonnenen Liste von möglichen Maßnahmen diejenigen festgelegt,
welche im Verbesserungsprojekt umgesetzt werden.
3.13.2 Plan and Implement Process-Improvement Activities
In diesem Teilgebiet werden die Verbesserungen geplant und umgesetzt. Dabei spielen im
CMMI® die Anpassung der den Projekten zur Verfügung gestellten Hilfsmittel und die Einbringung
der Erfahrungen aus der Einführung eine wichtige Rolle.
3.13.2.1 Establish Process Action Plans
Diese Praktik fordert die Entwicklung von Strategien für die Umsetzung und eine detaillierte
Planung der Umsetzung. Die Dokumentation dieser Schritte wird mit allen Betroffenen abgestimmt
und wenn nötig überprüft.
Die Strategien findet man im V-Modell XT in den Themen Realisierungskonzept und Pilotierungskonzept
des Verbesserungskonzeptes. Da für die Einführung von Verbesserung ein eigenes
Projekt existiert, wird in dessen Produkt Projektplan die detaillierte Planung aufgezeichnet und
abgestimmt. Die Prüfung erfolgt genauso im Rahmen der normalen Projekttätigkeiten.
3.13.2.2 Implement Process Action Plans
In dieser Praktik werden die neuen Prozesse und dazugehörige Methoden und Werkzeuge umgesetzt,
aber noch nicht eingeführt. Dabei sind die bekannten Vorgehensweisen des Projektmanagements
durchzuführen, also zum Beispiel Verifikation oder Fortschrittsverfolgung. Ein
wichtiger Aspekt ist die Planung der Pilotierung.
Im V-Modell XT ist dafür das Verbesserungskonzept zuständig. Es erzeugt das Organisationsspezifische
Vorgehensmodell. Da das V-Modell XT wie schon erwähnt ein eigenes Projekt für
die Weiterentwicklung der Prozesse hat, werden die schon besprochenen Methoden eingesetzt.
Somit wird das im Thema Pilotierungskonzept erstellte Vorgehen in einem Projektplan geplant.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 58 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.13.2.3 Deploy Organizational Process Assets
Nach der Pilotierung der neuen Prozesse und ihrer unterstützenden Methoden und Werkzeuge,
wird in dieser Praktik die Breiteneinführung der Verbesserungen geplant, durchgeführt und dokumentiert.
Dies erfolgt im V-Modell XT durch die Aktivität „Organisationsspezifisches Vorgehensmodell
erstellen, einführen und pflegen“. Die Planung übernimmt der Projektplan des Verbesserungsprojektes.
3.13.2.4 Incorporate Process-Related Experiences into the Organizational
Process Assets
Diese Aktivität fordert, dass Erfahrungen, Messdaten und Feedback aus der Entwicklung und
Einführung der Prozessverbesserungen allen Projekten zur Verfügung gestellt werden. Weiterhin
wird eine nächste Phase der Verbesserung begonnen, indem die Prozesse, Methoden und Werkzeuge
überprüft und dadurch weiteres Verbesserungspotential ermittelt wird.
Die Gewinnung und Aufzeichnung der Erfahrungen der Prozessverbesserung wird im
V-Modell XT automatisch durch das Thema Projekterfahrungen des Projekttagebuchs in die Erfahrungsdatenbasis
eingearbeitet. Dazu gehört beispielsweise auch das Feedback aus der Pilotierung.
3.14 Organizational Process Definition (Maturity Level 3)
Aufgabe der Organisationsweiten Prozessdefinition ist die Definition und Pflege benutzbarer organisationsweiter
Prozesselemente, die von den einzelnen Projekten angepasst und genutzt werden
können. Unter Prozesselementen versteht man neben den Beschreibungen der Prozesse zum
Beispiel unterstützende Tools, Dokumentenvorlagen und Schulungsmaterial. Außer den Prozessbeschreibungen
sind die Entwicklung von Lebenszyklusmodellen, einer Metrikdatenbank und
Kriterien und Richtlinien für das Tailoring nötig. Diese Informationen sowie weitere unterstützende
Elemente werden in einer Bibliothek (zum Beispiel Intranetplattform) zusammengefasst
und somit allen Nutzern zur Verfügung gestellt.
Das Prozessgebiet Organisationsweite Prozessdefinition wird durch den Vorgehensbaustein ORG
erfüllt, ergänzt durch die Produktdurchführungsstrategien, der V-Modell-Referenz Tailoring und
dem Kapitel über Entscheidungspunkte. Der Standardprozess, der Metrikkatalog und die Hilfsmittel
für die Organisation sind im Organisationsspezifischen Vorgehensmodell definiert. Verschiedene
Lebenszyklusmodelle für Projekte findet man in den Projektdurchführungsstrategien
des V-Modells. In der „V-Modell-Referenz Tailoring“ werden die Kriterien und Richtlinien für
das Tailoring beschrieben, die in einem Tailoring-Tool umgesetzt sind.
3.14.1 Establish Organizational Process Assets
Dieses Ziel sorgt für die Bereitstellung aller Informationen, Methoden und Werkzeuge, die für
die Anwendung der von der Organisation vorgeschriebenen Prozesse nötig sind.
3.14.1.1 Establish Standard Processes
Die Praktik stellt die Standardprozesse der Organisation zur Verfügung. Dabei sind Peer Reviews
für die Verifikation der Prozesse gefordert.
Im V-Modell XT wird in einem eigenen Projekt das Organisationsspezifische Vorgehensmodell
erarbeitet und eingeführt. Dazu gehören neben der Prozessbeschreibung auch Methoden und
Werkzeuge. Die geforderten Peer Reviews sind im V-Modell XT nicht zwingend.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 59 von 129

Damit ist die Praktik größtenteils erfüllt.
DAS V-MODELL XT AUS SICHT DES CMMI®
3.14.1.2 Establish Life-Cycle Model Descriptions
Ziel dieser Praktik ist die Erstellung von Lebenszyklusmodellen für Produkte und Projekte. Dabei
sind Peer Reviews für die Verifikation der Modelle gefordert.
Durch die Beschreibungen in den Kapiteln Entscheidungspunkte und Produktdurchführungsstrategien
des V-Modells XT sind die Modelle für Projektlebenszyklen festgelegt. Die Beschreibung
von Produktlebenszyklen fehlt und Peer Reviews ist nicht vorgeschrieben.
Diese Praktik ist nur teilweise erfüllt.
3.14.1.3 Establish Tailoring Criteria and Guidelines
Hier geht es um die Ermittlung eines Leitfadens und von Kriterien für das Tailoring. Dabei ist
Peer Reviews für die Verifikation des Leitfadens gefordert.
Im V-Modell XT ist das Tailoring in den Kapiteln „Grundlagen des V-Modells“, „Anleitung zur
Durchführung des Tailorings“ und „V-Modell-Referenz Tailoring“ beschrieben. Außerdem gibt
es ein Werkzeug für das Tailoring, das aufgrund der Kriterien den Standardprozess für das Projekt
anpasst. Peer Reviews ist nicht vorgeschrieben.
Die Praktik ist größtenteils erfüllt.
3.14.1.4 Establish the Organization’s Measurement Repository
Diese Praktik fordert die Erstellung, Bereitstellung und Überprüfung einer organisationsweiten
Erfahrungsdatenbank. Für die Verifikation ist Peer Reviews vorgeschrieben.
Im V-Modell XT gibt es dafür die Themen Metrikkatalog und Erfahrungsdatenbasis im Produkt
„Organisationsspezifisches Vorgehensmodell“. Die geforderten Peer Reviews werden nicht
zwingend verwendet.
Die Praktik ist größtenteils erfüllt.
3.14.1.5 Establish the Organization’s Process Asset Library
Hierbei geht es um die Einführung einer Plattform, die den Zugriff auf das Prozessmodell sowie
dessen Methoden und Werkzeuge ermöglicht.
Die Erstellung des Prozessmodells, der Methoden und Werkzeuge ist im V-Modell XT festgelegt,
die Veröffentlichung aller von den Projekten benötigten Informationen ist im Produkt „Organisationsspezifisches
Vorgehensmodell“ relativ kurz beschrieben. Im Thema Produktvorlagen ist die
Bereitstellung der Dokumentenvorlagen explizit genannt.
Die Praktik ist größtenteils erfüllt.
3.15 Organizational Training (Maturity Level 3)
Das Prozessgebiet „Organisationsweites Training“ befasst sich mit allen Belangen der Aus- und
Weiterbildung von Mitarbeitern, die allgemeine Fähigkeiten der Mitarbeiter betreffen, welche
projektübergreifend und zur Umsetzung der Ziele der Organisation benötigt werden. Als Vorbereitung
werden der Bedarf an organisationsweiter Ausbildung geklärt und die Ausbildungsbereiche
festgelegt, für welche die Organisation verantwortlich ist. Weiterhin muss ein taktischer
Trainingsplan erstellt und die nötigen Trainer- und Schulungsunterlagen der Organisation zur
Verfügung gestellt werden. Anhand des Plans werden die auszubildenden Mitarbeiter ausgewählt
und geschult. Die Ergebnisse der Ausbildung werden aufgezeichnet, sodass die Mitarbeiter ihrem
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 60 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Wissensstand entsprechend eingesetzt werden können. Um die Effektivität des Organisationsweiten
Trainings bewerten zu können, werden passende Messdaten erfasst und gespeichert.
Das Organisationsweite Training wird hauptsächlich in der Einführung und Pflege eines organisationsspezifischen
Vorgehensmodells umgesetzt. Das Schulungskonzept und die Schulungsunterlagen
werden geschaffen, um die Trainingsmöglichkeiten zur Verfügung zu stellen. Die
Schulung der Mitarbeiter entsprechend ihrer Rolle muss im Ausbildungsplan der Projekte festgelegt
werden. Die Messung der Effektivität der Schulungen und die Aufzeichnungen über den
Stand der Ausbildung aller Schulungsteilnehmer werden in der Erfahrungsdatenbasis aufgezeichnet.
Da Planung und Vorgehen sehr knapp beschrieben sind, wird nicht alles erfüllt.
3.15.1 Establish an Organizational Training Capability
Ziel ist eine Konzeption für rollenspezifische Schulungen, damit die Mitarbeiter der Organisation
gezielt für ihre Aufgaben in der Organisation geschult werden. Die dafür nötigen Fähigkeiten
und Hilfsmittel müssen geschaffen werden.
3.15.1.1 Establish the Strategic Training Needs
Auf Grundlage der Geschäftsziele und des rollenspezifischen Schulungsbedarfs wird der strategische
Trainingsbedarf ermittelt und gepflegt.
Im Organisationsspezifischen Vorgehensmodell wird zwar ein Schulungskonzept aufgestellt. Die
geforderte Abstimmung von Geschäftszielen mit dem Trainingsbedarf und die Ermittelung des
Bedarfs sind aber nicht vorhanden.
Die Praktik ist teilweise erfüllt.
3.15.1.2 Determine Which Training Needs Are the Responsibility of the
Organization
Hier geht es um die Abgrenzung zwischen den Schulungsaufgaben der Organisation und des Projektes.
Daraus ergeben sich die Schulungen, die Aufgabe der Organisation sind.
Das V-Modell XT erfüllt diese Forderung in den Themen Schulungskonzept und Schulungsunterlagen
nur unzureichend.
Deshalb ist die Praktik teilweise erfüllt.
3.15.1.3 Establish an Organizational Training Tactical Plan
Das CMMI® fordert in dieser Praktik die Erstellung und Pflege eines taktischen Trainingsplans.
Das Schulungskonzept des Organisationsspezifischen Vorgehensmodells erfüllt diese Aufgabe
nur ungenügend. Da der Projektplan des Verbesserungsprojekts, in dem die Schulungen während
der Pilotierung und Einführung geplant werden, nach Abschluss der Einführung endet, reicht
dies zu einer guten Erfüllung des Bereichs nicht aus.
Somit ist die Praktik teilweise erfüllt.
3.15.1.4 Establish Training Capability
Um der Organisation das notwendige Training zu geben, werden Trainingsunterlagen und Trainer
benötigt. Diese beiden Anforderungen können entweder von der Organisation umgesetzt oder
von externen Firmen erworben werden.
Das V-Modell XT erfüllt durch die Schulungsunterlagen einen Teil der Praktik. Da jedoch das
Thema zu kurz ausgeführt ist, kann es die Forderungen des CMMI® bei weitem nicht erfüllen.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 61 von 129

Es ergibt sich eine teilweise Erfüllung.
DAS V-MODELL XT AUS SICHT DES CMMI®
3.15.2 Provide Necessary Training
Das Ziel dieses Gebiets ist es, das nötige Training durchzuführen, dessen Effektivität zu messen
und Aufzeichnungen über den Erfolg für die Teilnehmer zu führen.
3.15.2.1 Deliver Training
Aufgrund der Vorgaben des taktischen Trainingsplans werden die einzelnen Mitarbeiter der Organisation
ausgesucht und geschult. Dabei wird auf die Planung des Trainings und der Ressourcen
geachtet und die Durchführung der Schulungsmaßnahmen verfolgt.
Das Thema ist teilweise im Schulungskonzept und in den Schulungsunterlagen des
V-Modells XT zu finden.
Die Praktik ist teilweise erfüllt.
3.15.2.2 Establish Training Records
In dieser Praktik sollen Aufzeichnungen über das organisationsweite Training erstellt und gepflegt
werden, sodass die Projekte die Kenntnisse des einzelnen Mitarbeiters abfragen können.
Es wird somit aufgezeichnet, wer welche Schulung mit welchem Erfolg absolviert hat.
Diese Informationen werden im V-Modell XT in der Erfahrungsdatenbasis abgelegt. Da der Inhalt
der aufzuzeichnenden Informationen nicht genau genug spezifiziert ist, ist eine vollständige
Umsetzung nicht gegeben.
Die Praktik ist größtenteils erfüllt.
3.15.2.3 Assess Training Effectiveness
Da die Organisation auch ihr Training verbessern soll, ist es nötig, die Effektivität der Schulungsmaßnahmen
zu überprüfen. Dazu wird in Projekten geprüft, ob die Fähigkeiten der Mitarbeiter
für die Durchführung ihrer Aufgaben ausreichen und ob die Schulungen die
Anforderungen der Mitarbeiter erfüllen. Nach jedem Kurs muss dessen Effektivität überprüft
werden.
Nur in der Erfahrungsdatenbasis sind Aufzeichnungen über die Schulungen zu finden. Das dort
geforderte Feedback reicht bei weitem nicht zur Erfüllung der Praktik aus.
Die Praktik ist deshalb nur teilweise erfüllt.
3.16 Integrated Project Management (Maturity Level 3)
Das Integrierte Projektmanagement bindet die Aktivitäten aller Projektmanagementthemen in die
Organisation ein. Als Vorbereitung wird aus dem organisationsweiten Prozess ein für das Projekt
passender Prozess abgeleitet und die organisationsweiten Messdaten genutzt um die Projektaktivitäten
zu planen. Die Integration aller Pläne zu einem integrierten Projektplan und die Nutzung
dieses Planes zum Verwalten und Steuern des Projektes stellen einen Teil der Umsetzung dar.
Zum anderen Teil gehören das Management der Beteiligung der Betroffenen, das Management
der Abhängigkeiten zwischen den Betroffenen und die Auflösung von Koordinationsproblemen
zwischen den Betroffenen. Da die Organisation aus den Aktivitäten der einzelnen Projekte lernen
soll, werden Messdaten und Erfahrungen der organisationsweiten Sammlung zur Verfügung gestellt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 62 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Das Prozessgebiet Integriertes Projektmanagement wird durch den Vorgehensbaustein Projektmanagement
und die Hilfe weniger anderer Produkte erfüllt. Die Anpassung des organisationsspezifischen
Prozesses an das Projekt erfolgt im Thema Projektspezifisches V-Modell. Unter
Nutzung der Erfahrungsdatenbasis können bessere Schätzungen durchgeführt werden, die dann
zu besseren Projektplänen führen. Die Integrierte Planung kann mit Hilfe von Projektstatusberichten,
Projekttagebuch, Projektfortschrittsentscheidungen und Metrikauswertungen erfolgreich
verwaltet werden. Durch die Führung des Projekttagebuchs und die Auswertung der Metriken,
können hilfreiche Erfahrungen der gesamten Organisation in der Erfahrungsdatenbasis zur Verfügung
gestellt werden. Die Einbindung und die Steuerung der Abhängigkeiten von allen Beteiligten
werden durch die Abstimmung von Projektplan und Projekthandbuch sichergestellt.
Koordinationsprobleme werden durch Abstimmung von Projektplan und Projekthandbuch gelöst.
3.16.1 Use the Project’s Defined Process
Durch die projektspezifische Anpassung der Standardprozesse der Organisation wird der für das
Projekt gültige Prozess entwickelt. Die weiteren von der Organisation zur Verfügung gestellten
Hilfen werden für das Projektmanagement genutzt.
3.16.1.1 Establish the Project’s Defined Process
Es erfolgt die Festlegung des für das Projekt festgelegten Prozesses. Außerdem werden der Lebenszyklus
des Projekts definiert, die Überprüfung des Projektprozesses gefordert und eine
Überarbeitung des Prozesses vorgesehen.
Im V-Modell XT wird der projektspezifische Prozess durch Tailoring des organisationsweit festgelegten
Prozesses erzeugt. Dabei spielt die Auswahl der Projektdurchführungsstrategie, die den
Projektlebenszyklus definiert, eine große Rolle. Der fertige Prozess des Projekts wird im Thema
„Projektspezifisches V-Modell“ des Projekthandbuchs aufgezeichnet. Die Überprüfung des Prozesses
erfolgt durch die Aktivität „Prozess prüfen“. Bei der Überprüfung gefundene Mängel am
Prozess werden durch das Problem- und Änderungsmanagement entfernt.
3.16.1.2 Use Organizational Process Assets for Planning Project Activities
Das CMMI® fordert die Nutzung der von der Organisation zur Verfügung gestellten Methoden,
Werkzeuge und der Erfahrungen abgelaufener Projekte für Projektplanung und Schätzungen.
Da im Projekthandbuch das projektspezifische Vorgehensmodell festgelegt wird und in Produkten
durch das V-Modell XT Methoden vorgeschlagen werden, sind die Forderungen für die Projektplanung
erfüllt. Die Nutzung der Erfahrungsdatenbasis für die Erstellung der Schätzungen ist
nicht explizit festgelegt. Es wird bei der kaufmännischen Projektkalkulation und der Schätzung
zwar auf die Nutzung von Erfahrungen hingewiesen, der konkrete Verweis auf die Erfahrungsdatenbasis
fehlt jedoch.
Somit ist die Praktik größtenteils erfüllt.
3.16.1.3 Integrate Plans
Durch Zusammenfügen der verschiedenen Pläne für die verschiedenen Prozessgebiete wie Risikomanagement
oder Prüfplan entsteht ein integrierter Plan. Dadurch sollen Überschneidungen
der verschiedenen Pläne und Abstimmungsprobleme zwischen den verschiedenen Beteiligten
vermieden werden. Unter anderem wird die Integration der Planung der Peer Reviews gefordert.
Im V-Modell XT gibt es von Anfang an das Thema Integrierte Planung, das alle Planungsthemen
zusammenfasst. Auch die Aktivitäten und Produkte der Prüfungen sind im integrierten Plan enthalten,
sodass die nicht vorgeschriebenen Peer Reviews nur einen geringen Einfluss haben.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 63 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.16.1.4 Manage the Project Using the Integrated Plans
Diese Praktik nutzt die integrierten Pläne und die projektspezifischen Prozesse um das Projekt zu
„managen“. Darin ist die Implementierung der im Projekt definierten Prozesse, die regelmäßige
Überprüfung der Angemessenheit der Umgebung und die regelmäßige Überprüfung der Projektperformanz
enthalten.
Diese verschiedenen Forderungen sind im V-Modell XT über die folgenden Aktivitäten, Themen
und Produkte verteilt:
• Projektstatusbericht erstellen; Projektstatusbericht
• Projekttagebuch führen; Projekttagebuch
• Projektfortschrittsentscheidung herbeiführen; Projektfortschrittsentscheidung
• Messdaten erfassen; Messdaten
• Metriken berechnen und auswerten; Metrikauswertung
• Erfahrungsdatenbasis
3.16.1.5 Contribute to the Organizational Process Assets
Damit andere Projekte die Erfahrungen, Messdaten und Dokumentation des Projekts nutzen
können, sind diese Informationen in die organisationsweite Erfahrungsdatenbank einzuarbeiten.
Dazu können auch Verbesserungsvorschläge bezüglich der von der Organisation bereitgestellten
Prozesse, Methoden und Werkzeuge gehören.
Im V-Modell XT werden aus dem Projektabschlussbericht, den Metrikauswertungen und den
Projekterfahrungen die zweckmäßigen Informationen in die organisationsweite Erfahrungsdatenbasis
eingearbeitet.
3.16.2 Coordinate and Collaborate with Relevant Stakeholders
Die Koordination und Zusammenarbeit zwischen dem Projekt und allen relevanten Betroffenen
wird in diesem Abschnitt abgewickelt.
3.16.2.1 Manage Stakeholder Involvement
Es wird die Beteiligung aller „gemanagt“, die relevant am Projekt beteiligt sind. Dazu werden
Terminpläne und Agenden für gemeinsame Aktivitäten abgestimmt, die Anforderungen an Arbeitsprodukte
für andere Projekte verifiziert und Probleme bei Anforderungen, Architektur und
Design aufgelöst.
Die geforderten Aktivitäten sind im V-Modell XT vor allem durch das Rollenkonzept und die
Trennung von Auftraggeber- und Auftragnehmerprojekt erfüllt. Diese Trennung sorgt zugleich
für eine regelmäßige und ausdrückliche Kommunikation zwischen den Vertragspartnern. Bei Erstellung
von Projekthandbuch und Projektplan wird extra in den Teilaktivitäten „Projekthandbuch
mit allen Beteiligten abstimmen“ und „Projektplan mit allen Beteiligten abstimmen“ die
Koordination erzwungen. Der Auftraggeber kann auch durch das Thema „Mitwirkungen und
Beistellungen des Auftraggebers“ im Projekthandbuch festlegen, wie er am Auftragnehmerprojekt
mitwirkt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 64 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.16.2.2 Manage Dependencies
Durch die Zusammenarbeit der relevanten Betroffenen werden kritische Abhängigkeiten identifiziert,
verhandelt und verfolgt. Dazu gehört unter anderem, dass die Beziehungen zwischen den in
die Planung übernommenen zu den vorgegebenen Terminen gesondert betrachtet werden.
Abhängigkeiten werden im V-Modell XT nicht explizit angesprochen, sondern liegen in der
baumförmigen Produktstruktur und den Produktabhängigkeiten. Somit sind sehr viele Abhängigkeiten
vorgegeben, die im normalen Rahmen des Projektmanagements bearbeitet werden müssen.
Kritische Abhängigkeiten fallen dabei in den Aufgabenbereich des Risikomanagements. In
der Aktivität „Risiken und Maßnahmen identifizieren“ wird beispielsweise ausdrücklich auf Abhängigkeiten
von Unterauftragnehmern geachtet. Das Rollenkonzept sorgt für klare Verantwortlichkeiten
zwischen den Vertragspartnern.
3.16.2.3 Resolve Coordination Issues
Offen gebliebene Punkte werden zwischen den relevanten Beteiligten bereinigt. Falls dies nicht
möglich ist, werden sie eskaliert. In beiden Fällen ist eine Verfolgung der Probleme bis zur erfolgreichen
Lösung nötig.
Zu diesem Thema gibt es im Thema „Organisation und Vorgaben für das Projektmanagement“
des Projekthandbuchs einen eigenen Teil über Konfliktmanagement. Die oberste Eskalationsinstanz
wird durch die Rolle Lenkungsausschuss gebildet. Derartige Probleme sind auch im Rahmen
des Problem- und Änderungsmanagements durch die Abarbeitung einer Problemmeldung zu
lösen.
3.17 Risk Management (Maturity Level 3)
Die Aufgabe des Risikomanagements ist die Erkennung von potentiellen Problemen bevor sie
auftreten. Vorbereitend werden die Risikoquellen ermittelt und Risikoklassen eingeteilt. Passende
Kenngrößen für Analyse, Einteilung und Aufwand der Risiken sind genauso notwendig wie
eine Strategie für die Behandlung der Risiken. Die identifizierten Risiken, ihre Eintrittsbedingungen
und Folgen werden regelmäßig ermittelt, aufgezeichnet und ausgewertet. Daraus entsteht
eine Liste von Risiken, die nach Risikoklassen und Prioritäten sortiert ist. Für die essentiellen
Risiken sind mit Hilfe der festgelegten Strategie Maßnahmen zu bestimmen und umzusetzen, die
das Eintreten dieser Risiken verhindern oder die Konsequenzen eindämmen.
Das Risikomanagement wird im V-Modell XT durch die Produktgruppe Planung und Steuerung
realisiert. Die Vorbereitung hat als Ergebnis einen Teil der identifizierten Risiken und das Thema
„Organisation und Vorgaben zum Risikomanagement“. In den Identifizierten Risiken ist die Ermittlung
und Analyse der Risiken aufgezeichnet. Die Planung und Umsetzung von Korrekturmaßnahmen
wird durch den Maßnahmenplan unterstützt.
3.17.1 Prepare for Risk Management
Zur Vorbereitung des Risikomanagements gehören die Definition von Risikoquellen, Risikoklassen,
Risikoparametern und einer Strategie für das Risikomanagement.
3.17.1.1 Determine Risk Sources and Categories
Zu allererst werden Risikoquellen ermittelt und Risikoklassen eingeteilt.
Im Thema „Organisation und Vorgaben zum Risikomanagement“ des Projekthandbuchs und in
der Teilaktivität „Risiken und Maßnahmen identifizieren“ sind diese Informationen im
V-Modell XT zu finden.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 65 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.17.1.2 Define Risk Parameters
Die hier geforderte Festlegung von Parametern beinhaltet die Definition von Kriterien für die
Beurteilung von Risikowahrscheinlichkeiten und von Schwierigkeitsgraden. Weiterhin werden
für jede Risikoklasse die Grenzwerte festgelegt.
Das V-Modell XT definiert diese Parameter im Thema „Organisation und Vorgaben zum Risikomanagement“.
3.17.1.3 Establish a Risk Management Strategy
Die Praktik erstellt eine Strategie für das Risikomanagement, die zum Beispiel die Methoden und
Werkzeuge festlegt oder die Intervalle der Überwachung definiert.
Die Umsetzung erfolgt im Thema „Organisation und Vorgaben zum Risikomanagement“.
3.17.2 Identify and Analyze Risks
Ziel ist die Ermittlung und Auswertung der Risiken.
3.17.2.1 Identify Risks
Bei der Ermittlung der Risiken ist es nicht nur wichtig, diese aufzuzeichnen, sondern auch die
Vorbedingungen, Konsequenzen und Betroffenen zu bestimmen und zu dokumentieren.
Das V-Modell XT generiert durch die Teilaktivität „Risiken und Maßnahmen identifizieren“ das
Thema „Identifizierte Risiken“ in der Risikoliste. Darin sind alle benötigten Informationen außer
den Betroffenen explizit zu belegen. Da durch das Rollenkonzept jedem Produkt Mitwirkende
und ein Verantwortlicher zugeordnet sind, können normalerweise die relevanten Betroffenen
leicht ermittelt werden. Somit kann man die Praktik als voll erfüllt ansehen.
3.17.2.2 Evaluate, Categorize and Prioritize Risks
In dieser Praktik werden die ermittelten Risiken anhand der in der Vorbereitungsphase festgelegten
Parameter bewertet und den Risikoklassen zugeordnet. Anschließend wird die Priorität aller
gefundenen Risiken ermittelt und alle gewonnenen Ergebnisse dokumentiert.
In der Teilaktivität „Risiken und Maßnahmen identifizieren“ werden die Risiken nicht nur identifiziert
sondern auch bewertet. Die geforderten Informationen werden in der Risikoliste aufgezeichnet.
3.17.3 Mitigate Risks
Nach der Ermittlung und Bewertung der Risiken ist es nötig, für die Risiken passende Maßnahmen
zu entwerfen und umzusetzen, die das jeweilige Risiko entschärfen. Falls dies nicht möglich
ist, sind Maßnahmen zur Milderung der Risikofolgen nötig.
3.17.3.1 Develop Risk Mitigation Plans
Ziel ist die Erstellung von Plänen, welche die Risiken entschärfen. Dazu werden Grenzwerte
festgelegt, ab denen die Pläne umgesetzt werden sollen. Für kritische Risiken sind Notfallpläne
zu entwerfen, die bei Eintritt umgesetzt werden können. Weiterhin werden die Verantwortlichen
und das Kosten-Nutzen-Verhältnis ermittelt.
Die Umsetzung erfolgt im V-Modell XT durch die Teilaktivität „Risiken und Maßnahmen identifizieren“.
Es wird der Maßnahmenplan erzeugt, der im Produkt Risikoliste zu finden ist.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 66 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.17.3.2 Implement Risk Mitigation Plans
Die Umsetzung der Pläne zur Minimierung der Risiken beinhaltet die regelmäßige Überwachung
des Status der Risiken. Falls Risiken die festgelegten Grenzwerte überschreiten, werden die entworfenen
Pläne umgesetzt.
In der Teilaktivität „Risiken und Maßnahmen überwachen“ werden diese Forderungen durchgeführt.
Die Ergebnisse gehen wieder in die Risikoliste ein.
3.18 Decision Analysis and Resolution (Maturity Level 3)
Entscheidungen sollen im CMMI® durch eine konsequente Vorgehensweise getroffen und danach
umgesetzt werden. Die Entscheidungsanalyse und -findung unterstützt alle anderen Prozessgebiete
beim Treffen von wichtigen Entscheidungen, indem durch einen formalen Prozess
die Alternativen gegen ihre Kriterien beurteilt werden. Einführend werden Richtlinien für die
Auswahl der zu analysierenden Entscheidungsprobleme aufgestellt und die Entscheidungskriterien
nach Prioritäten sortiert. Nach dem Ermitteln der verschiedenen Alternativen werden sorgfältig
die Evaluierungsmethoden ausgewählt. Anhand der vorher gewählten Kriterien und
Methoden werden nun die Alternativen gegeneinander abgewägt und eine Lösung gewählt.
Ein grundsätzliches Vorgehen zu Entscheidungsanalyse und -findung ist im V-Modell XT nicht
vorhanden. Das bedeutet nicht, dass es im V-Modell XT keine Entscheidungen gibt. Beispiele
sind die Projektfortschrittsentscheidung und die Make-or-Buy-Entscheidung. Dies sind jedoch
die einzigen explizit erwähnten Entscheidungen. Wesentlich ist, dass keine Vorgehensweise im
V-Modell XT festgelegt ist, welche die Schritte von der Analyse bis zur Wahl einer Lösung beschreibt.
Damit ist das Ziel „Evaluate Alternatives“ mit seinen Praktiken
• Establish Guidelines for Decision Analysis,
• Establish Evaluation Criteria,
• Identify Alternative Solutions,
• Select Evaluation Methods,
• Evaluate Alternatives,
• Select Solutions
nicht erfüllt.
3.19 Organizational Process Performance (Maturity Level 4)
Das Ziel des Prozessgebietes Performanz der organisationsweiten Prozesse ist es, die Leistung
der verwendeten Prozesse zu analysieren und die Ergebnisse zum Aufbau von Zielen, Baselines
und Vorhersagemodellen zu nutzen. Um dieses Ziel zu erreichen sind diejenigen Prozesse oder
Prozesselemente aus den Standardprozessen der Organisation auszuwählen, die statistisch analysiert
werden sollen. Weiterhin werden folgende Themen festgelegt und kontinuierlich überwacht,
verwaltet und gesteuert
• Metriken für die Messung der Prozessperformanz,
• Quantitative Ziele für Qualität und Prozessperformanz,
• Baselines für Prozessperformanz,
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 67 von 129

• Modelle für die Prozessperformanz.
DAS V-MODELL XT AUS SICHT DES CMMI®
Das V-Modell XT macht an dieser Stelle keine Vorgaben, da es sich auf Projekte beschränkt. Die
Ziele und Praktiken dieses Prozessgebietes werden aber in der Organisation definiert, realisiert
und somit die Basis für die organisationsweite Prozessverbesserung gelegt. Daher ist das Ziel
„Establish Performance Baselines and Models“ mit seinen Praktiken
• Select Processes,
• Establish Process Performance Measures,
• Establish Quality and Process Performance Objectives,
• Establish Process Performance Baselines,
• Establish Process Performance Models
nicht erfüllt.
3.20 Quantitative Project Management (Maturity Level 4)
Das Quantitative Projektmanagement dient der Einhaltung der Ziele des Projektes bezüglich
Qualität und Prozessperformanz. Das eine Teilgebiet umfasst das quantitative Management des
Projekts. Dazu stellt man Ziele für die Qualität und die Prozessperformanz des Projekts auf und
leitet aufgrund von historischen Daten die projektspezifischen Prozesse von den organisationsweiten
ab. Aus dem dann definierten Prozess des Projekts wählt man die statistisch zu überwachenden
Teilprozesse aus. Diese werden über die Laufzeit des Projektes überwacht, um das
Erreichen der festgelegten Ziele zu erreichen. Das andere Teilgebiet befasst sich mit dem statistischen
Management der Teilprozesse. Hierzu gehört die Auswahl der analytischen Techniken, die
bei der statistischen Prozesskontrolle verwendet werden. Aus der Anwendung erhält man Informationen,
die die Variation der Teilprozesse verstehen lässt. Durch dieses Wissen ist es möglich,
die Performanz der ausgewählten Teilprozesse zu überwachen und nötigenfalls korrigierende
Maßnahmen zu definieren und auszuführen. Die gesammelten Informationen werden in die organisationsweite
Informationssammlung eingearbeitet, damit auch andere Projekte von den Erfahrungen
profitieren können.
Das V-Modell XT macht an dieser Stelle keine Vorgaben, da es sich auf Projekte beschränkt. Die
Ziele und Praktiken dieses Prozessgebietes sind aber organisationsweit angelegt. Daher ist das
Ziel „Quantitatively Manage the Project“ mit seinen Praktiken
• Establish the Project’s Objectives,
• Compose the Defined Process,
• Select the Subprocesses that Will Be Statistically Managed,
• Manage Project Performance
sowie das Ziel „Statistically Manage Subprocess Performance” mit seinen Praktiken
• Select Measures and Analytic Techniques,
• Apply Statistical Methods to Understand Variation,
• Monitor Performance of the Selected Subprocesses,
• Record Statistical Management Data
nicht erfüllt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 68 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.21 Organizational Innovation and Deployment (Maturity Level 5)
Das Prozessgebiet Organisationsweite Innovation und Verbreitung beschäftigt sich mit der systematischen
Auswahl und Einführung von innovativen Verbesserungen, sodass die Prozesse und
Technologien statistisch nachmessbar verbessert werden. Unterteilt ist das Prozessgebiet in die
Auswahl und die Einführung der Verbesserungen. Für die Auswahl ist es nötig, zahlreiche Verbesserungsvorschläge
zu sammeln und zu analysieren, um daraus dann die innovativsten und für
die Organisation nützlichsten Verbesserungen auszuwählen. Durch eine Pilotierung der Verbesserungen
gewinnt die Organisation die nötigen Informationen, um die umzusetzenden Verbesserungen
auszuwählen. Die folgende Breiteneinführung der Verbesserungen wird geplant und die
Durchführung überwacht. Da eine Voraussetzung war, dass die Verbesserungen quantitativ
merkbar sein sollen, werden die Effekte der Verbesserungen statistisch gemessen und alle gewonnenen
Informationen in der organisationsweiten Bibliothek abgelegt.
Das V-Modell XT macht an dieser Stelle keine Vorgaben, da es sich auf Projekte beschränkt. Die
Ziele und Praktiken dieses Prozessgebietes sind aber organisationsweit angelegt. Daher ist das
Ziel „Select Improvements“ mit seinen Praktiken
• Collect and Analyze Improvement Proposals,
• Identify and Analyze Innovations,
• Pilot Improvements,
• Select Improvements for Deployment
sowie das Ziel „Deploy Improvements“ mit seinen Praktiken
• Plan the Deployment,
• Manage the Deployment,
• Measure Improvement Effects
nicht erfüllt.
3.22 Causal Analysis and Resolution (Maturity Level 5)
Die Ursachenanalyse und Problemlösung dient der systematischen Erkennung und Behebung der
Ursachen von Fehlern in allen Projekten der Organisation. Das Prozessgebiet ist zweigeteilt in
Fehleranalyse und Fehlerbehebung. Um die Ursache der Fehler zu erkennen, werden bestimmte
Fehler für die weitere Analyse ausgewählt. Durch die folgende statistische/quantitative Analyse
der Fehler werden die Ursachen ermittelt und dann Vorschläge für korrigierende Maßnahmen
entwickelt, die das künftige Auftreten dieser Fehler verhindern. Für die Behebung der Fehler ist
es nicht nur wichtig, die korrigierenden Maßnahmen umzusetzen, sondern auch die Erfolge der
Änderungen durch statistische Auswertungen zu evaluieren. Die gewonnenen Informationen aus
Fehleranalyse und Fehlerbehebung werden der Organisation zur Nutzung zur Verfügung gestellt.
Das V-Modell XT macht an dieser Stelle keine Vorgaben, da es sich auf Projekte beschränkt. Die
Ziele und Praktiken dieses Prozessgebietes sind aber organisationsweit angelegt. Daher ist das
Ziel „Determine Causes of Defects“ mit seinen Praktiken
• Select Defect Data for Analysis,
• Analyze Causes
sowie das Ziel „Address Causes of Defects” mit seinen Praktiken:
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 69 von 129

• Implement the Action Proposals
• Evaluate the Effect of Changes
• Record Data
nicht erfüllt.
DAS V-MODELL XT AUS SICHT DES CMMI®
3.23 Generic Goals
Die generischen Ziele dienen wie in Kapitel 2.2.2.3 beschrieben der Institutionalisierung einiger
Aufgaben. Sie sind auf alle Prozessgebiete von Reifegrad 2 und Reifegrad 3 anzuwenden. Das
V-Modell XT erfüllt durch seine grundlegenden Mechanismen alle generischen Praktiken und
damit auch die beiden generischen Ziele für alle vorher angeführten Prozessgebiete. Deshalb
wurden sie nicht in jedem Prozessgebiet einzeln betrachtet, sondern werden an dieser Stelle zusammenfassend
diskutiert.
3.23.1 Institutionalize a Managed Process (Generic Goal 2)
Aufgabe des generischen Ziels „Institutionalize a Managed Process“ ist es, dafür zu sorgen, dass
Projekte vernünftig geplant und durchgeführt werden, die benötigten Ressourcen zur Verfügung
stehen, Mitarbeiter entsprechend ihrer Rolle geschult sind und dass die Projekte entsprechend der
Prozessbeschreibungen überwacht und gesteuert werden. Das generische Ziel „Institutionalize a
Managed Process“ ist im V-Modell XT für die behandelten Prozessgebiete komplett abgedeckt.
3.23.1.1 Establish an Organizational Policy
Das CMMI® verlangt die Schaffung und Durchsetzung einer organisationsweiten Absicht für
das Planen und Durchführen der Prozesse.
Da jedes Projekt, das das V-Modell XT nutzt, seine projektspezifischen Prozesse vom „Organisationsspezifischen
Vorgehensmodell“ ableitet, ist diese Forderung erfüllt.
3.23.1.2 Plan the Process
Es wird für jedes Prozessgebiet eine Prozessdefinition und eine Planung verlangt.
Im V-Modell XT sind alle Prozesse von der Organisation vorgegeben und werden projektspezifisch
angepasst. Da alle Aktivitäten und Produkte im Projektplan geplant werden, ist die Praktik
erfüllt.
3.23.1.3 Provide Resources
Die für die Ausführung des Prozesses, die Entwicklung der Arbeitsergebnisse und die Bereitstellung
der Dienstleistungen nötigen personellen und materiellen Ressourcen müssen zur Verfügung
gestellt werden.
Da im Thema „integrierte Planung“ des Projektplans alle Ressourcen eingeplant werden, stehen
sie später zur Verfügung.
3.23.1.4 Assign Responsibility
Die Zuordnung von Verantwortlichkeiten und Rollen bei der Durchführung des Projekts ist erforderlich.
Da im V-Modell XT jeder Aktivität und jedem Produkt automatisch durch das Rollenkonzept ein
Verantwortlicher und Mitwirkende zugewiesen werden, ist die Praktik voll erfüllt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 70 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
3.23.1.5 Train People
Es werden die vorhandenen Kenntnisse hinterfragt und den Mitarbeitern die für die Nutzung
und/oder Unterstützung des Prozesses benötigte Ausbildung zur Verfügung gestellt.
Im Projektplan wird für alle Mitarbeiter der Schulungsbedarf ermittelt und ein Ausbildungsplan
erstellt, der alle Schulungsmaßnahmen des Projekts enthält. Dabei werden alle Fähigkeiten betrachtet,
die für den erfolgreichen Abschluss des Projekts nötig sind.
3.23.1.6 Manage Configurations
Diese Praktik soll sicherstellen, dass für alle Arbeitsergebnisse des Prozesses angemessenes Konfigurationsmanagement
angewendet wird.
Im V-Modell XT stehen prinzipiell alle Arbeitsergebnisse unter Konfigurationsmanagement. Im
Projekthandbuch und QS-Handbuch sind die Ergebnisse abzuwählen, die nicht mit den Methoden
des Konfigurationsmanagements verwaltet werden sollen. Durch das Problem- und Änderungsmanagement
wird die Integrität der Konfigurationen erhalten.
3.23.1.7 Identify and Involve Relevant Stakeholders
Während der gesamten Laufzeit müssen alle relevanten Betroffenen ermittelt und einbezogen
werden.
Eine explizite Identifikation und Planung der Mitwirkung wichtiger Beteiligter ist im
V-Modell XT nicht vorgesehen. Dies liegt daran, dass alle wichtigen Betroffenen durch das Rollenmodell
erfasst werden. Somit sind für jede Aktivität und jedes Produkt alle Beteiligten definiert.
Durch entsprechende organisatorische Festlegungen im Projekthandbuch und die
Zuweisung der Ressourcen im Projektplan wird die Einbeziehung verdeutlicht.
3.23.1.8 Monitor and Control the Process
Durch Überwachung und Steuerung der Prozessdurchführung gegen einen Plan werden Abweichungen
erkannt. Nötige korrigierende Maßnahmen sind daraufhin einzuleiten. Wichtige Unterstützung
bringt dabei die Erfassung und Auswertung von Messdaten.
Durch Projektstatusberichte wird im V-Modell XT regelmäßig der Projektfortschritt überwacht.
Im Thema Planungsabweichungen sind alle Abweichungen aufgezeichnet und im Thema „Planung
für den nächsten Berichtszeitraum“ werden Änderungen der Planung festgelegt. Die Metrikauswertungen
dienen zur Steuerung des Projektes im Rahmen des Soll/Ist-Abgleichs. Durch
den Kaufmännischen Projektstatusbericht wird die aktuelle Situation der Kosten überwacht.
3.23.1.9 Objectively Evaluate Adherence
Diese Aktivität soll die Einhaltung der Prozesse objektiv bewerten und Nichtbefolgungen aufzeigen.
Im QS-Handbuch werden die zu prüfenden Prozesse festgelegt und durch die Aktivität „Prozess
prüfen“ die Einhaltung geprüft. Im daraus entstehenden Produkt „Prüfprotokoll Prozess“ werden
mögliche Abweichungen und Lösungsvorschläge dokumentiert.
3.23.1.10 Review Status with Higher Level Management
Da das höhere Management eine Einsicht in den Status und die Ergebnisse der Prozess haben
möchte, ist eine gemeinsame Überprüfung der Aktivitäten, des Zustandes und der Ergebnisse gefordert.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 71 von 129

DAS V-MODELL XT AUS SICHT DES CMMI®
Durch die Projektdurchführungsstrategie des V-Modells XT sind Entscheidungspunkte festgelegt,
an denen das projektübergeordnete Management durch die Aktivität „Projektfortschrittsentscheidung
herbeiführen“ in Abstimmung mit dem Projekt über den Fortschritt des Projekts
entscheidet. Dabei ist es Aufgabe des Projektleiters, dem Management die für die Entscheidung
nötigen Informationen zur Verfügung zu stellen.
3.23.2 Institutionalize a Defined Process (Generic Goal 3)
Aufgabe des generischen Ziels „Institutionalize a Defined Process“ ist es dafür zu sorgen, dass
projektspezifische Prozesse von einem organisationsweiten Prozess entsprechend der Richtlinien
des Tailorings abgeleitet werden. Die Prozessbeschreibungen müssen gepflegt und es müssen unter
anderem Erfahrungen, Messdaten und Verbesserungsvorschläge der organisationsweiten Prozessbibliothek
zur Verfügung gestellt werden. Das generische Ziel „Institutionalize a Defined
Process“ ist im V-Modell XT für die behandelten Prozessgebiete abgedeckt.
3.23.2.1 Establish a Defined Process
Das CMMI® fordert den Einsatz eines genau definierten Prozesses. Dieser wird unter Befolgung
der Tailoring-Richtlinien vom organisationsweiten Prozess abgeleitet und über die gesamte Projektlaufzeit
gepflegt. Hierbei ist wichtig, dass der Prozess, das Vorgehen bei der Ableitung und
alle Abweichungen vom Standardprozess dokumentiert sind.
Im Thema „Projektspezifisches V-Modell“ des Projekthandbuchs ist der Prozess des Projekts dokumentiert,
im Thema „Abweichungen vom V-Modell“ sind die Abweichungen gegenüber dem
organisationsweiten Standardprozess belegt.
3.23.2.2 Collect Improvement Information
Ziel ist es, den organisationsweit gültigen Prozess leichter anwendbar zu machen und ihn zu
verbessern. Dies soll durch die Sammlung und Nutzung von Informationen gelingen, die aus der
aktuellen Anwendung entstehen.
Im V-Modell XT werden durch das Produkt Projekterfahrungen ebendiese aufgezeichnet und in
die Erfahrungsdatenbasis eingearbeitet.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 72 von 129

4 Bewertung des V-Modells XT
Ziel einer Bewertung im Rahmen eines Prozessassessments ist die Gewinnung einer objektiven
Information über den IST-Stand der Fähigkeiten einer Organisation. Dazu werden die Stärken
und Schwächen der Organisation systematisch analysiert. Aus den Schwächen leitet man Maßnahmen
ab, die zur Verbesserung der Fähigkeiten der Organisation dienen. Die gewonnenen
Maßnahmen werden bewertet und nach Prioritäten sortiert.
4.1 Methoden der Bewertung
Als Methode der Bewertung der Fähigkeiten einer Organisation können diverse standardisierte
und nicht standardisierte Verfahren dienen. Beispiele hierfür sind:
• SCAMPI® (Standard CMMI Appraisal Method for Process Improvement) [SCAMPI01]
• SPA (Siemens Process Assessment) [SPA04]
• SPICE-Assessment (Software Process Improvement Capability dEtermination, ISO
15504)
• EFQM-Bewertung (European Foundation of Quality Management)
• ISO 9001
Bei dieser Diplomarbeit wurde zum einen analog zum SCAMPI®-Verfahren bewertet, da dieses
Verfahren durch die in Kapitel 3 ermittelten Erfüllungsgrade der Praktiken leicht durchgeführt
werden kann.
Zum anderen wurde zusätzlich das Siemens Process Assessment durchgeführt, da es eine feinere
Bewertung der Prozessgebiete zulässt und sich gleichzeitig eng am CMMI® orientiert.
In einem Assessment werden normalerweise der definierte Prozess und das Leben in den Projekten
anhand von einem oder mehreren Projekten bewertet. Die Aufgabe der Diplomarbeit ist jedoch
auf die Bewertung des V-Modells XT als definierter Prozess beschränkt und betrachtet
keine reale Anwendung im Projekt.
4.1.1 Standard CMMI Appraisal Method for Process Improvement
(SCAMPI®)
Das SCAMPI® dient üblicherweise als Benchmarking-Verfahren um Organisationen miteinander
vergleichen zu können. Es bietet nur sekundär die Möglichkeit Verbesserungsmaßnahmen
herauszuarbeiten. Es hat für die Ermittlung des Reifegrads die im Folgenden erklärte rigorose
Auswertungsmethode.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 73 von 129

BEWERTUNG DES V-MODELLS XT
Nach der Ermittlung der Erfüllungsgrade der Praktiken (siehe Tabelle 5 in Kapitel 3) wird berechnet,
ob das jeweilige übergeordnete Ziel erreicht ist. Dazu dienen folgende zwei Regeln:
• Sind alle Praktiken größtenteils oder voll erfüllt, so ist das Ziel erreicht
• Ist nur eine der Praktiken teilweise oder nicht erfüllt, so ist das Ziel nicht erreicht
Beispielsweise wäre im Prozessgebiet Measurement and Analysis (Kapitel 3.5) das Ziel Provide
Measurement Results nicht erreicht, wenn die Praktik Store Data and Result teilweise erfüllt wäre,
auch wenn die restlichen Praktiken Collect Measurement Data, Analyze Measurement Data
und Communicate Results voll erfüllt wären..
Im nächsten Schritt wird beurteilt, welche Prozessgebiete erfüllt sind. Ein Prozessgebiet ist erfüllt,
wenn alle Ziele (generische und spezifische) des Prozessgebiets erreicht wurden. Als Beispiel
bleiben wir beim Prozessgebiet Measurement and Analysis. Falls wie oben beschrieben das
Ziel Provide Measurement Results nicht erreicht wird, so ist das gesamt Prozessgebiet nicht erfüllt.
Hierbei spielt das erreichen des zweiten Ziels Align Measurement and Analysis Activities
keine Rolle mehr.
Abschließend wird der Reifegrad nach dem gleichen Konzept ermittelt. Falls nur ein zur Erreichung
eines Reifegrades nötiges Prozessgebiet nicht erfüllt wird, so ist der Reifegrad nicht erreicht.
Für das Erreichen eines Reifegrades sind alle Prozessgebiete nötig, die zu ihm oder einem
niedrigeren Reifegrade gehören. Dies bedeutet beispielsweise für Reifegrad 3, dass man alle
Praktiken der den Reifegraden 2 und 3 zugeordneten Prozessgebiete (insgesamt achtzehn Stück)
mindestens größtenteils erfüllen muss. Am oben gewählten Beispiel des Prozessgebiets Measurement
and Analysis würde dies bedeuten, dass die Organisation das Prozessgebiet nicht erfüllt,
da eine Praktik nur teilweise erfüllt und somit ein Ziel nicht erreicht ist. Da dieses Prozessgebiet
zum Reifegrad 2 gehört, erreicht die Organisation diesen Reifegrad nicht und hat somit Reifegrad
1. Ein extremes Beispiel wäre, wenn eine Organisation alle Praktiken der Reifegrade 2 bis 5
mindestens größtenteils erfüllt bis auf eine Praktik im Prozessgebiet Projekt Planning, die sie
teilweise erfüllt. Dies würde nach den Regeln des SCAMPI® als Endergebnis einen Reifegrad 1
ergeben.
In dieser Diplomarbeit kann nur eine simulierte SCAMPI®-Bewertung auf die Prozess-
Dokumentation angewendet werden, da bei der Durchführung eines SCAMPI® das Leben im
Projekt beurteilt wird und bisher keine Organisationen existieren, die das zur Zeit noch in der
Entwicklung befindliche V-Modell XT anwenden. Deshalb wurden in Kapitel 3 alle Praktiken
des CMMI® aufgrund der in Tabelle 5 festgelegten Kriterien beurteilt und die Gründe für diese
Bewertungen bereits ausführlich erläutert. Anschließend wird auf dieser Basis in Kapitel 4.2.1
eine Bewertung der einzelnen Prozessgebiete durchgeführt, welche dann im Kapitel 4.3 zu einem
Endergebnis eines Reifegrades nach SCAMPI® verdichtet wird.
4.1.2 Siemens Process Assessment (SPA)
Das vom Fachzentrum CT SE 3 der Firma Siemens AG entwickelte Siemens Process Assessment
in Version 3.0 ist ähnlich dem SCAMPI® eine Methode um die Fähigkeiten einer Organisation
zu bewerten. Für die Durchführung des SPA wurde vom Fachzentrum CT SE 3 ein eigener Fragenkatalog,
das Siemens Process Assessment Questionaire [SPA04], mit 265 Fragen erstellt, der
sich an den Praktiken des CMMI® orientiert. Jede Frage des Katalogs lässt sich auf eine oder
mehrere Praktiken des CMMI® abbilden. Die Fragen sind, wie in Abbildung 13 zu erkennen,
ähnlich wie im CMMI® nach Prozessgebieten strukturiert. Das Siemens Process Assessment
Questionaire ist ein vertrauliches Dokument der Siemens AG. Daher kann der Wortlaut der Fragen
nicht wiedergegeben werden.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 74 von 129

Management Management im
im
Projekt
Projekt
Projektmanagement
Lieferantenmanagement
Qualitätssicherung
und Reviews
Konfigurations- und
Änderungsmanagement
Prozess
Prozess
Engineering
Engineering
Anforderungsdefinition
Produktlinienmanagement
Definition von
Leistungsmerkmalen und
Architektur
SW-Realisierung & Test
HW-Realisierung & Test
Komponenten-Re-Use
Produktintegration & -test
Abbildung 13: Kategorien und Prozessgebiete des SPA
BEWERTUNG DES V-MODELLS XT
Prozessmanagement
Prozessmanagement
Prozeßdefinition und
-pflege
Standardschulung
Organisationsweite
Prozessperformance
Quantitatives
Projektmanagement
Systematische
Ursachenanalyse und
Fehlervermeidung
Innovation & messbare
kontinuierliche
Prozessoptimierung
Jedes der Prozessgebiete des SPA ist einer der drei Kategorien Management im Projekt, Engineering
und Prozessmanagement zugeordnet. Die einzelnen Prozessgebiete sind wiederum in Themen
unterteilt, die aus mehreren Fragen bestehen. Die Auflistung aller Themen ist in Tabelle 6,
Tabelle 7 und Tabelle 8 zu erkennen. In diesen Tabellen sind in der linken Spalte alle Prozessgebiete
aufgelistet und in der rechten Spalte die dazugehörenden Themen. In der Mitte existiert für
jeden Reifegrad eine Spalte. Pro Thema wird hier aufgezeichnet, wie viele Fragen zu welcher
Reifegradstufe gestellt werden. Leere Zellen bedeuten, dass in der Reifegradstufe für dieses
Thema keine Fragen existieren.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 75 von 129

Prozessgebiet
Projektmanagement
Lieferantenmanagement
Qualitätssicherung
und
Reviews
Konfigurations- und
Änderungsmanagement
Zahl der Fragen pro
Reifegrad Thema
2 3 4 5
3 Institutionalisierung des Projektmanagements
4 2 Planen der Projektrahmenbedingungen
2 1 Schätzmethodik
4 Erstellen des Projektplans
2 1 Einbindung der Beteiligten
3 Messen und Analysieren im Projekt
6 1 Projektverfolgung
1 2 Risikomanagement
2 Institutionalisierung des Lieferantenmanagements
3 Make or Buy Vorgehen und Lieferantenauswahl
2 Fertigprodukte
3 Vertragsgestaltung bei Lieferanten
4 Management von Lieferanten
3 Bauelemente und Teile
2 Institutionalisierung der Qualitätssicherung
2 Prozess-Controlling
2 QS-Berichterstattung und Eskalation
1 7 Reviewmethodik und Reviewumfang
2
Institutionalisierung des Konfigurations- und
Änderungsmanagements
5 Objektverwaltung im Konfigurationsmanagement
3 Baselines und Freigabe
5 Fehler- und Änderungsmanagement
Tabelle 6: Themen in der Kategorie Management im Projekt
BEWERTUNG DES V-MODELLS XT
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 76 von 129

Prozessgebiet
Anforderungsdefinition
Produktlinienmanagement
Definition von
Leistungsmerkmalen
und
Architektur
Software
Realisierung & Test
Hardware
Realisierung & Test
Komponenten-
Re-Use
Produktintegration
und -tests
Zahl der Fragen pro
Reifegrad Thema
2 3 4 5
5
2 Institutionalisierung der Anforderungsdefinition
Tabelle 7: Themen in der Kategorie Engineering
BEWERTUNG DES V-MODELLS XT
2 Sammeln und Analyse von Markt/Kundeninformationen
6 Anforderungsdefinition für Serienprodukte
8 Anforderungsdefinition für kundenspezifische Lösungen
3 Institutionalisierung des Produktlinienmanagement
5 Produktlinienmanagement
2 Institutionalisierung Leistungsmerkmale und Architektur
3 Ermittlung und Analyse von Leistungsmerkmalen
5 Produktarchitektur
4 Identifikation und Analyse von SW/HW-Leistungsmerkmalen
Nachvollziehbarkeit und Verständnis der Anforderungen und
Leistungsmerkmale
4 Safety & Security
2 Patente
3 Institutionalisierung der SW Realisierung & Test
4 SW-Architektur
5 SW-Design und Codierung
3 SW Unit- und Integrationstest
2 SW Regressionstest
4 Institutionalisierung der HW Realisierung & Test
8 Architektur und Design von Schaltungen (und/oder ASICs)
3 Unit- und Integrationstest von Schaltungen (und/oder ASICs)
7
3
Architektur und Design von Mechanik
(und/oder Sonder-Einheiten)
Unit- und Integrationstest von Mechanik
(und/oder Sondereinheiten)
2 HW Regressionstest
3 Institutionalisierung des Komponenten-Re-Use
4 Komponenten-Re-Use
5 Institutionalisierung der Produkt Integration und -tests
3 Produktintegration und Verifikation
3 Produktvalidierung
2 Regressionstest
2 Auslieferung und Einsatzunterstützung
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 77 von 129

Prozessgebiet
Prozessdefinition
und -pflege
Standardschulung
OrganisationsweiteProzessperformance
Quantitatives
Projektmanagement
Systematische
Ursachenanalyse
und
Fehlervermeidung
Innovation und
messbare
kontinuierliche
Prozessoptimierung
Zahl der Fragen pro
Reifegrad Thema
2 3 4 5
Tabelle 8: Themen in der Kategorie Prozessmanagement
BEWERTUNG DES V-MODELLS XT
3 Institutionalisierung der Prozessdefinition und -pflege
3
Commitment für den Standard-Prozess und
Prozessverbesserung
5 Standardprozess und Tailoring
4 Organisationsweite Metrikdatenbank
4 Kontinuierliche Prozesspflege und -verbesserung
3 Institutionalisierung der Standardschulung
3 Bereitstellung von Standardschulungen
4 Ausführen der Standardschulungen
4
7
Institutionalisierung der organisationsweiten
Prozessperformance
Auswahl und Umfang von (Teil-) Prozessen zur statistischen
Prozesskontrolle
3 Abstimmung der Prozessfähigkeiten mit Organisationszielen
2 Institutionalisierung des quantitativen Projektmanagements
3 Vorgehen zur statistischen Analyse im Projekt
3 Quantitative Projektsteuerung
4
3
5
2
2
3
Institutionalisierung der systematischen Ursachenanalyse und
Fehlervermeidung
Systematische Ursachenanalyse und
Fehlervermeidung
Institutionalisierung der Innovation und der messbaren
kontinuierlichen Prozessoptimierung
Suche und Sichtung von Innovationen von Prozessen und
Prozesstechnologien
Suche und Sichtung von Innovationen von Produkten und
Produkttechnologien
Organisationsweite Einführung von Prozessoptimierungen und
Produktverbesserungen mit messbarem Erfolg
Wie man in Tabelle 6, Tabelle 7 und Tabelle 8 sieht, ist die Anzahl der Fragen in den Themen der
verschiedenen Prozessgebiete unterschiedlich. Jede dieser Fragen ist einem Reifegrad zugeordnet
und wird mit den in Tabelle 9 dargestellten Graden der Erfüllung bewertet. Falls eine Frage
nicht anwendbar ist, wird sie bei der Bewertung nicht betrachtet. Ein Beispiel hierfür ist die Anforderungsdefinition
für Serienprodukte, die nicht bewertet wurde, da der Fokus des
V-Modells XT kundenspezifische Lösungen sind. Da im SPA zwischen kundenspezifischer Entwicklung
und Markt-Entwicklung unterschieden wird, muss nur eines der beiden Themen Anforderungsdefinition
für kundenspezifische Lösungen oder Anforderungsdefinition für
Serienprodukte bewertet werden. Ebenso wären Fragen zur Hardwareentwicklung in einem Unternehmen,
das nur Software entwickelt, nicht anwendbar.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 78 von 129

Grad der Erfüllung
Tabelle 9: Erfüllungsgrade des SPA
BEWERTUNG DES V-MODELLS XT
In der Auswertung des SPA erhält man für jedes Thema einen prozentualen Erfüllungsgrad, indem
man jede einzelne Frage mit den in Tabelle 9 dargestellten Werten bewertet und daraus den
Durchschnitt bildet. Der Erfüllungsgrad des gesamten Prozessgebiets wird aus dem Durchschnitt
der Bewertung der einzelnen Fragen gewonnen. Zur Ermittlung des Reifegrads werden zusätzlich
die Schwächen eines niedrigeren Reifegrades durch die Anrechnung der Stärken des nächst
höheren Reifegrades etwas verringert. Der organisationsweite Reifegrad errechnet sich dann ähnlich
wie bei den Prozessgebieten.
Ein Unterschied zum SCAMPI® ist, dass das SPA die generischen Ziele und Praktiken nicht für
jedes Prozessgebiet einzeln behandelt, sondern durch einzelne, manchmal mehrere Fragen abfragt.
Dadurch vermeidet das SPA viele der im CMMI® vorhandenen Redundanzen. Der zweite
Unterschied ist die resultierende Beurteilung. Bei Durchführung eines SCAMPI® erhält man als
Ergebnis einen ganzzahligen Reifegrad zwischen eins und fünf. Die SPA-Bewertung ergibt im
Gegensatz dazu einen zwischen 1 und 5 liegenden Reifegrad, der in Schritten von 0,25 vergeben
wird. Bei der Bewertung der einzelnen Praktiken ist es beim SPA im Gegensatz zum SCAMPI®
nicht nötig, jede Praktik des CMMI® mindestens größtenteils zu erfüllen, um ein ganzes Prozessgebiet
zu erfüllen. Es ist beispielsweise möglich, eine einzelne Frage gar nicht zu erfüllen
und dennoch im Prozessgebiet den vollen Reifegrad zu erreichen, wenn die anderen Fragen einen
hohen Erfüllungsgrad haben.
Außerdem werden zu den im CMMI® behandelten Themen folgende zusätzliche Aspekte durch
die Fragen betrachtet:
• Safety & Security (4 Fragen auf Reifegrad 3)
• Patente (2 Fragen, auf Reifegrad 3)
Erläuterung
100 % voll erfüllt keine wesentlichen Schwächen
67 % größtenteils erfüllt richtiges Konzept, aber deutliche Schwächen
33 % teilweise erfüllt ungenügendes Konzept, aber erkennbarer Ansatz
0 % nicht erfüllt weniger als teilweise erfüllt
-- nicht anwendbar es kann auf die Frage nicht angewendet werden
• Komponenten-Reuse (7 Fragen, auf Reifegrad 4)
• Produktlinienmanagement (8 Fragen, auf Reifegrad 4)
Die Bewertung wurde ähnlich wie beim SCAMPI®-Verfahren durchgeführt. Die einzelnen Fragen
des SPA-Fragenkataloges wurden unter Zuhilfenahme der in Kapitel 3 gewonnenen Ergebnisse
beantwortet und die Antworten nochmals anhand der Prozessbeschreibung des
V-Modells XT überprüft. Da firmenvertrauliche Abbildungstabellen zwischen den SPA-Fragen
und den Praktiken des CMMI® existieren, wurde anschließend durch Verfolgung beider Richtungen
nochmals die Richtigkeit der Ergebnisse überprüft.
4.2 Auswertung der Ergebnisse
In dem folgenden Teil werden die Ergebnisse der zwei Bewertungsverfahren dargestellt und erläutert.
Bei den Schwächen sind nur größere Defizite aufgezählt, die nach dem SCAMPI®- bzw.
dem SPA-Verfahren ermittelt wurden. Es werden somit nur die Praktiken behandelt, die nicht
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 79 von 129

BEWERTUNG DES V-MODELLS XT
oder nur teilweise erfüllt sind. Weiteres Verbesserungspotential liegt also in den im Kapitel 3 als
größtenteils erfüllt bewerteten Praktiken.
Das Vorgehen und die Ergebnisse in den folgenden beiden Kapiteln sind wie folgt:
• Auswertung nach SCAMPI® (Kapitel 4.2.1)
o Bewertung der einzelnen Prozessgebiete (Abbildung 14),
o Aufschlüsselung der Prozessgebiete nach Zielen und Praktiken siehe Kapitel 3,
o Ermittlung der Schwächen in Reifegrad 2 und 3 (Tabelle 10 und Tabelle 11),
• SPA-Auswertung (Kapitel 4.2.2)
o Bewertung der einzelnen Prozessgebiete (Abbildung 15),
o Aufschlüsselung der Prozessgebiete nach Themen (3 Tabellen)
o Ermittlung der Schwächen in Reifegrad 2 und 3 (Tabelle 15 und Tabelle 16)
4.2.1 Auswertung nach SCAMPI®-Verfahren
Die Bewertung nach dem SCAMPI®-Verfahren ergibt wie in Kapitel 4.1.1 beschrieben für jedes
Prozessgebiet die Aussage, ob es erfüllt ist oder nicht (siehe auch die Übersicht in Tabelle 19 im
Anhang A.1). In Abbildung 14 ist für jedes Prozessgebiet die Erfüllung dargestellt.
Reifegrad
5
4
3
2
1
Requirements Management
Project Planning
Project Monitoring and Control
Supplier Agreement Management
Measurement and Analysis
Process and Product Quality Assurance
Configuration Management
Requirements Development
Technical Solution
Product Integration
Verification
Validation
Organizational Process Focus
Organizational Process Definition
Organizational Training
Integrated Project Management
Risk Management
Decision Analysis and Resolution
Organizational Process Performance
Quantitative Project Management
Organizational Innovation and Deployment
Causal Analysis and Resolution
Abbildung 14: Bewertung der Prozessgebiete nach SCAMPI®
nicht erfüllt
erfüllt
nicht zutreffend
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 80 von 129

BEWERTUNG DES V-MODELLS XT
An Prozessgebiete, die zum Erreichen von Reifegrad 2 erfüllt werden müssen, sind für das Erreichen
von Reifegrad 3 nochmals zusätzliche Anforderungen durch das Generische Ziel 3 gestellt.
Dadurch erstrecken sich in Abbildung 14 die für Reifegrad 2 zu erfüllenden ersten sieben Prozessgebiete
bis Reifegrad 3. Die gestrichelten Linien bedeuten, dass diese Prozessgebiete für den
jeweils höheren Reifegrad erforderlich sind, bei welchem der Balken beginnt.
Wie man aus Abbildung 14 sieht, sind zwei von sieben Prozessgebieten aus Reifegrad 2 und sieben
von elf Prozessgebieten aus Reifegrad 3 nicht erfüllt. Dies liegt an einzelnen Praktiken des
jeweiligen Prozessgebietes, die teilweise oder nicht erfüllt sind. Da die genauen Ursachen in Kapitel
3 beschrieben sind, werden die Schwächen bei den Themen des Reifegrads 2 (siehe Tabelle
10) und des Reifegrads 3 (siehe Tabelle 11) hier nur noch im Überblick dargestellt. Dabei steht in
der ersten Spalte eine Nummerierung, die aus den Buchstaben „a“ für SCAMPI® und „b“ für
SPA, aus dem betreffenden Reifegrad, einem Punkt und einer in der Reifegradstufe fortlaufenden
Nummer besteht. Somit ist jede Schwäche eindeutig nummeriert. Die Beschriftung a3.5 bedeutet
beispielsweise, dass das die fünfte durch das SCAMPI® gefundene Schwäche bei den Praktiken
des Reifegrads 3 ist. Die Spalten zwei bis vier spezifizieren das Prozessgebiet und die Praktik, in
der die Schwäche gefunden wurde. In der letzten Spalte ist in kurzen Worten die Schwäche beschrieben.
Die generischen Ziele aus Kapitel 3.23 sind beide erfüllt. Dies liegt daran, dass alle generischen
Praktiken in den grundlegenden Mechanismen des V-Modells XT verankert sind.
Bei Reifegrad 2 ist als Schwäche vor allem die bidirektionale Verfolgbarkeit der Anforderungen
zu sehen. Zwar ist das Anforderungstracing ausgehend vom Produkt „Anforderungen (Lastenheft)“
über die Spezifikationen und Architekturen bis auf die einzelnen Systemelemente gegeben,
es fehlt jedoch der Weg zurück.
Die zweite Schwäche in Reifgrad 2 bezieht sich auf das Commitment aller Beteiligten im Laufe
des Projektes. Dieses kann zwar in der Methodik des V-Modells XT vermutet werden, es ist jedoch
nicht explizit beschrieben und gefordert.
Nr Prozessgebiet Name der Praktik Schwächen Reifegrad 2
a2.1 Requirements
Management
a2.2
Project Monitoring
and Control
Maintain Bi-directional Traceability
of Requirements
Monitor Commitments
Bidirektionale Verfolgbarkeit der
Anforderungen
explizite Überwachung der
Verpflichtungen
Tabelle 10: Schwächen hinsichtlich Reifegrad 2 nach SCAMPI®-Verfahren
Die Defizite in den für Reifgrad 3 benötigten Prozessgebieten sind in Tabelle 11 aufgeführt. Im
besonderen Maße verbesserungsbedürftig sind hierbei die Prozessgebiete „Organisationsweites
Training“ und „Entscheidungsfindung und -analyse“, da in beiden nicht nur eine einzelne Praktik
sondern fast alle Praktiken der Verbesserung bedürfen. In den Prozessgebieten Requirements
Management, Technical Solution, Product Integration und Organizational Process Definition
sind jeweils nur an einzelnen Stellen Schwächen vorhanden. Das Prozessgebiet Verfication ist
ein Sonderfall. Hier wird vom CMMI® die Methode der Peer Reviews für die Durchführung der
Verifikation vorgeschrieben. Dies stellt eine Einschränkung dar, die das V-Modell XT nicht vornimmt.
Im V-Modell XT sind Methoden grundsätzlich aus der mitgelieferten Methodenreferenz
frei wählbar. Die Methode der Peer Reviews ist in der Methodenreferenz nur eine von mehreren
Methoden der Verifikation. Sie ist also nicht wie vom CMMI® gefordert vorgeschrieben, sondern
nur möglich.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 81 von 129

BEWERTUNG DES V-MODELLS XT
Vorschläge für Maßnahmen zur Beseitigung der Schwächen sind in Kapitel 4.4 beschrieben.
Nr Prozessgebiet Praktik Schwächen Reifegrad 3
a3.1 Requirements
Development
a3.2 Technical Solution
a3.3 Product Integration
a3.4 Product Integration
Elicit Needs
Select Product Component
Solutions
Confirm Readiness of Product
Components for Integration
Package and Deliver the Product
or Product Component
die Anforderungsermittlung ist nicht
proaktiv zwischen Anwender und
Auftragnehmer
Kriterien zur Auswahl der besten
Lösung
explizite Überprüfung der zu
integrierenden Elemente vor der
Integration
Verpackung des auszuliefernden
Systems
a3.5 Verification Prepare for Peer Reviews Peer Reviews nicht vorgeschrieben
a3.6 Verification Conduct Peer Reviews Peer Reviews nicht vorgeschrieben
a3.7 Verification Analyze Peer Review Data Peer Reviews nicht vorgeschrieben
a3.8 Organizational
Process Definition
a3.9 Organizational
Training
a3.10 Organizational
Training
a3.11 Organizational
Training
a3.12 Organizational
Training
a3.13 Organizational
Training
a3.14 Organizational
Training
a3.15
a3.16
a3.17
a3.18
a3.19
a3.20
Decision Analysis and
Resolution
Decision Analysis and
Resolution
Decision Analysis and
Resolution
Decision Analysis and
Resolution
Decision Analysis and
Resolution
Decision Analysis and
Resolution
Establish Life-Cycle Model
Descriptions
Establish the Strategic Training
needs
Determine Which Training Needs
Are the Responsibility of the
Organization
Establish an Organizational
Training Tactical Plan
- Produktlebenszyklen
- Peer Reviews nicht vorgeschrieben
nur geringe Elemente
nur geringe Elemente
nur geringe Elemente
Establish Training Capability nur geringe Elemente
Deliver Training nur geringe Elemente
Assess Training Effectiveness nur geringe Elemente
Establish Guidelines for Decision
Analysis
Tabelle 11: Schwächen hinsichtlich Reifegrad 3 nach SCAMPI®-Verfahren
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 82 von 129
fehlt
Establish Evaluation Criteria fehlt
Identify Alternative Solutions fehlt
Select Evaluation Methods fehlt
Evaluate Alternatives fehlt
Select Solutions fehlt

BEWERTUNG DES V-MODELLS XT
4.2.2 Auswertung nach SPA
Da die Bewertung nach SCAMPI® lediglich eine digitale Aussage über die Qualität des
V-Modells XT liefert, wird die SPA-Methode verwendet, um detailliertere Informationen zu erhalten.
Dazu sind in Anhang A.2 die ausführlichen Bewertungen der einzelnen Prozessgebiete
des SPA, die für die Reifegrad 2 und 3 relevant sind, in Abbildung 17 bis Abbildung 27 dargestellt.
In jeder der Übersichten sind die verschiedenen Themen des jeweiligen Prozessgebiets
aufgeführt und prozentual beurteilt. Eine Übersicht über die Bewertung der Prozessgebiete ist in
Abbildung 15 zu sehen.
5,0
4,5
4,0
3,5
3,0
2,5
2,0
1,5
1,0
Projektmanagement
Lieferantenmanagement
Qualitätssicherung und Reviews
Konfigurations- und Änderungsmanagement
Anforderungsdefinition
Produktlinienmanagement
Definition von Leistungsmerkmalen und Architektur
Software Realisierung & Test
Hardware Realisierung & Test
Komponenten-Re-Use
Produktintegration und -tests
Prozessdefinition und -pflege
Standardschulung
nicht erfüllt
erfüllt
nicht zutreffend
Organisationsweite Prozessperformance
Quantitatives Projektmanagement
Systematische Ursachenanalyse und Fehlervermeidung
Innovation und messbare kontinuierliche Prozessoptimierung
Abbildung 15: Bewertung der Prozessgebiete nach SPA
Auf der horizontalen Achse von Abbildung 15 sind alle Prozessgebiete des SPA aufgelistet. Vertikal
sind die Erfüllungsgrade der Prozessgebiete aufgetragen. Ein gelber Balken zeigt den Grad
der Erfüllung in Schritten von 0,25. Die möglicherweise an die gelben Balken nach oben anschließenden
roten Balken stellen das Verbesserungspotential in dem Prozessgebiet dar. Balken
können wie schon bei Abbildung 14 über die Reifegrade 2 und 3 dargestellt sein. Dies bedeutet,
dass in diesem Prozessgebiet Fragen zu Reifegrad 2 und zu Reifegrad 3 gestellt werden. Aus der
Abbildung wird nochmals deutlich, dass auf Reifegrad 4 und 5 beim V-Modell XT keine Inhalte
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 83 von 129

BEWERTUNG DES V-MODELLS XT
vorhanden sind. Dies ist auch verständlich, da hier die Aufgaben der Organisation im Prozess geregelt
werden, während das V-Modell XT sich auf Projekte beschränkt.
In Tabelle 12, Tabelle 13 und Tabelle 14 sind die Ergebnisse nach Prozessgebieten und Themen
aufgeschlüsselt. Für jedes Thema ist angegeben, wie die dazugehörenden Fragen bewertet wurden.
Aus dem Durchschnitt der Bewertung der Fragen ergibt sich die Bewertung des Themas.
Das Ergebnis des Prozessgebietes ergibt sich aus dem Durchschnitt aller Fragen, die in ihm enthalten
sind. Der Reifegrad eines Prozessgebietes wird anhand eines Algorithmus berechnet, der
den Reifegrad jeder Frage einbezieht. Das genaue Verfahren ist firmenvertraulich und kann daher
in dieser Diplomarbeit nicht veröffentlicht werden.
Prozessgebiet
Projektmanagement
Lieferantenmanagement
Qualitätssicherung
und
Reviews
Konfigurations-
und Änderungsmanagement
Thema
Institutionalisierung des Projektmanagements 3 100%
Planen der Projektrahmenbedingungen 3 3 83%
Schätzmethodik 1 2 89%
Erstellen des Projektplans 1 3 75%
Einbindung der Beteiligten 3 67%
Messen und Analysieren im Projekt 3 100%
Projektverfolgung 1 3 3 76%
Risikomanagement 3 100%
Institutionalisierung des Lieferantenmanagements 2 100%
Make or Buy Vorgehen und Lieferantenauswahl 1 2 78%
Fertigprodukte 2 100%
Vertragsgestaltung bei Lieferanten 3 100%
Management von Lieferanten 4 100%
Bauelemente und Teile 3 0%
Institutionalisierung der Qualitätssicherung 2 100%
Prozess-Controlling 2 100%
QS-Berichterstattung und Eskalation 1 2 83%
Reviewmethodik und Reviewumfang 1 6 96%
Institutionalisierung des Konfigurations- und
Änderungsmanagements
Zahl der Fragen
bewertet mit
Tabelle 12: Ergebnisse der Kategorie Management im Projekt
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 84 von 129
0%
33%
67%
100%
Ergebnis
Thema
2 100%
Objektverwaltung im Konfigurationsmanagement 5 100%
Baselines und Freigabe 3 100%
Fehler- und Änderungsmanagement 5 100%
Ergebnis
Prozessgebiet
84%
78%
95%
100%

Prozessgebiet Thema
Anforderungsdefinition
Produktlinienmanagement
Definition von
Leistungsmerkmalen
und
Architektur
Software
Realisierung &
Test
Hardware
Realisierung &
Test
Komponenten-
Re-Use
Produktintegration
und -tests
Tabelle 13: Ergebnisse der Kategorie Engineering
BEWERTUNG DES V-MODELLS XT
Institutionalisierung der Anforderungsdefinition 2 100%
Sammeln und Analyse von
Markt/Kundeninformationen
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 85 von 129
0%
33%
67%
100%
2 0%
Anforderungsdefinition für Serienprodukte n.a.
Anforderungsdefinition für kundenspezifische
Lösungen
Institutionalisierung des
Produktlinienmanagement
1 1 6 88%
3 0%
Produktlinienmanagement 5 0%
Institutionalisierung Leistungsmerkmale
und Architektur
2 100%
Ermittlung und Analyse von Leistungsmerkmalen 3 100%
Produktarchitektur 1 4 93%
Identifikation und Analyse von
SW/HW-Leistungsmerkmalen
Nachvollziehbarkeit und Verständnis der
Anforderungen und Leistungsmerkmale
4 100%
1 3 1 40%
Safety & Security 4 100%
Patente 2 0%
Institutionalisierung der SW Realisierung & Test 3 100%
SW-Architektur 1 3 92%
SW-Design und Codierung 4 1 20%
SW Unit- und Integrationstest 3 100%
SW Regressionstest 2 100%
Institutionalisierung der HW Realisierung & Test 4 100%
Architektur und Design von Schaltungen
(und/oder ASICs)
Unit- und Integrationstest von Schaltungen
(und/oder ASICs)
Architektur und Design von Mechanik
(und/oder Sonder-Einheiten)
Unit- und Integrationstest von Mechanik
(und/oder Sondereinheiten)
1 1 6 83%
3 100%
1 1 6 81%
3 100%
HW Regressionstest 2 100%
Institutionalisierung des Komponenten-Re-Use 3 0%
Komponenten-Re-Use 4 0%
Institutionalisierung der Produkt Integration
und -tests
Zahl der Fragen
bewertet mit Ergebnis
Thema
5 100%
Produktintegration und Verifikation 3 100%
Produktvalidierung 3 100%
Regressionstest 2 100%
Auslieferung und Einsatzunterstützung 1 1 67%
Ergebnis
Prozessgebiet
75%
0%
79%
75%
90%
0%
96%

Prozessgebiet
Prozessdefinition
und
-pflege
Standardschulung
OrganisationsweiteProzessperformance
Quantitatives
Projektmanagement
Systematische
Ursachenanalyse
und Fehlervermeidung
Innovation und
messbare
kontinuierliche
Prozessoptimierung
Thema
Institutionalisierung der Prozessdefinition
und -pflege
Commitment für den Standard-Prozess und
Prozessverbesserung
Tabelle 14: Ergebnisse der Kategorie Prozessmanagement
BEWERTUNG DES V-MODELLS XT
Am Beispiel des Prozessgebietes Anforderungsdefinition wird nun erklärt, wie der Reifegrad zustande
kommt.
In der ersten Frage der Institutionalisierung der Anforderungsdefinition werden für die Aktivitäten
der Anforderungsdefinition die Definition von Rollen und Verantwortlichkeiten, ausreichende
Ressourcen und ausreichende Fähigkeiten der Verantwortlichen gefordert. Im V-Modell XT wird
dies durch das Rollenkonzept und die Ressourcenplanung innerhalb der integrierten Planung erfüllt.
Die zweite Frage erwartet, dass die Aktivitäten vorausschauend abgeschätzt, geplant und
verfolgt werden. Da im V-Modell XT alle Aktivitäten in der integrierten Planung geplant werden
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 86 von 129
0%
33%
67%
100%
3 100%
1 2 78%
Standardprozess und Tailoring 1 4 93%
Organisationsweite Metrikdatenbank 1 1 2 75%
Kontinuierliche Prozesspflege und -verbesserung 1 3 75%
Institutionalisierung der Standardschulung 2 1 11%
Bereitstellung von Standardschulungen 2 1 11%
Ausführen der Standardschulungen 1 2 1 33%
Institutionalisierung der organisationsweiten
Prozessperformance
Auswahl und Umfang von (Teil-) Prozessen zur
statistischen Prozesskontrolle
Abstimmung der Prozessfähigkeiten mit
Organisationszielen
Institutionalisierung des quantitativen
Projektmanagements
4 0%
7 0%
3 0%
2 0%
Vorgehen zur statistischen Analyse im Projekt 3 0%
Quantitative Projektsteuerung 3 0%
Institutionalisierung der systematischen
Ursachenanalyse und Fehlervermeidung
Systematische Ursachenanalyse und
Fehlervermeidung
Institutionalisierung der Innovation und der messbaren
kontinuierlichen Prozessoptimierung
Suche und Sichtung von Innovationen von Prozessen
und Prozesstechnologien
Suche und Sichtung von Innovationen von Produkten
und Produkttechnologien
Organisationsweite Einführung von
Prozessoptimierungen und Produktverbesserungen mit
messbarem Erfolg
Zahl der Fragen
bewertet mit
Ergebnis
Thema
4 0%
3 0%
5 0%
2 0%
2 0%
3 0%
Ergebnis
Prozessgebiet
84%
20%
0%
0%
0%
0%

BEWERTUNG DES V-MODELLS XT
und durch Projektstatusberichte verfolgt werden, ist auch diese Frage erfüllt und damit das erste
Thema.
Die erste Frage des Themas Sammeln und Analyse von Markt/Kundeninformationen fordert das
methodische Identifizieren, Sammeln und Analysieren von Markt-/Kundeninformationen. Das
wird im V-Modell XT nicht durchgeführt. Somit ist die Frage mit 0% bewertet. Die Frage nach
einer systematischen Abbildung der Markt-/Kundeninformationen auf Produkte wird ebenso beurteilt,
da dieses Thema im V-Modell XT nicht behandelt wird. Das gesamte Thema ist deshalb
mit 0% bewertet.
Das dritte Thema ist die Anforderungsdefinition für Serienprodukte. Dieser ist auf das
V-Modell XT nicht anwendbar, da eine Marktanalyse vor einem V-Modell XT-Projekt stattfindet
und mit dem V-Modell XT normalerweise kundenspezifische Lösungen erstellt werden.
Die Anforderungsdefinition für kundenspezifische Lösungen stellt das vierte und letzte Thema
der Anforderungsdefinition dar. Die in der ersten Frage geforderte systematische Herleitung und
Analyse der Kundenanforderungen aus den entsprechenden Kundeninformationen wird durch die
Vorgehensweisen der Produktgruppe Anforderungen und Analysen erfüllt. Die zweite Frage fragt
nach einer methodischen und proaktiven Vervollständigung und Ausarbeitung der gesammelten
Kundeninformationen. Dazu würde es einer Kommunikation zwischen Anwender auf Auftraggeberseite
und Anforderungsanalytiker auf Auftragnehmerseite bedürfen. Dies ist durch das Konzept
der Ausschreibung im V-Modell XT nicht vorgesehen. Da durch das Angebot des
Auftragnehmers jedoch Kommunikation statt findet, wurde diese Frage mit 33% beurteilt. Die
nächsten beiden Fragen befassen sich mit der Erfassung der nicht-funktionalen Anforderungen
und der Kategorisierung und Paketierung der Kundenanforderungen. Dies geschieht im
V-Modell XT in den verschiedenen Spezifikationsprodukten. Deshalb sind diese beiden Fragen
voll erfüllt. Frage 5 lautet: Wird für Kundenanforderungen anhand einer Validierung frühzeitig
das richtige Verständnis ermittelt und eine Balance der Anforderungen erreicht? Diese Frage
wurde mit 66% beurteilt, da im V-Modell XT grundsätzlich alle Anforderungen in den Spezifikationsdokumenten
geprüft werden, aber nicht sichergestellt ist, dass sie frühzeitig validiert werden.
Die sechste Frage klärt die Existenz der systematischen und vollständigen Dokumentation
der Kundenanforderungen. Hier ergibt sich eine vollständige Erfüllung, da in den Spezifikationsdokumenten
alle Anforderungen erfasst werden und durch die automatisch generierten
Templates des V-Modells XT diese auch systematisch dokumentiert werden. Frage sieben fordert
eine systematische Vorgehensweise bei der Angebotserstellung. Hierfür wird in der nächsten
Entwicklungsphase des V-Modells XT ein eigener Vorgehensbaustein mit Inhalten gefüllt. Eine
kurze Beschreibung der Inhalte und die Struktur bestehen schon. Wegen der existierenden Produkte,
Themen, Aktivitäten und Teilaktivitäten wurde die Vorgehensweise als vorhanden gesehen
und mit 100% beurteilt. Die achte und letzte Frage beschäftigt sich mit den Zulieferungen, Beistellungen
und Tätigkeiten des Auftraggebers. Gefordert werden dafür eine Planung und Vereinbarungen
zwischen den Vertragspartnern. Die Zulieferungen und Beistellungen werden im
Thema „Mitwirkungen und Beistellungen des Auftraggebers“ im Projekthandbuch festgelegt und
somit im Projektplan geplant. Die Tätigkeiten sind durch das Rollenkonzept festgelegt und werden
somit auch durch den Projektplan geplant und abgesprochen. Diese Frage ist somit auch mit
100% bewertet.
Das gesamte Prozessgebiet Anforderungsdefinition ist somit zu 75% erfüllt. Daraus ergibt sich
direkt der Reifegrad von 2,75 für dieses Prozessgebiet.
Die hier ermittelte Schwäche der fehlenden Marktsichtung ist in der Bewertung nach SCAMPI®
nicht so klar herausgearbeitet worden, da die Marktsichtung im CMMI® nicht so explizit gefordert
wird. Die zweite schwerwiegende Schwäche, die proaktive Vervollständigung der Anforderungen
ist im CMMI® ebenso gefordert und findet sich in den entsprechenden Praktiken des
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 87 von 129

BEWERTUNG DES V-MODELLS XT
Prozessgebietes Requirements Development. Wenn man die Praktiken des CMMI® und die Fragen
des SPA genau vergleicht, sieht man die Übereinstimmung von deren Forderungen. Daher
konnten die Bewertungen der Fragen des SPA größtenteils aus den Ergebnissen des Kapitels 3
gewonnen werden.
Die ermittelten Schwächen wurden nach Reifegrad getrennt in Tabelle 15 und Tabelle 16 aufgelistet.
Dabei steht in der ersten Spalte eine Nummerierung, die aus den Buchstaben „a“ für
SCAMPI® und „b“ für SPA, aus dem betreffenden Reifegrad, einem Punkt und einer im Reifegradlevel
fortlaufenden Nummer besteht. Somit ist jede Schwäche eindeutig nummeriert. Die
Beschriftung b2.4 bedeutet beispielsweise, dass es sich bei der vierten durch das SPA gefundenen
Schwäche um die Praktiken des Reifegrads 2 handelt. Die Spalten zwei und drei spezifizieren
das Prozessgebiet und die Frage, in der die Schwäche gefunden wurde. In der letzten Spalte
ist in kurzen Worten die Schwäche beschrieben.
Nr Prozessgebiet Thema Schwäche Reifegrad 2
b2.1 Projektmanagement Erstellen des Projektplans
b2.2 Projektmanagement Projektverfolgung
b2.3 Lieferantenmanagement
b2.4 Lieferantenmanagement
b2.5
Definition von
Leistungsmerkmalen und
Architektur
Make or Buy Vorgehen
und Lieferantenauswahl
Bauelemente und Teile
Nachvollziehbarkeit und
Verständnis der
Anforderungen und
Leistungsmerkmale
es findet keine explizite Abstimmung mit anderen
Projekten statt
die Festlegung der Meetingintervalle und die
Überpüfung der Verpflichtungen aller Beteiligter
Strategien für Ausfall von Lieferanten
- organisationsweite Bauelementeliste
- Pflege der Bauelementeliste
- systematische Beschaffung von form- und
werkzeuggebundenen Teilen
- bidirektionales Tracing
- Vorgehen, um ein gemeinsames Verständnis
bzw. Commitment zu erreichen
Tabelle 15: Schwächen hinsichtlich Reifegrad 2 nach SPA
Die ermittelten Schwächen sind im Großen und Ganzen die gleichen Mängel, die durch das
SCAMPI®-ähnliche Verfahren in Kapitel 4.2.1 ermittelt wurden. Dies liegt daran, dass die Fragen
des SPA auf den Praktiken des CMMI® aufbauen und auch in einer m-zu-n-Beziehung abgebildet
werden können. Es sind im SPA zwei größere Erweiterungen in den Reifegradstufen 2
und 3 gegenüber dem CMMI® vorhanden. Das Thema Safety & Security wird im SPA durch
vier Fragen auf Reifegrad 3 betrachtet. Dieses Thema ist im V-Modell XT in dem Vorgehensbaustein
Systemsicherheit ausführlich beschrieben. Die zweite Erweiterung ist die Überprüfung von
Patentverstößen und eigenen Möglichkeiten der Patentanmeldung durch zwei Fragen im Fragenkatalog
des SPA (siehe b3.3 in Tabelle 16). Diese Aspekte werden im V-Modell XT ebenso wenig
betrachtet wie im CMMI®.
Einige weitere kleine Unterschiede zwischen dem mehr praxisorientierten SPA-Fragenkatalog
und den Praktiken des CMMI® liegen in der Auslegung der Fragen. An einigen Stellen werden
im SPA explizite Forderungen gestellt, die in den Praktiken des CMMI® allgemeiner gefasst
sind. Beispielsweise wird vom CMMI® bei der Erstellung des Projektplans die Abstimmung mit
allen Betroffenen gefordert. Die entsprechende Frage im SPA ist sehr viel präziser und fordert
auch die Abstimmung mit anderen Projekten, wie man an Schwäche b2.1 sieht.
Es gibt auch Themen, die im Fragenkatalog allgemeiner als in den Praktiken des CMMI® gehalten
sind. Ein Beispiel stellt das Prozessgebiet „Decision Analysis and Resolution“ dar. Die Prak-
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 88 von 129

BEWERTUNG DES V-MODELLS XT
tiken des Prozessgebietes sind meist auf viele Fragen des SPA verteilt, aber nicht in einem eigenen
Prozessgebiet zusammengefasst. Im SPA wird beispielsweise nach systematischem Vorgehen
für Make-Or-Buy-Entscheidungen, für Lieferantenauswahl, für die Abarbeitung von Problem-
und Änderungsanträgen und für Entscheidungen bei Meilensteinen gefragt.
Nr Prozessgebiet Thema Schwäche Reifegrad 3
b3.1 Anforderungsdefinition
b3.2 Anforderungsdefinition
b3.3
Definition von
Leistungsmerkmalen und
Architektur
b3.4 Software
Realisierung & Test
b3.5
b3.6
b3.7
b3.8
b3.9
b3.10
Hardware Realisierung &
Test
Hardware Realisierung &
Test
Produktintegration und
-test
Prozessdefinition und
-pflege
Prozessdefinition und
-pflege
Prozessdefinition und
-pflege
b3.11 Standardschulung
b3.12 Standardschulung
b3.13 Standardschulung
Sammeln und Analyse von
Markt- /
Kundeninformationen
Anforderungsdefinition für
kundenspezifische
Lösungen
Patente
SW-Design und Codierung
Architektur und Design von
Schaltungen (und / oder
ASICs)
Architektur und Design von
Mechanik (und / oder
Sondereinheiten)
Auslieferung und
Einsatzunterstützung
Commitment für den
Standard-Prozess und
Prozessverbesserung
Organisationsweite
Metrikdatenbank
Kontinuierliche
Prozesspflege und -
verbesserung
Institutionalisierung der
Standardschulung
Bereitstellung von
Standardschulungen
Ausführen der
Standardschulungen
Markt- / Kundenanforderungen werden weder
ausgewertet noch auf Produkte abgebildet
proaktive Vervollständigung der
Kundenanforderungen
- Analyse fremder Patente auf Verletzung
- Analyse eigener Patentmöglichkeiten
- Inline-Dokumentation
- statistische Codeanalyse
- dynamische Codeanalyse
- in der Organisation festgelegte
Programmierkonventionen
Designrichtlinien für Stromlauf und Layout
Designrichtlinien für mechanische Konstruktionen
Verpackung und Lagerung
Einbeziehung aller relevanten Betroffenen
(Rollen) bei der Prozessdefinition
Optimierung der Metrikdatenbank
regelmäßige Untersuchung auf
Prozessverbesserungsmöglichkeiten
- Rollen für Schulung der Mitarbeiter
- vorausschauende Planung der Schulungen
- Verfolgung der Schulungen
- Konfigurationsmanagement für Schulungen
- ganzheitliche Analyse des zukünftigen Bedarfs
an Kompetenz und Training
- Planung der Schulungsmaßnahmen
- Vorgehen für Erstellung / Auswahl / Pflege von
Schulungen
- Aufzeichnungen über Schulungen
- Effektivität / Nutzen der Schulungen
- Planung der Durchführung für jeden
Mitarbeiter
Tabelle 16: Schwächen hinsichtlich Reifegrad 3 nach SPA
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 89 von 129

BEWERTUNG DES V-MODELLS XT
Die Forderung des CMMI® nach einer Allgemeinen Vorgehensweise für die Entscheidungsfindung
kann das V-Modell XT nicht bieten, jedoch hat es für die oben angesprochenen Beispiele
gute Vorgehensweisen. Andererseits wurden die Bewertung der Fragen nach der Erstellung, Dokumentation
und systematischen Auswahl von alternativen Architekturen bei Software und
Hardware abgewertet. Diesen Fragen würden beim CMMI® teilweise durch das Prozessgebiet
„Decision Analysis and Resolution“ abgefragt werden und sind im V-Modell XT nicht umgesetzt.
Die oben geschilderten Umstände stellen die wesentlichen Unterschiede zwischen den Schwächen
dar, die nach SCAMPI® bzw. SPA ermittelt wurden.
4.3 Endergebnisse nach SCAMPI® und SPA
Die Auswertung nach SCAMPI® lässt keine höhere Bewertung als Reifegrad 1 zu, wie in
Abbildung 16 dargestellt. Dies liegt an den Schwächen in den Prozessgebieten „Anforderungsmanagement“
und „Projektverfolgung und -steuerung“ (siehe auch Tabelle 10). Da in diesen
Prozessgebieten des Reifegrads 2 jeweils eine Praktik nicht oder nur teilweise erfüllt ist, ist das
gesamte Prozessgebiet nicht erfüllt. Dies ist unabhängig von den im Reifegrad 3 festgestellten
weiteren Lücken.
Reifegrad
5,0
4,5
4,0
3,5
3,0
2,5
2,0
1,5
1,0
0,5
0,0
1
Abbildung 16: Endergebnis nach SCAMPI® und SPA im Vergleich
Das V-Modell XT ist jedoch wesentlich näher an Reifegrad 3, wie aus der Bewertung nach SPA
in Abbildung 16 zu sehen ist. Die feinere Bewertung nach SPA zeigt, dass zum Erreichen des
Reifgrades 3 nur ein Viertel fehlt. Diese Bewertung entspricht wesentlich besser der Qualität des
neuen V-Modells XT.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 90 von 129
2,75
SCAMPI SPA

BEWERTUNG DES V-MODELLS XT
Der nach SPA ermittelte Reifegrad 2,75 ist deswegen gerechtfertig, weil das V-Modell XT die für
Reifegrad 2 und Reifegrad 3 wichtigsten Themen größtenteils erfüllt. Dies hat sich schon in der
Bewertung der einzelnen Prozessgebiete in Abbildung 15 abgezeichnet, da in den Prozessgebieten
mit wenigen Ausnahmen nur geringe Schwächen vorhanden sind.
Zusammenfassend kann man feststellen, dass die Bewertung nach dem SCAMPI®-Verfahren einen
wenig aussagekräftigen Reifegrad liefert. Dagegen zeigt die Bewertung nach SPA besser die
Qualität des V-Modells XT. Sie ermöglicht somit auch eine wesentlich leichtere Definition von
Verbesserungsmaßnahmen.
4.4 Ansätze für Verbesserungsmaßnahmen
Aus den Schwächen der Kapitel 4.2.1 und 4.2.2 wurden erste Ansätze für Verbesserungsmaßnahmen
abgeleitet, die im Folgenden dargestellt sind. Dabei sind Schwächen, die durch beide
Bewertungen gefunden wurden, in gemeinsamen Maßnahmen formuliert. Alle anderen Schwächen
sind dem jeweiligen Verfahren zugeordnet. In Tabelle 17 und Tabelle 18 sind alle Maßnahmen
getrennt nach Reifegradstufe zusammengefasst. Dabei stehen in den ersten beiden Spalten
die Nummern der Schwächen aus der Bewertung nach SCAMPI® und SPA, die diesen in den
Kapiteln 4.2.1 und 4.2.2 zugeordnet wurden. In der dritten Spalte wird für jede Schwäche eine
Maßnahme empfohlen.
Schwächen-Nr.
SCAMPI SPA
a2.1 b2.5
a2.2
b2.2
b2.5
Erweiterung des unidirektionalen Tracings der Anforderungen auf ein bidirektionales:
beispielsweise könnte bei der Instantiierung eines Produktes das Vaterprodukt mit in der
Instanz erfasst werden
- hinzufügen zu Projektstatusbericht: jeder Beteiligte muss eine verbindliche
Aussage abgeben, dass er seine Aufgabe in Zeit, Kosten und Qualität wie geplant
durchführen wird
- hinzufügen zu Projektfortschrittsentscheidung: der Auftraggeber muss eine verbindliche
Aussage abgeben, dass er zu seinen Verpflichtungen steht
b2.1 bei Ressourcenplanung die Abstimmung mit anderen Projekten hinzufügen
b2.3
b2.4
Maßnahmen Reifegrad 2
in den "Kriterienkatalog für die Angebotsbewertung" die Risiken bei Ausfall des Lieferanten
ausdrücklich aufnehmen
zu Thema "nichtfunktionale Anforderungen" der HW-Spezifikation eine Liste der
freigegebenen Bauelemente und der form- und werkzeuggebundenen Teile hinzufügen
(Pflege Aufgabe der Organisation, da kontinuierlich durchzuführen)
Tabelle 17: Mögliche Verbesserungsmaßnahmen hinsichtlich Reifegrad 2
Die Maßnahmen aus Tabelle 17 helfen, auf Reifegradstufe 2 die Anforderungen von SPA und
SCAMPI® besser zu erfüllen. Aus der geringen Zahl an Maßnahmen erkennt man, dass in Richtung
von Reifegrad 2 nur wenige Verbesserungsmaßnahmen nötig sind.
Die mit dem SCAMPI®-Verfahren ermittelten Schwächen des Reifegrads 2 sind jedoch zwingend
zu beheben, um über die Erfüllung des Reifegrads 2 hinaus auch den Reifegrad 3 erreichen
zu können. Die in Tabelle 18 für eine Verbesserung in Richtung Reifegrad 3 aufgelisteten möglichen
Maßnahmen sind deutlich umfangreicher.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 91 von 129

Schwächen-Nr.
SCAMPI SPA
a3.1 b3.2
a3.2
a3.3
a3.4 b3.7
a3.5 - a3.7
a3.8
a3.9
a3.10
a3.11
a3.12
a3.13
a3.14
a3.15 -
a3.20
b3.11b3.13
b3.11b3.13
b3.11b3.13
b3.11b3.13d
b3.11b3.13
b3.11b3.13
BEWERTUNG DES V-MODELLS XT
nach Auswahl des Auftragnehmers durch den Auftraggeber, aber vor Abschluss des
Vertrags, sollten die Anforderungsanalytiker von Auftraggeber und Auftragnehmer die
Anforderungen abstimmen, um Unstimmigkeiten zu beseitigen
in die Architekturprodukte die Entwicklung von Kriterien für die Auswahl der Entwurfsalternativen
aufnehmen und beispielsweis in der Teilaktivität "Architektur bewerten"
die Auswahl der Alternative aufgrund der festgelegten Kriterien hinzufügen
in die Aktivitäten "zum/zur System/Segment/HW-Einheit/.. Integrieren" einen Passus
aufnehmen, der die Übereinstimmung der erwarteten zu den vorgelegten Elementen
sicherstellt
beim Produkt Lieferung kann ein Absatz für die sachgemäße Verpackung hinzugefügt
werden
in das Projekthandbuch / QS-Handbuch einen Satz bei der Auswahl der Methoden einfügen,
der Peer Reviews für CMMI-Kompatibilität vorschreibt
- zu Peer Reviews siehe a3.5
- Produktlebenszyklen nicht umsetzbar, da das Modell nicht die komplette Lebenszeit eines
Produktes erfasst
im Thema Schulungskonzept die Ermittlung der Anforderungen an das Training
ausführlicher beschreiben: Analyse der Ziele, des Bedarfs und benötigter Rollen
im Thema Schulungskonzept die Abgrenzung des organisationsweiten Trainings vom
Training im Projekt und mit den Projekten deren Bedarf ermitteln
zu Schulungskonzept hinzufügen: Ressourcen, Qualitätsanforderungen an Training,
Schulungsmethodik
die Rolle des Trainers und das Trainieren der Trainer hinzufügen
in der Teilaktivität "Breiteneinführung durchführen" die Durchführung der Schulungen besser
herausarbeiten: mit Auswahl der Teilnehmer, Planung des Trainings, Überwachung der
Durchführung
die Ergebnisse der Trainings aufzeichnen und auswerten: dazu gehören alle Ergebnisse
aller Teilnehmer
ähnlich der Projektfortschrittsentscheidung ein Produkt Entscheidung im Rahmen der
Planung und Steuerung definieren, in dem ein generelles Vorgehen zur
Entscheidungsfindung beschrieben wird. Inhalt:
- Kriterien für Auswahl und Auswahlmethodik
- Alternative Lösungen
- Bewertung der Lösungen
b3.1 kontinuierliche Aufgabe der Organisation
b3.3
b3.4
b3.5
b3.6
b3.8
in Spezifikationen und Architekturen Hinweise auf Prüfung von Patentenverletzungen und
von Patentanmeldungen aufnehmen
zu Thema "nichtfunktionale Anforderungen" der SW-Spezifikation Festlegungen für Inline-
Dokumentation, Codeanalysen und organisationsweite Programmierkonventionen
hinzufügen
zu Thema "nichtfunktionale Anforderungen" der HW-Spezifikation Designrichtlinien für
Stromlauf und Layout hinzufügen
zu Thema "nichtfunktionale Anforderungen" der HW-Spezifikation Designrichtlinien für
mechanische Konstruktionen hinzufügen
in Thema "Zielsetzung Managementunterstützung" des Produkts "Verbesserungskonzept
für ein Vorgehensmodell" die Einbeziehung der Mitarbeiter aufnehmen
b3.9 kontinuierliche Aufgabe der Organisation
b3.10 kontinuierliche Aufgabe der Organisation
Maßnahmen Reifegrad 3
Tabelle 18: Mögliche Verbesserungsmaßnahmen hinsichtlich Reifegrad 3
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 92 von 129

BEWERTUNG DES V-MODELLS XT
Beide Listen stellen einen ersten Ansatz in Richtung Verbesserung auf Reifegrad 3 dar. Die Vorschläge
für Maßnahmen erheben jedoch nicht den Anspruch auf Vollständigkeit, zumal eine
Menge von größtenteils erfüllten Themen in den herausgestellten Schwächen nicht auftaucht.
Die Prozessgebiete, die zu Reifegrad 4 und Reifegrad 5 beitragen, wurden im Rahmen der Bewertung
nicht betrachtet. Hier handelt es sich um Themen, die überwiegend durch die Organisation
geregelt werden müssen. Das V-Modell XT beschreibt hingegen die Projektabwicklung und
nicht Aufgaben der Organisation. Die Definition von Maßnahmen in Richtung Reifegrad 4 und 5
ist somit nicht sinnvoll.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 93 von 129

5 Ausblick
Mit dem V-Modell XT ist eine an den modernen Stand der Technologie angepasste Prozessbeschreibung
entwickelt worden. Sie schafft die Voraussetzung für Organisationen und Unternehmen,
CMMI®-Reifegrad 3 zu erreichen und so die Projektabwicklung in Zeit, Kosten und
Qualität zu verbessern.
Dabei besitzt das V-Modell XT gegenüber dem V-Modell 97 einen wesentlich erweiterten Anwendungsbereich.
Es ist einer der ersten Standards, die einen integrierten Entwicklungsprozess
definieren. In diesem sind alle Entwicklungsdisziplinen (Systems-Engineering, SW-Engineering,
HW-Engineering, Logistik-Engineering) eingearbeitet.
Kontinuierliche Aufgaben der Organisation kann das V-Modell XT aufgrund seiner Auslegung
für Projekte nicht abdecken. Behörden und Unternehmen, die das V-Modell XT anwenden, müssen
daher die organisationsspezifischen Regelungen des CMMI® gesondert umsetzen bzw. das
V-Modell XT entsprechend erweitern. Dies gilt insbesondere für die Prozessgebiete der Reifegrade
4 und 5, in welchen Regelungen durch die jeweilige Organisation definiert werden müssen.
In dieser Diplomarbeit konnte nur der im V-Modell XT dokumentierte und nicht der gelebte Prozess
in den Projekten bewertet werden. Ein echtes Assessment in einem ersten realen Anwendungsprojekt
wäre daher sehr interessant. Es würde die Stärken und Schwächen in der Praxis
deutlich machen und Hinweise auf Verbesserungspotentiale geben.
Wie vorher dargestellt setzt die Diplomarbeit auf dem Stand des V-Modells XT vom 30. Juni
2004 auf. Das V-Modell XT ist gegenüber diesem Stand verbessert, da einige Anregungen aus
der Diplomarbeit schon übernommen wurden. Diese verbesserte Version konnte jedoch nicht
mehr eingearbeitet werden.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 94 von 129

Anhang
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 95 von 129

A Ergänzende Informationen, Tabellen und Abbildungen
A.1 CMMI®-Erfüllungsgrade des V-Modells XT in der Übersicht
In der folgenden Tabelle sind die Ergebnisse der in Kapitel 3 ausführlich diskutierten Bewertung des V-Modells XT zusammengefasst dargestellt.
Die Tabelle ist entsprechend Kapitel 3 in Prozessgebiete, Ziele und Praktiken strukturiert. Die zugehörigen Kapitelnummern sind in der
ersten Spalte referenziert.
Die Bewertung der Ziele und Prozessgebiete folgt dem in Kapitel 4.1.1 angegebenen Bewertungsverfahren. Nach SCAMPI® wird nur eine
Aussage gemacht, ob die Ziele und Prozessgebiete erfüllt sind oder nicht. Deshalb werden die Erfüllungsgrade teilweise und größtenteils nicht
angewendet. Ziele sind nur dann erfüllt, wenn alle zugehörigen Praktiken größtenteils oder voll erfüllt sind. Prozessgebiete sind nur dann erfüllt,
wenn alle ihre Ziele erfüllt sind.
Legende:
Prozessgebiet
Ziel (spezifisch oder generisch)
Praktik (spezifisch oder generisch)
nicht anwendbar
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 96 von 129

Kapitel Prozessgebiet / Ziel / Praktik
3.1 Requirements Management (Maturity Level 2)
3.1.1 Manage Requirements
3.1.1.1 Obtain an Understanding of Requirements
3.1.1.2 Obtain Commitment to Requirements
3.1.1.3 Manage Requirements Changes
3.1.1.4 Maintain Bidirectional Traceability of Requirements
3.1.1.5 Identify Inconsistencies between Project Work and Requirements
3.2 Project Planning (Maturity Level 2)
3.2.1 Establish Estimates
3.2.1.1 Estimate the Scope of the Project
3.2.1.2 Establish Estimates of Work Product and Task Attributes
3.2.1.3 Define Project Life Cycle
3.2.1.4 Determine Estimates of Effort and Cost
3.2.2 Develop a Project Plan
3.2.2.1 Establish the Budget and Schedule
3.2.2.2 Identify Project Risks
3.2.2.3 Plan for Data Management
3.2.2.4 Plan for Project Resources
3.2.2.5 Plan for Needed Knowledge and Skills
3.2.2.6 Plan Stakeholder Involvement
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 97 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.2.2.7 Establish the Project Plan
3.2.3 Obtain Commitment to the Plan
3.2.3.1 Review Plans that Affect the Project
3.2.3.2 Reconcile Work and Resource Levels
3.2.3.3 Obtain Plan Commitment
3.3 Project Monitoring and Control (Maturity Level 2)
3.3.1 Monitor Project Against Plan
3.3.1.1 Monitor Project Planning Parameters
3.3.1.2 Monitor Commitments
3.3.1.3 Monitor Project Risks
3.3.1.4 Monitor Data Management
3.3.1.5 Monitor Stakeholder Involvement
3.3.1.6 Conduct Progress Reviews
3.3.1.7 Conduct Milestone Reviews
3.3.2 Manage Corrective Action to Closure
3.3.2.1 Analyze Issues
3.3.2.2 Take Corrective Action
3.3.2.3 Manage Corrective Action
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 98 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.4 Supplier Agreement Management (Maturity Level 2)
3.4.1 Establish Supplier Agreements
3.4.1.1 Determine Acquisition Type
3.4.1.2 Select Suppliers
3.4.1.3 Establish Supplier Agreements
3.4.2 Satisfy Supplier Agreements
3.4.2.1 Review COTS Products
3.4.2.2 Execute the Supplier Agreement
3.4.2.3 Accept the Acquired Product
3.4.2.4 Transition Products
3.5 Measurement and Analysis (Maturity Level 2)
3.5.1 Align Measurement and Analysis Activities
3.5.1.1 Establish Measurement Objectives
3.5.1.2 Specify Measures
3.5.1.3 Specify Data Collection and Storage Procedures
3.5.1.4 Specify Analysis Procedures
3.5.2 Provide Measurement Results
3.5.2.1 Collect Measurement Data
3.5.2.2 Analyze Measurement Data
3.5.2.3 Store Data and Results
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 99 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.5.2.4 Communicate Results
3.6 Process and Product Quality Assurance (Maturity Level 2)
3.6.1 Objectively Evaluate Processes and Work Products
3.6.1.1 Objectively Evaluate Processes
3.6.1.2 Objectively Evaluate Work Products and Services
3.6.2 Provide Objective Insight
3.6.2.1 Communicate and Ensure Resolution of Noncompliance Issues
3.6.2.2 Establish Records
3.7 Configuration Management (Maturity Level 2)
3.7.1 Establish Baselines
3.7.1.1 Identify Configuration Items
3.7.1.2 Establish a Configuration Management System
3.7.1.3 Create or Release Baselines
3.7.2 Track and Control Changes
3.7.2.1 Track Change Requests
3.7.2.2 Control Configuration Items
3.7.3 Establish Integrity
3.7.3.1 Establish Configuration Management Records
3.7.3.2 Perform Configuration Audits
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 100 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.8 Requirements Development (Maturity Level 3)
3.8.1 Develop Customer Requirements
3.8.1.1 Elicit Needs
3.8.1.2 Develop the Customer Requirements
3.8.2 Develop Product Requirements
3.8.2.1 Establish Product and Product-Component Requirements
3.8.2.2 Allocate Product Component-Requirements
3.8.2.3 Identify Interface Requirements
3.8.3 Analyze and Validate Requirements
3.8.3.1 Establish Operational Concepts and Scenarios
3.8.3.2 Establish a Definition of Required Functionality
3.8.3.3 Analyze Requirements
3.8.3.4 Analyze Requirements to Achieve Balance
3.8.3.5 Validate Requirements with Comprehensive Methods
3.9 Technical Solution (Maturity Level 3)
3.9.1 Select Product-Component Solutions
3.9.1.1 Develop Detailed Alternative Solutions and Selection Criteria
3.9.1.2 Evolve Operational Concepts and Scenarios
3.9.1.3 Select Product-Component Solutions
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 101 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.9.2 Develop the Design
3.9.2.1 Design the Product or Product Component
3.9.2.2 Establish a Technical Data Package
3.9.2.3 Design Interfaces Using Criteria
3.9.2.4 Perform Make, Buy or Reuse Analyses
3.9.3 Implement the Product Design
3.9.3.1 Implement the Design
3.9.3.2 Develop Product Support Documentation
3.10 Product Integration (Maturity Level 3)
3.10.1 Prepare for Product Integration
3.10.1.1 Determine Integration Sequence
3.10.1.2 Establish the Product Integration Environment
3.10.1.3 Establish Product Integration Procedures and Criteria
3.10.2 Ensure Interface Compatibility
3.10.2.1 Review Interface Descriptions for Completeness
3.10.2.2 Manage Interfaces
3.10.3 Assemble Product Components and Deliver the Product
3.10.3.1 Confirm Readiness of Product Components for Integration
3.10.3.2 Assemble Product Components
3.10.3.3 Evaluate Assembled Product Component
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 102 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.10.3.4 Package and Deliver the Product or Product Component
3.11 Verification (Maturity Level 3)
3.11.1 Prepare for Verification
3.11.1.1 Select Work Products for Verification
3.11.1.2 Establish the Verification Environment
3.11.1.3 Establish Verification Procedures and Criteria
3.11.2 Perform Peer Reviews
3.11.2.1 Prepare for Peer Reviews
3.11.2.2 Conduct Peer Reviews
3.11.2.3 Analyze Peer Review Data
3.11.3 Verify Selected Work Products
3.11.3.1 Perform Verification
3.11.3.2 Analyze Verification Results and Identify Corrective Action
3.12 Validation (Maturity Level 3)
3.12.1 Prepare for Validation
3.12.1.1 Select Products for Validation
3.12.1.2 Establish the Validation Environment
3.12.1.3 Establish Validation Procedures and Criteria
3.12.2 Validate Product or Product Components
3.12.2.1 Perform Validation
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 103 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.12.2.2 Analyze Validation Results
3.13 Organizational Process Focus (Maturity Level 3)
3.13.1 Determine Process-Improvement Opportunities
3.13.1.1 Establish Organizational Process Needs
3.13.1.2 Appraise the Organization’s Processes
3.13.1.3 Identify the Organization's Process Improvements
3.13.2 Plan and Implement Process-Improvement Activities
3.13.2.1 Establish Process Action Plans
3.13.2.2 Implement Process Action Plans
3.13.2.3 Deploy Organizational Process Assets
3.13.2.4
Incorporate Process-Related Experiences into the Organizational Process
Assets
3.14 Organizational Process Definition (Maturity Level 3)
3.14.1 Establish Organizational Process Assets
3.14.1.1 Establish Standard Processes
3.14.1.2 Establish Life-Cycle Model Descriptions
3.14.1.3 Establish Tailoring Criteria and Guidelines
3.14.1.4 Establish the Organization’s Measurement Repository
3.14.1.5 Establish the Organization’s Process Asset Library
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 104 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.15 Organizational Training (Maturity Level 3)
3.15.1 Establish an Organizational Training Capability
3.15.1.1 Establish the Strategic Training Needs
3.15.1.2 Determine Which Training Needs Are the Responsibility of the Organization
3.15.1.3 Establish an Organizational Training Tactical Plan
3.15.1.4 Establish Training Capability
3.15.2 Provide Necessary Training
3.15.2.1 Deliver Training
3.15.2.2 Establish Training Records
3.15.2.3 Assess Training Effectiveness
3.16 Integrated Project Management (Maturity Level 3)
3.16.1 Use the Project’s Defined Process
3.16.1.1 Establish the Project’s Defined Process
3.16.1.2 Use Organizational Process Assets for Planning Project Activities
3.16.1.3 Integrate Plans
3.16.1.4 Manage the Project Using the Integrated Plans
3.16.1.5 Contribute to the Organizational Process Assets
3.16.2 Coordinate and Collaborate with Relevant Stakeholders
3.16.2.1 Manage Stakeholder Involvement
3.16.2.2 Manage Dependencies
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 105 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.16.2.3 Resolve Coordination Issues
3.17 Risk Management (Maturity Level 3)
3.17.1 Prepare for Risk Management
3.17.1.1 Determine Risk Sources and Categories
3.17.1.2 Define Risk Parameters
3.17.1.3 Establish a Risk Management Strategy
3.17.2 Identify and Analyze Risks
3.17.2.1 Identify Risks
3.17.2.2 Evaluate, Categorize and Prioritize Risks
3.17.3 Mitigate Risks
3.17.3.1 Develop Risk Mitigation Plans
3.17.3.2 Implement Risk Mitigation Plans
3.18 Decision Analysis and Resolution (Maturity Level 3)
Evaluate Alternatives
Establish Guidelines for Decision Analysis
Establish Evaluation Criteria
Identify Alternative Solutions
Select Evaluation Methods
Evaluate Alternatives
Select Solutions
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 106 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.19 Organizational Process Performance (Maturity Level 4)
Establish Performance Baselines and Models
Select Processes
Establish Process Performance Measures
Establish Quality and Process-Performance Objectives
Establish Process Performance Baselines
Establish Process Performance Models
3.20 Quantitative Project Management (Maturity Level 4)
Quantitatively Manage the Project
Establish the Project’s Objectives
Compose the Defined Process
Select the Subprocesses that Will Be Statistically Managed
Manage Project Performance
Statistically Manage Subprocess Performance
Select Measures and Analytic Techniques
Apply Statistical Methods to Understand Variation
Monitor Performance of the Selected Subprocesses
Record Statistical Management Data
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 107 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.21 Organizational Innovation and Deployment (Maturity Level 5)
Select Improvements
Collect and Analyze Improvement Proposals
Identify and Analyze Innovations
Pilot Improvements
Select Improvements for Deployment
Deploy Improvements
Plan the Deployment
Manage the Deployment
Measure Improvement Effects
3.22 Causal Analysis and Resolution (Maturity Level 5)
Determine Causes of Defects
Select Defect Data for Analysis
Analyze Causes
Address Causes of Defects
Implement the Action Proposals
Evaluate the Effect of Changes
Record Data
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 108 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

Kapitel Prozessgebiet / Ziel / Praktik
3.23 Generic Goals
3.23.1 Institutionalize a Managed Process (GG 2)
3.23.1.1 Establish an Organizational Policy
3.23.1.2 Plan the Process
3.23.1.3 Provide Resources
3.23.1.4 Assign Responsibility
3.23.1.5 Train People
3.23.1.6 Manage Configurations
3.23.1.7 Identify and Involve Relevant Stakeholders
3.23.1.8 Monitor and Control the Process
3.23.1.9 Objectively Evaluate Adherence
3.23.1.10 Review Status with Higher Level Management
3.23.2 Institutionalize a Defined Process (GG 3)
3.23.2.1 Establish a Defined Process
3.23.2.2 Collect Improvement Information
Tabelle 19: Übersicht der Bewertung des V-Modells XT entsprechend Kapitel 3
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 109 von 129
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Erfüllungsgrade
nicht teilweise größtenteils voll

A.2 Bewertung der Prozessgebiete nach SPA
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
0% 20% 40% T
%
60% 80% 100%
L2: Institutionalisierung des Projektmanagements
L2/3: Planen der Projektrahmenbedingungen
L2/3: Schätzmethodik
L2: Erstellen des Projektplans
L2/3: Einbindung der Beteiligten
L2: Messen und Analysieren im Projekt
L2/3: Projektverfolgung
L2/3: Risikomanagement
Abbildung 17: Management im Projekt: Projektmanagement
0% 20% 40% T 60% 80% 100%
L2: Institutionalisierung des
Lieferantenmanagements
L2: Make or Buy Vorgehen und
Lieferantenauswahl
%
L2: Fertigprodukte
L2: Vertragsgestaltung bei Lieferanten
L2: Management von Lieferanten
L2: Bauelemente und Teile
Abbildung 18: Management im Projekt: Lieferantenmanagement
L2: Institutionalisierung der Qualitätssicherung
L2: Prozess-Controlling
L2: QS-Berichterstattung und Eskalation
L2/3: Reviewmethodik und Reviewumfang
0% 20% 40% T
%
60% 80% 100%
Abbildung 19: Management im Projekt: QS und Reviews
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 110 von 129

L2: Institutionalisierung des Konfigurations- und
Änderungsmanagements
L2: Objektverwaltung im
Konfigurationsmanagement
L2: Baselines und Freigabe
L2: Fehler- und Änderungsmanagement
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
0% 20% 40% T
%
60% 80% 100%
Abbildung 20: Management im Projekt: Konfigurations- und Änderungsmanagement
0%
L3: Institutionalisierung der
Anforderungsdefinition
20% 40% T
%
60% 80% 100%
L3: Sammeln und Analyse von
Markt/Kundeninformationen
L3: Anforderungsdefinition für Serienprodukte
L3: Anforderungsdefinition für kundenspezifische
Lösungen
Abbildung 21: Engineering: Anforderungsdefinition
0% 20% 40% T 60% 80% 100%
L3: Institutionalisierung Leistungsmerkmale und
Architektur
L3: Ermittlung und Analyse von Leistungsmerkmalen
%
L3: Produktarchitektur
L3: Identifikation und Analyse von SW/HW-
Leistungsmerkmalen
L2: Nachvollziehbarkeit und Verständnis der
Anforderungen und Leistungsmerkmale
L3: Safety & Security
L3: Patente
Abbildung 22: Engineering: Definition von Leistungsmerkmalen und Architektur
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 111 von 129
n.a.

ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
0% 20% 40% T 60% 80% 100%
L3: Institutionalisierung der SW Realisierung &
Test
%
L3: SW-Architektur
L3: SW-Design und Codierung
L3: SW Unit- und Integrationstest
L3: SW Regressionstest
Abbildung 23: Engineering: Software Realisierung & Test
0% 20% 40% T 60% 80% 100%
L3: Institutionalisierung der HW Realisierung &
Test
L3: Architektur und Design von Schaltungen
(und/oder ASICs)
L3: Unit- und Integrationstest von Schaltungen
(und/oder ASICs)
L3: Architektur und Design von Mechanik
(und/oder Sonder-Einheiten)
L3: Unit- und Integrationstest von Mechanik
(und/oder Sondereinheiten)
%
L3: HW Regressionstest
Abbildung 24: Engineering: Hardware Realisierung & Test
0% 20% 40% T 60% 80% 100%
L3: Institutionalisierung der Produkt Integration
und -tests
%
L3: Produktintegration und Verifikation
L3: Produktvalidierung
L3: Regressionstest
L3: Auslieferung und Einsatzunterstützung
Abbildung 25: Engineering: Produktintegration und -test
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 112 von 129

ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
0% 20% 40% T 60% 80% 100%
L3: Institutionalisierung der Prozessdefinition und
-pflege
%
L3: Commitment für den Standard-Prozess und
Prozessverbesserung
L3: Standardprozess und Tailoring
L3: Organisationsweite Metrikdatenbank
L3: Kontinuierliche Prozesspflege und -
verbesserung
Abbildung 26: Prozessmanagement: Definition und Pflege
L3: Institutionalisierung der Standardschulung
L3: Bereitstellung von Standardschulungen
L3: Ausführen der Standardschulungen
0% 20% 40% T
%
60% 80% 100%
Abbildung 27: Prozessmanagement: Standardschulung
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 113 von 129

ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
A.3 Konventionsabbildung im V-Modell XT:
CMMI®-Abbildung des V-Modells XT (Version 30.06.04)
Einleitung
Das Capability Maturity Model Integration® in Version 1.1(im Folgenden kurz CMMI® genannt) wurde
vom Software Engineering Institute der Carnegie Mellon University, Pittsburgh, PA entworfen, um interdisziplinäre
Entwicklungen, vor allem Software- und Systementwicklungsprojekte, schneller und günstiger
abwickeln und dabei qualitativ hochwertigere Produkte erhalten zu können. Dabei wurden vorher
getrennt vorhandene Modelle für Softwareentwicklung, Systementwicklung, integrierte Produkt- und
Prozessentwicklung und Lieferantenbeschaffung in ein gemeinsames Modell integriert. Aus der Historie
der Ursprungsmodelle ergaben sich zwei strukturell unterschiedliche Darstellungen, die stufenförmige
und die kontinuierliche Darstellung. Es wird bei dieser Konventionsabbildung nur die stufenförmige Variante
berücksichtigt, da sie den Reifegrad einer Organisation über alle Prozessgebiete hinweg ermittelt
und somit mehr der Sicht des V-Modells entspricht. Das wesentliche Strukturelement der stufenförmigen
Darstellung sind die Prozessgebiete, die den Reifegraden 2 bis 5 zugeordnet sind. In jedem Prozessgebiet
gibt es ein oder mehrere "Spezifische Ziele" (Specific Goals), welche zur Erfüllung des Prozessgebietes
erreicht werden müssen. Dies geschieht durch die Beherrschung der den Spezifischen Zielen zugeordneten
"Spezifischen Praktiken" (Specific Practices). Darüberhinweg gibt es noch "Generische Ziele" (Generic
Goals), eines für Reifegrad 2 und eines für die Reifegrade 3 bis 5. Deren "Generische Praktiken"
(Generic Practices) müssen für jedes Prozessgebiet, je nach angestrebtem Reifegrad erfüllt werden.
Grundsätzlich gilt, dass zur Erreichung eines Reifegrades die spezifischen und generischen Ziele aller
diesem und den niedrigeren Reifegraden zugeordneten Prozessgebiete erfüllt werden müssen.
Auf Reifegradstufe 1 sind die Prozesse meist nicht existent, „chaotisch“ oder entstehen aus dem Stehgreif.
Das bedeutet, dass es zwar Prozesse geben kann, diese werden aber weder projektspezifisch noch
unternehmensweit eingesetzt. Der Erfolg des Unternehmens hängt also von der Kompetenz und dem
„Heldentum“ der einzelnen Personen ab. Organisationen mit Reifegradstufe 1 überschreiten deshalb häufig
die Kosten und die Zeit. Erfolge durch gute Produkte sind möglich, können jedoch oft nicht wiederholt
werden.
In Organisationen mit Reifegradstufe 2 ist es Aufgabe der Projekte, dass Anforderungen verwaltet und die
Prozesse geplant, gesteuert, verwaltet und überprüft werden. Die bei Reifegradstufe 2 betrachteten Prozessgebiete
gewährleisten, dass vorhandene Verfahren auch in Zeiten großer Belastung angewendet werden.
Zu bestimmten Zeitpunkten können die Projektfortschritte vom Management nachvollzogen werden.
Die Arbeitsergebnisse werden überprüft und überwacht und sie erfüllen die geforderten Anforderungen,
Normen und Ziele.
Ein Unternehmen mit Reifegradstufe 3 hat einen organisationsweit festgelegten Standardprozess, der
ständig weiterentwickelt und von den Projekten durch Tailoring angepasst wird. Dieser Standardprozess
enthält neben Prozessbeschreibungen z.B. auch Werkzeuge, eine Erfahrungsdatenbank und eine organisationsweite
Sammlung von Metriken, die von den einzelnen Projekten genutzt werden können. Der Standardprozess
wird organisationsweit eingeführt und durch Weiterbildungsmaßnahmen allen Mitarbeitern
vermittelt. Während der Nutzung ist es wichtig, dass Verbesserungspotential der Prozesse in den Projekten
erkannt, dokumentiert und durch entsprechende Maßnahmen eingearbeitet wird.
Eine Organisation mit Reifegrad 4 muss den Bereich Messung und Analyse stark ausbauen. Ein Schwerpunkt
liegt dabei auf der Erstellung und Pflege einer organisationsweiten Metrikdatenbank. Es müssen Informationen
gesammelt werden, die nicht nur qualitativ sondern auch statistisch und quantitativ
ausgewertet werden können. Dazu wird die Leistung wichtiger Teilprozesse gemessen, die signifikant zur
Performanz der Prozesse beitragen. Auf Grundlage der daraus gewonnenen Erkenntnisse werden die Prozesse
verbessert. In den Projekten werden sowohl die Prozesse als auch die Ziele von denen der Organisation
abgeleitet und unter statistische/quantitative Kontrolle gestellt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 114 von 129

ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Organisationen mit Reifegradstufe 5 verbessern ihre Prozessperformanz kontinuierlich. Ausgehend von
den Zielen der Organisation und Geschäftswerten liefern die Prozesse voraussagbare Ergebnisse, sodass
das Unternehmen sehr schnell auf Chancen und Veränderungen reagieren kann. Ein anderer Aspekt des
Prozessgebietes ist die kontinuierliche Fehleranalyse. Hierbei erkennt man Fehler, deren Ursache regelmäßige
Variationen der Prozesse sind. Aufgrund der Ergebnisse gilt es, die Fehlerursachen zu ermitteln
und zu beheben.
Sowohl CMMI® als auch das V-Modell haben das Ziel, die interdisziplinäre Entwicklung von Systemen,
bestehend aus Software, Hardware und extern erstellten Einheiten zu vereinheitlichen und somit zu erleichtern.
Durch die Einführung unternehmensweit einheitlicher Vorgehensweisen werden die Entwicklungsergebnisse
verbessert.
Die Vorgehensweise ist dabei aber unterschiedlich. Das Prozessmodell CMMI® umfasst eine Menge von
Anforderungen an Prozesse einer Organisation, die dazu dienen die Prozesse zu beurteilen und aufgrund
der Ergebnisse Verbesserungsvorschläge zu machen. Das V-Modell hingegen stellt einen Standardprozess
dar, der durch Tailoring projektspezifisch angepasst werden kann. Ebenso ist es möglich einen organisationsweiten
Standardprozess auf Basis des V-Modells einzuführen. Das V-Modell bietet fertige Vorlagen
für Dokumente und enthält Vorschläge für einzusetzende Methoden und Werkzeuge. Dem gegenüber
stellt das Prozessmodell CMMI® abstrahierte Best Practices zur Verfügung. Dadurch dass hinter dem V-
Modell ein komplexes Modell mit Abhängigkeiten zwischen den Elementen steht, sind einige Anforderungen
des CMMI® im V-Modell nicht direkt durch individuelle Produkte oder Aktivitäten abgedeckt
sondern durch vielfach anwendbare Produkte/Aktivitäten, Automatismen des Modells oder allgemeine
Regelungen, die meist in den einführenden Kapiteln beschrieben sind. Beispiele hierfür sind:
• Die Einbeziehung der Stakeholder (Stakeholder Involvement and Commitment) wird im Wesentlichen
durch das Rollenmodell abgedeckt. Zu einigen Punkten (z.B. Projektplan) wird zusätzlich
noch explizit das Einverständnis aller Stakeholder eingeholt und dokumentiert.
• Die Prüfung z. B. von KM-Aktivitäten erfolgt im Rahmen der generischen Aktivität Prozess prüfen.
• Methoden sind bei der Einführung des V-Modells in der Organisation bzw. bei Projektbeginn auszuarbeiten.
Das V-Modell stellt zur Unterstützung einen Methodenpool zur Verfügung.
• Es gibt ein Produktzustandsmodell (vgl. Qualitätssicherung und Produktzustandsmodell), welches
gewährleistet, dass nach Umsetzung von Änderungen alle direkt von der Änderung betroffenen
Produkte und zusätzlich alle von diesen Produkten abhängigen Produkte erneut einer Prüfung unterzogen
werden.
Ein weiterer entscheidender Unterschied ist, dass das V-Modell XT zwischen Auftraggeber- und Auftragnehmerprojekten
unterscheidet. Die Aktivitäten z.B. des Prozessgebiets "Requirements Management"
sind deshalb auf zwei verschiedene Projekte verteilt.
Bei der CMMI®-Abbildung werden nur die Prozessgebiete der Reifegrade 2 und 3 untersucht, da das V-
Modell die Prozessgebiete der Reifegrade 4 und 5 nicht abdeckt. Da das V-Modell die Generischen Ziele
für alle im Rahmen des V-Modells relevanten Prozessgebiete erfüllt, werden sie entgegen der üblichen
Darstellung aus den Prozessgebieten herausgezogen und wie eigene Prozessgebiete behandelt.
Requirements Management
Das Prozessgebiet Requirements Management beschäftigt sich mit dem Management aller Anforderungen.
Dabei sollen auch Inkonsistenzen zwischen Anforderungen, Plänen und Ergebnissen aller Art erkannt
werden. Über die gesamte Projektdauer hinweg, besonders aber am Anfang ist es wichtig, dass ein
einheitliches Verständnis der Anforderungen bei allen Beteiligten erzielt wird und alle sich verbindlich
auf diese Anforderungen festlegen. Im weiteren Verlauf des Projekts müssen Änderungen verwaltet und
die bidirektionale Verfolgbarkeit der Anforderungen über alle Ebenen hinweg sichergestellt werden. Da-
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 115 von 129

ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
durch wird es auch möglich, Abweichungen zwischen Plänen, Arbeitsergebnissen und Anforderungen
rechtzeitig zu erkennen und entsprechende Gegenmaßnahmen einzuleiten.
Da das V-Modell im Gegensatz zu CMMI® eine strikte Trennung zwischen Auftraggeber- und Auftragnehmerprojekten
vornimmt, verteilen sich die Aktivitäten dieses Prozessgebiets auf zwei Projekte. Für die
Anforderungen (Lastenheft), die Vertragsbestandteil sind, ist im V-Modell der Auftraggeber zuständig.
Der Auftragnehmer leitet daraus die technische Sicht ab, ergänzt diese eventuell durch weitere Anforderungen
der eigenen Organisation und dokumentiert diese Anforderungen in der Gesamtsystemspezifikation
(Pflichtenheft).
Im V-Modell ist lediglich ein unidirektionales Tracing der Anforderungen implementiert. Somit ist das
Prozessgebiet nur zum größten Teil erfüllt.
Element der Konvention wird erfüllt durch
Manage Requirements Qualitätssicherung und Produktzustandsmodell,
Systemspezifikationen, Anforderungen (Lastenheft),
Problemmeldung/Änderungsantrag, Vertragszusatz,
Prüfprotokoll Dokument, Vertrag,
Prüfplan Dokumente, Planung und Steuerung
Project Planning
Die Aufgabe der Projektplanung ist es, Schätzungen durchzuführen und Pläne zu erstellen, die Pläne zu
aktualisieren und die Zustimmung zu den Plänen von allen Beteiligten zu erreichen. Auf Basis der Anforderungen
werden Umfang, Aufwand und Kosten abgeschätzt sowie ein passendes Lebenszyklusmodell
gewählt. Der Projektplan enthält neben Budget und Risiken auch die zeitliche Planung und Pläne für Ressourcen,
Schulungen, für die Datenverwaltung und die Mitwirkung der Beteiligten. Bevor von allen Beteiligten
die Zustimmung zum Projektplan eingeholt werden kann, muss er von allen Beteiligten überprüft
und es müssen die benötigten Ressourcen abgestimmt werden. Der Projektplan bildet die Grundlage für
die Durchführung und Steuerung des Projektes.
Das V-Modell deckt diese Anforderungen ab.
Element der Konvention wird erfüllt durch
Establish Estimates Projektdurchführungsstrategien, Schätzung, Kaufmännische
Projektkalkulation, Integrierte Planung,
Arbeitsauftrag vergeben
Develop a Project Plan Entscheidungspunkte, Rollen, Konfigurationsmanagement,
Kaufmännische Projektkalkulation, Projektmanagementinfrastruktur,
Projekthandbuch,
Projektplan, Identifizierte Risiken
Obtain Commitment to the Plan Projektplan, Projektplan mit allen Projektbeteiligten
abstimmen
Project Monitoring and Control
Das Prozessgebiet "Project Monitoring and Control" überwacht und steuert die Durchführung eines Projektes.
Abweichungen gegenüber der Planung werden identifiziert. Neben Parametern der Projektplanung
werden dabei auch Risiken, Datenmanagement und die Einbindung aller Beteiligten überwacht. Periodisch
und bei Erreichen von Meilensteinen werden der Projektfortschritt und die Projektergebnisse überprüft.
Steuernde und korrigierende Maßnahmen sind wenn nötig einzuleiten und zu überwachen.
Das Prozessgebiet Projektverfolgung ist durch das V-Modell vollständig erfüllt.
Element der Konvention wird erfüllt durch
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 116 von 129

ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Monitor Project Against Plan Entscheidungspunkte, Konfigurationsmanagement,
Projektstatusbericht, Risikoliste, Projektfortschrittsentscheidung
Manage Corrective Actions to Closure Projektstatusbericht
Supplier Agreement Management
Das Management von Lieferantenvereinbarungen beschäftigt sich mit der Auswahl und Einbindung von
Produkten, die von extern beschafft werden. Dabei kann es sich um Fertigprodukte, komplette Entwicklungen
durch Unterauftragnehmer oder um Mischformen handeln. In diesem Prozessgebiet geht es nicht
nur um die fundierte Auswahl des richtigen Produkts und geeigneter Lieferanten, sondern auch um die
Planung der Einbindung des gelieferten Produkts in das Gesamtprodukt und die kontinuierliche und gute
Zusammenarbeit mit dem Lieferanten bis hin zur Abnahme des Produkts.
Das Management der Lieferantenvereinbarungen ist durch das V-Modell vollständig abgedeckt.
Element der Konvention wird erfüllt durch
Establish Supplier Agreements Make-or-Buy-Entscheidung, Angebot (von AN),
Kriterienkatalog für die Angebotsbewertung, Angebotsbewertung,
Vertrag
Satisfy Supplier Agreements Marktsichtung für Fertigprodukte, Make-or-Buy-
Entscheidung, Projektstatusbericht, Vertragszusatz,
Prüfspezifikation Lieferung, Prüfprotokoll Lieferung,
Abnahmeerklärung, Externe Einheit, Mitwirkung
und Beistellungen des Auftraggebers
Measurement and Analysis
Das Prozessgebiet "Messung und Analyse" dient der Sammlung und Aufbereitung von numerisch messbaren
Projektinformationen, die das Management bzw. die Projektverantwortlichen zum Treffen von Entscheidungen
benötigen. Hierbei müssen nach Auswahl der Messziele die passenden Metriken definiert
werden. Für die Sammlung, Speicherung und Analyse der zu den Metriken gehörigen Messdaten sind geeignete
Verfahren zu entwickeln. Im Projektverlauf werden diese Verfahren angewendet und die Messergebnisse
in anschaulicher Form dargestellt.
Das Prozessgebiet "Messung und Analyse" ist durch das V-Modell vollständig erfüllt.
Element der Konvention wird erfüllt durch
Align Measurement and Analysis Activities Projektmanagementinfrastruktur, Organisation und
Vorgaben zu Messung und Analyse, Metrikkatalog,
Erfahrungsdatenbasis
Provide Measurement Results Messdaten, Metrikauswertung
Process and Product Quality Assurance
Das Prozessgebiet "Qualitätssicherung von Prozessen und Produkten" befasst sich mit der Überprüfung
von Prozessen und Arbeitsergebnissen, um den Mitarbeitern und dem Management einen objektiven Einblick
in Prozesse und zugehörige Arbeitsergebnisse zu geben. Prozesse und Arbeitsergebnisse müssen dazu
objektiv gegenüber den zugehörigen Prozessbeschreibungen, Standards und Vorgehensweisen beurteilt
werden. Dabei erkannte Abweichungen gegenüber den Vorgaben werden dokumentiert, an die Beteiligten
kommuniziert, berichtet und aufgelöst.
Die Qualitätssicherung von Prozessen und Produkten wird vom V-Modell komplett abgedeckt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 117 von 129

Element der Konvention wird erfüllt durch
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Objectively Evaluate Processes and Work Products Prüfung, QS-Bericht, QS-Handbuch, Nachweisakte
Provide Objective Insight Nachweisakte, QS-Bericht, Projektabschlussbericht,
Projekttagebuch
Configuration Management
Ziel des Konfigurationsmanagements ist es, die Integrität von Arbeitsergebnissen zu erreichen und aufrechtzuerhalten.
Vorbereitend werden die Arbeitsergebnisse ausgewählt, die dem Konfigurationsmanagement
unterstehen sollen, sowie ein Verfahren für das Konfigurations- und Änderungsmanagement
eingeführt. Es werden Produktkonfigurationen definiert, auf denen weiter aufgebaut und auf die jederzeit
zurückgegriffen werden kann. Prinzipiell werden Änderungen an allen Arbeitsergebnissen, die unter Konfigurationsmanagement
stehen, verfolgt und regelmäßig überprüft. Die Integrität der Produktkonfigurationen
wird durch regelmäßige Prüfungen gewährleistet.
Das Konfigurationsmanagement ist durch das V-Modell vollständig abgedeckt.
Element der Konvention wird erfüllt durch
Establish Baselines Qualitätssicherung und Produktzustandsmodell,
Produktbibliothek, Produktkonfiguration, Organisation
und Vorgaben zum Konfigurationsmanagement
Track and Control Changes Problem- und Änderungsmanagement, Änderungsstatusliste,
Produktkonfiguration
Establish Integrity Qualitätssicherung und Produktzustandsmodell,
Projektstatusbericht, Prozess prüfen, Dokument
prüfen, KM-Berichte erstellen
Requirements Development
Die Anforderungsentwicklung beschäftigt sich mit den Vorgehensweisen der proaktiven Identifizierung
und Analyse der Anforderungen. Dies beginnt beim Hinterfragen der Anforderungen, Erwartungen,
Randbedingungen und Schnittstellen des Kunden, bis sie vollständig verstanden werden. Die gewonnenen
Informationen werden in Kundenanforderungen umgesetzt. Aus den Kundenanforderungen werden nun
die technisch orientierten Anforderungen an die Produkte und Produktkomponenten erarbeitet und den
Produktkomponenten zugeordnet. Im nächsten Schritte findet die Ermittlung der Schnittstellenanforderungen
zwischen diesen verschiedenen Produktkomponenten statt. Um die verschiedenen bisher festgelegten
Anforderungen überprüfen zu können, werden Betriebskonzepte, dazugehörige Szenarien und eine
Definition der geforderten Funktionalität ermittelt und gepflegt. Nach der Analyse der Anforderungen
müssen die Anforderungen und Randbedingungen von allen Betroffenen in Einklang gebracht und
schließlich eine ausführliche Validation durchgeführt werden, sodass die Anforderungen zu einem Endprodukt
führen, das in der Nutzungsumgebung funktioniert.
Die Anforderungsentwicklung ist vom V-Modell abgedeckt.
Element der Konvention wird erfüllt durch
Develop Customer Requirements Anforderungen (Lastenheft), Gesamtsystemspezifikation
(Pflichtenheft)
Develop Product Requirements Systemspezifikationen, HW-Architektur, SW-
Architektur, Systemarchitektur, Unterstützungssystemarchitektur
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 118 von 129

ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Analyze and Validate Requirements Anforderungen (Lastenheft), Systemspezifikation,
Anforderungsbewertung, Prüfprotokoll Dokument,
Designabsicherung, Qualität der Anforderungen
analysieren, Anforderungsanalyse
Technical Solution
Die Technische Umsetzung setzt Anforderungen mit Hilfe von Design und Implementierung in Produkte
und Produktkomponenten um. Aus den verschiedenen, detailliert untersuchten Lösungsansätzen wird mit
Hilfe von Entscheidungskriterien die beste Variante ausgewählt. Das Hauptaugenmerk dieses Prozessgebiets
liegt auf der Entwicklung des Designs des zu erzeugenden Produktes bzw. der Produktkomponente.
Die gesammelten Designdokumente werden zusammen mit den Anforderungsdokumenten im so genannten
technischen Datenpaket zusammengefasst. Mit Hilfe dieser Informationen kann die Entscheidung getroffen
werden, ob das ganze oder Teile des Produkts zugekauft, neu entwickelt oder bestehende Produkte
wieder verwendet werden. Die gefällten Entscheidungen werden umgesetzt, indem das Design implementiert
wird und die dazugehörige Dokumentation verfasst wird. Die fertigen Module werden vor der Weiterverwendung
auf Funktion getestet.
Die Technische Umsetzung ist vollständig erfüllt.
Element der Konvention wird erfüllt durch
Select Product Component Solutions Systemspezifikationen, HW-Architektur, SW-
Architektur, Systemarchitektur, Unterstützungssystemarchitektur
Develop the Design Systemspezifikationen, HW-Architektur, SW-
Architektur, Systemarchitektur, Unterstützungssystemarchitektur,
Produktkonfiguration, Implementierungs-,
Integrations- und Prüfkonzept HW,
Implementierungs-, Integrations- und Prüfkonzept
SW, Implementierungs-, Integrations- und Prüfkonzept
System, Implementierungs-, Integrations-
und Prüfkonzept Unterstützungssystem, Make-or-
Buy-Entscheidung
Implement the Product Design Logistische Unterstützung, Systemelemente
Product Integration
Aufgabe der Produktintegration ist das Zusammensetzen des Produktes aus seinen Komponenten, die
richtige Funktion des Endproduktes sicherzustellen und das Produkt zu liefern. In der Vorbereitung werden
die Reihenfolge der Integration der Produktkomponenten festgelegt, die Umgebung und Vorgehensweisen
für die Durchführung der Integration geschaffen sowie die Kriterien für den Beginn der
Integration festgelegt. In einem weiteren Schritt wird die Kompatibilität der Schnittstellen sichergestellt,
indem die Schnittstellenbeschreibungen gemanagt und auf Vollständigkeit überprüft werden. Abschließend
muss das Produkt iterativ aus seinen Komponenten zusammengesetzt und ausgeliefert werden. Dazu
müssen die zuvor festgelegten Bedingungen für den Beginn der Integration erfüllt sein, um die Komponenten
zu integrieren, dann das Ergebnis mit Hilfe von Verifikation und Validation zu evaluieren und das
fertige Produkt oder die Produktkomponente zu liefern.
Die Produktintegration ist vollständig abgedeckt.
Element der Konvention wird erfüllt durch
Prepare for Product Integration Unterstützungssystem, Implementierungs-, Integrations-
und Prüfkonzept HW, Implementierungs-,
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 119 von 129

ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Integrations- und Prüfkonzept SW, Implementierungs-,
Integrations- und Prüfkonzept System,
Implementierungs-, Integrations- und Prüfkonzept
Unterstützungssystem
Ensure Interface Compatibility Problem- und Änderungsmanagement, Prüfprotokoll
Dokument, Prüfspezifikation Dokument,
Implementierungs-, Integrations- und Prüfkonzept
HW, Implementierungs-, Integrations- und Prüfkonzept
SW, Implementierungs-, Integrations- und
Prüfkonzept System, Implementierungs-, Integrations-
und Prüfkonzept Unterstützungssystem,
Schnittstellenübersicht
Assemble Product Components and Deliver the
Product
Verification
Qualitätssicherung und Produktzustandsmodell,
Systemelemente, Produktkonfiguration, Lieferung,
Implementierungs-, Integrations- und Prüfkonzept
HW, Implementierungs-, Integrations- und Prüfkonzept
SW, Implementierungs-, Integrations- und
Prüfkonzept System, Implementierungs-, Integrations-
und Prüfkonzept Unterstützungssystem, Systemelement
prüfen
Die Verifikation soll sicherstellen, dass ausgewählte Arbeitsergebnisse an sie gestellte Anforderungen erfüllen.
Die Vorbereitung besteht aus der Auswahl der zu verifizierenden Arbeitsergebnisse, des Einrichtens
der Verifikationsumgebung, dem Festlegen von Bedingungen für Korrektheit und Vorgehensweisen
für die Verifikation. Die wichtigsten Methoden bei der Durchführung der Verifikation sind Test und Peer
Review (Partnerreview), ein Review durch Gleichgestellte, welches regelmäßig ausgeführt und dadurch
möglichst früh durch die inhaltliche Prüfung eines Fachmanns Fehler erkennen soll. Der allgemeinere
Ansatz des Tests überprüft die Einhaltung der Anforderungen nach Fertigstellung des Produkts oder der
Produktkomponente. Beide Methoden werden vorbereitet, durchgeführt und die Ergebnisse analysiert.
Falls korrigierende Maßnahmen nötig sind, werden sie eingeleitet.
Die Verifikation wird mit Ausnahme der Anforderungen bezüglich Peer Reviews erfüllt. Die im CMMI®
wichtigen Peer Reviews sind als Methode vorgeschlagen aber nicht vorgeschrieben. Um in diesem Punkt
CMMI®-Konformität zur erreichen muss deshalb bei Projektbeginn festgelegt werden, Peer Reviews
durchzuführen.
Element der Konvention wird erfüllt durch
Prepare for Verification Prüfung, Qm-Handbuch, Implementierungs-, Integrations-
und Prüfkonzept HW, Implementierungs-,
Integrations- und Prüfkonzept SW,
Implementierungs-, Integrations- und Prüfkonzept
System, Implementierungs-, Integrations- und
Prüfkonzept Unterstützungssystem, Unterstützungssystem
Perform Peer Reviews Proofing, Review
Verify Selected Work Products Prüfung
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 120 von 129

Validation
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Das Ziel der Validation ist zu zeigen, dass ein Produkt oder eine Produktkomponente in ihrer geplanten
Zielumgebung wie gewünscht funktioniert. Vorbereitend werden die zu validierenden Produkte oder Produktkomponenten
ausgewählt, die Validationsumgebung eingerichtet, Bedingungen für Korrektheit der
Ergebnisse der Validation und Vorgehensweisen für die Durchführung der Validation festgelegt. Nach
der Durchführung der Validation werden die Ergebnisse analysiert und mit Hilfe der zuvor festgelegten
Bedingungen Schwachstellen ermittelt. Diese können durch die Einreichung und Umsetzung von Änderungsanträgen
korrigiert werden.
Das Prozessgebiet Validation ist vollständig abgedeckt.
Element der Konvention wird erfüllt durch
Prepare for Validation Prüfung, QS-Handbuch, Implementierungs-, Integrations-
und Prüfkonzept HW, Implementierungs-,
Integrations- und Prüfkonzept SW,
Implementierungs-, Integrations- und Prüfkonzept
System, Implementierungs-, Integrations- und
Prüfkonzept Unterstützungssystem, Unterstützungssystem
Validate Product and Product Components Prüfung
Organizational Process Focus
Dieses Prozessgebiet dient vorrangig der Identifizierung, Planung und Umsetzung von Prozessverbesserungen
innerhalb der eigenen Organisation basierend auf einem fundierten Verständnis für die Stärken
und Schwächen der organisationsweiten Prozesse. Um die Möglichkeiten für Prozessverbesserungen zu
ermitteln, werden die Bedürfnisse der Organisation an ihre Prozesse entwickelt und die aktuellen Prozesse
bewertet. Nach der Auswahl der umzusetzenden Verbesserungsmaßnahmen werden diese geplant und
durchgeführt. Die Verbesserungen bestehen nicht nur aus neuen oder geänderten Prozessen und deren Beschreibungen,
sondern z.B. auch aus Schulungsunterlagen und unterstützenden Werkzeugen. Diese Elemente
werden unternehmensweit eingeführt.
Das Prozessgebiet Organisationsweiter Prozessfokus ist vollständig erfüllt.
Element der Konvention wird erfüllt durch
Determine Process Improvement Opportunities Verbesserungskonzept für ein Vorgehensmodell,
Bewertung eines Vorgehensmodells
Plan and Implement Process Improvement Activities
Organizational Process Definition
Verbesserungskonzept für ein Vorgehensmodell,
Projektplan, Organisationsspezifisches Vorgehensmodell,
Projekterfahrungen, Zielsetzung und
Managementunterstützung, Erfahrungsdatenbasis
Aufgabe der Organisationsweiten Prozessdefinition ist die Definition und Pflege benutzbarer organisationsweiter
Prozess-Elemente, die von den einzelnen Projekten angepasst und genutzt werden können. Unter
Prozess-Elementen versteht man neben den Beschreibungen der Prozesse zum Beispiel unterstützende
Tools, Dokumentenvorlagen und Schulungsmaterial. Außer den Prozessbeschreibungen sind die Entwicklung
von Lebenszyklusmodellen, einer Metrikdatenbank und Kriterien und Richtlinien für das Tailoring
nötig. Diese Informationen sowie weitere unterstützende Elemente werden in einer Bibliothek (auch Intranet)
zusammengefasst und somit allen Nutzern zur Verfügung gestellt.
Das Prozessgebiet Organisationsweite Prozessdefinition wird vollständig abgedeckt.
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 121 von 129

Element der Konvention wird erfüllt durch
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Establish Organizational Process Assets Projektdurchführungsstrategien, Vorgaben und Anleitung
zum Tailoring, Tailoring-
Produktabhängigkeiten, Entscheidungspunkte, Organisationsspezifisches
Vorgehensmodell
Organizational Training
Das Prozessgebiet Organisationsweites Training befasst sich mit allen Belangen der Aus- und Weiterbildung
von Mitarbeitern, die allgemeine Fähigkeiten der Mitarbeiter betreffen, welche projektübergreifend
und zur Umsetzung der Ziele der Organisation benötigt werden. Als Vorbereitung werden der Bedarf an
organisationsweiter Ausbildung geklärt und die Ausbildungsbereiche festgelegt, für die die Organisation
verantwortlich ist. Weiterhin muss ein taktischer Trainingsplan erstellt und die nötigen Trainer und Schulungsunterlagen
der Organisation zur Verfügung gestellt werden. Anhand des Plans werden die auszubildenden
Mitarbeiter ausgewählt und geschult. Die Ergebnisse der Ausbildung werden aufgezeichnet,
sodass die Mitarbeiter ihrem Wissensstand entsprechend eingesetzt werden können. Um die Effektivität
des Organisationsweiten Trainings bewerten zu können, werden passende Messdaten erfasst und gespeichert.
Das Prozessgebiet Organisationsweites Training wird teilweise im Vorgehensbaustein „Einführung und
Pflege eines organisationsspezifischen Vorgehensmodells“ umgesetzt. Lediglich die Ermittlung der Ziele
der Fortbildung ist nicht beschrieben, da dies Aufgabe des Managements ist.
Element der Konvention wird erfüllt durch
Establish an Organizational Training Capability Schulungskonzept, Schulungsunterlagen
Provide Necessary Training Schulungskonzept, Schulungsunterlagen, Erfahrungsdatenbasis
Integrated Project Management
Das Integrierte Projektmanagement bindet die Aktivitäten aller Projektmanagementthemen in die Organisation
ein. Als Vorbereitung wird aus dem organisationsweiten Prozess ein für das Projekt passender Prozess
abgeleitet und die organisationsweiten Messdaten genutzt um die Projektaktivitäten zu planen. Die
Integration aller Pläne zu einem integrierten Projektplan und die Nutzung dieses Planes zum Verwalten
und Steuern des Projektes stellen einen Teil der Umsetzung dar. Zum anderen Teil gehören das Management
der Beteiligung der Betroffenen, das Management der Abhängigkeiten zwischen den Betroffenen
und die Auflösung von Koordinationsproblemen zwischen den Betroffenen. Da die Organisation aus den
Aktivitäten der einzelnen Projekte lernen soll, werden Messdaten und Erfahrungen der organisationsweiten
Sammlung zur Verfügung gestellt.
Das Prozessgebiet Integriertes Projektmanagement wird vollständig erfüllt.
Element der Konvention wird erfüllt durch
Use the Project's Defined Process Projektstatusbericht, Projekttagebuch, Projektfortschrittsentscheidung,
Metrikauswertung, Projektabschlussbericht,
Projektspezifisches V-Modell,
Erfahrungsdatenbasis, Integrierte Planung
Coordinate and Collaborate with Relevant Stakeholders
Rollen, Projektplan, Projekthandbuch, Mitwirkung
und Beistellungen des Auftraggebers, Organisation
und Vorgaben zum Projektmanagement
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 122 von 129

Risk Management
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Die Aufgabe des Risikomanagements ist die Erkennung von potentiellen Problemen bevor sie auftreten.
Vorbereitend werden die Risikoquellen ermittelt und Risikoklassen eingeteilt. Passende Kenngrößen für
Analyse, Einteilung und Aufwand der Risiken sind genauso notwendig wie eine Strategie für die Behandlung
der Risiken. Die identifizierten Risiken, ihre Eintrittsbedingungen und Folgen werden regelmäßig
ermittelt, aufgezeichnet und ausgewertet. Daraus entsteht eine Liste von Risiken, die nach Risikoklassen
und Prioritäten sortiert ist. Für die essentiellen Risiken sind mit Hilfe der festgelegten Strategie Maßnahmen
zu bestimmen und umzusetzen, die das Eintreten dieser Risiken verhindern oder die Konsequenzen
eindämmen.
Das Risikomanagement wird im V-Modell vollständig erfüllt.
Element der Konvention wird erfüllt durch
Prepare for Risk Management Organisation und Vorgaben zum Risikomanagement,
Identifizierte Risiken, Risiken managen
Identify and Analyze Risks Identifizierte Risiken
Mitigate Risks Maßnahmenplan
Decision Analysis and Resolution
Die Entscheidungsanalyse und -findung unterstützt alle anderen Prozessgebiete beim Treffen von wichtigen
Entscheidungen, indem durch einen formalen Prozess die Alternativen gegen ihre Kriterien beurteilt
werden. Einführend werden Richtlinien für die Auswahl der zu analysierenden Entscheidungsprobleme
aufgestellt und die Entscheidungskriterien nach Prioritäten sortiert. Nach dem Ermitteln der verschiedenen
Alternativen, werden sorgfältig die Evaluierungsmethoden ausgewählt. Anhand der vorher gewählten
Kriterien und Methoden werden nun die Alternativen gegeneinander abgewägt und eine Lösung gewählt.
Das Prozessgebiet Entscheidungsanalyse und -findung wird im V-Modell nicht abgedeckt. Es wird hier
kein allgemeines Verfahren beschrieben, sondern lediglich wie einzelne Entscheidungen wie zum Beispiel
Projektfortschrittsentscheidungen oder auch Make-or-Buy-Entscheidungen getroffen werden.
Element der Konvention wird erfüllt durch
Organizational Process Performance
Das Ziel des Prozessgebietes Performanz der organisationsweiten Prozesse ist es, die Leistung der verwendeten
Prozesse zu messen und die Ergebnisse zum Aufbau von Zielen, Baselines und Modellen zu
nutzen. Um dieses Ziel zu erreichen ist es nötig, diejenigen Prozesse oder Prozesselemente aus den Standardprozessen
der Organisation auszuwählen, die statistisch analysiert werden sollen. Weiterhin werden
folgende Themen festgelegt und kontinuierlich überwacht, verwaltet und gesteuert:
• Metriken für die Messung der Prozessperformanz
• Quantitative Ziele für Qualität und Prozessperformanz
• Baselines
• Modelle für die Prozessperformanz
Das Prozessgebiet Performanz der organisationsweiten Prozesse wird im V-Modell nicht abgedeckt, da es
ein Prozessgebiet der Reifegradstufe 4 ist.
Element der Konvention wird erfüllt durch
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 123 von 129

Quantitative Project Management
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Das Quantitative Projektmanagement dient der Einhaltung der Ziele des Projektes bezüglich Qualität und
Prozessperformanz. Das eine Teilgebiet umfasst das quantitative Management des Projekts. Dazu stellt
man Ziele für die Qualität und die Prozessperformanz des Projekts auf und leitet aufgrund von historischen
Daten die projektspezifischen Prozesse von den organisationsweiten ab. Aus dem dann definierten
Prozess des Projekts wählt man die statistisch zu überwachenden Teilprozesse aus. Diese werden über die
Laufzeit des Projektes überwacht um das Erreichen der festgelegten Ziele zu erreichen. Das andere Teilgebiet
befasst sich mit dem statistischen Management der Teilprozesse. Hierzu gehört die Auswahl der
Metriken und analytischen Techniken, die bei der statistischen Prozesskontrolle verwendet werden. Aus
der stichprobenartigen Anwendung erhält man Informationen, die einen die Variation der Teilprozesse
verstehen lässt. Durch dieses Wissen ist es möglich, die Performanz der ausgewählten Teilprozesse zu
überwachen und nötigenfalls korrigierende Maßnahmen zu definieren und auszuführen. Die gesammelten
Informationen werden in die organisationsweite Informationssammlung eingearbeitet, damit auch andere
Projekte von den Erfahrungen profitieren können.
Das Prozessgebiet Quantitatives Projektmanagement wird im V-Modell nicht abgedeckt, da es ein Prozessgebiet
der Reifegradstufe 4 ist.
Element der Konvention wird erfüllt durch
Organizational Innovation and Deployment
Das Prozessgebiet Organisationsweite Innovation und Verbreitung beschäftigt sich mit der systematischen
Auswahl und Einführung von innovativen Verbesserungen, sodass die Prozesse und Technologien
messbar verbessert werden. Unterteilt ist das Prozessgebiet in die Auswahl und die Einführung der Verbesserungen.
Für die Auswahl ist es nötig, zahlreiche Verbesserungsvorschläge zu sammeln und zu analysieren,
um daraus dann die innovativsten und für die Organisation nützlichsten Verbesserungen
auszuwählen. Durch eine Pilotierung der Verbesserungen gewinnt die Organisation die nötigen Informationen,
um die umzusetzenden Verbesserungen auszuwählen. Die folgende Breiteneinführung der Verbesserungen
wird geplant und die Durchführung überwacht. Da eine Voraussetzung war, dass die
Verbesserungen merkbar sein sollen, werden die Effekte der Verbesserungen gemessen und alle gewonnenen
Informationen in der organisationsweiten Bibliothek abgelegt.
Das Prozessgebiet Organisationsweite Innovation und Verbreitung wird im V-Modell nicht abgedeckt, da
es ein Prozessgebiet der Reifegradstufe 5 ist.
Element der Konvention wird erfüllt durch
Causal Analysis and Resolution
Die Ursachenanalyse und Problemlösung dient der systematischen Erkennung und Behebung der Ursachen
von Fehlern. Das Prozessgebiet ist zweigeteilt in Fehleranalyse und Fehlerbehebung. Um die Ursache
der Fehler zu erkennen, werden bestimmte Fehler für die weitere Analyse ausgewählt. Durch die
folgende Analyse der Fehler werden die Ursachen ermittelt und dann Vorschläge für korrigierende Maßnahmen
entwickelt, die das künftige Auftreten dieser Fehler verhindern. Für die Behebung der Fehler ist
es nicht nur wichtig, die die korrigierenden Maßnahmen umzusetzen, sondern auch die Erfolge der Änderungen
zu evaluieren. Die gewonnenen Informationen aus Fehleranalyse und Fehlerbehebung werden der
dem Rest der Organisation zur Nutzung zur Verfügung gestellt.
Das Prozessgebiet Ursachenanalyse und Problemlösung wird im V-Modell nicht abgedeckt, da es ein
Prozessgebiet der Reifegradstufe 5 ist.
Element der Konvention wird erfüllt durch
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 124 von 129

Institutionalize a Managed Process
ERGÄNZENDE INFORMATIONEN; TABELLEN UND ABBILDUNGEN
Das Generische Ziel Institutionalize a Managed Process soll dafür sorgen, dass der Prozess aller Prozessgebiete
verwaltet und gesteuert wird.
Institutionalize a Managed Process ist im V-Modell für die behandelten Prozessgebiete komplett abgedeckt.
Element der Konvention wird erfüllt durch
Establish an Organizational Policy Organisationsspezifisches Vorgehensmodell
Plan the Process Projektplan, Projektplan
Provide Resources Ressourcenplanung
Assign Responsibility Rollen
Train People Ausbildungsplan
Manage Configurations Konfigurationsmanagement, Problem- und Änderungsmanagement
Identify and Involve Relevant Steakholders Rollen, Projektplan mit allen Projektbeteiligten abstimmen,
Projekthandbuch mit allen Projektbeteiligten
abstimmen
Monitor and Control the Process Projektstatusbericht
Objectively Evaluate Adherence Prüfprotokoll Prozess, QS-Handbuch
Review Status with Higher Level Management Entscheidungspunkte, Projektfortschrittsentscheidung
Institutionalize a Defined Process
Das Generische Ziel Institutionalize a Defined Process soll für alle Prozessgebiete einen definierten Prozess
sicherstellen.
Institutionalize a Defined Process ist im V-Modell für die behandelten Prozessgebiete komplett abgedeckt.
Element der Konvention wird erfüllt durch
Establish a Defined Process Projektspezifisches V-Modell
Collect Improvement Information Projekterfahrungen, Erfahrungsdatenbasis
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 125 von 129

B Quellenverzeichnis
[Bau93] Bauer F. L.: Software-Engineering – wie es begann. Informatik-Spektrum 16
(1993) 5, S. 259 – 260
[Schu99] V. Schuppan: Das V-Modell 97 als Softwareentwicklungsprozeß aus der Sicht des
Capability Maturity Models (CMM) für Software. Diplomarbeit an der Technischen
Universität München, Fachrichtung Informatik, München 1999.
[STA02] THE STANDISH GROUP REPORT. CHAOS.
http://www.scs.carleton.ca/~beau/PM/Standish-Report.html. 2002.
[Kneu03] R. Kneuper: CMMI – Verbesserung von Softwareprozessen mit Capability Maturity
Model Integration, dpunkt.Verlag, Heidelberg 2003.
[CMMI02] Carnegie Mellon, Software Engineering Institute: CMMI for Systems Engineering/Software
Engineering/Integrated Product and Process Development, Version
1.1, Staged Representation (CMMI-SE/SW, V1.1, Staged). Technical Report
CMU/SEI-2002-TR-012. Pittsburgh 2002.
http://www.sei.cmu.edu/publications/documents/02.reports/02tr012.html
Capability Maturity Model, Carnegie Mellon, CMM, CMMI are registered in the
U.S. Patent and Trademark Office by Carnegie Mellon University
[VM92] A.-P. Bröhl / W. Dröschel: Das V-Modell, der Standard für die Softwareentwicklung,
R. Oldenburg Verlag München Wien 1993, ISBN 3-486-22207-4
[VM97] W. Dröschel, M. Wiemers: Das V-Modell 97, der Standard für die Entwicklung
von IT-Systemen mit Anleitung für den Praxiseinsatz, Oldenbourg Verlag München
Wien 2000, ISBN 3-486-25086-8
[VMxt04] WEIT-Team: TU München, Daily Build des V-Modells XT vom 30.06.04
[WEIT03] Deubler, Gnatz, Meisinger, Rausch (TUM), WEIT Anforderungsanalyse, 08.05.03
[SPA04] Siemens Process Assessment, Questionnaire V3.0.0, CT SE3, 12.01.2004-08-06
[SCAMPI01] Standard CMMI Appraisal Method for Process Improvement (SCAMPI®), Version
1.1: Method Definition Document, Carnegie Mellon Software Engineering
Institute, December 2001
SCAMPI is service mark of Carnegie Mellon University
[SPICE04] http://www.sqi.gu.edu.au/spice/, official Web Server for the SPICE Project
[SEI04] SCAMPI® v1.1 Appraisal Results, 2003 Year End Update, March 2004
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 126 von 129

C Abbildungsverzeichnis
Seite
Abbildung 1: Struktur und sichtenbasierte Darstellung des V-Modells XT 14
Abbildung 2: Vorgehensbausteine und ihre Bestandteile 15
Abbildung 3: Landkarte der Vorgehensbausteine 16
Abbildung 4: Beispiel für Produktgruppen zum Thema Projekt 17
Abbildung 5: Strukturelle Produktabhängigkeit im V-Modell XT 18
Abbildung 6: Erzeugende Produktabhängigkeiten der Managementprodukte im
Überblick 19
Abbildung 7: Beispiel für Aktivitätsgruppen zum Thema Projekt 20
Abbildung 8: Ablaufstruktur mit Strukturierung der Aktivität „Projekt planen“ in
Teilaktivitäten 21
Abbildung 9: Projektdurchführungsstrategien 22
Abbildung 10: Projektdurchführungsstrategie, Entscheidungspunkte und Produkte 22
Abbildung 11: Reifegrad von Organisationen [SEI04] 23
Abbildung 12: Struktur der stufenförmigen Darstellung 25
Abbildung 13: Kategorien und Prozessgebiete des SPA 75
Abbildung 14: Bewertung der Prozessgebiete nach SCAMPI® 80
Abbildung 15: Bewertung der Prozessgebiete nach SPA 83
Abbildung 16: Endergebnis nach SCAMPI® und SPA im Vergleich 90
Abbildung 17: Management im Projekt: Projektmanagement 110
Abbildung 18: Management im Projekt: Lieferantenmanagement 110
Abbildung 19: Management im Projekt: QS und Reviews 110
Abbildung 20: Management im Projekt: Konfigurations- und Änderungsmanagement 111
Abbildung 21: Engineering: Anforderungsdefinition 111
Abbildung 22: Engineering: Definition von Leistungsmerkmalen und Architektur 111
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 127 von 129

ABBILDUNGSVERZEICHNIS
Abbildung 23: Engineering: Software Realisierung & Test 112
Abbildung 24: Engineering: Hardware Realisierung & Test 112
Abbildung 25: Engineering: Produktintegration und -test 112
Abbildung 26: Prozessmanagement: Definition und Pflege 113
Abbildung 27: Prozessmanagement: Standardschulung 113
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 128 von 129

D Tabellenverzeichnis
ABBILDUNGSVERZEICHNIS
Seite
Tabelle 1: Übersicht über die Vorgehensbausteine 15
Tabelle 2: Reifegrade und Prozessgebiete des CMMI® v1.1 staged SE/SW 26
Tabelle 3: Prozessgebiete des CMMI® v1.1 continuous SE/SW nach Kategorien
sortiert 28
Tabelle 4: Die sechs verschiedenen Fähigkeitsgrade (Capability Level) 28
Tabelle 5: Erfüllungsgrade und Interpretation 31
Tabelle 6: Themen in der Kategorie Management im Projekt 76
Tabelle 7: Themen in der Kategorie Engineering 77
Tabelle 8: Themen in der Kategorie Prozessmanagement 78
Tabelle 9: Erfüllungsgrade des SPA 79
Tabelle 10: Schwächen hinsichtlich Reifegrad 2 nach SCAMPI®-Verfahren 81
Tabelle 11: Schwächen hinsichtlich Reifegrad 3 nach SCAMPI®-Verfahren 82
Tabelle 12: Ergebnisse der Kategorie Management im Projekt 84
Tabelle 13: Ergebnisse der Kategorie Engineering 85
Tabelle 14: Ergebnisse der Kategorie Prozessmanagement 86
Tabelle 15: Schwächen hinsichtlich Reifegrad 2 nach SPA 88
Tabelle 16: Schwächen hinsichtlich Reifegrad 3 nach SPA 89
Tabelle 17: Mögliche Verbesserungsmaßnahmen hinsichtlich Reifegrad 2 91
Tabelle 18: Mögliche Verbesserungsmaßnahmen hinsichtlich Reifegrad 3 92
Tabelle 19: Übersicht der Bewertung des V-Modells XT entsprechend Kapitel 3 109
Bewertung des neuen V-Modells XT aus Sicht von CMMI® Seite 129 von 129