Function Point Analysis – Introduction and Fundamentals

Every new project in an organization goes through an analysis phase. The information collected during the analysis forms the backbone for critical decisions with regards to the complexity, resources, frameworks, time schedule, cost, etc. Over the years, there have been several techniques to simplify the project analysis phase, but most of them still remain inadequate when considering the accuracy of the outcome. Even clearly defined projects can fall out during the later stages without an accurate analysis methodology in place.

Mitigation of risk in software projects turns out to be of prime importance. Usually, it starts with delineating precise measurements concerning the scope, performance, duration, quality and other key efficiency metrics of the project. Advanced analysis techniques like Function Point Analysis (FPA) bring a clear picture regarding each of these metrics, chiefly related to the project scope, staffing, cost and time, which helps in the management, control, customization of software development right from its initial planning phases.

Function Point Analysis is a standardized method used commonly as an estimation technique in software engineering. First defined by Allan J. Albrecht in 1979 at IBM, Function Point Analysis, has since then underwent several modifications, mainly by the International Function Point Users Group (IFPUG).

What is Function Point Analysis?

In simple words, FPA is a technique used to measure software requirements based on the different functions that the requirement can be split into. Each function is assigned with some points based on the FPA rules and then these points are summarized using the FPA formula. The final figure shows the total man-hours required to achieve the complete requirement.

Components of Function Point Analysis

Based on the interaction of the system components internally and with external users, applications, etc they are categorized into five types:

External Inputs (EI): This is the process of capturing inputs from users like control information or business information and store it as internal/external logic database files.
External Outputs (EO): This is the process of sending out data to external users or systems. The data might be directly grabbed from database files or might undergo some system-level processing.

Inquiries (EQ): This process includes both input and output components. The data is then processed to extract relevant information from internal/external database files.

Internal Logic File (ILF): This is the set of data present within the system. The majority of the data will be interrelated and are captured via the inputs received from the external sources.
External Logic File (ELF): This is the set of data from external resources or external applications. The majority of the data from the external resource is used by the system for reference purposes.

Source: https://bit.ly/2N2KFhy

Below are some abbreviations which need to be understood to know the logic in-depth:

Data Element Type (DET): This can be defined as a single, unique, non-repetitive data field.

Record Element Type (RET): This can be defined as a group of DETs. In a more generic way, we can call this a table of data fields.

File Type Referenced (FTR): This can be defined as a file type referenced by a transaction (Input/Output/Inquiry). This can be either an Internal logic file or an external interface file.

Based on the number of DETs and RETs, all the five components of FPA are classified into High, Average and Low complexity based on the below table.