1
DeSiaMore
Software cost estimation
www.desiamore.com/ifm
2
DeSiaMore
Objectives
 To
introduce the fundamentals of
software costing and pricing
 To describe three metrics for software
productivity assessment
 To explain why different techniques
should be used for software estimation
 To describe the principles of the
COCOMO 2 algorithmic cost estimation
model
www.desiamore.com/ifm
3
DeSiaMore
Topics covered
 Software
productivity
 Estimation techniques
 Algorithmic cost modelling
 Project duration and staffing
www.desiamore.com/ifm
4
DeSiaMore
Fundamental estimation questions
 How
much effort is required to complete
an activity?
 How much calendar time is needed to
complete an activity?
 What is the total cost of an activity?
 Project estimation and scheduling are
interleaved management activities.
www.desiamore.com/ifm
5
DeSiaMore
Software cost components
 Hardware
and software costs.
 Travel and training costs.
 Effort costs (the dominant factor in most
projects)


The salaries of engineers involved in the project;
Social and insurance costs.
 Effort
costs must take overheads into
account



Costs of building, heating, lighting.
Costs of networking and communications.
www.desiamore.com/ifm
Costs of shared facilities (e.g library, staff
restaurant, etc.).
6
DeSiaMore
Costing and pricing
•
•
•
Estimates are made to discover the cost,
to the developer, of producing a software
system.
There is not a simple relationship between
the development cost and the price
charged to the customer.
Broader organisational, economic,
political and business considerations
influence the price charged.
www.desiamore.com/ifm
7
DeSiaMore
Software pricing factors
M a rk et
o pp ortu ni ty
A d e ve lopm en t org an is at ion m ay qu ote a low p rice b eca us e it
w ishes to m ov e into a ne w se gm en t o f th e soft wa re m ark et.
A cce p tin g a low pro fit o n on e pro jec t m ay give th e o pp ortu nity
o f mo re pro fit late r. The ex p erie n ce g ai n ed m ay al low n ew
p ro du ct s t o be de v el o pe d.
C os t es tim ate
u nce rta in ty
If an o rga n isatio n is u nsure of its cos t estim ate, it ma y inc rea se
its pri ce b y som e c o ntin ge n cy o v er a n d a bo ve it s no rm al p ro fit.
C o ntra ct u al te rms
A c us to m er m ay b e w illi n g to al low th e d ev el o pe r to retai n
o w n er sh ip o f the sou rc e co de an d reu se it in o th e r project s. Th e
p rice ch arge d m ay th en be le ss th a n if th e soft wa re so urce co d e
is ha n de d o ve r t o the cu stom er.
R e qu irem en ts
v ol a tility
If th e req u irem en ts are lik el y to ch an ge , an orga nisa tio n m ay
low er it s pric e to w in a c o ntra ct. A fte r the co n trac t is aw a rd ed ,
h ig h p rice s c a n b e c ha rge d fo r c ha n ge s t o th e req uirem en ts.
F in an c ia l he alt h
D ev e lo p ers in fin an c ia l diffic ul ty m a y low er th eir pr ice to ga in
a c on tract . It is be tte r to m a ke a sm alle r th an no rma l p rof it or
b re a k ev en t h an t o g o o ut of b usine ss.
www.desiamore.com/ifm
8
DeSiaMore
Software productivity
•
•
•
A measure of the rate at which individual
engineers involved in software
development
produce software and associated
documentation.
Not quality-oriented although quality
assurance is a factor in productivity
assessment.
Essentially, we want to measure useful
functionality produced per time unit.
www.desiamore.com/ifm
9
DeSiaMore
Productivity measures
 Size
related measures based on some
output from the software process. This
may be lines of delivered source code,
object code instructions, etc.
 Function-related measures based on an
estimate of the functionality of the
delivered software. Function-points are
the best known of this type of measure.
www.desiamore.com/ifm
10
DeSiaMore
Measurement problems
 Estimating
the size of the measure (e.g.
how many function points).
 Estimating the total number of
programmer
months that have elapsed.
 Estimating contractor productivity (e.g.
documentation team) and incorporating
this
estimate in overall estimate.
www.desiamore.com/ifm
11
DeSiaMore
Lines of code
 What's


a line of code?
The measure was first proposed when programs
were typed on cards with one line per card;
How does this correspond to statements as in
Java which can span several lines or where
there can be several statements on one line.
 What
programs should be counted as
part of the system?
 This model assumes that there is a linear
relationship between system size and
www.desiamore.com/ifm
volume of documentation.
12
DeSiaMore
Productivity comparisons
 The
lower level the language, the more
productive the programmer

The same functionality takes more code to
implement in a lower-level language than in a
high-level language.
 The
more verbose the programmer, the
higher
the productivity

Measures of productivity based on lines of code
suggest that programmers who write verbose
www.desiamore.com/ifm
code are more productive than programmers
who write compact code.
13
DeSiaMore
System development times
A na lys is
Ass em bly c o de
H ig h-le v el la n gu ag e
Ass em bly c o de
H ig h-le v el la n gu ag e
3 w e ek s
3 w e ek s
D esig n
C od ing
T es ting
5 w e ek s
5 w e ek s
8 w e ek s
4 w e ek s
10
w ee k s
6 w e ek s
D oc u me nt ation
2 w e ek s
2 w e ek s
S iz e
E ff or t
Pr od uc tivi ty
5 00 0 lin es
1 50 0 lin es
2 8 w ee ks
2 0 w ee ks
7 14 line s/m o nth
3 00 line s/m o nth
www.desiamore.com/ifm
14
DeSiaMore
Function
points of program
 Based on a combination
characteristics




external inputs and outputs;
user interactions;
external interfaces;
files used by the system.
A
weight is associated with each of these and
the function point count is computed by
multiplying each raw count by the weight and
summing all values.
UFC =  (numb er o f elemen ts of given type)  (we ight)
www.desiamore.com/ifm
15
DeSiaMore
Function points
 The
function point count is modified by
complexity of the project
 FPs can be used to estimate LOC
depending on the average number of
LOC per FP for a given language


LOC = AVC * number of function points;
AVC is a language-dependent factor varying
from 200-300 for assemble language to 2-40 for
a 4GL;
 FPs
are very subjective. They depend
on
www.desiamore.com/ifm
the estimator

Automatic function-point counting is impossible.
16
DeSiaMore
Object points
 Object
points (alternatively named
application points) are an alternative
function-related measure to function
points when 4Gls or similar languages are
used for development.
 Object points are NOT the same as object
classes.
 The number of object points in a program
is a weighted estimate of


The number of separate screens that are
displayed;
www.desiamore.com/ifm
The number of reports that are produced by the
system;
17
DeSiaMore
Object point estimation
 Object
points are easier to estimate from
a specification than function points as
they are simply concerned with screens,
reports and programming language
modules.
 They can therefore be estimated at a
fairly early point in the development
process.
 At this stage, it is very difficult to estimate
www.desiamore.com/ifm
the number of lines of code in a system.
18
DeSiaMore
Productivity estimates
 Real-time
embedded systems, 40-160
LOC/P-month.
 Systems programs , 150-400 LOC/P-month.
 Commercial applications, 200-900
LOC/P-month.
 In object points, productivity has been
measured between 4 and 50 object
points/month depending on tool support
and developer capability.
www.desiamore.com/ifm
19
DeSiaMore
Factors affecting
productivity
A pp li c at ion
d om ai n
ex pe rie nc e
K no w led g e o f th e ap plica tio n d om ain is esse nt ial fo r effe c tiv e
soft wa re d ev el o pm en t. En g in ee rs w h o al rea d y un de rs ta nd a
d om ai n are li k el y t o b e the m os t prod uc tiv e.
P ro ce ss qu ali ty
T h e de ve lopm en t p ro ce ss us ed ca n ha v e a s ig nifica n t eff ect on
p ro du ct ivity . Th is is co v ered in C h ap ter 2 8 .
P ro je ct size
T h e la rg er a p ro je ct, th e m ore tim e re q uire d fo r tea m
com m u nica tio ns. Le ss tim e is av a il a bl e for de ve lopm en t so
in dividu al prod uc tiv it y is re du ce d .
Tec h no lo gy
sup por t
G oo d su pp ort tec h no lo gy suc h as C AS E to ols , co nfig uratio n
m an age me nt s ystems , e tc. c an im prov e pr od uc tiv it y .
W orking
en viro nm en t
As I dis cu ssed in C ha p te r 2 5, a q uiet wo rk in g e nv ironm en t w ith
p riva te w ork ar e as c o ntribu te s t o im pro ve d pro du ct ivity .
www.desiamore.com/ifm
20
DeSiaMore
Quality and productivity
 All
metrics based on volume/unit time are
flawed because they do not take quality
into
account.
 Productivity may generally be increased
at the
cost of quality.
 It is not clear how productivity/quality
metrics
www.desiamore.com/ifm
are related.
 If requirements are constantly changing
21
DeSiaMore
Estimation techniques
 There
is no simple way to make an
accurate estimate of the effort required
to develop a software system



Initial estimates are based on inadequate
information in a user requirements definition;
The software may run on unfamiliar computers
or use new technology;
The people in the project may be unknown.
 Project

cost estimates may be self-fulfilling
The estimate defines the budget and the
www.desiamore.com/ifm
product is adjusted to meet the budget.
22
DeSiaMore
Changing technologies
 Changing
technologies may mean that
previous estimating experience does not
carry over to new systems







Distributed object systems rather than
mainframe systems;
Use of web services;
Use of ERP or database-centred systems;
Use of off-the-shelf software;
Development for and with reuse;
Development using scripting languages;
www.desiamore.com/ifm
The use of CASE tools and program generators.
23
DeSiaMore
Estimation techniques
 Algorithmic
cost modelling.
 Expert judgement.
 Estimation by analogy.
 Parkinson's Law.
 Pricing to win.
www.desiamore.com/ifm
24
DeSiaMore
Estimation techniques
A lg orit hm ic
cos t mo de lling
A m od el ba sed o n h istoric a l cos t in fo rm atio n tha t rel a te s som e so ftwa re
m et ri c (usu al ly its size ) to th e pr oj e ct co st is us ed . A n es tim ate is m ad e
o f tha t m etric a n d th e m od el pred ict s th e e ff ort req uire d .
E x pe rt
ju dg em en t
S ev er a l ex pe rts on th e pr op osed softw are d ev el o pm en t tec h niqu es an d
th e a pp li c ati o n dom ai n are co nsu lted . Th e y e ach estim ate th e pro jec t
cos t. The se estim ate s ar e co m p ared an d d iscuss ed . Th e estim at ion
p ro ce ss ite rat es un til a n agr eed estim ate is r eac h ed .
E stim at ion by
an al o gy
T h is tech n iq ue is a pp li c ab le w he n o th er project s in th e sam e ap p licat ion
d om ai n h av e be en co mp le ted . Th e co st o f a ne w pr oject is estim ated by
an al o gy w it h the se co mp le ted projec ts. M y ers (M y er s 19 89 ) gi v es a
v er y clea r d es cr iptio n of th is a pp ro ac h .
P arkinso nÕs
La w
P arkinso nÕs La w sta te s tha t w ork ex p an ds to fill the time av ail a ble. T h e
cos t is de te rm in ed by av ail a ble resou rc es rat h er th an by o bj e ct ive
assessm en t. If the softw are h as to b e de li v ered in 12 mo nt hs an d 5
p eo p le ar e av ai lab le, the ef fo rt req u ired is es tim ated to be 60 p er so nm on ths .
P rici n g to w in
T h e softw are c ost is estim ated to be w h at e ve r the cu stom er h as
av ai lab le to sp en d o n th e pro jec t. T h e estim ated ef fo rt de pe n ds o n th e
cus to m e rÕs bud ge t an d n ot o n the s oftw are fun ct ion al ity .
www.desiamore.com/ifm
25
DeSiaMore
Pricing to win
 The
project costs whatever the customer
has to spend on it.
 Advantages:

You get the contract.
 Disadvantages:

The probability that the customer gets the
system he or she wants is small. Costs do not
accurately reflect the work required.
www.desiamore.com/ifm
26
DeSiaMore
Top-down and bottom-up
estimation
 Any
of these approaches may be used
top-down or bottom-up.
 Top-down

Start at the system level and assess the
overall system functionality and how this is
delivered through sub-systems.
 Bottom-up

Start at the component level and estimate
the effort required for each component.
Add these efforts to reach a final estimate.
www.desiamore.com/ifm
27
DeSiaMore
Top-down estimation
 Usable
without knowledge of the system
architecture and the components that
might be part of the system.
 Takes into account costs such as
integration, configuration management
and documentation.
 Can underestimate the cost of solving
difficult low-level technical problems.
www.desiamore.com/ifm
28
DeSiaMore
Bottom-up estimation
 Usable
when the architecture of the
system is known and components
identified.
 This can be an accurate method if the
system has been designed in detail.
 It may underestimate the costs of system
level activities such as integration and
documentation.
www.desiamore.com/ifm
29
DeSiaMore
Estimation methods
 Each
method has strengths and
weaknesses.
 Estimation should be based on several
methods.
 If these do not return approximately the
same result, then you have insufficient
information available to make an
estimate.
 Some action should be taken to find out
www.desiamore.com/ifm
more in order to make more accurate
estimates.
30
DeSiaMore
Pricing to win
 This
approach may seem unethical and
un-businesslike.
 However, when detailed information is
lacking it may be the only appropriate
strategy.
 The project cost is agreed on the basis of
an outline proposal and the development
is constrained by that cost.
 A detailed specification may be
www.desiamore.com/ifm
negotiated or an evolutionary approach
used for system development.
31
DeSiaMore
Algorithmic cost modelling
 Cost
is estimated as a mathematical
function of
product, project and process attributes
whose
values are estimated by project
managers:

Effort = A  SizeB  M

A is an organisation-dependent constant, B
reflects the disproportionate effort for large
projects and M is a multiplier reflecting product,
process and people attributes.
 The
www.desiamore.com/ifm
most commonly used product
attribute for cost
32
DeSiaMore
Estimation accuracy
 The
size of a software system can only be
known accurately when it is finished.
 Several factors influence the final size



Use of COTS and components;
Programming language;
Distribution of system.
 As
the development process progresses
then the size estimate becomes more
accurate.
www.desiamore.com/ifm
33
DeSiaMore
Estimate uncertainty
4x
2x
x
Feasibility
Re quirem en t s
Design
Co de
Deliv ery
0 .5 x
0 .2 5 x
www.desiamore.com/ifm
34
DeSiaMore
The COCOMO model
 An
empirical model based on project
experience.
 Well-documented, ‘independent’ model
which is not tied to a specific software
vendor.
 Long history from initial version published
in 1981 (COCOMO-81) through various
instantiations to COCOMO 2.
 COCOMO 2 takes into account different
www.desiamore.com/ifm
approaches to software development,
reuse, etc.
35
DeSiaMore
COCOMO 81
Pr o je ct
co m p le x ity
F o rm u la
D escr iption
S imp le
PM = 2.4 (K DS I) 1 .0 5  M
W el l-u nd ers to od
ap p lica tio ns
d eve lop ed by sm al l te ams .
M o de ra te
PM = 3.0 (K DS I) 1 .1 2  M
M or e com plex pr oject s w h er e
te am m em be rs ma y h av e lim it e d
ex pe rie nc e of r el a te d s ystems .
E m be dd ed
PM = 3.6 (K DS I) 1 .2 0  M
C om plex
project s
w h ere
th e
soft wa re is p ar t of a stron gly
co up le d com plex of ha rd w a re ,
soft wa re,
re gu lat ions
an d
o pe rat ion al proc ed u res .
www.desiamore.com/ifm
36
DeSiaMore
81 was developed
with the assumption
COCOMO
2
that a waterfall process would be used and that all
 COCOMO
software would be developed from scratch.
 Since its formulation, there have been many
changes in software engineering practice and
COCOMO 2 is designed to accommodate different
approaches to software development.
www.desiamore.com/ifm
37
DeSiaMore
COCOMO 2 models
 COCOMO
2 incorporates a range of submodels that produce increasingly
detailed software estimates.
 The sub-models in COCOMO 2 are:




Application composition model. Used when
software is composed from existing parts.
Early design model. Used when requirements
are available but design has not yet started.
Reuse model. Used to compute the effort of
integrating reusable components.
Post-architecture model. Used once the system
www.desiamore.com/ifm
architecture has been designed and more
information about the system is available.
38
DeSiaMore
Use of COCOMO 2 models
www.desiamore.com/ifm
39
DeSiaMore
Application composition
model
 Supports
prototyping projects and
projects where there is extensive reuse.
 Based on standard estimates of
developer productivity in application
(object) points/month.
 Takes CASE tool use into account.
 Formula is

PM = ( NAP  (1 - %reuse/100 ) ) / PROD

PM is the effort in person-months, NAP is the
www.desiamore.com/ifm
number of application points and PROD is the
productivity.
40
DeSiaMore
Object point productivity
D ev e lo p erÕs ex p erie n ce
an d c ap a bi lity
V er y l ow
Low
N om in al
H ig h
V er y h ig h
IC A SE m atu rity an d
ca p ab il ity
V er y l ow
Low
N om in al
H ig h
V er y h ig h
7
13
25
50
P R O D (N O P/m on th)
4
www.desiamore.com/ifm
41
DeSiaMore
Early design model
 Estimates
can be made after the
requirements have been agreed.
 Based on a standard formula for
algorithmic models

PM = A  SizeB  M where

M = PERS  RCPX  RUSE  PDIF  PREX  FCIL
 SCED;
A = 2.94 in initial calibration, Size in KLOC, B
varies from 1.1 to 1.24 depending on
novelty of the project, development
www.desiamore.com/ifm
flexibility, risk management approaches
and the process maturity.

42
DeSiaMore
reflect the capability of the
Multipliers
developers, the non-functional requirements, the
 Multipliers
familiarity with the development platform, etc.







RCPX - product reliability and complexity;
RUSE - the reuse required;
PDIF - platform difficulty;
PREX - personnel experience;
PERS - personnel capability;
SCED - required schedule;
FCIL - the team support facilities.
www.desiamore.com/ifm
43
DeSiaMore
The reuse model
 Takes
into account black-box code that is
reused without change and code that
has to be adapted to integrate it with
new code.
 There are two versions:


Black-box reuse where code is not
modified. An effort estimate (PM) is
computed.
White-box reuse where code is modified. A
size estimate equivalent to the number of
lines of new source code is computed.
This
www.desiamore.com/ifm
then adjusts the size estimate for new code.
44
DeSiaMore
Reuse model estimates 1
 For




generated code:
PM = (ASLOC * AT/100)/ATPROD
ASLOC is the number of lines of generated
code
AT is the percentage of code automatically
generated.
ATPROD is the productivity of engineers in
integrating this code.
www.desiamore.com/ifm
45
DeSiaMore
Reuse model estimates 2
 When
code has to be understood and
integrated:



ESLOC = ASLOC * (1-AT/100) * AAM.
ASLOC and AT as before.
AAM is the adaptation adjustment multiplier
computed from the costs of changing the
reused code, the costs of understanding
how to integrate the code and the costs of
reuse decision making.
www.desiamore.com/ifm
46
DeSiaMore
the same formula as the early
design model
Post-architecture
level
but with 17 rather than 7 associated multipliers.
 Uses
 The



code size is estimated as:
Number of lines of new code to be developed;
Estimate of equivalent number of lines of new code
computed using the reuse model;
An estimate of the number of lines of code that have
to be modified according to requirements changes.
www.desiamore.com/ifm
47
DeSiaMore
The exponent term
 This
depends on 5 scale factors (see next
slide). Their sum/100 is added to 1.01
 A company takes on a project in a new
domain. The client has not defined the
process to be used and has not allowed
time for risk analysis. The company has a
CMM level 2 rating.




Precedenteness - new project (4)
Development flexibility - no client involvement Very high (1)
Architecture/risk resolution - No risk analysis
- V.
www.desiamore.com/ifm
Low .(5)
Team cohesion - new team - nominal (3)
48
DeSiaMore
Exponent scale factors
P re ce d en ted n ess
R e flect s the prev io us e xp er ien ce o f the org an is at ion w ith th is t yp e o f
p ro jec t. V ery lo w m ea ns n o prev ious ex pe rie nc e , E x tra h ig h m ea ns
th at th e o rg an is at ion is co mp le tel y f am ilia r w it h t hi s ap p licat ion
d om ai n .
D ev e lo pm en t
fle x ib il ity
R e flect s the de gree of flex ib ility in th e d ev e lo pm en t p ro ce ss. V e ry
low m ea n s a p re sc ribe d p ro ce ss is u se d; Ex tra high m ea ns t h at th e
clie n t o nly se ts g en e ra l g oa ls .
A rc h itec ture/risk
resolutio n
R e flect s the ex ten t of ris k ana lysis ca rr ie d ou t. V e ry lo w m ea n s little
an alys is, Ex tra high m ea ns a c om plete a tho ro ug h ri sk an alysis.
Tea m co h esio n
R e flect s ho w w ell the de v el o pm en t tea m kn ow ea c h o th er an d w ork
to ge the r. V e ry low m ea ns ve ry d iffic ult int e ra ction s, E x tra h ig h
m ea ns a n i n tegr ate d an d ef fec tiv e tea m w ith n o co mm un ic at ion
p ro blems .
P ro ce ss m a turi ty
R e flect s the pro ce ss m aturity o f th e o rg an is at ion . T h e c om pu tatio n
o f this va lu e de pe n ds on th e C M M Ma turity Q ues tio nn ai re bu t a n
estim ate ca n b e ac h ie v ed b y su bt rac tin g the C M M pr oce ss m at u rity
le ve l f rom 5.
www.desiamore.com/ifm
49
DeSiaMore
Multipliers
 Product

attributes
Concerned with required characteristics of the
software product being developed.
 Computer

Constraints imposed on the software by the
hardware platform.
 Personnel

attributes
Multipliers that take the experience and
capabilities of the people working on the
project into account.
 Project

attributes
attributes
www.desiamore.com/ifm
Concerned with the particular characteristics of
50
DeSiaMore
Effects of cost drivers
E x po ne n t v al u e
S ystem siz e (in cl u ding fa ct o rs fo r re us e
an d req uire m e nts vo la til ity )
In itia l CO C OMO estim ate w ith out
cos t dr iv e rs
1 .1 7
1 28 , 0 00 D SI
R e li a bility
C om plex ity
M em ory c ons trai n t
T o ol use
S ch ed u le
A djus te d C OCO M O estima te
V er y h ig h, m u ltip li e r = 1.39
V er y h ig h, m u ltip li e r = 1.3
H ig h, m u ltip li e r = 1.21
L o w, m ul tip lier = 1 .12
A cce ler a te d , mu lt iplie r = 1. 2 9
2 30 6 p er son -m on ths
R e li a bility
C om plex ity
M em ory c ons trai n t
T o ol use
S ch ed u le
A djus te d C OCO M O estima te
V er y l ow , mu lt iplie r = 0. 7 5
V er y l ow , mu lt iplie r = 0. 7 5
N on e, mu lt iplie r = 1
V er y h ig h, m u ltip li e r = 0.72
N orm al, m ultip lier = 1
2 95 p er son- m o nths
7 30 p er son- m o nths
www.desiamore.com/ifm
51
DeSiaMore
Project planning
 Algorithmic
cost models provide a basis
for
project planning as they allow alternative
strategies to be compared.
 Embedded spacecraft system



Must be reliable;
Must minimise weight (number of chips);
Multipliers on reliability and computer
constraints > 1.
 Cost



components
Target hardware;
Development platform;
Development effort.
www.desiamore.com/ifm
52
DeSiaMore
Management options
A. Use e xist ing har d w ar e ,
de v elopment syst em and
developme nt tea m
B. Pr ocessor and
m emor y upg
C. Mem ory
r ade
Har d w ar e cost incr ease
Exper ienc e decr
ease
upg rade onl y
D. Mor e
e xperienced sta f
f
Har d w ar e cost
incr ease
E. Ne w de velopment
F. Sta f f wit h
system
har dw ar e e xperience
Har d w ar e cost incr ease
Exper ienc e decr
ease
www.desiamore.com/ifm
53
DeSiaMore
Management option costs
O ption
R E LY
S T OR
T IME
T O OL S
L T EX
T otal effor t S of tw a re co st
T otal co st
9 49 39 3
H ar dwa re
co st
1 00 00 0
A
1 .3 9
1 .0 6
1 .1 1
0 .8 6
1
63
B
1 .3 9
1
1
1 .1 2
1 .2 2
88
1 31 35 50
1 20 00 0
1 40 20 25
C
1 .3 9
1
1 .1 1
0 .8 6
1
60
8 95 65 3
1 05 00 0
1 00 06 53
D
1 .3 9
1 .0 6
1 .1 1
0 .8 6
0 .8 4
51
7 69 00 8
1 00 00 0
8 97 49 0
E
1 .3 9
1
1
0 .7 2
1 .2 2
56
8 44 42 5
2 20 00 0
1 04 41 59
F
1 .3 9
1
1
1 .1 2
0 .8 4
57
8 51 18 0
1 20 00 0
1 00 27 06
1 04 93 93
www.desiamore.com/ifm
54
DeSiaMore
Option choice
 Option
D (use more experienced staff)
appears to be the best alternative

However, it has a high associated risk as
experienced staff may be difficult to find.
 Option
C (upgrade memory) has a lower
cost saving but very low risk.
 Overall, the model reveals the
importance of staff experience in
software development.
www.desiamore.com/ifm
55
DeSiaMore
Project duration and
staffing
 As
well as effort estimation, managers
must estimate the calendar time required
to complete a project and when staff will
be required.
 Calendar time can be estimated using a
COCOMO 2 formula

TDEV = 3  (PM)(0.33+0.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
www.desiamore.com/ifm
the project.
 The
time required is independent of the
56
DeSiaMore
Staffing requirements
 Staff
required can’t be computed by
diving the development time by the
required schedule.
 The number of people working on a
project varies depending on the phase of
the project.
 The more people who work on the
project, the more total effort is usually
required.
 A very rapid build-up of people often
correlates with schedule slippage.www.desiamore.com/ifm
57
DeSiaMore
Key points
 There
is not a simple relationship between
the price charged for a system and its
development costs.
 Factors affecting productivity include
individual aptitude, domain experience,
the development project, the project size,
tool support and the working
environment.
 Software may be priced to gain a
www.desiamore.com/ifm
contract and the functionality adjusted
to
the price.
58
DeSiaMore
Key techniques
points of cost estimation should be
 Different
used when estimating costs.
 The COCOMO model takes project, product,
personnel and hardware attributes into account
when predicting effort required.
 Algorithmic cost models support quantitative option
analysis as they allow the costs of different options
to be compared.
 The time to complete a project is not proportional
to the number of people working on the project.
www.desiamore.com/ifm
Descargar

Software cost estimation