A Mathematical Model to Describe the Quantitative Behavior of Maintenance Efforts in Software Development over Time

A Mathematical Model to Describe the Quantitative Behavior of Maintenance Efforts in Software Development over Time

Abstract

Maintenance in software development has been widely covered and described in literature, however, usually from a qualitative point of view. The objective of this paper is to quantify the size of maintenance efforts over time. This is done via a comparatively simple mathematical model, with some simple, yet realistic assumptions. The results match reality as it is experienced in the software industry. By applying this model pragmatically in the software industry, planning and budgeting of software development over time including maintenance can be improved.

Introduction

Maintenance in software development has been deep-ly analyzed in literature, from various angles and under various aspects, however, usually from a qualitative point of view. A fundamental analysis was already done in 1969 by Meir M Lehman describing qualitatively how systems continue to evolve over time [1].?A further study [2] characterized the possible types of maintenance, based on an empirical study on 487 companies, finding the following categories:

a)??????????Corrective maintenance – primarily defect resolution

b)??????????Adaptive maintenance – environmental (e.g., operating system upgrades) and data changes

c)??????????Perfective maintenance – new functional or non-functional enhancements

d)??????????Preventative maintenance – proactive changes to extend system longevity (also referred to as “re-factoring”).

This paper qualitatively describes the size of effort over time for above categories a) and b). A very good example for category b) is represented by the following phenomenon: Software for business applications is subject to underlying law changes in respective countries, e.g. in the tax area or for human resources applications. Hence any relevant legal change imposes a new mandatory requirement to the software in use and hence needs to be correspondingly adapted and delivered.

The mathematical model

For this paper, let us formulate a mathematical model for maintenance categories a) and b).

Maintenance Category a):

Be d? the fraction of the capacity of a development team in year i from starting, that indeed goes into pure development, and not maintenance. Be d? = 1, and d? for i > 1 will be smaller than 1.

Be a? the corresponding maintenance - category a) - fraction of the capacity of a development team, in year i from starting. In presence of the only category a), there is

1)?????d? + a? = 1, i > 0

We assume that maintenance of category a) can be neglected after k years, because the software will have matured and has become almost free of defects. Let further α be the fraction of development, that has defects and causes maintenance efforts (so, α either measures the quality of development or equivalently the efficiency of the correction activities) and assume α is in average constant over time. ?The size of parameters k and α will in general depend on the involved respective development team, i.e. its development quality and correction efficiency, and on the nature of the respective software. Ideally k and α can be derived from historical team data. Corresponding calculations and examples can be found in the literature. [3,4]

With this and using equation 1), we define for a?:

2)?????a? = α(d??? + d??? + … + d???) ?for i > k and k > 0, 0 < α ?< 1

3)?????a? = α(d??? + d??? + … + d?)?for i <= k (i.e. the initial years)

Using equation 1):

4)?????d? = 1 - α(d??? + d??? + … + d???) ?for i > k and k > 0

5)?????d? = 1 - α(d??? + d??? + … + d?)??for i <= k

After several years, i.e. for large i, it can be shown [5] that d? converges to

6)?????d∞ = 1/(1 + αk)??

and correspondingly

7)?????a∞ = αk/(1 + αk)

As an example, take k = 3 (software would be free of defects after 3 years) and α = 0,17 (17% of coding developed requires maintenance effort. As a result, the maintenance part for the development team would converge to 33,77% (see also the simulation in figure 1), and the capacity left for new development would be left to 66,23%.

No alt text provided for this image

As a first important result, we see that in the presence of only maintenance category a), there is no “maintenance death”, and the maintenance part will stay limited, however, up to a significant fraction.

As a further result, there is a minimum in development capacity after k+1 years, where the development capacity decreases to

8)?????d??? = (1 - α)?

, which can be seen by transforming equation 5) into its explicit form. Note that with this, the development capacity never reaches zero, for any parameters α (between 0 and 1) or k, which will become important in the next session.

It can be discussed whether the constant factor α in equation 2) is realistic or whether the maintenance impact should not rather decrease over time. This behaviour can be covered with the same model. Let’s look at the following example with a linear decrease from α to zero within k years:

9)?????α? = α(k - j)/(k - 1) , j = 1, …, k, and 0 < α < 1

10)?????a? = d??? α + d??? α(k - 2)/(k - 1) + … + d????????α/k )?for i > k and k > 0, 0 < α < 1

With the same procedure as above we arrive at

11)?????d∞ = 1/(1 + αk/2)??

This shows that the above conclusions for maintenance category a) stay exactly the same and that just the parameters α and k are adjusted, in this example by replacing k with k/2.

Maintenance Categories a) and b):

Be further b? the fraction of the capacity of a development team in year i from start, that goes into maintenance category b). With this, we have in analogy to equation 1)

12)?????d? + a? + b? = 1 for all i.

Let further β be the fraction of development, that needs to be corrected within maintenance category b) (e.g. law changes) for every year, and assume β is in average constant over time, in analogy to α for maintenance category a). With this we have

13)?????b? = β(d???+ d??? + … + d???) for 0 < β < 1, i > n

14)?????b? = β(d???+ d??? + … + d?) for 0 < β < 1, 1 > i <= n

Like k for maintenance category a), n represents the number of years for which a development once done undergoes changes because of maintenance category b). However, the decisive difference between maintenance category a) and b) is that for b) new adaptive requirements may come up even many years after the original development, in fact during the entire life-time of a product. In mathematical terms: n will be much larger than k, practically representing the life-time of a product. Legal changes are a very good example of this “longevity”.

A second difference is that the changes introduced via maintenance category b) might have themselves defects of maintenance category a). Hence, we assume for maintenance category a):

15)?????a? = α(d??? + d??? + … + d???) + α(b??? + b??? + … + b???)

?With equation 12) this becomes

16)?????a? = α(k - a??? - a??? - … - a???)

, and again from this

17)?????a∞ = αk/(1 + αk)

This shows that the maintenance load of category a) for the development team stays the same even in the presence of maintenance of category b). As such, this is not a surprise, as maintenance of category b) behaves like regular development, e.g. for additional scope, and hence leads also to the same results in this mathematical model.

From equations 12) and 13), it follows

18)? d? ?+ a? + β(d??? + d??? + … + d??? ) = 1

For arbitrary large i, this converges to

19)?????d∞ + a∞ + βnd∞ = 1 ??????????and from this

20)?????d∞ = 1/(1 + αk)(1 + βn)

to be compared to equation 6) in the presence of maintenance category a) only. This already shows a significant decrease of the available development capacity as we assume n being large.

But the impact at earlier times is even larger: Using equations 12) and 14) we have

21)?????d? + a? + β(d??? + d??? + … + d? ) = 1 ??????????????for 1 < i <= n+1

Comparing this to the situation where maintenance category a) would not be present, but only maintenance category b), we see that the solution of the following equation presents an upper limit for di:

22)?????d’? + β(d’??? + d’??? + … + d’? ) = 1 ??

Like for equation 8), the explicit solution can be easily derived to be

23)?????d’??? = (1 - β)??????????????????????????????????????????????????????????????????????????????????for 1 < i <= n+1

, which for larger β approaches zero very quickly.

See an example simulation in figure 2) with k = 3, α = 0,17 (like in figure 1) and n = 17, β = 0,10. The upper limit for d’18 would be 0,917 = 17%. The actual value is 10%, which is lower, because maintenance category a) has been taken into account in this simulation.

No alt text provided for this image

Can d? become even negative? This would reflect a situation, where the available total capacity cannot handle any more all the maintenance caused by maintenance category a) and b). In fact, this can be the case, quite in contrast to the situation with maintenance category a) only, where it can be easily shown that di always stays between 0 and 1. Let’s look at equation 21) for i <= k + 1. The explicit solution can then be derived as [6]:

24)?????d? = α/(α - β)(1 - α)??1 - β/(α - β)(1 - β)??1 ?????????????0 < i <= k + 1

d? is decreasing with increasing α, β and i, and can become indeed even negative. See as an example the solution for the special case i = 4, and α = β [6]:

25)?????d? = (1 - α)2(1 - 4α)

This will become negative for α = β > 0,25.

Conclusions

Maintenance efforts can be forecasted and planned, pending on only few parameters (α and k for maintenance category a), and β and n for maintenance category b)). These parameters will in general depend on the development quality of the involved team, the correction efficiency and the nature of software considered. Hence, the following can be derived for application in the software industry:

????????????Budgeting and capacity planning can appropriately consider the principle evolution of maintenance over time in a quantitative manner.

????????????By analyzing actual data and comparing them to the parameters used in this model, development quality and correction efficiency can be assessed.

Maintenance category b) has serious impact on the free capacity of a development team and is considerably more critical than maintenance category a):

????????????Long-term, it decreases the free development capacity significantly.

????????????Especially towards the end of the lifetime of a specific product, free development capacity will drop almost to zero.

????????????Earlier, there is a risk that available resources will not be sufficient to handle the cumulative maintenance work, depending on the quality of the development, the efficiency in corrections and the sensitivity of the product to the need of continuous changes, e.g. because of legal changes.

Further studies suggested

????????????Analyzing actual data in the software industry and comparing them to the parameters used in the model

????????????Modelling of maintenance categories c) and d)

Acknowledgements

The author wishes to thank Dr. Knut Barthel, Heinz Lüken and Dr. Klaus Weber for helping to deepen his understanding of the matter and for important input for this document.

References

[1]?????[Lehman, Meir M. (1980). Programs, Life Cycles, and Laws of Software Evolution.?Proc. IEEE.?68?(9): 1060–1076]

[2]?????[Software Maintenance Management: A Study of the Maintenance of Computer Application Software in 487 Data Processing Organizations. Bennet P. Lientz, E. Burton Swanson. Addison-Wesley]

[3]?????[Idan Amit, Dror G. Feitelson, Corrective commit probability: a measure of the effort invested in bug fixing, Software Qual J (2021). https://doi.org/10.1007/s11219-021-09564-z]

[4]?????[Schach, S.R., Jin, B., Yu, L. et al. Determining the Distribution of Maintenance Categories: Survey versus Measurement. Empirical Software Engineering 8, 351–365 (2003)]

[5]?????As a first step, it is easy to show that if di converges, it converges to 1/(1+αk). If d? converges for large i, all terms d??in equation 4) become d∞, and equation 4) becomes d∞ = 1 - αkd∞, and from this directly equation 6).

To then show the convergence, we apply the z-transform on equation 4) and apply the final value theorem for the z-transform, leading to the desired result from equation 6)

[6]?????Equation 21) can be rewritten as d??? = (1 - β)d? ?- a??? + a?

Using the explicit solution for a? = 1 - d? for i <= k + 1 from equation 8), inserting the solution from equation 24) into equation 1) proves that this is the right solution. Note that mathematically the solution in 24) strictly is only valid for α ≠ β, but the solution can be meaningfully extended for α approaching β.


Dora Gabriella Zielske

International Business Mediator, Economist

3 年

Thank you Michael Depner and Barthel Knut. This is giving me facts to argue with. Companies embarking on the road of digital transformation, ie. starting massive internal software product development, must be 1)aware and 2)plan based on this

Eduardo Borba

CEO | CxO | General Manager | Tecnology, Data&AI, Cybersecutity | Mentoring | Advisory Board | Board Director | Entrepreneurial | Organizational Systemic Consultant

3 年

Great article bringing solid arguments. Very helpful for leaders from software industry. My respect Michael Depner

Daniel Lazzari Souza

Vice President, SAP Globalization, SAP Labs Latin America - building local software globally for intelligent enterprises

3 年

There it is, mathematically proven value of maintenance fees. If anyone is speculating about stopping maintenance and legal changes to keep innovating, I wouldn’t want to be there to see what happens ??

Barthel Knut

Head of Localization Product Management Latin America

3 年

Very relevant and simple, yet little known reasoning that easily explains why mature software development teams never seem to have the capacity to innovate like startups who are not yet under water with b)-type maintenance …

要查看或添加评论,请登录

Michael Depner的更多文章

社区洞察

其他会员也浏览了