Home
ISSUE
When reference data is sourced from another system but physically resides within the boundary of an application should it be counted as an ILF or EIF?
FUNCTIONAL OVERVIEW
This situation most commonly occurs with files that are classified as Reference Data.
There is a valid business requirement for the Reference Data to be accessed by both the source and receiving application, and potentially other applications also. The source application is the owner of the reference data and therefore has primary responsibility for maintaining this data. The data is physically loaded into the receiving application, and transactions in this application reference this physical file.
GENERAL DISCUSSION AND RESOLUTION
The Reference Table file is always counted as an ILF by the source application. The Reference Table file in the receiving application may be counted as either an ILF or EIF depending on the particular combination of the following factors:
- The data content of the files on the source and receiving systems
- The content of the data transfer file that is passed from the source to the receiving system to update it
- The nature of the table load/update processing in the receiving system
- The requirement to reference other files within the receiving system as part of the load/update processing.
These characteristics are explored in the following table:
CHARACTERISTIC |
EIF |
ILF |
|
Data content of 'Source' and 'Receiving' files
|
- Data attributes and values identical and required to be so.
|
Data attributes of 'receiving' file are a subset or a super set of the 'source' file.
Data values may differ for example, expanded fields descriptions, translated code values.
|
|
Data content of Transfer file
|
- Update records are of one type only.
- All sites receive exactly the same data.
|
Records are of more than one type and contain a record/transaction type.
Individual sites may receive site specific maintenance records.
|
|
Table Load Processing
|
- Simple copy/load process of all records.
- May involve minor reformatting of data. Reformatting is a requirement of technical platform differences (e.g. Different DBMS).
|
Load processing may involve validation, data extraction, translation of data values, reformatting, aggregation, comparison to existing records to derive update transactions or new fields.
|
CHARACTERISTIC |
EIF |
ILF |
|
Reference to other data during processing
|
- Load process overwrites existing records without referencing the records. All existing records are overwritten.
- Table records are changed without reference to any other 'receiving' system files.
|
Load process references existing records to identify those impacted by the update.
In the process of updating table records, other 'receiving' system files are referenced to validate the change or assess the impact of the change. For example, products cannot be deleted if there are outstanding orders for them.
|
For the Reference Table under review, assess each of these characteristics using the guidelines for the data function types. Assign type (ILF or EIF) based on the best profile match for the Reference Table.
Based upon the determination of file type, count the following functions for the source and receiving systems (assuming both these systems are being function point counted).
DATA FUNCTION TYPE |
SOURCE SYSTEM |
RECEIVING SYSTEM |
|
External Interface File
|
Count: - 1 ILF for the 'source' file.
Do not count: - Download function which transfers data between 'source' and 'receiving' systems
Note: Where the source system is unaware of how the download will be used by receiving systems, an EO will usually be counted.
|
Count: - 1 EIF for the 'source' file that is being referenced.
- The EIF as an FTR on all transactions that reference the data.
Do not count: - Upload/Copy function that copies data into the 'receiving' system file.
- Transfer file
|
|
Internal Logical File
|
Count: - 1 ILF for the 'source' file.
- 1 or more EOs for the transactions passed to the receiving system via the transfer file. Check for unique logical processing.
|
Count: - 1 ILF for the 'receiving' system file.
- 1 or more EIs for the processes that load the 'receiving' file records. Check for unique logical processing of record types.
- ILFs/EIFs for any translation/reference tables that are accessed in the load process.
- The Reference Table ILF as an FTR on all transactions that reference the data.
|
Further References - Issue External Interface Files - Sample Scenarios
This description addresses the same issue from a different perspective.
|
