 |
|
|
|
|
|
|
||
|
||
|
|
|
by: Paul Goodman AnalysisThere 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. CompletenessThe 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 DET’s, 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. Component Ratios
Omissions and DuplicationFPA can be used to size any business function whether or not that function is supported by a computer system. Progress TrackingMany 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 project’s 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.” |
||||||||||||
|
|
||||||||||||||
|
||||||||||||||
Articles
Services
Training
|
||||||||||||||
|
||||||||||||||
| Software Measurement Services Ltd. | |||
|
|||
