1 / 23 CS 709B Advanced Software Project Management and Development Software Estimation - II Based on Chapter 4 of the book [McConnell 2006] Steve McConnell, Software Estimation: Demystifying the Black Art, Microsoft Press, 2006 May 1, 2012

2 / 23 Outline n n Where Does Estimation Error Come From? u u Sources of Estimation Uncertainty u u The Cone of Uncertainty u u Chaotic Development Process u u Unstable Requirements u u Omitted Activities u u Unfounded Optimism u u Subjectivity and Bias u u Unwarranted Precision

3 / 23 Introduction n n Estimation in general presents challenges u u U of Washington CSE Department’s building: months late and $20.5 million over budget u u Seattle Mariners’ new baseball stadium was estimated in 1995 to cost $250 million. It was finally completed in 1999 and cost $517 million n n Examples in software u u Irish Personnel, Payroll and Related Systems (PPARS) canceled after its overran its 8.8 million Euro budget by 140 million Euro! u u FBI’s Virtual Case File shelved in 2005 after costing $170 million and delivering 1/10 of capabilities.

4 / 23 Sources of Estimation Uncertainty n n Four generic sources u u Inaccurate information about the project u u Inaccurate information about organization’s capabilities u u Too much chaos in the project (moving target) u u Inaccuracies arising from the estimation error itself n n Software development is a process of gradual refinement. The many ways a software could ultimately take shape will produce widely different combinations of cost, schedule, and feature set.

5 / 23 The Cone of Uncertainty Software development means making literally thousands of decisions. Uncertainty in software estimates results from uncertainty on how these decisions will be made.

6 / 23 The Cone of Uncertainty n Estimation accuracy increases as the project progresses, usually from +/-4x to +/-1.25x in about 30% of time

7 / 23 The Cone of Uncertainty n Can you beat the cone? It’s very hard, as it represents best- case accuracy. It’s only possible to be luckier. The main issue is project variability, and the cone narrows only if you remove sources of variability.

8 / 23 The Cone of Uncertainty n You must force the Cone to narrow by removing sources of variability from your project

9 / 23 The Cone of Uncertainty n One way of dealing with too narrow estimate ranges is to use predefined multipliers applied to “most likely” estimates; another is to use a “know-how-much” and “know-how- uncertain” strategy

10 / 23 The Cone of Uncertainty n n The Cone and the Commitment u u Effective organizations delay their commitments until they have done the work to force the Cone to narrow n n The Cone and the Iterative Development u u It’s impractical and almost impossible not to have iterations u u There is a mini Cone in each iteration u u Short iterations will narrow this mini Cone early u u Another approach is to have (more) iterations after narrowing the Cone. u u Also, it’s possible to plan for some unexpected requirements (“positive variability”)

11 / 23 Project Chaos n n Common examples of sources of chaos include: u u Requirements inadequately investigated u u Lack of end-user involvement in requirements u u Poor designs u u Poor coding practices u u Incomplete or unskilled project planning u u Inexperienced personnel u u Prima donna team members u u Abandoning planning under pressure u u Lack of automated source code control n n These induce variability and need be fixed with improved process control

12 / 23 Unstable Requirements n n Specific challenges raised by unstable requirements: u u They don’t allow the Cone to narrow u u Requirements changes are often not tracked, and the cost and schedule are not re-estimated n n Stabilizing requirements is more effective than improving estimation techniques n n Also, consider applying development techniques for high-volatile environments (XP, Scrum, DSDM, etc.)

13 / 23 Unstable Requirements n It’s useful to incorporate allowances for requirements growth. NASA SEL plans for 40% requirements increase. COCOMO incorporates a similar concept (“requirements breakage”).

14 / 23 Omitted Activities n Errors also arise from estimation practices n A common source of errors is forgetting to include necessary tasks n Omitted work includes: u Missing requirements u Missing software development activities u Missing non-software development activities

15 / 23 Omitted Activities u Missing requirements u Missing software development activities u Missing non-software development activities

16 / 23 Omitted Activities n Missing requirements examples are shown below n You must include estimates for stated requirements, implied requirements, and non-functional requirements

17 / 23 Omitted Activities

18 / 23 Omitted Activities n Examples of non-software development activities that tend to be omitted

19 / 23 Unfounded Optimism [the collusion of optimists] n Developers underestimate their work by 20% to 30% [Cusumano and Shelby 1995, 300 software projects] n Optimism applies to management as well, with a “fantasy factor” of about 1.33 [Boehm 1981, DoD, 100 schedule estimates] n Variations: u We’ll be more productive in this project than in the last one u A lot of things went wrong with the last project. This will not happen with the current project. u We are past the hard climbing of a steep learning curve

20 / 23 Subjectivity and Bias n Bias – tendency to “fudge an estimation” n Subjectivity – human judgment influenced by experience n Too many “control knobs” are likely to introduce subjectivity.

21 / 23 Subjectivity and Bias n Smaller number of adjustment factors (“knobs”) >>> smaller variation in estimates

22 / 23 “Off-the-Cuff” Estimates n It’s highly recommended to avoid “off-the-cuff” estimates

23 / 23 Unwarranted Precision n Accuracy refers to how close to the real value a number is. Precision refers merely to how exact a number is (how many significant digits).