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

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

Georgios Skourletopoulos (Scientia Consulting S.A., Greece), Rami Bahsoon (University of Birmingham, UK), Constandinos X. Mavromoustakis (University of Nicosia, Cyprus) and George Mastorakis (Technological Educational Institute of Crete, Greece)
DOI: 10.4018/978-1-4666-8225-2.ch002

Abstract

Predicting and quantifying promptly the Technical Debt has turned into an issue of significant importance over recent years. In the cloud marketplace, where cloud services can be leased, the difficulty to identify the Technical Debt effectively can have a significant impact. In this chapter, the probability of introducing the Technical Debt due to budget and cloud service selection decisions is investigated. A cost estimation approach for implementing Software as a Service (SaaS) in the cloud is examined, indicating three scenarios for predicting the incurrence of Technical Debt in the future. The Constructive Cost Model (COCOMO) is used in order to estimate the cost of the implementation and define a range of secureness by adopting a tolerance value for prediction. Furthermore, a Technical Debt quantification approach is researched for leasing a cloud Software as a Service (SaaS) in order to provide insights about the most appropriate cloud service to be selected.
Chapter Preview
Top

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.

Complete Chapter List

Search this Book:
Reset