CS 709 B Advanced Software Project Management and
CS 709 B Advanced Software Project Management and Development Software Estimation - II Based on Chapter 4 of the book [Mc. Connell 2006] Steve Mc. Connell, Software Estimation: Demystifying the Black Art, Microsoft Press, 2006 May 1, 2012 1 / 23
Outline n Where Does Estimation Error Come From? u Sources of Estimation Uncertainty u The Cone of Uncertainty u Chaotic Development Process u Unstable Requirements u Omitted Activities u Unfounded Optimism u Subjectivity and Bias u Unwarranted Precision 2 / 23
Introduction n Estimation in general presents challenges U of Washington CSE Department’s building: months late and $20. 5 million over budget u Seattle Mariners’ new baseball stadium was estimated in 1995 to cost $250 million. It was finally completed in 1999 and cost $517 million u n Examples in software Irish Personnel, Payroll and Related Systems (PPARS) canceled after its overran its 8. 8 million Euro budget by 140 million Euro! u FBI’s Virtual Case File shelved in 2005 after costing $170 million and delivering 1/10 of capabilities. u 3 / 23
Sources of Estimation Uncertainty n Four generic sources Inaccurate information about the project u Inaccurate information about organization’s capabilities u Too much chaos in the project (moving target) u Inaccuracies arising from the estimation error itself u n 4 / 23 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.
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. 5 / 23
The Cone of Uncertainty n 6 / 23 Estimation accuracy increases as the project progresses, usually from +/-4 x to +/-1. 25 x in about 30% of time
The Cone of Uncertainty n 7 / 23 Can you beat the cone? It’s very hard, as it represents bestcase 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.
The Cone of Uncertainty n 8 / 23 You must force the Cone to narrow by removing sources of variability from your project
The Cone of Uncertainty n 9 / 23 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-howuncertain” strategy
The Cone of Uncertainty n The Cone and the Commitment u n The Cone and the Iterative Development u u u 10 / 23 Effective organizations delay their commitments until they have done the work to force the Cone to narrow It’s impractical and almost impossible not to have iterations There is a mini Cone in each iteration Short iterations will narrow this mini Cone early Another approach is to have (more) iterations after narrowing the Cone. Also, it’s possible to plan for some unexpected requirements (“positive variability”)
Project Chaos n Common examples of sources of chaos include: u u u u u n 11 / 23 Requirements inadequately investigated Lack of end-user involvement in requirements Poor designs Poor coding practices Incomplete or unskilled project planning Inexperienced personnel Prima donna team members Abandoning planning under pressure Lack of automated source code control These induce variability and need be fixed with improved process control
Unstable Requirements n Specific challenges raised by unstable requirements: u u n n 12 / 23 They don’t allow the Cone to narrow Requirements changes are often not tracked, and the cost and schedule are not re-estimated Stabilizing requirements is more effective than improving estimation techniques Also, consider applying development techniques for high-volatile environments (XP, Scrum, DSDM, etc. )
Unstable Requirements n 13 / 23 It’s useful to incorporate allowances for requirements growth. NASA SEL plans for 40% requirements increase. COCOMO incorporates a similar concept (“requirements breakage”).
Omitted Activities n n n Errors also arise from estimation practices A common source of errors is forgetting to include necessary tasks Omitted work includes: u u u 14 / 23 Missing requirements Missing software development activities Missing non-software development activities
Omitted Activities u u u 15 / 23 Missing requirements Missing software development activities Missing non-software development activities
Omitted Activities n n 16 / 23 Missing requirements examples are shown below You must include estimates for stated requirements, implied requirements, and non-functional requirements
Omitted Activities 17 / 23
Omitted Activities n 18 / 23 Examples of non-software development activities that tend to be omitted
Unfounded Optimism [the collusion of optimists] n n n Developers underestimate their work by 20% to 30% [Cusumano and Shelby 1995, 300 software projects] Optimism applies to management as well, with a “fantasy factor” of about 1. 33 [Boehm 1981, Do. D, 100 schedule estimates] Variations: u u u 19 / 23 We’ll be more productive in this project than in the last one A lot of things went wrong with the last project. This will not happen with the current project. We are past the hard climbing of a steep learning curve
Subjectivity and Bias n n n 20 / 23 Bias – tendency to “fudge an estimation” Subjectivity – human judgment influenced by experience Too many “control knobs” are likely to introduce subjectivity.
Subjectivity and Bias n 21 / 23 Smaller number of adjustment factors (“knobs”) >>> smaller variation in estimates
“Off-the-Cuff” Estimates n 22 / 23 It’s highly recommended to avoid “off-the-cuff” estimates
Unwarranted Precision n 23 / 23 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).
- Slides: 23