Aufwandsschätzung (Softwaretechnik)

Aufwandsschätzung oder -abschätzung oder Kostenschätzung ist in der Softwaretechnik ein Bestandteil der Planung eines Softwareprojekts oder eines Arbeitspaketes. Dabei wird geschätzt, wie viele Personen und wie viel Zeit für die einzelnen Arbeitsschritte oder Programmteile notwendig sind, welche Ressourcen gebraucht werden und was eine Umsetzung letztlich an Kosten verursachen kann. Kosten, Termine und benötigte Ressourcen sind die Grundlage für ein Angebot oder für eine Entscheidung, ob, wie und wann ein Softwareprojekt oder Arbeitspaket daraus gemacht wird.

Struktur der Kosten

Im Bereich der Softwareentwicklung sind die Hauptkosten die Personalkosten; die Schätzung bezieht sich daher hauptsächlich darauf.

Daneben gibt es noch Sachkosten (soweit nicht in den Personalkosten enthalten) wie z. B.

  • benötigte Infrastruktur wie Computer o. ä.,
  • Rechenzeiten und Netzwerkkosten,
  • Lizenzen für Betriebssysteme und Tools,
  • Testhardware,
  • Umrechnungskurse,
  • Reisekosten.

Diese hängen oft von den Personalkosten ab, denn je länger ein Projekt dauern wird und je mehr Leute damit beschäftigt sein werden, desto mehr Sach- und Nebenkosten fallen an.

Für die zu erwartenden Gesamtkosten sind darauf noch erhebliche kaufmännische Aufschläge zu berücksichtigen, so für

  • Realisierungsrisiko (ein Großteil der IT-Projekte wird abgebrochen, ist nicht machbar etc.),
  • Sicherheitsaufschlag für Fehleinschätzung (Eisberg-Faktor),
  • Vorfinanzierungskosten,
  • Inflation, Personalkostensteigerung (bei länger laufenden Projekten),
  • Wechselkursrisiken (bei Auslandsprojekten),
  • Opportunitätskosten.

Personalaufwand

Die Schätzmethode ist abhängig von der Größe des Aufgabenumfangs (also Schätzung vor der Schätzung).

Für die Schätzung kleinerer Aktivitäten, z. B. Arbeitspakete in einem laufenden Projekt oder Änderungen in einem bestehenden System, wird meistens die Schätzklausur oder Delphi-Methode benutzt, weil hier das Augenmaß der Beteiligten die beste und kostengünstigste Schätzung liefert.

Für die Schätzung sehr großer Projekte wird meist der Vergleich mit anderen sehr großen Projekten benutzt. Mit Auf- und Abschlägen werden dann die Kosten für das aktuelle grob geschätzt. Durch Herunterbrechen auf einzelne Teilaufgaben wird dann der große Topf verteilt. Für diese Teilaufgaben werden dann Schätzungen erstellt. Zuletzt können diese wieder zusammengerechnet werden.

Die Grundstruktur für die Schätzung des Personalaufwandes eines mittelgroßen Projektes ist:

Menge × Preis × Kompetenzfaktoren

Dies kann sowohl für einzelne Teile oder Phasen gemacht und die Kosten dann addiert werden, oder für das Gesamtprojekt.

Größenmaße (Mengen)

Gebräuchliche Größenmaße für Programme sind Lines of Code (LOC), Function Points (FP), DSI (Delivered Source Code Instructions), oder Dokumentseiten.

Nach Watts Humphrey (Autor von The Personal Software Process) sind die meisten Menschen nicht sehr gut darin, den Zeitaufwand direkt zu schätzen. Stattdessen kann man aber erstaunlich genau die Größe des Programmcodes vorhersagen. Aus den Größen der geplanten Softwarebausteine, Korrekturfaktoren für diverse Einflussgrößen und Erfahrungsdaten wird dann der zu erwartende Zeitaufwand ermittelt. Das Schätzverfahren COCOMO berücksichtigt besonders viele Einflussfaktoren.

LOC wird häufig kritisiert, da der Wert schon durch eine unterschiedliche Codeformatierung beeinflusst wird (bis zum Faktor 3). Das LOC-Größenmaß stuft lange Programme als aufwändiger ein als kurze Lösungen. Die Länge eines Programms muss aber nicht zwangsläufig eine schlechtere Lösung bedeuten. Gut geschriebener, selbsterklärender Code muss nicht kurz sein, da er aufgrund seiner Lesbarkeit in der Regel wartbarer ist als ein auf Textkürze optimierter Programmcode.

Ferner benötigen unterschiedliche Entwickler für die gleiche Funktionalität unterschiedlich viele Programmzeilen. In der Praxis gibt es dramatische Produktivitätsunterschiede bei Entwicklern. Sogenannte „Superprogrammierer“ können 10- bis 100-fach mehr LOC pro Tag erzeugen als der Durchschnitt. Es gibt Projekte, bei denen kaum eine Zeile Code geschrieben wird, sondern z. B. nur interaktive Eingaben in ein vorhandenes System erfolgen (z. B. Datenbank-Tuning). Bei Projekten, bei denen die Codierung des Quellcodes nur 7 % des Gesamtaufwands ausmacht, ist LOC kein geeignetes Maß. LOC als Schätzgrundlage muss heute eher als historisch angesehen werden.

Trotz aller Kritik ist das LOC-Größenmaß noch weit verbreitet, wahrscheinlich deshalb, weil es intuitiv und leicht zu messen ist. Insbesondere im Nachhinein werden mitunter LOC (wozu dann auch Scripts und Test-Code zählen) als Maß für den Umfang einer Software und als Maß für die Leistung der Entwickler herangezogen. Davor ist zu warnen: Wer LOC als Maß für Leistung nimmt, wird viele davon bekommen, mit allen negativen Auswirkungen auf Einfachheit, Wartbarkeit, Performance, Zuverlässigkeit.

Statt LOC wurden später oft auch DSI (delivered source instructions) genommen. Das scheint vernünftiger, aber die prinzipiellen Probleme bleiben. So zählen z. B. Kommentare, die auch erheblich zu Qualität beitragen können, nicht mit.

Die Function-Point-Methode (nach Allen J. Albrecht, IBM) geht nicht vom zu erwartenden Code aus, sondern von den Anforderungen und versucht, die Anzahl und Komplexität von Datenstrukturen und Funktionen/Methoden zu schätzen, indem diese als einfach/normal/schwierig klassifiziert und mit entsprechenden Aufwandsfaktoren versehen werden. Diese Mengenfaktoren werden dann für Erschwernisse korrigiert. Die Function-Point-Methode ist im kommerziellen Umfeld weit verbreitet. Es wurde versucht, sie an andere Umfelder anzupassen.

In Fällen, wo das Hauptergebnis in Textdokumenten besteht wird auch häufig die zu erwartenden Seiten Papier als Maß benutzt und mit 1PT/Seite bewertet (z. B. Studien, Analysen, Pflichtenhefte).

In anderen Fällen (z. B. Pflichtenheft) wird auch die Anzahl von Sitzungen eines Gremiums herangezogen und daraus der Zeitaufwand einschließlich Vor- und Nachbereitung aller Beteiligten errechnet.

Zerlegung in Komponenten

Für eine gute Aufwandsschätzung ist es erforderlich, dass man gut verstanden hat, was gefordert wird, dass der Leistungsumfang genau definiert ist und Dinge, die zwar sinnvoll, nützlich oder naheliegend aber nicht gefordert sind, explizit ausgeschlossen werden. Zwingende Notwendigkeit ist das Vorliegen eines Pflichtenheftes (Requirement Specification), das ggf. noch weiter präzisiert werden muss. Darauf basierend kann eine Liste der zu liefernden Komponenten und der im Projektverlauf zusätzlich zu erstellenden Hilfskomponenten erstellt werden (insbesondere Scripts, Tests, Diagnose-Hilfen). Es kann dann der Umfang oder Aufwand für jede Komponente einzeln geschätzt werden. Unter der Annahme, dass die jeweiligen Schätzfehler voneinander statistisch unabhängig sind, heben sich die Schätzfehler für die einzelnen Komponenten teilweise gegenseitig auf.

Hierbei ist jedoch zu beachten, dass systematische Schätzfehler, wie zum Beispiel ein generelles Unterschätzen von Aufwänden durch komponentenbasiertes Schätzen, nicht behoben werden. Ferner stellt sich oft heraus, dass im Laufe des Projekts noch Komponenten benötigt werden, die gar nicht geschätzt wurden. Um solchen systematischen Schätzfehlern zu begegnen, kann man Schätzungen von alten Projekten mit den tatsächlichen Projektgrößen korrelieren und aus dieser Korrelation einen entsprechenden Korrekturfaktor für den systematischen Schätzfehler ableiten (Eisbergfaktor).

Berücksichtigung von Erschwernissen und Restriktionen

Soweit nicht schon bei der Komponentenschätzung berücksichtigt, müssen Erschwernisse oder Restriktionen durch Korrekturfaktoren berücksichtigt werden. Bei der COCOMO-Methode sind 14 solcher Faktoren angegeben, die aus statistischer Auswertung von vielen Projekten gewonnen wurden. Manche sind heute irrelevant (z. B. Turnaround-Zeit im Closed-Shop-Betrieb), die meisten aber noch nützlich. Der wichtigste ist die Qualität der Entwickler. Er ist bei Böhm mit einer Spanne von 4.2 zwischen bestem und schlechtestem Team angegeben und dürfte heute noch höher sein.

Schätzverfahren

Barry W. Boehm, der Vater von COCOMO nennt auch noch einige andere Schätzverfahren:

Analogie

Man sucht nach ähnlichen Projekten und nimmt mit Auf- und Abschlägen für dies und jenes deren Kosten.

Vorteil: Bezug auf reale Kosten.
Nachteil: Unterschiede in Aufgabe, Systemumgebung, Personal.

Geeignet für Gesamtsicht, wo man sich sonst in Details verlieren würde und für Plausibilisierung.

Parkinson-Verfahren

„Parkinsons erstes Gesetz“ besagt „Arbeit dehnt sich aus, so weit es geht“: Wenn man Budget und den Endtermin kennt, ergibt sich daraus, wie viele Leute man einsetzen kann und was es kostet. Dieses Verfahren ist aus der Praxis bekannt: Wenn man zu früh fertig ist, macht man Verschönerungen und testet mehr. Wenn man nicht fertig wird, aber das Budget erschöpft oder der Endtermin erreicht ist, wird der erreichte Zustand als fertig erklärt.

„Price-to-Win“

Eventuell ist dem Anbieter bekannt, was der potenzielle Kunde zu zahlen bereit ist, oder was ein Wettbewerber anbietet. Mitunter weichen diese Angaben von der eigenen Kalkulation – nach oben oder unten – ab. In diesen Fällen wird die Schätzung solange frisiert, bis sie zur vermuteten Erwartung des Kunden passt.

Um den Projektzuschlag zu erhalten, kann das auch zu unwirtschaftlichen Angeboten führen. Boehm schreibt dazu: „The price-to-win technique has won a large number of software contracts for a large number of companies. Almost all of them are out of business today.“ („Die Price-to-Win-Technik hat vielen Softwarefirmen eine große Zahl an Aufträgen verschaffen können. Die meisten dieser Firmen sind heute nicht mehr im Geschäft.“)

Delphi-Methode oder Schätzklausur

Alternativ oder zusätzlich kann die Aufwandsschätzung nach der Delphi-Methode verbessert werden. Dabei werden einfach mehrere Personen gebeten, unabhängig voneinander Schätzungen abzugeben. Die Hoffnung ist wieder, dass sich Schätzfehler bei der Mittelwertbildung gegenseitig ausgleichen. Zusätzlich besteht bei der Delphi-Methode die Möglichkeit, die Schätzer über stark voneinander abweichende Schätzungen diskutieren zu lassen. Dabei kann z. B. aufgedeckt werden, dass das Gros der Schätzer einen Problemaspekt übersehen und deswegen den Aufwand unterschätzt hat. Ebenso kann es sein, dass ein Schätzer eine Realisierungsidee hat, die einen wesentlich geringen Aufwand erfordert. Wichtig ist dabei, dass sich die Beteiligten über den Schätzgegenstand klar sind, also z. B. Netto-Zeitaufwand für eine Programm-Änderung, Bruttozeitaufwand für Änderung samt Test, Dokumentationsänderung und Benutzerinformation. Die Schätzklausur arbeitet so ähnlich, nur weniger formalisiert. Die Experten schätzen hier nicht getrennt voneinander, sondern im Kollektiv. Es werden die 3 Phasen Vorbereitung, Durchführung und Nachbereitung durchlaufen.

COCOMO

Die Grundidee der COCOMO-Methode „Constructive Cost Model“ besteht darin, alle kostenrelevanten Elemente zu erfassen, zu bewerten und hochzurechnen. Die Bewertung stützt sich dabei auf Erfahrungswerte, die aus einer Erfahrungsdatenbank gewonnen wurde, in die eine Vielzahl von Projekten eingetragen wurden. Diese Erfahrungsdatenbank basiert auf DSI und einer Systemumgebung aus der Lochkartenzeit. Die Formeln für den Basisaufwand sind daher heute nicht mehr brauchbar, das Grundkonzept mit passenden Bezugsgrößen sehr wohl.

Functional Sizing

Functional Size Measurement, oder als eine Ausprägung das Function-Point-Verfahren, sind selbst keine Aufwandsschätzverfahren, sondern dienen zur Bewertung des Umfangs fachlicher Anforderungen an ein Softwareprojekt. Wenn man annimmt, dass die Functional Size ein wesentlicher Aufwandstreiber für ein Softwareprojekt ist, kann daraus auf den Aufwand für das Projekt geschlossen werden. Eine einfache oder gar lineare Beziehung zwischen der Functional Size und dem Projektaufwand besteht jedoch nicht. Deshalb ist für eine Aufwandsschätzung auf jeden Fall noch ein Modell wie z. B. COCOMO notwendig, das die weiteren Aufwandstreiber beschreibt. Viele kommerzielle Aufwandsschätzmodelle verwenden die Functional Size ebenfalls als Input-Variable.

Beurteilung von Schätzverfahren

An Schätzverfahren werden neben Genauigkeit noch eine Reihe weiterer Anforderungen gestellt, die sich teilweise widersprechen:

  • Es soll möglichst früh einsetzbar sein. (Der Auftraggeber will am Anfang wissen, was es am Ende kostet.)
  • Änderungen in den Anforderungen sollen sich auf die Schätzung auswirken. (Mehr-/Minderkosten)
  • Die Ergebnisse sollen einfach nachvollziehbar sein.
  • Außer den Kosten soll auch ein grober Terminplan herauskommen, der den Übergang zur Projektplanung ermöglicht.
  • Das Schätzverfahren selbst soll möglichst wenig kosten.

Genauigkeit

Eine gute Aufwandsschätzung sollte auch immer mit Angaben zur Genauigkeit der Schätzung einhergehen. Solche Angaben können wieder aus der statistischen Betrachtung von früheren Schätzungen abgeleitet werden. Im Softwarebereich geht man bei einfachen Schätzansätzen von einer Genauigkeit von bis zu 10 aus. Das heißt, bei einem geschätzten Aufwand von einem Personenjahr liegt der wahrscheinliche Aufwand zwischen z. B. 36 Tagen und 10 Jahren. Durch Komponentenschätzung und Delphi-Methode kann dies oft auf einen Schätzfehler in der Größenordnung des Faktor 2 verbessert werden. Humphrey berichtet in seiner Probe-Methode in sehr günstigen Fällen sogar von einem Schätzfehler von nur 15 % in 75 % Prozent der Projekte. Dies gelingt aber nur, wenn eine große Anzahl von ähnlich gelagerten Vergleichsprojekten zur Verfügung steht und wenn sich bei dem neuen Projekt kein entscheidender Einflussfaktor geändert hat. Neues Personal, neue technische Anforderungen, neue Entwicklungswerkzeuge, neue Laufzeitumgebungen, neue Kunden oder ähnliche Risiken können leicht wieder zu einem Schätzfehler von mehreren Größenordnungen führen.

Es gibt dabei auch ein Paradoxon: Je mehr „Faktoren“ (nicht Summanden) berücksichtigt werden, umso plausibler ist das Ergebnis, weil Faktoren, die offensichtlich einen großen Einfluss haben berücksichtigt werden. Allerdings wird die Schätzgenauigkeit dabei verschlechtert, denn wenn z. B. 10 Faktoren um einen Faktor 1.05 zu optimistisch oder pessimistisch geschätzt werden, so macht das einen Faktor 1.6 aus. Softwareentwickler tendieren stark zu Optimismus. Verantwortliche auch wegen des „price-to-win“.

Kosten des Schätzverfahrens

Aufwand entsteht

  • für das Lesen und Verstehen der Anforderungen meist für mehrere Personen
  • für die Definition von Leistungen, Einschränkungen, Restriktionen
  • für die eigentliche Schätzung
  • für das Verkaufen der Schätzung, Nacharbeiten, Pflege von Schätz-Datenbanken

Schätzen ist oft ein iteratives Verfahren, indem Leistungen reduziert oder ergänzt werden, Annahmen korrigiert werden.

Die Kosten für eine gute Schätzung betragen nach manchen Angaben bis zu 3 % des Projektumfangs, die für ein gutes Angebot bis zu 5 % des Projektumfangs.

Damit wird die Schätzung oft schon selbst zum Problem: Bei 10 Anbietern und 5 % Aufwand je Anbieter machen schon die Angebotskosten 50 % des Projektumfangs aus. Aus Sicht des Anbieters muss er aber bei einem erfolgreich akquirierten Projekt die Angebotskosten für alle 9 anderen wieder mit herein holen. Er müsste dazu ziemlich teuer sein, was es unwahrscheinlich macht, dass er den Auftrag bekommt. Dies legt es nahe, eine eher grobe Schätzung mit hohem Aufschlag zu machen, um Schätzaufwand (und dadurch auch Schätzkosten) gering zu halten.

Siehe auch

Literatur

  • Siegfried Vollmann: Aufwandsschätzung im Software Engineering. IWT-Verlag, 1990, ISBN 3-88322-277-1.
  • Barry W. Boehm: Software Engineering Economics. Prentice Hall, 1981, ISBN 0-13-822122-7.
  • IBM Deutschland: Die Funktion Point Methode, Schätzmethode für IS-Anwendungs-Projekte. Formnr. E12–1618, 1985.
  • Oliver Hummel: Aufwandsschätzungen in der Software- und Systementwicklung - kompakt. Spektrum Akademischer Verlag, 2011, ISBN 978-3827427519.
  • Dietmar Hölscher: Aufwandsschätzung in digitalen Projekten. Schätzen ist nicht wissen. Verlag Altes Forsthaus, 2019, ISBN 978-1795231930.
  • Steve McConnell: Software Estimation: Demystifying the Black Art. Microsoft Press, 2006, ISBN 978-0-7356-0535-0.
  • Harry M. Sneed: Software-Projektkalkulation. Hanser, 2005.
  • Manfred Burghardt: Projektmanagement: Leitfaden für die Planung, Überwachung und Steuerung von Entwicklungsprojekten. 7. Auflage. Publicis Corporate Publishing, Erlangen 2006, ISBN 3-89578-274-2, S. 156 ff.
  • F. P. Brooks: Vom Mythos des Mann-Monats. Addison-Wesley, 1987. Übersetzung der Originalausgabe von 1975, ISBN 3-925118-09-8.