Dieser Artikel beschäftigt sich mit Cocomo. Für andere, gleichlautende Bedeutungen siehe Kokomo
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 oder 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.
1 Verfahren
1.1 Definitionen und Annahmen
1.1.1 Delivered Source Instructions (DSI)
1.2 Komplexität bestimmen
1.2.1 Organic Mode
1.2.2 Semidetached Mode
1.2.3 Embedded Mode
1.3 Aufwand errechnen
1.4 Projektdauer
1.5 Kostentreiberfaktoren
2 Weiterentwicklung
2.1 ADA COCOMO
2.2 COCOMO II
4 Referenzen
Verfahren[Bearbeiten]
Definitionen und Annahmen[Bearbeiten]
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.
Delivered Source Instructions (DSI)[Bearbeiten]
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[Bearbeiten]
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[Bearbeiten]
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[