Anna Rita Fasolino » 19.Il Modello COCOMO per la stima dei costi Software – La gestione dei Rischi

Il modello Constructive Cost Model (COCOMO)

Un modello empirico di stima basato su dati relativi ad esperienze di progetto proposto da Barry Boehm.

É un modello ben documentato ed indipendente dal venditore del software.
Ha avuto una lunga storia di modifiche dalla versione iniziale pubblicata 1981 (COCOMO-81) fino alla più recente, COCOMO 2.
COCOMO 2 (diversamente da COCOMO 81 basato sul pocesso a cascata) tiene conto di diversi approcci allo sviluppo software (quali prototipazione, component-based, riuso…).

COCOMO 81

Modello a tre livelli (base, intermedio e dettagliato) in base al livello di accuratezza della stima proposta (da rozza a più fine).

Ogni livello propone, inoltre, stime diverse corrispondenti a tre diverse tipologie di progetti:

• Semplice
  • Applicazioni piccole, per le quali il team di sviluppo è pienamente consapevole delle problematiche da affrontare.
• Moderato
  • Applicazioni più complesse, nelle quali si possono incontrare problematiche rispetto alle quali l’esperienza del team è limitata.
• Integrato
  • Applicazioni complesse, anche con problematiche hardware e vincoli legati a norme.

COCOMO 81 – livello base

Limiti di COCOMO 81

COCOMO 81 (Basic COCOMO) proponeva un modello estremamente semplificato sia delle applicazioni che del ciclo di vita adottato.

In pratica venivano utilizzati solo due parametrI.

• DSI, come metrica di prodotto;
• Tipologia, come ulteriore metrica che tenesse in conto di tutti i fattori di processo, ma che può assumere solo tre valori possibili.

A causa di queste limitazioni si sono introdotti modelli COCOMO più precisi → COCOMO II.

COCOMO 2

COCOMO 2 comprende un insieme di modelli applicabili al variare delle modalità di realizzazione dei software, che permettono stime più dettagliate e affidabili.

• Modello di composizione delle applicazioni. Utile per la stima di sistemi ottenuti a partire dal riuso di componenti.
• Modello di progettazione iniziale. Basata fondamentalmente sui Function Point; utile per ottenere stime in fase di analisi.
• Modello di riutilizzo. Utile per stimare il costo relativo all’integrazione di diversi componenti riusabili.
• Modello di post-architettura. Modelli utilizzabili a valle della definizione dell’architettura per ottenere stime più affidabili.

1. Modello di composizione delle applicazioni

È un modello utile per stimare i costi di realizzazione di un prototipo o di realizzazione di un software a partire da componenti esistenti.

PM = ( NAP x (1 – %reuse/100 ) ) / PROD

PM è lo sforzo in mesi-uomo, NAP il numero di Application Point, PROD la produttività.
In pratica, tale modello esclude dal calcolo dello sforzo la parte del sistema riusata.

Tabella per la valutazione della produttività

2. Modello di progettazione iniziale

Viene usato una volta che I requisiti utente sono stati definiti e la progettazione iniziata.
È spesso utilizzato per confrontare diverse soluzioni progettuali possibili.

Effort = A x Size^B x M

• A = 2.94 (almeno in prima istanza)
• Size è misurata in KLOC (calcolata a partire dai FP)
• B varia tra 1.1 e 1.24 in base ad una serie di fattori quali l’innovatività del progetto, la flessibilità, le tecniche di gestione del rischio, la maturità del processo …
• M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED;

I Moltiplicatori

I moltiplicatori riflettono vari aspetti:

• PERS: capacità del personale
• RCPX: complessità del prodotto
• RUSE: livello di riuso
• PDIF: difficoltà legate alla piattaforma utilizzata
• PREX: esperienza del personale
• FCIL: funzionalità di supporto
• SCED: tempistica

Ogni moltiplicatore è valutato su una scala da 1(molto basso) a 6 (molto alto).

3. Modello di riuso

Considera sia il riuso di codice in modalità black-box, senza cambiamenti, sia il riuso di codice che deve essere adattato per integrarlo con nuovo codice.

Ci sono due versioni del modello di stima:

• Black-box reuse (senza modifiche del codice riusato). Si calcola una stima dello sforzo (PM).
• White-box reuse (con modifiche del codice). Si calcola una stima del numero equivalente di linee di nuovo codice (a partire dal numero di linee riusate). Tale valore viene poi integrato con quello delle linee generate ex novo.

Modello di riuso (segue)

Per codice generato automaticamente (PM è lo sforzo di integrazione):

PM_Auto = (ASLOC * AT/100)/ ATPROD

ASLOC: numero di linee di codice complessivo;
AT: percentuale di codice automaticamente generato;
ATPROD: produttività degli ingegneri che si occupano dell’integrazione del codice (tipico: 2400 istruzioni al mese).

Modello di riuso (segue)

Per codice riutilizzato e modificato:

ESLOC = ASLOC * (1-AT/100) * AAM.

ESLOC: numero equivalente di righe di nuovo codice (da utilizzare nelle formule che richiedono il numero di linee di codice generato ex novo);
ASLOC: numero di linee di codice riutilizzato (ma da adattare);
AT: percentuale di codice automaticamente generato;
AAM coefficiente che indica la difficoltà di adattamento del codice. É la somma di AAF (costo per effettuare le modifiche), SU (costo per comprendere il codice esistente), AA (costo legato alle decisioni sul riutilizzo eventuale).

In pratica si paragona lo sforzo di adattamento del codice riusato ad uno sforzo di scrittura di nuovo codice.

4. Modello di Post-Architettura (P.A.)

Viene utilizzato quando è disponibile un progetto architetturale iniziale ed è conosciuta la struttura dei sottosistemi.

Viene riutilizzata la stessa formula del modello di composizione:

Effort = A x  Size^B x M

Stavolta però è possibile una migliore stima della Size.

Modello di Post-Architettura (P.A.) (segue)

La dimensione del codice (Size) è stimata sulla base della somma di 3 componenti:

1. Numero di linee di codice da sviluppare da zero;
2. Stima di numero di linee di codice equivalente calcolate tramite il modello di riuso;
3. Stima del numero di linee di codice che devono essere adattate ai requisiti specifici dell’applicazione (stima non semplice!!!).

Il termine esponenziale B invece varia in modo continuo (a partire da 1.01) e dipende da:

• 5 fattori di scala (valutati in una scala tra 0 e 5- da extra alto a molto basso);
• In COCOMO 81 B assumeva solo 3 possibili valori per modello.

Il coefficiente M dipende da 17 attributi.

Fattori di scala in COCOMO 2 – modello P.A.

Moltiplicatori (cost drivers)

Effetti dei cost drivers sulla stima

Tre esempi di Stime diverse ottenibili al variare del Modello COCOMO usato e al variare dei fattori di costo .

Qualche osservazione su COCOMO

• Il modello è stato proposto sulla base di esperienza e dati storici raccolti dagli autori del modello
  • Dovrebbe dunque essere tarato prima dell’uso in altre organizzazioni;
• Prevede molti attributi la cui valutazione è spesso difficile e imprecisa
  • Anche per gli attributi sarebbe necessaria una taratura in base a dati storici di progetto;
• Nella pratica è difficile che le aziende posseggano tali dati!

• Chi può permetterselo, paga un esperto di COCOMO per adattarlo ed usarlo nella propria realtà.

Modelli di costo nel Project planning

I modelli di costo algoritmici consentono di eseguire la pianificazione dei progetti, in quanto permettono la valutazione di strategie alternative.

• Un esempio: Sistema per controllo di esperimenti spaziali
  • Deve essere molto affidabile;
  • Deve minimizzare il peso hardware (number of chips);
  • Pertanto, I moltiplicatori su affidabilità e vincoli informatici saranno > 1.
• I componenti di costo del progetto:
  • Costi dell’hardware;
  • Costi della piattaforma di sviluppo;
  • Costo dello Sforzo di sviluppo.

Opzioni di gestione

6 diverse soluzioni alternative per l'esempio considerato.

I costi delle varie opzioni di gestione

La scelta dell’opzione

L’opzione D (uso di uno staff più esperto) sembra la migliore alternativa rispetto ai costi.
Ma ha un alto rischio associato, per la difficoltà di trovare uno staff molto esperto.

L’opzione C (upgrade memory) consente di risparmiare meno ma presenta bassi rischi.

Il modello rivela l’importanza dell’esperienza dello staff nello sviluppo software.

Durata del progetto e gestione dello staff

Analogamente alla stima dell’effort, i managers devono stimare anche:

• il tempo di calendario necessario a completare il progetto;
• quanto lo staff dovrà lavorare sul progetto.

Durata del progetto

COCOMO II ha anche una formula per la stima del tempo di sviluppo:
TDEV = 3 • PM^{[0.33+0.2•(B-1.01)]} • SCED

Dove:

• PM è lo sforzo calcolato precedentemente;
• B è il fattore esponenziale calcolato precedentemente;
• SCED è il moltiplicatore che indica la presumibile dilatazione nei tempi di sviluppo.

Si può notare che il tempo di sviluppo dipende direttamente dallo sforzo ma non direttamente dal numero di sviluppatori.

Requisiti sullo staff

Lo staff richiesto non si può determinare dividendo lo sforzo di sviluppo richiesto per la tempistica richiesta:
Es. 50 pm/ 10 mesi = 5 persone

• Il numero di persone rischiesto per lo sviluppo varia in base alla fase del progetto;
• Inoltre più persone lavorano, e maggiore è lo sforzo totale richiesto;
• Un rapido incremento dello staff in un progetto spesso comporta ritardi nello schedule!

Alcune considerazioni conclusive

Non c’è una relazione semplice tra costi di sviluppo e prezzi pagati.

Ci sono molti fattori che influiscono sulla produttività (es. Attitudine personale, esperienza nel dominio, il progetto di sviluppo, la dimensione del progetto, i tool e l’ambiente di lavoro).

In genere il prezzo del software viene stabilito per ottenere il contratto, e la funzionalità viene rapportata al prezzo pagato.

Alcune considerazioni conclusive (segue)

Si dovrebbero usare più tecniche di stima dei costi contemporaneamente.

Il modello COCOMO predice lo sforzo di sviluppo considerando vari fattori relativi al progetto, al prodotto, al personale e all’hardware.

I modelli di costo algoritmici supportano una analisi quantitativa di diverse opzioni consentendo il confronto di opzioni diverse.

Il tempo di un progetto non è proporzionale al numero di persone impiegate.

Gestione dei rischi

La gestione dei rischi in un progetto software consiste nella loro identificazione e nella proposta di soluzioni alternative che possano minimizzarne gli effetti.

Un rischio è definito come la probabilità che alcuni eventi avversi si verifichino in un progetto software.

• Rischi per il progetto
  • Allungamento dei tempi
• Rischi per il prodotto
  • Perdita di qualità
  • Riduzione di funzionalità
• Rischi per l’organizzazione
  • Incremento dei costi

Rischi possibili

Processo di gestione dei rischi

Le attività del processo di gestione dei rischi.

Processo di gestione del rischio

• Identificazione del rischio
  • Sono individuati i possibili rischi;
• Analisi del rischio
  • sono valutate probabilità e conseguenze dei possibili rischi;
• Pianificazione del rischio
  • Si disegnano piani per evitare rischi o minimizzarne gli effetti;
• Monitoraggio del rischio
  • Il rischio è costantemente controllato.

1. Identificazione dei rischi – Condotta mediante checklist

• Rischi tecnologici
  • Dipendenti dalle tecnologie utilizzate e dalla loro possibile evoluzione/dismissione;
• Rischi relativi alle persone
  • Abbandono di persone del team di progetto
  • Difficoltosa integrazione di nuovo personale;
• Rischi organizzativi
  • Relativi all’ambiente di lavoro nel quale si sta realizzando il progetto;
• Rischi strumentali
  • Dipendenti dagli strumenti di sviluppo e di supporto utilizzati;
• Rischi relativi ai requisiti
  • Variazione dei requisiti del cliente;
• Rischi di stima
  • Imprecisione nelle stime sulle quali viene dimensionato il processo di sviluppo.

Esempi di possibili rischi

2. Analisi del rischio

Valutazione della probabilità con la quale l’evento avverso si verifica e della serietà delle conseguenze connesse.

• La probabilità viene di solito stimata con una scala discreta che assuma valori come (molto bassa, bassa, moderata, alta, molto alta).
• Gli effetti degli eventi avversi possono essere stimati anch’essi su scala discreta che assuma valori come (insignificante, serio, tollerabile, catastrofico).

Esempi di analisi di rischio

3. Pianificazione dei rischi

• Strategie per evitare i rischi
  • Cercano di ridurre la probabilità connessa al rischio;
• Strategie per minimizzare i rischi
  • Cercano di ridurre l’impatto che eventualmente avrebbe l’evento avverso sul progetto;
• Piani precauzionali
  • Cercano di prevedere una soluzione alternativa di compromesso in anticipo rispetto all’effettivo verificarsi dell’evento avverso.

Esempi di strategie

4. Monitoraggio del rischio

Serve a valutare, dinamicamente

• se i rischi diventano più o meno probabili;
• se I loro effetti cambiano di intensità (ad esempio se aumenta la serietà del rischio).

Vengono monitorati un insieme di indicatori di rischio, in maniera automatica o soggettiva.

Ad ogni riunione del comitato che si occupa della gestione del progetto si dovrebbero riconsiderare i rischi effettivi, sulla base dei dati aggiornati provenienti dal monitoraggio.

Possibili indicatori di rischio