Function Point Analysis - Creating Stability in a Sea of Shifting Metrics
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 of "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 with ever changing technologies, methods, tools, and programming languages. FP works as an unchanging consistent 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.) or technical architectures.
CONSISTENCY REIGNS SUPREME
THE single most important characteristic of any software measure is consistency of measurement, 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 - one must take care 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, please send me an email ([email protected]) or post a comment below.
To a productive 2016!
Carol
Program Director, GenML Solutions Pvt. Ltd. || Data Scientist in Kolkata, developing data science practice in different domains viz., Life Science, DNA Sequencing & Information Technologies
8 年There is a very nice book on Function Point by M.A. Parthasarathy which provides very good insight into FP analysis.
Innovation | Cloud | Digital | Gen AI | AZURE | Automation | Delivery
8 年Sizing an application is an absolute must, but with the changes in the technology space, methodologies, i think FPA should also also evolve to be easily adapted to be used in the current scenario.
Creator of AI Software Requirements Analysis Tools - automated estimation, QA and insight.
9 年Nice article Carol, I use Function Points on virtually every IT project that I am involved with. The exception is infrastructure projects. They have brought a level of insight and certainty on my projects that I had never thought possible. My favourite tips for quick early sizing are: 1 Count the ILFs and x 35 + EIFs x15 for quick estimate. 2 Raise FP to the powers of 0.3 and 0.45 for a schedule range in months. 3 Raise FP to the power of 1.2 for an estimate of defects and test cases. Of course a full FPA count is necessary contractual or critical sizing exercises. Colin
New to your website QA. 5 hours - $100. Seeking work I can do at home due to recovering from an accident.
9 年Excellent article that produced many questions for me about using them. First, I think this brings us all to looking at the questions, "what is good enough?" How do we measure individual and group proficiency. I've worked on so many teams where I often felt that the software escaped not so much as was released. No one felt good about the product and it was a lousy product that customers hated. Second, how do we stay sane when circumstances change and something needs to ship before we thought. I've worked on web teams that the landscape experiences earthquakes and suddenly what was a cool idea yesterday can't sell today. Many cell phone apps have seen this. And what about fixing missing features (like why can't I look up bits of info I know about a contact on my iPhone? ) Really get article that gives us powerful tools to get better at this stuff.
Consultant - Software Measurement And Estimation - Training and Practice
9 年Good article.