Levels of Function Point Counting

( Download pdf Version )

Version 1.3 January 2004
Pam Morris - Total Metrics (Australia)
Email : Pam.Morris@Totalmetrics.com or visit www.totalmetrics.com

Introduction

A function point count can be conducted at a number of 'levels', each of which provides a count which has its:

  • Decisions documented to different levels of detail
  • Results within different bounds of accuracy.

 The level of detail for a particular count will depend on the purpose for which the count will be used. Different purposes will require different degrees of accuracy and detail in the documentation and consequently different counting rates. The most optimal level of counting may not always be able to be achieved in a particular situation since the level actually selected may be constrained by:

  • the quality of project or application documentation available,
  • the time in which the count must be completed,
  • planned use of the results.

This document defines a number of levels of function point counting that are available from Total Metrics. We will normally recommend a particular level to you based on how the results will be used and your description of the quality of the information available to provide background on the count. However the final decision will rest with the client and the quality of the information available.
A particular application count may be conducted at one of the following levels detail:


Level Name

  1. Detailed Linked and Flagged Count
  2. Detailed Linked Count
  3. Detailed Count
  4. Default Complexity Count
  5. Rough Count
  6. Size Approximation


Level 1: Detailed Linked and Flagged Count

Level 1 Count Description

A Detailed Linked and Flagged Count includes the following:

  • application boundary is defined
  • full functional decomposition to transaction level (transaction level is considered the lowest level function available to the business user)
  • all files and transactions within scope are uniquely identified
  • all files and transactions are classified according to type
  • all files and transactions are accurately categorised according to complexity (actual numbers of DETs and FTRs are identified where possible and provided the necessary source information is available)
  • all related files and transactions are linked (aids in assessing impact of change requests)
  • explanatory notes are attached to files and transactions as necessary (aids in future maintenance of the counts)
  • where possible a cross-reference between the physical files and the logical files is documented.
  • explanatory notes also link files and transactions to relevant documentation
  • all agreed attributes are attached to relevant transactions (aids in selective count reporting for management purposes)
  • count is recorded and reported using the SCOPE software repository tool

Level 1 Count Attributes

Detailed Linked and Flagged Count are:

  • very detailed
  • easily auditable
  • accurate (within the limits of the FPA technique +/- 10%)
  • very well documented
  • easily maintained

Best suited for following count purposes:

  • benchmarking projects (new development and enhancement)
  • detailed estimates
  • project tracking
  • as detailed baseline model for future detailed enhancement project counting
  • input into Metrics reporting for Strategic and Tactical Level reporting

Issues:

  • very time intensive - counting rates up to 200 fps per day
  • requires very skilled counters
  • rarely cost effective for large, legacy application baseline counts

Pre-requisites:

  • good to high quality system documentation
  • data model
  • full access to system experts


Level 2: Detailed Linked Count

 

Level 2 Detailed Linked Count Description

A detailed linked count includes the following:

  • application boundary is defined
  • full functional decomposition to transaction level
  • all files and transactions within scope are uniquely identified
  • all files and transactions are classified according to type
  • all files and transactions are accurately categorised according to complexity (DETs and FTRs are identified within IFPUG ranges where possible)
  • all related files and transactions are linked (aids in assessing impact of change requests)
  • explanatory notes are attached to files and transactions where necessary
  • count is recorded and reported using the SCOPE software repository tool

Level 2 Count Attributes

Detailed Linked Counts are:

  • very detailed
  • easily auditable
  • accurate (within the limits of the FPA technique +/- 10%)
  • very well documented
  • easily maintained

Best suited for the following count purposes:

  • benchmarking projects (new development and enhancement)
  • detailed estimates
  • project tracking
  • as detailed baseline model for future detailed enhancement project counting

Issues:

  • time intensive - counting rates up to 250 fps per day
  • rarely cost effective for large, legacy application baseline counts

Pre-requisites:

  • good to high quality system documentation
  • data model
  • full access to system experts


Level 3: Detailed Count

 

Level 3 Detailed Count Description

A detailed count includes the following:

  • application boundary is defined
  • full functional decomposition to transaction level
  • all files and transactions within scope are identified
  • all files and transactions are classified according to type
  • all files and transactions are accurately categorised according to complexity (DETs and FTRs are identified within IFPUG ranges where possible)
  • explanatory notes are attached to files and transactions where necessary
  • count is recorded and reported using the SCOPE software repository tool

Level 3 Detailed Count Attributes

Detailed Counts are:

  • detailed
  • auditable
  • accurate (with limits of the FPA technique +/- 10%)
  • well documented
  • very maintainable

Best suited for following count purposes:

  • benchmarking projects (new development and enhancement)
  • detailed estimates
  • baseline application counts for portfolio sizing
  • as detailed baseline model for future detailed enhancement project counting

Issues:

  • time intensive - counting rates up to 300 fps per day
  • reasonably cost effective for large, legacy application baseline counts

Pre-requisites:

  • good system documentation
  • data model if possible
  • access to system experts


Level 4: Default Complexity Count

Level 4 Default Complexity Count Description

A default complexity count includes the following:

  • application boundary is defined
  • full functional decomposition to transaction level
  • all files and transactions within scope are identified
  • all files and transactions are classified according to type
  • all files are defaulted to low complexity
  • all transactions are defaulted to average complexity
  • count is recorded and reported using the SCOPE tool

Level 4 Default Complexity Count Attributes

Default Complexity Counts are:

  • less detailed
  • auditable
  • reasonably accurate (within the limits of the FPA technique +/- 15%)
  • documented
  • maintainable

Best suited for the following count purposes:

  • portfolio baseline assessment
  • benchmarking development or support ratios
  • quality metrics
  • high level estimates
  • as a baseline model for future enhancement project counting
  • can be cost effective for large, legacy application baseline counts

Issues:

  • efficient - counting rates up to 400 fps per day
  • cost effective for large, legacy application baseline counts

Pre-requisites:

  • average system documentation
  • data model if possible
  • access to system experts


Level 5: Rough Count

Level 5 Rough Count Description

A rough count includes the following:

  • Application boundary is defined
  • functional decomposition (3-4 levels only)
  • transactions and data functions 'tallied' from menus, menu access paths, file lists, screen lists, report lists, application boundary
  • diagrams, system interface documentation
  • assumptions documented in count report
  • count is recorded and reported using the SCOPE tool

Level 5 Rough Count Attributes

Rough Counts are:

  • low detail
  • less accurate (+/- 20 - 25%)
  • documented (issues and assumptions)
  • 'Skeleton' on which enhancement counts can be built
  • needs to be refined over time

Best suited for following count purposes:

  • portfolio baseline assessment
  • benchmarking support ratios
  • as a baseline model for future enhancement project counting
  • cost effective for large, legacy application baseline counts

Issues:

  • very efficient - counting rates can exceed 750 fps per day
  • cost effective for large, legacy application baseline counts which have very little enhancement

Pre-requisites:

  • summarised system documentation
  • full-time access to system experts (for the duration of count)


Level 6: Size Approximation

There are various methods of approximating the functional size without counting all files and transactions. Such methods are often used for portfolio estimation, or as a basis for scheduling more detailed counts. They are based on characteristics of the application, which have been proven to have a strong correlation to size. Eg. Numbers of reports, number of 3rd normal form tables, and number of support staff etc. The size is estimated based on the answers to about 30 questions in a questionnaire.

Level 6 Size Approximation Description

A size Approximation includes the following:

  • size estimate reported in unadjusted and / or adjusted function points
  • assumptions documented in report

Level 6 Size Approximation Attributes

Size Approximation is:

  • very little detail -size results only
  • accuracy historically has been demonstrated to be within (+/- 20%)
  • not documented other than the completed questionnaire and a very brief report on the result
  • not maintainable, they are snapshot of size only. They need to be redone if anything changes

Best suited for following count purposes:

  • portfolio baseline assessment
  • software asset valuation
  • project scoping
  • estimating count durations
  • benchmarking support ratios
  • most cost effective for large, legacy applications, which do not need their counts maintained

Issues:

  • very efficient - most applications can have their size estimated within half a day
  • very cost effective for large, legacy application baseline counts which have very little enhancement

Pre-requisites:

  • accurate completion of a questionnaire (usually takes 2 hrs, but may take up to 2 days if the software is poorly documented or applications knowledge is limited)
  • access to system experts (1 - 2 hour interview)

Note: the number of Attribute categories attached to the count will have a significant impact on the counting rate. I.e. reduce the counting rate by 15% for each attached attribute.