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 Software-Projekt 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 Software-Entwicklung gemacht worden sind. Das Verfahren wurde bereits 1981 durch Barry W. Boehm, Software-Ingenieur bei Boeing, entwickelt.
Verfahren
Metrik bestimmen
Als Basis für die Errechnung muss die Anzahl von Codezeilen oder Function Points im fertigen Produkt geschätzt werden. Die Anzahl der letzten Endes auszulieferenden Codezeilen werden in KDSI (1000 (K) delivered source instructions [1 KDSI = 1000 Zeilen]) ausgedrückt. Oftmals wird auch LOC (lines if code) verwendet. Function points entsprechen den elementaren Prozessen und Datenzugriffen, die nach einer bestimmten Methode auch gewichtet werden, um komplexe Funktionalitäten höher zu bewerten.
Komplexität bestimmen
Dann muss man entscheiden, ob man an einem einfachen („organic mode“), mittelschweren („semi-detached“) oder einem komplexen („embedded“) Projekt arbeitet.
Bei einfachen Projekten wird ein kleines Team eingesetzt, das mit bekannten Werkzeugen und bekannter Arbeitsumgebung arbeitet. Es kennt die Hardware, auf der entwickelt wird, und die Software, mit der das zu entwickelnde Projekt interagiert. Es gibt nur einen geringen Zeitdruck. Sie werden nur bis ca. 50 KDSI groß.
Bei mittelschweren Projekten ist einer der obigen Faktoren nicht gegeben, also das Team ist größer oder kennt sich mit der Hardware oder anderen Faktoren nicht aus. In der Regel werden hier Projekte bis zu 300 KDSI angesiedelt.
Bei komplexen Projekten (embedded mode) ist die Software z. B. eng mit einem unbekannten Hardware-System gekoppelt, es müssen harte Echtzeitanforderungen eingehalten werden oder es gibt sehr komplexe organisatorische bzw. regulatorische Rahmenbedingungen, wie sie bei der Flugsicherung oder bei Bankensoftware zu finden sind.
Aufwand errechnen
Der Aufwand A in Personenmonaten wird dann errechnet als ein Faktor m multipliziert mit einer Potenz n der Metrikzahl.
- einfach
- mittelschwer
- komplex
Beispiel: Bei 100 KDSI betragen die Personenmonate ca. 300 für ein einfaches Projekt, ca. 500 für ein mittelschweres und ca. 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, um so mehr muss in die Kommunikation investiert werden.
COCOMO spricht von TDEV, time to develop (Entwicklungszeit). Auch hier werden drei Komplexitätsarten unterschieden:
- einfach
- mittelschwer
- komplex
Für ein einfaches Projekt mit 32 KDSI liefert die COCOMO-Abschätzung 91 PM und ein TDEV von 14 Monaten.
Interessanterweise ist bei der COCOMO-Berechnung von TDEV die Mindestdauer acht Monate, es kommt also sehr nahe an den Wert der Geburt eines Kindes heran. Wenn man diese Werte anders herum auf die Anzahl von Codezeilen berechnet, die eine Person pro Tag produziert, bekommt man für ein einfaches Projekt 16 DSI und für ein komplexes 4 DSI/Person/ Tag.
Kostentreiberfaktoren
Das erweiterte COCOMO-Verfahren (Intermediate COCOMO) berücksichtigt weitere sog. 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 nervend 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?
- Wieviel 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 |
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 selbst warnt davor, dieses Modell 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.“ (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.)
Manche meinen, COCOMO sei nicht anwendbar bei Objektorientierter Programmierung, was aber nicht stimmt, denn die Verwendung von Function Points als Metrik erlaubt auch bei OO-Programmierung eine grobe Kostenschätzung.
Inzwischen ist COCOMO durch COCOMO II abgelöst, COCOMO ist nur noch von akademischem Interesse um zu lernen, wie solche algorithmischen Aufwandsschätzungen für Softwaresysteme funktionieren.
Literatur
- Barry W. Boehm: Software Engineering Economics (1981)
- Barry W. Boehm: Chris Abts, A. Winsor Brown, A. Winsor Brown: Software Cost Estimation with Cocomo II w. CD-ROM. Prentice Hall, 2000 ISBN 0130266922
- Die Beispiele sind dem Standard-Lehrbuch von Ian Sommerville, Software Engineering, Addison-Wesley, ISBN 0321210263 entnommen.