Com o propósito principal de introduzir conceitos de evolução de software no jogo Programadores e Problemas, mas também com outros objetivos em relação à melhoria do jogo. A turma levantou algumas possíveis alterações ao jogo:
A) Definir melhor o número de pessoas. Uma sugestão foi que o jogo fosse jogado por até 9 pessoas, ou em uma faixa entre 4 e 9 pessoas. Em favor de um número maior de pessoas, se encontra o fato de que o jogo foi inicialmente proposto para ser jogado em sala de aula. Como geralmente uma turma tem muitos alunos, mais jogadores significa mais pessoas envolvidas no aprendizado. Por outro lado, um número elevado de jogadores torna o jogo demasiadamente lento.
B) Com o intuito de agilizar o jogo e melhorar sua dinâmica, foram feitas algumas propostas. Por exemplo:
(i) Jogar em equipe (dupla, por exemplo). Esta proposta além fazer com que o jogo tenha um fim mais próximo, também pode ajudar a desenvolver o espírito de coletividade dos jogadores.
(ii) Simplificação dos bugs e código ruim/bom. O jogo oferece possibilidades de simplificações sem que estas alterem seu objetivo principal (educacional). Por exemplo, os bugs poderiam ser de somente um tipo, eliminando a classificação entre “Simples”, “Normal” e “Grave”. Também, a diferenciação entre “Código Ruim” e “Código Bom” poderia ser removida.
C) Criar um catálogo bibliográfico anexo ao jogo. Este catálogo permitiria aos jogadores aumentar o conhecimento sobre determinado assunto. Por exemplo, quando aparecesse um problema relacionado à “Requisitos Unclear”, poderia haver referências que explicassem melhor a importância de uma análise de requisitos bem feita. Um problema com esta proposta é em relação a justamente a dificuldade de montar e manter um catálogo de referências. Para isto, precisaria de uma vasta – huge ;-) – revisão bibliográfica e que novas referências pudessem ser facilmente adicionadas.
D) Para introduzir o conceito de rastreabilidade de requisitos (um conceito muito importante para evolução de software) foram sugeridas cartas de rastreabilidade. Duas propostas foram feitas: (i) que estas cartas poderiam explicitamente indicar qual documentação esta relacionada à qual trecho de código; ou (ii) simplesmente existir cartas de rastreabilidade e jogadores que não às possuísse seriam penalizados.
E) Criar uma classificação para as cartas de documentação (especialmente requisitos), de tal forma que elas pudessem (i) trazer mais conceitos de Engenharia de Software e (ii) aumentar a dinâmica inicial do jogo. Por exemplo, foram sugeridas pelo menos dois novos tipos de carta de documentação: rastreabilidade e requisitos não funcionais (segurança, por exemplo). Em especial, as cartas de requisitos não funcionais poderiam alterar a forma de atuação do jogador.
F) Criar um tabuleiro de jogo para cada jogador. Esta proposta visa organizar melhor a fases do desenvolvimento e organizar a área de jogo de cada jogador. A área de jogo é apresentada na versão original deste jogo, mas não é explicitamente sugerida para os jogadores.
G) Limitar o número de problemas que podem ser jogados para cada pessoa. O número inicial seria um máximo de 3 problemas e os oponentes que sucedessem o jogador seriam responsáveis por apresentar os problemas.
