Resultados de búsqueda para Systematic Mapping Study

Context: Tertiary studies in software engineering (TS@SE) are widely used to synthesise evidence on a research topic systematically. As part of their protocol, TS@SE define inclusion and exclusion criteria (IC/EC) aimed at selecting those secondary studies (SS) to be included in the analysis. Aims: To provide a state of the art on the definition and application of IC/EC in TS@SE, and from the results of this analysis, we outline an emerging framework, TSICEC, to be used by SE researchers. Method: To provide the state of the art, we conducted a systematic mapping (SM) combining automatic search and snowballing over the body of SE scientific literature, which led to 50 papers after application of our own IC/EC. The extracted data was synthesised using content analysis. The results were used to define a first version of TSICEC. Results: The SM resulted in a coding schema, and a thorough analysis of the selected papers on the basis of this coding. Our TSICEC framework includes guidelines for the definition of IC/EC in TS@SE. Conclusion: This paper is a step forward establishing a foundation for researchers in two ways. As authors, understanding the different possibilities to define IC/EC and apply them to select SS. As readers, having an instrument to understand the methodological rigor upon which TS@SE may claim their findings.

Context. Quality requirements (QRs) describe the desired quality of software, and they play an important role in the success of software projects. In agile software development (ASD), QRs are often ill-defined and not well addressed due to the focus on quickly delivering functionality. Rapid software development (RSD) approaches (e.g., continuous delivery and continuous deployment), which shorten delivery times, are more prone to neglect QRs. Despite the significance of QRs in both ASD and RSD, there is limited synthesized knowledge on their management in those approaches.Objective.This study aims to synthesize state-of-the-art knowledge about QR management in ASD and RSD, focusing on three aspects: bibliometric, strategies, and challenges.Research method.Using a systematic mapping study with a snowballing search strategy, we identified and structured the literature on QR management in ASD and RSD.Results.We found 156 primary studies: 106 are empirical studies, 16 are experience reports, and 34 are theoretical studies. Security and performance were the most commonly reported QR types. We identified various QR management strategies: 74 practices, 43 methods, 13 models, 12 frameworks, 11 advices, 10 tools, and 7 guidelines. Additionally, we identified 18 categories and 4 non-recurring challenges of managing QRs. The limited ability of ASD to handle QRs, time constraints due to short iteration cycles, limitations regarding the testing of QRs and neglect of QRs were the top categories of challenges.Conclusion.Management of QRs is significant in ASD and is becoming important in RSD. This study identified research gaps, such as the need for more tools and guidelines, lightweight QR management strategies that fit short iteration cycles, investigations of the link between QRs challenges and technical debt, and extension of empirical validation of existing strategies to a wider context. It also synthesizes QR management strategies and challenges, which may be useful for practitioners.

The automation of robotic processes has been experiencing an increasing trend of interest in recent times. However, most of literature describes only theoretical foundations on RPA or industrial results after implementing RPA in specific scenarios, especially in finance and outsourcing. This paper presents a systematic mapping study with the aim of analyzing the current state-of-the-art of RPA and identifying existing gaps in both, scientific and industrial literature. Firstly, this study presents an in-depth analysis of the 54 primary studies which formally describe the current state of the art of RPA. These primary studies were selected as a result of the conducting phase of the systematic review. Secondly, considering the RPA study performed by Forrester, this paper reviews 14 of the main commercial tools of RPA, based on a classification framework defined by 48 functionalities and evaluating the coverage of each of them. The result of the study concludes that there are certain phases of the RPA lifecycle that are already solved in the market. However, the Analysis phase is not covered in most tools. The lack of automation in such a phase is mainly reflected by the absence of technological solutions to look for the best candidate processes of an organization to be automated. Finally, some future directions and challenges are presented.

Design Smells are indicators of situations that negatively affect software quality attributes such as understandability, testability, extensibility, reusability, and maintainability in general. Improving maintainability is one of the cornerstones of making software evolution easier. Hence, Design Smell Detection is important in helping developers when making decisions that can improve software evolution processes. After a long period of research, it is important toorganize the knowledge produced so far and to identify current challenges and future trends. In this paper, we analyze 18 years of research into Design Smell Detection. There is a wide variety of terms that have been used in the literature to describe concepts which are similar to what we have defined as «Design Smells», such as design defect, design flaw, anomaly, pitfall, antipattern, and disharmony. The aim of this paper is to analyze all these terms and include them in the study. We have used the standard systematic literature review method based on a comprehensive set of 395 articles published in different proceedings, journals, and book chapters. We present the results in different dimensions of Design Smell Detection, such as the type or scope of smell, detection approaches, tools, applied techniques, validation evidence, type of artifact in which the smell is detected, resources used in evaluation, supported languages, and relation between detected smells and software quality attributes according to a quality model. The main contributions of this paper are, on the one hand, the application of domain modeling techniques to obtain a conceptual model that allows the organization of the knowledge on Design Smell Detection and a collaborative web application built on that knowledge and, on the other, finding how tendencies have moved across different kinds of smell detection, as well as different approaches and techniques. Key findings for future trendsinclude the fact that all automatic detection tools described in the literature identify Design Smells as a binary decision (having the smell or not), which is an opportunity to evolve to fuzzy and prioritized decisions. We also find that there is a lack of human experts and benchmark validation processes, as well as demonstrating that Design Smell Detection positively influences quality attributes.

Artículo relevante. Leticia Montalvillo, Oscar Díaz: Requirement-driven evolution in software product lines: A systematic mapping study. Journal of Systems and Software Volume 122, December 2016, Pages 110-143, COMPUTER SCIENCE, SOFTWARE ENGINEERING, IF: 1,424, Posición: (24/106), Cuartil: Q1. DOI http://dx.doi.org/10.1016/j.jss.2016.08.053

Antecedentes. La creciente importancia del Open Source Software (OSS) ha llevado a los investigadores a estudiar cómo los procesos OSS difieren de los procesos de la ingeniería del software tradicional. Objetivo. Determinar las diferencias y similitudes entre las actividades del proceso de mantenimiento seguido por la comunidad OSS y el establecido por el estándar IEEE 1074:2006. Método. Para conocer las actividades que conforman el proceso de desarrollo OSS realizamos un Systematic Mapping Study. Posteriormente, realizamos un emparejamiento entre las actividades del estándar IEEE 1074:2006 con las actividades del proceso OSS. Resultados. Encontramos un total de 22 estudios primarios. De estos estudios, el 73% contaban con actividades relacionadas con el proceso de mantenimiento. Conclusiones. El proceso de mantenimiento tradicional del software no encaja con lo que ocurre en la comunidad OSS. En su lugar, puede ser mejor caracterizar la dinámica general de la evolución OSS como reinvención. Esta reinvención emerge continuamente de la adaptación, aprendizaje, y mejora de las funcionalidades y calidad del OSS. Los proyectos OSS evolucionan a través de mejoras menores donde participan tanto usuarios como desarrolladores.