FPA - Some changes are no changes

Or in other words: Some changes are free

The definition of a maintenance project according to NESMA is: A project in which functional changes with regard to an existing information system are realized. In the information system functions can be added, changed or removed.
The first conclusion is that technical changes can not be counted with this guideline. Organizations which offer maintenance based on fixed price/function points may have a problem here, unless they make additional agreements with their customer, which is done often. A good question is if bugfixing counts as a change. My opinion tends to be: This depends. If the bug is of a technical nature, the functionality is not changed. An example might be a programming error where the system occasionally crashes. If however, the system requires that data element z should be equal to a + b, and the bug is that z = a + b + c + d, then the functionality changes, and this should be counted as a functional change.

It is important here to distinguish between the question: ‘Should we count this?’ and the question: ‘Should we charge this to the customer?’. The first question can be answered from the counting guidelines, the second by the contract. It may well be that the change may be counted, but not billed. The reverse situation, that the item may be billed but not counted, is something I see less often.

A second conclusion is that we must differentiate between the documentation of specification of the information system and the information system itself. The specifications and the information system will generally not correspond 100%. What concerns us here is that we count functional changes to the information system, regardless of the documentation. This is why some bugs, if they are functional in nature, may and should be counted even if the documentation does not change.

FPA had several formulas for maintenance projects, that is, for changes to existing systems. One formula is for the size of the system:

PROD_New= PROD_Old + FUN_Added – FUN_Removed + (CHANGED_New - CHANGED_Old)

This formula is given on page 15 of the NESMA counting guidelines reference manual.

The other formula, which is given on page 18 of the NESMA counting guidelines, is the size of the project.
This formula is:

PROJECT = FUN_Added + FUN_Removed + CHANGED_New

An example of both is given in between these two formulas, which is strange, as it introduces the project formula in an informal form before it is explicitly defined. Several conclusions can be drawn from this last formula. The first one is:

1. 1) Any functional change to a function should be counted as if the function has to be build anew.
This is of course not very accurate. There generally is not very much discussion about = FUN_added + FUN_removed. But CHANGED_New is another matter. Changes may be big or small, and I know of at least one softwarehouse that varies the number of function points depending on the number of data-elements involved in the change. This will generally please the customer: they will pay less than in the case of a full count as prescribed by the NESMA guidelines. There is a considerable drawback imho: Counting a reduced number of function points for some small changes makes it doubtful if they can still be considered function points.

It is understandable that some customers get upset if a customer has to pay for say a nearly identical extra data element to be added to 100 screens as if these screens should all be build from scratch.

A second conclusion is:

1. 2) Non functional changes should not be counted.
Cosmetic changes may be chosen as an example. A complete whole-over of the layout of a website might well result in 0 function points, while it requires a considerable effort to realize. Again: if these changes can be billed also depend on the contract. Contract definitions are very important in this respect. If the contract specifies that all functional change requests will be billed a E xx per function point, cosmetic changes might still be charged as they are not covered by the contract. If the contract stipulates that all changes will be charged at xx per function point, the supplier might have a problem.

In the long term, the effect of 1) and of 2) might cancel out each other, but short term fluctuations might be large. One way to solve this dilemma would be to agree that exceptional circumstances might be offered on a non FPA based estimate, but that is an option that would not please most FPA afficionados. Neither would it please the lawyers and management negatiotors, as it would be hard to define what is exceptional.