© 1996-2003 by Software Composition Technologies, Inc.
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.1.
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:
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:
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.
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.
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. 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.
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.
For some time, function point practitioners recognized that some classes of applications did not profit from function point analysis as much as they hoped. These application classes included real-time process control, mathematical optimization and various embedded systems. In 1986, Software Productivity Research (SPR) developed feature points.
This technique considers the number of algorithms used in the application and slightly modifies some of the weights of the traditional function point constituents. It was designed in such a way that typical business applications, an area where function points have been applied successfully, would have the same size whether calculated with function points or feature points. The problem classes of applications mentioned above will typically have higher scores when measured feature points than with function points. This compensates for the fact that productivity usually appears to be lower for these applications. Of course, feature points are still considered to be experimental.
Feature points do not enjoy the same level of acceptance as function points do. There is no standards organization, like IFPUG, that concerns itself with its use. However one requirement of a standard is that it be available for people to study and use. Capers Jones has documented the technique in his Applied Software Measurement book. SPR makes a description of the technique available on its Web page in an article called "What Are Feature Points?" It describes both function and feature points, and discusses how to choose the appropriate one to use for any given application.
Nolan, Norton & Co., part of KPMG Management Consulting, hired Charles Symons in 1984 to advise clients on methods to improve their systems development performance. In the course of doing this he claims to have discovered weaknesses in Albrecht's approach to function point analysis and developed the Mk II approach to overcome them. By 1987 it became a licensed product and is actively marketed.
Symons claims that the Albrecht approach suffers from the following weaknesses:
The principal conceptual difference between the two methods is the calculation of Information Processing Size, which corresponds to the Albrecht Unadjusted Function Points. Symons decomposes the application being counted into a collection of logical transactions. Each transaction consists of an input, a process and an output. For each transaction, Unadjusted Function Points (UFP) become a function of the number of input data element-types, entity-types referenced and output data element-types. The UFPs for the entire system are then summed.
Detractors of Symons' work say that Mk II is simply a way to overstate the value of the monolithic systems that Nolan, Norton & Co.'s clients were building at the time. They consider it a political concession that will undermine the competitiveness of those clients in the long run. More moderate critics believe that Symons identified some function point issues that practitioners were already addressing. However, he chose to deal with them in a manner that would lead to a proprietary Nolan, Norton & Co. product, instead of strengthening the original Albrecht work.
Grant Rule supplied information on the current state of Mk II. He reported that the technique has been in the public domain since 1991. The design authority is the United Kingdom Software Metrics Association (UKSMA) who were formerly known as the United Kingdom Function Point Users Group (UFPUG). He has also written an article comparing Mk II and IFPUG function point counting. Unlike IFPUG, UKSMA makes there Counting Practices Manual available for free for download to non-members. It is interesting to note that the latest version of the UKSMA Counting Practices Manual was released in September of 1998.
Between 1989 and 1992, the Boeing Company considered the use of function points to measure productivity. An internal Boeing Company document was published in the proceedings of the Pacific Northwest Software Quality Conference in 1992. It defined a technique called 3D function points.
The new technique was designed to address two classic problems associated with the Albrecht approach. First, the approach is considered difficult to use. Second, it does not properly measure scientific and real-time systems.
The three dimensions in 3D function points are data, function and control. The data dimension is similar to Albrecht's function points. The function dimension adds transformations, which are similar to the algorithms. The control dimension adds transitions, which enumerate changes in application state. It has been claimed 3D function points scale downward to the class level when used in conjunction with object oriented development.
It is debatable whether 3D function points are any easier to count than traditional function points. It is also debatable whether the technique addresses scientific work any better than feature points do. It is a fact that 3D function points are not widely used at this time.