Function Point Counting Practices

Function Point
Counting Practices

Definition
• “Function Point Analysis is a standard method
for measuring software development from the
user’s point of view”, IFPUG 1999
• FPA measures software by quantifying the
functionality the software provide to the user
based primarily on logical design

Objectives
• Measures functionality that the user requests
and receives
• Measures software development and
maintenance independently of technology used
for implementation

Counting Process
• Should be
 Simple enough to minimize the overhead of
the measurement process
 A consistent measure among various projects
and organizations

Benefits
• A tool to determine the size of a purchased application package
• A tool to help users determine the benefit of an application
package to their organization by counting functions that
specifically match their requirements
• A tool to measure the units of a software product to support
quality and productivity analysis
• A vehicle to estimate cost and resources required for software
development and maintenance
• A normalization factor for software comparison

User View
• A user view represents a formal description of the
user’s business needs in the user’s language
• Developers translate the user information into
technology language in order to provide a solution
• A function point count is accomplished using the
information in a common language to both user(s)
and developers

User View
• A user view
 Is a description of the business functions
 Is approved by the user
 Can be used to count function points
 Can vary in physical form (e.g., proposals,
requirements document, detailed specification,
user handbook)

Sizing During Life Cycle
Phase: Initial User Requirements
 Incomplete
 Lack “utility” functionality
 Impossible to implement or very difficult to use
 Too general
 Varying functional needs, if more than one is responsible for the project
 Stated requirements without regard for application boundaries
 Expressed in a different context or a terminology incompatible with
function point analysis

Phase: Initial Technical Requirements
 Technology dependence
 Incorrect identification of the functional needs of the users
 Terminology unfamiliar to the users
 Functionality may be determined by placing too much emphasis
on technical constraints
 Boundaries are determined according to the technical
architecture of the other applications in the organization

Phase: Final Functional Requirements
 Contains terminology which can be understood by both users and
software developers
 Provides integrated descriptions of all user requirements, including
requirements from different users
 Is complete and consistent enough to accurately count function points
 Each process and group of data is approved by the user
 The feasibility and usability are approved by the software developers

Example
• User: "Whenever I’m working with an employee, I want to be able to view the
employee's information by entering his or her name.“
• Developer: "I recognize the need for an employee inquiry, but many
employees may have the same name. It is not possible to specify an individual
employee by typing his/her name; therefore, I suggest an online employee list
(name, location and social security number) from which to select an
employee. An index will be necessary to speed up the retrieval of a specific
employee.“
• User: "I agree that the employee selection list is necessary in this case, and it
may also be used for purposes other than selecting an employee.”

Step 1
Determine Type of Count

Types of Function Point Count
• Function point counts can be associated with either
projects or applications
• There are three types of function point counts:
1. Development project
2. Enhancement project
3. Application

Development Project
“ The development project function point count
measures the functions provided to the users
with the first installation of the software
delivered when the project is complete ”

Enhancement Project
“ The enhancement project function point count
measures the modifications to the existing
application that add, change, or delete user
functions delivered when the project is complete ”

Application
“ This count provides a measure of the current
functions the application provides the user ”
• This number is initialized when the development project
function point count is completed and updated every
time completion of an enhancement project alters the
application's functions

Types of Counts
(Project A is completed first, followed by Project B)

Example
The count type is for a project function point count,
which will also evolve into an application function
point count

Step 2
Identify Counting Scope &
Application Boundary

The Purpose of The Count
• Determines the type of function point count and the
scope of the required count to obtain the answer to the
business problem under investigation
• Influences the positioning of the boundary between the
software under review and the surrounding software

Examples of Purposes
• “ To provide a function point count as an input to the estimation
process to determine the effort to develop the first release of an
application ”
• “ To provide a function point count of the installed base of
applications “
• “ To provide a function point count to enable the comparison of
functionality delivered by two different suppliers’ packages “

Counting Scope
• The counting scope defines the functionality which will
be included in a particular function point count
• The counting scope:
 Defines a (sub) set of the software being sized
 Is determined by the purpose for performing the function point count
 Identifies which functions will be included in the function point count
so as to provide answers relevant to the purpose for counting
 Could include more than one application

Counting Scope
• The counting scope of:
 A Development Project includes all functions impacted (built
or customized) by the project activities.
 An Enhancement Project includes all the functions being
added, changed, and deleted
 An Application may include, depending on the purpose:
- only the functions being used by the user
- all the functions delivered

Application Boundary
• The application boundary indicates the border between
the software being measured and the user
• The application boundary:
 Defines what is external to the application
 Is the conceptual interface between the ‘internal’ application and the
‘external’ user world
 Acts as a ‘membrane’ through which data processed by transactions
(EIs, EOs and EQs) pass into and out from the application
 Encloses the logical data maintained by the application (ILFs)
 Assists in identifying the logical data referenced by but not maintained
within this application (EIFs)
 Is dependent on the user’s external business view of the application.
 It is independent of technical and/or implementation considerations

Boundary Rules
• The following rules must apply for boundaries:
 The boundary is determined based on the user's view. The
focus is on what the user can understand and describe.
 The boundary between related applications is based on
separate functional areas as seen by the user, not on
technical considerations.
 The initial boundary already established for the application
or applications being modified is not influenced by the
counting scope.

Boundary Rules
Note:
• There may be more than one application included in the
counting scope. If so, multiple application boundaries
would be identified.
• When the application boundary is not well-defined (such
as early in analysis), it should be located as accurately as
possible.

Counting Scope & Application
Boundary Procedures
Step Action
1 Establish the purpose of the count
2 Identify the counting scope
3 Identify the application boundary
4 Document the following items:
• The purpose of the count
• The counting scope
• The application boundary
• Any assumptions related to the above

Data Functions
• Data functions represent the functionality provided to
the user to meet internal and external data requirements
• Data function types are defined as
 Internal logical files (ILFs), and
 External interface files (EIFs)
• File refers to a logically related group of data, and not
the physical implementation of those groups of data

Internal Logical File (ILF)
“An ILF is a user identifiable group of logically related
data or control information maintained within the
boundary of the application”
• The primary intent of an ILF is to hold data maintained
through one or more elementary processes of the
application being counted.

External Interface File (EIF)
“An EIF is a user identifiable group of logically related data
or control information referenced by the application, but
maintained within the boundary of another application.”
• The primary intent of an EIF is to hold data referenced
through one or more elementary processes within the
boundary of the application counted.
• This means an EIF counted for an application must be in
an ILF in another application.

ILFs vs. EIFs
“The primary difference between an internal logical file
and an external interface file is that an EIF is not
maintained by the application being counted, while an
ILF is.”

Definitions
DefinitionTerm
Data that influences an elementary process of the application being
counted. It specifies what, when, or how data is to be processed.
For example, timing information that affects when the elementary
process of paying employees occurs.
Control
Information
Refers to defined requirements for processes and/or groups of data
that are agreed upon, and understood by, both the user(s) and
software developer(s).
User
Identifiable
The ability to modify data through an elementary process.
Examples, add, change, delete, populate, revise, update, and create.
Maintained
the smallest unit of activity that is meaningful to the user(s), and
must be self-contained and leave the business of the application in a
consistent state.
For Example, Adding a new employee with complete information.
Elementary
Process

Counting Data Functions
Counting
Data
Functions
Identify
ILFs
Identify
EIFs
Determine
Complexity
&
Contribution
Counting
DETs
Counting
RETs
Rate
Functional
Complexity
Calculate
UFP

ILF Identification Rules
• All of the following counting rules must apply for the
information to be counted as an ILF.
1. The group of data or control information is logical and user
identifiable.
2. The group of data is maintained through an elementary
process within the application boundary being counted.

EIF Identification Rules
information to be counted as an EIF.
1. The group of data or control information is logical and user
identifiable.
2. The group of data is referenced by, and external to, the application
being counted.
3. The group of data is not maintained by the application being
counted.
4. The group of data is maintained in an ILF of another application.

Complexity and Contribution
• The number of ILFs, EIFs, and their relative functional
complexity determine the contribution of the data functions
to the unadjusted function point count.
• Assign each identified ILF and EIF a functional complexity
based on the number of data element types (DETs) and
record element types (RETs) associated with the ILF or EIF.

Definitions
• A data element type (DET) is a unique user recognizable,
non-repeated field.
• A record element type (RET) is a user recognizable subgroup
of data elements within an ILF or EIF.
 Optional subgroups are those that the user has the option of
using one or none of the subgroups during an elementary process
that adds or creates an instance of the data.
 Mandatory subgroups are subgroups where the user must use at
least one.

DET Rules
• DET Rule #1: Count a DET for each unique user recognizable,
non-repeated field maintained in or retrieved from the ILF or EIF
through the execution of an elementary process.
• For example, an account number that is stored in multiple fields is
counted as one DET.
• For example, a before or after image for a group of 10 fields
maintained for audit purposes would count as one DET for the
before image (all 10 fields) and as one DET for the after image (all
10 fields) for a total of 2 DETs.

DET Rules
• For example, the result(s) of a calculation from an elementary process, such
as calculated sales tax value for a customer order maintained on an ILF is
counted as one DET on the customer order ILF.
• For example, accessing the price of an item which is saved to a billing file or
fields such as a time stamp if required by the user(s) are counted as DETs.
• For example, if an employee number which appears twice in an ILF or EIF
as (1) the key of the employee record and (2) a foreign key in the dependent
record, count the DET only once.
• For example, within an ILF or EIF, count one DET for the 12 Monthly
Budget Amount fields. Count one additional field to identify the applicable
month.

DET Rules
• DET Rule #2: When two applications maintain and/or reference
the same ILF/EIF, but each maintains/references separate DETs,
count only the DETs being used by each application to size the
ILF/EIF.
• For example, Application A may specifically identify and use an
address as: street address, city, state and zip code. Application B
may see the address as one block of data without regard to
individual components. Application A would count four DETs;
Application B would count one DET.

DET Rules
• DET Rule #3: Count a DET for each piece of data required by the
user to establish a relationship with another ILF or EIF.
• For example, in an HR application, the employee’s job name is included as
part of the employee's information (ILF). This DET is counted because it is
required to relate an employee to a job that exists in the organization. This
type of data element is referred to as a foreign key.
• For example, in an object oriented (OO) application, the user requires an
association between object classes, which have been identified as separate
ILFs. Location name is a DET in the Location EIF. The location name is
required when processing employee information; consequently, it is also
counted as a DET within the Employee ILF.

RET Rules
• One of the following rules applies when counting RETs:
1. Count a RET for each optional or mandatory subgroup of
the ILF or EIF.
Or
2. If there are no subgroups, count the ILF or EIF as one RET.

Functional Complexity
51 or more DETs20 to 50 DETs1 to 19 DETs
AverageLowLow1 RET
HighAverageLow2 to 5 RETs
HighHighAverage6 or more RETs
• Complexity Matrix

Calculate UFP
Unadjusted Function Point
7Low
10Average
15High
• ILF Translation Table
5Low
7Average
10High
• EIF Translation Table

Step 4
Count Transactional
Functions

Transactional Functions
• Transactional functions represent the functionality
provided to the user for the processing of data by an
application.
• Transactional functions are defined as
 External Inputs (EIs),
 External Outputs (EOs),
 External Inquiries (EQs).

External Inputs (EI)
“An EI is an elementary process that processes data or
control information that comes from outside the
application boundary.”
• The primary intent of an EI is to maintain one or more
ILFs and/or to alter the behavior of the system.

External Output (EO)
“An EO is an elementary process that sends data or
control information outside the application boundary.”
• 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, or create derived data.
• An EO may also maintain one or more ILFs and/or alter the
behavior of the system.

External Inquiry (EQ)
“An EQ is an elementary process that sends data or
control information outside the application boundary.”
• The primary intent of an EQ is to present information to a
user through the retrieval of data or control information
from an ILF or EIF.
• The processing logic contains no mathematical formulas or
calculations, and creates no derived data.
• No ILF is maintained during the processing, nor is the
behavior of the system altered.

Summery
Function
Transactional Function Type
EI EO EQ
Alter the behavior of the system PI F N/A
Maintain one or more ILFs PI F N/A
Present information to a user F PI PI
Legend:
PI The primary intent
F A function but is not the primary intent, it is sometimes present
N/A Not allowed

Definitions
DefinitionTerm
Requirements specifically requested by the user
to complete an elementary process
Processing
Logic

Counting
Transactional Functions
Counting
Transactional
Functions
Identify
Elementary
Processes
Identify EI
Identify EO
Identify EQ
Determine
Complexity &
Contribution
Counting
FTRs
Counting
DETs
Rate
Functional
Complexity
Calculate
UFP

Elementary Process
Identification Rules
process to be identified as an elementary process.
1. The process is the smallest unit of activity that is meaningful
to the user.
2. The process is self-contained and leaves the business of the
application in a consistent state.

EI Identification Rules
elementary process to be counted as an EI.
1. The data or control information is received from outside the
application boundary.
2. At least one ILF is maintained if the data entering the
boundary is not control information that alters the behavior
of the system.

EI Identification Rules
elementary process to be counted as an EI.
3. One of the following three statements must apply:
 Processing logic is unique from the processing logic performed
by other external inputs for the application.
 The set of data elements identified is different from the sets
identified for other external inputs for the application.
 The ILFs or EIFs referenced are different from the files
referenced by other external inputs in the application.

EO Identification Rules
elementary process to be counted as an EO.
1. The function sends data or control information external to the
 Processing logic is unique from the processing logic performed by other
external outputs or external inquiries for the application.
 The set of data elements identified is different from the sets identified for
other external outputs and external inquiries in the application.
 The ILFs or EIFs referenced are different from the files referenced by other
external outputs and external inquiries in the application.

EO Identification Rules
elementary process to be counted as an EO.
3. One of the following rules must apply:
 The processing logic of the elementary process contains at least one
mathematical formula or calculation.
 The processing logic of the elementary process creates derived data.
 The processing logic of the elementary process maintains at least one ILF.
 The processing logic of the elementary process alters the behavior of the
system.

EQ Identification Rules
elementary process to be counted as an EQ.
1. The function sends data or control information external to the
 Processing logic is unique from the processing logic performed by other
external outputs or external inquiries for the application.
 The set of data elements identified is different from the sets identified for
other external outputs and external inquiries in the application.
 The ILFs or EIFs referenced are different from the files referenced by other
external outputs and external inquiries in the application.

EQ Identification Rules
elementary process to be counted as an EQ.
3. All of the following rules must apply:
 The processing logic of the elementary process retrieves data or control information
from an ILF or EIF.
 The processing logic of the elementary process does not contain a mathematical
formula or calculation.
 The processing logic of the elementary process does not create derived data.
 The processing logic of the elementary process does not maintain an ILF.
 The processing logic of the elementary process does not alter the behavior of the
system.

Complexity and Contribution
• The number of EIs, EOs, and EQs and their relative
functional complexity determine the contribution of the data
functions to the unadjusted function point count.
• Assign each identified EI, EO and EQ a functional complexity
based on the number of data element types (DETs) and file
types referenced (FTRs) associated with the ILF or EIF.

Definitions
• A data element type (DET) is a unique user recognizable,
non-repeated field.
• A file types referenced (FTR) is
 An ILF read or maintained by a transactional function, or
 An EIF read by a transactional function.

FTR Rules for EIs & EOs
• FTR Rule #1: Count an FTR for each ILF maintained during the
processing of the elementary process.
• FTR Rule #2: Count an FTR for each ILF or EIF read during the
• FTR Rule #3: Count only one FTR for each ILF that is both
maintained and read.

FTR Rules for EQs
• FTR Rule #1: Count an FTR for each ILF maintained during the

DET Rules for EIs
• DET Rule #1: Count one DET for each user recognizable, non-
repeated field that enters or exits the application boundary and is
required to complete the external input.
• For example, job name and pay grade are two fields that the user
provides when adding a job.

DET Rules for EIs
• DET Rule #2: Do not count fields that are retrieved or derived by
the system and stored on an ILF during the elementary process if
the fields did not cross the application boundary.
• For example, when the customer order is added to the system, the
unit price is automatically retrieved for each ordered item and
stored on the billing record. The unit price would not be counted as
a DET for the EI because it did not cross the boundary when the
user adds the customer order.

DET Rules for EIs
• DET Rule #3: Count one DET for the capability to send a system
response message outside the application boundary to indicate an
error occurred during processing, confirm that processing is
complete or verify that processing should continue.
• For example, if a user tries to add an existing employee to a Human
Resources application, the system generates one of several error
messages and the incorrect field is highlighted. Count one DET that
includes all the system responses which indicate the error
conditions, confirm that processing is complete or verify that
processing should continue.

DET Rules for EIs
• DET Rule #4: Count one DET for the ability to specify an action
to be taken even if there are multiple methods for invoking the
same logical process.
• For example, if the user can initiate the adding of an employee by
clicking on the OK button or by pressing a PF key, count one DET
for the ability to initiate the process.

DET Rules for EOs & EQs
repeated field that enters the application boundary and is required
to specify when, what and/or how the data is to be retrieved or
generated by the elementary process.
• For example (EO/EQ), to generate a list of employees, employee
name is a field the user provides when indicating which employees
to list.

repeated field that exits the boundary.
• For example (EO/EQ), a text message may be a single word, sentence, or
phrase—a line or paragraph included on a report to indicate an explanatory
comment counts as a single DET.
• For example (EO/EQ), an account number or date physically stored in
multiple fields is counted as one DET when it is required as a single piece of
information.
• For example (EO/EQ), a pie chart might have a category label and a
numerical equivalent in a graphical output. Count two DETs —one for
designating the category and one for the numerical value.

• DET Rule #3: If a DET both enters and exits the boundary, count
it only once for the elementary process.
• DET Rule #4: Count one DET for the capability to send a system
response message outside the application boundary to indicate an
error occurred during processing, confirm that processing is
complete or verify that processing should continue.
• For example (EO/EQ), if a user tries to request a listing, but does
not have access to the information, count one DET for the system
response.

• DET Rule #5: Count one DET for the ability to specify an action to
be taken even if there are multiple methods for invoking the same
logical process.
• For example (EO/EQ), if the user can initiate the generation of a
report by clicking on the OK button or by pressing a PF key, count
one DET for the ability to initiate the report.
• DET Rule #6: Do not count literals as DETs.
• For example (EO/EQ), literals include report titles, screen or panel
identification, column headings, and field titles.

• DET Rule #7: Do not count fields that are retrieved or derived by
the system and stored on an ILF during the elementary process if the
fields did not cross the application boundary.
• For example (EO), when a paycheck is printed, a status field on the
Employee ILF is updated to indicate that the check has been printed.
Do not count the status field as a DET since it did not cross the
boundary.

• DET Rule #8: Do not count paging variables or system-generated
stamps.
• For example (EO/EQ), system-generated variables and stamps
include
 Page numbers
 Positioning information such as "Rows 37 to 54 of 211"
 Paging commands such as previous, next, and paging arrows on a GUI
application
 Date and time fields if they are displayed.

16 or more DETs5 to 15 DETs1 to 4 DETs
AverageLowLow0 to 1 FTR
HighAverageLow2 FTRs
HighHighAverage3 or more FTRs
• Complexity Matrix for EIs

20 or more DETs6to 19 DETs1 to 5 DETs
AverageLowLow0 to 1 FTR
HighAverageLow2 to 3 FTRs
HighHighAverage4 or more FTRs
• Complexity Matrix for EOs & EQs

Calculate UFP
3Low
4Average
6High
• EI & EQ Translation Table
4Low
5Average
7High
• EO Translation Table

Step 5
Determine Unadjusted
Function Point Count

Unadjusted Function
Point Count
𝑈𝐹𝑃𝐶 =
𝑈𝐹𝑃𝐶 𝐼𝐿𝐹 + 𝑈𝐹𝑃𝐶 𝐸𝐼𝐹 +
𝑈𝐹𝑃𝐶 𝐸𝐼 + 𝑈𝐹𝑃𝐶 𝐸𝑂 + 𝑈𝐹𝑃𝐶 𝐸𝑄

Step 6
Determine Value
Adjustment Factor

Value Adjustment Factor
• The value adjustment factor (VAF) is based on 14 general
system characteristics (GSCs) that rate the general
functionality of the application being counted.
• The degree of influence for each characteristic ranges on a scale
of zero to five, from no influence to strong influence.
• When applied, the value adjustment factor adjusts the
unadjusted function point count ± 35 percent to produce the
adjusted function point count.

General System
Characteristics
• The 14 general system characteristics are:
1. Data Communications 2. Distributed Data Processing
3. Performance 4. Heavily Used Configuration
5. Transaction Rate 6. Online Data Entry
7. End-User Efficiency 8. Online Update
9. Complex Processing 10. Reusability
11. Installation Ease 12. Operational Ease
13. Multiple Sites 14. Facilitate Change

Procedure to Determine
VAF
Step Action
1 Evaluate each of the 14 general system characteristics on a scale from
zero to five to determine the degree of influence (DI).
2 Add the degrees of influence for all 14 general system characteristics to
produce the total degree of influence (TDI).
3 Insert the TDI into the following equation to produce the value
adjustment
factor.
VAF = (TDI * 0.01) + 0.65

Step 7
Calculate Adjusted
Function Point Count

Review
Step Action
1 Determine the type of function point count.
2 Identify the counting boundary.
3 Determine the unadjusted function point count
a. Count data functions.
b. Count transactional functions.
4 Determine the value adjustment factor.
5 Calculate the adjusted function points.

Types of Function Point Count
• There are three types of function point counts:
1. Development project
2. Enhancement project
3. Application

Development Project
• The development project function point calculation
consists of three components of functionality:
 Application functionality included in the user
requirements for the project.
 Conversion functionality included in the user
 Application value adjustment factor (VAM).

Application Functionality
• Application functionality consists of functions used after
software installation to satisfy the ongoing business
needs of the user.

Conversion Functionality
• Conversion functionality consists of functions provided
only at installation to convert data and/or provide
other user-specified conversion requirements, such as
special conversion reports.
• For example, if a Human Resources (HR) software application was
in use and a new HR application is installed, the users may require
that information about employees be converted and loaded into the
new application. The user specified conversion requirement is to
transfer the current employee data into the new HR system.

• The value adjustment factor is determined by using the
14 general system characteristics to rate the application
functional complexity

Function Point Formula
DFP = (UFP + CFP) * VAF
Where:
• DFP is the development project function point count
• UFP is the unadjusted function point count for the
functions that will be available after installation
• CFP is the unadjusted function points added by the
conversion unadjusted function point count
• VAF is the value adjustment factor

Enhancement Project
• The Enhancement project function point calculation
consists of three components of functionality:
 Application functionality included in the user
 Conversion functionality included in the user
 Application value adjustment factor (VAM).

Application Functionality
• Application functionality consists of:
 Function points identified from the functionality that
is added by the enhancements
 Function points counted because existing functionality
is changed during the enhancement project
 Function points counted for functionality deleted
during the enhancement project

Conversion Functionality
• The conversion functionality consists of function points
delivered because of any conversion functionality
required by the user.

• The two value adjustment factors are the:
1. Application value adjustment factor before the
enhancement project begins
2. Application value adjustment factor after the
enhancement project is complete

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 or will be added by the enhancement project.
• CHGA is the unadjusted function point count of those functions that
were or will be modified by the enhancement project. This number
reflects the size of the functions after the modifications.

EFP = [(ADD + CHGA + CFP) * VAFA] + (DEL* VAFB)
Where:
• CFP is the function point count of those functions added by the
conversion.
• VAFA is the value adjustment factor of the application after the
enhancement project is complete.
• DEL is the unadjusted function point count of those functions that were
or will be deleted by the enhancement project.
• VAFB is the value adjustment factor of the application before the
enhancement project begins.

Application
• There are two variations of this formula:
1. Formula to establish the initial function point count
for an application.
2. Formula to re-establish the function point count for
an application after an enhancement project has
changed the application functionality.

Establish the Initial Count
AFP = ADD * VAF
Where:
• AFP is the initial application function point count.
• ADD is the unadjusted function point count of those
functions that were installed by the development project.
• VAF is the value adjustment factor of the application.

Reflect Enhancement Projects
The functionality for the application can be altered in one or
more ways:
• Added (new) functionality increases the size of the application
• Changed functionality increases, decreases, or has no effect on the size
of the application
• Deleted functionality decreases the application size
• Changes to the value adjustment factor adds, subtracts, or has no effect
on the function point count but does affect the adjusted function point
count.

AFP = [(UFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA
Where:
• AFP is the application's adjusted function point count.
• UFPB is the application's unadjusted function point count before the
enhancement project begins.
• 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 changed by the enhancement project. This number reflects the size
of the functions after the changes.

AFP = [(UFPB + ADD + CHGA) - (CHGB + DEL)] * VAFA
Where:
• CHGB is the unadjusted function point count of those functions that
were changed by the enhancement project. This number reflects the
size of the functions before the changes were made.
• DEL is the unadjusted function point count of those functions that
were deleted by the enhancement project.
• VAFA is the value adjustment factor of the application after the
enhancement project is complete.

Function Point Counting Practices

More Related Content

What's hot

Viewers also liked

Similar to Function Point Counting Practices

More from Umar Alharaky

Recently uploaded

Function Point Counting Practices