�ݺ�ߣ

AGENDA
• Basic Function Point concepts
• Agile and FP
• Top 10 FP uses by mature organizations
• Steps to a sustainable measurement program
• Q & A

Quality Plus Technologies, Inc.
List of Clients

BASIC
CONCEPTS
Quality Plus Technologies, Inc. www.qualityplustech.com

HISTORY LESSON 5
1970’s: Fred Brooks Mythical Man Month (1975); Alan Albrecht 1st FP
method (1979); Putnam parametric estimation; COBOL / Fortran; 1st
Software Development Life Cycle (SDLC) models
1980’s: Barry Boehm: S/W Engineering Economics (1981);
International FP User Group – IFPUG (1986) & other metrics groups
formed; Methods published: IFPUG FP, Mark II, Feature Points;
parametric estimating models: COCOMO II, etc.
1990’s: ISO/IEC 14143 Functional Size Standards (1998+); Italy (1st),
then Brazil & Korea governments FP; Certification (CFPS); national
metrics groups  Growth; ISBSG; Capers publishes in Scientific
American (1998); Watt Humphrey: Managing the Software Process;
2000’s: IFPUG & other FSM Methods  ISO/IEC FSM Methods; IFPUG
publishes textbook IT Measurement, Advice from the Experts;
Southern Scope; IFPUG releases (1-4.2); IFPUG releases SNAP:
Software Non-functional Assessment Process (2009)
2010’s: IFPUG 4.3.1 (2010), Malaysia adopts FP; IEEE PAR for SNAP
(2017); IFPUG celebrates 30th anniversary with ISMA14 (Sept 13-15,
Cleveland) and International Year of Software Measurement #IYSM
(2017)

Functional Size Measurement (FSM)*:
the process of measuring Functional Size
Functional Size*: a size of the software derived
by quantifying the Functional User Requirements
Functional User Requirements*:
a sub-set of the user requirements.
The Functional User Requirements represent the user practices
and procedures that the software must perform to fulfill the users’ needs.
They exclude Quality Requirements and any Technical Requirements
Function Points: unit of measure for Functional Size when using
The International Function Point Users Group (IFPUG) FSM Method
* Source: ISO/IEC 14143-1 Functional Size Measurement:
Definition of Concepts
BASIC TERMINOLOGY

“Function Points (FP) are similar
to square feet (or square
meters) for software.
FP quantify ‘WHAT’ the
software must do.”
Carol Dekkers

WHERE DO FP FIT?
1. Functional (user)
requirements
2. Non-Functional
(user) requirements “Project”
requirements
3. Technical
requirements

1. FUNCTIONAL USER
REQUIREMENTS
What the software must do
Assess functionality:
inputs, outputs, queries,
data stores (maintained,
referenced)
Size = functional size (units = FP)

2. NON-FUNCTIONAL USER
REQUIREMENTS
How software must perform
(Quality: ISO 9126/SQUARE,
performance, +ilities)
Formerly VAF, now SNAP Points, (or
parameters)
Non-functional size = VAF,
SNAP points (or parameters)

3. TECHNICAL REQUIREMENTS
How software will be built
Includes: Architecture,
environment,
programming language,
skills, resources,
methodology…
SDLC methods: Agile vs waterfall vs spiral
Not part of s/w product size (parameters)

ISO/IEC STANDARDS
Functional Size Measurement
• Functional size measurement framework
ISO/IEC 14143-1 through -6
• IFPUG 4.3.1 unadjusted – ISO/IEC 20926
• COSMIC – ISO/IEC 19761
• NESMA – ISO/IEC 24570
• Mark II – ISO/IEC 20968
• FiSMA 1.1 - ISO/IEC 29881
Quality Measurement
• SQUARE – ISO/IEC 25000 series, (replacing ISO/IEC 9126 series)
Process Standards
• Software (& systems) life cycle processes –ISO/IEC 12207
• Software Engineering body of Knowledge (SWEBOK)
• Software measurement framework – ISO/IEC 15939

ABOUT AGILE:
FP ARE INDEPENDENT OF METHODS,
TECHNOLOGY, NFR, ETC.
• Software product size  independent of SDLC
• Agile FP delivery delivered in releases (not sprints)
• Consistent measurement IMPORTANT !

TOP TEN FUNCTION POINT
USES BY MATURE
ORGANIZATIONS

2015 STATISTICS BY CAPERS JONES
GLOBAL
SOFTWARE
PROJECTS
10,000 +
FP
Projects
Started
1,000 +
FP
Projects
Started
Troubled
%
Outsource
%
Using
FP
%
Using
Parametric
Estimates
%
Large European 2,000 30,000 37% 20% 65% 15%
Large Asia/Pacific 4,000 60,000 44% 15% 35% 20%
LargeCentral/
South American 1,700 25,500 52% 25% 70% 9%
Large Russian 1,650 24,750 64% 20% 5% 5%
Large
Arab/middle east 500 7,500 55% 55% 4% 5%
Large African 250 3,750 58% 55% 30% 20%
Subtotal 10,100 151,500 48% 21% 43% 14%
U.S. Subtotal 4,050 60,750 38% 56% 46% 23%
GLOBAL TOTAL 14,150 212,250 11% 31% 42% 17%
Troubled projects = cancelled, delayed, overrun or poor quality.
Function Points mandated by governments in Brazil, Italy, Malaysia, Japan, S. Korea
15

1. SOFTWARE
CONTRACTING
Based on unit pricing
(currency/ FP)
•Balances risk (fixed price favors
customer, T&M favors supplier)
•Highly flexible to change
Government directives: Brazil,
Italy, Malaysia, Japan, Korea
Mandated / optional
implementations
•Proposal evaluation: # of Certified
Function Point Specialists (CFPS)
•Legislation may govern
•Pricing vs costing models

2. PARAMETRIC COST
ESTIMATION
Commercial products:
COCOMO II,
CostXpert,
Excelerplan,
Knowledge Plan,
SEER,
SLIM,
Software Risk Master,
True Price,
Others

ESTIMATION ACCURACY
Estimates based on Function Point sizing are
producing the most accurate estimates
25
2550Use WBS
only
Use Function
Points only
Use Both
Techniques

3. OUTSOURCING
MANAGEMENT
Supplier payment
based on FP
delivered
Negotiation /
pricing based on
(past) performance
May include reward
/ penalty
mechanism
May include unit
pricing
Offshore or other
(US/India,
Germany/Latvia,
Europe/China, etc.)
Basis for insourcing
(U.S.)

4. FORMAL
SCOPE
MANAGEMENT
Based on formal methodology
• Southern Scope (Australia)
• northernSCOPE (Finland, Sweden,
Denmark, Germany)
Training curriculum and
certification (northernSCOPE)
Customer driven with supplier
collaboration
• Early estimates in FP
• Contracting based on unit pricing
• Flexible to change (change orders)
• Scope manager role as customer and
supplier advocate

TOP 10 REASONS
FOR PROJECT FAILURE
• Lack of top management commitment
• Misunderstanding the requirements
• Not managing change properly
• Failure to gain user commitment
• Lack of effective project management skills
• Lack of adequate user involvement
• Failure to manage end user expectations
• Lack of effective PM methodology
• Unclear/ misunderstood scope/ objectives
• Changing scope/ objectives
•
• Misunderstanding the requirements
• Not managing change properly
• Failure to gain user commitment
• Failure to manage end user expectations
• Lack of effective PM methodology
• Unclear/ misunderstood scope/ objectives
• Changing scope/ objectives

5. MATURITY ASSESSMENT AND
PROCESS IMPROVEMENT
Level 2/3 of CMMI® outlines measurement criteria
•Software product size (requirements, scope, s/w product)
•Practical software and systems measurement (PSM)
•Goal Question Metric (GQM)
SPICE (Software Process Improvement Capability dEtermination)
FP is common denominator for measurement programs
•Defect density (defects / FP)
•Team productivity (FP / person month)
•Product delivery rate PDR (hours / FP)
•Maintenance and support rates (FTE / 1000 FP)

6. INTERNATIONAL
SOFTWARE BENCHMARKING
STANDARDS GROUP (ISBSG)
Established
in 1994
• Specific  FP
sized completed
projects
• Goal: “To
develop the
profession of s/w
measurement
by establishing a
common
vocabulary and
understanding
of terms.”
Non-
commercial
international
consortium
• Data quality is
critical
• Double blind
project
submissions
• AD&E database
> 8000 projects
• Maintenance
projects growing
Special
reports
• Agile
• Team size
• Government
• etc
ISBSG
repository
included in
parametric
tools
• SEER
• SLIM
• Others
• Basis of ISO/IEC
29155 Project
Performance
Benchmarking
standards

7. EVALUATE S/W PRODUCT SIZE
• Gauge requirements completeness (%
FP component)
• Sizing by analogy (t-shirt sizing)
• UAT coverage
• Evaluation of alternatives (functional fit)
• Replacement system size
• “Good” requirements = FP countable
• Shortcut methods (rule of 31, patterns,
all average, E&Q)
• With SNAP points = complete sizing

8. PROPOSAL
EVALUATION
Compare Supplier Bids
•Compare bids: pricing and product size
•Evaluate pricing (customer runs own parametric simulations)
•Gauge requirements completeness
Request for Proposal (RFP)  FP provisions
•Response must be sized in FP
•Team requirements (similar to CMMI® level)
•Common understanding of scope

9. INSURANCE VALUATION
AND LITIGATION
• U.S. Internal Revenue
Service (IRS)  FP-based
valuations of software
assets
• Expert witness cases:
• Infringement
• Non-delivery
• Malicious behavior
• Cancellation / contract
termination
• other

10. PRICE-TO-WIN AND
OTHER ESTIMATES
Price-to-
win:
engineering
design +
software
(FP) +
hardware +
other
Micro and
macro
based
estimating
models
(ISBSG)
“Fog test”
estimates 
work effort,
defects,
pricing,
WBS
History is
better
predictor
than
theoretical
models

TOP 10 MEASUREMENT
BEST PRACTICES WITH FP
1. Software contracting
2. Parametric estimating
3. Outsourcing management
4. Formal scope management
5. Process improvement and maturity assessment
6. ISBSG / benchmarking
7. Objective S/W product sizing
8. Proposal evaluation
9. Insurance valuation and litigation
10. Price-to-win / other estimates

STEPS TO A
SUSTAINABLE
MEASUREMENT
PROGRAM

SUSTAINABLE CHANGE
NEEDS
P.O.W.E.R.
Predisposition  we see success
Outlook  we will do it
Wherewithal  we can do it
Evaluation  we will measure it
Resources  we commit to it
Source: C.Dekkers
2000

“ Motivation moves
mountains…
Motivation is
everything! ”
Principle 6 of Tom Gilb’s Ten Most Powerful
Principles for Quality in (Software and)
Software Organizations, 2nd World
Congress on Software Quality, Tokyo,
September 2000

CRITICAL SUCCESS FACTORS
Source: P.Willman

Carol Dekkers
dekkers@qualityplustech.com

�ݺ�ߣ

Top 10 uses of Functional Size Measurement (Function Points) by Mature Organizations

More Related Content

Top 10 uses of Functional Size Measurement (Function Points) by Mature Organizations