One of the stated purposes of function point analysis is to provide a size measure that can be used as an input to help estimate the cost, effort, schedule, and staff needed to develop a software project. The standards for how this is done are maintained by the International Function Point Users Group (IFPUG). In a nutshell, function point analysis identifies, from a user perspective, logical groups of data that a project or application maintains or accesses and logical processes that update, query, transmit, or report on that data. The counting rules are extensive, very specific, and assign function point values to these based on the number of data stores a process accesses and the data elements it touches. To help assure that function point counting is conducted in a standardized manner, IFPUG certifies counters who have demonstrated mastery of the counting rules through passing an exam. These counters have the title of Certified Function Point Specialists (CFPS).

There is a problem with using traditional function point analysis in the conceptual phase of a software project when the budget, schedule, and staffing are being planned: the information required to count function points according to the rules is normally unavailable and, in many cases, does not yet exist. To overcome this obstacle, function point counters have devised a number of quick counting methods to estimate project function point counts. Most of these are rules of thumb whose implementation varies from one counter to another.

SiFP was developed by Roberto Meli and associates in Italy. In 2019, IFPUG acquired the rights to the methodology and plans to integrate it into its portfolio in 2021.  Follow this link for more details.

So how does SiFP differ from regular function point analysis, and why is it simpler? Three differentiators stand out:

We are pleased to announce that QSM Lead Trainer and Senior Consultant Pam Simonovich will be presenting a workshop focused on applying function point rules to emerging technologies at the upcoming ISMA 14 on September 13. She will also be giving away VR Elegiant Virtual Reality Glasses to one lucky participant!

Today’s sizing expert must be able to accurately apply function point counting rules and SNAP counting rules to a variety of software environments and technologies. This hands-on interactive workshop will prepare you to apply counting rules to the ever-popular gaming Industry and promises to include such technologies as Artificial Intelligence, Virtual Reality, Cloud computing, etc. The contents of the course will be reinforced with examples and hands-on case studies.

The workshop schedule will be as follows:

QSM recently published the fifth article in the QSM Agile Round Table series.  The QSM Agile Round Table was formed to discuss the role of estimation in agile environments.  QSM customers shared their questions, challenges, and experiences on the relevance and benefits of scope-based estimation in an agile environment. This article continues the focus from the previous article on determining size in a consistent enough manner across multiple products, projects, and agile teams so that you have good historical data on which to base an estimate. QSM's Andy Berner looks at other sizing units besides story points, in particular function points and source lines of code. 

Read the full article!

As we embark on 2017, which is also the 30th anniversary of IFPUG Bylaws, there are reports that the software development industry is making progress. The 2015 Standish Group CHAOS report cited that agile projects are, on average, three times more likely to be successful than waterfall projects (based on their survey of over 10,000 projects.) The not-so-good news, however, is that the percent of successful projects (defined as on-time, on-budget, and with a satisfactory result) hasn’t changed much since the first CHAOS report in 1996, and hovers around 40%. The top three success factors in the 2015 report were not technical: 1. Executive Support, 2. Emotional Maturity and 3. User Involvement (agile processes ranked #7.) The need for software sizing measures to support project estimating remains just as critical as it was 30 years ago, yet IFPUG function points are not used as extensively as they could be to support software sizing. Rather than “throwing the baby out with the bathwater,” so to speak, or creating new metrics to solve old problems, Carol Dekkers and Joe Madden suggest a new way to repurpose function points to achieve estimating successes today. This article was originally published in IFPUG's Metric Views.

Read the full article!

QSM is pleased to announce our Function Point Workshop is now IFPUG-certified! This 2 day course focuses on building function point analysis skills to measure software development work products. Students will learn how to express the result in a standard, accurate, repeatable way based on the logical view of required functionality in the business and the end user's perspective. This standard technique promotes consistent sizing across multiple project types, and can be used to support project estimating, application maintenance, and portfolio analysis. Ultimately students will gain an initial understanding of the purpose, context, and rules for counting function points. This course is targeted to attendees with interest levels ranging from high level familiarity with the process to those who are beginning to prepare for certification. 

Learn more about about QSM's workshops and function point offerings.

Function points are proven to be effective and efficient units of measure for both agile/iterative and waterfall software deliveries. However, inconsistencies come to light when comparing function points counted in agile/iterative development with those counted in waterfall or combination development . These inconsistencies can create confusion for cost, productivity, and schedule evaluations that span multiple software delivery methods. This paper, recently published on IFPUG's Beyond MetricViews by QSM Consultant Carol Dekkers, seeks to marry International Function Point Users Group (IFPUG) definitions with equivalent concepts in agile/iterative processes in order to create a basis for consistent comparison. 

Read the full article!

Sometimes business life follows literature. Recently, I came across the following quote and I had to pause:

“Before we build a better mousetrap, we need to find
out if there are any mice out there.” - Yogi Berra

It reminded me of a conversation I had over lunch 15 years ago, when I was president of the International Function Point Users Group (IFPUG) and Charles Symons was president of the UK Software Metrics Association (UKSMA), where we were talking about the future of software sizing.  IFPUG is the inventor of the original method to size software using a measure called “Function Points.”  Charles is the creator of a similar UK method called Mark II function points and a co-creator of the Common Software Metrics International Consortium (COSMIC) sizing method that was, at the time, still in its infancy.  I’m paraphrasing with the words but I believe it captures the content of our conversation:

“The problem with function points,” Charles remarked, “is that they aren’t yet perfect enough.  What we need is a better mousetrap and the world will beat a path to our door.”

I disagreed saying “I don’t think that’s the problem at all – I think the problem is that world doesn’t yet see mice as a problem.”

In our recent webinar, Function Point Analysis Over the Years, presented by Don Beckett, we received some great questions from our audience. Here are the highlights from the Q&A:

Q: The advice in recent years is to break large projects down into smaller ones to make them more likely to "succeed" by whatever measure. Is the advice now to make projects bigger?

A: I don't know if it's advice, but the data seemed to indicate that there is a benefit to grouping projects by larger size than the projects that are 50 or 100 function points. So I would say, where it's possible, where they can be grouped together, it would be a good idea.

Q: Why do you use the PI (Productivity Index) as opposed to the industry standard hours per function point or function points per person month?

A: Well hours per function point and function points per person month are ratios that take the ratio between effort and size and what we have found is that the schedule has a huge impact on how productive a project can be. The PI incorporates three major things: the size of the project, the amount of effort leveraged against it, and the time required to do it, so in a sense, it accounts for schedule, which function points per person month does not do. So that's why we use it.

Q: How do we convert a project from SLOC to function points to find the PI for a specific project?

Function point analysis has played an important role in software measurement and analysis for 30 years, but what will be the role of function points in the future? Will they have staying power? Expanding off of a recent article for IFPUG's Metrics Views, Don Beckett looks at the QSM software project database and examines a set of validated projects counted in function points that have completed since the year 2000 to see what they tell about productivity, schedule, and staffing. We are fortunate to have several thousand projects in this sample to work with as this allows us to parse the data many different ways and still have enough projects to be statistically significant. For this study only unadjusted function points were used.

Read the full white paper!