Function Points FAQs
Uniqueness of Front-end and Native Functions
Where a core application function is replicated by a core application function which satisfies a front-end system requirement, should separate transactions be counted?
Core applications are typically large, mainframe/text-based legacy systems. Many core applications have associated front-end applications that have been constructed with later generation tools in order to utilise user friendly features such as the GUI presentation layer. System users usually prefer a graphical interface to an awkward text based interface.
Core applications may have "native" transactions, i.e. transactions provided by the text-based application with corresponding front-end transactions. This situation is shown in the following diagram:
From the perspective of the core application, is it reasonable to account for both the front-end and native transactions?
GENERAL DISCUSSION AND RESOLUTION
Native and front-end transactions may be implemented with vastly different technologies. However, in accordance with IFPUG counting guidelines, differences in technical or implementation strategies are not an admissible basis for determining the uniqueness of a transaction. None of the following technical/implementation differences satisfy IFPUG conditions of uniqueness:
Native and front-end transactions have been written with different programming languages. For example, native transactions are written in the CSP language whereas front-end transactions are written in COBOL2.
Technical interfaces to handle receipt of the same information from different sources.
Native transactions have a technique to minimise the requirement for data transfer by utilising internal memory buffers with large amounts of data. Front-end transactions may be unable to restrict the volume of 'hits' upon the database, as they are unable to employ the memory buffer. Therefore the core application receives a transaction to provide more data for every scrolling request.
Communication of data differs depending upon the utilised technique.
Native and front-end transactions should be counted as individual transactions only where one of the following IFPUG definitions of unique processing logic are satisfied:
A unique elementary process must have the following properties:
Processing logic is defined as business rules:
Note: IFPUG Release 4.1 provides a comprehensive list of examples of different types of processing logic.
In cases where the front-end transaction contains data, which is a sub-set of the native transaction, FPA uniqueness criteria shall apply. FP Analysts should consider whether the following conditions apply:
The front-end and native transactions would always be impacted in the same manner by user change requests and over time both transactions would always stay aligned then one transaction should be counted for both native and front-end transactions.
If the front-end and native transactions are likely to change independently of each other, i.e. be the subject of independent change requests, unique transactions should be counted.
If the front-end/native transaction is removed from the application, and this results in all corresponding front-end/native transactions also being removed, then the transactions are considered variations and one transaction accounts for both native and front-end transactions.
If the front-end and native transactions are likely to be deleted independently of each other, both transactions should be counted.
If the front-end and native transaction retrieve/access the same records then one transaction should be counted for both native and front-end transactions.
If the front-end and native transaction retrieve/access different records then both transactions should be counted. For example, the front-end transaction may potentially return multiple records that satisfy search criteria but the native transaction would return only one record.