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"

Como abstrair?

Foto: Marcus Ramos

Um dos principais processos mentais relacionados ao desenvolvimento de software é o processo de abstração. Tal processo envolve a identificação de aspectos essenciais, relevantes ao foco de interesse. Os demais aspectos são conscientemente ignorados. Muitas vezes, quando se cadastra um novo comprador em algum negócio, por exemplo, apenas alguns dos aspectos do comprador, relevantes para o negócio, são registrados. O nome do comprador, é um destes aspectos.

O resultado primário de um processo de abstração é conhecido por modelo. Um modelo representa os aspectos essenciais identificados pelo processo de abstração conduzido por um modelador. Maquetes, desenhos, rascunhos, protótipos são rotineiramente considerados categorias de modelos. No caso de software, é comum o uso da técnica de falsificação (mockup) na construção de "modelos executáveis".

Questão: como abstrair os aspectos essenciais de um modelo de software?