Was ist das COCOMO Modell?

Das algorithmisches Kostenmodell für IT-Projekte

Bei der Entwicklung von Software und Softwareprojekten generell ist es wichtig, den Projektumfang richtig abschätzen zu können. Anders als bei Projekten, wo reale Objekte wie Häuser oder Maschinen gebaut – beziehungsweise entwickelt – werden, ist der Fortschritt hier sehr schwer zu überprüfen. Das liegt zum einen an der Natur von Softwareprodukten, wo die Qualität und der Erfolg des Projektes oft erst nach Fertigstellung messbar ist, zum anderen an dem vergleichsweise jungen Alter der Disziplin, weshalb wenige Erfahrungswerte vorhanden sind.

In anderen Feldern, wie dem Hausbau, war es möglich, über Jahrhunderte geeignete Kosten- und Aufwandsabschätzungen zu entwickeln. Da Computer und die für diese benötigte Software erst eine sehr kurze Historie haben, ist es also nicht möglich, auf diese Erfahrungen zurückzugreifen. Die moderne Arbeitswelt verlangt es jedoch, den Umfang und den Aufwand von Projekten, egal in welcher Branche, zuverlässig abschätzen zu können.
Wieso also nicht etablierte Methoden auf Softwareprojekte übertragen und/oder neue Methoden entwickeln?

Genau damit beschäftigt sich das COCOMO-Modell, welches Du im folgenden Text genauer kennenlernen wirst.

Definition COCOMO

COCOMO ist eine Abkürzung und steht für das “COnstructive COst MOdel”. Dieses Verfahren wurde 1981 von Barry W. Boehm, einem einflussreichen Softwareentwickler bei Boeing entwickelt, der dabei auf die im Vergleich lange Geschichte der Firma mit Softwareentwicklung zurückgriff. Außer COCOMO ist Boehm für die Entwicklung des Spiralmodells bekannt, ein Vorgehensmodell für die Softwareentwicklung. 1995 wurde COCOMO dann grundlegend überarbeitet und ist fortlaufend als COCOMO II bekannt. Bei den Veränderungen ging es vor allem darum, die populär gewordene objektorientierte Programmierung besser in das Verfahren einzubinden.

COCOMO ist ein algorithmisches Kostenmodell. Das heißt, es wendet bestimmte Rechenoperationen und Abfolgen dieser an, um die Kosten und den Aufwand des Projektes zu bestimmen. Die Software Metriken werden dabei im Zusammenhang mit den Kosten des Projektes dargestellt.

Grundprinzipien und -Annahmen bei COCOMO?

Bei der Entwicklung des Constructive Cost Model nahm Boehm auf Grund bestehender Erfahrung an, dass der Arbeitsaufwand eines Projekts exponentiell mit dem Umfang des verwendeten Programm-Codes wächst. In COCOMO wird dieser Aufwand in KDSI, Kilo Delivered Source Instructions, gemessen. Kilo sagt hier aus, dass die Einheit pro 1.000 eingesetzter Programmbefehle zählt. Das bedeutet ebenfalls, zum Codeumfang zählen laut dem Modell nur ausgeführte Programmbefehle, die im ausgelieferten Programm enthalten sind. Der Umfang des Programm Codes selbst wird hier normalerweise mit den Gearing Factors, aus der in Function Points gemessenen Softwaregröße, ermittelt. Ein Gearing Factor wird so gemessen, wie viele Programmbefehle im Durchschnitt für die Erstellung eines Function Points nötig sind.

Was ist ein Gearing Factor?

Der Gearing-Factor beschreibt gemeinsam mit der in Function Points ermittelten Softwaregröße den Umfang von Programm-Code.
Der Gearing-Factor ist dabei die Größte, die beschreibt, wie viele Programminstruktionen im Durchschnitt für die Erzeugung eines Funtional Points notwendig sind.

Was ist ein Function Point?

siehe Function-Pont-Verfahren.

Weitere Annahmen des COCOMO-Modells

Weitere Annahmen des COCOMO Modells sind, dass die Entwicklung mit dem Start des Produktdesigns beginnt und mit dem Abschluss der Produktabnahme und Akzeptanztests abschlossen wird. Die Aufwände für jede der einzelnen Phasen werden hier getrennt gemessen.

Ein COCOMO Personenmonat, eine weitere wichtige Einheit des Systems, besteht immer aus 152 Arbeitsstunden, welche auf 19 Arbeitstage mit jeweils acht Stunden verteilt werden. Im Personenmonat sind also krankheits- und urlaubsbedingte Fehlzeiten mit eingerechnet. Ein Personenjahr besteht entsprechend aus zwölf Personenmonaten.
COCOMO setzt auf hohe Produktivität. Das Management der Entwickler, sowie die Absprache mit dem Kunden erfolgt effizient und kosteneffektiv.

Wichtig: Keine (grundlegenden) Änderungen der Anforderungen während der Entwicklung

Des Weiteren nimmt COCOMO an, dass die Anforderungsspezifikation nach dem Abschluss der Anforderungsphase nicht mehr grundlegend verändert wird. Sollte das trotzdem eintreten, hätte das eine enorme Aufwandsänderung zur Folge.

Wie funktioniert COCOMO?

Diese Grundvoraussetzungen bilden bei dem Modell 17 Kosten- und Aufwandstreiber, sowie fünf Skalierungsfaktoren. So beschreibt COCOMO die Einflüsse von Projektumfelds und des Projekts selbst auf die Dauer und den Arbeitsaufwand des Projekts.
Die daraus resultierenden Werte dürfen nicht als Prognose, sondern als auf Erfahrungswerten basierende Referenzgrößen für die Projektplanung, verstanden werden.

Du kannst so durch Einsetzen bestimmter Faktoren wie dem geschätzten Projektaufwand und der geschätzten Projektdauer die ideale Teamgröße für diese Aufgabe bestimmen.

Die Drei Phasen der Berechnung der COCOMO-Werte

Die Bestimmung der Werte wird in COCOMO in drei Phasen durchgeführt.

Phase 1: Application Composition

Die erste Phase heißt Application Composition und hier wird der Entwicklungsaufwand in Personenmonaten bestimmt. Diese Anzahl wird mit Object Points bestimmt, die je nach Komplexität der Aufgaben und Programmiersprachen unterschiedlich gewichtet sind.

Phase 2: Early Design

Danach folgt das Early Design, wo der KDSI besonders wichtig ist, da hier der Projektaufwand anhand der Function Points und dem damit verbundenen, exponentiell wachsenden, Aufwand gemessen wird.

Was ist der KDSI?

Kilo Delivered Source Instructions: Ausgelieferte Programmbefehle (in tausend).

Phase 3: Post Architecture

Zuletzt gibt es die Post Architecture Stufe, wo die Formel ähnlich wie in der zweiten Stufe bestimmbar ist. Hier musst du allerdings noch andere Parameter wie die Produkteigenschaften oder Hardware-Plattform mit einbeziehen.

Wie kann ich COCOMO nutzen?

Durch COCOMO kann der Aufwand in Softwareprojekten gut bestimmt werden. Hast du zum Beispiel ein Projekt, das laut COCOMO 16 Personenmonate in Anspruch nimmt, Du aber nur vier Monate Zeit hast, um es zu beenden, musst du vier Entwickler in Vollzeit anstellen, um das Ziel zu erreichen.

Als Fazit lässt sich zu COCOMO sagen, dass es sich eignet, um den Aufwand von Softwareentwicklungsprojekten zu bestimmen, sollten die Anforderungsspezifikationen genau umgesetzt werden.