Estimating Software Costs

1
Estimating Software Costs

• Chris Tsouris, CIMA
• Fall 2007

2
Software Estimating Topics

• Introduction
• Estimating Attributes and Methods
• Manual Estimating vs. Automated Tools
• Project Sizing and Function Points
• The 10 Deadly Sins of Estimating

3
How do you build your estimates?

• What are the inputs to your estimates?
• Is your estimation process documented?
• Do you collect and use historical data?
• Do you track your estimates?
• Are the quality of your estimates based on the
  competency of a few key people in your
  organization?

4
Why is it important

• Software The driving force
• A state government may produce and modify
  hundreds of applications a year
• Cost estimation is a mainstream activity for
  every organization that builds software

5
Litigation

• Cost estimation is key in lawsuits involving
• Breach of contract
• Taxable value
• Recovery of excess costs
• Favoritism in contract awards
• Wrongful termination of personnel

6
Past and Present Then

• Small Projects (30 Function Points)
• One Programmer
• One Month
• 5,000
• Consequences were not serious

7
Past and Present Now

• Large Projects (25 million source code
  statements)
• Large Technical Staff
• Up to five years
• Up to 500,000,000
• Consequences are very serious

8
Accurate Estimates

• The best solution is to support the estimate with
  historical data from similar projects.
• Collection of historical data is a precursor to
  accurate estimation.

9
Software Estimating Principals

• (Project Size) X (Project Attributes)
  Estimates
• - Schedule
• - Effort
• - Costs

10
Project Attributes

• Rate of requirements change
• Experience of development team
• Methodology
• Number of iterations
• Programming Language and tools
• Reusable artifacts
• Work space
• Geographic separation of the team
• Schedule pressure

11
Key sets of Attributes

• Four key sets of attributes must be considered
  whether estimating manually or using a tool
• Technology
• Process
• Environment
• Personnel

12
Standard Estimating Steps

• Requirements Analysis
• Project Sizing
• Identify Activities
• Estimate Defect Potential
• Estimate Staffing Requirements
• Adjust Assumptions based upon Experience
• Estimate Effort and Schedules
• Estimate Development Costs
• Estimate Maintenance and Enhancement Costs
• Present and Defend the Estimate

13
Accidental Omissions (in order)

• Finding and Fixing Bugs
• Production of Paper Documents
• Scope Creep
• Travel Costs (applies to distributed
  applications)
• Support and Administrative Activities
• Technical Specialist Costs
• Effort Contributed by System Users
• Maintenance and Enhancements

14
The Estimation Lifecycle

• Rough requirements guesstimate
• Formal estimate based upon requirements
• Midlife estimated reflecting requirements change
• Final cost estimate using historical data
• And then..
• Litigation support for breach of contract
• Litigation support for taxable value

15
Manual vs. Automated Estimating

• Large Corporations (500 or more software
  personnel)
• 80 use automated estimation tools
• 30 use two or more estimation tools
• 15 employ cost estimation specialists
• Manual estimation used for small quick and
  dirty
• Small Companies (lt100 software personnel)
• 25 use automated estimation tools

16
Methods of Estimating Software

• Manual or Automated the methods are the same
• Project-level estimates using rules of thumb
• Phase-level estimates using ratios and
  percentages
• Activity-level estimates using work or task
  breakdown

17
Project Level Estimates

• Project estimates using rules of thumb are the
  oldest form of software estimation. Examples
• Raising the FP total by .4 will predict schedule
  in calendar months
• Java applications average 500 non-comment lines
  of code per staff month
• Project-level estimates are easy to do
• Project-level estimates should never serve as a
  formal budget or contract basis.

18
Phase-level Estimates

• Phase-level estimates using ratios and
  percentages are also a traditional form.
  Examples
• Requirements 10, analysis and design 20,
  coding 30, testing 35, installation and
  training 5, etc.
• Real-life percentages vary widely
• Aspects of the work span multiple phases
• Activities that are not phases can be omitted
• Slightly more useful than Project-level, far from
  sufficient

19
Activity-level Estimates

• Pro
• Far and away the most accurate
• Originated in the 60s for manual estimation
• The best automated tools operate at the
  activity-level
• Con
• Very time consuming initially
• More difficult to make changes for requirements
  or scope adjustment

20
Manual Estimating

• Manual estimating methods can work on small
  projects.
• If manual methods sufficed, there would be no
  commercial software estimating tools.
• Most major overruns and software disasters are
  built upon careless and grossly optimistic cost
  estimates that are done manually.

21
Automated Estimating

• Complexity There are hundreds of factors that
  can determine the outcome of a software project.
• It is not possible to deal with the combinations
  using algorithms and manual methods.

22
Why do we need estimating tools?

• Knowledge base of many projects
• Can perform size predictions
• Can adjust estimates based upon tools and
  languages
• Predict quality and reliability
• Predict maintenance and support costs after
  development

23
Manual vs. Automated Estimates

• Comparison of 50 estimates in the 5,000 FP range
• (about 625,000 C statements)

24
Causes of Estimation Errors

• Projects grow at 2 per month
• Excessive bugs/defects throw off testing
  schedules
• Producing paper documents costs more than code
• Accurate estimates are arbitrarily replaced by
  optimistic estimates

25
Optimistic Estimates

• Estimates must be approved and there is a strong
  tendency to reject accurate estimates.
• Why?
• Building complex software remains time consuming
  and expensive.

26
Project Sizing and Function Points

• Barry Boehm helped develop the Constructive Cost
  Models (COCOMO) for estimating software
  development costs.
• Parameters include
• Function points Technology-independent
  assessments of the functions involved in
  developing a system.
• object points
• use case points
• Source Lines of Code (SLOC) A human-written line
  of code that is not a blank line or comment.

27
What are Function Points
28
View of Application
29
Function Point Conversion

• Factors for Converting Raw Values to Function
  Points

Table 3. Factors for Converting Raw Values to
Function Points
30
Source Lines of Code (SLOC)
Lines of Code Per Function Point by Programming
Language
31
Preliminary Estimation
32
The Basic Concept

• If you know how many thousands of lines of code
  (KSLOC) your developers must write
• And
• You know the effort required to write a line of
  code
• Then
• You can multiply these numbers and arrive at the
  person months required

33
Effort Per Line of Code
34
Example Project

• E-Commerce Project
• 15,000 lines of code
• How many person months of effort would this take
  using just this equation?
• The answer is computed as follows
• ProductivityKSLOC3.6015Effort54PersonMonths

35
Counting Function Points
Spreadsheet Demo
36
Available Parametric Tools
37
On the Web

• Constructive Cost Model (COCOMO)
• COCOMO II Web Based Model
• http//sunset.usc.edu/research/COCOMOII/expert_coc
  omo/expert_cocomo2000.html

38
The 10 Deadly Sins of Estimating

• Sin 1
• Confusing Targets
• With Estimates

39
Confusing Estimates with Targets

• Targets are not created through any kind of
  analysis based on the work to be performed
• In practice, little real estimation is done
• Determine whether youre really supposed to be
  estimating or figuring out how to meet a target

40
The 10 Deadly Sins of Estimating

• Sin 2Saying Yes WhenYou Really Mean No

41
Why Developers Say Yes

• It is very difficult to make a vigorous,
  plausible, and job-risking defense of an estimate
  that is derived by no quantitative method,
  supported by little data, and certified chiefly
  by the hunches of the managers.
• Fred Brooks (1975)

42
Schedule Negotiations

• Software developers tend to be introverts and
  relatively young
• Management personnel tend to be more extroverted
  and organizationally senior to the developers
  they negotiate with

43
The 10 Deadly Sins of Estimating

• Sin 3
• Committing to
• Estimates Too Early

44
The Cone of Uncertainty
Most Projects Estimated Here
Good Estimates not Possible until Here
of Error
Project TimeLine
45
Plan to Revise Estimates Over Time
Preliminary Estimate
Refined Estimates
of Error
Project Timeline
46
The 10 Deadly Sins of Estimating

• Sin 4
• Assuming
• Underestimation has a
• Neutral Impact on
• Project Results

47
Effect of Estimation Accuracy
48
The 10 Deadly Sins of Estimating

• Sin 5
• Estimating in the
• Impossible Zone

49
Puzzle

• Suppose you drive 30 mph up a hill 1 mile long.
• How fast do you need to drive down the hill to
  average 60 mph for the entire trip?

50
A Variation on Sin 5

• An estimate is the most optimistic prediction
• that has a non-zero probability of coming true

51
Effort/Schedule Tradeoff

• All researchers have found some tradeoff between
  schedule compression and effort
• No one thinks theres no tradeoff
• Assume a maximum possible schedule compression of
  about 25

52
Dont Create Estimates In the Impossible Zone

• Whats the solution to the puzzle?

53
The 10 Deadly Sins of Estimating

• Sin 6
• Overestimating
• Savings from New
• Tools or Methods

54
Savings from New Tools or Methods

• Problems
• Must pay learning curve price during first use
• New tools and methods increase risk
• Maximum effectiveness doesnt appear during first
  use
• Payoff is less than expected when it does appear
• Best assumption is productivity loss from first
  use of new tool or method

55
The 10 Deadly Sins of Estimating

• Sin 7
• Using Only One
• Estimation Technique

56
Use Multiple Techniques

• Lack of this contributes to Brooks vigorous
  defense problem
• Most leading organizations use multiple
  techniques
• Create estimates different ways and look for
  convergence or spread among the estimates
• Personal experience

57
The 10 Deadly Sins of Estimating

• Sin 8
• Not Using Estimation
• Software

58
Use Estimation Software

• Best support for science of estimation is tools
• Estimates created with tools can have more
  credibility than estimates created by manual
  methods

59
The 10 Deadly Sins of Estimating

• Sin 9
• Not Including Risk
• Impacts in Estimates

60
How Much Risk Gets Included in the Project Plan?
61
Addressing Risk In Estimates

• Software projects are inherently risky
• The total Risk Exposure (RE) is the expected
  value of the project overrun
• The RE is where buffer planning starts

62
The 10 Deadly Sins of Estimating

• Sin 10
• Providing Off-The-Cuff
• Estimates

63
Treat Estimation as a Mini-Project

• Estimates created with guessing and intuition
  correlate with cost and schedule overruns (at the
  0.05 level of significance)

64
Define a Standardized Estimation Procedure

• Elements of a standardized procedure
• A clear description of an estimates imprecision
• Use of multiple estimation approaches
• A plan to re-estimate at pre-defined points in
  the project

65
Use Historical Data

• Most common estimation technique is comparing to
  past projects using personal memory
• Use of similar past projects based on documented
  facts is negatively correlated with overruns (at
  the 0.05 level of significance)

66
Decompose Big Estimates Into Smaller Estimates

• Decompose systems into modules
• Decompose big tasks into small tasks
• Makes use of a statistical property called the
  law of large numbershighs and lows tend to
  cancel each other out

67
Adjust Your Estimation Approach as the Project
Progresses

• Early in the project, algorithmic, macro
  approaches work best
• Late in the project, bottom-up, task-based
  estimates work best
• Different guidelines apply to different kinds of
  estimates

68
Advice

• Be accurate.
• Be conservative.
• Base the estimate on solid historical data.
• Include quality.
• Include paper documents.
• Include project management.
• Include scope creep.
• Do not exaggerate effect of productivity tools.
• Estimate at the activity level.
• Be prepared to defend the assumptions of your
  estimate

69
Contact Information

• Your Strategy for Success
• Chris Tsouris, President
• chris_at_scicomputing.com
• 303-796-0748 Ext. 21