1 / 27

The Art and Science of Estimating Software Development Cost

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

luke-rivera
Download Presentation

The Art and Science of Estimating Software Development Cost

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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 Estimates of Costs and Time Functionality Estimating Tools and Processes Tasks/Resources Confidence Level History Assumptions and Constraints

  10. How much of this comprises your estimate? Functionality Estimating Tools and Processes Estimates of Costs and Time Tasks/Resources Confidence Level History Assumptions and Constraints All of it!

  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 Estimating Tools and Processes • ‘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

  14. Project charter Iteration Plan High Level Requirements Project Planning Detailed Project Plan Determine size Determine tasks Historical data Experience Calc. Cost Estimate Estimate task durations Assign resources Bottom-up estimate Top-down estimate Calc. Cost Estimate Top down vs. Bottom Up

  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 weknow, the betterwe can do. Scope Time Plan Tasks People Functions Quality Features Goals

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

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

  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 simpleconstructs, easy to understand • Multiply size by productivity • Requires measurement of pastprojects 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

More Related