Importance of function points in application development and maintenance

When it comes to the development and maintenance of software application, the things that cannot be measured cannot be managed. As a result, an increasing number of organizations throughout the world now uses the function point methodology to measure the size of software for the existing applications, enhance the applications and for new projects.

When the function points are combined with other factors, the estimation and benchmarking of maintenance requirements and project delivery rates can be estimated accurately. In this post, we’ll have a detailed look at what the function points are, its counting process, and how they are truly used.

Origin

The function point metric which is now commonly used by reputed IT firms like JK Tech was published by Allan Albrecht of IBM in the year 1979 after several years of study and analysis. He learned that software could be sized when it's processed external transactions or its subsystems transactions and databases used are evaluated. As compared to the traditionally used Lines of Code, he found that this method was more practical.

In the year 1984, IBM enhanced the function point definition to provide system characteristics set and individual complexities which can be used for application development and maintenance. IFPUG (International Function Point Users Group) was formed in the year 1986 and was responsible for the standardization of the function point metric.

Definition of Function Points

If the function points are to be defined, they can be defined as a synthetic method, like the temperature or BTUs which allows the calculation of the size of individual applications, software, or subsystems right from the initial requirement stage. The counting is usually done when developers want to size the software or application and estimate the effort and development time that it will require. A number of factors should be considered during the estimation process. Some of the most important ones include-

1. Complexities of the application

2. Performance

3. Code language source

4. Reusable component

5. Skills and experience of the developers

6. Technology and process being used

7. Development environment

When the complexity and risk factors are taken into consideration, the efforts needed in the application development and maintenance phase for certain function points can be accurately estimated.

Counting of the Function Points

When the function points are being identified, the logical user data groups maintained in the software should also be identified. The external inputs can populate, add, change, revise, or update the stored data. The groups of user data are separately processed in the software for permitting data extraction and generate external inquiries and outputs.

The data groups are then classified as ILFs (Internal Logical Files). The counting of ILF is only done once for every software or application. It is very common to extract the data from ILF in some other application. When the maintenance of data is done in another application, when no part of the data that is maintained in the application that is being counted, and when the group of user data is referenced or used for assisting in the processing of external outputs, external inquiries, or external inputs, it is classified as EIF (External Interface Data).

The data that is received from outside of the boundary of application for providing the control functions or maintaining ILF are known as EIs (External Inputs). The counting for data with unique processing needs is done as separate external inputs. The counting of the EIFs and ILFs which are referenced and the fields is done for determining the complexity of every external point.

Data which is generated in the app but exits its boundary is known as EO (External EO) or EQ (External Query). EO and EQ have data which is sent to other applications, information that is printed, user screen displays and some other data. If any of the output data from the application contains calculated or derived information, maintains ILF or provides a control function, it is considered as an external output.

High, low and average EIFs, ILFs, EOs, EQs, and EIs are counted with the help of IFPUG matrices for determining the total of function points which are unadjusted. There are standard weights on the basis of which the values of every category is them determined.

After this, the GSCs (General System Characteristics) are determined and the VAF (Value Adjustment Factor) is calculated. There are 14 GSCs which are then rated between 0 and 5 on the basis of their on the application. The characteristics are-

1. Performance

2. Communication of data

3. Data processing distribution

4. Transaction rate

5. Configurations which are heavily used

6. Online update

7. Efficiency of end-user

8. Online data entry

9. Multiple sites

10. Ease of installation

11. Complex processing

12. Reusability

13. Facilitate

14. Ease of operation

Once the VAF is determined, the total is added to 0.65. The adjusted function point count of the application is determined by multiplying VAF by total unadjusted points.

Future of the Function Points

The effectiveness of the IFPUG is responsible for the well-being and health of the function points. The challenge for the group is in continuing the enhancement of the methodology and increase the awareness about the same among the professionals.

Over the years, many different types of methods that can be used for sizing an application have been introduced. The 3D Function Points by Boeing and Feature Points by Capers Jones’ are two of the most popular. However, none of the methods have gained enough popularity. Several new methods are introduced on a regular basis.

While the function points are not being used by all the professionals involved in application development and maintenance, it is surely useful for everyone who wants to improve the environment of application development by effectively utilizing the functional metrics of software.