Informationsmanagement in Organisationen Software-Metriken und Aufwandsschätzung

Transkript

1 Informationsmanagement in Organisationen Software-Metriken und Aufwandsschätzung Wolfgang H. Janko Andreas Geyer-Schulz Stefan Koch Edward Bernroider Abteilung für Informationswirtschaft Institut für Informationsverarbeitung und Informationswirtschaft Wirtschaftsuniversität Wien Augasse 2-6, A-1090 Wien, Österreich Telefon: URL:

2 Inhaltsverzeichnis 1. Software-Metriken (a) Grundlagen (b) Lines-of-Code (c) Cyclomatic Complexity (d) Halstead-Maß (e) Metriken der objekt-orientierten Programmierung 2. Aufwandsschätzung (a) Grundlagen (b) COCOMO (c) Modell von Putnam (d) Function Points (e) Nicht-algorithmische Verfahren (f) Einsatz in Organisationen, Datengewinnung und Validierung 1

3 Software-Metriken Grundlagen Metrik: Zuordnung einer Zahl zu einer Entität, um ein spezielles Attribut dieser Entität zu charakterisieren Klassen von Software-Metriken Produktmetriken: Maßzahlen für das Software-Produkt Prozessmetriken: Quantifizierung von Attributen des Entwicklungsprozesses und der Entwicklungsumgebung Messung von Software-Metriken direkt: ohne Abhängigkeit von einem anderen Attribut indirekt: inkludiert die Messung eines oder mehrerer anderer Attribute Anforderungen an Software-Metriken Einfachheit Validität Robustheit Analysierbarkeit mit statistischen Mitteln Eignung im Rahmen des Software-Projektmanagements Sensitivität auf atomare Änderungen 2

4 Verwendung und Nutzen von klaren und wohldefinierten Zielen geleitet (Goal/Question/Metric-Ansatz) Feststellung ( assessment ) im Rahmen der Steuerung eines Software-Projekts Vorhersage ( prediction ) von Charakteristiken von Projekten (Aufwandsschätzung) taktische Anwendung in Rahmen des Projektmanagements, strategische Anwendung im Rahmen der Prozessverbesserung 3

5 Lines-of-Code eine der gebräuchlichsten Metriken für die Größe einer Software LOC oder Programmzeilen jedoch unterschiedliche Definitionen (Was wird gezählt?) ausführbare Programmzeilen oder Anweisungen in jeder gängigen Definition inkludiert Kommentare? Leerzeilen? ohne diese beiden: NCSS (Non Commentary Source Statements) Deklarationen von Variablen oder Prozeduren? Anweisungen im Header? Compiler-Anweisungen? Programmzeile kann mehrere Anweisungen umfassen bei Überarbeitungen: Zählung von Löschen und Modifikation von einzelnen Programmzeilen Zählung bei Wiederverwendung von Code-Bestandteilen organisationsweit einheitliche Definition unumgänglich Verbindung zum Anreizsystem beachten 4

6 Vorteil: einfach, automatisiert erhebbar Probleme Sprachabhängigkeit mißt eigentlich nur Größe (etwa für die Speicherung oder einen Ausdruck) und nicht Komplexität (Beispiel rekursive Programme) 5

7 Beispiel use DBI; #open log files while(<cvs>) { my $count; if (/^RCS file: cvsroot([^]+)(.+),/) { $project=$1;$realfile=$1."/".$2; $file=$realfile; $file =~ tr/ /"/; $sumadd=0;$sumdel=0;$count++; my $instr="insert into file values ( $file, $project )"; print $instr; } elsif (/^date: (.+); author: (w+); state: Exp;$/) { $date=$1;$prog=$2; $lines_total= wc -l $datadir/$realfile ; } close CVS; } LOC: 21, 20 (ohne Leerzeilen), 19 (ohne Kommentar), 17 (ohne Deklarationen), 12 (nur Zeilen mit Befehlen), 16 (jeder Befehl)? 6

8 Cyclomatic Complexity beruht auf der Kontrollflußstruktur ( control flow graph oder flowgraph ) eines Programms mißt die Anzahl der linear unabhängigen Wege durch den Flowgraph F bei e Kanten, n Knoten und p Zusammenhangskomponenten v(f ) = e n + 2p (1) Knoten: Block sequentieller Anweisungen, die keine internen Verzweigungen aufweisen Kante: möglicher Kontrollfluß zwischen den Knoten Zusammenhangskomponenten: unabhängige Programmkomponenten (Module oder Prozeduren) Annahme: Module mit einer Cyclomatic Complexity von mehr als 10 besonders fehleranfällig erlaubt Aussagen über die Komplexität des Kontrollflusses beeinflußt vor allem das Testen, bei dem alle Pfade betrachtet werden sollten 7

9 Cyclomatic Complexity - Beispiele e = 15 n = 13 v(f) = e = 11 n = 9 v(f) =

10 Halstead-Maß Grundidee: Zählen von Operatoren (Symbole, die den Wert oder die Anordnung eines Operanden beeinflussen) und Operanden (Variablen oder Konstanten) gemessen werden jeweils die Gesamtanzahl sowie die Anzahl der verschiedenen Operatoren bzw. Operanden in der vorliegenden Implementierung (N 1 und N 2 bzw. η 1 und η 2 ) Beispiel (N 1 =4, N 2 =4, η 1 =2, η 2 =3) print $name; print $adresse; print $alter; $alter++; Vokabular: η = η 1 + η 2 Implementierungslänge: N = N 1 + N 2 Größe der Implementierung eines Algorithmus: Volumen V = N log 2 η es kann dann das Verhältnis zum minimalen oder potentiellen Volumen berechnet werden (Programmstufe) 9

11 Schwierigkeit des Verständnisses invers zu der Programmstufe (für jemanden mit geringem Wissen braucht man mehr Volumen zum Verständnis) 10

12 Metriken der objekt-orientierten Programmierung bekanntester Ansatz von Chidamber und Kemerer: weighted methods per class : Komplexität einer Klasse, für jede Funktion der Wert 1 depth in inheritance tree : Länge des längsten Pfades durch die Vererbungshierarchie number of children : Anzahl der Klassen, die direkt von dieser erben coupling between methods : Anzahl der Module, die mit dem betrachteten gekoppelt sind (wenn eine davon die Funktionen und/oder die Instanzvariablen der anderen benutzt) response for a class : Anzahl der Methoden, die potentiell ausgeführt werden können, wenn ein Objekt der betrachteten Klasse eine Nachricht empfängt lack of cohesion on methods : Anzahl der Methoden-Paare, die keine gemeinsamen Instanzvariablen haben, abzüglich der Anzahl der Methoden-Paare, die solche besitzen Ergänzungen und andere Ansätze: 11

13 inheritance coupling : Anzahl der Vaterklassen, mit der eine Klasse gekoppelt ist (wenn eine der geerbten Methoden eine neue oder neu definierte Variable oder Methode benutzt) coupling between methods : Anzahl der neuen oder neu definierten Methoden, mit denen die geerbten Methoden gekoppelt sind average method complexity : durchschnittliche Größe der Methoden einer Klasse MOOD-Gruppe: Method Inheritance Factor, Attribute Inheritance Factor, Coupling Factor, Clustering Factor, Polymorphism Factor, Method Hiding Factor, Attribute Hiding Factor und Reuse Factor 12

14 Literatur Norman E. Fenton, Software Metrics: A Rigorous Approach, Chapman & Hall, London, S.D. Conte and H.E. Dunsmore and V.Y. Shen, Software Engineering Metrics and Models, Benjamin/Cummings, Menlo Park, California, T.J. McCabe, A Complexity Measure, IEEE Transactions on Software Engineering, 2(4): , December Maurice H. Halstead, Elements of Software Science, Elsevier North-Holland, New York, Shyam R. Chidamber and Chris F. Kemerer, A Metrics Suite for Object-Oriented Design, IEEE Transactions on Software Engineering, 20(6): , June

15 Aufwandsschätzung Grundlagen Entwicklung und Wartung von Software: Aufgabe von hoher Unsicherheit vor allem die zugrundeliegende Komplexität zu Beginn kaum abzuschätzen Ziel trotzdem: Zeit-, Kosten- und Personalplanung sowie die laufende Kontrolle rein subjektive Schätzungen durch Experten haben sich als zu fehleranfällig erwiesen Modell zur Aufwandsschätzung: Vorhersagesystem für Attribute des zugrundeliegenden Prozesses (Aufwand, Kosten, Dauer) besteht aus einem mathematischen Modell des Prozesses mit den Beziehungen zwischen den verschiedenen Attributen, einer Vorgehensweise zur Bestimmmung unbekannter Parameter und einer Anleitung zur Interpretation der Ergebnisse Anforderungen: Validität der Schätzungen, Objektivität, einfache Handhabung, Robustheit in Hinsicht auf kleine 14

16 Änderungen bei den Input-Parametern und Transportfähigkeit zwischen verschiedenen Umgebungen 15

17 Einteilung Einteilung von Modellen nach der Methode, mittels derer sie abgeleitet wurden (Conte et al., 1986) Historisch-experimentelle Modelle: Expertenschätzungen, teilweise basierend auf historischen Daten Statistik-basierte Modelle: normalerweise mittels Regressionsanalyse eine Beziehung zwischen Aufwand und anderen Parametern wie der Programmgröße bestimmt Theoretisch-basierte Modelle: Annahmen über die Funktionsweise des menschlichen Geistes bei der Programmentwicklung sowie postulierte mathematische Gesetze, denen der Software-Entwicklungsprozeß folgt Zusammengesetzte Modelle andere Einteilungen z.b. nach der mathematischen Form der verwendeten Gleichungen, nach der Art der Daten, die zur Voraussage verwendet werden, und nach den Annahmen, die hinsichtlich des Software-Entwicklungsprozesses gemacht werden,... 16

18 Modelle der Software-Entwicklung liegen den meisten Aufwandsschätzungsmodellen zugrunde Ansatz von Norden: Entwicklungsprojekt: endliche Folge von zielgerichteten, zeitlich geordneten Aktivitäten, die sich auf eine homogene Menge von Problemelementen beziehen, um eine spezifizierte Menge von Zielen zu erreichen Projekt besteht folglich aus einer Menge von Problemen, die alle gelöst werden müssen Annahme: Anzahl der Probleme ist unbekannt aber endlich Annahme: Finden sowie Lösung von Problemen findet durch die kreative Leistung der eingesetzten Arbeitskräfte ( manpower ) statt Annahme: Lösen eines Problem ist ein Ereignis, das ein Element aus der endlichen Menge der ungelösten entfernt, Auftreten dieser Ereignisse ist unabhängig und zufällig (Poisson-Verteilung) Annahme: Anzahl der Personen, die zu einem bestimmten Zeitpunkt sinnvoll an einem Projekt mitarbeiten können, ist ungefähr proportional zu der Anzahl der 17

19 Probleme, die zu diesem Zeitpunkt zur Lösung bereit sind Folge: gegen Ende eines Projekts, wenn nur mehr wenige Probleme vorhanden sind, nimmt die Anzahl der eingesetzten Mitarbeiter ab (bzw. sollte es) Annahme: Lernrate des Projektteams wird mittels einer linearen Funktion der Zeit t mit p(t) = 2 a t modelliert Kosten C(t) in Mannjahren des Projektes entstehen durch die Kumulierung der eingesetzten Arbeitskraft über die Zeit Kosten sind zu Beginn des Projektes Null und steigen monton bis zum Gesamtaufwand K an Änderung dieser Kostenfunktion zu einem beliebigen Zeitpunkt, dc(t)/dt, ist die Anzahl der zu diesem Zeitpunkt involvierten Personen diese Anzahl der nutzbringend involvierten Personen ist über einen Faktor k (Lernrate) proportional zur Anzahl der noch zu lösenden Probleme diese Anzahl kann über die Differenz zwischen den bisher angefallenen Kosten und der Gesamtanzahl der Probleme, wobei dafür der gesamte Projektaufwand K als Indikator verwendet wird, ausgedrückt werden Folge: kumulativer Aufwand zu einem Zeitpunkt t C(t) = K[1 exp( at 2 )] (2) 18

20 Ableitung dieses Ausdrucks nach der Zeit gibt somit die Besetzung des Projekts mit Personen ( manpower function, Manpower-Funktion) an: m(t) = C (t) = 2 K a t exp( a t 2 ) (3) dies stellt eine Rayleigh-Kurve dar, daher Norden/Rayleigh- Modell genannt Verlauf: zu Beginn ein Wert von 0, dann ein Anstieg bis zu einem Gipfelpunkt t d und schließlich ein stetiger Abstieg wiederum auf 0 (Parameter a hat dabei einen wichtigen Einfluß auf diesen Gipfelpunkt t d, je größer a ist, desto steiler der Anstieg und früher der Gipfelpunkt) Es kann, wenn der Gipfelpunkt t d erreicht, und damit zugleich die Besetzung mit Personen zu diesem Zeitpunkt m 0 bekannt ist, der Gesamtaufwand K, der für das Projekt anfällt, berechnet werden. ähnlich Ansatz von Parr: Abfall im Entwicklungsaufwand gegen Ende eines Projekts ebenfalls erklärt durch Ausschöpfung des Problemraumes, jedoch keine Lernrate, sondern Abhängigkeiten zwischen den zu lösenden Problemen (Menge von sichtbaren ungelösten Problemen - modelliert Nutzen strukturierter Programmierung), Unterschiede vor allem in der Anfangsphase (Beginn eines Projekts nicht genau definiert) 19

21 NOV 1999 SEP 1999 JUL 1999 MAY 1999 MAR 1999 JAN 1999 NOV 1998 SEP 1998 JUL 1998 MAY 1998 MAR 1998 JAN 1998 NOV 1997 SEP 1997 JUL 1997 MAY Vollzeitprogrammierer 10 Variante 1 0 Variante 2 MAR 1997 JAN 1997 Abbildung 1: Rayleigh-Modell GNOME Projekt 20

22 Software-Entwicklungsprozeß als Produktionsfunktion einfachster Fall: Input einer solchen Funktion ist Aufwand zum Beispiel in Mannjahren und der Output ist das erstellte Software-Artefakt, gemessen anhand einer Metrik für die Größe wie zum Beispiel LOC unterschiedliche Arten von Produktionsfunktion: linear (nicht haltbar), quadratisch, Cobb-Douglas (S = a 0 E a 1), translog-produktionsfunktion,... Problem: steigende wie auch sinkende Skaleneffekte empirisch belegt Software-Projekt als dynamisches System (auch Faktoren wie die Erwartungen der Projektleitung, die Reaktionen auf Verzögerungen oder die Motivation der Mitarbeiter explizit modelliert) 21

23 Abbildung 2: Scatterplot 22

24 Abbildung 3: Regression 23

25 COCOMO COnstructive COst MOdel (Boehm) existiert in drei zunehmend detaillierteren Formen (Basic, Intermediate und Detailed) Grundannahmen Wasserfall-Modell Existenz von drei verschiedenen Modi der Entwicklung Organic: Kleine Teams erfahrener Personen in bekanntem Umfeld, mit stabiler Entwicklungsumgebung und geringer Projektgröße Embedded: Projekte relativ hoher Größe unter Existenz schwieriger Nebenbedingungen mit höherer Unsicherheit sowie einem höheren Innovationsgrad Semi-detached: Mischung aus den beiden anderen Modi primärer Kostentreiber sind die ausgelieferten Source- Anweisungen ( delivered source instructions ) gutes Management von Entwickler- wie auch Kundenseite weitgehende Konstanz der Anforderungsspezifikation während des Projektverlaufes 24

26 Entwicklungsaufwand E in Mannmonaten wird über die Größe S (in 1000en delivered source instructions ) ausgedrückt: E = a i S b i m(x) (4) m(x): Einfluß von 15 Umgebungsfaktoren (Produktattribute wie geforderte Zuverlässigkeit des System, Computerattribute wie Hauptspeicherengpäße, Personalattribute wie Programmiersprachenerfahrung und Projektattribute wie moderne Programmierpraktiken), diese werden jeweils in einigen Stufen von sehr niedrig bis sehr hoch bewertet (nach einer Tabelle folgt daraus jeweils ein Wert von ca. 0.7 bis 1.3, diese werden über alle Faktoren miteinander multipliziert), Anmerkung: werden erst in Intermediate COCOMO inkludiert, in Detailed COCOMO sogar für die einzelnen Phasen der Software-Entwicklung getrennt bewertet Parameter a i sowie b i : abhängig von Modus der Entwicklung und Form des Modells Modell Modus Entwicklungsaufwand Basic Organic E = 2.4S 1.05 Semi-detached E = 3.0S 1.12 Embedded E = 3.6S 1.20 Intermediate Organic E = 3.2S 1.05 m(x) Semi-detached E = 3.0S 1.12 m(x) Embedded E = 2.8S 1.20 m(x) 25

27 Vorgehen bei der Schätzung 1. Auswahl des Detaillierungsgrades (also des Modells): Basic, Intermediate oder Detailed 2. Einordnung des Projekts in eine der drei Modi: Organic, Semi-detached oder Embedded 3. Schätzung der Größe der zu erstellenden Software in LOC 4. für die Modelle Intermediate oder Detailed: Bewertung der 15 Umgebungsfaktoren 5. Anwendung der Formel (die zu verwendende Formel ergibt sich aus der Kombination Modell-Modus) Beispiel Entwicklung einer neuen Anwendung an der WU für LV-Anmeldung und Verwaltung Basic Model wird gewählt Modus Semi-detached wird gewählt Grösse wird mit LOC geschätzt Umgebungsfaktoren nicht nötig, da Basic Model verwendet wird ergibt Formel E = und damit einen Aufwand von 100,5 Mannmonaten Probleme 26

28 neuere Lebenszyklusmodelle Verfügbarkeit von Informationen in unterschiedlichen Stadien der Entwicklung (LOC schwer zu Beginn zu schätzen) daher: COCOMO 2 (Boehm et al., 2000) jetzt auch Verwendung von Function Points für Größenschätzung (siehe unten) Bewertung von Reuse mittels eines nicht-linearen Modells Re-engineering und Konvertierung von Bestandteilen eines vorhandenen Systems werden bewertet sowohl Economies wie auch Diseconomies of Scale möglich Schätzung: Effort nominal = A (Size) E (5) A: aufgrund der vorgenommenen Kalibrierung auf 2.94 gesetzt Skalen-Parameter E wird über fünf Skalenfaktoren (Precedentedness, Development Flexibility, Architecture/Risk Resolution, Team Cohesion und Process Maturity) mit einer jeweiligen Gewichtung SF j durch die Formel E = B bestimmt (B momentan 0.91) 27 j=1 SF j (6)

29 Einfluß von Kostentreibern EM i (alle 17 oder zu Beginn der Entwicklung nur 7 im Einsatz): Effort adjusted = Effort nominal 17 i=1 EM i (7) 28

30 Modell von Putnam basiert auf einer Modellierung des Software-Entwicklungsprozesses nach Norden/Rayleigh Untersuchung von 200 Projekten: Verlauf bestätigt außerdem: Gipfelpunkt t d liegt sehr nahe an dem Zeitpunkt liegt, zu dem das System operativ gesetzt wird (t d gleich Entwicklungszeit) Rayleigh-Gleichung dividiert durch die Zeit t mittels Logarithmus linearisiert ergibt eine Gerade (Argument des Interzepts weist eine Beziehung zu den betrachteten Projekten auf) Schwierigkeitsgrad ( difficulty ) eines Projektes mit D = K t 2 d (8) Betrachtung der Änderung des Schwierigkeitsgrades D über dessen Gradienten ergibt: wenn die Entwicklungszeit verkürzt wird, so steigt die Schwierigkeit des Projektes dramatisch an Größenordnung der partiellen Ableitung von D nach t d hat bei den betrachteten Projekten einen Wert von 8 für völlig neue Systeme mit vielen Interaktionen mit anderen 29

31 Systemen, 15 für neue stand-alone Systeme, oder 27 für Systeme, die aus vorhandenen Komponenten erstellt werden (Manpower Build-up, maximale Zufuhr an Mitarbeitern) Beziehung mit dem Umfang S der Software in NCSS über die Software-Gleichung S = C k K 1/3 t 4/3 d (9) C k : Umgebungsfaktor, der den Stand der angewendeten Technologie ausdrückt Beispiel Grösse der Software wird mit LOC geschätzt, Umgebungsfaktor ist 900 Software soll in 3 Jahren einsatzbereit sein Software-Gleichung daher: = 900 K 1/3 3 4/3 Gesamtaufwand K ist daher 206 Mannjahre wenn die Software nun doch schon in 2 Jahren einsatzbereit sein soll, ergibt sich eine Software-Gleichung von = 900 K 1/3 2 4/3 und ein neuer Gesamtaufwand K von 1043 Mannjahren 30

32 Function Points eigentlich Metrik zur Quantifizierung der Größe eines Software- Systems erster Schritt: alle Komponenten des betrachteten Systems werden in eine von fünf Klassen eingeordnet und nach ihrer Komplexität mittels dreier Stufen gewichtet Klassen: externe Inputs externe Outputs logische interne Dateien externe Schnittstellendateien externe Abfragen anhand einer Tabelle der jeweiligen Gewichte und entsprechender Summierung: Unadjusted Function Points (UFP) Einfluß von 14 Charakteristiken (Anforderungen an das System wie verteilte Verarbeitung oder hohe Transaktionsrate, jeweils auf einer Skala von 0 bis 5 gewichtet): Aufsummierung zur Processing Complexity (PC) oder Technical Complexity Factor (TCF) Function Points (FP, Metrik für den notwendigen Aufwand zur Erstellung des Software-Systems und damit seine 31

33 Größe) F P = UF P ( (0.01 P C)) (10) Korrelation zu LOC und tatsächlichem Entwicklungsaufwand empirisch bestätigt für verschiedene Sprachen Umrechungsfaktoren von einem Function Point in die jeweils im Durchschnitt zur Implementierung notwendige Anzahl von LOC (z.b. C 128, C++ 55, PERL 27, Visual Basic 29, Assembler 320,...) Schätzung des Aufwandes: entweder Umrechnung in LOC und anderes Modell (COCOMO,...), oder direkte Beziehung FP zu Aufwand aus Vergangenheitsdaten (z.b. E = 54 F P oder ln E = 1.00 (ln F P ) , siehe Produktionsfunktionen) Beispiel Entwicklung einer neuen Anwendung an der WU für LV-Anmeldung und Verwaltung externe Inputs: 1 einfacher (Noten), 2 schwierige (Ankündigung und Anmeldung) = 1x3 + 2x6 = 15 externe Outputs: 1 schwieriger (VVZ), 2 mittlere (Notenund Anmeldeliste) = 1x7 + 2x5 = 17 logische interne Dateien: 1 schwierige (LV-Verzeichnis), 2 mittlere (Notenliste, Teilnehmerliste) = 1x15 + 2x10 = 35 32

34 externe Schnittstellendateien: 2 schwierige (zu VVZ im WWW und zu Noten-DB) = 2x10 = 20 externe Abfragen: keine UF P = = 87 besondere Auswirkungen durch Anforderungen: Performance 3, Datenkommunikation 2, Transaktionsrate 4, Online-Eingaben 5, End User Effizienz 5, Online- Update 5 P C = = 24 F P = 87 ( ( )) = = Aufwandsschätzung: z.b. über Formel ln E = 1.00 (ln 77.43) = oder Umrechung in LOC (Programmiersprache Java) LOC = F P 53 = = und dann in COCOMO einsetzen Vorteile: frühzeitige Quantifizierbarkeit im Entwicklungsprozeß, von Sprache und Technologie unabhängige Produktivitätsmessung Weiterentwicklungen: z.b. Symons (Function Point Mark II): Input-Datenelemente, Output-Datenelemente und referenzierte Entitäten aller Transaktionen 33

35 Nicht-algorithmische Verfahren nicht-algorithmische ( machine learning ) Methoden Neuronale Netze (sehr sensitiv auf Topologie-Entscheidungen wie Anzahl der Layers, wenig Erklärungswert) Entscheidungsbaum ( decision tree ) bzw. Regressionsbaum ( regression tree ): Klassifikation der Daten entlang der verschiedenen vorhandenen Dimensionen beziehungsweise Attributen, an jedem Blatt sind die Aufwandsdaten der jeweils entsprechend klassifizierten Projekte gespeichert Case-based Reasoning: analogie-basierte Schätzung, jeder erfaßte Fall anhand der vorhandenen Information charakterisiert, bei einem neuen Fall werden die ähnlichsten (z.b. Nearest Neighbor ) gesucht und Schätzung (z.b. gewichteter Mittelwert) aus diesen abgeleitet Fuzzy Logic: Variablen eines Schätzungsmodells meistens schwierig zu quantifizieren, daher Fuzzy Variablen mit Expertenregeln 34

36 FP 210 MM 155 MM 110 MM 145 MM 178 MM 145 MM LOC FP FP FP X X X LOC LOC LOC Abbildung 4: Analogie-basierte Schätzung 35

37 Einsatz in Organisationen, Datengewinnung und Validierung viele Modelle enthalten organisationsspezifische Koeffizienten: Kalibrierung notwendig Datenaufzeichnung über vergangene Projekte notwendig (Projektdatenbank) oft nicht vorhanden, nicht einheitlich erhoben (z.b. LOC) oder nicht alle Attribute vorhanden (z.b. Function Points) dann: Methoden wie Regressionsanalyse, Bayessche Analyse zur Kombination der vorliegenden Daten mit a priori Expertenwissen zu einem posteriori Modell oder andere Validierung: Prozeß, mit dem in einer gegebenen Umgebung die Genauigkeit des Systems durch empirische Mittel, das heißt durch den Vergleich des Verhaltens des Modells mit bekannten Datenpunkten, festgestellt wird Kalibrierung und Validierung nötig: vorhandene Projekte zufällig in zwei Gruppen teilen ( holdout sample ) oder jack-knifing (jeweils ein Fall aus der Datenbasis entfernt und unter Verwendung der verbleibenden anderen geschätzt) Kennzahlen: objektive Maßzahlen, um die Leistung verschiedener Modelle vergleichbar zu machen 36

38 E: tatsächlicher Aufwand eines Software-Projektes, Ê: geschätzter Aufwand relativer Fehler RE ( relative error ) RE = E Ê E (11) sowie durchschnittlicher relative Fehler RE (starke Überschätzungen durch starke Unterschätzungen über mehrere Projekte hinweg ausgeglichen) Größe des relativen Fehlers M RE ( magnitude of relative error ) E MRE = RE = Ê (12) E sowie durchschnittliche Größe des relativen Fehlers MRE (Überschätzungen werden mehr bestraft als Unterschätzungen) Anzahl der Voraussagen auf einem gewissen Niveau l, P RED(l) ( prediction at level l ), definiert mit P RED(l) = k n (13) bei k Projekten mit MRE l in einer Datenbasis von insgesamt n Projekten (P RED(0.25) = 0.83: 83 Prozent der vorhergesagten Werte in einem Bereich von 25 Prozent der tatsächlichen Werte) 37

39 Literatur Barry W. Boehm, Software Engineering Economics, Prentice- Hall, Englewood Cliffs, New Jersey, Barry W. Boehm et al., Software Cost Estimation with COCOMO II, Prentice Hall PTR, Upper Saddle River, New Jersey, L.H. Putnam, A General Empirical Solution to the Macro Software Sizing and Estimating Problem, IEEE Transactions on Software Engineering, 4(4): , July Bernard Londeix, Cost Estimation for Software Development, Addison-Wesley, Wokingham, England, Allan J. Albrecht and John E. Gaffney, Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation, IEEE Transactions on Software Engineering, 9(6): , November Chris F. Kemerer, An Empirical Validation of Software Cost Estimation Models, Communications of the ACM, 30(5): , May

40 Diplomprüfungsfragen Erläutern Sie, wie Sie unter Verwendung des COCOMO-Verfahrens eine Aufwandsschätzung für ein Software-Projekt vornehmen würden. Sie sind dabei der Projektleiter in einer Organisation, die bereits einige ähnliche Projekte durchgeführt hat. Geben Sie dabei bei jedem Schritt an, welche Informationen Sie benötigen, und woher Sie diese erhalten können. (SS 2001, 2. Termin, 5 Punkte) Geben Sie Arten und Aufgaben von Software-Metriken an. Beschreiben Sie die Metriken Anweisungszeilen (lines-of-code, LOC) und Function Point näher und stellen Sie diese gegenüber. (SS 2001, 1. Termin, 6 Punkte) Als Berater werden Sie eingeladen, bei einem Kunden die Function- Point-Methode vorzustellen. Beschreiben Sie kurz die Function- Point-Methode und ihre Rolle bei der Planung von Informationssystemen! (SS 2000, 1. Termin, 5 Punkte) Beschreiben Sie, wie Sie unter Verwendung des Function Point Verfahrens eine Aufwandsschätzung für ein neues Software-Projekt vornehmen können. Was sind Vor- und Nachteile dieses Verfahrens im Vergleich zu anderen Aufwandsschätzungsmethoden? (SS 2002, 2. Termin, 5 Punkte) Zu welcher Klasse von Software-Metriken gehören LOC (linesof-code, Programmzeilen)? Worauf muß man bei einer Definition dieser Metrik achten? Was kann man damit messen, was nicht? Wo sehen Sie sonstige Vor- und Nachteile der Verwendung von LOC? Wofür kann man diese Metrik verwenden? (WS 2002, 1. Termin, 5 Punkte) 39