Journal of Software Engineering Research and Development

Studying the Impact of CI/CD Adoption on Atoms of Confusion Distribution and Prevalence in Open-Source Projects

2024-05-14T19:33:07+00:00

Atoms of Confusion (AoC) are indivisible code patterns that may confuse developers when trying to understand them, and that have less confusing equivalent patterns. Previous works suggest it is a good practice to avoid them. While there are studies on AoC relating them to bugs, there is not much about their relationship with the practices of Continuous Integration and Continuous Delivery (CI/CD). Since CI/CD is generally praised as a group of good practices, related to better code being released reliably and faster to clients, there is a possibility that the presence of CI/CD would also impact the presence of AoC, possibly making them less prevalent since they can be problematic to development processes. To clarify this relationship, we analyzed 10 open-source long-lived Java libraries and 10 open-source Java projects for Android, to see if there was any difference in the AoC rate, diffusion, and density before and after the implementation of CI/CD when comparing each project, the average total. We also analyzed the atoms separately, checking for the most and least prevalent. Our results show the metrics have considerably changed for all projects when checked separately, and less so on average, but we could not find a statistically relevant relationship between most of these changes and CI/CD. We found a significant relation when checking the growth rate on one of the metrics. We also found that the most prevalent atom is the Logic as Control Flow, and the least is the Arithmetic as Logic.

From Textual to Formal Requirements: A Case Study Using Spectra in Safety-Critical Systems Domain

2024-07-23T12:30:02+00:00

The requirements specification of any system is crucial for the correct development of the systems and software. It becomes even more relevant in the development of safety-critical systems (SCS). This paper aims to investigate the process of transforming requirements specification written in natural language (textual requirements) to requirements specification written in Spectra language (formal requirements). Spectra is a formal language built to specify reactive systems. The case study carried out in this research focuses on the requirements specification of a low-cost insulin infusion pump. The requirements were initially specified in natural language and later transformed into Spectra language. During the transformation process, we investigated the potential use of the Spectra language in the phase of requirements specification, identifying the difficulties in the transformation process and its advantages, taking into account the software engineer's point of view.

The Most In-Demand Soft Skills for QA Professionals in Brazil

2024-07-22T19:06:35+00:00

Background: Software quality assurance (QA) is carried out in tandem with software development. Essentially, QA activities are conducted in hopes of assessing the extent to which a software product aligns with predefined requirements. Although QA includes highly technical tasks, much like software development, it remains largely a human-centered endeavor. Consequently, soft skills can play a significant role in contributing to the success of a project and product quality, as well as boosting the productivity of QA professionals. Aim: Our objective is to investigate: (i) the most sought-after soft skills for QA professionals, (ii) potential correlations among these in-demand soft skills, (iii) variations in soft skill requirements based on the seniority level of positions, and (iv) potential differences in soft skills expectations according to the size of the hiring companies. Our analysis is centered around organizations in Brazil. Method: We looked for soft skills in 2,164 job advertisements from Brazilian companies. Our data extraction process followed an inductive, data-driven approach that included both manual and automated steps. Results: approximately 91% of the job advertisements list at least one soft skill. We identified 32 soft skills in our study, with five soft skills standing out as the most sought-after among them: communication-related skills, planning, innovation, collaboration, and written communication. Notably, companies of various sizes consistently prioritize communication-related and planning skills, deeming them crucial for QA professionals. Conclusions: Our findings underscore the critical importance of five soft skills: communication-related skills, planning, innovation, collaboration, and written communication. The results of our study hold potential value for QA professionals in Brazil seeking to enhance their employability and provide insights to those tasked with staffing, curriculum design, and professional development.

Investigating Conditioning Factors for Transparency in Software Ecosystems

2024-06-02T22:57:08+00:00

Software Ecosystems (SECO) are a set of actors interacting with a distributed market centered on a common technological platform to develop products and services. In this context, transparency allows third-party developers to learn processes and elements that integrate the SECO platform. This non-functional requirement impacts the coordination of developers and the management of requirements that emerge in SECO. Although it is an essential requirement, there is still a lack of a roadmap on what constitutes transparency in SECO. Thus, this article aims to characterize conditioning factors for transparency in SECO. To do so, we conducted a systematic mapping study (SMS) and a field study to identify and analyze such factors. After investigating the literature, we selected 23 studies to analyze the state-of-the-art about transparency in SECO. Next, we conducted interviews with 16 software developers to characterize the importance of conditioning factors for transparency identified in their interaction with GitHub, a platform to support project-based ecosystems. As results, we obtained a comprehensive view of solutions, conditioning factors, processes, and concerns related to transparency in SECO, whose discussion is centered on three main topics: access to information, communication channels, and requirements engineering. We also present a conceptual framework that structures all the knowledge about transparency in SECO obtained in both studies. Regarding implications for academia and industry, researchers can find a conceptual framework to be used as a foundation for systematic approaches to understanding transparency in SECO. Practitioners can find solutions and conditioning factors that help them to adopt initiatives to contribute to the open flow of information in a SECO and, thus, attract and engage new actors to a common technological platform.

How code composition strategies affect merge conflict resolution?

2024-07-05T01:51:23+00:00

Software developers often need to combine their contributions. This operation is called merge. When the contributions happen at the same physical region in the source code, the merge is marked as conflicting and must be manually resolved by the developers. Existing studies explore why conflicts happen, their characteristics, and how they are resolved. This paper investigates a subset of merge conflicts, which may be resolved using a combination of existing lines. We analyze 10,177 conflict chunks of popular projects that were resolved by combining existing lines, aiming at characterizing and finding patterns frequently addressed by developers to resolve them. We found that these conflicting chunks and their resolutions are usually small (they have a median of 6 LOC and 3 LOC, respectively). Moreover, 98.6% of the analyzed resolutions preserve the order of the lines in the conflicting chunks. We also found that 72.7% of the chunk resolutions do not interleave lines from different contributions more than once. Finally, developers prefer to resolve conflicts containing only Import statements using lines from the local version of the conflict. When used as heuristics for automatic merge resolution, these findings could reduce the search space by 94.7%, paving the road for future search-based software engineering tools for this problem.

Uniqueness of suspiciousness scores: towards boosting evolutionary fault localization

2024-06-19T08:02:27+00:00

Context. Software is subject to the presence of faults, which impacts its quality as well as production and maintenance costs. Evolutionary fault localization uses data from the test activity (test spectra) as a source of information about defects, and its automation aims to obtain better accuracy and lower software repair cost. Motivation. Our analysis identified that the test spectra commonly used in research exhibit a high ratio of sample repetition, which impairs the training and evolution of Genetic Programming (GP) evolved heuristics. Problem. We investigate whether evolutionary training based on the uniqueness of suspiciousness scores can increase the ability to find software faults (defects), even in repeat-sample scenarios. Specifically, we examine whether the GP-evolved heuristic, which is based on the distinguishability of program elements in terms of faults, is really competitive. Methodology. The investigation formalized hypotheses, introduced three training strategies to guide the research and carried out an experimental evaluation, aiming to reach conclusions regarding the assessment of research questions and hypotheses. Analysis. The results have shown the competitiveness of all the proposed training strategies through evaluation metrics commonly used in the research field. Conclusion. Statistical analyses confirmed that the uniqueness of suspiciousness scores guides the generation of superior heuristics for fault localization.

Hearing the Voice of Software Practitioners on Technical Debt Monitoring: Understanding Monitoring Practices and the Practices' Avoidance Reasons

2024-07-15T17:49:34+00:00

Context. Technical debt (TD) monitoring allows software professionals to track the evolution of debt incurred in their projects. The technical literature has listed several practices used in the software industry to monitor indebtedness. However, there is limited evidence on the use and on the reasons to avoid using these practices. Aims. This work aims to investigate, from the point of view of software practitioners, the practices used for monitoring TD items, and the practice avoidance reasons (PARs) curbing the monitoring of TD items. Method. We analyze quantitatively and qualitatively a set of 653 answers collected with a family of industrial surveys distributed in six countries. Results. Practitioners are prone to monitor TD items, revealing 46 practices for monitoring the debt and 35 PARs for explaining TD non-monitoring. Both practices and PARs are strongly associated with planning and management issues. The study also shows the relationship found among practices, PARs and types of debt and presents a conceptual map that relates practices and PARs with their categories. Conclusion. The results of this study add to a practitioners’ capability to monitor TD items by revealing the monitoring practices, PARs and their relationship with different TD types.

Do you think there is no gender inequality in Software Engineering? Perhaps you should reconsider your opinion

2024-05-14T12:15:07+00:00

Context: While researching gender inequality in software development teams, men consistently outnumber women among practitioners. Various perspectives, including gender bias and strategies to enhance diversity within development teams, have been explored by researchers in recent years. However, there is a significant gap in the existing literature, as the majority of studies focus on the perception of women practitioners, leaving the experiences of the larger demographic—men in the software development workforce—underrepresented and less examined. Goal: This study explores the perspectives of men regarding gender inequality within software development teams and compares their experiences in software development to those of women. Method: The study comprised two phases: Investigation and Confirmation. In the Investigation Phase, we distributed a survey questionnaire to gather a substantial number of responses. The subsequent Confirmation Phase aimed to validate the collected data. The Investigation phase involved 217 participants responding to a questionnaire with 27 questions. Subsequently, in the Confirmation Phase, two focus group sessions were held: one with ten Brazilian male practitioners and another with eight male practitioners working in five different European countries. The collected data was analyzed using a mixture of quantitative and qualitative techniques, incorporating graphical representations, percentages, and the grounded theory methodology. Results: Our results indicate that the majority of men surveyed do not perceive any sexist behavior among their team members, and they express satisfaction with their job performance. Furthermore, their primary recommendations to enhance their participation in software development projects include providing training courses and fostering improved interaction among team members. Furthermore, we did not find any substantial difference between the results we got during the Investigation and Confirmation phases. Conclusions: Men practitioners in software development teams encounter distinct barriers and challenges compared to their female counterparts. Moreover, they perceive that women’s limited presence in software development is attributed to a perceived lack of affinity and knowledge in coding.

A portal to catalog worked examples extracted from open source software projects to support the teaching of Software Engineering

2024-05-14T12:06:51+00:00

Software Engineering is continually evolving, with new techniques, tools, and processes emerging to enhance software development. However, finding real-life examples that reflect this evolution can be challenging for instructors. Open Source Software (OSS) projects offer a valuable resource in this context, as they provide access to actual development projects and environments. Despite their potential, integrating these projects into the classroom involves several hurdles, including selecting suitable projects, preparing classes, and adapting to the open-source environment. This study aims to alleviate the challenges instructors face in adopting OSS projects for teaching Software Engineering. We developed an open portal to catalog worked examples from OSS projects, thereby supporting instructors in demonstrating real-world Software Engineering concepts and techniques. Utilizing Design Science Research, we followed the Relevance, Design, and Rigor cycles to construct this solution. The primary contribution of this work is the portal itself, which helps reduce the time instructors spend searching for relevant materials and resources. Additionally, we proposed a template to create, structure, and catalog these examples and developed guidelines to assist instructors in using the worked examples effectively. We conducted a series of studies with experienced Software Engineering instructors, which indicated that the portal could significantly mitigate the challenges associated with sourcing and updating real examples. The effectiveness of the examples was also assessed based on student perceptions, revealing that exposure to worked examples from OSS projects could engage students with real projects and challenges.

Technical Debt Tools: a Survey and an Empirical Evaluation

2024-03-30T14:47:56+00:00

Background: The life cycle of a technical debt from its identification to its payment is long and may include several activities, such as identification and management. There is a lot of research in the literature to address different sets of these activities by different means. Specifically, several tools have already tackled such technical debt identification problems. However, only a few studies empirically assessed those tools. Method: In this article, we carried a multi-method research. We first surveyed the literature for the technical debt tools available and then we evaluated two of them, which aim at identification of self-admitted technical debt. They are named eXcomment e DebtHunter. Results: We found 97 tools employing different approaches to support technical debt life cycle management. Most of them (59%) address only the high level task of management, instead of actually identify and pay the debt. Additionally, as for our empirical evaluation of tools, our results show that DebtHunter found only 7% of debt identified by eXcomment. In the other way around, eXcomment found 19.9% the debt found by DebtHunter. Besides, both tools have low levels of precision and recall. Conclusion: It is hard to find technical debt through comments. Both tools can find indicators of debt items, however they struggle on the precision and recall. In fact, although eXcomment and DebtHunter diverge on the amount of debt identified, they seem to converge with regard to the type of debt present in the system under evaluation.

What Do Flutter Developers Ask About? An Empirical Study on Stack Overflow Posts

2024-02-15T15:50:46+00:00

Since Google launched Flutter, an open-source framework, in 2017, many companies and software developers have turned to its use owing to its cross-platform feature. Other attractive features include hot reloading, a rich widget library, and improved performance compared to other cross-platform frameworks. Despite the rise in the use and adoption of the framework, little has been done to understand developers’ challenges. This study aims to understand what Flutter developers post on Stack Overflow – a popular Q&A website for developers. Analyzing such posts would help us understand the challenges faced by Flutter developers. To meet this goal, the study used a topic modeling approach to analyze all “flutter” tagged posts between 2019 and 2023. This study revealed state management, widgets, navigation, packages, and persistence as some areas developers face challenges. Further, the study established that there is a growth in the number of Flutter-related posts and developers. While the Flutter framework is promising for companies and software developers, this study points out areas where Flutter trainers and developers should emphasize. Flutter Framework developers should provide more documentation and support as the language matures.

Overcoming Obstacles in Global Requirements Elicitation: A Multicultural Perspective

2024-01-24T21:33:43+00:00

Nowadays, multiculturality is the norm. No country or organization is monocultural. Little previous work has been carried out specifically on how culture influences multicultural requirements elicitation. In this paper we look at the importance of culture with the aim of increasing understanding of the role of cultural differences in differences in multicultural requirements elicitation. This paper starts with a literature review demonstrating the importance of raising awareness and understanding of cultural diversity which often causes conflict and mistrust which can lead to failure of any project. The ultimate aim is the improvement of the whole systems development process as well as the resulting products and services. We present the development and validation of the Multicultural Requirements Elicitation [McRE) framework which helps prevent or at least minimize prejudice, conflicts, misunderstandings and misinterpretations arising from cultural differences. McRE is an instrument for carrying out processes, defining the purpose of these processes and the methods that must be used, as well practical suggestions for raising awareness of cultural diversity and reflecting on unconscious bias. Additionally, McRE suggests relevant training and learning. Finally, it advocates prevention and mitigation actions. The rationale and results from the validation of the framework by experts from industry and academia are presented. The validation provided strong indications that the McRE framework is both necessary and suitable for multicultural requirements elicitation in the software development process but also in other domains.

On the Effectiveness of Trivial Refactorings in Predicting Non-trivial Refactorings

2023-12-19T13:40:45+00:00

Refactoring is the process of restructuring source code without changing the external behavior of the software. Refactoring can bring many benefits, such as removing code with poor structural quality, avoiding or reducing technical debt, and improving maintainability, reuse, or code readability. Although there is research on how to predict refactorings, there is still a clear lack of studies that assess the impact of operations considered less complex (trivial) to more complex (non-trivial). In addition, the literature suggests conducting studies that invest in improving automated solutions through detecting and correcting refactoring. This study aims to identify refactoring activity in non-trivial operations through trivial operations accurately. For this, we use classifier models of supervised learning, considering the influence of trivial refactorings and evaluating performance in other data domains. To achieve this goal, we assembled 3 datasets totaling 1,291 open-source projects, extracted approximately 1.9M refactoring operations, collected 45 attributes and code metrics from each file involved in the refactoring and used the algorithms Decision Tree, Random Forest, Logistic Regression, Naive Bayes and Neural Network of supervised learning to investigate the impact of trivial refactorings on the prediction of non-trivial refactorings. For this study, we contextualize the data and call context each experiment configuration in which it combines trivial and non-trivial refactorings. Our results indicate that: (i) Tree-based models such as Random Forest, Decision Tree, and Neural Networks performed very well when trained with code metrics to detect refactoring opportunities. However, only the first two were able to demonstrate good generalization in other data domain contexts of refactoring; (ii) Separating trivial and non-trivial refactorings into different classes resulted in a more efficient model. This approach still resulted in a more efficient model even when tested on different datasets; (iii) Using balancing techniques that increase or decrease samples may not be the best strategy to improve models trained on datasets composed of code metrics and configured according to our study.

Investigating the Social Representations of Harmful Code

2024-02-09T03:22:08+00:00

Context. Harmful Code denotes code snippets that harm the software quality. Several characteristics can cause this, from characteristics of the source code to external issues. By example, one might associate Harmful Code with the introduction of bugs, architecture degradation, and code that is hard to comprehend. However, there is still a lack of knowledge on which code issues are considered harmful from the perspective of the software developers community. Goal. In this work, we investigate the social representations of Harmful Code among a community of software developers composed of Brazilian postgraduate students and professionals from the industry. Method. We conducted free association tasks with members from this community for characterizing what comes to their minds when they think about Harmful Code. Then, we compiled a set of associations that compose the social representations of Harmful Code. Results. We found that the investigated community strongly associates Harmful Code with a core set of undesirable characteristics of the source code, such as bugs and different types of smells. Based on these findings, we discuss each one of them to try to understand why those characteristics happen. Conclusion. Our study reveals the main characteristics of Harmful Code by a community of developers. Those characteristics can guide researchers on future works to better understand Harmful Code.

Reducing Manual Efforts in Equivalence Analysis in Mutation Testing

2024-02-02T20:26:54+00:00

Mutation testing has attracted a lot of interest because of its reputation as a powerful adequacy criterion for test suites and for its ability to guide test case generation. However, the presence of equivalent mutants hinders its usage in industry. The Equivalent Mutant Problem has already been proven undecidable, but manually detecting equivalent mutants is an error-prone and time-consuming task. Thus, solutions, even partial, can help reduce this cost. To minimize this problem, we introduce an approach to suggest equivalent mutants. Our approach is based on automated behavioral testing, which consists of test cases based on the behavior of the original program. We perform static analysis to automatically generate tests for the entities impacted by the mutation. For each mutant analyzed, our approach can suggest the mutant as equivalent or non-equivalent. In the case of non-equivalent mutants, our approach provides a test case capable of killing it. For the equivalent mutants suggested, we also provide a ranking of mutants with a strong or weak chance of the mutant being indeed equivalent. In our previous work, we evaluated our approach against a set of 1,542 mutants manually classified in previous work as equivalents and non-equivalents. We noticed that the approach effectively suggests equivalent mutants, reaching more than 96% of accuracy in five out of eight subjects studied. Compared with manual analysis of the surviving mutants, our approach takes a third of the time to suggest equivalents and is 25 times faster to indicate non-equivalents. This extended article delves deeper into our evaluation. Our focus is on discerning the specific characteristics of mutants that our approach erroneously classified as equivalent, thereby producing false positives. Furthermore, our investigation delves into a comprehensive analysis of the mutation operators, providing essential insights for practitioners seeking to improve the accuracy of equivalent mutant detection and effectively mitigate associated costs.

Ethics: What is the Brazilian Software Engineering Research Scenario?

2023-10-11T23:35:55+00:00

Background: Ethics is the theory or science of the moral behavior of humans in society. Traditionally, we value “unethical” actions that go against determining morality in a specific context. One of the sub-domains of Ethics is Computational Ethics, which deals with ethical dilemmas that are strictly related to computational issues. Dilemmas in this area involve privacy, improper access, intellectual property, digital norms and laws, power, socio-technical aspects (such as gender discrimination), and robotics, among others. In this context, “Software Engineering” and “Software” are different objects. Engineering is an act, a practice, as also coding, programming, and software reuse. As with any act, moral and subsequent ethical considerations are appropriate. We characterize software as an object of concrete reality, as a sociotechnical system formed by a technical artifact, human aspect, and procedural aspect. This assumption will form the main base discussion of ethics and morals in Software Engineering in this paper. Objective: The goal of this paper is to unveil the Brazilian Software Engineering ethics panorama. Method: We follow the rigor of, and inspired by, a Systematic Literature Review (SLR) protocol to answer the question: how does ethics explicitly permeate the Brazilian Software Engineering publications between the last thirteen years (2010 and 2022)? Results: After analyzing 1529 papers through the research protocol, 175 (≈11%) presented some explicit occurrence of ethical aspects. The occurrence was relevant in only 7 papers (≈0.4%), exposing a shallow scenario on ethical or moral aspects. Conclusions: If Ethics is a topic considered important to deliberate, research or discuss, this did not occur significantly in the Brazilian Software Engineering research scenario since 2010. With this result in mind, we discussed parallel terms and concepts to enrich the contribution of the qualitative synthesis.

Using Third-Party Components’ Metadata to Analyze Cross-cutting Concerns

2023-09-22T16:38:56+00:00

Context: Modularity is a key concept in software development. Well-modularized systems are easier to maintain and evolve, but achieving good modularity is difficult. Concerns that are important, but not central to a systems' main business rules, frequently end up scattered and entangled throughout several software modules. Those so called cross-cutting concerns are a major source of loss of modularity and code decay in software systems. Motivation: Studies on cross-cutting concerns often resort to manual identification of concerns, but manual identification is effort demanding, does not scale, and tends to be imprecise. Automatic approaches are therefore very attractive when the codebase is extensive. In modern systems, developers implement modules to address central business rules, but they tend to add third-party components in the codebase to materialize concerns related to other secondary aspects. Logging, database access, and tests automation are examples of concerns that are usually implemented with the help of imported components and are prone to scatter and tangle throughout the codebase. Aims: This paper proposes a method to track this type of cross-cutting concern. Our work takes advantage of the addition of metadata about components to track them. The method scales by automating the identification and analysis of concerns scattered throughout the software codebase. We define a new metric, Dedication to Concern (DtC), to measure how much source code modules focus on implementing the identified concerns. Working Method: We describe our method to mine cross-cutting concerns from the metadata related to the use of components. The method is instantiated as a tool, architectural knowledge suite (AKS). The tool is used to analyze concerns in a set of large Java projects. The results are used to feed an action research study, during which software development specialists analyze the AKS outputs to evaluate and evolve the method. Conclusion: The semi-automated approach is feasible and scalable, and can be used to analyze secondary concerns that are currently being imported into modern software systems via third-party components.