2024: Domino Containers - The Next Step. News from the Domino Container commu...
Â
Function Point Analysis: An Overview
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
Welcome to DCGâs Function Point Analysis: Sizing the Software Deliverable Series. Function Point Fundamentals is the first course in a series of courses built to help you become a proficient counter, and should you choose to do so, become a Certified Function Point Specialist (CFPS).
Function points were introduced in 1979 by Alan Albrecht, from IBM. IBM needed a way to quantity the size of their projects in order to provide a better estimation model for their workload. Function points was the answer and in 1986 the International Function Point Users Group was chartered to be the governing body for the function point methodology. IFPUG is a not-for-profit organization consisting of an elected board of directors, and several committees devoted to supporting, developing and implementing consistent and accurate counting guidelines. The Counting Practices Committee (CPC) develops the counting guidelines and the Counting Practices Manual (Documented Rules), the New Environments Committee (NEC) applies those guidelines to new technologies and produces white papers and case studies for use by the IFPUG membership, the IT Performance Committee explores the use of function points in benchmarking and estimation modeling, and other committees oversee the certifications provided by IFPUG. Benefits of being an IFPUG member include reduced pricing for conferences and IFPUG training during the conferences, access to resource material (e.g. articles and white papers), and networking capabilities with the IT community that shares a common interest in metrics and function points.
Function points only address the functional requirements and are from a logical view not a physical view. A typical developer would be looking at programs, physical database tables, and physical screens. We as function point specialists (counters) look at the functionality provided by the screens (transactions), logical data groupings of tables, and the ability of the application to perform a complete process. Typically, business user requirements reflect the logical view.
Which of these things are the most important to you or frustrating or challengesâŚ
This slide concludes the class sessions. This is the first of several classes that we offer in the use of function points. If you want further mentoring or training for the individual or the organization, please contact Fiona Thompson at the DCG Headquarters or Sheila Dennis in the Colorado offices.