Function Points FAQsSystem Interfacing Summary |
||||||||||||||||
| Home ISSUE System interfaces can be physically implemented in multiple ways. To what extent should the physical interface solution impact the business functions counted? This section has been included to attempt to summarise a number of system interfacing scenarios, commonly encountered. Some of the issues have already been addressed in the Sections describing Front End Systems. They are repeated and summarised in this section primarily to provide an easy comparison of different scenarios and the resolutions of the counting issues relevant to the scenario. To simplify the descriptions the following terms have been used
In each example it has been established that an application boundary exists between System A and System B.
SAMPLE SCENARIO Scenario 1 System A Enquiry on System B Files. System B handles the file access This scenario is described in detail in Section 3.3.6 Duplicate Counting of Front-end and Core System Functions. An enquiry transaction initiated by System A, requires information from File Y in System B. This results in a request for information sent by A to System B. System B accesses File Y and sends a response with the required data to System A. System A displays the response data on a screen. Scenario 1 Resolution Transactions Both System A and System B contribute to the enquiry function. Both count one EQ. Neither system counts the messaging between the two applications i.e. the request and response messages. A variation of this scenario occurs where multiple systems initiate the same EQ. All initiating systems count one EQ and System B counts one EQ only. Files There is only one file involved. System B counts File Y as an ILF. System A counts File Y as an EIF. Scenario 2 System A Enquiry on System B Files. System A handles the file access An enquiry transaction initiated by System A, requires information from File Y in System B. System A has all the functionality required to directly access the File Y. System A displays the response data on a screen Scenario 2 Resolution Transactions System A has all the necessary functionality to deliver the complete enquiry function. System A counts one EQ. There is no messaging between the two applications Files There is only one file involved. System A counts the File Y as an EIF. Scenario 3 System A Update on System B Files. System B handles the file access An update transaction initiated by System A, has as its primary intent the update of data in File Y in System B. This results in the update DETS being sent by A to System B. System B accesses File Y and updates the data. A confirmation/error message response may or may not be sent to System A. System A displays the response on a screen Scenario 3 Resolution Transactions Both System A and System B contribute to the update function. Both count one EI. Neither system counts the messaging between the two applications i.e. the sent update data and response messages. A variation of this scenario occurs where multiple systems initiate the same EI. All initiating systems count one EI but System B counts only one EI. Files There is only one file involved. Both System A and System B counts the File Y as an ILF. Scenario 4 System A Update on System B Files. System A handles the file access An update transaction initiated by System A, has as its primary intent the update of data in File Y in System B. System A has all the functionality required to directly access and update the File Y. System A may display error/confirmation messages on a screen Scenario 4 Resolution Transactions System A has all the necessary functionality to deliver the complete update function. System A counts one EI. There is no messaging between the two applications Files There is only one file involved. System A counts the File Y as an ILF. System B counts the File Y as an ILF as it is assumed that it also has a maintenance function that updates this file. Scenario 5 System A Update on File X requires validation/contribution of data from File Y. System B handles the File Y access An update transaction initiated by System A, has as its primary intent the update of data in File X. As part of the processing of the transaction, data from File Y in System B must be accessed for validation/contribution purposes. This results in a request for information sent by A to System B. System B accesses File Y and sends a response with the required data to System A. System A completes its processing and the File X is left in a consistent state. Scenario 5 Resolution Transactions Both System A and System B contribute to the update function. System A counts an EI. System B counts an EQ Neither system counts the messaging between the two applications i.e. the request and response messages. Files There two files involved. System A counts the File X as an ILF and the File Y as an EIF. System B counts the File Y as an ILF. Scenario 6 System A Update on File X requires validation/contribution of data from File Y. System A handles the File Y access An update transaction initiated by System A, has as its primary intent the update of data in File X. As part of the processing of the transaction, data from File Y in System B must be accessed for validation/contribution purposes. System A has all the functionality required to directly access the File Y. System A may display error/confirmation messages on a screen Scenario 6 Resolution Transactions System A has all the necessary functionality to deliver the complete update function. System A counts one EI. There is no messaging between the two applications Files There two files involved. System A counts the File X as an ILF and the File Y as an EIF. System B counts the File Y as an ILF as it is assumed that it also has a maintenance function which updates this file. Scenario 7 System A Enquiry on multiple System B Files. System B handles the file access An initial enquiry transaction (which could potentially result in multiple subsequent enquiries) is initiated by System A, and requires information from File Y and File Z in System B. This results in a request for information sent by A to System B. System B access File Y and File Z, 'gathers' all the required information to handle the initial and subsequent enquiries, and sends a response with the required data to System A. System A temporarily stores the data gathered from System B. System A displays the response data on a screen. Subsequent enquiries are satisfied by referencing the data stored in the temporary file. At the end of the Enquiry 'session' the data in the temporary file is cleared. Scenario 7 Resolution Transactions Both System A and System B contribute to the enquiry functions. System B counts one EQ. System A counts multiple EQ's Neither system counts the messaging between the two applications i.e. the request and response messages. Files There are three files involved. System B counts File Y and File Z as ILFs. System A counts File Y and File Z as EIFs. Neither system counts the temporary data storage file. An exception to this situation may occur when, in counting System A, the FP Analyst has no knowledge of the files in System B. If the temporary file is the only 'view;' that System A has of System B data, this temporary file represents the EIFs and is counted. Scenario 8 System A Update on File X triggers a subsequent update of File Y in System B. System A handles the File X access. System B handles the File Y access An update transaction initiated by System A, has as its primary intent the update of data in File X. As a consequence of this update, data in File Y in System B is also required to be updated. Once System A completes its processing, a control transaction is sent to System B to trigger the consequent update. System B updates File Y. Scenario 8 Resolution Transactions Both System A and System B count their unique EI transactions. System A counts an EO for the control transaction sent to System B. Files There two files involved. System A counts the File X as an ILF. System B counts the File Y as an ILF. Scenario 9 Two Order Files, two updates. This scenario differs considerable from those previously described. The scenario is described in detail in Section 3.3.5, Front-end Systems - Counting Guidelines. System A is a Front-end System that has screens available to enter update data. The ultimate purpose of the System A screens are to update data on System B files. The difference between this and the previous scenarios is that System A is required to store a copy of the transaction data sent to System B. For example, the sequence of events is as follows:
Scenario 9 Resolution Transactions System A counts:
System B counts:
Files There two files involved. System A counts the Order Transaction File as an ILF. System B counts the Order File as an ILF.
|
