1. Introduction

In 1993 a typical word-processing software application would contain approximately 500,000 lines of code. A new PC spreadsheet software application would take two years and 20 programmers to develop. Further the transformation of Microsoft's Windows operating system to Microsoft's Windows NT operating system required one million lines of new code (The Economist 1993). In conjunction with the development aspects of software applications, U.S. Companies in 1993 spent $10 billion dollars for PC software applications and $20 billion dollars for customized software applications. The issue is the following: how does a software development company know what they are producing meets user requirements, schedules, and budget; while at the same time, customers realize the value of their expenditures for such software? Chances are most consumers of software applications do not get the requirements they need for the value they want and the time they need them. Hence the purpose of this paper is to inform the reader on how function point analysis enables developers to estimate cost and schedules based on user requirements for software development projects. From the estimates, customers can evaluate what functionality they need at what cost they are willing to pay. The result from this activity is for software development companies or internal information system departments to utilize their resources in a cost effective and timely manner; while allowing for software application customers to realize the value they are receiving.

1.1 A Brief History on Function Point Analysis

In the late 1970's Allan J. Albrecht of IBM addressed the issues of estimating and assessing productivity and costs in a multi- language and technological software development environment. Albrecht introduced function point analysis methodology to evaluate software development from the point-of-view of functional points or business requirements of the application. By 1986 a core group of function point analysis users established the International Function Point User's Group (IFPUG). The group is based in the U.S. and has over 600 corporate members from 30 countries. As of 1997 there were over 1,200 members worldwide. The purpose of IFPUG is to produce and maintain the Function Point Practices Counting Manual (release 4.0) for standardizing function point analysis (Smith 1997).

1.2 The Organization of the Paper

In section two, software development obstacles are described to build on the idea for the need of good estimating tools. Section three discusses how managers can use function point analysis. Section four provides the reader with the measurement assumptions and function point analysis caveats. This leads into section five, which offers alternatives to function point analysis. Finally section six will summarize the discussion of this paper.

2. Software Project Estimating Obstacles

System analysts and project managers have always been challenged with determining a well-defined project scope. This difficulty in determining user or system requirements has led to cancellation, cost overruns, or protracted delivery dates for software projects, applications, and maintenance (Smith 2000). In this section the focus will be on what are the obstacles to successfully determining user requirements.

 According to a study done by the Standish Group International, their 1995 Chaos Report on information technology (IT) project failures indicated that 40 percent of all application development projects were canceled before completion. Further U.S. companies lost $145 billion annually due to project failures or overruns (Gordon 1999). Notwithstanding these statistics, a more recent study on 100 companies concluded that 37 percent of major IT projects were completed as scheduled. However only 42 percent of all projects were completed on budget (Gordon 1999). These findings illustrate that there is an opportunity for IT managers to accurately determine what the application should do and what resources to make it happen.

2.1 Management Obstacles

There is a cliché: you can't manage what you can't measure. The IT manager must be able to foresee the potential size and cost of a project for he or she to have success in managing it. Grupe and Clevenger cite seven critical objectives for managers to plan successful projects, these are 1) ascertain programmers' productivity, 2) reduce costs, 3) increase throughput, 4) create run-time efficiency, 5) timeliness of delivery, 6) increased service to end-users, and 7) operational efficiency of staff. Of these seven managerial objectives, understanding programmers' productivity and timeliness of software delivery are the most difficult to manage and estimate (Grupe 1991). Managers have measured programmers' productivity by determining the number of source line code that has been entered. The inherent problem with this method is the inability to compare applications using different programming languages. An anecdote to this method was the time a mid-size company determined the productivity of its programmers by measuring the number of times the programmer hit the return key. Naturally the programmers quickly figured this out and were much too obliging to hit the return key. The second managerial problem is to accurately schedule the software deliverable times. In order to create budgets and plan for expenses, senior management required IT managers to accurately estimate the cost and completion of projects. For end-users, their productivity often hinged on how well the systems were functioning. And the most important user of the business, the customer, has expectations built upon competitive market forces on how well the systems deliver the product or service to them (Grupe 1991). This is a tall order of responsibility on the shoulders of the IT manager. Furthermore this demonstrates the importance of discerning the programmers' productivity and required resources to keep development or maintenance costs to a minimum and deliver applications in a timely manner.

2.2 Scope Creep

Coupled with the problem of discerning productivity and scheduling is the process of understanding the user requirements. Even though the manager knows the productivity of the resources involved and how to allocate them, unknowingly the requirements gathering fails and so does estimating costs and scheduling deliverables for the software application. As the project moves through the software development life cycle, requirement changes become increasingly more expensive and deliverable times become more protracted. Thus this leads to project failure or cost overruns. In essence this is the tragedy of "scope creep."

Gary Anthes argues seven facets of scope creep:

      1. Increasing user requirements causes budget and scheduling overruns;

      2. User makes significant changes to the system after the requirements have been established;

      3. Programmers are in the midst of developing the application;

      4. The user does not know what they want;

      5. The user does not know how to communicate what they need;

      6. Only after the demonstration of a prototype or staged development do users realize what they need; and

      7. Users do not want the system and use scope creep to perpetually stall the completion of the application (1994).

Studies on scope creep have revealed that 44 percent of projects have poor initial requirements definitions. An additional 22 percent in the research has revealed management failing to properly maintain expectations of senior management and end-users. These statistics help support the communication problem between end-users and system analysts or project managers, who gather project requirements. Consequently this undermines the manager's budgeting and scheduling, in conjunction with diminished productivity of the software development or maintenance group (Anthes 1994).

2.3 Early Estimate Syndrome

So far the discussion on consequences of poor project planning has hurt businesses' competitiveness in the U.S., organizations profitability, and the IT development staff's reliability. The inability to accurately gather requirements and communicate cost and deliverable times to end-users can have a profound affect on the project manager's job. The following describes a highly common scenario in the business world.

For over ten years, Jill Thomas has been a very successful programmer and project manager for Smith Enterprises, Inc. Recently she was asked by senior management to develop cost and scheduling estimates for a new licensing fees billing system. According to the request, Jill had developed a similar system months earlier and began on putting together the estimates. After review from senior management, the estimates were quickly approved and Jill began developing the new billing system. After several months into the project (the project was estimated to take five months), senior management wanted to see a demonstration of what she had completed thus far. Jill, who always was on ready for such requests, demonstrated the application to the senior management. Several of the senior managers were surprised that Jill was failing to produce the new billing system that would handle accounts receivable, cash outlays, the general ledger, etc. for Smith Enterprise, Inc. Much to Jill's astonishment and disappointment in the directives that she received by senior management, she embarked on developing a new corporate accounting system.

The resulting affect from this "miscommunication" was the following: 1) the new accounting system was months behind schedule; 2) the system was three times over budget; and 3) Jill suffers with the damage to her reputation. William Marks refers to a scenario like this as "qualification amnesia" (1992). This is the tendency of the users to only remember the estimate but forget or fail to disclose the qualifications or definition of the system. Nevertheless there are ways to avoid such miscommunication and demonstrate the need for function point analysis.

2.4 Communication and Measurement

In Jill's situation, too much was assumed from the standpoint of the project analyst and the senior management. However there are methods to minimize the communication errors. In addition function points are introduced here to present a quantitative measure to provide feedback on the project's scope for the end-user. There are six ways listed below to assist the system analyst or project manager to control expectations.

      1. Let end-users design the application they need with the help of IS staff

      2. IS personnel to learn to say "no" at times, when end-users request a change to the system during the development stage

      3. Use function points in contract to indicate the cost to change requirements - the next section will detail function point analysis

      4. Establish joint application development (JAD) sessions to determine requirements for the project

      5. Present prototypes to the users to help clear misconceptions and narrow the definition of the system

      6. Project managers need to explain well to end-users the impact to cost and scheduling when changes are requested prior to and during the development phase (Anthes 1994).

In order to discern the costs involved with a project, a metric needs to be used to determine the resources and time to complete the development of the application. Before using any metric to quantify the budget and schedule for developing or maintaining a software project, the project manager should meet following criteria: 1) if the metric's methods are not accepted by upper management, then support for the project my not be easy; 2) if programmers or managers have no goal with the metrics, then the metrics provide no value; and 3) the project manager should market the success of the project to upper management and end-users, stemming from the decisions based on the metrics used (Ray 1993). When the manager provides feedback on the success of the project, then upper management, programmers, and end-users find value in the metrics and confidence in the manager's decisions.

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

        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.

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.

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

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.

4. Things to Consider When Using Function Point Analysis

Accurately measuring software project's cost and development time is essential for a business, which internalizes its IS project development, and for software development companies, which develop business applications. If projects are not sized well in the requirements gathering phase of the software development life cycle, businesses will lose out to those who do it more efficiently. Therefore the following paragraphs describe why it is important to have good measurement systems in place, e.g., function point analysis, and what additional assumptions and caveats are worth mentioning for function point analysis.

4.1 Importance of Good Measurement Systems

According to one study, proper measurement of software development projects should cost five to eight percent of the total project's budget (Rubin 1994). This is to help ensure the project is estimated properly and allocate necessary resources for its development. There is no perfect metric; however software developers must accept and follow the measurement tool that is used. Measurement tools must evolve over time. Whether experience or better techniques are used, the measurement tool must incorporate the latest advances in measurement. Given these key points regarding the importance of measurement tools, if software developers are faithful at following these rules, it will help them maintain a competitive advantage (Rubin 1994).

4.2 Function Point Analysis Caveats

Function point analysis is one-of-many software application estimating tools for measuring cost and development time of software projects. As seen in the next section, alternative estimating tools are discussed; however before considering them, the following lists additional assumptions and caveats when using function point analysis:

 In light of these assumptions and caveats, the next sections implores the use of alternatives to function point analysis.

5. Alternatives to Function Point Analysis

In the article, "Using Function Point Analysis Can Give You Sharp Estimates," John Rakos declares, "… theoretically [the] most accurate method is function point analysis." He discusses three estimating methods commonly used by software developers: expert guess, historical guess, and function point analysis (1993). Often a programmer or analyst will estimate by a "rule of thumb" to determine the magnitude and cost of a software development project that is based on developing similar applications. Generally this is fine, however there must be similar technologies, programmers, and programming languages. The historical guess is a little more difficult for determining what and how much to estimate from documented projects. The expert guess criteria still hold, however the unknown is the lack of experience and interpretation made by the analyst using the documentation to help them with the estimation of a new application. The third method, praised by Rakos, is the function point analysis method for estimating. The analyst can compare past projects with current ones. In addition by factoring in programmer productivity, the analyst is much more certain, without the expert and historical guess restrictions, to estimate accurately (Rakos 1993).

5.1 Lines of Code Based Estimation Methods

Not everyone is a fan favorite of function point analysis. Carnegie Mellon Software Engineering Institute (Carnegie) argues in the Web article, "Software Technology Review," that lines of code (LOC) method is still viable. However Carnegie offers the two LOC based methods, COCOMO (construction cost models) and REVIC (revised COCOMO version), to be reliable alternatives to function point analysis (Carnegie 2000).

5.2 History-Based, Pseudo-Function Point Analysis Estimation Method

Christine Comaford writes in PC Week a less technical version of function point analysis that most software engineers could use without knowing function point analysis (1993). Comaford argues for using historical metrics from projects. There are three steps in determining the estimate for a project. The first step is to determine the amount of time it takes to complete simple, intermediate, and complex tasks for a given function. Second is to rate each function, similar to the zero to five scale when determining function points, GUI screens, reports, tables, queries, etc. The third step is to create a productivity quotient based on novice, intermediate, and advanced programmer skill sets (Comaford 1993). Once these are known, apply this knowledge similarly as the function point analysis method. Using prior experiences and current abilities in evaluation of functions, the analyst can determine the time and cost of future software development projects.

These approaches are to get a handle of the time and cost it takes to develop or maintain applications. Each method represents its own strengths and may be more appropriate to estimate a particular project than another; however, function point embodies fewer restrictions than the alternatives listed above because of its focus - the customer. Function points are customer or requirements based and the customer decides what he or she is willing to purchase in the way of software solutions.

6. Summary

The purpose of this paper is to explain how function point analysis enables software developers to estimate costs and delivery schedules based on end-user requirements for software applications. Due to the failure rates and over-budget and protracted delivery dates for software applications, managers are using methods of estimating, e.g., function point analysis, to prevent these problems from occurring. In section two, software project estimating obstacles, illustrated the problems with software development. The inability to estimate projects well has been costly in terms of budget over-runs and late delivery dates. Further managers have had a difficult time managing resources to produce applications. The biggest culprit to poor estimating has been scope creep. This is a by-product of poor communication and under-developed expectations.

 The using function point analysis section discussed how managers could use function point analysis to make decisions. FPA provides the manager with a metric to estimate and share with the customer how much the project will cost, and how long it will take to implement. A critical aspect of function points is how they are determined. FPs are based on the business requirements, not on programmer's ability to code, technology that is used, nor software language is used to develop the application.

 Sections four and five discuss measurement considerations and additional function point analysis assumptions, and alternatives to function point analysis as an estimating tool, respectively. All measurement systems must evolve over time and incorporate the latest knowledge. Managers must incorporate the best measurement system for software development or maintenance in order to keep up with competition or gain a competitive advantage in the marketplace.

Finally in a world of increasing competition, software developers must estimate as well as, if not better than, the competition in order to be competitive. One highly touted estimating methodology, function point analysis, gives IS managers a means to determine resources early in the software development life cycle. William Marks writes in Software Magazine, "Function point analysis is an objective methodology that produces consistent results (1992)." When technology and software languages are continually changing, the IS manager wants to have the best estimating method at his or her disposal: function point analysis is that method.

Bibliography

Anthes, Gary H. "No More Creeps!" Computerworld. 28(May 2, 1994): n18, p107(3).

Benyahia, Hadj. "Costs and Productivity Estimation in Computer Engineering Economics,"
    Engineering Economist. 41(Spring 1996): 229-242.

Bock, Douglas B., Klepper, Robert. "FP-S: A Simplified Function Point Count Method,"
    The Journal of Systems and Software. 18(July 1992): n3, p245(10).

Carnegie Mellon Software Engineering Institute. "Software Technology Review," September 22,
    2000: http://www.sei.cmu.edu/activities/str/descriptions/fpa_body.html.

Comaford, Christine. "Up-to-date Resource Estimation is a Must," PC Week.
    10(November 8, 1993): n44, p82(1).

Dudman, Jane. "Measure of Success," Computer Weekly. May 13, 1993: 40.

Fetcke, Thomas. "A Generalized Structure for Function Point Analysis," International Workshop
    on Software Management (IWSM 1999). September 8-10, 1999, in Mont-Tremblant, Canada:
    http://user.ex.tu-berlin.de/~fetcke/papers/Fetcke1999.pdf.

Garmus, David. "Function Point Counting In a Real-Time Environment," Principal, The David
    Consulting Group. http://www.davidconsultinggroup.com/articles/pbcrstlk.htm.

Gordon, Philip. "To Err Is Human, To Estimate, Divine," Informationweek. January 18, 1999: 65-72.

Grupe, Fritz H.; Clevenger, Dorothy F. "Using Function Point Analysis as a Software
    Development Tool," Journal of Systems Management. December 1991: 23-26.

Heller, Roger. "Introduction to Function Point Analysis," QIP Management Group Inc. 2000Ó .
    October 24, 2000: http://www.qpmg.com/fp-intro.htm.

Hitt, Lorin M; Brynjolfsson, Erik. "Productivity, Business Profitability, and Consumer Surplus:
    Three Different Measures of Information Technology Value," MIS Quarterly. 20(June 1996): i2, p121.

Hu, Qing; Plant, Robert T.; Hertz, David B. "Software Cost Estimation Using Economic Production
    Models," Journal of Management Information Systems. 15(Summer 1998): n1, p143(21).

International Function Point Users Group. "About Function Point Analysis," July 18, 2000:
    http://www.ifpug.org/home/docs/abfpa.html.

Inwood, Clifford. "Function Point Remains Metric of Choice," Computing Canada.
    20(September 14, 1994): n19, p20(1).

Longstreet, David. "Fundamentals of Function Point Analysis," Longstreet Consulting Inc. 2000Ó.
    http://www.softwaremetrics.com/fpafund.htm.

Marks, William W. "Escape Estimate Grip," Software Magazine. 12(September 1992): n12, p6(2).

Mukhopadhyay, Tridas; Vicinanza, Steven; Prietula, Michael. "Examining the Feasibility of a
    Case-Based Reasoning Model for Software Effort Estimation," MIS Quarterly. June 1992: p155(17).

Rakos, John. "Using Function Point Analysis Can Give You Sharp Estimates," Computing Canada.
    19(February 15, 1993): n4, p29(1).

Ray, Garry. "Measurement Programs Need Vision," Computerworld. 27(May 3, 1993): 99.

Rubin, Howard. "Dispensing the Measurement Myths," Computerworld. August 15, 1994:
    http://www.computerworld.com/cwi/Printer_…10,1212,NA47_ST05519-,00.htm.

Smith, Linda. "Function Point Analysis and Its Uses," Predicate Logic, Inc. 1997. October 24, 2000:
    http://www.predicate.com/up_fp.html.

Strehlo, Kevin. "EstiMate Project Duration with Function Point Analysis," InfoWorld.
    15(March 8, 1993): n10, p100(1).

The Economist. "Made to Measure: Software Engineering," 326(January 23, 1993): n7795, p79(1).

Watson, Paul. "Planning for Software Project Success," Communications of the ACM.
    43(March 2000): n3, p11(2).

Zhang, Xuemei; Pham, Hoang. "A Software Cost Model With Warranty Cost, Error Removal and Risk Costs,"
    IIE Transactions. 30(December 1998): i12, p1135(8).

Back to Top

Rick Southard
November 13, 2000
MSIS 488 - System Analysis