Vorlesung Software-Engineering Ihoyer/3.Semester_2017/Vorlesung/SWE1... · (D T llt d h h t hi dli h t t i ) (Das ... Fibonacci-Folge ... Microsoft PowerPoint

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.


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!


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


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


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.


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


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:


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.


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


nachgemessen werden um die erreichten Funktions Point zu ermitteln.

Okt.2009: Internationale FunctionPointUserGroup (IFPUG), Version 4.3 des CountingPracticeManuals

11

Function Points - Übersicht


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


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


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


Toolunterstützung möglich:„Was gefällt dir besser: A od. B?“

Best Practice: TreeMap – Darstellung von Größenvergleichen


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…


Fragen:


Documents

Vorlesung Software-Engineering Ihoyer/3.Semester_2017/Vorlesung/SWE1... · (D T llt d h h t hi dli h t t i ) (Das ... Fibonacci-Folge ... Microsoft PowerPoint