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

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Lines of Code Messen der LOC: + Intuitiv + leicht messbar + korrelieren in gleichbleibendem Umfeld erstaunlich gut zum Zeitaufwand - Stilabhängig - Produktgröße - Produktkomplexität - Qualitätsanforderungen - Entwicklungsumgebungen / Tools - Sprachen / Methoden - Ausbildungsstand der Entwickler - individuelle Produktivitäten der Entwickler - Erfahrungsabhängig => zeitlich veränderlich

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Reparaturmaßnahmen m einheitliche Indentierung z.B. mit JIndent m jeder Entwickler sammelt Daten über seine persönliche Produktivität (LOC/Hour) m Trendanalysen der Statistiken erfassen Erfahrungs-Speed-Up m programmiersprachenspezifische Daten sammeln (Sprachen werden nicht so oft gewechselt) m Korrekturfaktoren für die Komplexität einzelner Methoden statistisch ermitteln l Komplexität: leicht, mittel, schwer, komplex l Größe: kurz, mittel, groß, riesig m Weitere Korrekturfaktoren für die nichtfunktionalen Anforderungen COCOMO Kostenschätzungsverfahren m Varianz der statistischen Daten gibt exakte Auskunft über die Güte des verwendeten Maßes m Größe und Qualität der statistischen Datenbasis erlauben Aussage über Qualität der Schätzung

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Function Points m Alternativen zu LOC: Function Point Methode m Zählen der "syntaktischen Konstrukte" l # Methoden l # Parameter l # if und while Statements l...

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Umrechnung von Function Points in LOC

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Umrechnung von Function Points in Personenmonate

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Bewertung des Function-Point-Maßes + automatisch messbar + relativ verbreitet + Programmiersprachen unabhängig - nicht sehr intuitiv - Programmiersprachen unabhängig - keine individuellen Einflussfaktoren m letztlich Pro und Contra wie bei LOC nur eine gute statistische Datenbasis erlaubt Aussagen über die Güte eines Größenmaßes !

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Beispiel einer Zeit / LOC Statistik

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Bestimmung einer Ausgleichsgeraden mit "linearer Regression" m Zeitaufwand = b 0 + b 1 * LOC (oder allgemeiner: y = b 0 + b 1 * x) m Berechnung der Regressionsparameter b 0 und b 1

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Der Korrelationskoeffizent m Basis für Anwendung der linearen Regression m x i, y i wie vorher

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Interpretation des Korrelationskoeffizenten m r nahe bei 1: hohe positive lineare Abhängigkeit m r nahe bei -1: hohe negative lineare Abhängigkeit m r nahe bei 0: wenig (keine) lineare Abhängigkeit m r2 > = 0.9: hohe Wahrscheinlichkeit für lineare Abhängigkeit m 0.7 < = r2< 0.9: lineare Regression anwendbar m 0.5 < = r2< 0.7: lineare Regression nur mit Vorsicht anwenden m r2 < 0.5: keine lineare Regression möglich m Vorsicht: sinnvolle Überprüfung nur bei genügend Stichproben (> 10?) m Eventuell: statistische Signifikanz ermitteln, siehe [Humprey95]

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Schätzverfahren: Phasenbasierte Vergleichsschätzung m erstelle Statistik über prozentualen Anteil der Phasen am Gesamtprojekt m Messe Aufwand für die erste(n) Phase(n) des aktuellen Projekts m Berechne Restaufwand / Gesamtaufwand + wenig Aufwand + früh anwendbar + wird im Projektverlauf immer genauer - Hochrechnung aufgrund weniger Prozent des Gesamtaufwands Schätzfehler multipliziert sich auf

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Schätzverfahren: Komponentenbasierte Schätzung m erstelle Grobdesign m schätze die Größe der einzelnen Bausteine / Komponenten / Klassen m Summiere Gesamtgröße auf m 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) l 25 unabhängige Größen mit einem Schätzfehler von je 100% Gesamtfehler nur 20%

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Schätzverfahren: Lineare Regression zum Ausgleich von systematischen Schätzfehlern

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Delphi Methode m lasse mehrere Experten unabhängig voneinander Schätzen (z.B. komponentenbasiert) m dann diskutieren die Experten ihre Schätzungen (insbesondere auffällige Unterschiede) m 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)

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Fuzzy-basiertes Schätzen m Bewertung der Einflussfaktoren mit "linguistischen Kategorien (schwer-mittel-leicht, complex-schwierig-normal-leicht) m Ableitung von Korrekturfaktoren für die einzelnen Kategorien m 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)

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

Allgemeine Kritik an bisherigen Ansätzen m mangelnde statistische Absicherung m mangelhafte Genauigkeit (Faktor 2 bis 3 Abweichung sind üblich) geschätzte 10 Personenjahre bedeuten zwischen 3 und 30 Jahren tatsächlichem Aufwand m zu wenig individuelle / domänenspezifische / firmenspezifische Einflussfaktoren Humpreys PROBE Methode

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Fuzzy-Tabelle für Methodengrößen m persönliche Tabelle für Java-Methoden aus statistischen Daten erstellen m Methodengrößen sollten "normalverteilt" sein (Gaußsche Glockenkurve) m medium sollte 40% der Fälle abdecken, small und large je 20%, der Rest je 10%

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Lineare Regression (noch mal) m b 0 und b 1 wie gehabt

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Schätzgenauigkeit: Konfidenzintervall

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Graphische Veranschaulichung der t-Verteilung

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University t-Verteilung: (Tabelle A2, Seite 489)

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Konfidenzintervall-Beispiel: Datenbasis (Tabelle A30, Seite 551)

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Konfidenzintervall-Beispiel m sig 2 = ,3 / 8 = 39162,66 m sig = 197,896 m wir wählen alpha/2 = 90% => t( alpha/2=90, ) = m geschätzte LOC = 705 m nach linearer Regression mit b 0 = -22,54 und b 1 = 1,7279 erwarten wir 1195,63 LOC m mit 90% Sicherheit liegt die Programmgröße zwischen 793 LOC und 1598 LOC

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Verkleinerung des Konfidenzintervalls m weniger Sicherheit verlangen: t(70%, 8) = 1,108 (anstatt 1,860) m größere Datenbasis: t(70%, 30) = 1,055 m Standardabweichung durch viele Teilschätzung verbessern: l 100 mal so großes Programm mit 100 Komponenten a 705 geschätzte LOC l Gesamtschätzung ergibt LOC und nach Regression erwartete LOC l beim Konfidenzintervall rechnet man nicht 100 * Range sondern Wir erwarten zwischen bis LOC mit 90 % Konfidenz (Fehler ist kleiner als 10 %) l Generell ist die Genauigkeitsverbesserung

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Zusammenfassung m im wesentlichen lineare Regression über LOC / Hour Daten m Achtung: die Produktivität schwankt stark von Person zu Person m Falls Personen noch nicht festgelegt, "Durchschnittsperson" verwenden m nach Personeneinteilung, mit persönlichen Faktoren korrigieren m Ergebnis: l Gesamtstundenanzahl für das Projekt l Konfidenzinterval

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Zeitplanerstellung ACHTUNG: m man arbeitet nicht 52 Wochen a 40 Stunden = 2080 Stunden pro Jahr m Urlaub, Feiertage, Krankheit, Schulungen => 200 Arbeitstage pro Jahr m Besprechungen, Meetings, Mails, Surfen,... => 4 bis 5 Stunden Entwicklungsarbeit pro Tag circa 1000 Stunden pro Personenjahr m mehr ist unproduktiv und nicht lange durchzuhalten m wenns brennt kann man (für ein paar Wochen) auf 50 Stunden pro Woche hochfahren und Schätzfehler ausbügeln m wenn man das dauernd macht bricht man irgendwann ein

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

Zeitplanerstellung m Gesamtprojektzeit gemäß Schätzung m Einteilen in Tasks, z.B. Phasen, Komponenten,... m Schätzen der relativen Taskgröße und Ableiten der Taskzeit m bestimmen der typischen Stundenzahl für Projektarbeit pro Woche m Zeiten für andere Projekte, Schulungen, Urlaub, Meetings,... im Kalender vermerken m pro Kalenderwochen erwartete Projektstunden im Kalender eintragen m Taskreihenfolge festlegen: l Vorgänger / Nachfolgerbeziehung festlegen => Gantt Chart l topologisch sortieren l kritische Pfade analysieren l Risikoanalyse l... m Tasks im Kalender eintragen (z.B. mit Microsoft Project, ) m Meilensteine festlegen

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

Zusammenfassung PSP m solide statistische Absicherung von Projektplänen m LOC als Basismaß m individuelle Datenbasis m hohe Schätzgenauigkeit bei wiederholbarem Prozess