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?

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:

• Language

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.

• Source

Technical interfaces to handle receipt of the same information from different sources.

• Date format
• Front-end transactions may be ASCII format while the native transactions are EBCDIC.
• The order of fields within front-end transactions may differ from those in native transactions.
• Field lengths.
• Construct of application-to-application message format.
• Scrolling

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.

• System to system communication

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:

• the processing logic is different from any other elementary process
• data elements and/or file accesses are different from any other elementary process

Processing logic is defined as business rules:

• algorithms, calculations, editing or validation rules

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:

• Condition 1

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.

• Condition 2

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.

• Condition 3

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.