Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Art and Science of Estimating Software Development Cost Glenn Briskin Partner, Sierra Systems Group A. Nicklas Malik Technical Architect Certified.

Similar presentations


Presentation on theme: "The Art and Science of Estimating Software Development Cost Glenn Briskin Partner, Sierra Systems Group A. Nicklas Malik Technical Architect Certified."— Presentation transcript:

1 The Art and Science of Estimating Software Development Cost Glenn Briskin Partner, Sierra Systems Group A. Nicklas Malik Technical Architect Certified Function Point Specialist

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

3 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

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

5 What’s an Estimate?  An estimate predicts what something will cost and how long it will take to deliver –Numbers –Confidence Level

6 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

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

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

9 Estimating Process Functionality Tasks/Resources History Assumptions and Constraints Estimating Tools and Processes Estimates of Costs and Time Confidence Level

10 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

11 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

12 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

13 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

14 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

15 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

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

17 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

18 Any measurement should be:  Simple  Consistent  Not technology or platform dependent  Not company dependent  Useful at different points in software lifecycle

19 The generic application Application Store and Update data Push information inSimple lookup Produce report Pull information in

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

21 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%

22 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

23 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

24 Demo: Productivity Calculations  Guidance on what industry or local averages are.  Room for applying variances to averages + justifications  Calculations by Rational Unified Process Workflow

25 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

26 Software Estimation Resources  International Function Point User’s Group ( www.ifpug.org ) –Certification –Counting Practices Manual  “Software Assessments, Benchmarks and Best Practices” by Capers Jones  “Software Cost Estimation with COCOMO2” by Barry Boehm, et. al.

27 Where to Get More Information Glenn Briskin Partner, Sierra Systems Group 360 570 4531 GlennBriskin@SierraSystems.com A. Nicklas Malik Technical Architect Certified Function Point Specialist 360 570 4546 NickMalik@SierraSystems.com


Download ppt "The Art and Science of Estimating Software Development Cost Glenn Briskin Partner, Sierra Systems Group A. Nicklas Malik Technical Architect Certified."

Similar presentations


Ads by Google