Function Points FAQs

Front End Systems - Counting Guidelines

Home

Issue Description

Functional Overview

General Discussion and Resolution


ISSUE

Many organisations have computer systems that have new Front End Systems which allow users to make enquiries on reference data which resides on older, legacy Host systems and to enter transactions whose prime objective is to update information on the Host systems. These systems exist only as a front end to the Host system, but are considered to be separate applications. Separate project teams develop and maintain these Front End Systems and separate Work Orders are received for enhancements to these systems. In FPA terms how should these systems be counted?

 Home


FUNCTIONAL OVERVIEW

The functionality offered by the Front End System (FES) often duplicates functionality available within the Host system when operated in ‘native’ mode. The required functions and screens are purpose built for the FES.

Data required to satisfy the FES enquiry requirements often is physically copied from the host into temporary data repositories, which exist for the duration of the session and/or the customer enquiry, and/or the creation of the service transaction. Once each of these functions is completed the data is deleted from the FES.


Front End Systems tend to have very few true Internal Logical Files; they rely on the databases of the Host Systems that they access. Hence their EIF contribution to the overall FP result is higher than the normal 1-4%.

Front End Systems may have their own reference table ILFs (existing for FES use only and maintained by FES transactions). Often, FES’ use reference data provided by the host systems either by reading from Host system files directly, or by ‘copying’ the host system files into the FES.

FES’ are usually required to maintain a copy of the data they send to the host system, for example a copy of all Order transactions sent. At a minimum they are required to record the fact that a transaction has been sent.

Issues to be addressed include:

  1. Where should the FPA application boundary be drawn? Should Front End System functionality be counted as part of the Host System?
  2. If the Front End System is considered a separate application how should:

2.1 the information that physically crosses the application boundary be counted?

2.2 the data that is maintained/accessed be counted?

2.3 the data downloaded from the Host Systems be counted?

2.4 data conversion/translation tables and processes be counted?

Home


GENERAL DISCUSSION AND RESOLUTION

The development of Front End Systems is initiated by the business. While from a strict FPA view their functionality is an integral part of the host system functionality, however, in reality, these applications exist within their own right. They have business sponsors and separate project teams. One of the prime purposes for implementing FPA within an organisation, is to measure software product delivered. As business requirement changes impact both the Host and Front End Systems, and work effort is expended in both systems to implement the change, both systems should be credited with Function Points for software product delivered.

The application boundary is therefore considered to exist between the Front End System and the Host System.

Most purposes for counting would not be served by drawing artificial logical application boundaries around systems that are physically separate and acknowledged by all concerned as separate (i.e. by management, business sponsors and development teams).

Note: This resolution does not apply to distributed systems. Where an application, which is recognised by the business as a single application, resides on multiple platforms (e.g. PC and Mainframe), application boundaries should not be drawn between the platforms. See Section 3.3.1 Distributed Systems.

Having established the boundary the other FPA issues can now be addressed.

Files: Internal Logical Files

Where they exist, the following may be counted as ILFs for the Front End System:

  • Log files, in which copies of the transactions sent between the FES and the host are recorded.

Note: Only count these files where there is a business/legal requirement to record this data within the FES. (See Section 3.2.6, Error Files, Suspense Files, Event Logs, Journal Files, Statistics Files.)

Transactions should exist which allow the logged transactions to be viewed and reported on.

  • Files in which the transaction, transfer events are recorded. For example, there may not be a requirement to record the detail of a transaction, but there may be a requirement to record the fact that a transaction between the host and front end has occurred, and optionally, the current status of the transaction.

Note: Only count these files where there is a business requirement to report the data and the information cannot be derived from a transaction log file (see previous bullet point).

  • Reference Tables, that are specific to the FES and maintained by FES transactions.
  • Reference Tables that are sourced from other systems but are required to be processed (e.g. extracted, converted, translated etc.) by the FES before the data can be used by FES transactions. (See Section 3.4.4, External Interface Files – Sample Scenarios.)
  • Reference Tables used for purposes of data conversion/translation by both External Inputs and External Outputs.

Files: External Interface Files

Where they exist, the following may be counted as EIFs for the Front End System:

  • Host system files, which are referenced when a direct enquiry is made on host system data. For example, Enquire on Account Balance.

Note: These files are counted as EIFs even if, in response to the enquiry, the required data and/or additional data is transferred to the FES, and resides in temporary data repositories for the duration of the enquiry/session.

  • Reference files that are copy managed from the Host system or other systems. The FES does not have any transactions that directly maintain the contents of these files. (See Section 3.4.4, External Interface Files – Sample Scenarios.)

Transactions: External Inputs

Where they exist, the following may be counted as EIs for the Front End System:

  • All elementary processes that create, modify, delete host system data, where copies of the data are required to be stored within the FES for future enquiries and reports.
  • Transactions that maintain FES specific reference tables.
  • Transactions which upload/process/extract reference table data from Host system downloads. (See Section 3.4.4, External Interface Files – Sample Scenarios.)

Note: These should be checked to ensure that they involve real processing of the data and not just a simple overwrite of the FES file. In this case the load transaction is not an EI.

  • Elementary processes which maintain transaction event records.

Note: See Section 3.2.6, Error Files, Suspense Files, Event Logs, Journal Files, Statistics File for a description of how these maintenance functions should be counted.

  • Elementary processes that alter the status of the transactions stored within the FES. For example, a confirmation message received from the Host to indicate host processing of the function has completed successfully/unsuccessfully.

Note 1: A confirmation message that simply confirms the FES transmission was successfully received, is not counted as a separate elementary process. Rather it is part of the elementary process that transfers the business transaction from the FES to the Host. See Transactions: External Outputs, below.

Note 2: Investigate all status change transactions for uniqueness. Does the status change involve the update of any other data or is it simply a change to the value of the status flag?

Transactions: External Outputs

Where they exist, the following may be counted as EOs for the Front End System:

  • Reports which present data on the volume of transactions between the FES and the Host System.
  • Transactions transferred to the Host System provided that:
  • the output contains calculated, derived or manipulated data, and/or
  • a logical file is maintained as a result of the output. For example, the status flag on the record in the Transaction File is set to ‘Transmitted’ as a result of the output.

Where these conditions are not present the output is classified as an External Enquiry.

  • Other External Outputs as per existing IFPUG guidelines.

Transactions: External Enquiries

Where they exist, the following may be counted as EQs for the Front End System:

  • All enquiries made on the Host system files for which screens have been built within the FES.
  • All enquiries made on FES Internal Logical Files.

 Home

Issue Description

Functional Overview

General Discussion and Resolution