Cocomo

1

Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica

G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico

G.Raiss - Ingegneria del software COCOMO - 1

Polo di Latina

Gianluigi RaissDipartimento di Informatica e SistemisticaUniversità di Roma “La Sapienza”

[email protected] – [email protected]://www.dis.uniroma1.it/~raiss/

Corso@ 2006

La stima dei costi del software. Il metodo

CoCoMo


Razionale del metodo COCOMO….

n CoCoMo (COnstructive COst MOdel) è un metodo di stima dei costi di sviluppo del software, basato su un modello algoritmico-euristico, ideato da B.Boehm(versioni pubblicate tra il 1981 ed il 1995).

n CoCoMo permette di calcolare il costo derivandolo dall’impegno (in mesi persona) necessario allo sviluppo, che si ricava da una funzione che lo correla alla dimensione del software da sviluppare (espressa in KLoc o Function Points).

n La relazione è di tipo esponenziale: all’aumentare della quantità di software da realizzare, l’impegno necessario cresce in modo non lineare.

2




….Razionale del metodo COCOMO

n Conoscendo l’impegno (in mesi-persona) e le tariffe mensili delle risorse professionali da utilizzare, nonchéla distribuzione di tale impegno tra le principali attivitàdello sviluppo, si può ricavare il costo del software.

n CoCoMo fornisce infatti anche una indicazione della distribuzione percentuale tipica dell’impegno in 3 fasi del ciclo di sviluppo del software (Progettazione, Sviluppo, Test - La fase di raccolta dei requisiti non viene calcolata direttamente dal metodo, anche se sono fornite delle indicazioni per calcolare quanto impegno richiede).


COCOMO I - Assunzioni base

n Il tempo Tdev (in mesi) di durata dello sviluppo ècalcolato dall’inizio della fase di progettazione tecnicafino al termine di quella di integrazione e test.

n L’impegno necessario alla raccolta ed analisi deirequisiti non viene calcolato direttamente dal metodo.

n Il mese-persona “tipo” di lavoro è composto da:19 giorni e 152 ore di lavoro

e non comprende l’impegno del personale non tecnico.n I requisiti del progetto devono essere abbastanza

stabili (dominio applicativo noto).n Il ciclo di sviluppo del software deve essere del tipo

waterfall.

3




Kloc come variabile indipendente

n CoCoMo I considera come variabile indipendente la dimensione di software da sviluppare (misurata in KDSI, Kilo Delivered Source Code, o KDSI o KLOC).u Nelle LOC conteggiate vanno considerate solo le

istruzioni che vengono rilasciate al cliente, esclusi i commenti.

u Le istruzioni sviluppate per i test od i prototipi non vanno considerate.

u Non vanno considerate le istruzioni create da generatori automatici di applicazioni.


Tre modelli per la stima

n Il metodo comprende tre diversi modelli di stima, da utilizzare in funzione della quantità di informazioni disponibili e della fase dello sviluppo del software nella quale viene effettuata la valutazione:u Base (per stime iniziali, da effettuarsi quando la

progettazione tecnica è solo abbozzata).u Intermedio (quando la progettazione ha già

individuato la scomposizione in sottosistemi).u Dettagliato (quando i sottosistemi sono stati

scomposti in moduli elementari e il disegno dell’architettura è stato delineato).

4




COCOMO I - Modello Base

n Il modello Base calcola l’impegno MM ed il tempo Tdev in base alle relazioni:

MM = a KDSI b

Tdev = c MM d

n Il valore delle costanti a, b, c, d dipende dalle caratteristiche del software da sviluppare.

n COCOMO I individua 3 diverse tipologie di software, in base a fattori di dimensione e complessità.


Tipologie di software

nOrganic (semplice)uApplicazioni semplici e di limitate dimensioni

(<50KDSI), requisiti poco stringenti e poco variabili, ambiente di sviluppo noto e non innovativo.

n Semi-detached (intermedio)uComplessità e dimensioni medie (fino a 300 KDSI).

n Embedded (complesso)uApplicazioni complesse, con attento controllo del

processo e rigidi vincoli sulla qualità (i.e. sistemi realtime, applicazioni militari o per il volo).

5




Modello Base - costanti

I valori delle costanti a, b, c, d dipendono dal tipo di software da sviluppare.tipo di applicazione a b c d

Semplice 2,4 1,05 2,5 0,38Intermedia 3 1,12 2,5 0,35Complessa 3,6 1,2 2,5 0,32

MM =

Modello Base


Relazione tra impegno e size (Mod. base)

n Relazione tra MM e KDSIper tipo software

100 0

8 00

6 00

400

2 00

00 2 0 4 0 6 0 8 0 100 1 20

KD SI

Perso n-mo nt hs

Em bed d ed

Int ermedi a te

Sim pl e

6




Relazioni MM e Tdev - (Mod. base)

n Variazioni dei valori di MM e Tdev in funzione del tipo di software da sviluppare (modello base).

Volume = 32K Volume = 8K

MM Tdev MM Tdev Semplice 91 14 21 8 Intermedio 146 14 +60% 31 8 +48% Complesso 230 14 +153% 44 8 +110%


Distribuzione dell’impegno nel SLC

n Dopo aver calcolato l’impegno e la durata del progetto, COCOMO permette di distribuirli (in %) nelle fasi del ciclo di vita, tramite delle tabelle.uLa distribuzione è funzione delle dimensioni e del

tipo di progetto. Si presume che progetti piùgrandi richiedono più impegno nelle fasi di integrazione e test, ma riescono a comprimere la durata delle fasi di codifica del software utilizzando più team che lavorano in parallelo.

uPer progetti più piccoli si ipotizza una distribuzione più uniforme dell’impegno durante il progetto.

7




Distribuzione % per fasi - Mod. Base

Distribuzione % durata sviluppo (TDEV)

Pian. e requis. 10 11 12 13Progetto 19 19 19 19Sviluppo 63 59 55 51Integ. e test 18 22 26 30

Dimensione (in KDSI) Fasi 2 8 32 128

Pian. e requis 6 6 6 6Progetto 16 16 16 16Sviluppo 68 65 62 59Integ. e test 16 19 22 25

SW ORGANIC

Distribuzione % impegno sviluppo (MM)


Mod. Base - distribuzione % per fasi (2)

Fasi 2 8 32 128 512

Pian. e an.requis. 7 7 7 7 7Progetto 20 20 20 20 20Sviluppo 64 61 58 55 52Integ. e test 16 19 22 25 28

Pian. e an.requis. 16 18 20 22 24Progetto 24 25 26 27 28Sviluppo 56 52 48 44 40Integ. e test 20 23 26 29 32

MM

Tdev

SEMI DETACHEDDimensione (in KDSI)

8




Mod. Base - distribuzione % per fasi (3)

Pian. e requis. 8 8 8 8 8Progetto 18 18 18 18 18Sviluppo 60 57 54 51 48Integ. e test 22 25 28 31 34

Pian. e requis. 24 28 32 36 40Progetto 30 32 34 36 38Sviluppo 48 44 40 36 32Integ. e test 22 24 26 28 30

MM

Tdev

Dimensione (in KDSI)

Fasi 2 8 32 128 512

EMBEDDED


COCOMO I (Mod. Base) - esempio…..

n Modello base - software da produrre semplice (organic)uDSI (SLOC) da sviluppare = 32KuMM = 2.4 x (32)1.05 = 91 mesi-personauTdev = 2.5 x (91)0.38 = 14 mesi di duratauN° persone da impiegare = 91/14 = ~7 (FTE)

Produttività = 32K/14 = ~ 2,3K LOC al mese~ 115 LOC-giorno (ipotesi: mesi di 20 gg lav.)

~ 17 LOC-persona al giorno (ipotesi 7 FTE)

9




….esempio

n Quanti mesi-persona di programmazione?n Quanto dura (in mesi) la programmazione?n Quanti programmatori servono?uUsando le tabelle…. (Modello Base, Software di tipo

“Organic” ovvero “Semplice”)uMM (progr) = 0.62*91 = 56 mesi-personauTDev (progr) = 0.55*14 = 7.7 mesi di duratauN° risorse professionali = 56 / 7.7 = ~7 FTE

n NOTA: Se il Size in KSDI non è in tabella: interpolazione lineare.

n Costo programmatori: = 56 x 300 x 22 = 370.000 euro


COCOMO I - Modello intermedio

n Il modello intermedio differisce da quello base in quanto ha diversi valori dei coefficienti a, b, c e d e in quanto permette di correggere il calcolo base attraverso l’introduzione di un fattore di “aggiustamento”, che tiene conto della complessità del progetto.

n Il fattore di aggiustamento è definito dalla produttoriadei valori che assumono 15 fattori di complessità.

n Questi valori sono determinati dall’analista, in base alla sua esperienza, considerando le variabili di contesto dello specifico progetto ed utilizzando delle tabelle fornite da COCOMO.

10




Modello intermedio - costanti

Valori delle costanti a, b, c, d nel modello intermedio.

tipo di applicazione a b c d



Mod. intermedio - Fattore complessità

n Il modello intermedio aggiusta il calcolo dell’impegno introducendo un moltiplicatore il cui valore va determinato in base alla valutazione di 15 fattori di complessità (cost drivers). La formula di calcolo dell’impegno diventa:

MM = EAF x a KDSI b

dove: 15

EAF = ∏ (EM)i (produttoria di 15 fattori di complessità)i=1

u Ogni fattore può assumere fino a 6 diversi valori, in funzione del grado di influenza che si stima ha sul progetto (da “molto basso” a “estremamente alto”).

11




Mod. intermedio - fattori complessità...

Prodotton CPLX: product ComPLeXity (0.70 - 0.85 - 1.0 - 1.15 - 1.30 - 1.65)

Complessità globale del prodotto

n RELY: REquired software reliabiLitY (0.75-0.88-1.0-1.15-1.40-n/a)

Affidabilità richiesta (intesa come difettosità residua post consegna)

n DATA: DATA base size (n/a-0.94-1.0-1.08-1.16-n/a)

Dimensione dei dati gestiti dal software

Valori associati al giudizioE.HighV.HighHighStdLowV.Low


Sisteman TIME: execution TIME constraint (n/a-1.0-1.11-1.30-1.66-n/a)

Requisiti di efficienza richiesti al software

n STOR: main STORage constraint (n/a-1.0-1.06-1.21-1.56-n/a)

Requisiti di memoria centrale richiesti dal software

n VIRT - VIRTual machine volatility (n/a-0.87-1.0-1.15-1.30-n/a)

Frequenza con cui le caratteristiche del sistema target vengonomodificate durante lo sviluppo

n TURN - computer TURNaround time (0.87-1.0-1.07-1.15-n/a-n/a)

Vincoli sul tempo di risposta

…..fattori complessità...

12




Personalen ACAP - Analyst CAPability (1.40-1.19-1.0-0.86-0.71-n/a)

Efficienza del personale di analisin AEXP - Application EXPerience (1.29-1.13-1.0-0.91-0.82-n/a)

Esperienza (del personale) nello sviluppo di software similen PCAP - Programmer CAPability (1.42-1.17-1.0-0.86-0.7-n/a)

Efficienza del personale di programmazione

n VEXP - Virtual machine EXPerience (1.21-1.10-1.0-0.90-n/a-n/a)

Esperienza (del personale) nell’uso della macchina targetn LEXP - Program. Lang. EXPer. (1.14-1.07-1.0-0.95-n/a-n/a)

Esperienza nell’uso del linguaggio di programmazione

….fattori complessità...


Progetton MODP: MODern Program. practices (1.24-1.10-1.0-0.91-0.82-

n/a)

Uso di tecniche di programmazione efficienti

n TOOL - use of software TOOLs (1.24-1.10-1.0-0.91-0.83-n/a)

Uso di strumenti automatizzati

n SCED - SChEDule constraints (1.23-1.08-1.0-1.04-1.10-n/a)

Vincoli sul tempo di conclusione del progetto

….fattori complessità

13




nPer valutare l’influenza sul progetto dei fattori cheriguardano la esperienza del personale utilizzato (3 fattori LEXP, VEXP, AEXP), si potrebbero usarequesti criteri di classificazione dell’esperienza del personale:Very Low = 2- 4 mesi di esperienzaLow = 6- 8 mesi di esperienzaNominal = 1-1,5 anni di esperienzaHigh = 2-3 anni di esperienza

Valutare fattori di complessità - esempio


Modello intermedio - fattori comples.

Coefficiente correttivo M. Ba. Basso Nom. Alto M. Alto E.Alto

Attributi del prodottoAffidabilità richiesta 0,75 0,88 1,0 1,15 1,40Complessità prodotto 0,70 0,85 1,0 1,15 1,30 1,65Attributi del personaleEsperienza analisiti 1,40 1,19 1,0 0,86 0,71Esper. applicativa 1,29 1,13 1,0 0,91 0,82Esperienza progr. 1,42 1,17 1,0 0,86 0,70Attributi del progettoVincolo tempo svilup. 1,23 1,08 1,0 1,04 1,10

Modifica di M mediante 15 coefficienti correttiviESEMPI

14




COCOMO I - Modello Dettagliato….

n Il modello Dettagliato considera che l’influenza sul progetto degli stessi 15 fattori di complessità del modello intermedio vari in funzione delle fasi del ciclo di vita.

n Le fasi considerate sono:uRQ RequirementsuPD Product DesignuDD Detailed DesignuCT Code and Unit Testu IT Integrate & TestuMN Maintenance


….COCOMO I - Modello Dettagliato

n Ogni fattore (cost driver) assume valori specifici in funzione delle diverse fasi del ciclo di sviluppo.

Esempio per il fattore “efficienza del personale di analisi ”(ACAP)

15




Modello Dettagliato - costanti

Valori delle costanti a, b, c, d nel modello Detailed.

tipo di applicazione a b c d



Tipo di modello Base Intermedio Dettagliato

Caratteristiche generali progetto

Solo dimensione complessiva

coefficienti di correzione globali

coefficienti di correzione

per ciascuna fase

Semplice (organic)

M Sk= 2 4 1 05, ,

T M= 2 5 0 38, ,

M M cNom i= ∏1

15

M SNom k= 3 2 1 05, ,

idem

Intermedio (semi-detached)

M Sk= 30 112, ,

T M= 2 5 0 35, ,

M M cNom i= ∏1

15

M SNom k= 3 0 1 12, ,

idem

Complesso (embedded)

M Sk= 3 6 1 20, ,

T M= 2 5 0 32, ,

M M cNom i= ∏1

15

M SNom k= 2 8 1 20, ,

idem

COCOMO I - Modelli - Sinottico

16




COCOMO I - Workflow del metodo

n Si fa una previsione rispetto alle Kloc da produrre (per analogia, esperienza, usando la distribuzione Beta od altri metodi empirici).

n Si calcola con la formula COCOMO l’impegno in mesi-persona da prevedere per sviluppare il progetto.

n Si utilizzano le tabelle di distribuzione dell’impegno per determinare quanti mesi di lavoro servono di progettisti, sviluppatori, addetti ai test e distribuzione in esercizio.

n Si calcola il costo di queste risorse in base alle tariffe unitarie.n Si aggiunge l’impegno degli analisti per la fase di raccolta dei

requisiti, determinato in % rispetto al costo delle altre attività.n Si aggiunge il costo delle attività di supporto, non teniche,

determinato in % rispetto al costo delle altre attività.


Modello intermedio - esempio...

Il software è giudicato ORGANICO (a=3.2, b=1.05)I fattori di complessità sono i seguenti

Considerare un progetto di automazione ufficio.Il documento di analisi dei requisiti definisce 4 moduli.Le dimensioni sono stimate come segue:

data entry 0.6 KDSIdata update 0.6 KDSIquery 0.8 KDSIreport 1.0 KDSI

_________________________________System size tot. 3.0 KDSI

Fattore livello EAFcomplessità alto 1.15…… alto 1.06esperienza basso 1.13capacità program. basso 1.17

Tutti gli altri:val. nominale (1.0)

17




Modello intermedio - ….esempio...

Calcolo impegno richiesto in mesi-persona:

MM = (1.15*1.06*1.13*1.17) * 3.2 * (3.0) 1.05

= 1.61 * 3.2 * 3.17= 16.33

> 16 mesi-persona di impegno


Modello intermedio - …esempio...

Abbiamo stimato 16.33 mesi-persona per il progetto. Il software da sviluppare è stato giudicato “semplice”.

DURATA = 2.5 * (16.33) 0.38

= 2.5 * 2.89= 7.23

16.33 mesi-persona_________________ = 2.26 persone

7.23 mesi

> 7 mesi per completare

occorrono 2- 3 persone

Quante persone dovrebbero essere impegnate nel progetto?

18




Considerazioni su COCOMO I

n Modello base - errore < 20% nel 25% dei casi.n Modello intermedio - errore < 20% nel 68% dei

casi.n Modello avanzato - errore < 20% nel 70% dei

casi.n Ma…. usare le LOC come unità di misura premia

la inefficienza.n Poco utilizzabile a scopi previsionali nelle fasi alte

del SLC (deve essere noto il size!).n Inadeguato per linguaggi avanzati.


COCOMO I on line

nNASA4 www.jsc.nasa.gov/bu2/COCOMO.html

n Università di Magdeburgo (Germania)4 ivs.cs.uni-magdeburg.de/sw-

eng/us/java/COCOMO/co_test.shtmln University of Michigan – College of Engineering and

Computer Science4 www.engin.umd.umich.edu/CIS/course.des/cis525/js/f0

0/gamel/cocomo.html

www.softstarsystems.com

19




COCOMO II - Motivazioni

n Supportare riuso, prototyping e sviluppo CBSE.n Considerare la volatilità dei requisiti.n Considerare differenti granularità nella conoscenza

del problema.

X

0.25 X

4X

Ciclo di vita

Stima Impegno

Accettazione

Incertezza stima


Accuratezza stima vs fasi progetto

20




COCOMO II - I tipi di software…

nDifferenzia 5 tipologie di software:uEnd-User Programming (programmi piccoli e

flessibili, sviluppati dagli stessi utenti attraverso degli Application Generators, >98% del mercato),

u Infrastrutture (sistemi operativi, DBMS, networking systems),

uApplication Composition (applicazioni diversificate, da sviluppare ad hoc),


… tipologie di software

uApplication Generators & Composition Aids(prepackaged capabilities) è software incluso in pacchetti per utenti finali,

uSystems Integration (software altamente specializzato, incluso in sistemi di grandi dimensioni che richiedono notevole progettazione, anche se possono essere sviluppati in parte riutilizzando componenti).

21




CoCoMo II - modelli di stima

nCocomo II prevede 3 differenti modelli:u Early Prototyping - da usare nelle fasi iniziali o

nei primi cicli di uno sviluppo “a spirale”, mentre si fa analisi dei requisiti e specifica della soluzione di massima, utilizzando prototipi ed un forte riuso.

u Early Design - da usare quando si è nella fase iniziale di disegno della architettura.

u Post Architecture - da usare quando l’architettura è definita ed è definito nel dettaglio il piano di sviluppo.


COCOMO II - Unità di misura

n 3 possibili unità di misura della dimensione:u Object Points (da usare nello Early Prototyping

model).

u Function Points (solo gli Unadjusted, secondo la definizione IFPUG, da usare per Early Design e Post Architecture model).

u SLOC (Source Lines of Code secondo la definizione del SEI, da usare per Post Architecturemodel).

22




Utilizzo COCOMO II con FP

SpecificheCalcolo FP Calcolo LOCfp

pesati•spec. formali(ER DFD UML ..)•spec. testuali•schermate

Calcolo Sforzoe tempo: COCOMO

loc

Calcolo costoMM e T

$

mercato

parametri

parametri di aggiustamento


Modelli di stima vs fasi SLC

23




Relazione tra modelli e software

n Cocomo II non si applica agli end user programs, che hanno durata troppo breve per avere bisogno di una stima preventiva dell’impegno.

n Per le altre tipologie di software, va utilizzato uno dei tre modelli (Early Prototyping, Early Design, Post Architecture), a seconda delle specifiche del progetto e del momento della valutazione.


Relazione tra modelli e software

24




Early Prototyping Model

n Per stimare l’impegno (in mesi-persona) necessario a sviluppare un software, il modello COCOMO II usa una formula semplificata:

MM = ( NOP × (1 - %reuse/100 ) ) / PROD

NOP è il numero di object points (schermate, reports e moduli 3GL), da realizzare

PROD è la produttività (Ops/month) (valori tipicisono 40-50 Ops/month)


Object Points - Elementi di calcolo

n COCOMO II introduce alcuni altri elementi per il conteggio degli Object Points:srvr = n° di tabelle di dati di server su mainframe

utilizzate insieme a videate e reportsclnt = n° di tabelle di dati di client utilizzate insieme

a videate e reports

25




Object Points e pesi

n Gli Object Points sono il n° (pesato) di schermate, reports e componenti 3GL usati nella applicazione. Il loro peso si determina usando delle tabelle.

Pesi da assegnare

Classificazione della complessità


Early Prototyping - Processo di stima

nPer la stima dell’impegno, si procede come segue:1) si stimano gli object points da realizzare2) si classifica ogni istanza di object point in base alla stima del livello di “complessità”, semplice, media, difficile, utilizzando queste tabelle:

26




…..processo di stima….

3) si pesano gli object points utilizzando questa tabella:


….. processo di stima….

4) si sommano i valori pesati di tutti gli object points5) si determina l’incidenza del riuso, utilizzando la

formula:

NOP = (Object points - (100-%Riuso)) / 100

6) si determina il tasso di produttività PROD, utilizzando la tabella seguente:

27




7) l’impegno MM (in mesi-persona) si calcola infine con la formula semplificata:

MM = NOP / PROD

….. processo di stima


Early Prototyping – esempio stima

New Objects Points NOP = 103 (100-10)/100 = 92,7 (utilizzata % reuse = 10%)

15 screens (3 semplici, 11 medi, 1 difficile)4 reports (3 semplici, 1 difficile)5 moduli

Objects Points = (3x1 + 11x2 + 1x3) + (3x2 + 1x8) + (5x10) = 103

Impegno in mesi-persona = 92,7 / 25 = 3,7(utilizzato il tasso di produttività PROD = 25)

28




Early Design model

La formula per calcolare l’impegno (in mesi persona) è la seguente:

7

MM = a x Size b x ∏ (EAF)i + Pi=1

dove:a = costante (pari a 2.94 [nel 2000, era 2.45 nel 1997].b = esponente il cui valore va calcolato considerando 5

fattori relativi alla “scala” del progetto.EAF = Fattore di aggiustamento derivato dalla

valorizzazione di 7 parametri del progetto (“effortmultipliers” o “cost drivers”).

P = (ASLOC x (AT/100)) / ATPROD. (codice generato da tools)


Early Design model – Parametro Size

n Il volume del software (SIZE) deve essere calcolato tenendo conto della volatilità dei requisiti (fattore BRAK, che può aumentare il size) e del riuso(fattore REUSE che lo diminuisce).

u Volatilità dei requisiti. Si calcola con:Sizebrak = Size x (1 + Brak / 100)

dove:Brak = % di codice scartato a causa della volatilitàdei requisiti nel progetto

29




Early Design model - Fattore Riuso

n Il riuso viene considerato secondo un modello non lineare che parte da queste constatazioni:u è da prevedere un impegno del 5% circa (rispetto

al totale) per selezionare ed integrare il software da riusare;

u piccole modifiche da apportare al software da riusare possono richiedere impegni non proporzionali, in particolare per capire dove effettuare le modifiche e per effettuare i test delle interfacce.


Relazione riuso-costi

30




Early Design model - Riuso

n La formula per calcolare il riuso è:


Early Design model – Fattore SU

NOTA: se non c’è modifica nel codice, SU non va calcolato.

SU = Software understanding (= 0 se DM e CM = 0)

31




Early Design model - Fattore AA

Esempio di calcolodel riuso.


Cost drivers per Early Design Model

32




Cost drivers per Early Design Model


Valutare cost drivers - esempio

PDIF

PERS

33




Esponente del fattore di scala (1997)

n L’esponente b (fattore di scala) varia [1997] tra 0.91 e 1.15 e si calcola con la formula:

b = 0.91 + 0.01∑W i

Dove W i sono i livelli di influenza sul progetto assegnati a 5 diversi fattori di scala.

Val.max∑W =23,82

(tutti verylow)


Esponente del fattore di scala (2000)

n L’esponente b (fattore di scala) varia [2000] tra 0.91 e 1.22 e si calcola con la formula:

b = 0.91 + 0.01∑W i

Dove W i sono i livelli di influenza sul progetto assegnati a 5 diversi fattori di scala.

Val max∑W =30,92

(tutti verylow)

34




Fattori di scala

n I 5 fattori che costruiscono il valore dell’esponente b sono:uprecedenti (ambiente “noto”), flessibilità dello

sviluppo, architettura, coesione dei team, maturitàdel processo (in senso CMM).

n I possibili livelli dei fattori di scala sono 6, e considerano le economie di scala che i fattori possono introdurre nel progetto, da molto bassa a extra alta (∑W i = 0).

n Il valore massimo che può assumere l’esponente b(2000) è 1.22 (=tutti i fattori di scala introducono diseconomie). Se tutti i fattori sono “nominali” b = 1.0997.


Fattori di scala - pesi e criteri

Da B.Bohem e al., Software cost estimation with COCOMO II, Prentice-Hall, 2000

35




Fattore PMAT basato sul CMM

n Il valore da assegnare al fattore di scala PMAT, relativo al grado di maturità del processo di sviluppo, deriva da una analisi del livello di possesso (in %) delle 18 aree di processo chiave (KPAs).

Pmat =


Checklist per l’analisi delle KPAs

36




Early Design Model - Tempo

n La formula per calcolare il tempo necessario a completare il progetto è:

TDEV = 3 × (MM)(0.33+0.2*(B-1.01))


Post Architecture Model

La formula per calcolare l’impegno (in mesi persona) è la seguente:

17

MM = a x Size b x ∏ EMii=1

dove:a = costante (pari a 2.94 [2000])

b = esponente del fattore di scala, che tiene conto di 5 parametri di complessità del progetto che provocano diseconomie di scala. I parametri sono gli stessi dell’Early Design Model. Il valore di b varia tra 0.91 e 1.22 (si calcola come 0.91 + 0.01∑Wi).

∏EMi = produttoria di 17 fattori di progetto (”moltiplicatori di sforzo” o “cost drivers”), la cui influenza varia tra “very low” ed “extra high” con valori tra 0.75 e 1.67 (“nominale” = 1).

37




Valori dei cost drivers (1)

Da B.Bohem e al., Software cost estimation withCOCOMO II, Prentice-Hall , 2000

PRODOTTO




PIATTAFORMA

38






PERSONALE




PROGETTO

39




Criteri di rating dei cost drivers (1)



Criteri rating cost drivers (2)


40




COCOMO II - 7 vs 17 cost drivers

NOTA: I 7 cost drivers del modello Early Design comprendono i 17 del modello Post Architecture.


Dettaglio cost driver DATA

n Il cost driver Data considera gli effetti sull’impegnonello sviluppo di dover gestire grandi quantità di dati.

n Si calcola utilizzando il rapporto D/P (dimensione DB in bytes / Dimensione Software in Sloc), rapportandoloalla tabella seguente.

41




COCOMO II - Stima dei tempi

Per determinare la durata dello sviluppo Tdev, si usa la seguente equazione:

dove5

B = 0.91 + 0,01 x ∑ SFii=1

SF sono 5 fattori di scala (PREC, FLEX, RESL, TEAM, PMAT)

PM sono i mesi-persona di impegno stimati


COCOMO II – Cost driver SCED

Il cost driver SCED considera il maggior impegno prevedibile in un progetto che deve accelerare i tempi di completamento rispetto ad un progetto standard di caratteristiche simili.Il rapporto tra l’accelerazione (in %) ed il relativo valore da assegnare al cost driver (in scala ordinale), sono nella tabella successiva.

Ad esempio, ad una contrazione dei tempi del 25% (Very low) corrisponde un valore del cost driver pari a 1.43.

42




Riepilogo Cost Drivers (1)


Riepilogo Cost Drivers (2)

43




COCOMO II - Esempio Post Archit. (1)

n Un progetto di 100 KSLOC con una valutazione di influenza “extra alta” per tutti i 5 fattori di scala (W i), e nominale per tutti i cost drivers (EMi) avr à:u∑W i =0 ∏EMi = 1

n Si ha quindi (usando il Post Architecture Model):ub = 0.91 uMM = 2.94 x (100)0.91 x (1.0) = 194 mesi-persona

n Se i fattori di scala avessero tutti un influenza “molto bassa” e i cost drivers “nominale” si avrebbe:u∏EMi = 1 ∑W i =30.9ub = 1.22uMM = 2.94 x (100)1.22 x (1.0) = 810 mesi-persona

+300%!


COCOMO II - Esempio Post Archit. (1b)

n La durata Tdev del progetto sarà (considerando il fattore SCED = nominale = 100%):

Tdev = 3.67 x (810) (0.28 + 0.2 x (1.15-0.91) = 33 mesi

n Mentre lo staff dovrà essere composto da:

Staff = MM / Tdev = 810 / 33 = 25 persone

44




COCOMO II - Esempio Post Archit. (2)

n Un progetto di 80 KLoc ha tutti i cost drivers con influenza valutata “nominale” (ΠEmi = 1).

n Se i fattori di scala sono ugualmente tutti “nominali” (∑W i=18.97), si ha:ub = 0.91 + 0.01 x 18.97 = 1.10uMM = 2.94 x (80)1.10 x (1.0) = 365 mesi-persona

n Se i cost drivers fossero tutti “nominali” (=1) meno CLPX e RUSE “extra high” (= 1.3 x 1.29 = 1.67) e i fattori di scala tutti “molto bassi” (∑W i=30.92), si avrebbe:uΠEmi = 1.67 b = 0.91 + 0.01 x 30.92 = 1.22uMM = 2.94 x (80)1.22 x (1.67) = 1.030 mesi-persona


Altri modelli derivati da COCOMO

COCOTS - COstructive Cost of Off The Shelf products. Supporta nella valutazione del costo dell’acquisto di prodotti di mercato, inclusa la personalizzazione, l’integrazione nell’ambiente del cliente, il test.COQUALMO - COstructive QUAlity MOdel. Suppportanella valutazione del trade off tra costi e qualità del software, intesa come quantità di difetti residui dopo la consegna.CORADMO - COstructive Rapid Development Model. Supporta nella valutazione del costo conseguente alla riduzione dei tempi di sviluppo del software.

45




Bibliografia COCOMO II

n CSE Center for Software Engineeringusunset.usc.edu/research/COCOMOII/index.html

n B.Boehm & al, Software cost estimation withCOCOMO II, Prentice-Hall, 2000


Coqualmo - Defect removal

DeliveredDefects /

Ksloc

Documents

Cocomo