Introduction to IFPUG Function Point Analysis Tutorial

2.2 Introduction to IFPUG Function Point Analysis

Hello and welcome to software estimation course offered by Simplilearn. In the previous module, we covered the basics of software sizing and effort estimation. In this module, we will be introduced to one of the widely used estimation technique – International Function Point User Group (IFPUG) (pronounce as if-pug) Function Point Analysis. Let us look into the agenda of this module in the next slide.

2.3 Agenda

This module is an introduction to IFPUG (pronounce as if-pug) Function Point Analysis (FPA). We will first find out what sizing technique was used before the advent of FPA. We will then cover how FPA was established, its growth and where it stands today. We will then understand the components that make up function point analysis followed by the types of function point counts. We will end this module with a brief introduction on the FPA counting steps. In the next slide, we will look into the era before function point.

2.4 The Era Before Function Point

Before function point analysis, or for that matter any other sizing technique was devised, the most common unit of Software size was Lines of Code (LOC). The screenshot in the slide highlights the LOC. Software LOC is software metric, used to measure the size of a software application, by counting the physical number of lines of code in the software program. Experiments have confirmed that effort is highly correlated with Software Lines of Code, that is, software programs with larger LOC value takes more time to develop. Thus, LOC would be an ideal measure to estimate the effort required for software development. We will continue our discussion on the era before function point in the next slide.

2.5 The Era Before Function Point(contd.)

There were, and still are, several problems with using LoC as a unit of measurement of software size. LOC is highly dependent on the programmer. Research has shown that a highly skilled programmer can write fewer line of code, to develop the same functionality that a less skilled programmer would write. The programming language being used itself is a deterrent to LOC as a unit of measurement. Modern and visual programming languages like Visual Basic, JAVA, etc., require fewer lines of code than compared to assembly languages like COBOL (pronounce as one word), C, etc. Another major drawback of using LOC as measure is that the actual number of LOC is not known until the project is completed. Therefore, LOC cannot be used to estimate the effort and schedule – though some logic can be built based on data collected from the past. Finally, the major drawback is that there is no standard method to count lines of code. With the syntax for each programming language, it was close to impossible to have a standard method of counting the lines of code. Because of these issues with LOC, there was a need to devise a more structured and effective sizing technique. In the next slide we will look into the history and introduction of FPA.

2.6 FPA History and Introduction

The idea of measuring a size of software in terms of its ‘functionality’ as opposed to its physical components, was first put forward by Allan J Albrecht of IBM in 1979, in his paper titled “Measuring Application Development Productivity”. This fundamentally changed the concept of software sizing. Albrecht’s clever piece of lateral thinking laid the foundations for the subject of ‘Functional Size Measurement (FSM)’. Functional size measurement deals with measuring the amount of functionality that the software application provides to the user. Function point analysis is a method to break software application into smaller components, so that they can be better understood and analyzed. Function point is a unit of measure of size of a software application. Function point measures software, by quantifying its functionality provided to the user, based primarily on the logical design. The definition of this method is now managed by the International Function Point Users Group (IFPUG). The International Function Point User Group is a non-profit organization originally set up in 1986. This is a group of practitioners who are responsible for maintaining the Counting Practices Manual (CPM). The CPM is a body of knowledge used by function point analysts to measure the functional size of applications. The CPM contains a set of rules to break down a software application and count the Function Points contained within the application. The current version of the CPM is Version 4.3 which was released in October 2009. Now that we have understood that function point analysis deals with breaking down the application for better analysis, in the next slide, we will be looking at the components of function point analysis.

2.7 Components of Function Point Analysis

Before we get into demystifying the components of Function Point Analysis, let us look at the components of a typical software application. Consider the example of google.com as given in the slide. As an application, it has some internal storage to store information about the user, previous searches, location of the user, etc. It then refers to some external applications to retrieve the information, process it, and display to the user, which in this example, maybe wikipedia.org. It then has some means of collecting input from the user. This can be in terms of entering the search string, or selecting various products of Google, etc. Finally, there is some output to the user based on the user input. The output can be a static display of information without any processing logic, or it can be outputs based on complex algorithms and calculations. In addition to these functionalities, there are few inherent characteristics of the application like the user interface, the complexity of the application, etc., which describe the nature of the application. Let us continue our discussion on the components of FPA in the next slide.

2.8 Components of Function Point Analysis(contd.)

To summarize, we have seen that google.com has some internal storage, external storage, inputs, outputs – either static or processed (also known as calculated), and overall system attributes. These components are present in any software application that can be imagined. These components make up function point analysis. The internal storage of the application is called “Internal Logic Files (ILF)”, the external storage is called “External Interface Files (EIF)”, the user input is called “External Input (EI)”, the static output is called “External Query (EQ)”, the calculated output is called “External Output (EO),” and the overall system attributes are called “General System Characteristics (GSC)”. Function point analysis deals with breaking down the application into these components and counting the function points contributed by each of them. These components and the counting rules will be dealt with in detail in later modules. Let us look at the various types of function points in the following slide.

2.9 Types of Function Point Counts

Function point counts can be associated with either projects or application, that is, function points can be counted for an entire application after its development, or at various stage of application development in a project. There are three types of software projects – development projects, enhancement projects and maintenance projects. In accordance to these types of projects, there three types of function point counts – development function point count, enhancement function point count, and application function point count. Let us look into the development function point count in the next slide.

2.10 Types of Function Point Counts(contd.)

Development function points can be counted at all phases of project life cycle – from requirements to implementation. It is usually associated with new development projects. The scope creep can be measured more effectively by counting the function points at each stage of the project. This type of function is also called as baseline function point count, because this count acts as a baseline size of the application being built. Usually, the function point count is baselined after the end of the requirements phase. Moving on, we will understand enhancement function point count in the next slide.

2.11 Types of Function Point Counts (contd.)

Since it is common to enhance the functionality of software, the enhancement function point count aims at sizing the enhancement projects. This type of function point count helps to size the function points added, modified, or deleted due to the enhancement project. Since most software applications evolve over time, this type of count helps to understand how much the application has evolved. Let us continue our discussion with the third type of function point counts in the following slide.

2.12 Types of Function Point Counts(contd.)

Application counts are done on existing production applications. Application counts can assist organizations in understanding the size of the entire corporate portfolio/suite of applications. This type of count is similar to taking an inventory of a store. While development function point count was the baseline FP count, application function point can also be called as implemented function point count, as this type of function point, counts the actual functionality existing in the entire application. We will be looking into these types of function point in detail in the future modules. For all practical purposes, the basic process of counting the function points is the same, irrespective of the type of count. In the next slide, we will cover the FPA counting steps.

2.13 FPA Counting Steps

The components of Function Point Analysis are - Internal Logic Files (ILF), External Interface Files (EIF), External Inputs (EI), External Queries (EQ), External Outputs (EO), and General System Characteristics (GSC). Function point analysis basically involves breaking down of the entire application into these components and counting the function points contributed by each of these components. As seen in the slide, the first step is to identify the counting scope. The purpose of the count determines the counting scope. This step basically involves determining the type of function point count – development, enhancement, or application. The second step is to define the application boundary. Since it is common for computer systems to interact with other computer systems and/or human beings, a boundary must be drawn around each system, to be measured prior to classifying components. It is very important to draw the application boundary from the user’s point of view and not the technical implementation’s point of view. Basically boundary indicates the border between the project or application being counted, and the external applications or users. The third step is to identify and rate the data functions. The data functions include Internal Logic Files (ILF) and External Interface Files (EIF). Data functionality satisfies the functional user requirements to store and/or reference data. The fourth step is to identify and rate the transaction functions. The transaction functions include External Inputs (EIs), External Queries (EQs), and External Outputs (EOs). Transaction functionality satisfies the functional user requirements that process data. Transaction functions are composed of multiple elementary processes. An elementary process is the smallest unit of activity that is meaningful to the user. After identifying and rating the data functions and transaction functions, the resulting measure is called Unadjusted Function Point (UFP). This count specifies the size of the application, based on the functionality provided from the user perspective. The system attributes are not factored in this measure. The final step in this the process is to rate the General System Characteristics (GSCs). There are fourteen general system characteristics in IFPUG function point analysis that have to be analyzed and rated on a scale of zero to five, based on the level of influence each factor has on the application. Based on the rating for the fourteen GSCs, the Adjusted Function Point (AFP) is derived. Each of the above steps will be dealt in detail in the future modules. Let us summarize this module in the next slide.

2.14 Summary

In this module we found out that Lines of Code (LOC) was the preferred unit of measure though it posed various drawbacks. Then we saw that Allan J Albrecht of IBM introduced function point analysis in one of his papers in 1979. The components of function point analysis include –Internal Logic Files (ILF), External Interface Files (EIF), External Inputs (EI), External Queries (EQ), External Outputs (EO), and General System Characteristics (GSC). We learned that the types of function point counts are – development function point count, enhancement function point count, and application function point count. Finally, we concluded with understanding the five steps involved in the function point analysis. In the next module we will cover in detail the counting scope, application boundary, and the identification rules for data functions and transaction functions.

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

We use cookies on this site for functional and analytical purposes. By using the site, you agree to be cookied and to our Terms of Use. Find out more

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)

By proceeding, you agree to our Terms of Use and Privacy Policy

We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*

By proceeding, you agree to our Terms of Use and Privacy Policy