Lezione 17. Pianificazione e stima dei costi

1
Lezione 17. Pianificazione e stima dei costi

• S2001, Cap. 23
• GJM91, Sez. 8.2
• Composizione dei costi
• Misure di produttività (LOC, FP, OP)
• Tecniche di stima dei costi di sviluppo software
• Stima algoritmica dei costi
• il modello COCOMO81
• il modello COCOMO 2

2
Pianificazione di progetto e stime di costi

• Nella fase di planning di un progetto vengono
  descritte
• le attività in cui il progetto si articola
• le loro interdipendenze logiche e temporali
  (sequenziali / parallele)
• lindividuazione e allocazione di man-power alle
  singole attività (staffing)
• Ma un planning dettagliato deve anche
  quantificare, per ogni attività, il costo,
  suddiviso in
• costi di acquisizione/manutenzione di
  hardware/software
• costi di viaggio e training
• costi del personale coinvolto nel lavoro
  (dominante)
• La stima del costo è essenziale
• per allocare un budget di progetto
• per definire il prezzo da proporre al Cliente nel
  contratto

3

• I costi del personale che sviluppa il sistema
  comprendono
• salari di ingegneri del software e programmatori
• overheads (per una quota relativa allo staff
  coinvolto)
• riscaldamento, illuminazione, affitto spazi
  ufficio...
• servizi di segreteria, ufficio personale,
  assicurazioni, servizi legali, biblioteca, mensa,
  pulizie...
• collegamenti rete e telefonici
• contributi casse pensioni...
• Normalmente gli overheads sono una o due volte i
  salari
• un ing. che guadagna 100 ML./anno costa 200-300
  ML./anno alla sua organizzazione

4
Fattori nel calcolo dei prezzi del software
5
Produttività del programmatore e impatto sui
costi di progetto

• Si misura il software secondo qualche parametro,
  e
• si divide per il tempo-programmatore consumato
• (-) Le metriche basate su quantità/tempo non
  tengono conto del fattore qualità
• Parametri considerati
• misure di dimensione
• linee di codice sorgente
• linee di codice oggetto
• misure di funzionalità
• function points

Un modello altamente grossolano
Dimensione team programmazione ( persone)
/
Durata progetto (mesi)
Stima delle linee di codice del sistema (LOC)
/
Man-power necessario (mesi-uomo)


Costo progetto (M.lire)
Prezzo al Cliente (M.lire)
Produttività (LOC/mese-uomo)
Costo unitario (salarioverheads) (M.lire/mese-uom
o)
6
Linee di codice (LOC)

• Misura classica linee di codice sorgente per
  mese-uomo, includendo analisi, progetto,
  validazione, documentazione. Ma
• Da FORTRAN a C il concetto di linea di codice
  si complica
• Diversi criteri di conteggio (commenti?,
  dichiarazioni di dati?, comandi su piu linee?
  macro-expansion?)
• I programmatori verbosi sono più produttivi?
• I programmatori in linguaggi a più basso livello
  sono più produttivi?
• Il programmatore che riusa software già
  disponibile è meno produttivo?
• Un programmatore meno produttivo puo produrre
  codice
• piu affidabile,
• piu facile da capire
• piu facile da mantenere e modificare

7
Tempi di sviluppo con linguaggi ad alto / basso
livello
8
Esempio
4
9
Valori tipici di produttività in LOC

• Real-time embedded systems
• 40-160 LOC/P-month (mese-programmatore)
• Systems programs
• 150-400 LOC/P-month
• Commercial applications
• 200-800 LOC/P-month
• In Extreme Programming (continua evoluzione del
  codice) LOC è poco significativa Beck2000

10
Function points (Albrecht 79)

• Metrica indipendente dal linguaggio (ma molto
  soggettiva) e orientata a sistemi di
  data-processing.
• Una prima stima è possibile appena definite le
  interazioni del sistema con lesterno, prima del
  progetto dettagliato
• Si basa sul conteggio di alcuni elementi del
  programma
• external inputs and outputs
• user interactions
• external interfaces
• files used by the system
• E definita come somma pesata del numero di
  occorrenze degli elementi
• i pesi proposti da Albrecht vanno da un valore 3
  (per input dallesterno) a un valore 15 (per file
  interni gestiti dal programma)
• UFC (Unadjusted Function Count) ? i ( elem.
  tipo i) peso i
• Per ottenere il valore FC finale, UFC viene poi
  modificato in base a parametri di complessità del
  progetto, quali
• il grado di distributività, di riuso, di
  performance, ...

11

• Produttività function points / P-month
• Per un dato linguaggio si può definire, basandosi
  su dati storici, il numero medio di LOC per
  Function Point (AVC).
• Se si dispone di una stima dei Function Points di
  un nuovo sistema S, si puo stimare la dimensione
  del parametro LOC di S
• LOC(S) Function Points(S) AVC
• Valori tipici di AVC
• Linguaggio assembler 200-300 LOC/FP
• Linguaggio di 4a generazione 20-40 LOC/FP

12
Object points

• Object points are an alternative function-related
  measure to function points, when 4GLs (-gt) are
  used
• Object points do not count object classes, they
  are obtained by a weighted estimate of
• The number of separate screens displayed (weights
  1, 2, 3)
• The number of reports produced by the
  system(weights 2, 5, 8)
• The number of 3GL modules (high level
  programming languages such as Java) needed to
  supplement the 4GL code (weight 10)
• Easily estimated from system specification (i.e.
  early)
• Used in COCOMO-2 estimation model (---gt)

13
(4GL fourth generation language)
An "application specific" language. The term was
invented by Jim Martin to refer to
non-procedural high level languages built around
database systems. The first three generations
were developed fairly quickly, but it was still
frustrating, slow, and error prone to program
computers, leading to the first "programming
crisis", in which the amount of work that might
be assigned to programmers greatly exceeded the
amount of programmer time available to do it.
Meanwhile, a lot of experience was gathered in
certain areas, and it became clear that certain
applications could be generalised by adding
limited programming languages to them. Thus were
born report-generator languages, which were fed a
description of the data format and the report to
generate and turned that into a COBOL (or other
language) program which actually contained the
commands to read and process the data and place
the results on the page. Some other successful
4th-generation languages are database query
languages, e.g. SQL Focus, Metafont,
PostScript, RPG-II, S, IDL-PV/WAVE, Gauss,
Mathematica and data-stream languages such as
AVS, APE, Iris Explorer.
14
Valori tipici di produttività in Object Points

• In object points, productivity has been measured
  between 4 and 50 object points/month depending on
  tool support and developer capability (Boehm 95)

15
Fattori che influenzano la produttività
Ma, a parità di qualità del codice, un
programmatore puo essere fino a 10 volte piu
produttivo di un altro (Sackman 68)
16
Tecniche di stima di costi

• Minate da molti elementi di incertezza
• Requirements (in evoluzione, anche in dipendenza
  dal processo di sviluppo scelto)
• Personale (variabilità della produttività
  individuale)
• Tecnologie in parte ancora da definire,
• La scarsa affidabilità delle tecniche di stima
  dei costi scientifiche puo indurre a stime più
  politiche
• con la legge di Parkinson Limpegno (effort)
  necessario è quello possibile
• il cliente vuole il risultato dopo 12 mesi,
• (e lo sviluppatore ha 5 persone disponibili) gt
• lo sforzo stimato è 60 mesi-uomo
• con il criterio pricing to win
• il costo stimato è uguale alla disponibilità
  del Cliente...
• con il criterio del costo fisso
• anziché stimare i costi per un obiettivo
  prefissato
• si fissano i costi, e si ridimensionano gli
  obiettivi (dinamicamente)

17

• Criteri empirici più seri
• Valutazione iterativa da parte di un insieme di
  esperti (di dominio e tecnologia), fino a
  convergenza sulla previsione
• Valutazione per analogia con progetti nello
  stesso settore
• Modellazione algoritmica dei costi
• previsione dei costi secondo una
  formula/algoritmo che fa dipendere i costi da
  attributi del prodotto (tipicamente LOC), del
  progetto, del processo
• la formula è indotta dalla osservazione di dati
  storici sperimentali (valori degli attributi,
  costi) relativi a un corpus di progetti
  precedenti.
• Per progetti complessi, Boehm suggerisce di
  applicare piu tecniche di predizione dei costi,
  fino a quando i risultati convergono.

18
Algorithmic cost modelling

• Empirical method, based on the analysis of
  historical data (completed projects) and
  identification of best fit formula
• Effort is estimated as a function of product,
  project and process attributes whose values are
  estimated by project managers
• Effort A SizeB M
• A is an organisation-dependent constant (local
  practices, type of developed SW),
• B reflects the disproportionate effort for large
  projects (between 1 and 1.5)
• M is a multiplier reflecting product, process and
  people attributes
• Size estimated in LOC, FP, OP.
• Most models are similar but with different values
  for A, B and M

19
The COCOMO model Boehm 81

• COnstructive COst MOdel developed at TRW, a US
  defense contractor - Versions in 81, 89, 95.
• Provided with support tools, but independent
  from software vendors...
• Based on a cost database of more than 60
  different projects
• Exists in three stages
• 1. Basic - Gives an order of magnitude estimate
  based on product attributes
• 2. Intermediate - modifies basic estimate using
  project and process attributes
• 3. Advanced - Estimates project phases and parts
  (subsystems) separately. Not discussed here

20
1. Basic COCOMO formula for project classes

• simple
• small teams, familiar environment,
  well-understood applications, simple
  non-functional requirements (EASY)
• PM 2.4 (KDSI) 1.05 TDEV 2.5 (PM) 0.38
• moderate
• Project team may have experience mixture, system
  may have more significant non-functional
  constraints, organization may have less
  familiarity with application (HARDER)
• PM 3 (KDSI) 1.12 TDEV 2.5 (PM) 0.35
• embedded Hardware/software systems
• tight constraints, including local regulations
  and operational procedures unusual for team to
  have deep application experience (HARD)
• PM 3.6 (KDSI) 1.2 TDEV 2.5 (PM) 0.32
• KDSI thousands of Delivered Source Instructions
  ( source lines, excl. comments)
• PM Programmer Months (Effort)
• TDEV Expected duration of project (Time) )

21
Effort estimates
22
Esempi di stime in basic COCOMO

• Simple project , 32 KDSI
• PM 2.4 (32) 1.05 91 personmonth
• TDEV 2.5 (91) 0.38 14 month
• N 91/14 6.5 person
• Embedded project, 128 KDSI
• PM 3.6 (128)1.2 1216 person-months
• TDEV 2.5 (1216)0.32 24 months
• N 1216/24 51 persons

Effort (PM)
Durata (TDEV)
Numero persone necessarie (N)
Effort (PM)
Durata (TDEV)
Numero persone disponibili
23
COCOMO assumptions

• Implicit productivity estimate (but it still
  depends on size!)
• Simple mode 16 LOC/day
• Embedded mode 4 LOC/day
• Time required is a function of total effort, NOT
  team size
• Not clear how to adapt model to personnel
  availability

24
2. Intermediate COCOMO

• Takes basic COCOMO as starting point
• Identifies personnel, product, computer and
  project attributes which affect cost
• Multiplies basic COCOMO cost (required effort) by
  attribute multipliers which may increase or
  decrease costs
• Multipliers are assigned values in the range
  0.7, 1.66
• multiplier lt 1 implies reduced cost

25
Intermediate COCOMO attributes (--gt multipliers)

• Personnel attributes
• Analyst capability
• Programmer capability
• Programming language experience
• Application experience
• Product attributes
• Reliability requirement
• Database size
• Product complexity

• Computer attributes
• (i.e. constraints imposed on SW by the adopted
  HW)
• Execution time constraints
• Memory space constraints
• Project attributes
• Modern programming practices
• structured programming, when COCOMO was defined
• O-O programming today
• Software tools
• Required development schedule
• Mismatch between basic COCOMO and Client schedule
  gives attribute gt 1

• Model tuning - Each organization must identify
  its own attributes and associated multiplier
  values
• A statistically significant database of detailed
  cost information is necessary

26
Example

• Embedded software system on microcomputer
  hardware.
• Basic COCOMO predicts a 45 person-month effort
  requirement
• Attributes
• RELY 1.15,
• STOR 1.21,
• TIME 1.10,
• TOOL 1.10
• Intermediate COCOMO predicts
• 45 1.151.21.1.101.10 76 person-months.
• Total cost 76 7000 532, 000

27
Management options for previous example
28
Costs of alternatives based on varying COCOMO
params.
29
Calibrazione dei parametri delle formule COCOMO
Se il Predicted effort secondo i parametri
COCOMO standard si scosta dai valori
sperimentali misurati (i punti sul diagramma), i
parametri vengono modificati secondo il criterio
dei minimi quadrati, portando a una nuova curva
di previsione ottimale
30
Staffing requirements

• Staff required cant be computed by diving the
  effort (man months) by the required schedule
• The number of people working on a project varies
  depending on the phase of the project
• The more people work on the project, the more
  total effort is usually required
• Very rapid build-up of people often correlates
  with schedule slippage

31
COCOMO 2 levels

• COCOMO 2 is a 3 level model that allows
  increasingly detailed estimates to be prepared as
  development progresses
• L1. Early prototyping level
• Estimates based on object points and a simple
  formula is used for effort estimation
• L2. Early design level
• Estimates based on function points that are then
  translated to LOC
• (L3. Post-architecture level
• Estimates based on lines of source code )

32
L1. Early prototyping level

• Supports prototyping projects and projects where
  there is extensive reuse
• Based on standard estimates of developer
  productivity in object points/month
• Takes CASE tool use into account
• Formula is simplified
• PM ( NOP (1 - reuse/100 ) ) / PROD
• PM is the effort in person-months, NOP is the
  number of object points and PROD is the
  productivity (Ops/month)

33
L2. Early design level

• Estimates can be made after the requirements have
  been agreed
• Based on standard formula for algorithmic models
• PM A SizeB M PMm
• where
• M PERS RCPX RUSE PDIF PREX FCIL
  SCED
• PMm (ASLOC (AT/100)) / ATPROD reflects the
  amount of automatically generated code
• A 2.5 in initial calibration,
• Size in KSLOC, but derived from estimated
  Function Points, and FP to KSLOC conversion table
  (progr. language-dependent)
• B varies from 1.1 to 1.24 depending on novelty of
  the project, development flexibility, risk
  management approaches and the process maturity
  (overlap with M)

34
Multipliers

• Multipliers (values 1 to 6) reflect the
  capability of the developers, the non-functional
  requirements, the familiarity with the
  development platform, etc.
• PERS - personnel capability
• RCPX - product reliability and complexity
• RUSE - the reuse required
• PDIF - platform difficulty
• PREX - personnel experience
• FCIL - the team support facilities
• SCED - required schedule

35
The exponent term B

• This depends on five scale factors (5 low, 0
  high)
• Their sum/100 is added to 1.01
• Example
• Precedenteness - new project - 4
• Development flexibility - no client involvement -
  Very high - 1
• Architecture/risk resolution - No risk analysis -
  Very Low - 5
• Team cohesion - new team - nominal - 3
• Process maturity - some control - nominal - 3
• Scale factor is therefore 1.17
• Project duration TDEV 3 (PM)(0.330.2(B-1.01
  ))
• PM is the effort computation and B is the
  exponent computed as discussed above (B is 1 for
  the early prototyping model). This computation
  predicts the nominal schedule for the project