vorlesung software-engineering ihoyer/3.semester_2017/vorlesung/swe1... · (d t llt d h h t hi dli...
TRANSCRIPT
Vorlesung Software-Engineering I
… im 3. und 4. Semester
04. Analyse - Schätzverfahren
Aufgabe Aufwandx Personen
braucheny Tage.
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH
Metriken - Schätzverfahren
Frage: Wie lange braucht Ihr und was kostet das?
Aufgabe: Wir müssen die Komplexität des Produkts schätzen!
Vorgehensweise:
Rückgriff auf Erfahrungswerte -> Dokumentation abgeschlossener ProjekteRückgriff auf Erfahrungswerte > Dokumentation abgeschlossener Projekte
Schätzung als kontinuierliche iterative Vorgehensweise -> schrittweise Annäherung
Produkt in konkrete, handliche Teile zerlegen -> überschaubar = schätzbar
Toleranzspielraum festlegen -> wie genau müssen wir schätzen (+/- X%) ? Toleranzspielraum festlegen -> wie genau müssen wir schätzen (+/- X%) ?
Die Entwickler in der Schätzprozess mit einbinden -> wer sollte es sonst wissen?
Grundlage aller Verfahren:
Optimum finden zwischenSystemumfang/Zeitvorgaben und Aufwand/Produktivität/Dauer.
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH
Putnam: „Projekte lassen sich nicht beliebig verkürzen!“ Irgendwo dazwischen
Parkinson: „Das Projektteam füllt die geplante Zeit immer aus!“ liegt die Wahrheit!
2
Lines of Code (LOC)
Viele Klassische Schätzverfahren basieren auf programmierten Codezeilen (LOC).
„Lines of Code“ beschreibt dabei den Umfang des Software-Produkts.
Oft wird auch zwischen generierten/handgeschriebene CodeZeilen und Kommentaren unterschieden.
=> Die LOC-Methoden sind aufgrund neuer Programmiersprachen, Frameworks und
automatischer Codegenerierung faktisch direkt nicht mehr anwendbar!
Annahmen:
Ein Programmierer schafft ca 10 – 12 Zeilen Code pro Stunde
Beispiele:
Ein Programmierer schafft ca. 10 – 12 Zeilen Code pro Stunde
Ein Programmierer schafft ca. 16 – 19 Tausend Zeilen Code pro Jahr
Faustformel:Faustformel:
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH 3
http://en.wikipedia.org/wiki/Putnam_model
Analogie oder Makroschätzung
Ansatz: Das Produkt als Ganzes im Verhältnis zu anderen beurteilen.
„Wetter von Gestern“-Methode:
Den Aufwand auf Basis der zuletzt geleisteten Arbeit schätzen(geeignet für Zeiträume von 1-4 Wochen)
Grundlage: „Das Wetter wird Morgen so sein wie heute“Di B h t h t i W h h i li hk it 70%Diese Behauptung hat eine Wahrscheinlichkeit von 70%da sich das Wetter statistisch nur alle drei Tage ändert.
Sehr genau, wenn die Projekte/Aufgaben sehr ähnlichen Umfang/Zielsetzung haben.
=> Die Genauigkeit von 70% müssen andere Methoden erst mal leisten!
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH 4
Delphi-Methode
Ansatz: Top-Down-Expertenschätzung
Geeignet für eine grobe Kalkulation vor oder während der Startphase
Zerlegung des Produkts in einzelne Aufgaben.
Aufwandsschätzung der einzelner Aufgaben nach bestimmten Regeln durch Experten.
Anschließende anonyme Diskussion über die Schätzungen.
Weitere Schätzrunden und dadurch Annäherung der Ergebnisse.
Es gibt auch eine völlig anonyme Variante,
bei der die Experten nur mit dem Moderator
kommunizieren und Kommentare über abweichende
Meinungen schriftlich bekommen.
Di ll di B i fl i h d E
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH
Dies soll die Beeinflussung zwischen den Experten
minimieren um eine objektive Bewertung zu bekommen.
5
Dreipunkt-Schätzung
Ansatz: Die Entwickler schätzen immer zu pessimistisch um sich selbst einen Puffer zu schaffen,
Dies soll durch den Dreipunkt-Ansatz ausgeglichen werden.
Produkt in einzelne Arbeitspakete unterteilen
Zu jedem Arbeitspaket drei Schätzwerte angeben:optimistisch (wenn alles gut läuft)pessimistisch (wenn alles schlecht läuft)realistisch (was ich als realistisch schätze)realistisch (was ich als realistisch schätze)
3Punkt Schätzwert = (optimistisch + 4*realistisch + pessimistisch) / 6 3Punkt-Schätzwert = (optimistisch + 4*realistisch + pessimistisch) / 6
(der berechnete Wert ist etwas schlechter als der realistisch geschätze Wert)
StandardAbweichung = (pessimistisch – optimistisch) / 6
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH
StandardAbweichung = (pessimistisch – optimistisch) / 6
GesamtUnsicherheit = Wurzel(Summe(aller StandardAbweihungen))
6
Schätzkurve
Ansatz: Unterschiedliche Ansichten der Teammitglieder zusammenführen.(D T llt d h h t hi dli h t t i )(Das Team sollte dazu auch sehr unterschiedlich zusammengesetzt sein.)
Zerlegung des Produkts in einzelne Aufgaben.
Zeitliche Intervalle (1Tag, 2Tage, 3Tage …) festlegen.( g, g , g ) g
Eintrittswahrscheinlichkeit (%) für jedes Intervall und Aufgabe pro Teammitglied schätzen lassen.
Alle Schätzwerte auf Schätzkurven auftragen und den Mittelwert bilden.
=> je nach Anzahl der Intervallwerte ein sehr aufwändiges Verfahren.
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH 7
Use Case Points
Ansatz: Anwendungsfälle in ihrer Komplexität schätzen.(Z B t d f i h Ei d t b öti t )(Zur genauen Bewertung werden umfangreiche Eingangsdaten benötigt.)
Zur Berücksichtigen sind:
Technische Komplexitätp
Beteiligte Akteure
Umgebungsbedingungen
Die Anwendungsfälle werden in Klassen unterschiedlicher Gewichtung eingeteilt:
Gewicht Anzahl Ergebnis
Einfach (gering) x 5 7 35
Durchschnittlich (mittel) x10 13 130
Komplex (hoch) x15 3 45
Summe: 210 User Case Points
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH
Die Umrechnung von UseCasePoint in PersonenTage erfolgt je nach Produktivität des Teams.
(Erfahrungswert ist 2-5 Tage pro UserCasePunkt – siehe Beispiel)
8
Use Case Points – Beispiele 1/2:
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH 9
Use Case Points – Beispiele 2/2:
PF (Productivity Factor) ermitteln:Der Produktivitätsfaktor ird in Stunden pro User Case Point angegebenund spiegelt die unternehmensindividuelle Produktivität wieder.Der Wert muss daher aufgrund von eigenen Erfahrungen kalibriert werden.Erfahrungen in der Literatur schwanken zwischen 20h – 36h (2-5 Tage) pro Use Case Point.
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH 10
Erfahrungen in der Literatur schwanken zwischen 20h 36h (2 5 Tage) pro Use Case Point.
Quelle: APM-Agiles Projektmanagement Bernd Oestereich/Christian Weiss
Funktions Points
Ansatz: Schätzung des Umfangs auf Basis gewichteter Anforderungen bzw. Funktionen
Grundparameter:
Eingaben/Ausgaben
AbfragenAbfragen
Datenbestände
Referenzdateien
Gewichtung mit Einflussfaktoren:
Transaktionsrate
Wiederverwendung
Komplexität
Bewertung basiert auf statistischen Daten abgeschlossener Projekte, diese müssen dazu ggf. nachgemessen werden um die erreichten Funktions Point zu ermitteln
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH
nachgemessen werden um die erreichten Funktions Point zu ermitteln.
Okt.2009: Internationale FunctionPointUserGroup (IFPUG), Version 4.3 des CountingPracticeManuals
11
Function Points - Übersicht
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH 12
Quelle: Balzert
Widget Points
Ansatz: Benötigte Funktions Points aus der Anzahl von GUI-Bedienelemente ableiten.(Fü A d b i d i f i h GUI b öti t i d)(Für Anwendungen, bei denen eine umfangreiches GUI benötigt wird)
GUI f GUI entwerfen
Alle GUI-Objekte zählen
Die verschiedenen GUI-Objekte bleiben ungewichtet.
Wiederverwendete Objekte werden nur einmal gezählt.
Umrechnungsformel in Funktion Points:
1 FunktionPoint = 2 28 * WidgetPoints
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH
1 FunktionPoint = 2,28 WidgetPoints
13
Story Points (agile Methoden, Scrum)
Ansatz: Bewertung einer Einheit in Bezug auf eine schon geschätzte Einheit unter
Verwendung einer virtuellen Schätzgröße (StoryPoints).
Zerlegung des Produkts in einzelne Aufgaben (möglichst kleine Teile).
Eine möglichst kleine Einheit schätzen deren Umfang möglichst klar ist -> BasiseinheitEine möglichst kleine Einheit schätzen deren Umfang möglichst klar ist > Basiseinheit
Die nächsten Einheiten in Bezug zu dieser Einheit oder bereits
geschätzter anderer Einheiten schätzen.
Vorgehen (Planungspoker):
Einheit (z.B. Anforderung) vorstellen
Schätzkarten verdeckt auflegen, dann gemeinsam umdrehen
Extremwerte begründen bzw. diskutieren
Erneut schätzen bis Werte angeglichen oder Schätzgenauigkeit erreicht.Schätzkarten mit
Fibonacci-Folge
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH
Die Umrechnung von StoryPoints in PersonenTage ergibt sich nach 1-2 Iterationen aus der
gemessenen Arbeitsgeschwindigkeit des Teams (Velocity) -> Story-Point pro Tag.
14
Best Practice: Größen schätzen durch Vergleich
Welche Aufgabei t öß ?
1ist größer
ist größer?1
2
1
1
2
2 3 4 5 6
x x
2 Neu3
Neu3
4
5ist
kle
ine
r x
x
x
xx
x
x
4
6
Entscheidungsmatrix
Toolunterstüt ung möglich
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH 15
Toolunterstützung möglich:„Was gefällt dir besser: A od. B?“
Best Practice: TreeMap – Darstellung von Größenvergleichen
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH 16
Dilbert: Aufwandsschätzung
Ich mache einen Projektplan um die
Also ich mache solche Gute Arbeit!Projektplan um die Ressourcen einzuteilen damit wir unsere Software ändern können.
Änderungen in 10 Sekunden…Fertig!
Aber ich wollte doch nur den Projektplan machen…
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH 17
Fragen:
DHBW-Stuttgart/Frank M. Hoyer SWE1-04: Aufwandsschätzung 22. September 2010 geändert: 204 September 2014, FMH 18