next up previous contents
Next: 5.9 Probleme und Hindernisse Up: 5. Softwareprozeß-Verbesserung Previous: 5.7 Weiterentwicklung

5.8 Ergebnisse

Das SEI bietet als Dienstleistung an, Einstufungen von Organisationen oder Projekten gemäß CMM vorzunehmen (,,SEI-assisted assessments``). Dazu gibt es eine genau definierte Methode, die auf einem umfangreichen Fragebogen basiert, an dessen Beantwortung eine ganze Reihe von Personen der Organisation teilnehmen müssen, und zwar sowohl technisches Personal als auch Management. Solche Einstufungen können alternativ auch ohne direkte Mitwirkung des SEI von der Organisation selbst vorgenommen werden (,,self-assessments``). Eine direkte Methode ist ein stark verkürztes Verfahren mit einem vereinfachten Fragebogen, das im Rahmen eintägiger CMM-Einführungskurse durchgeführt werden kann (,,workshop assessments``). Die frühesten Ergebnisse solcher Untersuchungen aus den Anfangsjahren des CMM hat das SEI in [HKK89] veröffentlicht. Dabei erreichten bei 55 vollen und 113 verkürzten Bewertungen unter 5% der Organisationen die Stufe 3 und keine einzige Stufe 4 oder 5! Seither hat sich die Lage etwas gebessert. Ergebnisse aus den Jahren 1992 bis 1997, entnommen aus [Zub97] sind in Abbildung 5.3 dargestellt.

\includegraphics[scale=1]{Bild/prozessCMMresults.ps}

Wie wir sehen, ist der weit überwiegende Teil aller Organisationen und Projekte auf CMM-Reifestufe 1, nur jede siebte Organisation erreicht die Stufe 3 und die Stufen 4 oder 5 treten nur als Ausnahmen auf.

1995 machte das SEI eine größere Auswertung von Anwendungserfahrungen mit dem CMM und zwar in Form einer Umfrage [HG96]. Dazu schickte sie Fragebogen an 167 Personen aus 61 Institutionen, die mindestens ein Jahr und höchstens drei Jahre zuvor eine CMM-Selbstbewertung vorgenommen hatten. Die Zeitbeschränkungen sollten bewirken, daß einerseits genügend Zeit gewesen war, um Veränderungen anzustoßen, andererseits aber nicht soviel, daß die Leute, die die Bewertung mitgemacht hatten, nicht mehr erreichbar waren. In jeder Institution wurde soweit möglich ein Manager, ein erfahrener Softwareingenieur und ein Mitglied der Softwareprozeßgruppe (soweit vorhanden) befragt. Der Rücklauf betrug 83% oder 138 Fragebögen (47 von SW-Ingenieuren, 47 von Managern, 44 von SEPG-Mitgliedern). Die Antworten zeigten keine systematischen Unterschiede zwischen den drei Gruppen von Personen.

Die eigene Institution wurde zum Zeitpunkt der Umfrage von den Antwortenden in folgende Reifestufen eingeordnet: 87 mal Stufe 1, 36 mal Stufe 2 und 15 mal Stufe 3 oder höher. Bei der vorangegangenen früheren Selbstbewertung hatten erst 14 die Stufe 2 gehabt und 9 die Stufe 3 oder höher.

  Stufe 1 Stufe 2 Stufe 3
alte Bewertung 115 14 9
Eigeneinschätzung 87 36 15

Es wurden eine Reihe von Fragen gestellt, die mit einer aus den vier Möglichkeiten ,,exzellent``, ,,gut``, ,,mäßig``, ,,schlecht`` beantwortet werden konnten. Die Antwortenden sollten aus ihrer eigenen Perspektive eine möglichst gute subjektive Einschätzung abgeben. Dabei ergaben sich folgende Unterschiede zwischen den verschiedenen Reifestufen, wenn man über alle Antworten summiert.

Bei der Frage ,,Wie gut ist die Fähigkeit ihrer Organisation, den Projektzeitplan einzuhalten`` antworteten 40% der Antwortenden aus Organisationen auf Stufe 1 mit ,,exzellent`` oder ,,gut``, hingegen 80% der Antwortenden aus Organisationen auf Stufe 3. Ähnliche Änderungen ergeben sich beim Durchlaufen der Reifestufen von 1 nach 3 für die anderen Fragen:

Ein interessantes Detail ergibt sich bei der Kundenzufriedenheit: Hier lag der Wert von Stufe 2 nicht, wie sonst überall, zwischen denen von Stufe 1 und 3, sondern bei nur 69%. Möglicherweise ist das darauf zurückzuführen, daß nicht die Kundenzufriedenheit bei Organisationen auf Stufe 2 schlechter ist als bei Stufe 1, sondern nur das Bewußtsein für deren Fehlen besser ausgeprägt.

Die Antwortenden wurden gebeten, im nachhinein abzuschätzen, wie zutreffend die Aussagen in der CMM-Bewertung waren im Hinblick auf die Identifikation von Stärken und Schwächen der Organisation. Bei den Schwächen fanden 63% die Aussagen sehr zutreffend, 35% zutreffend, bei den Stärken 38% sehr zutreffend, 54% zutreffend. 74% stimmten der Aussage zu, daß die CMM-Bewertung die Mühe wert war und einen erheblichen positiven Einfluß auf die Organisation hatte. 90% berichteten, daß die meisten ihrer Prozeßverbesserungsbemühungen auf den Resultaten der CMM-Bewertung basieren. 86% hielten das CMM für eine gute Leitschnur bei der Festlegung der Reihenfolge von Verbesserungsschritten.

Manche gelegentlich geäußerte Kritik am CMM und den CMM-Bewertungen erhielt in der Umfrage einige Zustimmung, allerdings immer nur mäßig viel: Die Aussage, die Empfehlungen seien zu ehrgeizig, erhielt 29% Zustimmung, die Bewertungsresultate hingen zu sehr vom Bewertungsteam ab, erhielt 18%. Alle anderen Kritikpunkte hatten weniger als 10% Zustimmung.

Wieviel und welche Verbesserungen haben die Organisationen denn nun erreicht? 44% fanden, ihre Verbesserungen seien beschränkt oder fast gar nicht vorhanden, 26% fanden sie mäßig und 31% fanden sie substantiell oder sehr groß. Fast alle Organisationen (96%) hatten einen Aktionsplan aufgestellt, aber nur 53% hatten Änderungen in Pilotprojekten vorgenommen, und ebensoviele hatten Änderungen organisationsweit eingeführt. Letztere Werte sind insofern überraschend, als 89% nicht nur einen Aktionsplan hatten, sondern auch ein Aktionsteam, um ihn umzusetzen.

../Cartoon/job_burnout.gif

Eine andere Untersuchung [BJ94] konzentrierte sich auf die Erfahrungen, die kleinere amerikanische Softwareunternehmen oder Softwareabteilungen (unter 500 Personen, im Mittel 40 Personen) mit dem CMM haben. Die Ergebnisse stammen aus 190 Fragebögen (bei 545 verschickten) und 46 Interviews mit hochrangigen Firmenvertretern (Geschäftsführer, Softwaremanager, Leiter der Softwareprozeßgruppe). Kleine Softwareabteilungen in größeren Unternehmen haben häufiger Prozeßverbesserungsprogramme (z.B. alle, die mehr als 20 Mitarbeiter haben) als kleine Unternehmungen (nur ca. die Hälfte derer mit 20-40 Mitarbeitern).

Die am häufigsten geäußerten Schwierigkeiten (mit Überlappungen) waren folgende:

Auf der anderen Seite haben kleine Organisationen auch Vorteile gegenüber größeren: Die geringere Trägheit und Bürokratie erleichert generell die Umsetzung organisatorischer Änderungen. Kürzere Dauer von Projekten beschleunigt die Einführung technischer und organisatorischer Änderungen, weil diese leichter am Projektanfang vorzunehmen sind als mitten im Verlauf eines Projekts. Die größere Nähe der Manager zum technischen Personal verbessert die Kommunikation und erlaubt eine leichtere Überwachung und Steuerung der Prozeßverbesserung.

Trotz allem überwiegen die Nachteile: Neben den Einschränkungen als Unterauftragnehmer, denen kleine Organisationen besonders oft ausgesetzt sind, und der Unmöglichkeit, manche Anforderungen des CMM überhaupt umzusetzen, sind es vor allem die Kosten, die kleinen Organisationen eine ungünstige Position bescheren. Die Kosten für Prozeßverbesserung sind für kleine Organisationen relativ höher als für große, weil sich der Aufwand nicht proportional mit der Organisationsgröße herunterskaliert. Das liegt daran, daß es einen gewissen Basisaufwand gibt, der nicht vermieden werden kann, zum Beispiel bei der Dokumentation eines standardisierten Prozesses oder bei der Beschaffung und Installation technischer Infrastruktur.

Nichtsdestoweniger haben viele kleine Organisationen erfolgreiche Prozeßverbesserungsprogramme. Sie haben den Übergang hin zu einer Betonung von Qualität als Arbeitsziel vollzogen, haben eine organisationsweite Unterstützung entsprechender Aktivitäten eingeführt und haben die Vorgaben des CMM oder anderer Prozeßverbesserungsrahmen kreativ auf ihre Bedürfnisse hin angepaßt und umgesetzt. Viele dieser Organisationen erfüllen rein formal betrachtet nicht einmal die Anforderungen der CMM-Stufe 2, haben aber trotzdem schon einen überwiegenden Teil aller Eigenschaften der Stufen 4 oder gar 5, weil sie angemessen und im Geiste des CMM ihren Prozeß verbessern.


next up previous contents
Next: 5.9 Probleme und Hindernisse Up: 5. Softwareprozeß-Verbesserung Previous: 5.7 Weiterentwicklung
Lutz Prechelt
1999-04-13