Two challenges of software engineering projects are estimating the project effort (budget) and monitoring productivity of the development team. Both challenges can be addressed by using automated function point analysis (FPA). The concept is to build your own accurate benchmark of projects. Here’s how.
What is Function Point Analysis?
Function Point Analysis (FPA) – counting the number of inputs, outputs, queries, and files to estimate the size and complexity of a system – focuses on the functionality delivered by software engineers – rather than the development deliverables agreed per sprint cycle.
FPA is nothing new. Commonly-used in the era of waterfall development, where software was designed and developed to a plan, it required human counting to generate the data needed for meaningful insights. Usage used to be widespread, but FPA fell out of fashion due to its dependence on time-consuming, error-prone, manual counting methods.
Although the manual approach to FPA was unsuited to the modern era, it served an important role in determining the size and cost of a system – for internal benchmarking and project estimates. It gave organizations a unit of measurement for estimates – a cost per function point – providing transparency over billing and a way to predict the development time needed.
The widespread adoption of Agile development principles contributed to the decline of FPA due to shorter development cycles, and the need to count functionality more frequently than was possible through manual methods. That was until automated FPA came along.
How can FPA be used in an Agile environment?
Automation brings the benefits of FPA to the Agile way of working. In fact, the automation of function point counting – made possible by BonCode’s software quality management platform – has huge business value in modern development.
By automating and standardizing the counting of function points, it’s possible to calculate the function points as often as you like (as opposed to the early days, where FPA was expensive and cumbersome). As a result, a new stream of reliable project data emerges out of your project. This data provides reliable insight in the volume of functionality built, and that’s very useful in an Agile environment.
Conversations around productivity shift from project deliverables to how many functionality points were built, added, or removed in a particular sprint. Are we constantly redeveloping the same functionality (maybe good, maybe not so good), or are we consistently growing our functionality? Is the growth of the system stalling? Are our specification requirements maybe of lesser quality than we used to have?
And the second application of FPA is project cost estimation. The trick is to use it in all your projects. By automatically measuring function points in the same consistent way across your project portfolio, you can build your own internal benchmark. This benchmark supports project cost estimation.
The way this works is simple: any person busy with cost estimation knows that personal biases have a strong influence on estimations. People tend to underestimate the size of a project, because they rely on their knowledge of the actual usage of the software, which is not always related to the effort spent while building and maintaining it.
But most people have a pretty good intuition of ‘this project must be roughly the same size as that project’. Keeping track of recent projects (with your own benchmark), gives you an excellent health check on your cost estimation. Don’t change your cost estimation process, but add a check with your own internal FPA-based benchmark as a health check and challenge your team on discrepancies.
The internal benchmark gives organizations with business-critical, custom-coded software a reliable measure of three things: productivity, project timelines, and cost.
More reasons to use FPA
Automating FPA can help large enterprises to validate the productivity of different teams across different systems. It’s a useful way to standardize, creating an internal benchmark for project estimations. For instance, if a project of a similar size has previously taken place, it’s possible to get a time and cost.
Measuring function points makes it possible to make valuable comparisons to support data-driven decision-making. For example, by comparing productivity between low-code and hand-coded developers, we discovered low-code developers are up to 8 times more productive in terms of the number of function points completed.
Interested in internally benchmarking productivity in software development using Function Point Analysis? Speak to an expert at BonCode. Contact us.
