Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

You can't control what you can't measure" is a common mantra of those who practice software engineering. Consequently, an entire engineering discipline has grown to meet the demand for software measurement, and satisfy the desire for the necessary tools and techniques.

A few years ago, I wrote a series of columns investigating software metrics. The first and most common measurement that I discussed was the number of lines of code (LOC). Most people now realize the limitations of LOC—for instance, it's impossible to usefully compare programs written in different programming languages, and the correlation between the number of lines of code and a program's complexity is weak.

The History of Metrics
In the 1970s, various researchers attempted to address these LOC deficiencies; most notably T. J. McCabe, who created the Cyclomatic Complexity metric, and Maurice H. Halstead, who wrote The Elements of Software Science (Prentice-Hall, 1977). McCabe attempted to quantify complexity by analyzing the number of paths the code could follow during execution, while Halstead focused on counting operators and operands. Also during the 1970s, IBM researcher Alan Albrecht devised the function point (FP) metric. Function points differed from previous software measurement efforts in that they focused on the functionality of the program's behavior rather than the programmer's expression of that functionality (language, coding style, algorithm selection and so on).

When I began exploring software measurement, a debate was raging among the proponents of various metrics: Each was convinced that his measurement was the best. Most such debates won't endure without a victor emerging. Much as UML appears to have "won" the debate over which analysis and design notation is superior, FP appears to have won the hearts and minds of most measurement practitioners, as I found out when I recently surveyed software engineering literature published by the ACM and IEEE.

For the uninitiated, a summary of the essential tenets of FP counting is in order. David Garmus and David Herron, long-time FP gurus, recently published Function Point Analysis: Measurement Practices for Successful Software Projects (Addison Wesley, 2001). According to them, "The function point method evaluates the software deliverable and measures its size on the basis of well-defined functional characteristics of a software system. It accounts for data that is entering a system—external inputs (logical transaction inputs, system feeds); data that is leaving the system—external outputs and external inquiries (online displays, reports, feeds to other systems); data that is maintained outside the system but is necessary to satisfy a particular process requirement—external interface files." They add, "In addition, the impacts of general system complexities associated with system and processor constraints, distributed data processing, logical and algorithmic complexity, and several other variables are also assessed."

I asked Garmus how FP counting techniques work with the "lightweight" methodologies that emphasize rapid delivery and frequent iteration, such as Kent Beck's Extreme Programming and Jim Highsmith's Adaptive Software Development. "FP analysis sizes the deliverable, what the user receives," Garmus replied. "Consequently, the application development and maintenance (AD/M) process, technology, tools and methodology aren't considered in FP counting, although they are considered in estimation and project management. As a result, we can measure the success of AD/M processes, technologies, tools and/or methodologies for projects of a similar size and type. The organization can use the information to develop internal benchmarks when building new projects or even in managing outsourcing efforts."

FP Implementation
What's the best way to implement FP counting in an organization, I wondered? When I wrote my articles on software measurement, there was considerable interest among individuals interested in establishing careers as independent FP counters. However, that career path has not proven to be overly successful. According to Garmus, "There is strong evidence that function point analysis (FPA) is much more successful and useful when performed by a core group. They will be more consistent in FPA and more effective in its application for sizing, estimating and measuring software AD/M. Consequently, there is an ever-increasing demand for FP counters as permanent employees as well as consultants."

Function Point Analysis, like UML, seems to have survived a tumultuous adolescence and matured into a useful tool for the software engineer. If you've had experiences with FP counting—good or bad—write me at wkeuffel@acm.org.

RELATED ARTICLES No Related Articles		TOP 5 ARTICLES No Top Articles.