FPA - Function Point Analysis is one of the best methods for measuring functional size of a software. It is defined within the IFPUG FSM Method.
The FPA principles were introduced in 1979 by Alan Albrecht and his IBM colleagues. Then IBM waived the copright making FPA public and available to anyone and in 1986 IFPUG has been chartered. IFPUG (International Function Point Users Group) is a non-profit organization which promotes and encourages use of Function Points.
In general FPA helps develop consistent and accurate counting guidelines and maintains Public Standard for Sizing Software (CPM).
Function Point Analysis is a consistent, standardized method for measuring the functionality delivered to an end user. Although it's available at the early project's development stage, it provides acceptable and meaningful level of accuracy.
Functional size measurement (FSM) is accomplished using the information in a language that is common to both users and developers.
The FPA principles were introduced in 1979 by Alan Albrecht and his IBM colleagues. Then IBM waived the copright making FPA public and available to anyone and in 1986 IFPUG has been chartered. IFPUG (International Function Point Users Group) is a non-profit organization which promotes and encourages use of Function Points.
In general FPA helps develop consistent and accurate counting guidelines and maintains Public Standard for Sizing Software (CPM).
Function Point Analysis is a consistent, standardized method for measuring the functionality delivered to an end user. Although it's available at the early project's development stage, it provides acceptable and meaningful level of accuracy.
Functional size measurement (FSM) is accomplished using the information in a language that is common to both users and developers.
Objectives of Function Point Analysis
Most practitioners of Function Point Analysis (FPA) will probably agree that there are three main objectives within the process of FPA:
- Measure software by quantifying the functionality requested by and provided to the customer.
- Measure software development and maintenance independently of technology used for implementation.
- Measure software development and maintenance consistently across all projects and organizations.
In working towards objectives 2 and 3 above, several organizations have created large repositories of FP counts that cross projects, technologies, and organizations. These repositories can be an invaluable tool for your first estimation efforts, because it lets you compare your project to similar projects that have been developed by other organizations around the world.
Strengths and weaknesses of the FPA method
These days, time and money are the most valuable resources, therefore every business invention can be boiled down to looking for time- or money-savings. And so is with Function Points Method. Basically, the process of application developing or modifying usually is unknown - it's very difficult to predict what exactly is profitable.
In case of logistics, everything can be boiled down to kilometers, for instance. In case of IT applications, problem is more complex. The role of logistics' kilometers is played by function points there. Thank to them, it is easy to estimate the time needed for introducing changes or developing a new application. Thank to standardization it's also easier to compare the complexity of two (or more) applications written in different programming languages. Moreover, it no longer is a problem to rate development efficiency or estimate needed resources.
On the other hand, there still are countries which FPA isn't popular in. Why?
In a word, it must be remembered that Function Points Analysis isn't free of disadvantages.
In a word, it must be remembered that Function Points Analysis isn't free of disadvantages.
- Most of the weaknesses concern low accuracy of evaluating because usually a 'subjective judgement' is involved.
- Gaining proficiency in the Function Point Analysis is not easy, the learning curve is quite long.
- The method is quite time-consuming thus might result costly. External consultancy might be helpful, especially during the initial projects.
Against all odds, FPA remains the most common method for measuring the applications. Moreover, it still is being developed and improved, therefore its disadvantages are supposed to get eliminated quickly. After all, further growth of FPA popularity is certain.
Function points in practice
The idea of function points - slicing the system into smaller parts - seems simple, but the problem was how to distinguish each part.
Finally, they have decided to focus on five types of components:
- EI - external inputs, which are the components responsible for introducing changes in system's internal data.
- EO - external outputs, which are the ways system's internal data can be presented, but beware - there are a few similarities with EQ components, though.
- EQ - external inquiries, which are the methods for reading system's data without modifying it.
- EIF - external interface files, which are responsible for exchanging data with other systems.
- ILF - internal logical files, which are files that are being used by the system itself.
How to perform Function Points Analysis?
Every FPA must be begun with grouping the components of the system we'd like to analyze. That's why the five groups (listed above) are distinguished. Once the components are selected and grouped, we can turn to analyzing itself.
Basically people solve problems by dividing them into smaller parts. And so is with measuring the application complexity with Function Points Method. Thereupon, instead of trying to evaluate the application as a whole, we need to rate each of the selected groups. How exactly to do it?
We need to classify the complexity of each category. We therefore have three possibilities - the complexity could be low, average, or high. Then, the thing is to count the scores following the rules tabled below:
| Component: | Complexity: | ||
| Low | Average | High | |
| EI | 3 | 4 | 6 |
| EO | 4 | 5 | 7 |
| EQ | 3 | 5 | 6 |
| EIF | 5 | 7 | 10 |
| ILF | 7 | 10 | 15 |
Then, the whole "problem" is to sum the values. A total of them represents the number of application's function points.
Function points examples
STOCK CONTROL SYSTEM - estimating the time needed to develop application
Let's imagine a company which sells goods on the phone - if agents call the customers, customers call the agents, and so on - business operates successfully, but there comes a time for putting the whole in order. There occurs a need for developing a system able to control the whole stock, from orders to payments. Our thing is to estimate how complex such system can be and - after that - try to predict how long it would take to develop it.
At first, we should pay attention to the functionality - what exactly the system should be able to do. Basically, it should be able to take care about three parts - customers, stock, and transactions. Then, let us group functions into five categories:
- External Inputs - customer, order, stock, and payment details. There are four things we need to consider.
- External Outputs - customer, order, and stock details, and credit rating. Once again, there are four things to consider.
- External Inquiries - the system is requested for three things, which are customer, order, and stock details.
- External Interface Files - there's no EIFs to consider.
- Internal Logical Files - finally, the four elements belong to the last group. Customer, and good files, and customer, and good transaction files.
That's all about selecting the components. Unfortunately, it's the most difficult aspect of FPA because of lack of specified rules determining how to distinguish functions. Moreover, it's very easy to forget about a thing or place it in a wrong category. Nonetheless, there is only mathematics left to accomplish the function points analysis.
Let's predict every function's complexity is low, so the values can be presented in a table:
| Category | Multiplier | Weight |
| EI | 4 | 3 |
| EO | 4 | 4 |
| EQ | 3 | 3 |
| ILF | 4 | 7 |
4*3+4*4+3*3+4*7=65 [Function Points]
Let us omit additional technical complexity factors, so the only thing left to do is to check how long it takes to produce 65 function points. Some sources prove that one function point is an equivalent of eight hours of work in C++ language. Then, the last thing is:
65*8=520 [hours]
The answer? The estimate for developing the application would take about 520 hours of work.