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 system. This is not always possible because of the volatile nature of software, which means that it changes often according to the developers' and stakeholders' needs; most of the time these changes are additions to the existing software.
The problem with this process is that adding functionalities often brings more havoc than benefits and new functionalities have to be implemented to correct the previous ones. This cycle leads to an exponential growth in software, which will be out of the developers' control after a certain amount of time. What computer scientists have been trying to do is to find a way to predict with certainty a sustainable growth rate, knowing the duration of a certain project.
In [1] Jones suggests a sustainable monthly growth rate depending on the project's field. According to his research, simple Systems software can sustain a monthly growth rate of 5% while Military software can sustain as much as 15%, presumably because of the resources they have access to. This method turned out to be unreliable because it assigned the same growth rate to projects with different duration and size. The proof of this unreliability is presented in [2] by Kulk and Verhoef; in it not only the authors 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. These two ratios serve exactly the initial purpose of finding out if and when a project will be out of developers' control.
[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

<student_name>