arXiv Science⌕ Search

arXiv subjects

Fabio Petrillo

Publications and source records attributed to Fabio Petrillo.

52 records · Page 3Linked to original sources

Are Game Engines Software Frameworks? A Three-perspective Study

Game engines help developers create video games and avoid duplication of code and effort, like frameworks for traditional software systems. In this paper, we explore open-source game engines along three perspectives: literature, code, and human. First, we explore and summarise the academic literature on game engines. Second, we compare the characteristics of the 282 most popular engines and the 282 most popular frameworks in GitHub. Finally, we survey 124 engine developers about their experience with the development of their engines. We report that: (1) Game engines are not well-studied in software-engineering research with few studies having engines as object of research. (2) Open-source game engines are slightly larger in terms of size and complexity and less popular and engaging than traditional frameworks. Their programming languages differ greatly from frameworks. Engine projects have shorter histories with less releases. (3) Developers perceive game engines as different from traditional frameworks. Generally, they build game engines to (a) better control the environment and source code, (b) learn about game engines, and (c) develop specific games. We conclude that open-source game engines have differences compared to traditional open-source frameworks although this differences do not demand special treatments.

cs.SE↗

Dataset of Video Game Development Problems

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.

cs.SE↗

Learning from the past: A process recommendation system for video game projects using postmortems experiences

Context: The video game industry is a billion dollar industry that faces problems in the way games are developed. One method to address these problems is using developer aid tools, such as Recommendation Systems. These tools assist developers by generating recommendations to help them perform their tasks. Objective: This article describes a systematic approach to recommend development processes for video game projects, using postmortem knowledge extraction and a model of the context of the new project, in which "postmortems" are articles written by video game developers at the end of projects, summarizing the experience of their game development team. This approach aims to provide reflections about development processes used in the game industry as well as guidance to developers to choose the most adequate process according to the contexts they're in. Method: Our approach is divided in three separate phases: in the the first phase, we manually extracted the processes from the postmortems analysis; in the second one, we created a video game context and algorithm rules for recommendation; and finally in the third phase, we evaluated the recommended processes by using quantitative and qualitative metrics, game developers feedback, and a case study by interviewing a video game development team. Contributions: This article brings three main contributions. The first describes a database of developers' experiences extracted from postmortems in the form of development processes. The second defines the main attributes that a video game project contain, which it uses to define the contexts of the project. The third describes and evaluates a recommendation system for video game projects, which uses the contexts of the projects to identify similar projects and suggest a set of activities in the form of a process.

cs.SE↗

A Large Scale Empirical Study of the Impact of Spaghetti Code and Blob Anti-patterns on Program Comprehension

Context: Several studies investigated the impact of anti-patterns (i.e., "poor" solutions to recurring design problems) during maintenance activities and reported that anti-patterns significantly affect the developers' effort required to edit files. However, before developers edit files, they must understand the source code of the systems. This source code must be easy to understand by developers. Objective: In this work, we provide a complete assessment of the impact of two instances of two anti-patterns, Blob or Spaghetti Code, on program comprehension. Method: We analyze the impact of these two anti-patterns through three empirical studies conducted at Polytechnique Montréal (Canada) with 24 participants; at Carlton University (Canada) with 30 participants; and at University Basilicata (Italy) with 79 participants. Results: We collect data from 372 tasks obtained thanks to 133 different participants from the three universities. We use three metrics to assess the developers' comprehension of the source code: (1) the duration to complete each task; (2) their percentage of correct answers; and, (3) the NASA task load index for their effort. Conclusions: We report that, although single occurrences of Blob or Spaghetti code anti-patterns have little effect on code comprehension, two occurrences of either Blob or Spaghetti Code significantly increases the developers' time spent in their tasks, reduce their percentage of correct answers, and increase their effort. Hence, we recommend that developers act on both anti-patterns, which should be refactored out of the source code whenever possible. We also recommend further studies on combinations of anti-patterns rather than on single anti-patterns one at a time.

cs.SE↗

Are the Old Days Gone? A Survey on Actual Software Engineering Processes in Video Game Industry

In the past 10 years, several researches studied video game development process who proposed approaches to improve the way how games are developed. These approaches usually adopt agile methodologies because of claims that traditional practices and the waterfall process are gone. However, are the "old days" really gone in the game industry? In this paper, we present a survey of software engineering processes in video game industry from postmortem project analyses. We analyzed 20 postmortems from Gamasutra Portal. We extracted their processes and modelled them through using the Business Process Model and Notation (BPMN). This work presents three main contributions. First, a postmortem analysis methodology to identify and extract project processes. Second, the study main result: \textbf{the "old days" are gone, but not completely}. \textbf{Iterative practices} are increasing and are applied to at least \textbf{65\% of projects} in which \textbf{45\% of this projects} explicitly adopted Agile practices. However, \textbf{waterfall} process is still applied at least \textbf{30\% of projects}. Finally, we discuss some implications, directions and opportunities for video game development community.

cs.SE↗

Open Source Software Development Process: A Systematic Review

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 OSS community the need of 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 identifying and summarizing OSS process activities and their characteristics as well as translating OSS process in a macro process through BPMN notation. As a result, we systematically analysed 33 studies presenting an overview of the state-of-art of researches regarding OSS process, 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 being 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.

cs.SE↗

DR-Tools: a suite of lightweight open-source tools to measure and visualize Java source code

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.

cs.SE↗

Internet of Things Architectures: A Comparative Study

Over the past two decades, the Internet of Things (IoT) has become an underlying concept to a variety of solutions and technologies that it is now hardly possible to enumerate and describe all of them. The concept behind the Internet of Things is as powerful as it is complex, and for the components in the IoT solution tomesh together perfectly, they all have to be part of a well-thought-out structure. That is where understanding the IoT architecture becomes paramount. Because of the vast domain of IoT, there is no single consensus on IoT architecture. Different researchers and organizations proposed different architectures under a variety of classifications, mainly: conceptual, standard and, industrial or commercial adoption. It is indispensable to make a systematic analysis of IoT architecture to be able to compare the industrial proposals and identify their similarities and their differences. In this work, we summarize information about seven IoT industrial architectures in order to propose an approach that makes possible a comparative analysis between different IoT architectures. This work presents two main contributions: (i) an approach for analyzing and comparing IoTarchitectures using Layer-Model; (ii) a comparative study of seven industrial IoT architectures.

cs.SE↗

Code Smells and Refactoring: A Tertiary Systematic Review of Challenges and Observations

In this paper, we present a tertiary systematic literature review of previous surveys, secondary systematic literature reviews, and systematic mappings. We identify the main observations (what we know) and challenges (what we do not know) on code smells and refactoring. We show that code smells and refactoring have a strong relationship with quality attributes, i.e., with understandability, maintainability, testability, complexity, functionality, and reusability. We argue that code smells and refactoring could be considered as the two faces of a same coin. Besides, we identify how refactoring affects quality attributes, more than code smells. We also discuss the implications of this work for practitioners, researchers, and instructors. We identify 13 open issues that could guide future research work. Thus, we want to highlight the gap between code smells and refactoring in the current state of software-engineering research. We wish that this work could help the software-engineering research community in collaborating on future work on code smells and refactoring.

cs.SE↗

A Tertiary and Secondary Study Canvas

Over the past years, more secondary (Systematic Literature Reviews and Systematic Mappings) and tertiary studies have been conducted. Their conduction is considered a quite large task and labor-intensive since it involves a detailed process including a protocol development, which is one of the most challenging phase reported by the software engineering research community. In this scenario, we propose a Secondary and Tertiary Study Canvas aiming to simplify and clarify the understanding of the steps that need to be performed during the secondary and tertiary process conduction, including the protocol development. For this, we synthesized and organized the existing secondary studies' protocols in a Canvas format as well as suggesting a step-based approach to assist the secondary and tertiary studies' conduction.

cs.SE↗

The cross cyclomatic complexity: a bi-dimensional measure for program complexity on graphs

Reduce and control complexity is an essential practice in software design. Cyclomatic complexity (CC) is one of the most popular software metrics, applied for more than 40 years. Despite CC is an interesting metric to highlight the number of branches in a program, it clearly not sufficient to represent the complexity in a piece of software. In this paper, we introduce the cross cyclomatic complexity (CCC), a new bi-dimensional complexity measure on graphs that combines the cyclomatic complexity and the weight of a minimum-weight cycle basis in as pair on the Cartesian plan to characterize program complexity using control flow graphs. Our postulates open a new venue to represent program complexity, and we discuss its implications and opportunities.

cs.SE↗

Swarm Debugging: the Collective Intelligence on Interactive Debugging

One of the most important tasks in software maintenance is debugging. To start an interactive debugging session, developers usually set breakpoints in an integrated development environment and navigate through different paths in their debuggers. We started our work by asking} what debugging information is useful to share among developers and study two pieces of information: breakpoints (and their locations) and sessions (debugging paths). To answer our question, we introduce the Swarm Debugging concept to frame the sharing of debugging information, the Swarm Debugging Infrastructure (SDI) with which practitioners and researchers can collect and share data about developers' interactive debugging sessions, and the Swarm Debugging Global View (GV) to display debugging paths. Using the SDI, we conducted a large study with professional developers to understand how developers set breakpoints. Using the GV, we also analyzed professional developers in two studies and collected data about their debugging sessions. Our observations and the answers to our research questions suggest that sharing and visualizing debugging data can support debugging activities.

cs.SE↗

Software Architecture Metrics: a literature review

In Software Engineering, early detection of architectural issues is key. It helps mitigate the risk of poor performance, and lowers the cost of repairing these issues. Metrics give a quick overview of the project which helps designers with the detection of flaws or degradation in their architecture. Even though studies unveiled architectural metrics more than 25 years ago, they have not yet been embraced by the industry nor the open source community. In this study, we aim at conducting a review of existing metrics focused on the software architecture for evaluating quality, early in the design flow and throughout the project's lifetime. We also give guidelines of their usage and study their relevance in different contexts.

cs.SE↗

A quality model for evaluating and choosing a stream processing framework architecture

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 become 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 (or 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 should be done directly. Therefore, direct results are needed with a latency that may vary in real-time. In this paper, we propose an assessment quality model to evaluate and choose stream processing frameworks. We describe briefly different architectural frameworks such as Kafka, Spark Streaming and Flink 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.

cs.SE↗

Serverless architecture efficiency: an exploratory study

Cloud service provider propose services to insensitive customers to use their platform. Different services can achieve the same result at different cost. In this paper, we study the efficiency of a serverless architecture for running highly parallelizable tasks to compare theses services in order to find the most efficient in term of performance and cost. More precisely, we look at the compute time and at the cost per task for a given task. The tasks studied is the count of the occurrence of a given word in a corpus. We compare the serverless architecture to the Apache Spark map reduce technique commonly used for this type of task. Using AWS Lambda for the serverless architecture and Amazon EMR for the Apache Spark map reduce, with similar compute power, we show that the serverless technique achieve comparable performance in term of compute time and cost. We observed that the lambda function is a great approach for real time computing, while EMR is preferable for task that require long compute time.

cs.SE↗

Problems and Solutions of Continuous Deployment: A Systematic Review

Context: The software industry needs to adapt itself to a rapidly changing market. Continuous practices (Continuous Integration, Continuous Delivery and Continuous Deployment), commonly found in Agile development processes, it is possible to deliver new features more frequently to clients, integrating of smaller features is less likely to cause conflicts than the more traditional approach of merging big features less frequently all at once. However, Continuous Deployment is no clear way on the best approaches for their implementation. Objective: The goal of this paper is to identify the challenges and the solutions related to Continuous Deployment, and then see which of those solutions can be applied to which challenges. Method: This paper is a systematic literature review of the problems and the solutions found when implementing the continuous deployment practice inside an organization. It also presents which solution can be applied to which problem. Thirty-one articles published after 2015 were analyzed for this SLR. Results: 22 problems were grouped inside the categories Human and Organizational, Process, Tools, Infrastructure, Application Architecture and Testing. The 19 solutions found were grouped inside the categories Human and Organizational, Architecture, Process and Tools. Solutions have been found for 14 problems and some questions have been identified for future research. Conclusion: this article is to serve as a reference for the practitioner who wants to find how to solve a specific challenge when implementing the continuous deployment practice.

cs.SE↗