Enhancement Function Points Estimation - EFP
Overview
As explained in Enhancement Measure page, CAST supports the Enhancement Function Points Estimation (EFP) technology specification to estimate the size of an application revision (alongside the default AEP measure).
After an initial baseline count, CAST Imaging catalogs and stores both Data Functions and Transactional Functions structure. All objects that are part of the Data and Transactional Functions are stored along with a checksum that uniquely identifies the current version of each artifact. When a new version of the application source code is analyzed, the Enhancement Function Points algorithm uses the computed checksum of each artifact composing both data functions and transactional functions to determine:
- Added Functions
- Modified Functions
- Deleted Functions
Then, each Added, Modified or Deleted data functions and transactional functions are weighted using OMG tables.
The EFP measure is considered a legacy measure and as such, as such the default AEP measure option is always set as the default.
Data & Transactional Functions
Data Functions
From the baseline Function Points, CAST catalogs and stores Data Functions and their structure. Via the default algorithm, Data Functions are usually based on SQL Tables. The algorithm groups SQL tables into Data Functions using both naming convention and primary key - foreign key relationships. Whenever the SQL tables do not use referential integrity based on primary key - foreign key relationships or do not use any naming convention, then each table will be counted as one data function by the algorithm.
However, when the application uses both primary key - foreign key relationships and naming convention, the algorithm groups tables in a way that is very similar to the identification of Master-Details tables.
Each Data Function is uniquely identified by CAST through its Master table and the Master table will be used to determine Added and Deleted Functions. In the image below, the master table is the “Sales” SQL table:
Transactional Functions
From the baseline Function Points, CAST catalogs and stores Transactional Functions and their structure. Via the default algorithm, Transactional Functions are identified using an impact analysis algorithm that searches, starting from the transaction entry point and using the artifact dependencies, all the data functions used directly or indirectly by the transaction entry point.
CAST identifies the transaction entry points as well as all the technical objects used to implement the data processing:
Each Transactional Function or transaction is uniquely identified by CAST through its transaction entry point. Transaction entry points are usually the default user forms as defined in each programming language or can be chosen manually.
The transaction entry point will be used to determine Added and Deleted Functions. In the screenshot below, the transaction entry point is the PowerBuilder window called w\_gui\_newsale:
Added Data & Transactional Functions
Based on the identification of the differences between two application versions, the Enhancement Function Points algorithm identifies the data entities that have a new master table as added data functions. Similarly, the Enhancement Function Points algorithm identifies the transactions that have a new transaction entry point as added transactional functions. The master table and transaction entry point are considered as new whenever these artifacts did not exist in the previous application version with the same name, type and full qualified name.
Deleted Data & Transactional Functions
Based on the identification of the differences between 2 application versions, the Enhancement Function Points algorithm identifies, as deleted data functions, the data entity’s master table that no longer exist in the new application version analyzed. Similarly, the Enhancement Function Points algorithm identifies the transactions whose entry point no longer exists in the new application version analyzed as deleted transactional functions. The master table and transaction entry point are considered as no longer existing whenever these artifacts do not exist in the new application version with the same name, type and full qualified name.
Modified Data & Transactional Functions
Enhancement Function Points algorithm identification of the modified data and transactional functions is based on the structure, the objects and dependencies, of each data entity and transaction.
A Data Function is considered as modified if at least one of the SQL tables has been modified. An SQL table is modified if columns have been added or modified by a change of the name of the column or its type. The changes of the indexes are not considered as functional changes and, as such, a table that has an index change is not considered as modified.
A Transactional Function is considered as modified if its entry point, the data functions it uses, and/or any of the code elements used or called along the transaction are changed. As part of the transaction, CAST integrates all components the transaction uses including technical shared components. One should be especially cautious with shared technical components — when such shared components are modified, many transactions that rely on them will be identified by the CAST algorithm as changed.
Entry points and code elements are detected by the source code analyzers as changed if their signature is changed and/or their source code is changed. A change of the comments or blank lines is not taken into account.
Here is an example of a transactional function from an Oracle application. In this case, the stored procedure XFACE\_CONTROL\_PKG.BUILD\_TLIST that embeds several SQL queries is detected as modified: the transaction it belongs to will then be considered as modified:
As a consequence, if the stored procedure XFACE\_CONTROL\_PKG.BUILD\_TLIST is used in several transactional functions then these transactional functions will also be considered as modified, following the change in behavior of the stored procedure.
Another example of a transactional function from a J2EE & Oracle application with several layers written in different languages: An enhancement in such environment might be implemented in any of the layers — Presentation, Coordination, Business and Data Access — as well as the database itself. The Entry Point of the transaction is the JSP page called pageEnterPhone.jsp while the coordination layer is implemented using several Struts artifacts and the business layer is implemented through several Java classes. Changes of one of these JSP files, methods, or stored procedures will result in CAST Enhancement Function Points classifying the transaction as modified.
Weighting and Final Calculation
Enhancement Function Points generates Unadjusted Function Points. The calculation of the weight of the data functions and transactional functions is based on OMG-compliant Automated Function Points tables. The official OMG-compliant Automated Function Points formula for the Enhancement Function Points is as follows:
EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL * VAFB)
Where:
- EFP is the enhancement project function point count.
- ADD is the unadjusted function point count of those functions that were added by the enhancement project.
- CHGA is the unadjusted function point count of those functions that were modified by the enhancement project.
- CFP is the function point count added by the conversion.
- VAFA is the value adjustment factor of the application after the enhancement project.
- DEL is the unadjusted function point count of those functions that were deleted by the enhancement project. It is important to consider the absolute value of the deleted FP cannot have a negative value.
- VAFB is the value adjustment factor of the application before the enhancement project.
CAST generates the ADD, CHGA and DEL numbers using the OMG-compliant Automated Function Points tables below.
ILF Weighting Table
The weight and the associated number of function points of each internal data function (ILF) is given by the following table (DET stands for Data Element Type and RET stands for Record Element Type):
| 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 |
ILF vs EIF Function Points
A similar table is available for EIF. The number of function points differs slightly for Internal (ILF) and External (EIF) data functions:
| Internal (ILF) | External (EIF) | |
|---|---|---|
| Low | 7 FP | 5 FP |
| Average | 10 FP | 7 FP |
| High | 15 FP | 10 FP |
EI Weighting Table
For transactional functions, CAST also uses 2 OMG-compliant Automated Function Points tables as a computer-based algorithm cannot judge the primary intent of a GUI or a transaction. The weight and the associated number of function points of each transactional function is then given by the following table (this one is for EI):
| 1 to 4 DET | 5 to 15 DET | 16 or more DET | |
|---|---|---|---|
| 0 or 1 FTR | Low = 3 FP | Low = 3 FP | Average = 4 FP |
| 2 FTR | Low = 3 FP | Average = 4 FP | High = 6 FP |
| 2 or more FTR | Average = 4 FP | High = 6 FP | High = 6 FP |
EI, EO, and EQ Function Points
Similar tables are available for EO and EQ. The number of function points differs slightly for each type of transactional function:
| EI | EO | EQ | |
|---|---|---|---|
| Low | 3 FP | 4 FP | 3 FP |
| Average | 4 FP | 5 FP | 4 FP |
| High | 6 FP | 7 FP | 6 FP |
CAST conservatively uses the External Output (EO) table.