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:
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.
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):
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.
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:
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.
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).
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.