|
#
|
Characteristic
|
IFPUG FPA r4.3
|
NESMA FPA v2.0
|
Mark II FPA r1.3.1
|
COSMIC FSM r3.0.1
|
|
1
|
Origin
|
Created by Allan Albrecht at IBM in 1978
Latest release (January 2010) of the original method
|
Believed to have been created by NESMA (aka NEFPUG) in mid-1980s
Derived from IFPUG
|
Created by Charles Symons at Nolan Norton in 1984 (put into public domain 1991)
Updated method for use with DBMS, structured methods, CASE tools, etc
|
Created by international consortium of industry subject matter experts and academics from 19 countries in 1997
Updated method for use with OOA/D, layered architectures, Web2.0, lean/agile, etc
|
|
2
|
Complies with international standard for Functional Size Measurement Methods – ISO14143 and other official recognition
|
ISO/IEC 20926:2003
ISO Standard applies only to unadjusted FP
|
ISO/IEC 24570:2005
ISO Standard applies only to unadjusted FP
|
ISO/IEC 20968:2002
Recommended method for HM Government (UK)
|
ISO/IEC 19761:2003/2010
BCS Technology Award Winner in 2006
Recognised as National Standard in Spain & Japan
|
|
3
|
Counting Practices Manual available to international body of users
|
Available to IFPUG members
English & some other language versions available to members
|
Available for sale
Dutch-language version
English-language version
|
Available - public domain
English-language version
|
Available - public domain
9 language versions:
Arabic, Chinese, Dutch, English, French, German, Italian, Japanese, Spanish
|
|
4
|
Used by
|
Public & private sector organisations, large & small, both customers & vendors, around the world
Mostly MIS users
Stable user base – international
|
Public & private sector organisations, large & small, both customers & vendors, primarily for work in The Netherlands
Mostly MIS users
Declining user base – mostly The Netherlands
|
Originally HM Government’s preferred method for sizing & estimating software. Now used by a few public sector customers & their vendors
Declining user base – mostly United Kingdom
|
Public & private sector organisations, large & small, both customers & vendors, around the world
Mix of MIS and Engineering users
Growing user base – international
|
|
5
|
Certification of trained measurement staff
|
Yes
Certified Function Point Specialist (CFPS)
|
Uses IFPUG CFPS
|
Yes
Certified Function Point Analyst (CFPA)
|
Yes
COSMIC Practitioner Certification
|
|
6
|
Supported by the International Software Benchmarking Standards Group (ISBSG)
|
Yes
|
Yes
|
Yes
|
Yes
|
|
7
|
Pool of comparative data
|
Large
Compiled over many years – the utility of antique data is questionable
|
Large
Comparisons use
IFPUG data
|
Small
Some native data; can be compared to IFPUG data if care is taken
|
Moderate and growing
Data since 1997; ISBSG benchmark released 2009; can be compared to older data if care is taken
|
|
8
|
Terminology used
|
Founded in the 1970s
|
Founded in the 1970s
|
Uses structured methods terminology
|
Compatible with OOA/D, & software eng. principles
|
|
9
|
Oriented toward user-required functionality
|
Yes
|
Yes
|
Yes
|
Yes
|
|
10
|
Helps verify consistency & completeness of user-required functionality
|
Yes
|
Yes
|
Yes
|
Yes
|
|
11
|
Analyses can be used as basis for construction of tests independent of code & test activities
|
Yes
|
Yes
|
Yes
|
Yes
|
|
12
|
Measures functional size of dynamic (behavioural) aspects of system (expressed as e.g. use cases, conversational dialogues, user stories, epics & themes, etc)
|
Yes
|
Yes
|
Yes
|
Yes
|
|
13
|
Measures functional size of static (data storage) aspects of a system (expressed e.g. as files, tables, entity types, classes, etc)
|
Yes
|
Yes
|
Regarded as ‘double accounting’ –
only information processing measured
|
Regarded as ‘double accounting’ –
only information processing measured
|
|
14
|
Measures development of new requirements
|
Yes
|
Yes
|
Yes
|
Yes
|
|
15
|
Compatible with modern methods of requirements analysis
|
Partially
(1975/85s concepts)
requires data model
|
Partially
(1980/85s concepts)
requires data model
|
Yes
(1980/95s concepts)
requires data model
|
Yes
(1995/2010s concepts)
incl. incremental
|
|
16
|
Measures adaptive maintenance (enhancements)
|
Yes
|
Yes
|
Yes
|
Yes
|
|
17
|
Measures corrective maintenance (fixes)
|
No
|
No
|
No
|
No
|
|
18
|
Measures perfective maintenance (refactoring for improved performance)
|
No
|
No
|
No
|
No
|
|
19
|
Measures algorithmic complexity
|
No
|
No
|
No
|
No
|
|
20
|
Measures reuse of code
|
No
|
No
|
No
|
No
|
|
21
|
Designed for MIS systems - flat & indexed files, batch systems, OLTP systems
|
Yes
|
Yes
|
Yes
|
Yes
|
|
22
|
Designed for MIS systems - Relational DBMS
|
No
But mapping rules have been developed
|
No
But mapping rules have been developed
|
Yes
|
Yes
|
|
23
|
Designed to be applicable to real-time and/or embedded systems
|
No
MIS concepts only
|
No
MIS concepts only
|
No
terminology can be re-interpreted for real-time
|
Yes
one common model applicable across MIS, real-time & embedded systems
|
|
24
|
Can be used to measure complex, layered architectures
|
No
Rules assume monolithic system – infrastructure & middleware is ‘invisible’
|
No
Rules assume monolithic system – infrastructure & middleware is ‘invisible’
|
Yes
Limited – can recognise
3-tier architecture
|
Yes
Designed to recognise ‘layered architectures’ –
measures all functional requirements allocated to software systems
|
|
25
|
Can be used to measure Functional User Requirements before design, code & test
|
Yes
|
Yes
|
Yes
|
Yes
|
|
26
|
Can be used to measure Functional User Requirements after design, code & test
|
Yes
|
Yes
|
Yes
|
Yes
|
|
27
|
Early estimates of functional size can be made based on incomplete knowledge of Functional User Requirements – enabling consistent use of one size scale for estimating & measurement throughout project
|
Yes
Various methods:
e.g. Fast Eddy, File-Based Approach, Transaction-Based approach
|
Yes
Various methods:
e.g. Fast Eddy, File-Based Approach, Transaction-Based approach
|
Yes
Various methods:
e.g. Data Model Approach (CRUDL), Transaction-Based approach
|
Yes
Various methods: e.g.
Event-Based Approach, Object-Based Approach, Story-Based Approach
|
|
28
|
Can be used to (re)estimate during product life-cycle
|
Yes
|
Yes
|
Yes
|
Yes
|
|
29
|
Size can be used as input into top-down software cost models such as COCOMO.II.2000, SLIM, SEER, Price-S, etc
|
Yes
|
Yes
|
Yes
|
Yes
|
|
30
|
Can be used to construct product burndown charts, calculate takt time, #sprints, etc
|
Yes
|
Yes
|
Yes
|
Yes
|
|
31
|
Independent of product non-functional requirements
|
Yes
|
Yes
|
Yes
|
Yes
|
|
32
|
Independent of project constraints
|
Yes
|
Yes
|
Yes
|
Yes
|
|
33
|
Independent of developer experience
|
Yes
|
Yes
|
Yes
|
Yes
|
|
34
|
Independent of process, project management & development methods
|
Yes
|
Yes
|
Yes
|
Yes
|
|
35
|
Scale type:
Nominal – distinguishes members of sets, unordered
Ordinal – relationship between sets, unequal intervals
Interval – comparisons, equal intervals, arbitrary zero
Ratio – comparisons, equal intervals, a natural zero
ref: ISO/IEC CD 15939.
|
‘Nominal/Ordinal’ Scale
Unequal intervals between Low & Average, and between Average & High
|
‘Nominal/Ordinal’ Scale
Unequal intervals between Low & Average, and between Average & High
|
‘Ordinal/Interval’ Scale
Weights derived so that
1 MkII fp = 1 IFPUG fp
approximately comparing functional processes
|
Ratio Scale
Empirical data suggests
1 cfp = 1 IFPUG fp
approximately comparing functional processes
|
|
36
|
Permissible arithmetic & statistical operations
|
Categories assigned relative weights:
Data can be 'ranked', but 'quantifying' differences between values is difficult due to ‘cut off’ (Low is c. half of High) –
ratios are problematic
|
Categories assigned relative weights:
Data can be 'ranked', but 'quantifying' differences between values is difficult due to ‘cut off’ (Low is c. half of High) –
ratios are problematic
|
Ordered, synthetic scale with a natural zero:
Data can be ranked; differences & ratios between values can be quantified within limits but are problematic due to the use of weights
|
Ordered, constant scale with a natural zero:
Data can be ranked; differences between values can be quantified; ratios make sense (i.e. 20 is twice the size of 10, and 2000cfp is twice 1000cfp).
|
|
37
|
Accounts for information processing by:
|
Sizing static data and dynamic behaviour
|
Sizing static data and dynamic behaviour
|
Sizing dynamic behaviour, the use of data
|
Sizing dynamic behaviour, the use of data
|
|
38
|
Models the functional user requirements as:
|
File Types
and
Elementary Process
(= Input-Process-Output)
|
File Types
and
Elementary Process
(= Input-Process-Output)
|
Logical Transactions
(= Input-Process-Output)
|
Functional Processes
(= Input-Process-Output)
|
|
39
|
Equivalent of
stimulus/response message pair (i.e. a ‘thread of control with some input, related processing, and some output)
|
Elementary Process either:
External Input (EI),
External Output (EO) or
External Query (EQ)
depending on ‘primary intent’
|
Elementary Process either:
External Input (EI),
External Output (EO) or
External Query (EQ)
depending on ‘primary intent’
|
Logical Transaction (LT)
All stimulus/response message pairs regarded at LT irrespective of ‘primary purpose’
|
Functional Process (FP)
All stimulus/response message pairs regarded at FP irrespective of ‘primary purpose’
|
|
40
|
Rules for measuring size
|
Different rules apply depending on elementary process type
|
Different rules apply depending on elementary process type
|
Same rules apply to all logical transactions
|
Same rules apply to all functional processes
|
|
41
|
Base Functional Component(s)
|
Internal Logical File
External Interface File
External Input
External Output
External Query
|
Internal Logical File
External Interface File
External Input
External Output
External Query
|
Input Data Element
Entity Reference
Output Data Element
|
Data Movement
(either: Entry, eXit, Read, or Write depending on direction of movement)
|
|
42
|
Contributors to functional size
|
Per File Type:
#static Data Element Types & #Record Element Types
Per Transaction Type:
#dynamic Data Element Types
& #File Type References
|
Per File Type:
#static Data Element Types & #Record Element Types
Per Transaction Type:
#dynamic Data Element Types
& #File Type References
|
Per Logical Transaction:
#Input Data Elements
#Entity References
#Output Data Elements
|
Per Functional Process:
#Data Movements
i.e. the movement (Entry, eXit, Read or Write) of one Data Group
|
|
43
|
Unit of measure
|
Different weights assigned to 5 function types depending on their relative ‘complexity’
Unit = 1 fp (IFPUG)
|
Different weights assigned to 5 function types depending on their relative ‘complexity’
Unit = 1 fp (NESMA)
|
Weights assigned to the ‘minimum size logical transaction’ add to 2.5 to establish comparability between MkII and IFPUG
Unit = 1 fp (MkII)
|
1 Data Movement
=
1 COSMIC Function Point
Unit = 1 cfp
|
|
44
|
Sensitivity to small changes to requirements
|
Low
(only detects changes at boundaries between Low, Average, High categories)
|
Low
(only detects changes at boundaries between Low, Average, High categories)
|
High
(detects changes of single data element types and single entity references)
|
Moderate
(detects changes to single data-groups)
|
|
45
|
Integrity of measures (how well do the measures reflect the thing measured?)
|
Artificial limits (weights, thresholds, uneven intervals) limit size of function types measured.
Integrity is limited.
|
Artificial limits (weights, thresholds, uneven intervals) limit size of function types measured.
Integrity is limited.
|
No artificial limits imposed on size of functional process.
Integrity is good.
|
No artificial limits imposed on size of functional process.
Integrity is excellent.
|
|
46
|
Sensitivity to variation in functional size of dynamic model of system i.e. functional processes
|
Stepped:
minimum step 3fp
maximum step 7fp
|
Stepped:
minimum step 3fp
maximum step 7fp
|
Stepped:
minimum step either
0.26, 0.58 or 1.66
maximum step infinity
|
Accommodates size variation from zero to infinity in steps of 1 cfp
|
|
47
|
Sensitivity to variation in functional size of static model of system i.e. data stores
|
Stepped:
minimum step 5 fp
maximum step 15 fp
|
Stepped:
minimum step 5 fp
maximum step 15 fp
|
Data stores are considered to deliver functionality only when the data is referenced in transactions
|
Data stores are considered to deliver functionality only when the data is used in functional processes
|
|
48
|
Smallest feasible functional process
|
3 fp
|
3 fp
|
2.5 fp
|
2 cfp
|
|
49
|
Smallest feasible enhancement
|
3 fp
|
3 fp
|
0.26 fp
|
1 cfp
|
|
50
|
Availability
|
Available only to members of IFPUG (but easy to join organisation)
|
Public domain -– download from NESMA
|
Public domain – download from UKSMA
|
Public domain – download from COSMIC
|
|
51
|
Design Authority (independent of vendors)
|
International Function Point Users Group (IFPUG)
www.ifpug.org
|
Netherlands Software Metrics Association (NESMA)
www.nesma.nl
|
United Kingdom Software Metrics Association (UKSMA)
www.uksma.co.uk
|
COmmon Software Measurement International Consortium (COSMIC)
www.cosmicon.com
|
