Allan J. Albrecht first developed Function Point Analysis during his time at IBM in 1979. Since then, the technique has been continually refined by the International Function Point Users Group (IFPUG) and has become a widely recognized software engineering methodology.
It is a basic method for evaluating software functionality, which helps estimate the resources required for development and maintenance. FP Analysis provides a standardized approach to evaluating software functionality, making it an indispensable tool for software project managers and developers. This method allows for better project scope determination, project timeline setting, and efficient project resource management. In FP Analysis, software functionality is evaluated based on the inputs, outputs, inquiries, and internal logical files, which are classified into different complexity levels to calculate a final score. This score estimates the size and complexity of the software, and it is used to determine the resources and time needed for development and maintenance. Given its ability to provide accurate estimates, FP Analysis has become an integral part of software engineering.
Objectives of Function Point Analysis
- The fundamental aim of functional point analysis (FPA) is to measure and communicate the functional size of a software application to the clients, customers, and stakeholders, as required.
- By providing a standardized approach to evaluating software functionality, FPA enables project managers and developers to estimate the resources required for development and maintenance accurately.
- This methodology allows for better project planning, scope determination, and resource allocation, which ultimately results in more efficient and effective software development and maintenance.
Types of FPA
Functional Point Analysis (FPA) involves two primary types of functionality –
- Transactional Functional Types
- Data Functional Types.
The transactional functional type comprises the following elements:
- External Input (EI): This type of function processes data or control information that originates from outside the application’s boundary. EI is considered an elementary process in FPA.
- External Output (EO): EO is an elementary process that generates data or control information sent outside the application’s boundary.
- External Inquiries (EQ): EQ is an elementary process consisting of an input-output combination that results in data retrieval.
The data functional type comprises the following two elements:
- Internal Logical File (ILF): An ILF is a group of logically related data or control information identifiable by the user, which is maintained within the application’s boundary.
- External Interface File (EIF): An EIF is a group of logically related data maintained within the boundary of another software that is identifiable to users in the software.
Following are the Points Regarding Functional Point (FP) Analysis
- To determine the FPs of an application, one must tally the number and kinds of functions employed in the application.
- FPs are indicative of the intricacy of a software system and can, therefore, be utilized to estimate project duration and the necessary workforce.
- The resources needed to construct a project are contingent upon the functions of the software.
- FP is not reliant on the programming language being used.
- The FP technique is suitable for information systems such as data processing systems and business systems.
- The information domain characteristics mentioned above are often referred to as the five parameters.
Steps to Count Function Points in a system
Step 1 – Firstly, determine the type of function count required for the system.
There are three types of FP counts
- Development Project FP Count
- Enhancement Project FP Count
- Application FP count
Development Project FP Count
This type of function point count measures the functionalities that are directly involved in the development of the final system. It includes all the phases of the project, from requirements gathering to the initial installation.
Enhancement Project FP Count
This function point count measures the functionalities involved in the modifications made to the system after production. It captures the changes made to the system to enhance its features and functionality.
Application FP count
This type of function point count measures the functionalities involved in the final deliverable, excluding the effort of any pre-existing functions that may already exist in the system. It captures the features and functionalities of the completed application that is ready for deployment.
Step 2 – Scope and Boundary of the Count – The second step involves determining the scope and boundary of the functions. The boundary represents the demarcation between the application being measured and external applications. To determine the scope, data screens, reports, and files can be used as reference points. The scope of the functions can be defined by identifying the data elements that are required to be processed within the application being measured.
Step 3 – Unadjusted Function Point Count – The unadjusted function point count is the main step in the process of counting function points. This step involves adding up all the function points derived from the various FPA components, including external inputs, external outputs, internal logic files, external interface files, and inquiries. The sum of these function points is referred to as the unadjusted function point count.
Step 4 – Value Adjustment Factor – In the value adjustment factor step, the VAF is determined. The VAF is composed of 14 general system characteristics (GSCs) of the system or application, which define the types of application characteristics, and is rated on a scale of 0 to 5. The 14 GSC rates are summed up to provide a mathematical value, which is known as the Total Degree of Influence (TDI). The TDI is utilized in the computation of the VAF, and its value ranges from 0 to 35.
Advantages of FPA
- FPA can be used to determine the size of purchased application packages by counting all the functions included in the package.
- FPA provides a normalization factor for software comparison.
- FPA can measure the units of a software product to support quality and productivity analysis.
- It helps users discover the benefit of an application package to their organization by counting functions that match their requirements.
- It can estimate the cost and resources required for software development and maintenance.
Function Point Analysis Drawbacks
- FPA requires a subjective evaluation and involves multiple judgments, which may lead to inaccuracies.
- Many cost and effort models are based on Lines of Code (LOC), making it necessary to convert function points to LOC.
- Learning FPA can be time-consuming and requires a long learning curve, making it challenging to gain proficiency.
- Due to subjective judgments involved in FPA, the accuracy rate of the assessment may be low.
- Compared to LOC, there is limited research data available on function points.
- FPA is performed after the design specifications have been created, making it difficult to identify errors or omissions in earlier project phases.
- FPA is a time-consuming method that may not be suitable for fast-paced or agile projects.
Keep following our tutorials.freshersnow.com frequently to receive the updates regarding the Functional Point (FP) Analysis.