PTA_ProjektAufwandsschaetzung_Grundlagen.pdf - PTA GmbH

seit 1969 

Beratung 

Organisation 

Softwareentwicklung 

Aufwandsschätzung 

Aufwandsschätzung

• Function Point Analysis (FPA) 

– Grundlagen Schätzmethoden 

– Vorgehensweise FPA 

– Ablauf FPA 

– Inhalte FPA 

– Überleitung zu COCOMO II 


Gliederung 

• Aufwandsschätzung mit COCOMO II 

– Grundlagen 

– Vorgehensweise 

– Beispiel 

– Objektorientierte Analyse 

12.02.2007 PTA GmbH, Unternehmensberatung 2

• Erfahrungskurven 

– IBM, VW, ... 


Grundlagen Schätzmethoden 

• Schätzgleichungen 

– Function Point, Data Point, COCOMO, ... 

• Expertensysteme 

– Checkpoint, KnowledgePLAN, Project Bridge, COCOMO II, ... 


• Analogiemethode 

• Relationsmethode 

• Multiplikationsmethode 

• Gewichtungsmethode 


Basismethoden für das Schätzen 

• Parametrische Gleichungen 

• Prozentsatzmethode 

• ... 



Analogiemethode 

• Vergleich mit bereits abgeschlossenen Projekten anhand von 

Ähnlichkeitskriterien 

• Ähnlichkeitskriterien 

– Anwendungsgebiet 

– Produktumfang 

– Komplexitätsgrad 

– Programmiersprache 

– ... 



Relationsmethode 

• Vergleich mit bereits abgeschlossenen Projekten auf Basis von 

Faktorenlisten und Richtlinien 

• Faktoren 

– Programmiererfahrung: 1 Jahr = 140, 3 Jahre = 100, 5 Jahre = 80 

– Programmiersprache: PL/I = 100, Cobol = 120, Assembler = 140 

– Dateiorganisation: Sequentiell = 80, Indexsequentiell = 120 

– ... 



Multiplikationsmethode 

• Die Anwendung wird in schätzbare Teilfunktionen zerlegt. 

• Die Teilfunktionen werden bestimmten Kategorien zugeordnet und 

mit einem Faktor für den Aufwand multipliziert. 

• Der Gesamtaufwand ist die Summe der gewichteten 

Einzelaufwände. 



Multiplikationsmethode --Beispiel Beispiel 

Quelle: BALZERT, Helmut: Lehrbuch der Software-Technik, 1996, S. 67 



Gewichtungsmethode 

• Es werden Faktoren festgelegt, die zu bewerten sind. 

• Den Faktorausprägungen sind Werte zugeordnet. 

• Die Werte aller Faktoren werden nach einer vorgegebenen Formel 

verknüpft und ergeben den Gesamtaufwand 



Parametrische Gleichung 

• Durch Korrelationsanalysen wird auf Basis von abgeschlossenen 

Projekten ermittelt, welche Faktoren welchen wertmäßigen Einfluss 

auf den Gesamtaufwand haben. 

• Die Faktoren, die die höchste Korrelation besitzen, werden zu einer 

Gleichung zusammengefasst. 



Prozentsatzmethode 

• Aus abgeschlossenen Projekten wird ermittelt, wie der Aufwand 

sich auf die Phasen des Entwicklungsprozesses verteilt hat. 

• Auf Basis der Istwerte bereits abgeschlossener Phasen des 

laufenden Projektes kann auf den Umfang des Gesamtaufwandes 

geschlossen werden. 



Aufwandsverteilung 

Bertelsmann Hewlett-Packard 

Definition 30% 18% 

Entwurf 30% 19% 

Codierung 15-20% 34% 

Test 20-25% 29% 




Übersicht Schätzmethoden 

Methode 

A = Analogiemethode 

M = Multiplikatormethode 

R = Relationsmethode 

G = Gewichtungsmethode 

Ps = Parametrische Schätzgleichung 

P = Prozentsatzmethode 

Einsatz(punkt) 

P = Planungsphase 

D = Definitionsphase 

E = Entwurfsphase 

I = Iteratives Verfahren 

Berücksichtigte Faktoren(gruppe) 

1 = Quantität 

2 = Qualität 

3 = Entwicklungsdauer 

4 = Produktivität 










Gliederung 




– Beispiel 




Function Point Analysis (FPA) 



FPA --Annahmen Annahmen 

• Aufwand hängt vom Umfang und Schwierigkeitsgrad einer 

Anwendung ab. 

• Eine Schätzung ist möglich, wenn die gesamte Funktionalität einer 

Anwendung bekannt ist. 

• Die Schätzung wird aus fachlicher Sicht vorgenommen. 

• Der Istaufwand muss für die Nachkalkulation ermittelbar sein. 

• Es wird der Gesamtaufwand eines Projektes geschätzt. 



FPA --Vorgehensweise Vorgehensweise 

• Die Anwendung wird in Anforderungen zerlegt. 

• Eine Anforderung wird einer Kategorie zugeordnet mit der 

Klassifizierung der Komplexität. 

• Die ermittelten Function Points (Komplexität der Anforderung) 

werden durch Einflussfaktoren korrigiert. 

• Die korrigierten FP ergeben mittels einer Tabelle FP PM 

(Erfahrungswerte) den Aufwand. 



FPA --Die Die fünf Kategorien 










Gliederung 




– Beispiel 




Quelle: BALZERT, Helmut: Lehrbuch der 

Software-Technik, 1996, S. 77 



Kategorien der Anforderungen 

• Eingabedaten / Eingaben 

External Inputs - EI 

• Abfragen 

External Inquiries - EQ 

• Ausgabedaten / Ausgaben 

External Outputs - EO 

• Datenbestände / Entitäten 

Internal Logical Files - ILF 

• Referenzdateien / Code-Tabellen 

External Interface Files - EIF 









Gliederung 




– Beispiel 




Eingaben (External Inputs - EI) 

Als Eingabe zählt jede Eingabe mit 

• unterschiedlicher Verarbeitungslogik wie: 

- Erfassen 

- Ändern 

- Löschen 

(auch bei gleicher Maske) 

• unterschiedlichem Format wie: 

- Bildschirm 

- Diskette 

- Datei 

- Belegleser 

- Schnittstellendaten von anderen 

Anwendungen 

- ... 



Eingaben (External Inputs - EI) 

Kriterium 

Anzahl unterschiedlicher 

Datenelemente 

Eingabeprüfung 

Ansprüche an die 

Bedienerführung 

Komplexität 

Einfach 

12.02.2007 PTA GmbH, Unternehmensberatung 24 

1-5 

formal 

gering 

Mittel 

6-10 

formal 

logisch 

normal 

Komplex 

>10 

formal 

logisch 

DB-Zugriff 

hoch 


Software-Technik, 1996, S. 80


Abfragen (External Inquiries - EQ) 

• Suchen nach Informationen in den 

Datenbeständen und Anzeige des 

Ergebnisses. 

• Abfragen mit vielen Verarbeitungsschritten 

und Zwischenverarbeitungen 

zählen nicht als Abfragen, 

sondern als Ein- und Ausgaben. 

• Eingaben für Abfragen bewirken 

keine Veränderung des Datenbestandes, 

sondern dienen nur als 

Schlüsseldaten für den Suchvorgang 

(Selektionskriterien) 



Abfragen (External Inquiries - EQ) 

Kriterium 


Schlüssel 

Ansprüche an die 

Bedienerführung 

Komplexität 

Einfach 


1 

gering 

Mittel 

2 

normal 

Komplex 

>2 

hoch 




Ausgaben (External Outputs - EO) 

Als Ausgabe zählt jede einzelne: 

• Bildschirmausgaben, die aus einem 

anderen Verarbeitungsteil kommen oder 

ein unterschiedliches Format haben 

• Schnittstellen-Daten für andere 

Anwendungen 

• Listen und Formulare 

• Terminaldrucker 

• ... 

Regeln 

• Fehler, Bedienungshinweise, Bestätigungen 

pro Dialog nur einmal zählen. 

• Wenn bei einem Dialog eine Ausgabe 

gleichzeitig als Eingabe verwendet wird, 

darf dies nur einmal als Ausgabe gezählt 

werden. 



Ausgaben (External Outputs - EO) 

Kriterium 

Anzahl Spalten 


Datenelemente 

Gruppenwechsel 

Anz. Datenelemente 

Druckaufbereitung 

Komplexität 

Einfach 


1-6 

1-5 

1 

keine 

Mittel 

7-15 

6-10 

2-3 

einige 

Komplex 

>15 

>10 

>3 

viele 





ILF A 

ILF B 

Datenbeststände (Internal Logical 

Files - ILF) 

• Zu zählen ist jeder Datenbestand, 

der von der Anwendung verwaltet 

wird. 

• Zu zählen ist jede logische Datengruppe 

(Satzart, Tabelle) der Anwendung. 

• Zwischen-, Sortierdateien, technische 

Hilfsdateien werden nicht 

gezählt.


Datenbeststände (Internal Logical 

Files - ILF) 

Kriterium 

Anzahl Schlüssel / 

Satzarten 


Datenelemente 

Datenbestand bereits 

vorhanden 

Vorh. Datenbestand 

wird verändert 

Komplexität 

Einfach 


ILF A 

1 

1-20 

ja 

nein 

ILF B 

Mittel 

2 

21-40 

- 

ja 

Komplex 

>2 

>40 

nein 



-



EIF A 

EIF B 

Schnittstellen (External Interface 

Files - EIF) 

• Zu zählen ist jede logische 

Datengruppe, die Zusatzinformationen 

für die Anwendung 

liefert. 

• Die Daten werden von der 

Anwendung nicht komplett 

verarbeitet.


Schnittstellen (External Interface 

Files - EIF) 

Kriterium 

Read-Only-Dateien 


Datenelemente 

Anzahl Schlüssel / 

Satzarten 

Tabellen 


Datenelemente 

Dimension 

Komplexität 

Einfach 


EIF A 

1-5 

1 

1-5 

1 

Mittel 

6-10 

2 

6-10 

2 

EIF B 

Komplex 

>10 

>2 

>10 



3




Einfaches 

Einfaches 

Excel 

Excel 

Template 

Template 

- 

- 

Instructions 

Instructions 



Einfaches 

Einfaches 

Excel 

Excel 

Template 

Template 

- 

- 

Summary 

Summary 



Einfaches 

Einfaches 

Excel 

Excel 

Template 

Template 

- 

- 

EQs 

EQs 









Gliederung 




– Beispiel 




Einflussfaktoren 



Aufwandstabelle FP MM 


FP 


IBM-Erfahrungskurve 


PM


Erfahrungswerte von IBM und VW --Vergleich Vergleich 


Function Points 


Erfahrungswerte von IBM und VW 

3.000 

2.000 

1.000 

5 10 15 20 25 

Function Points / Personenmonat 



COCOMO II 

automatisiert 

diesen Schritt! 











Gliederung 




– Beispiel 




COCOMO II II --Constructive Constructive Cost Model 

• COCOMO II ist das Ergebnis der Verbesserung des bekannten 

COCOMO Software Kostenschätzungs-Modells, das ursprünglich 

von Dr. Barry Boehm im Jahre 1981 in Software Engineering 

Economics veröffentlicht wurde. 

• Entwicklungsleiter: Dr. Barry Boehm 

• Center for Software Engineering at University of Southern California 

• Verschiedene Sponsoren, u.a. AT&T, Motorola, Rational, Sun, US- 

Militär(industrie),usw. 

• Offene Entwicklung: Alle Algorithmen etc. frei verfügbar 

Quelle: http://sunset.usc.edu/research/COCOMOII/index.html 




• COCOMO ist ein parametrisches Schätzverfahren 

• Durch die Auswertung einer statistisch ausreichend großen Anzahl 

von Projekten werden Formeln, Einflussfaktoren und Konstanten 

bestimmt. 

• Zentrale Konzepte: 

– Ermittlung der Programmgröße (Size) 

– Einbeziehung von Skalierungsfaktoren (PM nom.) 

– Einbeziehung von Einflussfaktoren (PM adj.) 

– Berücksichtigung der Planung (TDEV, Scheduling) 

– Berücksichtigung von Requirement-Änderungen 

– Berücksichtigung von Wartungsaufwand (Maintenance) 




• COCOMO II unterstützt drei verschiedene Schätzverfahren (Modelle), 

die zu unterschiedlichen Zeitpunkten im Projekt verwendet 

werden sollen: 

– Application Composition 

– Early Design 

– Post Architecture 

• Post Architecture scheint allerdings die einzige derzeit gut 

kalibrierte und breit angewendete Schätzart zu sein und sollte daher 

für die Aufwandsschätzung verwendet werden. 









Gliederung 




– Beispiel 



Mengengerüst 


COCOMO II II --Vorgehensweise Vorgehensweise 

Komplexität 



Schätzverfahren 

COCOMO II 

Erfahrungswerte 

(wissenschaftlich 

ausgewertete Projekte) 

Standard 

Standard 

Ressourcenplanung 

Terminplanung 

Projektplan 



COCOMO II II --Beispiel Beispiel Mengengerüst detailliert 

Mengengerüst 

Komplexität 



Schätzverfahren 

COCOMO II 


(wissenschaftlich 

ausgewertete Projekte) 

XXXXXX 

XXXXXX 

XXXXXX 

XXXXXX XXXXXX 

Ressourcenplanung 

Terminplanung 

Projektplan 



COCOMO II II --Beispiel Beispiel Mengengerüst Gesamt 

Komplexität 

Applikation Art hoch mittel niedrig Anzahl 

Master BLL Batch 3 3 7 13 

Business Objects 16 16 

Dialog 1 2 17 20 

Liste / Report 1 2 3 

Schnittstelle 2 3 9 14 

BLL Summe 6 9 51 66 

Master Summe 6 9 51 66 

User BLL Batch 5 6 11 22 


Dialog 3 3 14 20 


Schnittstelle 2 6 8 

BLL Summe 10 10 54 74 

BSF Batch 5 5 


Dialog 

Liste / Report 

1 12 13 


BSF Summe 2 23 25 

TPV Batch 1 3 6 10 


Dialog 

Liste / Report 

4 4 

Schnittstelle 13 13 

TPV Summe 1 3 30 34 

User Summe 11 15 107 133 

Gesamt 17 24 158 199 









Gliederung 




– Beispiel 




COCOMO II II --Beispiel Beispiel Oracle SQL Forms und Java 

XXXXXXXXXXXXXXXXX 

• Mehrere Modelle werden unterstützt! 


Applikationen/Module 


COCOMO II II --Übersicht Übersicht der Module 


Mengengerüst 


152 h (= 1PM) * 200,- DM 

• Aufteilung einer Anwendung in Module möglich! 



COCOMO II II --Einflussfaktoren Einflussfaktoren 


• Beispiel Produktfaktoren 

Weitere Erläuterungen siehe Handbuch von COCOMO II 



COCOMO II II --Erfahrungswerte Erfahrungswerte 

Anpassung an 

eigene 


möglich! 



COCOMO II II --Summe Summe Einflussfaktoren EAF 


• EAF (Adjustment Factor) = 1,00 d.h. normal (keine besonderen Einflussfaktoren) 




COCOMO II II --Mengengerüst Mengengerüst und Function Points 


• Verbindung zu FPA 



ILF 

EIF 

EI 

EO 

EI


COCOMO II II --Mengengerüst Mengengerüst und Komplexität 


Applikation Art hoch 

Komplexität 

mittel niedrig Anzahl 

BLL Batch 5 6 8 19 


Dialog 3 3 12 18 



BLL Summe 9 10 43 62 




COCOMO II II --Mengengerüst Mengengerüst und Sprache 


• Erfahrungswerte können verändert werden! 




COCOMO II II --Erfahrungswerte Erfahrungswerte Sprache 

Sprache FP Sprache FP 

Fifth Generation 5 Lisp 64 

Spreadsheet Default 6 Prolog 64 

Query Default 13 Ada 83 71 

HTML 3.0 15 Fortran 95 71 

PowerBuilder 16 Modula 2 80 

Fourth Generation 20 Report Generator 80 

Perl 21 Third Generation 80 

UNIX Shell 21 Cobol 85, ANSI 91 

Object Oriented 29 High Level 91 

Visual Basic 5.0 29 Pascal 91 

APL 32 Procedural 105 

Basic, Interpreted 32 Fortran77 107 

Visual C++ 34 Second Generation 107 

Access 38 C 128 

Database Default 40 Assembly, Macro 213 

Simulation Default 46 Assembly, Basic 320 

AI Shell 49 First Generation 320 

Basic, Compiled 49 Machine Code 640 

Forth 49 USR_1 1 

Ada 95 49 USR_2 1 

C++ 53 USR_3 1 

Java 53 USR_4 1 

Basic, ANSI 64 USR_5 1 



COCOMO II II --Aufwand Aufwand in in Personenmonate 


• 1 PM = 152 h (kann verändert werden) 

Aufwand PM 

Produktivität 

EAF=1 EAF≠1 = Module Size / EST Effort 

bei 8 h pro Arbeitstag sind das 19 Arbeitstage im Monat (Durchschnitt für ein ganzes Jahr 228 Arbeitstage im Jahr!) 




COCOMO II II --Kosten Kosten 

• Kosten bestimmt u.a. durch den Monatssatz LABOR Rate 


Kosten 

= EST Effort (PM) * LABOR Rate


COCOMO II II --Kosten Kosten je je Line of of Codes 


= COST / Module Size 



COCOMO II II --Anzahl Anzahl Personen 


= Anzahl Personen (∅) 



COCOMO II II --Risikobewertung Risikobewertung 


Wenn EAF > 1 



COCOMO II II --Gesamtaufwand Gesamtaufwand in in drei Größen 


• Optimistische, wahrscheinliche und pessimistische Größe 



COCOMO II II --Gesamtaufwand Gesamtaufwand 


• Aufwand ohne Anforderungsanalyse 


Phase 


COCOMO II II --Gesamtaufwand Gesamtaufwand je je Phase 


XXXXXXXXXXXXXXX 

Aufwand in PM Laufzeit in Monaten Anz. Pers. 

• Aufwand ohne Anforderungsanalyse 



COCOMO II II --Beispiel Beispiel Realisierungsvarianten 

Sortierer XXXXXXXXVariante 

1: Master - Forms / User - Java 

PMonate PTage PStunden Betrag 

Phase 152 h 8 h h 200,- DM 

Analyseanforderung 9,352 177,7 1.422 284.301 

Analyse 22,713 431,5 3.452 690.475 

Design 33,399 634,6 5.077 1.015.330 

Realisierung + Modultest 44,086 837,6 6.701 1.340.214 

Integration + Systemtest 33,408 634,8 5.078 1.015.603 

Noch zu tun 110,893 2.107,0 16.856 3.371.147 

Gesamt 142,958 2.716,2 21.730 4.345.923 

ohne Anforderung (COCOMO) 4.061.622 

XXXXXXXX Sortierer Variante 3: Master - VB / User - VB 


Phase 152 h 8 h h 200,- DM 

Analyseanforderung 5,818 110,5 884 176.867 

Analyse 14,129 268,5 2.148 429.522 

Design 21,163 402,1 3.217 643.355 

Realisierung + Modultest 28,197 535,7 4.286 857.189 

Integration + Systemtest 19,622 372,8 2.983 596.509 

Noch zu tun 68,982 1.310,7 10.485 2.097.053 

Gesamt 88,929 1.689,7 13.517 2.703.442 


Sortierer XXXXXXXXVariante 

2: Master - Forms / User - VB 


Phase 152 h 8 h h 200,- DM 

Analyseanforderung 5,419 103,0 824 164.738 

Analyse 13,161 250,1 2.000 400.094 

Design 19,756 375,4 3.003 600.582 

Realisierung + Modultest 26,350 500,7 4.005 801.040 

Integration + Systemtest 18,153 344,9 2.759 551.851 

Noch zu tun 64,259 1.220,9 9.767 1.953.474 

Gesamt 82,839 1.573,9 12.592 2.518.306 


SLOC/UFP 

Mayes 

COCOMO Consulting 

Sprache 1996 2001 

COBOL 85 91 132,5 

C++ 55 69,3 

Java 53 50,3 

OO-Default 29 32,0 

Oracle - 46,6 

4GL 20 - 

VB 5.0 29 41,0 

MS Access 38 39,0 

Prüfen!!! 



COCOMO II II --Projektplan Projektplan erstellen 

XXXXXXXXX 



COCOMO II II --Excel-Template Excel-Template 

XXXXX 


Full Time Software Personnel 

(FSWP) 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 


COCOMO II II --Projektplan Projektplan 


Project Personnel per Schedule 

0 1 2 3 4 5 6 8 9 10 11 12 13 14 15 16 17 18 19 20 

Months 

Plans And Requirements Product Design Programming Integration and Test 









Gliederung 




– Beispiel 




COCOMO II II --Objektorientierte Objektorientierte Analyse 

• Funktionalität beschreiben: 

– Use Cases 

– Klassenmodell 

– Schnittstellen 

• Funktionalität bewerten: 

– FPA 

• Projektumgebung bewerten: 

– COCOMO 

• Ergebnisse / Auswertung 

Anforderungen 

Use Cases 

unbewertete Function 

Points 

Klassenmodell 

Function Point 

Analysis 

COCOMO II 

Ergebnis 

Beurteilung der 

Projektumgebung 




COCOMO II II --Anwendungsfall-/Klassendiagramm Anwendungsfall-/Klassendiagramm 

Use Case 

Normalablauf 

Weitere 

Informationen 

Verwalten Schueler 

Lehrer ruft Liste aller Schüler auf, 

selektiert einen Schüler zum Editieren 

oder pflegt einen neuen Schüler ein 


...


COCOMO II II --Erforderliche Erforderliche OOA-Dokumente 

• Benötigt werden die Dokumente, die im Rahmen einer Grobanalyse 

erstellt werden: 

– Use Cases 

• Mögl. detaillierte Beschreibung des Normalablaufes 

• Erfassung der gesamten Funktionalität des Systems 

• GUI-Entwurf, wenn verfügbar 

– Klassenmodell 

• Entity-Klassen (CRC-Karten reichen aus, ein Klassendiagramm ist nicht 

erforderlich) 

• ggf. Datenmodell der Altdaten 

– Schnittstellendateien / Spezifikation 



Quellen 

• JOCHER, T.; HOLL, M. (IZB SOFT): Pi mal Daumen - Ein Aufwandsschätzverfahren 

für objektorientierte Projekte; in OBJEKTspektrum 3/2000, S. 44 ff. 

• BALZERT, Helmut: Lehrbuch der Software-Technik S. 74ff. 

• COCOMO II Reference Manual, University for Southern California 2000 

• COCOMO II Model Definition Manual, University for Southern California 

2000 

• Tool COCOMO II .2000.0 University for Southern California 2000 

• BOEHM, B.: Software Engineering Economics, Prentice Hall 1981 

• Software Cost Estimation with COCOMO II, Prentice Hall PTR, 2000 

• „Fundamentals of Function Point Analysis“ und „Function Points Step by 

Step“, David Longstreet; http://www.SoftwareMetrics.com 

• ROGGE, Klaus-H.: Methodenatlas, Springer, 1995

PTA_ProjektAufwandsschaetzung_Grundlagen.pdf - PTA GmbH

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?