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: Betreuer: Abgabedatum: 16.08.2004 Prof. Dr. Dr. h.c. Manfred Broy Michael Gnatz (TU München) Doris Rauh (Siemens AG) Dr. Winfried Rußwurm (Siemens AG) 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
ÜBERBLICK Abbildung 1: Struktur und sichtenbasierte Darstellung des V-Modells XT 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. Produktgruppe Aktivitätsgruppe "! # # Abbildung 2: Vorgehensbausteine und ihre Bestandteile Thema Projekt Entwicklung Organisation Vorgehensbaustein 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..!!, 0 *!, 7..!, 7 1 2 34 /! 7.! / 7!, 2 "!, +!..!. * 1 2 30!. ) +!.!,,! * "! 5 5 *,!,! * "! " " *,!,! * "! 0 " 0 " *,!,! * "! 2 6,!* " 2 6 2 6 *,!,! * "! (! (! *,! &!, " *! +!, ) $ - ' " " ) $ - ' ) $ & ' " " ) $ & ' (!! " $% & ' 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
Ü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 6 %, " 6 2 2 2 3 2 2 4 8 3 2 8 3 4 8 3 2 8 3 4 8 3+ * 2 8 3+ * 4 8 3+ * 2 8 3+ * + * 3 / 4 8 3+ * 2 8 3+ * 4 8 3+ * 2 8 3+ * 4 8 3/ 2 8 3/ 4 8 3/ 2 8 3/ ( %, " & " " " 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
ÜBERBLICK.. * 1 2 34.! 7.. +!...! +!.! 0 *! 7 37 7 2 " / / 1 2 30 &,! * "! ",!* ",! * "! 5,!* 5 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: 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. Ü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
Ü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
ÜBERBLICK. *.!, *,!* 5 3,!* 2 6,!* " *. *.!, * * *. *. " *,! * 3 * * * 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
ÜBERBLICK! 2 6 *.! 2 6 *.! * "! 9. :! 8 8 / 9 : 2 6 5!, 2 6 *. + * 2 6 8! 2 6 8 / 6!,! * "! 2 6 Abbildung 9: Projektdurchführungsstrategien 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 * ; 9 < =! >: 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
Ü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. 100,00% 90,00% 80,00% % of Organisations 70,00% 60,00% 50,00% 40,00% 30,00% 29,70% 27,70% 27,70% 20,00% 10,00% 9,50% 5,40% 0,00% 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] 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
ÜBERBLICK Maturity Levels Process Area 1 Process Area 2 Process Area m Specific Goals Generic Goals Common Features Commitment to Perform Ability to Perform Directing Implementation Verifying Implementation Specific Practice 1 Specific Practice k Generic Practice 1 Generic Practice 3 Generic Practice 5 Generic Practice n Specific Practice 2 Generic Practice 2 Generic Practice 4 Generic Practice 6 Abbildung 12: Struktur der stufenförmigen Darstellung 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
ÜBERBLICK Reifegrad english Fokus deutsch Prozessgebiete Prozessgebiete nach Ralf Kneuper [Kneu03] 5 Optimizing 4 Kontinuierliche Prozessverbesserung Quantitatively Managed 3 Defined 2 Managed Quantitatives Management Standardisierung des Prozesses Grundlegendes Projektmanagement Organizational Innovation and Deployment Causal Analysis and Resolution Organizational Process Performance Quantitative Project Management Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organisationsweite Innovation und Verbreitung Ursachenanalyse und Problemlösung Performanz der organisationsweiten Prozesse Quantitatives Projektmanagement Anforderungsentwicklung Technische Umsetzung Produktintegration Verifikation Validation Organisationsweiter Prozessfokus Organizational Process Definition Organisationsweite Prozessdefinition Organizational Training Integrated Project Management Risk Management Organisationsweites Training Integriertes Projektmanagement Risikomanagement Decision Analysis and Resolution Entscheidungsanalyse und findung Requirements Management Project Planing Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process and Product Quality Assurance Configuration Management Anforderungsmanagement Projektplanung Projektverfolgung und steuerung Management von Lieferantenvereinbarungen Messung und Analyse Qualitätssicherung von Prozessen und Produkten Konfigurationsmanagement 1 Initial chaotisch -- -- Tabelle 2: Reifegrade und Prozessgebiete des CMMI v1.1 staged SE/SW 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