The Art and Science of Estimating Software Development Cost Glenn Briskin Partner, Sierra Systems Group A. Nicklas Malik Technical Architect Certified Function Point Specialist
Agenda Sierra Systems Intro Estimating Software Development Project Management Point of View –Key concepts for creating and managing estimates Technical Architect Point of View –Estimating Size (using Function Points) –Estimating Cost (using Historical Data)
Sierra Systems Intro A full service systems integration company Emphasis on business solutions Over 900 consultants, 300 in PNW –Vancouver and Victoria –Bellevue and Olympia Olympia office since 2000 serving over 25 state agencies EGovernment, Health, Justice, Enterprise Solutions Strong methodology and technology expertise
Managing Estimates What’s an estimate? What goes into an estimate? What happens once you make an estimate? How can you make it work for you, not against you?
What’s an Estimate? An estimate predicts what something will cost and how long it will take to deliver –Numbers –Confidence Level
What goes into an Estimate? Your understanding about what you want Your experience in doing that before The more you know about each, the easier it will be to estimate
Understanding and Experience Understanding –What problem will be solved? (Objectives) –What capabilities will solve it? (Functionality) –How will you do it? (Tasks) –What assumptions and constraints do you have?
Understanding and Experience Experience –What has it taken for you or others to do this? –What historical information do you have? –What expert experience can you draw on? –What is your confidence level in the applicability of your information? –What do you know about your possible resources?
Estimating Process Functionality Tasks/Resources History Assumptions and Constraints Estimating Tools and Processes Estimates of Costs and Time Confidence Level
How much of this comprises your estimate? Functionality Tasks/Resources History Assumptions and Constraints Estimating Tools and Processes Estimates of Costs and Time All of it! Confidence Level
What Happens when you make an Estimate? Set expectations –Cost, Time, Scope –People see what they are looking for Create a baseline –Cost, Time, Scope –Assumptions, Constraints, Confidence
Making the Estimate Work for You When any part of the estimate changes… –Functionality –Tasks –Assumptions/Constraints –Cost and Time Estimates –Confidence Level Then the entire estimate has changed Adjust expectations and show variance to the baseline Negotiate changes to expectations
Estimating Models – A case for Function Points ‘And then magic happens…’ Your inputs vary in quality and completeness Characteristics of a useful estimating model –Consistently applied to the information available –Usable early with accuracy –Easily updateable – responsive to changes –Applicable to historical projects –Adjustable with experience Estimating Tools and Processes
Top down vs. Bottom Up Project charter Iteration Plan High Level Requirements Project Planning Detailed Project Plan Determine size Calc. Cost Estimate Historical data Determine tasks Estimate task durations Experience Assign resources Calc. Cost Estimate Top-down estimate Bottom-up estimate
Top-down Cost Estimation First estimate the size. –Count function points. –Estimate total lines of code (KLOC) Apply Measured Productivity –Hours / Function Point or Hours / KLOC –Calibrate using local history or industry averages Cost = size * productivity
Ease into measurement On a couple of projects, count the function points at the beginning, and at every major release. At each point, take the effort expended and calculate productivity (hours per function point delivered). Store for future use in estimating.
Other benefits of measurement Measurement can lead to improving: –Cost performance –Methodology –Client Satisfaction –Credibility The more we know, the better we can do. Function s Goal s Quality Tasks People Features Plan TimeScope
Any measurement should be: Simple Consistent Not technology or platform dependent Not company dependent Useful at different points in software lifecycle
The generic application Application Store and Update data Push information inSimple lookup Produce report Pull information in
Relative Difficulty Each function gets a number of “points” reflecting how “hard” the function is to write. Each of these five functions can be complex, average, or simple. To be consistent, there is a whole set of rules to decide what function to use, and what level of complexity to measure it as.
Complexity Depending on requirements, some systems are harder to write… that needs to be taken into account. Complexity factors are multiplied against the total of the function points… causes the final number to range from 65% to 135%
Demo: Counting Tool Excel spreadsheet Pages for types of “files” (ILF, EIF) One page for all transaction types (EI, EO, EQ) Summary and Productivity pages Record of counter notes, constraints, use case notes, data dictionary, any other pertinent information
Estimating Cost Start with a size measurement Multiply by productivity –Dependent on platform, language, environment (IT shop vs. Outsource), project requirements (documentation, reviews, testing), etc. Heavily dependent on historical performance
Demo: Productivity Calculations Guidance on what industry or local averages are. Room for applying variances to averages + justifications Calculations by Rational Unified Process Workflow
Summary Measure size using simple constructs, easy to understand Multiply size by productivity Requires measurement of past projects to calibrate productivity As requirements improve, estimates improve
Software Estimation Resources International Function Point User’s Group ( ) –Certification –Counting Practices Manual “Software Assessments, Benchmarks and Best Practices” by Capers Jones “Software Cost Estimation with COCOMO2” by Barry Boehm, et. al.
Where to Get More Information Glenn Briskin Partner, Sierra Systems Group A. Nicklas Malik Technical Architect Certified Function Point Specialist