| Home
ISSUE
In certain systems, processing rules are defined in Rule tables rather than in source code. How should the functionality of such systems be counted in the baseline? How should enhancements to systems that are mainly table driven be counted?
FUNCTIONAL OVERVIEW Most table-driven systems share the following characteristics: - Processing (e.g. validation, editing, algorithms, calculations) and/or navigation, existence or creation rules are defined in Rule tables rather than built into source code.
- The design approach has been adopted to facilitate future changed business requirements. These changes may need to be implemented quickly, in response to a dynamic business environment. Alternatively, the system designer has recognised the productivity gains that may be made on future enhancement projects by adopting a table driven approach.
- The records within the Rule Tables usually identify the business transactions to which the rules apply.
- The attributes of the Rule tables will differ depending upon the type of Rule being defined. They may include:
- the order in which Common Use Modules (CUM) are to be called.
- allowable default or threshold values for fields.
- formulas for calculations.
For example, the formula to calculate PAYG tax may vary depending upon particular threshold values.
- navigation paths through particular processes.
- rules which allow existence in an occurrence entity depending upon existence in a rule entity.
For example, Product Compatibility rules.
- The business user of the system may or may not be aware of the existence of the Rule tables. Within the Functional Specification the business user may have stated a general requirement that the system should be responsive to dynamic changes within the business environment but it is unlikely that the business user has specifically requested the Rule tables.
- The Rule Tables differ from Reference Tables primarily because :
- the information within the tables lies in the domain of the developer and not the business user.
- the 'rules' within a table are aligned with particular master business transactions.
Refer also to Section 3.4.7 Reference Tables - Identification Guidelines.
GENERAL DISCUSSION AND RESOLUTION
The major FPA issue associated with table driven systems relates to the fact that: BUSINESS VIEW OF DELIVERED FUNCTIONS ¹ DEVELOPER VIEW OF BUILT FUNCTIONS
The business user identifies the system transactions as the functionality delivered, whereas, the developer identifies the Rule table and associated maintenance transactions as the functionality developed. In FPA terms both the Business and the Developer View of functionality delivered can be counted. However, the two views cannot be combined within the one Function Point Count. In most organisations, the Business View is adopted when counting table-driven system, as this view supports the business purpose for counting. Note: There are two exceptions to this rule. They are: - Where the table-driven system is a Robot application. See Section 3.3.4, Robots, File Transfer Systems - Counting Guidelines.
- Where what the developer builds and delivers to the user are the rule tables and associated maintenance functions. The user is provided with the ability to generate their own functions. The developer has no visibility of how the system is used from a business perspective.
The majority of development work undertaken in organisations relates to Enhancement activity. Users are more likely to specify adds, changes and deletes to business transactions that they recognise, than to Rule tables that they may or may not recognise.
The following counting guidelines present a generic solution to the FPA issues related to Table Driven Systems. Note: The guidelines reference only situations that are particular to these types of systems. The application of all other standard FPA guidelines (e.g. uniqueness criteria, identification of ILFs etc.) is assumed. Files: Internal Logical Files - Where they exist, Rule Files that define the processing/navigation/validation rules for business transactions are not counted in the baseline count for table-driven systems. Developers have implemented these parameter tables to simplify their transaction 'builds'. Each record in one of these tables defines the underlying processing (i.e. validation, navigation, calculation etc.) for business transactions which should be counted in their own right.
Note: One business transaction may have its processing specified in multiple Rule Tables.
- For table-driven systems, any enhancements to the Rule Files are counted as changes to the underlying processing for the relevant Business Transaction.
- A new record added to one of the Rule files is counted as a new Business Transaction.
- A change to an existing record attribute value in a Rule file is counted as a change to the Business Transaction that uses that attribute.
- An addition or change to a Rule file attribute is counted as a change to all Business Transactions that use that attribute.
Transactions: External Inputs - Where they exist, External Inputs that are Business transactions are counted as EIs for table-driven systems.
Note: The processing rules for these Business Transactions may be defined in Rule Tables and/or built into underlying source code. Do not count the maintenance transactions on the Rule files as EIs for the system. If the Rule files are not counted as ILFs the maintenance transactions on these files obviously cannot be counted either. - For baseline counts, count as per the standard FPA guidelines. For Enhancement Project Counts changes to Rule Tables are counted as changes to the specific Business Transactions that are impacted by the rule changes.
Transactions: External Outputs/External Enquiries - Where they exist, External Outputs/Enquiries that are Business transactions are counted as EOs/EQs for table-driven systems.
Note: The processing rules for these Business Transactions may be defined in Rule Tables and/or built into underlying source code. Do not count the List/Query transactions on the Rule files as EQs for the system.If the Rule files are not counted as ILFs the 'reporting' transactions on these files obviously cannot be counted either. - For Application Baseline Function Point Counts count as per the standard FPA guidelines. For Enhancement Project Counts changes to Rule Tables are counted as changes to the specific Business Transactions that are impacted by the rule changes.
Discussion of Advantages and Disadvantages of the Counting Approach Adopting the above approach has a number of advantages and disadvantages. These are listed below to assist FPA FP Analysts in understanding the resolution that has been adopted.
Advantages
- The FPA technique is intended to be independent of implementation strategies. Table-driven systems are clearly a design approach that may or may not be linked to a stated business user requirement that the system should be responsive to dynamic changes within the business environment.
- User Work Orders (Enhancements) that specify changes to underlying processing for business transactions will result in delivered Function Points. This reflects both the business user and developer view of what constitutes an enhancement to the system.
- If this approach were not adopted many business user recognised enhancement projects would result in the delivery of zero function points. This would not be of use to developers.
Disadvantages
- The Business view of delivered functionality does not reflect the Developer view of built functionality. In most organisations the FPA FP Analysts are developers and they may find it difficult to distinguish between the "What" and "How" of business functions. A paradigm shift needs to be made.
- Developers may object to having zero function points attributed to files and transactions that they clearly built and maintain. A further consequence of this is that because the Rule tables do not exist (from an FPA viewpoint), any enhancements to these tables and associated maintenance transactions will also not be attributed function points. (In practice developers usually want to combine the Business view and the Developer View in order to maximise function points.)
- It is difficult to establish clear guidelines between what is a Rule table (which is assigned zero function points) and a Reference table (to which function points are assigned). The table below is reproduced from Section 3.4.7, Reference Tables - Identification Guidelines, to assist FP Analysts in making this determination.
- Counting the Business view for table-driven systems has implications for productivity analysis. Enhancement Projects for these types of systems tend to deliver very high productivity. Due to the existence of Rule tables, the delivery of new and changed business transactions does not involve significant building/coding effort. Function Points are delivered with minimal developer effort.
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 business user
- Maintained by the user or at the request of the business user
- Mandatory to the business
|
Exists in the Developer Domain:
- Business 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
- Define processing sequences
- Define algorithms, calculations
- Define 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
|
|
