The Capability Maturity Model. Das Modell der Reifegrade - Seminar Informatik - Shavrov Anton 11040090

The Capability Maturity Model.
        Das Modell der Reifegrade.
                           Seminar Informatik.

Shavrov Anton   11040090

                                   -1-

Inhaltsverzeichnis.

1. Einführung in Capability Moturity Model(CMM). _____________________________ 3
     1.1    Geschichtliche Entwicklung. _______________________________________________ 4

2.     Capability Maturity Model Integration (CMMI) ist ein Nachfolgermodel. _______ 4

3. Andere Prozessbeurteilungsverfahren. _______________________________________ 6

4. Unreife vs. reife Software-Organisationen.____________________________________ 7

5.     Grundlegende Begriffe des Reife-Prozesses._________________________________ 7

6.     Grundgerüst des Capability Maturity Models. ______________________________ 9
     6.1 Grundebene (Initial Level). ___________________________________________________ 9
     6.2 Ebene der Wiederholbarkeit (Repeatable Level). _________________________________ 9
     6.3 Definierte Ebene (Defined Level). _____________________________________________ 10
     6.4 Lenkbare Ebene (Managed Level). ____________________________________________ 10
     6.5 Ebene der Optimierung (Optimizing Level). ____________________________________ 10

7. Interne Struktur des Capability Maturity Models. ____________________________ 11

8. Praktische Anwendung - C3 Project Chrysler Extreme Programmierung. ________ 12

9. Statistik der Bewertung internationaler Unternehmen durch CMM(I). ___________ 15

10. Zusammenfassung. _____________________________________________________ 17

11. Quellen._______________________________________________________________ 19

                                            -2-

1. Einführung in Capability Moturity Model(CMM).
Fast alle Organisationen haben ein Problem in einer festgelegten Zeit, mit einem begrenzten
Budget und der Einhaltung von bestimmten Qualitätsanforderungen eine Software zu
entwickeln. Die Problematik wurde sehr ernst genommen nach der Durchführung einer Reihe
von Statistiken und dem Scheitern der großen Projekte im Militärbereich inden USA. Ein
nicht publizierter Review des Verteidigungsministeriums (Department of Defence) hat
ergeben, dass siebzehn bedeutende Projekte im Verzug waren. Ein vier jähriges Projekt wurde
nicht nach sieben Jahren abgeliefert. Der Einsatz von B1 Bombenflugzeugn wurde wegen des
Softwareproblems verlegt. 1

Das Problem war auch in der Industrie bekannt. In den USA steigen die Ausgaben für
Software jedes Jahr ca. um 12%. Außerdem wächst immer mehr das Verlangen nach neuen
Funktionen und Anwendungen. Die Situation lässt sich durch die Aussage eines Senior
Manager beschreiben : “I'd rather have it wrong than have it late. We can always fix it later.”

Für die Auftraggeber führt dies dazu, dass sie Software nicht wie bestellt bekommen und
dadurch typischerweise Zusatzkosten haben, sei es, weil die Entwicklung als solche teurer
geworden ist oder weil der von der neuen Software erwartete Nutzen nicht oder zumindest
erst später realisiert werden kann.

Der Auftragnehmer hat im günstigsten Fall, wenn z.B. die Strafe nicht vertraglich festgelegt
ist, nur den Imageschaden. Das allein kann schon für ein Unternehmen schlechte Folge haben.

Für die Lösung dieses Problems hat das amerikanische Verteidigungsministerium die
Gründung eines Software Engineering Institutes (SEI) veranlasst. Die Aufgabe des Institutes
war die Software-Praktiken in der amerikanischen Industrie zu verbessern. Das musste auch
die Möglichkeit dem Ministerium geben, seine eigenen Auftragnehmer zu bewerten, damit
man sicher sein kann, dass die Software, wie versprochen, geliefert werden kann. Demgemäß
ist ein Capability Maturity Model (CMM) entstanden.

Die Hauptrichtlinie bei CMM ist die Bereitstellung der Methoden zur Bewertung der
Fähigkeiten der respektiven Reife einer Softwareorganisation und die Bestimmung der
Maßnahmen zur ihrer Verbesserung. Dabei geht man davon aus, dass die Qualität eines
Softwareproduktes von der Qualität der Entwicklungsprozesse abhängt, mit denen es
hergestellt wird.

Das Bewertungsverfahren durch einen Fragebogen wird als „Assessment“ bezeichnet.
Dieser Fragebogen kann auf den in CMM festgelegten Fragen zur Bestimmung der Ebene der
Organisation basieren. Eine Ebene wird durch die 18 Hauptkriterien, Schlüsselbereichen (Key
Process Areas) definiert. Ein Hauptkriterium wird durch bestimmte Aspekte oder Key
Practices bezeichnet. Sie schreiben vor, was getan werden muss, um das jeweilige
Hauptkriterium zu erfüllen.

1. The Capability Maturity Model:Guidlines for Improving the Software Process Addison-Wesley publishing
   company ISBN:0-201-54664-7

                                                  -3-

Es wird jedoch nicht festgelegt, wie das umgesetzt werden soll. CMM definiert also keine
Prozesse sondern lediglich deren Verwendung und Nutzen. Der Fragebogen bildet das
Herzstück von CMM. Anhand der Auswertung des Assessments kann der Reifegrad bzw.
Ebene der Softwarefirma bestimmt werden. Erreichen einer Ebene liefert ein Kriterium für
die Beurteilung der Kompetenz einer Organisation.

   1.1 Geschichtliche Entwicklung.
   •    1986 startete auf Initiative des US-Verteidigungsministeriums das Software
        Engineering Institute an der Carnegie Mellon University in Pittsburgh, welches dem
        US-Verteidigungsministerium untersteht, die Entwicklung eines Systems zur
        Bewertung der Reife von Softwareprozessen.
   •    1987 wurde die Software Proccess Maturity Framework freigegeben.
   •    1991 wurde das Modell als Capability Maturity Model 1.0 herausgegeben.
        Dabei wurde bei Assessments auf Maturity Questionnaire betont.
   •    1993 wurde es auf Grund von Rückmeldungen aus der Industrie überarbeitet und in
        der Version 1.1 bereitgestellt.
   •    1997 wurde CMM 2.0 kurz vor der Verabschiedung vom US-
        Verteidigungsministeriums zurückgezogen, stattdessen wurde das CMMI-Projekt
        gestartet.
   •    2000 wurde im Herbst CMMI - damals noch unter dem Namen Capability Maturity
        Model Integrated - als Pilotversion 1.0 herausgegeben.
   •    Anfang 2002 wurde CMMI unter dem neuen Namen Capability Maturity Model
        Integration (kurz CMMI) freigegeben.
   •    Ende 2003 ist die Unterstützung des SEI für die alte Version CMM ausgelaufen. Jetzt
        wird nur noch CMMI unterstützt.
   •    2005 wurde die CMMI-Version 1.2 für Herbst 2006 angekündigt. Die Unterstützung
        des SEI für CMMI Version 1.1 soll danach noch bis Ende 2007 weiterlaufen.
   •    Ende 2005 laufen die Lizenzen der Assessmentleiter für CMM aus, d. h. es gibt keine
        offiziellen CMM-Assessments mehr.
   •    Am 25. August 2006 ist die neue Version 1.2 des CMMI veröffentlicht worden. Mit
        dem neuen Release sind einige grundlegende Veränderungen einhergegangen. So
        wurde u. A. die neue Version auf CMMI-DEV umbenannt.1

 2. Capability Maturity Model Integration (CMMI) ist
                 ein Nachfolgermodel.
Seit August 2006 ersetzt CMMI die ältere Version des Software Capability Maturity Models.
Es wurde ebenso am Software Engineering Institute der Carnegie Mellon University in
Pittsburgh im Auftrag des amerikanischen Verteidigungsministeriums entwickelt. Im
neuenModel wird einen größeren Wert auf Modularität gesetzt. Dieses modulare Konzept
bewirkt

   1.   http://de.wikipedia.org/wiki/Capability_Maturity_Model_Integration

                                                   -4-

die Integration weiterer Entwicklungsdisziplinen. CMMI sammelt alle aus dem CMM
gewonnen Erfahrungen und Verbesserungen. Das Nachfolgemodel verfügt über die
einheitlichere Struktur und kann in anderen Bereichen außer der Softwareentwicklung
verwendet werden. Außerdem hat das neue Model zwei Arten der Darstellung:
eine stufenförmige (Staged Representation) mit ebenfalls fünf Stufen und eine kontinuierliche
(Continuous Representation). Die kontinuierliche Art stellt die Reife einer Organisation
detaillierter dar. Dabei wird pro Prozessgebiet , einen so genannten Fähigkeitsgrad auf einer
Skala von 0 bis 5, gegeben. Darüber hinaus gibt es neben der Unterscheidung zwischen zwei
Arten der Darstellung mehrere unterschiedliche Varianten, die eine Abhängigkeit von einem
Anwendungsbereich aufweisen.

 Neuerungen in CMMI gegenüber CMM.
 Neue Schlüsselbereiche (Key Process Areas).
    - fasst über Schlüsselbereiche verteilte Anforderungen an einer Stelle zusammen.

Umbenennung.
   - Software Projekt Planning in Project Planning.
   - Software Projekt Tracking und Oversight in Projekt Monitoring and Control
   - Software Subcontract Management in Supplier Agreement Management
   - Software Quality Assurance in Process and Product Quality Assurance
   - Software Configuration Management in Configuration Manamement.

Neue Prozessgebiete.
     - Anforderungsentwicklung
     - Technische Umsetzung
     - Produktintegration
     - Verifikation
     - Validation
     - Integriertes Projektmanagement
     - Risikomanagement
     - Entscheidungsanalyse und Entscheidungsfindung

Folgende Prozessgebiete fallen weg.
     - Integrated Softwaremanagement
     - Software Produkt Engineering
       entfällt ganz als eigenes Prozessgebiet, Inhalte sind jetzt auf mehreren Prozessgebieten
       verteilt.
     - Intergroup Coordination
     - Partnerreviews
        ist jetzt Teil von „Verifikation“ geworden.

Keine wesentlichen Änderungen.
     - Organisationsweiter Prozessfokus
     - Organisationsweite Prozessdefinition
     - Training Programm ist organisationsweites Training

                                             -5-

3. Andere Prozessbeurteilungsverfahren.
Es existiert eine Reihe der anderen Prozessbeurteilungsverfahren beziehungsweise Modele
für das Qualitätsmanagement, die dem CMM verwandt sind. Eine kurze Übersicht über einige
Modele wird im folgenden Abschnitt der Arbeit dargestellt.

ISO 9001.
Dieses Model ist sehr verbreitet und bekannt in Europa. Es stammt aus der
Fertigungsindustrie und im Vergleich mit CMM viel allgemeiner formuliert.
Die Allgemeinheit ermöglicht den Einsatz des Verfahrens fast in allen Branchen von
Schraubenproduktion bis zur Softwareentwicklung. Andererseits bietet es im Bezug auf
konkretes Problem weniger anwendbare Hilfsmittel als CMM auf Grund der Abstraktion an.
Es gibt allerdings die Richtlinie ISO 90003:2004 und
ISO 9001:2000 für die Anwendung im Bereich Software- und Systementwicklung. Ein
Vorteil des dargestellten Model ist es, dass es alle wesentlichen Geschäftsprozesse abdeckt.

Bootstrap.
Das Verfahren wurde von vieleneuropäischen Organisationen im Auftrag der EU
bereitgestellt. Das Model sollte mehr als CMM an die europäischen Anforderungen angepasst
werden und mehr zur Konjunktur passen. Bootstrap verwendet eine kontinuierliche
Darstellung. Dies kann mit einer Variante im CMMI verglichen werden. Momentan ist das
Verfahren von ISO 15504abgelöst.

ISO 15504 (SPICE).
Diese ISO-Norm ist sehr unter dem Namen SPICE verbreitet. Das Akronym SPICE steht für
Software Process Improvement and Capability dEtermination. Das Verfahren definiert einen
Rahmen für Reihfegrademodelle und zugehörige Bewertungsmethoden.

Bei der Entwicklung von CMMI war die Zielsetzung mit SPICE kompatibel und konsistent zu
bleiben.

European Foundation for Quality Management (EFQM)
Das Geschäftsfähigkeitsmodel der EFQM ist ein Modell für ein komplettes
Qualitätsmanagement - Total Quality Management. Es ist die Grundlage für den jährlich zu
vergebenen Europäischen Qualitätspreis. Das Model besteht aus zwei Teilen, eine Hälfte ist
Befähiger, die Qualität ermöglichen und der andere Teil sind die Ergebnisse der Befähiger. Zu
den Befähigern gehört die Nutzung definierter und kontinuierlich verbesserter Prozesse. Im
Bezug auf CMMI kann man sagen, dass es diesen Bereich zum großen Teil abdeckt, währen
die anderen Komponenten in CMMI fast nicht ausgearbeitet werden. Eine weitere Abbildung
1 stellt die Struktur des EFQM-Models dar.

                                           Abbildung 1

                                            -6-

4. Unreife vs. reife Software-Organisationen.
Um es nachvollziehen zu können, welche Verbesserungsmaßnahmen für ein Unternehmen
wirklich erforderlich sind, stellt CMM in der ersten Linie einen Unterschied zwischen einer
reifen und einer unreifen Organisation vor.

Bei einem unreifen Unternehmen wird der Softwareprozess generell im Laufe des ganzen
Projektes improvisiert. Selbst wenn der Softwareprozess spezifiziert ist, werden die
festgelegten Richtlinien nicht eingehalten. Die unreifen Organisationen sind in der Regel
rückschrittlich und ihre Manager sind nur auf die Überwindung der sofortigen Krisen
fokussiert. Solche Unternehmen überschreiten oft auf Grund fehlender Basis für die objektive
Bestimmung eigener Produktivität Ihren Fristablauf. In äußerst kritischen Fällen, kann für die
Einhaltung der Termine, ein bestimmter Teil der Funktionalität bzw. Qualität geopfert
werden. Die unreifen Organisationen haben also keine objektive Basis für die Bestimmung
der Produktqualität und der Lösung akuter Probleme, wie auch wenig Verständnis für den
Zusammenhang zwischen dem Prozess und Qualität. Die Produktqualität ist schwer vor zu
bestimmen. Der Auftraggeber hat kaum Einsicht in das Produkt bis zur Abnahme.

Die reifen Organisationen sind durch die gesteuerten Softwareentwicklungen und gut
definierte, unternehmensweite Entwicklungsprozesse gekennzeichnet. Alle Aktivitäten
werden nach einem vorgeschriebenen Plan durchgeführt. Die Planung ist hinreichend exakt
und verlässlich. Die Prozessdefinitionen werden bei dem Bedarf aktualisiert und die
Verbesserungen werden durch Pilot-Tests respektive Gewinn und Verlust-Analyse
gewährleistet. Rollen und Verantwortung bezüglich des Prozesses sind verständlich für das
ganze Projekt und die ganze Organisation. In den reifen Unternehmen überwachen Manager
die Qualität des Softwareproduktes und damit verbundene Entwicklungsprozesse. Es gibt eine
objektive, quantitative Basis zur Bestimmung der Produktqualität und Analyse der Probleme
mit dem Produkt und Prozess. Die Erwartungen für die Kosten, Planung, Funktionalität und
Qualität des Produktes werden in der Regel erfüllt. Im Allgemeinen folgen die reifen
Organisationen konsistent dem disziplinierten Prozess, weil alle Teilnehmer Ihnen gestellten
Aufgaben gut nachvollziehen, und die benötigte Infrastruktur vorhanden ist.

   5. Grundlegende Begriffe des Reife-Prozesses.
In diesem Teil der Arbeit werden die grundlegenden Begriffe vorgestellt, die eine Basis für
das Verstehen der Reife eines Softwareprozesses bilden und zur Beschreibung der Reife einer
Softwareorganisation dienen. CMM ist auf die Fähigkeit einer Organisation fokussiert, die
hoch qualitative Softwareprodukte liefert.

Die erste Frage, die beantwortet werden sollte, was ist ein Prozess? Ein Prozess ist eine
Sequenz der Schritte zum Erreichen eines bestimmten Ziels. Ein Prozess nimmt die Leute,
Werkzeuge und Methoden auf. Dies wird in der nächsten Abbildung 2 veranschaulicht.

Ein Softwareprozess kann definiert werden als „eine Menge von Aktivitäten und damit
zusammenhängenden Ergebnissen, die zur Herstellung eines Softwareprodukts führen.“1
Bei den reifen Organisationen wird ein Software Prozess besser definiert und implementiert.

1. Software Engineering ISBN 3-8273-7001-9 Auflage 6 2001

                                               -7-

Abbildung 21

Der Schwerpunkt eines Softwareprozesses legt CMM auf die Befähigung der Leute ihre
Arbeit zu leisten. Ein effektiver Softwareprozess bindet die Leute, Werkzeuge und Methoden
in eine integrierte Einheit zusammen.

Software Process Capability beschreibt eine Reihe der erwarteten Ergebnisse, die bei der
Ausführung des Software-Prozesses erreicht werden können. Software Process Capability
einer Organisation sorgt dafür, dass es auch für das nächste Projekt die Ergebnisse sowie die
Qualität vorhersagbar sein werden.

Softwareprozess Performanz stellt die aktuellen Ergebnisse eines Softwareprozesses dar.
Dabei wird auf erreichte Resultate fokussiert, währen Software Process Capability sich für die
Erwartungen interessiert.

Softwareprozess Reife ist ein Maß für die Bezeichnung eines bestimmten Prozesses, der
explizit definiert, gesteuert, gemessen, kontrolliert und effizient ist. Die Reife bedeutet ein
Potential für das Wachstum der Fähigkeiten und zeigt den Reichtum eines Prozesses einer
Organisation an. Außerdem wird es die Konsistenz eines Prozesses für die Projekte innerhalb
des Unternehmens aufgedeckt.

Infrastruktur ist das grundlegende Gerippe einer Organisation oder Systems. Darin werden
die Struktur, Methoden, Standard, Training, Einrichtungen und Werkzeuge eingeschlossen,
um die Performanz des Unternehmens zu unterstützen.

Institutionalisierung ist die Bildung einer Infrastruktur und Kultur, um die Methoden,
Praktiken und Prozeduren zu unterstützen. Das Ergebnis von Institutionalisierung ist die
organisationsweite Aufstellung eines effektiven, konsistenten Softwareprozesses.

1. The Software Engineering Institute. CMMI Product Team CMMI® for Development, Version 1.2

                                                 -8-

6. Grundgerüst des Capability Maturity Models.
   Die Grundlage eines kontinuierlichen Verbesserungsprozesses ist ehe eine Anzahl von
   kleinen evolutionären Schritten als eine revolutionäre Innovation. Die Schritte werden in
   CMM durch fünf Reifenebenen oder -stufen repräsentiert. Diese fünf Stufen definieren
   eine Scala für die Messung des Reifengrades des Softwareprozesses der Organisation und
   die Erhöhung der Qualität des Prozesses selbst. Die Reifeebenen stellen eine gut definierte
   Evolutionsgrundlage für das Erreichen der Reife eines Softwareprozesses dar. Jede Ebene
   schließt eine Anzahl der Ziele ein, bei deren Erreichen man eine wichtige Komponente
   des Softwareprozesses stabilisiert. Die fünf Reifeebenen sind in der Abbildung 3
   dargestellt.

                                                          Abbildung 3
   6.1 Grundebene (Initial Level).
Auf dieser Ebene gibt es keinen definierten Softwareprozess und keine stabile Umgebung für
die Entwicklung. Bei dem Eintreffen von Krisen werden alle geplanten Vorgehensweisen
weggelassen und durch Kodieren und Testen(Code&Fix) ersetzt. Im Laufe der Entwicklung
werden ständige Änderungen und Modifizierungen vorgenommen. Aus diesem Grund ist die
gute Produktion nur von dem gut qualifiziertem Personal und ihrem großem Einsatz abhängig.
Man kann auch nicht vorhersagen, mit welcher Qualität und zu welchem Zeitpunkt das
Produkt fertig gestellt wird. Das Budget wird meistens überschritten. Durch den Einsatz der
guten Manager kann der Prozess zwar gekräftigt werden, hängt aber völlig von dem Personal
ab. Die Fähigkeiten der Organisation der Ebene 1 sind personen- und nicht
organisationsbezogen.

   6.2 Ebene der Wiederholbarkeit (Repeatable Level).
 Die Ebene zwei kann durch Maßnahmen einer geordneten Steuerung und Verfolgung
charakterisiert werden. Das bedeutet, dass der Prozess auf dieser Ebene schon definiert ist.
Die Ablaufplanung ist auf der positiven Erfahrung aus den früheren und ähnlichen Projekten
aufgebaut. Das erlaubt eine grobe Abschätzung der Projekte aus der Analogie.
Prozessfähigkeit wird durch das disziplinierte Management deutlich verbessert. Die Manager
verfolgen die Kosten der Software, Ablaufplanung und Funktionalität. Darüber hinaus wird
eine einfache Kontrolle eingeführt. Dies führt zu einer gewissen Vorhersagbarkeit und
Verbesserung des Prozesses, obwohl man noch bemerken muss, dass die Prozessqualität auf
dieser Stufe noch nicht genügend ist.

                                            -9-

6.3 Definierte Ebene (Defined Level).
Auf der dritten Ebene sind alle Entwicklungs- und Managementprozesse vollständig definiert,
dokumentiert und unternehmensweit eingeführt. Die Integration des Softare-Engineerings und
Managementprozesses in ein Ganzes, bildet ein Standard-Softwareprozess der Organisation.
Die Organisation verwendet effektiv die Methoden aus dem Bereich Software Engineering
während der Standardisierung der Softwareprozesse. Diese Stufe wird auch durch die
Bildung einer Gruppe(Software Engineering Process Group) bezeichnet, die für die
Prozessaktivitäten beziehungsweise für die Umsetzung verantwortlich ist. Die Definition der
Prozesse soll es den Verantwortlichen ermöglichen Ihre Arbeit effizent zu leisten, ohne
dabei die Prozesse hemmend und unflexibel werden zu lassen. Ein definierter Prozess folgt
einer Reihe der vorgeschriebenen Techniken zur Durchführung und Verwaltung der Arbeit.
Dabei existieren Eingans- bzw. Ausgangskriterien, die Maßnahmen zur Sicherstellung der
Qualitätund die Methoden für die Steigerung der Performanz der Arbeit. Außerdem werden
für die Erhöhung der Qualität der Arbeit und somit des Prozesses die Trainingprogramme für
den Entwicklung- bzw. Verwaltungspersonal eingeführt.

Die Prozessfähigkeiten der Ebene 3 kann man als konsistent charakterisieren. Ferner werden
die Produktrichtlinie, Kosten, Planung, Funktionalität und Softwarequalität kontrolliert und
verfolgt. Die Organisation der dritten Ebene hat einen Überblick und Kontrolle über die
geführten Aktivitäten. Aber die Qualität des Softwareprozesses ist immer noch
Schwankungen ausgesetzt.

   Lenkbare Ebene (Managed Level).
Die vierte Ebene ist durch die Formulierung und Überwachung der quantitativen Ziele für
das Softwareprodukt gekennzeichnet. Die Produktivität und Qualität werden als die wichtigen
Aktivitäten des Softwareprozesses gemessen, um zahlreiche Aspekte des Prozesses zu
erfassen. Die Messungen werden in einer organisationsweiten Datenbank abgelegt, um die
Basis für die Analyse und Prozessverbesserungen zu ermitteln. Die Projekte erreichen die
Kontrolle über Ihre Produkte und Prozesse bei kleiner Schwankung der Leistung.

Die Prozessfähigkeiten der Ebene sind vorhersagbar. Die Organisationen dieser Stufe können
die Prozessgüte einschätzen, aber sie verfügen über kein Wissen, wie ihre Prozesse verbessert
werden können.

   6.5 Ebene der Optimierung (Optimizing Level).
Auf der Ebene 5 wird die ganze Organisation auf kontinuierliche Verbesserung des eigenen
Prozesses ausgerichtet. Ein Unternehmen ist in der Lage die Schwächen zu erkennen und
vorbeugende Maßnehmen zu treffen. Die gesammelten Messdaten werden für die Gewinn-
und Verlust-Rechnung gebraucht, um den Einsatz der neuen Technologien oder Änderungen
an dem Produkte beurteilen zu können. Die festgestellten Verbesserungsmöglichkeiten
werden organisationsweit eingeführt. Softwareteams der Ebene 5 untersuchen die Fehler, um
Ihre Ursachen zu identifizieren. Auf dieser Grundlage werden die Vorgehensweise so
geändert, dass man die Ursachen der Fehler möglichst ausschließt.

Die Prozessfähigkeiten der Ebene 5 kann man als „selbstverbessernd“ bezeichnen.

                                            - 10 -

7. Interne Struktur des Capability Maturity Models.
Im folgenden Abschnitt der Arbeit wird ein Überblick über die ganze Struktur des CMMs
gegeben. Wie schon bereits erwähnt wurde, bilden die Reifeebenen ein Grundgerüst des
Models. Jede Reifestufe wird auf weitere Elemente geteilt. Ausschließlich der Ebene 1(siehe
Abbildung 4), enthalten alle Stufen eine Reihe der Komponenten der abstrakten
Aufstellungen bis hin zu den Aktivitäten in den Schlüsselpraktiken.

                                                            Abbildung 4

Reifeebenen(Maturity Leveles).

Eine Reifeebene ist eine gut definierte Grundlage für das Erreichen eines reifen
Softwareprozesses. Jede Reifestufe zeigt das Niveau der Prozessfähigkeit, wobei
Prozessfähigkeit eine Reihe von erwarteten Ergebnissen beschreibt, die bei dem Folgen dem
Softwareprozess bereit gestellt werden können. Prozessfähigkeit einer Organisation dient zur
Prognose der Erfolge für die erwartenden Softwareprodukte.

Schlüsselbereiche(Key Process Areas).

Bis auf die Ebene 1 sind alle Reifestufen auf einige Schlüsselbereiche zerlegt. Ein solcher
Bereich zeigt einen Mittelpunkt für die Verbesserung des Softwareprozesses an, d.h. es
werden Ergebnisse für das Erreichen bestimmter Ebene festgelegt.

Jeder Schlüsselbereich legt eine Menge der Aktivitäten fest, deren vollständige Ausführung
bei der wichtigen Verbesserung und Erreichung der Prozessziele hilft. Die Schlüsselbereiche
aufeinander folgender Stufen bauen aufeinander auf. Die Art und Weise für die Erfüllung der
Ziele ist nicht definiert und hängen von dem Projekt und seiner Umgebung ab.

Die Ziele eines Schlüsselbereiches fassen seine Praktiken zusammen und können verwendet
werden, um nach zu weisen, ob eine Organisation oder ein Projekt effizient den

                                             - 11 -

Schlüsselbereich implementiert hat. Die Ziele bezeichnen den Umfang und den Rahmen
eines Bereiches.

Relevante Aspekte (Common Features).

Die Praktiken jedes Schlüsselbereichs sind zwecks besserer Bequemlichkeit in relevante
Aspekte organisiert, die eine Reihe von Attributen enthalten, mit deren Hilfe man verfolgen
kann, ob die Implementierung und Institutionalisierung eines Schlüsselbereiches effizient,
wiederholbar und nachhaltig ist. Man unterscheidet zwischen fünf relevante Aspekte:

Commitment to Perform : es werden Aktivitäten beschrieben, die umgesetzt werden sollten,
um sicher zu stellen, dass der Prozess aufgestellt ist.

Ability to Perform: es werden Vorbedingungen beschrieben, die notwendig sind, um den
Prozess mit Kompetenz zu verbessern.

Activities Performes: es werden die Rollen und Vorgänge beschrieben, um einen
Schlüsselbereich zu entwickeln.

Measurement and Analysis: es werden die Bedürfnisse beschrieben, um den Prozess zu
messen und Aufmass zu analisieren.

Verifying Implementation: es werden notwendige Schritte beschrieben, um sich zu
vergewissern, dass die Aktivitäten im Einvernehmen mit dem Prozess ausgeführt werden.

Schlüsselpraktiken (Key Practices).

Jeder Schlüsselbereich wird durch eine Anzahl der Schlüsselpraktiken festgelegt.
Eine Schlüsselpraktik beschreibt die Aktivitäten und Infrastruktur, mit deren Hilfe man in der
Lage ist, wirksam einen Schlüsselbereich zu implementieren und institutionalisieren.

Ein Schlüsselbereich stellt nur allgemeine Maßnahmen dar. Er schreibt aber nicht vor, wie
man das umsetzen sollte und welche Werkzeuge oder Techniken man beispielsweise
einsetzen muss.

Jeder Schlüsselbereich schließt nur einen einzigen Satz ein, der oft von einer detaillierten
Beschreibung gefolgt wird, die Beispiele und die Ausarbeitungen enthalten kann.

 8. Praktische Anwendung - C3 Project Chrysler
                            Extreme Programmierung.
In diesem Abschnitt wird ein Projekt, nämlich das Chrysler C3 Projekt im Bezug auf
Capability Maturity Model dargestellt. Ein Merkmal dieses Projektes ist, dass es auf dem
Exterme Programming(XP) beruht. Das kann etwas verwirrend sein, weil es Meinungen gibt,
dass die Extreme Programmierung nicht über Ebene 1 des CMMs hinaus geht. Das liegt an
der fehlenden Organisation, Dokumentation und nicht genügender Kontrolle über das Projekt.
Des Weiteren werden verschiedene Gemeinsamkeiten der Extreme Programmierung mit
CMM betrachten, die auf höhere Ebenen abgebildet werden.

                                             - 12 -

Ebene 1 - Grundebene.

Eigenschaften:

   -   keine stabile Umgebung für die Entwicklung.
   -   oft vorhandene Überforderung
   -   im Krisenfall Verzicht auf die Anforderungen
   -   Abhängigkeit des Erfolgs nur vom Personalkompetenz

Extreme Programmierung ist in zwei Ebenen der Terminplanung angeordnet, die den
Ablaufplan bestimmen. Diese Ebenen heißen Commitment Schedule and Iteration Plan und
sind auf der Einschätzung des Entwickler und seiner Erfahrung basiert. Das Resultat des
Commitment-Schedule-Prozesses ist eine umfangreiche Bestimmung des zu entwickelnden
Produktes und der Frist. Der Iteration Plan ist die Ruckkopplung an Commitmen Schedule,
die in kurzen Intervallen stattfindet und die Verfeinerung des Ablaufplans zum Ziel hat.

Der Fortschritt von C3 lässt sich auf keinen Fall als kritisch charakterisieren. Das C3-Team
verweigert explizit den großen, heroischen Einsatz und arbeitet fast ohne Überstunden. Eine
Neigung zur heroischen Taten ist ein Anzeichen für die bestehenden Probleme. In diesem Fall
wird die Situation analysiert und der Entwicklungsprozess korrigiert.

Die Mitglieder des C3-Teams sind kompetent aber nicht außergewöhnlich. Zur Steigerung der
Effizienz wird das Pair-Programming verwendet. Bei diesem Verfahren werden zwei Leute
eingesetzt, eine Person, die das bessere Verständnis über den aktuellen Zustand des Ablaufs
hat, schreibt den Code, die Andere überwacht den Prozess und den entwickelnde nTrend,
dabei korrigiert sie die aufgetretenen Fehler.

Der Teammanager bietet keine außergewöhnliche Unterstützung. Der Teammanager dient nur
zum Zweck der Verfolgung des Fortschrittes und als Schnittstelle zu Management.

Ebene 2 – Wiederholbarkeit.

Eigenschaften:

- effektive Prozessimplementierung auf Grund der vorhandenen Definitionen, Dokumenten,
  gesammelten Erfahrungen, der Übungen, Messungen und der Möglichkeit zur
Verbesserung.

 Extreme Programmierung offensichtlich spezifiziert eine Menge von Praktiken
 (Extreme Programming Rules). Diese Regeln sind gut definiert und dokumentiert.
Das Team wurde zum Anfang des Projekts gut vorbereitet, hatte Vollzeit-Coaching und übte
die Methoden und Vorgehensweise des Teams. Pair Programming und ein offener Prozess
gewährleistet allen Entwicklern zu wissen, in welchem Stand sich das Projekt befindet. In
seltenen Fällen konnten Entwickler, die die Teampraktiken nicht einhalten, gemahnt oder aus
dem Projekt ausgeschlossen werden.

Die Praktiken können angereichert werden und sie werden ständig verbessert.

                                           - 13 -

Weitere Eigenschaften:

   -   Managers des Projekts verfolgen den Aufwand, die Termineinhaltung und
       Funktionalität
   -   Identifizierung der Probleme bei der Entstehung.

In Extreme Programmierung werden vier Komponenten verfolgt, nämlich die Ressourcen,
den Rahmen, die Qualität und Zeit. Diese Komponente erlauben fest zu stellen, ob der
Terminplan mit entsprechender Qualität erreicht werden kann. Die Information über diese
Komponenten werden im Laufe des Projektes regelmäßig dem höheren Management
bereitgestellt.

Definierte Ebene.

Eigenschaften:

   -   Software Engineering-, Managementprozesse sind die Beistandteile des
       Softwareprozesses.
   -   Prozesscharakteristik mithilfe der Bereitschaftskriterien, den
       Verifikationsmechanismus, den Outputs, den Inputs, dem Endfertigungskriterium
   -   Leichte Einsicht in technischen Fortschritt.

Extreme Programmierung Methoden umfassen die Bereitschaftskriterien Inputs (Benutzer-
Geschichte), Standarten und Prozeduren (zahlreiche „Extreme Programming Rules“),
Verifikationsmechanismus (Unit-Test und Systemtest), Output (Software)und
Endfertigungskriterium (Abnahme durch einen Benutzer)

Verwendung von vier Komponenten: die Ressourcen, den Rahmen, die Qualität und Zeit
ermöglichen dem Management einfache und verständliche Einsicht in die aktuelle
Projektperformanz.

Lenkbare Ebene.

Eigenschaften:

- quantitativ qualitative Ziele sowohl für das Softwareprodukt als auch für den
Softwareprozess.

Für die Extreme Programmierung werden die qualitativen Ziele für das Produkt durch
Systemtest nachgeprüft. Außerdem ist es erforderlich, dass das Unit-Test ständig 100% erfüllt
hat. Der Auslastungsfaktor wird durch das Verhältnis der vergangenen Zeit zu dem vom
Entwickler abgeschätzten Schwierigkeit bestimmt. Der Faktor wird nicht als quantitatives Ziel
gesetzt, sondern es erlaubt die Durchführung und Bewertung der Veränderung, die zur
Verbesserung des Prozesses führen.

Wenn der Terminplan eingehalten ist und die Ergebnisse des Tests positiv sind, werden
keine anderen quantitativen Werte untersucht. Einige Kandidaten für die Bewertung könnten
zum Beispiel eine bestimmte Anzahl von Unit-Tests bzw. Systemklassen sein.

Bei der Betrachtung auf Extreme Programmierung im Zusammenhang mit CMM, besonders
wenn XP innerhalb des ganzen Unternehmens eingesetzt wird, könnte man vermuten, dass

                                            - 14 -

etwas mehr Messungen bzw. Auswertungen durchgeführt werden müssen als im Rahmen
dieses einzelnen Projektes nötig war. Eine interessante Frage unter diesen Umständen ist es,
wie viel ist in diese Messungen zu investieren? Eine Empfehlung seitens Extreme
Programming wären nur die Werte zu analisieren, bei deren Messung niedrige Kosten
entstehen und sich nur dann damit beschäftigen, wenn das wirklich notwendig ist. Ein anderer
Ratschlag ist Messungen zu protokollieren, wenn das nicht teuer ist, aber sie nur bei Bedarf
aus zu werten. Ansonsten werden die Ressourcen umsonst aufgewendet, die für die weitere
Entwicklung eingesetzt werden könnten.

Ebene der Optimierung.

Eigenschaften:

   -    Fehleranalyse
   -    Verbesserung des Softwareprozesses zwecks der Vermeidung von Fehlern.
   -    Verbreitung der gesammelten Erfahrung innerhalb der Organisation.

In einer der Phasen der Extreme Programmierung findet ein Implementierungstest statt.
Dabei werden bestimmte Fehler aufgedeckt, die anschießend korrigiert werden müssen, um
die Tests zu bestehen. Die Erfahrung aus den erfolgreichen Testfällen wird ferner auf die
gleichartigen Anwendungsgebiete übertragen.1

9. Statistik der Bewertung internationaler
                           Unternehmen durch CMM(I).
In diesem Kapitel wird eine Übersicht über den Stand der Reifegrade beziehungsweise
Adaptation von CMM(I) verschiedener Organisationen respektive Unternehmen weltweit
vermittelt. Die Reifegrade werden durch von dem Software Engineering Institute
bereitgestellten Bewertungsmethoden bestimmt. Die Bewertungen werden ab April 2002
innerhalb von 52 Monate, also bis Juli 2006 durchgeführt. In dieser Frist wurden 1581
Bewertungen eingereicht.

Abbildung 5 veranschaulicht die Verteilung aller Organisation über die CMM(I) Stufen.
Dabei fällt es auf, dass die meisten Unternehmen sich auf den Ebenen zwei und drei
positionieren und dabei die Stufen Managed und Defined erreicht haben.

   1.   http://www.xprogramming.com Ron Jeffries 01/01/2000

                                               - 15 -

Abbildung 51

Die Abbildung 6 zeigt die Statistik über die Verteilung der Branchen, aus denen die
bewerteten Organisationen stammen. Es wird zwischen kommerziellen Softwarehäusern,
die Auftragnehmer für Militär bzw. Regierung und Militär- bzw. Regierungsbehörden
unterschieden. Es lässt sich feststellen, dass die kommerzielle Organisation einen
überwiegenden Anteil mit einem Wert von 67,6% aufweisen.

                                                                         Abbildung 61
 Die nächste Abbildung 7 stellt eine Liste mit allen beteiligten Ländern dar. Daraus kann man
entnehmen, wie viele Organisationen eines bestimmten Landes einer CMMI Bewertung
unterzogen wurden.

1.Software Engineering Institut „Appraisal Results“ September 2006

                                                 - 16 -

Der höchste Wert hat die USA mit 598 Bewertungen. Danach kommen
Indien, China und Japan mit den Werten 177,158 und 155. Und nur 28 Organisation aus
Deutschland haben an der Bewertung teilgenommen.

                                                                                Abbildung 7

Aus den oben vorgeführten Statistiken, lässt sich die Folgerung ziehen, dass das CMMI
überwiegend in kommerziellen Organisationen verwendet wird. Die daran beteiligten
Organisationen sind meistens relativ ausgereift und haben bereit die Stufen Managed und
Defined erreicht. In Deutschland bzw. in Europa hat sich das Verfahren nicht durchgesetzt
und es wird in großer Anzahl nur lokal in den USA benutzt.

10. Zusammenfassung.
Dieser letzte Teil der Arbeit schließt das Thema Capability Maturity Model ab und stellt die
Schlussfolgerung dar.

Das oben beschriebene Model stellt eine Reihe von Methoden, Techniken und
Vorgehensweisen bereit, die es ermöglichen den Reifegrad einer Organisation bzw. der
Softwareprozesse dieser Organisation zu bewerten. Der Reifegrad wird in fünf Ebenen
eingeteilt. Jede Reifeebene definiert die Maßnahmen, die zur Prozessverbesserung führen, d.h.
erlauben einer Organisation effizienter Ihre Ressourcen auf zu wenden.

Das CMM war der erste systematische Ansatz zur Prozessverbesserung. Obwohl das Model
zuerst für Softwareentwicklungsprojekte entwickelt wurde, kann vieles davon mit nur
geringfügigen Anpassungen auch für andere Bereiche verwendet werden. Das CMM bietet
eine systematische Möglichkeit zur Verbesserung der Prozessqualität und Identifizierung von
Schwächen, deren Behebung besonders wirksam ist. Außerdem wird Evaluierung und damit

                                            - 17 -

Vergleich mit anderen Organisationen erlaubt.

Darüber hinaus sind einige Nebenwirkungen und Contraargumenten bekannt. Für die
Prozessverbesserung sind zusätzliche Kosten zu kalkulieren. Aber im Gegensatz dazu ergeben
die empirischen Untersuchungen, dass der Nutzen wesentlich höher ist als die Kosten. Die
Optimierung der Prozesse ist nur für die Standardprobleme möglich. Es ist aus verschiedenen
Blickwinkeln unbefriedigend und unvollständig. Die Anwendung ist teuer und langsam, daher
nur für große Organisationen geeignet. Das Model ist sehr stark technikbezogen und es wurde
wenig Rücksicht auf Personal genommen.

                                           - 18 -

11. Quellen.
1. The Capability Maturity Model:Guidlines for Improving the Software Process Addison-Wesley
   publishing company ISBN:0-201-54664-7
2. http://de.wikipedia.org/wiki/Capability_Maturity_Model_Integration
3. Software Engineering ISBN 3-8273-7001-9 Auflage 6 2001
4. http://www.xprogramming.com Ron Jeffries 01/01/2000
5. Software Engineering Institut „Appraisal Results“ September 2006

                                             - 19 -