upGAME Group - Progresso

Ontem o par 3 concluiu o mini-game 4.1 (Gabriel Poesia e Guilherme Cordeiro), fez alguns testes (Testes de caixa branca). O próximo passo a serem realizados nesse mini-game será a revisão de código e os testes de Caixa Preta. Testes de caixa cinza, serão realizados quando este mini-game for integrado ao restante do projeto.

Várias funções foram criadas usando JQuery e usando o MelonJs para controle do fluxo.

Neste mini-game temos 5 métricas que o jogador deve definir:

• Número de bugs por ponto de função
• Fração do código coberto por testes automatizados
• Fração do código revisado por um desenvolvedor que não escreveu o código
• Horas por ponto de função
• Fração dos requisitos que precisaram de revisão

Depois de definir isso, ele clica em um botão que "simula" o uso dessas métricas em um projeto. Com isso, ele obtém uma mensagem de resultado, do tipo:

• "Que pena! O número de horas máximo por ponto de função que você determinou fez com que os programadores corressem demais. O número de bugs por ponto de função no projeto foi absurdo, e isso fez com que o custo fosse alto demais!"
• "Que pena! Sem uma meta alta, seus programadores não escreveram suficientes testes automatizados. Com isso, muitos bugs foram reintroduzidos depois de corrigidos, por não haver testes de regressão. Quem confiará no projeto entregue?"
• "Que triste. Como você não permitiu que os requisitos fossem alterados algumas vezes, os analistas medrosos realizaram dezenas de reuniões de levantamento e consolidação de requisitos com os clientes. Isso atrasou muito o início do desenvolvimento e os clientes reclamaram do tempo que gastaram com isso, além do custo alto do projeto."
• "É... como você permitiu que os requisitos fossem muito alterados, eles foram muito mal escritos no início do projeto. Com isso, somente em reuniões de apresentação de entregas parciais é que vocês descobriram que o cliente queria funcionalidades muito diferentes! Isso atrasou o projeto e aumentou muito seu custo, por causa das mudanças tardias em requisitos."

Ou...

• - "O projeto foi um sucesso! Os bugs registrados durante os testes foram corrigidos a tempo e o cliente ficou satisfeito com o produto entregue. O custo ficou dentro do esperado, e toda a equipe ficou muito motivada por ter um projeto de tanto sucesso. Ninguém imaginou que a definição de metas quantitativas, quando bem aplicada, pudesse ser tão efetiva! Parabéns!"

Quando ele obtém essa última mensagem, passa para o próximo mini-game.

Estamos discutindo mensagens de retorno mais legais para melhorar a experiência de usuário, além de tentar aumentar a dificuldade, pois o mini-game pode ser resolvido através de tentativa e erro, o que não está alinhado aos nossos objetivos, que é ensinar os princípios do CMMI e não se aprende muito realizando um processo de tentativa e erro para resolver problemas.

Veja abaixo alguns screenshots relativos ao mini-game 4.1:

CF70 - Logo e novas decisões

Definimos uma logomarca para nossa empresa:
 

 
Decidiu-se utilizar uma textura metálica para mostrar a força e a resistência do grupo como um todo.

Além disso, pensamos também no nome do jogo e no nome do personagem principal.

O nome do personagem principal foi decidido como Renan C. Milgram.

Seu sobrenome é uma referência ao psicólogo Stanley Milgram, responsável por conduzir o famoso estudo sobre a obediência à autoridade (cujo resultado pretendemos usar na implementação do sistema de alinhamento dos personagens do jogo).

O título do jogo será: Renan Milgram e a Aula Perdida.

As tarefas na planilha continuam a serem executadas por seus respectivos membros.
A mecânica de um dos mini-jogos está bem adiantada e pretendemos detalha-la em breve.

upGAME Group - Segunda Apresentação

A segunda apresentação do nosso grupo está disponível para o público. Vejam abaixo ou façam o download pelo link: https://docs.google.com/presentation/d/1mz6CGkXUuG9CCYJlZOuEsig-BXp2aHpiYavYmgjR1js/pub?start=false&loop=false&delayms=3000

Resumo planejamento do enredo - esofteacher@sHoRTc

Na reunião de planejamento da próxima corrida (sprint), decidimos que as histórias 3, 4 e 5 serão desenvolvidas.

Essas três histórias, principalmente a 4, são a base do nosso jogo, o enredo principal que é o objetivo e que deve interligar tudo.

---

Lista de cenas

Dividimos a história do jogo nas 21 cenas listadas abaixo.

“NaMesa”

   cm - cenaMapa: Cena que se repete, onde o jogador escolhe qual projeto vai seguir na empresa.

Ágil

   aa - cenaMestreBolo: Apresentação do projeto PadaOne e do cliente.

   a1 - cenaCorrida1: Implementação do CRUD-Client.

   ar1 - cenaResumoCorrida1: Resumo da cena cenaCorrida1.

   a2 - cenaCorrida2: Entrega do CRUD-Client e implementação do CRUD-Produto.

   ar2 - cenaResumoCorrida2: Resumo da cena cenaCorrida2.

   a3 - cenaCorrida3: Entrega do CRUD-Produto e implementação do Venda-MesclandoClienteProduto.

   ar3 - cenaResumoCorrida3: Resumo da cena cenaCorrida3.

   af - cenaFimAgil: Entrega final do projeto e parabenização pela dedicação para fazer com que o projeto que utiliza a metodologia ágil fosse um sucesso.

   arf - cenaResumoFimAgil: Resumo do final do projeto, falando que foi entregue mas não foi tão bem quanto poderia, que seria bom se o jogador tivesse conseguido se dedicar mais a ele também.

Tradicional

   ta - cenaGerente: Apresentação do projeto PadaTout e do cliente.

   t1 - cenaJad1: Início da especificação do ClientProductSales.

   tr1 - cenaResumoJad1: Resumo da cena cenaJad1.

   t2 - cenaJad2: Fim da especificação do ClientProductSales.

   tr2 - cenaResumoJad2: Resumo da cena cenaJad2.

   t3 - cenaImplementacao: Implementação do ClientProductSales.

   tr3 - cenaResumoImplementacao: Resumo da cena cenaImplementacao.

   tf - cenaFimTradicional:  Entrega do projeto e parabenização pela dedicação para fazer com que o projeto que utiliza a metodologia tradicional fosse um sucesso.

   trf - cenaResumoFimTradicional: Resumo do final do projeto, falando que foi entregue mas não foi tão bem quanto poderia, que seria bom se o jogador tivesse conseguido se dedicar mais a ele também.

OutrosFinais

   fm - cenaFimMisto: Entrega dos dois projetos. Explicação de que os dois projetos foram terminados mas não foram tão bem por falta de atenção ou de mais pessoas trabalhando dedicadas a eles. Um pouco de reclamação pelo jogador ter se dedicado a nenhum projeto.

   fd - cenaDemissao: Jogador demitido da empresa.

As cenas principais do desenvolvimento dos projetos (a1, a2, a3 e t1, t2, t3) são as cenas mais complexas, que terão ações que vão influenciar nas barras de stress.

Algumas das diferenças entre os projetos que serão abordadas:

1. Inexistência do papel de levantador de requisitos no processo ágil.
2. No tradicional o contato com o cliente é concentrado durante o levantamento de requisitos enquanto que no ágil o contato é mais frequente durante todo o projeto.
3. No ágil as entregas são mais frequentes.
4. No tradicional a documentação maior no tradicional enquanto história do usuário são rasgadas no ágil.

---

Fluxo das cenas

As cenas aa e ta, por serem de apresentação do usuário aos projetos, acontecerão no início do jogo e o usuário poderá escolher qual delas verá primeiro.

Durante o desenvolvimento dos projetos o jogador escolherá em qual time vai se dedicar a cada “turno” e  essa escolha determina qual cena ele vai ver. Serão três turnos sequenciais, formados pelos pares de cenas a1 e t1, a2 e t2, a3 e t3. Caso o jogador vá bem na cena escolhida ele ganha o direito de participar da cena do outro time do mesmo turno. Caso não vá bem ou caso não queira ver a outra cena, o jogador é conduzido a uma cena resumo do que aconteceu com a outra equipe (ar1, ar2, ar3, tr1, tr2, tr3).

Caso o jogador consiga participar de todas as três cenas de desenvolvimento de um projeto ele participa da cena final dele. A participação nas cenas a1, a2, e a3 levam à cena af e as cenas t1, t2 e t3 levam à cena tf. Caso consiga participar de apenas de uma dessas cenas finais, um resumo do final do projeto da outra equipe é exibido, cenas arf ou trf. Se o jogador conseguir ir bem ele pode chegar a ver as cenas af E at.

Caso o jogador jogue sem foco em algum dos projetos a cena fm aparece ao final.

Se for mal nos desafios nas cenas, a barra de “estresse” vai subindo e pode chegar a um ponto onde ele é demitido da empresa, aparecendo a cena fd.

Exemplo de fluxo que poderá ser seguido por um jogador abaixo. As linhas tracejadas correspondem a cenas escolhidas pelo jogador enquanto as linhas sólidas correspondem ao jogador sendo levado automaticamente a uma cena pelo sistema.

CF70 - Atualização da Planilha

Desde a última apresentação, progredimos em todas as tarefas descritas na planilha do Kanban. A planilha atualizada pode ser visualizada no link abaixo:

https://www.dropbox.com/s/gkxms43bmed5ltk/kanban_2014_04_15.xlsx

Na parte de Recursos, a obtenção dos sprites de personagens foi finalizada, uma vez que uma quantidade julgada satisfatória de imagens foi obtida. Com isso, Gianlucca passou a trabalhar na próxima tarefa: recursos de HUD (heads-up display), que é a representação dos objetos de interface do jogo.

A primeira tarefa da parte relacionada às Fases, elaboração do conceito do cenário, já havia sido terminada na semana passada. Atualmente, o mapeamento dos objetos do jogo no cenário já está sendo feita pelo Luiz.

Quanto ao Roteiro, parte trabalhada por Rafael, a história do jogo também já havia sido definida. No momento estão sendo determinados os personagens que farão parte do jogo, levando em conta os sprites encontrados até então.

As ideias de alguns Mini-Jogos e Eventos foram refinadas desde a semana passada, e a partir de agora o Ramon trabalhará na elaboração das mecânicas dos mesmos.

Os temas das Perguntas foram revisados e consolidados. Rodrigo já começou a pensar nas perguntas que serão utilizadas no jogo.

Alguns detalhes do Código das mecânicas do jogo passaram por refatoração e testes. No momento Túlio está concentrando seus esforços na implementação de um sistema de menus.

Apesar de algumas tarefas terem sido definidas como "Finalizadas", nada impede o grupo de voltar a uma delas caso necessário, dada a natureza iterativa do processo. Por exemplo, é possível que novos sprites sejam necessários em uma fase mais avançada do projeto, ou que novos temas para as perguntas sejam considerados.

CF70 - Detalhamento da 2ª Apresentação e do que foi feito

Conforme citado na postagem anterior, detalharemos os tópicos apresentados na aula de hoje.

As tarefas definidas anteriormente foram divididas entre os integrantes do grupo, conforme pode ser verificado na planilha do Kanban (link: https://docs.google.com/spreadsheet/ccc?key=0AnimSuX7qDHcdGd6aFRvZ2ZPc01YS1llOTVIRmQtNXc&usp=sharing#gid=0).  Cada tarefa pode estar em um determinado estado ("a fazer", "sendo feito" e "finalizado").

Cada membro trabalhou em suas respectivas tarefas durante o período entre as duas últimas apresentações, mas podendo auxiliar em uma outra caso necessário.

Decisões de Cenário: Seguindo as tarefas na planilha Kanban, a primeira etapa do desenvolvimento do cenário é a criação do conceito do mapa.

Definiu-se que o cenário do jogo será o prédio do ICEx e ocorrerá no primeiro e segundo andar com foco em alguns locais chave, como mostrado nas imagens.

1ºAndar

2ºAndar

Decisões de recursos: As imagens dos personagens do jogo (sprite) foram todas retiradas do site DeviantArt (http://www.deviantart.com/) e possuem a devida autorização de seus autores desde que creditado. Os modelos seguem o estilo do jogo Pokémon apesar de serem obras originais e, portanto, apresentam visual cartoonico. No momento nosso acervo possuí modelos dos alunos, professores e das funcionárias da cantina (que infelizmente terão o contrato encerrado em maio de acordo com fontes confiáveis).

Decisões de história: Jogo acontece no dia 20/03, posterior a conhecida “Enchente das Goiabas” (http://cronicasurbanas.wordpress.com/2010/03/19/enchente-das-goiabas/), e não havia chovido até então. Dessa maneira, a ocorrência de chuva completamente inesperada prejudicou o aluno, resultando em sua chegada atrasada para a aula. Uma vez em sala de aula, ele descobre que tem de entregar uma lista de exercícios até o fim do dia, relacionado aos temas mencionados na aula que perdeu. Assim, precisará de toda ajuda que conseguir (colegas, internet, professores, biblioteca) para terminar a lista a tempo e aprender o que foi ensinado.

Decisões dos mini-jogos e eventos: Alguns dos mini-jogos e eventos pensados envolvem: Sinuca no DA, Queda de Energia nos laboratórios, Conversa atendente da cantina, Conversa Achados e Perdidos, Conversa colegas e professores.

Discorreremos sobre o assunto em uma ocasião futura, pois o tema é extenso e possuí conteúdo para uma postagem por si só.

Decisões das perguntas: O jogo possuirá de 10 a 15 perguntas, que estarão relacionadas com os eventos citados no tópico anterior e as outras interações possíveis.O tema das perguntas abrange uma gama de aspectos, dentre eles destacam-se: CMMI, Cone da Incerteza, Ciclos de Vida do Software, Deseconomia de Escala, Pontos de Função, Agilistas X Tradicionalistas, Linguagem UML.

Decisões de mecânica: Como grande parte do código de mecânica de jogo já havia sido implementado no protótipo mostrado na última apresentação não houveram grandes mudanças. Foram apenas realizados alguns ajustes nas colisões de objetos, movimentação e demais aspectos.

Decisões gerais: Descobrimos que o GameMaker possuí um controle de versão e o estamos utilizando (Versão atual: 1.1.1.3). Também decidimos inserir um glossário definindo termos importantes da matéria, a medida que o jogador entra em contato com eles. Rejeitamos a ideia de vários níveis, pois ela não condizia muito bem com a história elaborada e levaria a um jogo muito repetitivo.

CF70 - Apresentação 10/4

Segue o link para a apresentação de hoje:

Apresentação 10/04

Também segue o link para o executavel apresentado:

Prototipo do Jogo

Mais tarde falaremos mais detalhadamente sobre sobre os tópicos apresentados.

Versão de 10/04 - esofteacher@sHoRTcut

Endereço para download:

 

goo.gl/I048UU

Apresentação 10/04 - esofteacher@sHoRTcut

Reunião Semanal 06/04 esofteacher@sHoRTcut

Estes foram os temas discutidos por nossa equipe durante a semana e na última reunião semanal:

• Spring Backlog - 02

Definimos algumas cenas que serão utilizadas para o nosso jogo:

• Uma cena de introdução, onde o recém chegado é recebido na empresa “Padasoft” pelo supervisor e este o instrui com relação aos dois grupos de desenvolvimento de software da empresa. O grupo ágil segue o processo “PadaOne” enquanto a equipe tradicional segue o processo “PadaTout”.
• Uma cena de “RH”, onde o usuário do jogo preenche um formulário onde estão definidos alguns aspectos do personagem, como gênero, idade, nome, etc… que será utilizado posteriormente para definir certas situações e respostas dentro do jogo, além de criar um senso de customização e permitir uma aproximação do personagem com as preferências do usuário.

• Apresentação 10/04
• A respeito da próxima apresentação que será realizada discutimos sobre fazer uma compilação do que foi efetivamente implementado pós apresentação número 1. Em seguida demonstraremos o funcionamento da aplicação baseado em uma cena introdutória da história, que consiste na apresentação do personagem aos seus projetos.

• Grafo de história

• Sugestão de fazer um grafo sobre a história para permitir uma análise das escolhas feitas pelo usuário e avaliar a trajetória do personagem. Além disto esse grafo seria responsável por facilitar a detecção de erros em condições e loops na história.

• Cena help
• Inicialmente iriamos utilizar um Help simples no formato html. Porém esta funcionalidade apresentava algumas inconsistências quando utilizada em um tablet. Diante disto, optamos por incorporar o help a uma cena separada do jogo. Assim, ele funcionará em qualquer dispositivo suportado pelo renpy.

upGAME Group - Ata Reunião de Sprint

Em virtude da prova de Engenharia de Software, não pudemos postar essa ata na semana passada, mas agora já tivemos um tempo para formalizá-la e gerar um documento.

Como todos os integrantes estavam muito ocupados com provas e trabalhos de várias matérias, essa sprint foi menor que as demais.

O objetivo dela é apenas ser uma sprint de preparação.

Veja com mais detalhes o que fui resolvido e definido para esta sprint.

Neste arquivo também está disponibilizado o link do repositório Github para quem tiver interesse em acompanhar o desempenho e o progresso do grupo.

Para visualização e download do documento clique aqui.