COCOMO

• 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 – englisch Staff Month (SM) – besteht aus 152 Arbeitsstunden (19 Arbeitstage mit jeweils 8 Arbeitsstunden), ein Personenjahr aus 12 Personenmonaten. Der Personenmonat berücksichtigt also Urlaubs- und Krankenzeit.
• 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.

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.

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.

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.

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.

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 intermediaten Projekten (im Umfang von 8000 DSI) dem von großen Projekten (128000 DSI) im Organic Mode.

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

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

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

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

Man kann die Personenmonate jedoch nicht durch eine beliebige Anzahl von Personen teilen, um das Produkt schneller fertigzustellen. Als Beispiel dient oft das Austragen 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, desto mehr muss in die Kommunikation investiert werden.

COCOMO spricht von TDEV, time to develop (Entwicklungszeit). Die Entwicklungszeit TDEV in Monaten wird dann, je nach Komplexitätsart, berechnet gemäß:

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

• Für ein einfaches Projekt mit 100 KDSI liefert die COCOMO-Abschätzung PM = 302 Monate und TDEV = 21,9 Monate.
• Für ein mittelschweres Projekt mit 100 KDSI liefert die COCOMO-Abschätzung PM = 521 Monate und TDEV = 22,3 Monate.
• Für ein komplexes Projekt mit 100 KDSI liefert die COCOMO-Abschätzung PM = 904 Monate und TDEV = 22,1 Monate.

Bei der COCOMO-Berechnung von TDEV ist die Mindestdauer acht Monate.

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).

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.

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 des 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 eine 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 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.