Apresentação Final

Corrida Final e Resultados - Ganhando XP

Fase Gerencial

Nesta seção serão apresentados os planejamentos, resultados esperados, formas de controle de tarefas e outras adaptações que foram necessárias para realizar a entrega do trabalho. Ao fim do trabalho está um link contendo a versão final do jogo desenvolvido.

Entregas Esperadas:

Para essa apresentação as entregas esperadas eram:

• Módulos de treinamento completos e funcionais
• Módulos de desafio do mestre completos e funcionais
• Módulo de batalha contra o chefe final completo e funcional
• Tela final de pontuação implementada
• Todos os módulos integrados de forma a dar sequência ao jogo

Remanejamento da equipe:

Para evitar que houvessem membros da equipe trabalhando sozinhos, como ocorreu na terceira apresentação, foi preciso fazer um remanejamento das equipes e priorização das atividades de forma que todos tivessem pelo menos um par para revisar seu trabalho e vice-versa. Dessa forma, prezamos pela qualidade do produto e remoção antecipada de erros através de verificações constantes e inspeções feitas entre os parceiros de trabalho. A disposição da equipe ficou da seguinte maneira:

Criação das perguntas e conteúdo:  Lorena - Guilherme - Bernardo(Criação e revisão)
Criação dos enredos e ensinamentos:   Helbert - Márcio (Criação e revisão)
Programação em Back-End:   Jota - Matheus (Codificação e revisão)
Programação em Front-End:   Danilo - Lucas (Codificação e revisão)
Pesquisas de satisfação e qualidade:   Bernardo - Guilherme (Criação e revisão)

Telas de Controle

Durante a fase de controle foram utilizados apenas o Asana e a tabela de controle do Excel de forma que o Trello foi deixado, uma vez que nossos requisitos já eram bem definidos e estavam sendo controlados juntamente com a lista de tarefas no Asana. Nem todos os requisitos foram cumpridos, e estes serão explicitados mais a frente.

Desenvolvimento final e revisão do código de Front End

A última corrida, por parte da equipe de desenvolvimento Front-End foi focada principalmente na finalização e aprimoramento de todas as fases do jogo, ou seja, fase de aprendizagem, fase de treinamento e fase de desafio do Boss. Varias funções foram implementadas para cumprir os requisitos fundamentais e para que se conseguisse um projeto final funcional em todas as instâncias. Para que o projeto continuasse seguindo o curso planejado, continuou-se usando do artifício da programação em pares, o que proporcionou ao código uma revisão frequente. Mesmo assim, notou-se ao fim do projeto algumas falhas que passaram despercebidas em certos pontos do jogo, isso só veio a tona na revisão feita pelos membros do grupo que não eram desenvolvedores, mostrando a importância do conceito de revisão.

Também importante para o desenvolvimento da fase final do projeto foi o controle de versão, que não tinha sido utilizado na primeira corrida. Com tal recurso foi possível trabalhar em cima do projeto e estar sempre atualizado do que foi desenvolvido na última modificação do mesmo e o que ainda deveria ser feito. Foi utilizado o GitLab. Para que fosse desenvolvido um código repeitando as boas práticas de programação foi fundamental a utilização do JSHint, sempre tabulando e separando o código de maneira inteligível.

Infelizmente não foi possível entregar todas as funcionalidades previstas para última corrida ao fim do prazo estabelecido como final. Sendo assim, ficou comprometida a pontuação final do jogador e a luta com o Boss, ambas não cumpriram o que se esperava ao início do projeto.

Geração de conteúdo

Quanto à parte de geração de conteúdo, foram desenvolvidos perguntas com novos temas tanto para o treinamento quanto fase do chefe, totalizando cerca de 50 perguntas incluindo as de múltipla escolha e a de V ou F. Além disso, foi gerado o enredo para mais uma fase de treinamento. Um cuidado que foi tomado desta vez, foi com haver mais de uma pessoa em cada uma das atividades de forma a haver uma revisão e minimizar os erros. Além disso, foram realizadas revisões do conteúdo gerado por membros da equipe não diretamente envolvidos na criação do conteúdo, como Bernardo e Guilherme, de modo a localizar e resolver a maioria de problemas possível. O conteúdo desenvolvido foi baseados no livro-texto da disciplina.

Controle de Versão

O Controle de versão, prática do CMMI-DEV no nível 2 de maturidade, foi feito utilizando um repositório privado no Gitlab [1].

A lista de commits realizados pode ser verificada na seguinte figura:

Apropriamos da programação em pares, prática do XP, e o progresso de programação obtido em cada novo commit foi o seguinte:

Mostrando que o desenvolvimento do trabalho se deu forma contínua e estável, oscilando entre momentos de pausa e esforço maior, próximo do fim de cada corrida.

Controle de Qualidade do código

O código do front end foi todo escrito em Javascript, utilizando-se o editor Atom[2] devido a sua facilidade de uso, legibilidade e possibilidade de se utilizar pacotes para auxiliar no desenvolvimento de projetos.

Em nosso trabalho, visando termos algum método de controle de qualidade do código, com o intuito de minimizar os erros e seguir as boas práticas de programação, utilizamos um pacote de verificação de código chamado JSHint [3].

Esta ferramenta alerta o programador quando há algum erro de sintaxe e violação das boas práticas.

A figura a seguir, mostra um exemplo de atuação da ferramenta:

Podemos o trecho de código marcado em vermelho e na barra inferior a mensagem “[‘falas’] is better written in dot notation”, indicando a mudança adequada no código.

Testes de Unidade

No jogo, usamos como Framework a biblioteca Phaser.js [4]. Esta biblioteca facilita a criação de cenas nos jogos, através do conceito de Estados. Cada estado, corresponde a um momento do jogo, onde elementos podem ser criados e cenas podem ser rodadas. O diagrama de estados do jogo pode ser visto na figura a seguir:

Cada estado é na verdade um Objeto Javascript, portanto, os testes de unidade realizados verificaram a criação cada estado, bem como a existência de todos os métodos previstos no mesmo.

Aproveitando-se do Atom, utilizamos outro pacote para a realização de testes de unidade: o Mocha & Chai [5]. Este pacote permite a criação de código Javascript para testes através das estruturas:

• require: utilizada para criar uma variável de testes,
• describe: utilizada para descrição textual do teste corrente,
• it: utilizada para criar a função de teste,
• expect: utilizada para testar propriedades da variável de teste.

Podemos ver um exemplo de teste na figura a seguir:

Testamos se a variável bootState foi criada corretamente como um objeto e se esta possui um método (property), chamado create. O resultado do teste é mostrado a seguir:

As figuras a seguir exemplificam algumas falhas encontradas devido a reaproveitamento de código nos testes. As falhas ocorreram, pois, não seguimos o Test Driven Development (TDD), onde primeiro se criam os testes e depois se codifica para aprovação. Todas as falhas encontradas durante a programação ocorreram pela utilização de variáveis de testes diferentes. Todos os estados foram testados e todos os testes foram alcançados.

Testes de Caixa-Preta

Testes observando entradas e suas correspondentes saídas, conferindo se o resultado era mesmo o esperado (os denominados testes de caixa preta) foram realizados e bem satisfeitos. Esses testes eram importantes para a confirmação da integração correta entre front e back-end, ou seja, os testes mostraram que o requisitado pelo front era bem atendido pelo back. Uma requisição do front ao back é mostrada abaixo. A confirmação do funcionamento das requisições se dá no próprio funcionamento do jogo nas fases de teste pelo mestre e no desafio com o boss, onde todas as perguntas são resultado de requisições JQuery.Ajax ao back-end.

Conclusão

Percebemos diversas falhas cometidas na maneira como iniciamos nosso desenvolvimento do Software. Certas práticas de desenvolvimento adotadas por nós tal como inicio da programação com poucas revisões e/ou testes se mostrou rápida no inicio mas custosa a longo prazo, o que causou um atraso ao fim do projeto. Após a adoção de medidas de correção contínuas e revisões de códigos por pessoas que não haviam codificado, pudemos obter um produto satisfatório ao fim do trabalho, mas que poderia ter sido melhor caso tivéssemos adotado tais medidas logo ao início.

Link para o jogo completo

https://drive.google.com/file/d/0B3UBTm4ako88WFM1VmREdGRFLVU/view

Fontes

[1] http://gitlab.com/

[2] https://atom.io/

[3] https://atom.io/packages/jshint

[4] https://phaser.io/

[5] https://atom.io/packages/mocha-test-runner

Quarta Postagem - Terceira Apresentação

Planejamento para a terceira corrida

A terceira corrida tinha como objetivo entregar ao usuário uma demonstração da fase final do jogo completa com todas as funcionalidades de batalha com chefe final do jogo. As entregas planejadas para essa corrida foram:

• Módulo funcional da fase de combate com o chefe final
• Sprites da tela de fundo e do chefe final em várias versões
• Pacote com perguntas do chefe final, envolvendo conteúdos diversos do livro de Engenharia de Software
• Enredo situando o jogador sobre os motivos do jogador principal estar enfrentando o chefe final
• Código que gerencia as perguntas a serem exibidas

Resultados obtidos

O grupo obteve boa parte de seus requisitos cumpridos com exceção de alguns que foram definidos como menos prioritários para o momento e que puderam ser adiados para a próxima corrida.

Resultados Gráficos:

Para o desenvolvimento gráfico do projeto, desenhamos diversos tipos de fundo de tela para a etapa de treinamento além dos "Sprites" do chefe final do jogo em vários movimentos do jogo. Mais conteúdo pode ser desenvolvido tanto para desenhos do chefe quanto para fundos de tela. Os fundos definitivos serão escolhidos posteriormente na próxima corrida. Abaixo estão alguns dos conteúdos produzidos:

Os fundos acima poderão ser escolhidos conforme o grupo achar mais adequado.

Acima estão apresentados os Sprites do chefe final. Essas animações serão usadas na próxima corrida como forma de manter o jogo mais atrativo

Resultados de enredo e conteúdo:

Como forma de enredo, foi produzido um conteúdo de diálogo do mestre com seu discípulo de forma descontraída para gerar mais interesse ao usuário mantendo um clima de descontração que deveria realmente estar presente no jogo. Esse enredo está disponibilizado abaixo e será integrado ao jogo pelos programadores de back-end na próxima corrida:

Diálogo 2 - Ganhando XP

Cenário: Outra conversa entre o mestre (Chan - C) e o discípulo (Jack - J)

Tema: Testes e Requisitos

J: Mestre, alguma vez na sua vida você foi testado ou fez testes?

C: Sim gafanhoto! Falando nisso, você conhece os testes que fazem um guerreiro ter boas técnicas de produção J?

J: Não mestre, por favor, poderia falar mais sobre esses testes? Eu preciso testar apenas o produto final ou tem como eu ir testando o que eu faço ao longo do desenvolvimento?

C: Gafanhoto, sempre faça os testes para que você diminua qualquer defeito, porque testar tudo exaustivamente é impossível

J: Mestre, defeito é quando o produto não atende aos requisitos né?

C: Sim Gafanhoto, esses requisitos são ligados parcialmente às unidades, porém eles são do sistema como um todo. No geral os testes verificam os resultados da implementação e detectam defeitos que escapam das revisões. Para entende-los, você tem que entender seus elementos principais:

·         Procedimento de teste: É um conjunto detalhado de instruções para execução de teste em forma de roteiros que podem ser executados manualmente ou de forma automatizada, podendo ser invocada em vários casos de teste

·         Script de teste: São representações formalizadas de procedimentos de testes, geralmente automatizados.

·         Caso de teste: Especifica, para um item a testar, as entradas (válidas ou não), resultados previstos e as condições de execução. Normalmente ele segue alguma ordem e é usado para detectar falhas não para ver se o software funciona.

J: Hum, quanta sabedoria mestre! E quais são os tipos de testes que existem?

C: Gafanhoto, temos vários tipos de testes e classificações, que podem ser feitas com base em critérios de transparência/visibilidade do teste em relação ao sistema, automação no processo, grau de 

C: Sim Jack, aliás. Note, porém, que um teste de integração normalmente é um teste de caixa cinza! Temos também testes quanto à formalidade, uma vez que testes formais possuem planos e procedimentos, devem ser revistos e aprovados por algum responsável ou cliente, além disso são documentados. Já os teste informais são feitos durante o desenvolvimento, podendo ser feitos para tentar provocar alguma falha fornecendo entradas inválidas, por exemplo, são os testes destrutivos.

J: Ah, legal mestre. Nesses testes podemos usar aqueles valores limites na entrada né, como se chama?

C: Partição de Equivalência gafanhoto! Eles fazem parte do desenho de testes. Por fim, já estava me esquecendo de falar sobre o grau de automação dos testes Jack. Um teste manual pode ser formal ou não e podem ser parcialmente automatizados gerando entradas e relatórios. São feitos por agentes humanos. Já um teste automatizado é um caso específico de um teste formal, utilizamos alguma ferramenta que gerará entradas de teste por meio de controladores. Existem outras ferramentas de automação que geram relatórios de teste e oráculos de testes (mecanismos que avaliam resultados). Existem também os testes dirigidos por scripts de teste, testes embutidos (que ficam dentro do próprio código) e testes de asserções (que possuem alguma lógica que avalia condições em que variáveis devem satisfazer, por exemplo). Ufa, acho que é isso!

J: Nossa mestre Chan, muito legal. Mas agora preciso treinar e pesquisar para dominar melhor esses princípios e, quem sabe, me tornar um Engenheiro de Software como o Senhor.

C: Não se preocupe Gafanhoto, você aprenderá algo nessa disciplina e chegará lá!

Para o caso das perguntas de múltipla escolha, obteve-se 10 perguntas de chefe que serão integradas ao jogo apenas na próxima corrida do projeto. Podemos ver essas perguntas já disponibilizadas no formato em que serão usadas pelo programador de back-end.

·        Chefão  (perguntas de múltipla escolha)

{

'id': 1,

'question': ' Quantas são as áreas de processo do CMMI nível 2?',

'A': '4',

'B': '7',

'C': '11',

'correct': 'B',

'explanation': 'As 7 áreas do CMMI nivel 2 são: Gestão de Requisitos, Planejamento de Projetos, Monitoração e Controle, Gestão de Acordos com os Fornecedores. Da área de suporte são: Medição e Análise , Garantia da Qualidade de Processos, Gestão de Configurações. Todas ligadas à área de gerenciamento',

},

{

'id': 2,

'question': ' Qual a principal diferença entre CMMI nível 1 e nível 2?',

'A': ' Os desenvolvedores nível 2 não conseguem cumprir prazos, já os do nível 1 conseguem ',

'B': ' Os desenvolvedores nível 2 possuem planejamento, organização e cronograma, enquanto os do nível 1 possuem um desenvolvimento mais caótico',

'C': ' Os níveis 1 e 2 aplicam conceitos de planejamento estruturado, porém apenas o nível 1 consegue aplicar sempre esse planejamento ',

'correct': 'B',

'explanation': 'As organizações de nivel 1 do CMMI não tem nenhum controle de processo, e por muitas vezes atrasam seus projetos, dependendo de Heróis e Gurus para cumprimento de prazos. No caso de organizações de nível 2, essas prezam por um gerenciamento ordenado e firme de seus projetos, estruturando bem toda a parte gerencial do projeto diminuindo bem seus atrasos ',

},

{

'id': 3,

'question': ' Em qual das áreas de processo trata-se da integridade do produto?',

'A': ' Gestão de Requisitos ',

'B': 'Controle de projeto' ,

 'C': ' Medição e Análise ',

'D': ' Gestão de configurações ',

'correct': 'D',

'explanation': 'É nesta etapa que trata-se da integridade dos produtos, fazendo a gestão de alterações, estabelecendo uma linha de base, rastreando e controlando qualquer alteração, garantindo alterações apenas autorizadas e executando auditorias de configurações ',

},

{

'id': 4,

'question': ' Um guerreiro desenvolvedor de software foi designado para uma missão. Sabendo que, ao receber as instruções sobre o que era necessário, ele começou imediatamente a codificar seu código, em qual nível de maturidade do CMMI ele pertence?',

'A': ' Nível 1 ',

'B': 'Nível 2' ,

 'C': ' Nível 3 ',

'D': ' Nível 4 ',

'correct': 'A',

'explanation': 'O nível 1 é o estágio inicial doa produção de software. Normalmente ele é produzido de maneira informal, às vezes caótica. Foca-se muito na codificação, esquecendo de cumprir os métodos planejados em caso de problemas. ',

},

{

'id': 5,

'question': ' Um modelo de capacitação serve exclusivamente para:',

'A': ' Auxiliar o programador a conhecer novas linguagens de programação ',

'B': ' Permitir o conhecimento de novas técnicas de processamento' ,

 'C': ' Fazer melhorias em áreas de processo',

'D': ' Permitir treinamentos de equipes, visando agilizar e organizar o desenvolvimento de produtos ',

'correct': 'C',

'explanation': ' Um modelo de maturidade de capacitação, tal qual o CMMI, serve para fazer melhorias em áreas de processos ',

},

{

'id': 6,

'question': ' Quantas representações a arquitetura do CMMI possui?:',

'A': ' Duas ',

'B': 'Três' ,

 'C': ' Quatro',

'D': ' Cinco ',

'correct': 'B',

'explanation': ' A arquitetura CMMI possui 3 representações, sendo elas: Áreas de Processo, Nível de Maturidade e Nível de Capacitação ',

},

{

'id': 7,

'question': ' A ordem dos níveis de capacitação CMMI é:',

'A': ' Incompleto – Executado – Definido – Gerido – Gerido Quantitativamente - Otimizante ',

'B': 'Incompleto – Executado – Gerido – Gerido Quantitativamente – Definido - Otimizante' ,

 'C': ' Incompleto – Executado – Gerido – Gerido Quantitativamente – Otimizante - Definido',

'D': ' Incompleto – Executado – Gerido – Definido – Gerido Quantitativamente - Otimizante',

'correct': 'D',

'explanation': ' Os nível de capacitação CMMI são: 0-Incompleto, 1-Executado, 2-Gerido, 3-Definido, 4-Gerido Quantitativamente e 5-Otimizante',

},

{

'id': 8,

'question': ' As áreas de processo Gestão de Requisitos, Planejamento de Processos, Monitoração e Controle de Projetos, Gestão de Acordos com Fornecedores, Medição e Análise, Garantia da Qualidade de Processos e Produtos e Gestão de Configurações correspondem a qual nível do CMMI?',

'A': ' Nível 2',

'B': 'Nível 3' ,

 'C': ' Nível 4',

'D': ' Nível 5',

'correct': 'A',

'explanation': ' Estas são áreas correspondentes a processos com nível 2 de maturidade',

},

{

'id': 9,

'question': ' Na representação contínua do CMMI: ',

'A': ' As metas de um conjunto de áreas de processo estabelecem um nível de maturidade em que cada nível provê a fundação para os níveis subsequentes.',

'B': 'É a representação adotada na grande maioria das organizações cujos resultados de avaliação foram publicados pelo SEI.' ,

 'C': ' É a representação mais flexível, pois permite que a organização prorize investimentos na melhoria das áreas que considera mais relevantes.',

'D': ' É uma representação mais simples de entender e provavelmente mais simples de implantar ',

'correct': 'C',

'explanation': ' As demais alternativas correspondem à representação em estágios e não à representação contínua. Na representação contínua, os níveis de capacitação provêem uma ordem recomendada para a abordagem da melhoria de processos dentro de cada área, Uma avaliação feita com essa representação determinará um indicador individual de progresso para cada área de processo.',

},

{

'id': 10,

'question': ' No CMMI, a melhoria contínua é obtida através da redução de: ',

'A': ' Práticas genéricas.',

'B': 'Causas comuns de variação' ,

 'C': ' Patrimônio de processos',

'D': ' Causas especiais de variação ' ,

'correct': 'B',

'explanation': ' A melhoria contínua é conseguida por meio da redução das causas comuns de variação, isto é, variações que existem por causa de interações normais e esperadas entre os componentes de um processo.',

},

Resultados de produto final

O código de back-end foi totalmente feito para a parte de combate com o chefe final mas ainda não foi integrado com os elementos de front-end que também estão parcialmente prontos. Alguns defeitos de front-end foram encontrados a partir de testes feitos sob a plataforma do jogo, entre eles um problema em que o background do jogo não era carregado corretamente. Abaixo serão apresentadas as telas do front-end que foram desenvolvidas até o momento e que devem ser integradas ao back-end na próxima corrida.

Nessa corrida foi adicionada a integração das telas de jogo, um menu principal que pode ser usado pelo usuário para selecionar o conteúdo do jogo a ser aprendido e ainda se ele deseja desafiar o chefe final.

Testes inspeções e análises

Análise e teste de dificuldade das perguntas

As perguntas produzidas para a disciplina foram testadas com membros do grupo que tem contato com a matéria e com algumas pessoas que nunca tiveram contato com a matéria anteriormente. Os resultados dos testes além de uma análise detalhada do tipo de competência envolvida em cada pergunta está apresentada abaixo.

Testes de integração

Os tetes de integração não puderam ser realizados devido à má distribuição de tempo para realização do projeto (novamente).

Testes de Front-End

Os testes de front-end foram realizados entre todas as telas disponíveis para a interface de usuário até o momento. Todas as funcionalidades foram utilizadas diversas vezes para garantir consistência dos elementos gráficos do jogo. Em certo momento observou-se que o background do jogo não carregava corretamente na batalha final com o chefe. Para esse defeito não foi encontrada solução permanente e deverá ser analisado na próxima corrida

Pesquisas

Pesquisa de satisfação

Na pesquisa a seguir foram feitas pesquisas envolvendo os seguintes tópicos Os resultados estão apresentados abaixo:

Essas pesquisas visavam avaliar interesse no jogo, método de treinamento, abordagem de ensino, sistema de avaliação e resposta visual.

 Definições da matemática de danos

Acertos

Erros

CASO ACERTE A PERGUNTA: • Dá 20% de dano ao chefão se estiver no nível fácil (5 acertos para morrer) • Dá 15% de dano ao chefão se estiver no nível médio (7 acertos para morrer) • Dá 10% de dano ao chefão se estiver no nível difícil (10 acertos para morrer) Ganha 100 pontos por acerto. SE ACERTAR 3 SEGUIDAS: Multiplicador de pontos vai de 1x para 2x Recupera HP o equivalente a 1 dano do chefão SE ACERTAR 5 SEGUIDAS Multiplicador de pontos vai de 2x para 3x

CASO ERRE A PERGUNTA: • Recebe 20% de dano ao usuário se estiver no nível fácil (5 erros para morrer) • Recebe 35% de dano ao usuário se estiver no nível médio (3 erros para morrer) • Recebe 50% de dano ao usuário se estiver no nível difícil (2 erros para morrer) Multiplicador de pontos vai para 1x Perde 50 pontos por erro. SE ERRAR 3 SEGUIDAS Chefão recupera o equivalente a 2 danos do usuário

Abaixo foi feita uma simulação do sistema de danos implementado no jogo:

Tabela gerencial final da corrida

O resultado gerencial das corridas está apresentado abaixo. São usadas 3 telas de controle sendo una a planilha do excel, a outra a ferramenta Trello e uma última, a ferramenta Asana.A planilha excel contem os dados de forma mais concisa e visual, permitindo uma visualização mais fácil dos resultados. Como se pode ver a única tarefa não realizada foi a tarefa de integração.

Terceira postagem - Segunda apresentação

Objetivos Principais do jogo

Abordar o assunto de maneira simples e eficiente

Utilizar o método de revisão para retenção do conhecimento

Fazer com que o usuário obtenha um meio de aprendizado descontraído

Avaliar se os pontos chaves para o aprendizado foram absorvidos

Aplicar os conhecimentos sobre Engenharia de Software no desenvolvimento do produto

Gerenciamento de Requisitos (funcionais)

Como jogador, eu quero selecionar as fases de treinamento em uma tela específica.

Como jogador, eu quero que os ensinamentos do mestre sejam textuais.

Como jogador, eu quero que as perguntas da fase de teste sejam do tipo V ou F.

Como jogador, eu quero que as perguntas da fase de testes sejam aleatórias.

Como jogador, eu quero que respostas certas correspondam a um aumento da minha pontuação máxima.

Como jogador, eu quero que minha pontuação máxima seja exibida por meio de uma barra de XP.

Como jogador, eu quero que existam animações do personagem na fase de teste.

Como jogador, eu quero que o painel de seleção das fases de treinamento mostre meu desempenho nas fases concluídas no formato de 1, 2 ou 3 estrelas para pontuações mínimas, médias e máximas respectivamente.

Como jogador, eu quero enfrentar um personagem Chefão, como uma espécie de desafio máximo.

Como jogador, eu quero poder enfrentar o Chefão a qualquer momento fora das fases de teste, independentemente da quantidade de fases concluídas.

Como jogador, eu quero um mecanismo para ver minha pontuação relativa ao número de acertos.

Como jogador, eu quero um mecanismo para ver quanto tempo gastei para concluir uma fase de teste.

Como jogador, eu quero que meu progresso no jogo possa ser salvo.

Gerenciamento de Requisitos (não funcionais)

Como jogador, eu quero conseguir jogar em qualquer navegador

Como jogador, eu não quero que o jogo demore um tempo superior a alguns segundos para carregar

Planejamento do projeto

Primeira meta: Estabelecimento e a manutenção das estimativas do projeto.

Organização do grupo e decisões

Resultado da corrida

Duas atividades não foram completadas no tempo limite da primeira corrida.
Motivos:
*Sobrecarga dos programadores;
*Falta de experiência com o sistema de corridas.

Sugestões para a próxima corrida

Melhorar a divisão do trabalho;

Melhorar a administração do tempo.

Pesquisa com os usuários

Foi realizada uma pesquisa com os usuários a fim de analisar a proposta do jogo por meio de um formulário do Google. Os resultados obtidos foram disponibilizados via gráficos.

 Pesquisa de sugestões com o público-alvo

Um campo foi disponibilizado para que os usuários dessem sugestões para o grupo. Recebemos uma proposta interessante que está em fase de análise de viabilidade.

Proposta	Situação
Adicionar um tempo limite para responder as perguntas do chefão, tempo esse que se reduziria a cada perguntas, o que deixaria o jogo mais dinâmico e interessante	Sendo avaliada

 Desafios encontrados

Aplicar o conteúdo baseado no CMMI de forma didática, concisa e objetiva

Analisar e selecionar os requisitos visando uma maior qualidade e eficiência na implementação do software

Criação dos desenhos dos personagens e das telas de fundo do jogo.

Elaboração das perguntas e respostas utilizadas no jogo de forma a manter um nível desejado de dificuldade para melhor experiência e aprendizado do usuário.

Resultados obtidos

Produção parcial do conteúdo didático a ser apresentado no software e das perguntas.
Desenvolvimento da interface inicial do produto e da tela de treinamento e batalha
Interação e crescimento entre os participantes do projeto, aumentando o grau de maturidade da equipe
Possibilidade de utilização do protótipo e refinamento dos requisitos funcionais

Telas de demonstração do jogo

*Treinamento

*Teste