IMPORTANTE: Datas Finais

Alguns prazos finais, lembrando que atrasos em qualquer entrega serão penalizados!

• Data-limite para entrega dos formulários da avaliação final: 18/11 às 23:55
• Data-limite para postagem dos vídeos: 20/11 às 23:55.  
• Data-limite para envio do link do jogo: 20/11 às 23:55. Um link para a versão completa do jogo deve ser enviado por email para a monitora. 
• Data-limite para postagens: 20/11 às 23:55: postagens após essa data serão desconsideradas para a avaliação final do grupo. As postagens podem seguir o mesmo modelo da última apresentação, incluindo uma discussão reflexiva sobre o processo adotado.

IMPORTANTE: Substituição da Apresentação Final

Como já informado pelo professor Rodolfo, a apresentação final será substituída por um ou mais vídeos. O objetivo do(s) vídeo(s) é que os grupos evidenciem como o processo de desenvolvimento foi estabelecido e como esse processo conduziu o desenvolvimento do "jogo para conceitos de Engenharia de Software".

Vocês têm liberdade para montar o vídeo da forma como desejarem, desde que o objetivo mencionado acima seja alcançado. Uma sugestão seria dividir o vídeo em duas partes, uma explicitando o processo e em seguida uma apresentação do produto final. Porém, essa é apenas uma sugestão, logo os grupos podem optar por não seguir esse formato.

Algumas regras devem ser seguidas:

1) O(s) vídeo(s) devem ser postados como vídeos públicos na conta da turma no YouTube até domingo, dia 20/11. Informações sobre a conta da turma foram enviadas por email. Para receber novamente é só enviar um email para a monitora.

2) O grupo pode realizar:
- um único vídeo de 5 a 10 minutos OU
- vários vídeos com duração total máxima de 15 minutos

Orientações da Terceira Apresentação

Amanhã teremos a terceira apresentação do trabalho, dessa forma:

• esperamos que seja apresentada uma versão funcional do jogo e
• deve-se discutir o quanto a versão atual está distante da versão que foi proposta no início do trabalho e o que será feito até a entrega final.

Além disso, os seguintes pontos também devem ser discutidos:

Processo:

- Requisitos (cerca de 20% da nota): definir os requisitos do produto e da iteração, assim como o está pronto.

- Projeto (cerca de 20% da nota): evidências de projeto no nível 2 de maturidade do cmmi.

- Outros (cerca de 20% da nota):
    - Organização do grupo: para cada aluno, qual foi seu papel/contribuição na iteração.
    - Decisões da iteração: decisões de implementação, decisões relativas ao processo.
    - Desafios encontrados: problemas com o produto/processo de desenvolvimento.
    - Testes: testes realizados e resultados obtidos.

Produto: funcionamento(cerca de 20% da nota) e outros (cerca de 20% da nota).

Orientações da Segunda Apresentação

Amanhã teremos a segunda apresentação do trabalho da disciplina. Como já mencionado, 40% da nota é relativa ao produto e 60% ao processo. Dessa forma, a apresentação será avaliada considerando:

Processo:

- Requisitos (20% da nota): definir os requisitos do produto e da iteração, assim como o está pronto.

- Projeto (20% da nota): evidências de projeto no nível 2 de maturidade do cmmi.

- Outros (20% da nota):
    - Organização do grupo: para cada aluno, qual foi seu papel/contribuição na iteração.
    - Decisões da iteração: decisões de implementação, decisões relativas ao processo.
    - Desafios encontrados: problemas com o produto/processo de desenvolvimento.
    - Testes: testes realizados e resultados obtidos.

Produto: funcionamento(20% da nota) e outros (20% da nota).

Orientações Sobre as Postagens

• O objetivo das postagens é ter um registro de como o grupo se organizou no tempo, logo, o grupo deve postar no blog sempre que houver um avanço no trabalho, ou seja, alguma atividade/esforço foi completada.

• Por exemplo:

• O grupo planejou "Tarefa 1" -> vai para o blog

• O grupo executou "Tarefa 1" -> vai para o blog

• Todas as postagens de um mesmo grupo devem apresentar o marcador do grupo. Logo, pastagens do "Grupo 1" devem apresentar o marcador "Grupo 1".

Importante

Recomenda-se registrar todos os esforços do grupo, incluindo, mas não se limitando, aos seguintes pontos:

• Requisitos: definir os requisitos do produto e da iteração, assim como o está pronto.

• Organização do grupo: para cada aluno, qual foi seu papel/contribuição na iteração.

• Decisões da iteração: decisões de implementação, decisões relativas ao processo.

• Desafios encontrados: problemas com o produto/processo de desenvolvimento.

• Testes: testes realizados e resultados obtidos.

AVISO IMPORTANTE! Direitos Autorais

Cada grupo será responsável por certificar que qualquer material usado no processo e no produto não têm restrições relacionadas a qualquer aspecto, em particular relacionadas a Direitos Autoriais. Este tipo de problema faz parte da avaliação e poderá acarretar grande impacto nas notas.

Para mais informações sobre direitos autorais em jogos, o site gamasutra.com  apresenta e discute alguns mitos sobre materiais protegidos. No caso de desenvolvimento de jogos não se pode, por exemplo, solicitar para si o direito sobre a ideia de blocos que caem e desaparecem quando estes formam uma linha[1]. Contudo, conteúdos multimídias envolvidos no jogo (música, texto, ícones, fotos, API’s, bibliotecas e etc) podem estar protegidos pelos “direitos de cópia” (copyright). Além destes, conteúdos de livros de Engenharia de Software incluindo perguntas e respostas, podem ter direitos autorais e de comercialização.

Para auxiliar no desenvolvimento dos jogos, existem repositórios que oferecem conteúdo não protegidos por direitos autorais:

• O site archive.org oferece diversos tipos de conteúdo multimídia que são de livre utilização para fins acadêmicos. Para maiores detalhes acesso Termo de Uso do site.
• Este artigo da Wikipédia apresenta diversas fontes de áudios que são de domínio público ou livre.
• Neste artigo fontes de domínio público para imagens.

Uma sugestão para todos os grupos é incluir o requisito de que o jogo tenha a funcionalidade “Créditos” em que se exibe todo o material utilizado, mesmo aqueles que são livre, durante o desenvolvimento da aplicação. Esta abordagem deve ser utilizada quando o jogo utiliza algum conteúdo para explicar determinado conceito de Engenharia de Software.

[1] http://gbgames.com/blog/articles/indie-legal-copyright-and-trademark/what-an-indie-needs-to-know-about-copyright/

Primeira Apresentação e Postagem

Caros alunos,

Conforme é de conhecimento de todos na próxima quinta-feira, dia 15/09/2016 será realizada a primeira apresentação do trabalho prático da disciplina. Com intuito de ajudar na estrutura da apresentação vou apresentar algumas sugestões do que esperamos que seja exposto em sala da aula.

• O foco da apresentação deve ser maior no “processo de desenvolvimento”. O jogo (produto) é importante na composição da nota final, contudo, a forma que o “processo de desenvolvimento” vem sendo considerado representa 60% da nota final.

• Apresentem como os requisitos serão representados e gerenciados: a ferramenta utilizada para elucidar os requisitos, a situação de cada requisito, como os requisitos são classificados e priorizados.

• Apresentem como planejar e monitorar a iteração/corrida("sprint"). 

• A organização do grupo deve ser discutida. O papel a ser desempenhado por cada integrante deverá ser discutido sendo que estes papéis devem ser aderentes ao processo de desenvolvimento escolhido. Por exemplo: o SCRUM dá ênfase aos diferentes papéis.

•  Não é necessário ficar preso ao documento utilizado para apresentação (pdf, ppt, GoogleDocs). Muitas vezes apresentação da ferramenta que vocês estão utilizando para gerenciar o projeto, do código fonte e outros artefatos ilustram melhor o que vocês estão desenvolvendo do que apresentação por si só.

   

Outras observações importantes:

 

• A apresentação deve possuir de 15 a 20 minutos

• Nem todos os integrantes do grupo precisam falar durante a apresentação. Porém, cada integrante deverá participar de pelo menos duas das quatro apresentações ao longo do semestre.

• A primeira postagem deverá conter: a definição e justificativa do processo de desenvolvimento adotado, a tecnologia utilizada, motor de jogo, ambiente de desenvolvimento, controle de versão, framework e o cronograma a ser seguido. 

• Recomenda-se que os pontos principais da apresentação e qualquer outra informação que o grupo julgue ser relevante, conste nas postagens. As postagens fazem parte da avaliação do grupo!

• As postagens de cada grupo devem apresentar um marcador que identifique o grupo. Por exemplo, o grupo de nome "Grupo 1", deve realizar todas as postagens com o marcador "Grupo 1".

• A data limite para a primeira postagem é dia 16/09/2016 até 23:55. Postagens após essa data serão penalizadas.

Definição dos Grupos

Caros alunos,

segue a relação de alunos de cada um dos grupos definidos. Alunos que não tem grupo (ou que o nome não consta na lista) devem entrar em contato com algum dos grupos com menos de 12 integrantes e mandar um email para a monitora (thpaiva@dcc.ufmg.br) com o nome/email do aluno e do grupo escolhido.

• CRUD para Sempre
• Amanda Cristina Castro dos Santos
• Ana Karolina Madeira Vilhena
• Guilherme Vieira Leobas
• Guilherme Resende Borges
• Gustavo Roscoe de Assumpção
• Junio Cezar Ribeiro da Silva
• Marcelo Anselmo Gomes
• Marcos Paulo Quintão Fernandes
• Mariana de Oliveira Santos Silva
• Rafael Libanio Solli
• Thiago Silva Martins
• Rômulo Nogueira Coutinho

• Ganhando XP
• Matheus Jamil Alves Rachid
• Márcio Danilo Costa Júnior
• Guilherme Jácome de Paula
• Lorena Barreto Simedo
• Helbert Luiz Paulino
• Danilo Pacheco Lima
• Lucas Gabriel Aeraf de Assis
• Bernardo Brescia

• Grupo 3
• Andre Cunha
• Gustavo Mitsuichi Oliveira
• João Francisco Moreira Penna
• Marco Antonio Ribeiro
• Nivaldo Teixeira
• Pedro Bernardina
• Renan Aragao
• Victor Ferreira Muniz
• Vitor Lopes
• Wilson Carlos

Avisos Importantes

Definição dos Grupos

A data limite para a definição dos grupos é dia 8 de setembro. Relembrando:

• grupos devem ter de 8 a 12 integrantes e
• o email dos integrantes de cada grupo deverá ser informado na planilha para permitir o acesso de todos ao blog.

Primeira Postagem 

 

• as postagens de cada grupo devem apresentar um marcador que identifique o grupo. Por exemplo, o grupo de nome "Grupo 1", deve realizar todas as postagens com o marcador "Grupo 1".
• A primeira postagem deverá conter: a definição e justificativa do processo de desenvolvimento adotado, a tecnologia utilizada, motor de jogo, ambiente de desenvolvimento, controle de versão, framework e o cronograma a ser seguido. A data limite para a primeira postagem é dia 15 de setembro. Postagens após essa data serão penalizadas. 

 

Especificação do Trabalho Prático

Objetivo

 

Projetar e implementar um jogo para ensinar conceitos de Engenharia de Software (ES). Mais do que entregar um produto funcional, este trabalho visa a elaboração e execução de um processo de desenvolvimento que permita gerenciar os desafios de se trabalhar em equipe durante o desenvolvimento de um software.

Enunciado 

 

O seu grupo foi contratado como time de desenvolvimento de um jogo cujo objetivo é ensinar conceitos de Engenharia de Software. 

O jogo pode ser desenvolvido para plataforma móvel (Android, iOS) ou Web e possui como foco o ensino de um ou mais temas tratados na disciplina (requisitos, processos, etc). Recomenda-se o uso de tecnologias com as quais tenha-se familiaridade para evitar acúmulo no esforço de aprendizado. Além disso, o estilo do jogo fica a critério do grupo podendo ser escolhido entre jogos de plataforma, simulação, estratégia, aventura, tabuleiro, ação e quebra-cabeça. Na dissertação de mestrado de Rodrigo Possa existem exemplos de jogos que podem servir como inspiração. Finalmente, cabe a cada grupo preparar o roteiro do jogo e selecionar o motor de jogo (game engine) mais apropriado, justificando sua decisão.

O trabalho deverá ser desenvolvido utilizando as práticas, técnicas e idéias do Scrum e do XP, com vistas ao atendimento das áreas de processo do nível dois de  maturidade do CMMI-DEV, o grupo pode negociar o uso de outros métodos/processos.

A definição do processo a ser utilizado deve constar na primeira postagem de cada grupo no Blog. O processo de desenvolvimento, a tecnologia utilizada, motor de jogo, ambiente de desenvolvimento, controle de versão, framework, dentre outra deverão ser aprovados previamente pelo monitor.

Toda evidência de aderência ao processo deve estar justificada e postada no Blog, bem como todos os objetos entregáveis que o processo exige. Essas postagens serão consideradas para fazer a maior parte da avaliação.

Recursos

 

• Podem ser consultados os trabalhos feitos em semestres anteriores como guia. Isso pode ajudar tanto na ideia de um projeto quanto nas atas de reunião. Cabe ressaltar que os trabalhos dos semestres anteriores não são na maioria bons exemplos. Todavia, o grupo poderá ter uma ideia do que deve ser evitado.
• 1º semestre de 2016, com o monitor Vagner Clementino
• 2º semestre de 2015, com o monitor Guilherme Avelino
• 1º semestre de 2015, com o monitor Miguel Ramos
• 2º semestre de 2014, com a monitora Kattiana Constantino 
• 1º semestre de 2014, com a monitora Luciana Lourdes
• 2º semestre de 2013, com o professor Sérgio Crespo
• Um artigo do SBGames de 2012, publicado no blog do professor Sérgio, dá sugestões de métodos para o desenvolvimento de jogos.
• Nos seguintes links vocês podem achar motores de jogos para diferentes linguagens: Várias linguagens e Motores Web (html5).  

Informações Importantes 

 

• O Trabalho Prático (TP) estará descolado das aulas teóricas da disciplina. Enquanto as aulas teóricas seguem uma certa sequência o grupo deverá trabalhar desde agora com vários aspectos que não estão presentes nas aulas teóricas ou que serão tratados ao longo do semestre.
• É importante planejar bem o processo que será utilizado para implementar o projeto.
• Podem ser acessados os trabalhos dos semestres anteriores, contudo, as propostas de jogos devem ser diferentes com relação ao tema e/ou a tecnologia empregada. Por exemplo: um grupo do semestre passado escolheu o tema CMMI e usaram flash/actionscript. Assim, se alguém quiser escolher este tema não pode usar a tecnologia flash.
• O desenvolvimento deverá ser do tipo interativo incremental, entregas frequentes, controle de versão, dirigido por testes, o grupo deve investir na maturidade do processo.
• Os grupos deverão ter de 8 a 12 estudantes. Os integrantes do grupo acessar a planilha e informar o nome do grupo, assim como o nome completo do aluno e o email. Somente depois que o grupo listar os alunos, será possível adicioná-los como autores para que possam postar sem restrições no blog. A data limite para definição dos grupos é dia 08 de setembro.
• O grupo deverá elaborar um cronograma de entregas que será acompanhado pelo monitor da disciplina. Existe a expectativa de que sejam feitas 3 ou 4 entregas de software funcionando, as entregas não coincidem, necessariamente, com as apresentações, mas é esperado que nas apresentações cada grupo discuta o que já foi entregue e qual o planejamento para a entrega seguinte. A apresentação final apresenta o resultado final obtido. 
• O cliente do jogo é a monitora Thanis Paiva (thpaiva@dcc.ufmg.br).

 

Avaliação

 

• O trabalho será avaliado, principalmente, com relação a aderência a um processo e justificativas das tomadas de decisão! Esta parte da avaliação equivale a 60% do total. Para isso: toda evidencia de aderência ao processo deve estar postado no BLOG da turma.
• O jogo desenvolvido será também avaliado entre os alunos que deverão ordenar os resultados dos grupos. Esta parte equivale a 40% do total.
• O grupo também será avaliado em termos de conseguir se organizar para trabalhar de maneira contínua e distribuída, evitando o padrão de "picos de esforço". Isto é, um esforço de algumas horas um dia antes ou no dia de um ponto de verificação. Uma das maneiras de verificação será em função das publicações no blog e dos sistemas de controle de versão escolhido.
• É incentivada a criação conjunta de conteúdo. Desta forma, ao final do semestre o conjunto de sugestão e participação postadas neste blog será avaliada para possíveis pontos extras(da ordem de até 5% dos pontos da avaliação). 
• Os grupos devem fazer apresentações com duração de 15 a 20 minutos, informando o desenvolvimento do projeto, as decisões tomadas, as dificuldades encontradas, o cronograma e os avanços obtidos referentes à apresentação anterior. As datas das apresentações estão definidas abaixo:
• 15 de setembro
• 6 de outubro
• 27 de outubro
• 8 de novembro (Apresentação Final)