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.