Logs are vital to understanding a software system’s behavior, often being the only evidence available to investigate failures. Selecting a Log Severity Level (LSL) can be challenging for the following reasons: (i) the absence of knowledge about how logs are used in production, (ii) the lack of understanding of how critical an event is, and (iii) the lack of practical guidelines. This leads to frequent LSL adjustments during software development and evolution. Our goal is to investigate the LSL adjustments between system releases and explore methods to improve LSL classification. We analyzed the log statements from different releases of open-source systems, focusing on their LSL adjustments and examining the commit comments to understand the reasons for the adjustments. Our results show that most adjustments occur at the intersection of development and production environment logs. Furthermore, the main guiding factors for the adjustments are the experience and logging theory. Our contributions are (i) a description of trends and patterns in LSL adjustments and (ii) a set of 24 heuristics to guide the choice, review, and adjustments of LSL. We advise developers to adhere to the LSL purposes, routinely review LSL settings, and remain adaptable to their mutability. • The severity level of log statements can change as the software evolves. • Severity level adjustments occurring between system releases tend to be more experience-oriented rather than based on logging theories. • Avoiding the overproduction of log data is one of the main reasons for adjusting severity levels in the systems investigated. • There is a tendency towards one-degree adjustments with an emphasis on adjustments between the Debug and Info levels. • From our research, we have derived a set of 24 heuristics designed to guide the choice, review, and adjustment of log severity levels.

Modern distributed applications increasingly rely on cloud-native platforms to abstract the complexity of deployment and scalability. As the de facto orchestration standard, Kubernetes enables this abstraction, but its declarative configuration model makes the architectural understanding difficult. Developers, operators, and architects struggle to form accurate mental models from raw manifests, Helm charts, or cluster state descriptions. We introduce KubeDiagrams, an open-source tool that transforms Kubernetes manifests into architecture diagrams. By grounding our design in a user-centered study of real-world visualization practices, we identify the specific challenges Kubernetes users face and map these to concrete design requirements. KubeDiagrams integrates seamlessly with standard Kubernetes artifacts, preserves semantic fidelity to core concepts, and supports extensibility and automation. We detail the tool’s architecture, visual encoding strategies, and extensibility mechanisms. Three case studies illustrate how KubeDiagrams enhances system comprehension and supports architectural reasoning in distributed cloud-native systems. KubeDiagrams addresses concrete pain points in Kubernetes-based DevOps practices and is valued for its automation, clarity, and low-friction integration into real-world tooling environments.

The increasing demand for computational power in big data and machine learning has driven the development of distributed training methodologies. Among these, peer-to-peer (P2P) networks provide advantages such as enhanced scalability and fault tolerance. However, they also encounter challenges related to resource consumption, costs, and communication overhead as the number of participating peers grows. In this paper, we introduce a novel architecture that combines serverless computing with P2P networks for distributed training and present a method for efficient parallel gradient computation under resource constraints.Our findings show a significant enhancement in gradient computation time, with up to a 97.34% improvement compared to conventional P2P distributed training methods. As for costs, our examination confirmed that the serverless architecture could incur higher expenses, reaching up to 5.4 times more than instance-based architectures. It is essential to consider that these higher costs are associated with marked improvements in computation time, particularly under resource-constrained scenarios.Despite the cost-time trade-off, the serverless approach still holds promise due to its pay-as-you-go model. Utilizing dynamic resource allocation, it enables faster training times and optimized resource utilization, making it a promising candidate for a wide range of machine learning applications.

The advent of serverless computing has ushered in notable advancements in distributed machine learning, particularly within parameter server-based architectures. Yet, the integration of serverless features within peer-to-peer (P2P) distributed networks remains largely uncharted. In this paper, we introduce SPIRT, a fault-tolerant, reliable, scalable and secure serverless P2P ML training architecture. designed to bridge this existing gap. Capitalizing on the inherent robustness and reliability innate to P2P systems, we emphasized Intra-peer scalability for concurrent gradient to mitigate communication overhead from increased peer interactions. SPIRT, employs RedisAI for in-database operations, achieves an 82% reduction in model update times. This architecture showcases resilience against peer failures and adeptly manages the integration of new peers. Furthermore, SPIRT ensures secure communication between peers, enhancing the reliability of distributed machine learning tasks. Even in the face of Byzantine attacks, the system’s robust aggregation algorithms maintain high levels of accuracy. These findings illuminate the promising potential of serverless architectures in P2P distributed machine learning, offering a significant stride towards the development of more efficient, scalable, and resilient applications.

Distributed applications running on virtualization- based systems and cloud computing have become popular solutions, allowing developers to focus on application logic rather than dealing with the complexities of distributed systems. However, these applications often become increasingly complex, presenting multiple management challenges. To address this issue, software visualization approaches offer valuable solutions by pro-viding real-time insights into resources and their functionalities, offering a comprehensive overview. This study aims to analyze and evaluate existing software visualization tools for distributed applications on the Kubernetes platform. The objective is to comprehensively examine these tools' features, capabilities, and limitations to understand their effectiveness in visualizing complex distributed systems. Our findings provide valuable insights into the strengths and weaknesses of the available visualization tools, enabling researchers and practitioners to make informed decisions and advancements in software visualization for distributed applications on the Kubernetesplatform. Our research identified eight Kubernetes visualization tools, which were examined and compared based on relevant char-acteristics related to distributed applications and software vi-sualization standards. However, it is worth noting that despite the excellent work done by the community in establishing these first proposals, these tools currently only support, on average, a visualization of 9 % of the total resource types available, as mentioned in the official documentation. Therefore, we propose guidelines followed by a synthesized visualization that can guide further research and development in this area. Our study will assist users in selecting the most suitable Kubernetes visualization tool and encourage researchers and the community to explore new approaches in Kubernetes visualization.

Context: New scientific evidence continuously arises with advances in Software Engineering (SE) research. Conventionally, Systematic Literature Reviews (SLRs) are not updated or updated intermittently, leaving gaps between updates, during which time the SLR may be missing crucial new evidence. Goal: We propose and evaluate a concept and process called Continuous Systematic Literature Review (CSLR) in SE. Method: To elaborate on the CSLR concept and process, we performed a synthesis of evidence by conducting a meta-ethnography, addressing knowledge from varied research areas. Furthermore, we conducted a case study to evaluate the CSLR process. Results: We describe the resulting CSLR process in BPMN format. The case study results provide indications on the importance and preliminary feasibility of applying CSLR in practice to continuously update SLR evidence in SE. Conclusion: The CSLR concept and process provide a feasible and systematic way to continuously incorporate new evidence into SLRs, supporting trustworthy and up-to-date evidence for SLRs in SE.

Context: There are several initiatives to semi-automate the initial selection of studies task for Systematic Literature Reviews (SLR) to reduce effort and potential bias. Objective: We propose a strategy called SCAS-AI to semi-automate the initial selection task. This strategy improves the original SCAS strategy with Artificial Intelligence (AI) resources (fuzzy logic and genetic algorithm) for studies selection. Method: We evaluated the SCAS-AI strategy through a quasi-experiment with SLRs in Software Engineering (SE). Results: In general, the SCAS-AI strategy improved the results achieved using the original SCAS strategy in reducing the effort of the initial selection task. The effort reduction applying SCAS-AI was 39.1%. In addition, the errors percentage was 0.3% for studies automatically excluded (false negative – loss of evidence) and 3.3% for studies automatically included (false positive – evidence later excluded during the full-text reading). Conclusion: The results show the potential of the investigated AI techniques to support the initial selection task for SLRs in SE.

Video-game projects are notorious for having day- one bugs, no matter how big their budget or team size. The quality of a game is essential for its success. This quality could be assessed and ensured through testing. However, to the best of our knowledge, little is known about video-game testing. In this paper, we want to understand how game developers perform game testing. We investigate, through a survey, the academic and gray literature to identify and report on existing testing processes and how they could automate them. We found that game developers rely, almost exclusively, upon manual play-testing and the testers' intrinsic knowledge. We conclude that current testing processes fall short because of their lack of automation, which seems to be the natural next step to improve the quality of games while maintaining costs. However, the current game-testing techniques may not generalize to different types of games.

Context: A tertiary study can be performed to identify related reviews on a topic of interest. However, the elaboration of an appropriate and effective search string to detect secondary studies is challenging for Software Engineering (SE) researchers. Objective: The main goal of this study is to propose a suitable search string to detect secondary studies in SE, addressing issues such as the quantity of applied terms, relevance, recall and precision. Method: We analyzed seven tertiary studies under two perspectives: (1) structure – strings’ terms to detect secondary studies; and (2) field: where searching – titles alone or abstracts alone or titles and abstracts together, among others. We validate our string by performing a twostep validation process. Firstly, we evaluated the capability to retrieve secondary studies over a set of 1537 secondary studies included in 24 tertiary studies in SE. Secondly, we evaluated the general capacity of retrieving secondary studies over an automated search using the Scopus digital library. Results: Our string was capable to retrieve an optimum value of over 90% of the included secondary studies (recall) with a high general precision of almost 60%. Conclusion: The suitable search string for finding secondary studies in SE contains the terms “systematic review”, “literature review”, “systematic mapping”, “mapping study” and “systematic map”.

Context: Searching and selecting relevant evidence is crucial to answer research questions from secondary studies in Software Engineering (SE). The activities of search and selection of studies are labour-intensive, time-consuming and demand automation support. Objective: Our goal is to identify and summarize the state-of-the-art on automation support for searching and selecting evidence for secondary studies in SE. Method: We performed a systematic mapping on existing automating support to search and select evidence for secondary studies in SE, expanding our investigation in a cross-domain study addressing advancements from the medical field. Results: Our results show that the SE field has a variety of tools and Text Classification (TC) approaches to automate the search and selection activities. However, medicine has more well-established tools with a larger adoption than SE. Cross-validation and experiment are the most adopted methods to assess TC approaches. Furthermore, recall and precision are the most adopted assessment metrics. Conclusion: Automated approaches for searching and selecting studies in SE have not been applied in practice by SE researchers. Integrated and easy-to-use automated approaches addressing consolidated TC techniques can bring relevant advantages on workload and time saving for SE researchers who conduct secondary studies.

Communication between practitioners is essential for the system's quality in the DevOps context. To improve this communication, practitioners often use informal diagrams to represent the components of a system. However, as systems evolve, it is a challenge to synchronize diagrams with production environments consistently. Hence, the inconsistency of architectural diagrams can affect communication between practitioner and their understanding of systems. In this paper, we propose the use of system descriptors to improve deployment diagram consistency. We state two main hypotheses: (1) if an architectural diagram is generated from a valid system descriptor, then the diagram is consistent; (2) if a valid system descriptor is generated from an architectural diagram, then the diagram is consistent. We report a case study to explore our hypotheses. We constructed a system descriptor from the Netflix deployment diagram, and we applied our tool to generate a new architectural diagram. Finally, we compare the original and generated diagrams to evaluate our proposal. Our case study shows all Docker compose description elements can be graphically represented in the generated architectural diagram, and the generated diagram does not present inconsistent aspects of the original diagram. Thus, our preliminary results lead to further evaluation in controlled and empirical experiments to test our hypotheses.

Debugging is a relevant task for finding bugs during software development, maintenance, and evolution. During debugging, developers use modern IDE debuggers to analyze variables, step execution, and set breakpoints. Observing IDE debuggers, we find several breakpoint types. However, what are the breakpoint types? The goal of our study is to map the breakpoint types among IDEs and academic literature. Thus, we mapped the gray literature on the documentation of the nine main IDEs used by developers according to the three public rankings. In addition, we performed a systematic mapping of academic literature over 68 articles describing breakpoint types. Finally, we analyzed the developers understanding of the main breakpoint types through a questionnaire. We present three main contributions: (1) the mapping of breakpoint types (IDEs and literature), (2) compiled definitions of breakpoint types, (3) a breakpoint type taxonomy. Our contributions provide the first step to organize breakpoint IDE taxonomy and lexicon, and support further debugging research.

The choice of log severity level can be challenging and cause problems in producing reliable logging data. However, there is a lack of specifications and practical guidelines to support this challenge. In this study, we present a multivocal systematic mapping of log severity levels from literature peer-reviewed, logging libraries, and practitioners' views. We analyzed 19 severity levels, 27 studies, and 40 logging libraries. Our results show redundancy and semantic similarity between the levels and a tendency to converge the levels for a total of six levels. Our contributions help leverage the reliability of log entries: (i) mapping the literature about log severity levels, (ii) mapping the severity levels in logging libraries, (iii) a set of synthesized six definitions and four general purposes for severity levels. We recommend that developers use a standard nomenclature, and for logging library creators, we suggest providing accurate and unambiguous definitions of log severity levels.

More and more software projects are being consolidated into ecosystems to increase their discovery, usability, and usefulness. Some of the most popular ecosystems exist in npmjs, Python Package Indexing, and Apache Maven Repository. It is difficult for developers to relate these projects and use them to their full potential because of their number, the spread and depth of their features, and their intrinsic and accidental complexities. We present a technique—SECO Storms Maker—to capture and present the essential information from projects in an ecosystem to help developers join, use, and contribute to the ecosystem. We generate word-clouds based on the projects’ documentation via tokenization and distribution frequency. We identify relations among projects using grammar patterns scanning after part-of-speech tagging. We put these word-clouds into a graph to ease navigation and exploration. We evaluate our technique by manually building a ground truth and comparing a randomly-selected project with SECO to show its benefits.

Security logs are widely used to monitor data, networks, and computer activities. By analyzing them, security experts can pick out anomalies that reveal the presence of cyber attacks or information leaks and stop them quickly before serious damage occurs. This paper presents a systematic literature review on the use of security logs for data leak detection. Our findings are fourfold: (i) we propose a new classification of information leaks, which uses the GDPR principles; (ii) we identify the twenty most widely used publicly available datasets in threat detection; (iii) we describe twenty types of attacks present in public datasets; and (iv) we describe thirty algorithms used for data leak detection. The selected papers point to many opportunities that can be investigated by researchers interested in contributing to this area of research.

Open Source Software (OSS) has been recognized by the software development community as an effective way to deliver software. Unlike traditional software development, OSS development is driven by collaboration among developers spread geographically and motivated by common goals and interests. Besides this fact, it is recognized by the OSS community the need to understand OSS development process and its activities. Our goal is to investigate the state-of-art about OSS process through conducting a systematic literature review providing an overview of how the OSS community has been investigating OSS process over past years. We identified and summarized OSS process activities and their characteristics and translated them into an OSS macro process using BPMN notation. As a result, we systematically analyzed 33 studies presenting an overview of the OSS process research and a generalized OSS development macro process represented by BPMN notation with a detailed description of each OSS process activity and roles in OSS environment. We conclude that OSS process can be in practice further investigated by researchers. In addition, the presented OSS process can be used as a guide for OSS projects and be adapted according to each OSS project reality. It provides insights to managers and developers who want to improve their development process even in OSS and traditional environments. Finally, recommendations for OSS community regarding OSS process activities are provided.

Context: Systematic Literature Reviews (SLRs) are important instruments for both Software Engineering (SE) practitioners and scientific community. Their value directly depends on their quality and up-to-date results. However, most of the SLRs are outdated and the current scenario on how SLRs are documented does not favor their updating process. Goal: In this scenario, the main goal of this paper is to present an experience report on how to transfer the know-how of SLRs to facilitate their updates. Method: To address this issue, we used a Knowledge Management (KM) model, known as Nonaka-Takeuchi model, and described how we instantiated the Model for SLR update. We use two SLRs updates conducted by us to illustrate some of the knowledge sharing issues. Results: Our examples showed that the introduction of the concept of KM in the SLR update is in fact valuable, especially for sharing tacit knowledge (decisions) taken throughout the review process. Conclusions: We conclude that KM principles can be applied to manage the knowledge generated during the update of SLR.

In Software Engineering, some of the most critical activities are maintenance and evolution. However, to perform both with quality, minimizing impacts and risks, developers need to analyze and identify where the main problems come from previously. In this paper, we introduce DR-Tools Suite, a set of lightweight open-source tools that analyze and calculate source code metrics, allowing developers to visualize the results in different formats and graphs. Also, we define a set of heuristics to help the code analysis. We conducted two case studies (one academic and one industrial) to collect feedback on the tools suite, on how we will evolve the tools, as well as insights to develop new tools that support developers in their daily work.Videos: https://bit.ly/30weexX.

Different from traditional software development, there is little information about the software-engineering process and techniques in video-game development. One popular way to share knowledge among the video-game developers' community is the publishing of postmortems, which are documents summarizing what happened during the video-game development project. However, these documents are written without formal structure and often providing disparate information. Through this paper, we provide developers and researchers with grounded dataset describing software-engineering problems in video-game development extracted from postmortems. We created the dataset using an iterative method through which we manually coded more than 200 postmortems spanning 20 years (1998 to 2018) and extracted 1,035 problems related to software engineering while maintaining traceability links to the postmortems. We grouped the problems in 20 different types. This dataset is useful to understand the problems faced by developers during video-game development, providing researchers and practitioners a starting point to study video-game development in the context of software engineering.

Modern software applications are adapted to different situations (e.g., memory limits, enabling/disabling features, database credentials) by changing the values of configuration options, without any source code modifications. According to several studies, this flexibility is expensive as configuration failures represent one of the most common types of software failures. They are also hard to debug and resolve as they require a lot of effort to detect which options are misconfigured among a large number of configuration options and values, while comprehension of the code also is hampered by sprinkling conditional checks of the values of configuration options. Although researchers have proposed various approaches to help debug or prevent configuration failures, especially from the end users' perspective, this paper takes a step back to understand the process required by practitioners to engineer the run-time configuration options in their source code, the challenges they experience as well as best practices that they have or could adopt. By interviewing 14 software engineering experts, followed by a large survey on 229 Java software engineers, we identified 9 major activities related to configuration engineering, 22 challenges faced by developers, and 24 expert recommendations to improve software configuration quality. We complemented this study by a systematic literature review to enrich the experts' recommendations, and to identify possible solutions discussed and evaluated by the research community for the developers' problems and challenges. We find that developers face a variety of challenges for all nine configuration engineering activities, starting from the creation of options, which generally is not planned beforehand and increases the complexity of a software system, to the non-trivial comprehension and debugging of configurations, and ending with the risky maintenance of configuration options, since developers avoid touching and changing configuration options in a mature system. We also find that researchers thus far focus primarily on testing and debugging configuration failures, leaving a large range of opportunities for future work.

Today, we have to deal with many data (Big data) and we need to make decisions by choosing an architectural framework to analyze these data coming from different area. Due to this, it becomes problematic when we want to process these data, and even more, when it is continuous data. When you want to process some data, you have to first receive it, store it, and then query it. This is what we call Batch Processing. It works well when you process big amount of data, but it finds its limits when you want to get fast (real-time) processing results, such as financial trades, sensors, user session activity, etc. The solution to this problem is stream processing. Stream processing approach consists of data arriving record by record, and rather than storing it, the processing is done as the data arrive. In this paper, we propose an assessment quality model to evaluate and choose stream processing frameworks. We describe briefly different architectural frameworks such as Spark Streaming, Storm, Flink and Samza that address the stream processing. Using our quality model, we present a decision tree to support engineers to choose a framework following the quality aspects. Finally, we evaluate our model doing a case study to Twitter and Netflix streaming; model that will serve as well for engineers, as for future framework designers.

Serverless architecture is emerging more and more popular as the tools are becoming cheap and more accessible. This way of designing an architecture presents many advantages especially for computing intensive and event-driven applications. Stateless functions are the foundation for these types of architectures, and it might cause an impact on the maintainability of the software. In this paper, we statically analyzed 25 open-source projects using serverless architecture to bring out metrics that applies to the different characteristics of software maintainability. We found out that some characteristics are positively impacted whilst some other seems to be negatively impacted. This paper thus provides findings on the current state of the projects’ maintainability using serverless architecture.

In Software Engineering, one of the most important activities is debugging. Debugging is a set of techniques to detect, locate, and correct faults in a computer program. Modern Integrated Development Environments (IDEs), such as Eclipse or Visual Studio, provide infrastructure to support interactive debugging, during which a developer explores the source code of the system under development or maintenance. Although IDEs encourage developers to work collaboratively, debugging is still an individual activity. Furthermore, interactive debugging activity is limited by IDE debugging features that do not store previous debugging sessions. This condition forces developers to repeat debugging execution sessions to review the debugging information. In this paper, using the concept of Swarm Debugging, we present the Sequence Debugging Session View (SDV) tool. The primary goal is to capture the debugging information from a developer IDE (as Visual Studio) and store it. Then, the tool enables developers to retrieve the data in 3D interactive visualization and understand software behavior through the analysis and sharing of debugging session data. The main contribution of the tool is to assist on program comprehension and to reduce effort during software maintenance. To validate the solution, we performed two usage studies in real situations at a software house. The feedback from the evaluation of the tool suggests that the team could be helped on the software arrangement.

Software visualization (SV) allows us to visualize different aspects and artifacts related to software, thus helping engineers understanding its underlying design and functionalities in a more efficient and faster way. In this paper, we conducted a tertiary systematic literature review to identify, classify, and evaluate the current state of the art on software visualization from 48 software visualization secondary studies, following three perspectives: publication trends, software visualization topics and techniques, and issues related to research field. Hence, we summarized the main findings among popular sub-fields of SV, identifying potential research directions and fifteen shared recommendations for developers, instructors and researchers. Our main findings are the lack of rigorous evaluation or theories support to assess SV tools effectiveness, the disconnection between tool design and their scope, and the dispersal of the research community.

There are two well-known difficulties to test and interpret methodologies for mining developer interaction traces: first, the lack of enough large datasets needed by mining or machine learning approaches to provide reliable results; and second, the lack of "ground truth" or empirical evidence that can be used to triangulate the results, or to verify their accuracy and correctness. Moreover, relying solely on interaction traces limits our ability to take into account contextual factors that can affect the applicability of mining techniques in other contexts, as well hinders our ability to fully understand the mechanics behind observed phenomena. The data presented in this paper attempts to alleviate these challenges by providing 600+ hours of developer interaction traces, from which 26+ hours are backed with video recordings of the IDE screen and developer's comments. This data set is relevant to researchers interested in investigating program comprehension, and those who are developing techniques for interaction traces analysis and mining.

Virtual Reality (VR) is a computer technology that holds the promise of revolutionizing the way we live. The release in 2016 of new-generation headsets from Facebook-owned Oculus and HTC has renewed the interest in that technology. Thousands of VR applications have been developed over the past years, but most software developers lack formal training on this technology. In this paper, we propose descriptive information on the state of practice of VR applications' development to understand the level of maturity of this new technology from the perspective of Software Engineering (SE). To do so, we focused on the analysis of 320 VR open source projects from Github to determine which are the most popular languages and engines used in VR projects, and evaluate the quality of the projects from a software metric perspective. To get further insights on VR development, we also manually analyzed nearly 300 questions from Stack Overflow. Our results show that (1) VR projects on GitHub are currently mostly small to medium projects, and (2) the most popular languages are JavaScript and C#. Unity is the most used game engine during VR development and the most discussed topic on Stack Overflow. Overall, our exploratory study is one of the very first of its kind for VR projects and provides material that is hopefully a starting point for further research on challenges and opportunities for VR software development.

One of the most important tasks in software maintenance is debugging. Developers perform debugging to fix faults and implement new features. Usually they use interactive development environments to perform their debugging sessions. To start an interactive debugging session, developers must set breakpoints. Choosing where to set breakpoints is a non-trivial task, yet few studies have investigated how developers set breakpoints during interactive debugging sessions. To understand how developers set breakpoints, we analysed more than 10 hours of 45 video-recorded debugging sessions, where a total of 307 breakpoints were set. We used the videos from two independent studies involving three software systems. We could observe that: (1) considerable time is spent by developers until they are able to set the first breakpoint; (2) when developers toggle breakpoints carefully, they complete tasks faster than developers who set (potential useless) breakpoints quickly; and (3) different developers set breakpoints in similar locations while working (independently) on the same tasks or different tasks. We discuss some implications of our observations for debugging activities.

Debugging is a laborious activity in which developers spend lot of time navigating through code, looking for starting points, and stepping through statements. In this paper, we present the Swarm Debug Infrastructure (SDI) with which researchers can collect and share data about developers' interactive debugging activities. SDI allows collecting and sharing debugging data that are useful to answer research questions about interactive debugging activities. We assess the effectiveness of the SDI through an experiment to understand how developers apply interactive debugging

Debugging is a laborious activity in which developers spend lot of time navigating through code, looking for starting points, and stepping through statements. Yet, although debuggers exist for 40 years now, there have been few research studies to understand this important and laborious activity. Indeed, to perform such a study, researchers need detailed information about the different steps of the interactive debugging process. In this paper, to help research studies on debugging and, thus, help improving our understanding of how developers debug systems using debuggers, we present the Swarm Debug Infrastructure (SDI), with which practitioners and researchers can collect and share data about developers' interactive debugging activities. We assess the effectiveness of the SDI through an experiment that aims to understand how developers apply interactive debugging on five true faults found in JabRef, toggling breakpoints and stepping code. Our study involved five freelancers and two student developers performing 19 bug location sessions. We collect videos recording and data about 6 hours of effective debugging activities. The data includes 110 breakpoints and near 7,000 invocations. We process the collected videos and data to answer five research questions showing that (1) there is no correlation between the number of invocations (respectively the number of breakpoints toggled) during a debugging session and the time spent on the debugging task, ρ = -0.039 (respectively 0.093). We also observed that (2) developers follow different debugging patterns and (3) there is no relation between numbers of breakpoints and expertise. However, (4) there is a strong negative correlation between time of the first breakpoint (ρ = -0.637), and the time spent on the task, suggesting that when developers toggle breakpoints carefully, they complete tasks faster than developers who toggle breakpoints too quickly. We conclude that the SDI allows collecting and sharing debugging data that can provide interesting insights about interactive debugging activities. We discuss some implications for tool developers and future debuggers.

Debugging sessions require a methodical process of finding causes and reducing the number of software problems. During such sessions, developers run a software project, traversing method invocations, setting breakpoints, stopping or restarting executions. In these sessions, developers explore different parts of the code and create knowledge about them. When debugging sessions are over, it is likely that such knowledge is lost, and developers cannot use it in other sessions or sharing it with collaborators. We have developed Swarm Debugging, a new approach for visualizing and sharing information obtained during debugging sessions, providing interactive and real-time visualization techniques, and several searching tools. Through usage scenarios, we demonstrate that it can aid developers to decrease the required time for deciding where to toggle a break-point and locate bug causes. We show how Swarm Debugging offers more useful support for many typical development tasks than a traditional debugger tool.