GEF 492'13 Estimating Size: Function Points

1
GEF 492.13Estimating Size Function Points
Royal Military College of Canada Electrical and
Computer Engineering
Dr. Terry Shepard shepard_at_rmc.ca 613-541-6000
ext. 6031
Other sources - van Vliet, 7.3.5 - other
professors at RMC
2
Review

• Why do we estimate?
• To aid in planning
• Name describe some estimating techniques
• Parkinson
• Price to Win
• Expert
• Analogy
• Delphi
• Top down/bottom up
• Algorithmic
• What are their strengths weaknesses?

3
The Case for Function Points
4
Whats a good unit of measure for software size?

• ProductivityGoods or services produced per
  unit of labour and expense
• suppose the goods or services are lines of
  deliverable source code - LOC or SLOC
• Q Does moving to a higher-order language
  compiler increase productivity?

5
Consider an example
ACTIVITY CASE A
CASE B
ASSEMBLER FORTRAN
VERSION
VERSION
(10,000 LINES) (3,000 LINES) DIFFERENCE

-------------- -------------- --------------
Requirements 2
Months 2 Months 0
Design 3 Months
3 Months 0
Coding 10 Months 3
Months - 7
Integration/Test 5 Months 3
Months - 2 User
Documentation 2 Months 2 Months
0
Management/Support 3 Months 2
Months - 1
-------------- --------------
-------------- Total
25 Months 15 Months -
10
-------------- -------------- --------------
Total Costs
125,000 75,000 - 50,000
Cost Per Source Line 12.50
25.00 12.50
Lines Per Person Month 400
200 - 200
6
The Software Productivity Paradox

• Software involves a substantial number of
  activities that behave like fixed or inelastic
  costs that are not associated with coding.
• requirements analysis
• writing specifications (analysis/design)
• generating user documentation
• project planning/management
• configuration management/change control
• Increasing the efficiency of code generation
  increases the cost per line of source code!
• That makes no sense - so whats a good measure of
  size?
• not SLOC
• Completed Applications?
• User Stories?
• UML use cases?

7
A Different Measure of Productivity

• In the late 1970's A.J. Albrecht of IBM took
  the position that the economic output unit
  of software projects should be valid for all
  languages, and should represent topics of concern
  to the users of the software.
• Estimate and measure the functionality of
  software
• external aspects visible to the user
• the users functional requirements

what about the effects of non-functional
requirements?
8
Revised productivity, using FPs
ACTIVITY CASE A
CASE B
ASSEMBLER FORTRAN
VERSION
VERSION
(10,000 LINES) (3,000 LINES) DIFFERENCE

-------------- -------------- --------------
Requirements 2
Months 2 Months 0
Design 3 Months
3 Months 0
Coding 10 Months 3
Months - 7
Integration/Test 5 Months 3
Months - 2 User
Documentation 2 Months 2 Months
0
Management/Support 3 Months 2
Months - 1
-------------- --------------
-------------- Total
25 Months 15 Months -
10
-------------- -------------- --------------
Total Costs
125,000 75,000 - 50,000
Cost Per Source Line 12.50
25.00 12.50
Lines Per Person Month 400
200 - 200
ACTIVITY CASE A
CASE B
ASSEMBLER FORTRAN
VERSION
VERSION
(30 F.P.) (30 F.P.) DIFFERENCE

-------------- -------------- --------------
Requirements 2
Months 2 Months 0
Design 3 Months
3 Months 0
Coding 10 Months 3
Months - 7
Integration/Test 5 Months 3
Months - 2 User
Documentation 2 Months 2 Months
0
Management/Support 3 Months 2
Months - 1
-------------- --------------
-------------- Total
25 Months 15 Months -
10
-------------- -------------- --------------
Total Costs
125,000 75,000 - 50,000
Cost Per F.P. 4,166.67
2,500.00 - 1,666.67
F.P. Per Person Month 1.2
2.0 0.8
9
Some data
from http//www.softwaretechnews.com/fall95/functi
on.html
See also http//www.qsm.com/FPGearing.html
Java is somewhere in this range
10
When can we Count?

• In early product planning?
• During requirement specification?
• After requirement specification?
• After Design?
• After Delivery?

11
How are function points counted?

• Based on the external aspects / units of
  functionality visible to the user (ie. what the
  application does)
• Only count those software functions that are
  approved ie. benefit the end user
• Look at logical Data Groupings, Logical
  Transactions (algorithms are a
  complication)
• Not included
• job control/operating system functions
• temporary files
• possible or actual implementation details

12
How to count function points - officially

• Release 4.0 of the IFPUG Function Point Counting
  Practices Manual is about 200 pages long. Many
  people feel that it does not adequately explain
  the function point counting process six page
  magazine articles or summaries in textbooks like
  van Vliet do not accomplish this either.....
• But - it is NOT complicated (YMMV) - we now
  return to our regularly scheduled lesson

13
Types of Function Points

• Functionality...
• number of input types I
• number of output types O
• number of enquiry types E
• number of logical internal files L
• number of interfaces F

14
Function Points - stricter descriptions

• I EI External Input an elementary process in
  which data crosses the boundary from outside to
  inside. The data may be used to maintain one or
  more internal logical files
• O EO External Output an elementary process in
  which derived data passes across the boundary
  from inside to outside. Additionally, an EO may
  update an ILF
• E EQ External Inquiry an elementary process
  with both input and output components that result
  in data retrieval from one or more internal
  logical files and external interface files. The
  input process does not update or maintain any
  FTRs File Type References and the output side
  does not contain derived data
• L ILF Internal Logical File a group of
  logically related data or control information
  that is maintained by the application itself
• F EIF External Interface File Logically
  related, user identifiable data or control
  information that is not maintained within the
  application boundary

See slides 35 to 39 for more complete descriptions
15
Weighting the Functions

• Function points are not all equal
• Relative Weighting

• function point simple average complex
• input 3 4 6
• output 4 5 7
• enquiry 3 4 6
• logical files 7 10 15
• interfaces 5 7 10
• Weighted Sum yields count of Unadjusted Function
  Points (UFPs)

16
Determining simple, average and complex
of data elements (DETs) of file types
(FTRs) 1-4 5-15 gt15 0-1 simple
simple average 2-3
simple average complex gt3
average complex complex
This is a simplification there is ongoing
research - The International Function Points
Users Group
you dont want to go there!
17
Unadjusted Function Points (UFP)

• If all are average complexity

UFP 4I 5O 4E 10L 7F

• measures functionality of the system
• a raw how big the system is in terms of
  functionality

18
Raw Function Points unadjusted function points

• Caveats
• not a direct measure of the effort required to
  build the system
• is a major cost driver that effects this level of
  effort
• count is the same regardless of who is building
  the system or the conditions under which the
  system is being built

19
Adjusted Function Points

• If we imagine that we were always working with a
  nominal software development team working under
  nominal conditions then the function points would
  be a measure of effort.
• We can adjust the function point count for our
  particular conditions.
• The result is to say that building our system
  would require the same effort as building a
  system with the adjusted count under nominal
  conditions.

20
General Application Characteristics

• Production Environment Factors, each of which has
  a Degree of Influence (DI)
• Data communications
• Distributed data and processing
• Performance objectives
• Heavily-used configuration
• Transaction rate
• On-line data entry
• End-user efficiency
• On-line update
• Complex processing
• Reusability
• Conversion and installation ease
• Operational ease
• Multiple-site use
• Facilitate change

influence of each factor on design, development,
support, implementation is assigned a weighting
factor (DI) of 0-5 Sum these for a Total Degree
of Influence (TDI) Note that people factors are
not considered
21
(No Transcript)
22
Making the Adjustment

• Value Adjustment Factor
• (VAF) (TDI X .01) .65
• Then
• Adjusted Function Points (AFP) VAF UFP
• The adjusted function points are measure of
  equivalent effort for a specific project
• i.e. the adjusted function points no longer
  directly indicate the size of the project

23
Function Points Good and Bad
24
What are they good for...

• Defining When and What to Re-Engineer
• Estimating Test Cases
• Understanding Wide Productivity Ranges
• Understanding Scope Creep
• Calculating the True Cost of Software
• Estimating Overall Project Costs, Schedule and
  Effort
• Understanding Maintenance Costs
• Help with contract negotiations
• Understanding the appropriate set of metrics

25
What are they not good for...

• Performance tuning
• related to interaction of function
• Web Design
• high graphic intensity
• Small projects
• individual skill is confounding factor
• Maintenance
• primarily detective work on internal relations

26
Summary of Function Points

• If you want to measure productivity, SLOC is a
  poor measure
• Function Points (and similar systems) can provide
  a better estimate
• But there is a lot to learn about their real use

27
Example
28
Reality

• Real function point counting systems are complex
• They require carefully defined function point
  counting guides and practices
• eg. DETs, FTRs,
• We will work through the Weather application
  example --- taken from
• http//www.ifpug.com/Function20Point20Training2
  0Booklet20New.pdf
• next two slides state the problem

29
The Weather Application

• The following application was designed to capture
  temperature and rainfall by city and state.
  There are only one input screen, one file and one
  report. Each field on the following input screen
  can be modified (add, changed or deleted). The
  add and change functions are different. All
  previous entries viewed by using the scroll bar.
  Assume a VAF of 1.0.

30
Weather Application Example
31
Next COCOMO II
32
more details on function pointssee URLs below,
and following slides
http//www.softwaremetrics.com/examples/default.ht
m
An ongoing research effort The International
Function Points Users Group http//www.ifpug.org/
33
Backfiring

• It should be possible to guess how many function
  points are implemented based on the number of
  lines of code
• For example, if you had an application consisting
  of 106,000 line COBOL program, the table given
  earlier would lead you to believe that you had a
  1,000 function point system
• But this approach can make a product design that
  is implemented with excessive amounts of code
  look like a functionally rich product
• adjusted or raw??

34
Functions Points at a glance
35
External Inputs (EI)

• an elementary process in which data crosses the
  boundary from outside to inside.
• This data may come from a data input screen or
  another application.
• The data may be used to maintain one or more
  internal logical files.
• The data can be either control information or
  business information.
• If the data is control information it does not
  have to maintain an internal logical file

36
External Output (EO)

• an elementary process in which derived data
  passes across the boundary from inside to
  outside. Additionally, an EO may update an ILF.

37
External Inquiries (EQ)

• an elementary process with both input and output
  components that result in data retrieval from one
  or more internal logical files and external
  interface files. The input process does not
  update or maintain any FTRs (Internal Logical
  Files or External Interface Files) and the output
  side does not contain derived data. .

38
Internal Logical File (ILF)

• a group of logically related data or control
  information that is maintained by the application
  itself. Must
• be logical grouping user identifiable
• maintained through an elementary process within
  the application boundary

39
External Interface File (EIF)

• logically related, user identifiable data or
  control information that is not maintained within
  the application boundary
• be logical grouping user identifiable
• be external to the application
• maintained through an elementary process outside
  the application boundary (ie is an ILF of another
  app).