1
Management von Software-Systemen
Aufwands- und Kostenschätzung
2
Aufwandsschätzung
Wie viel Aufwand ist für die Erledigung einer Aufgabe erforderlich?
Wie viel Zeit ist für die Erledigung einer Aufgabe erforderlich?
Wie hoch sind die für eine Aufgabe anfallenden Gesamtkosten?
3
Drei Parameter sind für die Berechnung derGesamtkosten eines Softwareentwicklungsprojekts vonBedeutung:
Hardware- und Softwarekosten, einschließlich Wartung
Reise- und Schulungskosten
Personalkosten
4
Folgende Kostenfaktoren sind auch Teil des Gesamtaufwands:
1. Kosten für die Bereitstellung, Beheizung und Beleuchtung der Büroräume
2. Kosten für unterstützendes Personal
3. Kosten für Netz und Kommunikation
4. Kosten für zentrale Einrichtungen wie Bibliotheken, Erholungseinrichtungen
5. Kosten für Sozialversicherungen, Krankenversicherungsanteile und Mitarbeiterzuwendungen wie Erfolgsbeteiligungen und Betriebsrenten
5
Folgende Faktoren haben einen Einfluss aufden Preis von Software:
Marktchancen
Unsicherheit der Aufwandsschätzung
Vertragsbedingungen
Unbeständigkeit der Anforderungen
Wirtschaftliche Bonität
6
Produktivität (1)
Die Produktivität in einem Fertigungssystem wirdgemessen, indem man die produzierte Stückzahldurch die Anzahl der für die Produktionerforderlichen Personenstunden teilt.
7
Produktivität (2)
Folgende Faktoren haben einen Einfluss auf dieProduktivität der Softwareentwicklung:
- Erfahrung im Anwendungsgebiet
- Prozessqualität
- Projektgröße
- Technische Unterstützung
- Arbeitsumgebung
8
Produktivität (3)
Zur Produktivitätsschätzung werden einige Softwareattributeverwendet, deren Wert an der Entwicklung des erforderlichenGesamtaufwands in zwei Arten von Maßen beteiligt.
1. Größenspezifische Maße: Das gebräuchlichste größenspezifische Maß sind die Zeilen gelieferten Quellcodes.
2. Funktionsspezifische Maße:
~ Function Points
~ Object Points
9
Dauer der Systementwicklung:
Analyse Entwurf Codierung Testen Dokumen tation
Assemblercode 3 W 5 W 8 W 10 W 2 WHöhere Programmier- 3 W 5 W 8 W 6 W 2 Wsprache
Größe Aufwand ProduktivitätAssemblercode 5000 Zeilen 28 W 714 Zeilen/MonatHöhere Programmier- 1500 Zeilen 20 W 300 Zeilen/Monatsprache
10
Function Points (1)
Function Points wurden in den 70er Jahren von A.J. Albrecht (IBM) entwickelt und seither von verschiedenen Autoren und Gremien ergänzt und weiterentwickelt.
Die Grösse eines Informationssystems kann gemessen werden durch eine geeignete Quantifizierung der Funktionalität.
Idee
Entstehung
Unabhängig von der Realisierung
Können bereits ermittelt werden, wenn Anforderungen vorliegen
Weniger anschaulich als Lines of Code
Verfahren ist auf Informationssysteme zugeschnitten
11
Function Points (2)
Zur Berechnung der Gesamtanzahl der Function Points einesProgramms misst man die folgenden Programmfunktionen:
Gewichtungsfaktoren Komplexität
niedrig
Komplexität mitttel
Komplexität hoch
Dateneingaben 3 4 6
Datenausgaben 4 5 7
Benutzerinteraktionen 3 4 6
Externe Schnittstellen 5 7 10
Vom System verwendete Dateien
7 10 15
„Unadjusted Function Point Count“
Bestimmung der Anzahl Function Points(1)
12
Function Points (3)
Der sogenannte Function-Point-Rohwert wird berechnet, indemdie einzelnen Häufigkeiten mit dem geschätzten Gewichtmultipliziert und alle Werte aufsummiert werden.
Unadjusted Function Point Count
UFC=∑ (Anzahl der Elemente eines bestimmten Typs) * Gewicht
13
Durch die Multiplikation von „Unadjusted Function Point Count“ mit einem Korrekturfaktor, der die technischeKomplexität des Systems reflektiert, berechnet man den Wertvon „Adjusted Function Point Count“
Function Points (4)
Adjusted Function Point Count = Korrekturfaktor * „Unadjusted Function Point Count“
Adjusted Function Point Count
14
Aufwandschätzung mit Function Points
Sollen Function Points zur Aufwandschätzung verwendet werden, so muss der Aufwand pro Function Point bekannt sein.
Faustregeln zur Aufwandberechnung:
Kalenderzeit [Monate] = FP 0.4 Anzahl Mitarbeiter = FP/150Aufwand [Personenmonate]
= Kalenderzeit * Anzahl Mitarbeiter
Sollen projektspezifische Faktoren (z.B. die Fähigkeiten der MitarbeiterInnen) berücksichtigt werden, so müssen zusätzliche Korrekturfaktoren verwendet werden.
15
Weitere Faustregeln mit FPs (1)1 Function Point = 320 Statements in Basic Assembler1 Function Point = 213 Statements in Makro Assembler1 Function Point = 128 Statements in C1 Function Point = 107 Statements in COBOL1 Function Point = 107 Statements in FORTRAN1 Function Point = 80 Statements in PL/I1 Function Point = 71 Statements in ADA831 Function Point = 53 Statements in C++1 Function Point = 15 Statements in Smalltalk
für prozedurale Sprachen: 1 FP = 100 Statements für objekt-orientierte Sprachen: 1 FP = 20 Statements
16
Weitere Faustregeln mit FPs (2)
Dokumentationsumfang: Anzahl Seiten = FP 1.15
Schleichende Anforderungen wachsen während der Design bis zur Codierungsphase durchschnittlich um 2% pro Monat.
Anzahl benötigter Test Cases = FP 1.2
Anzahl benötigter Personen für die Wartung der Software = FP/750
17
Bei der Anzahl der Object Points eines Programmshandelt es sich um eine gewichtete Schätzungfolgender Faktoren:
- Die Anzahl der einzelnen angezeigten Bildschirmmasken
- Die Anzahl der erzeugten Berichte
- Die Anzahl der 3GL-Module, die zur Erzeugung des 4GL-Codes entwickelt werden müssen
Object Points
18
Schätzverfahren
Um den Aufwand und die Kosten für eine Softwareschätzen zu können, werden eines oder mehrereder unten beschriebenen Verfahren verwendet: - Analogieschätzung
- Parkinsons Gesetz
- price to win
- Algorithmisches Aufwandsmodell
- Expertenbeurteilung
19
Expertenbeurteilung
• Vorgehen:• Der Aufwand eines Projekts wird auf Grund des
Aufwands eines möglichst ähnlichen früheren Projekts prognostiziert.
• Unterschiede werden so gut wie möglich berücksichtigt.
Schätzverfahren (2)
Einfach und billig
Kann sehr ungenau sein (Die Qualität der Schätzung ist von der Erfahrung der Schätzer und der Qualität der Erfahrungs-daten abhängig)
20
Die neuen Methoden und -verfahren wie
- Objektorientierte anstelle funktionsorientierter Entwicklung
- Client/Server-Systeme anstelle von Großrechnern
- Entwicklung zur und unter Wiederverwendung anstelle von Neuentwicklung aller Systemteile
- …..
erschweren den Experten die genauere Schätzung desAufwands.
21
Top-down und Bottom-up Ansatz
Top-downEr setzt auf Systemebene ein.
Bottom-upEr setzt auf Komponentenebene ein
! Gefahr, dass projektübergreifende Aktivitäten vergessen werden
! Gefahr, dass Schätzung nicht genügend auf Details eingeht
22
Algorithmische Schätzverfahren (1)
Algorithmische Schätzverfahren berechnen den Aufwand mit Hilfe mathematischer Formeln.
Die Formeln sind in der Regel aus der statistischen Analyse historischer Daten entstanden.
Die Formeln verwenden Parameter, die das Produkt charakterisieren und Parameter, die die Bedingungen der Entwicklungsumgebung beschreiben
Die meisten Verfahren basieren auf der folgenden Grundformel: Aufwand = A * Grösse B
23
Der Aufwand für die Erstellung von Software steigt mit wachsender Produktgrösse
überproportional an.
24
0
40
80
120
160
200
240
280
0 40 80 120 160 200 240 280
Programmgrösse
Au
fwa
nd
y= a xe
Kurve 1:e>1
Kurve 2:e=1
Kurve 3:e<1
25
Genauigkeit der Schätzung abhängig von
der Genauigkeit der Eingangsgrössen
der Qualität der Kalibrierung (Anpassung an die
jeweilige Entwicklungsumgebung)
Algorithmische Schätzverfahren (2)
26
COCOMO (Constructive Cost Model)
COCOMO beruht auf einer Kombination von Gleichungen, statistischen Modellen, und Schätzungen von Parameterwerten
Cocomo ist ein Drei-Stufen-Modell
Ausgangspunkte der Schätzung sind:
- Ermittlung der LOC/KDSI
- Ermittlung der Berechnungsfaktoren
27
Basic COCOMO (1) Aufwand [in Personenmonaten] = A * Programmgrösse [inKDSC] B
Entwicklungszeit [in Monaten] = C * Aufwand D
Komplexität des Projekts A B C D
Einfach(„Organic Mode Projects“)
2.4 1.05 2.5 0.38
Mittelschwer(Semi-detached Mode Projects“)
3.0 1.12 2.5 0.35
Eingebettet(„Embedded Mode Projects“)
3.6 1.2 2.5 0.32
28
0
500
1000
1500
2000
2500
3000
3500
4000
Produktgrösse [KDSI]
Ge
sch
ätz
ter
Au
fwa
nd
[P
ers
on
en
mo
na
te]
Basic COCOMO (2)
eingebettet
mittelschwer
einfach
29
Basic COCOMO (3)
30
Intermediate COCOMO (1)
Cost Driver Attributes
Aufwand [in Personenmonaten]=
K1 * ... * K15 * „Aufwand aus Basic COCOMO“
Die mit dem Basic COCOMO ermittelten Werte können noch erheblich genauer gemacht werden, indem man den mit dem Basic COCOMO geschätzten Aufwand mit einer Reihe von Kostenfaktoren (sogenannten Cost Driver Attributes) multipliziert.
31
Produkt-abhängige Attribute -RELLY: Erforderliche Systemzuverlässigkeit
zwischen 0.75-1.40
Rechner-abhängige Attribute -VIRT: Software Entwicklungsumgebung zwischen 0.87-1.30
Personen-abhängige Attribute -LEXP: Erfahrung mit der Programmiersprache zwischen 0.95-1.14
Projektumgebung-abhängige Attribute -MODP: Erfahrung mit modernen Programmiermethoden zwischen 0.82-1.24
Einige Kostenfaktoren
32
Intermediate COCOMO (2)Vorgehen Den „Entwicklungsmodus“ des Projekts identifizieren Die Grösse des Projekts (in Anzahl Codezeilen)
schätzen Die 15 „Cost Driver Attributes“ bestimmen Den Projektaufwand in Personenmonaten und die
Projektdauer in Monaten berechnen
Transparent („man versteht das Modell“)
Modell ist anfällig auf falsches Zuweisen des Entwicklungsmodus
Cost Driver Attributes und insbesondere die Software-Grösse müssen gut geschätzt werden
33
Detailed COCOMO
Im Detailed COCOMO können die Cost Driver Attributes auf einzelne Phasen oder einzelne Subsysteme anstatt nur auf das System als Ganzes angewendet werden.
Höherer Aufwand für seine Implementierung und Anwendung als bei Intermediate Cocomo
34
Das COCOMO 2.0 Modell (1)
Wie das ursprüngliche Modell ist auch das COCOMO 2-Modell einDreistufenmodell
1. Die frühe Prototypenstufe:
- Die Größenschätzungen basieren auf Object Points, die durch eine Standardzahl für die geschätzte Produktivität dividiert wird.
- Zur Schätzung des erforderlichen Aufwands wird eine einfache Größen-/Produktivitätsformel verwendet.
PM=(NOP*(1-%reuse/100))/PROD
35
Das COCOMO 2.0 Modell (2)
2. Die frühe Entwurfsstufe: - Diese Stufe entspricht der abgeschlossenen Festlegung der Systemanforderungen und einem ersten Entwurf
- Die Schätzungen basieren auf Function Points, die dann in die Anzahl der Quellcodezeilen umgewandelt werden.
PM=A * GrößeB * M + PMm
M=PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCED PMm= (ASLOC * (AT/100)) / ATPROD
36
Das COCOMO 2.0 Modell (3)
3. Die Stufe nach dem Architekturentwurf:
- Die erste Aufwandsberechnung wird verfeinert.
- Es werden 17 Attribute anstelle von 7 Attributen verwendet.
- Die Schätzung der Gesamtanzahl der Zeilen an Quellcode wird so angepasst, zwei wichtige Projektfaktoren Berücksichtigung finden:
~ Die Unbeständigkeit der Anforderungen
~ Der Umfang einer möglichen Wiederverwendung
37
Das COCOMO 2.0 Modell (4)
Im Vergleich zum ursprünglichen COCOMO-Modell wird hierder Exponent unter Berücksichtigung von Skalierungsfaktorengeschätzt:
1. Vorhandensein
2. Entwicklungsflexibilität
3. Architektur/Risikoauflösung
4. Teamzusammenhalt
5. Prozessausgereiftheit
38
Die Auswirkung von Skalierungsfaktoren auf dieAufwandsschätzung (1)
Exponent 1.17Systemgröße(einschließlich der Faktoren für die 128,0 DSIa
Wiederverwendung und die Unbeständigkeit derAnforderungen)Erste COCOMO-Schätzung ohne Kostenfaktoren 730 PM
Zuverlässigkeit Sehr hochKomplexität Sehr hochSpeicherbeschränkungen HochWerkzeugverwendung GeringZeitplan
BeschleunigtAngepasste COCOMO-Schätzung 2306 PM
Das COCOMO 2.0 Modell (5)
39
Das COCOMO 2.0 Modell (6)
Zuverlässigkeit Sehr geringKomplexität Sehr geringSpeicherbeschränkungen KeineWerkzeugverwendung Sehr hochZeitplan NormalAngepasste COCOMO-Schätzung 295 PM
Die Auswirkung von Skalierungsfaktoren auf dieAufwandsschätzung (2)
40
Algorithmische Kostenmodelle bei der Projektplanung
Bei der Aufwandsschätzung für ein Projekt sind dreiKomponenten zu berücksichtigen:
1. Die Kosten der Zielhardware, auf der das System ausgeführt werden soll.
2. Die Kosten der Plattform, auf der das System entwickelt wird.
3. Die Kosten des für die Softwareentwicklung
erforderlichen Aufwands.
41
A. Verwendung vorhandener Hardware, eines vorhandenen Entwicklungssystems
und Entwicklungsteam
B. Prozessor- und Speicheraufrüstung
Hardwarekosten steigenErfahrung sinkt
C. Nur Speicher-Aufrüstung
Hardwarekosten steigen
D. ErfahrenesPersonal
E. Neues Entwicklungs-system
Hardwarekosten steigenErfahrung sinkt
F. Personal mitHardwareerfahrung
Optionen für das Management
42
Kosten der Managementoptionen
Option RELY STOR TIME TOOLS LTEX PM SK($) HK($) GK($) A 1,39 1,06 1,11 0,86 1 63 949.393 100.000 1.049.393 B 1,39 1 1 1,12 1,22 88 1.313.550 120.000 1.402.025 C 1,39 1 1,11 0,86 1 60 895.653 105.000 1.000.653 D 1,39 1,06 1,11 0,86 0,84 51 769.008 100.000 897.490 E 1,39 1 1 0,72 1,22 56 844.425 220.000 1.044.159 F 1,39 1 1 1,12 0,84 57 851.180 120.000 1.022.706
SK=Aufwandsschätzung*RELLY*TIME*STOR*TOOL*EXP*15.000$/PM
43
Projektdauer und Personalplanung (1)
Das COCOMO- Modell enthält eine Formel zum Schätzen desEntwicklungszeitraums, der für die Fertigstellung einesProjekts erforderlich ist.
Entwicklungszeit = 3 * (PM) (0.33+0.2*(B-1.01)
44
Die Nenn-Entwicklungszeit entspricht nicht unbedingt der für denProjektplan erforderlichen Zeit. Das wird im COCOMO 2-Modellberücksichtigt.
Projektdauer und Personalplanung (2)
Entwicklungszeit=3 * (PM) (0.33+0.2*(B-1.01)) * SCEDPercentage / 100
45
Danke für Ihre Aufmerksamkeit
Top Related