INTRODUÇÃO
Seguindo a proposta do Unified Process, um projeto de desenvolvimento de software deve se preocupar com dois importantes aspectos: (i) a engenharia do software (tudo aquilo relacionado com a fabricação e o software -- processo e produto) e (ii) a gerência do projeto (tudo aquilo que se refere à infra-estrutura necessária para a fabricação).
Em cada determinado projeto, a engenharia do software deve ser conduzida de acordo com um processo de trabalho. Ao longo dos anos, diversos modelos de processos foram investigados e experimentados. Três grandes categorias de modelos de processos podem ser identificadas: (i) lineares, como o Waterfall, (ii) espiral, como o Spiral, (iii) iterativos e incrementais, como o Unified Process. Recentemente, percebeu-se que aqueles modelos de processos da categoria (iii) apresentavam melhores resultados finais (conseguia-se fabricar o software do projeto com uma alta taxa de sucesso, quando comparada às demais categorias de processos).
PROJETO DE SW DE JOGOS
A realização do projeto de software de um jogo é diretamente influenciado pela natureza do software. Intangibilidade é parte dessa natureza. Volatilidade de requisitos também. Particularmente, esses dois aspectos da natureza de um software conduzem a uma grande dificuldade para a gestão do projeto em si. Esses ingredientes tornam não-convencional a gerência do projeto exigindo modelos gerenciais específicos, sob pena de ocorrer uma divergência da gestão em relação ao processo e ao produto do projeto.
Risco é um aspecto vital para a gerência de projetos. A questão "O que pode dar errado?" quase que impõe uma atividade gerencial conhecida por planejamento. No caso de produtos de software, a pergunta ainda embute, de forma implícita, a intangibilidade e volatilidade daquilo que pode dar errado (enquanto produto) e das atividades mentais de fabricação, que pouco podem ser rastreadas sem um registro apropriado. Em um projeto de jogo, isso exige daqueles diretamente envolvidos no software considerem as implicações de todas as suas atividades. Sempre que um novo elemento do jogo é integrado no software, ocorre um progresso na conclusão do projeto. Entretanto, isso provoca um aumento da complexidade (do software), cuja lei de crescimento tem forma exponencial. Ou seja, a introdução de erros de implementação ao longo do tempo torna cada vez mais cara a sua localização e subsequente correção (em diversas unidades de medida, não apenas a financeira).
VISÃO PESSOAL
Não conheço, em profundidade, literatura específica sobre o tema "Projetos de Desenvolvimento de Jogos, visão de Software". Irei estudar a respeito. Entretanto, acredito que diversos elementos do P(FTP)L devam ser contextualizados e experimentados. (P(FTP)L: Processos, (Ferramentas, Técnicas, Práticas), Linguagens, by Ítalo.)
SUGESTÃO
Em um curso sobre Produção de Jogos, seria interessante trabalhar com:
1) Linha temática suplementar: Gestão de Projetos de Implementação de Jogos.
2) Técnicas e práticas de gestão:
- Apresentação e crítica técnica dos projetos conduzidas pelos próprios alunos. Professor atua como moderador das participações dos alunos, incentivando a percepção de características (positivas e negativas) dos projetos, pontos de melhorias e adaptações, sugestões, etc.. Professor também deve assumir o papel de crítico, quando for apropriado.
- Organização do tempo do projeto. Professor ajuda na elaboração de calendários (cronogramas) de intenções e de comprometimentos. Cada fator de risco do projeto deve ser avaliado quanto a sua investigação e prioridade.
- Etc.
BIBLIOGRAFIA PRELIMINAR
- Flynt, J. P.; Salem, O. Software Engineering for Game Developers. Course Technology PTR, 2004.
- Braude, Eric. Software Design: From Programming to Architecture. John Wiley & Sons, 2004.
- Martin, Robert C. Agile Software Development: Principles, Patterns, and Practices. Pearson Education, Inc, 2003.
Nenhum comentário:
Postar um comentário