| || |
by: Paul Goodman
There is a very important word in the term Function Point Analysis, namely Analysis.
We tend to think of FPA as providing a size measure, which enables meaningful comparison of productivity across projects, systems and enterprises. We also concentrate on the use of FPA in cost estimation. However, the most important factor is that FPA views systems from the users perspective.
Users put information into an application, they get information out and they recognise discrete groups of data, entities or files, that the system will use and maintain. If we keep decomposing our system, we reach the lowest level of user recognisable functionality.
The International Function Point User Group (IFPUG) Counting Practices Manual (CPM) calls these elementary processes, the MkII Function Point CPM calls them Logical Transactions. The figure, below, shows this for part of a warehouse system.
In order to apply FPA you define not the layout of reports but the information contained in the output. That is all you need for FPA. One of the problems analysts have is that so called requirements specifications often express how the system will do things rather than what it will do. Also, the specifications are invariably incomplete!
Well defined specifications that can be sized can become the basis for contracts. Project constraints and service level agreements can easily be added later.
The relative proportions of the various function point components can inform us about the probable completeness of the specification. For MkII FPA, this involves comparing the ratio of input DETs, entity references and output DETs. For IFPUG FPA we must compare the ratio of external inputs, outputs and queries and internal logical files and external interface files.
Omissions and Duplication
FPA can be used to size any business function whether or not that function is supported by a computer system.
Many of us have been asked to report progress in terms of percent complete. This is sometimes expressed in terms of components built vs. components to be built; actual lines of code delivered vs. estimated lines of code to be delivered; actual effort consumed vs. estimated effort still to be consumed (which seldom decreases!) or various combinations of these. These measures have serious defects. They tend to be meaningless until quite late in a projects life and they are often based on estimated values.
Yet in FPA, we have expressions such as 50% of our Logical Transactions have now been signed off, or even 25% of the total Function Point Index has now been signed off.
|GIFPA Ltd. 2016|