Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Fachgebiet Software Engineering Übersicht © 22.01.2014 Albert Zündorf, Kassel University Kostenschätzung m Wieviel Stunden brauchen Sie, um ein Programm.

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

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

Ähnliche Präsentationen


Präsentation zum Thema: "Fachgebiet Software Engineering Übersicht © 22.01.2014 Albert Zündorf, Kassel University Kostenschätzung m Wieviel Stunden brauchen Sie, um ein Programm."—  Präsentation transkript:

1 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Kostenschätzung m Wieviel Stunden brauchen Sie, um ein Programm für die Berechnung der Varianz zu schreiben / zu testen? m Wie sicher ist Ihre Schätzung? 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 höchstens 10% Ungenauigkeit beantworten können

2 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Tätigkeiten bei der Softwareentwicklung

3 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Ziele der Prozessmodellierung m Standardisierte Vorgehensweisen m Standardisierte (Teil-) Ergebnisdokumente Vergleichbarkeit von verschiedenen Projekten m Messungen von Prozessgrößen werden möglich / vergleichbar / bewertbar m Basis für Schätzungen m Basis für Planungen m Basis für Verbesserungen

4 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Aufwandsmaße Vergleichsbasiertes Schätzen: m neues Projekt 20% "größer" 20% mehr Zeit/Aufwand m Zeitmessung bleibt schwierig: l manuell: manipulierbar l Controller: ja, aber … l automatisch: ungenau/gescheitert m Größenmessung: l leicht automatisierbar l reproduzierbar l...

5 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Messung der Programm/Problemgröße m gängige 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: Größe sollte leicht / automatisch messbar sein m Zeitschätzungen sind erfahrungsgemäß viel schwerer als Größenschätzungen m Watts Humphrey: l leicht messbar l intuitiv schätzbar l statistische Korrelation zu Zeitaufwand beschreibt Güte

6 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 - 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 -...

7 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

8 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Lines of Code m LOC sieht eigentlich untauglich aus / man hat dabei ein mulmiges Gefühl m Humphrey sagt: l frag die Statistik ob dein Maß taugt l bei geringer Varianz hast du ein gutes Maß

9 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...

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

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

12 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 !

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

14 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

15 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

16 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]

17 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

18 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%

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

20 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)

21 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)

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

23 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

24 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%

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

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

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

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

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

30 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

31 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

32 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

33 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

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

35 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

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

37

38

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

40 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Over Commitment m mehr Aufgaben als Zeit m Kalender dabei haben (den mit den Balken drin) m Für neue Aufgaben: l Zeit finden l Zeitplan / Termin nennen, l Streichposten diskutieren l oder ablehnen m Hier braucht es Rückgrat

41 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Und wenn es trotzdem eng wird? normal: 4 bis 5 Stunden / Tag (22 / Woche) produktive Arbeit (Achtung: persönliche Statistik aufstellen! [PSP]) m Besprechungen auslassen m s 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) - Produktivität geht mit der Zeit runter - Danach braucht man eine Erholungsphase (1 bis 2 Wochen)

42 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Und wenn es trotzdem eng wird? m andere Verpflichtungen / Projekte abgeben m weniger Testen m Funktionalität streichen / zurückstellen (rechtzeitig kommunizieren!) 80 – 20 Regel: 80% Funktionalität mit 20% Aufwand BÖSE

43 Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Alles Gute und bis bald mal: þ Programmieren þ Modellieren þ Große Projekte - Design Pattern - Interaktive Tools – SE2 - Model Driven Engineering - Seminar-, Projekt-, Bachelor-, Master-, Doktorarbeiten, …


Herunterladen ppt "Fachgebiet Software Engineering Übersicht © 22.01.2014 Albert Zündorf, Kassel University Kostenschätzung m Wieviel Stunden brauchen Sie, um ein Programm."

Ähnliche Präsentationen


Google-Anzeigen