CUSTOMIZAÇÃO DE PROCESSOS PARA O DESENVOLVIMENTO DE SOFTWARE

Transcrição

1 CUSTOMIZAÇÃO DE PROCESSOS PARA O DESENVOLVIMENTO DE SOFTWARE Marla Teresinha Barbosa Geller¹ Marialina Correa Sobrinho² João Elias Brasil Bentes Júnior³ Monilson Marinho 4 Resumo Este artigo descreve a pesquisa do Grupo de Trabalho Ágil GTA,formado por uma equipe de professores e alunos que desenvolvem as atividades dentro do ambiente acadêmico utilizando as disciplinas de desenvolvimento de software para testar a instanciação de processos adaptados a sistemas diversos. Os processos utilizados como base são processos já consolidados dentre eles o Processo Unificado, o SCRUM e Programação Extrema. Dentre os processos já instanciados estão P@PSI Processo Ágil para Pequenos sistemas, o P@PSeduc Processo Ágil para Software educativo e o P@PGame Processo Ágil para Games. A descrição dos processos resultantes deste estudo inicial é o conteúdo principal deste trabalho. Palavras Chave: Engenharia de Software. Processo de Software. Metodologias Ágeis. Abstract This article describes the research of the Agile Work Group - GTA, comprising a team of teachers and pupils that develop activities within the academic environment using the disciplines of software development to test the instantiation of processes adapted to various systems. The procedures used are based on procedures already established including the Unified Process, Scrum and Extreme Programming. Among the processes already instantiated are PSI - Agile Process for Small Systems, PSeduc - Agile Process for Educational Software and P@Pgame Agile Process for Games. The description of cases arising from this initial study is the main content of this work. Keywords: Software Engineering. Software Process.Agile Methodologi ¹Professora e Coordenadora do Curso de Sistemas de Informação do Centro Universitário Luterano de Santarém CEULS/ULBRA. Graduada em Informática e Mestre em Engenharia Elétrica com ênfase em Computação Aplicada pela Universidade Federal do Pará. Pesquisadora na área de Engenharia de Software mais especificamente em Melhoria de Processo de Desenvolvimento de Software. marla.geller@gmail.com ²Professora do Curso de Sistemas de Informação do Centro Universitário Luterano de Santarém CEULS/ULBRA e do Instituto Esperança de Ensino Superior de Santarém. Graduada em Pedagogia, com especialização em Informática na Educação e Mestre em Engenharia Elétrica com ênfase em Computação Aplicada pela Universidade Federal do Pará. Pesquisadora na área de Informática na Educação, mais especificamente em Objetos de Aprendizagem linasobrinho@gmail.com ³Bacharel em Sistemas de Informação do Centro Universitário Luterano de Santarém, desenvolve pesquisa na área de Melhoria de Processo de software para desenvolvimento de Jogos. joaobentes.junior@yahoo.com.br 4 Aluno concluinte do Curso de Sistemas de Informação do Centro Universitário Luterano de Santarém, desenvolve pesquisa na área de desenvolvimento de Jogos. monilson@gmail.com 106

2 1 INTRODUÇÃO O desenvolvimento de software de forma ágil e com qualidade, têm sido o grande desafio de todas as épocas. Atender as exigências de qualidade, obedecendo planilhas de custo e atendendo as necessidades do cliente é uma questão crítica para os desenvolvedores de software. Com maior intensidade nos tempos atuais, onde o equilíbrio do tripé custo, escopo e qualidade é alcançado somente com o auxílio de um bom processo para organização e acompanhamento no desenvolvimento do software. Estão disponíveis na literatura muitos modelos de processos, alguns modelos tradicionais bastante utilizados ainda, como o Modelo Cascata, ou modelos iterativos e incrementais, como o Processo Unificado, este que se tornou padrão para muitas empresas de desenvolvimento. Segundo Ambler (2004), o problema das perspectivas tradicionais é que elas enfocam procedimentos prescritivos e os produtos que devem ser criados. São considerados métodos pesados por fundamentar-se em regras definidas, inertes a mudanças dos requisitos e por possuírem um ciclo de desenvolvimento pouco adaptável e que devem ser completamente executados. Quanto ao Processo Unificado, a expectativa para que atenda o maior número de sistemas, torna-o muito genérico, voltado principalmente para equipes mais experientes. O aumento da demanda por projetos com características específicas como o desenvolvimento de software para pequenas empresas, de software educativo, de jogos eletrônicos, entre outros, é o que justifica a pesquisa. As particularidades de cada sistema impõem uma busca por processos customizados que atendam um contexto específico. O trabalho do GTA Grupo de Trabalho Ágil iniciou em 2007, onde na primeira etapa do projeto foram estudados os processos existentes e a especificação de um processo adaptado para atender o desenvolvimento de software para pequenos sistemas P@PSI(Processo Ágil para Pequenos Sistemas). O processo definido foi testado inicialmente pela equipe no desenvolvimento de um sistema para dispositivos móveis. Em 2008, o processo instanciado objetivou atender o desenvolvimento de software educativo P@PSEduc (Processo Ágil para Software Educativo) que é utilizado no desenvolvimento de software educativo por alunos do curso de Pedagogia em colaboração com os alunos do curso de Sistemas de Informação, no curso de pós graduação em Informática e as Novas Tecnologias Educacionais. Em andamento está a aplicação do processo para o desenvolvimento de jogos eletrônicos P@PGame (Processo Ágil para Games), que está sendo aplicado na criação e um jogo eletrônico. As atividades de pesquisa do GTA devem ser permanentes e contínuas, e a aplicação, avaliação e melhoramentos nos processos devem fazer parte do conteúdo de diversas disciplinas no curso de Sistemas de Informação, que abordam o tema, formando um trabalho interdisciplinar avaliado a cada período de um semestre. Perspectiva Amazônica - - Santarém v.1 n.1 p p jul/dez jan O trabalho aqui relatado está organizado em tópicos, onde o próximo tópico faz a fundamentação teórica dos processos base e sua adaptação, o terceiro tópico descreve a metodologia utilizada para pesquisa e cita alguns trabalhos correlatos, a seguir descrevem-se os processos resultantes e finalmente nas considerações finais apresentam-se algumas conclusões com o uso dos processos e o que se pretende como trabalhos futuros. 2 PROCESSOS BASE EADAPTAÇÃO A pesquisa do grupo inicia com o estudo de processos já consolidados existentes no mercado, intensificando-se no detalhamento do Scrum, da Programação Extrema e do Processo Unificado.Aopção por estas meto 107

3 dologias deve-se a análises preliminares feitas com alguns processos de desenvolvimento de software disponíveis e conhecidos no mercado. Dos processos estudados já consolidados na literatura pode-se citar o Processo Pessoal de Software, Processo Espiral, Prototipagem, Crystal,Desenvolvimento Adaptativo de Software, entre outros.(pressman, 2006).Estudos correlatos foram também objetos de pesquisa para fundamentar o tema e conhecer outras propostas de soluções para o mesmo problema, podendo-se citar Paiva (2004), Garcia (2004), Schneider(2003), Hazzan (2006), Alves(2006). A prática de desenvolvimento de sistemas com o uso de um processo se dá em geral, com o auxílio do Processo Unificado, que é iterativo, porém prescritivo e definido. Ao mesmo tempo, incorporam-se ao mundo do desenvolvimento, os Processos Ágeis, que sugerem práticas e valores a serem utilizados no trabalho do dia a dia do desenvolvedor. Perspectiva Amazônica - - Santarém v.1 n.1 p p jul/dez jan Tem-se dessa forma, de um lado, os modelos tradicionais de desenvolvimento de sistemas voltados para documentação, que são opções, geralmente, pesadas para pequenos projetos. Por outro lado os métodos adaptativos como o Scrum ou a Programação Extrema, podem não ser suficientes para equipes sem muita experiência em desenvolvimento, pois suas práticas são rigorosas e disciplinadoras, mas não possuem uma prescrição da ordem de como as atividades devem ser realizadas. Neste cenário, é bastante comum, equipes iniciantes em desenvolvimento, não adotarem processo algum, por não se adaptarem ao trabalho árduo da documentação e nem conseguirem se organizar quando não é prescrito o que deve ser feito, ou seja, estão entre os dois extremos. (CHARETTE, 2001). Seguindo a teoria de Keenan (2004), que diz que um processo de desenvolvimento de software pode ser melhorado através da captura do que de melhor se adapta ao contexto, unindo práticas de processos conhecidos, o GTAtem por objetivo adaptar essas práticas para melhor atender projetos com características específicas. Dessa forma os processos propostos unem os princípios e práticas de métodos empíricos, como o Scrum e o XP, com o auxílio da organização do Processo Unificado que é um processo definido. 2.1 Scrum A metodologia Scrum compartilha com XP a adoção das práticas definidas no Manifesto para o Desenvolvimento Ágil de Software, AgileManifest (2001). O foco da metodologia Scrum é a flexibilidade, a adaptabilidade e a produtividade. O resultado do processo deve ser um software que é realmente útil para o cliente. (SCHWABER, 2002). O ciclo de vida do Scrum é baseado em três fases: fase de planejamento, fase de desenvolvimento (Sprint) e fase de encerramento. A primeira e a última fase consistem em processos definidos, onde o fluxo de atividades é linear, podendo haver algumas iterações na fase de planejamento, como refereschwaber (1995). 5 Nesta fase define-se o ProductBacklog, que consiste em uma lista priorizada de todas as estórias de usuários que o sistema deve atender. Afase de desenvolvimento é dividida em ciclos chamados Sprints, que são realizados em tempo determinado (não mais que 30 dias). Um Sprint contém uma funcionalidade ou funcionalidades (Sprint 6 Backlog ) que devem ser implementadas. São os casos de uso priorizados. O Sprint Backlog é dividido em tare- 7 fas (Sprints Diários ) que não devem exceder24 horas. Tem-se a cada final de Sprint um release ou uma parte do 5 ProductBacklog: conjunto de requisitos do sistema. 6 Sprint Backlog: itens do ProductBacklog que a equipe se compromete em desenvolver em um período de até 4 semanas. 7 Sprints diários: definição da atividade a ser realizada em um dia e que faz parte do Sprint Backlog. 108

4 produto a ser avaliado ou até mesmo utilizado pelo cliente. Na fase de encerramento são feitas reuniões para analisar o progresso do projeto e demonstrar o software atual para os clientes. Nesta fase são feitas as etapas de integração, testes finais e documentação.(pressman, 2006). Uma equipe Scrum é formada pelo Scrum Master (gerente do projeto), que é responsável pela aplicação das regras do Scrum, que garante a plena funcionalidade e produtividade da equipe e que representa o escudo nas interferências externas; pelo ScrumOwner(dono do produto), que define as funcionalidades do produto, decide datas de lançamento do conteúdo, e pela equipe de desenvolvedores que deve ser pequena e multifuncional (programadores, testadores, desenvolvedores de interfaces, entre outros). Pode-se fazer uma analogia do Scrum com o jogo onde todos trabalham ao mesmo tempo para conseguir o mesmo objetivo, Takehushi (1986) descreve: O estilo de corrida de revezamento onde é dada a cada participante da equipe a responsabilidade de uma parte do projeto, quando aplicado ao desenvolvimento de produtos pode conflitar com os objetivos de velocidade e flexibilidade máximas. Na interpretação do texto de transcrito acima, tem-se a descrição do que acontece nos processos tradicionais. Ao invés disto, um estilo holístico, onde a equipe busca, como em um jogo de futebol, de forma integrada, chegar ao gol, com passes de bola, pode servir melhor às atuais necessidades competitivas. (TAKEHUSHI, 1986). 2.2 Programação Extrema - extremeprogramming - XP Conforme Beck (2004), XP é uma metodologia ágil para equipes pequenas a médias que desenvolvem software com requisitos vagos ou que mudam frequentemente. Baseia-se em quatro valores que são: comunicação, simplicidade, feedback e coragem. AXPpossui práticas que são aplicadas a qualquer outro processo e que agregam valor à equipe de desenvolvimento. Entre estas práticas estão: programação em pares, cliente presente, reuniões breves, testes freqüentes, refatoração do código, integração contínua, semanas de 40 horas. (TELES, 2004). A XP assim como o Scrum é um processo adaptativo, ou seja, adota a mudança, ou melhor, considera a mudança uma característica intrínseca aos sistemas. Portanto, ao invés de prever o que pode acontecer no futuro, adapta-se às mudanças, baseando-se em situações concretas, que realmente acontecem. XP recebe críticas, por ter uma análise de requisitos muito informal e por não valorizar tanto a modelagem como o Processo Unificado. 2.3 Processo Unificado Kruchten (2003) define o Processo Unificado como uma estrutura genérica de processo que pode ser customizado adicionando-se ou removendo-se atividades com base nas necessidades específicas e nos recursos disponíveis para um projeto. Possui quatro fases: Concepção, Elaboração, Construção e Transição. Dentro do Processo Unificado, fluxos de trabalho atravessam as fases do processo: Requisitos, Análise, Projeto, Implementação, Testes.(AMBLER, 2004). O Processo Unificado é um processo definido e preditivo que utilizado com a Linguagem de Modelagem Unificada, sugere a documentação do sistema através de modelos, como refere-se Scott (2003). Apesar de ter característica iterativa e incremental, prescreve as fases com planejamento e documentação mais extensa. 109

5 3 METODOLOGIADE INVESTIGAÇÃO E TRABALHOS CORRELATOS A metodologia utilizada para escolha dos processos base foi primeiramente o estudo de processos prescritivos para inserir no processo resultante o mínimo de organização necessária para orientar desenvolvedores inexperientes. Desta forma as etapas realizadas para instanciação do processo passaram por leitura e estudo dos diversos processos, dentre eles o tradicional Processo em Cascata. Através do Processo Cascata foi possível entender claramente os fluxos de Levantamento de Requisitos, Análise, Projeto, Implementação e Testes, fluxos estes que atravessam ortogonalmente qualquer processo. Ao mesmo tempo, preocupou-se em proporcionar agilidade através de práticas que facilitassem o desenvolvimento de pequenos projetos. Dentre as práticas herdadas do XP, utilizou-se a adoção da programação em pares, da refatoração de código, do planejamento diário, da propriedade coletiva do código, dentre outras. O processo Scrum uniu-se ao XP e ao Processo Unificado para gerenciar cada processo instanciado. Perspectiva Amazônica - - Santarém v.1 n.1 p p jul/dez jan O estudo das metodologias ágeis incluiu a Programação Extrema descrita por Astels (2002), família Crystal, Desenvolvimento Adaptativo de Software, referidos porpressmann (2006) e Scrum por Schwaber (1995). Estudos referentes a desenvolvimento de software educativo foram também objetos de pesquisa para fundamentá-la e conhecer outras propostas de soluções para o mesmo problema, podendo-se citar: Paiva (2004), Garcia (2004), Schneider (2003), Hazzan (2003), Alves (2006), Bassani (2006), Benitti (2005), Falkembach (2005). Quanto às metodologias para desenvolvimento de jogos pode-se considerar as propostas de Cabral (2004), Credidio (2008) e Nascimento (2008). 4 PROCESSOS RESULTANTES Como resultado inicial desta pesquisa, apresenta-se a seguir os processos instanciados que possuem como características comuns serem voltados para pequenos projetos e desenvolvidos por equipes inexperientes. E como especificidades, atenderem ao desenvolvimento de software para pequenas empresas, software educativos e desenvolvimento de jogos. 4.1 P@PSI Processo Ágil para Pequenos Sistemas O processo resultante - P@PSI (Processo Ágil para Pequenos Sistemas), é descrito como sendo gerenciado pelo Scrum, adotando práticas XP e com fluxos organizados do Processo Unificado. O processo constitui-se de três etapas representadas em raias no diagrama de atividades da figura 1: Planejamento, Desenvolvimento e Encerramento que possibilitam a iteratividade. Inicia-se com a fase de Planejamento, onde a equipe de desenvolvimento trabalha na captura de requisitos para definir o Produto Total. Os recursos utilizados para esta atividade são reuniões, entrevistas com os clientes, questionários, entre outras, que resultam em estórias de usuários podendo ser representados através de diagrama de casos de uso. Recomenda-se se necessário a descrição dos cenários dos casos de uso mais complexos. Seguindo para a fase de Desenvolvimento, prioriza-se do Produto Total, uma funcionalidade ou pequenas funcionalidades, representadas por um ou mais casos de uso. Essa funcionalidade deve ser desenvolvida em um período determinado, (aconselhável não 110

6 mais que quatro semanas). A esse pequeno pacote com os casos de uso priorizados chama-se Funcionalidade Priorizada, que é solucionada em um fluxo diário de projeto, implementação e teste, ou seja, executa-se o projeto, desenhando e detalhando as classes, implementa-se o código e testa-se a unidade funcional diariamente, podendo este fluxo ser iterativo. Nesta fase utilizam-se os recursos do diagrama de seqüência da UML para definir atributos e métodos, obtendo-se um diagrama de classes de projeto. Figura 1: Diagrama de atividades do P@PSI, com as fases definidas por raias. As atividades desenvolvidas na fase de Encerramento incluem a revisão, demonstração e entrega da Funcionalidade Priorizadaao cliente. Neste ponto o processo retorna executando uma nova iteração com um novo conjunto de funcionalidades priorizadas, criando um novo pacote,passando por todas as fases. Quando o Produto Total estiver finalizado o processo encerra-se. O P@PSI está sendo utilizado pelos acadêmicos do Curso de Sistemas de Informação em seus trabalhos de Conclusão de Curso, nos trabalhos de desenvolvimento das diversas disciplinas e nos trabalhos de Iniciação Científica, contribuindo desta forma para aprimoramento do processo. 111

7 4.2 Processo Ágil para Software Educativo No que se refere ao desenvolvimento de software educativo é importante que se tenha conhecimento das principais teorias de aprendizagem além de conhecimento de técnicas da engenharia de software que facilitem a produção do software com qualidade. Desta forma, tem-se a necessidade de trabalho colaborativo entre a área tecnológica (engenharia de software) e a área psico-pedagógica. (BASSANI,2006). Oliveira et al (2004) aponta 4 (quatro) parâmetros que distinguem um software qualquer de um software educativo: fundamentação pedagógica, conteúdo, interação aluno-software educativo professor e a programação. Nesta perspectiva, diversos autores têm apresentado algumas propostas metodológicas para o processo de desenvolvimento de software educativo. Entretanto, percebe-se que essas propostas tendem a contemplar aspectos educacionais e psicológicos, em detrimento dos aspectos computacionais, enfatizando o caráter descritivo. A proposta apresentada pelo GTA é uma adaptação do processo inicial P@PSI, atendendo os requisitos para o desenvolvimento de um software educativo, com o principal objetivo de facilitar o trabalho interdisciplinar entre as duas áreas (pedagógica e técnica), especificando cada papel no decorrer do processo, bem como sugerir os artefatos criados. Partindo-se deste cenário o P@PSEduc foi dividido em quatro fases, apresentadas através do diagrama de atividades na figura 2. Figura 2: Diagrama de atividades do P@PSEduc com suas fases definidas por raias. 112

8 Fase de Planejamento, onde é preciso considerar o produto a ser desenvolvido, definir os objetivos da aprendizagem e requisitos do software, além de definir o escopo e o público alvo conforme Benitti(2005). É preciso definir o tema, considerar as aplicações existentes e os recursos disponíveis. Fase de Modelagem - modelar um sistema é apresentá-lo em modelos gráficos com o objetivo de facilitar a compreensão, discussão e aprovação do sistema antes de começar a construí-lo. Uma aplicação que utiliza os recursos da hipermídia como a maior parte dos software educativos, inclui a criação de três modelos modelo conceitual, modelo navegacional e modelo de interface. A Fase de Desenvolvimento inclui as atividades de produção, reutilização, organização e integração das mídias. Cria-se os sons, as imagens, código, animações, vídeos e todo o recurso necessário para o sistema. (GELLER, 2009). Esta fase é facilitada quando se utiliza um Sistema de Autoria que ofereça os recursos para integrar todas as mídias em uma estrutura interativa permitindo uma navegação lógica e intuitiva (FALKEMBACH, 2005). Fase de Encerramento neste ponto o software já está em funcionamento, testado e corrigido. A equipe de desenvolvimento é responsável por confeccionar o manual do usuário e oferecer treinamento para todos aqueles que irão utilizar o sistema. 4.3 P@PGame Processo Ágil para Games Este projeto iniciado em agosto de 2008 visa atender o desenvolvimento de um tipo peculiar de software, os jogos eletrônicos. O desenvolvimento de um jogo eletrônico é um processo criativo e em vários pontos artístico, com fases semelhantes às de um software comum, porém processos convencionais de desenvolvimento, não são adequados às necessidades desse tipo de projeto.(junior, 2002). No planejamento de jogos e simulações é de vital importância definir e fixar os objetivos da atividade, a determinação do contexto desejado para a mesma, a identificação dos recursos utilizáveis para se alcançar os objetivos finais e a determinação da seqüência de interações, ou seja, uma fase de planejamento bastante criteriosa. A aprendizagem dos processos de desenvolvimento e da utilização das ferramentas necessárias é essencial para a evolução de um projeto de desenvolvimento de jogos.(amazonas, 2007). O P@PGame tem sua base no P@PSI, com a união das melhores práticas das metodologias de desenvolvimento de games mais conhecidas no mercado, como o processo Cabal da Valve Software Valve (2007). A estrutura do P@PGame é uma mescla das fases de Planejamento, Desenvolvimento e Encerramento do P@PSI com o modelo de Game Design apresentado por Schuytema, (2008) e Perucia et al (2005). O processo está divido em três grandes fases, como mostra a figura 3: Pré-Produção, Produção e Pós-Produção. O processo está sendo validado no desenvolvimento de um pequeno game, denominado Vivá (jogo para evidenciar conceitos de ecologia e sustentabilidade), que encontra-se em sua fase de Produção. O projeto de construção do jogo iniciou em outubro de 2009, com uma equipe liderada por acadêmicos do curso de sistemas de informação do CEULS/ULBRA. Durante a fase de Pré-Produção todas as atividades foram realizadas, sendo que após o Estudo de Viabilidade foram realizados brainstormings para produzir o Escopo do Jogo. A decisão foi tomada a partir da análise do Roteiro que gerou o Documento de Design Inicial. Durante a atividade Priorização de Level da Fase de Produção, a equipe definiu que o game seria desenvolvido na mesma ordem cronológica do Roteiro, com isso, o I Capítulo está sendo desenvolvido. Após a atividade de Priorização de Level, iniciou-se a criação da arte conceitual dos personagens principais. No momento, os desenhistas trabalham na produção dos modelos conceituais dos personagens principais do 1º level, e o game designer está trabalhando no roteiro. 113

9 4.3 Processo Ágil para Games Este projeto iniciado em agosto de 2008 visa atender o desenvolvimento de um tipo peculiar de software, os jogos eletrônicos. O desenvolvimento de um jogo eletrônico é um processo criativo e em vários pontos artístico, com fases semelhantes às de um software comum, porém processos convencionais de desenvolvimento, não são adequados às necessidades desse tipo de projeto.(junior, 2002). No planejamento de jogos e simulações é de vital importância definir e fixar os objetivos da atividade, a determinação do contexto desejado para a mesma, a identificação dos recursos utilizáveis para se alcançar os objetivos finais e a determinação da seqüência de interações, ou seja, uma fase de planejamento bastante criteriosa. Aaprendizagem dos processos de desenvolvimento e da utilização das ferramentas necessárias é essencial para a evolução de um projeto de desenvolvimento de jogos.(amazonas, 2007). O P@PGame tem sua base no P@PSI, com a união das melhores práticas das metodologias de desenvolvimento de games mais conhecidas no mercado, como o processo Cabal da Valve Software Valve (2007). A estrutura do P@PGame é uma mescla das fases de Planejamento, Desenvolvimento e Encerramento do P@PSI com o modelo de Game Design apresentado por Schuytema, (2008) e Perucia et al (2005). O processo está divido em três grandes fases, como mostra a figura 3: Pré-Produção, Produção e Pós-Produção. Figura 3: Diagrama de atividades do P@PGame 5 CONSIDERAÇÕES FINAIS Observa-se que a dificuldade de seguir um processo tradicional e definido tem sido um fator propulsor de pesquisas para encontrar um meio termo entre o desenvolvimento caótico e a rigidez das regras da Engenharia de Software. A prática da customização entre processos já existentes é considerada uma disciplina na área de desenvolvimento de sistemas. Como identificado nos processos descritos anteriormente a caracterização de um processo se dá pela intensidade de cada fluxo de trabalho dentro das fases que ocorre conforme as necessidades da aplicação. Assim tem-se que a característica principal do P@PSIé a evidência da complementaridade entre Scrum, XP e Processo Unificado. Enquanto XP não prevê análise de riscos, um sprint do Scrum ao ser organizado pelo fluxo do Processo Unificado analisa os riscos diariamente. As práticas do XP facilitam à equipe inexperiente o comportamento e relacionamento da equipe no dia a dia, como cliente presente, programação em pares, propriedade coletiva do código, reuniões em pé, integração diária, programação orientada por testes enquanto que a ordem dos 114

10 fluxos dada pelo Processo Unificado orienta as tarefas na seqüência do tempo. A natureza gerencial do Scrum possibilita a visão das atividades como um todo, fazendo com que a equipe trabalhe com um objetivo bem focado. No P@PSEduc tem-se um fluxo de levantamento de requisitos e análise bastante criterioso e extenso colocando a Fase de Planejamento como uma das mais importantes, pois é nesta fase que a função da equipe psico-pedagógica irá definir o conjunto de requisitos a serem cumpridos. Como em um software educativo se utiliza muitas mídias já prontas e ferramentas facilitadoras, o fluxo de implementação inclui mais a integração dessas mídias do que propriamente criação de código. AFase de Encerramento do Processo para o software educativo tem como ponto principal o treinamento dos usuários, ou seja, a preparação dos professores, orientadores pedagógicos, diretores de escolas, entre outros, para utilização correta do software, a fim de que ele alcance seus objetivos reais. O P@PGame procurou criar uma forma de nortear o desenvolvimento de um produto mais artístico do que sistemático. Isso se deu pela união dos conceitos de metodologias ágeis previstas no P@PSI e no P@PSEduc com os conceitos de Game Design e a metodologia do Cabal Process. Observou-se que é possível utilizar um processo com equipes inexperientes em desenvolvimento, porém é necessário que um acompanhamento das atividades seja realizado por um membro da equipe que tenha conhecimento dos princípios e práticas da engenharia de software. Desta forma é que se pode documentar as práticas positivas e as dificuldades para possíveis melhorias no processo. Também ficou claro que mesmo com um bom Game Designer conduzindo o projeto, é necessário capacitar a equipe que deve ser guiada por um processo adaptado às necessidades deste tipo de software. A dificuldade de se trabalhar pela primeira vez com um processo situa-se principalmente no fato de que não se tem histórico de experiências já realizadas e portanto é vital que se documente todo o processo com relato das dificuldades encontradas e das facilidades produzidas pelas regras. Assim foram elaborados relatórios de dificuldades encontradas em cada aplicação e conforme as necessidades os processos P@PSI, P@PSEduc e P@PGame estão sendo melhorados. A aplicação dos processos com vários sistemas e equipes diversificadas deve ser prática permanente do grupo GTA, para que boas experiências possam ser reproduzidas, relatadas e aperfeiçoadas a cada período. O Grupo de Trabalho Ágil espera com esta pesquisa encontrar não soluções, mas experimentar práticas capazes de facilitar a solução para sistemas específicos, enriquecendo os relatórios sobre as tentativas de customização de processos e de busca por recursos facilitadores para os engenheiros de software. Como trabalhos futuros pretende-se utilizar os relatos de experiências com os processos, considerar as dificuldades e pontos positivos e criar templates (modelo de documento) para facilitar a utilização do processo como documentação dos sistemas criados. REFERÊNCIAS Agile Manifesto, (2001). acessado em 20 de maio de AMAZONAS, D. S. Desenvolvimento de Jogos 3D em Java com a Utilização do Motor Gráfico Irrlicht.Monografia apresentada em 2007 na Faculdade Lourenço Filho, Fortaleza. Disponível em: Acesso em 3 de novembro de

11 Perspectiva Amazônica - - Santarém v.1 n.1 p p jul/dez jan AMBLER, S. Modelagem Ágil Práticas Eficazes para a Programação Extrema e o Processo Unificado. Porto Alegre: Bookmann, ASTELS, D. et al. Extreme Programming: Guia Prático. Campus, BASSANI, P. et al. Em Busca de uma Proposta Metodológica para o Desenvolvimento de Software Educativo Colaborativo. Novas Tecnologias para a Educação. CINTED,UFRGS. V. 4 No 1. Julho de BECK, K. Programação Extrema Explicada Acolha as Mudanças, Bookman, 2004 BENITTI, F. et al. Processo de Desenvolvimento de Software Educacional: Proposta e Experimentação. Novas Tecnologias na Educação. V.3 No1. Maio de CABRAL, Fátima A..Jogos Eletrônicos: técnica ilusionista ou emancipadora?.revista da USP, São Paulo, v. 000, p. 00, CHARETTE, R. Fair Fight?Agile Versus Heavy Methodologies.Cutter Consortium E-project Management Advisory Service, 2, 13, (2001). CREDIDIO, D. C. Metodologia de Design aplicada à concepção de jogos digitais f. Tese (Mestrado em Design). Universidade Federal de Pernambuco, Recife, FALKENBACH, G. Concepção e Desenvolvimento de Material Educativo Digital. Novas Tecnologias na Educação. V.3 No 1. Maio de GARCIA, F. P. et al. easyprocess: Um Processo de Desenvolvimento para Uso no Ambiente Acadêmico. Anais do Workshop de Educação em Informática WEI, GELLER, M. et.al. Proposta de Customização de um Processo de Desenvolvimento de Software Educativo. In Anais do XX Simpósio Brasileiro de Informática na Educação. Florianópolis, SC , ISSN: Disponível em: HAZZAN,O e DUBINSKY Y. Teaching a Software Development Methodology: The Case of Extreme Programming. Proceedings of the 16th Conference on Software Engineering Educations and Training (CSEE&T 2003), Madrid, Spain, JUNIOR, A. et al. Um Estudo Sobre os Processos de Desenvolvimento de Jogos Eletrônicos. Universidade Federal do Paraná Disponível em: Acessoem 3 de novembro de KEENAN, Agile Process Tailoring and problem analysis (APTLY). In Proceedings of the 26th International Conference on Software Engineering (ICSE'04). KRUCHTEN, P. Rational Unified Process made easy: A practioner's guide to the RUP, Addison-Wesley, 2003 NASCIMENTO, M. J. A. do. Modelagem De Ambientes Virtuais Para Jogos Eletrônicos f. Trabalho de Conclusão de Curso (Graduação em Engenharia da Computação) Universidade Federal do Pará, Belém, OLIVEIRA, A. et. al. Interface Homem Computador para Software Educativo. In IV Congresso Brasileiro de Computação. CBComp PAIVA, D.M.B et al. Definido Implantando e Melhorando Processos de Software em Ambiente acadêmico. VI Simpósio Internacional de Melhoria de Processo de Software. São Paulo:2004. PERUCIA, Alexandre Souza et al. Desenvolvimento de Jogos Eletrônicos: Teoria e Prática. 2. ed.são Paulo: Novatec, PRESSMAN, R.Engenharia de Software. 6a.ed. São Paulo: McGraw-Hill, 2006 SCHNEIDER, J.G and Johnston Lorraine. extreme Programming at Universities An Educacional Perspective. Proceedings of de 25th Internacional Conference on Software Engineering. Portland, Oregon, SCHUYTEMA, P. Design de Games: UmaAbordagem Prática. São Paulo: Cengage, SCHWABER, K..Scrum Development Process, OOPSLA'95 Workshop on Business Object Design and 116

12 Implementation. Springer-Verlag, SCHWABER, K. e BEEDLE, M. Agile Software Development with SCRUM, Prentice-Hall, TELES, Vinícius M. Extreme Programming. São Paulo: Novatec, WILLIAMS, L. et al. Agile Software Development. It's About Feedback and Change InIEEE Computer Society, june, V a l v e S o f t w a r e. S o u r c e E n g i n e, D i s p o n í v e l e m : Acesso em 25 de outubro de