1. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 1 8/8/2004 Day 2, Part 1 Estimating Software Size Section 1 Estimating Size

2. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 2 8/8/2004 Outline The Role and Risks of Size Estimating Selecting the Right Size Units Estimation Methods and Models Detailed Examples: –Analogy models –Expert judgement models –Prototyping –Bottom-up models Risk Management Issues

3. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 3 8/8/2004 The Overall Planning Cycle Analyze Job Manage Risks Execute Generate Detailed Plans Generate Initial Plans Measure, Manage Productivity and Quality

4. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 4 8/8/2004 Detailed Planning - Processes Estimate Effort and Cost Estimate Schedule Evaluate Source Information Statement of Work Requirements Constraints Standards Processes History etc. WBS Size Effort & Cost ScheduleOK Complete Detailed Planning Revise & Negotiate Not OK Estimate Size

5. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 5 8/8/2004 Fundamentals...

6. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 6 8/8/2004 Why Estimate Size? The cost of software is directly related to its size and complexity –It is hard to estimate the effort needed for a software development task without knowing how big it is –The “cost per unit size” of software is More for larger projects than smaller ones More for complex software than simple ones Size estimate can be tracked during early stages of the project –Size changes are an important early warning of cost or schedule changes!

7. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 7 8/8/2004 Other Factors Directly Related to Size The memory requirements of the software How many diskettes or CDs it will take to store the program How much disk space is required to install the program How much effort is required for configuration management …

8. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 8 8/8/2004 Size Estimate Estimating Picture WBS Source Documents (SOW, Requirements, Contract, Test Criteria, etc,) Estimate Size Past Experience & Data

9. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 9 8/8/2004 Inputs to Size Estimate What you must do (Analyzing the Job) How you will do it (Initial Planning) Past experience and data

10. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 10 8/8/2004 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

11. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 11 8/8/2004 “How You Will Do It” Inputs Software products Programming language(s) to be used Initial concepts of software design Process and methods Reusable software information These are identified during job analysis and initial planning

12. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 12 8/8/2004 “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 - and may even have left! –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

13. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 13 8/8/2004 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.

14. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 14 8/8/2004 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.

15. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 15 8/8/2004 Size Estimate Step 1 - Determine the Gross Size Estimate Size for Each Distinct SW Product  Gross Size Estimate for All Software Products WBS etc.

16. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 16 8/8/2004 Gross Size Estimate for All Software Products Size (Equivalent) Estimate for All Software Products Size Estimate Step 2 - Evaluate the Impact of Reuse Analyze Impact of Reuse

17. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 17 8/8/2004 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

18. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 18 8/8/2004 Accurate estimates are seldom attained early in the lifecycle –Early estimates tend to be underestimates The goal of estimating is –to educate the estimators –to assist with planning and risk management –to achieve a reasonable prediction Warning -- Estimate = Goal

19. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 19 8/8/2004 Units of Size How to Measure Size

20. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 20 8/8/2004 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?

21. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 21 8/8/2004 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 Lines of Code –Which ones count? –Do comments count? Functions performed Objects in the design Required bytes of computer memory Number of requirements

22. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 22 8/8/2004 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.

23. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 23 8/8/2004 Keep the Goal in Mind The goal is to help you estimate effort and memory size You cannot reasonably expect 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

24. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 24 8/8/2004 Estimating Methods and Models Note: Except where noted, these methods can be used for estimating size OR effort.

25. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 25 8/8/2004 Analogy methods 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 Analogy Methods

26. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 26 8/8/2004 Expert judgment methods involve consulting 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 Expert Judgment Methods

27. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 27 8/8/2004 Prototyping builds 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 Prototyping

28. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 28 8/8/2004 Bottom-up methods 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 Bottom-up Methods

29. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 29 8/8/2004 Categories of Estimating Methods Top-Down Models Top-Down Models estimate from the general characteristics of the 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

30. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 30 8/8/2004 Architecture of Spreadsheet Model Based Effort Estimate Other Effort Estimates... Analogy based Size Estimate Software Reuse Analysis Size / Reuse EffortSchedules Final Effort Estimate Productivity Based Effort Estimate Generic Schedule Effort Schedule Other Size Estimates... Final Size Estimate Expert Based Size Estimate

31. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 31 8/8/2004 Examples Widely Used Estimating Methods

32. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 32 8/8/2004 Examples to be Discussed Analogy / Bottom Up - Compare with Past Experience Expert Opinion - Wideband Delphi Prototype - (will discuss in general terms) Function Points and related methods Statistical Method (a way to assess the risk of other methods)

33. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 33 8/8/2004 Size Estimating Method #1: Compare with Past Experience If you have existing software that is similar to the code being developed, you have a good way to estimate the size of the new code This is a bottom-up, analogy method

34. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 34 8/8/2004 Compare With Past Experience Knowledge or experience on a similar system can be a good starting point

35. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 35 8/8/2004 If the New Code Is Not Identical... Indicate your level of confidence in the estimate, or Compute three different numbers –Minimum –Expected –Maximum These techniques help you understand the level of risk in the estimate

36. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 36 8/8/2004 Example

37. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 37 8/8/2004 Sources of Inaccuracies L -- Different programming languages C -- Different levels of complexity F -- Different functionality D -- Different application domain A -- Different algorithms R -- Different level of reality –simulation vs actual application; –simulation vs emulation

38. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 38 8/8/2004 A disciplined method of using the experience of several people to reach an estimate that incorporates all of their knowledge This method can also be used to estimate effort or cost directly 2. Wideband Delphi Method This is an expert judgment method

39. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 39 8/8/2004 Big Picture of Wideband Delphi Steps 1-2 - Meeting 1 –Inform the Experts Step 3-4 –Experts form Independent Opinions Steps 5-11 - Meeting 2 –Experts Meet and Compare Estimates –Experts Seek Consensus Step 12 –Consolidate the Data

40. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 40 8/8/2004 Wideband Delphi Method - Meeting 1 1) Get a few experts (typically three to five) –Include experience in all of the “risk” areas e.g. application domain, programming language, algorithms, target hardware, operating system, etc.

41. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 41 8/8/2004 Wideband Delphi Method - Meeting 1 (continued) 2) Discuss issues and describe the software to the experts –Specifications, source documents, WBS, etc. –Let them add their own info, questions, etc. –All take notes

42. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 42 8/8/2004 Wideband Delphi Method - Between Meetings 3) Each expert develops an estimate –Independent and anonymous 4) Record estimates anonymously –Usually done by a facilitator x xx x x

43. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 43 8/8/2004 Wideband Delphi Method - Meeting 2 5) Meet and have each expert discuss his/her estimate –Assumptions –Rationale x xx x x

44. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 44 8/8/2004 Wideband Delphi Method - Meeting 2 (continued) 6) Seek consensus on assumptions, etc. –May result in action items to gather factual data 7) Each expert updates his or her estimate based on the new information 8) Record the new estimates x x x x x

45. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 45 8/8/2004 Wideband Delphi Method - Meeting 2 (continued) 9) Discuss again –Typically, new questions will come up –But this round is typically much shorter 10) Repeat from step 7 until you reach a consensus x x x x x

46. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 46 8/8/2004 Wideband Delphi Method - Meeting 2 (continued) 11) If no consensus, break until you can gather additional data, then repeat from step 7

47. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 47 8/8/2004 Wideband Delphi Method (Concluded) Stop repeating when either: a) The experts agree on an estimate, OR b) There is no significant change in the estimate over two consecutive cycles and no significant additional data are available At the end, you have a consensus estimate on the expected value. You should also agree on the degree of confidence (i.e., the risk) in the estimate.

48. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 48 8/8/2004 Wideband Delphi Method Consolidation Step 12) Gather all of the detailed estimates and resolve remaining issues –Major discrepancies between experts’ views on individual components –Unknowns that can be resolved by gathering data –Assumptions that can be verified

49. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 49 8/8/2004 Advantages of Wideband Delphi Method Takes advantage of the expertise of several people All participants become better educated about the software Buy-in to final estimate Does not require historical data (although it can be useful input if it is available)

50. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 50 8/8/2004 Drawbacks of Wideband Delphi Method You can reach consensus on an incorrect estimate –Because you all “buy in”, you may not be skeptical enough when actual data shows the estimate is wrong You can develop a false sense of confidence You may fail to reach a consensus

51. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 51 8/8/2004 3. Prototyping Build a prototype of the software, including certain important functions –especially those whose size is unknown Use the prototype to answer questions raised by other estimating methods Then revisit previous estimates with the new information

52. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 52 8/8/2004 4. Function Points and Related Methods

53. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 53 8/8/2004 Function Point Methods (background) Function points measure the size of the customer’s requirements, or the size of the functionality to be produced, rather than the physical size of the software –This is analogous to measuring the size of a house by counting the number and types of rooms, rather than by square footage

54. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 54 8/8/2004 Function Point Methods Function Points as a size unit Function Point Analysis as an estimating method

55. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 55 8/8/2004 Function Points are a Unit of Size “Function points” may be directly correlated to effort, memory requirements, or even to lines of code –All of the estimating methods discussed previously can be used with function points as the size unit –For example, you can compare new software with previous software, or use wideband delphi techniques

56. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 56 8/8/2004 Function Point Analysis (FPA) is a Method of Estimating The function point method was developed by Allan Albrecht and refined by others (see references) to deal with situations where much was known about the functionality of the software but little about the structure or the size in “lines of code”.

57. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 57 8/8/2004 Function Point Methods The original definition by Albrecht was based on transaction oriented systems –This concept of a “function” may not work as well with other types of software Variations exist for real time, object oriented, and other kinds of applications

58. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 58 8/8/2004 (*) These are goals of all size estimating methods. Goals of Function Point Analysis To predict size accurately, as early as possible (*) To provide a mechanism to track and monitor “scope creep” (*) –The difference in the number of function points after requirements analysis, design & delivery is an indication to how much the scope of a project has grown

59. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 59 8/8/2004 Albrecht’s Model of a Computer Software Application Internal Logical Files (ILFs) End User / Other Programs EO EI EQ External Queries External Outputs External Inputs Data Base (External Interface Files)

60. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 60 8/8/2004 Categories of Functions - I 1. External Inputs (EI) –An elementary process where data flows in across the system boundary 2. External Outputs (EO) –An elementary process where “derived-data” flows out across the system boundary 3. External Queries (EQ) –An elementary process which outputs data from ILFs based on the data input

61. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 61 8/8/2004 Categories of Functions - II 4. Internal Logical Files (ILF) –A logically related group of data that resides entirely within the applications boundary and is maintained through EIs 5. External Interface Files (EIF) –A logically related group of data that is used for reference purposes only –The data resides entirely outside the application Note: the idea of splitting files into internal & external is credited to Capers Jones in the early 1980’s.

62. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 62 8/8/2004 Function Point Method in a Nutshell 1) Count the functions in each category 2) Establish the complexity of each: –High, Medium, or Low 3) Establish weights for each complexity 4) Multiply each function by its weight and then sum up to get total function points 5) Adjust for application characteristics

63. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 63 8/8/2004 Function Point Example Category Simple Average Complex EO 3 4 5 Weights 4 5 7 Points 12 2035 Total Points for External Outputs: 67

64. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 64 8/8/2004 Function Point Formula “Unadjusted” Function Points (UFP) = EO points + EI points + EQ points + ILF points + EIF points

65. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 65 8/8/2004 Adjustment Factor “Adjusted” FP = UFP * VAF VAF is an “application characteristics value adjustment factor” that ranges from 0.65 to 1.35 VAF is determined by application characteristics that cannot be counted but that affect the application as a whole –Ease of use, reliability, flexibility, etc.

66. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 66 8/8/2004 Note on Adjustment Factor Some studies have shown that the adjustment factor degrades the function point metric, resulting in lower accuracy Thus some authors prefer to leave out the adjustment factor and, instead, to assess application characteristics in the process of estimating effort

67. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 67 8/8/2004 The Devil is in the Details How do you establish the weights? How do you identify the functions? How do you determine the adjustment factor? What do you do if your application seems to have different kinds of functions other than Albrecht’s? The literature on function points is largely devoted to issues like these

68. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 68 8/8/2004 Step by Step Details Longstreet, Garmus, and the International Function Point Users Group (IFPUG) have good descriptions of how to count function points For more information, see the reference list at the end of the notes

69. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 69 8/8/2004 Calibration is Helpful - But Hard! Albrecht warns against attempting to calibrate for a given industry, application domain, or company He and others believe the specific software development organization must calibrate the FPA method to their own characteristics. But few organizations have enough data to do an effective calibration

70. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 70 8/8/2004 What About Other Applications? Example: real time systems –Tend to have few internal files –But have very complex algorithms Extensions to function points are often incorporated to handle non-transaction oriented systems, such as real time systems, object oriented designs etc Among the extensions are feature points and object points

71. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 71 8/8/2004 Feature Points An extension of the function point method designed to deal with real time systems. A new category of function that represents complex algorithms The complexity of the algorithm is defined in terms of the number of “rules” required to express that algorithm

72. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 72 8/8/2004 Object Points This approach is at a more macro level than function points Developed to address object oriented designs Assign one object point to each unique class or object, such as a screen, output report, etc. The rest of the process is similar, but the weights are different See Cocomo II web site (effort estimation section)

73. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 73 8/8/2004 Advantages of Function Points and Related Methods Estimates can be made relatively early in the project –before we know the architecture of the software Easier for customers to relate the impact of change in functional requirements etc.

74. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 74 8/8/2004 Advantages of Function Points and Related Methods Independent of programming language, technology, and techniques More reliable relationship to effort – IF you can determine the right functions to measure and the correct weights and adjustments

75. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 75 8/8/2004 Disadvantages of Function Points and Related Methods It is hard to count and track function points –Much judgment involved –Difficult to automate Details, such as weights and definitions of complexity level, vary significantly from one application to the next and from one organization to the next

76. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 76 8/8/2004 Disadvantages of Function Points and Related Methods Internal complexity of the application is not considered –For example, housekeeping, memory management, and other support functions Calibration takes time, effort, and data –Although using results from similar applications may be a good starting point

77. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 77 8/8/2004 Many People Really Like Function Points … but... Many effort estimation tools use lines of code, so figures in function points have to be converted –FPA may be a useful way to estimate lines of code, regardless of whether function points are a good size unit More data are available on lines of code than on function points –Although this is changing for some application areas

78. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 78 8/8/2004 5. Statistical Method (“PERT”) Statistical variance & fundamental inaccuracy are inherent risks in all estimation methods The statistical method is used in conjunction with the results from other methods to take into consideration the risk in the estimates To use this method you must estimate a minimum and maximum value along with each estimated value

79. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 79 8/8/2004 Statistical Method Goals Designed to predict the size, given the minimum, likely, and maximum values of size For each component, the expected size is: Expected = Min + 4*Likely + Max 6

80. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 80 8/8/2004 Notes on the Statistical Method Validity is questionable from a statistical viewpoint –Because the conditions necessary for statistical validity are probably not present –For example, the individual components of the estimate would need to be independent –And the values of “min” and “max” would have to meet certain conditions that are hard to show But it does give you some sense of the risk

81. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 81 8/8/2004 What Method to Use If there is No Data? What if there is no data on the code to be written? –No prior experience –No expertise available There are two issues: –What to do about an initial estimate –How to manage the inherent risk in the estimate

82. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 82 8/8/2004 Initial Estimate with No Data Prototype method is helpful if you have the time to do it Wide-band delphi method will help you consolidate all of the expertise you have available Consider hiring an consultant who is familiar with writing software for the application in question Consider function points and related methods

83. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 83 8/8/2004 Architecture of Spreadsheet Cocomo Based Estimate Other Effort Estimates... Analogy based Size Estimate Software Reuse Analysis Final Effort Estimate Productivity Based Effort Estimate Other Size Estimates... Final Size Estimate Expert Based Size Estimate Size / Reuse EffortSchedules Generic Schedule Effort Schedule

84. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 84 8/8/2004 Compare Results and Judge

85. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 85 8/8/2004 Final Notes on Size Estimating

86. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 86 8/8/2004 Final Notes 1) Use more than one method and resolve discrepancies –No method is reliable enough in most cases –When two methods disagree, it tells you you are missing some facts Method 1 Wideband Delphi Resolution? Method 3 Method 2 Statistical Analysis OK (Revise Estimates) Not OK

87. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 87 8/8/2004 Final Notes (continued) 2) Include data declarations in size estimates 3) Include all functions - many are easy to overlook or underestimate –Control –Power up –Power failure –Diagnostics –Operating Systems

88. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 88 8/8/2004 Final Notes (continued) 4) Account properly for reuse –Do it - reuse can save lots of money –Don’t consider it to be free

89. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 89 8/8/2004 Managing the Risks of Size Estimating

90. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 90 8/8/2004 Risks Associated with Estimating Incomplete or incorrect estimates due to lack of sufficient detail or lack of sufficient information –Guesstimates instead of legwork to get accurate data Incomplete flow of system level constraints –Example: failure to accommodate special system limitations, financial constraints, etc.

91. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 91 8/8/2004 Sometimes you have to be proactive. Meet with your peers from other functional disciplines, especially the ones you know the least about. Risks Associated with Estimating (continued) Insufficient visibility into other parts of the system –Hardware –Test sets –Maintenance and support plans –Etc.

92. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 92 8/8/2004 Ways to get Wrong Data Lack of data Missing facts Distorted facts Opinions without substantiation Biases Lack of visibility Etc. Truth Bias Opinion Guess

93. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 93 8/8/2004 Risk Mitigation Review assumptions with all affected parties Work the details. Don’t guess if you don’t have to guess. Communicate with those working on other parts of the system

94. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 94 8/8/2004 Managing the Risks Plan to update your plans –Especially your estimates Re-estimating Plan actions Estimating actions feedback feedback for next re-plan Updated Plan Re-estimating

95. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 95 8/8/2004 Managing the Risk (continued) Plan to update estimates at several key points in the project –At milestones when important information becomes available For example, after preliminary design is complete and you have a better idea about the size of the software –At points where major changes occur or major decisions are made For example, if a significant feature is added or deleted

96. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 96 8/8/2004 Managing the Risk (continued) Depending in your confidence in the estimate, you may wish to hold some “reserve” resources If a re-estimate shows that you need significantly more resources, you can negotiate options with your customer –Delay some features until a later release –Add resources and/or schedule –Cut back on the scope of the software

97. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 97 8/8/2004 Summary Size Estimation Use multiple methods –To have more reliable estimates –To reduce risk History and experience are valuable allies Being consistent about units of size is far more more important than exact choice of units

98. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 98 8/8/2004 Summary Size Estimation Function points and related methods estimate size based on functions performed But it takes calibration and experience to use them effectively Reuse can reduce effort and should be accounted for But reuse is not “free”

99. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 99 8/8/2004 References - Size Estimation Albrecht, Allan J., "Measuring Application Development Productivity," reprinted in Tutorial, Programming Issues for the Eighties (Capers Jones, editor), IEEE Computer Society Press, 1986, pp 35-44. Boehm, Barry, Software Engineering Economics, Prentice-Hall, Englewood Cliffs, N.J., 1981, ISBN 0-13-822122-7. Boehm, Barry, Estimating with Cocomo II, 2000 (updates and extends the above)

100. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 100 8/8/2004 References - Size Estimation Boehm, Barry, “Software Engineering Economics,” IEEE Transactions on Software Engineering, Vol. 14, no. 10 (October, 1988), pp. 1462-1475. Garmus, David and David Herron, Measuring the Software Process - A Practical Guide to Functional Measurements, Prentice-hall, 1996.

101. Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Day 2, Part 1, Page 101 8/8/2004 International Function Point Users Group, Function Point Counting Practices Manual Longstreet, David “Function Points: Step by Step”. Available on line at www.SoftwareMetrics.com/fpsteps.htm Symons, Charles, Software Sizing and Estimation, Mk II Function Point Analysis, West Sussex, England, John Wiley and Sons, 1991. References - Size Estimation