Home
ISSUE
When should data sourced from another system, which contributes to the update of internal logical files of the system being counted, be classified as an:
External Interface File
Internal Logical File
External Input transaction?
This section has been included to summarise a number of data transfer scenarios, commonly encountered. Some of the issues have already been addressed in other sections in this document. They are repeated and summarised in this section primarily to provide an easy comparison of different EIF scenarios and the resolutions of the counting issues relevant to the scenario.
To simplify the descriptions the following terms have been used
|
System A
|
The source system for the reference/transaction data being transferred.
|
|
System B
|
The receiving system for the reference/transaction data being transferred.
|
|
File X
|
System A ILF
|
|
File X'
|
System B ILF A subset or superset of the File X data. Similar but not identical. Uniqueness criteria have been established.
|
|
File Y
|
System B ILF
|
|
File Z
|
The data transfer file. This file is generated by System A and read by System B
|
In each example it has been established that an application boundary exists between System A and System B.
FUNCTIONAL OVERVIEW
Data used by elementary processes to maintain records on an Internal Logical File within an application may originate from a number of different sources:
- External non-system sources.
Sourced from external manual procedures and entered by system users via on-line screens.
- Other computer systems:
- via transferred files
- via direct on-line real-time information requests
- The system itself.
- Data from internal reference files may contribute to a master business transaction.
- Stored data may be used to generate new data that must be stored (and cannot be re-created at a future time).
The following Sample Scenarios, focus on the situation where the data required to complete elementary processes within System B, is sourced from another system/s, System A. Counting guidelines for the other two data information sources i.e. external non computer system sources, and System B itself, are adequately covered by the IFPUG Release 4.1 Counting Guidelines.
- Sample Scenarios
Scenario 1 Data Load, No Logical Processing of Loaded Data System A produces an extract File Z of records that are loaded into the System B. System B does not process the input data. It is copied directly into physical table, System B File X. The DETs on both Files X are identical. The records on the transfer File Z are of one type only and typically the attributes are the same as for File X. Scenario 1 Resolution This data transfer is a technical solution devised to satisfy the business requirement that System B should have access, for data retrieval purposes, to the System A File X. Transactions The data transfer transactions: System A download, and System B Load, are part of the technical solution and are not counted to either system. In reality, when counting System A in isolation, it may not be apparent to the FP Analyst that this is a technical transaction, and it may be counted as an EO/EQ. Files There is only one file involved. System A counts File X as an ILF. System B counts its copied version of File X as an EIF. Neither system counts File Z as a logical file. Scenario 2 Data Load, Includes Logical Processing of Loaded Data System A produces an extract File Z of records that are loaded into System B. The records are usually of one type only. System B processes the input data prior to storing it on internal File X'. The DETs on System A File X, and System B File X', are different. Load processing may include:
- data extraction
- conversion or translation of values
- validation
- derivation of new values
aggregation of values.
Scenario 2 Resolution
This data transfer is a user business requirement. Both System A and B have a requirement to access a version of the File X however the DETs on the two files are different.
Transactions
The data transfer transactions: System A download, and System B Load, are counted to the respective systems. Files There are two files involved. System A counts File X as an ILF. System B counts File X' as an ILF. Neither system counts File Z as a logical file. Scenario 3 File Update, Transaction Data Generated by Source System System A produces a transaction File Z of record 'changes' that are loaded into System B. The records are usually of more than one type. System B processes the input transactions according to the transaction type on the File Z records, prior to updating the records on internal File X'. The DETs on System A File X, and System B File X', are different. For example File X may be a Master Material Catalogue while File X' is a local Product List. Load processing may include the following transaction types:
Alternatively the transaction types may trigger different types of processing, for example the rating of different call types received on exchange Call Event Records.
Scenario 3 Resolution
This data transfer is a user business requirement. Both System A and B have a requirement to access a version of the File X however the DETs on the two files are different. System A transfers to System B, data related to changes only. System B reads the records on File Z and based upon the transaction type initiates different logical processing Transactions System A download transactions are counted as either one, or multiple, EO/EQ functions. For multiple functions, different logical processing must be demonstrated. If every record written by System A to the File Z is processed in the same way only one EO/EQ is counted. System B counts as EI's each unique maintenance function on File X'. The number of Transaction Types on the transaction File Z, usually determines the number of these functions, but this is not necessarily the case. Different logical processing must be demonstrated. Files There are two files involved. System A counts File X as an ILF. System B counts File X' as an ILF. Neither system counts File Z as a logical file. Scenario 4 File Update, Transaction Data Generated by Updating System System B has a requirement to update records on its internal File X'. File X in System A stores the most current version of the data required by X'. System B reads System A File X, compares the records to records on its own file X' and generates a 'changes' File Z. File Z transactions are then processed by System B and File X' is updated. Load processing may include the following transaction types:
Scenario 4 Resolution This file update is a user business requirement. System B performs all the functions required to facilitate the update. Transactions There are no transaction functions to count for System A. System B counts as EI's each unique maintenance function on File X'. . Files There are two files involved. System A counts File X as an ILF. System B counts File X' as an ILF and File X as an EIF. Neither system counts transaction File Z as a logical file.
GENERAL DISCUSSION AND RESOLUTION
Note: An associated counting issue is Section 3.4.3 ILF and EIF - Identification and Counting Guidelines
The resolutions to the different scenarios seek to avoid a situation where EIFs are double counted. For example:
- A file is counted as both an EIF and External Input transactions.
- A file is counted as both an EIF and an ILF.
-
|
