CMM geht deutlich über ISO 9000 hinaus

Reifezeugnis für Software

05.04.2002
Für die Zertifizierung von Software findet in Deutschland neben der ISO 9000 das amerikanischeCapability Maturity Model (CMM) zunehmend Verbreitung. Es deckt sich zwar in vielen Bereichen mit ISO 9000, verfolgt jedoch einen grundsätzlich anderen Ansatz. Dabei ist das Modell nicht frei von Schwächen, bietet aber dennoch eine brauchbare Möglichkeit, das Qualitäts-Management zu verbessern. Von Hubert Zenner*

Die Zertifizierung von Software und von Softwareentwicklung hat in den letzten Jahren große Bedeutung erlangt. Zu oft konnten Projekte nicht halten, was sie versprochen hatten, sei es, dass sie erfolglos abgebrochen werden mussten oder Anwender sich mit massiven Qualitätsproblemen konfrontiert sahen. Zahlreiche Unternehmen wollen sich heute nicht mehr auf bloße Zusicherungen der Anbieter verlassen, sondern versuchen, über den Rückgriff auf Zertifizierungen eine Absicherung zu erreichen. Wer heute Software für Großprojekte, etwa im Anlagen- oder Flugzeugbau, verkaufen will, kommt ohne solche Zertifizierungen nicht mehr aus.

Ein Softwareanbieter muss daher nicht nur über ein Qualitäts-Management verfügen, sondern auch nachweisen können, dass es funktioniert und dass im Unternehmen nach dokumentierten Verfahren gearbeitet wird. Die Zertifizierung des Qualitäts-Managements wird über die von den Normierungsstellen anerkannten Auditoren vorgenommen. Grundlage ist hier meist die ISO 9000, deren Funktion von Nichteingeweihten allerdings oft falsch interpretiert und damit überschätzt wird. Eine ISO-Zertifizierung ist nicht mit einer Art Garantie für das Funktionieren einer Software zu verwechseln. Zertifiziert wird beispielsweise, ob eine Dokumentation vorhanden ist.

Neben ISO 9000 gewinnt neuerdings das amerikanische Capability Maturity Model, der Standard des Software Engineering Institute(SEI) der Carnegie Mellon University in Pittsburgh, Pennsylvania, auch in Europa eine stärkere Bedeutung. CMM konzentriert sich ganz auf die Prozesse, die an der Herstellung von Produkten, hier insbesondere Software, beteiligt sind. Dahinter steht die Idee, dass die Qualität von Software wesentlich von den Entwicklungsprozessen bei der Herstellung abhängt, also von dynamischen Elementen, und nicht so sehr von statischen wie Programmiersprachen. CMM unterscheidet fünf Stufen von Reifegraden, die der Herstellungsprozess von Software in einem Unternehmen aufweisen kann: Initial, Repeatable, Defined, Managed und Optimized. Durch Aufsteigen auf eine höhere Stufe kann ein Unternehmen seine Entwicklungsprozesse und damit auch die Qualität seiner Produkte verbessern. Für jede Stufe, mit Ausnahme der ersten, bestehen im CMM eine Reihe von Schlüsselbereichen (Key Process Areas), in denen der Prozess eine gute Qualität aufweisen muss. Sie werden jeweils durch Schlüsselpraktiken (Key Practices) beschrieben.

Die CMM-Eingangsstufe (Initial) beschreibt einen Zustand ohne besondere Maßnahmen: Es ist die vielfach bekannte Chaosstufe. Hier gibt es weder Maßnahmen zur Prozesskontrolle noch zur Qualitätssicherung, es existiert keine formelle Planung und kein explizites Konfigurations-Management. Jeder Entwickler arbeitet ad hoc: Nach eigenen Vorstellungen plant, verwirft, ändert und dokumentiert er, was ihm gerade am nächsten liegt. Zwar kann auch auf dieser Stufe ein Projekt- und Qualitäts-Management vorhanden sein, es wird aber nicht konsequent angewendet und - vor allem - bei Problemen gleich wieder verworfen und durch etwas anderes ersetzt. Erfahrungsgemäß befindet sich die überwiegende Mehrzahl der Unternehmen auf dieser Stufe. Was jedoch keineswegs bedeutet, dass dabei nur schlechte Software produziert wird.

Prozessergebnis kaum vorhersagbarWenn hier trotz Prozesschaos gute Resultate erzielt werden, so aufgrund prozessfremder Faktoren, etwa durch das große Engagement der Mitarbeiter oder einen genialen Projektleiter. Insofern ist das Ergebnis des Prozesses nur selten vorhersehbar, vor allem nicht für Dritte. Extreme Terminüberschreitungen sind auf dieser Stufe daher ebenso programmiert wie empfindliche Qualitätsmängel.

Die zweite Stufe (Repeatable) führt die Wiederholbarkeit in den Entwicklungsprozess ein. Anstatt jeden Prozess neu zu definieren, wird versucht, die einzelnen Schritte in jedem Projekt zu wiederholen. Damit besteht eine stabile Projektverwaltung, und die Erfahrungen aus früheren Projekten können in neue Vorhaben einfließen. Kosten und Termine werden dabei laufend überwacht. So wird auch der Ablauf der Prozesse in bestimmten Rahmen vorhersagbar.

Auf der Defined-Reifestufe werden die Standardprozesse für die Entwicklung und Pflege von Software festgelegt und dokumentiert. Die Aktivitäten sind sowohl beim Software-Engineering als auch beim Prozess-Management stabil und wiederholbar. Für einzelne Schritte werden nun bestimmte Techniken vorgeschrieben, aber auch Start- und Endkriterien aufgestellt. Neben der technischen Vorgehensweise sind auch die jeweiligen Maßnahmen im Projekt-Management und in der Qualitätssicherung definiert.

Im Unterschied zur vorangegangenen Stufe werden im Reifegrad "Managed" quantitative Ziele aufgestellt, mit denen die Qualität der Prozesse festgestellt werden kann. Die Prozessdaten werden in einer unternehmensweiten Datenbank gesammelt. Damit lässt sich auch die Produktivität der Entwicklung überprüfen. Das Unternehmen verfügt so über ein Kontrollinstrument. Daraus können Kriterien abgeleitet werden, die den Entwicklungsprozess sowohl quantitativ als auch hinsichtlich der Projekt-Performance vorhersagbar machen.

Auf seiner fünften Stufe (Optimized) führt CMM Rückkopplungsmechanismen in das Prozess-Management ein. Damit lassen sich gezielt Schwächen beseitigen und Problemsituationen vermeiden. Unternehmen, die auf dieser Stufe agieren, legen fest, was zu geschehen hat, wenn etwa Abweichungen von den auf Stufe 4 getroffenen Vorgaben festgestellt werden. Die dort erhobenen Daten gehen in Analysen und Entscheidungsprozesse ein, die beispielsweise zu Änderungen in Projektverläufen führen können.

CMM und ISO 9000 überschneiden sich in weiten Teilen, sind aber nicht deckungsgleich. So ist CMM wesentlich ausführlicher und detaillierter als ISO 9000, weshalb das Erreichen von ISO 9000 nichts über den CMM-Level aussagt. Umgekehrt sollten sich Unternehmen, die eine Zertifizierung für CMM, Level 3, erhalten haben, ohne großen Aufwand auch für ISO 9000 zertifizieren lassen können.

Der Hauptunterschied liegt jedoch nicht so sehr in den einzelnen Klauseln, Schlüsselbereichen oder Schlüsselpraktiken, sondern darin, dass die 20 ISO-Klauseln strukturell gleichwertig sind und nicht wie CMM ein hierarchisches Stufenmodell bilden. Ein Aufsteigen von einem Qualitätsniveau zum nächsten wird von ISO 9000 nicht beschrieben. Insofern ist die Norm eher statisch, was jedoch in keiner Weise als Mangel zu verstehen ist: Es handelt sich einfach um einen anderen Blickwinkel. ISO 9000 beschreibt ein Anforderungsprofil an das Qualitäts-Management, das auch zum Vertragsgegenstand gemacht werden kann. CMM liefert zwar auch eine Zustandsbeschreibung, unterscheidet dabei jedoch unterschiedliche Zustände und bringt damit dynamische Elemente ein. Allerdings bietet CMM keine Strategien, wie sich die jeweils nächste Stufe erreichen lässt.

Auch an CMM wurde verschiedentlich Kritik geäußert. So hat man insbesondere darauf hingewiesen, dass das Modell zu wenig differenziert ist. Aber auch am anderen Ende der Skala zeigen sich Probleme: Kaum ein Unternehmen schafft heute die Stufe 4, und Stufe 5 ist in der Praxis der Softwareentwicklung bisher überhaupt nicht relevant. Ein Fünf-Stufen-Modell, bei dem die überwiegende Mehrzahl der Unternehmen auf Stufe 1 angesiedelt werden muss, während zwei Stufen kaum genutzt werden, ist zu eng und verfügt nicht über genug praktische Aussagekraft. Hinzu kommt, dass Stufe 1 bei genauer Betrachtung gar nicht definiert ist: Sie nimmt alles auf, was weiter oben gescheitert ist.

Während solche Einwände durch eine größere Differenzierung widerlegt werden könnten, geht eine andere Kritik ins Grundsätzliche. Es ist nämlich durchaus fraglich, ob Softwarehersteller das in CMM unterstellte Ziel überhaupt anstreben. Experten geben zu bedenken, dass CMM von einem Idealbild ausgeht, bei dem ein Softwareprozess über die statische Analyse von Prozessdaten gelenkt wird. Es sei jedoch keineswegs klar, dass dies die einzige optimale Form ist.

Auch solche grundsätzlichen Probleme haben den Erfolg von CMM in der Zertifizierungspraxis nicht aufhalten können. Die Relevanz konzentriert sich auf die Stufen 2 und 3 - besonders dort scheint bei den Unternehmen ein echter Nachholbedarf an Orientierung zu bestehen. Nach dem Motto "besser als nichts" erfüllt CMM hier mittlerweile eine wichtige Funktion - zumal wenn man sich über die immanenten Grenzen dieses Modells im Klaren ist. (ue)

*Hubert Zenner ist Business Development Manager bei der Merant GmbH in Ismaning.

CMM-Links

www.iso.ch

www.iso.ch/iso/en/iso9000-14000

www.din.de

www.sei.cmu.edu

www.cmii.de

www.ipd.ira.uka.de/~prechelt/swt2/node44.html

www.gfkm.de

Die fünf CMM-Stufen

Stufe 1: Initial

Stufe 2: Repeatable

-Konfigurationsverwaltung,

-Qualitätssicherung,

-Unterauftragsverwaltung,

-Softwareprojektverfolgung,

-Softwareprojektplanung sowie

-Anforderungsverwaltung.

Stufe 3: Defined

-Peer Reviews (Festlegung von Kontrollmechanismen),

-Koordination zwischen Arbeitsgruppen,

-Software-Produkt-Engineering,

-integriertes Software-Management,

-Training und Ausbildung der Mitarbeiter,

-Definition der Organisationsprozesse sowie

-Fokus auf die Organisationsprozesse.

Stufe 4: Managed

-Quantitative Prozess-Steuerung,

-Softwarequalitäts-Management.

Stufe 5: Optimized

-Management von Prozessänderung,

-Management von Technologieänderung,

-Defektvermeidung.

Abb: Capability Maturity Model

Das Capability Maturity Model (CMM) zur Qualitätssicherung und Zertifizierung von Software konzentriert sich auf Entwicklungsprozesse und verbindet deshalb mit jeder der fünf Reifegrad-Stufen auch eine Strategie zur Prozessverbesserung. In der Praxis befinden sich die meisten Projekte allerdings noch auf Ebene 1, während die Ebenen 4 und 5 bislang in der Softwareentwicklung so gut wie gar nicht erreicht werden. Quelle: Merant