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

Tamanho: px
Começar a partir da página:

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

Transcrição

1 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

2 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

3 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

4 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.

5 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.

6 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.

7 Lista de Figuras 1 A IDE ShaderLabs rodando em um sistema operacional GNU/Linux.. p Funcionalidades não exibidas na Figura p Pipeline de transformações e sistemas de coordenadas p Frustum de visão em uma projeção em perspectiva p Redefinição da primitiva para que toda ela esteja dentro do frustum de visão p Hierarquia para programação gráfica p Pipeline com shaders p Shader Designer p RenderMonkey p MeShade p WebGL Shader Lab p ShaderMaker p Câmera screen-based e rotação p Câmera object-based e rotação p Etapas do modelo Cascata de desenvolvimento p O Manifesto Ágil p Quadro de acompanhamento de um projeto ágil p Gráfco Burndown p Gráfico de cobertura de testes p Exemplo de cartão de história de usuário do ShaderLabs p A evolução da satisfação do cliente com novas funcionalidades p. 44

8 22 Avaliação do par de perguntas por referência cruzada p Tabulação dos resultados no Modelo Kano p Histórico da velocidade de desenvolvimento do projeto p Cumulative flow chart p Exemplo de semanário p Modelo de classes p Mapeamento dos pontos da tela em pontos da esfera p Sentido da rotação do arcball quando os pontos do mapeamento estão fora do círculo p Mapeamento dos círculos p Linha do tempo das funcionalidades do projeto p Resultado gerado pelo ShaderLabs de uma possível solução para um dos trabalho de Computação Gráfica I p Resultados para o trabalho de computação gráfica gerados por diferentes alunos p. 65

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

10 Sumário 1 Introdução p Motivação p O que é o ShaderLabs? p Estrutura deste trabalho p Computação gráfica e programação em GPU p Pipeline gráfico p Evolução das placas de vídeo p API para programação gráfica p Estágios programáveis p IDEs de programação gráfica p Shader Designer p RenderMonkey p MeShade p WebGL Shader Lab p ShaderMaker p Modelos de manipulação de câmera p Desenvolvimento ágil p Modelo de Desenvolvimento Ágil p O Manifesto Ágil p Gestão de um projeto ágil de software p. 34

11 3.1.3 Práticas de desenvolvimento mais utilizadas p Requisitos Ágeis - Product Backlog p Histórias de usuário p Pontos de história e priorização p Minimun Valuable Product (MVP) p O modelo Kano de satisfação do cliente p Introdução p O Método Kano aplicado a requisitos de software p Desenvolvimento do ShaderLabs p Aplicação da metodologia ágil p Perfis de usuário p MVP e usabilidade do ShaderLabs p Aplicação do modelo Kano p Andamento do projeto p Evolução do ShaderLabs p Implementação p Tecnologias utilizadas e documentação técnica p Modelo de manipulação de câmera p Estudo de Caso - o trabalho na disciplina Computação Gráfica I p Conclusões e trabalhos futuros p Conclusões p Trabalhos Futuros p Novas funcionalidades p Tutorial de GLSL p Divulgação externa p. 68

12 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

13 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-

14 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;

15 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 vértices Plano com aproximadamente vértices

16 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 p/shader-lab/. 1 GNU General Public License. Sua descrição pode ser vista em gpl.html

17 1.3 Estrutura deste trabalho 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.

18 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

19 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

20 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).

21 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.

22 2.4 Estágios programáveis 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.

23 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

24 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 Shader Designer Fonte: 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;

25 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 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.

26 2.5 IDEs de programação gráfica 25 Fonte: Figura 9: RenderMonkey 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;

27 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 MeShade Fonte: 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.

28 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 WebGL Shader Lab Fonte: 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 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.

29 2.6 Modelos de manipulação de câmera 28 Fonte: 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

30 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.

31 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

32 3.1 Modelo de Desenvolvimento Ágil 31 fonte: 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-

33 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 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.

34 3.1 Modelo de Desenvolvimento Ágil 33 fonte: 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

35 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 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 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.

36 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 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

37 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: 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 Funcionalidades separadas para implementação na iteração corrente.

38 3.1 Modelo de Desenvolvimento Ágil 37 fonte: Figura 19: Gráfico de cobertura de testes Práticas de desenvolvimento mais utilizadas 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.

39 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 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.

40 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 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

41 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 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

42 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 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

43 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 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.

44 3.3 O modelo Kano de satisfação do cliente O modelo Kano de satisfação do cliente 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

45 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 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.

46 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;

47 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.

48 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 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,

49 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 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 na página 42

50 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 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 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?

51 4.1 Aplicação da metodologia ágil 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? 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.

52 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 obrigatória Controlar configurações OpenGL diferencial Auto-completion diferencial Modelos próprios diferencial Propriedades de fonte indiferente Cor para erro de compilação diferencial Limpar output indiferente Mudar a posição da luz obrigatória Exibir numeração das linhas obrigatória Visualizar mais modelos pré-definidos indiferente Navegar pelas abas indefinido Suporte de hardware diferencial Zoom no modelo 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 diferencial Modelos próprios diferencial Propriedades de fonte indiferente Cor para erro de compilação diferencial Limpar output indiferente Mudar a posição da luz linear Exibir numeração das linhas indefinido Visualizar mais modelos pré-definidos diferencial Navegar pelas abas diferencial Suporte de hardware diferencial Zoom no modelo diferencial Neste segundo experimento, os resultados mais uma vez se mostraram inconclusivos, por razões que serão exploradas na seção 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-

53 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 indiferente Modelos próprios indefinido Propriedades de fonte indefinido Cor para erro de compilação diferencial Limpar output indiferente Mudar a posição da luz obrigatória Exibir numeração das linhas obrigatória Visualizar mais modelos pré-definidos indiferente Navegar pelas abas obrigatória Suporte de hardware diferencial Zoom no modelo 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 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 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

54 4.1 Aplicação da metodologia ágil 53 justificar seu esforço de implementação 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 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: Velocidade Uma vez que os requisitos de software foram descritos utilizando-se histórias de usuário (seção na página 40) e devidamente pontuados de acordo com sua dificuldade de implementação utilizando-se pontos de história (seção 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.

55 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

56 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 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/ Definidas dentro de um intervalo de tempo e com terefas pré-determinadas

57 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 na página 35. As figuras 27b e 27a mostram imagens desse quadro.

58 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 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.

59 4.2 Implementação 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

60 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.

61 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 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.

62 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.

63 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

64 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.

65 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

66 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 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.

OpenGL. Uma Abordagem Prática e Objetiva. Marcelo Cohen Isabel Harb Manssour. Novatec Editora

OpenGL. Uma Abordagem Prática e Objetiva. Marcelo Cohen Isabel Harb Manssour. Novatec Editora OpenGL Uma Abordagem Prática e Objetiva Marcelo Cohen Isabel Harb Manssour Novatec Editora Capítulo 1 Introdução A Computação Gráfica é uma área da Ciência da Computação que se dedica ao estudo e ao desenvolvimento

Leia mais

Bruno Pereira Evangelista. www.brunoevangelista.com

Bruno Pereira Evangelista. www.brunoevangelista.com Bruno Pereira Evangelista www.brunoevangelista.com 2 Introdução Shaders Pipeline de Renderização Evolução dos Shaders Como Programar Shaders Programando Shaders com XNA Ferramentas Conclusões 3 Durante

Leia mais

Utilização. de Shaders de efeitos realistas para jogos. Bruno Pereira Evangelista. Pontifícia Universidade Católica de Minas Gerais

Utilização. de Shaders de efeitos realistas para jogos. Bruno Pereira Evangelista. Pontifícia Universidade Católica de Minas Gerais Utilização de Shaders para criação de efeitos realistas para jogos Bruno Pereira Evangelista Pontifícia Universidade Católica de Minas Gerais Sumário 2/48 Apresentação pessoal Introdução Pipeline de renderização

Leia mais

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com

Processo de Desenvolvimento de Software. Unidade V Modelagem de PDS. Luiz Leão luizleao@gmail.com http://www.luizleao.com Processo de Desenvolvimento de Software Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo Programático desta aula Modelo Cascata (Waterfall) ou TOP DOWN. Modelo Iterativo. Metodologia Ágil.

Leia mais

Manual do Cantor. Alexander Rieder Tradução: Marcus Gama

Manual do Cantor. Alexander Rieder Tradução: Marcus Gama Alexander Rieder Tradução: Marcus Gama 2 Conteúdo 1 Introdução 5 2 Usando o Cantor 6 2.1 Recursos do Cantor..................................... 6 2.2 As infraestruturas do Cantor...............................

Leia mais

Formação em game programming: 01 - Introdução à programação

Formação em game programming: 01 - Introdução à programação Formação em game programming: Para que um jogo eletrônico funcione adequadamente como foi projetado, é necessário que ele esteja corretamente programado. Todas as funções de controle de personagens e objetos

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Microsoft Visual Studio Express 2012 for Windows Desktop

Microsoft Visual Studio Express 2012 for Windows Desktop Microsoft Visual Studio Express 2012 for Windows Desktop Apresentação da ferramenta Professor: Danilo Giacobo Página pessoal: www.danilogiacobo.eti.br E-mail: danilogiacobo@gmail.com 1 Introdução Visual

Leia mais

Excel 2010 Modulo II

Excel 2010 Modulo II Excel 2010 Modulo II Sumário Nomeando intervalos de células... 1 Classificação e filtro de dados... 3 Subtotais... 6 Validação e auditoria de dados... 8 Validação e auditoria de dados... 9 Cenários...

Leia mais

Linguagem de Programação Visual

Linguagem de Programação Visual Linguagem de Programação Visual Unidade 1 Ambiente de desenvolvimento Curso Técnico em Informática SUMÁRIO INTRODUÇÃO... 3 SOBRE O JAVA... 3 AMBIENTE DE DESENVOLVIMENTO... 5 RECURSOS DA FERRAMENTA NETBEANS...

Leia mais

Capítulo 7 O Gerenciador de Arquivos

Capítulo 7 O Gerenciador de Arquivos Capítulo 7 O Gerenciador de Arquivos Neste capítulo nós iremos examinar as características da interface do gerenciador de arquivos Konqueror. Através dele realizaremos as principais operações com arquivos

Leia mais

X3DOM E WEBGL: O 3D INDEPENDENTE NA WEB

X3DOM E WEBGL: O 3D INDEPENDENTE NA WEB X3DOM E WEBGL: O 3D INDEPENDENTE NA WEB Augusto Francisco Ferbonink¹, Willian Barbosa Magalhães 1 Universidade Paranaense (UNIPAR) Paranavaí PR Brasil aferbonink@gmail.com wmagalhães@unipar.com Resumo.

Leia mais

Metodologias Ágeis. Aécio Costa

Metodologias Ágeis. Aécio Costa Metodologias Ágeis Aécio Costa Metodologias Ágeis Problema: Processo de desenvolvimento de Software Imprevisível e complicado. Empírico: Aceita imprevisibilidade, porém tem mecanismos de ação corretiva.

Leia mais

Conhecendo o Visual FoxPro 8.0 Parte 3

Conhecendo o Visual FoxPro 8.0 Parte 3 AULA Conhecendo o Visual FoxPro 8.0 Parte 3 Continuando nossa saga pelas ferramentas do Visual FoxPro 8.0, hoje vamos conhecer mais algumas. A Ferramenta Class Designer A Class Designer é a ferramenta

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

Leia mais

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES

INDICE 3.APLICAÇÕES QUE PODEM SER DESENVOLVIDAS COM O USO DO SAXES w w w. i d e a l o g i c. c o m. b r INDICE 1.APRESENTAÇÃO 2.ESPECIFICAÇÃO DOS RECURSOS DO SOFTWARE SAXES 2.1. Funcionalidades comuns a outras ferramentas similares 2.2. Funcionalidades próprias do software

Leia mais

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa

Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Desenvolvendo e Integrando Serviços Multiplataforma de TV Digital Interativa Agenda Introdução Aplicações interativas de TV Digital Desafios de layout e usabilidade Laboratório de usabilidade Desafios

Leia mais

5 Detalhes da Implementação

5 Detalhes da Implementação Detalhes da Implementação 101 5 Detalhes da Implementação Neste capítulo descreveremos detalhes da implementação do Explorator que foi desenvolvido usando o paradigma MVC 45 e o paradigma de CoC 46 (Convention

Leia mais

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br

SCRUM. Fabrício Sousa fabbricio7@yahoo.com.br SCRUM Fabrício Sousa fabbricio7@yahoo.com.br Introdução 2 2001 Encontro onde profissionais e acadêmicos da área de desenvolvimento de software de mostraram seu descontentamento com a maneira com que os

Leia mais

ODG Auto Acessórios Ltda www.odginstruments.com.br Versão 2.0 FEVEREIRO 2009

ODG Auto Acessórios Ltda www.odginstruments.com.br Versão 2.0 FEVEREIRO 2009 ODG Auto Acessórios Ltda www.odginstruments.com.br Versão 2.0 FEVEREIRO 2009 1 INDICE 1. Instalação do Software...3 2. Tela Inicial...3 3. Criando arquivo de configurações (Alt + C + C)...4 3.1 Sensores

Leia mais

MICROSOFT WORD 2007. George Gomes Cabral

MICROSOFT WORD 2007. George Gomes Cabral MICROSOFT WORD 2007 George Gomes Cabral AMBIENTE DE TRABALHO 1. Barra de título 2. Aba (agrupa as antigas barras de menus e barra de ferramentas) 3. Botão do Office 4. Botão salvar 5. Botão de acesso à

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Manual do Teclado de Satisfação Local Versão 1.4.1

Manual do Teclado de Satisfação Local Versão 1.4.1 Manual do Teclado de Satisfação Local Versão 1.4.1 26 de agosto de 2015 Departamento de Engenharia de Produto (DENP) SEAT Sistemas Eletrônicos de Atendimento 1. Introdução O Teclado de Satisfação é uma

Leia mais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais Arquitetura de Computadores Introdução aos Sistemas Operacionais O que é um Sistema Operacional? Programa que atua como um intermediário entre um usuário do computador ou um programa e o hardware. Os 4

Leia mais

Conectando Bancos de Dados Microsoft Access no BrOffice.org Base. fornecido pelo Projeto de Documentação do BrOffice.org

Conectando Bancos de Dados Microsoft Access no BrOffice.org Base. fornecido pelo Projeto de Documentação do BrOffice.org Conectando Bancos de Dados Microsoft Access no BrOffice.org Base fornecido pelo Projeto de Documentação do BrOffice.org Índice 1 Introdução...2 1.1 Versão... 2 1.2 Licenciamento...2 1.3 Mensagem do Projeto

Leia mais

Lógica de Programação

Lógica de Programação Lógica de Programação Unidade 4 Ambiente de desenvolvimento Java QI ESCOLAS E FACULDADES Curso Técnico em Informática SUMÁRIO A LINGUAGEM JAVA... 3 JVM, JRE, JDK... 3 BYTECODE... 3 PREPARANDO O AMBIENTE

Leia mais

Tecnólogo em Análise e Desenvolvimento de Sistemas

Tecnólogo em Análise e Desenvolvimento de Sistemas Tecnólogo em Análise e Desenvolvimento de Sistemas O conteúdo deste documento tem como objetivos geral introduzir conceitos mínimos sobre sistemas operacionais e máquinas virtuais para posteriormente utilizar

Leia mais

Sincronização do Catálogo de Endereços no MDaemon 6.x com o uso do ComAgent, LDAP, MAPI e WAB

Sincronização do Catálogo de Endereços no MDaemon 6.x com o uso do ComAgent, LDAP, MAPI e WAB Sincronização do Catálogo de Endereços no MDaemon 6.x com o uso do ComAgent, LDAP, MAPI e WAB Alt-N Technologies, Ltd 1179 Corporate Drive West, #103 Arlington, TX 76006 Tel: (817) 652-0204 2002 Alt-N

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 05 PROFª BRUNO CALEGARO Santa Maria, 24 de Setembro de 2013. Revisão aula anterior Processos de Software Engenharia de Requisitos, Projeto,

Leia mais

Unidade 1: O Painel de Controle do Excel *

Unidade 1: O Painel de Controle do Excel * Unidade 1: O Painel de Controle do Excel * material do 2010* 1.0 Introdução O Excel nos ajuda a compreender melhor os dados graças à sua organização em células (organizadas em linhas e colunas) e ao uso

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Manual do Teclado de Satisfação Local Versão 1.2.2

Manual do Teclado de Satisfação Local Versão 1.2.2 Manual do Teclado de Satisfação Local Versão 1.2.2 18 de fevereiro de 2015 Departamento de Engenharia de Produto (DENP) SEAT Sistemas Eletrônicos de Atendimento 1. Introdução O Teclado de Satisfação é

Leia mais

Universidade Federal do Rio de Janeiro NCE/PGTIAE. Tutorial SweetHome3D

Universidade Federal do Rio de Janeiro NCE/PGTIAE. Tutorial SweetHome3D Universidade Federal do Rio de Janeiro NCE/PGTIAE Tutorial SweetHome3D Trabalho apresentado ao Prof. Carlo na Disciplina de Software Livre no curso Pós Graduação em Tecnologia da Informação Aplicada a

Leia mais

PROGRAMANDO ANDROID NA IDE ECLIPSE GABRIEL NUNES, JEAN CARVALHO TURMA TI7

PROGRAMANDO ANDROID NA IDE ECLIPSE GABRIEL NUNES, JEAN CARVALHO TURMA TI7 Serviço Nacional de Aprendizagem Comercial do Rio Grande do Sul Informação e Comunicação: Habilitação Técnica de Nível Médio Técnico em Informática Programação Android na IDE Eclipse PROGRAMANDO ANDROID

Leia mais

PÓS-GRADUAÇÃO EM MATEMÁTICA COMPUTACIONAL INFORMÁTICA INSTRUMENTAL

PÓS-GRADUAÇÃO EM MATEMÁTICA COMPUTACIONAL INFORMÁTICA INSTRUMENTAL PÓS-GRADUAÇÃO EM MATEMÁTICA COMPUTACIONAL INFORMÁTICA INSTRUMENTAL Introdução Aula 03: Pacote Microsoft Office 2007 O Pacote Microsoft Office é um conjunto de aplicativos composto, principalmente, pelos

Leia mais

2. O AMBIENTE DE PROGRAMAÇÃO EM C

2. O AMBIENTE DE PROGRAMAÇÃO EM C 2. O AMBIENTE DE PROGRAMAÇÃO EM C Este capítulo trata de colocar a linguagem C para funcionar em um ambiente de programação, concentrando-se no compilador GNU Compiler Collection (gcc). Mas qualquer outro

Leia mais

Parte I Introdução ActionScript_30_01.indd 1 5/11/2010 08:29:29

Parte I Introdução ActionScript_30_01.indd 1 5/11/2010 08:29:29 Parte I Introdução ActionScript_30_01.indd 1 5/11/2010 08:29:29 ActionScript_30_01.indd 2 5/11/2010 08:29:34 Aprendendo uma nova linguagem... ActionScript é uma linguagem e, como um novo idioma ou a linguagem

Leia mais

Informática básica Telecentro/Infocentro Acessa-SP

Informática básica Telecentro/Infocentro Acessa-SP Informática básica Telecentro/Infocentro Acessa-SP Aula de hoje: Periférico de entrada/saída, memória, vírus, Windows, barra tarefas. Prof: Lucas Aureo Guidastre Memória A memória RAM é um componente essencial

Leia mais

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 Rational Quality Manager Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 1 Informações Gerais Informações Gerais sobre o RQM http://www-01.ibm.com/software/awdtools/rqm/ Link para o RQM https://rqmtreina.mvrec.local:9443/jazz/web/console

Leia mais

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto

Resumo de TCC Desenvolvimento de um sistema ERP com foco nas tecnologias de software livre / código aberto UFSC - Universidade Federal de Santa Catarina CTC Centro Tecnológico INE Departamento de Informática e Estatística INE5631 Projetos I Prof. Renato Cislaghi Resumo de TCC Desenvolvimento de um sistema ERP

Leia mais

II Torneio de Programação em LabVIEW

II Torneio de Programação em LabVIEW Desenvolvimento da Aplicação II Torneio de Programação em LabVIEW Seção I: Requisitos Gerais A aplicação submetida deverá atender, pelo menos, às exigências de funcionamento descritas na Seção II deste

Leia mais

1 REQUISITOS BÁSICOS PARA INSTALAR O SMS PC REMOTO

1 REQUISITOS BÁSICOS PARA INSTALAR O SMS PC REMOTO 1 ÍNDICE 1 REQUISITOS BÁSICOS PARA INSTALAR O SMS PC REMOTO... 3 1.1 REQUISITOS BASICOS DE SOFTWARE... 3 1.2 REQUISITOS BASICOS DE HARDWARE... 3 2 EXECUTANDO O INSTALADOR... 3 2.1 PASSO 01... 3 2.2 PASSO

Leia mais

Aula 1 - Introdução e configuração de ambiente de desenvolvimento

Aula 1 - Introdução e configuração de ambiente de desenvolvimento Aula 1 - Introdução e configuração de ambiente de desenvolvimento Olá, seja bem-vindo à primeira aula do curso para desenvolvedor de Android, neste curso você irá aprender a criar aplicativos para dispositivos

Leia mais

Manual do Teclado de Satisfação Online Web Opinião Versão 1.0.5

Manual do Teclado de Satisfação Online Web Opinião Versão 1.0.5 Manual do Teclado de Satisfação Online Web Opinião Versão 1.0.5 09 de julho de 2015 Departamento de Engenharia de Produto (DENP) SEAT Sistemas Eletrônicos de Atendimento 1. Introdução O Teclado de Satisfação

Leia mais

Sistema topograph 98. Tutorial Módulo Projetos

Sistema topograph 98. Tutorial Módulo Projetos Sistema topograph 98 Tutorial Módulo Projetos Como abrir um projeto existente _ 1. Na área de trabalho do Windows, procure o ícone do topograph e dê um duplo clique sobre ele para carregar o programa.

Leia mais

Linux. Educacional. Tutorial Buzzword

Linux. Educacional. Tutorial Buzzword Linux Educacional Tutorial Buzzword Para trabalhar com o programa Buzzword online, é necessário que crie uma conta no site. Para isso acesse o endereço - https://buzzword.acrobat.com/ Para criar uma conta

Leia mais

Open Graphics Library OpenGL

Open Graphics Library OpenGL Open Graphics Library OpenGL Filipe Gonçalves Barreto de Oliveira Castilho Nuno Alexandre Simões Aires da Costa Departamento de Engenharia Informática Universidade de Coimbra 3030 Coimbra, Portugal http://student.dei.uc.pt/~fgonc/opengl/

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2015 Desenvolvimento Rápido de Software 2 1 Para quê o Desenvolvimento Rápido de Software? Os negócios

Leia mais

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO

LEI DE ACESSO A INFORMAÇÃO DIREITO DO CIDADÃO DESCRIÇÃO DO SIGAI O SIGAI (Sistema Integrado de Gestão do Acesso à Informação) é uma solução de software que foi desenvolvida para automatizar os processos administrativos e operacionais visando a atender

Leia mais

4 Conversor EDTV Raw. 4.1 Arquitetura

4 Conversor EDTV Raw. 4.1 Arquitetura 4 Conversor EDTV Raw O conversor EDTV Raw é o programa que lê um documento escrito no perfil NCL EDTV e gera um documento Raw equivalente, i.e. que define a mesma apresentação. Este capítulo, apresenta

Leia mais

Guia. PDA e SmartPhones. Windows Mobile, Pocket PC e CE.

Guia. PDA e SmartPhones. Windows Mobile, Pocket PC e CE. Guia PDA e SmartPhones Windows Mobile, Pocket PC e CE. Referência completa para o integrador do sistema Module. Aborda os recursos necessários para a itulização, instalação do software e importação das

Leia mais

Grifon Alerta. Manual do Usuário

Grifon Alerta. Manual do Usuário Grifon Alerta Manual do Usuário Sumário Sobre a Grifon Brasil... 4 Recortes eletrônicos... 4 Grifon Alerta Cliente... 4 Visão Geral... 4 Instalação... 5 Pré-requisitos... 5 Passo a passo para a instalação...

Leia mais

PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS

PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS PROGRAMAÇÃO PARA DISPOSITIVOS MÓVEIS Depurando aplicações Professor: Danilo Giacobo OBJETIVOS DA AULA Aprender dicas e técnicas para encontrar erros em aplicações Android. Conhecer os recursos que auxiliam

Leia mais

Sistema operacional Windows 7, Windows Live Mail e Adobe Reader. Sistemas operacionais em concursos públicos

Sistema operacional Windows 7, Windows Live Mail e Adobe Reader. Sistemas operacionais em concursos públicos Sistema operacional Windows 7, Windows Live Mail e Adobe Reader Sistemas operacionais em concursos públicos Antes de tudo é importante relembrarmos que o sistema operacional é um tipo de software com a

Leia mais

Lição 4 - Primeiros passos no Linux Ubuntu 11.04

Lição 4 - Primeiros passos no Linux Ubuntu 11.04 Lição 4 - Primeiros passos no Linux Ubuntu 11.04 Olá Aluno Os objetivos específicos desta lição são: - reconhecer o Ubuntu como mais uma alternativa de sistema operacional; - conhecer os elementos da área

Leia mais

Para que o NSBASIC funcione corretamente em seu computador, você deve garantir que o mesmo tenha as seguintes características:

Para que o NSBASIC funcione corretamente em seu computador, você deve garantir que o mesmo tenha as seguintes características: Cerne Tecnologia www.cerne-tec.com.br Conhecendo o NSBASIC para Palm Vitor Amadeu Vitor@cerne-tec.com.br 1. Introdução Iremos neste artigo abordar a programação em BASIC para o Palm OS. Para isso, precisaremos

Leia mais

FERRAMENTAS DE COLABORAÇÃO CORPORATIVA

FERRAMENTAS DE COLABORAÇÃO CORPORATIVA FERRAMENTAS DE COLABORAÇÃO CORPORATIVA Manual de Utilização Google Grupos Sumário (Clique sobre a opção desejada para ir direto à página correspondente) Utilização do Google Grupos Introdução... 3 Página

Leia mais

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com Sistemas Operacionais 2014 Introdução Alexandre Augusto Giron alexandre.a.giron@gmail.com Roteiro Sistemas Operacionais Histórico Estrutura de SO Principais Funções do SO Interrupções Chamadas de Sistema

Leia mais

O que há de novo. Audaces Idea

O que há de novo. Audaces Idea O que há de novo Audaces Idea Com o propósito de produzir tecnologia de ponta, o principal requisito da Política de Qualidade da Audaces é buscar a melhoria contínua de seus produtos e serviços. Inovadora

Leia mais

Manual Laboratório. ICS Sistemas de Gestão em Saúde ICS 01/01/2014

Manual Laboratório. ICS Sistemas de Gestão em Saúde ICS 01/01/2014 2014 Manual Laboratório ICS Sistemas de Gestão em Saúde ICS 01/01/2014 Sumário Acesso ao Sistema... 2 Menu Cadastros... 4 Cadastro de usuários... 4 Inclusão de Novo Usuário... 5 Alteração de usuários...

Leia mais

GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS

GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS Trabalho de graduação do Curso de Ciência da Computação do Setor de Ciências Exatas da Universidade Federal do Paraná. Professor: André Luiz Pires Guedes CURITIBA

Leia mais

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação

SCRUM. Desafios e benefícios trazidos pela implementação do método ágil SCRUM. Conhecimento em Tecnologia da Informação Conhecimento em Tecnologia da Informação SCRUM Desafios e benefícios trazidos pela implementação do método ágil SCRUM 2011 Bridge Consulting Apresentação Há muitos anos, empresas e equipes de desenvolvimento

Leia mais

Manual Simulador de Loja

Manual Simulador de Loja Manual Simulador de Loja Índice Início Menu Loja Modelo Loja Modelo Menu Criar Minha Loja Criar Minha Loja Abrir Projeto Salvo Teste Seu Conhecimento 0 04 05 08 09 8 9 0 Início 5 4 Figura 00. Tela inicial.

Leia mais

Grandes Montagens. Uma grande montagem é qualquer montagem complexa o suficiente para maximizar os recursos do sistema e prejudicar a produtividade.

Grandes Montagens. Uma grande montagem é qualquer montagem complexa o suficiente para maximizar os recursos do sistema e prejudicar a produtividade. Grandes Montagens O que é uma Grande Montagem? Uma grande montagem é qualquer montagem complexa o suficiente para maximizar os recursos do sistema e prejudicar a produtividade. Que fatores afetam o desempenho

Leia mais

CURSO TECNOLÓGICO 2008/01 1º SEMESTRE. Programação e Estruturas de Dados Fundamentais

CURSO TECNOLÓGICO 2008/01 1º SEMESTRE. Programação e Estruturas de Dados Fundamentais 1º SEMESTRE Programação e Estruturas de Dados Fundamentais 8 Créditos Desenvolver a lógica de programação através da construção de algoritmos utilizando português estruturado Representar a solução de problemas

Leia mais

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009

Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga. Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes de carga Um artigo técnico da Oracle Junho de 2009 Identificação rápida de gargalos Uma forma mais eficiente de realizar testes

Leia mais

Portal Contador Parceiro

Portal Contador Parceiro Portal Contador Parceiro Manual do Usuário Produzido por: Informática Educativa 1. Portal Contador Parceiro... 03 2. Acesso ao Portal... 04 3. Profissionais...11 4. Restrito...16 4.1 Perfil... 18 4.2 Artigos...

Leia mais

XXIV SEMANA MATEMÁTICA

XXIV SEMANA MATEMÁTICA XXIV SEMANA ACADÊMICA DA MATEMÁTICA Minicurso: Produção de Páginas Web para Professores de Matemática Projeto de Extensão: Uma Articulação entre a Matemática e a Informática como Instrumento para a Cidadania

Leia mais

Tutorial: Abrindo Vídeos e Medindo Comprimentos no ImageJ

Tutorial: Abrindo Vídeos e Medindo Comprimentos no ImageJ 1 1. Introdução Tutorial: Abrindo Vídeos e Medindo Comprimentos no ImageJ O ImageJ é um software livre (freeware) que pode ser obtido gratuitamente no site http://rsb.info.nih.gov/ij/. Esse software é

Leia mais

SISTEMAS OPERACIONAIS ABERTOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

SISTEMAS OPERACIONAIS ABERTOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 9-1. O KERNEL DO LINUX Nos sistemas GNU/Linux, todas as distribuições baseadas nos sistemas GNU/Linux existentes são compatíveis, graças ao uso de um kernel único desenvolvido por uma equipe de

Leia mais

Crescendo e Inovando com um Parceiro Confiável de Suporte

Crescendo e Inovando com um Parceiro Confiável de Suporte IBM Global Technology Services Manutenção e suporte técnico Crescendo e Inovando com um Parceiro Confiável de Suporte Uma abordagem inovadora em suporte técnico 2 Crescendo e Inovando com um Parceiro Confiável

Leia mais

Maximus Software Soluções Tecnológicas Ltda. A empresa que desenvolve o seu Produto ao Máximo

Maximus Software Soluções Tecnológicas Ltda. A empresa que desenvolve o seu Produto ao Máximo Maximus Software Soluções Tecnológicas Ltda. A empresa que desenvolve o seu Produto ao Máximo FARMAINFOR Modernização da Farmácia do Hospital Mater Day Documento de Requisitos Versão 2.0 Histórico de Revisão

Leia mais

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE. Modelos de Processo de Desenvolvimento de Software PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Introdução Modelos de Processo de Desenvolvimento de Software Os modelos de processos de desenvolvimento de software surgiram pela necessidade de dar resposta às

Leia mais

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de:

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de: i Sumário 1 Introdução 1 1.1 Linguagens....................................... 1 1.2 O que é um Compilador?................................ 2 1.3 Processadores de Programas: Compiladores, Interpretadores

Leia mais

Princípios de Design TRADUÇÃO DE TATIANE CRISTINE ARNOLD, DO ARTIGO IBM DESIGN: DESIGN PRINCIPLES CHECKLIST.

Princípios de Design TRADUÇÃO DE TATIANE CRISTINE ARNOLD, DO ARTIGO IBM DESIGN: DESIGN PRINCIPLES CHECKLIST. Princípios de Design TRADUÇÃO DE TATIANE CRISTINE ARNOLD, DO ARTIGO IBM DESIGN: DESIGN PRINCIPLES CHECKLIST. Um software deve ser projetado para simplificar tarefas e criar experiências positivas para

Leia mais

FERRAMENTAS PARA DESENVOLVIMENTO EM C#

FERRAMENTAS PARA DESENVOLVIMENTO EM C# FERRAMENTAS PARA DESENVOLVIMENTO EM C# Camila Sanches Navarro 1,2, Wyllian Fressatti 2 ¹Universidade paranaense (Unipar) Paranavaí PR Brasil sanchesnavarro@gmail.com wyllian@unipar.br Resumo. Este artigo

Leia mais

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT

DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT DOMAIN-DRIVEN DESIGN E TEST-DRIVEN DEVELOPMENT Jaqueline Rissá Franco email: jaquerifr@gmail.com Karla Marturelli Mattos Luciano Mathias Doll João Almeida Resumo: Este artigo mostra novas abordagens na

Leia mais

1. EXCEL 7 1.1. PLANILHAS ELETRÔNICAS 1.2. CARREGAMENTO DO EXCEL 7

1. EXCEL 7 1.1. PLANILHAS ELETRÔNICAS 1.2. CARREGAMENTO DO EXCEL 7 1. EXCEL 1.1. PLANILHAS ELETRÔNICAS As planilhas eletrônicas ficarão na história da computação como um dos maiores propulsores da microinformática. Elas são, por si sós, praticamente a causa da explosão

Leia mais

Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br

Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br Moodle FTEC Versão 2.0 Manual do Usuário Acesse a área de LOGIN do site da FTEC www.ftec.com.br Índice Como acessar o Moodle Editando seu PERFIL Editando o curso / disciplina no Moodle Incluindo Recursos

Leia mais

UMA ABORDAGEM COMPARATIVA ENTRE AS LINGUAGENS DE PROGRAMAÇÃO JAVA E C#

UMA ABORDAGEM COMPARATIVA ENTRE AS LINGUAGENS DE PROGRAMAÇÃO JAVA E C# UMA ABORDAGEM COMPARATIVA ENTRE AS LINGUAGENS DE PROGRAMAÇÃO JAVA E C# Robson Bartelli¹, Wyllian Fressatti¹. ¹Universidade Paranaense (Unipar) Paranavaí PR Brasil robson_lpbartelli@yahoo.com.br,wyllian@unipar.br

Leia mais

Algoritmos em Javascript

Algoritmos em Javascript Algoritmos em Javascript Sumário Algoritmos 1 O que é um programa? 1 Entrada e Saída de Dados 3 Programando 4 O que é necessário para programar 4 em JavaScript? Variáveis 5 Tipos de Variáveis 6 Arrays

Leia mais

Introdução. à Linguagem JAVA. Prof. Dr. Jesus, Edison O. Instituto de Matemática e Computação. Laboratório de Visão Computacional

Introdução. à Linguagem JAVA. Prof. Dr. Jesus, Edison O. Instituto de Matemática e Computação. Laboratório de Visão Computacional Introdução à Linguagem JAVA Prof. Dr. Jesus, Edison O. Instituto de Matemática e Computação Laboratório de Visão Computacional Vantagens do Java Independência de plataforma; Sintaxe semelhante às linguagens

Leia mais

Instalando o IIS 7 no Windows Server 2008

Instalando o IIS 7 no Windows Server 2008 Goiânia, 16/09/2013 Aluno: Rafael Vitor Prof. Kelly Instalando o IIS 7 no Windows Server 2008 Objetivo Esse tutorial tem como objetivo demonstrar como instalar e configurar o IIS 7.0 no Windows Server

Leia mais

Instalando o IIS 7 no Windows Server 2008

Instalando o IIS 7 no Windows Server 2008 Goiânia, 16/09/2013 Aluno: Rafael Vitor Prof. Kelly Instalando o IIS 7 no Windows Server 2008 Objetivo Esse tutorial tem como objetivo demonstrar como instalar e configurar o IIS 7.0 no Windows Server

Leia mais

PORTAL DE COMPRAS SÃO JOSÉ DO RIO PRETO

PORTAL DE COMPRAS SÃO JOSÉ DO RIO PRETO Compra Direta - Guia do Fornecedor PORTAL DE COMPRAS SÃO JOSÉ DO RIO PRETO Página As informações contidas neste documento, incluindo quaisquer URLs e outras possíveis referências a web sites, estão sujeitas

Leia mais

Conhecendo o Visual FoxPro 8.0 Parte 2

Conhecendo o Visual FoxPro 8.0 Parte 2 AULA Conhecendo o Visual FoxPro 8.0 Parte 2 Na aula anterior, vimos sobre: a) Janela de comando b) Gerenciador de Projetos c) Database Designer e Table Designer Prosseguiremos então a conhecer as ferramentas

Leia mais

Microsoft Excel 2000. Alan Cleber Borim - alan.borim@poli.usp.br. http://www.pcs.usp.br/~alan

Microsoft Excel 2000. Alan Cleber Borim - alan.borim@poli.usp.br. http://www.pcs.usp.br/~alan Microsoft Excel 2000 Alan Cleber Borim - alan.borim@poli.usp.br http://www.pcs.usp.br/~alan Microsoft Índice 1.0 Microsoft Excel 2000 3 1.1 Acessando o Excel 3 1.2 Como sair do Excel 3 1.3 Elementos da

Leia mais

AVISO. Treinamento GVcollege Módulo Ficha Complementar

AVISO. Treinamento GVcollege Módulo Ficha Complementar AVISO O conteúdo deste documento é de propriedade intelectual exclusiva da GVDASA Sistemas e está sujeito a alterações sem aviso prévio. Nenhuma parte desta publicação pode ser reproduzida nem transmitida

Leia mais

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br

Workshop SCRUM. Versão 5 Out 2010 RFS. rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos 2006 e 2010 Objetivo: Estudo de Caso Objetivo: Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em projeto de desenvolvimento de

Leia mais

Linha Silk: a maneira leve para testar, desenvolver e gerenciar

Linha Silk: a maneira leve para testar, desenvolver e gerenciar Linha : a maneira leve para testar, desenvolver e gerenciar Leve Criado apenas com a funcionalidade que você precisa Barato Do uso gratuito ao licenciamento flexível Eficiente Software fácil de usar e

Leia mais

Técnicas para Animação de Imagens em Jogos 2D Utilizando Java

Técnicas para Animação de Imagens em Jogos 2D Utilizando Java Técnicas para Animação de Imagens em Jogos 2D Utilizando Java Silvano Maneck Malfatti 1 1 Faculdade Católica do Tocantins (FACTO) Palmas TO Brasil Malfatti@catolica-to.edu.br Resumo. Um dos recursos que

Leia mais

Início Rápido Desktop. 2015 Release 1 Xojo, Inc.

Início Rápido Desktop. 2015 Release 1 Xojo, Inc. Início Rápido Desktop 2015 Release 1 Xojo, Inc. Capítulo 1 Introdução Bem-vindo ao Xojo, O jeito mais fácil de criar aplicativos multi-plataforma para Desktop e Web. Seção 1 Sobre o Início Rápido para

Leia mais

ÍNDICE... 2 INTRODUÇÃO... 3. A série... 3

ÍNDICE... 2 INTRODUÇÃO... 3. A série... 3 WORD 2007 E 2010 ÍNDICE ÍNDICE... 2 INTRODUÇÃO... 3 A série... 3 01 CAPTURAS DE TELA WORD 2010... 3 02 IMAGENS 2007/2010... 5 03 NOTAS DE RODAPÉ... 13 04 NUMERAÇÃO DE PÁGINAS... 15 05 CONTAR PALAVRAS...

Leia mais

O Primeiro Programa em Visual Studio.net

O Primeiro Programa em Visual Studio.net O Primeiro Programa em Visual Studio.net Já examinamos o primeiro programa escrito em C que servirá de ponto de partida para todos os demais exemplos e exercícios do curso. Agora, aprenderemos como utilizar

Leia mais

Informática básica: Sistema operacional Microsoft Windows XP

Informática básica: Sistema operacional Microsoft Windows XP Informática básica: Sistema operacional Microsoft Windows XP...1 Informática básica: Sistema operacional Microsoft Windows XP...1 Iniciando o Windows XP...2 Desligar o computador...3 Área de trabalho...3

Leia mais

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador

11/3/2009. Software. Sistemas de Informação. Software. Software. A Construção de um programa de computador. A Construção de um programa de computador Sistemas de Informação Prof. Anderson D. Moura Um programa de computador é composto por uma seqüência de instruções, que é interpretada e executada por um processador ou por uma máquina virtual. Em um

Leia mais

Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots

Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots Diretrizes para criação de um padrão de desenvolvimento de sistemas de informação baseados em cots Roosewelt Sanie Da Silva¹ 1 Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC) Rodovia

Leia mais