Function Point Analysis with case studies

1. Function Point Analysis
ISO/IEC 20926:2009
ARAF KARSH HAMID

2. Topics
2
1. Software Sizing Background
2. Function Point
3. Rules for Counting FP
4. Deep Dive - Function Point Analysis
5. Case Study
6. General Software Characteristics Details

3. History – Measurement Methodologies
3
• Lines of Code (Oldest)
• Use case based Software Sizing
• IPFUG Function Point Analysis
(ISO)

4. Need for Software Sizing
4
1. Estimation and Budgeting
2. Phasing Development Work
3. Prioritization of Work
4. Monitoring the Progress
5. Bidding for Projects
6. Allocating Testing Resources
7. To measure and Manage Productivity
8. Risk Assessment
9. Software Asset Valuation
10. CMMi Level 2 and 3 require that a valid sizing
method be used.

5. Software Sizing – Lines of Code
5
The easiest and historically the most common method in Sizing
Software project has been counting the number of lines of code
and / or the number of screens.
Advantages
Automation of the counting process can be done
Intuitive as the measurements are easily understood
Disadvantages
Lines of Code is language and the skill set of the developer
The coding phase is only around 30-35% of the actual software
development.
Lack of counting standards (What about comments, notes etc.?)

6. Lines of Code
6
• Language Dependent
• Skill dependent
• Unknown until written
• No Standards
• Function Points are better

7. History
7
1979 – Function Points introduced by Alan Albrecht
1984 – First FP guidelines
1986 – First IFPUG Board of directors
1994 – CPM Release 4.02003 ISO Standard
2003 – ISO Standard

8. Best in Class Software Companies
8
Best In Class
• 30% Requirement
• 35% Design
• 25% Coding
• 10% Testing
Worst In Class
• 10% Requirement
• 15% Design
• 37% Coding
• 38% Testing
• Higher Productivity
• Higher Quality
• Less over time
• Less Redundancy
• More Specialization
• Software Measurement Programs

9. Function point
9

10. Overview of Function Point
1. Measured from the users perspective
2. Technology Independent
3. Low Cost (Once the system is in place)
4. Repeatable
5. Works well with use cases
6. Answers lots of questions
7. Can be automated
10

11. Objectives of Function Point
Measures software by quantifying the
functionality requested by and provided to the
customer based primarily on logical design.
Measures software development and
maintenance independently of technology
used for implementation.
Measures software development and
maintenance consistently across all projects
and organizations.
11

12. Types of Function Point Counts
12
Development
All Phases through development
Forms a baseline
Enhancement
In Production, has a baseline
Count the size of the successive
enhancements
Application
In Production, no baseline
Forms a baseline

13. Function Points and CMM
13
SEI Capability
Maturity Model
1. INITIAL
Ad hoc
2. REPEATABLE
Basic management control
3. DEFINED
Process definition
4. MANAGED
Process measurement
5. OPTIMIZING
Process control
Process
Maturity
Levels
• Function Points are the
metric of choice for
many of the activities
required in the SEI
CMM Level 2
• In CMM, metrics
becomes a Key Process
Area in its own right

14. Major App Sizes (2010)
Applications Approximate Size in
Function Points
Star Wars Missile Defense 350,000
ERP (SAP, Oracle etc.,) 300,000
Microsoft Windows Vista 159,000
Microsoft Office 2007 98,000
Airline Reservation System 50,000
NASA Space shuttle 25,000
14

15. MajorAppSizes
Applications Function Points
1 Oracle 229,434
2 Windows 7 (all features) 202,150
3 Windows XP 66,238
4 Google Docs 47,668
5 Microsoft Office 2003 33,736
6 F15 Avionics / Weapons 23,109
7 Apple iPhone 19,366
8 Google Search Engine 18,640
9 Linux 17,505
10 Facebook 8,404
11 MapQuest 3,793
12 Microsoft Project 1,963
13 Google Android OS (Original Version 1,858
14 Mozilla Firefox 1,342
15 Java Compiler 1,185
16 Wikipedia 1,142
17 Twitter (Original 2009) 541 15

16. Changes to requirements
16
100 FPs 120 FPs 130 FPs 135 FPs
• State code input screen
changed (3 FPs)
• Interface to N&A file
added (10 FPs)
• N&A inquiry and state
code inquiry added (7
FPs)
• New regulatory
table added (10 FPs)
• Summary report
added (5 FPs)
Effort
Schedule
Cost
+ 1 month
+ 2 weeks
+ $5 K
+ .5 month
+ 1 week
+ $2.5 K
+ .25 month
+ 2.5 days
+ $1.25 K
Delivered
Application
Detail
Design
Functional
Design
Requirements
Impact
Source: International Function Point User Group 2001

17. Deep DIVE
FUNCTION POINT ANALYSIS
17

18. How to count Function Points?
18
Displays
Reports
Master Files Size
Reference
Files
Signals
Control Files

19. Steps in FP Counting
19
1. Determine Type of Count
2. Identify Counting Scope and Application
Boundary
3. Count Data Functions
4. Count Transaction Functions
5. Determine Unadjusted Function Points
6. Determine Value Adjustment Factor
7. Calculate Adjusted Function Point Count

20. FP - Functionalities
Data Functionality
◦ Internal Logical Files (ILF)
◦ External Interface Files (EIF)
20
• Transaction Functionality
• External Inputs (EI)
• External Outputs (EO)
• External Queries (EQ)

21. FP Data & Transaction Functionality
21
USER
ADD, CHG INVOICES PAYMENTS
USER
USER
PAYMENT
STATUS
USER
PAID
INVOICES
PURCHASE
ORDER INFO
PURCHASE
ORDER
SYSTEM
External Interface
File (EIF)
External Input (EI) External Input (EI)
External Query (EQ)
External Output (EO)
Internal Logical Files (ILF)
Payments
(Table)
Vendor
(Table)
Invoices
(Table)
Repository (Persistence Layer)
Accounts Payable App
Services Layer
APP BOUNDARY

22. Terms within ILF and EIF
22
Control Information
Control Information is data that influences an elementary process of the application
being counted. It specifies what, when, or how data is to be processed.
For example, someone in the payroll department establishes payment cycles to
schedule when the employees for each location are to be paid. The payment cycle, or
schedule, contains timing information that affects when the elementary process of
paying employees occurs.
User Identifiable
The term user identifiable 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).
For example, users and software developers agree that a Human Resources Application
will maintain and store Employee information in the application
Maintained
The term maintained is the ability to modify data through an elementary process.
Examples include, but are not limited to, add, change, delete, populate, revise, update,
assign, and create.

23. Elementary Process
23
An Elementary Process is the smallest unit of activity that is meaningful to the
user(s).
For example, a user requires the ability to add a new employee to the application.
The user definition of employee includes salary and dependent information. From
the user perspective, the smallest unit of activity is to add a new employee. Adding
one of the pieces of information, such as salary or dependent, is not an activity that
would qualify as an elementary process.
The elementary process must be self-contained and leave the business of the
application being counted in a consistent state.
For example, the user requirements to add an employee include setting up salary and
dependent information. If all the employee information is not added, an employee
has not yet been created. Adding some of the information alone leaves the business
of adding an employee in an inconsistent state. If both the employee salary and
dependent information is added, this unit of activity is completed and the business is
left in a consistent state.

24. Data Functions
24
Source: http://www.qpmg.com/fp-intro.htm
Internal Logical Files (ILF)
Logical group of data maintained by the application (Example
Employee File).
For example, a pilot may enter navigational data through a display
in the cockpit prior to departure. The data is stored in a file for use
and can be modified during the mission.
Therefore the pilot is responsible for maintaining the file that
contains the navigational information.
Logical groupings of data in a system, maintained by an end user
(and application), are referred to as Internal Logical Files (ILF).

25. Data Functions
25
Source: http://www.qpmg.com/fp-intro.htm
External Interface Files (EIF)
The second Data Function a system provides an end user is also
related to logical groupings of data. In this case the user is not
responsible for maintaining the data. The data resides in another
system and is maintained by another user or system. The user of
the system being counted requires this data for reference
purposes only.
For example, it may be necessary for a pilot to reference position
data from a satellite or ground-based facility during flight.
The pilot does not have the responsibility for updating data at
these sites but must reference it during the flight.
Groupings of data from another system that are used only for
reference purposes are defined as External Interface Files (EIF).

26. Transactional Functions
26
Source: http://www.qpmg.com/fp-intro.htm
These functions address the user's capability to access the data
contained in ILFs and EIFs. This capability includes maintaining, inquiring
and outputting of data. These are referred to as Transactional Functions.
External Inputs (EI)
This Transactional Function allows a user to maintain Internal Logical
Files (ILFs) through the ability to add, change and delete the data. For
example, a pilot can add, change and delete navigational information
prior to and during the mission.
In this case the pilot is utilizing a transaction referred to as an
External Input (EI). An External Input gives the user the capability to
maintain the data in ILF's through adding, changing and deleting its
contents.

27. Transactional Functions
27
Source: http://www.qpmg.com/fp-intro.htm
External Output (EO)
This Transactional Function gives the user the ability to produce outputs. For
example a pilot has the ability to separately display ground speed, true air
speed and calibrated air speed. The results displayed are derived using data
that is maintained and data that is referenced. In function point terminology
the resulting display is called an External Output (EO).
External Queries (EQ)
This Transactional Functions addresses the requirement to select and display
specific data from files. To accomplish this a user inputs selection information
that is used to retrieve data that meets the specific criteria.
In this situation there is no manipulation of the data. It is a direct retrieval of
information contained on the files. For example if a pilot displays terrain
clearance data that was previously set, the resulting output is the direct
retrieval of stored information. These transactions are referred to as External
Inquiries (EQ).

28. External Queries (EQ)
28
Input Side
• Click of a the mouse
• Search values
• Action keys (command
buttons)
• Error Messages
• Confirmation Messages
(searching)
• Clicking on the an action
key
• Scrolling
Recursive fields are
counted only once.
Output Side
• Values read from an internal
logical file or external interface file
• Color or Font changes on the
screen
• Error Messages
• Confirmation Messages
• Recursive fields are counted only
once.
The combined (unique) total input & output DET’s used when rating EQ.

29. FTRs, RETs & DETs
29
File Type Referenced (FTR)
A FTR is a file type referenced by a transaction. An FTR must also be an internal
logical file or external interface file.
Record Element Type (RET)
A RET is user recognizable sub group of data elements within an ILF or an EIF. It is
best to look at logical groupings of data to help identify them.
Data Element Type
A DET is a unique user recognizable, non-recursive (non-repetitive) field. A DET is
information that is dynamic and not static.
A dynamic field is read from a file or created from DET’s contained in a FTR.
Additionally, a DET can invoke transactions or can be additional information
regarding transactions. If a DET is recursive then only the first occurrence of the DET
is considered not every occurrence.
A data element can be either quantitative or qualitative. A quantitative data
element is data in numerical form. A qualitative data element is data not in
numerical form, but is in the form of text, photographs, sound bytes and so on.

30. Understanding DETs
30
Radio Buttons
Radio Buttons are treated as data
element types. Within a group of, a
frame, radio buttons the user has the
option of selecting only one radio button;
so only one data element type is counted
for all the radio buttons contained in the
frame.
Check Boxes
Check Boxes differ from radio buttons in
that more than one check box can be
selected at a time. Each check box, within
a frame, that can be selected should be
treated as a data element.
Command Buttons
Command buttons may specify an add,
change, delete or inquire action. A
button, like OK, may invoke several
different types of transactions.
Display of Graphical Images or Icons
A display of a graphical image is simply another
data element. An inventory application, for
example, may contain data about parts. It may
contain part name, supplier, size, and weight
and include a schematic image of the part. This
schematic is treated as a single data element.
Photographic Images
A photographic image is another data element,
and is counted as one. A human resource
application may display employee name, start
date, etc. and a photograph of the employee.
The photograph is treated the same as
employee name or employee start date. The
photograph is stored and maintained like any
other piece of information about the employee.
According to IFPUG counting rules, each command
button would be counted as a data element for the
action it invokes.

31. Understanding DETs
31
Error and Confirmation Messages
There are three types of messages that are generated in a GUI
application: error messages, confirmation messages and notification
messages. Error messages and confirmation messages indicate that
an error has occurred or that a process will be or have been
completed. They are not an elementary or independent process
alone, but they are part of another elementary process. A message
that would state, “zip code is required” would be an example of an
error message. A message that would state, “are you sure you want to
delete customer” is an example of a confirmation message.
Neither type of message is treated as a unique external output, but
each is treated as a data element for the appropriate transaction.

32. Understanding DETs
32
Notification Messages
On the other hand, a notification messages is a business type
message. A notification is an elementary process, has some
meaning to the business user and is independent of other
elementary processes. It is the basis of processing and a conclusion
being drawn.
For example, you may try to withdraw from an ATM machine more
money than you have in your account and you receive the dreaded
message, “You have insufficient funds to cover this transaction.”
This is the result of information being read from a file regarding
your current balance and a conclusion being drawn.
A notification message is treated as an External Output

33. Understanding RETs
33
A record element type (RET) is a user recognizable subgroup of data elements
within an ILF or EIF.
There are two types of subgroups:
Optional
Mandatory
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.
For example, in a Human Resources Application, information for an employee is added by entering some
general information. In addition to the general information, the employee is a salaried or hourly employee.
The user has determined that an employee must be either salaried or hourly. Either type can have
information about dependents. For this example, there are three subgroups or RETs as shown below:
Salaried employee (mandatory); includes general information
Hourly employee (mandatory); includes general information
Dependent (optional)

34. Rules for Counting FP
34

35. Internal Logical File (ILF) Rules
35
All the following counting rules must apply for the
information be counted as an Internal Logical File
(ILF)
• The group of data or control information is
logical and user identifiable
• The group of data is maintained through an
elementary process within the application
boundary being counted.

36. External Interface File (EIF) Rules
36
All the following counting rules must apply for the
information be counted as an External Interface File (EIF)
• The group of data or control information is logical and
user identifiable
• The group of data is referenced by, and external to,
the application being counted.
• The group of data is NOT MAINTAINED by the
application being counted.
• The group of data is maintained in an ILF of another
application.

37. Data Element Type (DET) Rules
37
A Data Element Type (DET) is a UNIQUE user recognizable, non repeated field.
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.
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.

38. Data Element Type (DET) Rules
38
A Data Element Type (DET) is a UNIQUE user recognizable, non repeated field.
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.
For example, Application X maintains and/or references an ILF that contains
a SSN, Name, Street Name, Mail Stop, City, State, and Zip. Application Z
maintains and/or references the Name, City, and State.
• Application X would count seven DETs;
• Application Z would count three DETs.

39. Data Element Type (DET) Rules
39
A Data Element Type (DET) is a UNIQUE user recognizable, non repeated field.
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, an employee's information is maintained
on an ILF. The employee’s job name is included as part of the employee's
information. 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.

40. Record Element Type (RET) Rules
40
A record element type (RET) is a user recognizable subgroup
of data elements within an ILF or EIF.
One of the following rules applies when counting RETs
Count a RET for each optional or mandatory subgroup of
the ILF or EIF.
Or
If there are no subgroups, count the ILF or EIF as one
RET.

41. Linkingeverything……
Function Type
Functional Complexity
Rating
Record Element
Type (RET)
File Type
Referenced (FTR)
Data Element
Type (DET)
Low Average High
Data Functions
• Internal Logic Files (ILF) x7 x10 x15 Yes Yes
• External Interface Files (EIF) x5 x7 x10 Yes Yes
Transaction Functions
• External Inputs (EI) x3 x4 x6 Yes Yes
• External Outputs (EO) x4 x5 x7 Yes Yes
• External Queries (EQ) x3 x4 x6 Yes Yes
41
Transaction Functions Transaction Data Element Types (DETs)
External Inputs (EI) Data Input Fields, Error Messages, Calculated values, Buttons
External Outputs (EO) Data Fields on a Report, Calculated Values, Error Messages, Column
Headings (from ILF). EO also can an Input (EI) side & output side
External Queries (EQ) Input Side, Field used to search by, Buttons. Output side displayed fields on
the screen.

42. Unadjusted Function Point Calculator
42
Component Type
Complexity of Components
Low Average High L+A+H Total
External Inputs 3 x3 9 1 x4 4 1 x6 6 9+4+6 19
External Outputs 5 x4 20 x5 1 x7 7 20+0+7 27
External Queries 5 x3 18 x4 1 x6 6 18+0+6 24
Internal Logical Files 1 x7 7 2 x10 20 1 x15 15 7+20+15 42
External Interface Files x5 x7 1 x10 10 0+0+10 10
Total Unadjusted Function Points 122

43. General Software Characteristics
43
General Software
Characteristics
Brief Description
1 Data Communication
How many communication facilities are there to aid in the transfer or exchange of information with
the application or system?
2 Distributed Data Processing How are distributed data and processing functions handled?
3 Performance Did the user require response time or throughput?
4 Heavily Used Configuration How heavily used is the current hardware platform where the application will be executed?
5 Transaction Rate How frequently are transactions executed daily, weekly, monthly, etc.?
6 Online Data Entry What percentage of the information is entered On-Line?
7 End User Efficiency Was the application designed for end-user efficiency?
8 Online Update How many ILF’s are updated by On-Line transaction?
9 Complex Processing Does the application have extensive logical or mathematical processing?
10 Reusability Was the application developed to meet one or many user’s needs?
11 Installation Ease How difficult is conversion and installation?
12 Operational Ease How effective and/or automated are start-up, back up, and recovery procedures?
13 Multiple Sites
Was the application specifically designed, developed, and supported to be installed at
multiple sites for multiple organizations?
14 Facilitate Change Was the application specifically designed, developed, and supported to facilitate change?
15 Security Framework Security Framework for all Input validations to check Cross Site Scripting, SQL Injection etc.
16 Multi Language Support Multi Language Support for the App
17 Multi Form Factors Application will be available in Multiple Form factors like Web, Smart Phone, Tablet etc

44. Calculations
FP = UFP X VAF
FUNCTION POINT = UNADJUSTED FP X VALUE
ADJUSTMENT FACTOR
44

45. When to count Function Points
45
Corrective
Maintenance
Proposal Design QA DeliveryRequirements Development
SIZING
Initial User
Requirements
Initial Technical
Requirements
Final Functional
Requirements
Feasibility
Study
SIZING
Change
Request
Scope
Adjustment
SIZING
SIZING SIZING

46. Calculating Unadjusted
Function Points (UFP)
46
External Inputs (EI)
External Outputs (EO)
FTR Data Element Type (DET)
1-5 6-19 >19
<2 Low (4) Low (4) Ave (5)
2 or 3 Low (4) Ave (5) High (7)
>3 Ave (5) High (7) High (7)
External Queries (EQ)
FTR Data Element Type (DET)
1-5 6-19 >19
<2 Low (3) Low (3) Ave (4)
2 or 3 Low (3) Ave (4) High (6)
>3 Ave (4) High (6) High (6)
FTR Data Element Type (DET)
1-4 5-15 >15
<2 Low (3) Low (3) Ave (4)
2 Low (3) Ave (4) High (6)
>2 Ave (4) High (6) High (6)
Internal Logical File (ILF)
RET Data Element Type (DET)
1-19 20-50 >51
1 Low (7) Low (7) Ave (10)
2 - 5 Low (7) Ave (10) High (15)
>5 Ave (10) High (15) High (15)
External Interface Files (EIF)
RET Data Element Type (DET)
1-19 20-50 >51
1 Low (5) Low (5) Ave (7)
2 - 5 Low (5) Ave (7) High (10)
>5 Ave (7) High (10) High (10)
Unadjusted Function Points in brackets (x) based on FTR / RET & DET
UFP = Σ (EI+EO+EQ+ILF+EIF)

47. Value Adjustment Factor (VAF)
47
Degree of Influence (Di)
0 Not Present, or No Influence
1 Incidental Influence
2 Moderate Influence
3 Average Influence
4 Significant Influence
5 Strong Influence Throughout
The Degree of influence range on a
scale of Zero to Five, from No
Influence to Strong Influence.
17
VAF = 0.65 + [( ΣDi) x 0.01]
i=1
New Additions over IFPUG Value Adjustment Factors – Points : 15, 16 & 17
Based on 14+3 General System Characteristics
User Business Constraints Independent of Technology
1. Data Communication
2. Distributed Data Processing
3. Performance
4. Heavily Used Configuration
5. Transaction Rate (Frequency of Transaction)
6. Online Data Entry
7. End User Efficiency
8. Online Update (How many ILF are updated using
Online transaction)
9. Complex Processing (Extensive Logical or
Mathematical Processing)
10. Reusability
11. Installation Ease
12. Operational Ease (Start-up, Back & Recovery Process)
13. Multiple Sites (Multi-Tenant)
14. Facilitate Change
15. Security Framework
16. Multi Language Support
17. Multi Form Factors
Adjusts FP count by up to + / - 50%

48. Standard Function Point
48
The final Function Point Count is obtained
by multiplying the Unadjusted Function
Point times the Value Adjustment Factor.
FP = UFP x VAF
Where
UFP = Unadjusted Function Point
VAF = Value Adjustment Factor

49. Function Points Per Person Month
49
Platform FP / Person / Month
Client Server 15
Main Frame 13
Web 22
E-Business Web 12
Vendor Packages 19
Data Warehouse 11
Language Hours / FP
ASP* 0.61
Visual Basic 0.85
Java 10.6
SQL 10.8
C++ 12.4
C 13.0
C# 15.5
PL/1 14.2
COBOL 16.8
ABAP 19.9
* refers to classic ASP. Included for comparison
purposes. (Courtesy of ISBSG.)
ISBSG, a non-profit software research group, has gathered
data on 6,000 projects, using functional size as the key sizing
measure. From this data, they can see how many hours it took
to take each project to completion and how those hours
mapped to languages, on projects that were primarily written
in one language
Source : http://www.drdobbs.com/jvm/the-comparative-productivity-of-programm/240005881

50. Costing for Simple SOA App
50
A : Role B : Price by
Role in
Dollars
C : Effort by
Role in the
Project (Hours)
D : %
(C*100/total
hours. I.e., 1000
hours)
E : Price by Role
in Dollars
(B * C)
Manager $100 50 05 $5,000
SOA Analyst $80 250 25 $20,000
SOA Architect $90 200 20 $18,000
SOA Developer $50 350 35 $17,500
SOA QA $40 50 05 $2,000
SOA Governance
Specialist
$80 50 05 $4,000
SOA Security
Specialist
$70 50 05 $3,500
1000 100 $70,000
100 FP * 10 FP per hour = 1000 Man hours

51. CASE STUDY
51
1. Case 1: Simple Form with 1 Table
2. Case 2: Simple Form with 4 Tables
3. Case 3: Shopping Portal

52. External Inputs (EI) – Customer
FTR Data Element Type (DET)
1-4 5-15 >15
<2 Low (3) Low (3) Ave (4)
2 Low (3) Ave (4) High (6)
>2 Ave (4) High (6) High (6)
Data Element
Types (DET)
1 Customer Name
2 Contact
3 Alt. Contact
4 Bill To
5 Phone
6 Fax
7 Alt. Phone
8 Ship To
9 Type
10 OK Button
11 Cancel Button
12 Save Message
13 Error Message
File Type
Reference (FTR)
1 Customer File
Total UFP
Customer UI – Add : 1 Table
Internal Logical File (ILF)
RET Data Element Type (DET)
1-19 20-50 >51
1 Low (7) Low (7) Ave (10)
2 - 5 Low (7) Ave (10) High (15)
>6 Ave (10) High (15) High (15)
Name Type RET DET FP
1 Customer ILF 1 12 7
Total ILF Function Points 7
Total UFP = EI + ILF = 7 + 3 = 10
EI = 1 FTR, 13 DET = 3 FP
10
1
52

53. External Inputs (EI) – Customer
FTR Data Element Type (DET)
1-4 5-15 >15
<2 Low (3) Low (3) Ave (4)
2 Low (3) Ave (4) High (6)
>2 Ave (4) High (6) High (6)
Data Element
Types (DET)
1 Customer Name
2 Contact
3 Alt. Contact
4 Bill To
5 Phone
6 Fax
7 Alt. Phone
8 Ship To
9 Type
10 OK Button
11 Cancel Button
12 Save Message
13 Error Message
File Type
Reference (FTR)
1 Customer File
2 Contact File
3 Bill To File
4 Ship To File
Total UFP
Customer UI – Add : 4 Tables
Internal Logical File (ILF)
RET Data Element Type (DET)
1-19 20-50 >51
1 Low (7) Low (7) Ave (10)
2 - 5 Low (7) Ave (10) High (15)
>6 Ave (10) High (15) High (15)
Name Type RET DET FP
1 Customer ILF 1 12 7
2 Contact ILF 1 21 7
3 Billing ILF 1 10 7
4 Shipping ILF 1 12 7
Total ILF Function Points 28
Total UFP = EI + ILF = 28 + 6 = 34
EI = 4 FTR, 13 DET = 6 FP
34
2
53

54. Total Function Points
54
17
VAF = 0.65 + [( Σ Di) x 0.01]
i=1
VAF =
0.65 + 0.64 =1.29
FP = UFP x VAF = 34 x 1.29 = 43.86
FP = 44
Total Function Points and Effort Estimation
FP = UFP x VAF = 10 x 1.29 = 12.9
FP = 13
1
2
Effort Estimation Java = 10.6 Hours / FP
13 * 10.6
= 137 Hours
44 * 10.6
= 466 Hours

55. General Software Characteristics
55

56. Value Adjustment Factor (VAF)
Based on 14+1 General System Characteristics
User Business Constraints Independent of Technology
1. Data Communication
2. Distributed Data Processing
3. Performance
4. Heavily Used Configuration
5. Transaction Rate (Frequency of Transaction)
6. Online Data Entry
7. End User Efficiency
8. Online Update (How many ILF are updated using Online
transaction)
9. Complex Processing (Extensive Logical or Mathematical
Processing)
10. Reusability
11. Installation Ease
12. Operational Ease (Start-up, Back & Recovery Process)
13. Multiple Sites (Multi-Tenant)
14. Facilitate Change
15. Security Framework
Adjusts FP count by up to + / - 40%
56
Degree of Influence (Di)
0 Not Present, or No Influence
1 Incidental Influence
2 Moderate Influence
3 Average Influence
4 Significant Influence
5 Strong Influence Throughout
The Degree of influence range on a
scale of Zero to Five, from No
Influence to Strong Influence.
15
VAF = 0.65 + [( ΣDi) x 0.01]
i=1

57. The data and control information used in the application are sent or received over
communication facilities. Terminals connected locally to the control unit are considered to
use communication facilities. Protocol is a set of conventions, which permit the transfer, or
exchange of information between two systems or devices. All data communication links
require some type of protocol.
57
1. Data Communications
Score As Description to Determine Degree of Influence
0 Application is pure batch processing or a standalone PC.
1 Application is batch but has remote data entry or remote printing.
2 Application is batch but has remote data entry and remote printing.
3
Application includes online data collection or TP (teleprocessing) front end to a batch
process or query system.
4
Application is more than a front-end, but supports only one type of TP communications
protocol.
5
Application is more than a front-end, and supports more than one type of TP
communications protocol.
Comments:
TCP/IP (Transmission Control Protocol/Internet Protocol). TCP/IP provides a common language for
interoperation between networks that use a variety of local protocols (Ethernet, Netware, AppleTalk,
DECnet and others) are examples of TP.
An application that allows query of application via a web based solution and local access would receive a
value of 3.
An application that allows for the update of ILF’s via the Internet and local update would receive a value of
a 5.

58. Distributed data or processing functions are a characteristic of the
application within the application boundary.
58
2. Distributed Data Processing
Score As Description to Determine Degree of Influence
0
Application does not aid the transfer of data or processing function between
components of the system.
1
Application prepares data for end user processing on another component of the system
such as PC spreadsheets and PC DBMS.
2
Data is prepared for transfer, then is transferred and processed on another component
of the system (not for end- user processing).
3 Distributed processing and data transfer are online and in one direction only.
4 Distributed processing and data transfer are online and in both directions.
5
Processing functions are dynamically performed on the most appropriate component of
the system.
Comments:
Copying files from a mainframe to a local PC or copy files from an Internet or intranet
would receive a value of 2.
Reading via a client or via Internet or intranet would receive a value of 3. Reading and
updating via Internet or intranet would receive a value of 4.
Depending on available resources, the application processes either local, on server, on
intranet or Internet application would receive a value of 5.

59. Application performance objectives, stated or approved by the user, in either
response or throughput, influence (or will influence) the design,
development, installation, and support of the application.
59
3. Performance
Score As Description to Determine Degree of Influence
0 No special performance requirements were stated by the user.
1
Performance and design requirements were stated and reviewed but no special actions
were required.
2
Response time or throughput is critical during peak hours. No special design for CPU
utilization was required. Processing deadline is for the next business day.
3
Response time or throughput is critical during all business hours. No special design for
CPU utilization was required. Processing deadline requirements with interfacing systems
are constraining.
4
In addition, stated user performance requirements are stringent enough to require
performance analysis tasks in the design phase.
5
In addition, performance analysis tools were used in the design, development, and/or
implementation phases to meet the stated user performance requirements.
Comments:
Again for a client/server or for internet/intranet application this remains the same.

60. A heavily used operational configuration, requiring special design considerations,
is a characteristic of the application. For example, the user wants to run the
application on existing or committed equipment that will be heavily used.
60
4. Heavily used Configuration
Score As Description to Determine Degree of Influence
0 No explicit or implicit operational restrictions are included.
1
Operational restrictions do exist, but are less restrictive than a typical
application. No special effort is needed to meet the restrictions.
2 Some security or timing considerations are included.
3
Specific processor requirements for a specific piece of the application
are included.
4
Stated operation restrictions require special constraints on the
application in the central processor or a dedicated processor.
5
In addition, there are special constraints on the application in the
distributed components of the system.
Comments
Does this application share hardware that is busy?.
For example, an application that shares a server with 5 other applications would need to be optimized
because it shares resources with 4 other applications.

61. The transaction rate is high and it influenced the design, development,
installation, and support of the application.
61
5. Transaction Rate
Score As Description to Determine Degree of Influence
0 No peak transaction period is anticipated.
1
Peak transaction period (e.g., monthly, quarterly, seasonally,
annually) is anticipated.
2 Weekly peak transaction period is anticipated.
3 Daily peak transaction period is anticipated.
4
High transaction rate(s) stated by the user in the application
requirements or service level agreements are high enough to require
performance analysis tasks in the design phase.
5
High transaction rate(s) stated by the user in the application
requirements or service level agreements are high enough to require
performance analysis tasks and, in addition, require the use of
performance analysis tools in the design, development, and/or
installation phases.

62. Online data entry and control functions are provided in the application.
62
6. Online Data Entry
Score As Description to Determine Degree of Influence
0 All transactions are processed in batch mode.
1 1% to 7% of transactions are interactive data entry.
2 8% to 15% of transactions are interactive data entry.
3 16% to 23% of transactions are interactive data entry.
4 24% to 30% of transactions are interactive data entry.
5 More than 30% of transactions are interactive data entry.

63. 63
7. End User Efficiency
• Navigational aids (for example,
function keys, jumps,
dynamically generated menus)
• Menus
• Online help and documents
• Automated cursor movement
• Scrolling
• Remote printing (via online
transactions)
• Pre-assigned function keys
• Batch jobs submitted from
online transactions
• Cursor selection of screen data
• Heavy use of reverse video,
highlighting, colors underlining, and
other indicators
• Hard copy user documentation of
online transactions
• Mouse interface
• Pop-up windows.
• As few screens as possible to
accomplish a business function
• Bilingual support (supports two
languages; count as four items)
• Multilingual support (supports more
than two languages; count as six
items)
The online functions provided emphasize a design for end-user efficiency. The design
includes:

64. 64
7. End User Efficiency
Score As Description to Determine Degree of Influence
0 None of the above.
1 One to three of the above.
2 Four to five of the above.
3
Six or more of the above, but there are no specific user requirements
related to efficiency.
4
Six or more of the above, and stated requirements for end- user
efficiency are strong enough to require design tasks for human factors
to be included (for example, minimize key strokes, maximize defaults,
use of templates).
5
Six or more of the above, and stated requirements for end- user
efficiency are strong enough to require use of special tools and
processes to demonstrate that the objectives have been achieved.

65. The application provides online update for the internal logical files.
65
8. Online Update
Score As Description to Determine Degree of Influence
0 None
1
Online update of one to three control files is included. Volume of
updating is low and recovery is easy
2
Online update of four or more control files is included. Volume of
updating is low and recovery easy.
3 Online update of major internal logical files is included.
4
In addition, protection against data lost is essential and has been
specially designed and programmed in the system.
5
In addition, high volumes bring cost considerations into the recovery
process. Highly automated recovery procedures with minimum
operator intervention are included.

66. 66
9. Complex Processing
Score
As
Description to Determine Degree of
Influence
0 None of the above.
1 Any 1 of the above
2 Any 2 of the above
3 Any 3 of the above
4 Any 4 of the above
5 All 5 of the above
• Sensitive control (for example, special
audit processing) and/or application
specific security processing
• Extensive logical processing
• Extensive mathematical processing
• Much exception processing resulting in
incomplete transactions that must be
processed again, for example,
incomplete ATM transactions caused by
TP interruption, missing data values, or
failed edits
• Complex processing to handle multiple
input/output possibilities, for example,
multimedia, or device independence
Complex processing is a characteristic of the application. The following components are
present.

67. 67
The application and the code in the application have been specifically
designed, developed, and supported to be usable in other applications.
10. Reusability
Score As Description to Determine Degree of Influence
0 No reusable code.
1 Reusable code is used within the application.
2
Less than 10% of the application considered more than one user's
needs.
3
Ten percent (10%) or more of the application considered more than
one user's needs.
4
The application was specifically packaged and/or documented to ease
re-use, and the application is customized by the user at source code
level.
5
The application was specifically packaged and/or documented to ease
re-use, and the application is customized for use by means of user
parameter maintenance.

68. 68
Conversion and installation ease are characteristics of the application. A
conversion and installation plan and/or conversion tools were provided and
tested during the system test phase.
11. Installation base
Score As Description to Determine Degree of Influence
0
No special considerations were stated by the user, and no special setup is required
for installation.
1
No special considerations were stated by the user but special setup is required for
installation.
2
Conversion and installation requirements were stated by the user, and conversion
and installation guides were provided and tested. The impact of conversion on the
project is not considered to be important.
3
Conversion and installation requirements were stated by the user, and conversion
and installation guides were provided and tested. The impact of conversion on the
project is considered to be important.
4
In addition to 2 above, automated conversion and installation tools were provided
and tested.
5
In addition to 3 above, automated conversion and installation tools were provided
and tested.

69. 69
Operational ease is characteristic of the application. Effective start-up, back-up, and
recovery procedures were provided and tested during the system test phase. The
application minimizes the need for manual activities, such as tape mounts, paper
handling, and direct on-location manual intervention.
12. Operational ease
Score As Description to Determine Degree of Influence
0
No special operational considerations other than the normal back-up procedures
were stated by the user
1 – 4
One, some, or all of the following items apply to the application. Select all that
apply. Each item has a point value of one, except as noted otherwise.
Effective start-up, back-up, and recovery processes were provided, but operator
intervention is required.
Effective start-up, back-up, and recovery processes were provided, but no operator
intervention is required (count as two items).
The application minimizes the need for tape mounts.
The application minimizes the need for paper handling.
5
The application is designed for unattended operation. Unattended operation means
no operator intervention is required to operate the system other than to start up or
shut down the application. Automatic error recovery is a feature of the application.

70. 70
The application has been specifically designed, developed, and
supported to be installed at multiple sites for multiple organizations.
13. Multiple Sites
Score As Description to Determine Degree of Influence
0
User requirements do not require considering the needs of more than one
user/installation site.
1
Needs of multiple sites were considered in the design, and the application is
designed to operate only under identical hardware and software
environments.
2
Needs of multiple sites were considered in the design, and the application is
designed to operate only under similar hardware and/or software
environments.
3
Needs of multiple sites were considered in the design, and the application is
designed to operate under different hardware and/or software environments.
4
Documentation and support plan are provided and tested to support the
application at multiple sites and the application is as described by 1 or 2.
5
Documentation and support plan are provided and tested to support the
application at multiple sites and the application is as described by 3.

71. 71
14. Facilitate Change
Score As Description to Determine Degree of Influence
0 None of the above.
1 Any 1 of the above
2 Any 2 of the above
3 Any 3 of the above
4 Any 4 of the above
5 All 5 of the above
The application has been specifically designed, developed, and supported to facilitate change.
• The following characteristics can apply for the application:
• Flexible query and report facility is provided that can handle simple requests; for example, and/or
logic applied to only one internal logical file (count as one item).
• Flexible query and report facility is provided that can handle requests of average complexity, for
example, and/or logic applied to more than one internal logical file (count as two items).
• Flexible query and report facility is provided that can handle complex requests, for example, and/or
logic combinations on one or more internal logical files (count as three items).
• Business control data is kept in tables that are maintained by the user with online interactive
processes, but changes take effect only on the next business day.
• Business control data is kept in tables that are maintained by the user with online interactive
processes, and the changes take effect immediately (count as two items).

72. 72
15. Security Framework
Score As Description to Determine Degree of Influence
0 None of the above.
1 Any 1 of the above
2 Any 2 of the above
3 Any 3 of the above
4 Any 4 of the above
5 All of the above
The application has been specifically designed, developed with a strong security
framework.
• User Authentication
• Role Based Access Control
• Label Based Access Control
• Protect the App from Session Hijacking, Data Validations for SQL Injection,
Cross site scripting (Protection against vulnerabilities defined by OWASP)
• Multi Factor Authentication
• Log Management and Exception Handling

73. 73
THANK YOU
Araf Karsh Hamid
email : araf.karsh@ozazo.com | araf.karsh@metamagic.in
Social : arafkarsh | Skype, Facebook, LinkedIn, Twitter, G+
Phone : +91.999.545.8627 | http://www.metamagic.in/

74. Backup slides
74

75. Understanding External Inputs (EI)
The following words are associated with External Inputs or Inputs
Add Memorize (Ad)
Activate Modify (Change)
Amend (Changed & Delete) Override (Change)
Cancel Post (Add, Change & Delete)
Change Remove (Delete)
Convert (Change) Reactivate (Change)
Create (Add) Remit
Delete Replace (Change)
De-assign Revise (Change and Delete)
Disable Save (Add, Change or Delete)
Disconnect Store (Add)
Enable Suspend (Change or Delete)
Edit (Change) Submit (Add, Change or Delete)
Insert (Add and Change) Update (Add, Change or Delete)
Maintain (Add, Change or Delete)
75