COCOMO

Da Wikipedia, l'enciclopedia libera.
bussola Disambiguazione – Se stai cercando la canzone dei Beach Boys, vedi Kokomo_(singolo).

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 sorgente]

Per ciascun livello di cocomo esisitono tre diverse tipologie di progetto, Organic, Semi-detached e Embedded, che possono essere utilizzate come modello a seconda dei vincoli che si hanno:

  • Organic: il progetto che si sta sviluppando è piccolo, si ha già esperienza su questa tipologia si hanno pochi vincoli esterni.
  • Embedded: è l'opposto dell'organic, il progetto è di grandi dimensioni, 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 e embedded

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.