22.214.171.124 Function Point Method (FPM)
Function Point Methode (FPM)
/IBM, 1985/ pp. 7-13
The Function Point Method (FPM) was developed by IBM. It is a combination of the analog method (the FP curve is based on the empirical values from similar projects) and weighting method (evaluation of the influence factors for the project). FPM is closely related with the function-oriented development methods (like SSADM, HIPO) and-based on the user requirements-concentrates on the functions. The effort estimation takes complexity, certain software characteristics, and productivity into consideration. The Function Points (FP) are applied as a measuring means for the productivity used to specify the effort.
- Determination of the Function Points
In order to determine the Function Points, the functions are defined and classified, according to external input, external output, logical internal file, external interface file, and external inquiry ("transactions"). After that, these transactions are classified according to their complexity (simple, average, complex). Based on the type and the degree of complexity, the transactions are weighted. The addition of these weights of all transactions results in the (unadjusted) Function Points.
- Determination of the adjusted Function Points
Influence factors like interlacing with other projects, decentralized data management, transaction rate, complex processing, reusability, conversions, user friendliness are taken into consideration and evaluated with regard to the influence they are having on the project. The degree of influence is calculated from the sum of the influence factors. Multiplying the unadjusted function points with the degree of influence results in the adjusted function points. As compared to the (unadjusted) function points, these can be increased or reduced by up to 30 %.
- Determination of the Effort
Based on a productivity curve/table, the adjusted function points are converted into man-months. To realize this, an "IBM curve" is available which should be successively replaced by individual empirical values from post-calculations.
Criteria for the Application of the FPM
- Commercial Application
FPM is particularly suited for IS developments; the effort estimation for ECS developments (small data volume, processing-oriented) is not sufficiently exact. This is due to the classification of the functions on the basis of the data to be processed, the processing complexity is globally evaluated as an influence factor across all functions.
- Development Project
The FPM procedure is not suited for SWMM projects. Normally, the basis for the estimation and the influence factors in an SWMM project have not been noticeably changed as compared to the ones in the development project. On the other hand, however, SWMM-based measuring quantities (like "additional input data") and influence factors (e. g. "personnel continuity") are lacking.
- Function-Oriented Engineering
Function-oriented engineering is no requirement for the FPM application. However, this type of methodical development facilitates the application of the FPM since it already covers the step to determine the transactions.
Strong and Weak Points of the Method and possible Remedial Measures
- Estimation Basis "Function Point"
The Function Points as an estimation basis are detected by means of the type and complexity degree of the functions, i. e. from the user's point of view. The technical realization has no impact on the estimated value (+). The FPM separated from the frequently applied estimation basis LOC which is only effective towards the end of the development process, anyway. Therefore, even staff members from the specialist departments can be made to participate in the effort estimation (+).
- Micro Estimation
The FPM offers no support for the breakdown of the specified effort to submodels, (sub-) activities, (sub-) products, or V-Model functional units (-). Therefore, a micro estimation is only possible by means of empirical values, the utilization of an experience database, or the integration of other methods.
- Influence Factors
Influence factors from SW quality, personnel, and software development environment (SDE) are not explicitly considered in the FPM. Implicitly they may partly influence the FP curve (pairs of values "function point-effort") but, because of this, either these must be uniform across the majority of the projects or must be minutely documented in order to guarantee the comparability of the projects (-). Therefore, if the project characteristics deviate, additions or subtractions must be made to or from the FP curve, or a separate FP curve must be generated for different project types so the dispersion of the values can be reduced and the precision of the procedure can be increased.
On the other hand, constant project characteristics (usually personnel and SDE) need not be specially evaluated, they are implicitly considered via the FP curve (+).
To get an objective evaluation, a unique delimitation/classification of the complexity and the weighting of the influence factors must be defined (-). However, up to a certain degree, an insufficient "objectively correct" estimation of the function points can be substituted by a constant "subjectively uniform" estimation.
- Method Familiarization
The familiarization with the clearly defined and simply structured method generally does not present a real problem (+); however, certain experience has to be expected for the application of the FPM with regard to the function point determination (-) since a separation from the realization-oriented aspects is requested.
- Application of the Method
FPM is a method to be applied at an early point to estimate efforts and to deliver realistic values by taking into consideration the above mentioned application criteria (+).
In order to adjust the IBM-FP curve to the individual situation, post-calculations have to be realized for completed projects (-). To maintain the FP curve in a current state, the latest project values ought to be upgraded or successively exchanged for the old ones. This way, any possible productivity trends can be recognized.
- Tool Support
The tool support for FPM may be helpful for small and average projects, but it is not really required (+). However, documentation should guarantee the traceability of the effort estimation by means of the corresponding forms. In large projects computer-based support is required because of the volume problem (-).
- not applicable -
- FPM in PM 1.3 "Planning":
By taking into consideration the above mentioned application criteria, the FPM can be applied for the effort estimation within the scope of preliminary planning. However, since no effort distribution is realized within FPM, the efforts for submodels and main activities must be generated on the basis of empirical studies and started out from the total effort.
The application of FPM is possible, within the scope of the project plan generation for the contractor and within the scope of the contract definition for the customer..
- FPM in PM4 - Detailed Planning:
FPM is not suited for the effort estimation within the scope of the detailed planning since the FPM method does not include a dedicated effort estimation for subactivities and subproducts. Therefore, the micro estimation is required in this case as well on the basis of empirical values or by applying other methods, e. g. the Delphi Method /Busch, 1972/.
The FPM has already been modified in several ways. Different versions exist with regard to
- the classification of the transactions:
/Albrecht, 1983/ and /Noth, 1986/: external input, external output, logical internal file, data file for other applications, and external inquiry
/IBM, 1985/: external input, external output, logical internal file, external interface file, and external inquiry
/Sneed, 1987/: data objects, input messages, output messages, on-line processes, batch processes
- the numbers and types of the influence factors:
/Albrecht, 1983/ and /Noth, 1986/: 14 influence factors
/IBM, 1985/: 7 influence factors
- the range of the degree of influence:
/IBM, 1985/: +/- 30 %
/Albrecht, 1983/ and /Noth, 1986/: +/- 35 %
- the upgrade by one software quality factor
The Data Point Method was developed by Harry M. Sneed /Sneed, 1991/, i. e. as an alternative to CoCoMo and FPM and as an answer to the trend towards data- or respectively object-oriented software development.
The procedure applied to determine the data points is similar to the one applied to determine the function points, with the difference that data objects and not transactions are concentrated on. The data point method can be applied for the estimation of commercial systems on the basis of a data model, FPM on the basis of a functional model.
Method ASSET-R /Reifer, 1989/ determines the size and effort of a real-time system via function points. In ASSET-R, real-time-oriented influence factors like process interfaces and operating modes are taken into consideration when setting up the function points. However, ASSET-R then returns via influence factors like system architecture and programming language to the estimation basis LOC.
||Comparison of the FPM with LOC-based Effort Estimation Methods
||Definition of the Delphi Method
||Original Literature (IBM Product Information)
||Definition and Introduction into FPM, Appraisal, Further Developments, |
and Application Proposals (pp. 89-105, p. 118)
||Description of Method ASSERT-R as compared to other Estimation Methods
||Explanation of the FP Method as compared to the Methods CoCoMo |
and Component Analysis Method (pp. 79-80, p. 175, pp. 178-181, pp. 185-189, pp. 195-196)
||Brief Description of the Data Point Method
||Critical Assessment of the FPM, Improvement Proposals (Mark II)
Last Updated 01.Jan.2002
Updated by Webmaster
Last Revised 01.Jan.2002
Revised by Webmaster