Software Size Estimation by Integrating Functional Size and Functional Complexity Measures
This study proposes a software size estimation model that integrates Functional Size Measures (UFP and CFP) with Functional Complexity Measures (CC and YC) using regression analysis, demonstrating that combining these metrics—particularly UFP with complexity measures—significantly reduces estimation error and improves prediction accuracy for applications like COCOMO II.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Building software is a complex endeavor, much like constructing a building, but instead of bricks and mortar, the materials are lines of code and functional requirements. For decades, project managers have relied on counting these lines of code to estimate how much time and money a project will take. However, this method is flawed because two programs can do the exact same thing while requiring vastly different amounts of code depending on how the programmer writes it. To solve this, the industry developed a way to measure software by what it actually does for the user—counting inputs, outputs, and data files—rather than how it is written. This is known as functional size. Yet, even this functional count has a blind spot: it measures the quantity of features but often misses the difficulty of building them. A simple feature might be easy to construct, while a complex one with many branching paths and conditions could be a nightmare to code, even if both count as a single "feature" in the traditional sense.
This gap between the size of a feature and the complexity of building it is the central puzzle tackled by a team of researchers from Indonesia. They set out to see if combining a measure of functional size with a measure of structural complexity could lead to more accurate predictions of a software project's true scale. Their work focuses on refining how we estimate the effort required to build software, a critical task that determines whether a project stays on budget or spirals out of control. By looking at both the "what" and the "how hard" of software, they aimed to create a clearer picture for the people who plan and manage these digital systems.
The researchers began by gathering data from two real-world software projects: one designed for an employee cooperative and another for a retail store. They did not use public datasets because those often lack the specific details needed for their analysis. Instead, they took the textual requirements for these applications and translated them into visual flowcharts, known as BPMN diagrams. These diagrams served as a bridge, allowing the team to extract two different types of measurements for every part of the system. First, they calculated the functional size, which counts the number of user interactions and data files. They used two established methods for this: one that counts unadjusted function points based on standard categories like inputs and outputs, and another that counts cosmic function points by tracking how data moves in and out of the system.
Next, they measured the structural complexity of those same parts. This involved analyzing the logic within the flowcharts to see how many decision points, loops, and branching paths existed. They used two different complexity metrics for this: one that counts the number of independent paths through the code, and another that weighs the cognitive difficulty of different types of branches and loops. Finally, they compared these combined measurements against the actual number of lines of code written for the projects. This final count served as the ground truth, the actual size of the finished software that the researchers were trying to predict.
The results revealed a distinct pattern depending on which functional size method was used. When the researchers used the first functional size method, adding the complexity measurements significantly improved the accuracy of their predictions. Specifically, the error rate in their estimates dropped from twenty-four percent down to twenty-two percent. This suggests that for this type of functional counting, knowing the complexity of the logic helps correct the estimate, bringing it closer to reality. However, the story was different for the second functional size method. When they used the cosmic function points, adding the complexity measurements did not lower the error rate, which remained steady at fifteen percent. In this case, the functional size measure was already so precise that the extra complexity data did not make the final number more accurate.
Despite the lack of improvement in error rates for the second method, the complexity data still proved valuable. When the researchers added complexity measures to the cosmic function points, the quality of their predictions improved in a different way. The percentage of estimates that fell within a very tight margin of error increased from seventy-six percent to eighty percent. This means that while the average error didn't change, the team became more reliable at getting very close to the correct answer. The study concludes that integrating complexity measures is not a one-size-fits-all solution; its value depends on which functional size method is being used. For one method, it sharpens the accuracy, while for the other, it sharpens the consistency. These findings offer a new, more nuanced way to feed data into established effort estimation models, potentially helping software teams make more informed decisions about the time and resources their projects will truly require.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.