Francisco Viégas Vianna Thiago Elias Gomes. ShaderLabs: Desenvolvimento ágil de uma IDE para OpenGL Shaders

Francisco Viégas Vianna Thiago Elias Gomes ShaderLabs: Desenvolvimento ágil de uma IDE para OpenGL Shaders Rio de Janeiro, Brasil 29 de fevereiro de 2012

Francisco Viégas Vianna Thiago Elias Gomes ShaderLabs: Desenvolvimento ágil de uma IDE para OpenGL Shaders Monografia apresentada para obtenção do Grau de Bacharel em Ciência da Computação pela Universidade Federal do Rio de Janeiro. Orientador: Prof. PhD. Rodrigo Penteado R. de Toledo Curso de Bacharelado em Ciência da Computação Universidade Federal do Rio de Janeiro Rio de Janeiro, Brasil 29 de fevereiro de 2012

ShaderLabs: Desenvolvimento ágil de uma IDE para OpenGL Shaders Francisco Viégas Vianna Thiago Elias Gomes Projeto Final de Curso submetido ao Departamento de Ciência da Computação do Instituto de Matemática da Universidade Federal do Rio de Janeiro como parte dos requisitos necessários para obtenção do grau de Bacharel em Ciência da Computação. Autores do Trabalho: Aprovado por: Francisco Viégas Vianna Thiago Elias Gomes Prof. Ph.D. Rodrigo Penteado R. de Toledo Universidade Federal do Rio de Janeiro Orientador Prof. D.Sc. Adriana Santarosa Vivacqua Universidade Federal do Rio de Janeiro Prof. D.Sc. Marcello Goulart Teixeira Universidade Federal do Rio de Janeiro Prof. D.Sc. Paulo Roma Cavalcanti Universidade Federal do Rio de Janeiro

Resumo ShaderLabs: Desenvolvimento ágil de uma IDE para OpenGL Shaders Francisco Viégas Vianna Thiago Elias Gomes ShaderLabs é uma IDE exclusiva para codificação de OpenGL Shaders, que são os estágios programáveis da GPU (Graphics Process Unit). Com a evolução das placas de vídeo, novas funcionalidades são incorporadas e novos estágios do pipeline gráfico são liberados à programação do usuário. Porém, para acessar essas funcionalidades ou estágios programáveis, faz-se necessário produzir muitas linhas de código que tornam o aprendizado um tanto massante. O ShaderLabs permite que o usuário se concentre apenas na programação dos shaders para gerar os resultados de computação gráfica desejados. Para isso, ele se baseia em uma região de edição de código shader e uma área de renderização. Como a avaliação da execução do código é imediata, ShaderLabs funciona como um laboratório para explorar e aprender a programação de shaders. Para o desenvolvimento deste trabalho, utilizamos uma metodologia de desenvolvimento ágil adaptada à nossa realidade. O sucesso na produção deste trabalho reforça o sucesso da utilização dessas práticas que ganham cada vez mais espaço na área de TI. O ShaderLabs é um software consistente e objetivo, o qual já teve sua utilidade aprovada experimentalmente.

Abstract ShaderLabs: an IDE for the study of OpenGL shaders Francisco Viégas Vianna Thiago Elias Gomes ShaderLabs is an integrated development enviroment (IDE) exclusively for OpenGL shaders coding, which are the programmable stages of a graphics processing unit (GPU). With the constant evolution of video cards, new functionalities are being incorporated to them and new rendering pipeline stages are being made available for user programming and customization. However, in order to make real use of those new functionalities, aditional OpenGL configuration code is necessary, making the learning process slower and burocratic. ShaderLabs allows the user to worry only about the code required for generating the desired computer graphics results, for example, coding the desired shaders e running them over a polygon mesh and checking results instantly. To make this possible, ShaderLabs is based upon a shader code editing area and a rendering area. Once the results can be imediately checked, ShaderLabs works as a laboratory for shader programming learning and exploration. In this work, we have adopted some agile principles and practices. The sucess of this work reenforces the benefits of such practices, which daily gain the respect of the IT community. ShaderLabs is a consistent and simple piece of software that has been experimentaly tested and approved.

Agradecimentos Gostaríamos de agradecer primeiramente: às nossas famílias, pelo suporte incondicional e a presença indispensável nas horas mais difíceis da vida. Aos nossos amigos, velhos e novos, por partilharem conosco todas as atribulações e alegrias da universidade. Aos alunos da disciplina computação gráfica I da UFRJ do período de 2011/1, amigos e conhecidos que, pela utilização do ShaderLabs em muito nos ajudaram para amadurecer o projeto através de sugestões, críticas e elogios. Em especial, aos alunos Mariam Afonso e Marco Jardim, e a Gustavo Nunes, pelos depoimentos em anexo neste texto.

Lista de Figuras 1 A IDE ShaderLabs rodando em um sistema operacional GNU/Linux.. p. 13 2 Funcionalidades não exibidas na Figura 1................. p. 15 3 Pipeline de transformações e sistemas de coordenadas.......... p. 17 4 Frustum de visão em uma projeção em perspectiva............ p. 18 5 Redefinição da primitiva para que toda ela esteja dentro do frustum de visão...................................... p. 19 6 Hierarquia para programação gráfica.................... p. 20 7 Pipeline com shaders............................. p. 21 8 Shader Designer............................... p. 23 9 RenderMonkey................................ p. 25 10 MeShade................................... p. 26 11 WebGL Shader Lab............................. p. 27 12 ShaderMaker................................ p. 28 13 Câmera screen-based e rotação....................... p. 29 14 Câmera object-based e rotação....................... p. 29 15 Etapas do modelo Cascata de desenvolvimento.............. p. 31 16 O Manifesto Ágil.............................. p. 33 17 Quadro de acompanhamento de um projeto ágil............. p. 36 18 Gráfco Burndown.............................. p. 36 19 Gráfico de cobertura de testes....................... p. 37 20 Exemplo de cartão de história de usuário do ShaderLabs........ p. 41 21 A evolução da satisfação do cliente com novas funcionalidades...... p. 44

22 Avaliação do par de perguntas por referência cruzada........... p. 45 23 Tabulação dos resultados no Modelo Kano................. p. 46 24 Histórico da velocidade de desenvolvimento do projeto......... p. 54 25 Cumulative flow chart............................ p. 55 26 Exemplo de semanário........................... p. 56 27 Modelo de classes............................... p. 59 28 Mapeamento dos pontos da tela em pontos da esfera........... p. 60 29 Sentido da rotação do arcball quando os pontos do mapeamento estão fora do círculo................................ p. 61 30 Mapeamento dos círculos.......................... p. 61 31 Linha do tempo das funcionalidades do projeto............. p. 62 32 Resultado gerado pelo ShaderLabs de uma possível solução para um dos trabalho de Computação Gráfica I..................... p. 64 33 Resultados para o trabalho de computação gráfica gerados por diferentes alunos..................................... p. 65

Lista de Tabelas 1 Resultados iniciais da aplicação do modelo Kano............. p. 51 2 Resultados para entrevistados com pouco conhecimento em computação gráfica.................................... p. 51 3 Resultados para entrevistados com maior conhecimento em computação gráfica.................................... p. 52 4 Requisitos priorizados após o estudo realizado e suas classificações para diferentes grupos.............................. p. 52

Sumário 1 Introdução p. 12 1.1 Motivação.................................. p. 12 1.2 O que é o ShaderLabs?........................... p. 12 1.3 Estrutura deste trabalho.......................... p. 16 2 Computação gráfica e programação em GPU p. 17 2.1 Pipeline gráfico............................... p. 17 2.2 Evolução das placas de vídeo........................ p. 19 2.3 API para programação gráfica....................... p. 20 2.4 Estágios programáveis........................... p. 21 2.5 IDEs de programação gráfica........................ p. 22 2.5.1 Shader Designer........................... p. 23 2.5.2 RenderMonkey........................... p. 25 2.5.3 MeShade............................... p. 26 2.5.4 WebGL Shader Lab......................... p. 27 2.5.5 ShaderMaker............................ p. 27 2.6 Modelos de manipulação de câmera.................... p. 28 3 Desenvolvimento ágil p. 30 3.1 Modelo de Desenvolvimento Ágil..................... p. 30 3.1.1 O Manifesto Ágil.......................... p. 32 3.1.2 Gestão de um projeto ágil de software.............. p. 34

3.1.3 Práticas de desenvolvimento mais utilizadas........... p. 37 3.2 Requisitos Ágeis - Product Backlog.................... p. 39 3.2.1 Histórias de usuário......................... p. 40 3.2.2 Pontos de história e priorização.................. p. 41 3.2.3 Minimun Valuable Product (MVP)................ p. 42 3.3 O modelo Kano de satisfação do cliente.................. p. 43 3.3.1 Introdução.............................. p. 43 3.3.2 O Método Kano aplicado a requisitos de software........ p. 44 4 Desenvolvimento do ShaderLabs p. 47 4.1 Aplicação da metodologia ágil....................... p. 47 4.1.1 Perfis de usuário.......................... p. 47 4.1.2 MVP e usabilidade do ShaderLabs................ p. 48 4.1.3 Aplicação do modelo Kano..................... p. 49 4.1.4 Andamento do projeto....................... p. 53 4.1.5 Evolução do ShaderLabs...................... p. 57 4.2 Implementação............................... p. 57 4.2.1 Tecnologias utilizadas e documentação técnica.......... p. 58 4.2.2 Modelo de manipulação de câmera................ p. 60 5 Estudo de Caso - o trabalho na disciplina Computação Gráfica I p. 63 6 Conclusões e trabalhos futuros p. 66 6.1 Conclusões.................................. p. 66 6.2 Trabalhos Futuros.............................. p. 66 6.2.1 Novas funcionalidades....................... p. 66 6.2.2 Tutorial de GLSL.......................... p. 68 6.2.3 Divulgação externa......................... p. 68

Referências p. 69 Anexo A -- Descrição completa do trabalho de computação gráfica p. 71 Anexo B -- Depoimentos sobre a utilização para produção do trabalho de computação gráfica p. 72 B.1 Gustavo Nunes............................... p. 72 B.2 Marco Elisio Oliveira Jardim........................ p. 72 B.3 Mariam Afonso............................... p. 73

12 1 Introdução 1.1 Motivação A motivação para este trabalho nasceu da vontade de produzir uma ferramenta que fornecesse aos alunos iniciantes em computação gráfica um suporte ao aprendizado. A idéia inicial era ajudar na solidificação dos conhecimentos teóricos fornecidos em sala e motivar a descoberta de outros detalhes que nem sempre são abordados. A proposta foi criar uma IDE em que o aluno não precisasse se preocupar com a programação em CPU (C++ por exemplo), e sim apenas com a programação em GPU (shaders). Assim o aluno observaria, instataneamente, o resultado de uma possível alteração de configuração, sendo esse rápido feedback um grande acelerador do seu aprendizado. Primeiramente pensamos em estender um software similar, o Shader Designer, porém preferimos iniciar um projeto novo. Adicionalmente, a idéia deste projeto é a de disponibilizar uma ferramenta 100% gratuita, de código aberto, multi-plataforma e suficientemente bem implementada para que possa ser estendida futuramente caso necessário. 1.2 O que é o ShaderLabs? O ShaderLabs é uma IDE simples que provê as principais funcionalidades para o aprendizado de programação em shaders. Nela um usuário pode fazer seus experimentos com shader e verificar o resultado instantaneamente. Essa ferramenta foi desenvolvida para facilitar o aprendizado e sua interface gráfica foi pensada para que fosse o mais simples e objetiva possível. A Figura 1 mostra uma configuração onde a maioria das funcionalidades descritas abaixo estão visíveis. No momento da produção deste texto, o ShaderLabs contava com as seguintes funcionalidades: Programação de shaders: é possível programar os estágios vertex, geometry e frag-

1.2 O que é o ShaderLabs? 13 Figura 1: A IDE ShaderLabs rodando em um sistema operacional GNU/Linux. ment shader. Controle de arquivos: com o ShaderLabs é possível executar as principais operações sobre arquivos de que se necessita, como: Abrir arquivo existente, com diálogo de busca; Abrir novo arquivo; Salvar como, com diálogo de busca; Salvar arquivo já existente. Gerência de projeto: o ShaderLabs possui uma forma de facilitar a abertura e salvamento dos shaders utilizando metadados de projeto. Essa funcionalidade serve basicamente para abrir e salvar múltiplos shaders simultaneamente. As funcionalidades para gerenciar projetos são: Abrir arquivo, com diálogo de busca; Salvar como, com diálogo de busca;

1.2 O que é o ShaderLabs? 14 Salvar projeto já existente. Controle de abas: para cada shader aberto existe uma aba de código associada (na Figura 1 pode-se ver 3 abas abertas: brick.vert, brick.frag e new_geometry). Essas abas podem ser reordenadas ou ter seu código bloqueado para execução, além de mostrarem visualmente quando um código não foi salvo (com * ) ou quando este está bloqueado para execução (ícone vermelho na aba associada). Execução do shader: para visualizar o resultado de um código shader, basta executá-lo e o resultado será mostrado instataneamente (botão Play na interface). Área visualização: é uma área onde a cena, ou contexto OpenGL, é renderizada (na figura 1, a Render Area contém uma esfera). Essa área é responsável por mostrar o resultado da execução dos shaders. Ela pode ser fechada, reaberta, destacada da IDE e redimensionada. Rotação: utilizando uma forma simples com clique e arrasto do mouse, é possível rotacionar o modelo que está carregado, baseado no arcball (vide seção 2.6). De forma semelhante, também é possível rotacionar a iluminação direcional que atua sobre esse modelo, selecionando-se a opção Light Rotation na Render Area. Área de saída: (Figura 1) região de saída de texto onde as mensagens do programa e o log de compilação e linkedição dos shaders é mostrada na parte inferior. Essa região pode ser fechada e reaberta quando necessário. Gerência de múltiplas texturas: (área esquerda da Figura 1 - Texture Properties) muitos efeitos utilizam texturas como container de dados. Com o ShaderLabs é possível carregá-las, removê-las do gerenciador, ou substituir a textura corrente. Cada textura possui um nome de variável associado, mostrado na interface, que pode ser utilizado para acessar essa textura via código. Modelos pré-definidos: um código shader só faz sentido se for aplicado a um modelo. O ShaderLabs possui 4 modelos pré-definidos que são: Esfera com aproximadamente 2500 vértices Plano com aproximadamente 2500 vértices Esfera com aproximadamente 250000 vértices Plano com aproximadamente 250000 vértices

1.2 O que é o ShaderLabs? 15 (a) Modelo wireframe e preenchido (b) Detecção dos shaders suportados Figura 2: Funcionalidades não exibidas na Figura 1. Busca textual: para buscar uma palavra ou pequeno texto dentro de um código, o ShaderLabs conta com um simples buscador acoplado a interface (acionado pelo atalho Ctrl + F ) que provê uma busca textual em dois sentidos. Sintax Highlighting: este é um recurso sempre presente em IDEs, pois facilita a localização de estruturas no código fonte, além de colorir palavras reservadas, tipos de variáveis entre outros. No ShaderLabs esse recurso ainda auxilia o programador marcando variáveis e funções globais disponibilizadas pela OpenGL. Wireframe: (Figura 2a) Um recurso muito útil para o desenvolvedor em computação gráfica é a visualização das arestas do modelo. Utilizando uma tecla de atalho ( Ctrl + W ) ou navegando pelo menu, é possível trocar entre a forma de renderização em wireframe e preenchida. Auto-adaptação à placa de vídeo: o ShaderLabs avalia no momento da inicialização, quais os shaders estão disponíveis pelo hardware gráfico, habilitando apenas os recursos suportados. Caso algum recurso não esteja disponível, uma mensagem é mostrada para o conhecimento do usuário e as funcionalidades referentes desabilitadas (Figura 2b). O ShaderLabs é um software gratuito e de código aberto sob uma licensa GPL 1. O código fonte ficará disponível por tempo indeterminado na url http://code.google.com/ p/shader-lab/. 1 GNU General Public License. Sua descrição pode ser vista em http://www.gnu.org/licenses/ gpl.html

1.3 Estrutura deste trabalho 16 1.3 Estrutura deste trabalho Este trabalho é dividido em partes que representam os principais conteúdos relacionados à sua execução. São elas: Capítulo 2, Computação gráfica e programação em GPU: esse capítulo descreve alguns conceitos teóricos sobre computação gráfica e programação em GPU, necessários para o entendimento do objetivo do ShaderLabs. Além disso, são avaliados alguns softwares similares; Capítulo 3, Desenvolvimento ágil: esse capítulo aborda aspectos gerais sobre desenvolvimento ágil, que foi o modelo utilizado durante o desenvolvimento desse projeto; Capítulo 4, Desenvolvimento do ShaderLabs: esse capítulo descreve todo o processo de desenvolvimento, bem como aspectos de implementação; Capítulo 5, Estudo de caso - o trabalho na disciplina computação gráfica I: esse capítulo mostra a experiência de utilização do ShaderLabs pelos alunos de computação gráfica do curso de ciência da computação da Universidade Federal do Rio de Janeiro; Capítulo 6, Conclusões: esse capítulo descreve as conclusões sobre este trabalho e possíveis trabalhos futuros.

17 2 Computação gráfica e programação em GPU 2.1 Pipeline gráfico Para que uma geometria passada da aplicação para a placa de vídeo seja renderizada, ela percorre um pipeline de transformações e em cada estágio trabalha-se com um determinado sistema de coordenadas, ou até mesmo transformando um sistema em outro. Uma forma de apresentar o pipeline visto em (DURAND; CUTLER, 2003) pode ser observada na Figura 3. Essa é uma abordagem simples, pois os diversos fabricantes podem implementá-lo de formas diferentes. Detalhes sobre esse processo podem ser vistos em uma forma mais técnica, com OpenGL, no livro (BOARD et al., 2007). Posicionamento Iluminação Visão Corte Projeção Rasterização Visualização Coordenada de Mundo/Câmera Coordenada de Corte Coordenada de Tela Figura 3: Pipeline de transformações e sistemas de coordenadas. Normalmente os modelos a serem renderizados possuem seus vértices definidos em coordenadas de modelo, que está normalmente centrado na origem. Como podemos observar na Figura 3, o primeiro estágio do pipeline é o posicionamento, onde os vértices do modelo são transformados para coordenada de mundo, isto é, o modelo é posicionado no mundo. Logo depois a origem do mundo é transformado para a origem do sistema de coordenadas de câmera. Essa passagem coordenada de modelo coordenada de

2.1 Pipeline gráfico 18 mundo coordenada de câmera normalmente é feita em sequência. Por isso a Figura 3 mostra o sistema de coordenada como mundo/câmera. Atualmente, as propriedades de um modelo são configuradas pelos seus vértices. Assim, cada vértice pode conter informações como cor, normal e coordenada de textura. No estágio de iluminação, a cor de cada vértice é ajustada para se adequar a iluminação levando em consideração a sua posição, a posição das fontes de luz e a normal, entre outras coisas. Caso a forma de projeção seja em perspectiva, o frustum de visão forma um tronco de pirâmide como visto na Figura 4. Na próxima etapa, o mundo é distorcido de forma que as paredes desse frustum tornem-se paralelas. Na projeção ortogonal essas paredes já são paralelas. Além disso, o mundo é transformado novamente, passando para o sistema de coordenas de corte, onde as coordenadas internas ao paralelogramo formado pelo frustum estão entre [ 1, 1] 3. Frustum de Visão câmera Figura 4: Frustum de visão em uma projeção em perspectiva. Na etapa de corte, as primitivas que estão totalmente fora desse cubo de visão são descartadas. Porém, em alguns casos, a primitiva pode ficar parcialmente dentro do cubo, como na Figura 5a, e nesses casos a primitiva deverá ser recortada. Fazendo essa modificação na primitiva, ela fica inteira dentro do cubo de visão como na Figura 5b. Na projeção, passamos a trabalhar com o espaço de tela que é o espaço discretizado do tamanho do framebuffer. Assim a placa de vídeo projeta o valor (x,y) de cada vértice da coordenada no cubo de visão para uma coordenada (x,y) discreta na tela. No final da projeção tem-se as primitivas com seus vértices onde seus valores (x,y) estão em coordenadas de tela e um valor z no intervalo [ 1, 1]. Como os vértices já estão projetados, a próxima etapa é para preencher a primitiva. Para isso, todos os atributos de cada vértice serão interpolados em cada fragmento que

2.2 Evolução das placas de vídeo 19 (a) Antes do recorte (b) Depois do recorte Figura 5: Redefinição da primitiva para que toda ela esteja dentro do frustum de visão. corresponde a um pixel do framebuffer. Além disso, a profundidade z também é interpolada e armazenada no z-buffer. Esse processo é chamado de rasterização. Em cada fragmento interpolado, toma-se a decisão de pintar ou não o pixel correspondente avaliando a profundidade z. Caso a profundidade do fragmento que está no framebuffer seja maior que a do fragmento que está sendo avaliado, este último será o utilizado, atualizando os valores de cor no framebuffer e de pronfundidade no z-buffer. Caso contrário, o fragmento é descartado. Após o término do processo anterior para todas as primitivas, a cena completa está renderizada no framebuffer que finalmente fica disponível para ser exibido na tela. 2.2 Evolução das placas de vídeo Inicialmente as placas gráficas eram responsáveis por somente mostrar no monitor os dados encontrados na memória de vídeo, ficando a cargo do processador fazer todos os cálculos necessários para obtenção da imagem. Hoje, além de sua principal utilização em jogos 3D, as GPU (Graphics Processing Unit) são ferramentas utilizadas em diversas pesquisas científicas. Todos os cálculos para renderizar uma cena, seguindo o pipeline visto na Seção 2.1, são disponibilizados nas chamadas funções fixas. Recentemente estão sendo incorporadas áreas de programação onde o desenvolvedor pode substituir as funções fixas por suas próprias rotinas, dando assim maior liberdade ao programador para criar efeitos mais interessantes, usufruindo do poder de processamento paralelo da GPU e de suas otimizações em nível de hardware. Essas áreas programáveis são chamadas de shaders (esse nome também refere-se ao próprio código que rodará nessas áreas).

2.3 API para programação gráfica 20 Uma outra vertente para o uso do poder de processamento das GPUs é a utilização dos mesmos para processamento genérico, onde a arquitetura mais conhecida é a CUDA (Compute Unified Device Architecture) da NVIDIA. 2.3 API para programação gráfica Em (WEI, 2005), é visto que para fazer a passagem da cena para placa gráfica, uma aplicação deve utilizar uma API (Application Program Interface) independente de hardware. Essa API fará a interface entre a aplicação e o drive específico da placa de vídeo, como pode ser visto na Figura 6. Atualmente as APIs mais difundidas são a OpenGL (Open Graphics Library) e a Direct3D (que é parte da API DirectX da Microsoft). Aplicação API Driver Gráfico Hardware Gráfico Figura 6: Hierarquia para programação gráfica. A OpenGL é uma API multiplataforma de código aberto que baseia-se em primitivas (pontos, linhas, triângulos, quadriláteros, etc) e não possui comandos de alto nível para tratar modelos. Esta API funciona como uma máquina de estados, assim é possível configurar variáveis e, dependendo do estado, o valor depositado nelas pode ser consultado. Por exemplo, deseja-se configurar uma mesma cor para uma série de vértices. Para isso, basta configurar essa cor antes de passar os vértices. Dessa forma, quando cada vértice for processado, a máquina consultará a cor corrente configurando o vértice da forma correta. Essa máquina de estados é conhecida como pipeline gráfico e pode ser vista de uma forma mais aprofundada na Seção 2.1. A Direct3D é a API mais utilizada na indústria de jogos para PC, porém não possui código aberto e nem é multiplataforma, sendo utilizada somente em sistemas Microsoft Windows.

2.4 Estágios programáveis 21 2.4 Estágios programáveis Os shaders são estágios programáveis do pipeline gráfico. Hoje existem 5 estágios programáveis que podem ser vistos em cinza escuro na Figura 7. Quando um shader está habilidado, as funções fixas correspondentes são desabilitadas, ficando a cargo do programador, via código shader, fazer os cálculos necessários. Vertex Shader Tessellation Control Shader Tessellator Tessellation Evaluation Shader Geometry Shader Corte Rasterização Fragment Shader Visualização Figura 7: Pipeline com shaders. O Vertex Shader é o estágio responsável por fazer o processamento dos vértices. Esse estágio processa um vértice de cada vez, sem conhecer a vizinhança ou tipo de primitiva. Ele recebe como entrada todos os atributos dos vértices e deve calcular sua posição já na coordenada de corte e possivelmente sua cor, fazendo os cálculos de iluminação. Esse estágio substitui os estágios de posicionamento, iluminação e visão como descritos na Seção 2.1. O Tessellation Control Shader e o Tessellation Evaluation Shader são os estágios responsáveis por fazer a tesselagem de uma primitiva, podendo criar milhares de novos triângulos dentro de cada uma. Utilizando-se esses estágios aliados a outros recursos, é possível, por exemplo, aumentar o nível de detalhe de um terreno dinamicamente (VAL- DETARO et al., 2010). O Geometry Shader é responsável por processar as primitivas individualmente. Nele, é possível reconfigurá-las e até gerar novas primitivas, num processo conhecido como extrusão.

2.5 IDEs de programação gráfica 22 O Fragment Shader é responsável por calcular a cor de um fragmento. Esse estágio recebe como entrada um fragmento de uma primitiva com todos os atributos de seus vértices já interpolados. Não é possível alterar sua posição (x,y), mas sim sua cor e profundidade. Para programar algum desses estágios é necessário utilizar uma das linguagens de programação disponíveis. Todas são muito parecidas entre si e de alto nível, baseadas na liguagem de programação C. Abaixo está uma breve descrição das principais: Cg (C for graphics): liguagem desenvolvida pela NVIDIA em parceiria com a Microsoft. É uma liguagem multiplataforma, mas dependente do hardware daquela empresa. HLSL (High Level Shader Language): liguagem independente de hardware desenvolvida pela Microsoft. Essa linguagem faz parte da API DirectX que somente trabalha em sistemas Windows. GLSL (OpenGL Shading Language): liguagem multiplataforma e independete de hardware, desenvolvida para trabalhar com a API OpenGL. A descrição completa dessa linguagem e diversos exemplos de utilização do vertex, geometry e fragment shader podem ser encontrados em (ROST et al., 2009). 2.5 IDEs de programação gráfica É importante esclarecer que, para visualizar um efeito obtido com um código shader sem utilizar uma IDE específica, é necessário: Escrever uma aplicação em alguma linguagem de programação; Utilizar uma API para programação gráfica; Preocupar-se com o carregamento de um modelo (malha de triângulos); Escrever o shader e passá-lo como parâmetro; Preocupar-se com detalhes como a posição e rotação do objeto ou iluminação para uma boa avaliação do resultado. Utilizando uma IDE para programação de shaders, o programador necessita somente se preocupar em escrever seu código. Dessa forma, percebe-se a importância desse tipo

2.5 IDEs de programação gráfica 23 de software para quem necessita testar, aprender ou avaliar algorítimos de computação gráfica. A seguir serão apresentadas algumas IDE similares ao ShaderLabs. 2.5.1 Shader Designer Fonte: http://www.opengl.org/sdk/tools/shaderdesigner/brics.jpg Figura 8: Shader Designer. O Shader Designer é uma IDE para programação e teste de shaders OpenGL. Ele foi desenvolvido pela Typhoon Labs até 2004 e atualmente é um projeto praticamente descontinuado, contando apenas com pequenas correções de bugs que surgem eventualmente. Ele e seu código-fonte estão disponíveis gratuitamente sob uma licensa LGPL na internet. Apesar disso, não há proposta de desenvolvimento de novas funcionalidades previstas, bem como não há ninguém na comunidade open source que tenha adotado o projeto. Apesar de trabalhar com apenas dois dos cinco shaders, o Shader Designer é um software razoavelmente completo em suas outras funcionalidades. Sua última versão disponível conta com funcionalidades como: Suporte a vextex shaders e fragmet shaders; Área de renderização de resultados; Gerenciamento de múltiplas texturas;

2.5 IDEs de programação gráfica 24 Configuração de parâmetros OpenGL relativos à iluminação, vertex e fragment shaders, perspectiva e ambiete; Passagem de variáveis para shaders; Marcação de sintaxe e auto-completar para código GLSL; Exportação de malhas compatíveis com o padrão 3D Studio Max 5.0; Modelos padrão disponíveis para teste (esfera, teapot, etc.); Visualização de malhas customizadas utilizando padrões conhecidos; Metadados de projetos. Apesar das muitas funcionalidades disponíveis, o Shader Designer, graças ao fato de não continuar sendo estendido ao longo do tempo, ficou desatualizado em relação às capacidades introduzidas pelas novas placas de vídeo que chegaram ao mercado nos últimos anos. Novos tipos de shaders foram criados, aumentando a eficiência do processamento gráfico. O Shader Designer não é multi-platforma, apesar de uma versão do programa ter sido portada para a plataforma GNU/Linux como uma versão Beta. Como já foi dito, inicialmente tentamos dar continuidade ao projeto Shader Designer, já que seu código fonte estava disponível na internet e ele parecia ser bem completo. Idealmente, habilitaríamos essa IDE para trabalhar com os shaders restantes (geometry, tessellation control e tessellation evaluation). Chegamos a entrar em contato com o desenvolvedor do projeto que ficou feliz por nossa iniciativa, porém alguns problemas listados a seguir inviabilizaram a continuidade dessa idéia. O Shader Designer foi desenvolvido em cima do framework.net, na versão 1.1 - a versão mais atual é a 4. O projeto em si está 100% baseado na IDE Visual Studio 2003, da Microsoft. Tentamos portá-lo para uma versão mais atual, mas nem o próprio desenvolvedor conseguiu fazer isso. Mesmo que conseguíssemos, o.net não é um framework multiplataforma e era o nosso desejo que essa ferramenta fosse portável para os principais sistemas operacionais. Além disso, seu componente de marcação de sintaxe é proprietário e foi descontinuado. Por causa de todos esses problemas, procuramos iniciar um projeto novo para que esse se adequasse aos nosso ideais.

2.5 IDEs de programação gráfica 25 Fonte: http://developer.amd.com/gpu_images/fullscreen-hebe_lrg.jpg Figura 9: RenderMonkey. 2.5.2 RenderMonkey O RenderMonkey é uma IDE poderosa desenvolvida pela AMD para a criação de efeitos visuais usando shaders, permitindo o trabalho tanto de programadores quanto de artistas. Seu modo de trabalho é baseado em cena, o que permite a inclusão de diversos objetos e efeitos organizados hierarquicamente como nós em uma árvore, utilizando o conceito de grafo de cena. O RenderMonkey suporta somente o DirectX 9.1 e OpenGL 2.0, pois não é mais mantido pela AMD e, como é um projeto proprietário, não foi continuado. Apesar disso, a AMD disponibilizou o RenderMonkey SDK, uma biblioteca extremamente flexível para criação de plugins para o software. Tanto o RenderMonkey quanto o RenderMonkey SDK estão disponíveis na internet gratuitamente, mas não possuem código aberto. O RenderMonkey possui uma extensa variedade de funcionalidades e por isso atentaremos somente para as principais: Suporte a DirectX 9.1 e OpenGL 2.0; Área de renderização dos resultados; Gerenciamento de multiplos modelos e efeitos;

2.5 IDEs de programação gráfica 26 Gerencimanto de código shader, textura, malha e outras características para cada modelo; Carregamento de malha (obj, 3ds,...); Vários editores customizados para trabalhar com HLSL e GLSL; Metadados de projetos; Passagem de parâmetros especiais como tempo e ação do mouse; SDK para desenvolvimento das suas próprias funcionalidades. O RenderMonkey só suporta o vertex e fragment Shader e sua enorme flexibilidade na construção de cenas cria uma certa complexidade de uso. Ele também não é multiplataforma, sendo distribuido somente para Windows. 2.5.3 MeShade Fonte: http://spidergl.org/img/meshade1.png Figura 10: MeShade. O MeShade é uma ferramenta web para teste e experimentação de shaders. A proposta dessa ferramenta é somente servir como exemplo de utilização de uma biblioteca gráfica JavaScript para renderização 3D em tempo real na Web SpiderGL. Por conta de já ter atigindo seu objetivo, o MeShade não possui um projeto de continuação. Seu código fonte está disponível, mas é necessário um servidor HTTP para rodá-lo localmente.

2.5 IDEs de programação gráfica 27 Nele é possível carregar uma malha no formato obj, editar os códigos vertex e fragment shader, visualizar o resultado da renderização e o log de compilação e gerar um código HTML para fazer a visualização do resultado fora do editor. Porém não é possível carregar texturas e o código shader é exclusivo para o SpiderGL. 2.5.4 WebGL Shader Lab Fonte: http://codedstructure.net/projects/webgl_shader_lab/ Figura 11: WebGL Shader Lab. O Shader Lab da codedstructure.net é um editor de shaders online feito sobre WebGL 1. É uma ferramenta bastante simples que ainda está em desenvolvimento e nele somente é possível editar um código vertex e fragment shader próprio e somente é possível trabalhar com geometrias definidas manualmente. A Figura 11 mostra a aparência aproximada do programa. 2.5.5 ShaderMaker O ShaderMaker é um editor de código GLSL multiplataforma, que funciona em Linux, Windows e Mac OS. De todos os concorrentes, esse é o que mais se aproxima dos objetivos que o ShaderLabs deseja alcançar, pois, além de ser simples, multiplataforma e trabalhar com GLSL, ele também possui seu código fonte aberto. Entre as principais funcionalidades, destacam-se um editor de código com syntax highlighting, onde é possível escrever para vertex, fragment e geometry shaders. Além da 1 API que estende as funcionalidades de JavaScript, permitindo gerar gráficos 3D interativos na web.

2.6 Modelos de manipulação de câmera 28 Fonte: http://cg.in.tu-clausthal.de/teaching/shader_maker/sm3.png Figura 12: ShaderMaker possibilidade de editar os parâmetros de fonte de luz e variáveis uniformes. Apesar de ser um ótimo editor de GLSL ele também não provê a possibilidade de escrever o tesselation control shader e o tesselation evaluation shader. Ele também não permite o bloqueio da execução de um shader específico para fins de experimentação. 2.6 Modelos de manipulação de câmera Neste trabalho, a manipulação do modelo de visualização de câmera é crucial para percepção dos resultados dos programas que estão sendo executados sobre um determinado objeto carregado. Ela permite que o objeto seja visto por todos os ângulos que se deseje. Naturalmente, são muitas as formas de se fazer esse tipo de processamento, cada uma apresentando diferentes características, vantagens e desvantagens. Em (CASTIER B.; MARTHA, 1994), é apresentada uma taxonomia que auxilia o entendimento das manipulações interativas de visualização de objetos 3D possíveis de serem realizadas. No contexto deste trabalho, descreveremos os modelos que utilizam referencial de movimento screen-based e object-based. Foram estudados então, dois modelos com estas características: O modelo de esfera virtual (CHEN; MOUNTFORD; SELLEN, 1988) e o arcball (SHOEMAKE, 1992). esfera virtual: de acordo com o artigo, ele é classificado como screen-based porque

2.6 Modelos de manipulação de câmera 29 Ponto de referência Eixo de Visualização (a) Câmera screen-based (b) Rotação Figura 13: Câmera screen-based e rotação. faz todas as suas movimentações em torno dos seus próprios eixos de coordenadas. Ele possui uma esfera virtual, onde o centro da esfera é o ponto de refêrencia da câmera e o raio é a distancia entre o ponto de referência e a posição da câmera. Dessa forma, as movimentações de rotação são feitas em torno dessa esfera virtual. Além disso, uma outra rotação pode ser aplicada em torno do eixo de visualização. A definição do modelo e o processo de rotação podem ser vistos nas Figuras 13a e 13b respectivamente. arcball: é um modelo que atua nos eixos do objeto em vez da câmera. A esfera envolvente fica em torno do objeto visualizado e não mais do ponto de referência da câmera (ver Figura 14). A movimentação é feita através de um mapeamento do arrasto do mouse para um arco sobre essa esfera envolvente. Definido o arco que representa o movimento a ser feito sobre a esfera, nota-se que a composição de movimentos nesse modelo pode ser dada pela resultante dos arcos descritos e que, dessa forma, qualquer sequência de movimentos que retorne ao ponto inicial representa um arco nulo. Isso faz com que o arcball não tenha histerese mudança de posição de um objeto quando o mouse retorna a sua posição inicial. De posse de um determinado arco e com cálculos matemáticos adequados, obtém-se o ângulo de rotação do objeto. Ponto de referência Ponto de referência Figura 14: Câmera object-based e rotação.

30 3 Desenvolvimento ágil 3.1 Modelo de Desenvolvimento Ágil Embora a consolidação dos métodos ágeis enquanto um conjunto de práticas bem definido e aplicável date do final dos anos 90, os princípios que regem sua forma de conduzir projetos de desenvolvimento de software (PDS) começaram a ser elaborados alguns anos antes (BECK, 1996). Eles surgiram como uma alternativa às antigas práticas de desenvolvimento que eram em geral utilizadas até então pela indústria de software. Estima-se que cerca de 68% dos PDS falhem (GROUP, 2009). Entende-se por projetos que falham aqueles que funcionam, mas são entregue sem atender ou custo ou esforço envolvido ou com o escopo parcial (44%), além daqueles que são cancelados durante o desenvolvimento ou que não são utilizados depois de prontos (24%). Para entendermos um pouco melhor a problemática envolvida em algumas metodologias clássicas de desenvolvimento, tomemos o exemplo do médodo conhecido como Cascata, um dos mais utilizados até os dias de hoje 1. As etapas do método Cascata podem ser resumidas, de forma simplificada, através da figura 15, que demonstra o fluxo que rege o PDS. É importante notar que uma etapa só se inicia após o término da anterior. seja, primeiramente todos os requisitos e funcionalidades do software a ser desenvolvido são relacionados e minunciosamente descritos. Passada essa fase, inicia-se o processo de planejamento, com a elaboração de diversos diagramas e modelagens - de classe, UML, de sequência, casos de uso, entre outros - que darão todo o suporte necessário à equipe de desenvolvimento. Após essa fase de planejamento teórico é que o desevolvimento se inicia de fato. Somente ao final da etapa de desenvolvimento o software é verificado, para que se certifique que este está de acordo com as especificações. Finalmente, uma vez conferido, 1 Tomamos o modelo em cascata como exemplo porque, embora haja outras alternativas de metodologias clássicas mais eficientes, todas elas partilham do mesmo problema: planejamento inicial excessivo. Sendo assim, foi escolhida aquela que melhor elucidaria os pontos de vista que queremos demonstrar. Ou

3.1 Modelo de Desenvolvimento Ágil 31 fonte: http://pt.wikipedia.org/wiki/ficheiro:modelo_em_cascata.png Figura 15: Etapas do modelo Cascata de desenvolvimento o software entra na etapa de manutenção, onde eventuais correções necessárias são feitas. Para entendermos mais profundamente o que acontece com esse tipo de desenvolvimento, avaliemos algumas das características de um PDS: Custo: valor estipulado previamente referente ao valor monetário que será gasto na produção do software. Prazo: tempo decorrido do início até a entrega final do software, com todas as funcionalidades previstas. Escopo: conjunto de funcionalidades definidas para serem implementadas. Qualidade: quão bem, em termos técnicos, o software foi desenvolvido. Na utilização de um modelo clássico para a implementação de um PDS, o que geralmente ocorre é que custos e escopo são previamente acordados e permanecem fixos durante toda a produção do software, pois representam quanto alguém está disposto a pagar por um determinado conjunto de funcionalidades. Uma vez que um projeto falha, temos duas situações decorrentes possíves (ou ambas ocorrendo simultaneamente): O prazo de entrega é prorrogado: como não houve tempo hábil suficiente para implementar até a última funcionalidade requerida, os prazos são postergados, ge-

3.1 Modelo de Desenvolvimento Ágil 32 ralmente causando atrasos incômodos. Muitas vezes existem estratégias de mercado associadas a um software, e tempo pode ser um fator crucial nesses casos. A qualidade do software produzido é prejudicada: num esforço para se manter dentro do prazo de entrega, a equipe de desenvolvimento acelera seu ritmo, aumentando as chances de introduzir bugs no sistema e prezando menos por boas práticas e consistência na hora de escrever o código. Isso acontece porque metodologias clássicas por vezes não levam em consideração a complexidade inerente ao processo de desenvolver um software. Existem inúmeros problemas que podem ocorrer entre o início e o fim do desenvolvimento de um projeto. Um caso comum é quando o cliente, aquele que está pagando pelo software, deseja fazer mudanças no escopo do projeto, retirando algumas funcionalidades que já não lhe parecem tão úteis, e adicionando outras, sobre as quais ele não havia previamente pensado. Infelizmente, do ponto de vista técnico, essas alterações nem sempre são simples de serem feitas, frequentemente causando grandes impactos na arquitetura do software. Eventualmente, devido a forma como o software está arquitetado, nem mesmo é possível implementar tais funcionalidades. Somando-se a isso, estatísticas geradas pelo Standish Group em 2002 (JOHNSON, 2002) dizem que cerca de 45% das funcionalidades presentes em um software em geral nunca são utilizadas, e outros 19% raramente são utilizadas (referência). Ou seja, cerca de 64% do produto final praticamente não agrega nenhum valor e poderia deixar de ser desenvolvido sem maiores problemas. A pior constatação é a de que, na verdade, os prazos e os custos extras direcionados ao projeto foram causados por essas funcionalidades dispensáveis. 3.1.1 O Manifesto Ágil No ano de 2001, dezessete desenvolvedores de software já envolvidos com novas práticas que visavam diminuir esses problemas se reuníram para discutir sobre as novas metodologias de desenvolvimento de software que surgiam, fornecendo alternativas às opções até então orientadas a documentação 2. O resultado desse encontro foi o Manifesto Ágil (HIGHSMITH; FOWLER, 2001), que define as pricipais premissas pelas quais uma metologia ágil de desenvolvimento deve zelar. Segue a tradução para o português, fornecida na página oficial, exibida na figura 16: Manifesto para Desenvolvimento Ágil de Software 2 quando a produção do software é conduzida pela documentação previamente criada.

3.1 Modelo de Desenvolvimento Ágil 33 fonte: http://www.agilemanifesto.org/ Figura 16: O Manifesto Ágil Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda. Uma breve explicação sobre os itens citados no manifesto se faz necessária: Indivíduos e interações mais que processos e ferramentas: Traz o foco do desenvolvimento do software para o elemento humano. Talvez a mudança mais importante de paradigma: compreender que são pessoas que estão por trás da produção do software e que, por consequência, esta está sujeita à problemática daqueles. É o entendimento também de que ferramentas são úteis, mas que o principal ativo do desenvolvimento de um software são as pessoas que dão vida a ele. Software em funcionamento mais que documentação abrangente: O foco inicial do desenvolvimento deve ser o funcionamento de acordo com as expectativas do cliente. Com essa postura, além da maior satisfação do cliente com os resultados, economizase todo o tempo gasto com planejamentos e documentações, que na maioria das vezes

3.1 Modelo de Desenvolvimento Ágil 34 não serão utilizadas após o final do projeto. Colaboração com o cliente mais que negociação de contratos: Em vez de definir contratualmente todos os aspectos do software a ser desenvolvido e mantê-lo afastado até a entrega final do produto, propõe fazer do cliente parte integrante de todo o processo de aprovação dos resultados, sempre que possível. Desta forma, ele não fica sujeito ao resultado de um processo que ele não acompanhou. Responder a mudanças mais que seguir um plano: Compreender que nem sempre é possível estabelecer à priori o que se deseja de um software, em termos de funcionalidade, e que ao longo do tempo as prioridades podem mudar. Estando-se pronto para responder a essas mudanças é mais fácil atingir os objetivos de um produto final. Naturalmente, esse novo paradigma exige mudanças nas práticas utilizadas no desenvolvimento de software. Citaremos nas seções que se seguem algumas delas, que em nosso entendimento carregam a maior parte desses valores e que permitem, em boa parte dos casos, obter melhores resultados. 3.1.2 Gestão de um projeto ágil de software Simplicidade é a capacidade de maximizar a quantidade de esforço evitado. É um dos valores mais importantes das metodologias ágeis. O que se espera quando do início de um projeto de software é que o cliente apresente um conceito, uma idéia, a qual ele deseja transformar em produto. Em geral, ele trará uma quantidade imensa de sugestões de funcionalidades, sempre pensando em maximizar a quantidade de opções e serviços que ele poderá disponibilizar para os usuários finais do seu produto. 3.1.2.1 Simplicidade: priorização e iterações curtas Em um modelo ágil, este conjunto de funcionalidades está sempre sendo revisto pelo cliente. O que se propõe é que todas as funcionalidades sejam listadas e priorizadas, por ordem de valor agregado para o produto, considerando-se esforços e investimentos feitos - o chamado Return of Investiment (ROI). A cada iteração 3, as funcionalidades restantes devem ser reavaliadas e repriorizadas. Com este procedimento simples, o cliente 3 Intervalo de tempo para o qual se define um pequeno subconjunto das funcionalidades para ser implementado.

3.1 Modelo de Desenvolvimento Ágil 35 ganha confiabilidade, pois está participando frequentemente da avaliação dos resultados em vez de ter que verificar se tudo está como ele gostaria ao final do desenvolvimento. Simultaneamente, ele ganha a capacidade de adicionar ou remover funcionalidades da lista inicial criada por ele com um mínimo impacto para o time de desenvolvimento, o que permite que o produto final fique o mais próximo possível de suas expectativas. Além disso o processo de priorização impede o tipo de desperdício citado na seção 3.1, que diz respeito à utilidade de funcionalidades implementadas. Reduz-se as chances de desenvolver funcionalidades que absolutamente não serão usadas ou que raramente o serão. Com as iterações curtas e escopos bem definidos para cada uma delas, as chandes de perder prazos de entrega também fica bastante reduzida. 3.1.2.2 Visibilidade: uma medida da comunicação Em metodologias ágeis de desenvolvimento, a comunicação é um fator crucial (SCHWA- BER; BEEDLE, 2001), em todas as suas escalas. Um time precisa estabelecer uma comunicação interna de foma eficiente, para que seja possível identificar problemas o mais rapidamente possível e corrigí-los o quanto antes. Estes problemas podem se apresentar nas mais diversas formas, desde pouco domínio de um conteúdo ou tecnologia que está sendo necessária no momento até questões de infra-estrutura que estejam atrapalhando o desempenho do time - computadores lentos, temperatura da sala do time, etc. Também é necessário que o time tenha pleno conhecimento de tudo que está acontecendo no projeto em escala pontual e global. Para isso, os métodos ágeis costumam fazer uso de recursos visuais para que seja fácil e rápido para qualquer pessoa da equipe obter essas informações. É importante e desejável que estes dados estejam fisicamente presentes na sala em que o time trabalha, simplificando ainda mais o processo. Entre recursos mais conhecidos e utilizado, pode-se citar: Quadro de tarefas: onde fica registrado o andamento de cada uma das tarefas designadas para a iteração atual. A figura 17 ilustra como, em geral, é um quadro de tarefas. Ele deve mostrar, para cada iteração, tarefas pendentes, feitas e verificadas, além de outras informações relevantes. É importante lembrar que esse modelo não é fixo. Cada time pode adaptá-lo de acordo com as sua necessidades. Gráfico Burn-down : Medida do que já foi desenvolvido na iteração atual em relação

3.1 Modelo de Desenvolvimento Ágil 36 Figura 17: Quadro de acompanhamento de um projeto ágil ao selected backlog 4, considerando-se tempo estimado e velocidade aproximada de desenvolvimento do time. Ajuda o time a acompanhar sua velocidade de desenvolvimento e compreender se seu desempenho está sendo como o esperado. A figura 18 mostra como deve ser um gráfico burndown. fonte: http:://www.agileway.com.br/2009/08/18/grafico-burndown-sugestao-de-uso Figura 18: Gráfco Burndown Gráfico de cobertura de testes: Medida de quanto do código produzido está sendo testado automaticamente ao longo do tempo. O ideal é que a maior parte possível de código esteja sendo testada. O gráfico de cobertura de teste ajuda o time a perceber se isso está sendo feito, como mostra a figura 19. 4 Funcionalidades separadas para implementação na iteração corrente.

3.1 Modelo de Desenvolvimento Ágil 37 fonte: http://msdn.microsoft.com/pt-br/library/ee461596.aspx Figura 19: Gráfico de cobertura de testes 3.1.3 Práticas de desenvolvimento mais utilizadas 3.1.3.1 Programação em par Como citado anteriormente, o desenvolvimento ágil valoriza mais pessoas que ferramentas e processos, compreendendo suas limitações e erros. A programação em par é uma prática presente em praticamente todas as metologias ágeis, e consiste em alocar os desenvolvedores a tarefas sempre em pares. Dessa forma, existem sempre duas pessoas focadas no mesmo objetivo. É importante dizer que existe sempre apenas uma pessoa ao teclado. O segundo componente da dupla troca informações, participando do processo criativo. Naturalmente, de tempos em tempos os papéis se invertem, e é desejável que as duplas sejam sempre alteradas e que todos trabalhem em todas as partes do código e com todos os outros programadores do time. Isso permite que ao longo do tempo todo o time tenha uma compreensão global do sistema, evitando especialistas. Também permite que durante a execução de uma tarefa, uma série de benefícios surjam, fazendo com que, em geral, a relação número de linhas de código produzidas versus pessoas alocadas não seja linear, mas muito mais vantajosa em par. Dentre esses benefícios, citamos três: Menos bugs introduzidos: com duas pessoas trabalhando no mesmo código, pequenos erros de sintaxe ou de lógica cometidos pelo programador que está digitando são quase sempre imediatamente detectados e corrigidos pelo seu companheiro. Isso evita, além de bugs, o desperdício de tempo nos casos em que pequenos erros difíceis de detectar ocorrem.

3.1 Modelo de Desenvolvimento Ágil 38 Dois escopos de visão para o mesmo código: durante a programação em par, o que geralmente acontece é que quem digita está concentrado na linha de código sendo escrita e nas linhas imediatamente acima e/ou abaixo. Já o seu companheiro fica naturalmente mais preocupado com o escopo global do código, ou seja, se este ou outro algoritmo está sendo implementado de forma correta e se o desenvolvimento está de acordo com o resto do projeto. Estas duas visões combinadas geram um código geralmente muito mais robusto. Menor interferência externa: pelo fato de o trabalho acontecer em conjunto, existe uma menor distração com coisas individuais - celulares, acesso à internet, etc., além de uma cobrança natural e do incentivo de um para o outro pela dedicação do companheiro. 3.1.3.2 Desenvolvimento orientado a testes e integração contínua Testes são um artifício muito utilizado em projetos ágeis. Eles são a garantia de que o código está funcionando conforme previsto, garantindo a qualidade da qual não pode-se abdicar em um PDS. O desenvolvimento orientado a testes é uma prática de desenvolvimento em ciclos, cada um dos quais composto pelas seguintes etapas: 1. Um código testador é escrito para algum dos casos possíveis de entrada/saída do código a ser escrito, ainda sem a existência deste. 2. Apenas a parte do código referente à solução deste teste é implementada, até que o código passe nele. 3. Uma vez passando no teste atual, o programador reinicia o ciclo, elaborando mais um teste que fará o código não se comportar como esperado. Este processo deve ser repetido até que não se consiga mais elaborar um caso de teste que faça o programa falhar. Dentre as vantagem dessa abordagem estão: Foco nos fluxos de exceção: o programador é forçado a pensar em casos ruins para o programa sendo desenvolvido, em vez de imaginar sempre que tudo acontecerá como previsto.

3.2 Requisitos Ágeis - Product Backlog 39 Automatização de testes: utilizando-se ferramentas apropriadas, os testes já escritos podem ser rodados automaticamente, permitindo que o programador perceba se a solução para um novo teste não estragou o código em relação a todos os testes anteriores para os quais o código já funcionava. Adicionalmente a esses benefícios, é possível que todos os códigos de teste escritos por todo o time de desenvolvimento sejam executados periodicamente sobre todo o projeto, verificando se existem interdependências de código problemáticas. É a chamada integração contínua, que inclusive pode ser realizada por programas automatizados, que ao detectarem novo código no projeto, realizam esse procedimento. Desta forma, todo o código testado está garantidamente funcionando para todos os casos pensados, que podem aumentar ao longo do tempo, conforme se perceba demais deficiências. Naturalmente todo este processo traz imensa robustez ao código produzido. 3.1.3.3 Refatoração Martin Fowler e Kent Back (FOWLER, 1999) definem refatoração como o processo de alterar um software de forma que seu comportamento externo permaneça o mesmo, mas que ainda assim, sua estrutura interna esteja melhor implementada. É uma forma sistematizada de simplificar o código, que minimiza as chances de introduzir bugs. Em sua essência, refatorar um código representa melhorar o seu design após sua escrita.. A refatoração ocorre, em geral, ao final de uma iteração, depois que as funcionalidades previstas já foram desenvolvidas, pois o foco inicial, como já foi citado, é ter o software funcionando corretamente. É neste momento que a estrutura do código é analisada, e questões de maior escopo, relativas ao projeto de uma forma mais abrangente são consideradas. Também é nesse momento que é garantida a fidelidade do código aos diversos padrões de projeto e demais boas práticas de desenvolvimento de software pertinentes. Assim, de posse de um código bem escrito, modular e extensível, a introdução de bugs torna-se mais improvável. 3.2 Requisitos Ágeis - Product Backlog Definir requisitos de software é um trabalho que necesita de debate entre time de desenvolvimento e cliente sobre as funcionalidades e os detalhes relativos a sua implementação. Nessa fase crucial de qualquer projeto, é preciso que haja um equilíbrio entre o

3.2 Requisitos Ágeis - Product Backlog 40 peso do time de desenvolvimento e do cliente na definição desses requisitos. Se o peso do cliente for muito maior que o dos desenvolvedores, serão relacionadas muitas funcionalidades para prazos muitas vezes irreais, pois o cliente em geral não se preocupa com os aspectos técnicos do desenvolvimento. Se, por outro lado, o time dominar, em muitos casos o que acontece é que são gerados requisitos de cunho técnico, que não significam muito para o cliente. 3.2.1 Histórias de usuário Histórias de usuário são pequenas descrições em geral escritas em cartões de papel e de forma bem simples de funcionalidades que se deseja presentes no sistema. Elas devem ser escritas sempre do ponto de vista do negócio, do cliente. Somente desta forma ele será capaz de calcular e compreender qual o valor que tal funcionalidade irá agregar ao seu produto. Uma história de usuário é escrita em 3 partes, sendo elas: 1. Descrição: pequena descrição simplificada, em termos gerais, da funcionalidade; 2. Detalhamento: informações adicionais que ajudarão o time a compreender melhor o que o cliente deseja; 3. Testes: formas apropriadas de verificar e documentar se a história foi implementada por completo. O detalhamento de uma história muitas vezes é chamado de conversação (COHN, 2004), pois ele é feito através de discussão com o cliente. Essas são as principais informações de uma história de usuário, pois são elas que determinam a customização desejada para o produto. Em muitos sistemas, existem funcionalidades diferentes para os diferentes perfis de pessoas que o utilizarão. Isso faz com que nesses casos seja conveniente escrever na história qual é esse perfil, bem como identificar todos os diferentes perfis de usuários presentes no sistema. Com isso, é possível compreender o escopo das diversas funcionalidades e a quem elas são destinadas. A descrição de uma história de usuário pode ser muito abrangente, com uma quantidade muito grande de detalhes e testes. Histórias deste tipo são frequentemente referidas

3.2 Requisitos Ágeis - Product Backlog 41 como épicos. O ideal é que uma história possa ser descrita de forma razoavelmente completa em um cartão e ser implementada por um ou dois desenvolvedores em um espaço de tempo que varie entre metade de um dia e duas semanas (COHN, 2004). Sendo assim, convém subdividi-la em demais sub-histórias, o que permite uma maior compreensão dos detalhes e testes envolvidos e que o desenvolvimento da mesma não se estenda por mais tempo que o necessário sem algum feedback real para o cliente. Na figura 20 vemos um exemplo de cartão de história. Confirmações: Eu, enquanto programador, gostaria que o código fosse mostrado com o objetivo de editá-lo. Abrir um arquivo com 20MB. Abrir um arquivo binário. * Fonte mono-espaçada * Identação de tamanho 4 * Numeração de linhas Abrir um arquivo com tamanho de linha maior que a largura do editor. (a) Frente (b) Verso Figura 20: Exemplo de cartão de história de usuário do ShaderLabs 3.2.2 Pontos de história e priorização O planejamento das entregas parciais de um software (releases) devem sempre ser planejadas de acordo com as funcionalidades mais importantes para o negócio do cliente e com o tempo disponível para implementação. Decisões de mercado podem influenciar nessa decisão, e convém ao time de desenvolvimento maximizar sempre que possível o retorno aos investimento do cliente (ROI), agregando o máximo de valor ao produto o mais rápido possível. Cada release é composta de várias iterações, intervalos de tempo mais curtos para os quais uma quantidade pré-determinada de funcionalidades é separada para desenvolvimento. O objetivo é determinar quais funcionalidades serão imlementadas a cada iteração e quantas iterações irão formar cada release para que o ROI seja máximo. No entanto, para priorizar as funcionalidades que serão desenvolvidadas antes ou depois, a métrica de valor agregado é insuficiente. É preciso que o cliente esteja ciente do custo relativo à implementação de cada funcionalidade, pois possivelmente ele é impeditivo em termos de planejamento de tempo. Com essa informação, é possivel ponderar ambos os fatores, gerando uma priorização de funcionalidades mais eficiente. Segundo Mike Cohn (COHN, 2004), pontos de história são uma medida dada pelo

3.2 Requisitos Ágeis - Product Backlog 42 time de desenvolvedores para o custo de implementação de uma história. Este valor é a informação necessária para dar suporte às decisões do cliente uma vez que, em geral, ele não faz idéia da dificuldade envolvida na implementação. Dado esse quadro, o time de desenvolvimento estima quantos pontos por iteração podem ser desenvolvidos, e o selected backlog da iteração pode ser escolhido de acordo. Um planejamento mais amplo pode ser feito, mas é sempre importante ter em mente que, ao longo do tempo, prioridades podem mudar e que é preciso ser capaz de responder às mudanças do negócio. Em geral, o maior escopo de planejamento é o de release, que já permite ao time dar boas estimativas de tempo e custo para o cliente. Embora elas não sejam precisas, são suficientemente próximas da realidade e geram flexibilidade durante o desenvolvimento. 3.2.3 Minimun Valuable Product (MVP) Relacionar funcionalidades, seu valor agregado e seu custo de implementação pode não ser o suficiente em termos de planejamento da primeira release de um software. Funcionalidades por si só agregam valor, mas no início do desenvolvimento de um projeto, existe um conjunto mínimo de requisitos que deve estar implementado para que o software tenha algum valor de mercado e seja minimamente utilizável. Por exemplo, uma busca de produtos em um site de compras não teria nenhum valor caso não fosse possível cadastrar tais produtos, como também não seria útil se não fosse possível realizar a compra dos mesmos após buscá-los. O MVP é justamente esse conjunto mínimo de funcionalidades. Pode ser de desejo do cliente que o produto seja imediatamente lançado assim que possível e, nesse caso, é desejável que a primeira release do software seja o seu MVP. No entanto, pode ser da estratégia do negócio que o software só seja lançado depois que um certo conjunto de funcionalidades mais elaboradas esteja implementado. Cabe ao time e ao cliente ponderarem estratégias e a importância de cada funcionalidade para decidir a melhor atitude a se tomar. Definir o MVP em geral é uma tarefa complicada, uma vez que a tendência é de sempre pensar em novas idéias de funcionalidades para o software. A definição do MVP é muito mais um trabalho de síntese do que de análise (TOLEDO, 2011). É preciso debate, argumentação e exposição do maior número possível de opiniões para que nada de supérfluo seja incluído no produto inicial.

3.3 O modelo Kano de satisfação do cliente 43 3.3 O modelo Kano de satisfação do cliente 3.3.1 Introdução O modelo Kano, proposto por Noriaki Kano (KANO et al., 1984) consiste em dividir as carecterísticas e funcionalidades de um produto em três categorias distintas, e dessa forma, compreender melhor seus papéis no produto final e as diferentes reações que cada uma delas causa no cliente/usuário. O modelo prevê que qualquer funcionalidade pode ser classificada como sendo de uma entre três categorias: obrigatória, linear ou diferencial. Características obrigatórias são aquelas sem as quais o cliente raramente suporta adquirir determinado produto ou serviço. Por exemplo, ao comprar um computador nos dias de hoje, poucas pessoas comprariam um equipamento que não dispusesse de portas USB. Já as características lineares são aquelas das quais quanto mais se dispõe, mais satisfação elas geram, e mais se está disposto a pagar para tê-las. O preço de produtos e serviços frequentemente está associado a características lineares. Ainda no exemplo do computador, memória principal (RAM), memória secundária (HD) e clock do processador são exemplos de características lineares. Por fim, as características diferenciais são aquelas que causam grande impacto no cliente, e que em geral mais chamam a sua atenção. Entretanto, a ausência de tais características em geral não faz com que o cliente fique insatisfeito com o produto. Para o referido exemplo, pode-se se citar como características diferenciais a presença de uma Webcam, ou de teclado e mouse sem fio. Diferenciais também são referidos como necessidades desconhecidas, uma vez que o cliente quase sempre desconhece tal necessidade até que lhe seja apresentado um produto que a revele. A figura 21 mostra como se comporta o nível de satisfação de um cliente de acordo com a presença de cada uma das três categorias de funcionalidade. Como é possível ver, a implementação de funcionalidades obrigatórias leva somente até certo ponto de satisfação, não importando o quanto delas esteja presente no produto final. De forma oposta, a presença de diferenciais gera uma cada vez mais alta satisfação do cliente, embora o sucesso desse impacto esteja relacionado com um certo nível de satisfação previamente adquirido através de funcionalidades obrigatórias e/ou lineares. Por fim, a linha central mostra que a satisfação do cliente cresce linearmente com a cada vez maior presença de

3.3 O modelo Kano de satisfação do cliente 44 características lineares. Figura 21: A evolução da satisfação do cliente com novas funcionalidades. É importante perceber também que uma característica tende a migrar de categoria ao longo do tempo. No início dos anos 90, o acesso à internet em um computador pessoal era um grande diferencial. Com o passar do tempo, dada a popularização da internet, essa característica se tornou obrigatória e de certa forma também linear, pois nos dias de hoje, quanto maior for a velocidade de acesso à rede, melhor. 3.3.2 O Método Kano aplicado a requisitos de software Para classificar as funcionalidades de um software da forma mais precisa possível, o modelo Kano propõe uma abordagem de pesquisa entre uma quantidade razoavelmente pequena de possíveis usuários do software através de um questionário escrito. A proposta: perguntar, para cada funcionalidade que se deseja conhecer a categoria, como o usuário se sentiria com e sem a presença da mesma. A resposta a cada uma das perguntas deve ser uma das opções que se seguem: 1. eu gostaria que fosse dessa forma; 2. eu espero que seja dessa forma; 3. tanto faz; 4. eu poderia suportar sendo dessa forma; 5. eu não gostaria que fosse dessa forma.

3.3 O modelo Kano de satisfação do cliente 45 Como exemplo, imagine um portal de compras na internet. Poderíamos avaliar a funcionalidade de drag-n-drop de um produto para o carrinho de compras através das seguintes perguntas: Se você pudesse arrastar um produto para seu carrinho de compras, o que você acharia? Se você não pudesse arrastar um produto para seu carrinho de compras, o que você acharia? Cujas respostas poderiam ser, por exemplo: Eu gostaria que fosse dessa forma Tanto faz Para cada par de perguntas, funcional e não-funcional, existem 25 combinações de respostas. É preciso então olhar para ambas ao mesmo tempo e em um contexto geral, para determinarmos de que categoria é a funcionalidade. Para isso, faz-se uma referência cruzada das respostas, de acordo com a figura 22. Temos então 6 avaliações possíveis para uma funcionalidade, a saber: Figura 22: Avaliação do par de perguntas por referência cruzada. M: Obrigatória; L: Linear; E: Diferencial;

3.3 O modelo Kano de satisfação do cliente 46 Q: Questionável: Pode haver erro na resposta; I: Indiferente: a implementação da funcionalidade causa pouco ou nenhum impacto no nível de satisfação do cliente; R: Reversa: Funcionalidade que não deve ser implementada. Para cada usuário entrevistado, esse processo é repetido para cada funcionalidade que se deseja avaliar. Dessa forma, ao final do experimento, temos as diversas avaliações de cada uma das funcionalidades divididas entre as seis opções acima M, L, E, Q, I e R. De posse dessas informações, podemos calcular as porcentagens de ocorrência de cada uma das categorias e descobrir qual delas é a predominante. O resultado deste processo pode ser tabulado em um quadro como o da Figura 23, que coloca possíveis resultados para a avaliação de funcionalidades do exemplo do portal de compras. Figura 23: Tabulação dos resultados no Modelo Kano. É importante perceber que nem sempre uma das categorias será notoriamente predominante, como podemos ver na última linha da figura 23. Nesse caso, a funcionalidade em questão gera diferentes reações nos diferentes tipos de usuário. Torna-se então conveniente dividi-los utilizando-se algum tipo de critério pertinente à usabilidade do software. Dessa forma, é possível ter uma melhor compreensão do efeito que a implementação de tal funcionalidade terá. Ao fim desse processo, temos em mãos informações valiosas sobre como cada uma das funcionalidades previstas afetará a percepção dos usuários em relação ao software, de forma que é possível agora pensar todo o processo de desenvolvimento de forma embasada, maximizando o valor agregado do produto a cada nova release.

47 4 Desenvolvimento do ShaderLabs 4.1 Aplicação da metodologia ágil Esta seção dedica-se a explicar como foi o processo de implantação das práticas de métodos ágeis ao planejamento e codificação deste projeto. 4.1.1 Perfis de usuário Uma das primeiras etapas do desenvolvimento do ShaderLabs foi o levantamento dos principais requisitos de sistema que foram pensados quando da idealização do projeto. Nesse momento, foi gerada uma lista de funcionalidades de diferentes níveis de dificuldade de implementação e diferentes escopos, no que diz respeito à sua utilização. Notoriamente, elas se dividiam em grupos, que representavam basicamente diferentes perfis de pessoas que poderiam utilizar o software. Isso nos levou a discriminar tais funcionalidades, com o objetivo de compreender o nível de alcançe que elas teriam quando viessem a ser implementadas. Nesse passo, o objetivo foi identificar que perfis de pessoa se interessariam por cada funcionalidade. Para isso, não foi feita nenhuma pesquisa com público. Todas as classificações foram feitas com nosso critério. Os perfis de usuário levantados foram: Programador: Usuário genérico, que necessita das funcionalidades básicas necessárias a todos que se disponham a utilizar o produto. Ele é um super-tipo dos outros dois perfis identificados: Aluno: Alunos de gradução, em geral com pouco conhecimento em Computação Gráfica, cujo objetivo principal é aprender. Profissional: Programador com conhecimentos em programação para GPU,

4.1 Aplicação da metodologia ágil 48 cujo objetivo pricipal é dispor de uma ferramenta simples, intuitiva e que permita-o maximizar o trabalho feito com um mínimo de esforço. Esses perfis levantados nos foram úteis posteriormente, pois foi baseado neles que a análise por subgrupos do modelo Kano foi feita, como descrito na seção 4.1.3.2. 4.1.2 MVP e usabilidade do ShaderLabs A definição do MVP 1 foi um desafio à parte. Com um escopo tão abrangente quanto a implementação de uma IDE permite, e com tantas idéias para implementar, o objetivo era excluir do produto inicial a maior parte possível delas, ainda assim gerando um produto que agregasse valor e fosse minimamente utilizável. Após alguma discussão e argumentação, chegamos a um consenso sobre o que não poderia faltar de forma alguma em um produto que se dispusesse a fazer o que o ShaderLabs faria. Segue a relação dessas funcionalidades. 1. Abrir um arquivo em disco para editar um vertex ou um fragment shader; 2. Carregar um modelo pré-definido sobre o qual o(s) novo(s) shader(s) executaria(m) (inicialmente uma esfera gerada pela biblioteca GLU, descrita na seção 4.2.1; 3. Execução dos shaders codificados sobre a esfera; 4. Salvar alterações no arquivo fonte; 5. Exibir o output de compilação; Este pequeno conjunto de funcionalidades pôde ser implementado em um intervalo relativamente curto. Em apenas duas semanas (duas iterações) já dispúnhamos de um software funcional e no qual era possível gerar resultados consistentes reprogramando o vertex e o fragment shader. Mesmo em estágio embrionário, o MVP já trazia um grande valor agregado para o projeto. A elaboração do MVP também foi de grande importância para que o projeto viesse posteriormente a ser utilizado na disciplina de computação gráfica, pois proveu a base necessária para um programa minimamente utilizável. Posteriormente, com mais algumas 1 Minimun Valuable Product - ver seção 3.2.3 na página 42

4.1 Aplicação da metodologia ágil 49 funcionalidades implementadas, o software foi utilizado com sucesso, permitindo aos alunos a geração de resultados interessantes e contribuindo para o seu aprendizado. Naquele momento, ainda havia algumas deficiências em relação ao que se espera de uma IDE como syntax-highlighting e metadados de projeto. Para um relato mais detalhado, veja o capítulo 5 na página 63. 4.1.3 Aplicação do modelo Kano Uma vez que a ferramenta idealizada dispunha de uma gama muito grande de possíveis funcionalidades a serem adicionadas, fez-se necessária a priorização do que deveria ser implementado, com o objetivo de maximizar o valor agregado com o mínimo de esforço de desenvolvimento. Adicionalmente, evita-se a implementação de funcionalidades que, ou seriam muito pouco usadas, ou se mostrariam desnecessárias quando da utilização prática do programa. Para isso, o modelo Kano de satisfação foi utilizado. Para uma conceituação do modelo, consulte a seção 3.3. 4.1.3.1 Priorizando requisitos do ShaderLabs através do Modelo Kano No processo de priorização, foram levantados uma série de requisitos de software do ShaderLabs para avaliação e classificação. Embora o ideal fosse que o método fosse aplicado quando do início do processo de desenvolvimento, no momento que optamos por utilizá-lo já havia uma quantidade razoável de funcionalidades implementadas. Apesar disso, a pesquisa se fazia necessária, uma vez que ainda tínhamos em mãos muitas funcionalidades passíveis de serem desenvolvidas. Após um processo de seleção e filtragem das perguntas, obteve-se o seguinte questionário (as perguntas não-funcionais foram omitidas): 1. Se o compilador GLSL do ShaderLabs exibisse corretamente a linha de um erro, como você se sentiria? 2. Se você pudesse controlar as configurações do contexto OpenGL sob o qual o modelo está sendo renderizado, como você se sentiria? 3. Se fosse disponibilizado auto-completion das variáveis GLSL disponíveis para utilização durante a programação, como você se sentiria? 4. Se você pudesse carregar seus próprios modelos (malhas de triangulos, etc) no ShaderLabs, como você se sentiria?

4.1 Aplicação da metodologia ágil 50 5. Se você pudesse controlar as propriedades de fonte do editor do ShaderLabs, como você se sentiria? 6. Se ao ocorrer um erro de compilação no ShaderLabs, a cor da fonte do código problemático fosse alterada (ex: vermelho), como você se sentiria? 7. Se você pudesse limpar a janela de output do ShaderLabs, como você se sentiria? 8. Se você pudesse mudar a posição da luz, como você se sentiria? 9. Se fosse exibida a numeração das linhas, como você se sentiria? 10. Se você pudesse visualizar outros modelos pré-definidos (Ex: torus, cubo e primitivas em geral), como você se sentiria? 11. Se você pudesse navegar pelas abas do ShaderLabs através de algum tipo de atalho (Ex: Ctrl+tab), como você se sentiria? 12. Se você fosse informado se o hardware da máquina tem suporte aos diversos shaders, como você se sentiria? 13. Se você pudesse dar zoom no modelo, como você se sentiria? 4.1.3.2 Resultados Com um total de 26 perguntas (somando-se a essas as 13 não funcionais), foi criado um questionário online utilizando a ferramenta Google Forms. Este questionário foi enviado a diversas pessoas, com diferentes perfis e níveis de conhecimento em computação gráfica. Entre elas, podemos citar alunos da disciplina de Computação Grafica I do curso de ciência da computação da UFRJ, alunos em estágio mais avançado na graduação, com conhecimentos em desenvolvimento de jogos e profissionais da área de computação grafica. Com os resultados da pesquisa em mãos, os dados foram devidamente formatados em modo texto e avaliados automaticamente por um script Python, que gerou os resultados exibidos na tabela 1 (nas tabelas que se seguem, as colunas referentes às classificações questionável e reversa foram omitidas, pois nenhuma resposta foi classificada como tal). Infelizmente somente em duas das perguntas pudemos determinar de forma mais precisa qual seria sua categoria. Apenas as funcionalidades Exibir corretamente linha de erro (Obrigatória), e Auto-completion (Diferencial) apresentaram resultados conclusivos, próximos da unanimidade. Nos demais casos, as opiniões ficaram muito divididas, e uma análise por subgrupo mostrou-se necessária.

4.1 Aplicação da metodologia ágil 51 Tabela 1: Resultados iniciais da aplicação do modelo Kano Resumo E I M L Resultado Exibir corretamente linha de erro 0 0.1 0.9 0 obrigatória Controlar configurações OpenGL 0.4 0.3 0.2 0.1 diferencial Auto-completion 0.9 0 0 0.1 diferencial Modelos próprios 0.4 0.2 0.3 0.1 diferencial Propriedades de fonte 0.33 0.67 0 0 indiferente Cor para erro de compilação 0.56 0.33 0 0.11 diferencial Limpar output 0.11 0.56 0.22 0.11 indiferente Mudar a posição da luz 0.11 0.11 0.56 0.22 obrigatória Exibir numeração das linhas 0.22 0 0.56 0.22 obrigatória Visualizar mais modelos pré-definidos 0.33 0.44 0.11 0.11 indiferente Navegar pelas abas 0.33 0.22 0.33 0.11 indefinido Suporte de hardware 0.67 0 0.33 0 diferencial Zoom no modelo 0.44 0.33 0.22 0 diferencial O critério utilizado para divisão em subgrupos foi o nível de conhecimento em computação gráfica. Uma vez que o questionário estava identificado por nome e a grande maioria dos entrevistados era conhecida ou de fácil contato, foi fácil dividi-los nessas duas categorias. Aplicando-se então o modelo Kano para os dois subgrupos separadamente, e excluindo-se as duas funcionalidades das quais já havíamos obtido uma classificação confiável, foram gerados os resultados mostrados nas tabelas 2 e 3, para pessoas com menos e mais conhecimentos em computação gráfica, respectivamente. Tabela 2: Resultados para entrevistados com pouco conhecimento em computação gráfica Resumo E I M L Resultado Controlar configurações OpenGL 0.75 0 0 0.25 diferencial Modelos próprios 0.5 0.25 0.25 0 diferencial Propriedades de fonte 0 1 0 0 indiferente Cor para erro de compilação 0.67 0.33 0 0 diferencial Limpar output 0.33 0.67 0 0 indiferente Mudar a posição da luz 0 0 0.33 0.67 linear Exibir numeração das linhas 0.33 0 0.33 0.33 indefinido Visualizar mais modelos pré-definidos 0.67 0 0 0.33 diferencial Navegar pelas abas 0.67 0 0 0.33 diferencial Suporte de hardware 0.67 0 0.33 0 diferencial Zoom no modelo 0.67 0.33 0 0 diferencial Neste segundo experimento, os resultados mais uma vez se mostraram inconclusivos, por razões que serão exploradas na seção 4.1.3.4. No entanto, considerou-se que, mesmo inconclusivos, esses resultados já demonstram uma certa tendência sobre qual categoria esta ou outra funcionalidade teria. Como a pesquisa por subgrupos se mostrou tão in-

4.1 Aplicação da metodologia ágil 52 Tabela 3: Resultados para entrevistados com maior conhecimento em computação gráfica Resumo E I M L Resultado Controlar configurações OpenGL 0.17 0.5 0.33 0 indiferente Modelos próprios 0.33 0.17 0.33 0.17 indefinido Propriedades de fonte 0.5 0.5 0 0 indefinido Cor para erro de compilação 0.5 0.33 0 0.17 diferencial Limpar output 0 0.5 0.33 0.17 indiferente Mudar a posição da luz 0.17 0.17 0.67 0 obrigatória Exibir numeração das linhas 0.17 0 0.67 0.17 obrigatória Visualizar mais modelos pré-definidos 0.17 0.67 0.17 0 indiferente Navegar pelas abas 0.17 0.33 0.5 0 obrigatória Suporte de hardware 0.67 0 0.33 0 diferencial Zoom no modelo 0.33 0.33 0.33 0 indefinido conclusiva quanto a mais geral, optou-se por utilizar os dados obtidos na pesquisa geral como base para a priorização das funcionalidades que ainda seriam desenvolvidas. 4.1.3.3 Priorizando o Backlog Juntamente com os dados de categorias obtidos, também foi avaliado o esforço que seria necessário para o desenvolvimento das novas funcionalidades utilizando-se pontos de história, como visto na seção 3.2.2 na página 41. Pelo fato de o projeto já encontrar-se em um estado razoavelmente avançado, a grande maioria das funcionalidades obrigatórias já havia sido desenvolvidas. Como foi visto anteriormente, requisitos obrigatórios param de agregar valor ao produto a partir de um determinado ponto, ou agregam muito pouco. Dessa forma, nossa abordagem foi dar prioridade aos requisitos diferenciais, com o mais baixo custo de implementação possível. A tabela 4 mostra a lista de requisitos priorizada após o estudo feito: Tabela 4: Requisitos priorizados após o estudo realizado e suas classificações para diferentes grupos Ordem Requisito Geral Alunos Exper. Custo 1 Mudar a posição da luz M L M Baixo 2 Navegar pelas abas M E M Muito baixo 3 Suporte de hardware E E E Baixo 4 Modelos próprios E E E Baixo 5 Zoom no modelo E E E Médio 6 Mudar configurações OpenGL E E I Alto As demais funcionalidades foram ou guardadas para um momento posterior (por falta de tempo hábil), ou deixadas de lado porque não agregariam mais valor suficiente para

4.1 Aplicação da metodologia ágil 53 justificar seu esforço de implementação. 4.1.3.4 Problemas na implementação do modelo Kano Apesar de o Modelo Kano ter sido determinante para a priorização dos requisitos que ainda seriam implementados no ShaderLabs, é importante frisar alguns problemas encontrados durante a coleta e apuração dos resultados das pesquisas feitas. Em (COHN, 2006), discute-se que o número médio de respostas para gerar confiabilidade nos resultados deve ser de 20 a 30. Por falta de quórum, esta pesquisa contou apenas com a resposta de dez pessoas diferentes. Consideramos que esta provavelmente foi a principal causa da falta de conclusividade dos resultados, uma vez que qualquer nova resposta ainda teria uma influência muito grande sobre a importância de cada categoria. Este fato é ainda mais notório na pesquisa por subgrupo, pois estes contaram com aproximadamente cinco pessoas em cada. Mesmo assim, como dito anteriormente, as pesquisas mostraram tendências suficientemente claras para que fossem utilizadas como embasamento para a priorização do backlog. 4.1.4 Andamento do projeto Monitorar a cada iteração o andamento do projeto como uma medida de desempenho e melhoria se mostraram uma excelente forma de auto-cobrança e uma possibilidade de conhecimento de nossas qualidades e defeitos enquanto desenvolvedores. Esse monitoramento foi feito através da coleta de alguns dados dos quais dispúnhamos semanalmente, que foram acompanhados durante a execução do projeto e que, ao seu término, proveram as seguintes estatísticas sobre o processo de desenvolvimento: 4.1.4.1 Velocidade Uma vez que os requisitos de software foram descritos utilizando-se histórias de usuário (seção 3.2.1 na página 40) e devidamente pontuados de acordo com sua dificuldade de implementação utilizando-se pontos de história (seção 3.2.2 na página 41), a escolha de um selected backlog nos dava, por iteração, as seguintes informações: Quantidade de pontos de história que deveriam ser implementados.

4.1 Aplicação da metodologia ágil 54 Quantidade de pontos de história que não foram implementados. Quantidade de pontos de história que foram efetivamente implementados. Com estes dados, foi possível gerar um histórico de velocidade de desenvolvimento, que ilustra a quantidade de pontos implementados por iteração, que no nosso caso durava uma semana. Este gráfico foi acompanhado ao longo do projeto e, ao fim deste, foi gerado um resultado geral de todo o desenvolvimento, como mostrado na figura 24. Figura 24: Histórico da velocidade de desenvolvimento do projeto O gráfico mostra que a velocidade de desenvolvimento não foi constante. Houve muitos contratempos e momentos em que o projeto precisou ser colocado de lado por conta de outras prioridades. Na 5 a iteração, por exemplo, não houve desenvolvimento, pois os desenvolvedores do projeto estiveram ocupados com coisas pessoais. Em outros momentos de menor produtividade em relação à programação ocorreram por conta da necessidade de produção textual. Apesar disso, é visivel que os picos de produtividade se mantiveram em um patamar bem próximo, o que nos deu a noção de qual é, de fato, a nossa velocidade de implementação. Além de medir a velocidade de desenvolvimento, alguns times ágeis utilizam um gráfico chamado Cumulative Flow Chart para avaliar o andamento do projeto numa visão mais ampla. Nesse gráfico observam-se três curvas distintas. A curva mais alta representa o total de pontos das histórias de usuário já pontuadas; a intermediária mostra o total de pontos que foram iniciados; e a mais baixa o total de pontos cuja implementação foi concluída. A Figura 25 mostra o cumulative flow chart deste projeto. Verificando as áreas nesse gráfico é possível perceber rapidamente alguns dados interessantes. A área superior representa a quantidade de pontos de história que ainda

4.1 Aplicação da metodologia ágil 55 Figura 25: Cumulative flow chart. não foram iniciadas. A estreita área do meio representa os pontos iniciados, mas não finalizados e a área mais abaixo representa o total de pontos concluídos. A metodologia ágil Kanbam (SOCIETY, 2011) prega pela não existência de iterações time-boxed 2, de forma que o desenvolvimento seja sempre sob demanda, ou seja, fazer menos coisas ao mesmo tempo e iniciar uma nova tarefa tão logo a anterior acabe o chamado sistema puxado. Iterações bem curtas (1 semana) e poucas tarefas em paralelo (sempre com baixas pontuações) refletiram na área intermediária do gráfico da Figura 25, o que demonstra que este projeto esteve bem próximo dessas práticas. Segundo essa metodologia, isso é um bom sinal para o desenvolvimento de um projeto de software. 4.1.4.2 Semanário e Selected Backlog Todas as etapas do projeto foram pensadas de acordo com as práticas de metologias ágeis descritas em seção 3.1 na página 30. Dessa forma, a cada iteração eram levantadas uma série de tarefas pesquisa, escrita, desenvolvimento, levantamento de dados, etc que deveriam ser realizadas até o início da iteração seguinte. Como uma forma de controle e acompanhamento das tarefas, foi criado um semanário em uma planilha online do Google Spreadsheet, que podia ser visualizada e editada colaborativamente por todas as pessoas envolvidas no projeto. A figura 26 mostra o semanário referente à iteração que ocorreu entre 05/04/2011 e 11/04/2011. 2 Definidas dentro de um intervalo de tempo e com terefas pré-determinadas

4.1 Aplicação da metodologia ágil 56 Figura 26: Exemplo de semanário Para cada tarefa, eram registrados o atual status feito, pendente ou abandonado além de informações relevantes sobre o processo de realização das mesmas. Grande parte dos conteúdos pesquisados e dos problemas encontrados ao longo do caminho ficavam registrados nessa planilha, de forma que ela proveu um arcabouço de informações que foi muito importante para a escrita deste trabalho e para que os conhecimentos e experiências adiquiridos ao longo do tempo não se perdessem. As iterações curtas sempre com duração de uma semana também receberam o acompanhamento do professor orientador deste trabalho, Rodrigo de Toledo, que também desempenhou o papel de dono do produto durante o desenvolvimento. Uma reunião semanal era realizada em sua sala, marcando o fim da iteração atual e o início da seguinte. Nessa reunião, todas as terefas previstas eram revistas e passavam por um processo de aprovação. Quando alguma pendência surgia, seja por não realização ou porque ainda era preciso fazer ajustes, o restante da tarefa era repriorizado juntamente com o resto das tarefas previstas para as próximas iterações e reatribuído ou não, dependendo do caso. Para que esse acompanhamento fosse feito de forma simples, um quadro com o status do projeto era mantido na sala do professor semelhante ao quadro de tarefas descrito na seção 3.1.2.2 na página 35. As figuras 27b e 27a mostram imagens desse quadro.

4.2 Implementação (a) Acompanhamento global do projeto 57 (b) Acompanhamento de uma iteração Este acompanhamento permitiu muitas vezes que coisas que pareciam ser importantes a priori se mostrassem de menor importância conforme o projeto evoluia, permitindo-nos sempre rever as prioridades. Isso reforça o valor da priorização para este projeto. 4.1.5 Evolução do ShaderLabs Ao longo do período de desenvolvimento, o ShaderLabs foi adiquirindo novas funcionalidades. Durante o projeto, houve momentos de maior importância, onde novas diretrizes foram estabelecidas para os rumos que seriam tomados. A Figura 31 na página 62 mostra, em linhas gerais, esses principais momentos e o estado do software, em termos de funcionalidade, em cada um deles. A lista de funcionalidades exibida está em ordem de implementação. Na linha de tempo traçada, cada segmento representa uma nova iteração. Os marcos que foram importantes durante o processo de desenvolvimento estão representados abaixo da linha de iterações e a caixa acima de cada uma deles exibe as funcionalidades até então implementadas. 4.2 Implementação Nesta seção, serão explicados os aspectos técnicos referentes à implementação do ShaderLabs. Este conteúdo funciona também como uma documentação simplificada, com infromações sobre este aspecto do projeto.

4.2 Implementação 58 4.2.1 Tecnologias utilizadas e documentação técnica Procuramos utilizar ferramentas livres e gratuitas para produzir um produto também livre e gratuito. Dessa forma, o conjunto de ferramentas utilizadas na produção desse projeto foram: SVN: Mecanismo para controle de versão do código produzido. Para isso, foi utilizado o repositório online Google Code. O versionamento de código é uma prática importante para qualquer projeto nos dias de hoje. Ele permite manter o histórico de desenvolvimento, garantindo backup automático, e provendo diversas outras funcionalidades que facilitam o desenvolvimento em equipe e remotamente. C++: utilizamos, para desenvolvimento da aplicação, a linguagem de programação C++ por ser uma linguagem orientada a objetos com boa documentação, largamente utilizada por profissionais de computação gráfica, com boa performace e facilidade para encontrar um compilador gratuito em diversos sistemas operacionais. Além disso, essa linguagem possui um framework 3 que foi muito útil e eficiente para o desenvolvimento desse trabalho. Qt: é um framework com um conjunto de APIs para desenvolvimento em C++. Esse framework é multiplataforma, possibilitando atingir diversos sistemas operacionais com o mesmo código base, além de possuir uma excelente API para criação de interfaces gráficas. Juntamente com o framework, obtém-se um conjunto de aplicações que facilitam o desenvolvimento. As principais são: uma IDE para ajudar no desenvolvimento do código; uma IDE para criação de interfaces gráficas; e uma aplicação gráfica que ajuda a organizar a documentação do framework e a fazer buscas nela de forma eficiente. Sua API já está integrada com a API OpenGL, descartando a necessidade de fazer essa integração manualmente. OpenGL: como a seção 2.3 descreve, a API OpenGL é a melhor opção para quem deseja trabalhar com renderização 3D utilizando ferramentas livres ou gratuitas. GLU (OpenGL Utility Library): é uma biblioteca que utiliza os recursos de baixo nível disponíveis no OpenGL para prover um conjunto de funções de alto nível. Essa biblioteca normalmente é distribuida com o OpenGL. 3 Framework é um conjunto de classes que colaboram para realizar uma responsabilidade para um domínio de um subsistema da aplicação. Fayad e Schmidt

4.2 Implementação 59 GLee (GL Easy Extension Library): para trabalhar com algumas extensões OpenGL é necessário utilizar uma biblioteca para carregamento de extensões. O Glee provê essa funcionalidade, além de possuir seu código aberto e trabalhar em diversos sistemas operacionais, estando assim, de acordo com nossos objetivos. Além de produzir um software gratuito, gostaríamos que esse software fosse facilmente extensível. A intensão é que, caso haja a liberação de mais estágios programáveis nas placas de vídeo, esses possam ser incluidos facilmente em alguma possível continuidade do projeto pela comunidade open source. Não só para se adequar a essa necessidade, sendo também uma das preocupações do sistema de desenvolvimento ágil, o ShaderLabs foi desenvolvido com uma forte atenção na qualidade da escrita do código. Para manter essa boa qualidade adotamos o MVC (Model-View-Controller) como principal padrão de projeto. De acordo com (GAMMA, 1995), o MVC consiste em três tipos de objetos: Modelo, Vista e Controle. O Modelo são objetos (dados) da aplicação, a Vista é a forma de apresentação e o Controle define como a aplicação reage às entradas do usuário. Esse padrão de projeto desacopla a vista do modelo por meio de um protocolo de inscrições e notificações entre eles. GLDisplay Arcball RenderController DirectionalLight PrimitivesDialog Object3D SLCommandLinkButton ChooseShaderDialog Plane Sphere HighLighter FindWidget MainController FileContainer ShaderCodeContainer MainWindow Project SLTabWidget SLToolBar TexturePropertiesView TextureController Texture Figura 27: Modelo de classes.

4.2 Implementação 60 A figura 27 mostra o diagrama de classes do projeto no seu estado atual. Nele observase como o padrão MVC foi seguido no desenvolvimento do ShaderLabs. As classes à esquerda são classes de vista que, assim com as classes de modelo à direita, somente são manipuladas pelas classes centrais. Essas são as classes de controle onde encontra-se a lógica de negócio do software. 4.2.2 Modelo de manipulação de câmera A seção 2.6 apresenta alguns modelos de manipulação de câmera e ambos os modelos apresentados provêem a funcionalidade desejada para esse projeto. No entanto, o ShaderLabs é uma IDE de programação em placas de vídeo fortemente centrada no objeto, isso já indica que o arcball seria a melhor opção por ser object-based. Além disso, é da opinião dos autores por meio de uso e experimentação, que ele permite um manipulação mais simples, sendo mais fácil posicionar um objeto da forma desejada. Isso se deve em grande parte a ausência de histerese. p2 p2 p1 p1 (a) Pontos na telal (b) Pontos na esfera Figura 28: Mapeamento dos pontos da tela em pontos da esfera. O artigo (SHOEMAKE, 1992) também mostra uma forma de implementação onde a posição do mouse em 2D é mapeado em uma esfera em 3D através de um círculo virtual na tela. Quando o cursor do mouse está dentro de um círculo virtual no plano da tela, sua posição é mapeada em uma esfera de raio 1 calculando a coordenada z em função dos valores de x e y. Quando a posição está fora, o ponto é projetado na borda da esfera. Exemplos desse mapeamento podem ser vistos na Figura 28. Após a implementação do referido mapeamento, percebemos um efeito desagradável uma rotação inesperada quando a posição inicial do mouse está dentro do círculo e, durante o arrasto, a posição final sai do círculo. Fica claro, observando os arcos na Figura 29, a mudança brusca na forma de rotação. A Figura 29a mostra a rotação sendo feita pela frente da esfera. Já na Figura 29b, a rotação é por fora.

4.2 Implementação 61 Ponto inicial Ponto inicial Ponto final Ponto final (a) Rotação pela frente (b) Rotação por fora Figura 29: Sentido da rotação do arcball quando os pontos do mapeamento estão fora do círculo. Para contornar esse problema, nós criamos uma alternativa para a forma de mapeamento 2D para 3D. Nessa nova forma, não existe somente um círculo virtual, mas infinitos. Para isso, utilizamos o raio do círculo principal e a distância entre a posição do mouse e o centro do círculo em uma aritimética modular para setorizar o mapeamento. A abordagem na situação onde o usuário clica dentro do círculo virtual ainda é a mesma. Esse círculo virtual agora é representado pelo círculo mais ao centro da Figura 30 (com menor raio). Os pontos na área seguinte são mapeados na face de trás da esfera, antes ignorada. A próxima área mapeará os pontos novamente na frente da esfera e assim por diante. Figura 30: Mapeamento dos círculos. Entretanto, após uma leitura posterior mais aprofundada, percebemos que o efeito indesejado era proveniente da nossa implementação. Apesar disso, optamos por manter nossa própria solução para o problema.

4.2 Implementação 62 Inicio (Março) Até [7] Até [12] Até [20] Todos listados MVP (Abril) Distribuição para beta testers (Junho) Trabalho de CG (Julho) Atualmente (Setembro) [1] Abrir um vertex shader do disco [2] Abrir fragment shader do disco [3] Carregar um modelo pré-definido (esfera) [4] Execução dos shaders [5] Abrir novo arquivo [6] Salvar alterações do arquivo [7] Exibir o output de compilação [8] Salvar como [9] Salvar todos [10] Controle de modificação no fechamento de arquivos [11] Movimentação interativa do modelo [12] Trocar entre wireframe e fill [13] Bloquear execução de um shader [14] Reordenação de abas [15] Salvar o resultado como imagem [16] Interação no processo de abertura [17] Gerenciamento de múltiplas texturas [18] Plano como modelo pré-definido [19] Exibição da posição do cursor [20] Plano e esfera super-tecelados como modelos pré-definidos [21] Busca textual [22] Sintax highlighting [23] Geometry shader habilitado à programação [24] Rotação interativa da iluminação [25] Abrir projeto [26] Salvar novo projeto [27] Atalho para navegação nas abas [28] Aviso de suporte de hardware Figura 31: Linha do tempo das funcionalidades do projeto

63 5 Estudo de Caso - o trabalho na disciplina Computação Gráfica I O fato de termos usado uma metodologia ágil seguindo o princípio de desenvolvimento em fatias (TOLEDO, 2010) fez com que o software estivesse sempre funcional após cada iteração. Com isso, o professor da cadeira de Computação Gráfica I e orientador desse trabalho, Rodrigo de Toledo, e seu monitor, um dos autores, Thiago Elias, decidiram testar a usabilidade do software na prática, fazendo com que os alunos produzissem um trabalho que o utilizasse. Naquele momento, o ShaderLabs contava com: Um editor simples com gerência usual de arquivos (novo, abrir, salvar, salvar como e salvar todos) sem syntax highlighting; Possibilidade de escrever código para vertex e fragment shader; Uma área onde o objeto é renderizado; Uma área para listar as saídas de compilação; Possibilidade de desativar a execução de qualquer um dos shaders; 4 modelos simples: esfera, esfera super-tecelada, plano e plano super-tecelado; Possibilidade de carregar multiplas texturas 2D gerando variáveis uniformes para acesso via código. No trabalho passado para os alunos (vide anexo A), foi pedido a eles que, utilizando o ShaderLabs, escrevessem um par de códigos GLSL (vertex e fragment shader) para transformar uma esfera em um cubo-mágico, onde esperávamos um resultado parecido com o da Figura 32.

5 Estudo de Caso - o trabalho na disciplina Computação Gráfica I 64 Neste trabalho, os alunos, trabalhando em duplas, tinham um conjunto mínimo de tarefas para implementar durante um prazo de 2 semanas. Isso lhes garantiria uma nota mediana. Para notas mais altas, eles poderiam implementar itens extras, de uma lista previamente fornecida, ou novas idéias que eles pudessem eventualmente ter. Esse foi o 4 o e último trabalho da disciplina, que contava com 68 alunos regularmente inscritos. Desse total, 50 alunos entregaram o trabalho, ou seja, 25 trabalhos. Figura 32: Resultado gerado pelo ShaderLabs de uma possível solução para um dos trabalho de Computação Gráfica I. Como não havíamos estudado formas de implantação do projeto, achamos que disponibilizar o binário gerado pela compilação e algumas já conhecidas bibliotecas dinâmicas seria o suficiente. Porém percebemos que havia dependência com outras bibliotecas que não geravam um erro, sendo mais difícil encontrá-las. Abaixo estão alguns problemas observados durante esse período: Não era possível carregar imagens no formato JPG; Os programas GLSL - Vertex e Fragment shader, eram compilados com sucesso, mas não era possível realizar o processo de linkedição; O recurso de multitextura não estava funcionando Começou então o esforço para fazer com que todos os alunos conseguissem rodar o programa e assim desenvolverem seus trabalhos. Dessa forma, a solução adotada foi pedir a eles que desenvolvessem o trabalho no LCI 1, baixando e compilando o código fonte. Trabalhar nesse local também contornaria o problema de algum aluno não possuir uma placa gráfica que permitisse esse tipo de programação. Felizmente todos os alunos que se propuseram a fazer o trabalho conseguiram terminá-lo. 1 Laboratório de Computação e Informática. Laboratório disponibilizado as alunos do curso de Ciência da Computação da UFRJ

5 Estudo de Caso - o trabalho na disciplina Computação Gráfica I 65 Figura 33: Resultados para o trabalho de computação gráfica gerados por diferentes alunos. Essa foi uma experiência muito boa para nosso amadurecimento e consequentemente do ShaderLabs. Conseguimos um feedback para os problemas encontrados, idéias de novas funcionalidades e até foi possível priorizar as próximas funcionalidades utilizando um formulário de pesquisa baseado no modelo Kano que pode ser visto com mais detalhes em 4.1.3. Para encorpar a explanação dessa experiência, conseguimos alguns depoimentos que podem ser vistos no anexo B. Alguns dos resultados obtidos pelos alunos podem ser vistos na figura 33.