While there are many models for measuring maturity of software organizations, little attention has been paid to factoring estimation maturity into these models. This true even for CMMI, which is an otherwise very a rigorous model. This presentation suggests adopting an Estimation Maturity model suggested by Galorath and using the Function Point estimation technique to achieve this goal.

1. Improving Estimation Organizational
Maturity
Achieving project success and productivity improvements with mature
estimation practices
1

2. Contents
 Estimation Organizational Maturity Model (EOMM)
 What is the EOMM?
 The 5 stages of Estimation Maturity
 Key differences between Level 1 and Level 2
 Achieving Level 2 maturity using Function Points
 Introducing Function Points
 Function Points across the project lifecycle
 Associated Metrics
 Resources

3. What is the EOMM?
 Proposed by Dan Galorath, chief architect and developer
of SEER, software cost estimation tool
 Defines 5 levels of estimation maturity
 Most organizations are at Level 1
 Provides a roadmap to
 Improve estimation accuracy
 Improve project predictability
 Measure and improve productivity

4. Level 0 Informal
Manual
Estimation
with no
process
Level 1
Direct Task
Estimation (Work
Breakdown
Structure)
Spreadsheets
Ad Hoc
Process
Level 2
Formal Sizing
(e.g. Function
Points)
Direct Task
Estimation
Simple Model
(Size*Productivit
y)
Some
Measurement and
Analysis)
Informal
Process
Level 3 Formal Sizing
Robust
parametric
Estimation
Estimation vs
Actual
capture
Formalized
multiple
estimate
process
Rigorous
measuremen
t and Analysis
Risk
Management
Repeatable
Process
Level 4 Formal Sizing
Repeatable
Process
Robust
Parametric
Estimating
Rigorous
Measuremen
t and Analysis
Parametric
Estimation
with Tracking
and control
Risk
Management
Process
Improvement
via lessons
learned
Level 5 Formal Sizing
Repeatable
Process
Robust
Parametric
Estimating
Rigorous
Measuremen
t and Analysis
Parametric
Estimation
with Tracking
and control
Risk
Management
Continuous
Process
Improvement
The 5 Stages of Estimation Maturity
Source: Galorath.com

5. Key Differences between Levels 1, 2 and 3
 Level 1 is based on Work Breakdown Method
 Level 2 is based on formal software sizing
 Size can be expressed in units like Lines of Code (LOC), feature points,
use case count or Function Points
 Introduces basis for organizational productivity measurement for
application development
 Level 3 lays the basis for continuous process improvement
 Uses parametric estimation (like COCOMO)
 Process improvement leads to productivity gains
 According to Gartner, just moving up from Level 1 to 2 reduces
estimated vs actual variance by 50%

6. Difference Between Formal Sizing and WBS
 Formal Sizing: Key Features
 Effort = Size / Productivity
 Size is measured from a user’s perspective
 Productivity depends on technology/skill level/ organization environment and
other factors
 A large number of secondary metrics can be predicted
 Large industry database available to benchmark
 WBS: Key Features
 Directly provides estimates in person hours (or days/months)
 Based on developer’s perspective, varies by person
 Productivity is hidden and cannot be verified, measured or improved
 Does not factor in organizational productivity

7. Parametric Estimation
 Level 3 introduces parametric based estimation
 Factors in a number of attributes that determine productivity
 COCOMO is an example of a parametric based estimation
technique
 Since productivity is broken down into smaller attributes, it is
easier to improve productivity by managing those attributes

8. How to measure software size
 Number of sizing options available
 Function Points
 Others like SLOC, feature points, use case count
 Function Points
 Industry Standard, developed by IBM in 1979
 Rich industry database base
 Can be used to compare projects and applications
 Rich knowledge base of secondary metrics available

9. Moving to Level 2…introducing Function
Points
 Using Function Point (FP) sizing at project start and during
execution can assist planning accuracy, manage and
improve project delivery
 This applies only to projects where FP sizing can be used
(Application Development and Enhancements, no
infrastructure projects)

10. Using Function Points across the project
lifecycle
Phase Key Derived Metrics Common across phases
Scoping High Level Effort, Cost and
Duration, Risk Assessment
• Productivity
• Drive Standardization
Requirements Baseline Effort, Cost and Duration
Design and Development Scope Creep
Testing Defect Count and Rework Effort
Maintenance Defect Prediction, Cost of
Maintenance
• Cost
• Duration
• Scope Creep
• Risk Assessment
• Defect Prediction
• Rework Effort
Size Application
(FP)
Historical Data

11. Scoping
 Take Decisions Early
 WBS based estimates take long to compute as they need inputs from many teams
 FP Sizing is a lot quicker and helps negotiate scope w.r.t duration, scope and cost
 Estimating with limited information
 Quick FP and assumptions can help in determining initial FP count
 Historical data for duration and cost can be leveraged
 Determine size by functional modules and provide an overall cost map (size is a
good measure of cost)
 Other benefits
 Assess Replacement Impact
 Compare FP size of existing and replacement systems
 CompareVendor Solutions

12. Requirements
 Determine baseline Effort, Duration, Cost
 Phase wise planning using historical data
 Evaluate Requirements Completion (e.g. use industry or own
historical data)
 Determine Risk (e.g. Projects less than 500 function points have a
risk of failure of less than 20% while those over 5000 function points which
have a probability of cancellation close to 40%.)
 Quantify scope for phased development using
quantified ‘what if’ scenarios

13. Development and Testing
 Determine FP count at phase end to
 Measure scope creep
 Compare with baseline FP count at end of requirements
phase
 Predict Defect Count at each phase
 Defect prediction can be used to assess project risk
to meet expectations

14. Associated Metrics: Effort and Duration
 Barry Boehm’s formula to compute duration as a
function of effort
Calendar Months (A) = 2.5 x Person Months 1/3
 Customize this equation based on historical data:
– Calendar Months = A + coefficient

15. Defect and Productivity Related Techniques
 There are techniques that can be used (and improvised) for defect prediction when sufficient
historical data is not available
 Count of UAT test cases = 1.2 x FP
 Total count of test cases = FP1.2
 Productivity
 COCOMO can be used to fine tune productivity numbers
 Source

16. Resources
 Galorath Inc
 SPR Estimation Resources
 Uses and Benefits of Function Points
 COCOMO
 Defect Prediction and Prevention

17. Thank you
Bhupinder Singh
http://ca.linkedin.com/in/bhupindersingh