Transcript Cost Estimation Van Vliet, chapter 7 Glenn D. Blank Cost estimates: when and why  When does a contractor estimate costs for building a house?     Before.

Cost Estimation
Van Vliet, chapter 7
Glenn D. Blank
Cost estimates: when and why

When does a contractor estimate costs for building
a house?




Before construction begins, let alone payment
Takes into account subcontracts for foundation, framing,
plumbing, electrical, etc.
 Hierarchy, modularity and abstraction support estimates
Who benefits from these cost estimates?
Can cost estimates have similar advantages
for software projects?


On the other hand, can cost estimates for software projects
be as accurate as for house contracts?
Why or why not?
Person-months

Most software cost estimates assume cost = effort



Effort = man-month, i.e., a person’s work for a month
Usually ignores cost of hardware or cost of maintenance
Fred Brooks, The Mythical Man-Month, 1975:



“Cost does indeed vary as the product of the number of men
and the number of months. Progress does not. Hence the
man-month as a unit for measuring the size of a job is a
dangerous and deceptive myth. It implies men and months are
interchangeable.”
“Men and months are interchangeable commodities only when
a task can be partitioned among many workers with no
communication among them. This is true of reaping wheat or
picking cotton; it is not even approximately true of systems
programming.”
“Adding manpower to a late project makes it later.”
LOC/KLOC

LOC: lines of code



KLOC: kilo lines of code, or (lines of code) / 1000
Still regarded as most accurate way to measure labor costs
What are some uncertainties about measuring LOC?




Should comment lines count? Or blank lines for formatting?
How do we compare lines of assembly language vs. high-level
language like C++ or Java?
How do you know how many LOC the system will contain
when it’s not implemented or even designed yet?
How do you account for reuse of code?
Bottom up estimates

Estimate the cost for each module or unit of code




Sum the cost of the modules
Add an estimate of integration costs
Assumes that design is far enough along that all modules
are defined
Another bottom-up estimate:



Break the work into subtasks small enough to estimate
Person responsible for performing the subtask estimates
the effort required
Software architectural design work must be done before
such an estimate is possible
Formal or algorithmic
cost models


Goal: compute the cost of a software project, with
formulas and constant factors called “cost drivers”
Formal cost models are thought to be the best way
we have to predict the software development costs



But for many projects it’s not possible to gather the input
data needed
At best, formal cost models yield estimates that are at most
25% off, 75% of the time, for the projects used to derive the
model
May imply more uncertainty for new projects (the ones we
want to estimate)
COCOMO
(1981)



COCOMO – COnstructive COst Model
 Basic formula is: Effort = bKLOCc
 where b, c are constants whose values depend on the project
characteristics
Basic COCOMO distinguishes three classes of projects:
 Organic: small teams develops software in known environment, so
developers can contribute early: b=2.4, c=1.05
 Embedded: Environment is inflexible and constrained, i.e., air traffic
control or embedded weapons systems, b=3.6, c=1.20
 Semidetached: Team members have varying levels of experience
working on larger projects, b=3.0, c=1.12
Intermediate COCOMO – factors in 15 additional cost drivers, i.e.,
complexity of software, documentation needs, etc.


E.g., if complexity is low, adjust this factor by 0.85 (40*0.84=34 months)
What do you think of measuring cost factors this way?
Detailed COCOMO – phase sensitive, uses separate multipliers for
each project phase, from requirements through integration
Function Point analysis
(1979, 1983)

Rather than counting LOC, count data structures (“function points”)




Key inputs are number of:



Input types, output types, inquiry types, logical internal files, interfaces
May also apply corrections for differences in complexity of data types
After computing the function points, map them to LOC


Intended to be a user-oriented measure of system function
Particularly suitable for business applications
Less well suited for systems such as compilers, real-time systems, etc.
Formula depends on the particular programming language to be used
Based on older, batch-oriented systems
 Object Point analysis may be more suitable for interactive,
screen-oriented systems

Note: objects are screens, reports and 3GL modules, not OOP classes
COCOMO 2
(1995, 1997)


Tuned to applications and life-cycle practices of 90’s and 2000’s
Three different models applied at different life cycle stages:
 Application Composition model




Early Design model



For the architectural design phase
Incorporates some aspects of Function Point analysis
Post-Architecture model




Intended for prototypes, using components or CASE tools
Similar goal as for Function Point analysis
Based on counting Object Points (instead of function points)
For the development stage
Most detailed
Similar to the original COCOMO model
Adds many new cost drivers:

Personnel capabilities, use of software tools, multi-site development, etc.