Function-point counting requires going through a requirements specification line by line and literally counting each input, output, file, and so on. This can be time consuming.
Estimation experts have proposed a handful of simplified approaches to counting function points. Considering the other sources of variability that feed into a software project in the early stages when function points are relevant, a focus on minimizing the effort required to obtain a not-very-accurate estimate seems appropriate.
The Netherlands Software Metrics Association (NESMA) suggests an "Indicative" method for early-in-the-project function-point counting (Stutzke 2005). In its method, rather than counting all inputs, outputs, and queries, only Internal Logical Files and External Interface Files are counted. An Indicative Count is then computed using this equation:
(#8) |
The numbers 35 and 15 have been derived through calibration, and you would ultimately want to come up with your own calibrations for use in your environment.
The function-point counts created using this method will be less accurate than counts created using the full function-point counting technique described in Section 18.2, "Function-Point Estimation." But the effort required is much lower, and so this sort of approximation can be useful for rough estimates.
Tip #82 | Use the Dutch Method of counting function points to attain a low-cost ballpark estimate early in the project. |
As an alternative to counting function points directly, you might count GUI elements instead. This is an example of proxy-based estimation, as described in Chapter 12, "Proxy-Based Estimates." The process follows these steps:
Count the number of GUI elements according to the categories in Table 18-4.
Convert the GUI elements to an approximate function-point count by transferring appropriate entries generated from Table 18-4 to the matrix shown in Table 18-1.
Calculate size in lines of code by using the relationships shown in Table 18-3.
GUI Element | Function-Point Equivalent |
---|---|
Simple Client Window | 1 Low Complexity External Input for add, change, and delete (if present), plus 1 Low Complexity External Query |
Average Client Window | 1 Average Complexity External Input for add, change, and delete (if present), plus 1 Average Complexity External Query |
Complex Client Window | 1 High Complexity External Input for add, change, and delete (if present), plus 1 High Complexity External Query |
Average Report | 1 Average Complexity External Output |
Complex Report | 1 High Complexity External Output |
Any File | 1 Low Complexity Internal Logical File |
Simple Interface | 1 Low Complexity External Input if coming in; 1 Low Complexity External Output if going out |
Average Interface | 1 Average Complexity External Input if coming in; 1 Average Complexity External Output if going out |
Complex Interface | 1 High Complexity External Input if coming in; 1 High Complexity External Output if going out |
Message or Dialog Box | Not counted; are counted as part of the screen they connect to |
If you use this approach, recognize how much uncertainty is feeding into your estimate. Some uncertainty likely exists in your original counts of the number of GUI elements or your estimates of them. You introduce additional uncertainty when you convert from GUI elements to function points. And you introduce still more uncertainty when you convert from function points to lines of code.
Tip #83 | Use GUI elements to obtain a low-effort ballpark estimate in the wide part of the Cone of Uncertainty. |