Progressive Function Point

Analysis

Managers Guide to FPA

ver 1.0
ruben.gerad@attinadsoftware.com

agers Guide to Progressive FPA

TOPICS
Function Point Analysis
Introduction to FPA
Identifying the Boundary and Operations
Data Functions
Transaction Functions
Counting Issues Addressed By Progressive FPA
Progressive FPA
Progressive FPA Accounting Process
Progressive FPA Practice
Progressive Function Point Template
Use Cases
Data Functions
Transaction Functions
Case Study: Tequila University

unction Point Analysis

INTRODUCTION TO FUNCTION POINTS

Transaction Function

User Records
Profile
1. Name
11.
2. Login ID
Photo
3. Password
Contact
4. IM {skype, msn,
yammer}
5. IM User ID
Address
6. Flat-Bld-Id
7. Street
8. Location
9. State
10 Country
12.
Update

1. DB
User
Records
2. Digital
Asset
Managemen
t
2 Sources (FTR)
(db, ext file source)

12 DETs
(11. Fields, 1 action)

Data Function

User Records
1. User Profile
1. Name
2.
2. Login
Login ID
ID
3. Password

VAF=Value Adjustment

2. Contact
4.
4. IM
IM
5. IM
IM User
User
3. 5.
Address
3.
Address
ID
ID
6.
Flat-Bld6. Flat-BldId
7. Street
8.
8.
Location
9.
9. State
State
Factor
10
Country
Country

3 Sources (RET)
(tables/subgroups)
10 DETs
(10. Fields)

FPA is used to measure the size of a

project by counting all the data and
transaction functions and provides the
most scientific approach in measuring size
of a project.
Most programs/applications consists of
several screens to interact with the data.
Common operations include CRUD (Create,
Read, Update & Delete). Each screen may
have one ore more of these functions, and
by counting all the elements on screen
with any one of these operations will
determine the Data Element Type(DET)
count for the transaction function, the
same process is repeated for each offscreen function. Similarly when we
create/delete/update a new database table
or data store object to save data then the
DET count will be all the fields in the
respective tables.
Once we have the count of all the DET

unction Point Analysis

INTRODUCTION TO FUNCTION POINTS

Low

Medium

High

of
of
Subgroups/
Subgroups/
File/Interface
File/Interface
Count
Count

Y
Y Axis-Count
Axis-Count

DETs 1--------------5 6------------------------19 20+

X Axis- Actual DET Count

Range

IFPUG Reference Card FP

Values

IFPUG provides a FP value reference

card that identifies an FP value for
Low, Medium and High FPs based on
the number of DETs with respect to
the complexity involved by counting
subgroups(tables), logical files or
remote interfaces within the counted
fields of that function.

For Transaction functions, DET count

is taken along with FTR count to find
Counting FPs Simplified
the FP value in the IFPUG reference
card. Similarly in data functions the
a = Count of DETs
DET count is take along with the RET
b = Count of Subgroups(RET) or (ILF/EIF)
count to identify the FP value in the
c = IFPUG FP Value where X = a and Y = b
IFPUG reference card.
Unadjusted FP Count: UFP = (c)
VAF = (+/-) 30% of UFP
Adjusted FP Count = UFP x VAF

VAF=Value Adjustment Factor

The sum of all function counts is the

Unadjusted Function Point count.
(UFP). Adjusted FP is calculated by
multiplying the UFP with a Value
Adjustment Factor. VAF Consists of 14
General System Characteristics to

unction Point Analysis

IDENTIFYING THE BOUNDARY AND

OPERATIONS
The boundary, inputs & outputs

The first major hurdle, though simple is recognizing what constitutes EI,
EO, EQ, ILF & EIF and in identifying the data functions and transaction
functions.

unction Point Analysis

DATA FUNCTIONS
Data Functions are primarily database
related transactions. This may involve
the creation, updating the structure or
deletion of tables or related data
sources.

Customer Record

Contact

1.
1.
2.
2.
3.
3.
4.
4.
5.
5.
6.
6.

Profile

Name
Name
Email
Email
Profile
Profile Id
Id
DOB
DOB
Address
Address
Photo
Photo URL
URL

Memo

Product Record
Product

Categor
y

Pricing

Order Record
Order

Items

Invoice

Internal Logical Files(ILF) are set of

tables or related files that form a
unique group. For instance we have
showcased 3 ILFs, Customer Records,
Product Records and Order Records.
External Interface Files(EIF) are ILFs of
external systems that reside outside
the boundary of our application.
RETs are the different tables (subgroups) in the parent groups.
Customer Record has 3 RETs which are
Profile, Contact and Preferences.
DETs are the fields, or individual
elements in the respective tables or
subgroups. The Profile table has 6

unction Point Analysis

TRANSACTION FUNCTIONS
File Data Sources (FTR)

1. Digital
Asset
Management

2. Local
Database

User Profile View

A transaction function consists of all

the input and output operations that
are used to display contents, generate
reports, collect details through web
pages, forms or any other form of input
device or send output to an external
device or external system through an
API call.

1. Name
6. Photo

2. Email
3. Profile Id
4. DOB
5. Address

7. Close

The DETs counted here are the

individual fields that make up the
report, screen elements or parameters
in an API call which should refer to
some ILF or EIF and not static display
fields(time), we also consider one
action button as a field, hence in the
same form we have 7 DETs.
The FTRs are the total count of the
number of record sources (ILFs) used
to collect the data, sometimes photos
or videos may be stored externally, or
in other systems such as ECMs so we

unction Point Analysis

COUNTING ISSUES ADDRESSED BY

PROGRESSIVE FPA
Low
DETs 1

Medium
5

20 20+

High
Masking RETs/FTRs for this illustration
6 DET = FP Val:4
19 DET = FP Val:4
40 DET = FP Val:5

6 DET = FP Val: 6 x 0.2105 = 1.263 = 1.3

19 DET = FP Val:19 x 0.2105 = 3.999 = 4.0
40 DET = FP Val:40 x 0.2500 = 10.00 = 10.0

The Problems with Traditional FP Counting

Any Transaction functions with more than 20 Fields are considered high
complexity functions and not counted further, this is the primary reason for
miscalculation.
A webpage containing 20 Fields the FP Count = 5FP
If the another webpage contains 40 Fields the FP Count remains 5FP since they
are simply derived as High complexity Function points
In Progressive FPA, the FP count is derived as 10 FP since they are calculated
based on actual number of elements using the standard IFPUG value matrix and
not limited by static value ranges of High, Medium & Low
Progressive FPA goes a step further to validate the complexity of business
scenarios and counts every process step inside the function to derive a genuine

gressive Function Point Analysis

PROGRESSIVE FPA
User Profile

6.
Photo

2. Digital
Asset
Management
1. Local
Database

2. Email
3. Profile
Id
4. DOB
5. Address

File Data Source (FTR)

1.Client
1.Client
App
App

1.Authentic
ate User

2.XYZ
2.XYZ
Server
Server

2. Call API
to load user
details

3.DAM
3.DAM

Logical Collaboration Segments (LCS)

7.
Save

Cance
l

7.Display
User Profile

3. Validate
Session
Token

4. Get user
Profile from
DB

5.Authentic
ate with
DAM

Process Element Type (PET)

6.Load
Resource as
Stream

Data Element Type (DET)

1. Name

Progressive FPA is based on

the same guiding principles
of FPA, however the FP value
of DETs are derived from the
actual count of DETs and
based on IFPUG reference
card values for compliance.
Progressive FPA additionally
accounts
for
complex
business functions through
Integrated Process Flows. IPF
counts each process step
involved as Process Element
Type and the complexity is
derived
based
on
dependencies classified as
Logical
Collaboration
Segments.
All IPFs outside the boundary
but referenced from within
the application are termed

gressive Function Point Analysis

PROGRESSIVE FPA
User Profile

6.
Photo

2. Digital
Asset
Management
1. Local
Database

2. Email
3. Profile
Id
4. DOB
5. Address

File Data Source (FTR)

1.Client
1.Client
App
App

1.Authentic
ate User

2.XYZ
2.XYZ
Server
Server

2. Call API
to load user
details

3.DAM
3.DAM

Logical Collaboration Segments (LCS)

7.
Save

Cance
l

7.Display
User Profile

3. Validate
Session
Token

4. Get user
Profile from
DB

5.Authentic
ate with
DAM

Process Element Type (PET)

6.Load
Resource as
Stream

Data Element Type (DET)

1. Name

In Transaction functions PET

is
counted
as
user
interactions and functions
that include the standard
CRUD
functionality
and
beyond to include business
rules, process and workflows.
In Data functions the PETs
counted are internal triggers,
functions
or
procedures
related to the data store.
Progressive function points
thereby
considers
the
functional parameters with
respect to groups to estimate
the size and also counts
process steps with respect to
dependencies involved to
arrive at the Progressive FPA
Count & provide an authentic
estimate.

gressive Function Point Analysis

PROGRESSIVE FPA ACCOUNTING PROCESS

1. Provides architect
Project details

4. Manager
works on
release and
sprint planning

Any work can be justified

with actual work effort in
terms of the total variables
Architect
and process involved with
clear dependencies.
2. Creates the data

Manager
5. Signoff and
approval from
client on
effort
estimate

Client

Every Unit of work is clearly

defined with an FP Count &
hourly estimate.

7. Billed to
client as per
final Project
FP count

6. Completes
work and
submits post
count

model, class model

and basic flow of

application and
hands It down to
team for validation
and entry.

Project Team
3. The team enters the
details onto the Progressive
FP template to provide the
first draft pre count of the
project and detailed task
list for approval

Every
User
Interface,
process,
and
database
operation is defined and
documented or assumed to
be within given limits to
counter any ambiguity.

Any operation or process

that was ambiguous can be
provided with a final count
and billed later assuring
payment guarantee.
Anything

that

is

not

gressive Function Point Analysis

PROGRESSIVE FUNCTION POINT PRACTICE

The FP Practice will consists of
a few senior project managers
and architects who would
train, mentor and guide every
project.

Provides
training for
managers to
validate
effort
Architects
Provides training for
architects in Progressive
FPA techniques and working
with ambiguous
requirements

Managers

FPA Practice
Dedicated Auditing
team for reviewing
estimates

Clients
Progressive counting practices
overview to provide detailed
guide on how Progressive FPA
provides greater ROI and clarity

Project Teams
Trains team on best
practices such as single
responsibility pattern,
identifying transactional and
functional steps and
estimation and including all
work effort into the
equation.

The Internal auditing team will

provide an instant spot check
on all project estimates to
validate against any possible
ambiguity
and
under
valuation.
The FPA Practice will train
clients to use our Progressive
FPA methodology and audit
the
estimates
submitted
based
on
substantial
evidence.
The practice will also identify,
recruit and train resources for
each client or account and

o g r e s s i v e F P A Te m p l a t e

PROGRESSIVE FPA TEMPLATE: USE CASES

This sheet provides a complete high level overview of each UC of the project for
prioritization and team allocation.
Being a project by downloading the latest Progressive FP Template is freely
downloadable from Sourceforge.
List down the use cases/user stories in the use cases for the current sprint.
After each data or transaction function is added, the man-days, UFP and Reuse
FP are automatically computed. This page together with the editable reports
page can provide an in-depth view of each user story/use case along with all the
tasks and computed man hours for each task.

o g r e s s i v e F P A Te m p l a t e

PROGRESSIVE FPA TEMPLATE: DATA

FUNCTIONS

This data function sheet includes every table/data store record added, updated
or deleted with field level details and process flows.
The first column describes the task, and the adjacent column is used to link the
task to the Use case.
The column after which is used to define if it is a internal data store (ILF) or
external source (EIF).
The next four columns are DET, RET, PET, LCS for which there are detailed count
followed by detailed descriptors that justify each count.
The final two columns are used to include reusability, for instance upload media

o g r e s s i v e F P A Te m p l a t e

PROGRESSIVE FPA TEMPLATE:

TRANSACTION FUNCTIONS

The transaction function includes every operation that is used to fetch data to
and from the data source either input or output and includes every screen,
reports and operations in the application.
The functions may be added, updated or removed as a part of the user
story/operational context.
The first column describes the task, and the adjacent column is used to link the
task to the Use case.
The column after is used to define if the operation is an external input/output or
query EI, EO, EQ.
The next four columns are DET, FTR PET, LCS for which there are detailed count
followed by detailed descriptors that justify each count.

CASE STUDY

CASE STUDY: TEQUILA UNIVERSITY

Tequila University (TqU) is exploring CRM solutions for managing their annual
student intake process. Each year the university intake team manages a large
number of student applicants and is required to track each student and each of the
students applications. All student in the country apply to the UCAS system which
allows them to select their desired university. The UCAS system provides an FTP
downloadable file to universities for students wishing to enrol in the university.
These students may be sent prospectus and open day invites after reviewing
candidate information.
The selected, or conditionally selected and rejected
candidates files are uploaded back to UCAS through FTP and selected students are
exported to the university database for next semester.
A mobile application is required so senior students of the university can track and
welcome candidates on open day and show them around campus and mark their
attendance.
The following are the tasks in brief.
Remove the current web support request and create a new web to lead
CRM integration.
Connect with UCAS and download new leads
Assign all applications equally to recruitment team members.
Send Email Invites for open day.
Review each candidate Applications for selection
Upload Selected applicants to UCAS
Search for any student in the mobile application
Update Open day Campaign Attendance for student in mobile application

Reference

UC1001

User Story

Create Support Request

Function Brief

Create Support Request

Type

DET

RET

PET

LCS

IFPUG
UFP

Progressive
UFP

IPF

EI

1.00

1.8

UC1001

Create Support Request

Update Lead Records

ILF

30

UC1001

Create Support Request

Delete University Online Requistion form

EI

UC1002

Extract and Load new Leads

Parse and Load Lead Data To Salesforce

EI

UC1002

Extract and Load new Leads

Create UCAS Records

EIF

UC1003

Assign to Team Members Intake Queue

Create Assignment Rule for Lead Task

Distribution

EI

4.20

1.00

1.60

1.84

1.50

Reuse% Reuse FP Man Hours

30

1.00

1.2

1.8

100

1.84

2.4

DET Details

RET Details

1. UCAS Id, 2. Name, 3. Email, 4.

1. Sales
Phone, 5. Request

PET Details
1. Enter fields in salesforce
2. Generate Web-To-Lead Form
3. Insert generated content to
university portal

LCS Details

1. Address, 2. Annual Revenue, 3.

Campaign, 4.Company, 5. Created
By, 6. Data.com Key, 7.
Description, 8. do Not Call, 9.
Email, 10. Email Opt Out, 11. Fax,
12. Fax Opt Out, 13. Last
Modified By, 14. Last Transfer
#REF!
Date, 15. Lead Owner, 16. Lead
Source, 17. Lead Status, 18.
Mobile, 19. Name, 20. No. of
Employees, 21. Partner Account,
22. Phone, 23. Rating, 24. Title,
25. Website11 26. Industry

13

1. Primary Course Preference, 2.

Secondary Course Preference, 3.
Lead
Tertiary Course Preference, 4.
UCAS Id

1. UCAS Id, 2. Name, 3. Email, 4.

1. Sales
Phone, 5. Request

1. Enter fields in requisition form

2. Post form details as email to
intake department.

1.University Portal

10

1. UCAS Id, 2. Student Name, 3.

Phone, 4. Email, 5. Phone, 6.
Primary Course Preference, 7.
1. Sales
Secondary Course Preference,
8.Tertiary Course Preference

1. Clean data and validate

information,
2. Upsert Prospects records to
Lead records,
3. Upsert Selection records to
qualified Lead.

Openshift Dataloader, Salesforce

12

1. UCAS Id, 2. Student Name, 3.

Phone, 4. Email, 5. Primary
Course Preference, 6. Secondary
PROSPECTS, SELECTION
Course Preference, 7. Tertiary
Course Preference

1. Record Id, 2. Round Robin Id

1. Sales, 2. User

Reuse of existing FTP files.

1. Create new Auto-number

Record Id,
2. Calculate Round Robin as
Mod(Record Id, Number of
Members)
Salesforce
3. Create a queue in Users for
each Team Member.
4. Assign the lead to the
appropriate queue based on round
robin number.
1. Address, 2. Annual Revenue, 3.
Campaign, 4.Company, 5. Created
By, 6. Data.com Key, 7.
Description, 8. do Not Call, 9.
Email, 10. Email Opt Out, 11. Fax,
12. Fax Opt Out, 13. Last
Modified By, 14. Last Transfer
Date, 15. Lead Owner, 16. Lead
Source, 17. Lead Status, 18.
Mobile, 19. Name, 20. No. of
Employees, 21. Partner Account,
22. Phone, 23. Rating, 24. Title,
25. Website11 26. Industry, 27.
Primary Course Preference, 28.
Secondary Course Preference, 29.
Tertiary Course Preference, 30.
UCAS Id

13

1. Lead Record Id, 2. Round

Robin Id

Lead

2.4

16

1. Campaign Id, 2. Campaign

Name, 3. Template Id, 4. Lead
Email Address

1. Campaign, 2. Leads

2.4

12

1. UCMS Id, 2. Name, 3. Email ID,

Phone, 5. Approval Status, 6.
1. Leads
Review Comments, 7. Course
Approval

1. UCMS Id, 2. Name, 3. Email ID,

Phone, 5. Approval Status, 6.
APPLICATION
Review Comments, 7. Course
Approval

2.4

12

1. UCMS Id, 2. Name, 3. Email ID,

Phone, 5. Approval Status, 6.
1. Leads
Review Comments, 7. Course
Approval

1. Load and filter Closed Leads

from Salesforce
2. Convert data to CSV
1. OpenShift, 2. SalesForce, 3.
3. Create new FTP Connection to TqU FTP Server
TqU Server
4. Save CSV to Applications file.

4.00

1.2

16

1. UCAS Id, 2. Student Name, 3.

Primary Course Preference, 4.
1. Leads
Secondary Course Preference,
5.Tertiary Course Preference

1. Select Student
2. Update open day campaign
attendance marker

Salesforce

4.00

1.2

16

1. UCAS Id, 2. Student Name, 3.

Primary Course Preference, 4.
1. Leads, 2. Campaign
Secondary Course Preference,
5.Tertiary Course Preference

1. Select Student
2. Update open day campaign
attendance marker

Salesforce

4.00

1.2

16

1. UCAS Id, 2. Student Name, 3.

Primary Course Preference, 4.
1. Leads, 2. Enrollment
Secondary Course Preference,
5.Tertiary Course Preference

4.00

1.8

17

1. UCAS Id, 2. Student Name, 3.

1. Leads, 2. Contact
Phone, 4. Email, 5. Phone

1. Load approved students from

Leads
2. Create new contact Record for
Salesforce
each Lead
3. Send community portal login
details

4.00

1.8

17

1. UCAS Id, 2. Student Name, 3.

1. Leads
Phone, 4. Email, 5. Phone

1. Load Leads from web source

2. Send new Open day Invite or
Salesforce
prospectus
3. Update Status of Lead to closed

UC1003

Assign to Team Members Intake Queue

Update Lead Records

ILF

32

4.48

UC1004

Send Email Invites for open day

Create Open day Invites Email Template

EI

3.00

UC1005

Review Applications for selection

Review Applications for Processing

EO

1.47

UC1006

Upload APPLICATIONS file to FTP

Create Application Record

EIF

1.84

UC1006

Upload APPLICATIONS file to FTP

Upload Applications to FTP

EO

1.47

UC1007

Search Student

Search and display results

EO

UC1008

Update Openday Campaign Attendance

Create new Campaign Attendance Record

EO

UC1009

Export Applications to Enrolment Database Save approved students to Enrollment Database

EO

UC1010

Convert Approved Leads to Community

Portal Users

Manual conversion of approved leads to Contacts

EO

UC1011

Process Web Lead

Process and update web leads

EO

32

1.00

Reuse Details

Univesity Portal, Salesforce

1. Create new Email Campaign

2. Select all members eligible for
next Email Campaign
Salesforce
3. Select Email Template
4. Start Campaign.
1. Review application files
2. Post Review Comments
3. Accept/Reject Candidate
4. Approve/Reject Course
Preference

1. Load approved students from

Leads
2. Export records to Internal
Enrollment DB

Salesforce

1. Salesforce, 2. Enrollment

Questions

THANK YOU!