Skip to content

The Benefits of Function-point Analysis

Vector 5:3, page 79

development practice

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 79

“A slightly strange process of counting up system elements, assigning times, and adding them up”

“Function point is an objective way of showing that APL really is as productive as we’ve always suspected”

You can’t manage what you can’t measure. ‘Functionality’ is what FPA measures; this broadly corresponds with what you are giving the user. It also correlates with the cost of development and also with cost of maintenance. FPA is independent of the method of implementation; it is based on what the user sees: input, output, files, enquiries and so on. The cost of development can be given in ‘Fn pts per man-week’: for Cobol, figures are typically between 10-30; for APL, 300-500 is common.

All very nice in theory … here are three concerns:

  1. The method was originally devised and tested in the late 70’s when computing was very much simpler than it is today. Life was about transactions, records and simple displays. Now we have graphics, relational data and so on. Do these invalidate the FPA validations?
  2. FPA is not appropriate (and has never been advocated) as a measure of individual performance. A lot of APL projects are completed by 1 or 2 people!?
  3. FPA is a terrible temptation. We’ve been looking for this for years …. of course FPA must be valid: it tells us just what we want to know!!