COCOMO (constructive cost model)

Bei COCOMO (COnstructive COst Model) handelt es sich um eine Aufwands- und Kostenschätzungstechnik für die Entwicklung von Software. Es ist ein algorithmisches Kostenmodell, welches unter Verwendung von mathematischen Funktionen einen Bezug zwischen spezifischen Software-Metriken und den Kosten des Software-Projekts herstellt. Somit können die Qualitätsmerkmale wie Kosten- und Termintreue eines Projekts besser geplant und realisiert werden.


COCOMO wurde erstmals 1981 vorgestellt und im Rahmen von COCOMO II 1995 erheblich überarbeitet, so dass auch verstärkt die besonderen Anforderungen Objektorientierter Software berücksichtigt werden. Die Methode arbeitet mit sogenannten Object Points. Neben der Function-Point-Methode ist COCOMO die am weitesten verbreitete Software-Metrik, die allerdings einen differenzierten Ansatz verfolgt. COCOMO basiert im Wesentlichen auf einer Schätzung der Programmzeilen, Lines of Code (LOC) des zu entwickelnden Softwareprodukts in Kilo Source Lines of Code (KSLOC).

Das abgestufte COCOMO-Verfahren

Bei dieser Software-Metrik handelt es sich um ein abgestuftes Verfahren auf Basis der Stufen Application Composition, Early Design und Post Architecture.

In der Stufe Application Composition wird der Entwicklungsaufwand in Mitarbeiter-Monaten (MM) basierend auf einer Schätzung von gewichteten Object Points bestimmt, die durch einen Standardwert für Mitarbeiterproduktivität dividiert wird. Die Anzahl der Object Points wird dabei bestimmt, in dem die Zahl der separat angezeigten Bildschirme zunächst gezählt und anschließend je nach Komplexitätsgrad gewichtet wird. Dazu werden dann entsprechend der verwendeten Programmiersprache zusätzliche Object Points addiert. Die so ermittelte Anzahl an Object Points wird mit einem Faktor, welcher die Wiederverwendbarkeit der Software ausdrückt, gewichtet und durch den Standardwert für Produktivität dividiert.

In der Stufe Early Design wird der Aufwand mit Hilfe der nachfolgenden algorithmischen Formel bestimmt:

Aufwand (MM) = 2,5 x Produktionsgröße (exp B) x M

Dabei steht die Produktgröße für die Anzahl von KSLOC. Dieser Wert wird durch Bestimmung von Function Points und deren Umrechnung mit Hilfe einer Tabelle ermittelt. Wie bei algorithmischen Schätzverfahren üblich, reflektiert der Exponent B den mit der Größe des Projekts überproportional ansteigenden Entwicklungsaufwand.

B kann dabei abhängig von den subjektiven Einflussfaktoren wie Qualität des Teams, Innovationsgrad, Flexibilität und dem Sicherheitsmanagement des Projektes Werte zwischen 1,1 und 1,24 annehmen.

Der Faktor M definiert die Projekt- und Prozess-Kostentreiber wie Produktzuverlässigkeit, Reliability and Complexity (RCPX), Verlangte Wiederverwendung, Reuse (RUSE), Plattformkomplexität, Platform Difficulty (PDIF), Erfahrung des Personals, Personal Experience (PREX), Terminanforderungen, Required Schedule (SCED) und Unterstützungs-Infrastruktur, Team Support Facilities (FCIL). Jeder dieser Faktoren kann Werte zwischen eins (sehr niedrig) und sechs (sehr hoch) annehmen. So ergibt sich:

M = PERS x RCPS x RUSE x PDIF x PREX x FCIL x SCED.

Auch in der Stufe Post Architecture wird eine ähnliche Formel wie in der zweiten Stufe verwendet. Dabei setzt sich jedoch der Faktor M aus einer erweiterten Anzahl von Einflussfaktoren zusammen. Diese lassen sich in vier verschiedene Klassen einordnen: In die Produkteigenschaften, die Hardware-Plattform, das Personal und die Projekt-Charakteristika.

Der Wert der Produktgröße bestimmt sich dabei in der Einheit KSLOC nach folgender Formel 1:

Bestimmung der Produktgröße, 
   Formel 1

Bestimmung der Produktgröße, Formel 1

Darin definiert

  • ASLOC für die potentiell wiederverwendbare Lines of Codes,
  • AA für den Testaufwand von 0 bis 8,
  • SU für die Software-Qualität von 10 (gut strukturiert) bis 50 (komplex, aber unstrukturiert),
  • DM den Prozentsatz des für die Wiederverwendung zu modifizierenden Designs,
  • CM den Prozentsatz an wiederverwendbaren Programmcodes und
  • IM den Prozentsatz des Integrationsaufwandes für wiederverwendbaren Code am Gesamt-Integrationsaufwand.
Der Exponent B wird bestimmt, indem die Produkteigenschaften "Gegebene Präzedenzfälle", "Gegebene Flexibilität", "Geforderte Architektur", "Team Zusammenhalt" und "Projekt-Zeitplan" jeweils mit 0 bis 5 bewertet, dann summiert, durch 100 dividiert und endgültig zu 1,01 addiert werden. Somit können sich für den Exponenten B Werte zwischen 1,01 und 1,26 ergeben.

Informationen zum Artikel
Deutsch:
Englisch: constructive cost model - COCOMO
Veröffentlicht: 28.10.2013
Wörter: 603
Tags: #Entwicklung, Codierung
Links: Apps, Architektur, Aufwand, Ausfallsicherheit, Bildschirm