HOW TO CALCULATE FUNCTION POINTS IN PLATFORM, PRODUCT, APPLICATION DEVELOPMENT TO OPTIMZE EFFORTS & COST

Function point analysis is considered to be an amazing tool for pro­vi­ding assis­tance to users in deter­mining the benefits of a product, feature, utility use case etc. for their organization, by coun­ting the func­ti­ons that spe­ci­fi­cally match their requi­re­ments. It sup­ports the analy­sis of pro­duc­ti­vity and qua­lity, either direc­tly or in con­junc­tion with other metrics such as effort, cost and defects. However, the catch 22 situation arises when the deve­lop­ment method of the orga­ni­za­tion is cha­o­tic or unstable(each pro­ject is deve­lo­ped in a dif­fe­rent way). In that case, even if the func­tion points coun­ting of the pro­ject and the effort record have been made cor­rec­tly, the analy­sis of pro­duc­ti­vity among the pro­jects would have been impaired. Let’s dig deeper to understand these terminologies:

What is a Function Point(FP)?

A measure representing functional size of a software product or application. It standardizes metrics describing a unit of product work suitable for quantifying software based on what the end user requests & receives.

What is Function Point Metrics(FPM)?

Function point metrics effectively measures functionality from the users point of view, on the basis of what the user requests and receives in return. It’s intent is to deliver a dimensionless number defined in function points which can be considered as an effective relative measure of function value delivered to our customer. In it’s key essence it broadly evaluates two aspects of quantifying the software product or application:

1. Measures the Measure functionality that the user requests and receives.
2. Measures software product development and maintenance independently of technology used for implementation.
3. Measure software by quantifying the functionality the product provides to the user based primarily on logical design.

What is Function Point Analysis(FPA)?

In the simplest of language, we can define Function Point Analysis as a standard method for measuring product development & maintenance from customer’s point of view. It can be used in existing, under-development or yet to be conceptualized applications.

How is Functional Point Analysis(FPA) Useful?

1. It is a great utility to determine the size of a a product, feature or module by counting all the functions included in the application.
2. It facilitates users to determine the benefit of an application package to their organization by counting functions that specifically match their requirements.
3. It also facilitates measurement of the units of a software product to support quality and productivity analysis.
4. It is invaluable in estimating cost & resources required for product development and it’s subsequent maintenance.
5. It is a great tool to establish a normalization factor for product/feature/module comparison.
6. Since it is linked directly to product/module/application requirements and functionality, it can help with communications between the end user community and the developers, assist with requirements management, functional size traceable throughout entire life cycle & most importantly it will be applicable from earliest requirements stage and throughout the product/feature/application life-cycle.
7. It can be also categorized as a tool which is technology, product/platform, and language independent.
8. It facilitates earned value management & gap analysis in the requirements.

What is Function Point Count(FPC)?

We can understand Function Point Count as the measurement of the function point of a platform, product or application or even a project. When we consider to adoption of function point count, the following aspects are best practices which should be taken into consideration:

1. It should be simple enough to minimize the overhead of the measurement process.
2. It should ideally be a consistent measure among various projects and organizations.

When to Count Function Point?

The Function Point could be counted across different stages of product development viz; proposal phase, requirement phase, design phase, development phase, QA phase, Delivery phase, Corrective Maintenance phase etc. This is depicted in Figure 1.1 below.

What is the process of Functional Point Count(FPC)?

Considering the fact that Function Point Analysis can help manage a product as well as the project & improve the probability of completing a it within the stipulated time and within budget, it becomes important to understand the process of Functional Point Count to execute the analysis. Refer to the step by step illustration(Figure 1.2) to get a high level overview of this:

Figure 1.2 General Steps Leading to FPC

Step 1: Type of FPC

The type of function point count should be determined at the outset. There are 3 types of function point counts: (a) Development project function point count (b) Enhancement project function point count (c )Application function point count.

Step 2: Identification of Scope

A boundary, which defines the system viewed by the users and determines any interaction with other systems, should first be determined so as to set up the scope for the related functions to be identified.

Step 3: Identification of Scope Complexity

Once the boundary of the application is determined, it is imperative to further identify the level of complexity of it’s execution.

Step 4: Determination of unadjusted FPC

The unadjusted function point reflects the functionality of a logical system provided to the user. Only user-requested and approved business functions are counted. Easiest way for this determination is illustrated below in Figure 1.3 as a distribution of 5 function types:

Figure 1.3 General FP Data & Transactional Functionality

Figure 1.3 FP Data & Transactional Functionality App Example

(a)An Internal Logical File (ILF) is a user identifiable group of logically related data or control information maintained within the application scope. The primary purpose of an ILF is to hold data maintained through one or more elementary processes of the primary application being counted. For example, A pilot may feed navigation data via a display before journey. Data is stored in a file & can be modified in future. Hence, the pilot is responsible for maintaining the file containing navigational information.

(b) An External Interface File (EIF) is a user identifiable group of logically related data or control information referenced by the application, but maintained within the scope of another application(ILF). The primary purpose of an EIF is to hold data transferred through one or more elementary processes within the boundary of the application counted. For example; It may be necessary for the pilot to reference position data from satellite or ground based facility during the flight. Here the pilot isn’t responsible for updating data on these sites but must reference it during the journey.

(c )An External Input (EI) is the smallest unit of activity that is meaningful to the end user in the business. The primary purpose of an EI is to maintain one or more ILF and/or to alter the behaviour of the system. For example, the pilot can add, change and delete navigational information before or during the journey. In a way, he/she is utilizing a transaction or EI which gives the capability to maintain data through adding, changing & deleting it’s content.

(d) The External Output (EO) is an elementary process that generates data or control information sent outside the application’s boundary. The primary purpose of an EO is to present information to user through processing logic other than or in addition to the retrieval of data or control information. For example, the pilot has the ability to display ground speed, true air speed & calibrated air speed. The results displayed here is derived from the maintained & referenced data or EO.

(e) An External Enquiry (EQ)is an elementary process made up of an input-output combination that results in data retrieval. The primary purpose of an EQ is to present information to the user through the retrieval of data or control information. For example, the pilot displays terrain clearance data that was previously set, the resulting output is direct retrieval of stored information (EQ).

For example, an application called billing will have it’s own set of boundaries/scope oriented towards satisfaction of the billing requirement. Now, there could a separate order management application or CRM which will have their own respective boundaries/scope. When we have multiple applications like this involved, we approach this by measuring one application at a time. For example; billing is our primary application to measure. Each application has their form of data storages. These data storage is called logical files in FPA. This is because it only considers the logical file that these storages hold but doesn’t matter in what format they are stored in. The data which is within the primary application of analysis is called ILF(Internal Logical Files ~ Billing Application) while the ones which are there in secondary application is called EIF( External Interface Files~ CRM/Order Management Storage Files). Now, usage of all these files occurs by multiple means. Like, a user may input data into the primary application(billing app). Such functionalities which input data into the application are called “External Input(EI)”. Some users may consume data from the app. If it is just basic fetching of information, it is called “External Query(EQ)” which is simply pick up of & display of data while some cases the data retrieval upon the request could be after some simple or complex calculations/derivations etc. This is “External Output(EO)”. These form the entities for your FPA of a billing application which has direct/indirect relationship with other external applications by the means of transactions.

It is very important to assessed for its complexity by the measure of low, average and high. Organizations/Platforms/Products that use FP methods, develop criteria for determining whether a particular entry is Low, Average or High even though it maybe subjective most times. Once classification of each of the five function types is established, the UFP is computed using predefined weights for each function type. A usable template is shared below to get started:

Typical Complexity Weights (Credits: platformrenderapps.com)

UFP Calculation Template 2 (Credits: platformrenderapps.com)

Where each of the complexity weight is provided a definition say 1 for “No Influence’, 2 for ‘Incidental’, 3 for ‘Moderate’, 4 for ‘’Significant, 5 for ‘Essential’ and so on.

Step 5: Determination of Value Adjustment Factors

The penultimate step involves evaluating the environment and processing complexity of the project or application as a whole. In this step, the impact of 14 general system characteristics(shown in the template below)is rated on a scale from 0 to 5 in terms of their likely effect on the project or application.

General System Characteristic Glossary (Credits: platformrenderapps.com)

Value Adjustment Calculation Template (Credits: platformrenderapps.com)

VAF= TDI x 0.01 + 0.65

Step 5: Calculation of Final Adjusted FPC

The last step involves the calculation of the Final Adjusted FPC to arrive at a conclusion of the function point analysis to arrive at the function point of the product, feature or module.

Function Point(FP)= UFP(Unadjusted FP) x VAF(Value Adjustment Factor)

Now that we have arrived at the steps leading to Function Point Analysis, let us review an execution with a simple example. Say, Table 1.1 represents the UFP count of a feature when the above process is being followed:

Table 1.1: Sample Table of UFP

Say Table 1.2 represents the value adjustment factor

Table 1.2 Sample Table of VAF

Now, this implies that VAF = 52 X 0.01 +0.65 = 1.17

So, Estimated FP = UFP x VAF = 318 x 1.17 =372

Now, for calculating the source line of code (SLOC), you may use the following formula:

Say, FP= Function Points

LP= Line of Code =Say, LOC for java is assumed as 53 (https://www.qsm.com/resources/function-point-languages-table)

Then SLOC= FP x LP = 372 X 53=19716

Say, man hours invested on burning 372 FP= 160 Hours

=> 1 FP ~372/160=2.325

In future, you can take this as your reference and multiply the functional point arrived at with the approximate estimated time take to complete 1 FP. In our example it is say 2.325. In a similar way, an approximate cost can be analysed using the same mathematical manipulation. Please note that this is tentative and it would be a wrong expectation to expect the effort to exactly match this. Even if it does, it would be a coincidence.

Functional Point Analysis has been instrumental in a robust, consistent & optimized product development process. Hope the article above will be useful in your journey to bring forth a science to sustain optimized transparency in the product/feature or application development process. I will be obliged to listen to any queries or feedback you would want to share at firstgobletinnovation@gmail.com or anuragchaudhuri92@gmail.com.

LinkedIn URL: https://www.linkedin.com/in/anuragchaudhuri92/

Your engagement encourages me to write more of my experiences. If it even makes difference to 1 life, I would consider my efforts to be successful.

References:

http://www.lrgl.uqam.ca/ IFPUG: Function Point Counting Practices Manual, Release 4.1.1

R. S. Pressman, Software Engineering: A Practitioner’s Approach, McGraw-Hill, 2000