3,349 research outputs found
A Study on Architectural Smells Prediction
Architectural smells can be detrimental to the system maintainability, evolvability and represent a source of architectural debt. Thus, it is very important to be able to understand how they evolved in the past and to predict their future evolution. In this paper, we evaluate if the existence of architectural smells in the past versions of a project can be used to predict their presence in the future. We analyzed four Java projects in 295 Github releases and we applied for the prediction four different supervised learning models in a repeated cross-validation setting. We found that historical architectural smell information can be used to predict the presence of architectural smells in the future. Hence, practitioners should carefully monitor the evolution of architectural smells and take preventative actions to avoid introducing them and stave off their progressive growth.</p
Exploring Maintainability Assurance Research for Service- and Microservice-Based Systems: Directions and Differences
To ensure sustainable software maintenance and evolution, a diverse set of activities and concepts like metrics, change impact analysis, or antipattern detection can be used. Special maintainability assurance techniques have been proposed for service- and microservice-based systems, but it is difficult to get a comprehensive overview of this publication landscape. We therefore conducted a systematic literature review (SLR) to collect and categorize maintainability assurance approaches for service-oriented architecture (SOA) and microservices. Our search strategy led to the selection of 223 primary studies from 2007 to 2018 which we categorized with a threefold taxonomy: a) architectural (SOA, microservices, both), b) methodical (method or contribution of the study), and c) thematic (maintainability assurance subfield). We discuss the distribution among these categories and present different research directions as well as exemplary studies per thematic category. The primary finding of our SLR is that, while very few approaches have been suggested for microservices so far (24 of 223, ?11%), we identified several thematic categories where existing SOA techniques could be adapted for the maintainability assurance of microservices
Can Network Analysis Techniques help to Predict Design Dependencies? An Initial Study
The degree of dependencies among the modules of a software system is a key
attribute to characterize its design structure and its ability to evolve over
time. Several design problems are often correlated with undesired dependencies
among modules. Being able to anticipate those problems is important for
developers, so they can plan early for maintenance and refactoring efforts.
However, existing tools are limited to detecting undesired dependencies once
they appeared in the system. In this work, we investigate whether module
dependencies can be predicted (before they actually appear). Since the module
structure can be regarded as a network, i.e, a dependency graph, we leverage on
network features to analyze the dynamics of such a structure. In particular, we
apply link prediction techniques for this task. We conducted an evaluation on
two Java projects across several versions, using link prediction and machine
learning techniques, and assessed their performance for identifying new
dependencies from a project version to the next one. The results, although
preliminary, show that the link prediction approach is feasible for package
dependencies. Also, this work opens opportunities for further development of
software-specific strategies for dependency prediction.Comment: Accepted at ICSA 201
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
A Domain Analysis to Specify Design Defects and Generate Detection Algorithms
Quality experts often need to identify in software systems design defects, which are recurring design problems, that hinder development\ud
and maintenance. Consequently, several defect detection approaches\ud
and tools have been proposed in the literature. However, we are not\ud
aware of any approach that defines and reifies the process of generating\ud
detection algorithms from the existing textual descriptions of defects.\ud
In this paper, we introduce an approach to automate the generation\ud
of detection algorithms from specifications written using a domain-specific\ud
language. The domain-specific is defined from a thorough domain analysis.\ud
We specify several design defects, generate automatically detection\ud
algorithms using templates, and validate the generated detection\ud
algorithms in terms of precision and recall on Xerces v2.7.0, an\ud
open-source object-oriented system
Community Smells -- The Sources of Social Debt: A Systematic Literature Review
Context: Social debt describes the accumulation of unforeseen project costs
(or potential costs) from sub-optimal software development processes. Community
smells are sociotechnical anti-patterns and one source of social debt that
impact software teams, development processes, outcomes, and organizations.
Objective: To provide an overview of community smells based on published
literature, and describe future research. Method: We conducted a systematic
literature review (SLR) to identify properties, understand origins and
evolution, and describe the emergence of community smells. This SLR explains
the impact of community smells on teamwork and team performance. Results: We
include 25 studies. Social debt describes the impacts of poor socio-technical
decisions on work environments, people, software products, and society. For
each of the 30 identified community smells, we provide a description,
management approaches, organizational strategies, and mitigation effectiveness.
We identify five groups of management approaches: organizational strategies,
frameworks, models, tools, and guidelines. We describe 11 properties of
community smells. We develop the Community Smell Stages Framework to concisely
describe the origin and evolution of community smells. We describe the causes
and effects for each community smell. We identify and describe 8 types of
causes and 11 types of effects for community smells. Finally, we provide 8
Sankey diagrams that offer insights into threats the community smells pose to
teamwork factors and team performance. Conclusion: Community smells explain the
influence work conditions have on software developers. The literature is scarce
and focuses on a small number of community smells. Thus, community smells still
need more research. This review organizes the state of the art about community
smells and provides motivation for future research along with educational
material.Comment: Accepted for publication in Information and Software Technolog
- …