Management groer Softwareprojekte

Prof. Dr. Holger Schlingloff

Humboldt-Universitt zu Berlin, Institut fr Informatik

Fraunhofer Institut fr Rechnerarchitektur und Softwaretechnik FIRST

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 2

4.2 Schtzverfahren

1. empirische Schtzverfahrendurch die ZielfunktionExpertenschtzungDelphi-Methode

2. algorithmische SchtzverfahrenFunction-point-MethodeCoCoMo, CoCoMo II

3. wissensbasierte Schtzwerkzeuge

4. Aufwandschtzung

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 3

Merkregeln Function-Point-Methode

Setzt frhestens beim Lastenheft ein betrachtet das gesamte Produkt Sichtweise des Auftraggebers Bewertung durch Produktexperten Ist-Aufwand muss ermittelt werden Unternehmensspezifische Faktoren

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 4

Kritik an Function Point Methode

+ Quasistandard, akzeptiert+ basiert auf Produktanforderungen (nicht LOC)+ iteratives Verfahren, anpassbar+ frh einsetzbar (Lastenheft)

- dominiert durch Interessenverband- wenig objektive Werte, Schtzerabhngig- umfangreiche empirische Datenbasis- neigt zur Unterschtzung in frhen Phasen

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 5

weitere Kritikpunkte

bercksichtigt nicht OO-Paradigma Mischung von Produkt- und

Prozesseigenschaften mangelnde theoretische Basis

Weiterentwicklung: Object Points, Feature Points usw.

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 6

Ergebnisse Hausaufgabe

Bestimmen Sie die bewerteten Function Pointsfr das Pizza-Beispiel!

0

1

0--9 20--29

40--49

60--69

80--89

100--109

120--129

140--149

160--169

180--189

>200

FPs

Ergebnisse:

(1) zu geringer Rcklauf fr eine definitive Aussage; machen Sie die Hausaufgaben!

(2) Zuordnung von FPs folgt gewissen Konventionen (z.B. Maske oder Feld je 1 FP)

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 7

LOC, DSI, FP

LOC (lines of code) und DSI (delivered sourceinstructions) sind fast linear voneinander abhngig

Produktivitt (in LOC/PM) bei hheren Programmiersprachen geringer als bei niederen, Gesamtaufwand trotzdem geringer (Debugging!)

300 LOC/PM5 PM1500 LOCJava714 LOC/PM7 PM5000 LOCAssembler

ProduktivittAufwandGre

FP in LOC mit Faktor umrechenbar (ohne ReUse)200-300 fr low-level, 30-100 fr high-level Sprachen

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 8

CoCoMo und CoCoMo II

Grundversion von Boehm, Barry W., Software Engineering Economics (1981)

Schtzung des Aufwandes in Abhngigkeit von Gre und Komplexitt des Projekts sowie sonstiger Rahmenbedingungen

g = geschtzte Grea = berechneter Aufwanda = c * g k

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 9

Annahmen

Ableitbarkeit des Umfangs durch Vergleich mit bereits durchgefhrten Projekten

Wiederverwendeter und generierter Code wird nicht mit gezhlt

Anforderungen bleiben fr die Zeit der Entwicklung konstant

Schtzungen klammern diverse Aufwnde aus (z.B. Administration, Training, Umstellung, ...)

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 10

Vorgehen

Schtzung der Anzahl der im Programm enthaltenen Befehle (in Kilo Delivered Source Instructions, KDSI)

Bestimmung des Schwierigkeitsgrades des Projekteseinfaches Projekt (organic mode)mittelschweres Projekt (semidetached mode)komplexe Projekte (embedded mode)

Einstufung weiterer Kosteneinflussfaktoren auf einer qualitativen Skala von sehr gering bis extrem hoch

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 11

Bedeutung der Stufen

einfach: wohlverstandene Anwendung, kleines Entwicklungsteam

mittel: groes Team mit wenig Erfahrung in vergleichbaren Produkten

komplex: eingebettetes System, hohe Sicherheitsanforderungen

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 12

Faktoren

einfach: a = 2.4 * g 1.05 mittel: a = 3.0 * g 1.12 komplex: a = 3.6 * g 1.20

a = Aufwand in PM, g = Gre in KDSI

exponentielles Wachstum wegen Kommunikationsoverhead

Entwicklungszeit:

einfach: t = 2.5 * a 0.38 mittel: t = 2.5 * a 0.35 komplex: t = 2.5 * a 0.32

t = zu erwartende Gesamtzeit

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 13

Unzulnglichkeit von CoCoMo81

neue Vorgehensweisen und modelle Wiederverwendung, Reengineering COTS, Middleware OO-Paradigma

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 14

CoCoMo II (1990 - 2000)

dreistufiges Modell, detailliertere Schtzung: (a) frhe Prototypenstufe:

Schtzung basiert auf Object-Points mit einer einfachen Formel

(b) frhe Entwurfsstufe:Schtzung basiert auf Function-Points

(c) Stufe nach dem Architekturentwurf:Schtzung basiert auf LOC, Wiederverwendung

Informationen: Siehe http://sunset.usc.edu/COCOMOII/Cocomo.htmlvergleiche auch Sommerville-Buch

http://sunset.usc.edu/COCOMOII/Cocomo.html

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 15

frhe Prototypenstufe (a)

a = (#OP * (1 - %reuse/100 ) ) / PROD#OP = Anzahl Object-Points PROD = OP/PM (standardisierte Produktivitt)

50251374Produktivitt

sehr hochhochnormalgeringsehr gering

Erfahrung

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 16

frhe Entwurfsstufe (b)

nach Erstellung des Pflichtenheftes hnlich zur CoCoMo-81-Methode:

a = c * g k * f + PMm

f = PERS * RCPX * RUSE * PDIF * PREX * FCIL * SCEDc ist anfnglich 2.5g geschtzte Gre in KLOC,k reicht von 1.1 to 1.24, abhngig von Neuheitsgrad, Flexibilitt der Anforderungen, Prozess-Reifegrad und Risikomanagement

PMm = Aufwand fr automatisch erzeugten Code

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 17

Kostenfaktoren

team support facilities(Infrastruktur)FCIL

required schedule(Terminanforderungen)SCED

personnel capability(Mitarbeiterfhigkeiten)PERS

personnel experience(Erfahrung der Mitarbeiter)PREX

platform difficulty (Plattformkomplexitt)PDIF

reuse (Wiederverwendbarkeit)RUSE

reliability and complexity(Zuverlssigkeit und Komplexitt)RCPX

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 18

Bewertung der Kostenfaktoren

Produkt der Kostenfaktoren in einem normalen Projekt ergibt 1

Bewertung jedes Faktors als extrem niedrig, sehr niedrig, niedrig, normal, hoch, sehr hoch oder extrem hoch

Werte laut Tabelle, von 0.5 bis 2.7

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 19

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 20

Stufe nach dem Architekturentwurf (c)

selbe Grundformel wie bei (b): a = f * g k Exponent hngt von 5 Skalierungsfaktoren ab

(siehe nchste Folie)

genauere Grenschtzungen fr Einflussfaktor, 17 statt 7 Kostenfaktoren

Unbestndigkeit der Anforderungen: Schtzung des nderungsaufwandes in LOCWiederverwendung wird bercksichtigtWertebereich von 0.7 bis 1.7

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 21

Skalierungsfaktoren

Vorhandenseinfrhere Erfahrungen mit hnlichen Projekten

EntwicklungsflexibilittFreiheit der Gestaltung des Entwicklungsprozesses

Architektur/RisikoauflsungUmfang der durchgefhrten Risikoanalyse

TeamzusammenhaltVertrautheitsgrad der Entwickler untereinander

Prozessausgereiftheit(5 CMM)

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 22

Berechnung des Exponenten

jeder der Skalierungsfaktoren wird mit einer Zahl zwischen 5 (sehr gering) und 0 (sehr hoch) bewertet (Minuspunkte)

s = Summe der Skalierungsfaktoren (0s25) k = 1.01 + s/100

a = f * g k

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 23

Beispiel

neuartiges Projekt Vorhandensein = 4unabhngiger Prozess Entwicklungsflexibilitt = 1keine Risikoanalyse Risikoauflsung = 5neues Team Teamzusammenhalt = 3CMM = 2 Prozessausgereiftheit = 3

= 16 k = 1.17

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 24

17 Kostenfaktoren

ProduktattributeEigenschaften des zu entwickelnden Produkts

ComputerattributeBeschrnkungen durch verwendete Plattformen

PersonalattributeErfahrungen und Fhigkeiten der Mitarbeiter

Projektattributebesondere Eigenschaften des Projektes

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 25

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 26

Produktattribute

RELY: verlangte Zuverlssigkeit, 0.75 .. 1.4 CPLX: Produktkomplexitt, 0.73 .. 1.74 DOCU: Dokumentationsbedarf, 0.81 .. 1.23 DATA: Gre der Datenbank, 0.9 .. 1.28 RUSE: Wiederverwendungsgrad, 0.95 .. 1.24

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 27

Plattformattribute

TIME: Ausfhrungszeitkritikalitt, 1 .. 1.66 PVOL: Volatilitt der SW/HW-Plattform STOR: Speicherbeschrnkungen

11.12.2002 H. Schlingloff, Management groer Softwareprojekte 28

Personalattribute

ACAP: Analysten-Fhigkeiten, 1.46 .. 0.71 (!) PCON: Kontinuitt des Personals, 1.29 .. 0.81 PEXP: Erfahrung mit der Plattform PCAP: Fhigkeiten der Programmierer AEXP: Erfahrung im Anwendungsbereich LTEX: programmiersprachliche Kompetenz,

0.95 ..1.14

11.12.2002 H. Schlingloff, Manag