CONTEXT. Focus Group (FG) is a qualitative technique that collects data through moderated group discussion. Although widely used in fields where human behavior is central, their use in Software Engineering (SE) is comparatively less common. In SE, FG applications often need to accommodate technical domains, participants with specialized expertise, and research goals that differ from those typically addressed in traditional social science settings. OBJECTIVE. This study analyzes four FG experiences conducted to investigate distinct SE technologies and topics. The objective is to examine how design decisions, execution strategies, and contextual conditions support or hinder the identification of the benefits and drawbacks of using FGs in SE research. METHOD. We performed a reflective cross-case methodological analysis of four FGs conducted in both academic and industrial settings. The studies differed in goals, group configurations, participant expertise, and moderation strategies. Data sources included session transcripts, written artifacts, moderator observations, and participant feedback. RESULTS. The results indicate that data quality depended on participants’ prior knowledge, the moderator's impartiality, the execution context, and the use of multimodal data capture. Depth and generalizability were limited by time constraints, uneven engagement, and the diverse qualitative data that hindered comparison. CONCLUSIONS. FG is an effective complementary method in SE research, particularly for exploratory analysis and for understanding practitioner perspectives on SE technologies. However, its effectiveness depends on deliberate design choices, including participant selection and preparation, group configuration, and systematic documentation.

With the advent of languages like POF and P4 and the ability to write code for redefining switch behavior, software verification becomes paramount to avoid network and service disruption due to buggy implementations. Various techniques like symbolic execution, annotations, and assertions have been recently used to ensure bug-free switch code. In spite of the potentialities, they are limited in the classes of errors they can capture. More importantly, existing proposals for switch program verification often require a programmer to write custom verification code (e.g., annotations), an error-prone approach in itself. In this paper, we present the design and implementation of p4-data-flow, a practical tool which uses data flow analysis for verification of switch programs. We focus on the P4 language, and present experiments showing that data flow analysis may reveal defects from classes not yet covered by existing work, without demanding further programmer effort.

Background: Some scientific fields, such as automobile, drugs discovery or engineer have used simulation-based studies (SBS) to faster the observation of phenomena and evolve knowledge. All of them organize their working structure to perform computerized experiments based on explicit research protocols and evidence. The benefits have been many and great advancements are continuously obtained for the society. However, could the same approach be observed in Software Engineering (SE)? Are there research protocols and evidence based models available in SE for supporting SBS? Are the studies reports good enough to support their understanding and replication? AIM: To characterize SBS in SE and organize a set of reporting guidelines aiming at improving SBS' understandability, replicability, generalization and validity. METHOD: To undertake a secondary study to characterize SBS. Besides, to assess the quality of reports to understand the usually reported information regarding SBS. RESULTS: From 108 selected papers, it has been observed several relevant initiatives regarding SBS in software engineering. However, most of the reports lack information concerned with the research protocol, simulation model building and evaluation, used data, among others. SBS results are usually specific, making their generalization and comparison hard. No reporting standard has been observed. CONCLUSIONS: Advancements can be observed in SBS in Software Engineering. However, the lack of reporting consistency can reduce understandability, replicability, generalization and compromise their validity. Therefore, an initial set of guidelines is proposed aiming at improving SBS report quality. Further evaluation must be accomplished to assess the guidelines feasibility when used to report SBS in Software Engineering.