COCOMO

COCOMO, abbreviazione di COnstructive COst MOdel, è un modello matematico creato da Barry Boehm utilizzato da chi progetta software per stimare alcuni parametri fondamentali come il tempo di consegna e i mesi-uomo necessari per lo sviluppo di un prodotto software.

Cocomo è basato sullo studio di sessanta progetti al TRW, una compagnia californiana di automazione e sviluppo software, acquistata da Northrop Grumman nel tardo 2002. I programmatori hanno esaminato progetti con dimensioni che vanno dalle 2000 alle 100.000 linee di codice, per linguaggi di programmazione che spaziano dall'assembly al PL/I.

Cocomo è considerato un modello statico e analitico; statico in quanto le variabili di ingresso e di uscita sono ben definite e fisse, analitico perché può essere utilizzato non necessariamente ad un progetto nella sua interezza ma anche a sue parti.

Esistono tre diversi modelli di cocomo che si differenziano per la raffinatezza e la precisione con cui vengono stimati i diversi valori: Basic, Intermediate e Advanced, chiamato anche Detailed.

• Basic COCOMO - è il più facile da calcolare ma anche il meno preciso, la stima viene fatta partendo dalla dimensione del software da sviluppare calcolata in KNCSS.
• Intermediate COCOMO - calcola lo sforzo di sviluppo del software come funzione della grandezza del programma, espressa sempre in KNCSS, e su un insieme di "indici di costi", detti Cost-driver, che includono l'assegnazione soggettiva di valutazioni di prodotti, hardware, attributi di progetto e personali.
• Advanced/Detailed COCOMO - incorpora tutte le caratteristiche del cocomo intermedio con una valutazione dell'impatto dei vari costi per ogni passo (analisi, progettazione, ecc.) del processo di ingegneria del software.

Tipologie di progetto

Per ciascun livello di Cocomo esistono tre diversi metodi di sviluppo di un progetto i "Cocomo mode": Organic, Semi-detached e Embedded, che implicano differenti valori per le costanti dei fattori correttivi, e quindi diversi costi finali (stimati):

• Organic: il progetto sviluppato in piccolo, si ha già esperienza su questa tipologia si hanno pochi vincoli esterni.
• Embedded: è l'opposto dell'organic, un progetto di grandi dimensioni, molto strutturato e di cui si ha poca esperienza su questa tipologia di prodotti, ci sono forti vincoli esterni sui costi e sui tempi.
• Semi-detached: è a metà via tra organic ed embedded, cioè progetti ove i membri del team potrebbero avere un'esperienza limitata dei relativi sistemi.

Una delle osservazioni importanti nel modello è che considerazioni soggettive affiancano tutti gli altri parametri. Ciò significa che le abilità del team e dell'individuo incaricato di tale valutazione influenzano grandemente il modello.