77 research outputs found
What to Fix? Distinguishing between design and non-design rules in automated tools
Technical debt---design shortcuts taken to optimize for delivery speed---is a
critical part of long-term software costs. Consequently, automatically
detecting technical debt is a high priority for software practitioners.
Software quality tool vendors have responded to this need by positioning their
tools to detect and manage technical debt. While these tools bundle a number of
rules, it is hard for users to understand which rules identify design issues,
as opposed to syntactic quality. This is important, since previous studies have
revealed the most significant technical debt is related to design issues. Other
research has focused on comparing these tools on open source projects, but
these comparisons have not looked at whether the rules were relevant to design.
We conducted an empirical study using a structured categorization approach, and
manually classify 466 software quality rules from three industry tools---CAST,
SonarQube, and NDepend. We found that most of these rules were easily labeled
as either not design (55%) or design (19%). The remainder (26%) resulted in
disagreements among the labelers. Our results are a first step in formalizing a
definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on
Software Architecture 2017 (Gothenburg, SE
Empirical evaluation of an architectural technical debt index in the context of the Apache and ONAP ecosystems
Background. Architectural Technical Debt (ATD) in a software-intensive system denotes architectural design choices which, while being suitable or even optimal when adopted, lower the maintainability and evolvability of the system in the long term, hindering future development activities. Despite the growing research interest in ATD, how to gain an informative and encompassing viewpoint of the ATD present in a software-intensive system is still an open problem. Objective. In this study, we evaluate ATDx, a data-driven approach providing an overview of the ATD present in a software-intensive system. The approach, based on the analysis of a software portfolio, calculates severity levels of architectural rule violations via a clustering algorithm, and aggregates results into different ATD dimensions. Method. To evaluate ATDx, we implement an instance of the approach based on SonarQube, and run the analysis on the Apache and ONAP ecosystems. The analysis results are then shared with the portfolio contributors, who are invited to participate in an online survey designed to evaluate the representativeness and actionability of the approach. Results. The survey results confirm the representativeness of the ATDx, in terms of both the ATDx analysis results and the used architectural technical debt dimensions. Results also showed the actionability of the approach, although to a lower extent when compared to the ATDx representativeness, with usage scenarios including refactoring, code review, communication, and ATD evolution analysis. Conclusions. With ATDx, we strive for the establishment of a sound, comprehensive, and intuitive architectural view of the ATD identifiable via source code analysis. The collected results are promising, and display both the representativeness and actionability of the approach. As future work, we plan to consolidate the approach via further empirical experimentation, by considering other development contexts (e.g., proprietary portfolios and other source code analysis tools), and enhancing the ATDx report capabilities
A Synthesis of Green Architectural Tactics for ML-Enabled Systems
The rapid adoption of artificial intelligence (AI) and machine learning (ML)
has generated growing interest in understanding their environmental impact and
the challenges associated with designing environmentally friendly ML-enabled
systems. While Green AI research, i.e., research that tries to minimize the
energy footprint of AI, is receiving increasing attention, very few concrete
guidelines are available on how ML-enabled systems can be designed to be more
environmentally sustainable. In this paper, we provide a catalog of 30 green
architectural tactics for ML-enabled systems to fill this gap. An architectural
tactic is a high-level design technique to improve software quality, in our
case environmental sustainability. We derived the tactics from the analysis of
51 peer-reviewed publications that primarily explore Green AI, and validated
them using a focus group approach with three experts. The 30 tactics we
identified are aimed to serve as an initial reference guide for further
exploration into Green AI from a software engineering perspective, and assist
in designing sustainable ML-enabled systems. To enhance transparency and
facilitate their widespread use and extension, we make the tactics available
online in easily consumable formats. Wide-spread adoption of these tactics has
the potential to substantially reduce the societal impact of ML-enabled systems
regarding their energy and carbon footprint.Comment: Accepted for publication at the 2024 International Conference on
Software Engineering - Software Engineering in Society (ICSE-SEIS'2024
Technical Debt Management: The Road Ahead for Successful Software Delivery
Technical Debt, considered by many to be the 'silent killer' of software
projects, has undeniably become part of the everyday vocabulary of software
engineers. We know it compromises the internal quality of a system, either
deliberately or inadvertently. We understand Technical Debt is not all
derogatory, often serving the purpose of expediency. But, it is associated with
a clear risk, especially for large and complex systems with extended service
life: if we do not properly manage Technical Debt, it threatens to "bankrupt"
those systems. Software engineers and organizations that develop
software-intensive systems are facing an increasingly more dire future state of
those systems if they do not start incorporating Technical Debt management into
their day to day practice. But how? What have the wins and losses of the past
decade of research and practice in managing Technical Debt taught us and where
should we focus next? In this paper, we examine the state of the art in both
industry and research communities in managing Technical Debt; we subsequently
distill the gaps in industrial practice and the research shortcomings, and
synthesize them to define and articulate a vision for what Technical Debt
management looks like five years hence.Comment: 16 page
- …