Das Capability-Maturity-Model
für Software (CMM) ist ein fünf Ebenen Layer-Modell zur
Verbesserung von Softwareorganisation. Das Modell ist gut und ausführlich in weiteren
Referenzen beschrieben und wird daher nicht vertieft behandelt.
Die
fünf Ebenen (Level) sind:
Level
1 (Initial) haben
alle Organisationen bis sie die sechs Schlüssel-Prozesse des Level 2
(Repeatable) anwenden. Der Zweck dieser Schlüssel-Prozeß-Bereiche ist, die grundlegenden
Projekt-Management-Praktiken bei der Projektplanung, Prozeßablauf, das Anforderungs-
Management, Softwarequalitaetssicherung und Konfigurationsmanagement zu berücksichtigen
Level
2. Wenn Ihre Organisation
dann einige Ihrer Entwicklungsaufgaben außer Hause abgibt,
werden diese Praktiken ebenso hierfür benötigt. Eine grundlegende Veränderung vom
Level 1
nach Level 2 besteht für Softwareorganisationen darin, daß Mitarbeiter und Teams sich einer
Disziplin unterwerfen und mit der Aufgabe sich verpflichtend identifizieren und
zusammenarbeiten.
Level
3 (Defined) hat
sieben Schlüssel Prozeß Bereiche, für die Einführung eines formales
Prozeßmanagement innerhalb seiner Organisation. Eine Organisation auf Level 3 verwendet gut
definierte und dokumentierte Prozeduren für die jeweiligen Aufgaben. Diesen Prozeduren sind
dokumentiert und änderbar, außer sie müssen fest sein oder sie müssen verbessert
werden. Alle
Projekte nutzen diese Prozesse der Organisation, aber alle Projekte nutzen nicht die gleichen
Prozesse. Die Prozesse der Organisation können von folgenden dokumentierten Richtlinien für
den Gebrauch an jedes Projekts angepaßt werden: Projektgröße, Anwendungsdomäne,
Gastgeber oder Zielumgebung, und Entwicklungs Lebens Zyklus können die Projektprozesse
verändern. Level 3 Organisationen minimieren
unnötige Variationen der Prozesse, so daß die
meisten Projekte
der Organisation
die bekanntesten und besten Praktiken nutzen, damit die Fähigkeiten der
Mitarbeiter produktiv eingesetzt werden und auf das nächste Projekt übertragbar sind.
Level
4 nennt sich “Managed”,
aber es meint wirklich Quantitatives Management. Produkte
von Level 4 Organisationen haben numerische Qualitätsziele (wie z.B. mit dem Produktziel von
nicht mehr als 0,1 Fehler je Tausend Lines of Code zum Abgabetermin, oder am
einwandfreiem Produkt bei 3% Abweichung vom Liefertermin). Der Prozeß einer Level 4-
Organisation steht unter statistischer Kontrolle. Die spezifische Metrik werden von der
Organisation erhoben wie zum Beispiel: Codierungsfehler während der Codeüberprüfungen,
Codierungsfehler des Moduletest, Codierungsfehler der Systemprüfung, und Codierungsfehler
nach dem Liefertermin.
Level
5 Organisationen “Optimizing” (In der Optimierung, nicht optimiert!).
Sie verbessern
sich kontinuierlich, weil jedes Teil zu den Software-Prozeß Verbesserungsaktivitäten hierzu
beiträgt. Neue Technologien und Prozesse werden identifiziert, Pilote werden im Bedarfsfall
abgefragt und ggf. installiert wenn sie hierfür geeignet sind. Sowohl inkrementale als auch
revolutionäre Prozeßverbesserung ist in einer Level 5-Organisation möglich. Prozeß
Verbesserungsentscheidungen können auf wirtschaftlichen (Return on Investition) Faktoren
basieren, weil die Kosten der gegenwärtigen Prozesse wohlbekannt sind und daraus die
Kosten der neuen Prozesse auf Grundlage von Pilotierungen geschätzt werden können. Level 5
Organisationen nutzen derzeit marktüblichen Softwareentwicklungumgebungen und ihr
Prozeßvorgehen entspricht dem konkurrenzfähigenVerhalten.
Jedes Reifeniveau
baut auf deren Möglichkeiten auf, und der Erfolg hängt kritisch von dem
geringeren Level(s) ab. Bis die Projekt Management Praktiken
eingeführt sind (siehe Level 2)
ist es wahrscheinlich, daß angesichts von Termindruck die Projekte die Organisation-Prozesse
verkürzt anwenden. Es sei denn, die Organisation hat definierte und benutzte Prozesse des
Level 3, dann haben üblicherweise die Metriken nur innerhalb der Projekten eine Bedeutung.
Bis eine Organisation seinen Prozeß unter statistischer Kontrolle (Level 4) hat ist es schwierig,
den Nutzen von geplanten Verbesserungen aufzuzeigen.