Function Points Step by Step

ABSTRACT

Many individuals struggle with counting function points even though they understand the function point counting rules. This article describes the necessary steps to complete a function point count. Additionally, the necessary documentation needed to complete a function point count is discussed. The counting process should utilize existing application and project documentation. The Step by Step counting process should be used in association with the article Fundamentals of Function Point Counting and  Function Point Counting Practices Manual, Release 4.1, by IFPUG.

This is an article on some mechanics of FPA.  Please see the article, Are Function Points More Useful than A Swiss Army Knife

OBJECTIVES OF FUNCTION POINT ANALYSIS

To provide accurate sizing, as early as possible, that can be used as an input into the estimating process.

To provide a mechanism to track and monitor scope creep. Function point counts at the end of requirements, analysis, design, code, testing and implementation can be compared. The function point count at the end of requirements and/or designs can be compared to function points actually delivered. If the project has grown, there has been scope creep. The amount of growth is an indication of how well requirements were gathered by and/or communicated to the project team. If the amount of growth of projects declines over time it is a natural assumption that communications with the user has improved.

KEY DELIVERABLES

Key deliverables from a Function Point Count are:

• Total Unadjusted Function Point Count
• The Unadjusted function point count by EI, EO, EQ, ILF and EIF’s.
• The Value Adjustment Factor (VAF).
• The total adjusted function point count.
• Validation reports -- as prescribed in step 8.

KEY INPUTS

Depending on the phase of the project the following documents will be needed.

• Documentation of the users’ perceived objectives, problems and needs.
• Collected documentation regarding the current system, if such a system (either automated or manual) exits.
• Any refined objectives and constraints for the proposed system.
• Any other requirement documentation completed to date.
• Screen Formats and dialogues
• Report Layouts
• Layouts of input forms
• Interfaces with other systems and between systems
• Logical and/or preliminary physical data models

KEY ASSUMPTIONS

The following assumptions are made:

• The Function Point Counting Practices Manual, Release 4.0, by IFPUG is used.

• The person completing the function point count has received training in function points prior to counting. Ideally, the application expert will count function points with the assistance of an Function Point Counting Expert.

Initial Steps

Prior to counting function points the application boundaries must be determined. The application boundary should be drawn around the entire application, not individual project teams. The function point counting expert and the application functionality expert need to work together to determine the boundary. The result of this initial step will be a boundary diagram. Refer to chapter 4, pp. 4-1 through 4-4, Function Point Counting Practices Manual, Release 4.0 by IFPUG. Drawing of the application boundary is a critical step in counting function points. This boundary will determine additional the inputs into Checkpoint, a tool used for estimating.

Step 1 - Planning the Function Point Count

The task of counting function points should be included in the overall project plan. That is, counting function points should be scheduled and planned. The first function point count should be developed to provide sizing used for estimating.

Function points can be counted prior to the completion of requirements. The function point counts completed early in the life cycle should be thoroughly documented, so they can be easily maintained and updated. Of course, early estimates using function points (or any method) are subject to change as much as the requirements. In short, if the scope and size of the project changes, the effort required to complete the project will change also. Function point analysis can be completed prior to having a complete set of requirements, but a function point count should be completed after the requirements have been finalized and again at implementation.

After the function point count has been completed it should be compared to previous function point counts to verify any new components or changed components and the function point count updated accordingly. Each addition to the function point count should have an attached label indicating if the new component or changed component is the result of changed functionality or if it is the result of improved function point counting.

Step 2 - Gathering the documentation

The following recommended documentation will assist in completing function points counts prior to the finalization of requirements.

Documentation of the users’ perceived objectives, problems and needs.

Collected documentation regarding the current system, if such a system (either automated or manual) exits.

Any refined objectives and constraints for the proposed system.

Description and/or model of the overall system framework.

Any other requirement documentation completed to date.

A more detail function point can be completed after analysis and design. Recommended documentation during and after the completion design.

Screen Formats and dialogues

Report Layouts

Layouts of input forms

Interfaces with other systems and between systems

Logical and/or preliminary physical data models

Filed sizes and formats

Menu Options

The function point counts completed prior to design should be compared to the function point counts after the completion design. This will be an indicator of how much the application has grown since requirements.

Recommend documentation at the conclusion or implementation of the project should include all the above mentioned documentation and any additional system documentation.

Step 3 - Determine the Value Adjustment Factor

Determine the Value Adjustment Factor (VAF). The VAF should be reviewed during the initial stages of function point counting. As the count proceeds the VAF can be updated as necessary and as more information is discovered. The VAF should be reviewed and updated at the completion of each subsequent step.

The value adjustment factor (VAF) is based on 14 general system characteristics (GSCs) that rate the general functionality of the application being counted. Each characteristic has associated descriptions that help determine the degrees of influence of the characteristics. The degrees of influence range on a scale of zero to five, from no influence to strong influence. The IFPUG Counting Practices Manual provides detailed evaluation criteria for each of the GSC, the table below is intended to provide an overview of each GSC.

Step 4 - Inventory of Transactions and Files

A complete inventory of all Function Point Components (EI’s, EO’s, EQ’s, ILF’s and EIF’s) should be completed prior to classifying the individual components. It is best to inventory all transactions prior to taking an inventory of the files. As transactions are inventoried, a listing of files needed for the transactions should be maintained. After the inventory of transactions is complete the file listing should be reviewed. Completing a the file inventory this way helps to insure files that are not ILF’s or EIF’s have not been included.

External Inputs (EI) - is an elementary process in which data crosses the boundary from outside to inside. This data may come from a data input screen or an other application. The data is used to maintain one or more internal logical files. A good source of information to determine EI’s are Screen Layouts, Screen Formats & dialogs, and layouts of any input forms. Additional inputs from other applications should be inventoried here. Inputs from other applications must update ILF’s of application being counted.

External Outputs (EO) - an elementary process in which derived data passes across the boundary from inside to outside. The data creates reports or output files sent to other applications. These reports and files are created from one or more Internal Logical Files A good source of information to determine the EO’s are report layouts and electronic file formats that are being sent outside the application boundary.

External Inquiries (EQ) - an elementary process with both input and output components that result in data retrieval from one or more Internal Logical Files. The input process does not update any Internal Logical Files, and the output side does not contain derived data. A good source of information to determine the External Inputs (EI’s) are Screen Layouts, Screen Formats & dialogs, and layouts of any input forms

Internal Logical Files (ILF) - a user identifiable group of logically related data that resides entirely within the applications boundary and is maintained through External Inputs. A good source of information to determine the ILF’s are logical and/or preliminary physical data models, table layouts, data base descriptions.

External Interface Files (EIF) - a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application and is maintained by another application. The External Interface File is an Internal Logical File for another application. A good source of information to determine EIF’s are interfaces descriptions with other systems.

The completed inventory of components should be distributed among the project team to insure that everything has been included. Once it is confirmed that all transactions and files have been included, then classifying individual components can take place.

Step 5 - Classification of Components

It is important to understand the matrix’s associated with the transactions (EI’s, EO’s, EQ’s) and files (ILF’s, EIF’s). The counter should identify the appropriate row prior to determining the column. There is much less granularity in determining the appropriate row (number of files referenced for transactions and the number of record types for files) than determining the appropriate column. This helps reduce the amount of effort required to complete a function points count.

Extending the above analysis, commonality should be considered prior to counting transactions and files. The function point counter should ask the following type of questions to help expedite the counting process.

External Inputs - Do external inputs need more or less than 3 files to be processed? For all the EI’s that reference more than 3 files, all that is needed to know is if the EI has more or less than 4 data element types referenced. If the EI has more than 4 DET’s the EI will be rated as high, less than 4 DET’s the EI will be rated as average. Any EI’s that reference less than 3 files should be singled out and counted separately.

External Outputs - Do external outputs need more or less than 4 files to be processed? For all the EO’s that reference more than 4 files, all that is needed to know is if the EO has more or less than 5 data element types. If the EO has more than 5 data element types then the EO will be rated as high, less than 5 the EO will be rated as average. Any EO’s that reference less than 4 files should be singled out and counted separately.

External Inquires - the same analysis can be conducted as outlined in EI and EO, but using the higher of the EI and EO as prescribed in the IFPUG counting practices manual.

Internal Logical Files and External Interface Files - Do all files contain one record type of more than one record type? If all or many of the files only contain one record type, then all that is needed to know if the file contains more or less than 50 data elements types (DET’s). If the file contains more than 50 data elements the file will be rated as average, if less than 50 data element types the file will be considered low. Any files that contain more than one record type can be singled out and counted separately.

Step 6 - Review 14 General System Characteristics

The 14 GSC’s should be reviewed to insure accuracy. Each GSC’s is rated on a scale from zero to five where from no influence to strong influence. Once all the 14 GSC’s have been answered, they should be tabulated using the IFPUG Value Adjustment Equation (VAF) --

Add up all the results from the GSC's.  Divide this number by 100 and add .65.

It is important to accurately apply the GSC’s and VAF, because they can impact the overall function Point Count by +/- 35%.

Step 7 - Tabulation of Results

The counts for each level of complexity for each type of component can be entered into a table such as the following one. Each count is multiplied by the numerical rating shown to determine the rated value. The rated values on each row are summoned across the table, giving a total value for each type of component. These totals are then summoned across the table, giving a total value for each type of component. These totals are then summoned down to arrive at the Total Number of Unadjusted Function Points.

The Unadjusted Function Point Count is multiplied by the Value Adjustment Factor to obtain the Adjusted Function Point Count.

Step 8 - Validate Results

The results of the function point count should be reviewed by the entire project team and validated by the metrics coordinator. The greatest sources of errors in function point analysis are errors of omission. Other errors arise when physical constructions are substituted for logical constructions and are counted as components. The project team therefore should review the function point analysis for completeness and should verify that all components (EI, EO, EQ, ILF, and EIF) have been included. The metrics coordinator should work with the function point counter to ensure the process has been followed properly and the he or she followed the prescribed validation process.

There are key questions to ask during function point counting. Any question that is answered no needs a short explanation. The following questions should be asked.

1. Is the function point count a task in the overall project plan?
2. Is the person performing the function point count trained in Function Point Counting?
3. Did the function point counter use current documentation to count function points?
4. Were IFPUG 4.0 Counting Practices Manual guidelines followed.
5. Were internally developed function point counting guidelines followed?
6. Was the application counted from the user’s point of view?
7. Was the system counted from a logical and not a physical point of view?
8. Does the established boundary for the FP count match the boundary of other metrics (time reporting, defect tracking)? If not, why?
9. Do the individual FP components (ILF, EIF, EI, EO, and EQ) percentages conform to industry averages (40% for ILF’s, 5% for EIF’s, 20% for EI’s, 25% for EO’s, and 10% for EQ’s) and averages established for GTE? If not, is there a valid reason?
10. Has an inventory of transactions (EI, EO and EQ) and files (ILF and EIF) been reviewed by the project team.
11. Do each of the 14 GSC’s fall within the ranges of other projects counted within the organization
12. Has the count be logged into a Function Point repository?
13. Are all the assumptions consistent with other projects counted?
14. Have all the assumptions been thoroughly documented?
15. Has the count been reviewed by an experienced FP counter?

Copy and reproduction of this article is permitted if and only if copyright notice appears.

Copyright Longstreet Consulting Inc. 2000
www.SoftwareMetrics.Com
David@SoftwareMetrics.Com