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.

For Internal Logical Files

And based on the complexity, the FPA points are calculated

For External Logical Files

And based on the complexity, the FPA points are calculated

For External Input Transactions

As the External input is a Transactional type, the complexity is judged based on FTR instead of RET.

And based on the complexity, the FPA points are calculated

For External Output Transactions

As External Output is a Transactional type the complexity is judged based on FTR instead of RET.

And based on the complexity, the FPA points are calculated

For Inquiries

As Inquiries is a Transactional type the complexity is judged based on FTR instead of RET.

And based on the complexity, the FPA points are calculated

As we now have the reference chart to find the complexity of each variety of functions discovered in the system and that we also have the Points that should be assigned based on the complexity of each component. We can now look into the calculation.

Steps to Count the Function Points

Below are the steps used in counting the function points of a system.

1. Type of count: The very first step of this process is to determine the type of function count. There are 3 types of function point (FP) count. 

  • Development Project FP Count: This measures the functions that are directly involved in the development of the final system. This would include all the phases of the project from requirements gathering to the first installation.
  • Enhancement Project FP Count: This measures the functions involved in the modifications brought in the system. That is the changes made to the system after production.
  • Application FP count: This measures the functions involved in the final deliverable excluding the effort of already existing functions that may have existed.

2. Scope and Boundary of the Count: In the second step, the scope and boundary of the functions are identified. Boundary indicates the border between the application being measured and the external applications. Scope can be decided with the help of data screens, reports, and files.

3. Unadjusted Function Point Count: This is the main step of this process where all the function points produced from the above FPA components (External Inputs, External Output, Internal Logic files, External Logic files, Inquiries) are added together and labeled as unadjusted function point count.

4. Value Adjustment Factor: In this step the value adjustment factor is determined. VAF contains 14 General system characteristics(GSC) of the system or application that defines the types of application characteristics and is rated on a scale of 0 to 5. The sum of all the 14 GSC rates are calculated to give out a mathematical value and is labeled as Total Degree Influence(TDI). TDI is used in the calculation of VAF and its value may vary from 0 to 35.

Below are the 14 GSCs listed and the mathematical formula for calculating the VAF.

  • Data communications
  • Distributed data processing
  • Performance
  • Heavily used configuration
  • Transaction rate
  • On-Line data entry
  • End-user efficiency
  • On-Line update
  • Complex processing
  • Reusability
  • Installation ease
  • Operational ease
  • Facilitate change
  • Multiple sites

Once the unadjusted function point and value adjustment factor is calculated, the Adjusted Functional point count is found out using the two values. This is done with the help of the following formula. 

The Adjusted FPC is then multiplied with a numeric value, which is the effort based on the technology. Some of the examples are below.

If the technology selected for a particular requirement is Java, then the formula to calculate the final hours are as follows:

FPC = (Non-adjusted FPC*VAF) * 10.6

This will give the total hours of effort required to achieve the requirement under analysis.

Merits of Function Point Analysis

  • FPA measures the size of the solution instead of the size of the problem
  • It helps in estimating overall project costs, schedule, and effort
  • It is independent of technology/programming language
  • It helps in the estimation of testing projects
  • FPA gives clarity in contract negotiations as it provides a method of easier communication with business groups

Related Read: Quality Assurance in Software Testing – Past, Present & Future

References

 

Stay up to date on what's new

    About the Author

    ...
    parvathy

    With over 8 years of experience in the IT industry, Parvathi clearly understands the strategic business process modeling, traceability, and quality management techniques. She is working as a Project Coordinator and business analyst in Fingent and majorly deals with processing requirements to create conceptual prototypes and mock-ups. Her key interests revolve around working on technical solutions for business problems and translate customer needs into new products.

    Recommended Posts

    Real Estate Industry

    23 Feb 2023 Real Estate B2B

    Futuristic Technologies Transforming The Real Estate Industry!

    According to a 2020 report, 58% of real estate brokers have a clearly defined digital strategy, a figure that represents a 6% increase from the two previous years and thus……

    Software development

    29 Nov 2022 B2B

    Build Or Buy: Analyzing The Most Crucial Step In Software Development!

    To build or to buy has been a million-dollar question most businesses seek an answer for. This can become more daunting when you consider the numerous factors influencing the decision.……

    22

    14 Jan 2022 B2B

    Know What’s Driving Custom Software Development Cost in 2024!

    Everyone uses software products. From toddlers to grandparents, in one way or the other, almost everyone has used a software product. The number of mobile devices operating worldwide stood at……

    software development outsourcing

    25 Jun 2021 Logistics

    Software Development Outsourcing Guide for CEOs – Fingent

    How CEOs Can Gain Value from Software Development Outsourcing In-house creation of a complete and sophisticated software application requires large amounts of resources and time. Maintaining an in-house team amid……

    ×