1 Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Modul Einige Schätzmethoden

1Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber

Modul

Einige Schätzmethoden


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

Quellen:z. B. Litke, DV-Projektmanagement, Hanser Glinz, Software-Aufwandschätzung, Universität Zürich, Institut für Informatik

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.


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


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


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


Breitband Delphi Methode: Ablauf

1.-3. 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


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


Übung: Wie bewerten Sie diese Methoden?

Aufwand

Genauigkeit

Eindeutigkeit

Flexibilität

Frühzeitige Anwendbarkeit

Benutzerfreundlichkeit

Detaillierbarkeit

Transparenz der Ergebnisse

Stabilität

Objektivität

Bitte bewerten Sie die Methoden auf einer Skala von --, -, 0, +, ++ anhand der früher festgelegten Kriterien

EP SDM BDM


Beispiel: Meine Bewertung

Aufwand ++ - --

Genauigkeit ? ? ?

Eindeutigkeit ++ ++ ++

Frühzeitige Anwendbarkeit ++ ++ ++

Flexibilität ++ ++ ++

Benutzerfreundlichkeit ++ 0 0

Detaillierbarkeit ++ ++ ++

Transparenz der Ergebnisse -- -- 0

Stabilität ? ? ?

Objektivität -- + 0

EP SDM BDM


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 1977-79)- Data Point Methodik (H. Sneed, 1987)- Bottom-up Methodik (diverse)


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 http://sunset.usc.edu/research/COCOMOII


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


Grundgleichungen (2)

OrganicAufwand = 2,4 KDSI1,05

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)


Verbesserung der Schätzung durch Kostenfaktoren


Präzisierung der Schätzung

1. Bestimmung des Nominalwerts für den Aufwand2. Bestimmung der Kostenfaktoren3. 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 heruntergebrochen werden. Dabei wird mit folgenden Ansätzen für die Aufwandsverteilung gearbeitet (s. Folgefolien).


Aufwandsverteilung für Wasserfallmodell-basierte Entwicklungen

Phase Durch COCOMO abgedeckt

Aufwand Zeit

Planung&Anforde-rungsspezifikation

nein 7%

(Bandbreite 2% - 15%)

Typisch 16% - 24%


Design ja 17% Bandbreite 24% - 28%

Programmierung ja Bandbreite 52% - 64% Bandbreite 40% - 56%

Integration&Test ja Bandbreite 19% - 31% Bandbreite 20% - 32%

Einführung nein 12%


12,5%


Total 119% typisch 128,5% - 136,5% Bandbreite 102% - 135% Bandbreite 102% - 150%

Quelle: http://sunset.usc.edu


Aufwandsverteilung für MBASE-basierte Entwicklung


Aufwand% des durch COCOMO II

geschätzten Werts

Zeit % des durch COCOMO II

geschätzten Werts

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%


Construction(Iterative inkrementelle

Entwicklung)

ja 76%


62,5%


Transition(Systemtest und –einführung)

nein 12%

Bandbreite 0% - 20%

12,5%

Bandbreite 0% - 20%

Total 118%

Bandbreite102% - 135%

125%


MBASE = Model based Architecture&Software Enginering (B. Boehm), s. http://sunset.usc.edu


Aufwandsverteilung für RUP-basierte Entwicklung


Aufwand% des durch COCOMO II

geschätzten Werts

Zeit % des durch COCOMO II

geschätzten Werts

Inception(Vorstudie und Anforderungsanalyse)

nein 5% 10%

Elaboration(Grobdesign und Komponentenbildung)

ja 20% 30%

Construction(Iterative inkrementelle

Entwicklung)

ja 65%

50%

Transition(Systemtest und –einführung)

nein 10% 10%

Total 100% 100%

RUP = Rational Unified Process, Vorgehensmodell der Fa. RationalQuelle http://sunset.usc.edu


Rechenbeispiel für ein „organic“ Projekt

Eine Ausgangsstudie hat ergeben, dass der Programmumfang ca. 32 000 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,33 91 Mann-Monate

Zeit = 2,5 91 0,38 = 13,87 14 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.


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


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.


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.

FunktionFunktion

Interne Dateien

Externe Schnittstellen

Externe Inputs

Externe Abfragen

Externe Outputs


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


Anzahl der• Eingaben• Abfragen• Pflege von Datenbeständen• Zugriffe zu Referenzdaten• Ausgaben

mit jeweils unterschied-

licher Komplexität

Function-Point-

Methodik

Einflussfaktoren, wie z. B.• zentrale oder dezentrale Verarbeitung• Verflechtung mit anderen Anwendungen• komplexe Arithmetik• Mitarbeiter-Erfahrung

Produktivitätstabelle in der firmenspezifische Erfahrungswerte niedergelegt sind

Ergebnis in MM(Personenmonate)für den gesamtenEntwicklungsprozess

Zusammenhang der Bausteine


Externer Input

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.


Beispiele für unterschiedliche Bewertungsansätze bei den Eingaben

Anzahl bearbeiteter Datenbestände 1 - 4 5 - 15 > 15

0 - 1 einfach einfach mittel

2 einfach mittel komplex

> 2 mittel komplex komplex

Anzahl unterscheidbarer Datenelemente in der Eingabe

Litke (1996)

IFPUG (1994)

einfach mittel komplex

Anzahl unterschiedlicher Datenelemente 1 - 5 6 - 10 > 10

Eingabeprüfung formal formal

logisch

formal

logisch

Zugriff auf DB

Anspruch an Bedienerführung gering normal hoch


Externer Output

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 AusgabedatenFehlernachrichten, 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.


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 bearbeiteter Datenbestände 1 - 5 6 - 19 > 19


2 einfach mittel komplex


Anzahl unterscheidbarer Datenelemente in der Ausgabe


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


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 bearbeiteter Datenbestände

(Fremdschlüssel)1 - 19 20 - 50 > 50


2 - 5 einfach mittel komplex


Anzahl unterscheidbarer Datenelemente in der Datei


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.


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.


Bewertung externer Datenbestände

Für die Gewichtung der externen Datenbestände sind folgende Kriterien heranzuziehen:

Anzahl bearbeiteter Datenbestände

(Fremdschlüssel)1 - 19 20 - 50 > 50


2 - 5 einfach mittel komplex


Anzahl unterscheidbarer Datenelemente in der Datei


Schema zur Berechnung des Function Point Roh-Werts (IFPUG 1994)

Element einfach mittel komplex Summe

Dateneingaben ___ x 3 = ___ ___ x 4 = ___ ___ x 6 = ___ ____

Datenausgaben ___ x 4 = ___ ___ x 5 = ___ ___ x 7 = ___ ____

Anfragen ___ x 3 = ___ ___ x 4 = ___ ___ x 6 = ___ ____

Ext. Schnittstellen ___ x 5 = ___ ___ x 7 = ___ ___ x 10 = ___ ____

Int. Datenbestände ___ x 7 = ___ ___ x 10 = ___ ___ x 15 = ___ ____

Function Point Roh-Wert (UFP)

Schwierigkeitsgrad

UFP = Unadjusted Funktion Points = Function Point Roh-Wert


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.

Grundsätzliches zu den Einflussfaktoren


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)


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


Umsetzung Function Points in Personenmonate

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.

FP PM FP/PM471 25 18,84550 30 18,33628 35 17,94706 40 17,65782 45 17,38857 50 17,14932 55 16,951005 60 16,751078 65 16,581149 70 16,411220 75 16,271290 80 16,131359 85 15,991426 90 15,841453 95 15,291559 100 15,591625 105 15,481689 110 15,351752 115 15,231814 120 15,121875 125 15,001936 130 14,891995 135 14,782588 190 13,623029 240 12,623434 300 11,45


Function Point-Werte-Paare: Beispiele IBM (1985) und VW (1991)

Function PointIBM-PM VW-PM

50 2,3 -

100 5,6 -

150 9,5 -

200 13,9 11,7

250 18,6 19,3

300 23,6 27,1

350 28,9 35

400 34,4 43

450 40,1 51,1

500 46,1 59,6

550 52,2 68,2

600 58,5 77

650 65 86,1

700 71,6 95,3

750 78,4 104,8

800 85,3 114,6

850 92,4 124,7

900 99,6 135,2Quelle: H. Balzert, Lehrbuch der Software Technik, Spektrum 1996


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


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 77 14 400

Advantage:Gen 38 31 10 180

Excel 47 46 31 63

Java 62 63 53 77

Powerbuilder 32 31 11 105

Smalltalk 26 19 10 55

Visual Basic 47 42 16 158


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


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


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


Vorteile der Function Point-Methodik

Ausgangspunkt sind Produktanforderungen, nicht LOCAnpassbar 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 SchritteRelativ leicht erlernbarBenötigt nur relativ geringen Zeitaufwand (Werkzeugunterstützung sinnvoll)Gute TransparenzBrauchbare bis gute SchätzgenauigkeitWerkzeugunterstützungen verfügbar


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


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


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

Objekte


Methodenschritte

1. Entitytypen erfassen und bewerten

2. Nachrichten erfassen und bewerten

3. Data-Points errechnen

4. Qualitätsfaktor ermitteln

5. Projektumgebungsfaktor ermitteln

6. Data-Points mit dem Qualitätsfaktor multiplizieren

7. Ergebnis mit dem Projektumgebungsfaktor bewerten

8. Anzahl Data-Points gegen die Produktivitätstabelle spiegeln und Aufwand zuordnen


Name des Objekts

Anzahl Attribute

Anzahl Schlüssel

Integrations-Grad

Nutzung Änderung in %

Errechnung der Data-Points für Entitytypen

1 Data-Point pro Attribut4 Data-Points pro SchlüsselIntegrationsgrad

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


Data Points für Entity Typen: Beispiel einer Berechnungstabelle

Objektname Anzahl Attributex 1

Anzahl Schlüsselx 4

Integrationsgradniedrig: +2Mittel: +4hoch: +8

Summe 1 Summe 2:Nutzung schreiben:= Summe 1 x 1,1sonst = Summe 1

Änderung in %(bei neuen

Objekten = 100%)

Summe 3 =Summe 2 xÄnderung

Summe Data Points für Entity Typen = ________


1 Data-Point pro Feld4 Data-Points pro Sicht (Anzahl der angesprochenen Informationsentitäten)Komplexitätsgrad

- niedrig +2 DP- mittel +4 DP- hoch +8 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.

Name der Nachricht

Anzahl Felder

Anzahl Sichten

Komplexitäts-Grad

Nutzung Änderung in %

Errechnung der Data-Points bei Nachrichten


Data Points für Nachrichten: Beispiel einer Berechnungstabelle

Name derNachricht

Anzahl Felderx 1

Anzahl der in derNachricht

angesprochenenEntity Typen

x 4

Komplexitätsgradniedrig: +2Mittel: +4hoch: +8

Summe 1 Summe 2:Nutzung Eingabe:= Summe 1 x 1,1sonst = Summe 1

Änderung in %(neue Objekte =

100%)

Summe 3 =Summe 2 xÄnderung

Summe Data Points für Nachrichten = ________


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.


Einflussfaktor 1 2 3 4 5

Projektverteilung mehrere Länder

mehrere Orte ein Ort mehrere Räume

ein Raum

Projekterfahrung keine mäßig mittel gut sehr gutProjektkenntnisse keine mäßig mittel gut sehr gutProjektautomation keine teilweise halb überwiegend vollRechenbedingungen schlecht mäßig mittel gut sehr gutProjektunterstützung keine wenig mittel gut sehr gutQualitätssicherung keine teilweise

automatischhalb

automatischüberwiegend automatisch

voll automatisch

Spezifikationsformalismen informal strukturiert semiformal formal formal-grafisch

Programmiersprache 1.Generation 2.Generation 3.Generation 4.Generation 5.GenerationTestautomation keine 25% 50% 75% 100%Summe 10 20 30 40 50

Bewertung der Einflussfaktoren (1)

Die sich ergebenden Data-Points werden mit einem Einflussfaktor (Projektumgebung) multipliziert. Die Data Point Methode kennt 10 Einflussfaktoren::


Bewertung der Einflussfaktoren (2)

Jeder Faktor wird auf einer Skala von 1 - 5 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 125 - 30 / 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.


Beispiel einer Produktivitätstabelle

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.

Data Points PM80 2160 4240 6320 8

: :800 20880 23960 261040 291120 321200 351280 381360 411440 441520 471600 50

: :2000 702080 742160 782240 822320 862400 90

: :

Quelle: H.D. Litke, DV-Projektmanagement, Zeit und Kosten richtig einschäötzen, Hanser 1996


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 oderalle Teilaufgaben werden getrennt bewertet und anschließend kumuliert


Einflussfaktoren

SchätzungSchätzfaktoren

Exte

rne

Fakto

ren

Lern

ku

rve

Faktor-Anzahl


Schätzprozess

FestlegenSystem-

Komplexität

BeurteilungsvermögenErfahrung

SchätzmodellSchätzfaktoren

Aktivitäten-aufwandProjekt-Inflatoren/-Deflatoren

Projektnotfallplanungen

FestlegenFaktor-Werte

Basisaufwand

EinschätzenexternerFaktoren

VerfeinernSchätzung

Tailoringdes Vor-gehens-modells


Tailoring des Vorgehensmodells - Beispielausschnitt

Welches Kriterium trifft für das Projekt zu (markiere J oder N)?

Gro

ßes

Tea

m

Wen

ig e

rfah

rene

s P

erso

nal

Lang

e La

ufze

it

Vie

le B

enut

zer

Ver

teilt

es S

yste

m

Ges

chäf

tspr

ozes

s-Ä

nder

ung

Neu

e D

aten

bank

Tec

hnis

che

Inno

vatio

n

Erh

öhte

s R

isik

o

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-ArchitekturG G G G Z G Z Z G Verteilen Daten und Prozesse im NetzwerkB B B B B B B B B Definieren VerarbeitungsflussG 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 DialogeB B B B B B B B B Design und Evaluierung Formulare und ReportsB B B B B B B B B Design und Evaluierung User-SupportK K K Z K Z K G K Durchführen Detail-Usability-Evaluation

Z = abhängige AktivitätB = Muss-Aktivität G = grob durchzuführende Aktivität K = keine Aktivität


Generelle Systemkomplexität

System-Charakteristik Einfach

0,9

Mittel

1,0

Komplex

1,2

Bewertung

Anzahl Elemente in der Datenbank 50 - 100 101 - 500 > 500

Anzahl komplexer Rechenoperationen 0 - 10 11 - 25 > 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 11 - 30 > 30

Anzahl von Produktionsstandorten 1 2 - 3 > 3

Anzahl von Tiers 1 2 > 2

Entwicklungs-Architektur Existiert und ist Standard

Existiert und ist customized

neu

Ausführungs-Architektur Existiert und ist Standard

Existiert und ist customized

neu

System-Auswirkungen auf die Organisation Minimal Wesentlich kritisch

Auswirkungen auf den Systembetrieb Minimal wesentlich kritisch

Durchschnitt = _________


Systemkomplexität für C/S-Systeme

System-Charakteriistik Einfach

0,9

Mittel

1,0

Komplex

1,2

Bewertung

Anzahl Windows 0 - 20 21 - 50 > 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



Systemkomplexität für Host-Systeme

System-Charakteristik

Einfach

0,9

Mittel

1,0

Komplex

1,2

Bewertung

Anzahl Masken 0 - 25 26 - 75 > 75

Anzahl der Dialoge 0 - 10 11 - 25 > 25



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

1 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



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.


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)


z.B.: Erstellen Prozessmodell

Faktor-Beschreibung Einfach Mittel Komplex

Anzahl betroffene Abteilungen x 24 h 48 h 80 h

Weitere Schätzfaktoren sind z.B.:

Anzahl Windows, Anzahl Reports, etc.

Schätzfaktor und geschätzte Anzahl


Beispiel für die Analyse-Phase (Ausschnitt)

Aktivität Schätzfaktor AnzahlProjekt-Bewertung Mh Einfach Mittel Komplex

Anforderungen ermitteln

Identifizieren Benutzeranforderungen Anz. der moderierten Workshop-Tage 2 24 48 24 32 40Anz. 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 16Fester 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,15Anz. der Geschäftsereignisse 4 12 48 12 16 24

Durch Addition aller Einzelschätzungen ergibt sich der Roh-Aufwand


Externe Faktoren – Organisation (Benutzer und Team)

Externer Faktor 0,9 1,0 1,2 BewertungBenutzer Commitment Ressourcen sind

involviertRessourcen sind

identifiziertKein 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



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 Extensiv Moderat Keine oder sehr wenig

Teamerfahrung mit dem Vorgehensmodell Extensiv Moderat Keine oder sehr wenig

Teamerfahrung mit dem DBMS Extensiv Moderat Keine oder sehr wenig

Teamerfahrung mit der Programmiersprache Extensiv Moderat Keine oder sehr wenig

Teamerfahrung mit Projektplattform/Betiebssystem Extensiv Moderat Keine oder sehr wenig

Teamerfahrung mit Netzwerk und Kommunikation Extensiv Beträchtlich Keine oder sehr wenig

Teamerfahrung mit CASE-Tools und Entwicklungsumgebung

Extensiv Moderat Keine oder sehr wenig

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



Externe Faktoren - Technik

Externer Faktor 0,9 1,0 1,2 Bewertung

Anzahl Programmiersprachen

Nicht zutreffend 1 > 1

Anzahl DBMS Nicht zutreffend 1 > 1

Anzahl der neuen DBMS 0 1 > 1

Anzahl Plattformen/ Betriebssysteme

1 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

Nicht zutreffend Gut strukturiert Unstrukturiert

Qualität der existierenden Dokumentation

Nicht zutreffend 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



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


Beurteilung

Aufwand --

Genauigkeit 0/+

Eindeutigkeit ++

Flexibilität ++

Frühzeitige Anwendung --

Benutzerfreundlichkeit -

Detaillierbarkeit ++

Transparenz ++

Stabilität 0

Objektivität 0

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


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


Relationenmethode

Charakteristika:- Ä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 = 100 5 Jahre = 80 sequentiell = 80

COBOL = 120 3 Jahre= 100 indexsequentiell = 120

Assembler = 140 1 Jahr= 140

Beurteilung:

s. Analogiemethode

Documents

1 Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Modul Einige Schätzmethoden