What is Function Point Analysis? five components fps

What is Function Point Analysis? five components fps

Function Point Methodology

   In late 1970, IBM felt the need to develop a language-independent approach to estimate software development effort. It assigned one of its employees, Allan Albrecht, with developing this approach in 1979. The result was the FP technique. FPs are a measure of the size of computer applications that are being built. The size is measured from a functional, or user, point of view. It is independent of the computer language, development methodology, technology, or capability of the project team used to develop the application.

    Functional size estimation uses the number of functionalities to be made available in the application and is a top-down technique used for estimating sublunary-level activity first and then breaking it into lower-level activities. After collecting requirements from the customer, the project team would count the number of FPs by using different methodologies available. When using FPS (Albrecht, 1979; IFPUG, 1999) or cosmic functional size units (CFSU) (Abran, Symons, and Oligny, 2001), the estimator needs to understand the required functionalities, and then use either of the above-mentioned methodologies to count FPs. But all these methodologies would give accurate results for large size new application development. 

     In order to make a reliable estimate for a (new) development project, the size should be over 200 FP or 100 CFSU. Most of the upgrade projects are smaller-sized applications and hence cannot use these methodologies. Capers Jones (1986) published a method based closely on that of Albrecht, called "feature points." This method aims to extend functional size methodology to scientific algorithms. 

      Charles Symons (1988) modified Albrecht's (1979) FP and developed the "MkII function point method” that aimed to take care of the complexity of the business application software, which is "data-rich." However, it was difficult to measure and classify complexity related to data requirements in business application software, and hence this method could not be used for upgrade projects in commercial software development.

  

     Using Albrecht's (1979) approach, Whitmire (1992) developed "3D function points" for estimating the size of scientific and real-time software. The three dimensions in 3D FPs are data, function, and control. The data dimension is similar to Albrecht's FPs. The function dimension adds transformations, which are similar to the algorithms, and the control dimension adds transitions, which explains changes in the application state. This approach was a proprietary of Boeing and not widely used because it is not easy to use for counting FPs and, compared with feature points, it does not help in counting FPs for algorithms in scientific software. NESMA (1997) developed its own variant for counting FPs. 

        The variations from the IFPUG method of counting FP were related to "further data processing" and data display, which is also known as “implicit inquiry.” This approach also does not take care of complexities involved in the algorithm and mostly used for development projects. For a smaller size of the applications, this method is not suitable. The University of Québec, Montréal, and others published the "full function point method" in 1997 that used the IFPUG rules for business application software and added extra components for sizing real-time software; however, this has not been accepted by practitioners for commercial software projects because this method can be accurate for large-sized application development only.

 

What is Function Point Analysis?

 Function point analysis (FPA) has been proven as a reliable method for measuring the size of computer software. In addition to measuring output, FPA is extremely useful in estimating projects, managing change of scope, measuring productivity, and communicating functional requirements.

One of the initial design criteria for FPs was to provide a mechanism that both software developers and users could utilize to define functional requirements. It was determined that the best way to gain

an understanding of the users' needs was to approach their problem from the perspective of how they view the results that an automated system produces. Therefore, one of the primary goals of FPA is to evaluate a system's capabilities from a user's point of view. In order to achieve this goal, the analysis is based on the different ways users interact with computerized systems. From a user's perspective, a system assists them in doing their job by providing five basic functions. Two of these address the data requirements of an end-user and are referred to as data functions. The remaining three address the user's need to access data and are referred to as transactional functions.

The five components of fps are as follows:

Data functions:

1. Internal logical files

2. External interface files Transactional functions

3. External inputs

4. External outputs

5. External inquiries

1.Internal logical files (ILFs)-

    The first data function allows users to utilize data they are responsible for maintaining. For example, a pilot may enter navigational data through a display in the cockpit prior to departure. The data is stored in a file for use and can be modified during the mission. Therefore, the pilot is responsible for maintaining the file that contains the navigational information. Logical groupings of data in a system, maintained by an end-user, are referred to as ILFs.

2.Externa interface files (ELES)-

   The second-data function a system-provides to an end-user is also related to logical groupings of data. In this case, the user is not responsible for maintaining the data. The data resides in another system and is maintained by another user or system. The user of the system being counted requires this data for reference purposes only. For example, it may be necessary for a pilot to reference position data from a satellite or ground-based facility during flight. The pilot does not have the responsibility for updating data at these sites but must reference it during the flight. Groupings of data from another system that are used only for reference purposes are defined as EIFs.

      The remaining functions address the user's capability to access the data contained in ILFs and EIFs. This capability includes maintaining, inquiring, and outputting of data. These are referred to as transactional functions.

3.External inputs (ET)-

   The first transactional function allows a user to maintain ILFs through the ability to add, change, and delete the data. For example, a pilot can add, change, and delete navigational information prior to and during the mission. In this case, the pilot is utilizing a transaction referred to as an external input (EI). An El gives the user the capability to maintain the data in ILFs through adding, changing, and deleting its contents.

4.External outputs (E0)-

The next transactional function gives the user the ability to produce outputs. For example, a pilot has the ability to separately display ground speed, true airspeed, and calibrated airspeed. The results displayed are derived using data that are maintained and data that are referenced. In FP terminology the resulting display is called an external output (EO).

5.External inquiries (EQ)-

The final capability provided to users through a computerized system addresses the requirement to select and display specific data from files. In order to accomplish this. a user inputs selection information that is used to retrieve data that meets the specific enteria. In this

the situation, there is no manipulation of the data. It is a direct retrieval of information contained in the files. For example, if a pilot displays terrain clearance data that was previously set, the resulting output is the direct retrieval of stored information. These transactions are referred to as external inquiries

In addition to the five functional components described above there are two adjustment factors that need to be considered in FPA.

Functional complexity.

The first adjustment factor considers the functional complexity for each unique function. Functional complexity is determined based on the combination of data groupings and data elements of a particular function. The number of data elements and unique groupings are counted and compared with a complexity matrix that will rate the function as low, average, or high complexity. Each of the five functional components (ILF, EIF, EI, EO, and EO) has its own unique complexity matrix. Table 2.5 shows the complexity matrix for EOS.