SimulES: Simulador de Engenharia de Software

Quick links

• Motivação
• Descrição do Jogo
• Download
• Pessoas Envolvidas
• Referências

Motivação

Tecnologia de jogos tem sido usada para o ensino em muitas áreas, mas em engenharia de software ela não é muito comum. Para minimizar este problema, apresentamos SimulES, um jogo educacional que utiliza cartas e simula o processo de desenvolvimento de software. O jogo é baseado em uma versão preliminar chamada Problems and Programmers [1, 5]. Ele permite que um estudante assuma o papel de gerente de projeto e depare com problemas que não são bem cobertos em aulas tradicionais.

Descrição do Jogo

SimulES pode ser jogado entre 4 e 8 jogadores, seu objetivo é que os particimantes disputem para terminar um projeto de software e o vencedor será quem implantar o projeto primeiro. Através deste jogo, os jogadores, preferencialmente alunos, aprendem importantes conceitos de computação e especialmente de engenharia de software. Os recursos do jogo são: um tabuleiro, cartões de projeto, cartas e um dado.

O Tabuleiro

O tabuleiro é uma área na qual cada jogador coloca seus engenheiros de software em colunas e os artefatos em linhas. Os artefatos podem ser dos seguintes tipos: requisitos, desenhos, códigos, rastros e ajuda aos usuários (ajudas). Na Figura abaixo é representado o tabuleiro em um cenário de jogo com a contratação de dois engenheiros. As cartas de artefatos são colocadas nas células do tabuleiro, abaixo do engenheiro que as produziram e nas linhas referentes aos seus tipos. Por exemplo, na linha de requisitos da figura estão dois artefatos feitos por Janaína e um por Carlos.

Cartão de Projeto

As seguintes informações estão presentes nos cartões de projeto:

• Descrição: texto em linguagem natural que descreve as principais características do projeto. Esta descrição torna o jogo mais realista e ajuda o jogador a compreender os principais requisitos do sistema. Abaixo da descrição são colocadas referências para artigos e livros relacionadas ao projeto ou seus principais conceitos.
• Complexidade: indica quantos pontos de tempo um engenheiro de software precisa gastar para completar um bom artefato. Artefatos de má qualidade custam metade deste valor. A complexidade do projeto pode ter o valor de 2 ou 4.
• Tamanho: indica quantos módulos integrados devem ser completados para integrar e terminar o projeto. O número máximo de módulos que um projeto pode ter é 6. O cartão indica também a forma que os módulos devem ser construídos. Por exemplo, o sistema da Figura 2 deve ser composto de 5 módulos e o primeiro deve conter duas cartas de requisitos (RQ), uma de desenho (DS) e uma de código (CD).
• Qualidade: representa o quão livre de defeitos deve estar o produto final. O valor varia entre 1 e 5 indicando o número mínimo de módulo sem defeitos necessários para se vencer o jogo. A qualidade do sistema é verificada na fase de entrega do produto.
• Orçamento: quantidade de dinheiro disponível para gastar com o projeto e será uma restrição para contratação de engenheiros de software bem como para o uso de cartas de conceitos. Durante qualquer momento do jogo o valor dos salários de todos os engenheiros somado com os custos dos conceitos (caso estes tenham valor) não deve ultrapassar o orçamento do projeto.

Cartas de Problemas

Estas cartas descrevem problemas clássicos de engenharia de software resultantes de falhas no processo de desenvolvimento. Essas cartas são utilizadas, para criar obstáculos ao progresso dos jogadores adversários. Além de um nome e um código, as cartas de problemas possuem os seguintes atributos: Literatura de Apoio para referências que melhor caracterizam o referido problema Condições a serem satisfeitas por um jogador para que seu oponente lhe jogue o problema Efeito no jogador (ou em seus engenheiros) quando a carta é jogada As cartas de problemas são as principais fontes de retorno negativo para o jogador quando este toma más decisões do ponto de vista da engenharia de software. A figura ao lado apresenta um exemplo de problema de código: Entrelaçamento de Interesses [4].

Cartas de Conceitos

Estas cartas descrevem boas práticas de engenharia de software e podem ser utilizadas pelos jogadores para avançarem face ao seu objetivo. Os atributos das cartas de conceitos são: Código e Nome do conceito Literatura de Apoio como nas cartas de problemas Efeito na configuração do jogo ou tabuleiro do jogador quando ela é jogada Custo (quando presente na carta) que incorre em gastos após o conceito ser usado pelo jogador A carta apresentada na figura ao lado descreve o conceito Modelagem UML [2].

Cartas de Artefatos

Estas cartas simbolizam os produtos dos engenheiros de software que podem ou não conter bugs. Os artefatos podem ter duas cores, branco ou cinza, dependendo de sua qualidade. Apesar de gastarem o dobro dos "pontos de tempo" para serem produzidas, as cartas de cor branca contêm defeitos na proporção de 5 cartas para 1 defeito enquanto nas cartas de cor cinza esta proporção é de 3 para 2. Para vencer no jogo, é preciso completar os módulos do projeto através da composição dos artefatos.

Engenheiros de Software

Este tipo de carta é o principal recurso que o jogador terá para progredir no jogo. Os engenheiros produzem artefatos que são necessários para cumprir o projeto. Cartas de engenheiros apresentam as seguintes informações: Nome e Descrição pessoal do engenheiro Salário a ser pago ao funcionário (deve respeitar o limite de orçamento do projeto) Habilidade indica o "pontos de tempo" que um engenheiro possui a cada rodada para desempenhar ações no jogo Maturidade reflete a tendência do engenheiro de software em ser um bom trabalhador A habilidade e a maturidade são medidas em uma escala de 1 a 5.

Dinâmica do Jogo

Antes do início do jogo, um cartão de projeto é escolhido aleatoriamente de uma série de projetos disponíveis. As informações deste cartão devem ficar visíveis a todos os jogadores. Em seguida, cada jogador monta seu tabuleiro de jogo e as cartas são separadas em quatro montes: um para engenheiros de software, outro para problemas e conceitos, um para artefatos branco e outro para artefatos cinza. Com o dado escolhe-se quem começa e o jogo deve prosseguir no sentido horário.

A cada jogada, o jogador da vez lança o dado e de acordo com o número tirado, retira cartas nos montes dependo do valor obtido. Se o jogador tirar entre 1 e 3 no dado ele terá direito de pegar no monte de problemas e conceitos o número de cartas indicadas pelo dado, mas não poderá pegar nenhuma carta de engenheiro. Se o jogador tirar entre 4 e 6 no dado, ele irá pegar 3 cartas de problemas e conceitos e a diferença (dado - 3) no monte de engenheiros de software. Por exemplo, se na vez da jogadora Maria o número tirado for 2, ela compra duas cartas no monte de problemas e conceitos. Por outro lado, se o número tirado for 5, Maria retira 3 cartas no monte de problemas e conceitos e 2 (5 - 3) engenheiros de software. As cartas de problemas e conceitos são guardadas na mão do jogador até o momento que ele achar oportuno para jogá-las. As cartas de engenheiros também podem ser guardadas nas mãos ou então podem ser colocadas imediatamente no tabuleiro, o que indica a contratação do funcionário.

Ao fim de sua jogada, o jogador está apto a receber as cartas de problemas de seus adversários. Ele pode receber problemas dos três jogadores que jogaram imediatamente antes dele. As cartas de problemas recebidas não alteram diretamente o estado do tabuleiro e devem ser guardadas para a rodada seguinte. No inicio de sua jogada na rodada seguinte, se o jogador tem em mãos uma carta de conceito que invalida o problema, então ele diz que a carta problema não se aplica e descarta tanto a carta de problema quanto a carta de conceito. Além disso, durante a jogada, um engenheiro de software pode exercer uma série de tarefas. A habilidade do engenheiro determina quantos "pontos de tempo" ele tem e, portanto, quantas ações ele pode desempenhar. Os engenheiros têm quatro opções de tarefas como descritas a seguir:

1. Construir Artefato: o engenheiro pode construir artefatos de cor branca gastando o valor de "pontos de tempo" indicado pela complexidade do projeto. Ele também pode construir artefatos de cor cinza pagando a metade da complexidade do projeto.
2. Inspeção de artefato: esta tarefa se caracteriza por desvirar uma das cartas de artefato que estão com a face virada para baixo. Se um artefato apresenta um defeito, esta carta pode potencialmente causar problemas quando o projeto for terminado.
3. Corrigir defeito: após inspecionar o artefato e descobrir um defeito, o engenheiro pode corrigi-lo gastando um "ponto de tempo". Para isso ele substitui a carta com defeito por uma nova carta de mesma qualidade (branca ou cinza) do monte de artefatos.
4. Integrar artefatos em um módulo: esta tarefa pode ser feita quando houver artefatos suficientes no tabuleiro do jogador para compor um módulo requerido pelo projeto. A integração retira os artefatos do tabuleiro e os coloca separados no monte de integração.

Uma vez terminado os componentes necessários para o termino do projeto, o jogador pode afirmar que completou o projeto. Nesse momento é feita a validação por parte do cliente. Isto significa que alguns dos módulos do projeto são aleatoriamente verificados e devem estar livres de problemas. O número de módulos a serem verificados na validação é igual ao valor da qualidade indicado na carta de projeto. O jogador somente é declarado vencedor se em nenhum dos módulos verificados for encontrado defeito.

Download

• Version 0.1
  - Tabuleiro de Jogo: Formato A4 (4 Engenheiros) ou Formato A3 (5 Engenheiros)
  - Cartões de Projetos
  - Cartas de Artefatos
  - Cartas de Engenheiros de Software
  - Cartas de Conceitos
  - Cartas de Problemas de Código
  

Pessoas Envolvidas

• Eduardo Magno Lages Figueiredo [ emagnoinf.puc-rio.br ]
• Klessis Lopes Dias [ klessisinf.puc-rio.br ]
• Cidiane Aracaty Lobado [ cidianeinf.puc-rio.br ]
• Glória Oliveira [ gloriainf.puc-rio.br ]
• Ritomar Torquato [ ritomargmail.br ]
• Julio Cesar Sampaio do Prado Leite [ julioinf.puc-rio.br ]

Referências desta Página

1. Baker, A.; Navarro, E.; Hoek A. (2005) "An Experimental Card Game for Teaching Software Engineering Processes". In: Journal of Systems and Software, pages 3-16, vol. 75, issue 1-2.
2. Booch, G.; Rumbaugh, J.; Jacobson, I. (1999) "The Unified Modeling Language User Guide". Addison-Wesley, 1st edition.
3. Garcia, A; Sant'Anna, C.; Chavez, C.; Silva, V; Staa, A; Lucena, C. (2004) "Separation of Concerns in Multi-Agent Systems: An Empirical Study". In: Software Engineering for Multi-Agent Systems II, Springer, LNCS 2940.
4. Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J.; Irwin, J. (1997) "Aspect-Oriented Programming". In: European Conference on Object-Oriented Programming (ECOOP), pages 220-242. Finland.
5. Navarro, E.; Baker, A.; Hoek, A. (2004) "Teaching Software Engineering Using Simulation Games". In: International Conference on Simulation in Education (ICSIE). California.