Modulo n – U.D. n – Lez. n Nome Cognome – titolo corso.

Presentazione sul tema: "Modulo n – U.D. n – Lez. n Nome Cognome – titolo corso."— Transcript della presentazione:

1 Modulo n – U.D. n – Lez. n Nome Cognome – titolo corso

2 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

3 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

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

5 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

6 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

7 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

8 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

9 Modelli COCOMO II COCOMO II ha tre modelli diversi
Modulo n – U.D. n – Lez. n Modelli COCOMO II 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 Application Composition è basato sugli Object Points, una revisione dei punti funzione Early Design usa nuove equazioni di stima. È basato su misure tradizionali, come Unadjusted Function Points o KSLOC. Post-Architecture ha nuovi cost driver, nuove regole di conteggio linee e nuove equazioni. Nome Cognome – titolo corso

10 Differenze di COCOMO II
Modulo n – U.D. n – Lez. n 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 COCOMO II sostituisce il COCOMO tradizionale? Non sempre. Si dovrebbe usare COCOMO II per la maggior parte dei nuovi progetti. COCOMO 81 è ancora il miglior approccio per alcuni progetti software. Se si utilizza un approccio tradizionale e un 3GL (third generation language, linguaggio di terza generazione) come C, Fortran o Cobol, il COCOMO originale darà buoni risultati.  Se i processi e i tool di sviluppo non sono cambiati molto negli ultimi anni, COCOMO 81 potrebbe essere il modello adatto. Nome Cognome – titolo corso

11 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

12 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

13 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.

14 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