Years ago when Karl Weigers (Software Requirements) introduced his “No More Models” presentation the IT landscape was rife with new concepts ranging from Extreme Programming to the Agile Manifesto to CMMI’s (multiple models), to Project/Program/Portfolio Management.
Since then, the rapidity of change in software and systems development has slowed, leaving the IT landscape checkered with agile, hybrid, spiral and waterfall projects. Change is the new black, leaving busy professionals and project estimators stressed to find consistent metrics applicable to the diverse project portfolio. Velocity, burn rates, story points and other modern metrics apply to agile projects, while defect density, use cases, productivity and duration delivery rates are common on waterfall projects.
What can a prudent estimator or process improvement specialist do to level the playing field when faced with disparate data and the challenge to find the productivity or quality “sweet spot”? You may be surprised to find out that Function Point Analysis (FPA) is part of the answer and that Function Points are as relevant today as when first invented in the late 1970’s.
What are function points (FP) and how can they be used?
Function points are a unit of measure of software functional size – the size of a piece of software based on its “functional user requirements,” in other words a quantification that answers the question “what are the self-contained functions done by the software?”
Function points are analogous to the square feet of a construction floor plan and are independent of how the software must perform (the non-functional “building code” for the software,) and how the software will be built (the technical requirements.)
As such, functional size, (expressed in FP,) is independent of the programming language and methodology approach: a 1000 FP piece of software will be the same size no matter if it is developed using Java, C++, or other programming language.
Continuing with the construction analogy, the FP size does not change on a project whether it is done using waterfall or agile or hybrid approaches. Because it is a consistent and objective measure dependent only on the functional requirements, FP can be used to size the software delivered in a release (a consistent delivery concept) on agile and waterfall projects alike.
WHy are fp a consistent and stable measure?
The standard methodology to count function points is an ISO standard (ISO/IEC 20926) and supported by the International Function Point User Group (IFPUG.) Established in 1984, IFPUG maintains the method and publishes case studies to demonstrate how to apply the measurement method regardless of variations in how functional requirements are documented. FP counting rules are both consistent and easy to apply; for the past decade the rules have not changed.
RELEVANCE OF fp in today’s it environment
No matter what method is used to prepare and document a building floor plan, the square foot size is the same. Similarly, no matter what development methodology or programming language is used, the function point size is the same. This means that functional size remains a relevant and important measure across an IT landscape of ever-changing technologies, methods, tools, and programming languages. FP works as a consistent common denominator for calculating productivity and quality ratios (hours / FP and defects / FP respectively), and facilitates the comparisons of projects developed using different methods (agile, waterfall, hybrid, etc.) and technical architectures.
consistency reigns supreme
THE single most important characteristic of any software measure is consistency of measurement!
This applies to EVERY measure in our estimating or benchmarking efforts, whether we’re talking about effort (project hours), size (functional size), quality (defects), duration (calendar time) or customer satisfaction (using the same questionnaire.) Consistency is seldom a given and can be easily overlooked – especially in one’s haste to collect data.
It takes planning to ensure that every number that goes into a metric or ratio is measured the same way using the same rules. As such, definitions for defects, effort (especially who is included, when a project starts/stops, and what is collected), and size (FP) must be documented and used.
For more information about Function Point Analysis (FPA) and how it can be applied to different software environments or if you have any questions or comments, please send me an email (dekkers@qualityplustech.com) or post a comment below.
To a productive 2016!
Carol
Musings about Software Development 