COCOMO

COCOMO (Constructive Cost Model) ist ein algorithmisches Kostenmodell, das in der Softwareentwicklung zur Kosten- bzw. Aufwandsschätzung verwendet wird. Mit Hilfe von mathematischen Funktionen wird ein Zusammenhang zwischen gewissen Softwaremetriken und den Kosten eines Projekts dargestellt.

Es fließen mehrere firmenspezifische Parameter in die Berechnung hinein, die feststellt, wie viele Personenmonate bzw. Personenjahre notwendig sind, um ein Softwareprojekt zu realisieren. Weiterhin kann die Gesamtdauer des Projekts abgeschätzt werden. COCOMO beruht auf vielfältiger Erfahrung, die in der Großindustrie, z. B. bei Boeing, bei der Softwareentwicklung gemacht worden ist. Das Verfahren wurde bereits 1981 durch Barry W. Boehm, Softwareingenieur bei Boeing, entwickelt.

Verfahren

Definitionen und Annahmen

• Der primäre Kostenfaktor (Cost Driver) für das Modell sind die Delivered Source Instructions (DSI) des Projekts.
• Die Entwicklungsperiode beginnt mit dem Start des Produktdesigns und endet mit dem Abschluss der Produktintegration und der Akzeptanztests. Die Aufwände der anderen Phasen werden separat ermittelt.
• Ein COCOMO-Personenmonat oder auch Staff Month (SM) besteht aus 152 Arbeitsstunden.
• COCOMO geht von gutem Management von Seiten der Entwickler als auch der Kunden aus und setzt voraus, dass unproduktive Zeiten möglichst gering gehalten werden.
• COCOMO setzt voraus, dass der Anforderungsspezifikation nach der Anforderungsphase keine grundlegende Änderung widerfährt. Eine signifikante Änderung in der Spezifikation zieht auch eine Änderung der Aufwandsschätzung nach sich.

Delivered Source Instructions (DSI)

Als Basis für die Berechnung muss die Anzahl von auszuliefernden Codezeilen in KDSI (1000 (K) delivered source instructions [1 KDSI = 1000 Instruktionen]) ermittelt werden. Als Delivered wird nur Software bezeichnet, welche dem Kunden als Teil des Produkts auch übergeben wird. Diese Definition schließt Code, der für Support-Software oder zum Testen geschrieben wurde, aus. Die Abschätzung dieser Größe ist von vielen Faktoren (z. B. Programmiersprache) abhängig und wird von COCOMO nicht behandelt. Source Instructions entsprechen den von Entwicklern geschriebenen und ausführbaren Computeranweisungen. Neben den Kommentaren schließt diese Definition also auch noch generierten Code aus. Instructions beruhen größtenteils noch auf den damals gängigen Lochkarten. So definiert Boehm Instructions in seinem Werk^[1] als Card Images. Delivered Source Instructions sowie Codezeilen oder Function Points sind Softwaremetriken zur Messung der Größe der Software.

Komplexität bestimmen

Dann muss man entscheiden, ob man an einem einfachen („organic mode“), mittelschweren („semi-detached“) oder einem komplexen („embedded“) Projekt arbeitet. Diese Projektmodi sind zentrale Punkte in COCOMO 81, welche die Unterschiede im Arbeitsprozess in den verschiedenen Arbeitsdomänen repräsentieren. Die Wahl des Projektmodus wirkt sich maßgeblich auf das Ergebnis der Berechnung aus – wobei die Formel der Berechnung gleich bleibt und sich nur die Koeffizienten ändern.

Organic Mode

Der Organic Mode entspricht kleinen bis mittelgroßen Softwareprojekten. Die meisten am Projekt beteiligten Mitarbeiter haben bereits eingehende Erfahrungen mit ähnlichen Projekten in diesem Unternehmen sowie der verwendeten Soft- und Hardware. Dies gewährleistet einen geringen Overhead an Kommunikation, da die Beteiligten schon eine genaue Vorstellung von dem zu erstellenden Produkt, haben. Dokumentation von Spezifikationen und Schnittstellen wird nicht streng gehandhabt, wodurch diesbezügliche Verhandlungen schneller abgeschlossen werden und der dadurch entstehende Mehraufwand (diseconomies of scale) gering gehalten wird. Weitere Merkmale des Organic Modes sind stabile Entwicklungsumgebungen mit wenig neuen Technologien, minimaler Bedarf an neuen Innovationen und wenig Zeitdruck.

Semidetached Mode

Der Semidetached Mode ist für Projekte gedacht, deren Größe und Komplexität zwischen Organic und Embedded Mode anzusiedeln sind. Es handelt sich um mittelgroße Projekte (zwischen 50 und 300 KDSI), deren Beteiligte bereits ein mittleres Maß an Erfahrung in der Entwicklung solcher Systeme haben oder in denen das Team aus erfahrenen sowie unerfahrenen Kollegen besteht oder das Team nur auf einem Teilgebiet Erfahrung besitzt. Projekte, welche diesem Modus entsprechen, sind komplexer, benötigen anspruchsvollere Interaktionsroutinen und flexible Schnittstellen.

Embedded Mode

Der Embedded Mode ist durch seine straffen, unflexiblen Strukturen und Richtlinien gekennzeichnet. Dies stellt auch den größten Unterschied zu den beiden anderen, eher locker geführten Modi, dar. Es zielt größtenteils auf sicherheitsrelevante Projekte (z. B. Flugassistenzsysteme, Systeme für Banken) ab, welche dadurch sehr unflexibel bezüglich Änderungen in Spezifikationen und Schnittstellen sind. Des Weiteren sind Projekte im Embedded Mode in der Regel Neuentwicklungen mit wenig bis keinen vergleichbaren Vorgängerprojekten. Aus diesem Grund zeichnen sich diese Projekte auch dadurch aus, dass sie mit einer relativ langen Analyse- und Design-Phase beginnen. Sind diese Phasen abgeschlossen, werden möglichst viele Entwickler parallel damit beauftragt, das System zu implementieren und zu testen. Hier entspricht bereits der Testaufwand von intermediate Projekten (im Umfang von 8000 DSI) dem von großen Projekten (128000 DSI) im Organic Mode.

Aufwand errechnen

Der Aufwand PM in Personenmonaten wird dann errechnet als ein Faktor m multipliziert mit einer Potenz n der Metrikzahl.

$PM = m \cdot \mathbf{KDSI}\;^ n$

• einfach: $PM = 2,4 \cdot \mathbf{KDSI}\;^ {1,05}$
• mittelschwer: $PM = 3 \cdot \mathbf{KDSI}\;^ {1,12}$
• komplex: $PM = 3,6 \cdot \mathbf{KDSI}\;^ {1,20}$

Beispiel: Bei 100 KDSI betragen die Personenmonate PM etwa 300 für ein einfaches Projekt, etwa 500 für ein mittelschweres und etwa 900 für ein komplexes.

Projektdauer

Man kann die Personenmonate jedoch nicht durch eine beliebige Anzahl von Personen teilen, um das Produkt schneller fertig zu stellen. Als Beispiel dient oft das Gebären eines Kindes – dies kann nicht durch den Einsatz von neun Frauen auf einen Monat abgekürzt werden. Es gibt gewisse Prozesse, die sequentiell ablaufen müssen, und je mehr Menschen mit einem Projekt betraut sind, umso mehr muss in die Kommunikation investiert werden.

COCOMO spricht von TDEV, time to develop (Entwicklungszeit). Auch hier werden drei Komplexitätsarten unterschieden:

• einfach: $TDEV = 2,5 \cdot \mathbf{PM}\;^ {0,38}$
• mittelschwer: $TDEV = 2,5 \cdot \mathbf{PM}\;^ {0,35}$
• komplex: $TDEV = 2,5 \cdot \mathbf{PM}\;^ {0,32}$

• Für ein einfaches Projekt mit 32 KDSI liefert die COCOMO-Abschätzung 91 PM und ein TDEV von 10,6 Monaten.
• Für ein mittelschweres Projekt mit 32 KDSI liefert die COCOMO-Abschätzung 145 PM und ein TDEV von 14 Monaten.
• Für ein komplexes Projekt mit 32 KDSI liefert die COCOMO-Abschätzung 230 PM und ein TDEV von 20 Monaten.

Bei der COCOMO-Berechnung von TDEV ist die Mindestdauer acht Monate. Wenn man diese Werte andersherum auf die Anzahl von Codezeilen berechnet, die eine Person pro Tag produziert, bekommt man für ein einfaches Projekt 16 und für ein komplexes 4 DSI/Person/Tag.

Kostentreiberfaktoren

Das erweiterte COCOMO-Verfahren (Intermediate COCOMO) berücksichtigt weitere sogenannte Kostentreiberfaktoren, die den errechneten Basiswert entweder verringern oder erhöhen. Diese basieren auf vielen Erfahrungen, die bei großen Firmen gemessen worden sind. Solche Faktoren sind unter anderem:

• Zuverlässigkeit des gelieferten Systems – ist ein Fehler nur störend oder gefährdet er Menschenleben?
• Wie groß ist die Datenbank, die erstellt werden muss?
• Wie komplex sind die Ein-/Ausgabeverarbeitung und die Datenstrukturen?
• Wie schnell muss das System Ergebnisse liefern?
• Wie viel Speicherbedarf hat das System?
• Wie oft erwartet man, dass das System an äußere Rahmenbedienungen angepasst werden muss? Hier schwankt die Bandbreite zwischen einmal im Jahr bis monatlich.
• Teamfaktoren – was für Erfahrung haben die Teammitglieder in der Analyse, in der verwendeten Programmiersprache, mit Software-Werkzeugen, mit dieser besonderen Hardware?
• Wie eng ist der Zeitplan?

Als Beispiel dafür, wie sehr diese Faktoren das Ergebnis beeinflussen, dient folgende Berechnung:

Komplex, 128 KDSI, entspricht 1216 PM (Basisberechnung nach COCOMO).

Faktor	von	bis
Zuverlässigkeit	sehr hoch = 1,4	sehr niedrig = 0,75
Komplexität	sehr hoch = 1,3	sehr niedrig = 0,70
Speicherbedarf	hoch = 1,2	kaum = 1,0
Werkzeugverwendung	niedrig = 1,1	hoch = 0,90
Zeitplan	schnell = 1,23	normal = 1,0
angepasst	3593 PM	575 PM

Erklärung: Die Einzelfaktoren werden zu einem „Gesamtfaktor“ aufmultipliziert und mit dem Basiswert für den Aufwand multipliziert.
Formel: Angepasster Wert = Basiswert * (Zuverlässigkeit * Komplexität * Speicherbedarf * Werkzeugverwendung * Zeitplan)

Diese Werte sind jedoch nur grobe Erfahrungswerte, jede Firma muss für sich selbst die eigenen Faktoren durch Kostenüberwachung und Analyse von bisher erstellten Projekten bestimmen.

Weiterentwicklung

Boehm weist darauf hin, dieses Modell nicht leichtfertig anzuwenden: „Basic COCOMO is good for rough order of magnitude estimates of software costs, but its accuracy is necessarily limited because of its lack of factors to account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other project attributes known to have a significant influence on costs.“^[1] (Das COCOMO-Basismodell ist gut geeignet für eine grobe Abschätzung der Größenordnung der Softwarekosten. Die Genauigkeit des Modells ist notwendigerweise eingeschränkt, weil es ihm an Faktoren für Unterschiede bei der verwendeten Hardware, der Personalqualität und -erfahrung, dem Einsatz moderner Werkzeuge und Technologien und anderen Merkmalen fehlt, die bekanntermaßen einen signifikanten Einfluss auf die Kosten haben.). Ein relativ genaues Ergebnis bekommt man erst unter Berücksichtigung mehrerer, auf das Projekt einwirkender Faktoren (siehe Intermediate und Detailed COCOMO).

ADA COCOMO

ADA COCOMO ist eine Weiterentwicklung von COCOMO 81 – welches sehr stark vom Batch-Processing und dem Wasserfall-Prozessmodell geprägt ist – zur Anpassung an die TRW-Implementierung des ADA-Prozessmodells. Dieses Modell beinhaltet Risk Management, Architektur Skeletons, Inkrementelles Implementieren und Testen und einheitliche Softwaremetriken. Hauptaugenmerk des Modells sind die Verringerung des Kommunikationsoverheads, Vermeidung späten Überarbeitens aufgrund instabiler Anforderungen. Die Änderungen zu COCOMO 81 können in drei Kategorien eingeteilt werden:

1. Allgemeine Verbesserungen von COCOMO: Diese beinhalten größtenteils Anpassungen der vorhandenen sowie zusätzlicher Kostenfaktoren. Neue Faktoren sind z. B. Security und Development for software reusability.
2. Ada-spezifische Effekte: Neue Regeln zum Abzählen der Instruktionen (DSI) für die Programmiersprache ADA. Zusätzliche Kostenfaktoren bezüglich Programming Language Experience.
3. Effekte bedingt durch das Ada-Prozessmodell: Diese Effekte wirken sich vor allem in den Exponenten der Regressionsgleichungen aus und leiten sich aus den Eigenschaften der Ada-Prozessmodells her. Hierfür wurden vier Skalierungsfaktoren eingeführt (Experience with the Ada Process Model, Design Thoroughness at PDR (Preliminary Design Review), Risks Eliminated at PDR, Requirements Volatility). Zusätzlich wurde ein Methode bereitgestellt, um den Aufwand von inkrementellen Projekten zu schätzen.

Der Rest von COCOMO 81 blieb unverändert – die generelle Form mit den verschiedenen Modi, etc.

COCOMO II

COCOMO II wurde ebenfalls, wie seine beiden Vorgänger, von Barry W. Boehm entwickelt und das erste Mal 1997 publiziert. Die offiziell bekannte Version ist jedoch 2000 in einem Buch^[2] veröffentlicht worden. COCOMO II repräsentiert die Änderungen in der ’modernen’ Softwareentwicklung, mit Anpassungen an neue Softwareentwicklungs-Prozessmodelle sowie neuen Entwicklungsmethodiken (z. B. Objektorientiertes Programmieren). Es werden wieder, wie in COCOMO 81, drei verschiedene Schätzarten unterschieden, mit dem Unterschied jedoch, dass sich diese vermehrt auf den Entwicklungsstand des Projekts beziehen. Auf die Unterteilung in verschiedene Projektmodi wurde hier verzichtet.

Kritik

Das COCOMO Modell ist nur sehr beschränkt für die Abschätzung des Aufwandes eines Projektes geeignet, da es schwer ist die zugrundeliegenden Delivered Source Instructions auf Basis einer Anforderungsspezifikation zu schätzen. Außerdem geht es nicht darauf ein, dass Software in modernen Hochsprachen oftmals mit weniger Zeilen mehr ausdrücken kann als die Sprachen zu der Zeit, als COCOMO entwickelt wurde. Die Ungenauigkeit dieser Schätzung macht diese Methode für die Aufwandsschätzung unbrauchbar.

Referenzen

1. ↑ ^{a b} Barry Boehm. Software engineering economics. Englewood Cliffs, NJ:Prentice-Hall, 1981, ISBN 0-13-822122-7
2. ↑ Barry Boehm, et al. Software cost estimation with COCOMO II (with CD-ROM). Englewood Cliffs, NJ:Prentice-Hall, 2000, ISBN 0-13-026692-2

Literatur

• Die Beispiele sind dem Standard-Lehrbuch von Ian Sommerville, Software Engineering, Addison-Wesley, ISBN 0-321-21026-3 entnommen.

Siehe auch

• Function-Point-Verfahren

Weblinks

• Biographie – Barry W. Boehm
• Sammlung von COCOMO-Nachfolgern und -Software
• Verfahren – COCOMO-Methode