Function and application points


Function points are a language independent way of expressing the functionality that is included in a program or other executable software unit. Function points wwre proposed by Albrecht (Albrecht 1979) and refined by Albrecht and Gaffney (Albrecht and Gaffney 1983). Garmus and Herron (Garmus and Herron 2000) describe the practical use of function points in software projects.

Productivity is expressed as the number of function points that are implemented per person-month. A function point is not a single characteristic but is computed by combining several different measurements or estimates. You compute the total number of function points in a program by measuring or estimating the following program features:

Obviously, some inputs and outputs, interactions and so on are more complex than others and take longer to implement. The function-point metric takes this into account by multiplying the initial function-point estimate by a complexity-weighting factor. You should assess each of these features for complexity and then assign the weighting factor that varies from 3 (for simple external inputs) to 15 for complex internal files. Either the weighting values proposed by Albrecht may be used or values based on local experience.

You can then compute the so-called unadjusted function-point count (UFC) by multiplying each initial count by the estimated weight and summing all values.

UFC = SumOf(number of elements of given type) * (weight)

You then modify this unadjusted function-point count by additional complexity factors that are related to the complexity of the system as a whole. This takes into account the degree of distributed processing, the amount of reuse, the performance and so on. The unadjusted function-point count is multiplied by these project complexity factors to produce a final function-point count for the overall system.

Symons (Symons 1988) notes that the subjective nature of complexity estimates means that the function-point count in a program depends on the estimator. Different people have different notions of complexity. There are therefore wide variations in function-point count depending on the estimator’s judgement and the type of system being developed. Furthermore, function points are biased towards data-processing systems that are dominated by input and output operations. It is harder to estimate function-point counts for event-driven systems. For this reason, some people think that function points are not a very useful way to measure software productivity (Furey and Kitchenham 1997)(Armour 2002). However, users of function points argue that, in spite of their flaws, they are effective in practical situations (Banker, Datar et al. 1993; Garmus and Herron 2000).

Application points (Banker, Kauffman et al. 1994) are an alternative to function points. They were originally called object points. They can be used with languages such as database programming languages or scripting languages. The number of application points in a program is a weighted estimate of:

  1. The number of separate screens that are displayed. Simple screens count as 1 object point, moderately complex screens count as 2 and very complex screens count as 3 object points.
  2. The number of reports that are produced. For simple reports, count 2 object points, for moderately complex reports, count 5 and for reports which are likely to be difficult to produce, count 8 object points.
  3. The number of modules in imperative programming languages such as Java or C++ that must be developed to supplement the database programming code. Each of these modules counts as 10 object points.

The advantage of application points over function points is that they are easier to estimate from a high-level software specification. Object points are only concerned with screens, reports and modules in conventional programming languages. They are not concerned with implementation details and the complexity factor estimation is much simpler.

References

Albrecht, A. J. (1979). Measuring application development productivity. SHARE/GUIDE IBM Application Development Symposium.

Albrecht, A. J. and J. E. Gaffney (1983). "Software function, lines of code and development effort prediction: a software science validation." IEEE Trans. on Software Engineering, SE-9(6): 639-47.

Armour, P. (2002). "Ten Unmyths of Project Estimation." Comm. ACM, 45(11): 15-8.

Banker, R., R. Kauffman, et al. (1994). "An Empirical test of Object-Based Output Measurement Metrics in a Computer-Aided Software Engineering (CASE) Environment." J. of Management Info. Sys. Winter 1991-92, 127–150.

Banker, R. D., S. M. Datar, et al. (1993). "Software Complexity and Maintenance Costs." Comm. ACM, 36(11): 81-94.

Garmus, D. and D. Herron (2000). Function Point Analysis: Measurement Practices for Successful Software Projects. Boston, Mass., Addison Wesley.

MacDonell, S. G. (1994). "Comparitive review of functional complexity assessment methods for effort estimation." BCS/IEE Software Eng. J., 9(3): 107-17.

Symons, C. R. (1988). "Function-point analysis: difficulties and improvements." IEEE Trans. on Software Engineering, 14(1): 2-11.

Furey, S. and B. Kitchenham (1997). "Point/Counterpoint: Function Points." IEEE Software, 14(2): 28-31.

 


(c) Ian Sommerville 2008