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