1Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
Modul
Einige Schätzmethoden
2Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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.
3Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
4Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
5Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
6Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
7Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
8Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
Ü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
9Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
10Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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)
11Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
12Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
13Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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)
14Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
Verbesserung der Schätzung durch Kostenfaktoren
15Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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).
16Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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 ja Bandbreite 52% - 64% Bandbreite 40% - 56%
Integration&Test ja Bandbreite 19% - 31% Bandbreite 20% - 32%
Einführung nein 12%
(Bandbreite 0% - 20%)
12,5%
(Bandbreite 0% - 20%)
Total 119% typisch 128,5% - 136,5% Bandbreite 102% - 135% Bandbreite 102% - 150%
Quelle: http://sunset.usc.edu
17Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
Aufwandsverteilung für MBASE-basierte Entwicklung
Phase Durch COCOMO abgedeckt
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%
Bandbreite 24% - 28%
Construction(Iterative inkrementelle
Entwicklung)
ja 76%
Bandbreite 72% - 80%
62,5%
Bandbreite 58% - 67%
Transition(Systemtest und –einführung)
nein 12%
Bandbreite 0% - 20%
12,5%
Bandbreite 0% - 20%
Total 118%
Bandbreite102% - 135%
125%
Bandbreite 102% - 150%
MBASE = Model based Architecture&Software Enginering (B. Boehm), s. http://sunset.usc.edu
18Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
Aufwandsverteilung für RUP-basierte Entwicklung
Phase Durch COCOMO abgedeckt
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
19Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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.
20Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
21Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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.
22Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
23Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
24Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
25Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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.
26Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
27Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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.
28Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
0 - 1 einfach einfach mittel
2 einfach mittel komplex
> 2 mittel komplex komplex
Anzahl unterscheidbarer Datenelemente in der Ausgabe
29Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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 ).
30Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
0 - 1 einfach einfach mittel
2 - 5 einfach mittel komplex
> 5 mittel komplex komplex
Anzahl unterscheidbarer Datenelemente in der Datei
31Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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.
32Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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.
33Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
0 - 1 einfach einfach mittel
2 - 5 einfach mittel komplex
> 5 mittel komplex komplex
Anzahl unterscheidbarer Datenelemente in der Datei
34Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
35Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
36Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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)
37Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
38Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
39Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
40Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
41Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
42Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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).
43Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
44Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
45Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
46Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
47Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
48Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
49Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
50Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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.
51Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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 = ________
52Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
53Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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 = ________
54Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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.
55Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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::
56Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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.
57Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
58Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
59Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
Einflussfaktoren
SchätzungSchätzfaktoren
Exte
rne
Fakto
ren
Lern
ku
rve
Faktor-Anzahl
60Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
61Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
62Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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 = _________
63Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
Durchschnitt = _________
64Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
Durchschnitt = _________
65Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
Durchschnitt = _________
66Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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.
67Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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)
68Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
69Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
70Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
Durchschnitt = _________
71Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
Durchschnitt = _________
72Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
Durchschnitt = _________
73Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
74Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
75Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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
76Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004 Modul: Aufwand SchätzmethodenCopyright: Dr. Klaus Röber
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