Function Point Analysis: Measurement Practices for Successful Software Projects

Analyzing Function Points
By Alan Zeichick

How big is this project?” That’s a hard question to answer when it comes to applications development. But it’s an important question, because unless you know how big a project is, you can’t estimate its costs or development schedule accurately. You can’t assess its quality fairly, or see if your organization is getting better—or worse—at handling projects of this size, or compare a development team’s efficiency against other teams within your enterprise or against industry norms

Back in the mainframe era, the crude methodology was to measure a project’s complexity by counting lines of code, and determine a development team’s effectiveness by tracking the man-months it took to build the program. These days, lines of code, lines of code per programmer per day, and person-months are no longer accepted as meaningful measurements. For the past 15 years or so, the industry’s best yardstick has been an application’s function-point count, and a team’s efficiency has been measured by the number of person-hours per function point, and software quality by bugs per function point.

Yet unlike counting lines of COBOL code, it’s hard to count the function points in a complex application, and seeing that complexity, many senior development managers and IT directors simply ignore the metric, and stick with counting lines of code. That’s why IBM Corp., which invented the function-point concept in the late 1970s, created an independent organization, the International Function Point Users Group (www.ifpug.org), to shepherd, simplify and promote function points to the broader software-development universe. And that’s why David Garmus and David Herron, two software-metric consultants, have written “Function Point Analysis: Measurement Practices for Successful Software Projects.”

What is a function point, anyway? One of the few weaknesses in Garmus and Herron’s book is that they don’t even get around to discussing that rather obvious point until halfway through the text—and even then, they can’t just come out with a clear and unambiguous definition. But briefly stated, an application’s function points are the sum of the different data types and sources used by the application (both internally generated and externally referenced), and the transactions and transformations applied to those data sources. Different weights are applied to different types of data and transactions, and some organizations also factor in so-called “general system characteristics,” such as required real-time performance, online data entry, code reusability and requirements for easy installation, to increase an application’s function-point count.

The authors’ primary audience is for the practitioner: the individual charged with learning all about function points, counting them and presenting the analysis to top IT management. However, any manager who is considering the use of formal function-point analysis to help instrument the software-development process, or who is part of an organization that uses function points, should have a good understanding of exactly what a function point is—not just to help with interpreting the analysis, but also because the entire concept of a function point is bound up with the parts of a piece of software that are hard to design, write and test.

The first five chapters of “Function Point Analysis” build the case for the use of function points. The arguments are no less persuasive because they’re familiar: Unless you can define and measure a process, you can’t determine its cost and efficiency, and unless you know its efficiency, you can’t quantitatively and qualitatively improve the process. Written largely for managers, the third chapter in particular points out how function-point counts can be used to track an application development project’s productivity, quality and financial costs, and also to estimate how hard it will be to maintain—the authors make the compelling point that for any development organization considering outsourcing new code development or maintenance, function-point benchmarks are a valuable tool for calculating ROI and for creating service-level agreements.

The next major section delves into the process of counting function points. It’s a maze of two- and three-letter acronyms for concepts like DETs and FTRs (data element types and file types referenced), ILFs and EIFs (internal logical files and external interface files), and then its EIs, EOs and EQs (external inputs, external outputs and external queries). Techniques for counting those acronyms constitute the essential elements of function-point analysis and can be used to derive the fundamental measurement, the unadjusted function-point count. Through these chapters, Garmus and Herron skillfully lead the reader through a minefield of do’s and don’ts, some of which can be quite unintuitive and even bewildering.

One area in which more guidance would have been appreciated is the discussion of modifying the unadjusted function-point count by applying subjective “general system characteristics.” Garmus and Herron make the point that a growing minority of organizations have chosen to ignore this particular process, called the value adjustment factor. I wish they’d provided clear advice: Should you use them or not?

The remainder of the book contains advice and advanced techniques for adapting function-point analysis to the modern world of the Web, GUIs, and object-oriented software. When the technique was first pioneered more than 20 years ago, applications were batch oriented and used structured programming techniques, and “code reuse” meant a library of standard subroutines. Garmus and Herron show where some aspects of function-point counting have lagged behind the state of software development.

Is function pointing for everyone? No. Is it a useful measurement? Yes. If you’re familiar with function-point analysis but want to know more, or if you don’t know anything about it beyond what I’ve written here, then this book represents the best single work on the topic that I’ve found. 

Reprinted with permission of SDTimes.  Originally appeared in Issue 26, March 15, 2001.