Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica                Polo di Latina         ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  ….Razionale del metodo COCOMO     n  ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Kloc come variabile indipendente    n...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  COCOMO I - Modello Base        n Il m...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Modello Base - costanti          I va...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Relazioni MM e Tdev - (Mod. base)    ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Distribuzione % per fasi - Mod. Base ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Mod. Base - distribuzione % per fasi ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  ….esempio    n Quanti mesi-persona di...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Modello intermedio - costanti        ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica Mod. intermedio - fattori complessità....
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica     ….fattori complessità...       Per...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Valutare fattori di complessità - ese...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  COCOMO I - Modello Dettagliato….     ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica   Modello Dettagliato - costanti      ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  COCOMO I - Workflow del metodo      n...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Modello intermedio - ….esempio...    ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Considerazioni su COCOMO I       n Mo...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  COCOMO II - Motivazioni    n Supporta...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  COCOMO II - I tipi di software…     n...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  CoCoMo II - modelli di stima    n Coc...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Utilizzo COCOMO II con FP            ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica Relazione tra modelli e software      ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Early Prototyping Model      n    Per...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica    Object Points e pesi    n Gli Objec...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica             …..processo di stima….    ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica               ….. processo di stima   ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica   Early Design model      La formula p...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica   Early Design model - Fattore Riuso  ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica   Early Design model - Riuso     n   L...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Early Design model - Fattore AA      ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Cost drivers per Early Design Model  ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Esponente del fattore di scala (1997)...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Fattori di scala       n I 5 fattori ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Fattore PMAT basato sul CMM    n Il v...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica   Early Design Model - Tempo      n   ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica     Valori dei cost drivers (1)       ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica        Valori dei cost drivers (3)    ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica     Criteri di rating dei cost drivers...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica   COCOMO II - 7 vs 17 cost drivers    ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  COCOMO II - Stima dei tempi     Per d...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Riepilogo Cost Drivers (1)   G.Raiss ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica COCOMO II - Esempio Post Archit. (1)  ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica COCOMO II - Esempio Post Archit. (2)  ...
Università La Sapienza – Polo di LATINA - Corso di laurea in ingegneria Informatica  Bibliografia COCOMO II      n CSE Cen...
Upcoming SlideShare
Loading in …5
×

Cocomo

960 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
960
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cocomo

  1. 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 - 2G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 1
  2. 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 - 4G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 2
  3. 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 - 6G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 3
  4. 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 - 8G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 4
  5. 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 - 10G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 5
  6. 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 - 12G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 6
  7. 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 - 14G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 7
  8. 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 - 16G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 8
  9. 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 - 18G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 9
  10. 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 - 20G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 10
  11. 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 - 22G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 11
  12. 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 - 24G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 12
  13. 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 - 26G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 13
  14. 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 - 28G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 14
  15. 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 - 30G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 15
  16. 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 - 32G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 16
  17. 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 - 34G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 17
  18. 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 - 36G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 18
  19. 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 - 38G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 19
  20. 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 - 40G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 20
  21. 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 - 42G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 21
  22. 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 - 44G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 22
  23. 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 - 46G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 23
  24. 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 - 48G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 24
  25. 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 - 50G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 25
  26. 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 - 52G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 26
  27. 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 - 54G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 27
  28. 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 - 56G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 28
  29. 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 - 58G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 29
  30. 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 - 60G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 30
  31. 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 - 62G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 31
  32. 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 - 64G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 32
  33. 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 - 66G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 33
  34. 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 - 68G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 34
  35. 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 - 70G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 35
  36. 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 - 72G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 36
  37. 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 - 74G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 37
  38. 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 - 76G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 38
  39. 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 - 78G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 39
  40. 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 - 80G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 40
  41. 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 - 82G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 41
  42. 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 - 84G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 42
  43. 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 - 86G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 43
  44. 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 - 88G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 44
  45. 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 - 90G.Raiss – Corso di INGEGNERIA DEL SOFTWARE - Materiale didattico 45

×