Das Software Engineering Institute (SEI) ist eine mit großen Mengen staatlicher Gelder geförderte Einrichtung an der Carnegie Mellon Universität in Pittsburgh und hat die Aufgabe, die Softwarepraktiken in der amerikanischen Industrie zu verbessern. Kernstück seiner Aktivitäten ist das sogenannte ,,disciplined engineering``-Programm, in dem in direkter Zusammenarbeit mit Firmen bessere Ingenieurpraktiken auf der Methodenebene entwickelt werden. Eine der Entwicklungsrichtungen hierbei ist eine Methode zur Bewertung der Fähigkeiten einer Softwareorganisation. Die Ausgangsüberlegung hierzu lautet, daß die Qualität eines Softwareprodukts weitgehend von der Qualität der Entwicklungsprozesse abhängt, mit denen es hergestellt wird. Also wurde das Capability Maturity Model (CMM) entwickelt.
Wie der Name schon sagt, ist das CMM ein Modell, also eine abstrakte Beschreibung eines Teils der natürlichen Welt. In diesem Fall eine Beschreibung mehrerer Klassen von Softwareprozessen. Der Zweck des Modells ist, einen Vergleichsmaßstab für wirkliche Softwareprozesse zu bekommen, um gezielt und reproduzierbar deren Stärken und Schwächen bestimmen zu können. Dies kann man sowohl als Basis zur Verbesserung der eigenen Organisation einsetzen als auch zur Auswahl zwischen fremden Organisationen, wenn man Aufträge zu vergeben hat. Das CMM soll einen Entwicklungspfad aufzeigen, der zur allmählichen Verbesserung des Softwareprozesses begangen werden kann.
Dieser Entwicklungspfad besteht beim CMM aus dem Durchlaufen von fünf Stufen zunehmender Prozeßreife, die wir unten etwas ausführlicher besprechen werden. Zu jeder dieser Stufen gibt es eine kleine Zahl von Schlüsselbereichen (key process areas), in denen der Prozeß eine gute Qualität erreichen muß, um auf die jeweilige Stufe zu gelangen. Diese gute Qualität ist mit Hilfe einer ganzen Reihe von Schlüsselpraktiken (key practices) zu jedem Bereich näher beschrieben. Die Schlüsselpraktiken sind gruppiert nach denjenigen Implementationsaspekten der Verbesserung im Schlüsselbereich, die sie betreffen, den sogenannten relevanten Aspekten (common features). Siehe auch Abbildung 5.2.
![\includegraphics[scale=1]{Bild/prozessCMMarch.ps}](img52.gif)
Die Bezeichnung Schlüsselbereich deutet an, daß diese Bereiche diejenigen sind, an denen besonders oft Mängel die Qualität des Softwareprozesses erheblich beeinträchtigen. Verbesserungen in diesen Bereichen sind also besonders effektiv zur Erhöhung der Prozeßreife. Das CMM beschreibt nur diese Schlüsselbereiche, nicht auch alle anderen Aktivitäten bei der Softwareentwicklung. Jeder Schlüsselbereich muß im Hinblick auf fünf verschiedene Aspekte verbessert werden, um eine Prozeßverbesserung damit zu erzielen. Diese werden die relevanten Aspekte genannt und sind
Aus einem anderen Blickwinkel betrachtet gehen die Ziele der Schlüsselbereiche in die folgenden Richtungen:
Auf der Eingangsstufe gibt es keine ordentlichen Vorkehrungen für die Verwaltung von Softwareprojekten und keine stabile Umgebung für die Entwicklung. Im Fall von Krisen werden geplante Vorgehensweisen typischerweise über Bord geworfen und durch bloßes Kodieren und Testen ersetzt. Der gesamte Softwareprozeß wird ständig geändert und modifiziert, wie es gerade passend zu sein scheint; er ist ad-hoc.
Wenn eine solche Softwareorganisation trotzdem gute Produkte erzeugt, so liegt das an gutem Personal und meist heroischem Einsatz desselben. Die Funktionalität und Qualität und der Fertigstellungszeitpunkt eines Softwareprodukts sind aber weitgehend unvorhersehbar. Stabilisierende Einflüsse auf den Prozeß durch ausnehmend gute Manager kommen in Stufe 1 zwar vor, hängen aber vollkommen von der Person ab und verschwinden gegebenenfalls mit dieser.
Die weitaus überwiegende Zahl von Softwareorganisationen befindet sich auf Stufe 1 und ein sehr großer Teil aller schweren Fehlschläge bei Projekten läßt sich auf die mangelnde Prozeßreife dieser Organisationen zurückführen. Es ist zu beachten, daß Stufe 1 weder eine notwendige noch eine hinreichende Bedingung für ein fehlschlagendes Projekt ist -- lediglich die Wahrscheinlichkeit wird enorm erhöht.
Auf Stufe 2 werden Maßnahmen für eine geordnete Verwaltung und Verfolgung von Softwareprojekten eingeführt. Die Planung und Durchführung neuer Projekte nutzt explizit und geordnet die Erfahrungen aus früheren Projekten. Dies führt zu einer gewissen Vorhersagbarkeit des Prozesses und zu der Fähigkeit, Erfolge in früheren Projekten auf neuen, ähnlichen Projekten zu wiederholen. Man kann die Prozeßfähigkeiten von Stufe 2 mit dem Wort ,,disziplinierter Prozeß`` zusammenfassen.
Auf Stufe 2 und allen höheren Stufen gibt es eine Reihe von Schlüsselbereichen des Prozesses (key process areas), in denen bestimmte Ziele erreicht werden müssen, bevor man davon sprechen kann, daß die Organisation diese Stufe erreicht hat.
Hier die Beschreibung der Schlüsselbereiche und Ziele für Stufe 2:
Auf Stufe 3 werden alle Prozesse der Organisation, sowohl die technischen Prozesse als auch die zur Verwaltung (Management), definiert und dokumentiert. Sie formen nun erstmals ein zusammenhängendes Ganzes, das Standard-Softwareprozeß der Organisation genannt wird. Die Herausforderung der Stufe 3 lautet, Prozesse zu definieren, die die einzelnen Softwareingenieure in die Lage versetzen, effizient nützliche Arbeit zu tun, ohne daß die Prozesse dabei einengend oder unflexibel werden.
Die einzelnen Prozeßteile streben an, günstige Techniken zur Durchführung und Verwaltung der Arbeit einheitlich vorzuschreiben und anzuwenden. Dabei gibt es Eintritts- und Austrittskriterien für jede Arbeit, eine wohldefinierte Vorgehensweise, Qualitätssicherungsmaßnahmen (Begutachtungen) und eine Arbeitsgruppe, die diese Teile angemessen festlegt. Für jedes Projekt wird aus dem allgemeinen Rahmen eine spezielle Fassung erzeugt, die an die Anforderungen des Projektes gut angepaßt ist, der sogenannte definierte Prozeß des Projekts. Alle Beteiligten erhalten die nötige Ausbildung, um diesen Prozeß kompetent durchzuführen. Die Prozeßfähigkeiten auf Stufe 3 lassen sich in dem Wort ,,konsistent`` zusammenfassen, erstmalig gibt es den Softwareprozeß in einer Form, die sich tatsächlich angeben läßt. Eine Organisation auf Stufe 3 weiß, was sie tut. Sie weiß aber nicht unbedingt, wie gut sie es tut.
Hier die Schlüsselbereiche und Ziele:
Auf Stufe 4 werden quantitative Ziele zur Prozeßgüte formuliert und überwacht. Wohldefinierte Messungen werden eingeführt, um zahlreiche Aspekte des Prozesses quantitativ zu erfassen, die Daten werden in einer organisationsweiten Datensammlung abgelegt, um die Grundlage für Prozeßanalysen und -verbesserungen zu schaffen. Damit lassen sich Leistungsvariationen vermindern. Die Prozeßfähigkeiten auf Stufe 4 lassen sich in dem Wort ,,vorhersagbar`` zusammenfassen. Eine Organisation auf Stufe 4 weiß, wie gut ihr Prozeß ist. Sie weiß aber nicht unbedingt, wie sie ihn verbessern kann.
Die Schlüsselbereiche und Ziele für Stufe 4 lauten:
Auf Stufe 5 richtet sich die Organisation auf laufende Verbesserung ihres Softwareprozesses aus. Sie kann ihre Schwächen identifizieren und ihren Prozeß vorbeugend verbessern. Die Meßdaten werden nun für Kosten-Nutzen-Analysen verwendet, auf deren Basis neue Technologien oder vorgeschlagene Änderungen im Softwareprozeß untersucht und beurteilt werden. Werden dabei Verbesserungsmöglichkeiten identifiziert, werden diese organisationsweit eingeführt. Defektvermeidung nimmt dabei eine wichtige Stellung ein: Begangene Fehler werden analysiert, gemeinsame Ursachen entdeckt und die Vorgehensweisen so verändert, daß diese Ursachen möglichst ausgeschlossen werden. Die Prozeßfähigkeiten von Stufe 5 lassen sich als ,,selbstverbessernd`` zusammenfassen.
Dies sind die Schlüsselbereiche und Ziele von Stufe 5:
Eine andere Art, die Reifestufen zu betrachten, ist der Blickwinkel des Managements, das nicht selbst im technischen Prozeß der Softwareherstellung steckt. Stellen wir uns einmal die Frage, welche Information über den Ablauf der Softwareentwicklung und die Zwischenzustände in Bezug auf Qualität und Arbeitsfortschritt den Managern auf den verschiedenen Reifestufen zur Verfügung stehen.
Auf Stufe 1 ist der gesamte Softwareprozeß für das Management völlig undurchsichtig. Er beginnt irgendwann und nach einer gewissen Zeit kommt ein gewisses Ergebnis heraus. Weder kann vorher in irgendeiner Weise die Qualität des Ergebnisses abgeschätzt werden, noch läßt sich vor dem plötzlichen ,,Auftauchen`` des Ergebnisses vorhersehen, wann das geschehen wird. Software machen ist schwarze Magie. Das Projekt hat meist die berüchtigte 90-90-Form: Über 90% seiner Laufzeit ist es angeblich bereits zu 90% fertig.
Auf Stufe 2 ergibt sich zumindest ein gelegentlicher Einblick in die Softwareentwicklung. An vordefinierten Meilensteinen kann eine Abschätzung der Zeitplanung und eventuell auch der Produktqualität vorgenommen werden. Softwareentwicklung mutiert zum Durchlaufen einer Abfolge von schwarzen Kästen. Zwischen je zwei solchen Kästen wird kurz eine Einsicht möglich, das Management kann auf Probleme reagieren, wenn sie aufgetreten sind.
Auf Stufe 3 wird auch die interne Struktur der Arbeitsstufen zwischen den Meilensteinen sichtbar, da der darin ablaufende Prozeß definiert ist; die schwarzen Kästen werden durchsichtig. Manager und Ingenieure verstehen ihre Rollen genauer und ein vorzeitiges Abschätzen von Risiken samt entsprechender Vorsorge wird möglich.
Auf Stufe 4 wird die Einsicht in die Prozesse von der qualitativen auf die quantitative Stufe gehoben. Das ermöglicht erheblich genauere Vorhersagen der Entwicklung, insbesondere von Problemen. Der Entwicklungsprozeß wird beherrscht.
Auf Stufe 5 erstreckt sich diese quantitative Einsicht auch auf Änderungen des Prozesses, so daß auch für Prozeßänderungen allmählich Vorhersagen ihrer Wirkungen möglich werden. Nicht nur der Entwicklungsprozeß selbst, sondern auch seine Fortschreibung und Verbesserung wird beherrscht.
