Effort estimates may be used as input to project plans, iteration plans, schedule, budgets, investment analyses, pricing processes and bidding rounds.
Typically, effort estimates are over-optimisticand there is a strong over-confidence in their accuracy. The mean effortoverrun seems to be about 30% and not decreasing over time.
1. Software estimation categories
There are many ways of categorizing estimation approaches, see for example.[9][10] The top level categories are the following:
- Expert estimation: The quantification step, i.e., the step where the estimate is produced based on judgmental processes.
- Formal estimation model: The quantification step is based on mechanical processes, e.g., the use of a formula derived from historical data.
- Combination-based estimation: The quantification step is based on a judgmental or mechanical combination of estimates from different sources.
Expert estimate is the dominant estimate method in the industry.
2. Estimate practices (Expert estimate)
2.1 Estimate check list
- Coding
- Unit test
- Integration test
- Build script
- Installation
- Document
- Buffer
2.2 Use Historical data
Historical project execution data is very valuable for estimation, we often make estimate using below historical information:
- Line of code (total and per-task)
- Dev effort (total and per-task)
- Common issues and risks
- Common bugs raised.
2.3 PERT estimate (三点估算)
(Pessimistic estimate + 4 * Most likely estimate + Optimistic estimate) / 6
3. Limitations
Limitations to the accuracy of software estimate include:
- How well the requirement is described.
- Domain knowledge related to the task being estimated.
- Technologies used in development.
- Development infrastructure and environment. E.g. IDEs, test servers, version control tools, project management tools
- Pressure from management, schedule, cost, etc.
- Development process
软件估算是手段,不是承诺。
软件估算是范围,不是精确值。
References
Jørgensen, M.. "A Review of Studies on Expert Estimation of Software Development Effort"
PMBOK