Lezione 4 Il metodo COCOMO Ingegneria del software

  • Slides: 14
Download presentation
Lezione 4 – Il metodo COCOMO Ingegneria del software Modulo 2 - Il software

Lezione 4 – Il metodo COCOMO Ingegneria del software Modulo 2 - Il software come prodotto Unità didattica 2 - I costi del software Ernesto Damiani Università degli Studi di Milano

COCOMO 81 (1) • Un sistema aperto pubblicato per la prima volta da Barry

COCOMO 81 (1) • Un sistema aperto pubblicato per la prima volta da Barry Bohem nel 1981 • Impiegato abbastanza bene per i progetti negli anni ’ 80 e nei primi anni ’ 90 • Errore inferiore al 68% delle volte

COCOMO 81 (2) • Comprende tre modelli diversi (con livello di dettaglio crescente): –

COCOMO 81 (2) • Comprende tre modelli diversi (con livello di dettaglio crescente): – Basic: applicato a priori – Intermediate: si applica dopo che i requisiti sono stati specificati – Advanced: si applica dopo che il design è stato completato

COCOMO 81 (3) • Ha tre modalità diverse: – Organic: “team software relativamente piccoli

COCOMO 81 (3) • Ha tre modalità diverse: – Organic: “team software relativamente piccoli che sviluppano software in un ambiente familiare e per uso interno [Bohem] – Semidetached: fase intermedia tra organic ed embedded. Di solito fino a 300 KLOC – Embedded: operando all’interno di vincoli stretti, il prodotto è fortemente legato alla “complessità di hardware, software, regole e procedure di funzionamento” [Bohem]

COCOMO 81 (4) • COCOMO usa due equazioni per calcolare lo sforzo in mesi

COCOMO 81 (4) • COCOMO usa due equazioni per calcolare lo sforzo in mesi uomo (MM) e il numero di mesi stimati per il completo progetto (TDEV) • MM si basa sul numero di KLOC • MM = a(KLOC)b * EAF • TDEV = c(MM)d

COCOMO 81 (5) • EAF (Effort Adjustment Factor) è il coefficiente di assestamento che

COCOMO 81 (5) • EAF (Effort Adjustment Factor) è il coefficiente di assestamento che deriva dai cost driver • Per il modello basic EAF è 1 • I valori per a, b, c e d differiscono a seconda di quale modalità si sta usando

Un esempio di COCOMO 81 • Il progetto è un sistema di controllo dei

Un esempio di COCOMO 81 • Il progetto è un sistema di controllo dei voli (mission critical) con 310, 000 LOC in modalità embedded – L’affidabilità deve essere molto alta (RELY=1. 40), quindi possiamo calcolare: § Effort = 1. 40*3. 6*(319)1. 20 = 5093 MM § Schedule = 2. 5*(5093)0. 32 = 38. 4 mesi § Average Staffing = 5093 MM/38. 4 mesi = 133 FSP

COCOMO II Obiettivi principali • Sviluppare un modello di stima delle pianificazioni e dei

COCOMO II Obiettivi principali • Sviluppare un modello di stima delle pianificazioni e dei costi del software ottimizzato alle procedure del ciclo di vita degli anni ’ 90 e 2000 • Sviluppare capacità di supporto dei tool e database dei costi per un continuo miglioramento del modello

Modelli COCOMO II ha tre modelli diversi • Application Composition – Indicato per progetti

Modelli COCOMO II ha tre modelli diversi • Application Composition – Indicato per progetti costruiti usando rapidi tool di sviluppo delle applicazioni (GUI builder ecc. ) • Early Design – Si possono ottenere stime grezze prima che sia decisa l’intera architettura • Post-Architecture – È il modello più dettagliato e viene usato dopo che è stata decisa l’intera architettura

Differenze di COCOMO II • Il valore b esponenziale nell’equazione di effort è sostituito

Differenze di COCOMO II • Il valore b esponenziale nell’equazione di effort è sostituito da un valore variabile basato su cinque fattori di scala piuttosto che da costanti • Le dimensioni del progetto possono essere elencate come object point, function point o SLOC (source lines of code) • EAF viene calcolato da 17 cost driver più adatti ai metodi odierni, COCOMO 81 ne ha 15 • Una valutazione del punto di rottura (breakage rating) è stata aggiunta per affrontare la volatilità di sistema

Calibrazione di COCOMO II • Perché i risultati di COCOMO II siano precisi, il

Calibrazione di COCOMO II • Perché i risultati di COCOMO II siano precisi, il modello deve essere calibrato • La calibrazione richiede che tutti i parametri dei cost driver siano modificati • Richiede molti dati, di solito più di quelli che ha una società • Il progetto iniziale era rilasciare calibrazioni ogni anno, ma finora sono state eseguite solo due calibrazioni (II. 1997, II. 1998) • Gli utenti possono proporre i dati dei loro progetti perché siano usati nelle calibrazioni future

Importanza della calibrazione • La giusta calibrazione è molto importante • COCOMO II 1997

Importanza della calibrazione • La giusta calibrazione è molto importante • COCOMO II 1997 riusciva a stimare entro il 20% dei valori effettivi il 46% del tempo. Si basava su 83 data point • La ricalibrazione per COCOMO II 1998 riusciva a a stimare entro il 30% dei valori effettivi il 75% del tempo. Si basava su 161 data point

COCOMO è il metodo migliore? • Anche se COCOMO è il metodo migliore per

COCOMO è il metodo migliore? • Anche se COCOMO è il metodo migliore per qualsiasi stima dei costi del software, in realtà si dovrebbero usare più metodi • È meglio usare un altro metodo che differisca molto da COCOMO, in modo che il progetto venga esaminato da più angolazioni • Anche le società che vendono prodotti basati su COCOMO consigliano di usare più di un metodo.

Conclusioni su COCOMO • COCOMO è il metodo più diffuso di stima dei costi

Conclusioni su COCOMO • COCOMO è il metodo più diffuso di stima dei costi del software • Effettuare brevi stime è facile e lo si può fare anche a mano • Esistono molte versioni commerciali diverse basate su COCOMO e forniscono supporto e ulteriori dati, ma a pagamento FINE