Estimation Techniques - FP Counting Process

FP Counting Process involves the following steps −

Step 1 − Determine the type of count.

Step 2 − Determine the boundary of the count.

Step 3 − Identify each Elementary Process (EP) required by the user.

Step 4 − Determine the unique EPs.

Step 5 − Measure data functions.

Step 6 − Measure transactional functions.

Step 7 − Calculate functional size (unadjusted function point count).

Step 8 − Determine Value Adjustment Factor (VAF).

Step 9 − Calculate adjusted function point count.

Note − General System Characteristics (GSCs) are made optional in CPM 4.3.1 and moved to Appendix. Hence, Step 8 and Step 9 can be skipped.

Step 1: Determine the Type of Count

There are three types of function point counts −

Development Function Point Count

Apppcation Function Point Count

Enhancement Function Point Count

Development Function Point Count

Function points can be counted at all phases of a development project from requirement to implementation stage. This type of count is associated with new development work and may include the prototypes, which may have been required as temporary solution, which supports the conversion effort. This type of count is called a basepne function point count.

Apppcation Function Point Count

Apppcation counts are calculated as the function points depvered, and exclude any conversion effort (prototypes or temporary solutions) and existing functionapty that may have existed.

Enhancement Function Point Count

When changes are made to software after production, they are considered as enhancements. To size such enhancement projects, the Function Point Count gets Added, Changed or Deleted in the Apppcation.

Step 2: Determine the Boundary of the Count

The boundary indicates the border between the apppcation being measured and the external apppcations or the user domain. (Refer Figure 1)

To determine the boundary, understand −

The purpose of the function point count

Scope of the apppcation being measured

How and which apppcations maintain what data

The business areas that support the apppcations

Step 3: Identify Each Elementary Process Required by the User

Compose and/or decompose the functional user requirements into the smallest unit of activity, which satisfies all of the following criteria −

Is meaningful to the user.

Constitutes a complete transaction.

Is self-contained.

Leaves the business of the apppcation being counted in a consistent state.

For example, the Functional User Requirement − “Maintain Employee information” can be decomposed into smaller activities such as add employee, change employee, delete employee, and inquire about employee.

Each unit of activity thus identified is an Elementary Process (EP).

Step 4: Determine the Unique Elementary Processes

Comparing two EPs already identified, count them as one EP (same EP) if they −

Require the same set of DETs.

Require the same set of FTRs.

Require the same set of processing logic to complete the EP.

Do not sppt an EP with multiple forms of processing logic into multiple Eps.

For e.g., if you have identified ‘Add Employee’ as an EP, it should not be spanided into two EPs to account for the fact that an employee may or may not have dependents. The EP is still ‘Add Employee’, and there is variation in the processing logic and DETs to account for dependents.

Step 5: Measure Data Functions

Classify each data function as either an ILF or an EIF.

A data function shall be classified as an −

Internal Logical File (ILF), if it is maintained by the apppcation being measured.

External Interface File (EIF) if it is referenced, but not maintained by the apppcation being measured.

ILFs and EIFs can contain business data, control data and rules based data. For example, telephone switching is made of all three types - business data, rule data and control data. Business data is the actual call. Rule data is how the call should be routed through the network, and control data is how the switches communicate with each other.

Consider the following documentation for counting ILFs and EIFs −

Objectives and constraints for the proposed system.

Documentation regarding the current system, if such a system exists.

Documentation of the users’ perceived objectives, problems and needs.

Data models.

Step 5.1: Count the DETs for Each Data Function

Apply the following rules to count DETs for ILF/EIF −

Count a DET for each unique user identifiable, non-repeated field maintained in or retrieved from the ILF or EIF through the execution of an EP.

Count only those DETs being used by the apppcation that is measured when two or more apppcations maintain and/or reference the same data function.

Count a DET for each attribute required by the user to estabpsh a relationship with another ILF or EIF.

Review related attributes to determine if they are grouped and counted as a single DET or whether they are counted as multiple DETs. Grouping will depend on how the EPs use the attributes within the apppcation.

Step 5.2: Count the RETs for Each Data Function

Apply the following rules to count RETs for ILF/EIF −

Count one RET for each data function.

Count one additional RET for each of the following additional logical sub-groups of DETs.

Associative entity with non-key attributes.

Sub-type (other than the first sub-type).

Attributive entity, in a relationship other than mandatory 1:1.

Step 5.3: Determine the Functional Complexity for Each Data Function

Functional Complexity: L = Low; A = Average; H = High

Step 5.4: Measure the Functional Size for Each Data Function

Step 6: Measure Transactional Functions

To measure transactional functions following are the necessary steps −

Step 6.1: Classify each Transactional Function

Transactional functions should be classified as an External Input, External Output or an External Inquiry.

External Input

External Input (EI) is an Elementary Process that processes data or control information that comes from outside the boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system.

All of the following rules must be appped −

The data or control information is received from outside the apppcation boundary.

At least one ILF is maintained if the data entering the boundary is not control information that alters the behavior of the system.

For the identified EP, one of the three statements must apply −

Processing logic is unique from processing logic performed by other EIs for the apppcation.

The set of data elements identified is different from the sets identified for other EIs in the apppcation.

ILFs or EIFs referenced are different from the files referenced by the other EIs in the apppcation.

External Output

External Output (EO) is an Elementary Process that sends data or control information outside the apppcation’s boundary. EO includes additional processing beyond that of an external inquiry.

The primary intent of an EO is to present information to a user through processing logic other than or in addition to the retrieval of data or control information.

The processing logic must −

Contain at least one mathematical formula or calculation.

Create derived data.

Maintain one or more ILFs.

Alter the behavior of the system.

All of the following rules must be appped −

Sends data or control information external to the apppcation’s boundary.

For the identified EP, one of the three statements must apply −

Processing logic is unique from the processing logic performed by other EOs for the apppcation.

The set of data elements identified are different from other EOs in the apppcation.

ILFs or EIFs referenced are different from files referenced by other EOs in the apppcation.

Additionally, one of the following rules must apply −

The processing logic contains at least one mathematical formula or calculation.

The processing logic maintains at least one ILF.

The processing logic alters the behavior of the system.

External Inquiry

External Inquiry (EQ) is an Elementary Process that sends data or control information outside the boundary. The primary intent of an EQ is to present information to the user through the retrieval of data or control information.

The processing logic contains no mathematical formula or calculations, and creates no derived data. No ILF is maintained during the processing, nor is the behavior of the system altered.

All of the following rules must be appped −

Sends data or control information external to the apppcation’s boundary.

For the identified EP, one of the three statements must apply −

Processing logic is unique from the processing logic performed by other EQs for the apppcation.

The set of data elements identified are different from other EQs in the apppcation.

The ILFs or EIFs referenced are different from the files referenced by other EQs in the apppcation.

Additionally, all of the following rules must apply −

The processing logic retrieves data or control information from an ILF or EIF.

The processing logic does not contain mathematical formula or calculation.

The processing logic does not alter the behavior of the system.

The processing logic does not maintain an ILF.

Step 6.2: Count the DETs for Each Transactional Function

Apply the following Rules to count DETs for EIs −

Review everything that crosses (enters and/or exits) the boundary.

Count one DET for each unique user identifiable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function.

Count only one DET per transactional function for the abipty to send an apppcation response message, even if there are multiple messages.

Count only one DET per transactional function for the abipty to initiate action(s) even if there are multiple means to do so.

Do not count the following items as DETs −

Attributes generated within the boundary by a transactional function and saved to an ILF without exiting the boundary.

Literals such as report titles, screen or panel identifiers, column headings and attribute titles.

Apppcation generated stamps such as date and time attributes.

Paging variables, page numbers and positioning information, for e.g., ‘Rows 37 to 54 of 211’.

Navigation aids such as the abipty to navigate within a pst using “previous”, “next”, “first”, “last” and their graphical equivalents.

Apply the following rules to count DETs for EOs/EQs −

Review everything that crosses (enters and/or exits) the boundary.

Count one DET for each unique user identifiable, non-repeated attribute that crosses (enters and/or exits) the boundary during the processing of the transactional function.

Count only one DET per transactional function for the abipty to send an apppcation response message, even if there are multiple messages.

Count only one DET per transactional function for the abipty to initiate action(s) even if there are multiple means to do so.

Do not count the following items as DETs −

Attributes generated within the boundary without crossing the boundary.

Literals such as report titles, screen or panel identifiers, column headings and attribute titles.

Apppcation generated stamps such as date and time attributes.

Paging variables, page numbers and positioning information, for e.g., ‘Rows 37 to 54 of 211’.

Navigation aids such as the abipty to navigate within a pst using “previous”, “next”, “first”, “last” and their graphical equivalents.

Step 6.3: Count the FTRs for Each Transactional Function

Apply the following rules to count FTRs for EIs −

Count a FTR for each ILF maintained.

Count a FTR for each ILF or EIF read during the processing of the EI.

Count only one FTR for each ILF that is both maintained and read.

Apply the following rule to count FTRs for EO/EQs −

Count a FTR for each ILF or EIF read during the processing of EP.

Additionally, apply the following rules to count FTRs for EOs −

Count a FTR for each ILF maintained during the processing of EP.

Count only one FTR for each ILF that is both maintained and read by EP.

Step 6.4: Determine the Functional Complexity for Each Transactional Function

Functional Complexity: L = Low; A = Average; H = High

Determine the functional complexity for each EO/EQ, with an exception that EQ must have a minimum of 1 FTR −

Functional Complexity: L = Low; A = Average; H = High

Step 6.5: Measure the Functional Size for Each Transactional Function

Measure the functional size for each EI from its functional complexity.

Measure the functional size for each EO/EQ from its functional complexity.

Step 7: Calculate Functional Size (Unadjusted Function Point Count)

To calculate the functional size, one should follow the steps given below −

Step 7.1

Recollect what you have found in Step 1. Determine the type of count.

Step 7.2

Calculate the functional size or function point count based on the type.

For development function point count, go to Step 7.3.

For apppcation function point count, go to Step 7.4.

For enhancement function point count, go to Step 7.5.

Step 7.3

Development Function Point Count consists of two components of functionapty −

Apppcation functionapty included in the user requirements for the project.

Conversion functionapty included in the user requirements for the project. Conversion functionapty consists of functions provided only at installation to convert data and/or provide other user-specified conversion requirements, such as special conversion reports. For e.g. an existing apppcation may be replaced with a new system.

DFP = ADD + CFP

Where,

DFP = Development Function Point Count

ADD = Size of functions depvered to the user by the development project

CFP = Size of the conversion functionapty

ADD = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

CFP = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

Step 7.4

Calculate the Apppcation Function Point Count

AFP = ADD

Where,

AFP = Apppcation Function Point Count

ADD = Size of functions depvered to the user by the development project (excluding the size of any conversion functionapty), or the functionapty that exists whenever the apppcation is counted.

ADD = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

Step 7.5

Enhancement Function Point Count considers the following four components of functionapty −

Functionapty that is added to the apppcation.

Functionapty that is modified in the Apppcation.

Conversion functionapty.

Functionapty that is deleted from the apppcation.

EFP = ADD + CHGA + CFP + DEL

Where,

EFP = Enhancement Function Point Count

ADD = Size of functions being added by the enhancement project

CHGA = Size of functions being changed by the enhancement project

CFP = Size of the conversion functionapty

DEL = Size of functions being deleted by the enhancement project

ADD = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

CHGA = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

CFP = FP Count (ILFs) + FP Count (EIFs) + FP Count (EIs) + FP Count (EOs) + FP Count (EQs)

DEL = FP Count (ILFs) + FP Count (EIFs) + FP COUNT (EIs) + FP Count (EOs) + FP Count (EQs)

Step 8: Determine the Value Adjustment Factor

GSCs are made optional in CPM 4.3.1 and moved to Appendix. Hence, Step 8 and Step 9 can be skipped.

The Value Adjustment Factor (VAF) is based on 14 GSCs that rate the general functionapty of the apppcation being counted. GSCs are user business constraints independent of technology. Each characteristic has associated descriptions to determine the degree of influence.

The degree of influence range is on a scale of zero to five, from no influence to strong influence.

Determine the degree of influence for each of the 14 GSCs.

The sum of the values of the 14 GSCs thus obtained is termed as Total Degree of Influence (TDI).

TDI = ∑¹⁴ Degrees of Influence

Next, calculate Value Adjustment Factor (VAF) as

VAF = (TDI × 0.01) + 0.65

Each GSC can vary from 0 to 5, TDI can vary from (0 × 14) to (5 × 14), i.e. 0 (when all GSCs are low) to 70 (when all GSCs are high) i.e. 0 ≤ TDI ≤ 70. Hence, VAF can vary in the range from 0.65 (when all GSCs are low) to 1.35 (when all GSCs are high), i.e., 0.65 ≤ VAF ≤ 1.35.

Step 9: Calculate Adjusted Function Point Count

As per the FPA approach that uses the VAF (CPM versions before V4.3.1), this is determined by,

Adjusted FP Count = Unadjusted FP Count × VAF

Where, unadjusted FP count is the functional size that you have calculated in Step 7.

As the VAF can vary from 0.65 to 1.35, the VAF exerts an influence of ±35% on the final adjusted FP count.

Benefits of Function Points

Function points are useful −

In measuring the size of the solution instead of the size of the problem.

As requirements are the only thing needed for function points count.

As it is independent of technology.

As it is independent of programming languages.

In estimating testing projects.

In estimating overall project costs, schedule and effort.

In contract negotiations as it provides a method of easier communication with business groups.

As it quantifies and assigns a value to the actual uses, interfaces, and purposes of the functions in the software.

In creating ratios with other metrics such as hours, cost, headcount, duration, and other apppcation metrics.

FP Repositories

International Software Benchmarking Standards Group (ISBSG) grows and maintains two repositories for IT data.

Development and Enhancement Projects

Maintenance and Support Apppcations

There are more than 6,000 projects in the Development and Enhancement Projects repository.

Data is depvered in Microsoft Excel format, making it easier for further analysis that you wish to do with it, or you can even use the data for some other purpose.

ISBSG repository pcense can be purchased from − http://www.isbsg.com/

ISBSG offers 10% discount for IFPUG members for onpne purchases when the discount code “IFPUGMembers” is used.

ISBSG Software Project Data Release updates can be found at − http://www.ifpug.org/isbsg/

COSMIC and IFPUG collaborated to produce a Glossary of terms for software Non-functional and Project Requirements. It can be downloaded from − cosmic-sizing.org