Folien

Aufwandsschätzung von
Softwareprojekten
Florian Pilz
[email protected]
- Florian Pilz
- Methoden zur Aufwandsschätzung von Softwareprojekten und deren Zuverlässigkeit
Übersicht
1. 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
Logan Ingalls „11g poker chips“, CC BY 2.0
Planning Poker
Planning Poker
(Grenning, 2002)
• für agile Teams
• schnelles, grobes Abschätzen
• jeder ist beteiligt
• verhindert Beeinflussung
Jason Jacobs „Poker Chips“,
CC BY-NC 2.0 (beschnitten)
-
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
Limitierungen
vgl. (Boehm, 1984)
Integrationstests
Systemtests
Aufwand
Auslieferung
tatsächlicher Aufwand
Implementation
Entwurf
Anforderungsanalyse
Zeit, Informationen
- verfügbare Informationen
- Kegel der Unsicherheit
- am Beispiel vom Wasserfall-Modell
Limitierungen
Zuverlässigkeit
vgl. (Boehm & Sullivan, 2000)
interaktive Verarbeitung
erste höhere Programmiersprache
Objektorientierung
Zeit, technische Innovationen
- 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
Integrationstests
Systemtests
Aufwand
Auslieferung
tatsächlicher Aufwand
Implementation
Entwurf
Anforderungsanalyse
Zeit, Informationen
- 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
(Jørgensen, 2007)
• Verwenden mehrerer Schätzungsmethoden
Planning Poker
9 Monate
COCOMO
24 Monate
15.4 Monate
Analogie
13 Monate
Delphi-Methode
16 Monate
Expertensystem
15 Monate
- 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
(Spolsky, 2008)
• Projekt in kleine Aufgaben zerlegen
• Aufgaben unter Entwicklern verteilen
• jeder schätzt individuell
• rein intuitiv, kein formaler Prozess
- 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
F
2
4
4 16
2
3
tatsächliche Dauer 4
8
2
1
6
geschätzte Dauer
Geschwindigkeit
-
32
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
Zeitpunkt der Fertigstellung
Entwicklung der Zukunft
03.01.13
03.12.12
02.11.12
02.10.12
95%
50%
5%
01.09.12
01.08.12
01.07.12
31.05.12
01.12.11 01.01.12 01.02.12 01.03.12 01.04.12 01.05.12
Zeitpunkt der Berechnung
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
Nika Trie B & Poppy Yunita
„The Programmer“, some rights reserved
Zeitpunkt der Fertigstellung
Vorteile
03.01.13
03.12.12
02.11.12
02.10.12
95%
50%
5%
01.09.12
01.08.12
01.07.12
31.05.12
01.12.11 01.01.12 01.02.12 01.03.12 01.04.12 01.05.12
Zeitpunkt der Berechnung
* 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
•
Jason Jacobs „Poker Chips“, CC BY-NC 2.0 (beschnitten)
http://www.flickr.com/photos/plutor/1818402449/
http://www.flickr.com/photos/hisc1ay/116988432/
•
Nika Trie B & Poppy Yunita „The Programmer“, some rights reserved,
•
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
http://www.petshopboxstudio.com/blog/2010/07/free-vector-character-the-programmer/
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