Function Points Step by Step
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 from a Function Point Count are:
Depending on the phase of the project the following documents will be needed.
The following assumptions are made:
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.
A more detail function point can be completed after analysis and design. Recommended documentation during and after the completion design.
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.
Step 6 - Review 14 General System Characteristics
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.
Copy and reproduction of this article is permitted if and only if copyright notice appears.