Some notes for Software Engineering --
Estimating
by Herbert J. Bernstein
© Copyright Herbert J. Bernstein, 2002
Estimating
There is no algorithmic way to estimate the time and resources
that will be required to do an arbitrary software project, for the
same reasons that we cannot write a program that will determine
if an arbitrary program will halt. (See
http://www.idiom.com/~zilla/Work/Softestim/softestim.html,
Mathematical
Limits to Software Estimation, supplementary materials, by J. P. Lewis).
However, there are heuristics we can apply to try to estimate
many software projects.
- People are the problem
- Hardware and communications costs are "easy" to estimate
- Purchased software infrastructure is "easy" to estimate
- People cost more than hardware and communications
- People are difficult to control and predict
- All estimates depend on estimates of productivity
- 3-20 lines of code per day per programmer (usually 3)
- There are 200-240 working days in a year
- productivity declines with multiple interactions
- managers are needed
- managers do not produce code
- infrastructure and support people are needed
- space
- utilities (power, HVAC, telephone, network)
- secretaries, guards, IT, etc.
- infrastructure and support people do not produce code
- people need materials, supplies and travel money
- material supplies and travel money do not produce code
- estimate salaries + fringe + MS&T + overhead
- salaries are the direct payments to the programmers
- fringe benefits are such things as health insurance,
unemployment insurance, FICA, usually applied as
an averaged percentage of salaries
- overhead includes such things as space, managers,
secretaries, guards, usually applied as an averaged
percentage of "modified total direct costs" (salaries
+ fringe + MS&T)
- If a programmer costs $100,000/yr and produces 1000 lines
of code, and fringe and overhead double costs, you spend $200
per line of code.
- Computer hardware costs are rarely large, but someone must pay them.
- Time
- Triple all estimates
- There are only 1200 productive hours in a year
- Allow time for all the processes in the project
- The best estimates are made by experienced programmer-managers
- The worst estimates are made by experienced programmer-managers
- Reuse can help
- Reuse can hurt
- Algorithmic models
- Based on characteristics of completed projects, e.g.
- estimated lines of code, or
- function points, or
- I/O elements
- user interaction elements
- ...
- object points
- number of screens
- number of reports
number of code modules
- Model is fit to available data
- Resulting curves tend to be non-linear
- Only work when accurate size estimates are available
and new project is sufficiently similar to the test base
- Bottom-line: estimation is an art, not a science.