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.

  • 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.
  • 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.
  • 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.

  • 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.

  1. Data communications
  2. Distributed data processing
  3. Performance
  4. Heavily used configuration
  5. Transaction rate
  6. On-Line data entry
  7. End-user efficiency
  8. On-Line update
  9. Complex processing
  10. Reusability
  11. Installation ease
  12. Operational ease
  13. Facilitate change
  14. 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

Looking for a reliable IT solutions provider?

Fingent has helped businesses leverage the power of IT to create solutions that solve complex business challenges for more than 13 years. Get in touch with us for a free consultation to know how you can leverage our expertise in web and mobile applications to improve your business for higher productivity and profits.

Parvathi Chandran

Parvathi Chandran

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.  

View all posts >>

Leave a Reply

Your email address will not be published. Required fields are marked *