3. Using Function Point Analysis

As stated in the introduction, the reason function point analysis exists is to address the issues of estimating and assessing productivity and costs in multi-language, multi-technological, and multi-applications environment. Users of the function point analysis want to achieve any one or more of the following:

• Ignore source code and focus on the application's functionality
  
  
• Apply analysis to any software or application
  
  
• Apply analysis to any computer language
  
  
• Calculate software's cost per function point
  
  
• Determine the number of function points written by programmer per month
  
  
• Measure software engineering firm or department's productivity (The Economist 1993). 

Therefore function point analysis provides a measure of the system's size and complexity in order to determine the effort and cost to develop or maintain it. This section defines and explains what function point analysis is, how it is to be used, and what successes have come from using function point analysis.

Back to Top

3.1 What is Function Point Analysis?

Function point analysis (FPA) is a methodology for measuring software productivity and the cost associated with the development and maintenance. One function point (FP) is one end-user requested business function. The following defines the five characteristics of function points (Grupe 1991):

1. External Inputs: these are end-user actions such as putting in a login or executing a mouse click.
   
   
2. External Outputs: the system provides the end-user output or interface such as a GUI display or items in a report.
   
   
3. Logical Internal Files: these files are the master or transaction files that the system interacts with during its session.
   
   
4. External Interface Files: unlike logical internal files, where the application uses solely for its purpose, these files are or databases are shared with other applications or systems. 
   
   
5. External Inquiries: this function is initiated by the end-user. For example, the end-user wishes to submit a query to a database or requests on-line help. In any case the developer provides a means for the end-user to "search" for answers.

Once these function points have been identified, a complexity rating of the functional value for the end-user is determined. See Table 1 below for the list of 14 function point complexity factors (Grupe 1991).

14 Factors in Function Point Analysis Complexity
1	Will the application use data communications?
2	Are data or functions distributed?
3	Are there specific performance objectives that must be met?
4	Will the application run on a heavily used configuration requiring special design considerations?
5	Will the transaction rate of the application be high?
6	Will there be on-line data entry?
7	Will the application be designed for end-user efficiency?
8	Will there be on-line updates?
9	Is complex processing logic involved?
10	Is there an intent to provide usability for other applications?
11	How important are installation ease and conversion?
12	How important is operational ease?
13	Will the application be accessed from multiple sites?
14	Is there an intent with the design to facilitate change?
Table 1

Next the function points are added and considered unadjusted. The analyst will assign a weighted value from the scale of zero to five on each function point's degree of influence on the development of the project (Grupe 1991). When assigning the degree of influence to a function point, inputs and inquiries are rated lowest on the zero to five scale, while interacting with files or databases receive the highest weights (The Economist 1993). The analyst's time to do an evaluation for a one-person-year project, for example, will take between one to four hours (Grupe 1991).

The material presented thus far in this section discusses the attributes in determining the function point analysis. Actually performing a function point analysis is not included of this paper. However the reader may consider the works cited in this document for details of this activity.

Back to Top

3.2 Using Function Point Values

The power of using function points is for organizations to compare project to project, applications to applications, and organizations to organizations. Function points permit this comparison by separating project size from the effort and then from technology. On the other hand if the need is to estimate development time, programmer productivity, or process improvement - minimizing defects in software, function points allow for the size of the project not to be influenced by technology alone (Smith 1997). The following are rates used in these comparisons:

• Delivery Rate - project function point per work effort (FP/Hours)
  
  
• Support Rate - work effort support per application function point (Hours/FP)
  
  
• Cost Rate - cost per function point ($/FP)
  
  
• Defect Density - defects per application function point (Defect/FP).

During the requirement phase or project scope, the analyst will determine functional requirements of the system from the end-user. Before the project begins the design work for development, the customer (assuming he or she willing and able to pay for the development work) will need to accept or reject the estimates determined from the function point analysis. Communicating to the customer the amount of time and cost that is associated to the project is paramount. Expectations are built and managed from that point forward. Therefore there are two measures derived from the function point analysis, and they are project development time and cost (Smith 1997). Below are four scenarios where the function points rates come into play before any effort is given to an application.

1. Project Viability: When the issue of development time, suppose the software developer's delivery rate is 0.20 FP/Hour. The analyst determined that the project has 1,000 FPs. The time to complete the project is 5,000 hours. The customer can do one of three things:

• reject the project to be completed by the developer,
  
  
• ask for the developer to increase the delivery rate (note that this is unlikely to change because of the intrinsic nature of the methodology the developer works with), or
  
  
• the customer can choose to reduce the number of function points or functionality of the application.

1. Managing Project Change During Development: Give the customer the increased project hours incurred when the customer wishes increase the number of function points during development. So, if the customer wants an additional 100 FPs added to the application, then using 0.20 FP/Hour delivery time as before, the additional time for the project schedule will be 500 hours. Also the customer will want to know the cost increase of the changes. 
   
   
2. Supporting Applications: In this scenario assume that the support delivery time for an existing application is 0.10 (Hours/FP) per month. If there are 100 function points per month to support then the time for supporting this is 10 hours per month.
   
   
3. Defect Density: For purposes of quality improvement, function points can give management insight into how well the application is performing without regard to its environment, technology, or language used. Suppose there are two projects each having 100 defaults, if the first application has 100 FPs and the second has 1,000 FPs, the manager can evaluate that the quality of the first application is no where near the quality of the second application.

After reviewing these scenarios, one other situation can be used with function points. Since the FP values are normalized across applications, projects, support, and quality, a manager can use the FP measurements to evaluate outsourcing software projects or purchasing software off the shelf (Smith 1997).

Back to Top

3.3 Success Stories Using Function Point Analysis

As seen earlier how function points can be used, function point analysis quantifies the system's functions in order to identify the effort needed to develop the application (Marks 1992). According to Clifford Inwood function point analysis estimates have been found to be within ten percent of actual time and costs for modifying existing systems. For new development, Inwood cites that function point analysis estimates are within 15 to 20 percent of actual time and costs (1994). This is a remarkable track record in comparison to the findings in the Standish Group International report where 40 percent were canceled before completion and 63 percent were over-budget.

One main reason for the success of function point analysis is the ability to set function point values in reference to the stage in which the development is taking place. According to one software development company, the average cost to build a function point at the beginning of the software development life cycle (SDLC) in the U.S. is $1,000. This is for the requirement phase and through the design phase. However if the customer wishes to include more function points between the design phase and the testing phase, the cost of each additional function points is $1,200. Once the software testing begins, the value for an additional function point increases to $2,000 (Anthes 1994). As seen here, the function point analysis method fits well into the planning and development stages of software development.

The following two business case studies, Cincinnati Bell Information Systems and Certified Grocers of Commerce, California, illustrate the advantages to using function point analysis. Errol Shim a quality manager at Cincinnati Bell Information Systems completed a scope on the telephone billing system in one week - without using function point analysis the time was estimated to take three months! Shim celebrated the fact that function point analysis produced an estimate within 85 to 90 percent of the actually time and cost of the projects he managed at Cincinnati Bell Information Systems (Anthes 1994). Certified Grocers of Commerce, California had a project estimated for them using the function point analysis methodology. The estimate revealed to have the project take 1,280 hours to complete. After the requirements stage the project grew, like most projects once they are started, to 1,460 hours of development. The function point analysis was within 10 percent of the actually development time (Rakos 1993).

Not every project will fit nicely into using function point analysis as the ones just mentioned. The next two sections, starting with function point analysis assumptions then alternatives to function point analysis, describe for the reader caveats and other options to function point analysis.