Über unsMediaKontaktImpressum
Florian Schnitzhofer 15. März 2016

Leistungsorientiertheit in modernen Software-Entwicklungsprojekten: So schätzen und bewerten Sie richtig!

Moderne Softwareentwicklung strebt nach Leistungsorientiertheit, Objektivierung und Standardisierung. Eine nachvollziehbare Aufwandsabschätzung und standardisierte Metriken zur Performancemessung in der Softwareentwicklung sind die Basis für jedes gelungene Softwareprojekt. 

Seit den Anfangstagen der Softwareentwicklung wurde die externe Beschaffung von Software und Programmierleistung mit Metriken bewertet. Zum Einsatz kamen Personentage (PT), Lines of Code (LOC), Story Points (SP) oder Preis der Dienstleistung pro Programmierstunde (€). Alle diese Metriken lassen nur einen beschränkten Rückschluss auf die objektive Programmier-Performance oder den tatsächlichen Umfang von eingekaufter Software zu. Heutige Produktivitätsfaktoren sind meist subjektiv und speziell bei zugekauften Programmierleistungen lassen sich die Anbieter schwer vergleichen. Es bedarf einfacher und standardisierter Metriken zur Abschätzung der Entwicklungsperformance. Speziell die agile Softwareentwicklung stellt die IT-Beschaffung vor neue Herausforderungen. Dieser Artikel stellt Messgrößen für die effiziente Umsetzung von Softwareprojekten vor und beschreibt Methoden für eine agile Beschaffung von Programmierleistungen. Dabei dreht sich alles um die Fragestellung, wie man agile Softwareentwicklung zum Fixpreis einkaufen bzw. planen kann.

Aufwandsschätzung als Basis für Projektperformance

Die Basis jedes industrialisierten Softwareprojekts ist die initiale Aufwandsschätzung. Ressourcen müssen geplant, Kosten geschätzt und die Meilensteine bis zum Projektende festgelegt werden. Die initiale Aufwandsschätzung erfolgt zum Beginn des Projekts und steht vor der großen Herausforderung, dass der Projektumfang noch nicht abschließend definiert werden kann. Häufig werden vergleichende Schätzungen durchgeführt: "Vermutlich hat dieses Projekt eine vergleichbare Größe wie Projekt B und wird somit ca. 1 Million Euro kosten". Hierbei handelt es sich um eine valide Schätzmethode und man kann damit einen groben Budgetrahmen festlegen. In der nächsten Projektphase muss diese Abschätzung konkretisiert werden. Als Vorarbeit muss der tatsächliche fachliche, funktionale Projektumfang mit allen High-Level-Anwendungsfällen (Epics) definiert werden. Nur so kann eine verlässliche Aufwandsschätzung durchgeführt werden. 

Methoden der Aufwandsschätzung

  • Experten-Schätzungen
    Je nach Komplexität, Priorität und Größe eines Projekts kommen unterschiedliche Methoden der Expertenschätzung zum Einsatz. Die einfachste Schätzmethodik ist die Schätzung durch einen außergewöhnlich erfahrenen Senior Projektmanager. Auf Grund der zahlreichen absolvierten Softwareprojekten ist es diesem Experten sehr einfach möglich, den konkreten Aufwand für die unterschiedlichen Projektteilnehmer abzuschätzen. Je größer die Projekte werden, umso wichtiger werden multiple Expertenschätzungen. Abhängig vom Bedarfsfall empfiehlt sich eine der folgenden Schätzmethoden: Mehrfachbefragung, Delphi-Methode oder die Durchführung einer Schätzklausur [1].
  • Parametrisierte Schätzungen
    Die parametrisierte Schätzung von gesamten Softwareprojekten oder Softwarekomponenten erfolgt idealerweise mit einer organisationsinternen historischen Projektdatenbank oder mit einer öffentlichen Projektdatenbank. Dabei werden die Schätzparameter durch die Fach- oder technischen Experten ermittelt und mit der historischen Projektdatenbank abgeglichen. Diese Methode und eine umfangreiche historische Projektdatenbank lieferten die besten Schätzergebnisse. Beispiele sind die ISBSG-Projektdatenbank [2] oder der ReqPOOL Estimation Manger [3].
  • Komplexitäts-Schätzungen
    Moderne Softwareentwicklungsteams tendieren zur Bewertung der technischen Umsetzungskomplexität der Anforderungen. Als Ergebnis erhält man die Komplexitätsbewertung in Form von Story Points, T-Shirt-Größen oder Function Points. Aufgrund von historischen Erfahrungswerten kann von dieser Komplexitätseinschätzung auf den tatsächlichen Umsetzungsaufwand geschlossen werden. Generell sollte auf komplexe Mathematische Modelle zur Umrechnung auf den Aufwand verzichtet werden, da sie eine trügerische Sicherheit vermitteln. Eine einfache Umrechnung (z. B.: 1 Function Point kann mit 2 Personentagen Aufwand umgesetzt werden) ist erfahrungsgemäß die kosteneffizienteste und objektivste Methode, um von der Komplexität auf den Umsetzungsaufwand zu kommen.

Bei der korrekten Aufwandsschätzung ist zu beachten, dass der Zahlenwert immer mit einer Ungenauigkeit (Varianz) angegeben wird. Die langjährige Schätzerfahrung hat gezeigt, dass Schätzungen selten nach unten hin abweichen. Der tatsächliche Umsetzungsaufwand liegt beim Großteil der Softwareprojekte signifikant über dem initial geschätzten Wert. Bei der Grobschätzung eines Projekts kann die Abweichung bis zu 100 Prozent des geschätzten Wertes liegen. Die Korrektheit der Feinschätzung (Bottom-Up-Schätzung) eines Softwareprojekts sollte sich im 20 Prozent-Korridor zum tatsächlichen Umsetzungsaufwand bewegen. 

Performancemessung im Softwareprojekt

Aufbauend auf der verlässlichen Aufwandsschätzung kann ein vollständiger Projektplan für das Softwareentwicklungsprojekt erstellt werden. Der zuverlässige Projektplan bildet die Basis für eine nachvollziehbare Umsetzung. Für die Performancemessung von Entwicklungsleistungen werden Referenzpunkte herangezogen. Während der Umsetzung werden die anfallenden Aufwände regelmäßig mit den Planwerten verglichen und über Performanceindizes transparent gemacht. Die Entwicklungsperformance wird mit dem objektiven Fertigstellungswert berechnet. Dieser ergibt sich als Summe der Planwerte der bereits abgeschlossenen Anforderungen, bzw. User Stories. Als Performanceindikator kann man nun die Zeiteffizienz des Softwareprojekts berechnen.

Die Zeiteffizienz ergibt sich aus dem Fertigstellungswert geteilt durch den aufsummierten Planaufwand bis zum heutigen Tag. Damit erhält man ein objektives Maß, wie weit sich das Projekt im zeitlich gesehenen Plansoll befindet. Die Kosteneffizienz errechnet sich aus dem Fertigstellungswert geteilt durch die bereits angefallenen Kosten (z. B.: Buchungsstunden) bis zum heutigen Tag. Dabei misst man den Wert der bisher geleisteten Arbeit. Beide Performanceindikatoren geben einen objektiven und nachvollziehbaren Status der Projektentwicklung wieder. Im historischen Verlauf kann somit die Entwicklungsperformance in Relation zum Projektfortschritt gemessen werden.

Der nächste Schritt ist die projektunabhängige Messung von Entwicklungsperformance. Dafür benötigt es eine unabhängige Messgröße für Software.

Funktionale Softwaregröße als objektive Metrik

Allgemein können Güter durch Metriken definiert und vergleichbar gemacht werden. Beispielsweise werden Wohngrößen in Quadratmetern und Motoren in Pferdestärken (neuerdings KWh) gemessen und verglichen. Um diese Messbarkeit auch in der Informationstechnologie zu ermöglichen, wurde das System der Function Points entwickelt. Die Function-Point-Analyse [4] ist eine Methodik, welche zur Bewertung des fachlich-funktionalen Umfangs eines Softwaresystems dient.

Das Function-Point-Verfahren rief Ende der Siebzigerjahre Allen J. Albrecht, im Rahmen seiner Tätigkeit bei dem US-amerikanischen Unternehmen IBM, ins Leben. Das Bewertungsergebnis, die Functional Size, wird in der Maßeinheit Function-Points angegeben.

Messbares Scope-Management

Function-Points werden in der Entwicklung von Software als Grundlage für Aufwandsschätzung, Benchmarking und allgemein zur Ableitung von Kennzahlen zur Produktivität und Qualität eingesetzt. Der Vorteil besteht in der Ermittlung von Kennzahlen ohne eine Verbindung zu technischen Details, wie verwendete Programmiersprachen oder Systembedingungen. Die ermittelten Function-Points (FP) können dadurch transparent als Grundlage zur Aufwandsschätzung oder Benchmarking verwendet werden und unterstützen das Controlling bei Kennzahlenanalysen.

Entsprechend der Vorgehensweise bei der Aufwandsschätzung empfiehlt es sich bereits zu Beginn eines jeden Softwareprojekts, die funktionale Größe zu bestimmen. Sobald der Projektumfang mit den wichtigsten Anwendungsfällen (Epics) definiert ist, kann die Größe der jeweiligen Funktionalitäten abgeschätzt werden. Als Ergebnis erhält man den vollständig bewerteten Funktionskatalog der geplanten Software. Damit kann der Fachbereich erfolgreich eine Kosten-/Nutzen-Rechnung auf granularer Ebene durchführen. Fachliche Aufwandstreiber werden bereits vor einer externen Vergabe erkannt und sind für alle Beteiligten transparent.

Während der Projektumsetzung wird der definierte Funktionskatalog (Backlog) weiter entwickelt und an neue fachliche Anforderungen angepasst. Änderungen an der Funktionalität können erneut mit Function-Points bewertet werden. Die Summe der Function-Points über alle Funktionalitäten ergibt dann die Gesamtgröße der Software. Somit wird bei jedem nachträglichen Change-Request die tatsächliche Auswirkung auf die Anwendung transparent aufgezeigt. Zusätzlich können Aufwandsschätzungen von nachträglichen Change-Requests durch Referenzwerte basierend auf den Function-Points validiert werden. Unverhältnismäßig teuer angebotene nachträgliche Change-Requests oder freche Aufwandsschätzungen bei Rahmenverträgen gehören mit dieser Methodik der Vergangenheit an.

Objektive Messung der Entwicklungsperformance

Durch Analyse der bestehenden Entwicklungsleistungen – irrelevant ob extern beauftragt oder durch interne Ressourcen erbrachte Entwicklungsleistung – ist eine Bestimmung der Performance der Entwicklung über mehrere Releases messbar. Diese analysierten, historischen Werte dienen der Kalibrierung dieser Methodik und ermöglichen die Bestimmung der Stückkosten für einen implementierten Function-Point. Hierzu müssen zusätzlich zum Quellcode die historischen Werte der Entwicklung und die Dokumentation der entwickelten Funktionalitäten zur Verfügung gestellt werden.

Für die Entwicklungsperformance von Software gibt es Referenzwerte mit Bezug auf Function-Points. Abhängig von der eingesetzten Technologie belaufen sich die Stückkosten für einen implementierten Function-Point auf durchschnittlich 1,5 bis 3 Personentage.

Die Einführung von regelmäßigen Aufwandsschätzungen und die Messung der funktionalen Größe von Software kann Einsparungen bei der Softwarebeschaffung von bis zu 35 Prozent realisieren. Der Einsparungseffekt ergibt sich durch die verbesserte Planung während der Softwareentwicklung, transparenterer Nachverfolgung von Änderungen und der vollständigeren Spezifikation vor der Übergabe.

Agile Softwarebeschaffung vs. Beschaffung als Gewerk

Bei der externen Beschaffung von Programmierleistung hat man wenig bis keinen Einfluss auf die Entwicklungsleistung und auf die Performance-Faktoren während der Entwicklung. Umso wichtiger ist eine detaillierte Beschreibung der Funktionalität und der Anforderungen an die Software vor der Angebotseinholung. Nur bei einer vollständigen Spezifikation macht die Beschaffung als Gewerk Sinn. Zusätzlich zu den funktionalen Anforderungen sollten auch Umweltfaktoren, nicht funktionale Anforderungen und etwaige Zukunftsszenarien definiert werden. Die Angebotslegung und die anschließende Umsetzung der Programmierfirmen erfolgt dann genau auf diesen vordefinierten Anforderungen. Die langjährige Beschaffungs-Praxis zeigt, dass bei heutigen Angeboten nur wenig Spielraum für Änderungen bleibt und der starke Preisdruck für eine gefährliche Reduktion des Risikopuffers sorgt.

Bei der Beschaffung als Gewerk hat der Kunde keinen Einfluss auf die Entwicklungsperformance während der Projektlaufzeit und konzentriert sich auf die Abnahme der fertigen Software. Nur hier hat der Kunde die Möglichkeit, die gelieferte Softwarequalität zu beanspruchen und nicht umgesetzte Funktionalität zu reklamieren.

Diese nicht zufriedenstellende Situation hat in den vergangenen Jahren dazu geführt, dass viele Programmierleistungen als Rahmenverträge eingekauft wurden. Der Vorteil bei der Beschaffung von Personenstunden Programmierleistung ist es, dass zu Beginn des Projektes nicht der gesamte Scope feststehen muss. Je nach Bedarf kann man diese Stunden im Laufe eines Projektes verbrauchen. Die Herausforderung für die Umsetzung eines Projekts dieser Art ist das strenge Aussteuern des magischen Projektdreiecks aus Budget, Projektumfang und Meilensteine. Dafür benötigt es einen sehr erfahrenen und mit den Tücken der Softwareentwicklung vertrauten Projektmanager.

Die empfehlenswertere Alternative dazu ist die Beschaffung von Softwareprogrammierleistungen nach der funktionalen Größe der programmierten Software. Dabei handelt es sich um eine Methode der agilen Beschaffung die speziell agile Projektabwicklungen unterstützt. Anstatt Personentage einzukaufen bestellt man beim Lieferanten einen Rahmenvertrag an standardisierten Function-Points. Function-Points sind die Messgröße für funktionale Größe von Software und werden durch die Internationale Function-Point User Group standardisiert [5]. Der Vorteil dieser Methodik ist, dass Softwareprogrammierleistung beschafft werden kann, obwohl zu Beginn des Projekts noch nicht der gesamte Umfang feststeht. Ein weiterer Vorteil dieser Methode ist die ständige Kontrollierbarkeit und Transparenz des externen Dienstleisters. Mit einem starken internen Produktverantwortlichen kann trotz agiler Softwareentwicklung eine Beschaffung mit Gewerks-Charakter ermöglicht werden.

Messbarkeit bei der Abnahme der Software

Die erfolgreiche Abnahme einer Individualsoftware dreht sich um folgende Fragestellung: "Wurden alle meine Anforderungen und eingebrachten Change-Requests erfolgreich implementiert und steht mir die Software im vollen Umfang zur Verfügung?". Auch für diesen Anwendungsfall lässt sich die funktionale Größe als objektive Metrik heranziehen. Zur funktionalen Größe der ursprünglich beauftragten Softwareanwendung werden alle weiteren Änderungen aufaddiert und mit der gelieferten Softwarelösung verglichen. Abweichungen in der funktionalen Größe weisen auf nicht gelieferte Funktionalitäten hin oder sind ein guter Indikator für ungeplante Scope-Erweiterungen ("Scope-Creep").

Werkzeuge zur automatisierten Qualitätskontrolle des gelieferten Quellcodes können zum Zeitpunkt der Abnahme die Qualität der Software messen. Für die aufgedeckten Schwachstellen wird eine automatisierte Aufwandsschätzung für dessen Behebung durchgeführt und man erhält die anfallende "technische Schuld" (technical dept) in Personentagen als Ergebnis der Analyse. Gewappnet mit dieser Information empfiehlt es sich, diese Schwachstellen mit dem Lieferanten zu diskutieren. So kann noch vor einer Abnahme über die Behebung der Schwachstellen und die Finanzierung des Zusatzaufwands verhandelt werden. Ziel der metrikbasierten Abnahme ist es, die optimale Qualität der extern programmierten Software zu gewährleisten.

Am Weg zur industrialisierten Softwareentwicklung muss die Programmierleistung planbarer, messbarer und Qualitätsunterschiede nachvollziehbarer werden. Die Methoden zur Leistungsmessung existieren bereits seit Jahrzehnten und nun liegt es an den Einkaufs- und Softwareentwicklungsabteilungen, diese in den täglichen Softwareentwicklungsprozess einzubinden.

Autor

Florian Schnitzhofer

Florian Schnitzhofer berät das IT-Management führender Unternehmen in Deutschland und Österreich und ist als zertifizierter Projektmanager spezialisiert auf große industrialisierte Softwareentwicklungsprojekte.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben