Monitoring Software Size


Large and complex software systems are hard to keep under control; in fact one of Software Engineering's goals is to achieve the same objectives with simpler and lighter systems. This is not always possible due to the volatile nature of software, which means that it often changes according to the developers' and stakeholders' needs. Software size is measured by counting the number of features and functions, known also as requirements, that it provides. The change in the number of requirements or, as it is called technically, requirements volatility can happen in various forms:
* Requirements creep: requirements need to be added because additional features need to be implemented.
* Requirements scrap: the scope of the requirements is considered to be too broad they need to be reduced.
* Requirements churn: the number of requirements is the same, but they are different ones.
The change in software's size could be easily expressed as the average percentage of requirement change, but this measure would not give enough information about the interval of time in which the change has happened. Instead of this simple percentage, it is better to measure the change in a similar way to the one used to calculate the compound interest in finance. This activity considers the initial money deposited in an account, after the first period it produces a sum called interest, this amount of money is left in the account, therefore the next period's total interest will be higher than the first as it is produced by the first period's interest too. This leads to a compound monthly growth instead of a linear one.
The same thing happens with requirements. They never remain the same, and when a change is made it brings more changes with it due to incompatibility with other requirements or rising of other requirements that hadn't been thought before. The later the requirement change happens, the bigger impact it causes because it may influence more requirements than it would have in an earlier stage of the development.
The first formula in Figure 1 estimates the final size of a project knowing the initial size of the project, the growth rate and the expected duration. However, if the final size of the project is already known, it is also possible to discover the actual compound growth rate r by inverting the first formula. 
Volatility rate is a strong indicator for a project's success or failure, in fact projects with high volatility rates are often in trouble. The goal is to find the exact growth rate that is problematic for a certain project as different projects with certain size and expected duration may be able to tolerate different growth rate values.
To be able to calculate a monthly growth rate it is necessary to determine the size of the project at least in two different moments, knowing this information and the duration of the project in months and having the previously mentioned formula we can easily determine the monthly growth rate of a given project.
Many authors have proposed ways to determine a maximum growth rate for IT projects, they all state that excessive requirements creep is bad but they fail to identify a way to determine how much is excessive or unhealthy. It is believed that requirements volatility is a technical necessity, because of that it is necessary to find ways to deal with it.
In [1] Jones suggests a fixed sustainable monthly growth rate depending on the project's field. Figure 2, taken from the same article, shows the average sustainable growth rate and the maximum one recorded by the projects studied by Jones. The third column shows what Jones thought were the limits between a project's success and failure. What these values ignore is the projects' size and the duration, taking into account only the field they belong to.
This method turned out to be unreliable because it assigned the same maximum growth rate to projects with different duration and size. The proof of this unreliability is presented in [2] by Kulk and Verhoef; the authors not only refute Jones' proposition, but they introduce two simple indexes based on a growth tolerance factor: the p-ratio that takes into account the project's duration and the ?-ratio, similar to the previous one but with the addition of the project's size into the calculation.
This formula shown in Figure 3 is relative to the p-ratio and relates the actual growth rate ract with the maximum sustainable one in that precise moment rp. It gives an indication on how close a project is to the danger zone.
Next figure shows a simple example in which a project's health is checked after eight months of development. The maximum growth sustainable is 22.22%, while the requirements have actually increased only by 10%; dividing 22.22 by 10 the result is 0.45, meaning that the project is still in good health and has not reached its limit yet.

Figure 4 - p-ratio chart
Using this index it is possible to compare different projects with different durations: for example the above mentioned project would be in better shape than a project with a p-ratio of 0.8 and in a worse one with respect to one with 0.2. This comparison is possible because duration was considered in the calculation. This formula could be used also to check a project's health in two different times during its development and see how it varies.
Sometimes comparing two projects only taking into account their duration could be misleading. In this case dimension needs to be considered too; the ?-ratio is then introduced.
Unlike the p-ratio, the ?-ratio formula in Figure  5 contains the project's dimension, called f. To assess if a project is in a good state it is then needed to consider its rate, duration and size. Next figure shows graphically this concept; once the formula has been applied with the input data, if the value is above the blue surface it means that the project is already in the danger zone, and therefore out of control, while if it is below the surface it is still under control and its development can continue. 

Figure 6 - ?-ratio chart

[1] C. Jones, Strategies for managing requirements creep, IEEE Computer 29 (1996) 92-94
[2] G.P. Kulk, C. Verhoef, Science of Computer Programming 72 (2008) 136-175