Estimating the breaking point for technical debt

Chatzigeorgiou, Alexander; Ampatzoglou, Apostolos; Amanatidis, Theodoros

doi:10.1109/mtd.2015.7332625

Cited by 40 publications

(48 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Regarding the number of must-fix problems. In our previous work [7] we have presumed that there is an actual design quality for any object-oriented software, which can be estimated by a proper fitness function. Under this perspective, the 'spread' between the optimal and the actual design, as it can be derived by the difference in their fitness function values, can be mapped to the principal, i.e., the effort needed to convert the actual system to the correspondent optimum one.…”

Section: Principal Estimationmentioning

confidence: 99%

“…Although research on TDM has been intense in the last years, the community still faces major challenges, two of which are the focus of this paper: (a) a sound estimation of the amount of TD (i.e., the quantification of interest and principal [5]), and (b) the monitoring of the TD amount, as it increases due to the accumulation of interest [6]. In our previous work [6,7], we begun to address these challenges, by defining a theoretical framework, named FITTED, that can be used for the long-term management of Technical Debt. FITTED considers that interest accumulating during software evolution, can potentially outgrow the amount required for repaying the principal of TD.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

A framework for managing interest in technical debt

Michailidis

Sarikyriakidis

Ampatzoglou

et al. 2018

Proceedings of the 2018 International Conference on Technical Debt

Self Cite

View full text Add to dashboard Cite

Technical debt management entails the quantification of principal and interest. In our previous work we had introduced a framework for calculating the Technical Debt Breaking Point (TD-BP), which is a point in time where the accumulated interest becomes larger than the principal; thus the debt of the company is no longer sustainable after this point in time. In this paper, we instantiate this framework and validate its ability to assess the breaking point of source code modules in an industrial setting. The results of the validation suggest that the calculated TD-BP is strongly correlated to experts' opinion on the sustainability of modules, and that it can accurately rank components, based on their maintenance difficulty. CCS CONCEPTS• Software and its engineering → Software creation and management; Designing software; Software design engineering • Social and professional topics → Professional topics; Management of computing and information systems; Quality assurance KEYWORDS

show abstract

Section: Principal Estimationmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

A framework for managing interest in technical debt

Michailidis

Sarikyriakidis

Ampatzoglou

et al. 2018

Proceedings of the 2018 International Conference on Technical Debt

Self Cite

View full text Add to dashboard Cite

show abstract

“…Zazworka et al presented four techniques for identifying types of TD. While this work did validate the effectiveness of various detection methods, it was not intended “to predict either defects or change‐proneness in future instances of the code base.” Chatzigeorgiou et al provided an approach that estimates “the time point at which accumulated interest from TD will exceed the initial savings obtained by not repaying the principal.” By determining a break point based on the estimation of a principal, the interest, and cost for fixing a problem, project managers are better able to manage long‐term support. Fernandez‐Sanchez et al proposed an evaluation framework to assist in TD management.…”

Section: Literature Reviewmentioning

confidence: 99%

“…Over the life cycle of a software application, changes in sustainment requirements, such as the number of defects requiring correction or enhancements to capability, increase the cost and time required for maintenance. Specifically, organizations typically employ short‐term fixes at the expense of a long‐term support strategy, which increases the level of application complexity or technical debt (TD) …”

Section: Introductionmentioning

confidence: 99%

“…Specifically, organizations typically employ short-term fixes at the expense of a long-term support strategy, which increases the level of application complexity or technical debt (TD). 17 From the author's research, the elements influencing software obsolescence risk assessment fall into two categories. The first is external dependencies, which are outside the control of an organization or application developer because an outside vendor determines the availability of support based on market forces.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Software obsolescence risk assessment approach using multicriteria decision‐making

Bowlds

Fossaceca

Iammartino

2018

Systems Engineering

View full text Add to dashboard Cite

System obsolescence issues are a routine occurrence, especially for systems with a high utilization of commercial electronic components or software applications with a long operational life. The extended length of a system's development can often result in obsolescence well before system production and fielding begins. Obsolescence affects individual electronic components and availability of materials, as well as access to experienced personnel, processes, and software. Legacy application software obsolescence is influenced by multiple factors. Included in these factors are hardware obsolescence, increased software maintenance, commercial off‐the‐shelf software obsolescence, growth in technical debt, growth in complexity, and a lack of embedded business rule documentation. These criteria influence subjective management decisions in the remediation of current or future obsolescence risk. A multicriteria decision‐making (MCDM) approach is proposed to evaluate the impact of multiple obsolescence elements over the life cycle of a software application with consideration for the knowledge, preference, and subjectivity of experts to better inform the risk assessment and timing of future mitigation strategies. The resulting MCDM score provides a break point for a quantifiable increase in obsolescence risk.

show abstract

The Nature of Technical Debt in the Development of Descriptive Models for MBSE

Noguchi

2024

INCOSE International Symp

View full text Add to dashboard Cite

Model‐Based Systems Engineering (MBSE) is the growing practice of systems engineering (SE) in which descriptive models replace documents as the embodiment of SE knowledge. These descriptive models capture SE information in place of documents, are developed in a similar manner to software source code, and are encoded and used in machine‐to‐machine applications as data. This paper describes how the Technical Debt concept widely used in the software domain—rework deferred to the future for expediency—needs to be modified for the domain of descriptive models. Technical Debt is often associated with agile development practices of software or descriptive models, which emphasize the rapid creation and iterative evolution of a Minimum Viable Product (MVP). Consciously applying appropriate modeling principles and practices is essential to make informed decisions during the modeling process to prevent the accumulation of excessive model Technical Debt—particularly during this iterative evolutionary process—which can require substantial rework to correct. The paper establishes a foundation for characterizing the Technical Debt implications of key model architecture and implementation decisions that are made explicitly or implicitly by modelers when developing descriptive models. To illustrate the model Technical Debt concept, several examples of modeling principles pertaining to model purpose and implementation are described along with their implications on model Technical Debt.

show abstract

Estimating the breaking point for technical debt

Cited by 40 publications

References 13 publications

A framework for managing interest in technical debt

A framework for managing interest in technical debt

Software obsolescence risk assessment approach using multicriteria decision‐making

The Nature of Technical Debt in the Development of Descriptive Models for MBSE

Contact Info

Product

Resources

About