Zur Reife bringen

Softwareentwicklungsprozesse verbessern mit CMMI – aber wie?

Michael Tarnowski

Software bestimmt heutzutage weite Teile unseres Alltags: die Online-Transaktion unseres Bankkontos, die Steuerung des elektronischen Küchenherds, die Bedienung des Handys, Fahrerassistenzsysteme im viel geliebten Automobil. Enthält die Software dieser komplexen Systeme Fehler, sind die Folgen für den Produzenten und seine Zulieferer schwerwiegend. Methodiken zur Softwareprozessverbesserung wie CMMI können helfen, die Fehlerquote zu reduzieren und die Einhaltung von Compliance-Regeln zu sichern. Und nicht zuletzt bringen sie Unternehmen, die ihre Softwareprodukte und Geschäftsprozesse schneller an den Markt anpassen können, klare Wettbewerbsvorteile.

In der klassischen Fertigungsindustrie ist der Einfluss von Entwicklungs- und Produktionsprozessen auf die Produktqualität ebenso wie der Zusammenhang zwischen Prozessverbesserung und Qualitätsoptimierung schon seit langem bekannt. Sind die Entwicklungs- und Produktionsprozesse dort jedoch klar voneinander getrennt, ist dies im Softwareengineering keineswegs der Fall. Hier sind Entwicklungs- und Produktionsprozess identisch, sodass sich Entwicklungsfehler nicht einfach später in der Produktion korrigieren lassen.

Das branchenübliche nachträgliche Testen der produzierten Software stellt keine wirklich befriedigende Lösung dar, denn dadurch kann die Produktqualität (oder deren Abwesenheit) nur festgestellt werden. Jeder Entwicklungsfehler eines Software-Produkts muss als ein nur kostenintensiv korrigierbarer Produktionsfehler betrachtet werden. Methodiken zur Softwareprozessverbesserung (Engl. Software Process Improvement, SPI) beschäftigen sich daher damit, die Entwicklungsprozesse als solche zu verbessern.

In vielen Entwicklungsteams sind die Entwicklungsprozesse wenig ausgeprägt und entwickelt, eher ad hoc improvisiert, reaktiv und werden ständig neu erfunden. Pläne und Budgets sind nicht vorhersagbar und werden ständig überschritten. Qualitätsexperten provozieren gerne mit der Einschätzung, dass der erfolgreiche Abschluss von Softwareprojekten dementsprechend rein zufällig ist und ausschließlich dem Heldentum, zahlreichen Überstunden und permanentem „Firefighting“ des Projektteams zu verdanken ist. Als Ausweg aus der Misere bieten sie Methodiken zur systematischen Verbesserung von Softwareentwicklungsprozessen an.

Prozessreifegradmodelle und CMMI

International hat sich das Capability Maturity Model Integration (CMMI) als zentrales Reifegrad- bzw. Prozessmodell zur Bewertung und Verbesserung von Entwicklungsprozessen etabliert. Es ist das Nachfolgemodell des bekannten Capability Maturity Model (CMM), das vom Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh, USA, ursprünglich im Auftrag des amerikanischen Verteidigungsministeriums zur Qualitätssicherung von Softwareentwicklungsprojekten seiner Lieferanten entwickelt wurde.

Als Reifegradmodell ist CMMI eine Art Messlatte zur eigenen Verbesserung, zum Vergleich der eigenen Prozessdurchführung und der Bewertung der Zulieferer („Benchmarking“). Von Prozess- oder Vorgehensmodellen unterscheidet es sich darin, einen Mechanismus zur Bewertung der Prozessreife („Maturity“) des gesamten Unternehmens bzw. der Prozessfähigkeit („Capability“) einzelner Prozessgebiete („Process Areas“) zu enthalten.

Die beiden Begriffe Prozessfähigkeitsgrad und Prozessreifegrad meinen fast das Gleiche, nur der Fokus ist verschieden. Der Prozessfähigkeitsgrad bezieht sich auf die Durchführung der Prozesse innerhalb eines Prozessgebiets. Das Ergebnis der Bewertung des Prozessfähigkeitsgrads ist ein so genanntes Prozessfähigkeitsprofil – meistens bezogen auf ein spezielles IT-Projekt oder eine einzelne Fachabteilung. Der Prozessreifegrad dagegen erstreckt sich über das gesamte Unternehmen hinweg auf eines oder die Gesamtmenge seiner Prozessgebiete.

Den erreichten Prozessreifegrad des Unternehmens stellt CMMI in einem Stufenmodell dar, bei dem ein einzelner Zahlenwert von 1 bis 5 den Gesamtreifegrad des Unternehmens angibt. Zur Darstellung des Prozessfähigkeitsgrades dient das so genannte kontinuierliche Modell.

Abb. 1: Kontinuierliches vs. Stufenmodell in CMMI
Die Elemente von CMMI

CMMI basiert auf ISO 12207, dem Standardprozessmodell für Software-Engineering und ISO 15288, dem Standardmodell für das System-Engineering. ISO 12207 definiert, welche Prozesse in einer Software-Entwicklungsorganisation definiert sein sollten, ISO 15288 darüber hinaus diejenigen für eine System-Entwicklungsorganisation. CMMI integriert die Software- und System-Entwicklungsprozesse und gliedert die Prozesse in vier Prozessgebietkategorien:

  • Prozessmanagement: Prozessgebiete, die sich mit dem Management der für die gesamte Organisation gültigen Prozesse befassen. Dazu gehört unter anderem auch die Definition und kontinuierliche Verbesserung der Prozesse.
  • Projektmanagement: Prozessgebiete, die sich mit dem Management einzelner Projekte befassen.
  • Ingenieursdisziplinen: (Technische) Entwicklungsprozesse; sie umfassen neben einem einfachen Lebenszyklusmodell auch die Verifikation und Validation der Ergebnisse.
  • Unterstützung: Querschnittsprozesse, welche die Arbeit in den anderen Prozessgebieten unterstützen.

Abb. 2: Prozesskategorien und -gebiete von CMMI

Allgemein lässt sich in Prozessverbesserungsprogrammen die Prozessdurchführung nur durch Prozessergebnisse messen: an den Arbeitsergebnissen, an signifikanten Zustandsänderungen oder an der Erfüllung definierter Vorgaben und Ziele. Die Bewertung der Prozessreife fällt also auf die Bewertung von Evidenzen („Findings“) der Prozessdurchführung zurück. CMMI definiert hierzu so genannte Prozessattribute und zugehörige Prozessindikatoren (Metriken).

CMMI gliedert seine Prozessattribute in so genannte Ziele (Goals) und Praktiken (Practices). Spezifische Ziele (Specific Goals, SG) und spezifische Praktiken (Specific Practices, SP) gelten nur für das jeweilige Prozessgebiet und beschreiben deren spezielle Anforderungen. Generische Ziele (Generic Goals, GG)/generische Praktiken (Generic Practices, GP) beschreiben die so genannte „Institutionalisierung“ der Prozessgebiete, also all das, was zu tun ist, damit die spezifischen Ziele regelmäßig, dauerhaft und effizient umgesetzt werden. Diese Ziele sind übergreifend für die einzelnen Prozessgebiete formuliert. Insgesamt definiert CMMI 47 spezifische Ziele, 161 spezifische Praktiken, 22 generische Ziele und 264 generische Praktiken.

In einem Prozessverbesserungsprogramm verpflichtet das CMMI die Organisation über eine gemeinsame Struktur (common features), die generischen Ziele bei der Prozessverbesserung zu erfüllen:

  • Verpflichtung zur Umsetzung (Wollen): Die Organisation verpflichtet sich zu Policies und sichert sich Sponsoren, um die Anforderungen der Prozessdurchführung zu erfüllen.
  • Fähigkeit zur Durchführung (Können): Sicherstellung, dass die Organisation die für das Entwicklungsprojekt benötigten Ressourcen bereitstellt.
  • Durchführung (Tun): notwendige Aktivitäten, das spezifische Ziel zu erreichen.
  • Steuerung der Umsetzung (Steuern): Unterstützung des Prozesses und seiner Erzeugnisse.
  • Verifikation der Umsetzung (Prüfen): Review und objektive Begutachtung der Prozessumsetzung durch das höhere Management.
Geschrieben von
Michael Tarnowski
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.