Search

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]

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]

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]

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]

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]

Although architectural smells are one of the most studied type of architectural technical debt, their impact on maintenance effort has not been thoroughly investigated. Studying this impact would help to understand how much technical debt interest is being paid due to the existence of architecture smells and how this interest can be calculated. This work is a first attempt to address this issue by investigating the relation between architecture smells and source code changes. Specifically, we study whether the frequency and size of changes are correlated with the presence of a selected set of architectural smells. We detect architectural smells using the Arcan tool, which detects architectural smells by building a dependency graph of the system analyzed and then looking for the typical structures of the architectural smells. The findings, based on a case study of 31 open‐source Java systems, show that 87% of the analyzed commits present more changes in artifacts with at least one smell, and the likelihood of changing increases with the number of smells. Moreover, there is also evidence to confirm that change frequency increases after the introduction of a smell and that the size of changes is also larger in smelly artifacts. These findings hold true especially in Medium–Large and Large artifacts. [ABSTRACT FROM AUTHOR]

The modern retail environment is evolving rapidly under the confluence of technological advancement, environmental uncertainty, and general market dynamism. We summarize and synthesize the studies in this special-topic issue to illustrate how transportation capabilities enable members of the modern retail supply chain to adopt new business models, enhance lifestyles of community members, and contribute to corporate social responsibility. Further, we propose extensions to the studies published in this issue to further examine the future of transportation in retail. Notably, we call for future studies to explore how retail supply chain members may (1) develop new transportation and distribution capabilities by overcoming technical debt associated with specialized but abandoned assets; (2) leverage secondary markets to develop a closed-loop supply chain to maximize value and minimize waste; and (3) use enhanced transportation transparency and visibility to enhance customer service and sustainability efforts in retail supply chains. [ABSTRACT FROM AUTHOR]

This study argues the difference between security and privacy and outlines the concept of Privacy Debt as a new Technical Debt. Privacy is gaining momentum in any software system due to mandatory compliance with respect to laws and regulations. There are several types of technical debts within the umbrella of software engineering, and most of them arise during different phases of software development. Several research studies have been focussed on highlighting different types of technical debts. However, authors introduce Privacy Debt as a particular technical debt focussed on privacy management and linked to a perturbative method. Privacy must be considered not only as technical debt requirements but also at design and deployment phases, among others. In addition, this method is illustrated with a use case. [ABSTRACT FROM AUTHOR]

In model‐driven engineering (MDE) software projects, large portions of the executable code are automatically generated from designs and models. This generated code may or may not be edited by the developers to achieve their development objectives. MDE projects also include a significant amount of handwritten code (HC). This handwritten code is developed under unique constraints, as it must integrate with generated artifacts and code elements that are not directly developed by the engineers. These constraints adversely affect codebase quality and maintainability. This case study aims to investigate the hypothesis pertaining to the handwritten code quality developed in the context of MDE. The study analyzes these unique code fragments and compares their characteristics to handwritten code in repositories where code generation is not present. The study finds that handwritten code quality in the MDE context suffers from elevated technical debt and code smells. We observe key code smells that are particularly evident in this handwritten code. These findings imply that code generators must optimize for human comprehension, prioritize extensibility, and must facilitate integration with handwritten code elements. [ABSTRACT FROM AUTHOR]

Nowadays, security and safety aspects are two of the major concerns for any software system development, especially while developing safety critical systems. This is especially relevant for very small entities because they have a limited amount of resources for dealing with all these aspects at the same time. In addition, these systems are highly regulated domains, and they involve a huge set of standards focused on safety and security‐related issues. Therefore, these small entities are not only facing hurdles related to technical aspects but also from the so‐called technical debt when overarching a critical development. This paper extends the assurance cases approach by integrating security aspects within the life cycle, and it proposes a framework for managing the associated security technical debt for very small entities. A tool chain is outlined, and the approach is illustrated with an industrial use case. [ABSTRACT FROM AUTHOR]

Context Technical debt refers to the consequences of taking shortcuts when developing software. These consequences can impede the software growth and have financial implications. The software engineering research community needs to explore technical debt further from a practitioner standpoint. Objective This study gathers insights from practitioners on key components of technical debt such as its definition, characterization, consequences, benefits, and how it is communicated. Method We conducted semi-structured interviews with a convenience sample of 17 practitioners and a survey of 67 participants. Results Despite the lack of consensus, we identified the most commonly accepted definition, method to measure technical debt (as person hours), and method to reduce debt (by allocating time in iterations to address the debt). Defects were also identified as type of debt and the cost of technical debt is more than the cost to make changes to source code. Three distinct company profiles emerged. Conclusion Despite increasing research on technical debt, the field lacks consensus on its many facets. One interesting outcome of this study is how to assess the risks of technical debt by evaluating liabilities beyond costs of directly handling debt. [ABSTRACT FROM AUTHOR]

As a summary of past, current, and future trends in software maintenance and reengineering research, we give in this editorial a retrospective look from the past 14 years to now. We provide insight on how software maintenance has evolved and on the most important research topics presented in the series of the European Conference on Software Maintenance and Reengineering. [ABSTRACT FROM AUTHOR]