Folie 1

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Kostenschtzung m Wieviel Stunden brauchen Sie, um ein Programm fr die Berechnung der Varianz zu schreiben / zu testen? m Wie sicher ist Ihre Schtzung? m Wie lange brauchen Sie, um 1000 LOC zu spezifizieren, zu programmieren, zu testen? m Wie viele Fehler machen Sie durchschnittlich pro 100 Zeiten Quelltext? m Solche Fragen muss man mit hchstens 10% Ungenauigkeit beantworten knnen

Folie 2

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Ttigkeiten bei der Softwareentwicklung

Folie 3

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Ziele der Prozessmodellierung m Standardisierte Vorgehensweisen m Standardisierte (Teil-) Ergebnisdokumente Vergleichbarkeit von verschiedenen Projekten m Messungen von Prozessgren werden mglich / vergleichbar / bewertbar m Basis fr Schtzungen m Basis fr Planungen m Basis fr Verbesserungen

Folie 4

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Aufwandsmae Vergleichsbasiertes Schtzen: m neues Projekt 20% "grer" 20% mehr Zeit/Aufwand m Zeitmessung bleibt schwierig: l manuell: manipulierbar l Controller: ja, aber l automatisch: ungenau/gescheitert m Grenmessung: l leicht automatisierbar l reproduzierbar l...

Folie 5

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Messung der Programm/Problemgre m gngige Metriken l Lines Of Code l Function Points l Anzahl GUI-Elemente l Anzahl der HTML-Tags l Anzahl der Datenbanktabellenspalten, Anzahl SQL-Statement- Elemente l... m zur Arbeitsminimierung: Gre sollte leicht / automatisch messbar sein m Zeitschtzungen sind erfahrungsgem viel schwerer als Grenschtzungen m Watts Humphrey: l leicht messbar l intuitiv schtzbar l statistische Korrelation zu Zeitaufwand beschreibt Gte

Folie 6

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Lines of Code Messen der LOC: + Intuitiv + leicht messbar + korrelieren in gleichbleibendem Umfeld erstaunlich gut zum Zeitaufwand - unterschiedliche Einrckungen - Programmiererabhngig - Erfahrungsabhngig => zeitlich vernderlich - Programmiersprachenabhngig - komplexittsabhngig: 1 Zeile Betriebsystemscheduler entspricht 100 Zeilen GUI-Code - Copy-Paste Programmierung bringt mehr Zeilen als Refactoring in Methoden -...

Folie 7

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Reparaturmanahmen m einheitliche Indentierung z.B. mit JIndent m jeder Entwickler sammelt Daten ber seine persnliche Produktivitt (LOC/Hour) m Trendanalysen der Statistiken erfassen Erfahrungs-Speed-Up m programmiersprachenspezifische Daten sammeln (Sprachen werden nicht so oft gewechselt) m Korrekturfaktoren fr die Komplexitt einzelner Methoden statistisch ermitteln l Komplexitt: leicht, mittel, schwer, komplex l Gre: kurz, mittel, gro, riesig m Weitere Korrekturfaktoren fr die nichtfunktionalen Anforderungen COCOMO Kostenschtzungsverfahren m Varianz der statistischen Daten gibt exakte Auskunft ber die Gte des verwendeten Maes m Gre und Qualitt der statistischen Datenbasis erlauben Aussage ber Qualitt der Schtzung

Folie 8

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Lines of Code m LOC sieht eigentlich untauglich aus / man hat dabei ein mulmiges Gefhl m Humphrey sagt: l frag die Statistik ob dein Ma taugt l bei geringer Varianz hast du ein gutes Ma

Folie 9

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Function Points m Alternativen zu LOC: Function Point Methode m Zhlen der "syntaktischen Konstrukte" l # Methoden l # Parameter l # if und while Statements l...

Folie 10

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Umrechnung von Function Points in LOC

Folie 11

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Umrechnung von Function Points in Personenmonate

Folie 12

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Bewertung des Function-Point-Maes + automatisch messbar + relativ verbreitet + Programmiersprachen unabhngig - nicht sehr intuitiv - Programmiersprachen unabhngig - keine individuellen Einflussfaktoren m letztlich Pro und Contra wie bei LOC nur eine gute statistische Datenbasis erlaubt Aussagen ber die Gte eines Grenmaes !

Folie 13

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Beispiel einer Zeit / LOC Statistik

Folie 14

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, 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

Folie 15

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Der Korrelationskoeffizent m Basis fr Anwendung der linearen Regression m x i, y i wie vorher

Folie 16

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Interpretation des Korrelationskoeffizenten m r nahe bei 1: hohe positive lineare Abhngigkeit m r nahe bei -1: hohe negative lineare Abhngigkeit m r nahe bei 0: wenig (keine) lineare Abhngigkeit m r2 > = 0.9: hohe Wahrscheinlichkeit fr lineare Abhngigkeit 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 mglich m Vorsicht: sinnvolle berprfung nur bei gengend Stichproben (> 10?) m Eventuell: statistische Signifikanz ermitteln, siehe [Humprey95]

Folie 17

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Schtzverfahren: Phasenbasierte Vergleichsschtzung m erstelle Statistik ber prozentualen Anteil der Phasen am Gesamtprojekt m Messe Aufwand fr die erste(n) Phase(n) des aktuellen Projekts m Berechne Restaufwand / Gesamtaufwand + wenig Aufwand + frh anwendbar + wird im Projektverlauf immer genauer - Hochrechnung aufgrund weniger Prozent des Gesamtaufwands Schtzfehler multipliziert sich auf

Folie 18

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Schtzverfahren: Komponentenbasierte Schtzung m erstelle Grobdesign m schtze die Gre der einzelnen Bausteine / Komponenten / Klassen m Summiere Gesamtgre auf m teile durch die Produktivitt => Aufwand - erfordert ein Grobdesign - grerer Aufwand + hhere Genauigkeit + einzelne Schtzfehler mitteln sich weg (wenn statistisch unabhngig) l 25 unabhngige Gren mit einem Schtzfehler von je 100% Gesamtfehler nur 20%

Folie 19

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Schtzverfahren: Lineare Regression zum Ausgleich von systematischen Schtzfehlern

Folie 20

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Delphi Methode m lasse mehrere Experten unabhngig voneinander Schtzen (z.B. komponentenbasiert) m dann diskutieren die Experten ihre Schtzungen (insbesondere auffllige Unterschiede) m obige Schritte werden iteriert bis "Stabilitt" erreicht + Diskussion ber Unterschiede deckt bersehene / falsch eingeschtzte Probleme auf + Minimierung von persnlichen Schtzfehlern des einzelnen Experten - je mehr Experten je mehr Aufwand - gruppendynamische Effekte knnen falsche Tendenzen auslsen (2 oder 3 unabhngige Schtzungen und hchstens zwei Durchgnge sind meistens gut)

Folie 21

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Fuzzy-basiertes Schtzen m Bewertung der Einflussfaktoren mit "linguistischen Kategorien (schwer-mittel-leicht, complex-schwierig-normal-leicht) m Ableitung von Korrekturfaktoren fr die einzelnen Kategorien m entsprechende Korrektur der Basisschtzung + intuitives Verfahren + projektspezifische Anpassungen werden mglich + Korrekturfaktoren knnen mit historischer Datenbasis abgeglichen / justiert werden - Schwankungsbreite durch Korrekturfaktoren ist dramatisch (bis zu Faktor 10 und mehr)

Folie 22

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University

Folie 23

Allgemeine Kritik an bisherigen Anstzen m mangelnde statistische Absicherung m mangelhafte Genauigkeit (Faktor 2 bis 3 Abweichung sind blich) geschtzte 10 Personenjahre bedeuten zwischen 3 und 30 Jahren tatschlichem Aufwand m zu wenig individuelle / domnenspezifische / firmenspezifische Einflussfaktoren Humpreys PROBE Methode

Folie 24

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Fuzzy-Tabelle fr Methodengren m persnliche Tabelle fr Java-Methoden aus statistischen Daten erstellen m Methodengren sollten "normalverteilt" sein (Gausche Glockenkurve) m medium sollte 40% der Flle abdecken, small und large je 20%, der Rest je 10%

Folie 25

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Lineare Regression (noch mal) m b 0 und b 1 wie gehabt

Folie 26

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Schtzgenauigkeit: Konfidenzintervall

Folie 27

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Graphische Veranschaulichung der t-Verteilung

Folie 28

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University t-Verteilung: (Tabelle A2, Seite 489)

Folie 29

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Konfidenzintervall-Beispiel: Datenbasis (Tabelle A30, Seite 551)

Folie 30

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Konfidenzintervall-Beispiel m sig 2 = 313301,3 / 8 = 39162,66 m sig = 197,896 m wir whlen alpha/2 = 90% => t( alpha/2=90, 10 - 2 ) = 1.860 m geschtzte 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 Programmgre zwischen 793 LOC und 1598 LOC

Folie 31

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Verkleinerung des Konfidenzintervalls m weniger Sicherheit verlangen: t(70%, 8) = 1,108 (anstatt 1,860) m grere Datenbasis: t(70%, 30) = 1,055 m Standardabweichung durch viele Teilschtzung verbessern: l 100 mal so groes Programm mit 100 Komponenten a 705 geschtzte LOC l Gesamtschtzung ergibt 70 500 LOC und nach Regression 119 563 erwartete LOC l 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 %) l Generell ist die Genauigkeitsverbesserung

Folie 32

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Zusammenfassung m im wesentlichen lineare Regression ber LOC / Hour Daten m Achtung: die Produktivitt schwankt stark von Person zu Person m Falls Personen noch nicht festgelegt, "Durchschnittsperson" verwenden m nach Personeneinteilung, mit persnlichen Faktoren korrigieren m Ergebnis: l Gesamtstundenanzahl fr das Projekt l Konfidenzinterval

Folie 33

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, 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 (fr ein paar Wochen) auf 50 Stunden pro Woche hochfahren und Schtzfehler ausbgeln m wenn man das dauernd macht bricht man irgendwann ein

Folie 34

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University

Folie 35

Zeitplanerstellung m Gesamtprojektzeit gem Schtzung m Einteilen in Tasks, z.B. Phasen, Komponenten,... m Schtzen der relativen Taskgre und Ableiten der Taskzeit m bestimmen der typischen Stundenzahl fr Projektarbeit pro Woche m Zeiten fr andere Projekte, Schulungen, Urlaub, Meetings,... im Kalender vermerken m pro Kalenderwochen erwartete Projektstunden im Kalender eintragen m Taskreihenfolge festlegen: l Vorgnger / 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

Folie 36

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University

Folie 37

Folie 38

Folie 39

Zusammenfassung PSP m solide statistische Absicherung von Projektplnen m LOC als Basisma m individuelle Datenbasis m hohe Schtzgenauigkeit bei wiederholbarem Prozess

Folie 40

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Over Commitment m mehr Aufgaben als Zeit m Kalender dabei haben (den mit den Balken drin) m Fr neue Aufgaben: l Zeit finden l Zeitplan / Termin nennen, l Streichposten diskutieren l oder ablehnen m Hier braucht es Rckgrat

Folie 41

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Und wenn es trotzdem eng wird? normal: 4 bis 5 Stunden / Tag (22 / Woche) produktive Arbeit (Achtung: persnliche Statistik aufstellen! [PSP]) m Besprechungen auslassen m Emails nicht lesen m berstunden m Wochende m Urlaub m andere Verpflichtungen / Projekte abgeben - Verdopplung der produktiven Stunden erreichbar? - das geht nicht lange (2 bis 4 Wochen) - Produktivitt geht mit der Zeit runter - Danach braucht man eine Erholungsphase (1 bis 2 Wochen)

Folie 42

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Und wenn es trotzdem eng wird? m andere Verpflichtungen / Projekte abgeben m weniger Testen m Funktionalitt streichen / zurckstellen (rechtzeitig kommunizieren!) 80 20 Regel: 80% Funktionalitt mit 20% Aufwand BSE

Folie 43

Fachgebiet Software Engineering bersicht 22.01.2014 Albert Zndorf, Kassel University Alles Gute und bis bald mal: Programmieren Modellieren Groe Projekte - Design Pattern - Interaktive Tools SE2 - Model Driven Engineering - Seminar-, Projekt-, Bachelor-, Master-, Doktorarbeiten,