The CPM includes all of the IFPUG Function Point Rules

The CPM includes all of the IFPUG Function Point Rules

We defined IFPUG Function Points as a measure of the functionality delivered by a project or application. We also talked about their uses and criticisms in the Metrics Minute. What this blog has not explored is how to count function points.  Function points are generated by counting five basic components that represent the features and functions of the project or application based on a set of rules. The rules are for counting IFPUG Function Points are documented in the IFPUG Counting Practices Manual (CPM). The following counting process has been slightly modified from the IFPUG CPM:

  1. Determine the type of count and determine the counting scope.  IFPUG recognizes three types of counts.
    1. An application count whose scope includes all of the functionality for a specific application.
    2. An enhancement count scope includes the functionality a project adds to, changes or deletes from an existing application and any conversion functionality.
    3. A development project that includes all the functionality built for a new application and supporting conversion functionality.
  2. Determine the boundary (ies). The boundary defines what we are interested in sizing and represents a line in the sand between the application and the user domains.
  3. Gather the available documentation. Once the count type, counting scope and boundaries have been established, the counter will gather the documentation available for the count.  It may include demonstrations of the system, interviews with developers and architects, requirements, user stories, data flow diagrams and models, design documents and user manuals.  This list is incomplete, and depending on when in the flow of development the count is performed, a subset of the listed documentation may exist.  Sometimes you will need to use a less conventional approach. For example, in an Agile project I recently witnessed, the counter sized the delivered stories as part of the each demo (I detail this process here), rather than relying on project documentation.  Note that the IFPUG CPM calls for counters to do this step first, however I find it more efficient to gather the documentation after the type of count and scope are determined.
  4. Identify the functional user requirements. IFPUG function points are an interpretation of the functional user requirements based on the rules identified in the IFPUG CPM.  The CPM defines functional user requirements as “what the software shall do, in terms of tasks and services[1].”
  5. Measure the data functions.  IFPUG recognizes two types of data functions.  The first is an Internal Logical File (ILF).  An ILF is a user-recognizable group of logically related data maintained within the boundary of the application being measured.  Employee is an ILF typically found in a human resources application.  The logical grouping of data needed to define an employee would be grouped together as single logical group (even if it were in multiple tables or objects).  The logical group data named “employee” would be easily recognizable by users of the systems. This logical group of data can have records added, changed and deleted by an HR system, therefore the ILF can be maintained. The second type of data function is called an External Interface File (EIF).  An EIF is an ILF from another application that is used as reference.  For example, the HR system may require the entry of a health benefit package when adding or changing an employee. Let’s assume that the definition of the health benefits package was maintained in the benefits application. The health benefits package would be an ILF in the benefits application and an EIF if used for validation or reference in the HR application.  A counter would identify the ILFs and EIFs in the scope of the count. When doing an enhancement count the counter would count all of the ILFs or EIFs that were added (new), changed (modified structure) or deleted.  Application counts would count all ILFs within the boundaries and any EIFs referenced in the application.  Finally a development project would count any ILFs added (by definition a development project is equivalent to a new application.  Once the counter has identified the data functions he or she will determine their size.  We explore the science of sizing ILFs and EIFs here.

The process continues with:

  1. Measure the transaction functions:  There are three types of transactions: External Inputs, External Outputs and External Inquires.
  2. Getting to a number and some optional bits:  Once all of the data and transaction functions have been identified and sized, generating a count is simple mathematics.  The outcome of a count at this point is called an Unadjusted Function Point Count.  A set of 14 characteristics can be appraised for each application in the count to adjust the count for the differences based on a set of criteria yielding an adjustment factor.  Application of the adjustment factor to the unadjusted count yields an adjusted function point count (this is the optional bit).
[1] IFPUG Counting Practices Manual 4.0, January 2010, Part 2, Section 1-3