Search

TODO comments are widely used by developers to remind themselves or others about incomplete tasks. In other words, TODO comments are usually associated with temporary or suboptimal solutions. In practice, all the equivalent suboptimal implementations should be updated (e.g., adding TODOs) simultaneously. However, due to various reasons (e.g., time constraints or carelessness), developers may forget or even are unaware of adding TODO comments to all necessary places, which results in the TODO-missed methods. These "hidden" suboptimal implementations in TODO-missed methods may hurt the software quality and maintainability in the long-term. Therefore, in this article, we propose the novel task of TODO-missed methods detection and patching and develop a novel model, namely TODO-comment Patcher (TDPatcher), to automatically patch TODO comments to the TODO-missed methods in software projects. Our model has two main stages: offline learning and online inference. During the offline learning stage, TDPatcher employs the GraphCodeBERT and contrastive learning for encoding the TODO comment (natural language) and its suboptimal implementation (code fragment) into vector representations. For the online inference stage, we can identify the TODO-missed methods and further determine their patching position by leveraging the offline trained model. We built our dataset by collecting TODO-introduced methods from the top-10,000 Python GitHub repositories and evaluated TDPatcher on them. Extensive experimental results show the promising performance of our model over a set of benchmarks. We further conduct an in-the-wild evaluation that successfully detects 26 TODO-missed methods from 50 GitHub repositories. [ABSTRACT FROM AUTHOR]

Smart contract-based applications are executed in a blockchain environment, and they cannot directly access data from external systems, which is required for the service provision of these applications. Instead, smart contracts use agents known as blockchain oracles to collect and provide data feeds to the contracts. The functionality and compatibility with smart contract applications need to be considered when selecting the best-fit oracle platform. As the number of oracle alternatives and their features increases, the decision-making process becomes increasingly complex. Selecting the wrong or sub-optimal oracle is costly and may lead to severe security risks. This article provides a decision support model for the oracle selection problem. The model supports smart contract decision-makers in selecting a secure, cost-effective, and feasible oracle platform for their applications. We interviewed oracle co-founders and smart contracts experts to refine and validate the decision model. Two real-world smart contract application case studies were used to evaluate the model. Our model prioritises and suggests more than one possible oracle platform based on the developer's required criteria, security assessment and cost analysis. Moreover, this guided decision model serves to reveal issues that may go unnoticed if done haphazardly, reduce decision-making efforts and provide a cost-effective solution. [ABSTRACT FROM AUTHOR]

Technical Debt (TD) can be defined as any incomplete, immature, or inadequate artifact resulting from delayed activities or tasks that, if not resolved in a timely manner, may cause future problems. The objective of this article is to present a state of the art on TD, according to what has been reported in the last five years. To identify and interpret the results of the available research on TD on its management in the context of Software Engineering, a tertiary study was carried out under the approach of a mapping study, in which 19 secondary studies that included aspects related to TD were analyzed. A set of research questions were posed regarding types of TD, management activities, as well as human factors mentioned in the studies. The authors found areas of opportunity on the relationship between TD and human factors in topics such as morale, experience, human participation, and feelings. [ABSTRACT FROM AUTHOR]

Agile methodologies have emerged as transformative paradigms in the ever-evolving software development landscape, emphasizing iterative development, customer collaboration, and adaptability. As the scope and complexity of projects and organizations expand, applying agile principles within the context of Large-Scale Agile Development (LSAD) encounters distinctive challenges. The majority of challenges encountered in LSAD, technical and non-technical, are attributed to the accrual of social debt. However, a conspicuous gap remains in understanding and addressing social debt in LSAD. This study aims to fill this void by investigating social debt in LSAD through an in-depth industrial case study with a leading Nordic company specializing in telecommunications software and services and focusing on producing secure 5G network solutions. The study investigates the causes of LSAD's social debt and examines its impacts on secure 5G telecom software development. By addressing these objectives, this research sheds light on a critical aspect of LSAD's social debt, caused by 3C challenges(communication, coordination and collaboration), social confines challenges, community smells challenges, and organisational social challenges in the telecom sector that have been underrepresented in the existing literature. [ABSTRACT FROM AUTHOR]

Self-admitted technical debts (SATDs) refer to a solution in software development that selects suboptimal solutions to meet the current requirements and are intentionally introduced and documented by developers. SATDs in issue-tracking systems are a complement to those within source code comments. The effective identification of SATDs is crucial for software quality assurance and maintenance. Current studies focus on whether issue sections contain debt, but overlook specific SATD types. Meanwhile, they lack solutions for the challenge that SATD features are hard to learn due to the scarcity of instances containing SATDs. To address these problems, we propose a novel method, which is a weighted prompt tuning to identify SATDs, called WPTD. Specifically, WPTD employs a weighted prompt tuning to adapt the model with few-shot samples for insufficient training data. Moreover, to improve the performance of the model, WPTD constructs an SATD verbalizer by extracting keywords through mutual information and refining it with prior contextual information. Furthermore, it also improves SATD representation by extracting weights using the chi-square method and integrating them into the text. Finally, to reduce bias, WPTD computes the average score of results as final predicted distributions. We conduct comprehensive experiments on seven projects and the results show that our method significantly outperforms baseline approaches. In addition, we summarize the project-specific keywords, which can help developers better understand SATDs. [ABSTRACT FROM AUTHOR]

The winter storm of late 2022 caused difficulties for many US-based airlines, but none more so than Southwest Airlines. Like other airlines, Southwest canceled flights in the early stages of the storm. Their attempted recoveries failed due to procedural and technology issues. The airline was unable to cope with the magnitude of canceled flights, aircraft and crews in the wrong places, disrupted passenger plans, and luggage separated from its owners. Over the next several days, Southwest canceled tens of thousands of flights, called in thousands of additional staff to support manual operations, and flew a reduced schedule for a time before returning to normal operations. The case provides numerous scenarios for you to analyze and research, to strengthen your understanding of the underlying concepts. [ABSTRACT FROM AUTHOR]

Context. Technical debt (TD) prevention allows software practitioners to apply practices to avoid potential TD items in their projects. Aims. To uncover and prioritize, from the point of view of software practitioners, the practices that could be used to avoid TD items, the relations between these practices and the causes of TD, and the practice avoidance reasons (PARs) that could explain the failure to prevent TD. Method. We analyze data collected from six replications of a global industrial family of surveys on TD, totaling 653 answers. We also conducted a follow up survey to understand the importance level of analyzed data. Results. Most practitioners indicated that TD could be prevented, revealing 89 prevention practices and 23 PARs for explaining the failure to prevent TD. The article identifies statistically significant relationships between preventive practices and certain causes of TD. Further, it prioritizes the list of practices, PARs, and relationships regarding their level of importance for TD prevention based on the opinion of software practitioners. Conclusion. This work organizes TD prevention practices and PARs in a conceptual map and the relationships between practices and causes of TD in a Sankey diagram to help the visualization of the body of knowledge reported in this study. [ABSTRACT FROM AUTHOR]

Technical Debt Management (TDM) can suffer from unpredictability, communication gaps and the inaccessibility of relevant information, which hamper the effectiveness of its decision making. These issues can stem from division among decision-makers which takes root in unfair consequences of decisions among different decision-makers. One mitigation route is Skin in the Game thinking, which enforces transparency, fairness and shared responsibility during collective decision-making under uncertainty. This article illustrates characteristics which require Skin in the Game thinking in Technical Debt (TD) identification, measurement, prioritisation and monitoring. We point out crucial problems in TD monitoring rooted in asymmetric information and asymmetric payoff between different factions of decision-makers. A systematic TD monitoring method is presented to mitigate the said problems. The method leverages Replicator Dynamics and Behavioural Learning. The method supports decision-makers with automated TD monitoring decisions; it informs decision-makers when human interventions are required. Two publicly available industrial projects with a non-trivial number of TD and timestamps are utilised to evaluate the application of our method. Mann–Whitney U hypothesis tests are conducted on samples of decisions from our method and the baseline. The statistical evidence indicates that our method can produce cost-effective and contextual TD monitoring decisions. [ABSTRACT FROM AUTHOR]

Organizations replace their legacy systems for technical, economic, and operational reasons. Replacement is a risky proposition, as high levels of technical and social inertia make these systems hard to withdraw. Failure to fully replace systems results in complex system architectures involving manifold hidden dependencies that carry technical debt. To understand how a process for replacing a complex legacy system unfolds and accumulates technical debt, we conducted an explanatory case study at a local manufacturing site that had struggled to replace its mission-critical legacy systems as part of the larger global company’s commercial-off-the-shelf (COTS) system implementation. We approach the replacement as a sociotechnical change and leverage the punctuated sociotechnical information system change model in combination with the design-moves framework to analyze how the site balanced creating digital options, countering social inertia, and managing (architectural) technical debt. The findings generalize to a two-level (local/global) system-dynamics model delineating how replacing a deeply entrenched mission-critical system generates positive and negative feedback loops within and between social and technical changes at local and global levels. The loops, unless addressed, accrue technical debt that hinders legacy system discontinuance and gradually locks the organization into a debtconstrained state. The model helps managers anticipate challenges that accompany replacing highly entrenched systems and formulate effective strategies to address them. [ABSTRACT FROM AUTHOR]

Model‐Based Systems Engineering (MBSE) is the next step in the evolution of systems engineering (SE) in which documents are replaced by descriptive models as the authoritative embodiment of SE knowledge. These descriptive models possess a unique combination of the features and characteristics of documents, software, and data. Conscientiously applying appropriate modeling principles and practices is essential to make informed decisions to moderate the accumulation of model technical debt. This paper briefly explains the concept of technical debt and its adaptation to the domain of descriptive models for MBSE. The paper then describes 18 foundational modeling principles that model architects should consider when making architectural and implementation decisions about their models and describes some of the key model technical debt tradeoffs that result when these principles are not followed. These principles address commonly observed challenges regarding model federation architecture, the selection and use of model layers, the modeling of the domain, and the semantics of modeling constructs. Applying disciplined model architecting practices to conscientiously manage the accrual and payoff of technical debt can make the difference between an enduring model that provides substantial value throughout the life cycle of the modeled entity and a model whose value collapses under the weight of uncontrolled technical debt. [ABSTRACT FROM AUTHOR]

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. [ABSTRACT FROM AUTHOR]

Technical debt presents sub-optimal choices made in development, which are beneficial in the short term but not in the long run. Consciously admitted debt, which is marked with a keyword, e.g., TODO, is called keyword-labeled self-admitted technical debt (KL-SATD). KL-SATD can lead to adverse effects in software development, e.g., to a rise in complexity within the developed software. We investigated the relationship between KL-SATD from source code comments and reports from the highly popular industrial program analysis tool SonarQube. The goal was to find which SonarQube metrics and issues are related to KL-SATD introduction and removal and how many KL-SATD in the context of an issue addresses that issue. We performed a study with 33 software repositories. We analyzed the changes in SonarQube reports (sqale index, reliability and security remediation metrics, and SonarQube issues) and the relationship to KL-SATD addition and removal with mixed model analysis. We manually annotated a sample to investigate how many KL-SATD comments are in the context of SonarQube issues and how many address them directly. KL-SATD is associated with a reduction in code maintainability measured with SonarQube's sqale index. KL-SATD removal is associated with an increase in code maintainability (sqale index) and reliability measured with SonarQube's reliability remediation effort. The introduction and removal of KL-SATD have a predominantly relationship with code smells, and not with vulnerabilities and bugs. Manual annotation revealed that 36% of KL-SATD comments are in the context of a SonarQube issue, but only 15% of the comment address an issue. This means that despite of statistical relationship between KL-SATD comments and SonarQube reports there is a large set of KL-SATD comments that are in areas that Sonarqube reports as clean or free of maintainability issues. KL-SATD introduction and removal are connected mainly to code smells, connecting them to maintainability rather than reliability or security. This is reinforced by the relationship with the sqale index, as well as the dominance of code smells in SonarQube issues. Many KL-SATD issues have characteristics going beyond static analysis tools and require future studies extending the capabilities of the current tools. As KL-SATD comments and SonarQube reports appear to have limited overlap, it suggests that they are complementary and both are needed for getting a comprehensive view coverage of code maintainability. The study also presents rules violations developers should be aware of regarding KL-SATD introduction and removal. [ABSTRACT FROM AUTHOR]

Static code analysis (SAST is a well-known concept) to identify security flaws in the code to improve software product quality. A SAST tool called SonarQube which can scan source code of an application and identify the vulnerabilities present in software. It can also find the RCA of the vulnerabilities found in software products. it helps in rehabilitating the securities flaws found in analysis of the software products. SAST tools analyses upside-down for an application. It does not need s system to be in running state to perform analysis. The scan provides instant feedback to developers in terms of reducing security risks for an application. It helps to resolve issues which was present during development and helps developers to increase their knowledge. As a result, developers become competent about knowledge of security for software product. The sonar analysis report provides on demand access to all recommendations. The user can navigate to line-of-code which have vulnerabilities and they can do faster discovery and auditing. And hence the developers can write more code which is less vulnerable. This way they have more secure and quality product delivered. To conduct static analysis, the Authors have used SonarQube as a tool, which compile and measure the code quality for the code kept in repositories. The Authors observed SAST is important step in conductingsecurity and vulnerabilities scan for software product, it was also observed that most of the organisationconduct this SAST at later stage in DevOps/DevSecOps Phase which actually increases pipeline execution time. This motivated Authors topropose a better Model to reduce the build pipeline execution time. As Devops/DevSecOps standards, SonarQube is used to do SASTin DevSecOps pipelines which normally increases the build pipeline execution time. This increases the effort and time to complete the build pipeline and hence it also impacts overall budget of the software product. In the proposed solution, the Authors tried to reduce build pipeline execution time by conducting static analysis early in DevSecOps phases using shift left. Proposed solution uses GitHub open-source project written in C#.NET language, Azure Devops, dotnet sonar scanner tool and SonarQube to conduct static analysis and testing. The authors(s) tried to enhance the software quality in early Devops phases which will be helpful in reducing the build time and cost. Proposed Model will be helpful in increasing reliability, efficiency, and performance of software product. [ABSTRACT FROM AUTHOR]

Monitoring technical debt (TD) is considered highly important for software companies, as it provides valuable information on the effort required to repay TD and in turn maintain the system. When it comes to TD repayment, however, developers are often overwhelmed with a large volume of TD liabilities that they need to fix, rendering the procedure effort demanding. Hence, prioritizing TD liabilities is of utmost importance for effective TD repayment. Existing approaches rely on the current TD state of the system; however, prioritization would be more efficient by also considering its future evolution. To this end, the present work proposes a practical approach for prioritization of TD liabilities by incorporating information retrieved from TD forecasting techniques, emphasizing on the class‐level granularity to provide highly actionable results. Specifically, the proposed approach considers the change proneness and forecasted TD evolution of software artifacts and combines it with proper visualization techniques, to enable the early identification of classes that are more likely to become unmaintainable. To demonstrate and evaluate the approach, an empirical study is conducted on six real‐world applications. The proposed approach is expected to facilitate developers better plan refactoring activities, in order to manage TD promptly and avoid unforeseen situations long term. [ABSTRACT FROM AUTHOR]

Technical debt (TD) is a metaphor used to refer to the added software system costs acquired from taking shortcuts. Unfortunately, large amounts of TD can lead to serious consequences, and, thus, the management of TD is essential. Due to TD being a relatively new subject of study, many aspects of TD remain ambiguous. Fortunately, Twitter has been proven to hold a wealth of information on many subjects. As such, this survey study aims to gain a better understanding on how interest in TD has evolved over time and how TD is addressed on Twitter. A total of 128,897 TD‐related tweets were scrapped from Twitter and analyzed using a number of proxy measures and Latent Dirichlet Allocation (LDA). The results revealed that interest in TD on Twitter has been generally increasing since the platform's early stages. Furthermore, TD‐related tweets were found to revolve around 11 distinct categories. The TD in games category was discovered to be the most popular category, followed by TD communication and TD repayment. The results highlight that TD is a diverse and overarching topic that contains many potential avenues for further exploration. Software engineering researchers, practitioners, and educators can utilize this study to help steer their TD‐related future efforts. [ABSTRACT FROM AUTHOR]

Technical debt (TD) poses a significant risk in the software industry, representing the compromises made during software development that result in long-term consequences. To facilitate the management of TD, it is important to explore the causes of TD and the effects of the presence of TD on software projects. While the concept of TD has been investigated in several countries, no study has explored TD in the context of Saudi Arabia. In this paper, we aim to investigate the familiarity of the TD concept within the Saudi software practitioners and identifying the common causes and effects of TD in the Saudi software industry. We replicated a global survey called InsighTD, using the same survey instrument and the analysis procedure but collecting the data from software practitioners in Saudi Arabia. A total of 48 Saudi software practitioners completed the survey. The study findings indicate that the TD concept is not well recognized among the Saudi software practitioners (50% of the survey respondents have never heard of it before). Additionally, we identify the common causes and effects of TD from the perspective of Saudi software practitioners. The top causes of TD were tight-release deadlines, work pressure, lack of experience, and inappropriate project planning. On the other hand, the top effects of TD were increased maintenance effort/cost, low software quality, and delayed delivery of new versions. In conclusion, our findings support previous research regarding the most common TD causes and effects. In addition, they highlight some important factors in the Saudi software industry. [ABSTRACT FROM AUTHOR]

Organizations dealing with mission-critical AI based autonomous systems may need to provide continuous risk management controls and establish means for their governance. To achieve this, organizations are required to embed trustworthiness and transparency in these systems, with human overseeing and accountability. Autonomous systems gain trustworthiness, transparency, quality, and maintainability through the assurance of outcomes, explanations of behavior, and interpretations of intent. However, technical, commercial, and market challenges during the software development lifecycle (SDLC) of autonomous systems can lead to compromises in their quality, maintainability, interpretability and explainability. This paper conceptually models transformation of SDLC to enable affordances for assurance, explanations, interpretations, and overall governance in autonomous systems. We argue that opportunities for transformation of SDLC are available through concerted interventions such as technical debt management, shift-left approach and non-ephemeral artifacts. This paper contributes to the theory and practice of governance of autonomous systems, and in building trustworthiness incrementally and hierarchically.

Refactoring, which aims to improve the internal structure of the software systems preserving their behavior, is the most common payment strategy for technical debt (TD) by removing the code smells. There exist many studies presenting code smell detection approaches/tools or investigating their impact on quality attributes. There are also studies that focus on refactoring techniques, their relation with quality attributes, tool supports, and opportunities for them. Although there are several studies addressing the gap between refactoring and TD indicators, the empirical evidence provided is still limited. In this study, we examine the distribution of 29 refactoring types among the different projects and their relation with code smells or faults. We explore the refactoring types that are most commonly performed together and other activities performed with refactorings. We conduct a large exploratory study with automatically detected 57,528 refactorings, 37,553 smells, 27,340 faults, and 134,812 commits of 33 Java projects. Results show that some refactoring types are more commonly applied by developers. Our analysis indicates that refactorings usually remove or do not affect the code smells, and this contradicts with the previous studies. Also, the commits in which refactoring(s) is performed are three times more fault inducing than those without refactoring. [ABSTRACT FROM AUTHOR]

Technical debt (TD) refers to the phenomenon that developers choose a compromise solution from a short-term benefit perspective during design or architecture selection. TD-related issues, such as code smells, may have a critical impact on important non-functional requirements. Different severity levels of TD issues require different measures to be taken by developers in the future. Existing studies mainly focus on detecting TD in software projects through source code or comments, but usually ignore the severity degree of TD issues. As a matter of fact, it is very important to identify the severity of TD issues and clarify which TD should be prioritized. In this paper, we propose an approach that combines the semantic and structural information of the code snippets to identify their severity at method level. In the approach, we first transform each method affected by TD issues into an abstract syntax tree (AST) and use the paths in the AST to represent its semantic information. Then, we extract different code metrics to measure the size, coupling, and complexity of methods affected by TD issues to represent their structural information. Finally, we build a stacking ensemble model to identify the severity of TD issues by using Random Forest (RF) and eXtreme Gradient Boosting (XGBoost) for the base classifiers and Support Vector Machine (SVM) for the meta-classifier. The evaluation results on the real dataset show that our approach achieves 65.77% in terms of precision, 68.18% in terms of recall, and 65.84% in terms of F1-score on average. In addition, the experimental results also demonstrate that the strategy of combining the semantic and structural information of code snippets is effective in improving the effectiveness of our approach. [ABSTRACT FROM AUTHOR]

The metaphor of technical debt (TD) has generated a conceptual framework on factors that weaken the quality of software and accumulate a repair cost. However, user-related aspects like user experience (UX) receive little consideration among TD types, for reasons like the substantial focus on code TD, some dynamics inherent to agile processes, and an apparent lack of cumulative cost over time. This article has two main goals: first, to present evidence of the existence of UXDebt as a type of TD, with a cumulative cost for the development team as well as stakeholders; second, to propose a definition and characterization of UXDebt that may serve as a frame for further research on methods and tools for continuous management within agile processes. For the first goal, we have compiled evidence on the current state of UXDebt from three sources: a literature review, a survey among software engineering professionals in agile teams, and the analysis of UX issues in GitHub. All sources have evidenced some form of UXDebt; surveyed practitioners have recognized its poor management with a cost for the entire team that accumulates over time. Moreover, issue tracking systems allow to visualize and measure a technical form of UXDebt. For the second goal, we have defined a conceptual model that characterizes UXDebt in terms of both technical and non-technical aspects. On the technical side, we propose the notion of UX smells which allows us to discuss concrete management activities. [ABSTRACT FROM AUTHOR]

Technical debt (TD) expresses the lack of internal quality directly affecting software evolution. Therefore, it has gained the attention of software researchers and practitioners recently. Software researchers have performed empirical studies to observe the perspective of TD in different software cultures and organizations. However, it is important to replicate such studies in more places and with more practitioners to strengthen the perception of TD. In this paper, we present the results of a set of new research questions from an evolved survey design of a survey replication in the Uruguayan software industry to characterize how the software industry professionals understand, perceive, and adopt TD management (TDM) activities. The results allow us to observe that different participant contexts (startups, government, job roles) show different levels of awareness and perception of TD. Details in the form of the adoption of each TDM activity were presented. We could observe some difficulties in conducting some TDM activities that the practitioners consider very important, especially in TDM and monitoring. Differences in specific organizational contexts like startups and government could indicate the need for research efforts in other software engineering communities that meet their specific TD challenges and needs. [ABSTRACT FROM AUTHOR]

Technical debt refers to maintenance obligations that stem from violations of established standards during the development and subsequent maintenance of enterprise systems. Technical debt remediation is particularly challenging in the outsourcing context due to information asymmetry between client and vendor teams. Control balancing—the periodic adjustments to the control configurations of outsourced projects—has been proposed as a process to help mitigate these information asymmetry challenges. Using data collected from 1,824 real-world projects, we tested to what extent control balancing improves the remediation of technical debt. After controlling for a number of technical and environmental factors, including system size, system lifespan, and contract parameters, we find that control balancing can benefit technical debt remediation, but primarily when processes for migrating technical debt-laden systems to new technological platforms have been identified. We highlight the role of technical debt in influencing the effects of relational flexibility in inter-firm engagements. [ABSTRACT FROM AUTHOR]

The metaphor of technical debt (TD) is widely adopted in the software engineering field, referring to short‐term compromises in software artifacts in exchange for speed or to meet release schedules or other constraints. The implication is that TDs accumulate over time, and may eventually make rework or maintenance very expensive or even impossible. The analogy is generally applicable in the systems engineering field, particularly concerning numerous program cancellation and obsolescence challenges due to premature decisions made in early acquisition phases. This paper adapts this metaphor of TD to the systems engineering field, and proposes a TD taxonomy to support the early identification and assessment of TD items in engineering complex systems, especially in the early life cycle phases of engineering complex, distributed systems. The taxonomy identifies seven TD types: functionality, performance, interoperability, version conflicts, documentation and support, system evolution, and organic, based on systematic indicators and signs discoverable during early acquisition activities. We expect that the notion and the taxonomy of TD will offer an additional perspective for design decisions that will help mitigate challenging integration and obsolescence issues in the engineering of complex systems. [ABSTRACT FROM AUTHOR]

The metaphor of "technical debt" is used in software engineering to describe technical solutions that may be pragmatic in the near‐term but may have a negative long‐term impact. Similar decisions and similar dynamics are present in the field of systems engineering. This work investigates the current body of knowledge to identify if, and how, the technical debt metaphor is used within the systems engineering field and which systems engineering lifecycle stages are most susceptible to technical debt. A systematic literature review was conducted on 354 papers in February 2022, of which 18 were deemed relevant for inclusion in the study. The results of the systematic literature review show that the technical debt metaphor is not prevalent within systems engineering research and that existing research is limited to specific fields and theoretical discussions. This paper concludes with recommendations for future work to establish a research agenda on the identification and management of technical debt within systems engineering. [ABSTRACT FROM AUTHOR]

Purpose: Development of the customer perceived value expression with the product use functions optimization model aiming particularly the case of new technology based innovations. Design/methodology/approach: Firstly, the role of customer is presented with particular attention payed to the client role in value creation process in the case of innovation based product. Then the perceived customer value and customer value definition are described. Those formulas are used in consequence as the base for expanded theoretic value concept, which is integrating the impact of used product brand and user functions mix. Finally, the introduced notion is developed in matrix form and briefly discussed. Findings: Extended formula of innovation based new product perceived customer value is presented in the form of the matrix notation, the possible application in the company innovation based product portfolio formation process is discussed. Research limitations/implications: Presented approach to the customer perceived value is based on the application of technical debt concept as the measure of analyzed product innovativeness, which is sensitive data and stay difficult to collect, particularly in case of new technologies. Practical implications: Proposed extended customer perceived value formula can be used as practical tool of new technology based innovative product, allowing to assess its market value in comparison to the existing company product cost structure. Makes possible to confront the customer product appreciation to those coming from the company interior analyzes. Hence its matrix form can serve as optimization model taking under consideration the possible market potential, impact of used brand and design and product use functions mix according to their technology life cycle. Social implications: Developed concept can reinforce the client role in commercialization process, particularly in case technology innovation. Also its use can be an interesting tool of prosumption development, making it more unambiguous and proactive. Originality/value: Presented extended formula of customer perceived vale can be applied as an interesting concept of research about nature the value of new technologies based innovation product also as base for practical managerial tool of optimization the new product mix during the commercialization process. [ABSTRACT FROM AUTHOR]

With the advent of regulations protecting users such as the General Data Protection Regulation, security and privacy concerns are playing a new role in small settings such as in very small entities. Their relevance is increasing, and privacy is being considered a Troy horse in software developments. In fact, privacy is a part of software architectural decisions, and they must be considered as a technical debt. The contributions of this paper are the following: a privacy debt definition with a principal and an interest, privacy‐related activities to be considered within the ISO/IEC 29110 basic profile, and the use of the net present value within this context. All these contributions help us to integrate privacy debt and VSE's software developments. [ABSTRACT FROM AUTHOR]

Technical debt, the long-term impact of decisions made to achieve a short-term benefit, has a unique impact on a project schedule. Technical debt does not impact the ability to complete the task on which it is incurred but rather impacts successor tasks causing unplanned schedule delays or budget increases. The impact of technical debt is uncertain and therefore must be modeled probabilistically. When unaccounted for and unmanaged, technical debt can build up in the project with increasing impact, eventually forcing forward progress to stop while the technical debt is remedied. Traditional project scheduling methods allow for uncertain task durations but do not provide explicit means of modeling the impacts of technical debt. Instead, they assume that each task is unaffected by the completion status of its predecessors and its duration is only dependent upon the initial estimates. This research addresses this gap by providing a novel model of the impact of technical debt on the project schedule through estimating the dynamics of value creation in the presence of technical debt. Equations are developed for estimating the probabilistic impacts of technical debt on the generation of earned value. These equations are then inverted and used to calculate task duration in the presence of technical debt and included in a Monte Carlo analysis. Comparisons are made to an existing Monte Carlo schedule analysis and technical debt impacts are explored.

The List, Evaluate, Achieve, Procure (LEAP) process defines a methodology for mathematically associating the delivery of system capabilities with the temporal satisfaction of stakeholder needs while identifying technologies at high risk of imparting technical debt into the system. The original process is qualitative, relying on binary definitions of timelines for technology development – the technology either is or is not developed in a specific time period. The binary definitions allow for rapid high-level assessments of the potential for technical debt. However, they fail to capture more realistic scenarios of uncertain technology development timelines. This paper resolves these issues by introducing probability into LEAP process. This paper also provides examples of using the probability in the LEAP process and compares the probabilistic (quantitative) and binary (qualitative) models. These examples show improvements in the ability to assess the likelihood of delivering capabilities in time to meet stakeholder needs when using the probabilistic version of the LEAP process. Since the impact of technical debt is uncertain, the inclusion of probabilities within the LEAP process provides a higher fidelity decision support system for iterative release planning and system development.

Technical debt is considered detrimental to the long-term success of software development, but despite the numerous studies in the literature, there are still many aspects that need to be investigated for a better understanding of it. In particular, the main problems that hinder its complete understanding are the absence of a clear definition and a model for its identification, management, and forecasting. Focusing on forecasting technical debt, there is a growing notion that preventing technical debt build-up allows you to identify and address the riskiest debt items for the project before they can permanently compromise it. However, despite this high relevance, the forecast of technical debt is still little explored. To this end, this study aims to evaluate whether the quality metrics of a software system can be useful for the correct prediction of the technical debt. Therefore, the data related to the quality metrics of 8 different open-source software systems were analyzed and supplied as input to multiple machine learning algorithms to perform the prediction of the technical debt. In addition, several partitions of the initial dataset were evaluated to assess whether prediction performance could be improved by performing a data selection. The results obtained show good forecasting performance and the proposed document provides a useful approach to understanding the overall phenomenon of technical debt for practical purposes. [ABSTRACT FROM AUTHOR]

Current Internet of Things (IoT) systems comprise multiple software systems that are deployed to provide users with the required functionalities. System architects create system blueprints and draw specifications for the software artefacts that are needed; subsequently, either custom-made software is developed according to these specifications and/or ready-made COTS/open source software may be identified and customized to realize the overall system goals. All deployed software however may entail vulnerabilities, either due to insecure coding practices or owing to misconfigurations and unexpected interactions. Moreover, software artefacts may implement a much broader set of functionalities than may be strictly necessary for the system at hand, in order to serve a wider range of needs, and failure to appropriately configure the deployed software to include only the required modules results in the further increase of the system attack surface and the associated risk. In this paper, we present a software vulnerability management framework which facilitates (a) the configuration of software to include only the necessary features, (b) the execution of security-related tests and the compilation of platform-wide software vulnerability lists, and (c) the prioritization of vulnerability addressing, considering the impact of each vulnerability, the associated technical debt for its remediation, and the available security budget. The proposed framework can be used as an aid in IoT platform implementation by software architects, developers, and security experts. [ABSTRACT FROM AUTHOR]

The average lifetime of software systems has been growing steadily over the last few decades, and thus, they are demanding increasing resources to remain in operation while still meeting business needs. As a software system ages, it needs to be continuously modified and expanded to stay useful. Whether intentional or not, the various maintenance activities performed during the software's lifetime inevitably introduce quality violations, contributing to building up the software's technical debt. If these violations are not adequately addressed, they can negatively impact the software's maintainability and, thus, the software's capacity to adapt and evolve. In general terms, usually, the aim is to sustain satisfactory levels of technical quality characteristics of the software and, at the same time, preserve the maintenance costs and the tangible software asset itself at acceptable levels to organizations. The long-term impact of various maintenance investment decisions inevitability influences the software's evolutionary path, which goes through numerous iterations throughout its lifetime. This work uses the systems thinking approach to map the main concepts related to the software maintenance processes that account for this tradeoff analysis and decisions and describe their causal relationships. Moreover, it presents a systemic causal-effect relationship map capable of evidencing how some of the emergent behavior arising from long-term operating and maintaining software systems could be endogenously explained. [ABSTRACT FROM AUTHOR]

Technical debt (TD) is a technical compromise wherein the ability to maintain information technology (IT) applications over the long term is sacrificed for short-term goals. TD occurs when software development teams undergo constant pressure to release applications swiftly, on a tight schedule. The accumulation of TD, which often leads to a significant cost surplus, presents a ubiquitous challenge in technology-driven organisations. To keep TD levels under control, many organisations implement top-down mechanisms that impose enterprise-wide principles on software development teams. This clinical research presents a complementary but distinct approach to managing TD. A digital nudge was introduced at Credit Suisse, a global financial services company, to help raise awareness and understanding, and stimulate actions related to TD decision-making in software development teams. This paper reports on the nudge's clinical design, implementation, impact, and evaluation. As the nudge was effective in reducing TD in IT applications after one year of use, we demonstrate that digital nudges are viable means for guiding collective decisions in complex decision environments like that of TD management. Our findings have several implications for research and practice. [ABSTRACT FROM AUTHOR]

Technical debt (TD) can bring short-term benefits to software projects, but its presence is associated with issues such as decreasing product quality. Recent literature has proposed various approaches for identifying and managing TD, but most of them focus on the software developers' point of view. Little is known about how project management practitioners perceive and manage TD items. Goal: This work aims to investigate how project management practitioners discuss and experience TD. Method: To achieve this goal, our work mines, curates, and selects a total of 108 TD-related discussions on the Stack Exchange Project Management (SEPM) Q&A site. These discussions amount to 547 posts and 882 text comments on the subject. We analyze this data set quantitatively and qualitatively, using open coding to derive TD types, indicators, and management practices. Results: We identified 74 indicators used for recognizing debt items and 126 TD management practices. The types of debt most discussed at SEPM are process and people debts. This contradicts studies done with developers where code and design debts are most discussed. Conclusion: The perspective considered by project management practitioners to analyze the TD phenomenon is different from the one considered by other roles in the software development process. Our work organizes the identified TD indicators and management practices into a Sankey diagram, which may assist TD management practitioners and serve as guidance for future research on the subject. [ABSTRACT FROM AUTHOR]

Context: The presence of technical debt (TD) brings risks to software projects. Managers must continuously find a cost-benefit balance between the benefits of incurring in TD and the costs of its presence in a software project. Much attention has been given to TD related to coding issues, but other types of debt can also have impactful consequences on projects. Aims: This paper seeks to elaborate on the growing need to expand TD research to other areas of software development, by analyzing six elements related to TD management, namely: causes, effects, preventive practices, reasons for non-prevention, repayment practices, and reasons for nonrepayment of TD. Method: We survey and analyze, quantitatively and qualitatively, the answers of 653 software industry practitioners on TD to investigate how the previously mentioned elements are related to coding and noncoding issues of the software development process. Results: Coding issues are commonly related to the investigated elements but, indeed, they are only part of the TD Management stage. Issues related to the project planning and management, human factors, knowledge, quality, process, requirements, verification, validation, and test, design, architecture, and the organization are also common sources of TD. We organize the results in a hump diagram and specialize it considering the point of view of practitioners that have used agile, hybrid, and traditional process models in their projects. Conclusion: The hump diagram, in combination with the detailed results, provides guidance on what to expect from the presence of TD and how to react to it considering several issues of software development. The results shed light on TD management of software elements, beyond source code related artifacts. [ABSTRACT FROM AUTHOR]

Efficient Technical Debt Management (TDM) requires specialized guidance so that decisions taken are oriented to add value to the business. Because it is a complex problem that involves several variables, TDM requires a systemic look that considers professionals' experiences from different specialties. Guilds have been a means technology companies have united specialized professionals around a common interest, especially those using the Spotify methodology. This paper presents the experience of implementing a guild to support TDM's activities in a software development organization using the action research method. The project lasted three years, and approximately 120 developers were involved in updating about 63,300 source-code files, 2,314 test cases, 2,097 automated test scripts, and the build pipeline. The actions resulting from the TDM guild's efforts impacted the company's culture by introducing new software development practices and standards. Besides, they positively influenced the quality of the artifacts delivered by the developers. This study shows that, as the company acquires maturity in TDM, it increases the need for professionals dedicated to TDM's activities. [ABSTRACT FROM AUTHOR]

The Technical Debt (TD) metaphor describes development shortcuts taken for expediency that cause the degradation of internal software quality. It has served the discourse between engineers and management regarding how to invest resources in maintenance and extend into scientific software (both the tools, the algorithms and the analysis conducted with it). Mathematical programming has been considered 'special purpose programming', meant to program and simulate particular problem types (e.g., symbolic mathematics through Matlab). Likewise, more traditional mathematical programming has been considered 'modelling programming' to program models by providing programming structures required for mathematical formulations (e.g., GAMS, AMPL, AIMMS). Because of this, other authors have argued the need to consider mathematical programming as closely related to software development. As a result, this paper presents a novel exploration of TD in mathematical programming by assessing self-reported practices through a survey, which gathered 168 complete responses. This study discovered potential debts manifested through smells and attitudinal causes towards them. Results uncovered a trend to refactor and polish the final mathematical model and use version control and detailed comments. Nonetheless, we uncovered traces of negative practices regarding Code Debt and Documentation Debt, alongside hints indicating that most TD is deliberately introduced (i.e., modellers are aware that their practices are not the best). We aim to discuss the idea that TD is also present in mathematical programming and that it may hamper the reproducibility and maintainability of the models created. The overall goal is to outline future areas of work that can lead to changing current modellers' habits and assist in extending existing mathematical programming (both practice and research) to eventually manage TD in mathematical programming. [ABSTRACT FROM AUTHOR]

This paper focuses on application of a technical debt prioritisation technique in telecommunication software managing a fleet of devices for a video surveillance system. Technical debt for this application was gathered, categorised and prioritised according to the Continuous Debt Valuation Approach (CoDVA), previously proposed by the authors. The following research question was posed: Is prioritising technical debt reduction based on CoDVA effective (i.e., executed as per plan, bringing tangible benefits)? The outbreak of COVID-19 pandemic caused unprecedented disturbance to the engineering organisations worldwide, therefore the technical debt identification phase had to be adapted to cope with a switch to forced working-from-home mode. This was achieved by applying the Wisdom of Crowds method, ensuring broad participation of engineers, and providing a fairly complete picture of the accrued technical debt. Nevertheless, the actual technical debt reduction activities did not follow exactly the expected guidelines. The three main causes of this phenomenon were discovered: continuous refactoring approach, sizing of technical debt items, and the broadened scope of refactoring activities. Therefore, as a result of this case study we propose to adopt a specific broadened definition of technical debt and follow a few rules for defining its scope and granularity. [ABSTRACT FROM AUTHOR]

It is crucial to understand how reproducible the measurement results in the scientific publications are, as reproducibility is one of the cornerstones of engineering.

Technical debt (TD) happenswhen project teams carry out technical decisions in favor of a short-term goal(s) in their projects, whether deliberately or unknowingly. TD must be properly managed to guarantee that its negative implications do not outweigh its advantages. A lot of research has been conducted to show that TD has evolved into a common problem with considerable financial burden. Test technical debt is the technical debt aspect of testing (or test debt). Test debt is a relatively new concept that has piqued the curiosity of the software industry in recent years. In this article, we assume that the organization selects the testing artifacts at the start of every sprint. Implementing the latest features in consideration of expected business value and repaying technical debt are among candidate tasks in terms of the testing process (test cases increments). To gain the maximum benefit for the organization in terms of software testing optimization, there is a need to select the artifacts (i.e., test cases) with maximum feature coverage within the available resources. The management of testing optimization for large projects is complicated and can also be treated as a multi-objective problem that entails a trade-off between the agile software's short-term and long-term value. In this article, we implement a multi-objective indicatorbased evolutionary algorithm (IBEA) for fixing such optimization issues. The capability of the algorithm is evidenced by adding it to a real case study of a university registration process. [ABSTRACT FROM AUTHOR]

Context: Technical debt (TD) is a challenge for companies who develop software on which their critical operations depend. To properly manage TD, it is necessary to make it visible to the different stakeholders involved to support informed decisions. Objective: To validate a TD visualization approach based on hybrid Sankey diagrams that makes the TD visible by showing (a) technical and business aspects, and (b) the flow of value and TD impacts. This approach regards visualizations as boundary objects. Method: We performed a multi-case study in a large multi-industry state-owned company. The objective was to validate the effectiveness of such visualizations and to explore their possible uses in TD management. We first used a retrospective case study on a TD decision-making scenario and, later, visualization usage scenarios using focus groups to evaluate its usefulness. Results: The results suggest that the proposed approach: (a) provides a structured process for systematic TD visualization to help the decision-making process; (b) enables the communication at knowledge boundaries between stakeholders to make informed decisions; (c) uses flow representations that are important for assessing the impact in multiple functional areas; and (d) enables documentation and reuse. Conclusion: The study results suggest that TD decision-making events can benefit from using our TD visualizations based on hybrid Sankey diagrams as boundary objects to portray the impact of TD in business, services, and technical aspects. [ABSTRACT FROM AUTHOR]

In software development, due to the demands from users or the limitations of time and resources, developers tend to adopt suboptimal solutions to achieve quick software development. In such a way, the released software usually involves not-quite-right code that is called technical debt, which will significantly decrease the quality of software and increase the maintenance cost. Recently, the concept of self-admitted technical debt (SATD) is proposed and refers to technical debt that is self-admitted by developers in code comments. Existing studies mainly focus on detecting technical debt by classifying code comments into either “SATD” or “non-SATD.” However, different types of SATD has different impacts on software maintenance and needs to be handled by different developers. Therefore, the detected SATD should be further classified so that developers can understand and remove technical debt better. In this article, we propose a new method based on eXtreme Gradient Boosting (XGBoost) to classify SATD into multiple classes. In our approach, we first preprocess the original code comments and adopt the easy data augmentation strategy to overcome the class unbalance problem. Then, chi-square is leveraged to select representative features from the textual feature set. Finally, we apply XGBoost to train a classifier and use the trained classifier to partition each comment into the corresponding class. We experimentally investigate the effectiveness of our approach on a public dataset, including 62 566 code comments from 10 open-source projects. Experimental results show that our approach achieves 56.66% in terms of macroaveraged precision, 59.07% in terms of macroaveraged recall, and 55.77% in terms of macroaveraged F-measure on average, and outperforms the natural language processing based method by 4.98%, 5.32%, and 3.17%, respectively. In addition, the experimental results also demonstrate that the data augmentation strategy is effective in improving the effectiveness of our approach. [ABSTRACT FROM AUTHOR]