FUNCTION POINTS
        WTF?
YOUR COMPANY IS A SOFTWARE
COMPANYIGNORANCE
STOP FEIGNING !

Is a website 'software'?
Is an iPhone or iPad app 'software'?
Is Rich Media 'software'?
YES! Absolutely! No doubt about it!

Your company definitely IS a software company

Is your company a world-class, best-in-class Software Company?

Do you know how much software you produce?
Per year? Per Month? Per Day?

How much software - exactly, specifically?

How productive are you - exactly?
BEST IN CLASS SOFTWARE COMPANIES

Best in Class Software Companies Have:

 ● higher productivity

 ● higher quality
                                         Best in Class
 ● small project growth rates             ● 28% Requirements
                                          ● 36% Design
 ● less overtime                          ● 20% Coding
                                          ● 16% Testing
 ● less redundancy

 ● more specialization                   Worst In Class
                                          ● 11% Requirements
 ● software                               ● 16% Design
   measurement           programs!        ● 37% Coding
                                          ● 37% Testing
PRODUCTIVITY

“Goods or services per unit of labor or expenses”

Productivity = outputs/inputs

Software Productivity = functionality/hours

● Unit cost of software goes up with size
● Marginal costs for software increase with size
● There are different costs for each component
MEASUREMENT

● Standard units

● Houses can be measured in square feet

● Software can be measured too

● Measuring things is repeatable
  ○ an inch today is an inch tomorrow

● Measuring eliminates wasteful guessing
  and               introduces accurate and justifiable
LINES OF CODE
● Language dependent


● Skill dependent


● Unknown until written


● No Standards


● Function Points are better
FUNCTION POINTS ARE STANDARDIZED
Large user group
IFPUG - http://ifpug.org
1,200 members in 30 countries around the world

ISO Standard
IFPUG v4.3 is an ISO standard

De-facto standard
estimating packages: Cocomo II, Construx Estimate, etc.

Certified Function Point Specialist
official IFPUG certification test

Counting Practices Manual
official manual by IFPUG

FP data repositories
large repositories of data
HISTORY

● 1979 FPs introduced by Alan Albrecht

● 1984 First FP guidelines

● 1986 First IFPUG Board of Directors

● 1994 CPM Release 4.02003ISO standard

● 2003 ISO standard

● Adoption rate is increasing
OVERVIEW

● Measured from the user's perspective

● Technology-independent

● Low cost (once the system is in place)

● Repeatable

● Works well with use cases

● Answers lots of questions

● Can be automated
TYPES OF COUNTS

1. Development
    ○ all phases through deployment
    ○ forms a baseline
2. Enhancement
    ○ in production, has a baseline
    ○ count the size of successive enhancements
3. Application
    ○ in production, no baseline
    ○ forms a baseline
BENEFITS AND USES
● Accurate and justifiable estimations of
   ○ Cost
   ○ Duration
   ○ Staffing

● Actionable productivity metrics, including
   ○ Defect rate
   ○ Cost per function point
   ○ Velocity (fp/hr)

● Competitive advantages
   ○ Fixed prices
   ○ Real data and facts to drive decisions
BENEFITS AND USES

● software sizing          ● when and what to re-engineer

● communication            ● test case estimation

● over-time reduction      ● productivity

● project inventory        ● scope creep

● estimates                ● true cost

● repeatability            ● contracts

● organization portfolio
APPLY THE DATA
Given:
 ● a team of developers that average 18 FP/month (velocity)
 ● at an average cost of $5200/month per developer
 ● with requirements doc that contains 197 FP

Derive:
 ● months of effort
    ○ 197 / 18 = 11 man-months
 ● cost
    ○ 11 x 5200 = 57,200 dollars
 ● duration
    ○ 2.5 x 2.2 = 5.5 months
 ● minimum duration
    ○ .75 x 2.2 = 1.65 months
 ● staff
    ○ square root of 11 = 3.3 developers
 ● and many, many more magical formulas!
WHEN NOT TO USE


● when sizing maintenance efforts
   ○ detective work
   ○ maintenance productivity can vary




● when analyzing performance issues
   ○ may not be related to functionality
   ○ more likely about throughput & processing
CHALLENGES

Must be an ongoing corporate software metrics program initiative, not an
afterthought or on-the-side pet project


Must be systematized and well-managed in order to be accurate


Counting requires special training and/or special software


Usage of count data will challenge and
transform                          existing management practices
TIP OF THE ICEBERG

Function Points

  • 1.
  • 2.
    YOUR COMPANY ISA SOFTWARE COMPANYIGNORANCE STOP FEIGNING ! Is a website 'software'? Is an iPhone or iPad app 'software'? Is Rich Media 'software'? YES! Absolutely! No doubt about it! Your company definitely IS a software company Is your company a world-class, best-in-class Software Company? Do you know how much software you produce? Per year? Per Month? Per Day? How much software - exactly, specifically? How productive are you - exactly?
  • 3.
    BEST IN CLASSSOFTWARE COMPANIES Best in Class Software Companies Have: ● higher productivity ● higher quality Best in Class ● small project growth rates ● 28% Requirements ● 36% Design ● less overtime ● 20% Coding ● 16% Testing ● less redundancy ● more specialization Worst In Class ● 11% Requirements ● software ● 16% Design measurement programs! ● 37% Coding ● 37% Testing
  • 4.
    PRODUCTIVITY “Goods or servicesper unit of labor or expenses” Productivity = outputs/inputs Software Productivity = functionality/hours ● Unit cost of software goes up with size ● Marginal costs for software increase with size ● There are different costs for each component
  • 5.
    MEASUREMENT ● Standard units ●Houses can be measured in square feet ● Software can be measured too ● Measuring things is repeatable ○ an inch today is an inch tomorrow ● Measuring eliminates wasteful guessing and introduces accurate and justifiable
  • 6.
    LINES OF CODE ●Language dependent ● Skill dependent ● Unknown until written ● No Standards ● Function Points are better
  • 7.
    FUNCTION POINTS ARESTANDARDIZED Large user group IFPUG - http://ifpug.org 1,200 members in 30 countries around the world ISO Standard IFPUG v4.3 is an ISO standard De-facto standard estimating packages: Cocomo II, Construx Estimate, etc. Certified Function Point Specialist official IFPUG certification test Counting Practices Manual official manual by IFPUG FP data repositories large repositories of data
  • 8.
    HISTORY ● 1979 FPsintroduced by Alan Albrecht ● 1984 First FP guidelines ● 1986 First IFPUG Board of Directors ● 1994 CPM Release 4.02003ISO standard ● 2003 ISO standard ● Adoption rate is increasing
  • 9.
    OVERVIEW ● Measured fromthe user's perspective ● Technology-independent ● Low cost (once the system is in place) ● Repeatable ● Works well with use cases ● Answers lots of questions ● Can be automated
  • 10.
    TYPES OF COUNTS 1.Development ○ all phases through deployment ○ forms a baseline 2. Enhancement ○ in production, has a baseline ○ count the size of successive enhancements 3. Application ○ in production, no baseline ○ forms a baseline
  • 11.
    BENEFITS AND USES ●Accurate and justifiable estimations of ○ Cost ○ Duration ○ Staffing ● Actionable productivity metrics, including ○ Defect rate ○ Cost per function point ○ Velocity (fp/hr) ● Competitive advantages ○ Fixed prices ○ Real data and facts to drive decisions
  • 12.
    BENEFITS AND USES ●software sizing ● when and what to re-engineer ● communication ● test case estimation ● over-time reduction ● productivity ● project inventory ● scope creep ● estimates ● true cost ● repeatability ● contracts ● organization portfolio
  • 13.
    APPLY THE DATA Given: ● a team of developers that average 18 FP/month (velocity) ● at an average cost of $5200/month per developer ● with requirements doc that contains 197 FP Derive: ● months of effort ○ 197 / 18 = 11 man-months ● cost ○ 11 x 5200 = 57,200 dollars ● duration ○ 2.5 x 2.2 = 5.5 months ● minimum duration ○ .75 x 2.2 = 1.65 months ● staff ○ square root of 11 = 3.3 developers ● and many, many more magical formulas!
  • 14.
    WHEN NOT TOUSE ● when sizing maintenance efforts ○ detective work ○ maintenance productivity can vary ● when analyzing performance issues ○ may not be related to functionality ○ more likely about throughput & processing
  • 15.
    CHALLENGES Must be anongoing corporate software metrics program initiative, not an afterthought or on-the-side pet project Must be systematized and well-managed in order to be accurate Counting requires special training and/or special software Usage of count data will challenge and transform existing management practices
  • 16.
    TIP OF THEICEBERG