In some articles, we frequently FACE many distorted statements and questions regarding the technique of function point analysis, which does not show anything besides a lack of knowledge about the subject. Who has not heard the false statement “function point analysis doesn’t serve to measure objectoriented systems”?

More recently, with the consolidation of the UML as the standard market language for analysis and objectoriented design, another frequent false claim is that the function point analysis is not meant to measure systems whose requirements were expressed according to specifications of use cases. A specific discussion of this issue was presented in the March 2004 Bulletin.

Since the late 90’s a test management technique that originated in Holland, called “TMap — Test Management Approach” is GAINING traction, driven by the wave of process improvement initiatives based on quality STANDARDS such as ISO and CMM. Its implementation is supported by a test estimation technique called Test Point Analysis (TPA) which, in turn, is based on Function Point Analysis (FPA).

TPA is used specifically to estimate the effort requiredin the execution of acceptance and system testing. For this, the TPA considers relevant, besides the functional size determined by function points, two other elements: the testing strategy and the productivity. Even when the element is “size”, it adds more factors that have more influence on the effort than specifically on functional size, as algorithmic complexity, degree of integration with other functions and functional uniformity.

Although it is a consistent and useful technique for INCREASING the quality of the process and software product, TPA preaches one more fuzzy concept on the analysis of function points when it says that this cannot be used to estimate the effort in activities involving acceptance and system testing. Nevertheless , this means that the Function Point Analysis (FPA) considers the particularities of the development process while applying the technique of COUNTING. Which is not true.

The result of TPA application is measured in a unit of effort (hours), unlike the function point analysis, which measures the functional size of software project. Thus, as indeed does not directly measure the effort used in the tests, the FPA also does not measure the effort used in the analysis phase, design or construction of the software. Its main function is to measure the functionality delivered by the software project. However, function points can be used perfectly well as an input to a process of effort estimation of different stages of development, as discussed in the January 2004 Bulletin.

The biggest benefit of TPA is being able to gather, in a systematic way, the factors that influence the effort of a specific stage of the development process, producing more accurate results.

In some articles, we frequently face many distorted statements and questions regarding the technique of function point analysis, which does not show anything besides a lack of knowledge about the subject. Who has not heard the false statement “function point analysis doesn’t serve to measure objectoriented systems”?

More recently, with the consolidation of the UML as the standard market language for analysis and objectoriented design, another frequent false claim is that the function point analysis is not meant to measure systems whose requirements were expressed according to specifications of use cases. A specific discussion of this issue was presented in the March 2004 Bulletin.

Since the late 90’s a test management technique that originated in Holland, called “TMap — Test Management Approach” is gaining traction, driven by the wave of process improvement initiatives based on quality standards such as ISO and CMM. Its implementation is supported by a test estimation technique called Test Point Analysis (TPA) which, in turn, is based on Function Point Analysis (FPA).

TPA is used specifically to estimate the effort requiredin the execution of acceptance and system testing. For this, the TPA considers relevant, besides the functional size determined by function points, two other elements: the testing strategy and the productivity. Even when the element is “size”, it adds more factors that have more influence on the effort than specifically on functional size, as algorithmic complexity, degree of integration with other functions and functional uniformity.

Although it is a consistent and useful technique for increasing the quality of the process and software product, TPA preaches one more fuzzy concept on the analysis of function points when it says that this cannot be used to estimate the effort in activities involving acceptance and system testing. Nevertheless , this means that the Function Point Analysis (FPA) considers the particularities of the development process while applying the technique of counting. Which is not true.

The result of TPA application is measured in a unit of effort (hours), unlike the function point analysis, which measures the functional size of software project. Thus, as indeed does not directly measure the effort used in the tests, the FPA also does not measure the effort used in the analysis phase, design or construction of the software. Its main function is to measure the functionality delivered by the software project. However, function points can be used perfectly well as an input to a process of effort estimation of different stages of development, as discussed in the January 2004 Bulletin.

The biggest benefit of TPA is being able to gather, in a systematic way, the factors that influence the effort of a specific stage of the development process, producing more accurate results.