Modul Einige Schätzmethoden

Präsentation zum Thema: "Modul Einige Schätzmethoden"—  Präsentation transkript:

1 Modul Einige Schätzmethoden

2 Empirische Schätzverfahren
Inhalt Empirische Schätzverfahren Expertenschätzung (1 Person) Expertenschätzung (mehrere Personen) Algorithmische Schätzverfahren COCOMO Function Point Methodik Data Point Methodik Bottom-up Methodik Vergleichsverfahren Analogiemethodik Relationenmethodik Bemerkung: Es wird hier keine vollständige Darstellung der Thematik angestrebt, sondern es werden einige Verfahren ausgewählt, die in der Praxis angewandt werden. „Methodik“ statt wie üblich „Methode“ wird benutzt, um darauf hinzuweisen, dass es sich jeweils nicht um eine Methode handelt, sondern dass viele Varianten existieren. Quellen:z. B. Litke, DV-Projektmanagement, Hanser Glinz, Software-Aufwandschätzung, Universität Zürich, Institut für Informatik

3 Expertenschätzung (1 Person)
Charakteristikum: „Expertenschätzung“ ist eine vornehme Bezeichnung für Schätzungen über den Daumen In der Regel wird aufgrund von Analogien zu bisher abgewickelten Projekten geschätzt Beurteilung: Einfach und billig Brauchbar, wenn Erfahrungen mit ähnlichen Projekten vorliegen Krasse Fehler möglich, wenn Erfahrungen fehlen oder Erfahrungen mit kleineren Projekten auf große extrapoliert werden

4 Expertenschätzung (mehrere Personen)
Charakteristika: systematische Befragung von mindestens zwei Experten, die aus Erfahrung Voraussagen über den Zeitbedarf einzelner Aktivitäten machen können Zwei Varianten: Standard Delphi Methode Befragung anonym Breitband Delphi Methode Schätzergebnisse werden gegenseitig bekannt gegeben, damit die Resultate diskutiert und ggf. korrigiert werden können

5 Standard Delphi Methode: Ablauf
1. Der Projektleiter schildert jedem Experten das Projektvorhaben und übergibt ihm ein Formular, auf dem die einzelnen Aufgabenpakete angeführt sind 2. Jeder Experte füllt das Formular aus; dabei dürfen Fragen lediglich mit dem Projektleiter besprochen werden 3. Der Projektleiter analysiert die Angaben. Falls Schätzwerte eines Paketes stark voneinander abweichen, werden diese mit Kommentar auf einem neuen Formular erfasst 4. Das neue Formular wird erneut zur selbstständigen Überarbeitung an die Experten gereicht 5. Die Schritte 2-4 werden solange wiederholt, bis die gewünschte Annäherung der Ergebnisse erreicht ist, oder der Projektleiter die Ergebnisse akzeptiert 6. Der Durchschnittswert der letzten Überarbeitung der Ergebnisse aller Aufgabenpakete stellt das endgültige Schätzergebnis dar

6 Breitband Delphi Methode: Ablauf
Schritte 1-3 wie beim Standardverfahren mit dem Zusatz, dass vor dem Ausfüllen der Formulare eine Sitzung einberufen wird, in der alle Experten unter der Moderation des Projektleiters über die zu erstellende Schätzung diskutieren 4 Der Projektleiter beruft eine Sitzung ein, in der die Teilnehmer über die zurück erhaltenen Formulare diskutieren 5. Die Experten überarbeiten ihre Ergebnisse selbstständig und übergeben diese dem Projektleiter 6. Die Schritte 2-5 werden solange wiederholt, bis die gewünschte Annäherung erreicht ist, oder bis der Projektleiter die Ergebnisse akzeptiert 7. Der Durchschnittswert der letzten Überarbeitung der Ergebnisse aller Aufgabenpakete stellt das endgültige Schätzergebnis dar

7 Beurteilung der Delphi Methode
Besser als die Expertenschätzung durch eine Person, da Ausreißer eliminiert werden Erheblich höherer Aufwand Bei der Breitband Delphi-Methode treten gruppendynamische Probleme auf (die „siegreichen Schätzungen und Argumente“ sind nicht immer unbedingt die richtigen, sondern die, die von den durchsetzungsfähigsten/ranghöchsten Mitgliedern stammen

8 Übung: Wie bewerten Sie diese Methoden?
Bitte bewerten Sie die Methoden auf einer Skala von --, -, 0, +, ++ anhand der früher festgelegten Kriterien EP SDM BDM Aufwand Genauigkeit Eindeutigkeit Flexibilität Frühzeitige Anwendbarkeit Benutzerfreundlichkeit Detaillierbarkeit Transparenz der Ergebnisse Stabilität Objektivität

9 Beispiel: Meine Bewertung
EP SDM BDM Aufwand ++ - -- Genauigkeit ? Eindeutigkeit Frühzeitige Anwendbarkeit Flexibilität Benutzerfreundlichkeit Detaillierbarkeit Transparenz der Ergebnisse Stabilität Objektivität +

10 Algorithmische Schätzverfahren
Charakteristika: Bestehen aus einem oder mehreren Algorithmen zur Berechnung einer Aufwands- bzw. Durchlaufzeitfunktion aus einer Reihe von Variablen. Die Genauigkeit der Prognosen hängt entscheidend von zwei Dingen ab: Die Eingangsgrößen der Aufwandsfunktion (z. B. bei COCOMO die Anzahl der Instruktionen) müssen hinreichend genau geschätzt werden. Das Modell muss kalibriert werden, d. h. der Wert der einzelnen Aufwandsattribute muss an die jeweilige Entwicklungsumgebung angepasst werden. Eine solche Kalibrierung ist nur möglich, wenn genügend Messwerte von durchgeführten Projekten vorliegen. Die Koeffizienten müssen permanent überprüft werden, um den technischen Fortschritt zu berücksichtigen. Bekannte Verfahren: COCOMO (COnstructive COst Model, B. Boehm 1981) Function Point Methodik (A. Albrecht ) Data Point Methodik (H. Sneed, 1987) Bottom-up Methodik (diverse)

11 COCOMO Charakteristika:
Grundlage der Aufwandsschätzung ist die Produktgröße. Die Produktgröße wird in KDSI (Kilo lines of delivered source instructions) gemessen. Source = Programminstruktionen, die vom Projektpersonal erzeugt werden (nicht gezählt werden z. B. Kommentare, eingesetzte Utility Software, wohl aber Formatanweisungen und Datendeklarationen) Aus diesem Grundwert und einer Reihe von Multiplikationsfaktoren werden Aufwand und Projektlaufzeit ermittelt. Im Aufwand enthalten ist die Entwicklungstätigkeit ab Beginn des Programmentwurfs bis zum Ende der Test- und Integrationsphase. Nicht enthalten ist der Aufwand für Projektvorbereitung, Projektplanung und Anforderungsdefinition sowie der Aufwand für die Einführung (Transition). Ursprüngliche Version COCOMO 1981, inzwischen COCOMO II (1998) Details s. Literatur und

12 Grundgleichungen (1) COCOMO unterscheidet zunächst zwischen drei Umgebungsstrukturen Organic (unabhängig) Relativ kleine Teams in vertrauter Umgebung Stabile Entwicklungsumgebung, wenige Änderungen an der HW-/SW-Umgebung Geringer Zwang zu neuartigen Verfahrens-/Modulstrukturen Geringer Zeitdruck Embedded (abhängig eingebettet) Entwicklung unterliegt starken Restriktionen Systemumgebung verändert sich stark Hoher Termindruck Semidetached (halb unabhängig) Alles, was zwischen Organic und Embedded liegt

13 Grundgleichungen (2) Organic
Aufwand = 2,4 KDSI1, Zeit = 2,5 Aufwand 0,38 Semidetached Aufwand = 3,0 KDSI1,12 Zeit = 2,5 Aufwand0,35 Embedded Aufwand = 3,6 KDSI1,2 Zeit = 2,5 Aufwand0,32 KDSI = Kilo delivered source instructions (1000 ausgeführte Befehle)

14 Verbesserung der Schätzung durch Kostenfaktoren

15 Präzisierung der Schätzung
1. Bestimmung des Nominalwerts für den Aufwand 2. Bestimmung der Kostenfaktoren 3. Multiplikation des Nominalaufwands mit dem Produkt der Kostenfaktoren Aufwand Korr = Produkt der Kostenfaktoren x Aufwand Nominal Damit ergibt sich ein Wert für den Gesamtaufwand. Dieser muss jetzt noch auf die einzelnen Phasen bzw. Aktivitäten herunter gebrochen werden. Dabei wird mit folgenden Ansätzen für die Aufwandsverteilung gearbeitet (s. Folgefolien).

16 Aufwandsverteilung für Wasserfallmodell-basierte Entwicklungen
Phase Durch COCOMO abgedeckt Aufwand Zeit Planung&Anforde-rungsspezifikation nein 7% (Bandbreite 2% - 15%) Typisch 16% - 24% (Bandbreite 2% - 30%) Design ja 17% Bandbreite 24% - 28% Programmierung Bandbreite 52% - 64% Bandbreite 40% - 56% Integration&Test Bandbreite 19% - 31% Bandbreite 20% - 32% Einführung 12% (Bandbreite 0% - 20%) 12,5% Total % typisch 128,5% - 136,5% Bandbreite 102% - 135% Bandbreite 102% - 150% Quelle:

17 Aufwandsverteilung für MBASE-basierte Entwicklung
Phase Durch COCOMO abgedeckt Aufwand % des durch COCOMO II geschätzten Werts Zeit Inception (Vorstudie und Anforderungsanalyse) nein 6% Bandbreite 2% - 15% 12,5% Bandbreite 2% - 30% Elaboration (Grobdesign und Komponentenbildung) ja 24% Bandbreite 20% - 28% 37,5% Bandbreite 24% - 28% Construction (Iterative inkrementelle Entwicklung) 76% Bandbreite 72% - 80% 62,5% Bandbreite 58% - 67% Transition (Systemtest und –einführung) 12% Bandbreite 0% - 20% Total 118% Bandbreite102% - 135% 125% Bandbreite 102% - 150% MBASE = Model based Architecture&Software Enginering (B. Boehm), s.

18 Aufwandsverteilung für RUP-basierte Entwicklung
Phase Durch COCOMO abgedeckt Aufwand % des durch COCOMO II geschätzten Werts Zeit Inception (Vorstudie und Anforderungsanalyse) nein 5% 10% Elaboration (Grobdesign und Komponentenbildung) ja 20% 30% Construction (Iterative inkrementelle Entwicklung) 65% 50% Transition (Systemtest und –einführung) Total 100% RUP = Rational Unified Process, Vorgehensmodell der Fa. Rational Quelle

19 Rechenbeispiel für ein „organic“ Projekt
Eine Ausgangsstudie hat ergeben, dass der Programmumfang ca auszuführende Source-Befehle (32 KSDI) betragen wird (damit haben wir die Hauptproblematik elegant umschifft!). Dann ergeben sich folgende Werte Aufwand = 2,4 32 1,05 = 91, Mann-Monate Zeit = 2,5 91 0,38 = 13, Monate Da ein Mitarbeiter (je nach Kalkulationsansatz) im Jahr etwa 10 MM an produktiver Arbeit leisten kann, d. h. in 14 Monaten 11,7 MM, ergibt sich ein Personalbedarf von 91/11,7 = 7,8 oder aufgerundet von rund 8 Mitarbeitern.

20 Beurteilung von COCOMO
COCOMO liefert z. T. recht gute Werte. Der Hauptnachteil ist die Notwendigkeit, die KDSI am Projektbeginn zu schätzen. Entweder muss der Schätzer eine große Erfahrung mit ähnlichen Systemen haben, oder er verfügt über eine Wissensdatenbank mit Zahlen über vergleichbare Projekte. Die Anzahl der KDSI hängt nicht nur von der Programmiersprache, sondern auch vom Programmierstil ab. Gut ist die Berücksichtigung der Qualitätsziele und der Produktivitätsfaktoren. Facit: Die COCOMO Methode ist auf einem Maß (KDSI) aufgebaut, dass schwer zu schätzen und problematisch zu berechnen ist. Deshalb ist die Methode – trotz ihrer weiten Verbreitung insbesondere in der USA – selbst in Zweifel zu ziehen. Aufwand ++ Genauigkeit 0/+ Eindeutigkeit Flexibilität Frühzeitige Anwendung +* Benutzerfreundlichkeit Detaillierbarkeit -- Transparenz Stabilität --* Objektivität * Steht und fällt mit der Eingangsschätzung

21 Die Function Point Methodik
Charakteristika: Das Konzept des Functional Size Measurement wurde erstmalig von Allan Albrecht, IBM, in der zweiten Hälfte der 70iger Jahre entwickelt. Es basiert darauf, den Umfang eines Softwaresystems nicht dadurch zu messen, wie die Software implementiert wurde (Lines of Code) sondern aufgrund der funktionalen Anforderungen des Anwenders. Es gibt inzwischen verschiedene Varianten einer Function Point Methodik. Insofern sind auch Produktivitätsangaben in der Literatur, die in Function Points gemacht werden, nicht unbedingt vergleichbar. Die IFPUG (International Function Points User Group) bemüht sich um Standardisierung. Varianten der Function Point Methodik sind weltweit die in der Praxis am häufigsten eingesetzten algorithmischen Methoden zur Aufwandschätzung. Grundsätzlich können Varianten der Function Point Methodik nicht nur für kommerzielle Systeme, sondern auch für wissenschaftliche bzw. Real-Time Systeme angewandt werden. Ebenfalls gilt das für objektorientierte Entwicklungen.

22 Kategorien der Function Point-Methodik (IFPUG)
Die Function Point-Methodik geht davon aus, dass der Aufwand zur Erstellung eines neuen Produktes vom Umfang und vom Schwierigkeitsgrad des Produktes abhängt. Jede Produktanforderung wird einer von fünf Kategorien zugeordnet: Diese werden in drei Niveaus der Komplexität (der Informationsverarbeitung) eingeteilt: niedrig, durchschnittlich, hoch. Dabei erhält jedes Niveau eine bestimmte Anzahl Function Points. Externe Inputs Interne Dateien Funktion Externe Abfragen Externe Schnittstellen Externe Outputs

23 Prinzipielle Vorgehensweise
1. Quantifizierung des Projektumfanges nach Komponenten (Functions) 2. Bewertung des Schwierigkeitsgrades je Funktion durch Points 3. Addition der Function Points für alle auftretenden Geschäftsvorfälle 4. Adjustierung des Function Point Roh-Werts durch Betrachtung von insgesamt 14 Einflussfaktoren 4. Berechnung der bewerteten Function Points 5. Ermittlung des Aufwandes aus einer Produktivitätstabelle, die im Idealfall mittels historischer Daten gewonnen wurde

24 Zusammenhang der Bausteine
Einflussfaktoren, wie z. B. zentrale oder dezentrale Verarbeitung Verflechtung mit anderen Anwendungen komplexe Arithmetik Mitarbeiter-Erfahrung Anzahl der Eingaben Abfragen Pflege von Datenbeständen Zugriffe zu Referenzdaten Ausgaben mit jeweils unterschied- licher Komplexität Function- Point- Methodik Ergebnis in MM (Personenmonate) für den gesamten Entwicklungsprozess Produktivitätstabelle in der firmenspezifische Erfahrungswerte niedergelegt sind

25 Externer Input Dateneingaben können z. B. sein:
Zu zählen ist jeder externe Input, der in der IS-Anwendung verarbeitet wird, sofern er unterschiedliches Format oder eine unterschiedliche Verarbeitungslogik hat. Dateneingaben können z. B. sein: Bildschirmeingaben, Eingaben über Diskette/CD, Interfacedaten von anderen Anwendungen, Datenbestände, die vollständig sequentiell abgearbeitet werden Belegleser-Eingaben usw. Transaktionen wie Hinzufügen, Löschen und Ändern werden einzeln als unterschiedliche Eingaben gezählt, da sie unterschiedlich verarbeitet werden, auch wenn sie über das gleiche Bildschirmformat eingegeben werden. Wenn bei einer Online Anwendung eine Ausgabe gleichzeitig als Eingabe verwendet wird, darf dies nur einmal, und zwar bei den Ausgabedaten gezählt werden. Unterschiedliche Benutzermenüs (nicht vom System generiert) mit Selektionsmöglichkeiten zählen je als eine Eingabe Abfragen mit vielen Verarbeitungsschritten, Zugriff auf mehrere Dateien, evtl Zwischenverarbeitung mit Speicherung und/oder Sortierung zählen nicht als externe Abfragen, sondern als externe Inputs und als externe Outputs.

26 Beispiele für unterschiedliche Bewertungsansätze bei den Eingaben
Litke (1996) einfach mittel komplex Anzahl unterschiedlicher Datenelemente 1 - 5 6 - 10 > 10 Eingabeprüfung formal logisch Zugriff auf DB Anspruch an Bedienerführung gering normal hoch IFPUG (1994) Anzahl unterscheidbarer Datenelemente in der Eingabe Anzahl bearbeiteter Datenbestände 1 - 4 5 - 15 > 15 0 - 1 einfach mittel 2 komplex > 2

27 Externer Output Datenausgaben können z. B. sein:
Zu zählen ist jeder externe Output, der in der IS-Anwendung erstellt wird. Datenausgaben können z. B. sein: Bildschirmausgaben Wenn sie aus einem unterschiedlichen Verarbeitungsteil kommen Wenn sie ein unterschiedliches Format haben Interface-Daten an andere Anwendungen, wenn sie aus einem unterschiedlichen Verarbeitungsteil kommen Berichte in Listenform oder Formularen Druckausgabe dezentral Ausgaben auf Micro-Fiche, wenn sie ein unterschiedliches Format haben Wenn bei einer Online Anwendung eine Ausgabe gleichzeitig als Eingabe verwendet wird, darf dies nur einmal gezählt werden und zwar bei Ausgabedaten Fehlernachrichten, die aufgrund formaler und logischer Prüfungen ausgegeben werden und Bedienernachrichten sowie Bestätigungsscreens werden pro Dialog nur einmal als Output gezählt. Eine Fehlerliste wird pro unterschiedliche Listenform als ein Output gezählt.

28 Bewertung der Ausgaben
Bei der Bewertung der Ausgaben wird die Technik der Ausgabe nicht berücksichtigt Für die Gewichtung der logischen Ausgaben sind folgende Kriterien heranzuziehen: Anzahl unterscheidbarer Datenelemente in der Ausgabe Anzahl bearbeiteter Datenbestände 1 - 5 6 - 19 > 19 0 - 1 einfach mittel 2 komplex > 2

29 Interne Datenbestände
Zu zählen ist jeder Datenbestand, der von der IS-Anwendung gepflegt (update) und/oder betreut (Security, Recovery) wird. Datenbestände werden in der Function-Point-Analyse immer aus der Sicht des Anwenders betrachtet. Die Art der technischen Realisierung wird nicht berücksichtigt. Logische, interne Datenbestände (z. B. Kunde, Auftrag, Rechnung ) Logische, externe Datenbestände ( nur lesend benutzt, z. B. zentrale Adressdatei ) Die logischen internen und externen Datenbestände können über das Datenmodell mit seinen Entitytypen ermittelt und dokumentiert werden. Die Einteilung in logische Datengruppen geschieht nach organisatorischen – nicht nach DV-technischen – Gesichtspunkten ( Zwischendateien, Sort-Dateien, technische Hilfsdateien usw. werden nicht gezählt ).

30 Bewertung interner Datenbestände
Bei der Bewertung der Ausgaben wird die Technik der Ausgabe nicht berücksichtigt Für die Gewichtung der logischen Ausgaben sind folgende Kriterien heranzuziehen: Anzahl unterscheidbarer Datenelemente in der Datei Anzahl bearbeiteter Datenbestände (Fremdschlüssel) 1 - 19 > 50 0 - 1 einfach mittel 2 - 5 komplex > 5

31 Bewertung der Abfragen
Zu zählen ist jede Abfrage, die zu einem Suchen nach Informationen in einem Datenbestand führt und bei der das Ergebnis dem Benutzer sichtbar gemacht wird. Gezählt wird jeweils jede unterschiedlich formatierte Online-Eingabe. Abfragen bestehen immer aus einem Aufrufen und Anzeigen, d.h. es handelt sich grundsätzlich um eine Eingabe mit einer anschließenden Ausgabe. Abfragen bewirken keine Veränderung der Datenbestände. Zur Bewertung der Abfragen sind zunächst die Function Points für die Ein- und Ausgabenteile getrennt zu ermitteln. Der größere Wert wird dann zur Bewertung der Abfrage genommen.

32 Externe Datenbestände
Zu zählen ist jeweils jede Datei, die in der IS-Anwendung als Informationsträger benötigt wird, z. B. Tabellen, Read-Only-Dateien. Read-Only-Dateien werden nicht komplett verarbeitet, sondern dienen zur Bereitstellung von Zusatzinformationen (z. B. Schlüssel-, Stammdaten). Nicht zu zählen sind Tabellen, die lediglich aus IS-technischen Gründen benötigt werden und die nicht vom Benutzer gepflegt werden.

33 Bewertung externer Datenbestände
Für die Gewichtung der externen Datenbestände sind folgende Kriterien heranzuziehen: Anzahl unterscheidbarer Datenelemente in der Datei Anzahl bearbeiteter Datenbestände (Fremdschlüssel) 1 - 19 > 50 0 - 1 einfach mittel 2 - 5 komplex > 5

34 Schema zur Berechnung des Function Point Roh-Werts (IFPUG 1994)
Schwierigkeitsgrad Element einfach mittel komplex Summe Dateneingaben ___ x 3 = ___ ___ x 4 = ___ ___ x 6 = ___ ____ Datenausgaben ___ x 5 = ___ ___ x 7 = ___ Anfragen Ext. Schnittstellen ___ x 10 = ___ Int. Datenbestände ___ x 15 = ___ Function Point Roh-Wert (UFP) UFP = Unadjusted Funktion Points = Function Point Roh-Wert

35 Grundsätzliches zu den Einflussfaktoren
Projektspezifische Einflussfaktoren (Summe = VAF = Value Adjustment Factor) sind Anforderungen an das System, durch die sich das zu bewertende Projekt vom allgemeinen Standard unterscheidet ! Es ist streng darauf zu achten, dass die gesamte Anwendung betrachtet wird. Die Einflussfaktoren können den Function Point-Wert und damit den Projektaufwand um +/- 30% verändern. Die Bewertung geschieht im Allgemeinen nach folgender Skala: kein Einfluss = 0 unbedeutender Einfluss = 1 mäßiger Einfluss = 2 mittlerer Einfluss = 3 erheblicher Einfluss = 4 starker Einfluss = 5 Von der Konstruktion des Maßes her, müsste eigentlich VAF = 1 gelten, wenn alle Faktoren durchschnittlichen Einfluss haben. Das wäre der Fall, wenn durchschnittlicher Einfluss mit dem Faktor 2,5 bewertet würde. Aus Praktikabilitätsgründen hat man sich aber für den Wert 3 entschieden, was dazu führt, dass VAF bei lauter durchschnittlichen Einflüssen den Wert 1,07 hat.

36 Schema zur Bestimmung der Einflussfaktoren (IFPUG 1994)
Nr. Faktor Wert 1 Datenkommunikation 2 Verteilte Funktionen 3 Leistungsanforderungen 4 Belastung der Hardware 5 Verlangte Transaktionsrate 6 Online-Dateneingabe 7 Effiziente Benutzerschnittstelle 8 Online-Datenänderungen 9 Komplexe Verarbeitungen 10 Wiederverwendbarkeit 11 Einfache Installation 12 Einfache Benutzbarkeit 13 Installation an mehreren Orten 14 Änder- und Erweiterbarkeit Summe der Faktoren (TDI = Total Degree of Influence)

37 Berechnung des Function Point Werts
Es gelten folgende Formeln: Der Wertkorrekturfaktor (VAF) berechnet sich nach der Formel VAF = 0,65 + 0,01 x TDI Die Formel ist so konstruiert, dass VAF in einem Bereich zwischen 0,65 und 1,35 liegt. Die Function Points des Systems berechnen sich dann zu FP = UFP x VAF

38 Umsetzung Function Points in Personenmonate
FP PM FP/PM 471 25 18,84 Der Function-Point-Wert für eine IS-Anwendung ist eine Kennzahl, aus der die IS-Entwicklungs- Mannmonate für ein IS-Projekt abgeleitet werden. Hierzu wird eine Function-Point-Kurve mit ( am besten eigenen ) Erfahrungswerten herangezogen. Die nebenstehende Tabelle wurde gewonnen, indem durch Nachkalkulation verschiedene implementierte IS-Anwendungen mit Function Points bewertet wurden (IBM 1990) Eine Übertragung auf andere Organisationen ist nur bedingt möglich. 550 30 18,33 628 35 17,94 706 40 17,65 782 45 17,38 857 50 17,14 932 55 16,95 1005 60 16,75 1078 65 16,58 1149 70 16,41 1220 75 16,27 1290 80 16,13 1359 85 15,99 1426 90 15,84 1453 95 15,29 1559 100 15,59 1625 105 15,48 1689 110 15,35 1752 115 15,23 1814 120 15,12 1875 125 15,00 1936 130 14,89 1995 135 14,78 2588 190 13,62 3029 240 12,62 3434 300 11,45

39 Function Point-Werte-Paare: Beispiele IBM (1985) und VW (1991)
Function Point IBM-PM VW-PM 50 2,3 - ,6 - ,5 - ,9 11,7 ,6 19,3 ,6 27,1 ,9 35 ,4 43 ,1 51,1 ,1 59,6 ,2 68,2 ,5 77 ,1 ,6 95,3 ,4 104,8 ,3 114,6 ,4 124,7 ,6 135,2 Quelle: H. Balzert, Lehrbuch der Software Technik, Spektrum 1996

40 Durchlaufzeit [in Monaten] = FP 0,4 Anzahl Mitarbeiter = FP/150
Faustregeln von Jones Durchlaufzeit [in Monaten] = FP 0,4 Anzahl Mitarbeiter = FP/150 Aufwand = Durchlaufzeit x Anzahl Mitarbeiter = FP 0,4 x FP/150 Quelle: Jones, T. C., Software Estimating Rules of Thumb, IEEE Computer 29, 1996

41 Umrechnung von Function Points in Code-Zeilen
Die Anzahl der Code-Zeilen pro Function Point ist stark abhängig von der benutzten Programmiersprache (Leer- Zeilen und Kommentare werden nicht gezählt). Die folgende Tabelle ist ein Auszug einer Tabelle der Fa. QSM = Quantitative Software Management, Inc. Vom July 2002. Sprache Durchschnitt Median Intervall unt. Grenze Intervall ob. Grenze Access 35 38 15 47 ADA 154 104 205 Assembler 337 315 91 694 C++ 66 53 29 178 Cobol 77 14 400 Advantage:Gen 31 10 180 Excel 46 63 Java 62 Powerbuilder 32 11 105 Smalltalk 26 19 55 Visual Basic 42 16 158

42 Weiterentwicklung der Function Point Methodik
Die Function Point Methodik wird aktiv weiter entwickelt. Der zur Zeit fortschrittlichste Ansatz ist das COSMIC Projekt (Common Software Measurement International Consortium).

43 Wozu lässt sich die Function Point Methodik verwenden?
Quelle: Come Back Function Point Analysis (Modernized) – All Is Forgiven, Charles Symons , Software Measurement Services, Ltd. 2001

44 Merkmale der Function Point-Methodik
frühzeitig, genauer: nach der Anforderungsanalyse einsetzbar später im Projektverlauf iterativ einsetzbar die Ergebnisse sind erklärbar und nachvollziehbar Für die Bewertung wird die Gesamtheit der Anforderungen herangezogen, eine Gliederung ist nicht erforderlich Da die FP Methodik auf den geschäftlichen Anforderungen basiert, ist die Berechnung der Function Points unabhängig davon, ob sich die Technologie ändert (nicht jedoch die Übersetzung der FP in Aufwand!). Diese Aussage liest man immer wieder, leider stimmt sie aber nicht! Die Bewertung der Komponenten und Einflussfaktoren sowie die Übersetzung in Aufwandszahlen enthält viele subjektive Entscheidungen, unterschiedliche Gruppen werden deshalb zu unterschiedlichen Ergebnissen für dasselbe Projekt kommen

45 Vorteile der Function Point-Methodik
Ausgangspunkt sind Produktanforderungen, nicht LOC Anpassbar an verschiedene Anwendungsbereiche (Änderung der Kategorie) Anpassbar an neue Techniken (Änderung der Einflussfaktoren und der Einflussbewertung) Anpassbar an unternehmensspezifische Verhältnisse (Änderung der Einflussfaktoren und der Einflussbewertung) Verfeinerung der Schätzung entsprechend dem Entwicklungsfortschritt (iterative Methode), z. B. erste Schätzung auf der Grundlage des Lastenheftes zweite Schätzung auf der Grundlage des Pflichtenheftes dritte Schätzung nach Erstellung des formalen Modells Erste (grobe) Schätzung bereits zu einem frühen Zeitpunkt möglich (Vorstudie). Dies erfordert jedoch viele Annahmen, die bei weiterer Detaillierung der Analyse überprüft bzw. berichtigt werden müssen. Festgelegte methodische Schritte Relativ leicht erlernbar Benötigt nur relativ geringen Zeitaufwand (Werkzeugunterstützung sinnvoll) Gute Transparenz Brauchbare bis gute Schätzgenauigkeit Werkzeugunterstützungen verfügbar

46 Nachteile der Function-Point-Methodik
Es kann nur der Gesamtaufwand geschätzt werden. Eine Umrechnung auf einzelne Phasen muss mit der Prozentsatzmethode erfolgen. Der mittlere Aufwand pro Function Point muss bekannt sein Umrechnungsfaktoren müssen unternehmensspezifisch kalibriert und projektspezifisch angepasst werden Umrechnungstabellen und Faustregeln sind mit Vorsicht anzuwenden! Stark funktionsbezogen (neuere Versionen berücksichtigen mehr die Daten bzw. Objekte) Qualitätsanforderungen werden nicht berücksichtigt Mischung von Produkt- und Projekteigenschaften bei den Einflussfaktoren

47 Data-Point-Methode Charakteristika:
Ist eine Antwort auf den Trend zur daten- bzw. objektbezogenen Systementwicklung: die Größe der Software wird an den betroffenen Objekten und der Summe der darin enthaltenen Datenelemente gemessen. Voraussetzung ist eine Liste sämtlicher Entitytypen und Nachrichten. Es gibt mehrere Varianten, z. B. von Harry Sneed 1991 Nach der Ermittlung des Aufwandes in Data Points lässt sich dieser - ebenso wie bei der Function Point Methode - aufgrund einer firmenspezifischen Produktivitätstabelle in Personenmonate umrechnen

48 Objekte Entitytypen Nachrichten
Logische Sätze und Tabellen einer Ziel-Datenbank, auf die das System zugreifen muss ergeben sich aus der Datenanalyse. Nachrichten Bildschirmmasken, Reports, Datenübergaben an andere Systeme ergeben sich aus der Prozess- oder Kommunikationsanalyse.

49 Methodenschritte Entitytypen erfassen und bewerten Nachrichten erfassen und bewerten Data-Points errechnen Qualitätsfaktor ermitteln Projektumgebungsfaktor ermitteln Data-Points mit dem Qualitätsfaktor multiplizieren Ergebnis mit dem Projektumgebungsfaktor bewerten Anzahl Data-Points gegen die Produktivitätstabelle spiegeln und Aufwand zuordnen

50 Errechnung der Data-Points für Entitytypen
1 Data-Point pro Attribut 4 Data-Points pro Schlüssel Integrationsgrad niedrig 2 DP mittel 4 DP hoch 8 DP Nutzung Bei zu schreibenden Objekten die Summe der bisher ermittelten Data- Points um 10 % erhöhen. Änderung Angabe eines %-Satzes, der den Änderungsaufwand des Objektes darstellt (bei neuen Objekten = 100 %). Data-Points-Ergebnis Die Summe der ermittelten Data-Points wird mit dem in der Spalte „Änderung in %“ festgehaltenen Prozentsatz multipliziert, z.B. 30 % von 130 Data-Points = 39 Data-Points.

51 Data Points für Entity Typen: Beispiel einer Berechnungstabelle

52 Errechnung der Data-Points bei Nachrichten
1 Data-Point pro Feld 4 Data-Points pro Sicht (Anzahl der angesprochenen Informationsentitäten) Komplexitätsgrad niedrig +2 DP mittel +4 DP hoch DP Nutzung Bei Eingabenachrichten die Summe der bisher ermittelten Data-Points um 10 % erhöhen. Änderung Angabe eines %-Satzes, der den Änderungsaufwand des Objektes darstellt (bei neuen Objekten = 100 %). Data-Points-Ergebnis Die Summe der ermittelten Data-Points wird mit dem in der Spalte „Änderung in %“ festgehaltenen Prozentsatz multipliziert, z.B. 30 % von 130 Data-Points = 39 Data-Points.

53 Data Points für Nachrichten: Beispiel einer Berechnungstabelle

54 Bewertung der Qualitätsanforderungen
In diesem Schritt wird die Summe der Data Points mit dem Qualitätsfaktor multipliziert. Qualitätsmerkmale: Zuverlässigkeit Sicherheit Effizienz Datenunabhängigkeit Benutzerfreundlichkeit Übertragbarkeit Integrität Wartbarkeit Der Qualitätsfaktor ist eine Zahl von 0,5 bei der niedrigsten Qualität bis 1,5 bei der höchsten Qualität. Die Data Points können abhängig von den Qualitätsanforderungen um 50 % erhöht oder reduziert werden.

55 Bewertung der Einflussfaktoren (1)
Die sich ergebenden Data-Points werden mit einem Einflussfaktor (Projektumgebung) multipliziert. Die Data Point Methode kennt 10 Einflussfaktoren:: Einflussfaktor 1 2 3 4 5 Projektverteilung mehrere mehrere Orte ein Ort mehrere ein Raum Länder Räume Projekterfahrung keine mäßig mittel gut sehr gut Projektkenntnisse keine mäßig mittel gut sehr gut Projektautomation keine teilweise halb überwiegend voll Rechenbedingungen schlecht mäßig mittel gut sehr gut Projektunterstützung keine wenig mittel gut sehr gut Qualitätssicherung keine teilweise halb überwiegend voll automatisch automatisch automatisch automatisch Spezifikationsformalismen informal strukturiert semiformal formal formal- grafisch Programmiersprache 1.Generation 2.Generation 3.Generation 4.Generation 5.Generation Testautomation keine 25% 50% 75% 100% Summe 10 20 30 40 50

56 Bewertung der Einflussfaktoren (2)
Jeder Faktor wird auf einer Skala von bewertet. Die Summe der 10 Einflussfaktoren (Minimum 10, Maximum 50) wird von 125 subtrahiert und durch 100 dividiert. Beispiel: Eine Durchschnittsbewertung von 3 für alle Einflussfaktoren ergibt einen Gesamt-Einflussfaktor von / 100 = 0,95. Der Gesamt-Einflussfaktor wird mit der schon durch die Qualität gewichteten Data-Point-Anzahl multipliziert, um die endgültige Data-Point-Zahl zu erreichen Gesamtaufwand = Summe Data Points*Q-Faktor*Einflussfaktor. Mit diesem Wert wird der Aufwand in PM aus der Produktivitätstabelle abgeleitet.

57 Beispiel einer Produktivitätstabelle
Data Points PM 80 2 In dieser Produktivitätstabelle entspricht einem Data-Point ein Wert zwischen 0,5 und 1,0 PT (Personentagen), abhängig von der Projektgröße. Die Werte sind stark abhängig von der jeweiligen Umgebung und können deshalb nur bedingt ungeprüft übernommen werden. Der Aufbau von eigenen Erfahrungswerten muss angestrebt werden. 160 4 240 6 320 8 : : 800 20 880 23 960 26 1040 29 1120 32 1200 35 1280 38 1360 41 1440 44 1520 47 1600 50 : : 2000 70 2080 74 2160 78 2240 82 2320 86 2400 90 : : Quelle: H.D. Litke, DV-Projektmanagement, Zeit und Kosten richtig einschäötzen, Hanser 1996

58 Bottom-up-Methodik - Beispiel
Charakteristika: Klasse: Algorithmische Methoden Algorithmen zur Ermittlung von Schätzwerten auf der Basis von Eingangsgrößen Die Gesamtaufgabe ist in Aktivitäten zergliedert, z. B. nach Method/1(kommerzielles Vorgehensmodell), ASAP (Accelerated SAP) oder PSP/WBS (Projektstrukturplan = Work Breakdown Structure z. B. nach dem Vorgehensmodell PRO-IV) Die Kalkulation einer repräsentativen Stichprobe dient als Basis für die Hochrechnung der Gesamtkosten oder alle Teilaufgaben werden getrennt bewertet und anschließend kumuliert

59 Einflussfaktoren Externe Faktoren Schätzung Faktor-Anzahl
Schätzfaktoren Schätzung Faktor-Anzahl Lernkurve

60 Schätzprozess Tailoring des Vor- gehens- modells
Beurteilungsvermögen Erfahrung Schätzmodell Schätzfaktoren Festlegen System- Komplexität Einschätzen externer Faktoren Festlegen Faktor- Werte Aktivitäten- aufwand Projekt-Inflatoren/-Deflatoren Projektnotfallplanungen Basisaufwand Verfeinern Schätzung

61 Tailoring des Vorgehensmodells - Beispielausschnitt
Welches Kriterium trifft für das Projekt zu (markiere J oder N)? Z = abhängige Aktivität B = Muss-Aktivität G = grob durchzuführende Aktivität K = keine Aktivität Wenig erfahrenes Personal Geschäftsprozess-Änderung Technische Innovation Verteiltes System Neue Datenbank Großes Team Lange Laufzeit Viele Benutzer Erhöhtes Risiko J/N ? J/N ? J/N ? J/N ? J/N ? J/N ? J/N ? J/N ? J/N ? Arbeitspaket / Aktivität Design Anwendungs-Architektur B B B B B B B B B Definieren Anwendungs-Architektur G G G G Z G Z Z G Verteilen Daten und Prozesse im Netzwerk B B B B B B B B B Definieren Verarbeitungsfluss G Z G G Z G Z Z Z Entwickeln Assembly-Test-Verfahren Design User-Interface B B B B B B B B B Design und Evaluierung Dialoge B B B B B B B B B Design und Evaluierung Formulare und Reports B B B B B B B B B Design und Evaluierung User-Support K K K Z K Z K G K Durchführen Detail-Usability-Evaluation

62 Generelle Systemkomplexität
System-Charakteristik Einfach 0,9 Mittel 1,0 Komplex 1,2 Bewertung Anzahl Elemente in der Datenbank > 500 Anzahl komplexer Rechenoperationen 0 - 10 > 25 Level an Background-/asynchroner Verarbeitung Klein mäßig signifikant Schnittstellen zu anderen Applikationen Wenige Einweg Wenige Zweiweg Viele Zweiweg Anzahl von wesentlichen Reports 5 - 10 > 30 Anzahl von Produktionsstandorten 1 2 - 3 > 3 Anzahl von Tiers 2 > 2 Entwicklungs-Architektur Existiert und ist Standard Existiert und ist customized neu Ausführungs-Architektur System-Auswirkungen auf die Organisation Minimal Wesentlich kritisch Auswirkungen auf den Systembetrieb wesentlich Durchschnitt = _________

63 Systemkomplexität für C/S-Systeme
System-Charakteriistik Einfach 0,9 Mittel 1,0 Komplex 1,2 Bewertung Anzahl Windows 0 - 20 > 50 Anzahl der Dialoge 0 - 5 6 - 15 > 15 GUI Style Form-Filled Text Grafisch Daten-Verteilungs-Strategie Keine Verteilung Eine DB Partitioniert Redundant Prozess-Verteilungs-Strategie Remote Präsentation Remote Server Voll kooperativ Durchschnitt = _________

64 Systemkomplexität für Host-Systeme
System-Charakteristik Einfach 0,9 Mittel 1,0 Komplex 1,2 Bewertung Anzahl Masken 0 - 25 > 75 Anzahl der Dialoge 0 - 10 > 25 Durchschnitt = _________

65 Systemkomplexität für Kaufsoftware
System-Charakteristik Einfach 0,9 Mittel 1,0 Komplex 1,2 Bewertung Anzahl der Kandidaten 1 2 - 3 > 3 Anzahl der einzuschätzenden Plattformen 2 > 2 Multi-nationale Anforderungen Keine Fremdsprache Eine Fremdsprache Mehr als eine Fremdsprache Menge an Paket-Optionen Wenige Einige Viele Erforderliche Paket-Programm-Modifikationen Keine/Standard Minimale Modifikationen Wesentliche Änderungen Durchschnitt = _________

66 Zusammenfassung: Systemkomplexität
Die durchschnittliche Systemkomplexität ergibt sich durch Mittelbildung Systemkomplexität = ¼(durchschnittliche allgemeine Systemkomplexität + durchschnittliche Client-Server Systemkomplexität + durchschnittliche Host-Systemkomplexität + durchschnittliche Kauf-Softwarekomplexität) Anmerkung: Falls einer der Faktoren nicht zutrifft (z. B. wenn keine Kauf- Software vorhanden ist), wird der entsprechende Faktor auf 1 gesetzt.

67 Vier Ansätze zur Schätzung
Faktoranzahl x Produktivitätsrate Z. B. könnte in der Aktivität „Design Reports“ als Schätzfaktor „Anzahl der Report“ definiert sein und als Produktivitätsrate „3 Stunden pro Report“. Dies ergäbe bei 10 Reports einen Aufwand von 30 Stunden. Funktion einer anderen Aktivität Eine Aktivität, wie z. B. „Projekt vorbereiten“ kann z. B. mit 1% des Aufwands für alle „Nicht-Projektmanagement-Aktivitäten“ eingeschätzt werden. Der Aufwand kann auch zusammengesetzt sein, z. B. „Entwicklung eines Testmodells“ hat einen Aufwand von 10% des Programmieraufwands + 8 Stunden pro Entity Typ Feste Größen Für bestimmte Aktivitäten kann der Aufwand fix sein, z. B. Kick-Off Meeting Eigene Beurteilung Wenn keine Schätzfaktoren existieren, muss der Projektleiter (oder jemand anders) aufgrund von Erfahrungen schätzen (z. B. Bereinigen der Daten bei einer Produktionsübernahme)

68 Schätzfaktor und geschätzte Anzahl
z.B.: Erstellen Prozessmodell Faktor-Beschreibung Einfach Mittel Komplex Anzahl betroffene Abteilungen x h h h Weitere Schätzfaktoren sind z.B.: Anzahl Windows, Anzahl Reports, etc.

69 Beispiel für die Analyse-Phase (Ausschnitt)
Projekt- Bewertung Aktivität Schätzfaktor Anzahl Mh Einfach Mittel Komplex Anforderungen ermitteln Identifizieren Benutzeranforderungen Anz. der moderierten Workshop-Tage 2 24 48 24 32 40 Anz. der betroffenen Org-Einheiten 2 40 80 40 80 120 Erheben Istzustand Anz. existierender Tabellen, Dateien 20 6 120 6 8 10 Erstellen TOP-Modelle Anz. der betroffenen Abteilungen 2 8 16 8 12 16 Fester Aufwand für Aktivität 8 8 8 24 40 Anforderungen analysieren Erstellen Ereignismodell % von Erstellen Datenmodell 0,05 1,2 0,05 0,1 0,15 Anz. der Geschäftsereignisse 4 12 48 12 16 24 Durch Addition aller Einzelschätzungen ergibt sich der Roh-Aufwand

70 Externe Faktoren – Organisation (Benutzer und Team)
Externer Faktor 0,9 1,0 1,2 Bewertung Benutzer Commitment Ressourcen sind involviert Ressourcen sind identifiziert Kein Ressourcen-Commitment Benutzervertrautheit mit Systementwicklung Extensiv Moderat Minimal Entscheidungskompetenz 1 Schlüsselperson Ein Gremium Mehrere Gremien IS Managementstruktur 1 Entscheider Starkes IS Management Mehrere Abt. oder Gremien Projektteamstruktur 3-5 Teammitglieder 1 Projektteam Mehrere Projektteams Projektteamstandorte Ein Standort für Entwickler und Benutzer Entwickler und Benutzer an versch. Standorten Mehrere Projektstandorte Existenz von Zielen und Strategien Existieren und sind gut definiert Existieren Existieren nicht Größe des Unternehmens oder Bereichs 50 – 250 Mitarbeiter 251 – 500 Mitarbeiter > 500 Mitarbeiter Benutzervertrautheit mit Client/Server Erfahren Wenig erfahren Komplett neu Anzahl beteiligter externer Lieferanten 1 2 > 2 Durchschnitt = _________

71 Externe Faktoren – Projekt
Externer Faktor 0,9 1,0 1,2 Bewertung Geschäftserfahrung des Projektteams Extensiv Beträchtlich Keine oder sehr wenig Teamerfahrung mit aktueller Applikation Moderat Teamerfahrung mit dem Vorgehensmodell Teamerfahrung mit dem DBMS Teamerfahrung mit der Programmiersprache Teamerfahrung mit Projektplattform/Betiebssystem Teamerfahrung mit Netzwerk und Kommunikation Teamerfahrung mit CASE-Tools und Entwicklungsumgebung Teamerfahrung mit der Architektur und den Werkzeugen beim Kunden Nicht benötigt Architektur passt zur Applikation Architektur passt weniger zur Applikation Projekt-Zeitrahmen Genug zur Unterstüt-zung der Lernkurve Einigermaßen ausreichend Aggressiv-knapp Durchschnitt = _________

72 Externe Faktoren - Technik
Externer Faktor 0,9 1,0 1,2 Bewertung Anzahl Programmiersprachen Nicht zutreffend 1 > 1 Anzahl DBMS Anzahl der neuen DBMS Anzahl Plattformen/ Betriebssysteme 2 > 2 CASE-Tools oder Entwicklungstools Integriert ohne Modifikation Integriert mit Modifikation Keine Tools oder mehrere, die Integration erfordern Performance-Risiken Keine Gering Kritisch Qualität des existierenden Codes Gut strukturiert Unstrukturiert Qualität der existierenden Dokumentation Gut dokumentiert Nicht dokumentiert oder nicht verwendbar Status im Vergleich zur Industrie Industrie ist voraus Üblich in der Industrie Industrie liegt dahinter Tool-Reife Beweisen Relativ neu, aber bereits im Einsatz Pionier, Beta-Version oder kein Tool Programmiersprachen-Typ 4. Generation 3. Generation Objektorientiert Durchschnitt = _________

73 Berechnung des Brutto-Aufwandes
Nettoaufwand = Roh-Aufwand x Systemkomplexität x Organisationsfaktor x Teamfaktor x Technikfaktor + Zuschlag für Pufferzeiten x1% + Zuschlag für unvorhergesehenen Aufwand x2% + Zuschlag für allg. Projektmanagement x3% + Zuschlag für Qualitätsmanagement x4% + Zuschlag für Risikomanagement x5% ____________________________________________________________ = Bruttoaufwand

74 Beurteilung Potentiell das genaueste Verfahren
Aufwand -- Genauigkeit 0/+ Eindeutigkeit ++ Flexibilität Frühzeitige Anwendung Benutzerfreundlichkeit - Detaillierbarkeit Transparenz Stabilität Objektivität Potentiell das genaueste Verfahren Neigt dazu, den Aufwand hoch einzuschätzen, Erst nach Erstellung des Pflichtenhefts anwendbar Deshalb absichern durch andere Methode Benötigt unbedingt Toolunterstützung (Excel reicht aber) Erfordert umfangreiche Vorarbeiten und Projekt-Nachkalkulation, um die Faktoren zu verifizieren/weiter zu entwickeln

75 Analogiemethode Charakteristika:
Basiert auf Aufzeichnungen von Ist-Werten vergleichbarer, abgewickelter Projekte desselben Unternehmens; sorgfältige Kostenanalysen abgeschlossener Projekte liefern benötigte Informationen („Erfahrungsmaterial“); Ist-Werte werden mit entsprechenden Korrekturfaktoren multipliziert. Beurteilung: Geeignet, wenn ein neues System zum Großteil aus existierenden Komponenten besteht und/oder Analogien zu ähnlichen Bauteilen hergestellt werden können Anwendbar im Anfangsstadium eines Projekts. Da es in der Praxis sehr schwer ist, wirklich vergleichbare Projekte zu finden, kann die Anwendung der Methode zu krassen Fehlurteilen führen

76 Relationenmethode Charakteristika: Beispiel:
Ähnlich wie bei der Analogiemethode wird das zu schätzende Produkt direkt mit ähnlichen Entwicklungen verglichen. Im Gegensatz zur Analogiemethode erfolgt die Aufwandsanpassung im Rahmen einer formalisierten Vorgehensweise. Für die Aufwandsanpassung stehen Faktorenlisten und Richtlinien zur Verfügung, wie diese zu berücksichtigen sind. Die Werte geben an, in welcher Richtung und wie stark die einzelnen Faktoren den Aufwand beeinflussen. Beispiel: Programmiersprache Programmiererfahrung Dateiorganisation PL/1 = Jahre = 80 sequentiell = 80 COBOL = Jahre= 100 indexsequentiell = 120 Assembler = Jahr = 140 Beurteilung: s. Analogiemethode