Function Points FAQs
Resolving Common Counting Issues
The IFPUG Counting Practices Manual (CPM) Release 4.2, May 2004 is the current defacto international standard for Function Point Analysis. This Manual is the primary source of counting guidelines for FP Analysts. It includes a series of definitions, rules and examples, which provide FP Analysts with guidelines for functionally sizing software.
It is recognised by FPA practitioners that the IFPUG guidelines are subject to interpretation in some areas, and do not specifically address, some types of functionality that exists in today's applications. FP Analysts are increasingly being asked to count different types of applications within different software domains. Where specific IFPUG guidelines are not provided, FP Analysts must interpret the existing guidelines. Within an organisation, it is very important to ensure that such 'interpretations' are consistent among FP Analysts, and, are applied consistently, to ensure a repeatable, accurate and auditable outcome.
The resolutions in this document are provided to ensure a standard approach is adopted when counting common functions, and technical and design features, delivered by the software used within an organisation. This document will continue to evolve over time, as FP Analysts gain more experience with their organisation's applications and as new counting issues are encountered and resolved. Users of this document should ensure that they are using the latest version by referring to the Document Version Control information in Amendment History on page iii of the manual.
NOTE: The IFPUG Counting Practices Manual Release 4.2 provides examples on how to count various software implementations. However in some instances these examples do not adhere to the basic rules and guidelines presented elsewhere in the 4.2 text. It is recommended that when there is a conflict between the counting guidelines and the examples, that you ignore the resolution given in the examples and use the basic concepts of FPA to develop your resolution.
The issues and resolutions discussed in this document attempt to address counting issues commonly encountered in a modern computing environment. However, nearly every count raises its own unique issues. A 'recipe book' approach is inviting but is not practical since every application has to be assessed relevant to its own user business environment and user needs. A typical scenario has been provided with most issues and a counting resolution developed for its characteristics. These issues are provided as a guide for FP Analysts to develop resolutions for their own issues. It is recommended that all major counting issues and their proposed resolutions be approved by the Function Point Administrator before being officially adopted and incorporated into this document.
STEPS IN DEVELOPING A RESOLUTION
1. Check if the process, or data is a Functional User Requirement:
1.1 If Yes then check that it has the attributes of a unique Elementary Process (transaction), or logical data group (logical file).
- If Yes then determine the number of Transactions and Files, type and complexity
- If No then check if it is business data which contributes to a file and or transaction
- If Yes then count as one or more Data Element Types (or Record Element Types)
- If No then ignore it and do not consider in the FPA count
2. If No then check if the process or data is a user required quality or technical feature:
2.1 If Yes then it may be a candidate for assessment in a General System Characteristic
2.2 If No then ignore it and do not consider in the FPA count.
NOTE: The recommended strategy for resolving issues is to check that the process or data you are evaluating is a user business function and exists for business reasons not just for technical or design reasons. One of the best methods of doing this is to try and determine other ways in which the same user requirement could be implemented. This often gives an insight into 'what' is being delivered without clouding the issue with 'how' it is being done.
Counting Issues would not be identified as such if their resolutions were clear-cut. In the issues described in this manual, the resolutions presented represent the best opinion of Total Metrics consultants who specialize in providing IFPUG function point analysis related services. There are instances where two equally appropriate resolutions are possible for a particular issue, in these cases both resolutions have been included. It is recommended that an organisation select the alternative that best suits their purpose for counting, and the environment in which the counts will be conducted.
FUNCTION POINT ADMINISTRATOR ROLES AND RESPONSIBILITIES
The Function Point Administrator performs the role of the FPA expert within an organisation; as such they plays a key role in the Issue Resolution process. The Function Point Administrator should:
- Keep informed of any changes in FPA techniques, rules or principles
- Communicate any changes in FPA counting rules, guidelines or procedures to function point FP Analysts
- Communicate the basic principles, uses and benefits of FPA to management
- Develop procedures, guidelines and standards for the collection, recording and reporting of FPA data
- Provide expertise to resolve function point counting issues
- Establish regular workshops/forums at which function point counting issues and their resolutions can be discussed within the organisation
- Include new issues and their resolutions in this manual, and provide regular updates to FP Analysts
- Participate in Industry associations/groups that specifically address FPA Counting Guidelines and issues, in order to ensure that issue resolutions developed by the organisations FP Analysts, are compatible with current Country and International practices.
Function Point Repository Tool Functionality
Most organisations that implement FPA utilise a software repository tool to store, document, calculate and report their function point counts. One such tool is SCOPE.
For some issues, the ability to implement the resolution described, relies upon the functionality provided by the organisation's Function Point Repository Tool. In this manual, wherever this dependency exists it is clearly identified. As SCOPE is widely used by organisations that implement FPA, a description of how the resolution can be implemented in SCOPE is provided for relevant issues. Organisations using different Function Point Repository Tools will need to investigate the functionality provided by their tool of choice, and map that functionality to the resolution requirements.