Jogo das Equações

O "Jogo das Equações" (JEQ) serve como contexto para a modelagem de software por "responsabilidades de objetos". Ele faz parte de uma série de ensaios realizados ao longo da disciplina de programação do curso de Ciência da Computação. A ideia é que o jogador informe os coeficientes "a" e "b" de uma equação de 2o grau e solicite o cálculo das suas raízes. Se elas forem reais e maiores do que zero, o jogador ganha a partida; perdendo, em caso contrário. O coeficiente "c" será aleatoriamente gerado no intervalo de 1 a 1000, inclusive. Quais são os requisitos de uma aplicação para esse jogo? Qual a sua arquitetura? Quais as classes dos objetos da aplicação?

Requisitos do JEQ

A Técnica ICA (Interface Com o Ambiente) ajuda na etapa de identificação de requisitos de negócio. Para o JEQ, 12 requisitos de negócio podem ser identificados, sendo o RF1 ("Calcular o resultado da jogada a partir dos coeficientes 'a' e 'b'") aquele que caracteriza a essência do JEQ.

Requisitos e Alocação de Responsabilidades

Para cada requisito (promessa feita pela aplicação para o usuário), deverá existir um objeto (simples ou complexo) com a responsabilidade de ajudar a aplicação no seu cumprimento. Assim, no caso do RF1, deverá existir um objeto responsável por ajudar a aplicação a calcular o resultado da jogada. Qual seria a classe de tal objeto? O "Princípio do Napoleão" é uma técnica útil nesse ponto. A pergunta: "Qual objeto deve ser responsável por calcular o resultado da jogada do JEQ?" Resposta: um objeto da classe JEQ!

Mas, para que seja possível realizar o cálculo, é preciso que tal objeto conheça os valores dos coeficientes "a", "b" e "c". Os dois primeiros são informados pelo jogador. O valor de "c", entretanto, deve ser gerado aleatoriamente. Ou seja, deverá existir uma classe de objetos com a responsabilidade de gerar o valor do coeficiente "c". Qual objeto deve ser responsável por gerar o coeficiente de uma equação para o JEQ?

Requisitos como Promessas da Aplicação

Ajuda pensar em requisitos no sentido de "promessas que uma aplicação" faz para o usuário? Tenho experimentado isso nas aulas (grad e pós) e o efeito tem sido muito positivo. Ao forçar a leitura como "a aplicação promete fazer isso para o usuário", o modelador tende a identificar um requisito funcional mais claramente. Da mesma forma, ao forçar a leitura "a aplicação promete fazer isso obedecendo aquilo para o usuário", um novo requisito regulatório (não-funcional) é identificado.

Além disso, a palavra "promessa" também sugere a possiblidade de não ser cumprida: o modelador conseguirá chegar em uma arquitetura que cumpra todas as promessas feitas pela aplicação para o usuário? Eventualmente, algumas promessas poderão ser cumpridas (alocando-se responsabilidades aos objetos) e outras não, as quais sofrerão um processo de negociação conjunta com o usuário.

Em relação às promessas regulatórias, uma classificação adicional pode auxiliar na identificação de requisitos:

• promessas de negócio (regras e leis de negócio)
• promessas de produto (URPS)
• promessas de metodologia (processo de desenvolvimento, ferramentas, técnicas, práticas e linguagens)... P(Ftp)L

Objetos versus Procedimentos

De tempos em tempos encontro uma discussão relacionada com os conceitos iniciais de programação que devem ser apresentados em uma disciplina introdutória. Inevitavelmente, o foco acaba destacando uma antiga (agora) discussão: seguir a trilha das linguagens procedimentais ou seguir a trilha das linguagens OO.

Solução de Problemas

Acredito que um ponto importante a ser considerado é aquele que se relaciona com o tema "solução de problemas" no nível abstrato. Esse tema conduz, naturalmente, ao estudo dos algoritmos [Vega, 2008]. Ou seja, quais técnicas auxiliam na descoberta de instruções que resolvem um problema? Quais técnicas auxiliam a organizar tais instruções para que o problema seja resolvido? Como saber se o algoritmo, ao ser executado (em uma máquina abstrata) resolve o problema? O estudo das estruturas de controle (sequencia, decisão e repetição) não pode ser excluído. Como, também, as diferentes maneiras de se organizar as informações manipuladas pelas instruções do algoritmo.

Codificação

Por outro lado, a codificação do algoritmo (e das estruturas de dados), revela um outro tema, de natureza diferente ao de "solução de problemas". Preocupa-se com a geração de um código que resolve um problema ao ser executado em uma máquina concreta (física ou virtual). Quais técnicas são apropriadas para gerar o código? Como coordenar os esforços de vários programadores, quando da geração de trechos de código que devem ser posteriormente integrados?

Seriam as questões relacionadas à solução de problemas e de codificação tratadas em um momento introdutório? Certamente. E como fazer isso? Qual o papel das linguagens de programação?

Revista ReCeT

Concluí a editoração do primeiro número da revista ReCeT, uma revista do Departamento de Computação da PUC-SP. Ela tem a proposta de divulgar trabalhos de pesquisa e posições ideológicas na área computacional. O acesso aos artigos é livre (no site da revista).

Foram quase três anos, desde o momento da ideia até a finalização do primeiro número. Agradeço aos colegas articulistas pelo crédito no projeto, bem como aos demais colaboradores (incluindo os anônimos) pelo apoio e ajuda na reta final.

Faço um destaque para o desenho da capa. Um belo trabalho de belíssima qualidade do professor David. Tive a honra de assistir as suas aulas sobre técnicas de elaboração de roteiro de jogos.

O acesso pode ser feito através do seguinte endereço: http://revistas.pucsp.br/ReCET

Projetos de TI e Estimação

“O problema é que o desenvolvimento de software é um importante esforço, mas não amadureceu como processo de engenharia, ainda é uma forma de arte”.

Craig Mundie
Executivo-chefe de pesquisa e estratégia da Microsoft
http://idgnow.uol.com.br/computacao_corporativa/2007/06/05/idgnoticia.2007-06-05.7937781119/

Normalmente, definem-se indicadores de desempenho sobre pessoas, artefatos (produtos) e atividades, procurando estimar tempo ou gasto financeiro. No caso de projetos de TI, entretanto, surge um agravante: processo, seja ele de desenvolvimento ou de gerência. Dependendo do processo, ocorre uma variação muito grande nos parâmetros pessoas-artefatos-atividades, tornando os indicadores de pouca valia (em parte, daí surgem os 400% de erro do Boehm...) Supondo-se uma maturidade do processo (no sentido CMM, por exemplo) os parâmetros passam a ter um comportamento mais estável (embora o parâmetro pessoa seja fortemente influenciado pelo paradigma de programação, que é outro elemento com marcante influência na definição de indicadores).

Mas aí um novo desafio surge. Os modelos de indicadores tradicionais são definidos acentuadamente em termos das atividades realizadas. Em projetos de TI, no entanto, como medir o andamento de uma atividade de análise? Quanto da análise já foi realizada? Essa pergunta faz sentido? A resposta é: não! Sem acompanhar a realização de uma atividade, como averiguar a performance da pessoa que a realiza? A possibilidade é observar o progresso do artefato... Mas o artefato-alvo de um projeto de TI chama-se: computação. Tal artefato é intangível e móvel (transforma-se com a velocidade das alterações dos requisitos). Assim, como acompanhar o progresso de um alvo intangível e móvel? Nem PMBOK consegue!

Obviamente, muitas pesquisas têm sido realizadas no sentido de se encontrar indicadores para projetos de TI: até agora nada. Apenas para ilustrar, Pontos de Função (IBM, 1979) pressupõem um paradigma de programação centrado em modelagem por decomposição funcional, mas tal paradigma entra em conflito com o paradigma de programação centrado em implementação por objetos, por exemplo, e os indicadores perdem seu sentido de existência. Mesmo com a "reciclagem" da proposta, a instabilidade dos requisitos dificulta o cálculo de indicadores úteis para estimações de projetos de TI.

Outra situação ocorre se houver a tentativa de se empregar algum processo ágil. Já chegamos em "Kanban para software": linha de produção? Ainda não conseguimos responder porque 70% dos projetos de TI fracassam (vide relatórios do Standish, que apenas observam se o projeto foi encerrado dentro do prazo e do orçamento e se os requisitos foram atendidos e controvérsias...)!!!

Resultado: existem muitos modelos de indicadores de desempenho para projetos de TI. Podem e devem ser utilizados para estimação, hoje?

Projetos de Jogos: Aspectos Gerenciais

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.

Sete Princípios

Perspectivas para avaliar um ambiente de aprendizagem (How People Learn: Bransford, Brown, & Cocking, 1999):

• Conhecimento
• Aprendiz
• Comunidade
  
• Avaliação

TLT
Aprendizagem com simulações
Changing High Education
Teaching to Variation in Learning
The Role of Language Paradigms in Teaching Programming
Teaching Programming
Teach Programming Principles, Not "Tools and Tips"