Function-point Analysis at British Airways

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

FPA is a technique which makes it simple to involve the user, but is broad-brush; it may be very misleading for small amount of data. However, British Airways like to make things measurable, and when you see figures like:

                     Fn pts / man-month
                     ------------------
Environment          Average    Maximum
-----------          -------    -------
3GL                     3-30      20-50
4GL(Focus)            50-120
APL                  200-300    300-500

… based on largely anecdotal evidence, you want to know more. The correlation with the size of task and with programmer experience (who got the results at the 500 end?) would be interesting. It would also be fascinating to know what the ‘productivity surface’ looked like … there are lots of non-linear functions in there!

An Example¶

This really falls outside the true domain of FPA, however it is typical of the things we do in APL. The system involved 12 new functions … the application was really made up of 8 of these (170 lines) with another 4 fns (270 lines) generated automatically to handle screen I/O. The data was held in blocked inverted files, with non-zero values compressed (say 80 mbytes per file), keyed for fast access. The screens show: (a) the file contents; (b) a series of sample compressions to help to select the best algorithm. Typically, picking the best algorithm can save some 42% of the current file space. The other info shown gives: (c) details about the keys; (d) a summary of the file blocking. There is help behind every screen panel.

The unadjusted function point count was 54. The process complexity was 33 (out of 70), giving an adjusted count of 54 × 0.98 = 53. Not counted were: reports (these are automatic, and users may not actually want them); the help screens. These yield up to 40 further function points, which are not claimed in the above total.

How long did it take? The activity-log says 5 days, with a lot of work on 4 of those days. This gives a figure in the 200-250 FP/MMnth range, which looks reasonable. Other very small systems have been in the 300-400 bracket.

Discussion¶

I think most people at the meeting agreed with the basic premise that FPA was measuring something sensible, and was a worthwhile technique for measuring APL systems. However the idea of using the figures to promote the case of APL as the new ‘wonder machine’ was not accepted; we would all like to see the evidence from a decent-size project or two! Maybe APLers have the luxury of being able to choose what they work on, and gravitate to ‘interesting’ systems (those with an intrinsically high fn-pt count) which they know they can do quickly? Maybe APL just attracts the brightest brains in the business, and we would still score high in COBOL if that was all we had? Yes, MJ’s comparison is a valid measure of something, but we don’t quite know what!