Ata da quinta reunião do grupo SpeedGames

Data: 11/10/2013
Nomes:
    Júlio Albinati Cortez
    Paulo Viana Bicalho
    Rubens Emilio Alves Moreira



O foco desta reunião foi identificar quais requisitos -- funcionais e não-funcionais -- foram atingidos ou estão em processo de desenvolvimento. O grupo viu como relevante levantar as causas de alguns dos requisitos ainda não terem sido concluídos (itens marcados com um *). A lista abaixo dispõe o resultado das análises feitas:

1. Requisitos funcionais:

1.1 A fazer:

    h) ao término do jogo, o sistema deve informar a classificação final de cada participante;

    i) o jogo deve possuir eventos de sorte e azar, disparados pela roleta;

1.2 Em andamento:

    b) o sistema deve ter uma tela de configuração, onde devem ser informados:
        - quantidade de jogadores;
        - número de rodadas;
        - metodologia de desenvolvimento de software de cada jogador (SCRUM, XP, Kanban, Praxis);
        - apelidos dos jogadores;

    b*) o protótipo inicial da tela de configurações já foi definido, mas falta realizar a impĺementação do mesmo sobre a engine de desenvolvimento de jogos escolhida, o Allegro;

    e) o sistema deve permitir que o usuário adquira empresas com nível inicial de maturidade;

    e*) o jogo já permite que usuário adquira empresas com nível inicial de maturidade, mas ainda é necessário definir quais os custos associados às empresas de forma a manter o balanceamento e jogabilidade da aplicação;

    f) o sistema deve permitir que o usuário aumente o nível de maturidade das empresas que possuir;

    f*) o jogo já permite que usuário aumente o nível de maturidade das empresas que possuir; é necessário definir quais os custos associados às certificações das empresas;

    g) o sistema deve pontuar os usuários de acordo com as empresas que o usuário possuir;

    g*) apesar de o jogo disponibilizar uma pontuação inicial a cada jogador, ainda é necessário balancear o método de distribuição dos pontos;

1.3 Atingidos:

    a) o sistema deve suportar de dois a quatro participantes;

    c) o sistema deve possuir mecânica de turno, em que cada turno respeita o autômato abaixo;

    d) o sistema deve possuir uma tela principal de interação com o usuário; a tela deve ser implementada segundo o protótipo já definido;

    j) o jogo deve apresentar perguntas ao usuário, de acordo com a posição em que a roleta parar;

    k) o jogo deve validar a resposta do usuário, verificando se o mesmo acertou ou errou a questão, e recompensando-o adequadamente;

2. Requisitos não-funcionais:

2.1 A fazer:

    a) os conhecimentos do usuário sobre engenharia de software devem ser testados e avaliados;
    d) o sistema deve ser portável para diversos sistemas operacionais;
   
2.2 Em andamento:
   
    b) o sistema deve ser intuitivo e de fácil interação;
    e) o sistema deve possuir bom desempenho.

2.3 Atingidos:

    c) o sistema deve simular a roleta -- definida no protótipo -- de forma realística.

Ata da 5ª Reunião - 10/10

Membros:

Antônio Gonçalves

Bruno Liberal

Rafael Fonseca

Vinícius Garcia

Vitor Paisante

- Objetivos da reunião: 2º Sprint Review e 3º Sprint Planning

Selected BackLog:

- Elaborar os dados para que serão utilizados no jogo:

Requisitos funcionais:

1. Fazer um protótipo apresentável para o cliente. 20 pontos
2. Fazer o relacionamento de tarefas a se fazer no projeto e os papéis dos funcionários.  13 pontos.
3. Criar 10 funcionários exemplos para os primeiros testes - 8 pontos.
4. Criar 5 projetos exemplo para os primeiros testes - 8 pontos.
5. Fazer o relacionamento dos bônus das tarefas para as outras tarefas.  13 pontos.

Jogo:

    Foram definidos os conceitos mais específicos e discutidos conceitos mais concretos do jogo a respeito da jogabilidade, e do fluxo do jogo.

Task Board pode ser visto aqui.

EEGames - Reunião do dia 08/10/2013

Após essa reunião levantamos mais alguns requisitos, a serem atendidos no terceiro release :

1) Ranking de pontuações : a cada tentativa o usuário terá a opção de gravar o seu placar no registro do jogo;

2) Mudar a figura que, hoje, é representada por uma estrela, quando o usuário
tem a oportunidade de responder a uma pergunta, com o objetivo de destacá-la;

3) Extrair frases interessantes para compor o banco de frases dos capítulos
do livro texto referentes aos assuntos de Capacitação em Processos, Processos de Software, e Análise;

4) Criar um logo para o jogo, evidenciando o seu nome : SoftClick;

5) Melhorar a aparência gráfica do jogo.

Com a finalidade de melhorar e evidenciar o processo, decidimos, após essa reunião, que para cada requisito testado, deverá haver uma pequena descrição dos passos executados para verificá-lo, por mais simples que ela seja.

Além disso deveremos comparar, para cada release, quais dos requisitos foram atendidos, para que possamos avaliar as maiores dificuldades encontradas, e termos alguma métrica do nosso progresso.

Obs : Prof. Sérgio, será que você poderia disponibilizar o material sobre "Testes" que você nos falou hoje após a aula?

Ata da quarta reunião do grupo SpeedGames

Data: 07/10/2013
Nomes:
    Júlio Albinati Cortez
    Paulo Viana Bicalho
    Rubens Emilio Alves Moreira


Nesta reunião redefinimos o diagrama de classes da nossa aplicação de acordo com o que consideramos pertinente. As modificações foram dadas a partir da adição de novos módulos ao protótipo que havia sido desenvolvido. O diagrama de classes pode ser acessado neste link.


Com os módulos, novas funcionalidades foram acessadas à aplicação:

• adição de turnos de jogo;
• suporte a mais de um usuário;
• interface para responder as perguntas correspondentes às jogadas do usuário;
• exibição de atributos do usuário, como recursos disponíveis e empresas já adquiridas.

Dada a adição de novos módulos, vimos como pertinente a reestruturação do código em diretórios, tanto para facilitar o processo de programação, quanto para manter o código mais fácil de versionar paralelamente (pelos integrantes do grupo). Além disso, adicionamos o uso do utilitário de compilação CMake, para melhorar o processo de compilação do código.

Por fim, adicionamos o utilitário Doxygen, para facilitar a documentação do código. A partir do mesmo, e do script Doxygraph, foi possível gerar o diagrama de classes da aplicação de forma bem rápida. Abaixo, exibimos a nova interface da aplicação:

Para a próxima entrega, pretendemos apresentar a aplicação com as seguintes funcionalidades adicionadas:

• tela de apresentação do jogo;
• tela de configuração da aplicação, e integração com a lógica principal do jogo;
• definição do conjunto inicial de perguntas do jogo;
• possíveis melhorias na interface/jogabilidade.

20th BOOTH GAMES -- MARCO ATINGIDO: FLAG 2

Seguindo com o processo de software estabelecido, conclui-se neste domingo o prazo estabelecido para o segundo grande marco do desenvolvimento do jogo. As metas de desenvolvimento foram atingidas, e seu progresso é explicitado a seguir:

Dominar a linguagem de programação FLASH e a biblioteca FLASH PUNK (André e Josué) :

Embora um domínio completo de qualquer um destes componentes seja uma tarefa monumental, foram adquiridos conhecimentos que serão suficientes para o desenvolvimento do jogo.

A principal contribuição técnica neste período foi a exploração das possibilidades da modularização dos componentes do jogo, investigando a possibilidade de usar tanto uma orientação por classes como uma DSL. A escolha quanto a qual modelo será adotado deve seguir uma discussão que se torna possível somente agora, com a conclusão do roteiro do jogo.

Desenvolver desenho do jogo em função do script da novela, da árvore de decisões e do esquema de interfaces (Júlio e Yuri):

As duas grandes colocações nesta meta foram atingidas: O script do jogo e o design da interface.

O script consiste na linha de história a ser seguida pelo jogador, que segue nos passos de um avalista de CMMI, cujo papel é de investigar e, com base nos recursos disponíveis a ele (ora artefatos, ora entrevistas) qual seria o grau de maturidade atingido pela empresa em questão.

A organização deste documento é em um grafo de fluxo, tendo galhos e folhas que representam as escolhas do jogador.

Quanto a interface do jogo, além da conclusão das interfaces de cada uma das telas do jogo (completando o conjunto já apresentado no último seminário), uma database considerável de Backgrounds foi adquirida (http://www.spriters-resource.com/) cuja política de uso é completamente livre. Alguns exemplos desta base são colocadas a seguir.

https://www.dropbox.com/sh/bojhf8108syg542/R-gQSDTUV5/Recursos%20Gr%C3%A1ficos#lh:null-sample.png

Metas do próximo Flag (previsto para 27/10)

Com isso, passa-se para a próxima coluna do Kanban, cujas metas gerais são colocadas a seguir:

• Implementar o código do jogo na função de DESENVOLVEDOR CHEFE. Funções: Criação do código fonte, com prioridade na hierarquia de tomada de decisões (André).
• Implementar o código do jogo na função de INSPETOR. Funções: Criação do código fonte, com poder de inferência sobre as decisões tomadas pelo desenvolvedor chefe, e inspeção de código (Josué).
• Implementar o jogo na função de GERENTE DE TESTES. Função: Auxílio na criação do código fonte; analisar a testabilidade do código e desenvolver rotinas de testes para o mesmo (Júlio).
• Implementar o jogo na função de COORDENADOR. Função: Auxílio no desenvolvimento do código fonte, com poder de decidir conflitos de opiniões entre o desenvolvedor chefe e o desenvolvedor auxiliar; Garantir a fidelidade ao desenho e ao script da novela. Garantir atendimento aos requisitos (Yuri).

Grupo G8 Games

Telas do Design do jogo baseado no Gameflow

Gameflow:
https://docs.google.com/file/d/0By177K4-mvLLLWRHanYxSVM1YWM/edit?usp=drive_web

Telas de Design:
https://drive.google.com/?authuser=0#folders/0B1Sic6iZbQWpai15ZFVkUkVsZ0U
ou
https://docs.google.com/file/d/1hR3pOHt8BSRtm63WbTUe7zdQ1EzkJ5V0TO1tGBSI-5QZL_SJ4GoV0nrk6m4A/edit?usp=drive_web

EEGames - Segundo Release - 4/10/2013

Grupo EEgames Integrantes:

• Lilian
• Hudson
• Clarisse
• Luiz Guilherme
• Rafel Kioji

Link para o instalador do segundo release: https://www.dropbox.com/s/7kgfwvh7l0ezek8/eeGames_SoftClick_release2.exe

Link para o quadro de atividades: https://docs.google.com/spreadsheet/pub?key=0ArdLUMUpNso3dFdmU3M0YWdhQXhvWEYwZTgxSUtrMGc&output=html

Os seguintes requisitos foram atendidos para o segundo release do projeto:

1. Amadurecimento da lógica de pontuação: no primeiro release não foi trabalho muito na lógica da pontuação e sim na sua estrutura. Neste release a lógica de pontuação foi amadurecida conforme diversas conversas realizadas entre os membros da equipe em reuniões "em pé".
2. Acréscimo de dificuldade evolutiva: neste release foi acrescentado um parâmetro de dificuldade evolutivo intrínseco ao jogo. Ou seja, conforme o tempo avança, o nível de dificuldade vai se incrementado e o jogador não pode modificar esta dificuldade. Requisito previsto nas especificações do projeto.
3. Contagem de tempo de jogo: como outro parâmetro de métrica de pontuação, foi acrescentado o tempo de jogo. As interações com os membros da equipe de desenvolvimento se mostraram muito à favor desta característica.
4. Aumento do conjunto de palavras: tendo em vista o feedback de uso do jogo no primeiro release, decidiu-se aumentar o conjunto de palavras relacionadas e não relacionadas com engenharia de software.
5. Criação de frases: tendo em vista o feedback de uso do primeiro release pelo cliente, uma nova funcionalidade foi acrescentada no segundo release. Agora no jogo aparecem frases que servem como bônus ao jogador, se ele selecionar uma opção coerente com a frase pontuação extra é somada ao seu score.
6. Lógica de sorteio de palavras: como característica de um desenvolvimento ágil, diversas funcionalidades do jogo final não são previstas nos primeiros releases. Desta forma, teve-se que dedicar um tempo, para o segundo release, alterando uma lógica interna de estrutura de dados de sorteio das palavras com manutenibilidade e portabilidade mais fácil.

Todas as melhorias colocadas para o segundo release foram submetidas a testes. Utilizando a bateria de testes de regressão armazenada durante o desenvolvimento do primeiro release, pode-se validar a funcionalidades que deveriam ter permanecido intactas com o desenvolvimento do segundo release. Um novo critério para armazenar os novos testes realizados nos testes de regressão será discutido entre os membros da equipe em reuniões futuras.

Release entregue ao cliente, aguardando sugestões/críticas.

att,
EEGames®.