Faustregel, Software, Entwicklungsaufwand, Testaufwand

Faustregel zur Schätzung von Software-Entwicklungsaufwand

Wer (in der Rolle des Auftragnehmers) Software für einen Kunden zu entwickeln hat, sollte – nach meiner Erfahrung – folgende Faustregel zugrundelegen:

Raster für Entwicklungsaufwand

Auf Basis » reiner Entwicklungsaufwand = 1 « kommen hinzu:

0.1 für politsches Projektmanagement
0.2 für technisches Projektmanagement
0.1 für Qualitätsmanagement
0.1 für Anpassen von Entwicklungswerkzeug, Integration und Configuration Management
0.5 für Test
und wenigstens 0.1 für Dokumentation

Unter reinem Entwicklungsaufwand (= 1) verstehe ich dabei

Anforderungs- und Change Management (= 0.3)
Entwurf und Schnittstellenspezifikation (= 0.4)
Codierung (= 0.3)

Configuration Management für sich allein erfordert deutlich weniger als 1% des Entwicklungsaufwands.

Da man, wie oben gesagt, zum reinen Entwicklungsaufwand 0.5 für Test (durch die Software-Entwickler selbst) hinzurechnen sollte, gilt grob: Wer Software entwickelt (als Auftragnehmer), aber nicht ihr Nutzer sein wird, muss etwa 1/3 des Gesamtaufwandes für Test einkalkulieren, den er selbst durchzuführen hat.

Als Auftraggeber sollte man wissen, dass der Auftragnehmer diese Zahl kennt und bei seiner Schätzung zugrundelegt, dass er aber selten so viel Testaufwand dann auch wirklich spendiert: Allzu oft kommt es bei der Implementierung zu Zeitverzögerung, und allzu oft fällt Test seitens der Entwickler dann allzu dürftig aus. Gleiches gilt, wenn eines vereinbarten Festpreises wegen das Budget knapp wird.

Es gibt zudem Fehler, von denen man nicht erwarten kann, dass der Auftragnehmer sie zu entdecken in der Lage ist.

Und so gilt auf jeden Fall: Aus Sicht des Auftraggebers kommt Test hinzu, für den er (als Auftraggeber und Nutzer des Systems) sich selbst verantwortlich fühlen und mit einbringen muss: Sog. Acceptance Test, der dann stets reiner Black Box Test ist. Hier konnte ich beobachten: Es gibt Kunden, die kaum solchen Test machen, und andere Kunden, die eigene (oft große) Test-Teams damit beschäftigen. Diese Kunden — vor allem Banken, Versicherungen, Großkonzerne — wissen, dass es nicht beim Test der ersten Version des Systems bleiben wird und dass es daher gilt, eine regressionsfähige Testsuite aufzubauen, die

alle wesentlichen Funktionen der Anwendung zum Gegenstand haben muss
und die immer dann, wenn modifizierter Code in Betrieb genommen werden soll, auch komplett neu abzuarbeiten ist.

Diese Testsuite so anzulegen, dass sie das System sein ganzes Leben lang begleiten kann, ist eine schwierige, kostspielige Aufgabe. Die Testtreiber und Testauswertungsfunktionen zu pflegen, d.h auf jeweils neue Releases der Anwendung anzupassen und vor Inbetriebnahme jedes neuen Releases oder jeder Bug-Fix-Auslieferung den kompletten Acceptance-Test neu durchzuführen, kann sehr aufwendig sein. Solchen Aufwand über eine Faustregel zu quantifizieren ist unmöglich – ihn gezielt klein zu halten gelingt nur dann, wenn die Software-Architekten die Anwendung ganz gezielt so entworfen haben, dass sie einfach testbar wird.

Einfache Testbarkeit als notwendiges Kriterium mit in Auftrag zu geben und einzufordern vergessen aber fast alle Auftraggeber – und genau diese Lücke ist dann der entscheidende Kostentreiber, der wie ein trojanisches Pferd zum Auftraggeber und Nutzer der Software kommt.

Hinreichend gut getestete Software erreicht man am ehesten (und am kostengünstigsten) dann, wenn man schon vom System-Architekten verlangt, dem System Eigenschaften zu geben, die garantieren,

dass es gut testbar wird (als Black Box)
und solcher Test gut automatisiert werden kann.

Software über längere Zeit gut wartbar zu halten gelingt am ehesten dann, wenn schrittweise eine regressionsfähige Testsuite (für Black Box Test) aufgebaut wird.

Als Faustregel gilt auch:

Etwa 2/3 aller Kosten, die eine Software-Anwendung verursacht, fallen an,

NACHDEM sie zum ersten Mal produktiv gesetzt wurde.

Siehe auch, was gezielt durchgeführte Untersuchungen sagen.

Einer Tabelle dort (und auch einer von Microsoft selbst) entnimmt man u.A., dass Bill Gates (in 2006) etwa 50% des gesamten Entwicklungsaufwandes als Testaufwand sah. Hier allerdings ist zu berücksichtigen, dass Microsoft Produkte entwickelt, der Testaufwand aus Sicht von Gates also dem entspricht, den das Entwicklungsteam UND sein Kunde zu erbringen haben.

Wichtig ist:

Den Aufwand für die Entwicklung von Software einigermaßen zutreffend abzuschätzen, sind mindestens drei Personen notwendig, die u n a b h ä n g i g voneinander eine Schätzung erarbeiten.

Man sollte den Schätzern eine grobes Aufgabenraster vorgeben. Nur dann nämlich wird klar erkennbar sein, bezüglich welcher Teilaufgaben sie zu gravierend unterschiedlicher Meinung kamen. Die Meinungen der Schätzer wird man dann

durch ihren Durchschnitt ersetzen — wo sie sich nur wenig voneinander unterscheiden —,
ansonsten aber gemeinsam diskutieren.

Die Zahl der Schätzer kleiner als 3 zu wählen, muss — mindestens bei größeren Projekten — als wenig professionell — und als allzu fahrlässig — eingestuft werden.

stw6728EFS — Entwicklungsaufwand . Faustregel . Schätzung — News?

Mehr + B G E + S H A + More

Session's Law of Size

2017: Erfolgsrate

2017: Management Aspekte

2017: Verwendete Vorgehensmodelle

Faustregel für den Entwicklusaufwand einer Smartphone App

Erfahrungen zu Software-Fehler-Dichte

Brauchbare Code Reviews und was sie (per 100 LOC) kosten

Wissenswertes zu
Testaufwand, Entwicklungsaufwand, Software, Faustregel