Entwickelt wurde COCOMO von Dr. Barry W. Boehm, der es 1981 in seiner ersten Version veröffentlichte (Boehm, Barry H.: Software Engineering Economics, Englewood Cliffs, NJ, Prentice-Hall, 1981). Diese Version wird mittlerweile als "COCOMO 81" bezeichnet. Boehm entwickelte seine Methode weiter und benannte die nächste Version "COCOMO II" (Boehm, Barry W.: Software Cost Estimation with COCOMO II, Prentice Hall, 2000

Grundprinzipien von COCOMO

Boehm geht von der Annahme aus, dass der Arbeitsaufwand für eine Software-Entwicklung exponentiell mit dem Umfang des Programm-Codes wächst. Diesen misst COCOMO in sog. "Kilo Delivered Source Instructions" (KDSI), d.h. in tausend ausgelieferten Programmbefehlen. Zum Code-Umfang zählen somit ausschließlich Programmbefehle, die im ausgelieferten Programm enthalten sind. Üblicherweise wird der Umfang des Programm-Codes mit Hilfe eines sog. "Gearing Factors" aus der in Function Points gemessenen Softwaregröße ermittelt. Der Gearing Factor beschreibt für die verwendete Software, wie viele Programmbefehle im Mittel für die Erzeugung eines Function Points benötigt werden.

Mit 17 sog. "Kostentreibern" bzw. "Aufwandsstreibern" und fünf "Skalierungsfaktoren" beschreibt COCOMO die Einflüsse des Projekts und des Projektumfelds auf Dauer und Arbeitsaufwand. Z.B. gehen auf diese Weise Faktoren wie die Erfahrung des Projektteams oder die Komplexität der Entwicklungsaufgabe ein.

Anwendung der Schätzergebnisse von COCOMO auf die Projektplanung

Die Schätzergebnisse dürfen nicht als Prognose missverstanden werden, sondern als auf Erfahrungswerten basierende Referenzgrößen für die Projektplanung. Das Verhältnis von Aufwandsschätzung (in Personenmonaten) und Projektlaufzeit (in Monaten) ergibt z.B. eine fiktive Teamgröße in ↑Vollzeitäquivalenten. Für die konkrete Projektplanung gibt dies einen Anhaltspunkt für eine sinnvolle Größe des Projektteams.

Allerdings trifft COCOMO keine Aussage darüber, wie viele Personen diesen Aufwand erbringen sollten bzw. welchen Einfluss die Anzahl der eingesetzten Ressourcen auf Dauer und Aufwand des Projekts hat. Der geschätzte Arbeitsaufwand kann natürlich auch auf Teilzeitressourcen verteilt werden, was immer dann sinnvoll ist, wenn für einzelne Aufgaben spezielles Expertenwissen erforderlich ist. Andererseits steigt mit der Anzahl der Teammitglieder auch der Koordinierungsaufwand, so dass mit einer stärkeren Verteilung des geschätzten Aufwands auf mehr Personen sowohl Aufwand als auch Projektlaufzeit steigen kann, wie dies durch das ↑Brooksche Gesetz beschrieben wird.

Soll tatsächlich die Projektlaufzeit verkürzt werden, so führt dies gemäß COCOMO zu einer Erhöhung des Aufwands. Für eine Verkürzung der Projektlaufzeit um 25% gibt COCOMO z.B. eine Erhöhung des Aufwands um 43% an (COCOMO II, Model Definition Manual, Tab. 34, S. 35).

Wenn COCOMO für ein Projekt z.B. einen Aufwand von 16 Personenmonaten und eine Projektdauer von 8 Monaten abschätzt, dann können z.B. 2 Entwickler in Vollzeit dieses Projekt durchführen. Es ist aber nicht möglich, durch den Einsatz von 16 Entwicklern, die alle gleichzeitig nur einen Monat arbeiten, die Projektdauer auf einen Monat zu verkürzen. Bereits eine Verkürzung des Projekts auf eine Laufzeit von 6 Monaten (Beschleunigung von 25%) würde gemäß COCOMO bewirken, dass der Aufwand auf 22,88 Personenmonate ansteigt - es wären somit 3,8 Vollzeitäquivalente erforderlich, um das Projekt in 6 Monaten durchzuführen.