Software Effort Estimation. Planning to Meet Schedule. Lewis Sykalski 5/01/2010. How Managers View Software Effort Estimation. Nebulous Vague No correlation to reality Why bother. Effects of Bad/No Estimation. Underestimation can lead to Schedule/Cost Over-runs:
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Software Effort Estimation
Planning to Meet Schedule
Most managers today are unaware of established software effort estimation methodologies or don’t account for unforeseen consequences when using a method.
This paper attempts to reconcile this by surveying several effort estimation approaches and gauging both the utility and inherent pitfalls in each.
Additionally, this paper will present a refined method for software effort estimation based on expert judgment and describe benefits of using said method.
where a & b come from historical data/curve-fitting
Effort = LOC*Productivity
Combines inherent simplicity of expert judgment method w/feedback control provided for in other models
Expert A: 40 hours
Expert B: 20 hours
Expert C: 5 hours
Expert D: 20 hours
Expert E: 30 hours
No historical data:
40*0.2+20*0.2+5*0.2+20*0.2+30*0.2 =23.0 hours
Everybody counts methodology…
If we had rules where we threw out experts’ estimates if they were wildly off: > 12.0 STDEV
(Where σi <12.0)
(Could be closer?)
You could alternatively tighten the standard deviation constraint to trust only the leading expert…
(Where σi = best)
You could also adjust for deviations in estimate (how far they are normally off and in what direction)