Function Points FAQsFront End Systems - Counting Guidelines |
|||||||||
Home 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?
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:
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?
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:
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.
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).
Files: External Interface Files Where they exist, the following may be counted as EIFs for the Front End System:
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.
Transactions: External Inputs Where they exist, the following may be counted as EIs for the Front End System:
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.
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.
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:
Where these conditions are not present the output is classified as an External Enquiry.
Transactions: External Enquiries Where they exist, the following may be counted as EQs for the Front End System:
|