skip to main content


Title: Technical debt resulting from architectural degradation and code smells: a systematic mapping study
Poor design choices, bad coding practices, or the need to produce software quickly can stand behind technical debt. Unfortunately, manually identifying and managing technical debt gets more difficult as the software matures. Recent research offers various techniques to automate the process of detecting and managing technical debt to address these challenges. This manuscript presents a mapping study of the many aspects of technical debt that have been discovered in this field of study. This includes looking at the various forms of technical debt, as well as detection methods, the financial implications, and mitigation strategies. The findings and outcomes of this study are applicable to a wide range of software development life-cycle decisions.  more » « less
Award ID(s):
1854049
NSF-PAR ID:
10393892
Author(s) / Creator(s):
; ; ; ; ; ; ; ; ;
Date Published:
Journal Name:
ACM SIGAPP Applied Computing Review
Volume:
21
Issue:
4
ISSN:
1559-6915
Page Range / eLocation ID:
20 to 36
Format(s):
Medium: X
Sponsoring Org:
National Science Foundation
More Like this
  1. Context: Managing technical debt (TD) associated with potential security breaches found during design can lead to catching vulnerabilities (i.e., exploitable weaknesses) earlier in the software lifecycle; thus, anticipating TD principal and interest that can have decidedly negative impacts on businesses. Goal: To establish an approach to help assess TD associated with security weaknesses by leveraging the Common Weakness Enumeration (CWE) and its scoring mechanism, the Common Weakness Scoring System (CWSS). Method: We present a position study with a five-step approach employing the Quamoco quality model to operationalize the scoring of architectural CWEs. Results: We use static analysis to detect design level CWEs, calculate their CWSS scores, and provide a relative ranking of weaknesses that help practitioners identify the highest risks in an organization with a potential to impact TD. Conclusion: CWSS is a community agreed upon method that should be leveraged to help inform the ranking of security related TD items. 
    more » « less
  2. null (Ed.)
    Context: Managing technical debt (TD) associated with external cybersecurity attacks on an organization can significantly improve decisions made when prioritizing which security weaknesses require attention. Whilst source code vulnerabilities can be found using static analysis techniques, malicious external attacks expose the vulnerabilities of a system at runtime and can sometimes remain hidden for long periods of time. By mapping malicious attack tactics to the consequences of weaknesses (i.e. exploitable source code vulnerabilities) we can begin to understand and prioritize the refactoring of the source code vulnerabilities that cause the greatest amount of technical debt on a system. Goal: To establish an approach that maps common external attack tactics to system weaknesses. The consequences of a weakness associated with a specific attack technique can then be used to determine the technical debt principal of said violation; which can be measured in terms of loss of business rather than source code maintenance. Method: We present a position study that uses Jaccard similarity scoring to examine how 11 malicious attack tactics can relate to Common Weakness Enumerations (CWEs). Results: We conduct a study to simulate attacks, and generate dependency graphs between external attacks and the technical consequences associated with CWEs. Conclusion: The mapping of cyber security attacks to weaknesses allows operational staff (SecDevOps) to focus on deploying appropriate countermeasures and allows developers to focus on refactoring the vulnerabilities with the greatest potential for technical debt. 
    more » « less
  3. Architecture debt is a form of technical debt that derives from the gap between the intended and the actual architecture design. In this study we measured architecture debt in two ways: 1) in terms of system-wide coupling measures, and 2) in terms of the number and severity of architecture flaws. In recent research it was shown that the amount of architecture debt has a huge impact on software maintainability and evolution. Consequently, reducing debt is expected to make software less costly and more amenable to change. This paper reports on a longitudinal study of a healthcare communications product created by BrightSquid Secure Communications Corp. This young company is facing the typical trade-off problem of desiring responsiveness to change requests, but wanting to avoid the ever-increasing effort that the accumulation of quick-and- dirty changes eventually incurs. In the first stage of the study, we analyzed the status of the “before” system, which showed the impacts of change requests. This initial study motivated a more in-depth analysis of architecture debt. The results of this debt analysis were used in the second stage of the work to motivate a comprehensive refactoring of the software system. The third stage was a follow-on architecture debt analysis which quantified the improvements realized. Using this quantitative evidence, augmented by qualitative evidence gathered from in- depth interviews with BrightSquid’s architects, we present lessons learned about the costs and benefits of paying down architecture debt in practice. 
    more » « less
  4. In a software system’s development lifecycle, engineers make numerous design decisions that subsequently cause architectural change in the system. Previous studies have shown that, more often than not, these architectural changes are unintentional by-products of continual software maintenance tasks. The result of inadvertent architectural changes is accumulation of technical debt and deterioration of software quality. Despite their important implications, there is a relative shortage of techniques, tools, and empirical studies pertaining to architectural design decisions. In this paper, we take a step toward addressing that scarcity by using the information in the issue and code repositories of open-source software systems to investigate the cause and frequency of such architectural design decisions. Furthermore, building on these results, we develop a predictive model that is able to identify the architectural significance of newly submitted issues, thereby helping engineers to prevent the adverse effects of architectural decay. The results of this study are based on the analysis of 21,062 issues affecting 301 versions of 5 large open-source systems for which the code changes and issues were publicly accessible. 
    more » « less
  5. In this paper we reflect on our decade-long journey of creating, evolving, and evaluating a number of software design concepts and technical debt management technologies. These include: a novel maintainability metric, a new model for representing design information, a suite of design anti-patterns, and a formalized model of design debt. All of these concepts are rooted in options theory, and they all share the objective of helping a software project team quantify and visualize major design principles, and address the very real maintainability challenges faced by their organizations in practice. The evolution of our research has been propelled by our continuous interactions with industrial collaborators. For each concept, technology, and supporting tool, we embarked on an ambitious program of empirical validation—in “the lab”, with industry partners, and with open source projects. We reflect on the successes of this research and on areas where significant challenges remain. In particular, we observe that improved software design education, both for students and professional developers, is the prerequisite for our research and technology to be widely adopted. During this journey, we also observed a number of gaps: between what we offer in research and what practitioners need, between management and development, and between debt detection and debt reduction. Addressing these challenges motivates our research moving forward. 
    more » « less