2,257 research outputs found
Are Smell-Based Metrics Actually Useful in Effort-Aware Structural Change-Proneness Prediction? An Empirical Study
Bad code smells (also named as code smells) are symptoms of poor design choices in implementation. Existing studies empirically confirmed that the presence of code smells increases the likelihood of subsequent changes (i.e., change-proness). However, to the best of our knowledge, no prior studies have leveraged smell-based metrics to predict particular change type (i.e., structural changes). Moreover, when evaluating the effectiveness of smell-based metrics in structural change-proneness prediction, none of existing studies take into account of the effort inspecting those change-prone source code. In this paper, we consider five smell-based metrics for effort-aware structural change-proneness prediction and compare these metrics with a baseline of well-known CK metrics in predicting particular categories of change types. Specifically, we first employ univariate logistic regression to analyze the correlation between each smellbased metric and structural change-proneness. Then, we build multivariate prediction models to examine the effectiveness of smell-based metrics in effort-aware structural change-proneness prediction when used alone and used together with the baseline metrics, respectively. Our experiments are conducted on six Java open-source projects with up to 60 versions and results indicate that: (1) all smell-based metrics are significantly related to structural change-proneness, except metric ANS in hive and SCM in camel after removing confounding effect of file size; (2) in most cases, smell-based metrics outperform the baseline metrics in predicting structural change-proneness; and (3) when used together with the baseline metrics, the smell-based metrics are more effective to predict change-prone files with being aware of inspection effort
Technical Debt Prioritization: State of the Art. A Systematic Literature Review
Background. Software companies need to manage and refactor Technical Debt
issues. Therefore, it is necessary to understand if and when refactoring
Technical Debt should be prioritized with respect to developing features or
fixing bugs. Objective. The goal of this study is to investigate the existing
body of knowledge in software engineering to understand what Technical Debt
prioritization approaches have been proposed in research and industry. Method.
We conducted a Systematic Literature Review among 384 unique papers published
until 2018, following a consolidated methodology applied in Software
Engineering. We included 38 primary studies. Results. Different approaches have
been proposed for Technical Debt prioritization, all having different goals and
optimizing on different criteria. The proposed measures capture only a small
part of the plethora of factors used to prioritize Technical Debt qualitatively
in practice. We report an impact map of such factors. However, there is a lack
of empirical and validated set of tools. Conclusion. We observed that technical
Debt prioritization research is preliminary and there is no consensus on what
are the important factors and how to measure them. Consequently, we cannot
consider current research conclusive and in this paper, we outline different
directions for necessary future investigations
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
On the relation between architectural smells and source code changes
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
Security Code Smells in Android ICC
Android Inter-Component Communication (ICC) is complex, largely
unconstrained, and hard for developers to understand. As a consequence, ICC is
a common source of security vulnerability in Android apps. To promote secure
programming practices, we have reviewed related research, and identified
avoidable ICC vulnerabilities in Android-run devices and the security code
smells that indicate their presence. We explain the vulnerabilities and their
corresponding smells, and we discuss how they can be eliminated or mitigated
during development. We present a lightweight static analysis tool on top of
Android Lint that analyzes the code under development and provides just-in-time
feedback within the IDE about the presence of such smells in the code.
Moreover, with the help of this tool we study the prevalence of security code
smells in more than 700 open-source apps, and manually inspect around 15% of
the apps to assess the extent to which identifying such smells uncovers ICC
security vulnerabilities.Comment: Accepted on 28 Nov 2018, Empirical Software Engineering Journal
(EMSE), 201
Managing technical debt: prioritising and quantifying architectural smells
Architectural smells zijn een beruchte schadelijke vorm van ATD die verwijst naar schendingen van bekende ontwerpprincipes die resulteren in ongewenste afhankelijkheden, te grote omvang en overmatige koppeling. Architectural smells hebben een negatieve invloed op de onderhoudbaarheid en evolueerbaarheid van een systeem en maken het moeilijker om wijzigingen aan te brengen en nieuwe functionaliteit toe te voegen. Onderzoekers hebben de afgelopen jaren verschillende soorten architectuurgeuren geïdentificeerd, beschreven en gecategoriseerd. Vervolgens werden verschillende onderzoekstools ontwikkeld om dergelijke geuren automatisch te detecteren op basis van de bron artefacten van een systeem. Vanuit het oogpunt van de praktijk is identificatie alleen niet voldoende om de door architectuurgeuren ontstane technische schuld goed te kunnen beheren. Om de bedreiging die architectuurgeuren vormen voor de onderhoudbaarheid van een systeem goed aan te pakken, hebben praktijkmensen ook ondersteuning nodig voor de prioritering, kwantificering, terugbetaling en monitoring. Helaas is de literatuur over dit onderwerp onvolledig, en ontbreekt de instrumentele ondersteuning voor deze specifieke activiteiten
- …