The Estimation of Software Size by Measuring Functionality: How to do it

In this article, we will discuss how the size of a software project can be estimated by measuring its functionality.

Software size estimation is a necessary and important task in software development. It can be used to determine the resources needed for developing a product and forecast its final cost.

Is it possible to estimate software size before coding?

Yes, but it is important to note that the size of the software depends on several factors. The number of lines of code (LOC) in the software is a good place to start. Other factors that aid in estimation include the number of functions, bugs, or even the number of users.

While LOC is commonly used, it does not account for non-functional elements, duplicate lines, and some unused functions. Further, different programming languages have different numbers of lines per unit of code. This, therefore, makes it an inaccurate estimation technique.

How do I measure software size by functionality?

Overview

This is the most common method of measuring software size. Using this technique, you measure the functionality you need to deliver to your users. In other words, you will count the number of features that have been implemented.

Functionality is a good metric of size because it measures the complexity of the software.

1. Identify all functions and features

1. Create a list of all of the functions and features in your software. You can use a tool like Microsoft Excel.
2. Next, include a description of what it does and any other attributes you think are important, as this information will come in handy when grouping them into logical components.
3. Determine which functions/features depend on others. A component with no dependencies can be considered standalone, and its size will equal its LOC count. You can count the LOC manually or use a LOC counter tool.
4. If a function/feature has dependencies, increase its size by adding up all the LOC dependent on it.

2. Assign each function to a group

1. Group like functions together and assign them to one or more categories.
2. Assign points per function within these groups based on their complexity and difficulty.

The size of a component should be proportional to its complexity. A component with more complex logic will have more features than a component with simple logic. For instance, when grouping functions, you can create a distinction between basic and core functions.

Each software has basic and core functions and features. They are the key ingredients that make your product work properly and are a necessity. This will help you create more meaningful metrics when comparing your application’s size over time.

3. Calculate the size of each component

After you’ve grouped your components and decided which ones need to be included in your calculation, you need to determine how many lines of code (LOC) each component has.

You can manually do it by identifying the number of groups and multiplying each group with its size in terms of function points. Alternatively, you can do this by using a tool that can automatically count LOC for each component.

Pros and cons of using the functionality metric in software size estimation?

Traditional software size measurement methods only count the number of lines of code, which doesn’t show how many features are really in your software. Measuring software size by functionality makes more sense, especially when talking about large-scale, enterprise-level software.

It gives a more accurate picture of what is available to the user, and allows the product owner to easily assess the competitive landscape.

And even though this method has its drawbacks, it is much better compared to other size measurement techniques. After all, the end user can always reduce the software size if they deem fit and your code allows it.

As you can likely tell, our thoughts support the functional method. However, we must admit it’s not everyone’s cup of tea, so we’re open to hearing your suggestions. Is there any estimation of software metrics you think would do a better job? Let us know below.