Padrões Estabelecidos para Evolução das Cartas (Parte I)

Na aula passada, começamos a evolução das cartas de problema. Concluímos as cartas de problema de código e também algumas cartas de problema de desenho.

 

Debatemos sobre como seria a melhor forma de considerar habilidade e maturidade. Pensamos em estabelecer três conceitos: habilidade (capacidade de produzir artefatos); Experiência (capacidade de produzir com qualidade) e personalidade (capacidade pessoal de cada engenheiro em lidar com problemas do dia-a-dia dado seu caráter pessoal, sua facilidade de comunicação, sua arrogância, sua pretensão, seu bom-humor, etc).

 

Ficou estabelecido que vamos considerar habilidade (capacidade de produzir artefatos com qualidade) e maturidade (considerando uma mistura de experiência e personalidade). Mas, tentaríamos direcionar, nos textos das cartas, quando exatamente usar habilidade e quando utilizar maturidade e em que sentido. O objetivo é direcionar o leitor para que o mesmo não tenha dúvidas sobre como agir. Caso ficasse evidente a necessidade em considerar Habilidade, Experiência e Personalidade, ou colocaríamos como trabalho futuro ou já estabeleceríamos esses conceitos nessa mesma versão.

 

Estabelecemos alguns padrões que devem ser seguidos por todos na evolução das demais cartas. Como sugestão do aluno Bruno, estou postando no meu Blog esses padrões. Conforme sugerido pelo professor Julio estou apresentando esses padrões colocando exemplos para facilitar o entendimento e aplicação dos mesmos. Seguem os padrões definidos em aula:

1) Padrão utilizar £ ou ³ no lugar de < ou >, respectivamente:

Antes de Aplicar o Padrão:               Depois de Aplicar o Padrão:

2) Padrão para penalizar em termos de pontos de tempo para construir, corrigir e inspecionar:

Antes de Aplicar o Padrão:                 Depois de Aplicar o Padrão:

 

3) Padrão para penalizar de forma educativa o jogador:

Antes de Aplicar o Padrão:                   Depois de Aplicar o Padrão:

 

4) Padrão para penalizar de forma educativa aplicando perdas de artefatos:

Antes de Aplicar o Padrão:                    Depois de Aplicar o Padrão:

5) Padrão a ser considerado em cartas onde existe o conceito de maturidade:

Antes de Aplicar o Padrão:                        Depois de Aplicar o Padrão:

  

6) Padrão evitar o adjetivo “má”:

Antes de Aplicar o Padrão:                         Depois de Aplicar o Padrão:

 

7) Padrão utilizar “rastro” no lugar de “rastreabilidade”:

Antes de Aplicar o Padrão:                       Depois de Aplicar o Padrão:

 

8) Padrão utilizar “corrigir” (ou conjugações) “artefato” no lugar de “consertar” “defeito”:

Antes de Aplicar o Padrão:                      Depois de Aplicar o Padrão:

 

9) Padrão utilizar “construir” (ou conjugações) artefato no lugar de “criar” artefato:

Antes de Aplicar o Padrão:                      Depois de Aplicar o Padrão:

 

10) Padrão utilizar “requisito cinza” no lugar de “requisitos não claros”:

Antes de Aplicar o Padrão:                  Depois de Aplicar o Padrão:

 

Espero ter exemplificado a maior parte dos padrões que estabelecemos.

 

No próximo post pretendo colocar a evolução das cartas que me foram confiadas.

 

Até o próximo post!

Read Full Post »

Rastreabilidade (Parte II) e Construção dos Cenários do Jogo SimulES (Parte II)

Conforme solicitado pelo professor Julio, seguem os cenários, já modificados, de acordo com as observações levantadas em sala.

Cenários Obtidos (Quarta Versão): 

Título: Dinâmica do SimulES

Objetivo: Descrever as regras do SimulES

Contexto: INICIO DE JOGO.

Atores: jogador

Recursos: dado, cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador da vez inicia turno.

Se jogador puder empacotar o produto, então jogador SUBMETE PRODUTO.

Jogador JOGA RODADA DE AÇÕES.

Jogador JOGA RODADA DE CONCEITOS.

Jogador TRATA PROBLEMAS.
______________________

Título: Inicio de jogo

Objetivo: Descrever os preparativos para inicio do jogo.

Contexto: Tabuleiro de cada jogador colocado na mesa de jogo.

Cartas embaralhadas sobre a mesa.

Cada jogador tem uma carta de engenheiro de software.

Atores: jogador

Recursos: dado, cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador joga dado. Restrição: Jogador que tirar o maior número no dado, inicia o jogo.

Jogador escolhe aleatoriamente do monte de cartões de projeto. Restrição: Outros jogadores têm que concordar com o cartão escolhido pelo jogador que inicia o jogo.

Cada jogador compra uma carta de engenheiro de software e coloca-a no tabuleiro. Restrição: Sentido de jogo é horário.

___________________________

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.

Primeiro jogador já foi escolhido.

Atores: jogador

Recursos: dado, cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador 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 lança o dado.

Se dado igual a 1, 2 ou 3, então jogador pega 1, 2 ou 3 cartas do monte de problemas e conceitos. Restrição: jogador não pode pegar cartas do monte de engenheiros de software.

Se dado igual a 4 ou 5 ou 6, então jogador 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 não usou engenheiros de software e nem jogou o dado, então INTEGRA ARTEFATOS EM UM MÓDULO.  

________________________________

Título: Joga Rodada de Conceitos

Objetivo: Descrever as regras da rodada de conceitos.

Contexto: Cartão do projeto no centro da mesa.

Primeiro jogador já foi escolhido.

Todos os jogadores terminaram JOGA RODADA DE AÇÕES.

Atores: jogador, concorrente.

Recursos: cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador aplica conceitos caso sejam permanentes, colocando-os ao lado do tabuleiro. Restrição: Não pode exceder o orçamento do projeto.

Se jogador tem cartas de engenheiro de software, então jogador contrata engenheiro de software de acordo com o orçamento do projeto (que consta no cartão do projeto), colocando-os no tabuleiro.

Jogador descarta cartas, retornando-as aos montes apropriados.

Jogador escolhe até 3 concorrentes e pode submeter para cada um deles uma carta de problema. Restrição: Concorrente não pode ter mais de 2 cartas de problemas permanentes e mais de 3 cartas de problemas temporários.

Jogador lê em voz alta o problema que submete ao concorrente. Restrição: Quem escolhe as cartas do concorrente afetadas pelos problemas impostos é o próprio jogador.

_____________________________

Título: Trata Problemas

Objetivo: Descrever as regras do tratamento de problemas.

Contexto: Cartão do projeto no centro da mesa.

Todos os jogadores terminaram JOGA RODADA DE CONCEITOS.

Jogador recebeu cartas de concorrente.

Atores: jogador, concorrente.

 Recursos: cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador estuda como atender a demanda da carta de problema colocada pelo concorrente.

Jogador atende a demanda da carta de problema. Restrição: Carta de problema pode ser contraposta por carta de conceito.

Se o problema é temporário então jogador descarta a carta de problema. Restrição: Carta de problema pode ser contraposta por carta de conceito.

Se o problema é permanente então jogador mantém carta de problema. Restrição: Carta de problema pode ser contraposta por carta de conceito. Jogador pode demitir um engenheiro de software, descartando-o. 

__________________________

Título: Submete produto

Objetivo: Descrever as regras da submissão de produto.

Contexto: Cartão do projeto no centro da mesa.

Jogador acabou de integrar seu último módulo.

Atores: jogador, concorrente.

Recursos: cartas, cartão do projeto, módulos.

Episódios:
Jogador mostra que produziu todos os módulos, de acordo com o cartão do projeto.

Concorrentes escolhem todos os artefatos de x módulos, onde x é o nível de qualidade do projeto. Restrição: Concorrentes não podem escolher módulo protegido por carta de conceito do jogador.

Concorrentes desviram artefatos escolhidos.

Concorrentes verificam artefatos desvirados.

Se artefatos verificados forem livres de defeito, então jogador ganha o jogo.  

Se artefatos verificados forem defeituosos, então jogador pode corrigir um por turno de jogo. 

_________________________

Título: Constrói artefato  

Objetivo: Descrever as regras da construção de artefatos.  

Contexto: Cartão do projeto no centro da mesa.

Atores: jogador

Recursos: cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador, para cada carta de engenheiro de software, compra do monte de artefatos. Restrição: A quantidade de artefatos depende da habilidade do engenheiro de software, do tipo do artefato escolhido e da complexidade do projeto.

Se jogador compra carta branca, então o número de cartas é determinado pela complexidade do projeto e pela habilidade do engenheiro de software. Restrição: Cartas brancas custam valor da complexidade do projeto.

Se o jogador compra carta cinza, então o número de cartas é determinado pela metade da complexidade do projeto e pela habilidade do engenheiro de software. Restrição: Cartas cinzas custam metade do valor da complexidade do projeto.

Jogador coloca as cartas compradas no tabuleiro de acordo com o engenheiro de software e de acordo com o tipo de artefato produzido.

______________________________

Título: Inspeciona artefato

Objetivo: Descrever as regras da inspeção de artefatos.

Contexto: Cartão do projeto no centro da mesa.

Jogador tem artefatos no tabuleiro.

Atores: jogador

Recursos: cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador escolhe artefato do tabuleiro.

Se o engenheiro de software responsável pelo artefato faz a inspeção, então o mesmo gasta um ponto de tempo.

Se outro engenheiro de software faz a inspeção, então esse gasta dois pontos de tempo.

Artefato inspecionado é desvirado no tabuleiro.  

________________________

Título: Corrige artefato

Objetivo: Descrever as regras da correção de artefatos.

Contexto: Cartão do projeto no centro da mesa.

Jogador tem artefatos inspecionados com defeito (INSPECIONA ARTEFATO) no tabuleiro.

Atores: jogador

Recursos: cartas, cartão do projeto, tabuleiro.  

Episódios:
Jogador escolhe artefato com defeito do tabuleiro.

Se o engenheiro de software responsável pelo artefato faz a correção, então o mesmo gasta um ponto de tempo.

Se outro engenheiro de software faz a correção, então esse gasta dois pontos de tempo.

Artefato inspecionado é substituído por artefato da mesma cor comprado do monte de artefatos.   

_____________________________ 

Título: Integra artefatos em um módulo

Objetivo: Descrever as regras da integração de artefatos.

Contexto: Cartão do projeto no centro da mesa.

Jogador tem artefatos no tabuleiro.

Atores: jogador

Recursos: cartas, cartão do projeto, tabuleiro.

Episódios:
Jogador escolhe módulo do projeto.

Jogador seleciona artefatos do tabuleiro, independente do responsável (engenheiro de software) de acordo com o cartão do projeto.

Jogador integra o módulo juntando as cartas em um monte fora do tabuleiro. 

********** Rastreabilidade **********

Em relação à rastreabilidade da Evolução do Jogo, exercitamos na aula passada, como é feito o processo de rastreabilidade. Para isso, consideramos as versões 1, 2 e 3 da construção dos cenários. Denominamos a primeira versão como A, a segunda como B e a terceira como C.

Definimos ainda que a granularidade utilizada no rastreamento seria determinada por diferenças entre sentenças. Esse foi um ponto alto da aula, onde discutimos a dificuldade de se determinar qual a granularidade a ser considerada no processo de rastreabilidade de um software. Assim, decidimos, para o nosso caso, que cada sentença dos cenários seria identificada com um código. Depois comparamos cada uma dessas sentenças, determinamos quais sentenças foram modificadas, quais permaneceram inalteradas e fizemos a associação entre elas de acordo com as versões A, B e C. O resultado foi que percebemos alguns erros na montagem dos cenários o que originou a quarta versão apresentada anteriormente nesse mesmo post.

Percebemos que é bastante complicado documentar a evolução de um software, trabalhar com diferentes versões e manter o rastro entre elas. De qualquer forma, percebemos também que é uma boa prática manter o rastro, pois já considerávamos a versão C uma versão bem completa dos cenários do Jogo SimulES e percebemos erros que nos levaram a versão 4.

 ********** Refatoração e Design Orientado a Objetos **********

O documento Envolving Object-Oriented Designs with Refactorings indicado para leitura pelo professor Julio também foi objeto dos meus estudos essa semana. Esse documento apresenta basicamente três tipos de design de evolução. Particularmente achei interessante considerar os padrões de projeto como forma de se aplicar soluções inteligentes em problemas comuns encontrados no desenvolvimento de softwares orientado a objetos. Alguns padrões apontados são: Command, Abstract Factory, Singleton, Composite, Decorator e Integrator.

 ********** Evolução das Cartas do Jogo SimulES **********

Foi solicitado também pelo professor Julio que as cartas do jogo SimulES evoluam. Tenho algumas sugestões que apresentarei em sala hoje.

Até a aula pessoal!

Read Full Post »

Rastreabilidade (Parte I) e a Evolução do Jogo SimulES (Parte II)

Primeiramente, gostaria de postar sobre o que conseguimos realizar na aula passada:

1) Identificamos, mesmo que ainda não todas, mas boa parte das palavras chaves do jogo SimulES e as classificamos em sujeito, verbo, objeto e estado. O objetivo dessa classificação foi obter o léxico.

2) Achamos pertinente documentar os cenários, já determinados, e a construção do léxico no CEL (Cenários&Léxico). Já documentamos todos os cenários e fizemos boa parte do léxico, porém, devido a alguns problemas encontrados, não conseguimos terminar essa tarefa. Tivemos inclusive que recuperar boa parte do que fizemos, acessando diretamente o banco de dados do CEL. Essa tarefa foi realizada pelo aluno Maurício.

3) Ficamos também com a tarefa de ler os documentos sugeridos pelo professor Julio. Esses documentos serão debatidos na próxima aula, no caso, na aula de hoje.

Uma outra preocupação apontada pelo professor Julio era manter a rastreabilidade no processo de evolução do jogo SimulES. Com base no documento Rastreabilidade de Requisitos, tenho algumas coisas a comentar e que são apresentadas a seguir:

• Rastreabilidade de requisitos pode ser entendida como um requisito não funcional que visa estabelecer relacionamentos entre os requisitos do sistema;
• Questões inerentes do gerenciamento de requisitos, que busca, principalmente, estabelecer uma visão comum entre cliente e equipe de desenvolvimento de projeto, estão intimamente relacionadas com a rastreabilidade. Dentre algumas das preocupações inerentes da Gerência de Requisitos, destacam-se:
  • Documentar;
  • Controlar as mudanças;
  • Manter planos;
  • Descrever em linguagem natural, e
  • Modelar os cenários.
• Outro ponto importante é entender que rastreabilidade significa estabelecer uma dependência entre os requisitos e suas fontes; determinar porque os requisitos existem; identificar quais outros requisitos se relacionam com um dado requisito; perceber como um dado requisito se relaciona com outras informações, dentre outros detalhes.

Acredito, portanto, que já demos o primeiro passo nesse sentido, pois, de certa forma, o fato de termos utilizado uma linguagem para descrição de cenários e de documentarmos todos os cenários e parte do léxico no CEL ajuda muito identificar os relacionamentos de dependência entre, cenários, artefatos e objetos, por exemplo. Isso é facilitado pois definimos sinônimos para os sujetos, objetos, verbos e estados e o CEL cuida de estabelecer as ligações entre esses conceitos. Através desses links, providos pelo CEL, com base nas especificações que fizemos, é possível navegar, conhecer detalhes dos cenários, perceber se alguma especificação não está de acordo, estabelecer de certa forma um fluxo de atividades e ter uma noção do todo. Acredito, até mesmo, que isso facilita a inspeção de cenários e a identificação de padrões nesses cenários.

 

Um ponto que merece ser destacado e que é apontado no documento de Rastreabilidade citado anteriormente, consiste em diferenciar o que é Gerência de Requisitos e o que vem a ser Gerência dos Requisitos. Muitas vezes, passa-se despercebido ou mesmo pode ser confundido um como o outro:

1. Gerência de Requisitos: Controlar todo o processo de desenvolvimento tendo como referência uma baseline.
2. Gerência dos Requisitos: Acompanha a evolução dos resquisitos do sistema.

O documento aponta ainda uma incoerência identificada nos modelos de qualidade CMM e CMMI. Gerência de requisitos é exigida no nível 2 do CMMI e Gerência dos requisitos é exigida no nível 3. Dessa forma, como é possível obter os requisitos que devem ser gerenciados no nível 2? Seria através das atividades de elicitação, modelagem, verificação, etc que são apresentadas no nível 3? No caso do gerenciamento de qualidade, por exemplo, pressupõe requisitos de qualidade! Então, existe uma discrepância na distribuição das atividades nos níveis de maturidade propostos nos modelos CMM e CMMI. Deixo essa colocação para reflexão de todos.

 

Num próximo post pretendo trabalhar mais a idéia de como prover rastreabilidade no contexto do Jogo SimulES.

Boa aula a todos!

Read Full Post »

Construção dos Cenários do Jogo SimulES e Construção do Léxico – Parte I

Na aula do dia 10 de maio, nos reunimos com o propósito de construir os cenários do jogo SimulES baseando-nos nas regras de jogo e iniciar a construção do léxico, identificando, primeiramente, as palavras chaves.O resultado da aula pode ser conferido a seguir e foi obtido com a participação de todos os alunos presentes em sala. 

Cenários Obtidos: 

Título: Dinâmica do SimulES

Objetivo: Descrever as regras do SimulES

Contexto: INICIO DE JOGO.

Atores: jogador

Recursos: dado, cartas, informações do projeto, tabuleiro.

Episódios:
Jogador da vez inicia turno.

Se jogador puder empacotar o produto, então jogador SUBMETE PRODUTO.

Jogador JOGA RODADA DE AÇÕES.

Jogador JOGA RODADA DE CONCEITOS.

Jogador TRATA PROBLEMAS.

Título: Inicio de jogo

Objetivo: Descrever os preparativos para inicio do jogo.

Contexto: Tabuleiro de cada jogador colocado na mesa de jogo.

Cartas embaralhadas sobre a mesa.

Cada jogador tem uma carta de engenheiro de software.

Atores: jogador

Recursos: dado, cartas, informações do projeto, tabuleiro.

Episódios:
Jogador joga dado. Restrição: Jogador que tirar o maior número no dado, inicia o jogo.

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.

Cada jogador compra uma carta de engenheiro de software e coloca-a no tabuleiro. Restrição: Sentido de jogo é horário.

Título: Joga Rodada de Ações

Objetivo: Descrever as regras da rodada de ações.

Contexto: Informações do projeto no centro da mesa.

Primeiro jogador já foi escolhido.

Atores: jogador

Recursos: dado, cartas, informações do projeto, tabuleiro.

Episódios:
Jogador usa seus Engenheiros de Software em CONSTRÓI ARTEFATO ou INSPECIONA ARTEFATO ou CORRIGE DEFEITO 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 lança o dado.Se dado igual a 1,ou 2 ou 3, então jogador pega 1, 2 ou 3 cartas do monte de problemas e conceitos. Restrição: jogador não pode pegar cartas do monte de engenheiros de software.

Se dado igual a 4 ou 5 ou 6, então jogador 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 não usou engenheiros de software e nem jogou o dado, então INTEGRA ARTEFATOS EM UM MÓDULO.

Título: Joga Rodada de Conceitos

Objetivo: Descrever as regras da rodada de conceitos.

Contexto: Informações do projeto no centro da mesa.

Primeiro jogador já foi escolhido.

Todos os jogadores terminaram JOGA RODADA DE AÇÕES.

Atores: jogador, concorrente.

Recursos: cartas, informações do projeto, tabuleiro.

Episódios:
Jogador aplica conceitos caso sejam permanentes, colocando-os ao lado do tabuleiro. Restrição: Não pode exceder o orçamento disponível no projeto.

Se jogador tem cartas de engenheiro de software, então jogador contrata engenheiro de software de acordo com o orçamento disponível (que consta nas informações do projeto), colocando-os no tabuleiro.

Jogador descarta cartas, retornando-as aos montes apropriados.

Jogador escolhe até 3 concorrentes e pode submeter para cada um uma carta de problema. Restrição: Concorrente não pode ter mais de 2 cartas de problemas permanentes e mais de 3 cartas de problemas temporários.

Jogador lê em voz alta o problema que submete ao concorrente. Restrição: Quem escolhe as cartas do concorrente afetadas pelos problemas impostos é o próprio jogador.

Título: Trata Problemas

Objetivo: Descrever as regras do tratamento de problemas.

Contexto: Informações do projeto no centro da mesa.

Todos os jogadores terminaram JOGA RODADA DE CONCEITOS.

Jogador recebeu cartas de concorrente.

Atores: jogador, concorrente.

Recursos: cartas, informações do projeto, tabuleiro.

Episódios:
Jogador estuda como atender a demanda da carta de problema colocada pelo concorrente.

Jogador atende a demanda da carta de problema. Restrição: Carta de problema pode ser contraposta por carta de conceito.

Se o problema é temporário então jogador descarta a carta de problema. Restrição: Carta de problema pode ser contraposta por carta de conceito.

Se o problema é permanente então jogador mantém carta de problema. Restrição: Carta de problema pode ser contraposta por carta de conceito.Jogador pode demitir um engenheiro de software, descartando-o. 

  Título: Submete produto

Objetivo: Descrever as regras da submissão de produto.

Contexto: Informações do projeto no centro da mesa.

Jogador acabou de integrar seu último modulo.

Atores: jogador, concorrente.

Recursos: cartas, informações do projeto, módulos.

Episódios:
Jogador mostra que produziu todos os módulos, de acordo com as informações de projeto.

Concorrente (qualquer) verifica todos os artefatos de x módulos, onde x é o nível de qualidade do projeto. Restrição: Concorrente não pode selecionar módulo protegido por carta conceito do jogador.

Se artefatos escolhidos (desvirados) forem livres de defeito, então jogador ganha o jogo. Se artefatos escolhidos (desvirados) forem defeituosos, então jogador pode corrigir um por turno de jogo. 

Título: Constrói artefato

Objetivo: Descrever as regras da construção de artefatos. Contexto: Informações do projeto no centro da mesa.

Atores: jogador

Recursos: cartas, informações do projeto, tabuleiro.

Episódios:
Jogador, para cada carta de engenheiro de software, compra do monte de artefatos os artefatos que podem ser produzidos por aquele engenheiro de software.

Se jogador compra carta branca, então o número de cartas é determinado pela complexidade do projeto e pela habilidade do engenheiro de software.

Se o jogador compra carta cinza, então o número de cartas é determinado pela metade da complexidade do projeto e pela habilidade do engenheiro de software.

Jogador coloca as cartas compradas no tabuleiro de acordo com o engenheiro de software e de acordo com o tipo de artefato produzido.

Título: Inspeciona artefato

Objetivo: Descrever as regras da inspeção de artefatos.

Contexto: Informações do projeto no centro da mesa.

Jogador tem artefatos no tabuleiro.

Atores: jogador

Recursos: cartas, informações do projeto, tabuleiro.

Episódios:
Jogador escolhe artefato do tabuleiro.

Se o engenheiro de software responsável pelo artefato faz a inspeção, então o mesmo gasta um ponto de tempo. Se outro engenheiro de software faz a inspeção, então esse gasta dois pontos de tempo.Artefato inspecionado é desvirado no tabuleiro. 

 

Título: Corrige artefato

Objetivo: Descrever as regras da correção de artefatos.

Contexto: Informações do projeto no centro da mesa.

Jogador tem artefatos inspecionados com defeito (INSPECIONA ARTEFATO) no tabuleiro.

Atores: jogador

Recursos: cartas, informações do projeto. Episódios:
Jogador escolhe artefato com defeito do tabuleiro.

Se o engenheiro de software responsável pelo artefato faz a correção, então o mesmo gasta um ponto de tempo.

Se outro engenheiro de software faz a correção, então esse gasta três pontos de tempo.

Artefato inspecionado é substituído por artefato da mesma cor não inspecionado. 

Título: Integra artefatos em um módulo

Objetivo: Descrever as regras da integração de artefatos.

Contexto: Informações do projeto no centro da mesa.

Jogador tem artefatos no tabuleiro.

Atores: jogador

Recursos: cartas, informações do projeto.

Episódios:
Jogador escolhe módulo do projeto.

Jogador seleciona artefatos do tabuleiro, independente do responsável (engenheiro de software) de acordo com as informações de projeto.

Jogador integra o módulo juntando as cartas em um monte fora do tabuleiro. 

Dúvida levantada pelos alunos em sala:

1)     Um cenário pode conter loops como, por exemplo, no cenário Inicio de Jogo no episódio “Cada jogador compra uma carta de engenheiro de software e coloca-a no tabuleiro. Restrição: Sentido de jogo é horário”?


 Sugestão discutida pelos alunos em sala:

1)     O cenário Submete Produto poderia ser dividido em dois cenários chamados Submete Produto e Valida Produto. Esse último contendo os episódios que verificam se os módulos do projeto, integrados pelo jogador, possuem ou não artefatos com defeito. 


Construção do Léxico – Identificação dos sujeitos, objetos, verbos e estados:

Sujeitos: jogador, concorrente, responsável

Objetos: dado, tabuleiro, carta(s), cartão(ões), informações do projeto, sentido de jogo, monte, habilidade, módulo, ponto(s) de tempo, orçamento do projeto, carta(s) de conceito(s), carta(s) de problema(s), carta(s) de artefato, carta(s) de engenheiro(s) de software, artefato(s), problema(s),  conceito(s), engenheiro(s) de software, produto, carta branca, carta cinza, regra(s), SimulES, custo(s), ação(ões), demanda

Verbo: empacotar (+ boa parte de suas conjugações), contratar (+ boa parte de suas conjugações), comprar (+ boa parte de suas conjugações), descartar (+ boa parte de suas conjugações), desvirar (+ boa parte de suas conjugações), iniciar (+ boa parte de suas conjugações), escolher (+ boa parte de suas conjugações), jogar (+ boa parte de suas conjugações), lançar (+ boa parte de suas conjugações, é sinônimo de jogar quando o objeto lançado é dado), construir (+ boa parte de suas conjugações), inspecionar (+ boa parte de suas conjugações), corrigir (+ boa parte de suas conjugações), submeter (+ boa parte de suas conjugações), integrar (+ boa parte de suas conjugações), selecionar (+ boa parte de suas conjugações), ganhar (+ boa parte de suas conjugações), concordar (+ boa parte de suas conjugações), atender (+ boa parte de suas conjugações), manter (+ boa parte de suas conjugações), verificar (+ boa parte de suas conjugações), produzir (+ boa parte de suas conjugações),

Estados: persistente, temporário, com defeito(s) (sinônimo de defeituoso), livre de defeito(s), desvirado(s), escolhido(s)  

Não identificamos todos ainda, e não sabemos se todos esses serão realmente considerados, mas fica uma primeira sugestão. 

Até a próxima aula, quando continuaremos a construção do léxico.

Read Full Post »

Descrição das regras do SimulES usando uma Linguagem para Descrição de Cenários (Parte I)…

As regras sugeridas pelo professor Julio na primeira versão já foram parcialmente modificadas, abaixo estão listadas algumas dessas regras já revisadas:

• Título: 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ódios:
  Jogador da vez inicia rodada.
  Se jogador pode empacotar o produto, então jogador SUBMETE PRODUTO.
  Jogador JOGA RODADA DE AÇÕES.
  Jogador JOGA RODADA DE CONCEITOS.
  Jogador TRATA PROBLEMAS.

• Título: Joga Rodada de Ações
  Objetivo: Descrever as regras da rodada de ações
  Contexto: Informações do projeto no centro da mesa
  Primeiro jogador já foi escolhido
  Atores: jogadores
  Recursos: dado, cartas, informações do projeto
  Episódios:
  Jogador usa seus Engenheiros de Software em CONSTRÓI ARTEFATOS ou INSPECIONA ARTEFATO ou CORRIGE DEFEITOS de acordo com a habilidade de cada engenheiro de software. Restrição: Habilidades podem ser afetadas por cartas de conceito ou cartas de problemas.
  Jogador lança o dado.
  Se dado igual a 1 ou 2 ou 3, então jogador pega 1 ou 2 ou 3 cartas do monte de problemas e conceitos. Restrição: jogador não pode pegar cartas do monte de engenheiros de software.
  Se dado igual a 4 ou 5 ou 6, então jogador 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 tem engenheiros de software, então jogador contrata engenheiro de software de acordo com o orçamento disponível (informado na carta de projeto) colocando-o(s) no tabuleiro.

• Título: Joga Rodada de Conceitos
  Objetivo: Descrever as regras da rodada de conceitos
  Contexto: Informações do projeto no centro da mesa
  Primeiro jogador já foi escolhido, Todos os jogadores terminaram RODADA DE AÇÕES
  Atores: jogadores, jogador, concorrente
  Recursos: cartas, informações do projeto
  Episódios:
  Jogador descarta suas cartas de conceito no tabuleiro caso sejam permanentes.
  Se o jogador tem cartas de engenheiro de software, então jogador contrata engenheiro de software de acordo com o orçamento disponível (informado na carta de projeto) colocando-os no tabuleiro.
  Jogador descarta cartas, retornando-as aos montes apropriados.
  Jogador escolhe até 3 concorrentes e pode submeter para cada um uma carta de problema.
  Jogador lê em voz alta o problema que submete ao concorrente.
  

Conforme solicitado pelo professor Julio, continuaremos alterando as regras na próxima aula.

Então, até a próxima aula!

Read Full Post »

Meu segundo contado com o jogo SimulES…

Conforme discutimos na aula passada, ficou decidido fazer uma revisão na monografia do jogo SimulES, descrevendo melhor as regras, corrigindo erros e melhorando a documentação.

Dentre os detalhes discutidos, estabelecemos um passo-a-passo para explicar a dinâmica do jogo. Fica a minha sugestão exposta a seguir, onde são estabelecidas três etapas:

• Etapa INICIAL: quando o jogo começa e os jogadores ainda não possuem cartas, nem projeto e nem engenheiros.
• Etapa JOGO: cujo principal objetivo é jogar, tendo como pré-requisito, na primeira rodada, a etapa INICIAL.
• Etapa DESCARTE: onde os principais objetivos são apresentar e receber problemas e demitir engenheiros. Resumindo, é a etapa onde as cartas são “descartadas”.

Na etapa INICIAL, primeiramente, um projeto é escolhido na sorte, retirando do monte de cartões de projeto. Estabelecemos quem começa o jogo usando o critério do lançamento do dado. O jogo começa com o jogador que obtiver o maior número no dado, e prossegue em sentido horário e alternando para o próximo jogador a cada rodada. Depois, estabelecemos que cada jogador pode comprar um engenheiro de acordo com o orçamento do projeto escolhido. A partir daí começamos a produzir artefatos e passamos para a etapa JOGO e não mais voltamos para essa etapa INICIAL até o final do jogo. Assim, a cada rodada, vamos simplesmente alternar entre as etapas JOGO e DESCARTE.

Na etapa JOGO, temos algumas fases:

• Fase de Ações: na qual os jogadores tomam suas ações construindo e inspecionando artefatos, corrigindo bugs e integrando módulos. Para cada uma dessas ações foram estabelecidos custos específicos. Então, temos:
  • Construir Artefatos: construir um artefato de boa qualidade (branco), o custo é a complexidade do projeto, e para construir um de má qualidade (cinza), o custo é 1. Tudo isso respeitando as cartas de problemas persistentes e/ou as impostas na rodada anterior. Dessa forma os jogadores se sentem atentados a arriscar mais no jogo, construindo muitas vezes, por falta de crédito, artefatos de má qualidade por serem bem mais baratos.
  • Inspecionar Artefatos: quando o engenheiro inspeciona seu próprio artefato, o custo é 1. Quando o mesmo inspeciona o artefato de outro engenheiro de equipe, o custo é 2. Tudo isso respeitando as cartas de problemas persistentes e/ou as impostas na rodada anterior.
  • Corrigir Bugs: quando o engenheiro corrige um bug de um artefato que é seu, custa 1. Mas, corrigir um bug de um artefato de outro engenheiro custa 2. Tudo isso respeitando as cartas de problemas persistentes e/ou as impostas na rodada anterior.
  • Integrar Módulos: integrar um módulo consume o turno todo de ação e o jogador não poderá realizar mais nem um outro tipo de ação na rodada corrente. Tudo isso respeitando as cartas de problemas persistentes e/ou as impostas na rodada anterior.

Nessa fase, o jogador deverá quitar todas as pendências resultantes dos problemas aplicados a ele pelos demais jogadores na etapa de DESCARTE (que será vista a seguir), pois a produção e inspeção de artefatos, a correção de bugs e a integração de módulos são ações afetadas por esses problemas. O jogador pode utilizar conceitos para amenizar as pendências. Obviamente, na primeira rodada, como a etapa DESCARTE ainda não ocorreu ninguém precisará quitar pendências.

• Fase de Comprar Cartas: na qual os jogadores compram as cartas de acordo com o que foi obtido no dado. Mantivemos a mesma relação de compra de cartas estabelecida anteriormente no jogo. Então, se o jogador obtiver 3 ou menos no dado, ele somente pode comprar cartas do monte de problemas e conceitos, de forma que o número de cartas que ele compra é exatamente o número obtido no dado. Se o jogador obtiver mais de 3 no dado, ele tem direito de comprar 3 cartas do monte de problemas e conceitos e gastar o resto (número obtido no dado menos 3) com a compra de engenheiros de softwares. Cada engenheiro consome 1 do resto, de forma que no máximo um jogador poderá comprar 3 cartas do monte de problemas e conceitos e 3 cartas do monte de engenheiros, por rodada.
• Fase de Contratar Engenheiros: na qual o jogador poderá contratar novos engenheiros, caso suas cartas permitam e respeitando o orçamento imposto no jogo para o projeto. O engenheiro contratado, como a fase de ação já ocorreu, não poderá atuar na rodada corrente, tendo de aguardar a próxima rodada.

A etapa DESCARTE compreende somente a fase de descartes apresentada a seguir:

• Fase de Descartes: na qual cada jogador pode aplicar até dois problemas em seus adversários. Cada jogador deve ter, em qualquer momento do jogo, inclusive nessa fase, no máximo dois problemas persistentes. Os demais tipos de problemas não são limitados. Mas, de qualquer forma uma limitação ocorre, pois, a cada rodada, um jogador pode receber no máximo dois problemas, seja persistente (verificando se o mesmo já não excede o limite de problemas persistentes) ou não.

O objetivo dessa divisão é tornar o jogo mais dinâmico. Temos agora uma etapa onde todos estão preocupados com o jogo em si e outra para aplicar e receber problemas e demitir engenheiros. Assim, temos uma etapa mais lenta (etapa DESCARTE), porém a mesma é mais lenta para todos, sendo imperceptível para os jogadores que o jogo deu uma parada; e uma etapa bem dinâmica (etapa JOGO), que é dinâmica para todos também.

Aplicamos em sala de aula essas sugestões e obtivemos resultados bem melhores, todos estavam mais motivados para jogar. O jogo fluiu mais, aumentando tanto a jogabilidade do mesmo quanto o seu dinamismo. Adorei! Na próxima aula, provavelmente, continuaremos jogando. Então, bom jogo a todos!

Read Full Post »