Function point Analysis

Size of any software product is directly dependent on the number of different functions or
features it supports.

Each function when invoked reads some input data and transforms it to the corresponding output
data.

In addition to number of basic functions that software performs, the size is also dependent on the
number of files and the number of interfaces.

Function point doesn’t measure the internal architectural or technological complexity of an application

1. Measure software by quantifying the functionality requested by and provided to the

customer.
2. Measure software development and maintenance independently of technology used for
implementation.
3. Measure software development and maintenance consistently across all projects and
organizations.

979 FPs introduced by Alan Albrecht

1984 First FP guidelines
1986 First IFPUG Board of Directors
1994 CPM Release 4.0
2003 ISO standard

4.

 The ability to accurately estimate:

1. project cost
2. project duration
3. project staffing size

A simple five step counting process

To start at a high level, there are five steps in the process of counting FPs. They are:
 1. Determine the type of count.
2. Identify the scope and boundary of the count.
3. Determine the unadjusted FP count.
4. Determine the Value Adjustment Factor.
5. Calculate the Adjusted FP Count.

Five standard "functions"

In counting FPs there are five standard "functions" that you count. The first two of these are
called Data Functions, and last three are called Transaction Functions. The names of these
functions are listed below.

1. Data Functions:
1. Internal logical files
2. External interface files
2. Transactional Functions:
1. External Inputs
2. External Outputs
3. External Inquiries

Using this terminology, when a person that counts FPs looks at a software system, they see
something like this:

Figure 1: The view of a software application from the eyes of a Function Point practitioner.
mportant terms and definitions used in describing the five functions
User identifiable

This term refers to defined requirements for processes and/or groups of data that are agreed
upon, and understood by, both the users and software developers.

Control information

This is data that influences and elementary process of the application being counted. It specifies
what, when, or how data is to be processed.

Elementary process

An elementary process is the smallest unit of activity that is meaningful to the user. An
elementary process must be self-contained and leave the business of the application being
counted in a consistent state.

Data Element Type, or DET

A data element type is a unique, user recognizable, non-repeated field. This definition applies to
both analyses of data functions and transactional functions.

Record Element Type, or RET

A record element type is a user recognizable subgroup of data elements within an Internal
Logical File or External Interface File.

1) Data Functions - Internal Logical Files (ILFs)

"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."

Examples of ILFs

Samples of things that *can* be ILFs include:

1. Tables in a relational database.

2. Flat files.
3. Application control information, perhaps things like user preferences that are stored by
the application.

When you're counting ILFs you will constantly be referring to the two tables that follow. The purpose of
the first table is to help you determine whether the ILF you're currently looking at has a complexity level
of Low (L), Average (A), or High (H). You do this by going into the table knowing the number of DETs and
number of RETs you have counted in the ILF, and then finding the resulting Low, Average, or High value.

. Weights:
Complexity Points
Low 7
Average 10
High 15

Data Functions - External Interface Files (EIFs)

EIF stands for "External Interface File". In my words, EIFs represent the data that your
application will use/reference, but data that is not maintained by your application.

The official IFPUG definition of an EIF is:

"An external interface file (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."

Again, think of this as data that your application needs and uses, but does not maintain.

Examples of things that can be EIFs are identical to the list for ILFs, but again, the big difference
here is that EIFs are not maintained by the application under consideration, but ILFs are.
Function point counts resulting from EIFs

Assigning an FP value to an EIF is the same as assigning one to an ILF. First, determine the
number of DETs and RETs in the EIF, then do a lookup in the following table to determine
whether the EIF has a complexity of Low, Average, or High. 

  Data Element Types (DETs)

RETS 1-19 20-50 51+

1 L L A

2 to 5 L A H

6 or more A H H

Table 4: EIF complexity matrix Then, once you know whether the EIF is considered Low,
Average, or High, look in the following table for the number of FPs to count for this particular
EIF.
EIF Weights:

Value No. or Function Points

Low 5

Average 7

High 10

) Transaction Functions - External Inputs (EI's)

EI stands for "External Input". Here the official IFPUG definition of an EI is as follows:

An external input (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.

Examples of EIs include:

1. Data entry by users.

2. Data or file feeds by external applications.

Function point counts resulting from EI's

Allocating FPs to EIs is similar to the process we covered for ILFs and EIFs. However, in this
case, instead of doing a lookup based on DET's and RET's to determine a Low/Average/High
complexity, the lookup is performed using DET and FTR values. As you'll recall from the earlier
definition, an FTR is a "file type referenced", so it can be either an ILF or an EIF.

As an example, suppose that you have a process that has 5 DET's, and during the processing it
references an EIF named Users and an ILF named Process. You would go into the following
table looking for the complexity of an EI that has 5 DET's and 2 FTR's. As you'll see from the
table below, this EI is considered an "Average" complexity EI. 

FTR's Data Element Types (DET's)

  1-4 5-15 16+

0-1 L L A

2 L A H
3 or more A H H

Table 6: EI complexity matrix To carry our example forward, as you can see from the following
table, an Average complexity EI is worth 4 FPs.

Weights:

Complexity Points/Weight

Low 3

Average 4

High 6

Transaction Functions - External Outputs (EO's)

External Outputs are referred to as EO's. The IFPUG definition of an EO is as follows:

An external output (EO) is an elementary process that sends data or control information outside the
application boundary. The primary intent of an external output 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 or alter the behavior of the system.

EO examples include:

1. Reports created by the application being counted, where the reports include derived
information.

Function point counts resulting from EO's

Allocating FP's to EO's is very similar to the process for EI's. Again, you perform your lookup
using DET's and FTR's, with a resulting Low/Average/High complexity.

As an example, suppose that you have a process that you've identified as being an EO, and it has
10 DET's and references two FTR's. You would go into the following table looking for the
complexity of an EI that has 10 DET's and 2 FTR's. As you'll see from the table below, this EO
is considered an ``Average'' complexity EO. 

FTR Data Element Types (DET)

   1-5 6-19 20+

0-1 L L A

2-3 L A H

4 or more A H H

Table 8: EO complexity matrix Weights:

To carry our example forward, using the table that follows, you'll see that an Average complexity
EO has a value of 5 FPs.

Complexity Points/Weight

Low 4

Average 5

High 7

ransaction Functions - External Inquiries (EQ's)

The last transactional function is referred to as an EQ, or External Inquiry. The IFPUG definition
of an EQ is as follows:

An external inquiry (EQ) is an elementary process that sends data or control information outside the
application boundary. The primary intent of an external inquiry is to present information to a user
through the retrieval of data or control information from an ILF of 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.

Examples of EQs include:

1. Reports created by the application being counted, where the report does not include any
derived data.
2. Other things known as "implied inquiries", which unfortunately, are a little out of scope for this
paper.

Function point counts resulting from EQ's

Allocating an FP count to EQs is very similar to the process for EIs and EOs. Again, you
perform your lookup using DETs and FTRs, with a resulting Low/Average/High complexity.

As an example, suppose that you have a process that you've identified as being an EQ, and it has
20 DETs and references 4 FTRs. You would go into the following table looking for the
complexity of an EI that has 20 DETs and 4 FTRs. As you'll see from the table below, this EQ is
considered a "High" complexity EQ. 

FTRs Data Element Types (DETs)

  1-5 6-19 20+

0-1 L L A

2-3 L A H

4 or more A H H

Table 10: EQ complexity matrix Weights:

Carrying our EQ example forward, you'll find from the table below that a High complexity EQ is
worth 6 FPs.

Complexity Points/Weight

Low 3

Average 4

High 6

The type of count

The first step in our FPA process is determining the type of count for the application at hand.
Function point counts can be one of three different types:

Name Definition

Development Project FP Measures the functions provided to the users with the first installation of the
Count software being delivered.
Enhancement Project FP
Measures the modifications to an existing application.
Count

Application FP Count Measures the functionality provided to users in an existing application.

The full listing of the fields stored in each table are shown in the following tables. These tables
provide each field name, a field description, and indicator as to whether the field should be
counted as a DET, and other notes/comments regarding each field. The last row of each table
provides a count of the total number of DETs in the corresponding database table.

Table 13: The "Project" database table

Count as a
Field Description Notes
DET?
Sequential id, system- This is a technical artifact. It is not user-
project_id No
assigned. recognizable, and therefore not counted.
The name a user assigns
project_name Yes  
to a given project.
project_type The type of project count. Yes  
A description of the
description Yes  
project.
Total DETs: 3    

Table 14: The "Entity" database table

Count as
Field Description Notes
a DET?
Sequential id, system- System-generated sequence number. Not user-
entity_id No
assigned. recognizable.
Do count a DET for pieces of data that are
required by the user to establish a relationship
project_id Foreign key. Yes
with another ILF or EIF. Foreign keys usually fit
this definition.
name Name of the entity. Yes  
Type of entity (ILF or
type Yes  
EIF).
Number of RETs in
no. RETs Yes  
the entity.
 Number of DETs in
no. DETs Yes  
the entity.
Calculated
complexity complexity (Low, Yes  
Average, or High).
Total
6    
DETs:

Table 15: The "Process" database table

Count as a
Field Description Notes
DET?
Sequential id, system- System-generated sequence number. Not
process_id No
assigned. user-recognizable.
pg_id Foreign key. Yes  
name Name of the process. Yes  
Type of process (EI, EO,
type Yes  
or EQ).
Order of appearance when
sort_order Yes  
displayed.
no. FTRs Number of FTRs. Yes  
no. DETs Number of DETs. Yes  
complexity Low, Average, or High. Yes  
description Description of the process. Yes  
Total DETs: 8    

Table 16: The "Process Group" database table

Count as a
Field Description Notes
DET?
process Sequential id, system- System-generated sequence number. Not
No
group id assigned. user-recognizable.
project id Foreign key. Yes  
Name of the process
name Yes  
group.
Total DETs: 2    

Table 17: The "ProcessDETs" database table

 Count as a
Field Description Notes
DET?
Sequential id, system- System-generated sequence number. Not
id No
assigned. user-recognizable.
process_id Foreign key. Yes  
Sort order, for display
sequence Yes  
purposes.
User-supplied
description Yes  
description.
Total DETs: 4    

Table 18: The "ProcessEntities" database table

Count as a
Field Description Notes
DET?
Sequential id, system- System-generated sequence number. Not
id No
assigned. user-recognizable.
process_id Foreign key. Yes  
entity_id Foreign key. Yes  
Sort order, for display
sequence Yes  
purposes.
Total DETs: 3    

I won't keep you guessing about these tables; the data they represent are all ILFs (and not EIFs)
because they are maintained within the boundary of the FPTracker application. That being said,
you're about to see some of the complexity of FP counting. 

In this particular application there is not a one-to-one relationship between the database tables
and the way a user would logically view this data being stored. As an FP counter, and also the
primary user of this application :), I think of the data logically being stored like this:

1. Project
2. Entity
3. Process Group
4. Process
1. ProcessDETs
2. ProcessEntities

In this case what I'm saying is that, as the user of this application, I think of the Process DETs
and the Process Entities as being logical subgroups of the overall Process data. Okay, you say,
but what does that matter to me as an FP counter? Let's look at how our counts would differ if
we count the tables first as being separate, then second as being logically merged.

First, if I think of the these six tables as separate ILFs, because of the number of DETs they
contain, each table would be considered to be a "Low" complexity table. Because each Low table
is worth 7 FPs, the FP count for these six tables would be 42 FPs (6x7=42).

However, if I look at the tables from a "logical" perspective instead of the physical RDBMS
layout, what I really have are four logical groups. Because of their DET and RET counts, all four
of the groups are considered "Low" in complexity. So, in this case, the total count is 28 FPs
(4x7=28).

Therefore, had I counted the physical implementation of the tables as opposed to a logical
grouping, I would have over-counted this portion of the application by 14 FPs, or 50%. This is a
good example of where a physical implementation differs from a correct, logical grouping for an
FP count. Total Count Due to ILFs

To tally up the FP count due to ILFs, I've identified four ILFs, with the number of RETs and
number of DETs as shown in the table below. The first three ILFs are very straightforward, and
as discussed above, I believe that I have one Process ILF with three RETs: (1) Process, (2)
Process DETs, and (3) Process Entities. Using the ILF lookup table shown earlier in Table 2, I
see that each ILF is considered "Low" in complexity. Looking up Low Complexity ILFs in Table
3, I see that a Low Complexity table is counted as seven FPs. This gives me the total of 28 FPs
as a result of ILFs. 

ILF No. RETs No. DETs Complexity Function Points

Project 1 3 Low 7
Entity 1 6 Low 7
Process Group 1 2 Low 7
Process 3 13 Low 7
Total: 28      

Table 19: Total FP counts due to ILFs

Next: Step 3b: Determine the Up: A sample count P

Before getting into the VAF formula, let me quickly list the 14 GSCs:

1. Data Communication
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

ILF No. RETs No. DETs Complexity Function Points Project 1 3 Low 7 Entity 1 6 Low 7 Process Group 1 2
Low 7 Process 3 13 Low 7 Total: 28