Function Points FAQ's

What are function points and why count them?

In the late seventies, IBM felt the need to develop a language independent approach to estimating software development effort. It tasked one of its employees, Allan Albrecht, with developing this approach. The result was the function point technique.

In the early eighties, the function point technique was refined and a counting manual was produced by IBM's GUIDE organization. The International Function Point Users Group (IFPUG) was founded in the late eighties. This organization produced its own Counting Practices Manual. In 1994, IFPUG produced Release 4.0 of its Counting Practices Manual. While the GUIDE publication and each release of the IFPUG publications contained refinements to the technique originally presented by Albrecht, they always claimed to be consistent with his original thinking. In truth, it is still very close considering the nearly two decades that have elapsed since Albrecht's original publication!

During the eighties and nineties, several people have suggested function point counting techniques intended to substantially extend or completely replace the work done by Albrecht. Some of these will be briefly discussed in this FAQ. However, unless otherwise specified, information in this FAQ is intended to be consistent with IFPUG Release 4.0.

Function points are a measure of the size of computer applications and the projects that build them. 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. The fact that Albrecht originally used it to predict effort is simply a consequence of the fact that size is usually the primary driver of development effort. The function points measured size.

It is important to stress what function points do NOT measure. Function points are not a perfect measure of effort to develop an application or of its business value, although the size in function points is typically an important factor in measuring each. This is often illustrated with an analogy to the building trades. A three thousand square foot house is usually less expensive to build one that is six thousand square feet. However, many attributes like marble bathrooms and tile floors might actually make the smaller house more expensive. Other factors, like location and number of bedrooms, might also make the smaller house more valuable as a residence.

Bill Hufschmidt, a seasoned function point practitioner, always stresses that the first three letters in function points are FUN. People who enjoy function point counting and can justify it on that basis should do so. The following are more hard nosed reasons:

• Measure productivity -- Many executives have come to the conclusion that regardless of their core business, they are also in the software business. Calculating several variations on the function points produced per month theme tells them how well they are doing in this regard.
• Estimate development and support -- Since the beginning, function points have been used as an estimating technique. Estimating is obviously necessary for the cost benefit analysis that justifies application development. Even for strategic projects that need no quantitative justification, accurate estimation is required for proper staffing.
• Monitor outsourcing agreements -- Companies outsourcing significant parts of their IS requirements are concerned that the outsourcing entity deliver the level of support and productivity gains that they promise. Outsourcers, like CSC and IBM Global Services, frequently use function points to demonstrate compliance in these areas.
• Drive IS related business decisions -- Companies must analyze their portfolios of applications and projects. The size in function points is an attribute that needs to be tracked for each application and project. Along with other data, this will allow decisions regarding the retaining, retiring and redesign of applications to be made.
• Normalize other measures -- To put them in perspective, other measures frequently require the size in function points. For example, 100 delivered defects on a 100 function point system is not good news. The same 100 delivered defects on a 10,000 function point system are much easier to take.

There are a number of frequently asked questions that are related to the more general question of "What are function points?" These questions and answers follow:

Can function points be used for GUI based systems?

Yes. When the function point technique was originally developed, it was not applied to systems with Graphical User Interfaces (GUIs). There were no systems with GUIs! Even as late as three years ago, there was a certain amount of disagreement between function point practitioners regarding how to count these systems.

Two years ago, IFPUG completed Release 4.0 of their Function Point Counting Practices Manual. It contains the official rules for, and extensive examples of, counting GUI based systems. Subsequently, IFPUG produced a case study that contained the count of an entire GUI-based system.

Unfortunately, you can still find practitioners who are not familiar with the new rules and have not updated their course material to reflect current technology. Do not tolerate this! Just like any other professional you rely on, your function point specialist(s) should have knowledge that is up to date.

Can function points be used for client/server systems?

Yes. In the simplest case, the user may be unaware of whether she is using a program running on a central computer or a set of programs running on various computers across a network. In fact, in the wonderful world of client/server, your application can abend (reach an abnormal end) because of a failure on a computer that you did not even know existed! This presents a strong argument that client-server systems can be counted just like any other ones. Unfortunately, client/server does introduce some complications into the counting process.

Accounting for the development of a technical infrastructure is often a challenge. The technical infrastructure can be composed of database managers, middleware, APIs and other components that are used by the developers. Installing this infrastructure is often a completely separate project. Are there function points associated with this project? If so, is the count performed as if the application developers are the users of the infrastructure? Of course, it is possible that some of the business users of the enterprise will interact directly with this infrastructure when doing end-user application development. Will this change the answers to any of the preceding questions?

Even when confining our attention to the application programs, identifying the boundaries in client/server systems development projects can often be tricky. In the simple case, where an application is developed partially on a client and partially on a server, the boundary includes them both. However, many projects call for the development of server applications that will interact with other pre-existing clients and servers in addition to a client program that is being developed as part of the project. In this case, multiple boundaries may need to be considered.

Can function points be used with object oriented development?

Yes. You probably see the pattern here! The short answer is that they can be used to measure these applications and their size is the same as if object oriented development had not been used. This is because the function point count for an application is independent of the technology used to develop the application. However, the use of object orientation does tend to impact the function point count of the project that builds the application.

In the simplest case of software development, an application is built from scratch by a single project. In this case, the application and project function point counts are the same. For example, building a 1000 function point system would be a 1000 function point project. Object orientation is quickly making this simple approach to application building a thing of the past!

At a minimum, using object oriented development techniques allows the developer to use pre-built Windows editing controls and the like. When object orientation is fully embraced, developers can incorporate major chunks of functionality into their applications. For example, OLE Automation allows an application to completely harness the power of Microsoft Project version 4.0. Counting in these situations requires good engineering judgment and experience.

One school of thought has been simply to incorporate all of the functionality into the application and project counts. This makes sense for minor functionality that would not be separately recognized by the user anyway, like editing controls. However it is often a problem for more function rich components. If the user realizes that much of the functionality that is being provided has actually come from a purchased application, will he be willing to give the developer "credit" for all of that functionality? If the developer claims all of the functionality of both the custom written portions and the acquired portions of the project, will the function point technique still be usable for estimating?

It should be stressed that these considerations have been around longer than object oriented development. However, years ago these were the exceptional cases. Now, they are becoming the norm. The function point community still needs to codify its approach to handling these situations.

The International Function Point Users Group (IFPUG) has just published a case study showing the count for an application that was developed using object oriented techniques. It is Case Study number 3.

How does the use of function points compare to the use of lines of code?

The number of lines of code is the traditional way of gauging application size. Some people claim it is still relevant because it measures what software developers actually do, that is, write lines of code. They will use lines of code either instead of or in addition to function points. Other practitioners say lines of code are irrelevant. Capers Jones has declared "the use of lines of code metrics for productivity and quality studies to be regarded as professional malpractice starting in 1995."

At best, counting lines of code measures software from the developers' point of view. Since function points are based on screens, reports and other external objects, this measure takes the users' view. In these days of outsourcing and other confusion regarding the role of IT in an organization, understanding the users' view is of critical importance!

Related to these different views is the phenomenon that you get what you measure. When the number of lines of code is your primary measure of productivity, you often get it by having developers use less powerful languages and ignore opportunities for reuse. When the number of function points is your primary measure of productivity, you tend to get increased production of functionality by the developers. Of course, it is the users' responsibility to evaluate whether this functionality is delivering increased business value.

There are other technical problems with the lines of code measure. IBM encouraged the development of function points because it was starting to see a heterogeneous development environment where BAL, COBOL and PL/I where being used. Now almost every shop is using a mixture of languages. Furthermore, most modern development projects use a host of languages. How do you compare a project that delivers a 100,000 line mixture of C++, SQL and Visual Basic to one that delivers 100,000 lines of COBOL?

In addition, there is no standard definition of what a line of code is. Do blank lines count? Do comments count? Are data declarations included? What happens if a statement extends over several lines? Organizations, like the Software Engineering Institute, have published some guidelines in an attempt to standardize counting, but no one organization has played the same role for lines of code that IFPUG has for function points.