More than just counting
To estimate a software development project based on the number of function points of the project, one does not automatically use the standard productivity rate for the specific development environment. Beforehand, one should determine whether there are specific circumstances that may influence (in a positive or negative sense) the productivity rate for the project. This analysis results in the expected project productivity rate.
The estimating and budgeting process consists of more activities than a function point analysis. FPA is just a supporting tool in this process. One needs to perform four steps to make a budget for a project based on FPA:
- Determine the functional size of the information system to be developed
- Determine the standard productivity rate for the development environment
- Determine the expected project productivity rate
- Budget the project
1: Determine the functional size of the information system to be developed
The amount of hours needed to develop an information system is related to the size of the information system in the same way the number of hours needed to build a wall is related to the size of the wall (number of bricks). The bigger the information system, the more hours one needs, and the more expensive it will cost. Function points are a good measure for the functional size of an information system. The functional size of an information system is expressed in a number of function points.
The way in which FPA determines the functional size of an information system is described on the page Function Point Analysis of this cluster.
2: Determine the standard productivity rate for the development environment
Determining the (functional) size of the information system is not enough. The next step is, to determine the specific development environment of the information system. It is clear, that the specific development environment (software and hardware) plays an important role in the needed number of development hours, especially in the construction phase (programming and testing).
There may be a big difference in developing an information system in a third generation programming language, like Cobol, or in a fourth generation language. The same remark is valid for the various hardware platforms and architectures, such as mainframe, PC, client server, SOA environment or the cloud. It is generally necessary to maintain a standard productivity rate for each development environment: needed development hours per function point. A company should record these standard productivity rates for each phase of the system development life cycle. For the Construction phase, however, the reliability and repeatability is more consistent than for earlier phases of the project life cycle.
Standard productivity rates (specifically per development environment) are determined based on experiences with completed similar projects in the past. These project productivity rates from the past are an indicator for the expected productivity rates in new similar projects in the future. Experiences in new projects may lead to an update of the standard productivity rates. To sensibly use a standard productivity rate in future situations, a company should clearly determine which project activities are included in this rate (for more explanation, see step 4). Activities that are not included in the rate should be budgeted individually in step 4.
3: Determine the expected project productivity rate
Using a check list with so called “productivity attributes”, one should establish whether there are specific circumstances for the project under consideration that influence the productivity in positive or negative sense (for example, inexperienced/very experienced project staff, a new development tool, etc.). One should estimate the particular influence of these circumstances and “translate” them into the expected project productivity rate (hours per function point for the project under consideration). This expected project productivity rate may differ from the standard productivity rate for the specific development environment.
The step from function points to the initial project budget (needed development hours in the project) is simple: multiply the number of function points by the expected project productivity rate in hours/fp.
4: Budget the project
For each productivity rate (hours/fp) an organization should record which activities are included in this rate, and which are not. Activities that are usually not included in a productivity rate are activities that are not correlated to the size of a project or not always performed in a typical project. For example, in some projects an organization needs to have extensive talks with external third parties, but not in all projects. This could be a reason for the organization not to include this type of activity in the (standard) productivity rate.
Effort needed for activities that are not included in the productivity rate should be estimated in another way; these hours should be added to the initial project hours (hours related to the activities that are included in the standard productivity rate) as determined in step 3, see above.
Another good way to estimate the project costs other than that based on FPA is to determine a traditional estimate from experienced staff and specialists. Comparing both estimates (FPA versus traditionally estimated) may provide a better analysis in more detail, and a better estimate.
Using the expected project hours needed, the financial rates and other expenses, one finally determines the project budget (cost).
Confront the result
Finally, Nesma advises to always calculate a budget based on a “conventional” activity estimate of specialists too, based on the Product Breakdown Structure and the Work Breakdown Structure.
Compare this specialist estimate with the FPA estimate.
Although estimating based on functional size is widely recognized as being superior to specialist estimates, the confrontation of the two approaches together results in an even better reliability of the estimate than either of the two approaches apart.