Count And Compute
Count for software estimation is the most basic thing to do in each development phase. Software projects produce many things to count that can be used as a basis for estimates. Counting strategies are not only the foundation of further estimation techniques but also starting point to develop your own estimation strategy.
Description
Developing software produces a large amount of data that easily can be counted. In early development phases you can for example count requirements, features, use cases, and stories. In the middle of the project you can count things like Function Points, change requests, Web pages, reports and so on. Late in the project it is possible to count code written, defects reported, classes, packages, tasks and many things more.It is recommended to select a measure that is correlated with the size of the software. The estimated size is important for estimating cost and schedule. The indicator of size is also influenced by the environment. It is important to find something that's a relevant indicator of size in a specific environment. The measurement of software size is a major core discipline for project effort and productivity. It is impossible to estimate any project if you don't know the size of the product being developed.
Size indicators shall be identified as soon as possible in the development cycle to guarantee long-range predictability. McConnel recommends to find at least something that produces a count of 20 or more to get statistically meaningful result.
To get an accurate basis for your estimation, you need to be sure that the count based on historical data and the count for your actual estimation, are acted on the same assumption. For example, if you are planning to estimate Marketing Requirements with historical data, be sure that gained information from your historical Marketing Requirements have the same basis, like team size, programmer experience, development technology and so on.\cite{McConnel_BlackArt05} \\
The input values must be clearly documented to guarantee a trustworthy measurement and estimation. Therefore it is crucial to measure in a precise manner and to evaluate the complexity of the project. To minimize variances in computations and effort estimations you should also address the following items:
- Overtime work effort must be recorded to get any reliable computations.
- item Project start and end points can't vary. In the historical database has to be a consistent definition for the project with fixed start and end dates.
- Teammembers must be known. It has to be defined who is included into the project. This can have a huge impact on the reported effort hours for a project
- The type of project must be recorded. For future estimations it has to be known from what type of project the historical data comes from.
- Software development methodology must be clearly defined for the project being measured.
How To
The Software Process Measurement Project recommends to establish a framework for counting. Two principle criteria for a general strategy are:
- Communication: If someone uses our methods to define a measure or describe a measurement result, will others know precisely what has been measured and what has been included and exluded?
- Repeatability: Would someone else be able to repeat the measurement and get the same result?
Software metrics are quantitative measures to gain insight into efficacy of software processes and into problem areas. IEEE standard glossary defines software metrics as "a quantitative measure of the degree to which a system, component, or process possesses a given attribute". They provide requisite information for quantitative decision making and estimations as well as supporting risk assessment and reduction.
One of the first and simplest software metrics is the number of lines of code.
There are numerous tool to count lines of code easily. Lines of Code are a intuitively meaningful measure for software size. Measurement in LOC allow for cross-project comparisons and estimation of future projects. On the other side LOC are error-prone because of software's diseconomy of scale, differences in productivity between programmers and complexity differences in projects. It is also difficult to measure LOC at the beginning of the project.\cite{Bundschuh} Anyway, LOC are a good measure to start counting, but surely other counts can be measured easily as well, like Features, User stories, Story points, Use cases, Function points, Web pages, GUI components, Interface definitions, Classes, Packages, Defects, Change Requests, Effort in hours/persondays/weeks, Money involved and many more.
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.
Example
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. |
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.