1. 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 - Ingegneria del software COCOMO - 2
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 1
2. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
….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).
G.Raiss - Ingegneria del software COCOMO - 3
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.
G.Raiss - Ingegneria del software COCOMO - 4
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 2
3. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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.
G.Raiss - Ingegneria del software COCOMO - 5
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).
G.Raiss - Ingegneria del software COCOMO - 6
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 3
4. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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à.
G.Raiss - Ingegneria del software COCOMO - 7
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).
G.Raiss - Ingegneria del software COCOMO - 8
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 4
5. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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 =
G.Raiss - Ingegneria del software COCOMO - 9
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
G.Raiss - Ingegneria del software COCOMO - 10
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 5
6. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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%
G.Raiss - Ingegneria del software COCOMO - 11
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.
G.Raiss - Ingegneria del software COCOMO - 12
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 6
7. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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)
G.Raiss - Ingegneria del software COCOMO - 13
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
G.Raiss - Ingegneria del software COCOMO - 14
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 7
8. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
G.Raiss - Ingegneria del software COCOMO - 15
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)
G.Raiss - Ingegneria del software COCOMO - 16
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 8
9. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
….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
G.Raiss - Ingegneria del software COCOMO - 17
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.
G.Raiss - Ingegneria del software COCOMO - 18
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 9
10. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
Modello intermedio - costanti
Valori delle costanti a, b, c, d nel modello
intermedio.
tipo di applicazione a b c d
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
G.Raiss - Ingegneria del software COCOMO - 19
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”).
G.Raiss - Ingegneria del software COCOMO - 20
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 10
11. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
G.Raiss - Ingegneria del software COCOMO - 21
…..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
G.Raiss - Ingegneria del software COCOMO - 22
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 11
12. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
….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
G.Raiss - Ingegneria del software COCOMO - 23
….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
G.Raiss - Ingegneria del software COCOMO - 24
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 12
13. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
G.Raiss - Ingegneria del software COCOMO - 25
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
G.Raiss - Ingegneria del software COCOMO - 26
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 13
14. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
G.Raiss - Ingegneria del software COCOMO - 27
….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)
G.Raiss - Ingegneria del software COCOMO - 28
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 14
15. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
Modello Dettagliato - costanti
Valori delle costanti a, b, c, d nel modello Detailed.
tipo di applicazione a b c d
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
G.Raiss - Ingegneria del software COCOMO - 29
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
G.Raiss - Ingegneria del software COCOMO - 30
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 15
16. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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à.
G.Raiss - Ingegneria del software COCOMO - 31
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
G.Raiss - Ingegneria del software COCOMO - 32
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 16
17. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
G.Raiss - Ingegneria del software COCOMO - 33
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
G.Raiss - Ingegneria del software COCOMO - 34
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 17
18. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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.
G.Raiss - Ingegneria del software COCOMO - 35
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
G.Raiss - Ingegneria del software COCOMO - 36
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 18
19. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
G.Raiss - Ingegneria del software COCOMO - 37
Accuratezza stima vs fasi progetto
G.Raiss - Ingegneria del software COCOMO - 38
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 19
20. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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),
G.Raiss - Ingegneria del software COCOMO - 39
… 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).
G.Raiss - Ingegneria del software COCOMO - 40
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 20
21. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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.
G.Raiss - Ingegneria del software COCOMO - 41
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).
G.Raiss - Ingegneria del software COCOMO - 42
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 21
22. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
G.Raiss - Ingegneria del software COCOMO - 43
Modelli di stima vs fasi SLC
G.Raiss - Ingegneria del software COCOMO - 44
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 22
23. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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.
G.Raiss - Ingegneria del software COCOMO - 45
Relazione tra modelli e software
G.Raiss - Ingegneria del software COCOMO - 46
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 23
24. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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)
G.Raiss - Ingegneria del software COCOMO - 47
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
G.Raiss - Ingegneria del software COCOMO - 48
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 24
25. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
G.Raiss - Ingegneria del software COCOMO - 49
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:
G.Raiss - Ingegneria del software COCOMO - 50
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 25
26. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
…..processo di stima….
3) si pesano gli object points utilizzando questa
tabella:
G.Raiss - Ingegneria del software COCOMO - 51
….. 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:
G.Raiss - Ingegneria del software COCOMO - 52
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 26
27. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
….. processo di stima
7) l’impegno MM (in mesi-persona) si calcola infine con
la formula semplificata:
MM = NOP / PROD
G.Raiss - Ingegneria del software COCOMO - 53
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)
G.Raiss - Ingegneria del software COCOMO - 54
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 27
28. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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)
G.Raiss - Ingegneria del software COCOMO - 55
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
G.Raiss - Ingegneria del software COCOMO - 56
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 28
29. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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.
G.Raiss - Ingegneria del software COCOMO - 57
Relazione riuso-costi
G.Raiss - Ingegneria del software COCOMO - 58
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 29
30. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
Early Design model - Riuso
n La formula per calcolare il riuso è:
G.Raiss - Ingegneria del software COCOMO - 59
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.
G.Raiss - Ingegneria del software COCOMO - 60
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 30
31. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
Early Design model - Fattore AA
Esempio di calcolo
del riuso.
G.Raiss - Ingegneria del software COCOMO - 61
Cost drivers per Early Design Model
G.Raiss - Ingegneria del software COCOMO - 62
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 31
32. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
Cost drivers per Early Design Model
G.Raiss - Ingegneria del software COCOMO - 63
Valutare cost drivers - esempio
PDIF
PERS
G.Raiss - Ingegneria del software COCOMO - 64
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 32
33. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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)
G.Raiss - Ingegneria del software COCOMO - 65
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)
G.Raiss - Ingegneria del software COCOMO - 66
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 33
34. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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.
G.Raiss - Ingegneria del software COCOMO - 67
Fattori di scala - pesi e criteri
Da B.Bohem e al., Software cost estimation with COCOMO II, Prentice-Hall, 2000
G.Raiss - Ingegneria del software COCOMO - 68
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 34
35. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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 =
G.Raiss - Ingegneria del software COCOMO - 69
Checklist per l’analisi delle KPAs
G.Raiss - Ingegneria del software COCOMO - 70
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 35
36. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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))
G.Raiss - Ingegneria del software COCOMO - 71
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).
G.Raiss - Ingegneria del software COCOMO - 72
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 36
37. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
Valori dei cost drivers (1)
PRODOTTO
Da B.Bohem e al., Software cost estimation with COCOMO II, Prentice-Hall, 2000
G.Raiss - Ingegneria del software COCOMO - 73
Valori dei cost drivers (2)
PIATTAFORMA
Da B.Bohem e al., Software cost estimation with COCOMO II, Prentice-Hall, 2000
G.Raiss - Ingegneria del software COCOMO - 74
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 37
38. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
Valori dei cost drivers (3)
PERSONALE
Da B.Bohem e al., Software cost estimation with COCOMO II, Prentice-Hall, 2000
G.Raiss - Ingegneria del software COCOMO - 75
Valori dei cost drivers (4)
PROGETTO
Da B.Bohem e al., Software cost estimation with COCOMO II, Prentice-Hall, 2000
G.Raiss - Ingegneria del software COCOMO - 76
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 38
39. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
Criteri di rating dei cost drivers (1)
Da B.Bohem e al., Software cost estimation with COCOMO II, Prentice-Hall, 2000
G.Raiss - Ingegneria del software COCOMO - 77
Criteri rating cost drivers (2)
Da B.Bohem e al., Software cost estimation with COCOMO II, Prentice-Hall, 2000
G.Raiss - Ingegneria del software COCOMO - 78
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 39
40. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
COCOMO II - 7 vs 17 cost drivers
NOTA: I 7 cost drivers del modello Early Design
comprendono i 17 del modello Post Architecture.
G.Raiss - Ingegneria del software COCOMO - 79
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.
G.Raiss - Ingegneria del software COCOMO - 80
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 40
41. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
G.Raiss - Ingegneria del software COCOMO - 81
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.
G.Raiss - Ingegneria del software COCOMO - 82
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 41
42. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
Riepilogo Cost Drivers (1)
G.Raiss - Ingegneria del software COCOMO - 83
Riepilogo Cost Drivers (2)
G.Raiss - Ingegneria del software COCOMO - 84
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 42
43. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
u MM = 2.94 x (100)1.22 x (1.0) = 810 mesi-persona
G.Raiss - Ingegneria del software COCOMO - 85
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
G.Raiss - Ingegneria del software COCOMO - 86
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 43
44. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
u MM = 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.22
u MM = 2.94 x (80)1.22 x (1.67) = 1.030 mesi-persona
G.Raiss - Ingegneria del software COCOMO - 87
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.
G.Raiss - Ingegneria del software COCOMO - 88
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 44
45. Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica
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
G.Raiss - Ingegneria del software COCOMO - 89
Coqualmo - Defect removal
Delivered
Defects /
Ksloc
G.Raiss - Ingegneria del software COCOMO - 90
G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 45