Tag Archives: productivity

Function Point Analysis (FPA) – 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 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!


Technophobia is more real than global warming

Have you read the hype lately about global warming – it seems to go in spurts and depending on how slow a news day it happens to be, it can be world news one day and relegated to the back of the classifieds the next.  While I don’t want to make a mockery of the effects of climate change on our planet (I haven’t done the full research to know whether to believe the Republicans or Democrats or the farmers on this one!) – I do think that global warming is the news du jour and the topic becomes a soapbox whenever a politician wants their 15 minutes of fame.

One thing that I know is an issue in software development and is seldom discussed is Technophobia or the irrational fear of technology.  One might be convinced that there is no such thing as technophobia when we read how the latest Apple iPad supplies swarmed off the shelves into the eager arms of technology savvy consumers, but I have to wonder what’s the true story. Every day, in every city, in almost every country I speak in, I meet professionals (and some are gen X’ers!) who are literally in the dark when it comes to technology. And, here’s the scary part, they might even be on your project teams!  (No, not on the software development side, of course, the customer/business/shareholder side) And furthermore, you might not even know it.

Our obsession with agile development, faster/better/cheaper, acronyms, connectivity, networking (hardware not people), configuration management systems, and all the other productivity tools we embrace to speed up our software development processes miss the boat when it comes to truly discovering what our customers (especially those with technophobia) really need.

So, what can a project manager or business analyst or programmer do when we meet a stakeholder who we fear (hmmm is there a fear of someone with technophobia?) might have technophobia?  It might seem all a bit trite to say the least that someone would actually fear technology, but I can assure you that it exists and it is not a fear that goes away when talking to those who live, eat, and breathe technology!

This is where a scope manager or customer advocate can make inroads with stakeholders. Often pride prevents professionals from confessing to their technophobia – and it can be debilitating to admit that one doesn’t understand members of the project team at all. Scope management is customer advocacy as I’ve stated earlier posts – and the scope manager as an independent consultant has the luxury of spending time with the customer to truly discover the scope of the business problem before any systems or software engineers get involved.  That means that the customer invests time and energy in initial discovery and doesn’t waste it trying to talk about what they really meant – as often would happen if a Request for Proposal (RFP) goes out with mistaken or incomplete requirements scope.

Technophobia is real and all around us, and if we want to firmly gain control of the typical 40% rework that consumes our software development projects, we ought to take a solid look at what a scope manager can truly bring to our projects and programs.

To your successful projects!


Carol Dekkers
email: dekkers@qualityplustech.com

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Dusseldorf, Copenhagen, and other venues in 2010 visit www.qualityplustech.com.
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======