Function Points

The missing link in software development

Straight Talk Software Testing(STST) Conference 2014

Kuala Lumpur

Morten Korsaa
Director - Whitebox
About me
• Searching for the silver bullet
• Information Engineering, OO, Project management, CASE tools,
• Process Improvement
• Maturity models
• Assessments
• ImprovAbility
• No silver bullet
Topics
• Methods and techniques
• Potential benefits
• Implementation
 Questions
• How many are either producing or buying software?

• How much software did you produce or acquire last year?

Why bother?
• Because Function Points is measuring the size of what the users need - which is -
Functionality.

• FP is the natural basic unit.

• You want more – you pay more

• Contracts based on price / FP is solving some of the most common problems known to it
projects.

• Control - professionalism
 Is it a magic wand??

• Wand? No, but the capability to measure the

size of what is delivered is a very strong tool
in your professional toolbox
• Magic? Definitly not, just introducing what
every other industry has.
Analogy
Function Points
• Measure the size of functionality
• The more you get the more possibilities
• There are different quality requirements to a
brain surgery remote control and a quad
copter remote control
• No one expects to pay the same
• But the size is comparable
Square meters
• Measure the size of a house
• The more you get the more possibilities
• There are different quality requirements
to a brain surgery room and a hall
• No one expects to pay the same
• But the size is comparable
What does it take ?

• Scope
• Standard for counting to ensure conformance
• A counting method
• Counting practices in projects
• Fact based management
Scope: What is measured with Function Points?
• Only the size of the functionality seen from the users perspective.

• NOT
• Quality (ISO25000)
• Hardware
• Infrastructure
• Architecture
• Project maturity
• Personal capabilities
Counting standards
• IFPUG
• COSMIC
• Mark2
• NESMA
• FISMA

• Pick any one, and you have 95% of the benefits in reach.
• I would choose FISMA
Counting method
• Comes with the standard
• Is the systematic approach to measure the size consistently
• Needs to be trained to all who counts
• Varies in complexity and effort
Counting method – example: FISMA
• There are seven classes, that follows the classic three-layer architecture:
• UI layer
• Navigation and query
• Input
• Business layer
• Output
• Algorithmic and manipulation
• Interfaces from other systems
• Interfaces to other systems
• Data layer
• Data storage
Counting method – example: FISMA
• For each class, you count the size by counting each of the defined types and add them
together, using a simple formula.
• Look for: reads, writes, data elements and operations.
• The result is the functional size of the software measured in FP
Counting method – example: Input screen
Employee information

First name
OK
Last name
Empl. nr.
Address 1
Address 2
City
State

Inquiry screen: 0,2+N/7+R/2 = 0,2 + 10/7+2/2 = 2,6 FFP

Counting practices in projects
• Who – all, but start with the project leaders and customer representatives
• When – every time you make a change, and would like to know the size, but start with a
retrospective to establish baselines, then to establish an early estimate,…
• What – the projects software
• Why – to focus on the size as a basis for estimates and cost evaluations
Fact based management
• The management team must insist on high quality information based on the size of the
software
You need the size to
• Estimate
• Progress (earned value analysis)
• Cost evaluations
• Price
• Productivity
• Planning
• Quality control
Estimation techniques
• Different techniques for different purposes
• Final count
• Early estimation
• Own historic facts and data
• Industry historic facts and data
• ISBSG
• Corrective factors
Size and estimation
• Own historic facts for future estimates
• Hours distribution between classes to mae early estimates
• Make early estimates using e.g. the KISS method
• Hours distribution on between activities to estimate activities.
• e.g. IV&V (0.07 work hours/FP and 5$/FP)
Size and cost evaluation
• Development performance becomes tangible the moment you have the figures of cost/FP
• It makes sense to compare projects / departments / vendors / suppliers when you have
a common figure for their performance in either cost/FP or FP delivered/man month.
Size and price
• “If you buy hours, you get hours”
• “If you buy functionality, you get functionality”
[Quote: Pekka Forselius]

• Changed distribution of responsibility.

• Compare with industry
Agile and FP contracts
• Tender:
• Workflow management system for the police
• Approximately 12.000 FP
• Environment
• Qualiity requirements
• Price / FP?
• Project
• Customer prioritize functionality
Size and productivity
• Hours/FP is the basic measure of productivity.
• Benefits of process improvements become easily recognizable.
• E.g. You used to spend 0,53 hours/FP on regression testing. You plan to establish a
better automated testing environment, and the target is 0,40 hours/FP. Then you can
easily calculate a realistic ROI for the investment - and you can measure the progress.
Size, productivity and maturity
1000 FP project 10.000 FP project 10.000 FP project 10.000 FP project
CMMI level Work hours/ FP Work hours/ FP Potential defects Delivered defects
1 22,00 52,80 6,50 1,63
2 19,56 48,00 6,25 1,13
3 18,86 37,71 5,50 0,72
4 18,21 31,06 5,25 0,53
5 17,60 24,00 4,50 0,27

From Capers Jones 2013

Size and planning
• To plan e.g. amount of documentation based on the size (a 10.000 FP application requires
in average 21 pages/FP)
• To plan the support for increased scope during the project.
• Planning the effort needed for maintenance
 Activity Hours/FP
Requirements 0,38
Planning based on FP Prototypes 0,33
Design 1,5
Design inspections 3,30
Programming 4,00
Code inspections 3,30
User documentation 0,29
What would your planning Unit testing 0,88
look like if you had figures like this? Function testing 0,75
Regressiontesting 0,53
Integration testing 0,44
Performance testing 0,33
Systems testing 0,88
Misc testing 0,91
Project management 4,40
Compiled from a set of 40 activities
From Capers Jones 2013 Misc. 0,99
Total 20,44
Size and quality control
• If you collect defects removal figures for the different activities correlated to FP you
start to know if inspections or regression test are the most efficient way to remove
defects
Quality control including FP

From Capers Jones 2013

Quality - differences
• Best case project introduces 2,5 defects/FP – remove 98% - and deliver 0,03
defects/FP to the customer

• Average project introduces 5,0 defects/FP – remove 87% - and deliver 0,63 defects/FP
to the customer

• Worst case project introduces 7,75 defects/FP remove 81% - and deliver 1,44 defects/FP
to the customer

From Capers Jones 2013

Size and progress
• Earned Value Management
• Only make good sense based on
delivered functionality
• Because the value is the
functionality, not the hours spend
What does CxO’s care about? Top ten!
Topic of care Metric
Competitive practices in industry $ / FP
Project failure rates (sizes and methods) FP
Risks: Software FP + defect removal efficiency
Patent litigation and results Cases won, lost. Specific issues
Outsourcing success/failure FP, defect removal efficiency
Risks: Corporate financial $/litigation/competition
Risks: Legal FP, defects removal
Cyber security attacks Vulnerabilities
Return on Investment FP, ROI
Total Cost of Ownership FP, ROI
… ….
From Capers Jones 2013
Requirements to success.
• DEMAND
• Customers who will only buy functionality.
• Training
• To customers and vendors
• National strategy for implementation

• And then – to speed it up

• SCOPE Management – Northern SCOPE
SCOPE Management
• Customer hire a Certified SCOPE
Manager, to act on his behalf
• 1-2 days / month
• Early estimation, scoping,
requirements quality control
• The scope manager facilitates the
process and ensure success
Workshop tomorrow
• Experiences from Danish and Finnish industry
• The classical project set-up, and why it is doomed to fail
• SCOPE management
• Sources for more information
• Set-up that will ensure success with function point supported software development in
the Malaysian public it sector.
Questions ??
Morten Korsaa
mk@whitebox.dk