What is Function Point Analysis? Learn more about this software sizing technique!

1. Function Point Analysis:
An Overview
David Herron
David Consulting Group
d.herron@davidconsultinggroup.com

2. International Function Point Users Group
• Function Points were introduced in 1979 by A. Albrecht, IBM,
at joint Share/ Guide Conference
• IFPUG chartered in 1986
• IFPUG Purpose
• To promote and encourage use of Function Points
• To develop consistent and accurate counting guidelines
• Maintains Public Standard for Sizing Software (CPM)
• Benefits:
• Networking with other counters
• Management Reporting
• Research projects
• Website
• Certifications for Function Point Methodology
©2012 David Consulting Group 1

3. Function Point History
• Now used world-wide in North America, Central
America, South America, Australia, Europe, and Asia
• Recognized Functional Size Measure for ISO Standards
• Functional size measurement (FSM) method which is an
International Standard in compliance with ISO/IEC 14143-
1:2007
• IFPUG White Papers published on a variety of
measurement-related topics
• IFPUG CPM Version 4.3 issued in 2009, effective 2010
• IFPUG - Certifications in FPA and Software Measurement
• ISMA - Fall Conferences on Metrics and Measurement
• Website : www.ifpug.org
©2012 David Consulting Group 2

4. Why Function Point Analysis?
Function Point Analysis is the method for measuring
functional size as defined within the IFPUG FSM Method.
• Standardized method for measuring the functionality
delivered to an end user
• Consistent
• Available early in the lifecycle
• Acceptable level of accuracy
• Meaningful internally and externally
FSM is accomplished using the information in a language that is
common to both user(s) and developer(s).
IFPUG FSM Method is the major global functional sizing methodology.
©2012 David Consulting Group 3

5. What is (are) Function Points?
• Unit of measure for functional size as defined within the
IFPUG Functional Size Measurement (FSM) Method
• Standard method for quantifying the software deliverable
based upon the user view
• User is any person or thing that communicates or interacts
with the software at any time
• User View is the Functional User Requirements as
perceived by the user
• Functional user requirements are a subset of user
requirements: requirements that describe what the
software shall do, in terms of tasks and services
©2012 David Consulting Group 4

6. Functional vs. Non- Functional
Requirements
Functional
• Data Transfer (Input customer data, send control signal, send transactions
from one system to another)
• Data Transformation (Calculate bank interest; derive average temperature; use
billing data to produce invoice totals)
• Data Storage (Store customer order; record temperature over time; store
control parameters to drive data)
• Data Retrieval (List current employees; retrieve satellite position; display a
report of employee dependents)
Non-Functional
• Quality Constraints (Usability, Reliability, Efficiency, Portability)
• Organizational Constraints (locations for operations, target
hardware, compliance to standards)
• Environmental Constraints (interoperability, security, privacy, safety)
• Implementation constraints (development language, delivery schedule)
©2012 David Consulting Group 5

7. What Do We Count? The Logical View.
Function Points looks at Vs. Physical View
the logical View
Functionality
[“The ability to”] Lines of code or
programs
Logically grouped stores of user data Databases or
[Data in 3rd normal form] Tables
Elementary processes Physical
[complete function, e.g., wizard] transactions
(screens)
Typically the user requirements reflect the logical view
©2012 David Consulting Group 6

8. What Do We Count?
INPUT FILES AND INPUT
TRANSACTIONS APPLICATION
(BATCH INTERFACES) BOUNDARY
OUTPUT FILES
AND OUTPUT
TRANSACTIONS
(BATCH INTERFACES)
SCREENS INTERNAL LOGICAL FILES
(ADDS, CHANGES, (TABLES, DATA FILES,
DELETES, QUERIES) CONTROL FILES) OTHER OUTPUTS
•REPORTS
•FILES
•XML
•VIEWS
CONTROL INFORMATION •FICHE
•TAPE
•DISKETTES
EXTERNAL •LETTERS
TABLES & FILES REFERENCED •NOTICES
from other applications •ALARMS
(Not Maintained)
©2012 David Consulting Group 7

9. What Do We Count? The Logical View.
External
External External Inquiry
Input (EI) Output (EQ)
(EO)
External
Input (EI) Internal Logical External
File (ILF) Interface File
Other (EIF)
Applications Internal Logical
File (ILF)
Other
Applications
External
Output (EO) Application
Boundary
©2012 David Consulting Group 8

10. How Do We Count?
• Gather available documentation
• Determine the counting scope, boundaries and identify functional user
requirements
• Identify and classify the base functional components
– Measure the data functions
• Internal Groupings of data called Internal Logical Files (ILF)
• External Groupings of data or External Interface Files (EIF)
– Measure the transactional functions
• External Inputs (EI)
• External Outputs (EO)
• External Inquires (EQ)
– Each function is assigned a functional complexity (L-A-H) and a weight
(FPs)
• Calculate the functional size
• Document the Function Point Count
• Report the result of the Function Point Count
©2012 David Consulting Group 9

11. Gather Available Documentation
• Should describe the functionality delivered by the software
or the functionality that is impacted by the software project
that is being measured
• Sufficient to conduct the count, or have access to subject
matter experts who are able to provide additional
information to address gaps in the documentation
• Requirements, data/object models, class diagrams, data
flows, use cases, process descriptions, report
layouts, screen layouts, user manuals
©2012 David Consulting Group 10

12. Scope and Boundary
• An application boundary is a conceptual interface between
the software under study and its users.
• Scope of a project could include multiple applications.
• A functional size would be calculated for each affected
application, in perspective to its boundary, thereby
producing its own count
• All affected application counts would be compiled to
produce the total project count.
©2012 David Consulting Group 11

13. Identify, Classify, Calculate
1. Identity and classify system components that are user
identifiable - files, reports, inputs, outputs, transactions
(System functions)
2. Classify system components into base functional
components categories. {Report could be an External
Output}
3. Measure each entity by applying a complexity rating (low,
average, high) and a weight (in function points). {High
Output = 7 FPs}
4. Calculate: Add all the weights together to get an
(unadjusted) function point count
©2012 David Consulting Group 12

14. Component Complexity & Weights
• FP Counting is based on Identification Rules and
Complexity Rules (CPM)
• Components are assessed based upon complexity
according to the rules
Complexity
Components: Low Avg. High Total
Internal Logical File (ILF) __ x 7 __ x 10 __ x 15 ___
External Interface File (EIF) __ x 5 __ x 7 __ x 10 ___
External Input (EI) __ x 3 __ x 4 __ x 6 ___
External Output (EO) __ x 4 __ x 5 __ x 7 ___
External Inquiry (EQ) __ x 3 __ x 4 __ x 6 ___
©2012 David Consulting Group 13

15. What Can We Count?
Any system that has inputs or outputs and has
and/or uses data or control information.
• Installed application: Baseline (or application) count
• Development project: New system or subsystem
• Enhancement project: Add, change or delete to
present system (includes minor enhancements)
• Non-functional (technical) requirements
are not countable for some types of maintenance
©2012 David Consulting Group 14

16. What Can We Count?
Enhancement vs. Maintenance
• Adaptive Maintenance – Software maintenance performed to make
a computer program usable in a changed environment
– Includes modifications to meet new or changing business or technical
requirements
– Initiated by business requests (user requests that may be functional or non-
functional requirements)
– “Enhancement” requests are a subset of this group
• Corrective Maintenance – Software maintenance performed to
correct faults in hardware or software
– Includes defect repair
– Ensures that previously delivered functionality performs as required
– Effort should be attributed to the original project that introduced the defect
• Perfective Maintenance – Software maintenance performed to
improve the performance, maintainability, or other attributes of a
computer program
– Includes system upgrades, performance optimization, platform service
agreement maintenance
– No business functionality – typically non-functional requirements
©2012 David Consulting Group 15

17. What Can We Count?
Enhancement vs. Maintenance
• Function Point Analysis is applicable to a subset of
Adaptive Maintenance
• Function Point Analysis should not be used to size
Perfective or Corrective Maintenance work.
• Mixing enhancement work with maintenance work can be
expedient or necessary, even efficient, but the hours must
be tracked separately
• For accurate metrics, separation of work effort is
necessary
• Preventative and/or corrective maintenance have zero
function points
• Packing into releases and apportioning releases is usually
the most manageable approach
©2012 David Consulting Group 16

18. Using
FP WHEN Can We Count?
PROPOSAL DESIGN CONSTRUCTION TESTING DELIVERY CORRECTIVE
REQUIREMENTS
MAINTENANCE
Initial User
Feasibility Requirements Function Function Function
Study Points Points
Points
Initial Revised Actual
Technical Estimate Size
Requirements
Counted Counted
Size can be Size can be
Life Cycle Phase approximated measured?
Final
?
Functional
Requirements
Proposal Yes No
Requirements Yes Yes
Design Yes Yes
Construction Yes Yes
Function
Delivery Yes Yes
Points Corrective Yes Yes
Maintenance
Early
Estimate
Approximated
©2012 David Consulting Group 17

19. Why Do We Count? – Benefits of FPA
• Requirements Management. A tool to determine the benefit of an application
to an organization by counting functions that specifically match functional
requirements
• Benchmarking. Measure software development and maintenance activities
independently of technology used for implementation for comparisons
• Increase Process Capability.
– Metrics. Provide a consistent, normalized measure across various
projects, organizations and technology platforms to support performance
(quality and productivity) analysis
– Estimation Modeling. A vehicle to estimate cost and resources required
for software development and maintenance (Must also consider project
attributes, work breakdown structure, etc.)
• Size Customized and COTs. A tool to size purchased application package
• Client-Supplier Relationships. Establish service level agreement (SLA)
targets and tolerances.
©2012 David Consulting Group 18

20. Contact Us
Email: d.herron@davidconsultinggroup.com
Phone: 1-610-644-2856, ext 21
http://www.davidconsultinggroup.com
@DavidConsultGrp
/DavidConsultGrp
/company/David-Consulting-Group
©2012 David Consulting Group 19