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:
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á!
·
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.
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.
Nenhum comentário:
Postar um comentário