Future of Function Points

What is the Future of Function Points?

Scrum / Function Point?

In 1979, Allan Albrecht defined the initially concepts about Function Points and remain valid till now. At the same time, this is a strength and weakness of Function Point model. It is a strength because the real value of the benchmarking activity, results from applying the same rules and process to compare industry data. But it is a weakness because software engineering has evolved a lot since then. For example, the waterfall model is now considered a flawed method because it is so rigid and unrealistic. Nowadays, much software is created using agile methods.

Not only new environments should be introduced in the Function Point Counting Practices Manual, we need to be able to introduce new software engineering models in this manual.

The future of Function Points depends on the capacity of adaptation to the changes. Adaptation to changes is nothing new, throughout history, human have repeatedly demonstrated a strong capacity for adapting to different environmental changes.

IFPUG community should keep working to improve the Function Point Counting Practices Manual providing more examples, clarification and enhanced interpretations for existing rules. All of this may help software developers to stably patterns and facilitate automated measurements of function points.

The automated measurement should help an organization to deliver quickly. The organization could estimated efforts quickly and could be agile to adapt the development team to changing requirements. But IFPUG community should change and improve the Functional Size Measurement Method Procedure. This procedure should be Agile.

 
Agile? Could we use Function point with an agile methodology? We can take a look inside Scrum.

Scrum is a team-based iterative and incremental Agile methodology. It has its own components, such as the Scrum Team, backlogs, and sprints. But what is the meaning of backlog in Scrum? The product backlog is an ordered list of “requirements”, the product backlog is the “What” that will be built, the backlog are commonly written in story format, the development team can identify the user, action and required result in a request and is a simple way of writing requests that anyone can understand.

Then we take a look inside Function Point. The first step in the function point counting procedure is to gather the available documentation. These requirements are very close to definition of backlog: the user requirements specifying what the software shall do, in a language that is common to both user(s) and developers.

The first step in both situation are very similar, we could continue improving the Functional Size Measurement Method Procedure. I think a shortcut should be introduced in the process and make it even easier. For example, we could measure only Transactional Functions and not Data Functions.

IFPUG community could move to the next level, analyzing a new approach for development using Agile methodologies.
 

This article was published on the IFPUG website, and the July/August2013 Issue of MetricViews can be downloaded as a PDF here.