Methods and Tools for TD Estimation and Forecasting: A State-of-the-art Survey
---
paper_title: Measuring and Monitoring Technical Debt

paper_content:

Abstract Technical debt is a metaphor for immature, incomplete, or inadequate artifacts in the software development lifecycle that cause higher costs and lower quality in the long run. These artifacts remaining in a system affect subsequent development and maintenance activities, and so can be seen as a type of debt that the system developers owe the system. Incurring technical debt may speed up software development in the short run, but such benefit is achieved at the cost of extra work in the future, as if paying interest on the debt. In this sense, the technical debt metaphor characterizes the relationship between the short-term benefits of delaying certain software maintenance tasks or doing them quickly and less carefully, and the long-term cost of those delays. However, managing technical debt is more complicated than managing financial debt because of the uncertainty involved. In this chapter, the authors review the main issues associated with technical debt, and propose a technical debt management framework and a research plan for validation. The objective of our research agenda is to develop and validate a comprehensive technical debt theory that formalizes the relationship between the cost and benefit sides of the concept. Further, we propose to use the theory to propose mechanisms (processes and tools) for measuring and managing technical debt in software product maintenance. The theory and management mechanisms are intended ultimately to contribute to the improved quality of software and facilitate decision making in software maintenance.
---
paper_title: Comparing and experimenting machine learning techniques for code smell detection

paper_content:

Several code smell detection tools have been developed providing different results, because smells can be subjectively interpreted, and hence detected, in different ways. In this paper, we perform the largest experiment of applying machine learning algorithms to code smells to the best of our knowledge. We experiment 16 different machine-learning algorithms on four code smells (Data Class, Large Class, Feature Envy, Long Method) and 74 software systems, with 1986 manually validated code smell samples. We found that all algorithms achieved high performances in the cross-validation data set, yet the highest performances were obtained by J48 and Random Forest, while the worst performance were achieved by support vector machines. However, the lower prevalence of code smells, i.e., imbalanced data, in the entire data set caused varying performances that need to be addressed in the future studies. We conclude that the application of machine learning to the detection of these code smells can provide high accuracy (>96 %), and only a hundred training examples are needed to reach at least 95 % accuracy.
---
paper_title: A systematic mapping study on technical debt and its management

paper_content:

A systematic mapping study on technical debt and its management.Ninety-four papers are finally selected for data extraction and analysis.Technical debt was classified into 10 types.Eight activities of and 29 tools for technical debt management were identified.Code-related technical debt has gained the most attention. ContextTechnical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. ObjectiveThis work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. MethodA systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. ResultsNinety-four studies were finally selected. TD was classified into 10 types, 8 TDM activities were identified, and 29 tools for TDM were collected. ConclusionsThe term "debt" has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
---
paper_title: Managing technical debt in software-reliant systems

paper_content:

Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of short-term expedients. The technical debt metaphor is gaining significant traction in the agile development community as a way to understand and communicate such issues. The idea is that developers sometimes accept compromises in a system in one dimension (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises incur a "debt": on which "interest" has to be paid and which the "principal" should be repaid at some point for the long-term health of the project. We argue that the software engineering research community has an opportunity to study and improve this concept. We can offer software engineers a foundation for managing such trade-offs based on models of their economic impacts. Therefore, we propose managing technical debt as a part of the future research agenda for the software engineering field.
---
paper_title: Managing Technical Debt with the SQALE Method

paper_content:

To date, several methods are available for estimating the technical debt present in an application's source code. The SQALE (software quality assessment based on life-cycle expectations) method provides guidance for managing this debt. This article provides some implementation recommendations the authors learned from coaching and assisting large organizations in setting up and using SQALE.
---
paper_title: Technical Debt: From Metaphor to Theory and Practice

paper_content:

The metaphor of technical debt in software development was introduced two decades ago to explain to nontechnical stakeholders the need for what we call now "refactoring." As the term is being used to describe a wide range of phenomena, this paper proposes an organization of the technical debt landscape, and introduces the papers on technical debt contained in the issue.
---
paper_title: Refactoring for Software Design Smells: Managing Technical Debt

paper_content:

Awareness of design smells - indicators of common design problems - helps developers or software engineers understand mistakes made while designing, what design principles were overlooked or misapplied, and what principles need to be applied properly to address those smells through refactoring. Developers and software engineers may "know" principles and patterns, but are not aware of the "smells" that exist in their design because of wrong or mis-application of principles or patterns. These smells tend to contribute heavily to technical debt - further time owed to fix projects thought to be complete - and need to be addressed via proper refactoring. Refactoring for Software Design Smells presents 25 structural design smells, their role in identifying design issues, and potential refactoring solutions. Organized across common areas of software design, each smell is presented with diagrams and examples illustrating the poor design practices and the problems that result, creating a catalog of nuggets of readily usable information that developers or engineers can apply in their projects. The authors distill their research and experience as consultants and trainers, providing insights that have been used to improve refactoring and reduce the time and costs of managing software projects. Along the way they recount anecdotes from actual projects on which the relevant smell helped address a design issue. Contains a comprehensive catalog of 25 structural design smells (organized around four fundamental design principles) that contribute to technical debt in software projects Presents a unique naming scheme for smells that helps understand the cause of a smell as well as points toward its potential refactoring Includes illustrative examples that showcase the poor design practices underlying a smell and the problems that result Covers pragmatic techniques for refactoring design smells to manage technical debt and to create and maintain high-quality software in practice Presents insightful anecdotes and case studies drawn from the trenches of real-world projects
---
paper_title: Forecasting Java Software Evolution Trends Employing Network Models

paper_content:

The evolution of networks representing systems in various domains, including social networks, has been extensively studied enabling the development of growth models which govern their behavior over time. The architecture of software systems can also be naturally represented in the form of networks, whose properties change as software evolves. In this paper we attempt to model several aspects of graphs representing object-oriented software systems as they evolve over a number of versions. The goal is to develop a prediction model by considering global phenomena such as preferential attachment, past evolutionary trends such as the tendency of classes to create fewer relations as they age, as well as domain knowledge in terms of principles that have to be followed in object-oriented design. The derived models can provide insight into the future trends of software and potentially form the basis for eliciting improved or novel laws of software evolution. The forecasting power of the proposed model is evaluated against the actual evolution of 10 open-source projects and the achieved accuracy in the prediction of several network and software properties, which reflect the underlying system design, appears to be promising.
---
paper_title: A framework for managing interest in technical debt: an industrial validation

paper_content:

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.
---
paper_title: A portfolio approach to technical debt management

paper_content:

Technical debt describes the effect of immature software artifacts on software maintenance - the potential of extra effort required in future as if paying interest for the incurred debt. The uncertainty of interest payment further complicates the problem of what debt should be incurred or repaid and when. To help software managers make informed decisions, a portfolio approach is proposed in this paper. The approach leverages the portfolio management theory in the finance domain to determine the optimal collection of technical debt items that should be incurred or held. We expect this approach could provide a new perspective for technical debt management.
---
paper_title: Managing Technical Debt in Software Engineering (Dagstuhl Seminar 16162)

paper_content:

This report documents the program and outcomes of Dagstuhl Seminar 16162, “Managing Technical Debt in Software Engineering.” We summarize the goals and format of the seminar, results from the breakout groups, a definition for technical debt, a draft conceptual model, and a research road map that culminated from the discussions during the seminar. The report also includes the abstracts of the talks presented at the seminar and summaries of open discussions.
---
paper_title: Prioritizing design debt investment opportunities

paper_content:

Technical debt is the technical work developers owe a system, typically caused by speeding up development, e.g. before a software release. Approaches, such as code smell detection, have been developed to identify particular kinds of debt, e.g. design debt. Up until now, code smell detection has been used to help point to components that need to be freed from debt by refactoring. To date, a number of methods have been described for finding code smells in a system. However, typical debt properties, such as the value of the debt and interest rate to be paid, have not been well established. This position paper proposes an approach to using cost/benefit analysis to prioritize technical debt reduction work by ranking the value and interest of design debt caused by god classes. The method is based on metric analysis and software repository mining and is demonstrated on a commercial software application at a mid-size development company. The results are promising: the method helps to identify which refactoring activities should be performed first because they are likely to be cheap to make yet have significant effect, and which refactorings should be postponed due to high cost and low payoff.
---
paper_title: A systematic mapping study on technical debt and its management

paper_content:

A systematic mapping study on technical debt and its management.Ninety-four papers are finally selected for data extraction and analysis.Technical debt was classified into 10 types.Eight activities of and 29 tools for technical debt management were identified.Code-related technical debt has gained the most attention. ContextTechnical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. ObjectiveThis work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. MethodA systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. ResultsNinety-four studies were finally selected. TD was classified into 10 types, 8 TDM activities were identified, and 29 tools for TDM were collected. ConclusionsThe term "debt" has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
---
paper_title: Technical Debt: From Metaphor to Theory and Practice

paper_content:

The metaphor of technical debt in software development was introduced two decades ago to explain to nontechnical stakeholders the need for what we call now "refactoring." As the term is being used to describe a wide range of phenomena, this paper proposes an organization of the technical debt landscape, and introduces the papers on technical debt contained in the issue.
---
paper_title: Estimating the breaking point for technical debt

paper_content:

In classic economics, when borrowing an amount of money that causes a debt to the issuer, it is not usual to have interest which can become larger than the principal. In the context of technical debt however, accumulated debt in the form of interest can in some cases quickly sum up to an amount that at some point, becomes larger than the effort required to repay the initial amount of technical debt. In this paper we propose an approach for estimating this breaking point. Anticipating how late the breaking point is expected to come can support decision making with respect to investments on improving quality. The approach is based on a search-based optimization tool that is capable of identifying the distance of an actual object-oriented design to the corresponding optimum one.
---
paper_title: An Analysis of Techniques and Methods for Technical Debt Management: A Reflection from the Architecture Perspective

paper_content:

Technical debt is a metaphor referring to the consequences of weak software development. Managing technical debt is necessary in order to keep it under control, and several techniques have been developed with the goal of accomplishing this. However, available techniques have grown disperse and managers lack guidance. This paper covers this gap by providing a systematic mapping of available techniques and methods for technical debt management, covering architectural debt, and identifying existing gaps that prevent to manage technical debt efficiently.
---
paper_title: Using technical debt data in decision making: Potential decision approaches

paper_content:

The management of technical debt ultimately requires decision making -- about incurring, paying off, or deferring technical debt instances. This position paper discusses several existing approaches to complex decision making, and suggests that exploring their applicability to technical debt decision making would be a worthwhile subject for further research.
---
paper_title: A systematic mapping study on technical debt and its management

paper_content:

A systematic mapping study on technical debt and its management.Ninety-four papers are finally selected for data extraction and analysis.Technical debt was classified into 10 types.Eight activities of and 29 tools for technical debt management were identified.Code-related technical debt has gained the most attention. ContextTechnical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. ObjectiveThis work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. MethodA systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. ResultsNinety-four studies were finally selected. TD was classified into 10 types, 8 TDM activities were identified, and 29 tools for TDM were collected. ConclusionsThe term "debt" has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
---
paper_title: Managing technical debt in software-reliant systems

paper_content:

Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of short-term expedients. The technical debt metaphor is gaining significant traction in the agile development community as a way to understand and communicate such issues. The idea is that developers sometimes accept compromises in a system in one dimension (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises incur a "debt": on which "interest" has to be paid and which the "principal" should be repaid at some point for the long-term health of the project. We argue that the software engineering research community has an opportunity to study and improve this concept. We can offer software engineers a foundation for managing such trade-offs based on models of their economic impacts. Therefore, we propose managing technical debt as a part of the future research agenda for the software engineering field.
---
paper_title: Estimating the size, cost, and types of technical debt

paper_content:

This study summarizes results of a study of Technical Debt across 745 business applications comprising 365 million lines of code collected from 160 companies in 10 industry segments. These applications were submitted to a static analysis that evaluates quality within and across application layers that may be coded in different languages. The analysis consists of evaluating the application against a repository of over 1200 rules of good architectural and coding practice. A formula for estimating Technical Debt with adjustable parameters is presented. Results are presented for Technical Debt across the entire sample as well as for different programming languages and quality factors.
---
paper_title: A portfolio approach to technical debt management

paper_content:

Technical debt describes the effect of immature software artifacts on software maintenance - the potential of extra effort required in future as if paying interest for the incurred debt. The uncertainty of interest payment further complicates the problem of what debt should be incurred or repaid and when. To help software managers make informed decisions, a portfolio approach is proposed in this paper. The approach leverages the portfolio management theory in the finance domain to determine the optimal collection of technical debt items that should be incurred or held. We expect this approach could provide a new perspective for technical debt management.
---
paper_title: DebtFlag: technical debt management with a development environment integrated tool

paper_content:

In this paper, we introduce the DebtFlag tool for capturing, tracking and resolving technical debt in software projects. DebtFlag integrates into the development environment and provides developers with lightweight documentation tools to capture technical debt and link them to corresponding parts in the implementation. During continued development these links are used to create propagation paths for the documented debt. This allows for an up-to-date and accurate presentation of technical debt to be upheld, which enables developer conducted implementation-level micromanagement as well as higher level technical debt management.
---
paper_title: CloudMTD: Using real options to manage technical debt in cloud-based service selection

paper_content:

In cloud marketplace, cloud-based system architectures can be composed of web services, which are leased or bought off the cloud. These architectures can add value to its composition by switching and substituting its constituent services. The value-added can relate to improved Quality of Service (QoS), new revenue streams by enabling new business models, reduced operational cost and so forth. The selection and substitution decisions may introduce a technical debt, however. We specifically look at the debt of substitution decisions in support for scaling up scenarios. This debt may need to be managed, cleared and transformed to value-added. We take an option-based approach to inform the selection of candidate web services with varying debt. For every selection, we quantify the extent to which it can clear the debt and provide future options.
---
paper_title: Estimating the Principal of an Application's Technical Debt

paper_content:

This article characterizes technical debt across 700 business applications, comprising 357 MLOC. These applications were analyzed against more than 1,200 rules of good architectural and coding practice. The authors present a formula with adjustable parameters for estimating the principal of technical debt from structural quality data.
---
paper_title: What is the value of your software?

paper_content:

Assessment of the economic value of software systems is useful in contexts such as capitalization on the balance sheet and due diligence prior to acquisition. Current accounting practice in determining software value is based on the cost spent in software development. This approach fails to account for the efficiency with which software has been produced or the quality of the product. This paper proposes three alternative models for determining the production value of software, based on the notions of technical debt and interest. We applied the models to 367 proprietary systems developed by a range of different organisations using a range of different programming languages. We present the valuation results and discuss the weaknesses and strengths of the models.
---
paper_title: Assessing technical debt by identifying design flaws in software systems

paper_content:

Tough time-to-market constraints and unanticipated integration or evolution issues lead to design tradeoffs that usually cause flaws in the structure of a software system. Thus, maintenance costs grow significantly. The impact of these design decisions, which provide short-term benefits at the expense of the system's design integrity, is usually referred to as technical debt. In this paper, I propose a novel framework for assessing technical debt using a technique for detecting design flaws, i.e., specific violations of well-established design principles and rules. To make the framework comprehensive and balanced, it is built on top of a set of metrics-based detection rules for well-known design flaws that cover all of the major aspects of design such as coupling, complexity, and encapsulation. I demonstrate the effectiveness of the framework by assessing the evolution of technical debt symptoms over a total of 63 releases of two popular Eclipse® projects. The case study shows how the framework can detect debt symptoms and past refactoring actions. The experiment also reveals that in the absence of such a framework, restructuring actions are not always coherent and systematic, not even when performed by very experienced developers.
---
paper_title: Monitoring code quality and development activity by software maps

paper_content:

Software development projects are difficult to manage, in general, due to the friction between completing system features and, at the same time, obtaining a high degree of code quality to ensure maintainability of the system in the future. A major challenge of this optimization problem is that code quality is less visible to stakeholders in the development process, particularly, to the management. In this paper, we describe an approach for automated software analysis and monitoring of both quality-related code metrics and development activities by means of software maps. A software map represents an adaptive, hierarchical representation of software implementation artifacts such as source code files being organized in a modular hierarchy. The maps can express and combine information about software development, software quality, and system dynamics; they can systematically be specified, automatically generated, and organized by templates. The maps aim at supporting decision-making processes. For example, they facilitate to decide where in the code an increase of quality would be beneficial both for speeding up current development activities and for reducing risks of future maintenance problems. Due to their high degree of expressiveness and their instantaneous generation, the maps additionally serve as up-to-date information tools, bridging an essential information gap between management and development, improve awareness, and serve as early risk detection instrument. The software map concept and its tool implementation are evaluated by means of two case studies on large industrially developed software systems.
---
paper_title: An empirical model of technical debt and interest

paper_content:

Cunningham introduced the metaphor of technical debt as guidance for software developers that must trade engineering quality against short-term goals. We revisit the technical debt metaphor, and translate it into terms that can help IT executives better understand their IT investments. An approach is proposed to quantify debts (cost to fix technical quality issues) and interest (extra cost spent on maintenance due to technical quality issues). Our approach is based on an empirical assessment method of software quality developed at the Software Improvement Group (SIG). The core part of the technical debt calculation is constructed on the basis of empirical data of 44 systems that are currently being monitored by SIG. In a case study, we apply the approach to a real system, and discuss how the results provide useful insights on important questions related to IT investment such as the return on investment (ROI) in software quality improvement.
---
paper_title: In Search of a Metric for Managing Architectural Technical Debt

paper_content:

Practices designed to expedite the delivery of stakeholder value can paradoxically lead to unexpected rework costs that ultimately degrade the flow of value over time. This is especially observable when features are developed based on immediate value, while dependencies that may slow down future development efforts are neglected. The technical debt metaphor conceptualizes this tradeoff between short-term and long-term value: taking shortcuts to optimize the delivery of features in the short term incurs debt, analogous to financial debt, that must be paid off later to optimize long-term success. In this paper, we describe taking an architecture-focused and measurement-based approach to develop a metric that assists in strategically managing technical debt. Such an approach can be used to optimize the cost of development over time while continuing to deliver value to the customer. We demonstrate our approach by describing its application to an ongoing system development effort.
---
paper_title: The SQALE method for evaluating Technical Debt

paper_content:

This paper presents the SQALE (Software Quality Assessment Based on Lifecycle Expectations) method. We describe its Quality Model and Analysis Model which is used to estimate the Quality and the Technical Debt of an application source code. We provide recommendations and guidelines for using the SQALE indicators in order to analyse the structure and the impact of the Technical Debt.
---
paper_title: An Open Tool for Assisting in Technical Debt Management

paper_content:

Technical debt monitoring is one of the activities that have to be performed in technical debt management. To do that, there are different techniques that can be used to estimate technical debt and different tools that implement those different techniques. This paper presents TEDMA Tool, a tool for monitoring technical debt over the software evolution and that it is open to integrate third party tools. TEDMA is based on the analysis of source code repositories and is useful for researching using empirical data extracted from software projects. Currently, it is been used to analyze big projects in the execution of several case studies. The expected evolution of TEDMA will make the tool useful for software development industry.
---
paper_title: Predicting and quantifying the technical debt in cloud software engineering

paper_content:

Identifying and managing effectively the Technical Debt has become an issue of great importance over recent years. In cloud marketplaces, where the cloud services can be leased, the difficulty to promptly predict and manage the Technical Debt has a significant impact. In this paper, we examine the Technical Debt, which stems from budget constraints during the software development process as well as the capacity of a cloud service. In this context, the budget and the cloud service selection decisions may introduce Technical Debt. Towards reaching a conclusion, two approaches are taken into consideration. Initially, a cost estimation approach is researched, which is related to implementing Software as a Service (SaaS) in the cloud for three scenarios aiming to predict the incurrence of the Technical Debt in the future. The Constructive Cost Model (COCOMO) is exploited, in order to estimate the implementation cost and define a range of secureness. In addition, a Technical Debt quantification approach is adopted, which is associated with leasing a cloud Software as a Service (SaaS), towards indicating the most appropriate cloud service to be selected.
---
paper_title: A framework for managing interest in technical debt: an industrial validation

paper_content:

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.
---
paper_title: Is complexity really the enemy of software security?

paper_content:

Software complexity is often hypothesized to be the enemy of software security. We performed statistical analysis on nine code complexity metrics from the JavaScript Engine in the Mozilla application framework to investigate if this hypothesis is true. Our initial results show that the nine complexity measures have weak correlation (ρ=0.30 at best) with security problems for Mozilla JavaScript Engine. The study should be replicated on more products with design and code-level metrics. It may be necessary to create new complexity metrics to embody the type of complexity that leads to security problems.
---
paper_title: A Bayesian Network Approach to Assess and Predict Software Quality Using Activity-Based Quality Models

paper_content:

Context: Software quality is a complex concept. Therefore, assessing and predicting it is still challenging in practice as well as in research. Activity-based quality models break down this complex concept into concrete definitions, more precisely facts about the system, process, and environment as well as their impact on activities performed on and with the system. However, these models lack an operationalisation that would allow them to be used in assessment and prediction of quality. Bayesian networks have been shown to be a viable means for this task incorporating variables with uncertainty. Objective: The qualitative knowledge contained in activity-based quality models are an abundant basis for building Bayesian networks for quality assessment. This paper describes a four-step approach for deriving systematically a Bayesian network from an assessment goal and a quality model. Method: The four steps of the approach are explained in detail and with running examples. Furthermore, an initial evaluation is performed, in which data from NASA projects and an open source system is obtained. The approach is applied to this data and its applicability is analysed. Results: The approach is applicable to the data from the NASA projects and the open source system. However, the predictive results vary depending on the availability and quality of the data, especially the underlying general distributions. Conclusion: The approach is viable in a realistic context but needs further investigation in case studies in order to analyse its predictive validity.
---
paper_title: Operationalised product quality models and assessment: The Quamoco approach

paper_content:

ContextSoftware quality models provide either abstract quality characteristics or concrete quality measurements; there is no seamless integration of these two aspects. Quality assessment approaches are, hence, also very specific or remain abstract. Reasons for this include the complexity of quality and the various quality profiles in different domains which make it difficult to build operationalised quality models. ObjectiveIn the project Quamoco, we developed a comprehensive approach aimed at closing this gap. MethodThe project combined constructive research, which involved a broad range of quality experts from academia and industry in workshops, sprint work and reviews, with empirical studies. All deliverables within the project were peer-reviewed by two project members from a different area. Most deliverables were developed in two or three iterations and underwent an evaluation. ResultsWe contribute a comprehensive quality modelling and assessment approach: (1) A meta quality model defines the structure of operationalised quality models. It includes the concept of a product factor, which bridges the gap between concrete measurements and abstract quality aspects, and allows modularisation to create modules for specific domains. (2) A largely technology-independent base quality model reduces the effort and complexity of building quality models for specific domains. For Java and C# systems, we refined it with about 300 concrete product factors and 500 measures. (3) A concrete and comprehensive quality assessment approach makes use of the concepts in the meta-model. (4) An empirical evaluation of the above results using real-world software systems showed: (a) The assessment results using the base model largely match the expectations of experts for the corresponding systems. (b) The approach and models are well understood by practitioners and considered to be both consistent and well suited for getting an overall view on the quality of a software product. The validity of the base quality model could not be shown conclusively, however. (5) The extensive, open-source tool support is in a mature state. (6) The model for embedded software systems is a proof-of-concept for domain-specific quality models. ConclusionWe provide a broad basis for the development and application of quality models in industrial practice as well as a basis for further extension, validation and comparison with other approaches in research.
---
paper_title: Software Engineering Economics

paper_content:

This paper summarizes the current state of the art and recent trends in software engineering economics. It provides an overview of economic analysis techniques and their applicability to software engineering and management. It surveys the field of software cost estimation, including the major estimation techniques available, the state of the art in algorithmic cost models, and the outstanding research issues in software cost estimation.
---
paper_title: A Financial Approach for Managing Interest in Technical Debt

paper_content:

Technical debt (TD) is a metaphor that is used by both technical and management stakeholders to acknowledge and discuss issues related to compromised design-time qualities. Until now, despite the inherent relevance of technical debt to economics, the TD community has not sufficiently exploited economic methods/models. In this paper we present a framework for managing interest in technical debt, founded on top of Liquidity Preference, a well-known economics theory. To tailor this theory to fit the TD context, we exploit the synthesized knowledge as presented in two recent studies. Specifically, in our framework, we discuss aspects related to technical debt interest, such as: types of TD interest, TD interest characteristics, and a proposed TD interest theory. Finally, to boost the amount of empirical studies in TD research, we propose several tentative research designs that could be used for exploring the notion of interest in technical debt practice.
---
paper_title: Comparing and experimenting machine learning techniques for code smell detection

paper_content:

Several code smell detection tools have been developed providing different results, because smells can be subjectively interpreted, and hence detected, in different ways. In this paper, we perform the largest experiment of applying machine learning algorithms to code smells to the best of our knowledge. We experiment 16 different machine-learning algorithms on four code smells (Data Class, Large Class, Feature Envy, Long Method) and 74 software systems, with 1986 manually validated code smell samples. We found that all algorithms achieved high performances in the cross-validation data set, yet the highest performances were obtained by J48 and Random Forest, while the worst performance were achieved by support vector machines. However, the lower prevalence of code smells, i.e., imbalanced data, in the entire data set caused varying performances that need to be addressed in the future studies. We conclude that the application of machine learning to the detection of these code smells can provide high accuracy (>96 %), and only a hundred training examples are needed to reach at least 95 % accuracy.
---
paper_title: Programs, life cycles, and laws of software evolution

paper_content:

By classifying programs according to their relationship to the environment in which they are executed, the paper identifies the sources of evolutionary pressure on computer applications and programs and shows why this results in a process of never ending maintenance activity. The resultant life cycle processes are then briefly discussed. The paper then introduces laws of Program Evolution that have been formulated following quantitative studies of the evolution of a number of different systems. Finally an example is provided of the application of Evolution Dynamics models to program release planning.
---
paper_title: Measuring, analyzing and predicting security vulnerabilities in software systems

paper_content:

In this work we examine the feasibility of quantitatively characterizing some aspects of security. In particular, we investigate if it is possible to predict the number of vulnerabilities that can potentially be present in a software system but may not have been found yet. We use several major operating systems as representatives of complex software systems. The data on vulnerabilities discovered in these systems are analyzed. We examine the results to determine if the density of vulnerabilities in a program is a useful measure. We also address the question about what fraction of software defects are security related, i.e., are vulnerabilities. We examine the dynamics of vulnerability discovery hypothesizing that it may lead us to an estimate of the magnitude of the undiscovered vulnerabilities still present in the system. We consider the vulnerability discovery rate to see if models can be developed to project future trends. Finally, we use the data for both commercial and open-source systems to determine whether the key observations are generally applicable. Our results indicate that the values of vulnerability densities fall within a range of values, just like the commonly used measure of defect density for general defects. Our examination also reveals that it is possible to model the vulnerability discovery using a logistic model that can sometimes be approximated by a linear model.
---
paper_title: A Validation of Object-Oriented Design Metrics as Quality Indicators

paper_content:

This paper presents the results of a study in which we empirically investigated the suite of object-oriented (OO) design metrics introduced in (Chidamber and Kemerer, 1994). More specifically, our goal is to assess these metrics as predictors of fault-prone classes and, therefore, determine whether they can be used as early quality indicators. This study is complementary to the work described in (Li and Henry, 1993) where the same suite of metrics had been used to assess frequencies of maintenance changes to classes. To perform our validation accurately, we collected data on the development of eight medium-sized information management systems based on identical requirements. All eight projects were developed using a sequential life cycle model, a well-known OO analysis/design method and the C++ programming language. Based on empirical and quantitative analysis, the advantages and drawbacks of these OO metrics are discussed. Several of Chidamber and Kemerer's OO metrics appear to be useful to predict class fault-proneness during the early phases of the life-cycle. Also, on our data set, they are better predictors than "traditional" code metrics, which can only be collected at a later phase of the software development processes.
---
paper_title: A Preliminary Study on the Relationship Among Software Metrics and Specific Vulnerability Types

paper_content:

Several studies have highlighted the ability of software metrics to predict vulnerabilities. However, limited attention has been given on the capacity of software metrics to discriminate between different types of vulnerabilities, while the existence of potential interdependencies among different vulnerability types has not been studied yet. For this purpose, an empirical study was conducted based on 100 widely-used Java libraries. A wide range of software metrics were calculated for each project of the code base, along with the densities of a carefully selected set of vulnerability categories, which were quantified through static analysis. Correlation analysis was employed in order to find statistically significant relationships. The preliminary results suggest that: (i) software metrics may not be sufficient indicators of specific vulnerability types, (ii) software metrics are more capable of discriminating between security-specific and quality-specific weaknesses, than between specific vulnerability types, (iii) previously uninvestigated metrics may be good indicators of security issues, and (iv) important interdependencies may exist among security-specific issues. To the best of our knowledge, this is the largest study in terms of code base size, while it is the first attempt for finding interdependencies among different vulnerability types.
---
paper_title: The Evolution of Technical Debt in the Apache Ecosystem

paper_content:

Software systems must evolve over time or become increasingly irrelevant says one of Lehman’s laws of software evolution. Many studies have been presented in the literature that investigate the evolution of software systems but few have focused on the evolution of technical debt. In this paper we study sixty-six Java open-source software projects from the Apache ecosystem focusing on the evolution of technical debt. We analyze the evolution of these systems over the past five years at the temporal granularity level of weekly snapshots. We calculate the trends of the technical debt time series but we also investigate the lower-level constituent components of this technical debt. We aggregate some of the information to the ecosystem level.
---
paper_title: Examining the relationship between firm's financial records and security vulnerabilities

paper_content:

We examine the correlation between firms financial records and vulnerabilities.Financial records are significantly associated with the number of vulnerabilities.There is positive correlation between vulnerabilities and firms size and performance.Vulnerabilities and marketing expenditure are positively correlated.Vulnerabilities and R&D expenditure are negatively correlated. Security vulnerabilities and breaches remain a major concern for firms as they cost billions of dollars in downtime, maintenance and disruptions. Although researchers in the fields of security and vulnerability prediction have made significant contributions, the number of vulnerabilities continues to increase. Contrary to existing vulnerability studies, this research examines vulnerabilities from a financial perspective. We explore whether firms financial records are associated with vulnerabilities. In particular, we examine the correlation between the number of vulnerabilities and each of firms size, financial performance, marketing and sales, and research and development expenditures. The empirical analysis of this study is based on data collected from 89 publicly traded technology firms over a 10-year period. Our results reveal that financial records are significantly associated with vulnerabilities. More specifically, our results show that as technology firms increase their marketing and sales expenditures, the number of vulnerabilities increases as well. Interestingly, the analysis shows that firms can counter this rise by increasing their spending on research and development. We also find a positive correlation between the number of vulnerabilities and each of firms size and performance.
---
paper_title: Software evolution: analysis and visualization

paper_content:

Gaining higher level evolutionary information about large software systems is a key challenge in dealing with increasing complexity and decreasing software quality. Software repositories such as modifications, changes, or release information are rich sources for distinctive kinds of analyses: They reflect the reasons and effects of particular changes made to the software system over a certain period of time. If we can analyze these repositories in an effective way, we get a clearer picture of the status of the software. Software repositories can be analyzed to provide information about the problems concerning a particular feature or a set of features. Hidden dependencies of structurally unrelated but over time logically coupled files exhibit a high potential to illustrate software evolution and possible architectural deterioration. In this tutorial, we describe the investigation of software evolution by taking a step towards reflecting the analysis results against software quality attributes. Different kinds of analyses (from architecture to code) and their interpretation will be presented and discussed in relation to quality attributes. This will show our vision of where such evolution investigations can lead and how they can support development. For that, the tutorial will touch issues such as meta-models for evolution data, data analysis and history mining, software quality attributes, as well as visualization of analysis results.
---
paper_title: Modeling history to analyze software evolution

paper_content:

SUMMARY The histories of software systems hold useful information when reasoning about the systems at hand or when reasoning about general laws of software evolution. Over the past 30 years more and more research has been spent on understanding software evolution. However, the approaches developed so far do not rely on an explicit metamodel, and thus, they make it dicult to reuse or compare their results. We argue that there is a need for an explicit meta-model for software evolution analysis. We present a survey of the evolution analyses and deduce a set of requirements that an evolution meta-model should have. We define, Hismo, a meta-model in which history is modeled as an explicit entity. Hismo adds a time layer on top of structural information, and provides a common infrastructure for expressing and combining evolution analyses and structural analyses. We validate the usefulness of our a meta-model by presenting how dierent analyses are expressed on it.
---
paper_title: Forecasting Java Software Evolution Trends Employing Network Models

paper_content:

The evolution of networks representing systems in various domains, including social networks, has been extensively studied enabling the development of growth models which govern their behavior over time. The architecture of software systems can also be naturally represented in the form of networks, whose properties change as software evolves. In this paper we attempt to model several aspects of graphs representing object-oriented software systems as they evolve over a number of versions. The goal is to develop a prediction model by considering global phenomena such as preferential attachment, past evolutionary trends such as the tendency of classes to create fewer relations as they age, as well as domain knowledge in terms of principles that have to be followed in object-oriented design. The derived models can provide insight into the future trends of software and potentially form the basis for eliciting improved or novel laws of software evolution. The forecasting power of the proposed model is evaluated against the actual evolution of 10 open-source projects and the achieved accuracy in the prediction of several network and software properties, which reflect the underlying system design, appears to be promising.
---
paper_title: Predicting object-oriented software maintainability using multivariate adaptive regression splines

paper_content:

Accurate software metrics-based maintainability prediction can not only enable developers to better identify the determinants of software quality and thus help them improve design or coding, it can also provide managers with useful information to help them plan the use of valuable resources. In this paper, we employ a novel exploratory modeling technique, multiple adaptive regression splines (MARS), to build software maintainability prediction models using the metric data collected from two different object-oriented systems. The prediction accuracy of the MARS models are evaluated and compared using multivariate linear regression models, artificial neural network models, regression tree models, and support vector models. The results suggest that for one system MARS can predict maintainability more accurately than the other four typical modeling techniques, and that for the other system MARS is as accurate as the best modeling technique.
---
paper_title: SAVI: Static-Analysis Vulnerability Indicator

paper_content:

Open source software presents new opportunities for software acquisition but introduces risks. The selection of open source applications should take into account both features and security risks. Risks include security vulnerabilities, of which published vulnerabilities are only the tip of the iceberg. Having an application's source code lets us look deeper at its security. SAVI (Static-Analysis Vulnerability Indicator) is a metric for assessing risks of using software built by external developers. It combines several types of static-analysis data to rank application vulnerability.
---
paper_title: QATCH - An adaptive framework for software product quality assessment

paper_content:

Abstract The subjectivity that underlies the notion of quality does not allow the design and development of a universally accepted mechanism for software quality assessment. This is why contemporary research is now focused on seeking mechanisms able to produce software quality models that can be easily adjusted to custom user needs. In this context, we introduce QATCH, an integrated framework that applies static analysis to benchmark repositories in order to generate software quality models tailored to stakeholder specifications. Fuzzy multi-criteria decision-making is employed in order to model the uncertainty imposed by experts’ judgments. These judgments can be expressed into linguistic values, which makes the process more intuitive. Furthermore, a robust software quality model, the base model, is generated by the system, which is used in the experiments for QATCH system verification. The paper provides an extensive analysis of QATCH and thoroughly discusses its validity and added value in the field of software quality through a number of individual experiments.
---
paper_title: An application of bayesian network for predicting object-oriented software maintainability

paper_content:

As the number of object-oriented software systems increases, it becomes more important for organizations to maintain those systems effectively. However, currently only a small number of maintainability prediction models are available for object-oriented systems. This paper presents a Bayesian network maintainability prediction model for an object-oriented software system. The model is constructed using object-oriented metric data in Li and Henry's datasets, which were collected from two different object-oriented systems. Prediction accuracy of the model is evaluated and compared with commonly used regression-based models. The results suggest that the Bayesian network model can predict maintainability more accurately than the regression-based models for one system, and almost as accurately as the best regression-based model for the other system.
---
paper_title: Analysis and Prediction of Design Model Evolution Using Time Series

paper_content:

Tools which support Model-Driven Engineering have to be evaluated and tested. In the domain of model differencing and model versioning, sequences of software models (model histories), in which a model is obtained from its immediate predecessor by some modification, are of special interest. Unfortunately, in this application domain adequate real test models are scarcely available and must be artificially created. To this end, model generators were proposed in recent years. Generally, such model generators should be configured in a way that the generated sequences of models are as realistic as possible, i.e. they should mimic the changes that happen in real software models. Hence, it is a necessary prerequisite to analyze and to stochastically model the evolution (changes) of real software systems at the abstraction level of models. In this paper, we present a new approach to statistically analyze the evolution of models. Our approach uses time series as a statistical method to capture the dynamics of the evolution. We applied this approach to several typical projects and we successfully modeled their evolutions. The time series models could predict the future changes of the next revisions of the systems with good accuracies. The obtained time series models are used to create more realistic model histories for model versioning and model differencing tools.
---
paper_title: The past, present, and future of software evolution

paper_content:

Change is an essential characteristic of software development, as software systems must respond to evolving requirements, platforms, and other environmental pressures. In this paper, we discuss the concept of software evolution from several perspectives. We examine how it relates to and differs from software maintenance. We discuss insights about software evolution arising from Lehmanpsilas laws of software evolution and the staged lifecycle model of Bennett and Rajlich. We compare software evolution to other kinds of evolution, from science and social sciences, and we examine the forces that shape change. Finally, we discuss the changing nature of software in general as it relates to evolution, and we propose open challenges and future directions for software evolution research.
---
paper_title: Comparing four approaches for technical debt identification

paper_content:

Software systems accumulate technical debt (TD) when short-term goals in software development are traded for long-term goals (e.g., quick-and-dirty implementation to reach a release date versus a well-refactored implementation that supports the long-term health of the project). Some forms of TD accumulate over time in the form of source code that is difficult to work with and exhibits a variety of anomalies. A number of source code analysis techniques and tools have been proposed to potentially identify the code-level debt accumulated in a system. What has not yet been studied is if using multiple tools to detect TD can lead to benefits, that is, if different tools will flag the same or different source code components. Further, these techniques also lack investigation into the symptoms of TD "interest" that they lead to. To address this latter question, we also investigated whether TD, as identified by the source code analysis techniques, correlates with interest payments in the form of increased defect- and change-proneness. Comparing the results of different TD identification approaches to understand their commonalities and differences and to evaluate their relationship to indicators of future TD "interest." We selected four different TD identification techniques (code smells, automatic static analysis issues, grime buildup, and Modularity violations) and applied them to 13 versions of the Apache Hadoop open source software project. We collected and aggregated statistical measures to investigate whether the different techniques identified TD indicators in the same or different classes and whether those classes in turn exhibited high interest (in the form of a large number of defects and higher change-proneness). The outputs of the four approaches have very little overlap and are therefore pointing to different problems in the source code. Dispersed Coupling and Modularity violations were co-located in classes with higher defect-proneness. We also observed a strong relationship between Modularity violations and change-proneness. Our main contribution is an initial overview of the TD landscape, showing that different TD techniques are loosely coupled and therefore indicate problems in different locations of the source code. Moreover, our proxy interest indicators (change- and defect-proneness) correlate with only a small subset of TD indicators.
---
paper_title: Identification and analysis of the elements required to manage technical debt by means of a systematic mapping study

paper_content:

Identification and classification of the elements to manage technical debt (TD).The classification resulted in a framework including the stakeholders interests.The industrial relevance of current support to elements was assessed.The framework is a basis for building TD decision-making models.It was found out that TD management decisions are context-dependent. Technical debt, a metaphor for the long-term consequences of weak software development, must be managed to keep it under control. The main goal of this article is to identify and analyze the elements required to manage technical debt. The research method used to identify the elements is a systematic mapping, including a synthesis step to synthesize the elements definitions. Our perspective differs from previous literature reviews because it focused on the elements required to manage technical debt and not on the phenomenon of technical debt or the activities used in performing technical debt management. Additionally, the rigor and relevance for industry of the current techniques used to manage technical debt are studied. The elements were classified into three groups (basic decision-making factors, cost estimation techniques, practices and techniques for decision-making) and mapped according three stakeholders' points of view (engineering, engineering management, and business-organizational management). The definitions, classification, and analysis of the elements provide a framework that can be deployed to help in the development of models that are adapted to the specific stakeholders' interests to assist the decision-making required in technical debt management and to assess existing models and methods. The analysis indicated that technical debt management is context dependent.
---
paper_title: Comparing and experimenting machine learning techniques for code smell detection

paper_content:

Several code smell detection tools have been developed providing different results, because smells can be subjectively interpreted, and hence detected, in different ways. In this paper, we perform the largest experiment of applying machine learning algorithms to code smells to the best of our knowledge. We experiment 16 different machine-learning algorithms on four code smells (Data Class, Large Class, Feature Envy, Long Method) and 74 software systems, with 1986 manually validated code smell samples. We found that all algorithms achieved high performances in the cross-validation data set, yet the highest performances were obtained by J48 and Random Forest, while the worst performance were achieved by support vector machines. However, the lower prevalence of code smells, i.e., imbalanced data, in the entire data set caused varying performances that need to be addressed in the future studies. We conclude that the application of machine learning to the detection of these code smells can provide high accuracy (>96 %), and only a hundred training examples are needed to reach at least 95 % accuracy.
---
paper_title: A systematic mapping study on technical debt and its management

paper_content:

A systematic mapping study on technical debt and its management.Ninety-four papers are finally selected for data extraction and analysis.Technical debt was classified into 10 types.Eight activities of and 29 tools for technical debt management were identified.Code-related technical debt has gained the most attention. ContextTechnical debt (TD) is a metaphor reflecting technical compromises that can yield short-term benefit but may hurt the long-term health of a software system. ObjectiveThis work aims at collecting studies on TD and TD management (TDM), and making a classification and thematic analysis on these studies, to obtain a comprehensive understanding on the TD concept and an overview on the current state of research on TDM. MethodA systematic mapping study was performed to identify and analyze research on TD and its management, covering publications between 1992 and 2013. ResultsNinety-four studies were finally selected. TD was classified into 10 types, 8 TDM activities were identified, and 29 tools for TDM were collected. ConclusionsThe term "debt" has been used in different ways by different people, which leads to ambiguous interpretation of the term. Code-related TD and its management have gained the most attention. There is a need for more empirical studies with high-quality evidence on the whole TDM process and on the application of specific TDM approaches in industrial settings. Moreover, dedicated TDM tools are needed for managing various types of TD in the whole TDM process.
---
paper_title: Managing Technical Debt with the SQALE Method

paper_content:

To date, several methods are available for estimating the technical debt present in an application's source code. The SQALE (software quality assessment based on life-cycle expectations) method provides guidance for managing this debt. This article provides some implementation recommendations the authors learned from coaching and assisting large organizations in setting up and using SQALE.
---
paper_title: Forecasting Java Software Evolution Trends Employing Network Models

paper_content:

The evolution of networks representing systems in various domains, including social networks, has been extensively studied enabling the development of growth models which govern their behavior over time. The architecture of software systems can also be naturally represented in the form of networks, whose properties change as software evolves. In this paper we attempt to model several aspects of graphs representing object-oriented software systems as they evolve over a number of versions. The goal is to develop a prediction model by considering global phenomena such as preferential attachment, past evolutionary trends such as the tendency of classes to create fewer relations as they age, as well as domain knowledge in terms of principles that have to be followed in object-oriented design. The derived models can provide insight into the future trends of software and potentially form the basis for eliciting improved or novel laws of software evolution. The forecasting power of the proposed model is evaluated against the actual evolution of 10 open-source projects and the achieved accuracy in the prediction of several network and software properties, which reflect the underlying system design, appears to be promising.
---
paper_title: Technical Debt Indexes Provided by Tools: A Preliminary Discussion

paper_content:

In software maintenance and evolution, it is important to assess both code and architecture in order to identify issues to be solved to improve software quality. Different tools provide some kind of index giving us an overall evaluation of a project to be used when managing its technical debt. In this paper, we outline how the indexes, that we call in general Technical Debt Indexes, provided by five different tools are computed. We describe their principal features and differences, what aspects they are missing, and we outline if (and how) the indexes take into account architectural problems that could have a major impact on the architectural debt. We show that the indexes rely on different information sources and measure different quantities.
---

Title: Methods and Tools for TD Estimation and Forecasting: A State-of-the-art Survey

Section 1: INTRODUCTION
Description 1: This section introduces the concept of Technical Debt (TD), its implications in software development, and the significance of Technical Debt Management (TDM). It also outlines the paper's structure and its objective to review TD estimation and forecasting methods.

Section 2: RELATED WORK
Description 2: This section reviews existing research on TD estimation methods and tools as well as forecasting methods and techniques, highlighting different approaches and key findings.

Section 3: OPEN ISSUES AND CONTRIBUTIONS
Description 3: This section identifies open issues and gaps in the current research on TD estimation and forecasting, also proposing potential future research directions and contributions to address these challenges.

Section 4: CONCLUSIONS AND FUTURE WORK
Description 4: This section summarizes the main findings of the survey, acknowledges the identified open issues, and provides an outlook on future research directions and potential developments in TD estimation and forecasting.