This document discusses using function points to estimate the cost and time required for a software project. It provides an example of estimating a program for a phone order company. The example counts the function points for the program's inputs, outputs, files and queries, then converts this to lines of code and staff hours using standard metrics. Finally, it calculates the estimated cost for the project based on typical programmer salaries. The document advocates that function point analysis provides a more accurate estimation approach than just comparing to past similar projects.

1. Software Project CostSoftware Project Cost
EstimationEstimation
UsingUsing
Function PointsFunction Points
ByBy
Drew TkacDrew Tkac

2. Program Estimation ExampleProgram Estimation Example
• Phone order company thinks they need a customer /
order taking program.
• New customer contact information is entered into data
base controlled by the program. Fields are:
– First Name
– Last Name
– Street Address
– City
– State
– Zip Code
– Phone Number
– Initial Contact Date

3. Program Estimation ExampleProgram Estimation Example
• Inventory data base, controlled by another program, is referenced
for orders.
– Stock Number
– Quantity in Stock
– Selling Price
• Customer order data base is maintained by the program. Fields are:
– First Name
– Last Name
– Stock Number of Item Purchased
– Quantity Purchased
– Date of Purchase
• All records within the program may be created, modified or deleted.
• How long will it take and how much will it cost to write
this program?

4. The Point of Function Points….The Point of Function Points….
• A unit of software work
• Generated during the requirements stage
for size and effort estimation.
• Worst estimation technique, ahead of all
the others.
• Something to count at the requirements
stage as opposed to lines of code.
• Calibrated to type of software and past
staff performance.

5. Function Point Users GroupFunction Point Users Group
• The standard for function point counting is
International Function Point Users Group
(IFPUG) www.ifpug.org
• Offer classes, seminars and certification.
• Maintain data bases and references.

6. Useful Regardless of SoftwareUseful Regardless of Software
ModelModel
Requirements Design Implementation Verification Maintenance
Adaptive Predictive
Big Giant
Requirements
Bite Sized
Requirements
Design Implementation Verification Maintenance
Predictive
Adaptive

7. Function Points Useful to….Function Points Useful to….
• The business / department
– Used to determine ROI
– What features can be compromised?
• The technical staff / consultant
– Used to determine staffing requirements
– Used for performance review
– Used to establish schedule
– Used to estimate cost

8. Function Points ProvideFunction Points Provide
An EstimateAn Estimate
• How long does it take you to get here from
home?
• Normal conditions: 10 min.
• Could it ever be 1 min?
• Could it ever be 20 min?
• Could it ever not happen?
• Estimation – Has a probability attached – 98% of
the time it takes 10 min +/- 2 min

9. Software Cost Estimates:Software Cost Estimates:
Black Art or Real Science?Black Art or Real Science?
• Currently typical software organizations are
struggling to avoid estimates that are
incorrect by 100% or more.
• Most common estimation technique -
compare new project with past project
based on personal memory. Guessing,
intuition and unstructured expert judgment
are used for 60% to 85% of estimates.

10. Results of Past ProjectsResults of Past Projects

11. Some Past Project SizesSome Past Project Sizes

12. Performing Function PointPerforming Function Point
AnalysisAnalysis
1. Start with the project requirements.
2. Count function points.
3. Convert function points to lines of code based
on programming language.
4. Convert lines of code to programmer hours
based on project type, and performance
history.
5. Convert programmer hours to dollars using
average values or staff salaries.

13. Characteristics of a Software
Program
Input Output
External Files
Process
Internal Files
Program

14. What to Count?What to Count?
• External Inputs (EI)
• External Outputs (EO)
• External Queries (EQ)
• Internal Logical File (ILF)
• External Interface File (EIF)

15. External Inputs (EI)External Inputs (EI)
• Screens, forms, dialog boxes, or control signals
through which an end user or other program
adds, deletes, or changes program data.
• Grouped logically.
• Number of data elements determine the logical
inputs complexity. (Data element type DET)
• Include any input that has a unique format or
unique processing.

16. External Input ExampleExternal Input Example
Name
Street Address
Zip
Phone
Part Number
Part Description
Program
1 External Input with 4 DET
1 External Input with 2 DET

17. External Outputs (EO)External Outputs (EO)
• Screens, reports, graphs, or control
signals that the program generates for use
by an end user or other program.
• Grouped logically.
• Number of data elements determine an
outputs complexity. (DET)
• They include any output that has a
different format or different processing
than other types.

18. External Output ExampleExternal Output Example
Program
1 External Output with 4
DET
First Name
Last Name
Date of Purchase
Item Purchased

19. External Queries (EQ)External Queries (EQ)
• Input/output combinations in which an
input results in an immediate, simple
output.
• Receive data directly from a data base
with little formatting.

20. Internal Logical Files (ILF)Internal Logical Files (ILF)
• Major logical groups of end user data that
is completely controlled by the program.
• Number of data elements control
complexity.
• Single table in a data base or a data file

21. External Interface Files (EIF)External Interface Files (EIF)
• Files controlled by another program with
which the program interacts.
• Major logical group of data.
• Number of data elements control
complexity.

22. Tally the Points, AccountingTally the Points, Accounting
WorkWork
• Each EI, EO, EQ, EIF, and ILF have
values attached.
• Complexities for each are considered.
• Additional factors are applied to produce
adjusted function points.
• Can be cross checked to other methods.
• Tables are available via IFPUG

23. The Dutch MethodThe Dutch Method
• Works well early in the project
• High degree of uncertainty
• Best applied to data base related projects
• Great to determine if the project is worth
taking the next step.
• Developed by Netherlands Software
Metrics Association (NESMA)
• Formula: Function Point Count = (35 X Internal
Logical Files) + (15 X External Interface Files)

24. Convert Function Points to LinesConvert Function Points to Lines
of Codeof Code

25. Lines of Code per Staff MonthLines of Code per Staff Month

26. Diseconomies of ScaleDiseconomies of Scale

27. Convert Staff Hours to CostConvert Staff Hours to Cost
Programmer’s SalariesProgrammer’s Salaries
Haskell $198,000
Erlang $99,000
Objective-C $82,000
Pascal $81,000
C++ $80,000
SmallTalk $80,000
TCL $80,000
C# $79,000
Java $79,000
Python $78,000
Perl $77,000
Ruby $74,000
COBOL $73,000
JavaScript $72,000
ColdFusion $64,000
Delphi $64,000
PHP $64,000
Visual Basic $64,000
C $60,000

28. Our ExampleOur Example
Calculate Function PointsCalculate Function Points
• Internal Logical Files
– Customer Contact File
– Customer Purchase File
• External Interface Files
- Inventory Data Base
• Using the Dutch Method:
FP = (35 X 2) + (15 X 1) = 85 FP’s

29. Our ExampleOur Example
Convert Function Points to Lines of CodeConvert Function Points to Lines of Code
• Choose the programming language that requires
the fewest number of lines of code to implement
a function point
• Consider cost of a programmer for this language
and availability
• Consider maintenance factors
• My choice was: Visual Basic
• Example program: 32 lines of code / function
point or 32 X 85 = 2720 LOC

30. Our ExampleOur Example
Convert Lines of Code to CostConvert Lines of Code to Cost
• VB Programmers $64K / year X 1.25
benefits = $80K / 12 months = $6667/mo
• Lines of code per month for a business
system, medium performance, small
project = 3000
• 2720 Lines of code / 3000 Lines of code
per month = 0.9 Months or $6045

31. ReferencesReferences
Garmus, David and Herron, David, Function Point Analysis,
ISBN-0-201-69944-3
McConnell, Steve, Software Estimation, ISBN10: 0-7356-
0535-1
International Function Point Users Group
Brooks, Fred, The Mythical Man-Month: Essays on
Software Engineering