Cost Estimation

1
Cost Estimation

• Van Vliet, chapter 7
• Glenn D. Blank

2
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?

3
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.

4
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?

5
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

6
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)

7
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
  b2.4, c1.05
• Embedded Environment is inflexible and
  constrained, i.e., air traffic control or
  embedded weapons systems, b3.6, c1.20
• Semidetached Team members have varying levels of
  experience working on larger projects, b3.0,
  c1.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 (400.8434 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

8
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

9
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.