Computation
Computational estimates require data from count, see [Count]. If you collect historical data, you can convert the counts to estimated effort.
Description
Once all relevant facts for the software project are counted other relevant input factors are assessed. The project size is a very important input. It determines the resources, duration and costs. Before an estimate can be done all relevant factors must be evaluated, like:
- Stability of requirements
- Experience of the development team
- Project goals and constraints
- Technology to be used
- Quality requirements
Since measurement alone doesn't guarantee that a project can be delivered in time, within costs and adequate quality it must facilitate estimation to provide productivity and quality. Therefore relevant cost driving factors must be assessed as input variables to get a basis for computations estimation. These include the work effort of IT developers, system programmers, quality assurance, project management, data modeling, database and system management, testing and so on.
If the resource effort and the size of the project have been measured, you have to find applicable relationships between size and work effort. This can be done by size-based or heuristic estimates.
How To
In following table some examples are listed of what you can count and the data you need to compute an estimate.
| Quantity to Count | Historical Data Needed to Convert the Count to an Estimate |
|---|---|
| Marketing requirements | Average effort hours per requirement for development, testing, documentation, engineering requirements. |
| Features | Average effort hours per feature for development, testing. |
| Use cases, Stories | Average effort hours per use case/story. Average number of use cases/stories that can be delivered in a particular amount of calendar time. |
| Engineering requirements | Average number of engineering requirements that can be formally inspected per hour. Average effort hours per requirement for development, test, documentation. |
| Function points | Average effort hours per function point for development, test, documentation. Average lines of code in the target language per Function Point. |
| Change requests | Average effort hours per change request for development, test, documentation. |
| Web pages | Average effort per Web page for user interface work. |
| Reports | Average effort per report for report work. |
| Dialog boxes | Average effort per dialog for user interface work. |
| Database tables | Average effort per table for database work. |
| Classes | Average effort hours per class for development, inspection of class, testing. |
| Defects found | Average effort hours per defect to fix, regression test. Average number of defects that can be corrected in a particular amount of calendar time. |
| Configuration settings | Average effort per configuration setting |
| Lines of code already written | Average number of defects per line of code. Average lines of code that can be formally inspected per hour. |
Examples
Suppose you have counted 25 Use Cases for your project so far. Referring to historical data you have spent 60 hours per Use Case in a project that had similar conditions, you can estimate that your new project will take about 25 x 60 = 1500 hours of work.