Aufwandsschätzung von Softwareprojekten in der Praxis

Matthias Hänsgen  /  14.04.22  /  Digitale Transformation

 

Einer der ersten Schritte im Rahmen unserer Softwareentwicklungs-Projekte ist die Erstellung einer Aufwandsschätzung für den Kunden. Zwar werden die Projekte heutzutage größtenteils auf Basis agiler Methoden (Scrum) durchgeführt, nichtsdestotrotz ist für die betriebswirtschaftliche Entscheidung zu einer Investition eine Budgetierung innerhalb eines Unternehmens erforderlich.

Die Ausgangssituation für eine Aufwandsschätzung stellt sich hierbei im Allgemeinen wie folgt dar:

  • Der Funktionsumfang der Software ist noch nicht vollständig spezifiziert. Der Grund hierfür ist oftmals, dass bei digitalen Transformationsprozessen geschäftliches Neuland betreten wird oder dass bei der Modernisierung von Altsystemen das entsprechende Knowhow über das System nicht mehr in der benötigten Tiefe vorhanden ist.
  • Die genaue Ausgestaltung von Funktionalitäten ist noch nicht definiert. Dies kann einen erheblichen Einfluss auf die Aufwände und damit Kosten der Softwareentwicklung haben. Um eine Analogie zu bemühen – die Erstellung eines Einfamilienhauses mit einer definierten Grundfläche, Aufteilung etc. kann je nach Ausstattung und Ausführung im Preis auch erheblich variieren.

Dies leitet zu dem nächsten Punkt über, der häufig verkannt wird. Eine Aufwandsschätzung ist kein singulärer Wert im Sinn eines Festpreises, sondern aufgrund der genannten Unschärfen mit einer Bandbreite behaftet. Die Bandbreite ist davon abhängig wie weit ein Projekt fortgeschritten ist, sprich wie ausgereift und detailliert die Anforderungen sind. Diesen Sachverhalt bildet der sog. „Cone of Uncertainty” [1] ab. Hierzu gibt es entsprechende Untersuchung im Rahmen des COCOMOII-Projektes, mit welchen Schätzkorridoren in Abhängigkeit von der Projektphase zu rechnen ist. Nach unserer Erfahrung hat sich in einer frühen Projektphase („Approved Product Definition“) die Anwendung der folgenden Werte bewährt:

  • Schätzabweichung nach unten – 50 %
  • Schätzabweichung nach oben + 100 %

Nach diesen einführenden Betrachtungen zum Thema widmen wir uns jetzt dem eigentlichen Schätzprozess.

Wie schätzt man eigentlich Softwareprojekte?

Alle gängigen Schätzverfahren basieren auf derselben prinzipiellen Methodik [McC006], unterscheiden sich aber in den zugrundeliegenden Kenngrößen/Metriken, die bei der Schätzung verwendet werden:

  • Count („Zählen“): Es wird eine Metrik wie Anzahl der Anwendungsfälle, Story Points, User Stories etc. verwendet, um die Größe und Komplexität einer Software zu quantifizieren.
  • Compute („Umrechnen“): Anhand heuristischer oder empirischer Faktoren wird die ermittelte „Größe“ der Software in einen Aufwand für deren Erstellung umgerechnet.
  • Judgement („Beurteilung“): In einem letzten Schritt kann der so ermittelte Wert ggf. durch Experteneinschätzung angepasst werden. Aus unserer Erfahrung heraus ist dieser Schritt mit Vorsicht zu verwenden, da in den meisten Fällen sich die Treffgenauigkeit der Schätzung verschlechtert.

Im nächsten Schritt betrachten wir nun, wie in unserem Unternehmen Softwareschätzungen konkret durchgeführt werden.

Grundlagen des Consist-Schätzverfahrens

Die Grundlage unseres Schätzverfahrens basiert zum einen auf der Standardisierung des Entwicklungsprozesses und der eingesetzten Technologien und zum anderen aus den Erfahrungen mit diesen in unseren Projekten. Hierzu werden während der Entwicklung z. B. die aktuellen (Produktivitäts-)Kennzahlen erfasst. Die Eckpunkte des Vorgehens stellen sich wie folgt dar:

  • Entwicklung von (Web-)Anwendungen auf einem standardisierten Technologie-Stack
    • Serverseitig, Java mit dem Spring Boot Framework
    • Web-Benutzeroberfläche, Angular Framework mit diversen Erweiterungen
  • Agiler Softwareentwicklungsprozess basierend auf Scrum mit der folgenden Vorgehensweise:
    • Schätzung der Größe/Komplexität einer Funktionalität (User Story/Anwendungsfall) in Form von sog. Story-Punkten
      • Die Storypunkte bilden eine Fibonacci-Reihe mit den Werten 1, 2, 3, 5, 8, 13, 20, 40 und 100. Je höher dieser Wert ist, desto komplexer/größer ist eine Funktionalität.
    • Umrechnung der Größe/Komplexität einer User Story in einen Realisierungsaufwand anhand des Produktivitätsfaktors:
      • Produktivitätsfaktor = Aufwand für die Realisierung eines Story-Punktes in Personentagen
      • Hierzu erfolgt die laufende Ermittlung des Produktivitätsfaktors in den aktuellen Projekten. Diese werden dann in einem weiteren Schritt bewertet und aggregiert und der daraus resultierende Wert dient dann als Produktivitätsfaktor für die Schätzungen.

Der eigentliche Schätzprozess

Im ersten Schritt muss die Basis für eine Schätzung geschaffen werden. Diese besteht daraus, die Anforderungen an die Software formal und kompakt zu erfassen. Für uns hat sich das folgende Format bewährt:

  • Funktionale Anforderungen
    • Fachklassenmodell (Entitätsmodell) mit grundlegenden Beziehungen
    • Erfassung aller User Stories (als Anwendungsfälle, ggf. detailliert durch Szenarien)
  • Nichtfunktionale Anforderungen
    • Erfassung der grundlegenden nichtfunktionalen Anforderungen (z. B. Geschwindigkeit, Sicherheit). Zur konsistenten Beschreibung hat sich hierfür die Verwendung der sog. Sophist Anforderungsschablonen [2] bewährt.

Der eigentliche Schätzprozess basierend auf den Anforderungen stellt sich dann wie folgt dar:

  • Ermittlung der Aufwände zur Erfüllung der funktionalen Anforderungen
    • Unabhängige Schätzung der Größe der User Stories durch 3 Personen, die mit dem standardisierten Technologie-Stack vertraut sind.
      • Mittelung der Schätzwerte bei Differenzen
      • Umrechnung der Storypunkte in einen Realisierungsaufwand anhand des aktuellen Produktivitätsfaktors
    • Ermittlung der Aufwände zur Erfüllung der nichtfunktionalen Anforderungen
      • Bewertung der projektspezifischen Anforderungen, die nicht durch die Standardarchitektur abgedeckt sind, in Hinblick auf eine technologische Lösung durch 2 Softwarearchitekten. Bewertung und Schätzung der technischen (Mehr-)Aufwände, die sich durch diese Anforderungen ergeben.

Durch die Aufsummierung der einzelnen Schätzwerte für die Anforderungen ergibt sich schließlich der konkrete Schätzwert, der mit der Schätzbandbreite entsprechend des „Cone of Uncertainity“ belegt wird.

Schließende Worte

Wie bereits zu Beginn dargestellt, sollte eine Schätzung vom Kunden nicht wie ein Festpreisangebot betrachtet werden. Um die skizzierte Budgetsicherheit für ein Unternehmen zu erhalten, ist dazu im Projekt zum einen ein effizientes Projektmanagement und zum anderen eine lösungsorientierte Kooperationskultur erforderlich. Damit dies prinzipiell gelingen kann, muss im agilen Entwicklungsprozess ein ständiges Monitoring der Aufwände, der Produktivität und der Abweichungen von den Schätzgrundlagen erfolgen. In Abstimmung zwischen dem Product Owner (Kunde) und dem Scrum Master (Entwicklung) muss dann bei Abweichungen entschieden werden, ob dem Kunden ein bestimmtes Feature wichtig ist (mehr Geld…) oder die Budgettreue. Im Fall der Budgettreue muss dann eine Kompensation an einer anderen Stelle der Software erfolgen.


[1]
Cone of Uncertainty, http://www.agilenutshell.com/cone_of_uncertainty

[2]
Anforderungsschablonen – der MASTER-Plan für gute Anforderungen, https://www.sophist.de/fileadmin/user_upload/Bilder_zu_Seiten/Publikationen/RE6/Requirements-Engineering_und_-Management_6-Auflage_-_Kapitel_10_-Leseprobe.pdf

[McC006]
Software Estimation: Demystifying the Black Art, Steve McConnell, Addison-Wesley Professional, February 2006