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 persons 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 its 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 its 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 = bKLOC
c

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)
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.
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
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 90s and 2000s
Three different models applied at different life cycle stages:
Application Composition 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)
Early Design model
For the architectural design phase
Incorporates some aspects of Function Point analysis
Post-Architecture model
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.