Sie sind auf Seite 1von 9

Aufwandsschätzung am Beispiel COCOMO II

Daniela ESBERGER
0160072
daniela.esberger@edu.uni-klu.ac.at

Abstract 1.1. Kostenarten

Nur allzu oft wird aus vermeintlich logischen Grün- Bei Softwareprojekten unterscheidet man drei Ar-
den wie beispielsweise Zeitersparnis auf eine sorgfäl- ten von Kosten [SOMM01]:
tige Aufwandsschätzung verzichtet. Dabei bildet sie − Hardware- und Softwarekosten
einen Grundpfeiler des Projektes und sollte daher − Reise- und Schulungskosten
auch ihrem Stellenwert entsprechend behandelt wer- − Personalkosten
den. Im Speziellen bei Projekten für externe Auftrag-
geber bildet die Aufwandsschätzung die Basis jeder Die ersten beiden Punkte sind im Vergleich zu den
Angebotserstellung, aber auch bei internen Projekten Personalkosten nahezu zu vernachlässigen. Zwar kön-
sollte sie nicht vernachlässigt werden. Oft wird eine nen speziell die Reisekosten bei Projekten, die an ver-
Schätzung nur zu Beginn durchgeführt und auf eine schiedenen Standorten realisiert werden, ein erhebli-
regelmäßige Kontrolle und Beobachtung des Verlau- ches Ausmaß annehmen. Sie sind dennoch meist eher
fes, um gegebenenfalls vorbeugend einzugreifen, ver- gering. Außerdem kann durch moderne Kommunikati-
gessen. Im Folgenden soll das Thema Aufwandsschät- onsformen (zB E-Mail, Video- und Telefonkonferen-
zung näher beleuchtet werden und mit COCOMO II zen) diesen Kosten teilweise entgegengewirkt werden.
dem Leser ein Werkzeug zur praktischen Anwendung Der Personalaufwand hingegen ist der wichtigste
geboten werden. und größte Kostenfaktor. Aus diesem Grund wird der
errechnete Aufwand des Projektes in der Regel in Per-
sonenmonaten angegeben. Dies führt wiederum dazu,
1. Aufwandsschätzung dass die Aufwandsschätzung gemeinsam mit der Zeit-
planung erfolgt.
“Was man nicht misst, das kann man nicht steuern.“ Bei den Personalkosten handelt es sich nicht nur
Dieser Satz von Tom de Marco trifft den Nagel auf den um die Entlohnung der beteiligten Programmierer,
Kopf. Zu Beginn eines Softwareprojektes sind oft Fra- sondern auch andere Kosten werden in diesen Satz
gen über den Arbeitsaufwand, die Dauer, die Kosten eingerechnet. Dies sind unter anderem:
und die Anzahl der Mitarbeiter, die für die Durchfüh- − Kosten für die Bereitstellung, Beheizung und Be-
rung des Projektes benötigt werden, durch den Projekt- leuchtung der Büroräume,
leiter zu klären. Obwohl zu diesem Zeitpunkt genaue − Kosten für unterstützendes Personal (zB Buchhal-
Informationen fehlen, sollte dennoch eine möglichst ter, Sekretäre, Reinigungspersonal)
präzise Schätzung vorgenommen werden, da bei- − Kosten für Netz und Kommunikation
spielsweise aufgrund dieser Daten ein Angebot erstellt − Kosten für zentrale Einrichtungen (zB Bibliothek,
wird und dies weder zu hoch noch zu niedrig ausfallen Aufenthaltsraum, Kaffeeküche)
darf. Dies stellt natürlich ein erhebliches Problem dar, − Kosten für sozialen Aufwand (zB Sozialversiche-
das mit Hilfe der verschiedenen Methoden der Auf- rung) und Mitarbeiterzuwendungen (zB Erfolgs-
wandsschätzung (siehe Kapitel 1.2) gelöst werden beteiligung)
kann. Aufwandsschätzung ist keine einmalige Aufgabe
bei der Projektplanung, sondern sollte regelmäßig 1.2. Methoden
durchgeführt werden um Abweichungen zu erkennen
und um frühzeitig entsprechende Maßnahmen zu er- Zur Aufwandsschätzung stehen nach Barry Boehm
greifen. [SOMM01] folgende Methoden zur Verfügung [BOEH81]:
1.2.1. Algorithmische Modelle. Algorithmische Mo- vermeiden, wurde die Delphi-Methode entwickelt, die
delle bieten ein oder mehrere Berechnungsverfahren, in verschiedenen Bereichen einsetzbar ist. Kurz zu-
die eine Vielzahl an Einflussfaktoren berücksichtigen. sammengefasst funktioniert die Delphi-Methode wie
Diese Berechnungsverfahren können linear (Fakto- folgt: Die Experten bleiben untereinander anonym.
ren werden addiert), multiplikativ (Faktoren werden Dadurch können persönliche Faktoren größtenteils
multipliziert), analytisch (mathematische Funktion, die ausgeschlossen werden. Eine Monitorgruppe holt die
nicht linear oder multiplikativ ist), tabellarisch (Werte Meinungen der Experten ein und versucht durch eine
werden einer Tabelle entnommen) oder zusammenge- Befragung dieser zu einem Ergebnis zu kommen.
setzt (Kombination aus den bereits genannten Verfah- Problematisch ist hier allerdings der hohe Zeitbedarf
ren) sein. und so ist dies nur bei großen Projekten auch wirklich
Im Vergleich zu den anderen Arten haben algo- sinnvoll.
rithmische Methoden eine Reihe von Vorteilen. Sie Da die Stärken und Schwächen der Expertenbefra-
sind objektiv, können nicht durch Wunschvorstellun- gung genau konträr zu denen der algorithmischen Mo-
gen oder persönliche Ansichten beeinflusst werden, delle sind, wird diese Methode oft zu deren Unterstüt-
sind wiederholbar und effizient. Andererseits haben sie zung verwendet. Die Stärken liegen vor allem darin,
auch einige Schwächen. Sie basieren auf früheren Pro- dass neue Techniken, Architekturen, Anwendungen
jekten und dabei stellt sich natürlich die Frage, wie und außerordentliche Einflüsse berücksichtigt werden
repräsentativ diese Projekte für die Zukunft sind. Au- können. Der Nachteil dieser Methode liegt in der Sub-
ßerdem können sie keine außerordentlichen Einflüsse jektivität. Die Schätzung ist nur so gut wie der Exper-
berücksichtigen und wie jedes andere Modell auch, te, wobei hier natürlich immer eine persönliche Note
sind sie abhängig von der Qualität der Eingabedaten miteinfließt.
und der Bewertung der Einflussfaktoren.
Die zwei wohl bekanntesten Vertreter dieser Me- 1.2.3. Analogiemethode. Diese Methoden versuchen
thode sind COCOMO, das in einem späteren Kapitel einen Bezug zwischen vergangenen Entwicklungen
noch behandelt wird, und die Function Point-Analyse und der geplanten Entwicklung herzustellen. Man be-
von Allen Albrecht. dient sich hier Erfahrungsdaten aus ein oder mehreren
abgeschlossenen Projekten unter der Verwendung von
1.2.2. Expertenbefragung. Bei dieser Methode wer- Vergleichskriterien. Die Analogiemethode kann ent-
den ein oder mehrere Experten befragt. Sie erstellen weder auf das ganze Projekt oder auf Teile dessen an-
ihre Schätzung aufgrund ihrer Erfahrung und ihres gewendet werden. Sie hat vor allem den Vorteil, dass
Wissens. Man unterscheidet hier also primär zwischen sie auch schon in den Frühphasen eines Projektes ein-
Einzel- und Mehrfachbefragungen. Bei der Einzelbe- gesetzt werden kann und sich an aktuellen und tatsäch-
fragung legt ein einziger Experte allein die Schätzwer- lichen Erfahrungswerten orientiert. Andererseits ent-
te hinsichtlich Aufwand, Dauer und Kosten fest. Han- steht natürlich das Problem, dass nicht genau geklärt
delt es sich um einen erfahrenen Experten, der bereits werden kann, inwiefern die Einflussfaktoren von frü-
an mehreren ähnlichen Projekten mitgearbeitet hat, heren Projekten sich auch tatsächlich auf ein aktuelles
dann haben die vorgeschlagenen Schätzwerte im All- auswirken.
gemeinen eine hohe Genauigkeit. Andernfalls können
die ermittelten Schätzwerte weit entfernt von den künf- 1.2.4. Parkinsons Gesetz. Laut dem Gesetz von Par-
tigen Istwerten liegen. kinson, nimmt die Dauer einer Arbeit immer den Zeit-
Sind mehrere Experten beteiligt, kommt es zu ver- raum an, der ihr zur Verfügung steht. Man geht also
schiedenen Ergebnissen, die auf einen Endwert ge- von einem festen Zeitrahmen und den Ressourcen
bracht werden müssen. Um ein gemeinsames Resultat (Mitarbeitern), die zur Verfügung stehen, aus. Hat man
zu erreichen, gibt es zwei Möglichkeiten: Einerseits nun also 3 Monate bis zur Fertigstellung des Auftrages
kann ein Mittelwert errechnet werden. Hier können Zeit und verfügt man über 6 Mitarbeiter, so braucht
Extremwerte allerdings zu einer Verschleierung füh- man nach diesem Gesetz 18 Personenmonate. In man-
ren. Andererseits kann in einer Diskussion, in die alle chen Fällen hat sich diese Schätzung als sehr genau
Experten miteingebunden werden, ein einheitliches erwiesen, in anderen wiederum als stark abweichend.
Ergebnis gefunden werden. Eine herkömmliche Be- Diese Methode wird nicht empfohlen.
sprechung, wo alle Experten zusammenkommen und
sich auf eine Lösung einigen sollen, hat aber markante 1.2.5. Price-To-Win. Hier werden die Projektkosten
Nachteile. Mitglieder können leicht durch wortge- durch die beim Auftraggeber verfügbaren Mittel be-
wandtere Personen mit mehr Durchsetzungskraft oder stimmt. Der zu erwartende Aufwand wird durch das
Autorität in den Schatten gestellt werden. Um dies zu Budget des Auftraggebers und nicht durch das Projekt
selbst bestimmt. Hier kommt es oft zu Überschreitun- COCOMO II ist gut für die Anwendung in Unter-
gen des Zeitplans und des Budgets, was wiederum zu nehmen geeignet und gehört zu den wenigen Schätz-
Unzufriedenheit führt. verfahren, die alle Einflüsse (Quantität, Qualität, Pro-
Price-To-Win hat eine Vielzahl von Ausschreibun- jektdauer und Produktivität) berücksichtigen.
gen für viele Softwareunternehmen gewonnen. Aller- [KNOE91]
dings sind viele davon verständlicherweise heute nicht Außerdem spricht für COCOMO, dass es gut do-
mehr am Markt. kumentiert ist sowie häufig verwendet und ausgewertet
wird. Des Weiteren ist es frei verfügbar und wird von
1.2.6. Top-Down. Bei der Top-Down-Methode wird Public-Domain und kommerziellen Werkzeugen unter-
zuerst der Gesamtaufwand für ein Projekt geschätzt stützt. [SOMM01]
und dann wird dieser für die einzelnen Komponenten Aus verschiedenen Gründen, die in Kapitel 2.1 nä-
heruntergebrochen. Dieses Verfahren kann in Kombi- her ausgeführt werden sollen, kam es zu einer Überar-
nation mit jeder anderen bisher genannten Methode beitung des ursprünglichen Modells, das heute
erfolgen. Vorteilhaft hierbei ist, dass das Projekt als COCOMO 81 genannt wird, und zur Neuentwicklung
eine Einheit gesehen wird und nicht auf Kosten für und Veröffentlichung im Jahr 2000 von COCOMO II.
Systemintegration, Benutzerhandbuch etc. vergessen
wird. Der Nachteil ist allerdings, dass auf Schwierig- 2.1. Von COCOMO zu COCOMO II
keiten in Einzelfällen oft nicht im Vorhinein als solche
erkannt werden. Mittels empirischen Untersuchungen erkannte Bar-
ry Boehm einen funktionalen Zusammenhang zwi-
1.2.7. Bottom-Up. Die Bottom-Up-Methode ist das schen Systemgröße (nach Anzahl der Codezeilen) und
Gegenstück zu Top-Down und kann ebenso in Kombi- dem Erstellungsaufwand. Da eine derartige Gleichung
nation zu den anderen Methoden angewandt werden. keine zufriedenstellenden Ergebnisse lieferte, berück-
Es wird jede einzelne Komponente geschätzt und zu sichtigte er zusätzlich Einflussfaktoren für Qualitätsan-
einem Gesamtaufwand addiert. Die Vor- und Nachteile forderungen und Produktivität. Auf diesem Wege ent-
sind demzufolge gegengleich zu Top-Down. stand COCOMO. [KNOE91]
Je nach Entwicklungskomplexität und
-schwierigkeit gibt es bei COCOMO 81 [BOEH00],
2. COCOMO II wie das ursprüngliche Modell heute genannt wird, drei
Berechnungen. Man unterscheidet hier zwischen ein-
COCOMO zählt zu den algorithmischen Modellen fach (basic), mittel (intermediate) und detailliert (detai-
zur Kosten- und Aufwandsschätzung von Software. led). Ausgangspunkt für die Schätzung ist die Größe
COCOMO wurde Ende der siebziger Jahre erschaffen des Projektes, also die Schätzung der Anzahl der benö-
und 1981 von Barry Boehm veröffentlicht. tigten Codezeilen in KDSI (kilo delivered source in-
Barry W. Boehm studierte Mathematik in Harvard struction). Mit Hilfe einer Formel werden dann die
und ist heute Professor an der University of Southern Personenmonate errechnet. Eine Erhöhung der Qualität
California. Den Großteil seiner Arbeiten entwickelte er der Schätzung kann mittels Multiplikation vorbe-
während seiner Beschäftigung bei TRW, wo er von stimmter Einflussfaktoren, deren Werte aus einer Ta-
1973 bis 1989 Hauptwissenschaftler der Verteidi- belle zu entnehmen sind, erfolgen.
gungssystemgruppe war. Neben COCOMO entwickel- Seit Entwicklung von COCOMO 81 haben sich im
te er auch das spiralförmige Modell des Softwarepro- Bereich Softwareentwicklung drastische Veränderun-
zesses, die Theorie W (win-win), das TRW Software- gen ergeben, die eine Überarbeitung des ursprüngli-
produktivitätssystem und die Quantensprungumge- chen Modells unumgänglich machten. COCOMO 81
bung. Sein heutiger Forschungsbereich umfasst Soft- basiert auf dem Wasserfallmodell, was heute als über-
wareprozessmodellierung, Software Requirements holt und veraltert gilt, und auf der Annahme, dass
Engineering, Softwarearchitekturen, Softwaremaßsys- Software immer neu entwickelt wird. Mittlerweile
teme, Kostenmodelle, Softwaretechnikumgebungen spricht man von komponentenbasierter Softwareent-
und wissensbasierte Softwaretechnik. [TUWI04] wicklung, wo bereits fertige Komponenten zusammen-
Das COnstructive COst MOdel (COCOMO) ba- gefügt werden und es so zu einer Wiederverwendung
siert auf empirischen Werten, die aus Datensammlun- der Software kommt. Des Weiteren wurde die Ent-
gen aus verschiedenen Projekten und Analysen ge- wicklung von Prototypen nicht berücksichtigt. Heute
wonnen wurden. [SOMM01] ist dies jedoch eine weit verbreitete Methode. Auch
werden viel mehr gekaufte Subsysteme eingesetzt,
Programmiersprachen der 4. Generation (4GLs) ver-
wendet, vorhanden Software wird umgestaltet und kommunikation, Luft- und Raumfahrt, Automo-
daraus neue kreiert und häufig wird die Entwicklung bilindustrie sowie im Finanzsektor benötigt wird.
durch ein CASE-Werkzeug unterstützt. Um all diese Auf unterster Ebene findet man die Programmie-
Änderungen auch in der Aufwandsschätzung dement- rung der Infrastruktur. Typische Bereiche sind bei-
sprechend zu berücksichtigen, überarbeitete Barry spielsweise Betriebssysteme, Datenbankmanagement-
Boehm dahingehend das Modell und veröffentlichte im systeme, Benutzerschnittstellenmanagementsysteme
Jahr 2000 COCOMO II. [SOMM01] und Netzwerksysteme. Bekannte Firmen auf diesem
Sektor sind Microsoft, Netscape, Oracle, Sybase,
2.2. Zielgruppen 3Com und Novell. [BOEH00]

Für wen eignet sich überhaupt COCOMO II? Diese 2.3. Das Modell
Frage soll hier im Folgenden geklärt werden. Man geht
hier, wie Abbildung 1 zeigt, von fünf verschiedenen COCOMO II ist im Grunde genommen nicht nur
Gruppierungen aus. ein einzelnes Modell. Je höher die Entwicklungsstufe
Der Großteil wird hier der Endbenutzer- und das Fortschreiten des Projektes, umso genauer
programmierung zugeordnet. Hier handelt es sich in kann auch die Abschätzung erfolgen (siehe Abbil-
der Regel um kleine Projekte, wo der Programmierer dung 2). Daher besteht COCOMO II aus drei Teilmo-
in vordefinierten Umgebungen (zB Tabellenkalkulati- dellen, die sich bezüglich Skalenfaktoren, Aufwands-
on, SQL-Client, Planungssysteme) arbeitet und das multiplikatoren und Modellkonstanten unterscheiden.
Programm auf die Bedürfnisse des Endbenutzers ab- Hier ein kurzer Überblick:
stimmt. Hier wird aufgrund des geringen Projektum- 1. The Application Composition Model
fangs nur eine sehr einfache Aufwandsschätzung benö- (Die frühe Prototypenstufe)
tigt. Die erste grobe Größenschätzung basiert auf der
Methode der Object Points und erfolgt mit einer
Endbenutzerprogrammierung einfachen Größen-/Produktivitätsformel.
(55 Millionen Programmierer in den USA – 2005) 2. The Early Design Model
Generierung v. (Die frühe Entwurfsstufe)
Applikationen Aufbau v. Ap- In dieser Stufe sind bereits alle Systemanforde-
Systemintegration
u. Hilfsmittel plikationen (0.7 (0.7 Millionen) rungen niedergeschrieben und es existiert viel-
für d. Aufbau Millionen) leicht auch schon ein erster Entwurf. Die Schät-
(0.6 Millionen) zung basiert auf Function Points.
Infrastruktur 3. The Post-Architecture Model
(0.75 Millionen)
(Die Stufe nach dem Architekturentwurf)
Abbildung 1. Bereiche der SW-Entwicklung [BOEH00]
Die Systemarchitektur wurde bereits entworfen
und demzufolge kann eine genauere Bewertung
Die mittlere Ebene umfasst folgende drei Unter-
erfolgen. Das Post-Architecture Model verwendet
gruppen:
zur Feinabstimmung der Schätzung eine Vielzahl
1. Generierung von Applikationen und Hilfsmittel
von Multiplikatoren, die u.a. die Fähigkeiten der
für den Aufbau
Mitarbeiter sowie die Produkt- und Projekteigen-
Es erfolgt häufig eine Wiederverwendung von
schaften ausdrücken. [SOMM01]
Komponenten, aber auch neue Funktionalitäten
werden hinzugefügt. Die bekanntesten Firmen in
diesem Sektor sind beispielsweise Microsoft, Net-
scape, Lotus, Novell und Borland.
2. Aufbau von Applikationen
Hier kann keine Wiederverwendung der Kompo-
nenten aufgrund von Umfang oder Diversifizie-
rung der Produkte erfolgen. Allerdings können
die Komponenten (zB graphische Benutzer-
schnittstellen) leicht mittels CASE-Werkzeugen
erstellt werden.
3. Systemintegration
Man spricht hier von systemnaher („embedded“)
Software, die vor allem in Bereichen wie Tele- Abbildung 2. COCOMO II Modellphasen [BOEH00]
PM = (OP*(1-%reuse/100))/PROD
2.3.1. The Application Composition Model. Die frü- bzw.
he Prototypenstufe, wie das Application Composition PM = NOP/PROD
Model auch genannt wird, dient als Unterstützung bei NOP = OP*(1-%reuse/100)
der Schätzung von Prototypen und Projekten, die eine Abbildung 3. Formel: Application Composition Model
Software hervorbringen sollen, die aus vorhandenen
Komponenten zusammengesetzt wird. 2.3.2. The Early Design Model. Dieses Modell wird
In dieser frühen Phase ist es noch sehr schwer, eine im Deutschen “Die frühe Entwicklungsstufe” genannt.
genaue Bewertung durchzuführen. Die Basis stellen Die Schätzungen, die in dieser Stufe erfolgen, basieren
hier Object Points dar. Sie sind bei Programmierspra- auf der Standardformel algorithmischer Modelle (siehe
chen der 4. Generation (anwendungsbezogene bzw. Abbildung 4). Das Modell wird, wie sein Name bereits
applikative Sprachen) und anderen vergleichbaren aussagt, in der frühen Phase der Entwicklung, wo noch
Sprachen eine Alternative zu Function Points, da sie wenige Informationen über Umfang des Projektes,
im frühen Stadium noch leichter zu schätzen sind. Bei Zielplattform, Eigenschaften der Personen, die bei die-
Object Points handelt es sich nicht um Objektklassen sem Projekt mitarbeiten, und keine Einzelheiten des
sondern um eine gewichtete Schätzung der folgenden Entwicklungsprozesses vorliegen, verwendet. Es eig-
Faktoren: net sich sowohl für die Generierung von Applikationen
– Anzahl der angezeigten Bildschirmmasken als auch für die Systemintegration und die Entwick-
Einfache Masken und Dialogfelder gelten als 1 lung von Infrastruktur (siehe Zielgruppen). [BOEH00]
Object Point, komplexere als 2 und sehr komplexe
als 3. PM = A*GrößeE*M
– Anzahl der erzeugten Berichte bzw.
Einfache Berichte zählen für 2, komplexere für 5 PM = A*GrößeE*M+PMm
und schwer erzeugbare Berichte für 8 Object
Points. M = PERS*RCPX*RUSE*PDIF*PREX*FCIL*SCED
– Anzahl der Module in Programmiersprachen der PMm = (ASLOC*(AT/100))/ATPROD
3. Generation (höhere Programmiersprachen) Abbildung 4. Formel: Early Design Model
Jedes Modul, das in einer höheren Programmier-
sprache erzeugt werden muss, zählt für 10 Object Für den Koeffizient A empfiehlt Barry Boehm in
Points. dieser Phase den Erfahrungswert 2,5. Dieser Wert ba-
siert auf der Auswertung der Datenmenge von zahlrei-
Die errechneten Object Points werden in weiterer chen Projekten. [SOMM01]
Folge durch einen Standardwert für die Produktivität Die Größe wird in KSLOC (kilo source lines of
dividiert. Dieser Wert ist abhängig von der Erfahrung code), also die Quellcodezeilen in Tausend, angege-
und Fertigkeit des Programmierers sowie von den Fä- ben. Zur Erleichterung kann hier auch die Anzahl der
higkeiten der verwendeten CASE-Werkzeuge und lässt Function Points in der Software geschätzt werden und
sich aus Tabelle 1 ersehen. [BOEH00] mit Hilfe von Standardtabellen in SLOC (source lines
of code) und in weiterer Folge in KSLOC umgerechnet
Tabelle 1. Produktivität in Object Points pro Monat werden. Diese Standardtabellen geben die Anzahl der
Erfahrungen u.
sehr sehr SLOC pro Function Point für jede Programmierspra-
Fähigkeiten d. gering mittel hoch
gering hoch che an. Tabelle 2 gibt hier die Werte für eine Auswahl
Entwicklers
Fähigkeiten der sehr sehr der wichtigsten Programmiersprachen an. [BOEH00]
gering mittel hoch
CASE-Werkzeuge gering hoch
PROD Tabelle 2. Umrechnungstabelle FP in SLOC
4 7 13 25 50
(NOP/Monat) Sprache SLOC/UFP Sprache SLOC/UFP
4GLs 20 Lisp 64
Da in dieser Phase durchaus bereits erstellte Kom- Assembly 320 Pascal 91
ponenten wieder verwendet werden, muss auch ein C 128 Perl 27
dementsprechender „Reuse-Anteil“ (in Prozent –
C++ 55 Prolog 64
%reuse) miteinbezogen werden. Daher werden die
HTML 15 VB 5.0 29
Object Points (OP) um diesen Faktor gewichtet (NOP).
Java 53 Visual 34
Die Formel zur Berechnung des Aufwandes in Per-
C++
sonenmonaten (PM) sieht wie folgt aus [SOMM01]:
Der Exponent E soll den steigenden Aufwand bei (die unterstützenden Einrichtungen)
wachsender Projektgröße ausdrücken. Der Wert ist − SCED – Required Development Schedule
hier nicht genau festgelegt, sondern kann zwischen (der Zeitplan)
1,01 und 1,26 liegen. Abhängig ist die Größe dieser Auch diese Faktoren werden mittels einer Skala
Zahl von der Neuartigkeit des Projekts, der Entwick- (siehe Tabelle 4) bewertet. Multipliziert man die Er-
lungsflexibilität, den verwendeten Prozessen zur Risi- gebnisse, gelangt man zum Multiplikator M.
kolösung, dem Teamzusammenhalt und der Ausge-
reiftheit des Prozesses. [BOEH00] Tabelle 4. Projekt- und Prozessfaktoren
Zur Berechnung des Exponenten werden nun die --- -- - ~ + ++ +++
fünf Skalierungsfaktoren (siehe Tabelle 3) nach einer RCPX 0,49 0,60 0,83 1 1,33 1,91 2,72
Sechs-Punkte-Skala (5 – sehr gering bis 0 – besonders RUSE 0,95 1 1,07 1,15 1,24
hoch) bewertet. Die Ergebnisse werden addiert, durch PDIF 0,87 1 1,29 1,81 2,61
hundert dividiert und zum fixen Wert 1,01 hinzuge- PERS 2,12 1,62 1,26 1 0,83 0,63 0,50
zählt. PREX 1,59 1,33 1,22 1 0,87 0,74 0,62
FCIL 1,43 1,30 1,10 1 0,87 0,73 0,62
Tabelle 3. Skalierungsfaktoren für den Exponenten SCED 1,43 1,14 1 1 1 n/a
Faktor Bemerkungen
Neuartigkeit Erfahrung mit dieser Art von Pro-
Alternativ zur oben genannten Bewertung können
jekten
die Faktoren auch durch eine Kombination der im Post
0 – totale Vertrautheit
Architecture Model verwendeten Multiplikatoren be-
5 – keine Erfahrung
rechnet werden. [BOEH00]
Entwicklungs- Flexibilität im Entwicklungsprozess Wird ein bedeutender Teil des Codes automatisch
flexibilität 0 – keine Vorgaben der Prozesse erstellt, so sollte dies auch berücksichtigt werden. Hier
5 – Vorgabe des zu verwendenden empfiehlt sich ein Formel mit der zusätzlichen Variab-
Prozess le PMm: PM = A*GrößeE*M+PMm (siehe auch Abbil-
Architektur/ Umfang der Risikoanalyse dung 4). Obwohl auch hier meist manuelle Eingaben
Risikoauflö- 0 – vollständige Analyse erforderlich sind, ist der Produktivitätsgrad signifikant
sung 5 – geringe/keine Analyse höher als bei manuell erstelltem Code.
Teamzusam- Vertrautheit und Zusammenarbeit PMm berechnet sich mit der folgender Formel:
menhalt im Team PMm = (ASLOC*(AT/100))/ATPROD (siehe auch
0 – integriertes und effektives Team Abbildung 4). ASLOC (automatically generated source
5 – sehr schwierige Interaktion lines of code) stellt, wie der Name bereits sagt, die
Ausgereiftheit Ausgereiftheitsgrad des Prozesses Anzahl der Zeilen dar, die automatisch erstellt wurden.
des Prozesses abhängig vom CMM Maturity ATPROD steht für den Grad der Produktivität für die-
Questionnaire. Schätzung durch se Codeerstellung. Weiters ist ein bestimmter Aufwand
Abzug des Ausgereiftheitsgrades für die Herstellung einer Schnittstelle zwischen dem
des CMM-Prozesses vom Wert 5. erzeugten Code und dem restlichen System nötig. Da
dieser vom prozentuellen Anteil (AT) des automatisch
Der Multiplikator M in der Formel des Early De- erstellten Codes abhängig ist, ist auch dies zu berück-
sign Models (siehe Abbildung 4) gibt eine vereinfachte sichtigen. [SOMM01]
Reihe von Projekt- und Prozessfaktoren wieder. Dazu
zählen: 2.3.3. The Post-Architecture Model. Das Post-
− RCPX – Product Reliability and Complexity Architecture Model, also die Stufe nach dem Architek-
(die Produktzuverlässigkeit und –komplexität) turentwurf, ist das detaillierteste der drei Modelle. Es
− RUSE – Developed for Reusability sollte dann verwendet werden, wenn bereits die Soft-
(der benötigte Wiederverwendungsgrad) warearchitektur festgelegt wurde. Einsatz findet das
− PDIF – Platform Difficulty Modell in den Breichen Generierung von Applikatio-
(der Schwierigkeitsgrad der Plattform) nen, Systemintegration und Infrastrukturprogrammie-
− PERS – Personnel Capability rung (siehe Zielgruppen).
(die Mitarbeiterfähigkeiten) Die Schätzung für dieses Modell basiert auf der
− PREX – Personnel Experience gleichen Grundformel wie das Early Design Model
(die Erfahrung des Personals) (siehe Abbildung 4 und Abbildung 5). Da zu diesem
− FCIL – Facilities späteren Zeitpunkt nun schon mehrere Informationen
zur Verfügung stehen, werden statt den sieben Projekt- − Projektattribute
und Prozessfaktoren nun 17 Einflussgrößen (oft auch − TOOL – Use of Software Tools
„Cost Driver“ genannt) verwendet, die durch diesen (die Verwendung von Softwarewerkzeugen)
zusätzlichen Detailliertheitsgrad zu einem genaueren − SITE – Multisite Development
Ergebnis führen sollen. [BOEH00] (die Anzahl der Arbeiten, die an mehreren
Stellen ausgeführt werden, und die Kommu-
PM = A*GrößeE*M nikation zwischen diesen Stellen)
bzw. − SCED – Required Development Schedule
PM = A*GrößeE*M+PMm (die Komprimierung des Entwicklungsplans)

M = Π(Cost Driver) Wie auch beim Early Design Model können diese
PMm = (ASLOC*(AT/100))/ATPROD Größen bewertet werden und ihre Produktsumme er-
Abbildung 5. Formel: Post-Architecture Model gibt wiederum den Multiplikator M. Die Werte sind
folgender Tabelle zu entnehmen [BOEH00]:
Die Einflussfaktoren sind vier verschiedenen
Gruppen zugeteilt: Tabelle 5. Cost Driver beim Post-Architecture Model
− Produktattribute -- - ~ + ++ +++
− RELY – Required Software Reliability RELY 0,82 0,92 1 1,10 1,26 n/a
(die erfolgreiche Systemzuverlässigkeit) DATA n/a 0,90 1 1,14 1,28 n/a
− DATA – Data Base Size CPLX 0,73 0,87 1 1,17 1,34 1,74
(die Größe der verwendeten Datenbank) RUSE n/a 0,95 1 1,07 1,15 1,24
− CPLX – Product Complexity DOC
0,81 0,91 1 1,11 1,23 n/a
(die Komplexität der Systemmodule) U
− RUSE – Required Reusability TIME n/a n/a 1 1,11 1,29 1,63
(der benötigte Wiederverwendungsgrad) STOR n/a n/a 1 1,05 1,17 1,46
− DOCU – Documentation match to LC needs PVOL n/a 0,87 1 1,15 1,30 n/a
(der Umfang der erforderlichen Dokumentati- ACAP 1,42 1,19 1 0,85 0,71 n/a
on) PCAP 1,34 1,15 1 0,88 0,76 n/a
− Computerattribute PCON 1,29 1,12 1 0,90 0,81
− TIME – Execution Time Constraint APEX 1,22 1,10 1 0,88 0,81 n/a
(die Beschränkung der Ausführungszeit) PEXP 1,19 1,09 1 0,91 0,85 n/a
− STOR – Main Storage Constraint LTEX 1,20 1,09 1 0,91 0,84
(die Speicherbeschränkung) TOOL 1,17 1,09 1 0,90 0,78 n/a
− PVOL – Platform Volatility SITE 1,22 1,09 1 0,93 0,86 0,80
(die Unbeständigkeit der Entwicklungsplatt- SCED 1,43 1,14 1 1 1 n/a
form)
− Personalattribute Bei der Größe des Projektes werden zusätzlich
− ACAP – Analyst Capability zwei wichtige Einflüsse berücksichtigt [SOMM01]:
(die Fähigkeiten der Projektanalytiker) − Die Unbeständigkeit der Anforderungen
− PCAP – Programmer Capability Man geht davon aus, dass eventuell noch Nachar-
(die Fähigkeit der Programmierer) beiten aufgrund von Änderungen der Systeman-
− PCON – Personal Continuity forderung zu leisten sind. Diese sollen in ihrem
(die Personalkontinuität) Zeilenausmaß geschätzt werden und zu der „nor-
− APEX – Applications Experience malen“ Größenschätzung hinzuaddiert werden.
(die Erfahrungen der Analytiker auf dem Ge- − Der Umfang einer möglichen Wiederverwendung
biet des Projektes) Bei einem umfangreichen Reuse muss die Zeilen-
− PEXP – Platform Experience anzahl des tatsächlich entwickelten Quellcodes
(die Erfahrung der Programmierer auf dem verändert werden. Nun ist es jedoch so, dass die
Gebiet des Projektes) Kosten für eine Wiederverwendung aufgrund des
− LTEX – Language and Tool Experience benötigten Aufwandes zur Findung und Auswahl
(die Erfahrung mit der Sprache und den der Komponenten und deren Schnittstellen sowie
Werkzeugen) den notwendigen Änderungen nicht linear verlau-
fen. Dies findet in COCOMO II Berücksichtigung.
Der Größenaufwand wird durch nachstehende 2.5. Tools
Formel angenähert.
Es gibt sowohl kostenlose/private Tools als auch
ESLOC = kommerzielle Tools, die bei der Aufwandsschätzung
ASLOC*(AA+SU+0,4DM+0,3CM+0,3IM)/100 mit COCOMO II den Benutzer unterstützen sollen.
Abbildung 6. Formel für Reuse Hier sollen drei nützliche Tools kurz vorgestellt wer-
den [UNIM04]:
ESLOC (extension source lines of code) steht für 1. QuickSoft-Calculator
die Zeilenanzahl des neuen Codes, ASLOC (adapted Der QuickSoft-Calculator ist zu finden unter:
source lines of code) für die änderungsbedürftige Zei- http://www.pm99.de/oldhome/quicksoft/index.ht
lenanzahl des wiederverwendbaren Codes, DM (design m
modifications) für den prozentuellen Anteil des geän- QuickSoft wurde speziell für Studenten von
derten Entwurfs, CM (code modifications) für den pro- Dr. Siegfried Seibert (Professor an der Fachhoch-
zentuellen Anteil des geänderten Codes und IM (modi- schule Darmstadt) entwickelt um ihnen den prak-
fications for integration) für den prozentuellen Anteil tischen Einsatz zu erleichtern und um das Modell
des anfänglich erforderten Aufwandes für die Integra- auszuprobieren. Dieses Tool steht in Form einer
tion der wiederverwendeten Software. SU (source usa- Web Applikation zur freien Verfügung. Es ist
bility) ist ein Faktor, der auf den Kosten für das Be- sehr übersichtlich und leicht handhabbar.
herrschen der Software basiert. Der Wert kann variabel 2. Costar
zwischen 10 und 50 gewählt werden. 10 bedeutet, dass Costar ist ein kommerzielles Tool. Die Einzelli-
der Code gut geschrieben und objektorientiert ist. Bei zenz kostet 1.900 USD, die Unternehmenslizenz
50 handelt es sich um einen sehr komplexen und un- liegt bei 25.000 USD. Nähere Informationen zum
strukturierten Code. Der Faktor AA (application as- Produkt sowie eine kostenlos downloadbare De-
sessment) spiegelt die ursprünglichen Beurteilungskos- moversion findet man unter:
ten für die Entscheidung über die Wiederverwendung http://www.softstarsystems.com/index.htm.
der Software wider. Auch hier kann der Wert variabel 3. Construx Estimate 2.0
gewählt werden. Der Wertebereich liegt zwischen 0 Construx bietet auf seiner Homepage dieses Tool
und 8. zum freien Download mit eingeschränkter Lizenz
(vorher ist allerdings eine Registrierung notwen-
Wie beim Early Design Model wird ebenso hier für dig) an. Zu finden ist das Tool unter:
A der Erfahrungswert 2,5 eingesetzt. Auch der Expo- http://www.construx.com/resources/estimate/inde
nent E kalkuliert sich wie bereits im vorigen Modell x.php Die bekanntesten Partner sind Dell, Nokia,
demonstriert und an der Berechnung von PMm ändert Microsoft, Intel und General Electric.
sich genauso wenig.
2.6. Kritische Betrachtung
2.4. Einsatzgebiete
Durch die vielen Einflussfaktoren, die berücksich-
COCOMO II wurde entwickelt um bei folgenden tigt werden müssen, wird die praktische Anwendbar-
Entscheidungen und Situation zu helfen [BOEH00]: keit von COCOMO schnell komplex. Vor allem ist
– Entscheidungen, die die Investitionen eines Soft- hier anzumerken, dass diese Einflussfaktoren die ur-
wareprojektes betreffen, sprüngliche Schätzung sehr stark beeinflussen können.
– Festsetzungen von Projektbudgets und Zeitplänen So können hohe Werte zu einer dreimal so hohen
(Wie viele Mitarbeiter werden in welcher Phase Schätzung führen, niedrige Werte zu einem Drittel der
gebraucht? Wie hoch ist der Aufwand zur Errei- ursprünglichen Schätzung.
chung eines bestimmten Meilensteines?), Ziel ist es, dass Anwender dieses Modells ihre ei-
– Diskussionen über Kosten, Zeitpläne und Leis- genen Erfahrungen berücksichtigen und die Attribut-
tung, werte auf ihren historischen Projektdaten basieren. In
– Entscheidungen über Risiken, der Regel sind allerdings zu wenig oder gar keine die-
– Entscheidungen über Fortschritt und Verbesserun- ser Daten vorhanden. [SOMM01]
gen von Software (Reuse, Outsourcing, Tools,…); Außerdem gelten hier natürlich auch die allgemei-
nen Kritikpunkte an algorithmischen Schätzverfahren
(siehe Kapitel 1.2).
auch kommerzielle Tools zur Erleichterung der Be-
3. Resümee rechnung vorgestellt.

Zusammenfassend soll hier noch einmal verdeut-


licht werden, wie wichtig Aufwandsschätzung für je- Literatur
des Projekt und besonders auch für Softwareentwick-
lungsprojekte ist. Insbesondere bei solchen Projekten [BOEH81] B.W. Boehm, Software Engineering Economics,
fällt die richtige Schätzung oft schwer, da viele oft Prentice Hall, Englewood Cliffs, 1981.
unvorhersehbare Faktoren hier mitspielen und der
Fortschritt und Erfolg von Können und Kreativität der [BOEH00] B.W. Boehm et al., Software cost estimation with
COCOMO II, Prentice Hall PTR, Upper Saddle River, 2000.
Programmierer abhängig ist. Dennoch sollte trotz der
Vielzahl an Unsicherheiten nicht auf eine Aufwands- [KNOE91] H.D. Knöll, Aufwandsschätzung von Software-
schätzung verzichtet werden. Diese Schätzung ist so- Projekten in der Praxis, Bibliographisches Institut & F.A.
wohl zu Beginn durchzuführen, als auch regelmäßig Brockhaus AG, Mannheim, 1991.
während des Entwicklungsprozesses um Abweichun-
gen vorzeitig zu erkennen und Gegenmaßnahmen und [SOMM01] I. Sommerville, Software Engineering, Pearson
Korrekturen einzuleiten. Studium, München, 2001.
In dieser Arbeit wurde COCOMO II als algorithmi-
sche Methode zur Aufwandsschätzung schrittweise mit [TUWI04] o.V., Barry W. Boehm, URL:
http://cartoon.iguw.tuwien.ac.at:16080/fit/fit01/spiral/entsteh
seinen drei Submodellen (Application Composition
ung.html, Wien, 2004.
Model, Early Design Model und Post-Architecture
Model) und deren jeweiligen Formeln präsentiert. [UNIM04] o.V., Tools, URL: www.unibw-
Auch wurden die Entwicklung des Modells und die muenchen.de/campus/WOW/v1052/_private/Tools.ppt,
Unterschiede zu COCOMO 81 dargelegt. Zum Ab- München, 2004.
schluss wurde das Modell kritisch betrachtet, seine
Einsatzgebiete erläutert und sowohl kostenlose als