arXiv Science⌕ Search

arXiv subjects

Fabio Petrillo

Publications and source records attributed to Fabio Petrillo.

At least 37 records · Page 2Linked to original sources

Towards Continuous Systematic Literature Review in Software Engineering

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 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.

cs.SE↗

Establishing a Search String to Detect Secondary Studies in Software Engineering

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 two-step 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".

cs.SE↗

What Makes a Game High-rated? Towards Factors of Video Game Success

As the video game market grows larger, it becomes harder to stand out from the crowd. Launching a successful game involves different aspects. But what are they? In this paper, we investigate some aspects of the high-rated games from a dataset of 200 projects. The results show that the none of the aspects of this study have a strong relationship with the game's success. A further analysis on the high-rated games shows that team, technical, and game-design aspects should be the main focus of the game developers.

cs.SE↗

Video Game Project Management Anti-patterns

Project Management anti-patterns are well-documented in the software-engineering literature, and studying them allows understanding their impacts on teams and projects. The video game development industry is known for its mismanagement practices, and therefore applying this knowledge would help improving game developers' productivity and well-being. In this paper, we map project management anti-patterns to anti-patterns reported by game developers in the gray literature. We read 440 postmortems problems, identified anti-pattern candidates, and related them with definitions from the software-engineering literature. We discovered that most anti-pattern candidates could be mapped to anti-patterns in the software-engineering literature, except for Feature Creep, Feature Cuts, Working on Multiple Projects, and Absent or Inadequate Tools. We discussed the impact of the unmapped candidates on the development process while also drawing a parallel between video games and traditional software development. Future works include validating the definitions of the candidates via survey with practitioners and also considering development anti-patterns.

cs.SE↗

Towards Automated Video Game Testing: Still a Long Way to Go

As the complexity and scope of game development increase, playtesting remains an essential activity to ensure the quality of video games. Yet, the manual, ad-hoc nature of playtesting gives space to improvements in the process. In this study, we investigate gaps between academic solutions in the literature for automated video game testing and the needs of video game developers in the industry. We performed a literature review on video game automated testing and applied an online survey with video game developers. The literature results show a rise in research topics related to automated video game testing. The survey results show that game developers are skeptical about using automated agents to test games. We conclude that there is a need for new testing approaches that did not disrupt the developer workflow. As for the researchers, the focus should be on the testing goal and testing oracle.

cs.SE↗

Log severity level classification: an approach for systems in production

Context: Logs are often the primary source of information for system developers and operations engineers to understand and diagnose the behavior of a software system in production. In many cases, logs are the only evidence available for fault investigation. Problem: However, the inappropriate choice of log severity level can impact the amount of log data generated and, consequently, quality. This storage overhead can impact the performance of log-based monitoring systems, as excess log data comes with increased aggregate noise, making it challenging to utilize what is actually important when trying to do diagnostics. Goal: This research aims to decrease the overheads of monitoring systems by processing the severity level of log data from systems in production. Approach: To achieve this goal, we intend to deepen the knowledge about the log severity levels and develop an automated approach to log severity level classification, demonstrating that reducing log severity level "noise" improves the monitoring of systems in production. Conclusion: We hope that the set of contributions from this work can improve the monitoring activities of software systems and contribute to the creation of knowledge that improves logging practices

cs.SE↗

Log severity levels matter: A multivocal mapping

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 peer-reviewed literature, 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.

cs.SE↗

Mapping breakpoint types: an exploratory study

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.

cs.SE↗

Continuous Systematic Literature Review: An Approach for Open Science

Systematic Literature Reviews (SLRs) play an important role in the Evidence-Based Software Engineering scenario. With the advance of the computer science field and the growth of research publications, new evidence continuously arises. This fact impacts directly on the purpose of keeping SLRs up-to-date which could lead researchers to obsolete conclusions or decisions about a research problem or investigation. Creating and maintaining SLRs up-to-date demand a significant effort due to several reasons such as the rapid increase in the amount of evidence, limitation of available databases and lack of detailed protocol documentation and data availability. Conventionally, in software engineering SLRs are not updated or updated intermittently leaving gaps between updates during which time the SLR may be missing important new research. In order to address these issues, we propose the concept, process and tooling support of Continuous Systematic Literature Review (CSLR) in SE aiming to keep SLRs constantly updated with the promotion of open science practices. This positional paper summarizes our proposal and approach under development.

cs.SE↗

Towards auto-completion on software requirements statements

As software systems become more complex, modern software development requires more attention to human perspectives, and active participation of development teams in requirements elicitation tasks. In this context, incomplete or ambiguous requirements descriptions do not guide the development of good software products. We hypothesize that the text auto-completion feature improves the quality of the software requirements artifacts. We present the motivation for this study, related works, our approach and future research efforts.

cs.SE↗

Towards Logging Noisiness Theory: quality aspects to characterize unwanted log entries

Context: Logging tasks track the system's functioning by keeping records of evidence that have been analyzed by monitoring and observability activities. For these activities to be effective, it is necessary to consider the quality of the consumed information. Problem: However, the presence of noise - unwanted information - compromises the log files' quality. The noisiness of a log file can be affected among other things by: (i) the wrong severity log choices, (ii) the production of duplicate entries, (iii) the incompleteness of the information, (iv) the inappropriate format of the entries, (v) the amount of information generated. Objective: This work aims to broadly define the concept of noise in the context of logging, proposing the initial steps of Logging Noisiness, a theory on quality aspects to characterize unwanted log entries.

cs.SE↗

Towards Automated Acceptance testing for industrial robots

Industrial robots are important machines applied in numerous modern industries that execute repetitive tasks with high accuracy, replacing or supporting dangerous jobs. In this kind of system, with increased complexity in which cost is related to the time the system keeps working, the system must operate with a minimum number of failures. In other words, a quality aspect important in industry is reliability. We hypothesize that Automated Acceptance Testing improves reliability for industrial robot program. We present the research question, the motivation for this study, our hypothesis and future research efforts.

cs.RO↗

Towards improving architectural diagram consistency using system descriptors

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. Furthermore, 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.

cs.SE↗

A Survey of Video Game Testing

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.

cs.SE↗

Software Engineering for Robotic Systems:a systematic mapping study

Robots are being applied in a vast range of fields, leading researchers and practitioners to write tasks more complex than in the past. The robot software complexity increases the difficulty of engineering the robot's software components with quality requirements. Researchers and practitioners have applied software engineering (SE) approaches and robotic domains to address this issue in the last two decades. This study aims to identify, classify and evaluate the current state-of-the-art Software Engineering for Robotic Systems (SERS). We systematically selected and analyzed 50 primary studies extracted from an automated search on Scopus digital library and manual search on the two editions of the RoSE workshop. We present three main contributions. Firstly, we provide an analysis from three following perspectives: demographics of publication, SE areas applied in robotics domains, and RSE findings. Secondly, we show a catalogue of research studies that apply software engineering techniques in the robotic domain, classified with the SWEBOK guide. We have identified 5 of 15 software engineering areas from the SWEBOK guide applied explicitly in robotic domains. The majority of the studies focused on the development phase (design, models and methods and construction). Testing and quality software areas have little coverage in SERS. Finally, we identify research opportunities and gaps in software engineering for robotic systems for future studies.

cs.RO↗

Game Industry Problems: an Extensive Analysis of the Gray Literature

Context: Given its competitiveness, the video-game industry has a closed-source culture. Hence, little is known of the problems faced by game developers. However, game developers do share information about their games projects through postmortems, which describe informally what happened during the projects. Objective: The software-engineering research community and game developers would benefit from a state of the problems of the video game industry, in particular the problems faced by game developers, their evolution in time, and their root causes. This state of the practice would allow researchers and practitioners to work towards solving these problems. Method: We analyzed 200 postmortems from 1997 to 2019, resulting in 927 problems divided into 20 types. Through our analysis, we described the overall landscape of game industry problems in the past 23 years and how these problems evolved over the years. We also give details on the most common problems, their root causes, and possible solutions. We finally discuss suggestions for future projects. Results: We observe that (1) the game industry suffers from management and production problems in the same proportion; (2) management problems decreased over the years giving space to business problems, while production problems remained constant; (3a) technical and game design problems are decreasing over the years, the latter only after the last decade; (3b) problems related to the team increase over the last decade;(3c) marketing problems are the ones that had the biggest increase over the 23 years compared to other problem types; (4) finally, the majority of the main root causes are related to people, not technologies. Conclusions: In this paper we provide a state of the practice for researchers to understand and study video-game development problems. We also offer suggestions to help practitioners to avoid the most common problems.

cs.SE↗

What Skills do IT Companies look for in New Developers? A Study with Stack Overflow Jobs

Context: There is a growing demand for information on how IT companies look for candidates to their open positions. Objective: This paper investigates which hard and soft skills are more required in IT companies by analyzing the description of 20,000 job opportunities. Method: We applied open card sorting to perform a high-level analysis on which types of hard skills are more requested. Further, we manually analyzed the most mentioned soft skills. Results: Programming languages are the most demanded hard skills. Communication, collaboration, and problem-solving are the most demanded soft skills. Conclusion: We recommend developers to organize their resumé according to the positions they are applying. We also highlight the importance of soft skills, as they appear in many job opportunities.

cs.SE↗

Applying system descriptors to address ambiguity on deployment diagrams

Communication between practitioners is essential for product quality in the DevOps context. This communication often takes place through deployment diagrams of a system under development. However, it is common diagrams to become ambiguous or inconsistent as the system progresses and goes to a continuous delivery pipeline or production. Moreover, diagrams could not follow the evolution of systems, and it is challenging to associate diagrams to production. In this paper, we propose the use of system descriptors to address the ambiguity of deployment diagrams. We state three main hypotheses (1) if a deployment diagram is generated from a valid system descriptor then the diagram is unambiguous; (2) if a valid system descriptor is generated from a deployment diagram then the descriptor is unambiguous; (3) if a diagram $μ$ generated from a descriptor $A$ is unambiguous and if a descriptor $B$ is generated from the diagram $μ$ equally unambiguous then descriptors $A$ and $B$ are equivalent. We report a case study to test our hypotheses. We constructed a system descriptor from Netflix deployment diagram, and we applied our tool to generate a new deployment diagram. Finally, we compare the original and generated diagrams to evaluate our proposal. Our case study shows the generated deployment diagrams are graphically equivalent to system descriptors and eliminated ambiguous aspects of the original diagram. Thus, our preliminary results lead to further evaluation in controlled and empirical experiments to test our hypotheses conclusively.

cs.SE↗