Aufwandsschätzung (Softwaretechnik)
aus Wikipedia, der freien Enzyklopädie
| Dieser Artikel oder Abschnitt bedarf einer Überarbeitung. Näheres ist auf der Diskussionsseite angegeben. Hilf bitte mit ihn zu verbessern und entferne anschließend diese Markierung. |
Aufwandschätzung oder -abschätzung ist in der Softwaretechnik Bestandteil der Planung eines Softwareprojekts. Dabei wird abgeschätzt, wie viel Personen und wie viel Zeit für die einzelnen Arbeitsschritte oder Programmteile notwendig sind. Dann kann ein Zeitplan erstellt werden. Zeitaufwand und Zeitpunkte der einzelnen Meilensteine sind häufig wichtige Vertrags- und Finanzierungsgrundlagen.
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. Gebräuchliche Größenmaße für Programme sind Lines of Code (LOC) und Function Points (FP).
Inhaltsverzeichnis |
[Bearbeiten] Größenmaße
LOC wird häufig kritisiert, da der Wert schon durch eine unterschiedliche Codeformatierung beeinflusst wird (bis zum Faktor 3). Ferner benötigen unterschiedliche Entwickler für die gleiche Funktionalität unterschiedlich viele Programmzeilen. Das LOC-Größenmaß stuft umständliche, unnötig lange Programme als aufwändiger ein als elegante kurze Lösungen. Schließlich beobachtet man in der Praxis dramatische Produktivitätsunterschiede der Entwickler. Sogenannte "Superprogrammierer" können 10- bis 100-fach mehr LOC pro Tag erzeugen als der Durchschnitt. Das Größenmaß FP versucht, die Komplexität des Codes zu erfassen, indem Kontrollstrukturen wie Schleifen und Verzweigungen, die Anzahl von Methodenparametern etc. gewichtet gezählt werden. Auch wenn dieses Größenmaß sinnvolle Grundideen enthält, treffen auf die Function Points im wesentlichen die gleichen Kritikpunkte zu wie auf das LOC-Größenmaß.
Trotz aller Kritik ist das LOC-Größenmaß am weitesten verbreitet, wahrscheinlich deshalb, weil es intuitiv und leicht zu messen ist. Nach Humphrey kann die Qualität eines Größenmaßes für die Aufwandsschätzung am besten dadurch überprüft werden, dass man bei einer Reihe von ähnlichen Projekten die ermittelten Größen mit dem tatsächlichen Zeitaufwand vergleicht.
[Bearbeiten] Zerlegung in Komponenten
Eine weitere Verbesserung der Aufwandsschätzung kann durch eine Zerlegung des Programms in mehrere Komponenten erreicht werden, wobei dann der Aufwand für jede Komponente einzeln geschätzt wird. 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, das systematische Schätzfehler, wie zum Beispiel ein generelles Unterschätzen von Aufwänden durch Komponenten-basiertes Schätzen, nicht behoben werden. 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. Hierbei ist zu beachten, dass Schätzer im Laufe der Zeit auch eine Lernkurve durchlaufen und solche systematischen Schätzfehler selbsttätig korrigieren.
[Bearbeiten] Delphi-Methode
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.
[Bearbeiten] 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 zwischen Pi und 10 aus. Das heißt, bei einem geschätzten Aufwand von einem Personenjahr liegt der wahrscheinliche Aufwand zwischen 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.
[Bearbeiten] Literatur
- Burghardt, Manfred: 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
[Bearbeiten] Weblinks
- Die Kalkulation des Software-Aufwandes setzt mehr voraus als eine gute Softwaremetrik! Fachartikel von Robert Hürten, Knowledge Department
- 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
