Aufwandsschätzung (Softwaretechnik)

Aufwandsschätzung oder -abschätzung oder Kostenschätzung ist in der Softwaretechnik 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 es letztlich kostet. Kosten, Termine und benötigte Ressourcen sind dann Grundlage für ein Angebot oder für eine Entscheidung, ob und wie und wann ein Softwareprojekt oder Arbeitspaket davon 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 Computer,
• Rechenzeiten und Netzwerkkosten,
• Lizenzen für Betriebssysteme und Tools,
• Testhardware,
• Kurse,
• Reisekosten.

Diese hängen oft von den Personalkosten ab, denn je länger ein Projekt dauert, je mehr Leute damit beschäftigt sind, desto mehr Sachkosten fallen auch an.

Für die zu erwartenden Gesamtkosten sind darauf noch erhebliche kaufmännische Aufschläge erforderlich, 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)

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 bestehende System wird meistens die Schätzklausur oder Delphi-Methode benutzt, weil hier das Augenmaß der Beteiligten die besten 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. Diese können dann 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 werden 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), 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. Kommentare, die erheblich zu Qualität beitragen, zählen 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 Vorbereitung und Nacharbeiten aller Beteiligter 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 nahe liegend, 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 komponenten-basiertes 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

Parkinson sagt: „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“

Aus diversen Quellen weiß man, was der Kunde bereit ist zu zahlen, oder was ein Konkurrent anbietet; meist weit weniger als eine solide Arbeit kosten würde. Die Schätzung wird solange frisiert, bis sie zur Erwartung passt. Boehm schreibt weiter 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 Modell“ 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.

Function Point

Das Function-Point-Verfahren wurde von Allen J. Albrecht bei IBM entwickelt als Fortentwicklung des früheren Verfahrens. Es ist gedacht für kommerzielle Programme, die Eingabedaten bearbeiten unter Benutzung von Stammdaten und Referenzdaten und Ausgabedaten erstellen. Function Points gibt es für Datenstrukturen (je nach Komplexität), für Programme (je nach Schwierigkeit) für Referenzdaten. Ferner gibt es Korrekturfaktoren (Einflussfaktoren), sowie einen von der Projektgröße abhängigen Umrechnungsfaktor von FP in PM (Personenmonate). Die Function Point Methode basiert auf den funktionalen Anforderungen und ist im Prinzip unabhängig von der verwendeten Programmiersprache.

Es gibt eine internationale Benutzergruppe: http://www.ifpug.org Es gibt Bestrebungen, Function Point als ISO-Standard zu etablieren.

Beurteilung von Schätzverfahren

An Schätzverfahren werden neben Genauigkeit noch eine Reihe weiterer z. T. sich widersprechende Anforderungen gestellt:

• 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. 70 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

Aufwände entstehen

• 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.

Literatur

• 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. 156ff.
• 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.
• F. P. Brooks: Vom Mythos des Mann-Monats. Addison-Wesley 1987, Übersetzung der Originalausgabe von 1975, ISBN 3-925118-09-8.
• Harry M. Sneed: Software-Projektkalkulation. Hanser, 2005.
• Steve McConnell: Software Estimation: Demystifying the Black Art. Microsoft Press, 2006, ISBN 978-0-7356-0535-0.
• Oliver Hummel: Aufwandsschätzungen in der Software- und Systementwicklung - kompakt. Spektrum Akademischer Verlag, 2011, ISBN 978-3827427519.

Weblinks

• Methodische Aufwandsschätzung aus Sicht eines agilen Projektmanagements Hans-Jürgen Plewan, White Paper; publiziert in B. Oestereich (Hrsg.), Agiles Projektmanagement, dpunkt verlag 2006 S. 83–100

Siehe auch

• Softwaremetrik
• Testaufwand