Estimating software development
Download as PPTX, PDF1 like275 views
The document discusses improving software project estimates by putting more effort into understanding project scope, gaining experience in the relevant domain and technology, and accounting for unanticipated work. It notes that estimates are often too optimistic due to the "planning fallacy". Better approaches include basing estimates on past actuals, recording time ongoing, and communicating lessons learned beyond just hour estimates. The goal is to provide more accurate and useful information to decision-makers while acknowledging estimates will always have some uncertainty for large projects.
Estimating software development
- 2. 2Viasat Proprietary Every developer and every line manager everywhere
- 3. 3Viasat Proprietary ›More accurate ›More confident ›Less effort to deliver Defining better
- 4. 4Viasat Proprietary › Estimates happen early in the project life cycle – Little is known about the project – including scope, requirements, technical details and resources. – With software development every project is different. Often there is little experience in the domain, technology and resource management. – Anticipated work and risk gets estimated. Unanticipated work is typically left out from the estimating effort. Facts about estimates
- 5. 5Viasat Proprietary Put more effort into learning the scope, requirements, technical details and resources. What we do Little is known about the project – including scope, requirements, technical details and resources Increase time and effort for creating estimates.
- 6. 6Viasat Proprietary Gain experience in the domain, technology and resource management. Seek help from experts. What we do Every project is different. Often there is little experience in the domain, technology and resource management Time and effort that may go more directly toward getting the project done. Pushes out estimate delivery timeline, but also improves accuracy.
- 7. 7Viasat Proprietary Put more effort into discovering the work needed for the project. What we do Anticipated work and risk gets estimated. Unanticipated work is typically left out from the estimating effort. Takes time and effort, produces valuable knowledge. Results are hard to convert to a date or time line.
- 8. 8Viasat Proprietary Software projects report 1994 - 2004 • 16% … 29% Successful • 53% … 53% Challenged • 31% …18% Aborted
- 9. 9Viasat Proprietary Software projects report 1994 - 2004 • 16% … 29% Successful • 53% … 53% Challenged • 31% …18% Aborted ›Success is defined as “delivered as estimated” ›Anything less than successful can be due to poor execution – or bad estimate
- 10. 10Viasat Proprietary › Sydney Opera house was estimated to take 6 years and $7mln to build. It was completed after 16 years and $102mln. › Denver International Airport was estimated to take – 4 years and $2.6bln. – It started operating after 5.5years, having spent $4.8bln, with reduced scope. Baggage handling was never implemented as originally designed. › Home Redecorating/Remodeling for kitchens and bathrooms – Redecorating projects were over budget 35% of the time – Remodeling projects were over budget 53% of the time What others do
- 11. 11Viasat Proprietary › Past effort is consistently underestimated › Future effort is estimated optimistically – Consistently – Despite having good information about past performance of same tasks – Estimating larger efforts with deadline farther out in the future exacerbates the effect of too-optimistic predictions › Work by others is estimated more realistically – Applies to both past effort and future work Studies looked at filing taxes, completing a college thesis, writing a book. Behavioral science: planning fallacy
- 12. 12Viasat Proprietary Random events are skewed to introduce additional cost and delay Not evenly balanced between positive and negative results Larger efforts take longer to react to unexpected events Increasing the cost of delay as unexpected events arise Consequences of disruption are non-linear, i.e. small delays compound into larger schedule slips over life of larger projects Error effect in estimates: more on planning fallacy
- 13. 13Viasat Proprietary › Estimate other people’s work and let others estimate yours – to avoid optimistic bias › Consider past estimates, use logged time for work already done, and calculate actual effort involved – Keep records of on-going work. Consult those records when working on future estimates – Calculate appropriate multipliers and apply to future estimates › Learn to live with low-confidence estimates on larger efforts – Improve ROI by limiting time & effort spent on early estimates › Focus estimation effort on smaller and more familiar projects for higher-confidence estimates What can we learn from science and history?
- 14. 14Viasat Proprietary The Mythical Man-Month: Essays on Software Engineering by Frederick Phillips Brooks Originally published in 1975 Later editions come with additional essays
- 16. 16Viasat Proprietary Programmers are optimists › In the upper left of Fig. 1.1 is a program. › It is complete in itself, ready to be run by the author on the system on which it was developed. That is the thing commonly produced in garages, and that is the object the individual programmer uses in estimating productivity. › In the bottom left is a programming product. › This is a program that can be run, tested, repaired, and extended by anybody. It is usable in many operating environments, for many sets of data. It must be written in a generalized fashion. Must be thoroughly tested, so that it can be depended upon. Finally, it requires its thorough documentation, so that anyone may use it, fix it, and extend it. A
- 17. 17Viasat Proprietary Programmers are optimists (contd.) › Top right: programming system component › every input and output conforms in syntax and semantics with precisely defined interfaces. The program must also be designed so that it uses only a prescribed budget of resources. Finally, the program must be tested with other system components, in all expected combinations. This testing must be extensive, for the number of cases grows combinatorially. Subtle bugs arise from unexpected interactions of debugged components. › Bottom right: programming system product › Many components working together. Cost may rise further with more components, tighter dependencies, and moving dependencies.
- 18. 18Viasat Proprietary ›Estimates inform business decisions – Is this project feasible? – How long until we realize any benefit, a sizeable benefit, all the expected benefit from success? – What will we have to give up in order to make this project happen? – What is worth giving up for this project? – What do we lose in case of failure? What do we lose in case of time overruns? Better estimates: purpose
- 19. 19Viasat Proprietary › There is typically a need for projected delivery dates in order to coordinate with other teams working in the same problem space › There is also a need to allocate resources over time based on expected progress of the project › In addition, estimate is often used as a measuring stick for project success (i.e. CHAOS reporting metrics) › The goal of estimates that get created should be to satisfy a tangible business need. Can we live with no estimates?
- 20. 20Viasat Proprietary › Estimate often › Record actual spent – Calendar time – Effort › Work from past history when creating future estimates – Check your optimism › Communicate learning – Share more than the # of hours estimated Better approach to estimating
- 22. 22Viasat Proprietary › Estimating is discovering and sharing useful information about a body of work – Usually focused on work not done – Occasionally about work that has been done, but no records are available › Estimates are assumed to be a fictional number of man-hours Estimating != estimates