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