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
[modifica | modifica wikitesto]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.