Softwareentwicklung ist für viele Unternehmen eine enorme Herausforderung: Trotz steigender IT-Ausgaben kämpfen sie mit immer gravierenderen Qualitäts- und Stabilitätsproblemen. Zu teuer, zu langsam, zu unflexibel oder ein nur schwer bezifferbarer Nutzen sind die häufigsten Kommentare. Das gilt nicht nur für öffentlich diskutierte Großprojekte wie Toll Collect oder Arbeitslosengeld II, sondern auch für kleinere interne Softwarevorhaben in fast allen Branchen.

Zur Verbesserung der Softwareentwicklungs-Produktivität gibt es drei herkömmliche Ansätze, die allerdings meist hinter den Erwartungen zurückbleiben:

Der Budgetansatz

Der Budgetansatz arbeitet mit Messgrößen wie Kosten pro Anwender oder pro Transaktion und kann helfen, die absoluten Kosten zu steuern. Meist konzentrieren sich budgetorientierte Ansätze nur auf Input-Größen wie Kosten und Personalkapazität, nicht jedoch auf den Output wie Funktionalität, Zeit, Qualität und Kundenzufriedenheit. Daher kann dieser Ansatz erhebliche Qualitätsprobleme verursachen, wenn die kostenorientierte Planung keinen Raum für Upgrades oder Weiterentwicklungen lässt. Das System arbeitet dann vielleicht kosteneffizient, liefert aber unzureichende Qualität oder ist nur begrenzt in der Lage, in kurzer Zeit neue Funktionen aufzunehmen. Solche rein ökonomisch ausgerichteten Modelle vernachlässigen außerdem die weniger eindeutig messbaren Elemente wie etwa die Mitarbeitermotivation und -qualifikation und lassen zuweilen die Gründe der Leistungsmängel im Dunkeln.

Das Capability Maturity Model

CMM, wörtlich übersetzt "Fähigkeits-Reife-Modell", ist ein anspruchsvolles und bewährtes Verfahren zur Optimierung von Prozessen, das von Experten des Software Engineering Institute (SEI) der Carnegie Mellon University, Pittsburgh, geschaffen wurde. Es eignet sich hervorragend dazu, die Prozessreife in verschiedenen Dimensionen zu beurteilen und Verbesserungshebel zu identifizieren. Allerdings tendiert es dazu, Prozesse zu "überoptimieren" und einen Overhead zu schaffen. Zudem nutzt es keine Messgrößen, so dass seine Effizienz und Effektivität schwer zu bewerten sind. Auch ist es sehr komplex - allein der Fragebogen umfasst rund 450 Fragen. Schließlich hilft das Modell zwar dabei, die Reife von Prozessen zu bestimmen, aber es ist nicht in der Lage, ihre Effizienz zu messen und zu steuern.

Das Six-Sigma-Modell

Das Six-Sigma-Modell kann die Qualität und damit auch die Produktivität wirksam verbessern, indem es die Prozessvariabilität erfasst. Allerdings wurde dieses Modell für Fertigungsprozesse entwickelt, die immer wieder gleich ablaufen - genau das aber ist bei der Softwareentwicklung meist nicht der Fall. Als Folge sind typische Six-Sigma-Zielgrößen für die Fehlerreduktion nicht übertragbar: So ist für Software eine Größenordnung von 18000 Fehlern pro Million Function Points (Defects per million) typisch, während Six Sigma 4,3 vorgibt.

Mit derartigen Schwächen soll das "Software-Development-Productivity"-Modell (SDP-Modell) aufräumen. Es folgt einer ganzheitlichen Vorgehensweise und ermöglicht es, die Produktivität der Softwareentwicklung in vielen Fällen um 20 bis 40 Prozent zu steigern - und das in einem Zeitraum von drei bis fünf Jahren. Um Produktivitätsproblemen auf den Grund zu gehen und Lösungen herauszufinden, verbindet SDP die besten Elemente aus den klassischen Produktivitätskonzepten. So vereint es vom Budgetansatz die messbare Ergebniswirkung, vom CMM die Prozessreife-Indikatoren und von Six Sigma den strikten Fokus auf Qualität und kontinuierliche Verbesserungen. Das Resultat besteht aus quantifizierbaren Ergebnissen aufgrund einer gezielten Verbesserung des Prozessreifegrads in der Organisation. Die Produktivität bemisst sich dabei nicht allein nach den absoluten IT-Kosten, sondern nach Output-Kennzahlen wie gelieferte Funktionalität, Time-to-Market und Qualität.

KPIs sind meist vorhanden

Mit dem SDP-Modell sind drei wesentliche Ansätze verbunden. Zum einen geht es davon aus, dass die Software-Entwicklungsproduktivität messbar ist. Es gibt Leistungskennzahlen (Key Performance Indicators = KPIs), die sich in fast allen IT-Unternehmen schnell erfassen lassen. Diese KPIs richten sich nach der Ergebniswirkung. In vielen Unternehmen sind die notwendigen Rohdaten zur Erhebung dieser KPIs bereits vorhanden, zuweilen können jedoch einige Messgrößen geringe zusätzliche Investitionen erfordern.

Fünf Hebel, um die Softwareentwicklung zu optimieren

Um die Prozessreife zu messen, stützt sich das SDP-Modell auf rund 60 Key Performance Areas (KPAs). Sie gliedern sich im Wesentlichen in folgende fünf Bereiche, in denen Effizienzgewinne möglich sind: • Produktdefinition - die Festlegung neuer Produkte und Dienstleistungen, das heißt, Anforderungen so zu definieren, dass die Anwendungen zielgerichtet entwickelt werden können. • Produktarchitektur - meist unterteilt in Anwendungsarchitektur und technische Architektur; die Verknüpfung neuer Produkte oder Dienstleistungen mit vorhandenen Angeboten, das heißt eine Umgebung zu schaffen, in der neue Anwendungen mit niedrigerem Aufwand erstellt und integriert werden können. • Prozesse und Tools - die Erstellung neuer Produkte mit Hilfe grundlegender Software-Entwicklungsprozesse und -Tools. Das heißt, ein mit den Entwicklungsprozessen konsistentes Toolset zu haben, das die Softwareentwicklung vereinfacht und die Qualität zu verbessern hilft. • Partnering und Lieferanten - die Nutzung von Kooperations- und Outsourcing-Möglichkeiten, wenn das Unternehmen das Produkt nicht komplett selbst entwickeln möchte. • Mitarbeiter und Organisation - das Management der Mitarbeiter und der Organisation, um sicherzustellen, dass der Prozess korrekt auf- gebaut ist und die Produkte schnell erstellt werden können.

Die folgenden Ausführungen beziehen sich auf die Kosten der proprietären Software, da nur die firmeninterne Softwareentwicklung und keine Standardsoftware-Pakete betrachtet werden. Die Softwarekosten setzen sich aus den direkten Entwicklungskosten (Umfangerweiterung der Software oder Erstellung neuer Systeme) und den Fehlerbehebungskosten zusammen. Der Ausdruck "Fehlerbehebung" wird hier bewusst dem Begriff "Wartung" vorgezogen, da Letzterer auch das Hinzufügen neuer Funktionen einschließen kann. Die aber werden den direkten Entwicklungskosten zugerechnet.

Leistungskennzahlen können sowohl für Entwicklungs- als auch für Fehlerkosten bestimmt werden. Sämtliche kostenorientierten KPIs, die in der Grafik "Entwicklungsproduktivität ist messbar" gezeigt werden, basieren auf der Input-Output-Relation, da es wenig Sinn hätte, die Kostensenkungen im Auge zu behalten, wenn gleichzeitig der Output zurückginge. Einige der KPIs - wie etwa die Anzahl der Mitarbeiter, die sich mit Softwareentwicklung oder Fehlerbehebung beschäftigen - sind relativ gebräuchlich; andere aber, wie etwa der Software-Ouput, können schwierig zu messen sein. In solchen Fällen wird mit Analogien gearbeitet. Beispielsweise wird der Output in Function Points (FPs) wiedergegeben.

Function Points statt Codezeilen

Die FP-Analyse ist eine Methode zur Abschätzung von Komplexität und Umfang eines gegebenen Softwaresystems. Dazu werden die Systemkomponenten aus Endnutzersicht identifiziert (zum Beispiel Anfragen, Schnittstellen, Outputs, Inputs), von einfach bis komplex eingestuft und gewichtet. Auf diese Weise erhält man eine Zahl, die den Umfang und die Komplexität der Aufgabe berücksichtigt. Function Points werden immer dann herangezogen, wenn sich der Output nicht sinnvoll in Codezeilen bemessen lässt.

Zur Messung der Gesamtproduktivität reichen oft sieben KPIs aus: Monatssatz des Entwicklers, Entwicklungsproduktivität, Entwicklungsumfang, Fehlerrate, Fehlerbehebungsaufwand, Monatssatz für Fehlerbehebung und Anwendungsbestand.

Die Bestimmung der am besten geeigneten KPIs ist entscheidend für den Erfolg des SDP-Ansatzes - und dafür sind Produktivität, Qualität und Kosten die zentralen Größen. Produktivität ist das Verhältnis von Output zu Input, wobei sich der Output nach dem Projektumfang bemisst und der Input nach dem Zeit- und Arbeitsaufwand (zum Beispiel Anzahl der Function Points, die ein durchschnittlicher Entwickler in einem Monat leisten kann = Function Points pro Personenmonat = FP/PM). Qualität und Kosten werden in Fehlerraten beziehungsweise Entwicklermonaten gemessen.

Zu Beginn jeder Produktivitätsanalyse sollte man die sieben KPIs messen oder zumindest abschätzen. Dazu gibt es verschiedene Schätzmethoden, die vom einfachen Vier-Punkt-Schätzer mit 30 Minuten Aufwand bis hin zu einer Woche reichen. Während die meisten davon in vielen Unternehmen bereits bekannt sein dürften, ist die Function- Point-Analyse hierzulande nicht sehr verbreitet. Für die Ermittlung der Function Points muss daher meist etwas mehr Zeit investiert werden - doch dieser Aufwand ist weit geringer als beim klassischen CMM.

Obwohl die Function-Point-Methodik nicht immer positive Resonanz erhält, ist sie die beste bekannte Methode zum Messen des Software-Output. Sie ist nicht technologieabhängig wie Lines of Code (LoC), kann auf alle Arten von Softwareprojekten angewendet werden, und es existiert eine Reihe verlässlicher Schätz-Tools und Benchmarks.

Wie reif sind Prozesse?

Die zweite, dem SDP-Modell zugrunde liegende Erkenntnis geht davon aus, dass Prozessreife messbar ist. Ein schneller CMM-ähnlicher Scan ermöglicht es, wesentliche Lücken zu erkennen und den Prozessreifegrad zu beurteilen. Im SDP-Ansatz wird dazu nicht das gesamte CMM-Modell eingesetzt, sondern lediglich eine straffe, auf die unmittelbaren Bedürfnisse zugeschnittene Analyse. Das SDP-Modell stützt sich auf etwa 60 Key Performance Areas (KPAs - wörtlich: Schlüssel-Leistungsbereiche), in denen die Prozessreife nach dem Vorbild von CMM auf einer Skala von 1 bis 5 bewertet wird.

Ist der Output gemessen, muss die Qualität des Inputs bestimmt werden. Dabei gilt es, die Fähigkeiten der IT-Organisation zu beurteilen. Hierzu können die fünf Leistungsstufen des Capability Maturity Model (beginnend, wiederholbar, definiert, gesteuert, optimiert) herangezogen werden. Gemessen werden die Fähigkeiten in den fünf Bereichen der Wertschöpfungskette, in denen Verbesserungen zu erzielen sind: Produktdefinition, Produktarchitektur, Prozesse und Tools, Partnering und Sourcing sowie Personal und Organisation. So betrachten Softwareentwickler vor allem anfangs die Produktentwicklung gerne als kreativen Prozess. Spätestens auf der dritten bis fünften CMM-Stufe aber sollten sie diese als normale technische Disziplin behandeln, bei der beispielsweise Gestaltungsvarianten getestet und überprüft werden.

Die sieben KPIs

Die Software-Entwicklungsproduktivität lässt sich über Key Performance Indicators (KPIs) messen. Dies sind: • Monatssatz für Entwicklung (Aufwand in Euro pro Entwickler und Monat); • Entwicklungsproduktivität (Function Points im Verhältnis zum personellen Aufwand); • Entwicklungsumfang (der zu erstellende Umfang an Function Points als technologie- und unternehmensunabhängige Messgröße für den Software-Output); • Fehlerrate (Fehler beziehungsweise Abweichungen von den dokumentierten oder angenommenen Nutzerspezifikationen im Verhältnis zum Bestand der zu pflegenden Function Points); • Fehlerbehebungsaufwand (personeller Aufwand für Fehlerbehebung im Verhältnis zu den Fehlern/Abweichungen); • Monatssatz für Fehlerbehebung (monatlicher Aufwand in Euro für involvierte Personen); • Anwendungsbestand (der zu pflegende Bestand an Function Points).

Ist ein Unternehmen beispielsweise auf Stufe 1 des Capability Maturity Model und möchte seine Produktentwicklung verbessern, so sollte es sich in erster Linie auf die Rationalisierung der Produktmerkmale konzentrieren - beispielsweise, indem es für die Merkmale oder Funktionen eine Grundlogik oder sogar einen Business Case entwickelt. Der Übergang von Stufe 2 auf Stufe 3 erfordert dann die Einrichtung eines wiederholbaren, klar definierten Prozesses zur Erfassung der Nutzeranforderungen. Will man auf Stufe 4 gelangen, müssen für jedes Produktmerkmal der Preis und der Wert quantifiziert und die Merkmale entsprechend priorisiert sein. Der Übergang auf Stufe 5 schließlich setzt voraus, dass alle vorherigen Schritte nicht nur beherrscht, sondern auch nachweislich laufend verbessert werden.

Dieses Vorgehen ist eine Weiterentwicklung des Capability Maturity Model: Einerseits sind weniger Fragen als beim klassischen CMM zu beantworten, andererseits wird der Gesamtrahmen erweitert und eine ganzheitliche Betrachtungsweise ermöglicht. Fokussiert sich das herkömmliche CMM hauptsächlich auf Prozesse und Tools, schließt das SDP-Modell zusätzlich die Produktdefinition und -architektur sowie die Zusammenarbeit mit Partnern und Lieferanten ein - die End-to-End-Perspektive.

KPAs und KPIs sind korrelierbar

Zwischen dem Reifegrad und der Produktivität der Prozesse lässt sich eine mathematische Korrelation herstellen: So haben beispielsweise reife Prozesse mit niedrigen Fehlerraten eine hohe Produktivität. Folglich zahlt sich eine Investition in Prozessreife in Form von Qualitäts- und Produktivitätssteigerungen aus.

Die Outputs der ersten beiden Schritte - Produktivität (KPIs) und Prozessreife (KPAs) - stehen miteinander in einer nachvollziehbaren Relation. So korrelieren beispielsweise die Reifegrade für Prozesse und Tools positiv mit den KPIs für die Entwicklungsproduktivität: Produktivitätsgrade können auf der höchsten Reifestufe ("optimiert") doppelt so hoch sein wie auf der untersten.

Weitere Beispiele für Korrelationen sind:

• Eine strikte Qualitätssicherung führt zu niedrigeren Fehlerraten;

• ein Architekturkomplexitäts-Management steigert die Entwicklungsproduktivität und verringert den Anwendungsbestand;

• ein Fähigkeits-Management erhöht ebenfalls die Entwicklungsproduktivität.

Es gibt ein paar "Hot Spots", in denen die Wirkung besonders stark sein kann. So hat beispielsweise die Zusammenarbeit mit Partnern einen sehr starken Einfluss auf die monatliche Entwicklungsrate. Insbesondere bei Offshoring können so bis zu 30 Prozent der Kosten eingespart werden. Ein weiteres Beispiel ist die Architekturreuse: Die Software-Entwicklungsproduktivität kann in Einzelfällen um bis zu 30 Prozent gesteigert werden - vor allem bei Web-Applikationen, da häufig Komponenten von anderen Vertriebskanälen genutzt werden können.

Individueller Reifegrad

Jede Organisation - zu einem gewissen Grad sogar jede Branche - hat ihren eigenen Prozessreifegrad, und die Korrelation zwischen KPIs und KPAs hängt stark von den gegenwärtigen und angestrebten Reifegraden ab. So stellt jede Branche andere Qualitätsanforderungen: Während in der Unterhaltungselektronik ein gewisser Prozentsatz an Softwarefehlern akzeptabel sein mag, wäre der gleiche Prozentsatz in der Luft- und Raumfahrt völlig undenkbar. Solche und andere Unterschiede sind bei der Realisierung eines neuen Modells für die Softwareentwicklung zu berücksichtigen.

Auch bei der Implementierung des neuen Modells müssen die spezifischen Gegebenheiten des Unternehmens beachtet werden. Befindet es sich beispielsweise auf einer der unteren Reifestufen und ist noch mit der Qualitätssicherung beschäftigt, ist es sinnvoll, zunächst ein zentrales Testteam aufzustellen.

Aufbau von Testteams

In dieser Phase sind noch keine projektspezifischen Testteams erforderlich. Derartige Anstrengungen sollten zurückgestellt werden, bis das Unternehmen von der Reifestufe 2 zur Stufe 3 übergeht. Dafür gibt es einen simplen Grund: Solange das Unternehmen noch kein klar definiertes Testverfahren etabliert hat, kann ein zentrales Testteam schon hochwertige, bis in die Einzelprojekte greifende Tests betreiben - gleichzeitig kann das Unternehmen bereits weitere Mitarbeiter schulen, so dass es beim Übergang zur Stufe 3 für jedes Projekt ein eigenes Testteam aufstellen kann. Beim Übergang von Stufe 4 zu Stufe 5 ist überhaupt kein zentrales Testteam mehr erforderlich: Es wäre zwar hilfreich für die zentrale Wissensverwertung, würde aber einer hocheffizienten Projektarbeit im Weg stehen. In diesem Fall sind projekteigene Testteams weitaus flexibler und schneller.