Systematische Softwareentwicklung


	> SSE > Anforderungsanalyse > Abschätzung

"Die sich des Vergangenen nicht erinnern, sind dazu verurteilt, es noch einmal zu erleben."
(Santayana)

Abschätzung

Entwickler anwendungsfallbezogen schätzen lassen (Verantwortung delegieren).

- Metrik mit Kennzahlen für Prozesse als Faktoren
- Jedes Projekt als Basis für spätere monitoren, um Metrik zu erhalten
- LOC (lines of code) oder Speicherbedarf bei Low-Level- und Embedded-Software
- Unbekannte Fachlichkeiten durch Vergleiche der Charakteristika abschätzen
- Expertenmeinungen zum Vergleich einholen (Kollegen fragen, mehrere Schätzungen)
- Nicht abschätzbares zerlegen, bis es abschätzbar ist
- Black-Box-Abschätzung: Wie schätze ich ab, was ich nicht kenne (bzw. nicht kennen darf)? Vergleichsabschätzung mit White-Boxes
- 20% buffer time IS minimum!
- Organisatorische Aufwände wie Reisekosten oder Testläufe (z.B. bei automotive embedded systems) oder Weiterbildung für Tools berücksichtigen
- Pakete als Ganzes schätzen und nach Erfahrungsmetrik prozentual runterrechnen; als Stichprobe dann ein Paket bottom-up gegenrechnen

Abschätzung für Entwicklung einerseits und Quako, Doku, Handbuch andererseits
Kennzahlen als Faktoren
Parallelisierbarkeit der Entwicklung schätzen

Schließlich wurde es
als "Nicht machbar"
eingestuft, was der
Kunde gar nicht
verstand.

Mit die beste Methode zur Abschätzung ist die Vergleichsabschätzung mit etwas Ähnlichem, dass man schon mal realisiert hat. Voraussetzungen dafür sind natürlich einerseits, dass man schon mal etwas Ähnliches realisiert hat, und andererseits, dass man dokumentiert hat, wie aufwändig es damals war: Wer gemessen hat, hat auch eine Metrik zum Schätzen! Diese Methode ist insbesondere beim XP (Extreme Programming) sehr beliebt, weil dort möglichst wenig Aufwand getrieben werden soll und möglichst schnell Ergebnisse produziert werden sollen [B34]. Unter Meteorologen gibt es die Weisheit, dass die Verwendung des Wetters von gestern für eine Vorhersage des Wetters von morgen eine Trefferquote von 70% hat! Dies ist oft mehr, als die komplexeste satellitengestützte Software auf einem fetten Blech (engl.: big iron, damit sind die Großrechner gemeint) zustande bringt! Aber es ist nun mal so: wenn ich in einem J2EE-Projekt für die letzten 14 Reports auf einer Server Reporting Engine jeweils drei bis fünf Tage gebraucht habe, dann muss ich eine Schätzung von zehn Tagen für den nächsten Report einfach gründlich hinterfragen.

ROI = Return On Investment

TCO = Total Cost of Ownership

		Machbarkeiten prüfen

		technisch machbar?
		zeitlich machbar?
		personell machbar?
		organisatorisch machbar?
		finanziell machbar?

Prüfen Sie die Machbarkeiten des Projekts am Ende der Analyse erneut, denn sie sind jetzt deutlich präziser abschätzbar als nach der Pre-Analyse.

- technisch
- finanziell (Lizenzen für Tools, muss in der Regel der Kunde entscheiden)
- personell (Parallelisierbarkeit, Qualifikationen, Job-Rotation, Reservebank, Übersetzer, Autoren)
- zeitlich (Dauer und Termine)
- organisatorisch (Räumlichkeiten, Synchronisation Teilteams, Schutz von Wissen)

Geschätzte Iterationen beobachten und Konsequenzen für das Projekt ziehen (Verfolgung, Monitoring)