1. Copyright 1995-2009, Dennis J. Frailey CSE7315 – Software Project Management CSE7315 M11 - Version 9.01 SMU CSE 7315 Planning and Managing a Software Project Module 11 Overview of Size Estimating

2. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 2 Objectives of This Module  To examine why size estimating is useful  To discuss how to measure size  To review several categories of estimating methods

3. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 3 When do you Do Estimating  Before writing proposals –To get rough estimates in support of marketing efforts  When writing proposals –To develop a bid  When starting a project –Once you know the final terms of the contract and the budgets  During a project –When things have changed enough to justify updating the estimate Rough Estimates Good Estimates Better Estimates Even Better Estimates

4. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 4 Detailed Planning - Processes Estimate Schedule Evaluate Source Information Statement of Work Requirements Constraints Standards Processes History etc. WBSSize Effort & Cost ScheduleOK Complete Detailed Planning Revise & Negotiate Not OK Estimate Size Estimate Effort and Cost

5. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 5 Why Do You Need to Estimate the Size?  To help you estimate the effort, schedule and cost  And to help you estimate the memory requirements, if you need to know them  In theory, you could estimate effort and cost without knowing size –Since you know the tasks to be performed from the WBS, you can (in theory) compute effort and cost directly

6. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 6 How To Estimate Cost and Effort Without Estimating Size For each task, you determine effort and then cost, as follows: Task -------------> Effort ---------------> Cost This is known as a “bottom up” estimating technique

7. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 7 TaskEffortx factorCost 1.1.123 staff months$5000/sm$115,000 1.1.25 staff months$4000/sm$ 20,000............ 2.3.4(3 trips)$1000/trip$ 3,000............ _______________________ Total$435,000 “Bottom Up” Cost Estimating The highlighted tasks are to develop the software. Other tasks are for related activities required by SOW, etc.

8. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 8 But Sometimes This is Not So Easy  In practice, the software development tasks may be hard to estimate in this fashion  It is very hard to estimate the effort to perform a software development task unless you know something about the size and the complexity of the software

9. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 9 Moreover...  Large software projects cost more than small ones; complex software costs more than simple software  So you often need to estimate the size and complexity as part of the process of determining the effort required to develop the software

10. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 10 In Fact...  It may be easier and faster to estimate the effort to do a whole software project than to estimate the exact effort of performing each task  Example: -- How long will it take you to answer the questions on the test? vs. -- How long will it take you to answer each individual question?

11. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 11 “Short Cut” to Estimate Software Development Effort For Software Development Tasks: use software items rather than tasks: Software ----> Size -------> Effort ------> Cost Item & Complexity For Other Tasks: Task ---------------> Effort ----------------> Cost

12. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 12 Estimating Software Development Effort SW ItemSizeComplexity File System2400 unitssimple User I/F3000 unitsmoderate......... _____ __________ _______ Total35,000 unitsmoderate Historical Data Effort Estimate

13. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 13 Inputs to Size Estimate  What you must do (job analysis)  How you will do it (Initial Planning)  Past experience and data

14. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 14 Good job analysis and initial planning will have identified all of these things and summarized them in the work breakdown structure (WBS) “What You Must Do” Inputs  Statement of work  System design information  Requirements of the software  Tasks to be Performed

15. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 15 “How You Will Do It” Inputs  How you will break it into software items  Programming language(s) to be used  Initial concepts of software design  Process and methods to be used for development  Reusable software information These are also identified during job analysis and initial planning

16. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 16 “Past Experience” Inputs  Prior experience on similar tasks is valuable in helping you estimate –People who have worked on something similar can be a good source - but they may be biased - or may be unavailable –Historical data can provide useful facts to counteract natural human biases  An organizational data base of past project experience is one of the best investments an organization can make

17. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 17 Past History May Be Particularly Hard to Find Cindy Wilson did that the last time & she left the company last year. We never have time around here to write down what we learned.

18. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 18 You May Have to Scramble to Get What Information You Can Hello, Cindy? Can you tell me about how big the user interface module was in project Zing? Hey, George! Who around here knows the most about the HP X123 test station? Anne, can you participate in an estimating session next week? Let’s look at the source code of the old data base module.

19. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 19 Size Estimating Concept Size Estimate WBS Source Documents (SOW, Requirements, Contract, Test Criteria, etc,) Estimate Size Past Experience & Data

20. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 20 Size Estimate Step 1 - Determine the Gross Size Estimate Size for Each Distinct SW Item  Gross Size Estimate for All Software Items WBS etc.

21. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 21 Gross Size Estimate for All Software Items Equivalent Size Estimate for All Software Items Size Estimate Step 2 - Evaluate the Impact of Reuse Analyze Impact of Reuse

22. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 22 Risks of Size Estimating 1) Statistical variance & fundamental inaccuracy of estimating methods –Multiple methods are recommended to increase confidence 2) Biases due to lack of knowledge, optimism, etc. –The earlier in the lifecycle, the less accurate the estimates –Therefore, plan to update estimates when you have more facts

23. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 23  Accurate estimates are seldom attained, especially early in the lifecycle –Early estimates tend to be underestimates  The goal of estimating is –to help plan the project –to educate estimators –to manage risk Warning -- Estimate = Goal You don’t need a perfect prediction to manage a project effectively

24. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 24 Units of Size

25. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 25 How Would You Measure the Size of a House?  Square Feet  Number of bedrooms, bathrooms, garages, etc  Number of floors  Size of lot required to build it ... What are the advantages and drawbacks of each measure?

26. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 26 Important Questions  What unit will you use to measure size? –It should be related to effort  How will you define it? –Everyone should be measuring the same thing  How will you measure it? –Can you measure it accurately? –Can you measure it easily? These questions are important whether you are measuring the size of houses or software

27. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 27 The decision about which unit is best should be based on the suitability of a unit to your application domain Some Possible Units of Size for Software  Lines of Code –Which ones count? –Do comments count?  Functions performed  Objects in the design  Required bytes of computer memory  Number of requirements  Web pages

28. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 28 How to Decide Between Options?  Are data available to help you estimate? –previous, similar projects are best  Is your unit of measure suited to the application & your organization’s processes?  How easy is it to measure? Consistency between projects is more important than the measure itself.

29. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 29 Keep the Goal in Mind  The primary goal of a software size measure is to help you estimate effort  A secondary goal is to help you estimate how much memory you need to hold the software  The goal is not to have the most precise and perfect unit for measuring size –Don’t get hung up in debates about what unit to measure –If it works, use it

30. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 30 How to Define a Unit - Example - What Is a Line of Code?  Source line images? –80 characters/carriage return character  Source statements? –Semicolons (in some languages)  Do comments count? (usually not)  Data Declarations? (usually yes)

31. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 31 Notes Most methods of size estimating will work with just about any size unit you choose We will often illustrate the process with “lines of code”, and will later discuss other units

32. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 32 Estimating Methods and Models Note: Except where noted, these methods can be used for estimating size OR effort.

33. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 33 1. Analogy Models –Compare with past experience History is a good ally –But truly similar models seldom exist –Use as a baseline for “sanity” checks or when no other method is available Categories of Estimating Methods Stukes, Sherry, “A Guide to Cost Estimation for Space Systems Software,” Management Consulting and Research, 1995/1999

34. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 34 2. Expert Judgment Models –Consult with experts Examples:  Hire a consultant  Wideband Delphi –Good for new, unique & different situations –High risk of biased/insufficient knowledge –Use in conjunction with other models Categories of Estimating Methods (continued)

35. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 35 3. Prototyping –Build a model of the parts that are riskiest or least well understood Prototypes take time –But they can answer questions raised by other estimating methods Categories of Estimating Methods (continued)

36. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 36 4. Bottom-up Models –Estimate each component –And add them all up Expensive and time consuming, but –Good for tracking costs later –“Buy-in” from developers –Use if data and time are available –Won’t work if you lack key information –Ignores integration/support Categories of Estimating Methods (continued)

37. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 37 Categories of Estimating Methods (continued) 5. Top-Down Models –Estimate based on general characteristics of application, environment, personnel, etc. –Normally these are used for effort, not size Examples: Cocomo, Price-S, SEER, etc. –Fast, easy to use, requires little detail, captures system costs –Less accurate and stable than bottom-up –Does not foster buy-in to estimate –Use - but calibrate to your own data

38. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 38 Architecture of Spreadsheet for assignments 3 and 4 Model Based Effort Estimate Other Effort Estimates... Analogy based Size Estimate Software Reuse Analysis Size / Reuse EffortEffort & Cost Schedules Final Effort Estimate Productivity Based Effort Estimate Generic Schedule Effort Schedule Labor Schedule Cost Schedule Other Size Estimates... Final Size Estimate Expert Based Size Estimate

39. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 39 Architecture of Spreadsheet for assignments 3 and 4 Model Based Effort Estimate Other Effort Estimates... Analogy based Size Estimate Software Reuse Analysis Size / Reuse EffortEffort & Cost Schedules Final Effort Estimate Productivity Based Effort Estimate Generic Schedule Effort Schedule Labor Schedule Cost Schedule Other Size Estimates... Final Size Estimate Expert Based Size Estimate This diagram serves as a guide to the next several modules

40. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 40 Module Summary  Size estimates help you estimate effort and memory size  They can also be helpful for tracking (this will be shown in later modules)  Most estimating methods benefit from past experience or history data  Units of size should be chosen based on availability of data in those units

41. Copyright 1995-2009, Dennis J. Frailey CSE7315- Software Project Management CSE7315 M11 - Version 9.01 41 END OF MODULE 11