Post on 16-Aug-2019
Aufwandsschätzung von Softwareprojekten
Florian Pilzfpilz87@gmail.com
- Florian Pilz- Methoden zur Aufwandsschätzung von Softwareprojekten und deren Zuverlässigkeit
Übersicht1. Motivation
2. Planning Poker
3. Zuverlässigkeit
4.Evidence Based Scheduling
5. Fazit
- kurzen Überblick- wozu Schätzmethoden nötig- Planning Poker und EBS Schätzmethoden- Zuverlässigkeit: was, Limit, Verbesserung- wichtigste Punkte nennen & zusammenfassendes Beispiel
Motivation
Motivation
• Schneesturm-Simulator
• Winter 2012
• realisierbar?
commons.wikimedia.org (gemeinfrei)
- Firma Schneeflocke- möchte Simulator zur Gefahrenvorhersage entwickeln (Lawine, Glatteis, ...)- muss rechtzeitig fertig sein (sonst Ruin wegen fehlenden Umsatz)- ermitteln ob realistisch durch Schätzmethoden
Realisierbarkeit
• ermitteln durch Schätzmethoden
• mögliche Maßnahmen:
‣ Umfang verringern
‣ mehr Entwickler
‣ Sandsturm-Simulator kaufen
- gibt Methoden zur Aufwandsschätzung- Aufwand = Kosten, Personal, Entwicklungsdauer- im Vortrag: Aufwand = Zeit- Maßnahmen, falls so nicht realisierbar- Funktionsumfang (Scope): nur Schneelawinen, nur Gebirgsstraßen
Planning Poker
Logan Ingalls „11g poker chips“, CC BY 2.0
Planning Poker
• für agile Teams
• schnelles, grobes Abschätzen
• jeder ist beteiligt
• verhindert Beeinflussung
Jason Jacobs „Poker Chips“,CC BY-NC 2.0 (beschnitten)
(Grenning, 2002)
- agil = feingranulare Aufgaben (User Stories) => kleine Aufgaben nicht ganzes Projekt- Ziele sind ...- damit Kunde / Visionär entscheiden kann, was er will („Oh, so teuer? Dann lieber B statt A.“)- im Gegensatz zur Gruppendiskussion nicht nur der lauteste & „einflussreichste“
Planning Poker
commons.wikimedia.org (gemeinfrei)
- jeder Entwickler hält folgende Karten- Zahl bedeutet Aufwand in Stunden- As = „splitten“ oder mehr Info => back to customer
Planning Poker
commons.wikimedia.org (gemeinfrei)
- Schätzmethode läuft wie folgt ab- User Story in Tischmitte, kurze Erklärung, Verständnisfragen- User Story = textuelle Beschreibung eines Features- jeder Entwickler wählt individuell Karte- alle decken gleichzeitig auf (jeder, unabhängig)
Planning Poker
commons.wikimedia.org (gemeinfrei)
- hier: 1, 3, 3, 7- d.h. uneinig- Uneinigkeit = unterschiedliche Annahmen, z.B. textuelle oder graphische Darstellung- niedrigste (1) und höchste (7) Schätzung erklären- neu schätzen
Planning Poker
commons.wikimedia.org (gemeinfrei)
- ähnliche Schätzung => Einigung auf 5h- sonst Schätzung verschieben und Aufgabe weiter aufspalten oder mehr Informationen einholen- Schneeflocke wendet Planning Poker für Schneesturm-Simulator an- Ergebnis: mit 4 Entwicklern in 9 Monaten- würde reichen, aber muss angezweifelt werden- Zuverlässigkeit überleiten
Zuverlässigkeit
Definition
• Wahrscheinlichkeit, dass Schätzungen „nahe“ des tatsächlichen Aufwandes
• empirisch ermittelt
• für jede Schätzmethode einzeln
- Schätzungen sind nie exakt- Beispiel: Planning Poker in Stunden => Release Mo 10:25- genauer Termin unwichtig, 1 Tag Verzögerung nicht so schlimm, 1-2 Monate schon- nachfolgend steht Zuverlässigkeit daher für ...- maximale Abweichung erlauben => „nah“- empirisch: Schneeflocke hat bereits 10x mit diesem Team & Planning Poker geschätzt- üblicherweise je Schätzmethode ermittelt, aber auch andere Kriterien möglich (Team, Domäne)- nachfolgend Limitierungen & Verbesserungen
LimitierungenA
ufw
and
Anforderungsanalyse
Implementation
Entwurf
Integrationstests
Systemtests
Auslieferung
Zeit, Informationen
tatsächlicher Aufwand
vgl. (Boehm, 1984)
- verfügbare Informationen- Kegel der Unsicherheit- am Beispiel vom Wasserfall-Modell
LimitierungenZ
uver
läss
igkei
t
Objektorientierung
interaktive Verarbeitung
erste höhere Programmiersprache
Zeit, technische Innovationen
vgl. (Boehm & Sullivan, 2000)
- technische Innovationen- ablösen von Assembler durch Programmiersprache usw.- am Beispiel von Planning Poker: Entwickler haben noch keine Erfahrungen mit neuer Technologie- lernen mit der Zeit dazu => Zuverlässigkeit wird besser- anschließend Verbesserungsmöglichkeiten
Verbesserungsmöglichkeiten
• Projekt mehrmals abschätzen
‣ wegen verfügbaren Informationen
Aufw
and
Anforderungsanalyse
Implementation
Entwurf
Integrationstests
Systemtests
Auslieferung
Zeit, Informationen
tatsächlicher Aufwand
- bei Gewinn wichtiger Informationen neu schätzen- z.B. nach fertigem Entwurf, sobald Kunde Änderungswünsche einreicht usw.- Firma Schneeflocke kann so frühzeitig die Schätzung überprüfen => neue Schätzung mit tieferem Verständnis => bisheriger Fortschritt und Schätzungen der Features gegenüberstellen
Verbesserungsmöglichkeiten
• Datensammlung verwenden
‣Feedback
‣weitere Schätzmethoden
- Datensammlung = abgeschlossene Projekte / Aufgaben mit Aufwand, Schätzung, Probleme, Komplexität, ...- Qualität der Schätzmethode mit Datensammlung erhöhen- Feedback: Entwickler lernen nur bei Gegenüberstellung von Schätzung und tat. Aufwand => hilft Firma nicht sofort für das aktuelle Projekt, aber auf lange Sicht- weitere Methoden: wird im nächsten Kapitel eine vorgestellt
Verbesserungsmöglichkeiten
• Verwenden mehrerer Schätzungsmethoden
Planning Poker
COCOMO
Analogie
Delphi-MethodeExpertensystem
9 Monate
13 Monate
15 Monate
24 Monate
16 Monate
15.4 Monate
(Jørgensen, 2007)
- mehrere Schätzmethoden = mehrere Schätzungen für dasselbe Projekt- z.B. (informelle) Analogie: ein Entwickler hat schonmal Simulator entwickelt, schätzt aus Erfahrung ab (Ähnlichkeit)- Aussage (hier am Mittelwert): Schätzungen gehen weit auseinander => keine hohe Zuverlässigkeit, wahrscheinlich zu lang => genannte Maßnahmen + neu schätzen- am besten geeignete Kombination verschiedener Methoden => ergänzen sich => günstig mehrere Schätzungen
Evidence Based Scheduling
Voraussetzungen
• Projekt in kleine Aufgaben zerlegen
• Aufgaben unter Entwicklern verteilen
• jeder schätzt individuell
• rein intuitiv, kein formaler Prozess
(Spolsky, 2008)
- EBS wurde von Joel Spolsky erfunden und ist ein algorithmisches Modell- d.h. läuft automatisch nach festem Algorithmus ab => setzt voraus, dass ...
- jeder Entwickler verantwortlich für bestimmte Aufgaben- hier: Projekteigenschaften = Schätzung + zuständiger Entwickler- Schätzungen speichern => Datensammlung- Bauchgefühl
Geschwindigkeit
• nach Fertigstellung einer Aufgabe
• Geschwindigkeit = geschätzt / tatsächlich
Jane Doe A B C D E Fgeschätzte Dauer 2 4 4 16 2 3tatsächliche Dauer 4 8 2 32 1 6Geschwindigkeit 0.5 0.5 2 0.5 2 0.5
- nach Fertigstellung die tatsächliche Zeit notieren => Datensammlung- Datensammlung enthält nun Schätzung + tatsächlichen Aufwand- Geschwindigkeit pro abgeschlossene Aufgabe bestimmen- geschätzte Dauer / tatsächliche Dauer- Beispiel ... Aufgaben A, B, C, D, E, F- mit Schätzung & abgeschlossen, verschiedenen Geschwindigkeiten- 1/3 => 2 und 2/3 => 0.5
Zukunft vorhersagen
• offene Aufgabe wählen
• durch zufällige Geschwindigkeit teilen
• für jede Aufgabe & Entwickler wiederholen
• 100 solcher Zukünfte berechnen
- EBS wird versuchen die Zukunft vorherzusagen- Monte Carlo Simulation (Zufallsexperimente)- Geschwindigkeit desselben Entwicklers wählen, z.B. Jane <-> Jane- Bsp: Aufgabe 10h geschätzt, Geschwindigkeit 2 wegen doppelt so schnell fertig => 5h- aufsummieren der Zeiten- Urlaub, Arbeitszeiten & Abhängigkeiten beachten- ersten 3 Punkte ergeben eine mögliche Zukunft- 100 Zukünfte = jede Zukunft hat 1% Wahrscheinlichkeit
ungewisse Zukunft
mit freundlicher Genehmigung von Fog Creek Software
- 100 Zukünfte sortiert, d.h. kürzeste ist 1%, zweitkürzeste 2%, ..., längste 100%- weil 2% auch 1% einschließt (Abschätzung nach oben)- lange Lücken = Wochenende- kurze Lücken = Feierabend- ungewiss, da lang gestreckt- (hier: keine 100 Zukünfte)
gewisse Zukunft
mit freundlicher Genehmigung von Fog Creek Software
- gewiss, da ziemlich sicher an einem Tag- wegen Wochenende Verschiebung möglich- noch schlimmer wenn Urlaub ab nächster Woche
Entwicklung der Zukunft
01.12.11 01.01.12 01.02.12 01.03.12 01.04.12 01.05.12
31.05.12
01.07.12
01.08.12
01.09.12
02.10.12
02.11.12
03.12.12
03.01.13
95%
50%
5%
Zeitpunkt der Berechnung
Ze
itp
un
kt
de
r F
ert
igste
llung
vgl. (Spolsky, 2008)
- EBS algorithmisch => automatisch => Zukunft täglich neu berechnen- Linien des 5%, 50% und 95%igen Enddatums über die Zeit der Berechnung- je näher zusammen, desto gewisser die Zukunft (wenig Varianz)- sollten über Zeit daher konvergieren- bei Anstieg aller Linien = Projekt verzögert sich (mehr Aufgaben oder Verschlechterung der Schätzung)
Vorteile
• Geschwindigkeit einbeziehen
• Risiken frühzeitig erkennen
• hohe Zuverlässigkeit durch:
‣ automatische Aktualisierung
‣ Feedback durch Datensammlung
‣ Kombination von Schätzmethoden
- Geschwindigkeit: Jane Doe braucht immer doppelt so lang wie geschätzt * wenn man es nicht weiß => sehr unzuverlässig * Geschwindigkeit mit einbeziehen => sehr zuverlässig- Risiken = stetig steigende Feature-Anzahl, fehlende Konversion der Zukunfts-Linien, zu später Release- Graph wird täglich aktualisiert (neue Features, niedrige Geschwindigkeit etc. wird einbezogen)- Feedback verbessert Schätzfähigkeiten der Entwickler- weitere Schätzung mit wenig Aufwand
Vorteile
01.12.11 01.01.12 01.02.12 01.03.12 01.04.12 01.05.12
31.05.12
01.07.12
01.08.12
01.09.12
02.10.12
02.11.12
03.12.12
03.01.13
95%
50%
5%
Zeitpunkt der Berechnung
Ze
itp
un
kt
de
r F
ert
igste
llung
Nika Trie B & Poppy Yunita„The Programmer“, some rights reserved
* Firme zerlegt Projekt in Aufgaben* Aufgaben Entwickler zuordnen und schätzen intuitiv* Entwickler erledigen Aufgaben => Datensammlung => Feedback => ermöglicht EBS* EBS berechnet weitere Schätzung (automatisch)* neue Aufgaben werden verteilt und geschätzt, alte wenn nötig neu geschätzt => EBS berechnet täglich neu => Entwicklung der Zukunft warnt vor Scope Creep===> Firme Schneeflocke kann von Terminproblemen frühzeitig erkennen (und dagegen handeln)
Fazit
Fazit
• für Projektmanagement
• limitiert durch Information & Innovation
• hohe Zuverlässigkeit durch
‣ mehrmalige Schätzungen
‣ Datensammlung (Feedback, neue Methoden)
‣ Nutzung mehrerer Schätzmethoden
- Aufwandsschätzung von Softwareprojekten für ...- Projektmanagement: Funktionsumfang, Personal, Aufwand & Ertrag, Preisverhandlungen, ...- Limitierung: Wissen über Endprodukt je nach Fortschritt, Auswirkung von Innovation auf Produktivität noch unbekannt- Zuverlässigkeit erhöhen durch * mehrmaliges schätzen um Schätzung verfügbaren Infos anzupassen * Datensammlung (Feedback = Entwickler lernen, Faktoren math. Modelle anpassen; neue Methoden wie EBS) * mehrere Schätzmethoden / Kombination, bestmöglich mit verschiedenen Ansätzen und geringe Kombinationskosten
Vielen Dank für Ihre Aufmerksamkeit!
Quellenangaben• Logan Ingalls „11g poker chips“, CC BY 2.0
http://www.flickr.com/photos/plutor/1818402449/
• Jason Jacobs „Poker Chips“, CC BY-NC 2.0 (beschnitten)http://www.flickr.com/photos/hisc1ay/116988432/
• Nika Trie B & Poppy Yunita „The Programmer“, some rights reserved,http://www.petshopboxstudio.com/blog/2010/07/free-vector-character-the-programmer/
• James W. Grenning „Planning Poker or How to avoid analysis paralysis while release planning“, 2002, http://www.renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf
• Barry W. Boehm „Software Engineering Economics“, IEEE Transaction on Software Engineering, 10(1):4–21, 1984
Quellenangaben• Barry W. Boehm und Kevin J. Sullivan „Software economics: a roadmap“. In Anthony
Finkelstein, Hrsg., The Future of Software Engineering 2000: 22nd International Conference on Software Engineering, Seiten 319–343, New York, USA, 2000
• Magne Jørgensen „Forecasting of Software Development Work Effort: Evidence on Expert Judgement and Formal Models“, International Journal of Forecasting,23(3):449–462, 2007
• Joel Spolsky „More Joel on Software: Further Thoughts on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity“, Apress, Berkeley, USA, 1. Auflage, 2008