SimulES - Simulador de Engenharia de Software - Parte 2

Nesta aula, os alunos puderam jogar pela primeira vez o SimulES. Observou-se vários aspectos positivos e negativos do jogo durante a partida. Como aspectos positivos, pode-se citar:

• A proposta de um jogo educativo para ensinar boas práticas de engenharia de software
• Aproximar o aluno aos problemas e dificuldades em projetos de sistema de software
• Cartas de problemas e conceitos bem elaboradas
• Referências bibliográficas nas cartas, para que os jogadores possam se aprofundar nos conceitos apresentados.

Porém, com o desenrolar da partida, percebeu-se um jogo demorado e pouco dinâmico, que precisava ser evoluído para se tornar mais atraente, melhorando sua jogabilidade e dinamismo. Pode-se notar algumas perguntas que não foram respondidas somente com a documentação disponível do SimulES, tais como:

• Quando um engenheiro for contratado, ele pode produzir artefatos?
• Posso demitir um engenheiro de software?
• Um artefto que acabou de ser produzido pode ser inspecionado?
• Um engenheiro pode consertar um artefato quando ele já tiver sido integrado?
• Quanto custa inspecionar? E corrigir?
• O que é requisito não claro?
• Quantos problemas persistentes ou não persistentes cada jogador pode ter?
• Como é feita a integração dos módulos do projeto?
• É necessário separar os artefatos de requisitos, desenho, código, rastro e ajuda após serem integrados?
• Um engenheiro de software pode inspecionar artefatos de outro engenheiro?

Além dessas perguntas, ocorreram alguns problemas de inconsistência, como por exemplo, o cartão de projeto do Tomcat possui Complexidade = 4, Tamanho = 4, Qualidade = 5 e Orçamento = 210K. Isso torna inconsistente o projeto, pois é necessário produzir 4 módulos, sendo 5 deles com qualidade. Isso ocorre também com outros cartões de projeto do jogo. Em seguida, pode-se citar algumas cartas que acrescentam um valor ao tamanho do projeto, sem descrever que artefatos devem estar presentes nesses módulos adicionais.

Para solucionar os problemas apresentados é necessária a realização de uma revisão da documentação do SimulES, buscando responder as dúvidas apresentadas e as inconsistências encontradas. Deve-se buscar também, mecanismos para melhorar a dinâmica do jogo, aumentando o interesse dos jogadores e diminuindo o tempo de jogo (a partida teve duração de 3 horas e não se chegou ao final).

Observou-se também que o SimulES ainda está muito "amarrado" ao modelo cascata. Deve-se procurar flexibilizar o jogo para outros modelos de desenvolvimento de software, como o eXtreme Programming.

Existe também uma quantidade muito maior de cartas de problema em relação as cartas de conceito (mais que o dobro). A inserção de cartas de conceito melhoraria consideravelmente o aspecto educativo do jogo, introduzindo ainda mais conceitos de engenharia de software. Cabe ressaltar que é necessário também uma revisão em todas as cartas do jogo.

Por fim, verifica-se que o SimulES é uma interessante ferramenta para o ensino de engenharia de software e deve-se parabenizar a equipe de alunos responsáveis pelo SimulES pelo excelente trabalho de evolução do jogo.