Damit die Kunst sich rechnet

Softwaremessung: Wie misst man die Produktivität von Softwareprojekten?
Kommentare

Software muss funktionell, modern und anforderungsrecht sein. Entwicklungsprojekte sind eine Investition und haben eine starke wirtschaftliche Komponente. Diese definiert sich aus dem Verhältnis von Aufwand und Ertrag. Untrennbar damit verbunden ist das Konstrukt der Produktivität. Kann man die Produktivität bei einer Tätigkeit mit einem hohen kreativen Anteil – wie Softwareentwicklung – messen?

In diesem abschließenden Beitrag zum Thema Softwaremessung beschäftigen wir uns mit der Produktivität der Softwareentwicklung. Diese ökonomisch getriebene Fragestellung gewinnt in Zeiten knapper Ressourcen, beschränkter Budgets und weltweiter Konkurrenz eine neue Bedeutung. Zunächst ist zu klären, was darunter zu verstehen ist. Wie kann der aus der Industrie stammende Produktivitätsbegriff in die Welt der Softwareentwicklung übertragen werden? Zwei Extrempositionen stehen sich gegenüber: Der Arbeitgeber bzw. Auftraggeber möchte am liebsten die Produktivität exakt anhand von definierten Parametern bestimmen. Dann wäre die Arbeitsleistung zwischen Projekten und Personen vergleichbar und bestmöglich zu prognostizieren. Die andere Extremposition ist die Aussage, dass hoch kreative Tätigkeiten unter keinen Umständen einer Messung und Vergleichbarkeit zugänglich sind. Die Wahrheit liegt wahrscheinlich – wie so oft – in der Mitte. Begeben Sie sich mit uns auf eine interessante Diskussion zum Thema, aus der durchaus verwertbare Schlussfolgerungen für die Gestaltung unserer alltäglichen Arbeit abgleitet werden können.

Softwaremessung – Eine Einführung in drei „Akten“
Das Thema Softwaremessung ist umfangreich in Theorie und Praxis. Für das Ableiten von Handlungsvorschlägen muss man sich mit einigen konzeptionellen Ansätzen beschäftigen.
Teil 1: Im Artikel „Softwaremessung – Wie man Entwicklungsprozesse analysiert und verbessert“ geht um die Ziele und Gegenstände der Softwaremessung. Je nach Messobjekt und Entwicklungsphase sind unterschiedliche Verfahren notwendig. Es werden Ansätze zur Messung der Softwarequantität besprochen.
Teil 2: Im Mittelpunkt von Teil 2 „Softwarequalität – so misst und verbessert man Software“ steht die Frage: „Was ist Softwarequalität“. Wenn man es definieren kann, kann man es vielleicht auch messen und objektivieren?
Teil 3
: Produktionsprozesse sollen möglichst effektiv sein. Softwareentwicklung ist jedoch eine Disziplin im Grenzbereich zwischen ingenieurmäßigen Vorgehen und künstlerischer Arbeit. Lässt sich dennoch die Produktivität bestimmen und kann Verbesserungspotenzial abgleitet werden?

Produktivität von Softwareprojekten

Putnam und Meyer definieren im Buch „Five Core Metrics“ fünf Kernmaße der Softwaremessung. Dies sind Quantität, Qualität, Zeit, Aufwand und Produktivität. Diese Größen gehören ebenfalls zu den Determinanten des Teufelsquadrats der Softwareentwicklung nach Sneed (Abb. 1). Die Produktivität wird dabei als inneres Quadrat abgebildet, die konstant bleibt, d. h. zum Beispiel die Mitarbeiter können nur eine bestimmte Menge an Software pro Zeiteinheit erstellen. Die vier Ecken des äußeren Quadrats sind die Funktionalität, die Qualität, die Zeit und die dafür anfallenden Kosten. Die Produktivitätsmessung beschäftigt sich mit den Prozessen der Softwareentstehung und Softwareerhaltung. Dabei werden die zugrunde liegenden Prozesse betrachtet, wobei sich die Prozesse zu Projekten zusammenfügen. Die Projekte sind vom Charakter her einmalig, weisen eine bestimmte Komplexität auf und haben ein definiertes Ziel. Neben Prozessen in Bezug auf Softwareentwicklung ist auch die Produktivität der Wartungs-, Migrations- und Integrationsprozesse von Interesse. Grundsätzlich kann Produktivität wie folgt definiert werden: Produktivität = Quantität/Aufwand.

Abb. 1: Das Teufelsquadrat nach Sneed

In der Literatur existieren unterschiedliche Ansätze zur Übertragung dieses allgemeinen Produktivitätsbegriffs auf den Softwareentwicklungsbereich. Hier findet sich dazu eine Zusammenstellung der wichtigsten Begriffsinterpretationen und Definitionen zur Messung der Produktivität. Deren Eignung erscheint unterschiedlich, sie lauten:

• Line-of-Code über Zeit (LOC-Maß): Gemessen werden die Codezeilen in einer bestimmten Zeiteinheit (z. B. in Tagen, Wochen, Monaten oder Jahren).
• Function-Point über Zeit: Die Anzahl der Function-Points (oder vergleichbare Einheiten, wie Use-Case-Points) in einer bestimmten Zeiteinheit werden zur Beurteilung herangezogen.
• Zeit zur Fertigstellung eines Produkts: Dabei wird lediglich die Zeitkomponente quantifiziert.
• Messung der Fehlerzahl: Die Anzahl der Fehler bestimmt die Produktivität des Produkts.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Abbildung 2 zeigt die Häufigkeit dieser Definitionen in den untersuchten Fachberichten, die sich mit dem Thema Produktivität im Softwareentwicklungsbereich auseinandersetzen. Die Feststellung der Produktivität ist damit untrennbar mit der Schätzung des Aufwands verbunden. Die Schätzung des Aufwands ist ein eigenes Thema. Dazu existiert eine Reihe von Verfahren, deren Spektrum vom bloßen Raten, über Schätzungen bis hin zu berechnenden Methoden reicht. Das Thema wurde im Entwickler Magazin vor nicht allzu langer Zeit aufgegriffen. Ein sehr einfaches Beispiel verdeutlicht diese Zusammenhänge. Ein Entwicklungsprojekt hat einen Aufwand von zwanzig Personenmonaten. Dabei wurden 10 000 Codezeilen erstellt. Die Produktivität beträgt demnach: Produktivität = 10 000 [Codezeilen]/20 [Personenmonate] = 500 [Codezeilen/Personenmonat].

Abb. 2: Häufigkeit unterschiedlicher Definitionen des Begriffs Produktivität

Bei dieser Berechnung wird implizit unterstellt, dass über die Größe Quantität (in diesem Fall 10 000 Codezielen) sämtliche Anforderungen an die Software erfüllt sind. Nun weiß jeder Entwickler, dass die Menge der Codezeilen nur eine bedingte Aussagekraft bezüglich der Funktionalität der Anwendung bzw. deren Qualität hat. Um sich der Wirklichkeit etwas zu nähern, kann man die Formel zur Bestimmung der Produktivität um die Faktoren Komplexität und Qualität erweitern, man gelangt dann zu: Produktivität = (Quantität * Komplexität * Qualität)/Aufwand.
Erweitert man das Zahlenbeispiel um die Angaben, dass der Komplexitätsfaktor 1,2 und der Qualitätsfaktor einen Wert von 0,9 betragen, so ergibt sich: Produktivität = (10 000 [Codezeilen] * 1,2 * 0,9)/20 [Personenmonate] 540=[Codezeilen/Personenmonat].
Inhaltlich bedeuten diese Werte zum Beispiel, dass die Komplexität des aktuellen Projekts um ca. 20 Prozent über den durchschnittlichen Grad der Vergleichsprojekte liegt. Hinsichtlich der Qualitätsbemühungen wird von einem Aufwand von ca. 90 Prozent ausgegangen. Das heißt ausdrücklich nicht, dass die Qualität hier vernachlässigt wird, sondern dass man ggf. bei den anderen Projekten ein besonderes Augenmerk auf eine nahezu fehlerfreie Implementierung verwenden musste (zum Beispiel bei sicherheitskritischen Anwendungen).

Ist die Produktivitätsmessung zulässig?

Die Messung der Produktivität ist und bleibt sehr umstritten. Zumindest dann, wenn es sich auf die Produktivität des Entwicklungsprozesses, also der menschlichen Arbeitsleistung bezieht. Softwareentwicklung – so wurde schon erwähnt – ist und bleibt in einem bestimmten Ausmaß eine Disziplin mit künstlerischen Anteilen. Natürlich gibt es Standards und Empfehlungen, aber es wird keine absolut richtige oder falsche Lösung geben. Eine Problemstellung wird durch mehrere Personen immer auf unterschiedliche Art und Weise gelöst. Wahrscheinlich würde man selbst die Lösung des gleichen Problems bei einem weiteren Versuch anders angehen. Die Dimensionen einer Lösung sind so vielfältig und werden durch eine Reihe von Determinanten beeinflusst (z. B. unterschiedliche Anwendungstypen, verschiedene Programmiersprachen, mehrere Optionen bezüglich der Wahl des Programmierstils …), sodass man niemals von der Lösung sprechen kann. Produktivität unter diesen Gesichtspunkten würde bedeuten, dass man beispielsweise bewerten und vergleichen müsste, in welcher Zeit ein Entwickler eine bestimmte Lösung erreicht. Um überhaupt einen Vergleich durchführen zu können, müsste sichergestellt werden, dass die Lösungen hinsichtlich ihrer Qualität identisch sind. Hier wird dazu von einem sehr interessanten Experiment bereits aus den 60er Jahren berichtet. Es wurden zwölf Programmierer mit einer identischen Aufgabe betraut. Die ersten Lösungen lagen nach zwei Stunden vor, die letzten Entwickler kamen erst nach fünfzig Stunden zu einem Ergebnis. Die Qualität soll vergleichbar gewesen sein. Nun, welche Schlussfolgerungen lassen sich daraus ziehen? Die Produktivität geistiger Arbeitsleistung (Kreativität, Problemlösungen mit einem bestimmten Grad an Abstraktion etc.) sind zwischen Personen (interpersonell) und in Bezug auf eine Person in unterschiedlichen Situationen (intrapersonell) vollständig verschieden. Man kann natürlich Personen „zwingen“, in einer bestimmten Situation schneller zum Ergebnis zu kommen. Diese Vorgabe wird dann meist jedoch mir einem Verlust an Qualität eingekauft (siehe magisches Viereck nach Sneed). Nach diesen Erfahrungen ist man zum Schluss gekommen, dass die Messung der Produktivität der Programmierleistung nicht möglich und deren Versuche teilweise als unsozial abgetan werden. Anders formuliert „Gut Ding will Weile haben“.

Arten der Softwareproduktivität

Die eingangs geschilderten Definitionen haben gezeigt, dass die Produktivität unterschiedlich gemessen und damit auch unterschiedlich definiert wird. Da der Entwicklungsprozess selbst sich in unterschiedliche Phasen (Analyse, Entwurf, Programmierung, Test, …) unterteilt, kann für jede dieser Phasen die Produktivität separat gemessen und festgestellt werden. Es existieren folgende grundsätzliche Regeln:

1. Je größer der in einer Phase notwendige Aufwand ist, um das Ergebnis (Teilziel) dieser Phase zu erreichen, desto größer ist hier die Wirkung einer hohen Produktivität. Gleichzeitig wirken sich Steigerungen der Produktivität im besonderen Maße auf das Gesamtprojekt aus.

2. Produktivität nimmt auch immer Bezug auf ein bestimmtes Maß an Qualität des Produkts. Frühe Entwicklungsphasen haben bereits einen entscheidenden Anteil an der Qualität und damit am Erfolg eines Projekts. Es muss klar sein, dass eine Erhöhung der Produktivität nicht zu Lasten der Qualität in Kauf genommen wird. Eine sorgfältige und sehr genaue Analyse hat – auch in Zeiten agiler Projektdurchführungen – seine Daseinsberechtigung. Hier Zeit einzusparen und die Anforderungen nur unvollständig zu erheben, führt spätestens im weiteren Projektverlauf zu Problemen. Eine kurzfristige Steigerung der Produktivität wird durch die Notwendigkeit einer späteren Nachbesserung, Ergänzung und Korrektur im Regelfall mehr als wieder aufgehoben. Man spricht in diesem Fall auch von der Aufnahme technischer Schulden, die später durch Zinsen (Fehlerkorrekturen) zu vergüten sind.

Man kann die Produktivitätsarten in Bezug auf den Entwicklungsprozess unterteilen (nach Sneed):

Analyseproduktivität: Unter Analyse wird die Erhebung, Analyse und Dokumentation von Informationen verstanden. Problematisch ist die Frage der Informationszugänglichkeit. Je nach Projekt ist diese entweder einfacher oder schwerer. Ein weiteres Problem ist die Gültigkeit der ermittelten Anforderungen. Wichtig ist eine klare Definition der Aufgabenstellung von Anfang an. Der Prozess der Anforderungserhebung (Requierements Engineering) ist umfassend, komplex und nicht immer klar strukturiert. Die Durchführung ist kostenintensiv. Oftmals ist es notwendig, Prototypen zu entwickeln. Messwerte sind die Anzahl der Anforderungen und Anforderungsfälle. Die zugehörige Dokumentation kann in Function oder Use Case Points ausgedrückt werden. Insofern ist die Messung der Analyseproduktivität je nach Projekt und Situation sehr unterschiedlich und lässt sich nicht verallgemeinern.
Designproduktivität: Softwaredesign ist eine kreative Tätigkeit. Die Arbeit eines Softwaredesigners ist schwer messbar und im Voraus nicht abschätzbar. Als Größeneinheiten für das Design werden Data, Object und Function Points eingesetzt. Durch den Vergleich dieser Größen mit den Arbeitstagen kann die Designproduktivität nachträglich gemessen werden. Hilfestellung ergibt sich, wenn „Standardoberflächen“ – zum Beispiel für Datenbankbusinessanwendungen entworfen werden. Die Vergleichbarkeit mit bereits realisierten Projekten kann hilfreich sein. Wird beispielsweise das neue UI für eine Dialogmaske entworfen, kann auf frühere Erfahrungen zurückgegriffen werden. Hat aber ein Wechsel der Technologie stattgefunden (zum Beispiel von Windows Forms zu Windows Presentation Foundation), ist die Vergleichbarkeit sehr eingeschränkt.
Programmierproduktivität: Bei der Neuentwicklung von Anwendungen bezieht sich die Programmierproduktivität auf den von dem Entwickler produzierten Code. Dieser lässt sich in Zeilen oder Anweisungen leicht messen. Die Interpretation ist aufgrund unterschiedlicher Programmiersprachen, Formatierungsrichtlinien und Herangehensweise an die Problemstellung schon deutlich schwerer. Wichtig ist es, die dabei enthaltenen Fehler zu berücksichtigen bzw. vom Leistungsumfang abzuziehen, denn diese müssen später korrigiert werden. Messgrößen sind erneut Object, Function und Data Points. Bei der Weiterentwicklung bzw. Änderung bestehenden Codes bezieht sich die Programmierproduktivität auf die zu ändernde bzw. hinzuzufügende Codemenge. Auch deren Bewertung ist nicht so einfach, denn jede Änderung muss von dem Programmierer auf mögliche (nicht erwünschte) Effekte geprüft werden. Ist der Programmierer bereits angehalten, Tests (meist Unit Tests) für seinen Code zu erstellen, so ist das bei der Messung zu berücksichtigen.
Testproduktivität: Grundsätzlich gilt die Testproduktivität als messbar. Diese nimmt 30 bis 50 Prozent des Gesamtaufwands in Anspruch. Die Anzahl der erforderlichen Testfälle ergibt sich aus dem vorgeschriebenen Überdeckungsgrad. Die Testproduktivität ist recht konstant und stark von technischen Voraussetzungen abhängig (Grad der Testautomation).
Gesamtproduktivität: In Migrations-, Sanierungs-, Evolutions- und Integrationsprojekten ist die Gesamtproduktivität relativ leicht messbar und auf ähnliche Projekte übertragbar. Im Gegensatz dazu ist die Gesamtproduktivität der Entwicklungsprojekte mit einem großen Anteil von Analyse- und Designaktivitäten schwer bestimmbar. Die Vergleichbarkeit ist hier grundsätzlich begrenzt.

Die wichtigsten Einflussfaktoren auf die Produktivität

Die Produktivität wird durch eine Vielzahl von Faktoren beeinflusst (Abb. 3). Um jedoch Ableitungen für die Praxis vornehmen zu können, ist es notwendig, sich auf die Kernelemente zu beziehen. Eine interessante Aufstellung dieser Kernfaktoren findet sich hier. Diese werden als die acht Gebote der Produktivität bezeichnet und lauten:

1. Ziel
2. Team
3. Anforderungen
4. Vorgehen
5. Qualität und Rework
6. Verschwendung
7. Umgebung
8. Steuerung

Abb. 3: Produktivitätseinflussfaktoren

Zu jedem dieser Faktoren können Kriterien genannt werden, die die Produktivität positiv beeinflussen und damit zu einer Beschleunigung des Entwicklungsprozesses führen (Tabelle 1).

Kernfaktor zur Beeinflussung der Produktivität Erläuterung
Ziele klare Zielstellung des Projekts, strenge Ausrichtung aller Aktivitäten an dieser Zielstellung
Team gute Mischung aus Hard und Soft Skills, Etablierung einer Leistungskultur und Motivation der Mitarbeiter,
angemessene Teamgröße und richtige Zusammensetzung
Anforderung sorgfältige Anforderungsanalyse, um sicherzustellen, dass die richtigen Dinge implementiert werden
Vorgehen gute Wahl der Vorgehensmethodik, diese kann nach Erfahrungen die Produktivität um den Faktor zwei bis drei steigern
Qualität und Rework systematische Steigerung der Qualität, Nacharbeit (Rework) reduzieren, Einführung eines Qualitätssicherungsinstruments, zum Beispiel: Einführung von Codereviews, statt nur Tests
Verschwendung durch Zielorientierung werden bereits Verschwendungen minimiert, zum Beispiel: keine Durchführung unnötiger Meetings, „Angemessenheit“ des Einsatzes aller Mittel, um das Projektziel, möglichst „schlank“ zu erreichen
Umgebung gute organisatorische Einbettung des Projekts, „Abschirmung“ gegenüber äußeren Einflüssen
Steuerung sinnvolle, durchdachte und effektive Steuerung des Projekts anhand des magischen Quadrats: Quantität, Qualität, Zeit, Aufwand, Einsatz etablierter Projektmanagementwerkzeuge und -methoden

Tabelle 1: Kernfaktoren, die die Produktivität eines Projekts maßgeblich beeinflussen (siehe hier)

Die ökonomische Sichtweite – die bessere Alternative?

Betrachtet man die Frage der Produktivität aus betriebswirtschaftlicher Sicht, so ist der Nutzwert des Systems wichtig. Nach Anselmo und Ledgard lässt sich Produktivität als der Nutzwert der Software dividiert durch deren Erstellungskosten darstellen: Produktivität = Nutzen/Kosten.
Diese wird dann in Geldeinheiten ausgedrückt. Auch Boehm („Value-driven Software Development“) bezweifelte die Messung der Produktivität auf der Basis von Softwaregrößen. Sein Gegenvorschlag war die Messung der Produktivität anhand des wirtschaftlichen Werts des Produkts. Dabei ist der betriebswirtschaftliche Nutzen und nicht die Größe des Systems wichtig. Er hat vorgeschlagen, den Projektfortschritt anhand der Earned-Value-Analyse zu messen. Diese zielt darauf, den IT-Projektfortschritt jederzeit kontrollierbar und prognostizierbar zu machen. Die dahinterstehende Grundidee ist: Durch die Unterstellung der Proportionalität von Ist- und Plankosten erhält man falsche Ergebnisse. Die Earned-Value-Analyse basiert stattdessen auf dem Vergleich von Ist- mit Soll-Kosten. Eine Reihe von weiteren Kennzahlen wird für die Analyse und den Vergleich von Projekten gebildet.

Weitere Ansätze zur Steigerung der Produktivität

Aus den vorherigen Schilderungen den Schluss zu ziehen, dass Produktivität aufgrund der vielen Faktoren und der Spezifika von Softwareentwicklung grundsätzlich nicht messbar ist, wäre falsch. Statt den Kopf in den Sand zu stecken, kann man folgende Empfehlungen für die Praxis ableiten, durch deren Umsetzung man eine Steigerung der Produktivität erreichen kann:

• Leistung der Mitarbeiter erhöhen: mögliche Maßnahmen sind die Erhöhung der Qualifikation durch Weiterbildungsmaßnahmen, Verbesserung der Arbeitsumgebung und Arbeitsbedingungen, Etablierung eines kooperativen und offenen Führungsstils und Förderung einer guten Unternehmenskultur.
• Erhöhung der Zufriedenheit bei den Mitarbeitern durch ansprechende und fordernde Arbeitsaufgaben und Übertragung von Gesamtverantwortung.
• Effizienzverbesserungen der Arbeitsschritte durch den Einsatz von CASE-Umgebungen, die Optimierung der Rechnerausstattung (zum Beispiel sehr guter Bildschirm in entsprechender Größe und Auflösung) und Verbesserung der Möglichkeiten der Bürokommunikation.
• Verwendung von aktuellen und etablierten Vorgehensmodellen der Softwareentwicklung durch die Motivation zum frühzeitigen Erstellen von Prototypen und der Einführung agiler Entwicklungsansätze wie Scrum.
• Förderung der Wiederverwendung durch den Einsatz von Komponentenbibliotheken und einer grundsätzlichen Ausrichtung des gesamten Entwicklungsprozesses auf eine komponentenorientierte Entwicklung.
• Sorgfältige Personalauswahl: Das Ziel ist es, die Motivation und das mögliche Leistungsvermögen eines Mitarbeiters bereits im Vorfeld der Einstellung zu bestimmen.

Fazit und Ausblick

Das Thema Softwaremessung, das wir in den letzten Ausgaben des Entwickler Magazins in einer dreiteiligen Serie angerissen haben, ist vielschichtig. Zugegeben: Es macht an vielen Stellen noch einen stark theoretischen und leicht akademischen Eindruck. Das dürfte auch der Grund dafür sein, dass es in der Praxis noch nicht die Bedeutung erlangt hat, die eigentlich notwendig ist. Die Notwendigkeit ist jedoch offensichtlich: Softwareentwicklungsprojekte müssen sich im Sinne einer Investition kapitalmäßig rechnen. Die wirtschaftliche Dimension erlangt damit eine zunehmende Bedeutung. Es gilt, die Ansätze des betrieblichen Controllings auf den IT-Bereich zu übertragen und dafür entsprechend anzupassen. Eines sollte auf jeden Fall klar geworden sein, Software lässt sich vermessen und damit in ihren bestimmenden Dimensionen auch einordnen. Zwar bleiben die Komplexität, die Qualität, der Aufwand und letztendlich die Produktivität immer mit einer bestimmten Unsicherheit behaftet. Eine exakte Definition und Messbarkeit wird es auch in der Zukunft nicht geben, aber brauchbare Näherungswerte für die Arbeit in der Praxis kann man schon heute bestimmen. Es lohnt sich, sich die eigenen Entwicklungsprojekte unter diesen Gesichtspunkten anzusehen und im Sinne eines Benchmarks Vergleiche zuzulassen.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

 

Aufmacherbild: Young pretty woman in shirt and colorful splashes von Shutterstock / Urheberrecht: Sergey Nivens

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -