The Technical Debt in Cloud Software Engineering: A Prediction-Based and Quantification Approach

Related Work

The Technical Debt constitutes a metaphor coined by Cunningham (1992), which explains the correlation between the software development and the financial debt. The extra work that is necessary to be held in the future is discussed, aiming to improve some of the non-functional requirements, such as the readability or the complexity (Cunningham, 1992), resulting in additional cost and likely interest payments (Allman, 2012; Curtis, Sappidi, & Szynkarski, 2012; Fowler, 2003; Klinger, Tarr, Wagstrom, & Williams, 2011; Lim, Taksande, & Seaman, 2012). Narrowing in, the term refers to the acceleration of the velocity for releasing software products, which might lead to implications, and forms the tradeoff between short and long-term value (Nord, Ozkaya, Kruchten, & Gonzalez-Rojas, 2012). The rework is the effect when the Technical Debt incurs and can range from a trivial one with few amendments to changes that may affect the whole system. Sterling (2010) mentions that the lifecycle can affect the size of the Technical Debt. For instance, an agile software development process would create less Technical Debt than a waterfall model due to the more flexible structure it has.