Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "1 Workshop: Grundlagen des IT-Projektmanagements - Version 3.0 - 01/2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Modul Einige Schätzmethoden."—  Präsentation transkript:

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

2 2 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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.

3 3 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

4 4 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

5 5 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

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

7 7 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

8 8 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

9 9 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Beispiel: Meine Bewertung Aufwand++--- Genauigkeit??? Eindeutigkeit++ Frühzeitige Anwendbarkeit++ Flexibilität++ Benutzerfreundlichkeit++00 Detaillierbarkeit++ Transparenz der Ergebnisse-- 0 Stabilität??? Objektivität--+0 EP SDM BDM

10 10 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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 ) -Data Point Methodik (H. Sneed, 1987) -Bottom-up Methodik (diverse)

11 11 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

12 12 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

13 13 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Grundgleichungen (2) Organic Aufwand = 2,4 KDSI 1,05 Zeit = 2,5 Aufwand 0,38 Semidetached Aufwand = 3,0 KDSI 1,12 Zeit = 2,5 Aufwand 0,35 Embedded Aufwand = 3,6 KDSI 1,2 Zeit = 2,5 Aufwand 0,32 KDSI = Kilo delivered source instructions (1000 ausgeführte Befehle)

14 14 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Verbesserung der Schätzung durch Kostenfaktoren

15 15 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Präzisierung der Schätzung 1. Bestimmung des Nominalwerts für den Aufwand 2. Bestimmung der Kostenfaktoren 3. Multiplikation des Nominalaufwands mit dem Produkt der Kostenfaktoren Aufwand Korr = Produkt der Kostenfaktoren x Aufwand Nominal Damit ergibt sich ein Wert für den Gesamtaufwand. Dieser muss jetzt noch auf die einzelnen Phasen bzw. Aktivitäten herunter gebrochen werden. Dabei wird mit folgenden Ansätzen für die Aufwandsverteilung gearbeitet (s. Folgefolien).

16 16 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Aufwandsverteilung für Wasserfallmodell-basierte Entwicklungen PhaseDurch COCOMO abgedeckt AufwandZeit Planung&Anforde- rungsspezifikation nein7% (Bandbreite 2% - 15%) Typisch 16% - 24% (Bandbreite 2% - 30%) Designja17%Bandbreite 24% - 28% ProgrammierungjaBandbreite 52% - 64%Bandbreite 40% - 56% Integration&TestjaBandbreite 19% - 31%Bandbreite 20% - 32% Einführungnein12% (Bandbreite 0% - 20%) 12,5% (Bandbreite 0% - 20%) Total 119% typisch 128,5% - 136,5% Bandbreite 102% - 135% Bandbreite 102% - 150% Quelle:

17 17 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Aufwandsverteilung für MBASE-basierte Entwicklung PhaseDurch COCOMO abgedeckt Aufwand % des durch COCOMO II geschätzten Werts Zeit % des durch COCOMO II geschätzten Werts Inception (Vorstudie und Anforderungsanalyse) nein6% Bandbreite 2% - 15% 12,5% Bandbreite 2% - 30% Elaboration (Grobdesign und Komponentenbildung) ja24% Bandbreite 20% - 28% 37,5% Bandbreite 24% - 28% Construction (Iterative inkrementelle Entwicklung) ja76% Bandbreite 72% - 80% 62,5% Bandbreite 58% - 67% Transition (Systemtest und –einführung) nein12% Bandbreite 0% - 20% 12,5% Bandbreite 0% - 20% Total118% Bandbreite102% - 135% 125% Bandbreite 102% - 150% MBASE = Model based Architecture&Software Enginering (B. Boehm), s.

18 18 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Aufwandsverteilung für RUP-basierte Entwicklung PhaseDurch COCOMO abgedeckt Aufwand % des durch COCOMO II geschätzten Werts Zeit % des durch COCOMO II geschätzten Werts Inception (Vorstudie und Anforderungsanalyse) nein5%10% Elaboration (Grobdesign und Komponentenbildung) ja20%30% Construction (Iterative inkrementelle Entwicklung) ja65% 50% Transition (Systemtest und –einführung) nein10% Total100% RUP = Rational Unified Process, Vorgehensmodell der Fa. Rational Quelle

19 19 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Rechenbeispiel für ein organic Projekt Eine Ausgangsstudie hat ergeben, dass der Programmumfang ca auszuführende Source-Befehle (32 KSDI) betragen wird (damit haben wir die Hauptproblematik elegant umschifft!). Dann ergeben sich folgende Werte Aufwand = 2,4 32 1,05 = 91,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.

20 20 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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++ Genauigkeit0/+ Eindeutigkeit++ Flexibilität++ Frühzeitige Anwendung+* Benutzerfreundlichkeit++ Detaillierbarkeit-- Transparenz-- Stabilität--* Objektivität--* * Steht und fällt mit der Eingangsschätzung

21 21 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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.

22 22 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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. Funktion Interne Dateien Externe Schnittstellen Externe Inputs Externe Abfragen Externe Outputs

23 23 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

24 24 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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 gesamten Entwicklungsprozess Zusammenhang der Bausteine

25 25 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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.

26 26 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Beispiele für unterschiedliche Bewertungsansätze bei den Eingaben Anzahl bearbeiteter Datenbestände > einfach mittel 2 einfachmittelkomplex > 2 mittelkomplex Anzahl unterscheidbarer Datenelemente in der Eingabe Litke (1996) IFPUG (1994) einfachmittelkomplex Anzahl unterschiedlicher Datenelemente > 10 Eingabeprüfungformal logisch formal logisch Zugriff auf DB Anspruch an Bedienerführunggeringnormalhoch

27 27 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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 Ausgabedaten Fehlernachrichten, die aufgrund formaler und logischer Prüfungen ausgegeben werden und Bedienernachrichten sowie Bestätigungsscreens werden pro Dialog nur einmal als Output gezählt. Eine Fehlerliste wird pro unterschiedliche Listenform als ein Output gezählt.

28 28 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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 > einfach mittel 2 einfachmittelkomplex > 2 mittelkomplex Anzahl unterscheidbarer Datenelemente in der Ausgabe

29 29 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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 ).

30 30 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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) > einfach mittel einfachmittelkomplex > 5 mittelkomplex Anzahl unterscheidbarer Datenelemente in der Datei

31 31 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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.

32 32 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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.

33 33 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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) > einfach mittel einfachmittelkomplex > 5 mittelkomplex Anzahl unterscheidbarer Datenelemente in der Datei

34 34 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Schema zur Berechnung des Function Point Roh-Werts (IFPUG 1994) ElementeinfachmittelkomplexSumme 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

35 35 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

36 36 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Schema zur Bestimmung der Einflussfaktoren (IFPUG 1994) Nr.FaktorWert 1Datenkommunikation 2Verteilte Funktionen 3Leistungsanforderungen 4Belastung der Hardware 5Verlangte Transaktionsrate 6Online-Dateneingabe 7Effiziente Benutzerschnittstelle 8Online-Datenänderungen 9Komplexe Verarbeitungen 10Wiederverwendbarkeit 11Einfache Installation 12Einfache Benutzbarkeit 13Installation an mehreren Orten 14Änder- und Erweiterbarkeit Summe der Faktoren (TDI = Total Degree of Influence)

37 37 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

38 38 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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. FPPMFP/PM , , , , , , , , , , , , , , , , , , , , , , , , , ,45

39 39 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Function Point-Werte-Paare: Beispiele IBM (1985) und VW (1991) Function PointIBM-PMVW-PM 502, , , ,911, ,619, ,627, , , ,151, ,159, ,268, , , ,695, ,4104, ,3114, ,4124, ,6135,2 Quelle: H. Balzert, Lehrbuch der Software Technik, Spektrum 1996

40 40 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

41 41 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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 SpracheDurchschnittMedianIntervall unt. Grenze Intervall ob. Grenze Access ADA Assembler C Cobol Advantage:Gen Excel Java Powerbuilder Smalltalk Visual Basic

42 42 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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).

43 43 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

44 44 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

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

46 46 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

47 47 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

48 48 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

49 49 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

50 50 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Errechnung der Data-Points für Entitytypen 1 Data-Point pro Attribut 4 Data-Points pro Schlüssel Integrationsgrad -niedrig 2 DP -mittel 4 DP -hoch 8 DP Nutzung -Bei zu schreibenden Objekten die Summe der bisher ermittelten Data- Points um 10 % erhöhen. Änderung -Angabe eines %-Satzes, der den Änderungsaufwand des Objektes darstellt (bei neuen Objekten = 100 %). Data-Points-Ergebnis -Die Summe der ermittelten Data-Points wird mit dem in der Spalte Änderung in % festgehaltenen Prozentsatz multipliziert, z.B. 30 % von 130 Data-Points = 39 Data-Points.

51 51 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Data Points für Entity Typen: Beispiel einer Berechnungstabelle

52 52 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber 1 Data-Point pro Feld 4 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. Errechnung der Data-Points bei Nachrichten

53 53 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Data Points für Nachrichten: Beispiel einer Berechnungstabelle

54 54 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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.

55 55 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Einflussfaktor12345 Projektverteilungmehrere Länder mehrere Orteein Ortmehrere Räume ein Raum Projekterfahrungkeinemäßigmittelgutsehr gut Projektkenntnissekeinemäßigmittelgutsehr gut Projektautomationkeineteilweisehalbüberwiegendvoll Rechenbedingungenschlechtmäßigmittelgutsehr gut Projektunterstützungkeinewenigmittelgutsehr gut Qualitätssicherungkeineteilweise automatisch halb automatisch überwiegend automatisch voll automatisch Spezifikationsformalismeninformalstrukturiertsemiformalformalformal- grafisch Programmiersprache1.Generation2.Generation3.Generation4.Generation5.Generation Testautomationkeine25%50%75%100% Summe Bewertung der Einflussfaktoren (1) Die sich ergebenden Data-Points werden mit einem Einflussfaktor (Projektumgebung) multipliziert. Die Data Point Methode kennt 10 Einflussfaktoren::

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

57 57 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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 PointsPM :: :: :: Quelle: H.D. Litke, DV-Projektmanagement, Zeit und Kosten richtig einschäötzen, Hanser 1996

58 58 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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 oder alle Teilaufgaben werden getrennt bewertet und anschließend kumuliert

59 59 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Einflussfaktoren Schätzung Schätzfaktoren Externe FaktorenLernkurve Faktor-Anzahl

60 60 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Schätzprozess Festlegen System- Komplexität Beurteilungsvermögen Erfahrung Schätzmodell Schätzfaktoren Aktivitäten- aufwand Projekt-Inflatoren/-Deflatoren Projektnotfallplanungen Festlegen Faktor- Werte Basisaufwand Einschätzen externer Faktoren Verfeinern Schätzung Tailoring des Vor- gehens- modells

61 61 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Tailoring des Vorgehensmodells - Beispielausschnitt Welches Kriterium trifft für das Projekt zu (markiere J oder N)? Großes TeamWenig erfahrenes PersonalLange Laufzeit Viele BenutzerVerteiltes System Geschäftsprozess-Änderung Neue Datenbank Technische Innovation Erhöhtes Risiko J/N ? Arbeitspaket / Aktivität Design Anwendungs-Architektur BBBBBBBBB Definieren Anwendungs-Architektur GGGGZGZZG Verteilen Daten und Prozesse im Netzwerk BBBBBBBBB Definieren Verarbeitungsfluss GZGGZGZZZ Entwickeln Assembly-Test-Verfahren Design User-Interface BBBBBBBBB Design und Evaluierung Dialoge BBBBBBBBB Design und Evaluierung Formulare und Reports BBBBBBBBB Design und Evaluierung User-Support KKKZKZKGK Durchführen Detail-Usability-Evaluation Z = abhängige Aktivität B = Muss-Aktivität G = grob durchzuführende Aktivität K = keine Aktivität

62 62 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Generelle Systemkomplexität System-CharakteristikEinfach 0,9 Mittel 1,0 Komplex 1,2 Bewertung Anzahl Elemente in der Datenbank > 500 Anzahl komplexer Rechenoperationen > 25 Level an Background-/asynchroner VerarbeitungKleinmäßigsignifikant Schnittstellen zu anderen ApplikationenWenige Einweg Wenige Zweiweg Viele Zweiweg Anzahl von wesentlichen Reports > 30 Anzahl von Produktionsstandorten12 - 3> 3 Anzahl von Tiers12> 2 Entwicklungs-ArchitekturExistiert und ist Standard Existiert und ist customized neu Ausführungs-ArchitekturExistiert und ist Standard Existiert und ist customized neu System-Auswirkungen auf die OrganisationMinimalWesentlichkritisch Auswirkungen auf den SystembetriebMinimalwesentlichkritisch Durchschnitt = _________

63 63 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Systemkomplexität für C/S-Systeme System-CharakteriistikEinfach 0,9 Mittel 1,0 Komplex 1,2 Bewertung Anzahl Windows > 50 Anzahl der Dialoge > 15 GUI StyleForm-FilledTextGrafisch Daten-Verteilungs-StrategieKeine Verteilung Eine DB PartitioniertRedundant Prozess-Verteilungs-StrategieRemote Präsentation Remote Server Voll kooperativ Durchschnitt = _________

64 64 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Systemkomplexität für Host-Systeme System- Charakteristik Einfach 0,9 Mittel 1,0 Komplex 1,2 Bewertung Anzahl Masken > 75 Anzahl der Dialoge > 25 Durchschnitt = _________

65 65 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Systemkomplexität für Kaufsoftware System-CharakteristikEinfach 0,9 Mittel 1,0 Komplex 1,2 Bewertung Anzahl der Kandidaten12 - 3> 3 Anzahl der einzuschätzenden Plattformen 12> 2 Multi-nationale AnforderungenKeine Fremdsprache Eine Fremdsprache Mehr als eine Fremdsprache Menge an Paket-OptionenWenigeEinigeViele Erforderliche Paket-Programm- Modifikationen Keine/StandardMinimale Modifikationen Wesentliche Änderungen Durchschnitt = _________

66 66 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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.

67 67 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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)

68 68 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber z.B.: Erstellen Prozessmodell Faktor-BeschreibungEinfach 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

69 69 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Beispiel für die Analyse-Phase (Ausschnitt) AktivitätSchätzfaktor Anzahl Projekt- Bewertung Mh EinfachMittelKomplex Anforderungen ermitteln Identifizieren BenutzeranforderungenAnz. der moderierten Workshop-Tage Anz. der betroffenen Org-Einheiten Erheben IstzustandAnz. existierender Tabellen, Dateien Erstellen TOP-ModelleAnz. der betroffenen Abteilungen Fester Aufwand für Aktivität Anforderungen analysieren Erstellen Ereignismodell% von Erstellen Datenmodell0,051,20,050,10,15 Anz. der Geschäftsereignisse Durch Addition aller Einzelschätzungen ergibt sich der Roh-Aufwand

70 70 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Externe Faktoren – Organisation (Benutzer und Team) Externer Faktor0,91,01,2Bewertung Benutzer CommitmentRessourcen sind involviert Ressourcen sind identifiziert Kein Ressourcen- Commitment Benutzervertrautheit mit Systementwicklung ExtensivModeratMinimal Entscheidungskompetenz1 SchlüsselpersonEin GremiumMehrere Gremien IS Managementstruktur1 EntscheiderStarkes IS Management Mehrere Abt. oder Gremien Projektteamstruktur3-5 Teammitglieder1 ProjektteamMehrere Projektteams ProjektteamstandorteEin Standort für Entwickler und Benutzer Entwickler und Benutzer an versch. Standorten Mehrere Projektstandorte Existenz von Zielen und Strategien Existieren und sind gut definiert ExistierenExistieren nicht Größe des Unternehmens oder Bereichs 50 – 250 Mitarbeiter251 – 500 Mitarbeiter> 500 Mitarbeiter Benutzervertrautheit mit Client/Server ErfahrenWenig erfahrenKomplett neu Anzahl beteiligter externer Lieferanten 12> 2 Durchschnitt = _________

71 71 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Externe Faktoren – Projekt Externer Faktor0,91,01,2Bewertung Geschäftserfahrung des ProjektteamsExtensivBeträchtlichKeine oder sehr wenig Teamerfahrung mit aktueller ApplikationExtensivModeratKeine oder sehr wenig Teamerfahrung mit dem VorgehensmodellExtensivModeratKeine oder sehr wenig Teamerfahrung mit dem DBMSExtensivModeratKeine oder sehr wenig Teamerfahrung mit der ProgrammierspracheExtensivModeratKeine oder sehr wenig Teamerfahrung mit Projektplattform/BetiebssystemExtensivModeratKeine oder sehr wenig Teamerfahrung mit Netzwerk und KommunikationExtensivBeträchtlichKeine oder sehr wenig Teamerfahrung mit CASE-Tools und Entwicklungsumgebung ExtensivModeratKeine oder sehr wenig Teamerfahrung mit der Architektur und den Werkzeugen beim Kunden Nicht benötigtArchitektur passt zur Applikation Architektur passt weniger zur Applikation Projekt-ZeitrahmenGenug zur Unterstüt- zung der Lernkurve Einigermaßen ausreichend Aggressiv-knapp Durchschnitt = _________

72 72 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Externe Faktoren - Technik Externer Faktor0,91,01,2Bewertung Anzahl Programmiersprachen Nicht zutreffend1> 1 Anzahl DBMSNicht zutreffend1> 1 Anzahl der neuen DBMS01> 1 Anzahl Plattformen/ Betriebssysteme 12> 2 CASE-Tools oder Entwicklungstools Integriert ohne ModifikationIntegriert mit ModifikationKeine Tools oder mehrere, die Integration erfordern Performance-RisikenKeineGeringKritisch Qualität des existierenden Codes Nicht zutreffendGut strukturiertUnstrukturiert Qualität der existierenden Dokumentation Nicht zutreffendGut dokumentiertNicht dokumentiert oder nicht verwendbar Status im Vergleich zur Industrie Industrie ist vorausÜblich in der IndustrieIndustrie liegt dahinter Tool-ReifeBeweisenRelativ neu, aber bereits im Einsatz Pionier, Beta-Version oder kein Tool Programmiersprachen-Typ4. Generation3. GenerationObjektorientiert Durchschnitt = _________

73 73 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Berechnung des Brutto-Aufwandes Nettoaufwand = Roh-Aufwand x Systemkomplexität x Organisationsfaktor x Teamfaktor x Technikfaktor + Zuschlag für Pufferzeiten x 1 % + Zuschlag für unvorhergesehenen Aufwand x 2 % + Zuschlag für allg. Projektmanagement x 3 % + Zuschlag für Qualitätsmanagement x 4 % + Zuschlag für Risikomanagement x 5 % ____________________________________________________________ = Bruttoaufwand

74 74 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: Dr. Klaus Röber Beurteilung Aufwand-- Genauigkeit0/+ Eindeutigkeit++ Flexibilität++ Frühzeitige Anwendung-- Benutzerfreundlichkeit- Detaillierbarkeit++ Transparenz++ Stabilität0 Objektivität0 Potentiell das genaueste Verfahren Neigt dazu, den Aufwand hoch einzuschätzen, Erst nach Erstellung des Pflichtenhefts anwendbar Deshalb absichern durch andere Methode Benötigt unbedingt Toolunterstützung (Excel reicht aber) Erfordert umfangreiche Vorarbeiten und Projekt-Nachkalkulation, um die Faktoren zu verifizieren/weiter zu entwickeln

75 75 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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

76 76 Workshop: Grundlagen des IT-Projektmanagements - Version /2004Modul: Aufwand Schätzmethoden Copyright: 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 ProgrammiererfahrungDateiorganisation PL/1= Jahre = 80sequentiell= 80 COBOL= Jahre= 100indexsequentiell= 120 Assembler= Jahr= 140 Beurteilung: s. Analogiemethode


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

Ähnliche Präsentationen


Google-Anzeigen