Cocomo

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

Polo di Latina Corso
@ 2006

La stima dei costi del
software. Il metodo
CoCoMo
Gianluigi Raiss
Dipartimento di Informatica e Sistemistica
Università di Roma “La Sapienza”

raiss@dis.uniroma1.it – raiss@cnipa.it
http://www.dis.uniroma1.it/~raiss/

G.Raiss - Ingegneria del software COCOMO - 1

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.


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


….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 tecnica
fino al termine di quella di integrazione e test.
n L’impegno necessario alla raccolta ed analisi dei
requisiti 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.



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




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

n Organic (semplice)
u Applicazioni semplici e di limitate dimensioni
(<50KDSI), requisiti poco stringenti e poco variabili,
ambiente di sviluppo noto e non innovativo.
n Semi-detached (intermedio)
u Complessità e dimensioni medie (fino a 300 KDSI).

n Embedded (complesso)
u Applicazioni complesse, con attento controllo del
processo e rigidi vincoli sulla qualità (i.e. sistemi real
time, applicazioni militari o per il volo).




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,38
Intermedia 3 1,12 2,5 0,35
Complessa 3,6 1,2 2,5 0,32

Modello
Base
MM =


Relazione tra impegno e size (Mod. base)
100 0 P e rso n- m o nt hs
n Relazione tra
Em be d d ed
MM e KDSI
8 00
per tipo
software
6 00
I nt er m e di a te

400
S im pl e

2 00

0
0
20 40 60 80 100 1 20
KD S I




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.
u La 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.
u Per progetti più piccoli si ipotizza una
distribuzione più uniforme dell’impegno durante il
progetto.




Distribuzione % per fasi - Mod. Base
SW ORGANIC Dimensione (in KDSI)
Fasi 2 8 32 128

Pian. e requis. 10 11 12 13 Distribuzione
Progetto 19 19 19 19
% durata
Sviluppo 63 59 55 51
sviluppo
Integ. e test 18 22 26 30
(TDEV)

Pian. e requis 6 6 6 6 Distribuzione
Progetto 16 16 16 16
% impegno
Sviluppo 68 65 62 59
sviluppo
Integ. e test 16 19 22 25
(MM)


Mod. Base - distribuzione % per fasi (2)

SEMI DETACHED
Dimensione (in KDSI)
Fasi 2 8 32 128 512

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

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




Mod. Base - distribuzione % per fasi (3)
EMBEDDED
Dimensione (in KDSI)
Fasi 2 8 32 128 512

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

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


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

n Modello base - software da produrre semplice (organic)
u DSI (SLOC) da sviluppare = 32K
u MM = 2.4 x (32)1.05 = 91 mesi-persona
u Tdev = 2.5 x (91)0.38 = 14 mesi di durata
u N° 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)




….esempio

n Quanti mesi-persona di programmazione?
n Quanto dura (in mesi) la programmazione?
n Quanti programmatori servono?
u Usando le tabelle…. (Modello Base, Software di tipo
“Organic” ovvero “Semplice”)
u MM (progr) = 0.62*91 = 56 mesi-persona

u TDev (progr) = 0.55*14 = 7.7 mesi di durata

u N° 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 produttoria
dei 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.




Modello intermedio - costanti

Valori delle costanti a, b, c, d nel modello
intermedio.
Semplice 3,2 1,05 2,5 0,38
Intermedia 3 1,12 2,5 0,35
Complessa 2,8 1,2 2,5 0,32


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”).



Mod. intermedio - fattori complessità...
Valori associati al giudizio
Prodotto V.Low Low Std High V.High E.High

n 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


…..fattori complessità...

Sistema
n 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 vengono
modificate 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à...
Personale
n ACAP - Analyst CAPability (1.40-1.19-1.0-0.86-0.71-n/a)
Efficienza del personale di analisi
n AEXP - Application EXPerience (1.29-1.13-1.0-0.91-0.82-n/a)
Esperienza (del personale) nello sviluppo di software simile
n 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 target
n 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à

Progetto
n 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




Valutare fattori di complessità - esempio

n Per valutare l’influenza sul progetto dei fattori che
riguardano la esperienza del personale utilizzato (3
fattori LEXP, VEXP, AEXP), si potrebbero usare
questi criteri di classificazione dell’esperienza del
personale:
Very Low = 2- 4 mesi di esperienza
Low = 6- 8 mesi di esperienza
Nominal = 1-1,5 anni di esperienza
High = 2-3 anni di esperienza


Modello intermedio - fattori comples.
Modifica di M mediante 15 coefficienti correttivi
ESEMPI
Coefficiente correttivo M. Ba. Basso Nom. Alto M. Alto E.Alto

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




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:
u RQ Requirements
u PD Product Design

u DD Detailed Design

u CT Code and Unit Test

u IT Integrate & Test

u MN 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)




Modello Dettagliato - costanti

Valori delle costanti a, b, c, d nel modello Detailed.
Semplice 3,2 1,05 2,5 0,38
Intermedia 3 1,12 2,5 0,35
Complessa 2,8 1,2 2,5 0,32


COCOMO I - Modelli - Sinottico

Tipo di modello Base Intermedio Dettagliato
Caratteristiche Solo dimensione coefficienti di coefficienti di
generali progetto complessiva correzione globali correzione
per ciascuna fase
M = 2 ,4 S k
1, 05 15
Semplice idem
M = M Nom∏ ci
(organic) T = 2,5 M 0 , 38 1

M Nom = 3,2 Sk
1, 0 5

M = 3,0 Sk
1,1 2 15
M = M Nom∏ ci
Intermedio idem
(semi-detached) T = 2,5 M 0, 35 1

M Nom = 3,0 S k1,12
M = 3,6 Sk
1 , 20 15
Complesso M = M Nom∏ ci
idem
(embedded) T = 2,5 M 0 , 32
1

M Nom = 2,8 S k1,20




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...
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 KDSI
data update 0.6 KDSI
query 0.8 KDSI
report 1.0 KDSI
_________________________________
System size tot. 3.0 KDSI

Il software è giudicato ORGANICO (a=3.2, b=1.05)
I fattori di complessità sono i seguenti
Fattore livello EAF
complessità alto 1.15
…… alto 1.06 Tutti gli altri:
esperienza basso 1.13 val. nominale (1.0)
capacità program. basso 1.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 mesi per completare
= 7.23

Quante persone dovrebbero essere impegnate
nel progetto?
16.33 mesi-persona
_________________ = 2.26 persone
7.23 mesi occorrono 2- 3 persone




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

n NASA
4 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.shtml
n University of Michigan – College of Engineering and
Computer Science
4 www.engin.umd.umich.edu/CIS/course.des/cis525/js/f0
0/gamel/cocomo.html

www.softstarsystems.com




COCOMO II - Motivazioni

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

Incertezza Stima
stima Impegno X

Accettazione
0.25 Ciclo di
X vita

Accuratezza stima vs fasi progetto




COCOMO II - I tipi di software…

n Differenzia 5 tipologie di software:
u End-User Programming (programmi piccoli e
flessibili, sviluppati dagli stessi utenti attraverso
degli Application Generators, >98% del mercato),
u Infrastrutture (sistemi operativi, DBMS, networking
systems),
u Application Composition (applicazioni diversificate,
da sviluppare ad hoc),


… tipologie di software
u Application Generators & Composition Aids
(prepackaged capabilities) è software incluso in
pacchetti per utenti finali,
u Systems Integration (software altamente
specializzato, incluso in sistemi di grandi dimensioni
che richiedono notevole progettazione, anche se
possono essere sviluppati in parte riutilizzando
componenti).




CoCoMo II - modelli di stima

n Cocomo 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 Architecture
model).




Utilizzo COCOMO II con FP

parametri di aggiustamento

Specifiche
•spec. formali Calcolo FP fp Calcolo LOC
(ER DFD pesati
UML ..)
•spec. testuali loc
•schermate parametri

MM e T Calcolo Sforzo
$ Calcolo costo e tempo: COCOMO

mercato


Modelli di stima vs fasi SLC




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




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 tipici
sono 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 reports
clnt = n° di tabelle di dati di client utilizzate insieme
a videate e reports




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.
Classificazione
della complessità

Pesi da
assegnare


Early Prototyping - Processo di stima

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




…..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 points
5) 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:




….. processo di stima

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


Early Prototyping – esempio stima

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
New Objects Points NOP =
103 (100-10)/100 = 92,7 (utilizzata % reuse = 10%)
Impegno in mesi-persona = 92,7 / 25 = 3,7
(utilizzato il tasso di produttività PROD = 25)




Early Design model
La formula per calcolare l’impegno (in mesi persona)
è la seguente:
7
MM = a x Size bx ∏ (EAF)i + P
i=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 (“effort
multipliers” 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




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




Early Design model - Riuso
n La formula per calcolare il riuso è:


Early Design model – Fattore SU
SU = Software understanding (= 0 se DM e CM = 0)

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



Early Design model - Fattore AA

Esempio di calcolo
del riuso.


Cost drivers per Early Design Model




Cost drivers per Early Design Model


Valutare cost drivers - esempio
PDIF

PERS




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 very
low)


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 very
low)




Fattori di scala

n I 5 fattori che costruiscono il valore dell’esponente
b sono:
u precedenti (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




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




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
b x∏
MM = a x Size EMi
i=1

dove:
a = costante (pari a 2.94 [2000])
b = esponente del fattore di scala, che tiene conto di 5 parametri d i
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).




Valori dei cost drivers (1)

PRODOTTO




PIATTAFORMA





PERSONALE




PROGETTO





Criteri di rating dei cost drivers (1)



Criteri rating cost drivers (2)





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’impegno
nello sviluppo di dover gestire grandi quantità di dati.
n Si calcola utilizzando il rapporto D/P (dimensione DB in
bytes / Dimensione Software in Sloc), rapportandolo
alla tabella seguente.




COCOMO II - Stima dei tempi

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

dove
5
B = 0.91 + 0,01 x ∑ SFi
i=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% ( ery low)
V
corrisponde un valore del cost driver pari a 1.43.




Riepilogo Cost Drivers (1)


Riepilogo Cost Drivers (2)




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
u MM = 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.9
+300%!
u b = 1.22



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




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

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.22
u MM = 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. Suppporta
nella 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.




Bibliografia COCOMO II

n CSE Center for Software Engineering
usunset.usc.edu/research/COCOMOII/index.html
n B.Boehm & al, Software cost estimation with
COCOMO II, Prentice-Hall, 2000


Coqualmo - Defect removal

Delivered
Defects /
Ksloc



Cocomo

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a Cocomo

Semelhante a Cocomo (20)

Cocomo