Total de visualizações de página

sexta-feira, 30 de outubro de 2015

Grupo NWO - Corrida 1

Nessa última semana realizamos algumas reuniões a fim de finalizar a corrida 1. Sendo assim, elaboramos o documento de partida.

Para controle de versão, estamos utilizando o github:
https://github.com/assispedro/quiz-now



Os detalhes do jogo seguem abaixo.




Gênero:
Trívia /Casual

Plataforma:
WEB (PC, Mobile)

Audiência/ESRB:
E – para todas as idades, agradando pessoas que já trabalharam ou estudaram Engenharia de Software

Core Concept:
O jogo será uma competição entre 2 jogadores que responderão uma série de perguntas sobre Engenharia de Software. O principal objetivo é ganhar a partida e se tornar o melhor jogador ranqueado.


Core Gameplay:
  O QuizNOW será um jogo de fácil jogabilidade, basicamente após efetuar o “Login” no jogo, o jogador será redirecionado para uma tela de “matchmaking” onde será selecionado outro jogador (com as mesmas características) para uma disputa de 10 perguntas. Em cada pergunta, selecionada de forma randômica pelo sistema, haverá um contador de 10 segundos para que a mesma seja respondida e dada uma resposta por um jogador, uma quantidade de pontos (baseada no tempo de resposta) será dada a ele. Ao final da disputa o jogador vencedor receberá uma quantidade de pontos pela vitória. Os comandos são associados ou mouse (PC) ou toque (Mobile) que correspondem na seleção das respostas para cada pergunta.

Golden Nuggets:
O QuizNOW visa dar ao jogador a possibilidade de entender a aprender os conceitos da matéria de Engenharia de Software. O grande diferencial é propor uma competição entre jogadores, afim de estimular que os jogadores busquem aprender sobre o tema para que eles estejam no topo de ranking.

9 Group - Requisitos de Software


  1. Funcionais
    1. O jogo é do gênero de jogos de tabuleiro;
    2. Cada casa do tabuleiro possui associada à ela um tema de engenharia de software;
    3. Cada tema de engenharia de software possuirá pelo menos três perguntas sobre o assunto;
    4. Todas as perguntas serão problemas de múltipla escolha com cinco alternativas cada;
    5. A associação de casas do tabuleiro e temas de engenharia de software será feita de forma aleatória, porém, a quantidade total de ocorrências de cada tema deve ser aproximadamente uniforme;
    6. Podem haver temas repetidos associados a diferentes casas do tabuleiro;
    7. Devem existir pelo menos 10 temas de engenharia de software no jogo; e
    8. Regras do jogo à serem implementadas:
      1. Para realizar a movimentação dos jogadores pelas casas do tabuleiro soma-se o índice da posição atual do usuário detentor do turno ao valor obtido com o lançamento do dado;
      2. Caso o cálculo de movimentação apresentado acima defina uma posição de índice maior que a última casa do tabuleiro, o jogador em questão será posicionado na última casa do tabuleiro;
      3. Os jogadores apenas podem lançar o dado, mover-se e responder às perguntas a ele assinaladas em seus respectivos turnos;
      4. O dado do jogo possui valores de 1 a 6 com distribuição de probabilidade aleatória uniforme, ou seja, ⅙ de chances de sortear qualquer um de seus números;
      5. Cada pergunta corretamente respondida pelo usuário garante-lhe 10 pontos;
      6. As perguntas erroneamente respondidas pelo usuário não garantem-lhe qualquer adição a sua pontuação;
      7. Para classificar-se à receber um bônus chamado de BAC (Bônus por Acertos Consecutivos) em pontuação o jogador deve acertar questões consecutivamente;
      8. Cada acerto consecutivo de questões respondidas por um jogador garante-lhe mais 1 extra. Exemplo: ao acertar 2 questões consecutivas o jogador recebe ao todo 21 pontos; Ao acertar 3 questões consecutivas o jogador recebe 33 pontos; Ao acertar 4 questões consecutivas o jogador recebe 46 pontos; e assim por diante;
      9. O jogo termina no ciclo de turnos em que o primeiro jogador chegar à casa final;
      10. Quando um jogador atingir a casa final do tabuleiro, todos os demais jogadores que ainda não jogaram no ciclo atual de turnos possuem a oportunidade de jogar;
      11. O jogador que chegar à casa final do tabuleiro ganha 15% de bônus em relação à sua pontuação total adquirida ao longo do jogo (bônus este aplicado após o cálculo da pontuação final que pode incluir outras formas de bônus). Este bônus será chamado de BCJ (Bônus de Conclusão do Jogo);
      12. Cada jogador pode jogar apenas em seu turno;
      13. Os turnos são cíclicos, passando apenas uma vez por cada jogador, dentre todos os jogadores participantes;
      14. A configuração inicial dos turnos é definida aleatoriamente; e
      15. O jogador vencedor será aquele com maior pontuação final, pontuação esta que inclui todos os bônus aplicáveis.
  2. Não funcionais
    1. O tempo médio de resposta do software deve ser tal que permita o jogo fluir em ritmo tolerável por seus usuários;
    2. O jogo deve rodar na plataforma android;
    3. A linguagem utilizada deve ser Java; e
    4. O jogo deve apresentar no mínimo modularidade de nível básico por questões de legibilidade e manutenções futuras do mesmo.

quinta-feira, 29 de outubro de 2015

9 Group - Método de desenvolvimento ágil escolhido, adaptações feitas e ferramenta utilizada

A metodologia escolhida para a gestão e planejamento do projeto foi a metodologia ágil Scrum.
No nosso projeto, usaremos apenas algumas funcionalidades da metodologia que melhor se adaptam à situação.
O projeto foi dividido em corridas, e a cada corrida o software irá sendo incrementado. Tendo ao fim da última corrida, o produto final. Para facilitar, as datas das corridas correspondem às apresentações de andamento do projeto em sala de aula. Cada corrida tem duração de aproximadamente duas semanas.
A equipe foi dividida em Mestre Scrum, Dono do Produto e Time Scrum. O Time Scrum, no entanto, conta também com a participação tanto do Mestre Scrum como do Dono do Produto, sendo também uma equipe multidisciplinar. Para melhorar o rendimento, o desenvolvimento será feito em trios, que podem mudar durante as corridas. Os papéis de Mestre do Scrum e do Dono do Produto também podem variar durante as corridas.
Em função do pouco tempo e da não compatibilidade de horários, optamos por não realizarmos as reuniões diárias do Scrum. No lugar destas reuniões, estamos fazendo uso de redes sociais (grupos no facebook e no whatsapp) para diariamente nos comunicarmos e vermos como está o andamento da corrida, eventuais dificuldades, entre outras coisas.
Foi planejado que teremos duas reuniões presenciais por semana para debatermos impasses que possam ocorrer no desenvolvimento e tomar decisões. Estas reuniões serão reuniões rápidas, normalmente de até 20 minutos, intermediadas pela(o) mestre Scrum, mas em que todos poderão se manifestar.
Os encontros de revisão da corrida serão adotados. Eles se iniciarão com a apresentação em sala de aula e continuarão logo após. Com isso, é mostrado o que foi alcançado em cada corrida. Também realizaremos uma retrospectiva da corrida, observando assim o que funcionou bem e o que pode ser melhorado para a próxima, iniciando, assim, o planejamento da mesma.
Adotamos o "Backlog" do Produto. Foi feita uma lista de requisitos em que houve a definição da maioria das funcionalidades a serem entregues ao cliente. Esta lista irá ser alterada sempre que houver necessidade, durante o processo de desenvolvimento.
Outra etapa do Scrum adotada foi o Backlog da Corrida, em que há a seleção dos itens presentes no Backlog do Produto para cada corrida. Esta escolha dos itens é feita em reuniões chamadas de Encontros de Planejamentos da Corrida. Estas reuniões ocorrem, normalmente na primeira reunião após Retrospectivas da Corrida.
A Preparação dos itens do Backlog do Produto, onde vamos estimando o tamanho e esforço de cada item é feito durante as Reuniões de Planejamento da Corrida. Após essa preparação há, então, a divisão dos itens entre os trios de desenvolvimento, de forma que nenhum trio fique sobrecarregado.
A definição de pronto de cada corrida ou funcionalidade em nosso projeto é outra coisa definida nos Encontros de Planejamento de cada Corrida. A escolha do momento dessa definição ocorreu pois a mesma varia muito de corrida para corrida e é importante que todos os membros do time tenham um entendimento compartilhado do que significa cada corrida ou funcionalidade estar completa. Na reunião de Revisão da Corrida, analisamos se conseguimos alcançar a definição de pronto foi alcançada e caso negativo, como podemos chegar lá.
Para facilitar a gerencia do projeto seguindo a metodologia ágil do Scrum, utilizaremos a ferramenta gratuita online SeeNowDo da empresa bigvisible. Com o SeeNowDo podemos organizar as tarefas por categorias, possibilitando organizá-las dentro de um painel de trabalho e utilizando cores e colunas para diferenciarmos os dados. Sendo bem intuitivo. Há também a funcionalidade de indicarmos quanto tempo falta para concluirmos cada uma das atividades cadastradas, assim como o status da atividade (não começada, em progresso...). Sendo uma boa boa ferramenta para gerenciar dados de forma simples.

• Grupo: Oito 8
 
Reunião dia 27/10/2015

• Membros do Grupo:

Weslei Antonio Vilela
Flávio Bastos Haueisen
Daniel Lucas Pereira
Jean Henrique Ferreira Freire
Humberto Lopes de Morais
Lucas Antonio Conceição
Thiago Lucas dos Santos

••• Pauta:
Assuntos abordados durante esta reunião:

→Continuar mantendo pelo menos 2 Reuniões Presenciais por Semana (fora as reuniões e comunicações/diálogos virtuais):
O Grupo concordou em continuar mantendo as duas Reuniões Presenciais (logo após as aulas de Engenharia de Software), assim como tem sido feito desde a formação do grupo.
Estas Reuniões Presenciais são um complemento as formas de comunicação e reunião que também ocorrem pelos meios virtuais.
Em geral, avaliamos que as Reuniões Presenciais são muito Positivas, além de tornar mais dinâmica todas as decisões importantes. Avaliamos que esta tem sido uma boa estratégia para complementar o desenvolvimento do projeto.

→ Acompanhamento referente ao desenvolvimento da interface:
Já está sendo desenvolvido o sistema da interface do jogo, seguindo a proposta originalmente definida, ou seja: a principio teremos uma interface funcional e simplificada. Algumas novas sugestões foram propostas, mas sem grandes alterações estruturais no jogo.
O desenvolvimento da interface está seguindo a proposta do modelo organizacional que foi apresentado em reuniões passadas; (e que representa o formato do layout para as funcionalidades desejadas, e do jogo.).

→ Acompanhamento do desenvolvimento do Projeto:
Foi discutido em geral, como está o nível de desenvolvimento do projeto. Ficou mantida algumas estratégias e metas de desenvolvimento propostas, visando dividir melhor o tempo e a carga de trabalho.
Além disso, durante o desenvolvimento do projeto, foi observado é possível que ocorram algumas modificações ou incrementos necessários em algumas classes, após algumas observações.

→ FeedBack do desenvolvimento do sistema de testes:
Foi apresentado ao grupo o um novo Feedback da tarefa de desenvolvimento dos testes (como esta o desenvolvimento do mesmo.).

• Tarefas que não foram previamente definidas na reunião anterior mas que foram desenvolvidas entre a reunião anterior e a reunião atual:
• Divisão das tarefas de desenvolvimento no Trello (usando cartões de tarefas e itens no checklist; para controle de desenvolvimento e organização das tarefas de cada um.).

• Tarefas que foram previamente definidas na reunião anterior e que já foram concluídas antes desta reunião:
• Apresentar o desenvolvimento do sistema de testes.
• Acompanhar o desenvolvimento de cada módulo de programação.

• Tarefas a serem desenvolvidas até o próxima reunião presencial:
• Apresentar o desenvolvimento do banco de questões do MPS.BR (necessário para o desenvolvimento de parte das funcionalidades do jogo.).
• Apresentar o desenvolvimento do sistema de testes (funcionando.).
• Apresentar o desenvolvimento do quadro de membros/objetos/recursos e suas respectivas características (necessário para o desenvolvimento do jogo.).
• Atualizar o desenvolvimento de cada módulo de programação.





quarta-feira, 28 de outubro de 2015

ScrumSociety - 5ª REUNIÃO (19/10): Análise de requisitos e criação de histórias

Nesta reunião, analisamos os requisitos do Cliente e escrevemos histórias para eles.

REQUISITOS:

  • Requisitos Não Funcionais:
    • Deve rodar em plataforma móvel ou web.
    • Tempo para carga e inicio do jogo não deve exceder 10s.

  • Requisitos Funcionais:

    • O jogo deve:
      • promover, de forma divertida, o aprendizado de conceitos de Engenharia de Software;
      • possuir múltiplas fases, com aumento progressivo de dificuldade de forma a manter o usuário estimulado;
      • fornecer  mecanismos para obtenção de pontos extras (atividades extras, bônus por tempo, etc.).

    • É desejável que o jogo:
      • permita salvar o progresso, possibilitando a retomada do jogo a partir do mesmo ponto;
      • exiba ranking com melhores pontuações.

Vamos escrever histórias para esses requisitos.

Ficou decidido que a complexidade das histórias serão estimadas baseadas na sequência de Fibonacci.

Backlog do Produto:

Criação do banco de questões
Estimativa: 21.
Descrição:
Eu como jogador,
desejo poder responder questões no jogo
De tal modo que estas tenham conteúdo associado a questões de Engenharia de Software.
Tarefas:
  • SS-001: Criar a entidade Questão
  • SS-002: Reunir questões sobre o conteúdo de eng. de sw
  • SS-003: Criar tabelas no banco de dados.
  • SS-004: Povoar o banco com as questões.
  • SS-005: Testar e verificar se as questões são corretas.

Implementar um progresso no jogo
Estimativa: 8
Descrição:
Eu como cliente
desejo observar um progresso no jogo
De tal modo que a cada questão respondida, a próxima seja mais difícil, e que o progresso no jogo vá das questões mais fáceis às questões mais difíceis

  • SS-006: Classificar as questões por dificuldade
  • SS-007: Definir quantas questões por nível serão respondidas até que se passe de nível
  • SS-008: Implementar o progresso ao responder as questões
  • SS-009: Implementar testes

Implementar tela inicial
Estimativa: 8.
Descrição:
Eu enquanto jogador,
desejo visualizar uma tela inicial antes de começar o jogo
De tal modo que essa tela possua um botão de iniciar o jogo.
Tarefas:
  • SS-010: Implementar botão de inicio do jogo.
  • SS-011: Testes exploratórios.

Criar tela de questões
Estimativa: 13.
Descrição:
Eu como jogador
desejo visualizar uma tela a cada questão respondida.
De tal modo que possua opções de respostas que eu possa clicar naquela que considero verdadeira.
         
  • SS-012: Criar o apresentador da entidade Questão
  • SS-013: Criar a visualização da Entidade Questão
  • SS-014: Implementar testes exploratórios para a visualização das Questões
  • SS-015: Implementar Botões de CheckBox que representam as alternativas que o jogador tem para responder.

Gerar ranking com os resultados do jogo:
Estimativa: 13.
Descrição:
Eu enquanto jogador,
desejo poder visualizar um ranking com os resultados do jogo.
De tal modo que este ranking exiba os dados referentes a minha pontuação em cada jogada.
Tarefa:
  • SS-016: Criar a entidade Ranking
  • SS-017: Criar o apresentador de Ranking
  • SS-018: Criar a tela de visualização do Ranking
  • SS-019: Criar testes para o Ranking


terça-feira, 27 de outubro de 2015

9Group - CRONOGRAMA

Na reunião realizada no dia 27/10 foi definido o cronograma.

Cronograma:

    08/10: 1ª reunião: Definição do projeto
    13/10: 2ª reunião: Definição da entrevista para análise de requisitos
    15/10: Primeira Apresentção: Apresentação para o cliente e o professor
    22/10: reunião com cliente: Entrevista com o cliente, onde foi ocorreu a definição dos requisitos.
    27/10: Realização do cronograma
    28/10: Divisão das tarefas em trios
    15/10 até 02/11: Primeira corrida
    02/11: Primeira Entrega
    03/11 - 05/11: Segunda entrevista com o cliente
    03/11 até 18/11: Segunda corrida
    18/11: Segunda entrega
    19/11 - 20/11: terceira entrevista com o cliente
    20/11 até 27/11: terceira corrida
    27/11: Terceira Entrega
    01/12: Apresentação e Entrega final