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

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

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%


Schätzverfahren: Lineare Regression zum Ausgleich von systematischen Schätzfehlern


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)


Allgemeine Kritik an bisherigen Ansätzen

mangelnde statistische Absicherung

mangelhafte Genauigkeit (Faktor 2 bis 3 Abweichung sind üblich)

geschätzte 10 Personenjahre bedeuten zwischen 3 und 30 Jahren tatsächlichem Aufwand

zu wenig individuelle / domänenspezifische / firmenspezifische Einflussfaktoren

Humprey’s PROBE Methode


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%


Lineare Regression (noch mal)

b0 und b1 wie gehabt


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


Zusammenfassung

im wesentlichen lineare Regression über LOC / Hour Daten

Achtung: die Produktivität schwankt stark von Person zu Person

Falls Personen noch nicht festgelegt, "Durchschnittsperson" verwenden

nach Personeneinteilung, mit persönlichen Faktoren korrigieren

Ergebnis: Gesamtstundenanzahl für das Projekt Konfidenzinterval


Zeitplanerstellung

ACHTUNG:

man arbeitet nicht 52 Wochen a 40 Stunden = 2080 Stunden pro Jahr

Urlaub, Feiertage, Krankheit, Schulungen => 200 Arbeitstage pro Jahr

Besprechungen, Meetings, Mails, Surfen, ... => 4 bis 5 Stunden Entwicklungsarbeit pro Tag

circa 1000 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


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, ) Meilensteine festlegen


Zusammenfassung PSP

solide statistische Absicherung von Projektplänen

LOC als Basismaß

individuelle Datenbasis

hohe Schätzgenauigkeit bei wiederholbarem Prozess

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

Documents

Transcript of Fachgebiet Software Engineering Übersicht © 23.01.2014 Albert Zündorf, Kassel University...