Unadjusted Data Functions

Overview

A detailed explanation of Unadjusted Data Functions.

Estimation Process for Data Functions

The Unadjusted Data Functions metric for an application is computed as follows:

Identification of the Data Entities (group tables forming an Entities)
Compute Record Element Types (RET) and Data Element Types (DET) for each Entity (~ number of tables, ~ number of non-redundant columns),
Compute Function Points for each Entity
Compute Unadjusted Data Functions (the sum of all Entities Function Points).

The main case development below is for SQL databases and Mainframe IMS databases.

Step 1 - Identify the Data Entities

The estimation engine identifies data entities (OMG-compliant Automated Function Point ILF and EIF) by grouping Master-Details tables based on their foreign key relationships and their naming convention (a group of Master-Details tables is a Data Entity – OMG-compliant Automated Function Point ILF), eventually using configuration data (see below Configuration - Database Tables Prefixes).

For a given table A, the engine searches attached tables, i.e. having a (1,1)-(x,x) with the table A (called the Master). If the attached tables share a naming convention with the table A (called the Master), the attached tables are set to be the Details table of the Master table. A Master table shares a naming convention with its Detail table if the first 4 characters of the Master table name matches any part of the Detail table name.

As explained below it is possible to configure Table Prefixes for a database schema. A table prefix is a set of characters that are systematically added at beginning of table names like T_ or SYS_ or APP_. Whenever prefixes are defined for a schema, the prefix is removed from table names before the check of naming convention.

As an example, for tables called T_SALES and T_SALESDETAILS and a prefix set by configuration to T_, the naming convention check will be done on SALES and SALESDETAILS.

For a database schema, the result is a list of Data Entities each one being composed of one master table and 0 or more Detail tables.

Step 2 - Compute RET and DET for each Entity

RET = Record Element Types:

= Number of tables belonging to the data entity
= 1 + number of detail tables.
Or = number of IMS segments
Or = 1 for GSAM/VSAM data files.

DET = Data Element Types

= Number of non-redundant columns for all tables of the data entities (redundant columns are columns with same names).

Step 3 - Compute Function Points for each Entity

Unadjusted Data Functions = Sum of (Data Entities FP). There are 2 modes used to compute Function Points for Data Entities:

The basic mode assumes that all entities are ILF (Internal Logical File). It is used whenever the source analyzer used can not identify Insert, Update, Select, Delete statements.
The Advanced mode identifies ILF (Internal Logical File) and EIF (External Interface File). To do so, CAST uses the information from the source analyzer that describe the action made on the tables or data files: Insert, Update, Select, Delete statements or Read/Write. “ILF are group of data maintained through an elementary process within the application boundary being counted.” Maintained means the data are created, deleted, updated within the application. The Advanced Mode works as follows:

Data Functions:

The goal is to differentiate ILF & EIF using I,U,S,D Link Information. Any Data Entity that has one of the following characteristic will be identified as an ILF:

At least one table is inserted, deleted or updated,
At least one file is written.

Other Data Entities will be identified as EIF. The ILF OMG-compliant Automated Function Points is computed as follows:

	1 to 19 DET	20 to 50 DET	51 or more DET
0 or 1 RET	Low = 7 FP	Low = 7 FP	Average = 10 FP
2 - 5 RET	Low = 7 FP	Average = 10 FP	High = 15 FP
6 or more RET	Average = 10 FP	High = 15 FP	High = 15 FP

The EIF OMG-compliant Automated Function Points is computed as follows:

	1 to 19 DET	20 to 50 DET	51 or more DET
0 or 1 RET	Low = 5 FP	Low = 5 FP	Average = 7 FP
2 - 5 RET	Low = 5 FP	Average = 7 FP	High = 10 FP
6 or more RET	Average = 7 FP	High = 10 FP	High = 10 FP

Step 4 - Compute Unadjusted Data Functions (sum of all Entities Function Points)

Unadjusted Data Functions = Sum of (Function Points of all Data Entities)

Example

As an example, the image below shows a Data Entity. The tables that are part of Data Entity are identified by retrieving all tables that have Primary Key – Foreign Key relationship with the table called SALES (master table). Then within this set of tables, the engine identifies SALESDETAIL to be part of the data entity because it shares a naming convention with the SALESDETAIL table.

Example - SALES data function (ILF):

In the following example, the result of the counting will be 7 FP:

RET = 2 and DET = 6
Weight is Low
Results = 7 Function Points

RET = 2 because there are 2 tables and DET = 6 because there are 8 columns minus 2 redundant columns STOR_ID & ORD_NUM.

Assumptions

The Data Function count is based on the following assumptions:

The Estimation method considers all data functions as Internal Logical Files (ILF). So it weights the External Logical Files (EIF) the same manner as the internal ones.
This approximation is based on the ISBSG statistics (International Software Benchmarking Standards Group http://www.isbsg.org/ ).
The ISBSG statistics show that within a given application the External Logical Files (EIF = Read-Only) account for 5% of the application Function Points size whereas Internal Logical Files (ILF = Read-Write) account for 22%. Given the small difference in weight compared to the proportions of ILF/EIF, this approximation is acceptable.
It is also assumed that all table’s columns are user recognizable (all DET).

Calibration

You can use CAST Imaging to calibrate the Function Points Counting and take into account specific technical implementations, naming conventions or to filter technical or temporary tables.

Excluding Technical Items

You can exclude technical elements before or after the Function Points estimation is executed. Users usually exclude the temporary, template and auditing trail data based on naming convention or inheritance. Here are examples of such typical excluded naming conventions:

TEMP, SESSION, ERROR, SEARCH, LOGIN, LOGON, FILTER (Temporary data),
TEMPLATE, TEMPLATE (Template data), HISTORY,
_OLD, AUDIT (Auditing data).

A set of default “excluded” items is provided by default:

User Configuration - Database Table Prefixes

In order to increase the accuracy of the algorithm, it is possible to take into account technical naming conventions, table prefixes, when the algorithm groups several SQL Tables into data entities. A table prefix is a set of characters that are systematically added at beginning of table names like T_ or SYS_ or APP_. It is possible to configure several Table Prefixes for a given database/schema, so that the Data Function Algorithm removes the prefixes from table names before trying to group together several SQL Tables into one data entity:

User Configuration - Data Entities

In order to increase the accuracy of the algorithm, it is possible to take into account technical naming convention and base class inheritance to identify Data Entities other than RDBMS defaults. So by configuration, it is possible for the user to provide a rule to automatically select Data Entities of a given application (so the list of the Data Entities is made available to the Estimation engine). By configuration, the selection of the Data Entities of a module is done using the following type of rules:

By naming (selection of an Object Type + a naming convention)
By inheritance (name of an Object, then all the objects that inherit directly or indirectly from that object)
By type (selection of an Object Type)
Free Definition (define more complex criteria for detecting objects that you want to include in the Function Point Calibration process via the creation of sets)

A predefined set of Data Entities is provided in the “Built-in parameters node”.