Fachgebiet Software Engineering Übersicht © 22.01.2014 Albert Zündorf, Kassel University...
-
Upload
berlin-reichard -
Category
Documents
-
view
110 -
download
3
Transcript of Fachgebiet Software Engineering Übersicht © 22.01.2014 Albert Zündorf, Kassel University...
Fachgebiet Software Engineering Übersicht © 11.04.23 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 Zeiten Quelltext?
Solche Fragen muss man mit höchstens 10% Ungenauigkeit beantworten können
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Tätigkeiten bei der Softwareentwicklung
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
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
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Aufwandsmaße
Vergleichsbasiertes Schätzen:
neues Projekt 20% "größer" 20% mehr Zeit/Aufwand
Zeitmessung bleibt schwierig: manuell: manipulierbar Controller: ja, aber … automatisch: ungenau/gescheitert
Größenmessung: leicht automatisierbar reproduzierbar . . .
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Messung der Programm/Problemgröße
gängige Metriken Lines Of Code Function Points Anzahl GUI-Elemente Anzahl der HTML-Tags Anzahl der Datenbanktabellenspalten, Anzahl SQL-Statement-
Elemente . . .
zur Arbeitsminimierung: Größe sollte leicht / automatisch messbar sein Zeitschätzungen sind erfahrungsgemäß viel schwerer als
Größenschätzungen Watts Humphrey:
leicht messbar intuitiv schätzbar statistische Korrelation zu Zeitaufwand beschreibt Güte
Fachgebiet Software Engineering Übersicht © 11.04.23 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
- . . .
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Reparaturmaßnahmen
einheitliche Indentierung z.B. mit JIndent jeder Entwickler sammelt Daten über seine persönliche Produktivität
(LOC/Hour) Trendanalysen der Statistiken erfassen Erfahrungs-Speed-Up programmiersprachenspezifische Daten sammeln
(Sprachen werden nicht so oft gewechselt) Korrekturfaktoren für die Komplexität einzelner Methoden statistisch
ermitteln Komplexität: leicht, mittel, schwer, komplex Größe: kurz, mittel, groß, riesig
Weitere Korrekturfaktoren für die nichtfunktionalen Anforderungen COCOMO Kostenschätzungsverfahren
Varianz der statistischen Daten gibt exakte Auskunft über die Güte des verwendeten Maßes
Größe und Qualität der statistischen Datenbasis erlauben Aussage über Qualität der Schätzung
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Lines of Code
LOC sieht eigentlich untauglich aus / man hat dabei ein mulmiges Gefühl
Humphrey sagt: frag die Statistik ob dein Maß taugt bei geringer Varianz hast du ein gutes Maß
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Function Points
Alternativen zu LOC: Function Point Methode
Zählen der "syntaktischen Konstrukte" # Methoden # Parameter # if und while Statements . . .
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Umrechnung von Function Points in LOC
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Umrechnung von Function Points in Personenmonate
Fachgebiet Software Engineering Übersicht © 11.04.23 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
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 © 11.04.23 Albert Zündorf, Kassel University
Beispiel einer Zeit / LOC Statistik
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Bestimmung einer Ausgleichsgeraden mit "linearer Regression"
Zeitaufwand = b0 + b1 * LOC(oder allgemeiner: y = b0 + b1 * x)
Berechnung der Regressionsparameter b0 und b1
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Der Korrelationskoeffizent
Basis für Anwendung der linearen Regression
xi , yi wie vorher
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Interpretation des Korrelationskoeffizenten
r nahe bei 1: hohe positive lineare Abhängigkeit
r nahe bei -1: hohe negative lineare Abhängigkeit
r nahe bei 0: wenig (keine) lineare Abhängigkeit
r2 > = 0.9: hohe Wahrscheinlichkeit für lineare Abhängigkeit
0.7 < = r2< 0.9: lineare Regression anwendbar
0.5 < = r2< 0.7: lineare Regression nur mit Vorsicht anwenden
r2 < 0.5: keine lineare Regression möglich
Vorsicht: sinnvolle Überprüfung nur bei genügend Stichproben (> 10?)
Eventuell: statistische Signifikanz ermitteln, siehe [Humprey95]
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
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
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%
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Schätzverfahren: Lineare Regression zum Ausgleich von systematischen Schätzfehlern
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
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)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
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)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
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
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
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%
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Lineare Regression (noch mal)
b0 und b1 wie gehabt
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Schätzgenauigkeit: Konfidenzintervall
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Graphische Veranschaulichung dert-Verteilung
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
t-Verteilung: (Tabelle A2, Seite 489)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Konfidenzintervall-Beispiel: Datenbasis (Tabelle A30, Seite 551)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
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
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
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
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
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
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
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
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
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
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Zusammenfassung PSP
solide statistische Absicherung von Projektplänen
LOC als Basismaß
individuelle Datenbasis
hohe Schätzgenauigkeit bei wiederholbarem Prozess
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Over Commitment
mehr Aufgaben als Zeit
Kalender dabei haben (den mit den Balken drin)
Für neue Aufgaben: Zeit finden Zeitplan / Termin nennen, Streichposten diskutieren oder ablehnen
Hier braucht es Rückgrat
Fachgebiet Software Engineering Übersicht © 11.04.23 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])
Besprechungen auslassen
Emails nicht lesen
Überstunden
Wochende
Urlaub
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)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Und wenn es trotzdem eng wird?
andere Verpflichtungen / Projekte abgeben
weniger Testen
Funktionalität streichen / zurückstellen(rechtzeitig kommunizieren!)
80 – 20 Regel:
80% Funktionalität mit 20% Aufwand
BÖSE
Fachgebiet Software Engineering Übersicht © 11.04.23 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, …