Home
ISSUE
What are the characteristics of Logical Files that are classified as Reference Tables? Are Translation tables considered to be Reference Tables?
BACKGROUND
The following discussion and proposed resolution are based upon the premise that the type of logical file, ie EIF or ILF, has already been determined using the guidelines in Section 3.4.3, ILF and EIF Identification and Counting Guidelines and Section 3.4.6, Reference Tables Maintained via Utility Software.
In identifying FPA logical files a useful distinction is made between:
- Master Business Data
- Reference Data
- Codes Data
Master data and Reference data are counted as separate FPA logical files but Codes data is not counted as separate files. (See Section 3.4.8 Codes Tables/Look-up Tables - Identification and Counting Guidelines.)
Another type of file/table that may exist within a system, and exhibits similar characteristics to Reference data is classified as a Rule File. The purpose of these files is to define the processing/navigation/validation rules for business transactions. Developers have implemented these parameter tables to simplify their transaction "builds". Each record in one of these tables defines the underlying processing for a business transaction that is counted in its own right. The business user of the system may, or may not be aware of the existence of the Rule tables. It is recommended that 'hidden' Rules Tables are not counted but Reference Tables are.
These distinctions emphasise the importance of clear guidelines for identifying Reference Table logical files. Issues to be addressed include: - What are the characteristics of Logical Files that are classified as Reference tables?
- Can a Reference table exist to support implementation strategies alone?
- How can a Reference table be distinguished from a Rule table?
- Should hard coded reference data be counted?
- Should Translation tables that are used during data loads be counted as Reference tables or Rule tables?
GENERAL DISCUSSION AND RESOLUTION
Identification of Reference Tables Compare the file under investigation with the characteristics defined in the table below and determine whether the logical file is a Reference table or a Rule table. In cases where the distinction remains unclear, the default position is to count the file as a Reference Table. By definition, a reference table that exists to support implementation strategies alone should not be counted. These are not expected to be a common occurrence. Hardcoded Reference Tables It is recognised that reference table data may sometimes be hardcoded within programs. The recommended counting standards discourage the perusal of pseudo code and source code to identify business functions and function complexity. This recommendation is made to:
- support the logical, rather than physical view of business functionality, and
- facilitate efficient counting.
As a result, it is possible that hardcoded reference data may not be recognised by the FP Analyst. It is therefore recommended that hardcoded reference data not be counted as FPA logical files. Any changes to this data will require changes at the source code level and will therefore be counted as changes to the relevant business transaction. This approach conflicts with FPA guidelines to disregard implementation strategies; however, a pragmatic and cost effective approach needs to be taken in this case. It also facilitates correlation of effort to function point count results. Hardcoded reference tables are a rare occurrence and it is not expected that this decision will have a major impact on function point counts. Translation Tables Translation tables that exist to support data load functions satisfy the majority of Reference table characteristics and are counted as Reference tables and therefore as FTR's for the transactions which reference them. Where tables exist which translate codes, and other data, as part of transaction processing, count one translation table per system if the physical files referenced, to translate the data, are not already being counted as Reference Tables because of the existence of additional attributes. Count one Translation Table per system regardless of how many such tables exist, if they all have the same logical attributes. The table potentially has six DETs.
- Code Type
- System From
- Code Value From
- System To
- Code Value To
- Date Effective
Do not count maintenance functions on this table unless they really exist.
The characteristics of Reference tables and Rule tables are best contrasted in the following table:
REFERENCE TABLE |
RULE TABLE |
|
Exists within the User Domain
- Recognised and specified by the user
- Maintained by the user or at the request of the user
- Mandatory to the business
|
Exists in the Developer Domain:
- User may not be aware of the existence of the Rule table
- Table is usually maintained by the developer
|
|
Does not exist in order to:
- optimise data storage
- maximise processing performance
- improve software delivery productivity
|
Exist in order to:
- improve software delivery productivity
|
|
Exists to support Master Transaction Processing
- Supports users business activities
- Defines valid values for Master Data Fields
- Provide values for Master Data calculations
|
Defines Master Transaction Processing
- Defines validation checks. For example
- default values
- threshold values
- allowable field combinations
- Defines processing sequences
- Defines algorithms, calculations
- Defines navigation rules
|
|
Records in the file do not reference a particular business transaction. Records may be used by multiple business transactions
|
Transaction Id is a key field in a Rule Table record. Table records are referenced by one business transaction only
|
|
Information in the table exists in its own right. Would have business meaning regardless of the existence of master business transactions
|
Information in the table exists only in the context of the master business transactions
|
|
Attribute values are updated independently of changes to business transactions
|
Attribute values are updated in response to changes in business transaction processing
|
|
