Demystifying Function Points

[article]
Clarifying Common Terminology
Summary:

 

A challenge in implementing function point analysis (FPA) is making it understandable to developers, cost analysts, and customers alike. Because function points are based on functional user requirements (what the software does), irrespective of the physical implementation (how the software is implemented), users of the method must think in terms of the logical functional requirements. This article discusses difficulties that arise with developers and clarifies a number of terms that often cause confusion.

 

A challenge in implementing function point analysis (FPA) is making it understandable to developers, cost analysts, and customers alike. Because function points are based on functional user requirements (what the software does), irrespective of the physical implementation (how the software is implemented), users of the method must think in terms of the logical functional requirements. This can be especially difficult for developers who spend their days focused on providing physical software solutions (involving how the software will be built).

Just as an architect begins by drawing a floor plan to meet the owners' needs, though, software project managers and developers begin by documenting the functional user requirements articulated by their customers. FPA examines these logical (also called functional) user requirements to determine the functional size of the software.

The difficulty that sometimes arises with developers is twofold:

·        A developer's job concentrates on the physical aspects of designing and implementing software, similar to how a master plumber or master electrician concentrates on the physical aspects of building a house

·        The function point analysis method itself uses terms that are well known in the information technology industry, but the meanings of particular words are different.

This article focuses on several key words that are the most problematic when introducing function points. By simply making your developers aware of these differences in meaning, you can achieve higher levels of measurement success and less resistance in FPA implementation.

Pages

About the author

Carol Dekkers's picture Carol Dekkers

Carol A. Dekkers is President of Quality Plus Technologies, Inc., a management consulting firm specializing in creating peace of mind for companies who want to improve their software processes. Software measurement, software quality, process improvement, requirements, and software sizing (using function point analysis, as an example) are a few of the Quality Plus areas of specialization.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!