No abstract

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.

Muitos projetos de desenvolvimento falham em entregar o software dentro do cronograma, orçamento e níveis de qualidade, por causa da avaliação inadequada dos fatores de risco. Este trabalho propõe uma abordagem sistemática para prevenir e monitorar riscos, baseado em adaptação do processo de desenvolvimento. Para prevenção de risco é sugerido um procedimento para listar, analisar e priorizar os riscos, visando selecionar ações preventivas para incluir no processo de desenvolvimento, minimizando a exposição ao risco. Utilizando o paradigma Goal/Question/Metric são definidas métricas do processo de software para serem usadas para acompanhar o progresso dos fatores de risco, possibilitando ao gerente de projeto tomar ações corretivas, quando necessário e no momento adequado.

We have put forward an approach to online collaborative discussion of software development problems based on Argumentation theory. Having records of past discussions can significantly help solve problems in new projects, and CBR techniques are used to retrieve the most similar cases. However, long discussions on past projects still contain too much information to provide support in new discussions. To address this problem, in this paper we introduce the idea of explanation templates that are able to summarize past experiences, particularly for risk management discussions. We formalize this notion of template, introduce the main templates we have developed to support explanation of past experience with risk management, and report the results of a case study on a realworld software project to assess the usefulness of those templates.

-Managing risks in real-world software projects is of paramount importance. A significant class of such risks is related to the engineering of requirements, commonly involving the presentation and analysis of risk management arguments from both software engineers and clients involved in collaborative debates. In this work, drawing inspiration from argumentation theory in Artificial Intelligence, we introduce a number of "argumentation schemes" and associated "critical questions" to support such discussions. In doing so, we propose schemes related to risks due to excessive numbers of requirements; inadequate client representatives and poor understanding of client needs; incorrect, incomplete and conflicting requirements, and complex and non-traceable requirements. We also present a case study where the developed schemes were used to support the discussion of requirement risks in the context of a research and prototyping software project for the Brazilian Army.