Evolução das cartas de problemas de RH do jogo SimulES

Nesta aula, os alunos iniciaram o processo de evolução das cartas de problemas do jogo SimulES. Inicialmente, surgiu um debate sobre maturidade e habilidade nas cartas. Decidiu-se que o texto das cartas deveria ser revisto baseados em que habilidade estaria ligado a parte de produção profissional do engenheiro, e maturidade a experiência e personalidade.

Em seguida, os problemas foram divididos entre os alunos por áreas. Segue abaixo, a evolução das cartas de Recursos Humanos. As alterações feitas foram basicamente, escrever maturidade ao invés de personalidade, colocá-las no padrão especificado pela turma, revisão do texto da carta barulho anormal (que tornou-se Atraso no Pagamento).

Referência:

FIGUEIREDO, E. M. L., LOBATO, C. A., DIAS, K. L., LEITE, J. C. S. P., LUCENA, C. J. P., "SimulES: Um Jogo para o Ensino de Engenharia de Software. " Monografia em Ciência da Computação n 34/06. Departamento de Informática - PUC-Rio, 2006.

Evolução e Rastreabilidade dos Cenários do SimulES

Nesta aula, o grupo de alunos se reuniu para corrigir e definir o conjunto de cenários para descrever as regras do SimulES. Abaixo são listados alguns exemplos obtidos. Todos os cenários podem ser obtidos no blog da aluna Milene Serrano , que realizou um excelente trabalho.

Título: Dinâmica do SimulES
Objetivo: Descrever as regras do SimulES
Contexto: INICIO DE JOGO.
Atores: jogador, jogador da vez.
Recursos: dado, cartas, cartão do projeto, tabuleiro.
Episódios: Jogador da vez inicia turno.
Se jogador da vez puder empacotar o produto, então jogador da vez SUBMETE PRODUTO.
Jogador da vez JOGA RODADA DE AÇÕES.
Cada jogador JOGA RODADA DE AÇÕES.
Jogador da vez JOGA RODADA DE CONCEITOS.
Cada jogador JOGA RODADA DE CONCEITOS.
Jogador da vez TRATA PROBLEMAS.
Cada jogador TRATA PROBLEMAS.


É fácil observar a separação do jogo em rodada de ações e rodada de conceitos .


Título: Joga Rodada de Ações
Objetivo: Descrever as regras da rodada de ações.
Contexto: Cartão do projeto no centro da mesa.
Jogador da vez já foi escolhido.
Atores: jogador da vez.
Recursos: dado, cartas, cartão do projeto, tabuleiro.
Episódios: Jogador da vez usa seus Engenheiros de Software em CONSTRÓI ARTEFATO ou INSPECIONA ARTEFATO ou CORRIGE ARTEFATO de acordo com a habilidade de cada engenheiro de software. Restrição: Habilidades e o custo dessas ações podem ser afetados por cartas de conceitos ou cartas de problemas.
Jogador da vez lança o dado.
Se dado igual a 1, 2 ou 3, então jogador da vez pega 1, 2 ou 3 cartas do monte de problemas e conceitos. Restrição: jogador da vez não pode pegar cartas do monte de engenheiros de software.
Se dado igual a 4 ou 5 ou 6, então jogador da vez pega 3 cartas do monte de problemas e conceitos e x cartas do monte de engenheiro de software, onde x é o valor do dado menos 3.
Se jogador da vez não usou engenheiros de software e nem jogou o dado, então INTEGRA ARTEFATOS EM UM MÓDULO.

Um último exemplo poderia ser:


Título: Submete produto
Objetivo: Descrever as regras da submissão de produto.
Contexto: Cartão do projeto no centro da mesa.
Jogador de vez acabou de integrar seu último módulo.
Atores: jogador, jogador da vez, adversário.
Recursos: cartas, cartão do projeto, módulo.
Episódios: Jogador da vez mostra que produziu todos os módulos, de acordo com o cartão do projeto.
Adversários escolhem todos os artefatos de x módulos, onde x é o nível de qualidade do projeto. Restrição: Adversários não podem escolher módulo protegido por carta de conceito do jogador da vez.
Adversários desviram artefatos escolhidos.
Adversários verificam artefatos desvirados.
Se artefatos verificados forem livres de defeito, então jogador da vez ganha o jogo.
Se artefatos verificados forem defeituosos, então jogador da vez pode corrigir um por turno de jogo.


Os cenários apresentados anteriormente pertencem a sua versão D. Mas o que é rastreabilidade e como é possível manter a rastreabilidade em um projeto de software?

Para responder essas perguntas e preocupado com a rastreabilidade na evolução do jogo SimulES, a turma realizou a leitura do artigo Rastreabilidade de Requisitos .
Do ponto de vista gerencial, a rastreabilidade possibilita identificar rapidamente artefatos de desenho, projeto e código afetados por uma solicitação de mudança. Para isso, a gerência deve entre outras ações: documentar, realizar controle de mudanças, manter planos, descrever os cenários, etc. Do ponto de vista da qualidade, a importância da rastreabilidade está na análise da cobertura de testes de funcionalidade e correção de defeitos.

Com relação ao SimulES, ao utilizar o software C&L (cenários e léxico), tem-se um elo indicando toda relação de dependência entre cenários, objetos, verbos, estados entre outros. Além disso, foi exercitado em aula o processo de rastreabilidade entre os cenários do jogo. Inicialmente, foram definidas para as 4 versões de cenários presentes as letras A, B, C, D. Em seguida, definiu-se a granularidade para rastreabilidade a diferença entre as sentenças. Cada sentença em cada versão possuia um código único. Por exemplo, na versão A, o primeiro cenário possui código CA1 (C - cenário e A - versão e 1 - numeração do cenário). Logo o contexto desse cenário seria CA1C1. Baseado nisso, pode-se apresentar um exemplo de evolução de cenários:


Título: Inicio de jogo (CA1)
Objetivo: Descrever as regras do SimulES (CA1O1)
Contexto: Informações do projeto no centro da mesa (CA1C1)
Primeiro jogador já foi escolhido (CA1C2)
Atores: jogadores (CA1A1)
Recursos: dado, cartas, informações do projeto (CA1R1), (CA1R2), (CA1R3)
Episódio: Jogador da vez inicia rodada. (CA1E1)
Jogador JOGA DADO. (CA1E2)
Jogador DESCARTA CARTAS. (CA1E3)
Jogador RECEBE CARTAS. (CA1E4)
Se jogador empacotou o produto, então jogador SUBMETE PRODUTO. (CA1E5)


Título: Inicio de jogo (CB2)
Objetivo: Descrever os preparativos para inicio do jogo (CB2O2)
Contexto: Tabuleiro de cada jogador colocado na mesa de jogo. (CB2C1)
Cada jogador tem uma carta de engenheiro de software. (CB2C2)
Atores: jogador (CB2A1)
Recursos: dado, cartas, informações do projeto. (CB2R1), (CB2R2), (CB2R3)
Episódios: Jogador joga dado. Restrição: Maior dado inicia jogo. (CB2E1)
Jogador escolhe aleatoriamente do monte de carta de informações de projeto um projeto. (CB2E2) Restrição: outros jogadores têm que concordar com carta escolhida por jogador que inicia jogo.
Cada jogador escolhe uma carta de engenheiro de software e coloca-a no tabuleiro. (CB2E3)


Título: Inicio de jogo (CC2)
Objetivo: Descrever os preparativos para inicio do jogo. (CC2O1)
Contexto: Tabuleiro de cada jogador colocado na mesa de jogo. (CC2C1)
Cartas embaralhadas sobre a mesa. (CC2C2)
Cada jogador tem uma carta de engenheiro de software. (CC2C3)
Atores: jogador (CC2A1)
Recursos: dado, cartas, informações do projeto, tabuleiro.(CC2R1),(CC2R2),(CC2R3)
Episódio: Jogador joga dado. Restrição: Jogador que tirar o maior número no dado, inicia o jogo. (CC2E1)
Jogador escolhe aleatoriamente do monte de cartões de projeto. Restrição: Outros jogadores têm que concordar com carta escolhida por jogador que inicia jogo. (CC2E2)
Cada jogador compra uma carta de engenheiro de software e coloca-a no tabuleiro. Restrição: Sentido de jogo é horário. (CC2E3)


Título: Inicio de jogo (CD2)
Objetivo: Descrever os preparativos para início do jogo. (CD2O1)
Contexto: Tabuleiro de cada jogador colocado na mesa de jogo. (CD2C1)
Cartas embaralhadas sobre a mesa. (CD2C2)
Cada jogador tem uma carta de engenheiro de software. (CD2C3)
Atores: jogador, jogador da vez. (CD2A1), (CD2A2)
Recursos: dado, cartas, cartão do projeto, tabuleiro. (CD2R1), (CD2R2), (CD2R3)
Episódios: Jogador joga dado. Restrição: Jogador que tirar o maior número no dado, inicia o jogo e é o jogador da vez. (CD2E1)
Jogador da vez escolhe aleatoriamente do monte de cartões de projeto. Restrição: Outros jogadores têm que concordar com o cartão escolhido pelo jogador da vez. (CD2E2)
Cada jogador compra uma carta de engenheiro de software e coloca-a no tabuleiro. Restrição: Sentido de jogo é horário. (CD2E3)

Ao final do exemplo pode-se perceber como foram realizadas todas as mudanças nos cenários. Uma das mudanças perceptíveis foi a versão do cenário CA1 para CB2, pois o cenário A foi quebrado em 2 cenários, nascendo assim um novo cenário CB1 (Dinâmica do SimulES).

Ao fim da atividade, s alunos puderam perceber o quanto é difícil documentar a evolução de um software e manter a rastreabilidade entre elas.

Construção do léxico para o jogo SimulES

Nesta aula, os alunos iniciaram a construção do léxico para o jogo SimulES, baseado nos cenários produzidos e corrigidos anteriormente. Foi utilizado para esta tarefa o software C&L.
Inicialmente, foram identificados e separados os sujeitos, verbos, objetos e estados.

Sujeitos: jogador, adversário

Verbos: comprar, descartar, desvirar, produzir, construir, inspecionar, integrar, contratar, empacotar, jogar, verificar. Importante salientar as demais conjugações possíveis de todos os verbos.

Objetos: carta, cartão, carta de conceito, carta de problema, sentidod do jogo, tabuleiro, pontos de tempo, monte, habilidade, maturidade, módulo, tamanho do projeto, complexidade do projeto, qualidade do projeto, orçamento do projeto, engenheiro de software, artefato, artefato branco, artefato cinza.

Estados: contratado, demitido, escolhido, desvirado, defeituoso, livre de defeito.

Em seguida, é apresentado alguns léxicos presentes no C&L:


Nome: artefato
Noção: Cartas que simbolizam os produtos que são produzidos pelos engenheiros de software e que podem ou não conter defeitos.
Artefatos com defeito possuem um inseto.
Podem ser de boa qualidade (branco) ou de má qualidade (cinza).
Classificação: Objeto
Impacto(s): Jogador pode produzir artefato. Jogador coloca artefatos no tabuleiro.
Sinônimo: artefatos


Nome: carta de conceito
Noção: Cartas que representam boas práticas de Engenharia de Software. Possuem referências para pesquisas do conceito citado. Podem neutralizar cartas de problemas.
Classificação: Objeto
Impacto(s): Jogador compra carta de conceito.
Jogador descarta carta de conceito.
Jogador usa carta de conceito.
Jogador coloca carta de conceito no tabuleiro.
Sinônimo: cartas de conceito conceito



Nome: carta de problema
Noção: Cartas que descrevem problemas clássicos de Engenharia de Software resultantes de faltas no processo de produção. São utilizadas para criar obstáculos ao progresso dos jogadores adversários. Podem ser neutralizadas por cartas de conceito.
Classificação: Objeto
Impacto(s): Jogador compra carta de problema. Jogador descarta carta de problema. Jogador usa carta de problema. Jogador coloca carta de problema no tabuleiro.
Algumas cartas de problema usam a maturidade como condição de aplicação do problema.
Sinônimo: cartas de problema problema cartas de problemas


Nome: engenheiro de software
Noção: Carta do jogo que representa o profissional responsável por desempenhar ações. Possui habilidade e maturidade.
Classificação: Objeto
Impacto(s): Um jogador pode contratar e/ou demitir engenheiros de software. Um jogador pode desempenhar ações por meio de seus engenheiros de software contratados.
Sinônimo: engenheiros de software


Nome: contratar
Noção: Jogador contrata engenheiro de software.
No início do jogo é obrigatório cada jogador contratar um engenheiro de software.
O engenheiro contratado deve ser colocado no tabuleiro do jogador.
Classificação: Verbo
Impacto(s): Engenheiro de software contratado só poderá produzir artefatos no próximo turno.
Sinônimo: Contratados contrata contratação

Descrição das regras do SimulES utilizando Cenários

Nesta aula, os alunos tiveram contato com uma linguagem para descrição de cenários, com o objetivo de escrever as regras do SImulES. Pode-se verificar os cenários no site do prof. Júlio. Abaixo, seguem exemplos de descrições realizadas:

Título: Inicio de jogo
Objetivo: Descrever as regras do SimulES
Contexto: Informações do projeto no centro da mesa
Primeiro jogador já foi escolhido
Atores: jogadores
Recursos: dado, cartas, informações do projeto
Episódio: Jogador da vez inicia rodada.
Jogador JOGA DADO.
Jogador DESCARTA CARTAS.
Jogador RECEBE CARTAS.
Se jogador empacotou o produto, então jogador SUBMETE PRODUTO.


Título: Constrói artefato
Objetivo: Descrever as regras de construir artefatos
Contexto: Informações do projeto no centro da mesa
Jogador já descartou cartas de conceito
Atores: jogadores, jogador
Recursos: cartas, informações do projeto
Episódio: Jogador, para cada carta de engenheiro de software, escolhe do monte de artefatos os artefatos que podem ser produzidos por aquele engenheiro de software.Se jogador escolhe carta branca, então o número de cartas é determinado pela complexidade do projeto e pela habilidade da carta de engenheiro de software.Se o jogador escolhe carta cinza, então o número de cartas é determinado pela metade mais um da complexidade do projeto e pela habilidade da carta engenheiro de software. estuda como atender a demanda d carta de problema colocado pelo concorrente.Jogador coloca as cartas escolhidas no tabuleiro de acordo com o jogador e de acordo com o tipo de artefato produzido.

SimulES - Simulador de Engenharia de Software - Parte 3

Os alunos jogaram novamente o SimulES nesta aula. Porém, durante a partida foram sendo realizadas as correções dos problemas citados na postagem anterior. Inicialmente, respondeu-se as perguntas que até então estavam pendentes:

1. Quando um engenheiro for contratado, ele pode produzir artefatos?
Sim

2. Posso demitir um engenheiro de software?
Sim

3. Um artefato que acabou de ser produzido pode ser inspecionado?
Somente na próxima rodada

4. Um engenheiro pode consertar um artefato quando ele já tiver sido integrado?
Sim

5. Quanto custa inspecionar? E corrigir?
Ambas custam 1.

6. O que é requisito não claro?
São requisitos adquiridos com artefatos de cor cinza (má qualidade).

7. Quantos problemas persistentes ou não persistentes cada jogador pode ter?
2 persistentes e 3 não persistentes no máximo

8. Como é feita a integração dos módulos do projeto?
Quando o jogador tiver completado um módulo, a integração do mesmo utiliza uma rodada completa.

9. É necessário separar os artefatos de requisitos, desenho, código, rastro e ajuda após serem integrados?
Não

10. Um engenheiro de software pode inspecionar artefatos de outro engenheiro?
Sim

Após responder essas perguntas, o jogo foi se desenvolvendo e sendo analisado, buscando principalmente melhorar o dinamismo. Foi quando surgiu a ideia de separar o turno em duas rodadas: rodada de ações e rodada de conceitos.

No início do jogo, os jogadores devem iniciar comprando uma carta de engenheiro de software, começando por quem tirou o maior valor no dado. Após isso, começa a rodada de ações.

Na rodada de ações, o jogador lança o dado e compra cartas de problemas/conceitos e/ou cartas de engenheiros de software, dependendo do número obtido no dado. Em seguida, os jogadores podem construir e inspecionar artefatos, corrigir artefatos com bugs e integrar módulos.
Para construir artefatos brancos, o jogador gasta o equivalente a complexidade do projeto. Para artefatos cinza, o custo é a metade deste valor. Para inspecionar artefatos, o engenheiro de software gasta 1 ponto de tempo (o mesmo valor para corrigir um artefato defeituoso). Para integrar um módulo o jogador gasta toda a rodada, sem poder realizar nenhuma ação.

Na rodada de conceitos, os jogadores analisam suas cartas e aplicam os problemas e conceitos, podendo ainda demitir engenheiros.

Com essas modificações, o SimulEs melhorou consideravelmente sua jogabilidade e aumentou o dinamismo, conseguindo-se chegar ao final da partida em aproximadamente 2 horas.

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.