OKA Anmeldung Now Open m Meldet euch bis zum 11.02.2011 in der OKA an (unter Softwaretechnik)...

OKA Anmeldung Now Open

Meldet euch bis zum 11.02.2011 in der OKA an(unter Softwaretechnik)

Fachgebiet Software Engineering Übersicht © 11.04.2023 Albert Zündorf, Kassel University


Kostenschätzung

Wieviel Stunden brauchen Sie, um ein Programm für die Berechnung der Varianz zu schreiben / zu testen?

Wie sicher ist Ihre Schätzung? Wie lange brauchen Sie, um 1000 LOC zu spezifizieren, zu

programmieren, zu testen? Wie viele Fehler machen Sie durchschnittlich pro 100 Zeilen

Quelltext? Solche Fragen muss man mit höchstens 10%

Ungenauigkeit beantworten können


Ziele der Prozessmodellierung

Standardisierte Vorgehensweisen Standardisierte (Teil-) Ergebnisdokumente

Vergleichbarkeit von verschiedenen Projekten Messungen von Prozessgrößen werden möglich /

vergleichbar / bewertbar Basis für Schätzungen Basis für Planungen Basis für Verbesserungen

Schätzen mit Konfidenzinterval


0 10 20 30 40 50 60 70 80 900

50

100

150

200

250

300

Est.Time (Std)

Act

Tim

e (S

td)

Konfidenz mit Excel

Projekt Est.Time (Std) Act.Time(Std) Regression Fehler

CoffeeCounter 40 124 115,962618 8,03738228

AirDrone 10 28 25,1424178 2,85758216

MilkOrderSys 22 61 61,4704978 -0,47049779

QRDoor 4 16 6,97837786 9,02162214

AndroidCar 6 20 13,0330579 6,96694215

LegoSegWay 8 40 19,0877378 20,9122622

TrafficSim 80 255 237,056218 17,9437824

Android3D 24 59 67,5251778 -8,52517778

WLanLocalization 32 35 91,7438978 -56,7438978

varianz: 531,8456539

sigma: 23,06177907 21,7428538

Korrelationskoeffizient r: 0,95329747

Steigung b1: 3,02734

Achsabschnitt b0: -5,13098213

anzahl: 9

estimation: 42

regression: 122,0172977 122,017298

lower range 111,2796157

upper range 132,7549797

Genauigkeit 80%

Konfidenz.T 10,73768203


• Schätz- und Messdaten alter Projekte• Ausgleichsgerade y = b1 * x + b0• Standardabweichung sigma• Konfidenz mit t-Verteilung• Obere und untere Schranke


Schätzgenauigkeit: Konfidenzintervall

2


Graphische Veranschaulichung dert-Verteilung


t-Verteilung: (Tabelle A2, Seite 489)


Konfidenzintervall-Beispiel: Datenbasis (Tabelle A30, Seite 551)


Konfidenzintervall-Beispiel

sig2 = 313301,3 / 8 = 39162,66 sig = 197,896 wir wählen alpha/2 = 90% => t( alpha/2=90, 10 - 2 ) = 1.860 geschätzte LOC = 705 nach linearer Regression mit b0 = -22,54 und b1 = 1,7279 erwarten wir 1195,63

LOC

mit 90% Sicherheit liegt die Programmgröße zwischen 793 LOC und 1598 LOC


Verkleinerung des Konfidenzintervalls

weniger Sicherheit verlangen: t(70%, 8) = 1,108 (anstatt 1,860) größere Datenbasis: t(70%, 30) = 1,055 Standardabweichung durch viele Teilschätzung verbessern:

100 mal so großes Programm mit 100 Komponenten a 705 geschätzte LOC

Gesamtschätzung ergibt 70 500 LOC und nach Regression 119 563 erwartete LOC

beim Konfidenzintervall rechnet man nicht 100 * Range sondern

Wir erwarten zwischen 114 000 bis 124 000 LOC mit 90 % Konfidenz (Fehler ist kleiner als 10 %)

Generell ist die Genauigkeitsverbesserung

Lines of Code Schätzungen


0 100 200 300 400 500 600 700 800 9000

50

100

150

200

250

300

Est.LOC

Act

Tim

e (S

td)

Lines of Code Schätzungen

Zeitmessungen tendenziell schwierig

Zeitschätzungen tendenziell ungenau

=>

LOC als einfaches Größen- / Schätzmaß



Lines of Code

Messen der LOC:

+ Intuitiv

+ leicht messbar

+ korrelieren in gleichbleibendem Umfeld erstaunlich gut zum Zeitaufwand

- unterschiedliche Einrückungen

- Programmiererabhängig

- Erfahrungsabhängig => zeitlich veränderlich

- Programmiersprachenabhängig

- komplexitätsabhängig: 1 Zeile Betriebsystemscheduler entspricht 100 Zeilen GUI-Code

- Copy-Paste Programmierung bringt mehr Zeilen als Refactoring in Methoden

- . . .


Function Points

Alternativen zu LOC: Function Point Methode

Zählen der "syntaktischen Konstrukte" # Methoden # Parameter # if und while Statements . . .


Umrechnung von Function Points in LOC


Umrechnung von Function Points in Personenmonate


Bewertung des Function-Point-Maßes

+ automatisch messbar

+ relativ verbreitet

+ Programmiersprachen unabhängig

- nicht sehr intuitiv

- Programmiersprachen unabhängig

- keine individuellen Einflussfaktoren

letztlich Pro und Contra wie bei LOC

nur eine gute statistische Datenbasis erlaubt Aussagen über die Güte eines Größenmaßes !


Schätzverfahren: Phasenbasierte Vergleichsschätzung

erstelle Statistik über prozentualen Anteil der Phasen am Gesamtprojekt

Messe Aufwand für die erste(n) Phase(n) des aktuellen Projekts Berechne Restaufwand / Gesamtaufwand

+ wenig Aufwand

+ früh anwendbar

+ wird im Projektverlauf immer genauer

- Hochrechnung aufgrund weniger Prozent des Gesamtaufwands

Schätzfehler multipliziert sich auf


Schätzverfahren: Komponentenbasierte Schätzung

erstelle Grobdesign schätze die Größe der einzelnen Bausteine / Komponenten / Klassen Summiere Gesamtgröße auf teile durch die Produktivität => Aufwand

- erfordert ein Grobdesign

- größerer Aufwand

+ höhere Genauigkeit

+ einzelne Schätzfehler mitteln sich weg (wenn statistisch unabhängig) 25 unabhängige Größen mit einem Schätzfehler von je 100% Gesamtfehler nur 20%


Delphi Methode

lasse mehrere Experten unabhängig voneinander Schätzen(z.B. komponentenbasiert)

dann diskutieren die Experten ihre Schätzungen(insbesondere auffällige Unterschiede)

obige Schritte werden iteriert bis "Stabilität" erreicht

+ Diskussion über Unterschiede deckt übersehene / falsch eingeschätzte Probleme auf

+ Minimierung von persönlichen Schätzfehlern des einzelnen Experten

- je mehr Experten je mehr Aufwand

- gruppendynamische Effekte können falsche Tendenzen auslösen(2 oder 3 unabhängige Schätzungen und höchstens zwei Durchgänge sind meistens gut)


Fuzzy-basiertes Schätzen

Bewertung der Einflussfaktoren mit "linguistischen Kategorien„(schwer-mittel-leicht, complex-schwierig-normal-leicht)

Ableitung von Korrekturfaktoren für die einzelnen Kategorien entsprechende Korrektur der Basisschätzung

+ intuitives Verfahren

+ projektspezifische Anpassungen werden möglich

+ Korrekturfaktoren können mit historischer Datenbasis abgeglichen / justiert werden

- Schwankungsbreite durch Korrekturfaktoren ist dramatisch (bis zu Faktor 10 und mehr)


Fuzzy-Tabelle für Methodengrößen

persönliche Tabelle für Java-Methoden aus statistischen Daten erstellen Methodengrößen sollten "normalverteilt" sein (Gaußsche Glockenkurve) medium sollte 40% der Fälle abdecken, small und large je 20%, der Rest je 10%


Zeitplanerstellung

ACHTUNG: man arbeitet nicht 52 Wochen a 40 Stunden = 2080 Stunden pro Jahr Urlaub, Feiertage, Krankheit, Schulungen => 220 Arbeitstage pro Jahr Besprechungen, Meetings, Mails, Surfen, ... => 4 bis 5 Stunden

Entwicklungsarbeit pro Tag

circa 1100 Stunden pro Personenjahr mehr ist unproduktiv und nicht lange durchzuhalten wenn’s brennt kann man (für ein paar Wochen) auf 50 Stunden pro Woche

hochfahren und Schätzfehler ausbügeln wenn man das dauernd macht bricht man irgendwann ein


Probe MethodeWatts Humphrey


Zeitplanerstellung

Gesamtprojektzeit gemäß Schätzung Einteilen in Tasks, z.B. Phasen, Komponenten, ... Schätzen der relativen Taskgröße und Ableiten der Taskzeit bestimmen der typischen Stundenzahl für Projektarbeit pro Woche Zeiten für andere Projekte, Schulungen, Urlaub, Meetings, ...

im Kalender vermerken pro Kalenderwochen erwartete Projektstunden im Kalender eintragen Taskreihenfolge festlegen:

Vorgänger / Nachfolgerbeziehung festlegen => Gantt Chart topologisch sortieren kritische Pfade analysieren Risikoanalyse ...

Tasks im Kalender eintragen (z.B. mit Microsoft Project, JGantt ) Meilensteine festlegen

Scrum Schätzungen

Burn Down Charts

Komponentenbasierte Task Schätzung

Zeitbasierte Schätzung

Messung des Projektfortschritts durch Restzeitschätzung

Keine Erfassung / Planung der Arbeitszeiten

Burn Down Velocity für‘s Team (Steigung der Ausgleichsgerade)

Standardabweichung und Konfidenzintervalle denkbar


OKA Anmeldung Now Open m Meldet euch bis zum 11.02.2011 in der OKA an (unter Softwaretechnik)...

Documents

Transcript of OKA Anmeldung Now Open m Meldet euch bis zum 11.02.2011 in der OKA an (unter Softwaretechnik)...