Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

13.03.1992 - 

Der Reifegrad des Softwareprozesses wird meßbar

US-Uni Carnegie Mellon stellt die Entwicklung auf den Prüfstand

Software ist im Grunde immer nur so gut wie der Prozeß, durch den sie entsteht. Um zu beurteilen, wie gut der Entwicklungsprozeß ist, fehlte bislang der Maßstab. Diese Lücke hat das Software Engineering Institute (SEI) der Carnegie Mellon University geschlossen: Das zwischen 1986 und 1991 entstandene "Capability Maturity Modell" (CMM) ist dafür ausgelegt, den jeweiligen Entwicklungsprozeß in ein

fünfstufiges Schema einzuordnen.

In seinem Buch "Quality is free" beschrieb Philip Crosby ein fünfstufiges Modell, mit dessen Hilfe der Qualitätsstandard einer Organisation gekennzeichnet und verbessert werden kann. W. S. Humphrey hat dieses Modell auf die Softwarewelt übertragen und seine Erkenntnisse in dem 1989 bei Addison-Wesley erschienenen Buch "Managing the Software Process" veröffentlicht.

Das SEI wiederum hat die Humphrey-Vorlage verfeinert und in modifizierter Form zu Papier gebracht. Unter dem Titel "Capability Maturity Model for Software" wurden die Arbeitsergebnisse im August 1991 von der Carnegie Mellon University herausgegeben. Die von der in Pittsburgh, Pennsylvania, ansässigen Hochschule vorgenommenen Verbesserungen dienten vor allem dazu, einzelne Eigenschaften der verschiedenen Qualitätsebenen klarer herauszuarbeiten und quantitativ beurteilbar zu machen.

Heroische Anstrengungen von seiten einzelner

Humphrey geht von fünf Stufen aus, die er mit "initial" (Stufe 1), "repeatable" (2), "defined" (3), "managed" (4) und "optimizing" (5) bezeichnet. Die erste Stufe könnte man weniger höflich als Chaos bezeichnen. Sie ist gekennzeichnet durch einen Mangel an Planung: Von Tag zu Tag ändern sich die Ziele, es gibt keine Vorgaben für die Programmierer in Form von Normen und Standards, das Management der Software-Entwicklung fehlt ganz oder ist nur rudimentär vorhanden, die Unternehmensleitung wird nur mangelhaft und nicht fundiert über den Fortschritt von Projekten unterrichtet.

Trotzdem können Organisationen dieser Art gute Software entwickeln - allerdings nicht als Folge eines Prozeßmodells, sondern durch die heroischen Anstrengungen und das Können einzelner oder kleiner Teams. Verlassen diese Mitarbeiter die Firma, so ist der Erfolg nicht wiederholbar, die Organisation fällt im Wettbewerb zurück. Also kann diese Stufe des CMM aus der Sicht des Managements nicht wünschenswert sein.

Im Gegensatz zur Stufe 1 kann der erzielte Erfolg auf der mit "repeatable" bezeichneten zweiten Stufe wiederholt werden.

Das Projekt-Management erlaubt es, einzelne Funktionen der Software zu verfolgen; ein Zeitplan wird aufgestellt und seine Einhaltung überwacht.

Außerdem läßt sich der Fluß finanzieller Mittel verfolgen, weshalb das Management bei Abweichungen von der Planung eingreifen kann. Darüber hinaus findet ein Vergleich zwischen verschiedenen Projekten statt. Und last, but not least is es möglich, aus anderen Software-Entwicklungsprojekten der eigenen Organisation zu lernen.

Bei den Unternehmen, deren Entwicklungsprozeß der dritten, mit "defined" gekennzeichneten Stufe des Modells zuzuordnen ist, basiert der Entwicklungsprozeß auf Normen und Standards, die für die gesamte Organisation und alle Projekte Gültigkeit haben. Projektspezifisch werden detaillierte Pläne für die Bereiche Entwicklung, Qualitätssicherung und Konfigurationsmanagement erstellt. Die Einhaltung dieser Vorgaben wird überwacht.

Auf der Stufe 4 kommt eine quantitative Bewertung hinzu. Dabei werden sowohl der Entwicklungsprozeß als auch die entstehenden Softwareprodukte durch Messungen überwacht. Metriken sind die geeigneten Werkzeuge, um eine fundierte Aussage zur Software und deren Entstehung machen zu können (vgl. CW Nr. 36 vom 6. September 1991, Seite 14: "Qualitätskontrolle ist ohne einen Maßstab nicht möglich").

Die fünfte und vorläufig letzte Stufe des Capability Maturity Models wird als "optimizing" bezeichnet. Hier lassen sich die Messungen der vorhergehenden Stufe nutzen, um Schwachpunkte zu identifizieren und Verbesserungen einzuführen. Neue Ideen und Technologien können übernommen und in der Praxis erprobt werden.

Chaos herrscht in drei von vier Unternehmen

Das Software Engineering Institute hat 1989 in der amerikanischen Industrie eine Untersuchung durchgeführt, um herauszufinden, wie es derzeit um den Reifegrad der Software-Entwicklungsprozesse bestellt ist. Das Ergebnis ist erschreckend: Drei Viertel der befragten Organisationen bringen gute Software - wahrscheinlich - nur dadurch zustande, daß sich wenige Könner die Nächte um die Ohren schlagen, um das Programm doch noch zum Laufen zu bringen.

Selbst ein renommiertes Unternehmen wie Hughes ist derzeit nur als 2+ einzuordnen. Ganze drei Prozent der befragten Organisationen verfügen über einen definierten Software-Entwicklungsprozeß. Die Ebenen 4 und 5 sind nach den Ergebnissen des SEI überhaupt nicht besetzt.

Nach Schätzung der Carnegie-Mellon-Wissenschaftler braucht eine Firma 18 bis 36 Monate dafür, sich von einer Ebene des Modells in die nächsthöhere zu bewegen. Um eine Organisation der Stufe 5 zu werden, müssen die meisten also durchaus ein Jahrzehnt ansetzen. Die Darstellung des Modells als Pyramide habe ich keinesfalls zufällig gewählt. Es baut immer ein Erfolg auf dem anderen auf. Daher ist es beispielsweise nicht möglich, von Stufe 2 direkt auf Stufe 4 zu springen.

Was aber, bedeutet nun im Grunde die Ausgereiftheit Entwicklungsprozesses ("Software Process Maturity")? Wichtig ist in diesem Zusammenhang vor allem der Nutzen für die Praxis. Dazu zählt der Nutzen für das Management, der darin besteht, daß das Softwareprojekt überschaubar, der Prozeß durchsichtig und Abweichungen vom Plan minimiert werden; kurz: Es ist nicht nur möglich, Voraussagen zu machen, sondern es gelingt auch, die Softwareprodukte zum großen Teil rechtzeitig fertigzustellen.

Über das Tagesgeschäft hinaus liefert das Entwicklungsmodell einen Maßstab, um Verbesserungen in der Organisation erreichen und beurteilen zu können. Für den Auftraggeber oder Kunden ermöglicht die Anwendung des Modells eine Beurteilung der potentiellen Auftragnehmer; es liefert Daten zur Produktivität sowie zur Qualität der Software und läßt sich zur Abschätzung des Projektrisikos heranziehen. Und als Instrument der strategischen Planung kann das Modell zur Messung des Fortschritts dienen.

Da wir schon bei der Beurteilung einer Organisation und des angewandten Prozeß Modells sind, sollten wir an dieser Stelle auch die Vorgehensweise näher untersuchen. Es gibt im Grunde zwei Fälle: Bewertung durch den Auftraggeber (Evaluation) und Selbsteinschätzung (Assessment).

Die Evaluation geschieht auf Veranlassung des Auftraggebers bei der Auswahl eines Auftragnehmers oder während der Projektdurchführung. Die Resultate der Untersuchung erhält der Auftraggeber. Es werden die Möglichkeiten und Chancen der untersuchten Organisation zur Verbesserung des Prozesses beurteilt. Auf diese Weise läßt sich die Einhaltung eines Vertrages zur Software-Entwicklung untersuchen.

Ein Assessment hingegen wird zum Nutzen der eigenen Organisation durchgeführt. Die Ergebnisse der Untersuchung bleiben vertraulichen können aber als Anstoß zur Verbesserung dienen, indem sie in einen Plan zur Verbesserung des Entwicklungsprozesses einfließen.

Durchgeführt werden kann die Beurteilung des jeweiligen Software-Entwicklungsprozesses durch das Software Engineering Institute oder einen von ihm beauftragten Lizenznehmer. Als Hilfsmittel kommen Fragebögen und Interviews zum Einsatz. Die Hauptuntersuchung dauert fünf Tage, nach deren Ablauf dem Top-Management das Ergebnis vorgestellt wird.

Allerdings irrt, wer glaubt, mit Hilfe dieses Instruments sei es ganz einfach geworden, die Software-Entwicklung zu optimieren. Vielmehr ist es mit Arbeit verbunden, den Software-Entwicklungsprozeß so zu planen, zu steuern und zu überwachen, daß regelmäßig Software hoher Qualität mit vertretbaren Kosten und zu dem vereinbarten Termin entsteht.

Der Verdienst des SEI ist es ohne Zweifel, ein Modell zur Beurteilung und Einordnung des Prozesses geliefert zu haben. Nun liegt es an dem verantwortlichen Management in, der Industrie, dieses Instrument einzusetzen. Angesichts der ständig zunehmenden Bedeutung der Software in allen Bereichen auch in sicherheitskritischen - sollte diese Aufgabe nicht vernachlässigt werden.