How should system modules that are reused by transactions within the one application, or shared by multiple applications, be counted?

How should a change to the common module be counted?

Common Use Modules (CUM's) provide functionality that can be used by multiple business functions, across multiple applications. For example, GST Calculator functions, functions which permit read/write access to files etc. They are usually developed by one application team for use within their particular application, and then reused by multiple teams. Less commonly, a special development team, delivers generic functions that are intended for use by multiple applications.

They are created to maximise re-use within, and across, applications, thereby minimising development work effort. If the CUM did not exist each, transaction and application that requires the CUM functionality would need to develop and incorporate the necessary code. Typically CUM's standardise calculations, database accesses, or algorithmic functions.

A CUM, in FPA terms, represents a sub process of an elementary business process. The sub process is considered to be an integral part of each business function that uses it. The CUM is merely an implementation choice, made by the system designer to improve development and maintenance productivity.

When the logical processing within the CUM changes, the logical processing of all transactions that utilise the code is also considered to have changed. When a CUM is used by multiple applications, it may not be apparent to all applications that a change has occurred. Typically, the application, and development team which has responsibility for maintaining the CUM functionality, identify and develop the change and hence accrue project function points. For other applications, the change to the CUM may only be apparent from the testing specifications for an enhancement project. In some cases the required change may be specified solely as a change to the CUM. The specification provides no indication of the transactions which use the CUM functionality, or the context in which it is used.

Two resolutions are provided for counting changes to CUM functionality. The choice depends upon current system documentation practices, and whether they provide greater support to one or other of the resolutions. Wherever possible, resolution 1 should be adopted.

In order to standardise the counting of changes to a CUM, it is recommended that, for enhancement project purposes, each function within the application that uses the CUM should be counted as changed. The CUM itself should not appear on the functional hierarchy of the application baseline. Where the CUM is used by other applications, and there is a requirement to size the project for those applications, those functions that use the CUM should be identified and counted as changed.

If it is not possible to identify where a CUM is used, it is recommended that, for enhancement project purposes, the CUM should be treated as an elementary process and counted only once by the development team that maintains it. A separate CUM function is included on the functional hierarchy under a separate CUM parent. It is not expected that there are many such functions, nor that changes to them will occur often.