CUSTOMIZAÇÃO DE PROCESSOS PARA O
DESENVOLVIMENTO DE SOFTWARE
Marla Teresinha Barbosa Geller¹
Marialina Correa Sobrinho²
João Elias Brasil Bentes Júnior³
Monilson Marinho4
Resumo
Perspectiva Amazônica - Santarém v.1 n.1 p.106-117 jan 2011
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 P @ PSI - Agile Process for Small Systems, P @ 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. E-mail: [email protected]
²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 E-mail: [email protected]
³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. E-mail: [email protected]
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. E-mail: [email protected]
106
1 INTRODUÇÃO
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.
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
Perspectiva
PerspectivaAmazônica
Amazônica--Santarém
Santarémv.1
v.1n.1
n.1p.82-93
p.106-117
jul/dez
jan 2011
2010
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.
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).
Perspectiva
PerspectivaAmazônica
Amazônica--Santarém
Santarémv.1
v.1n.1
n.1p.82-93
p.106-117
jul/dez
jan 2011
2010
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.
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).
Nesta fase define-se o ProductBacklog5, 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
Backlog6) que devem ser implementadas. São os casos de uso priorizados. O Sprint Backlog é dividido em tarefas (Sprints Diários7) que não devem exceder 24 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
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).
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.
AXP possui 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
Perspectiva Amazônica - Santarém v.1 n.1 p.106-117 jan 2011
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).
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.
Perspectiva
PerspectivaAmazônica
Amazônica--Santarém
Santarémv.1
v.1n.1
n.1p.82-93
p.106-117
jul/dez
jan 2011
2010
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.
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
Perspectiva Amazônica - Santarém v.1 n.1 p.106-117 jan 2011
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
4.2 P@PSEduc – 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.
Perspectiva Amazônica - Santarém v.1 n.1 p.106-117 jan 2011
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
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.
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
Perspectiva Amazônica - Santarém v.1 n.1 p.106-117 jan 2011
4.3 P@PGame – Processo Ágil para Games
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. 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).
Perspectiva Amazônica - Santarém v.1 n.1 p.106-117 jan 2011
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
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.
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). http://www.agilemanifesto.org/, acessado em 20 de maio de 2007.
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:
http://www.flf.edu.br/midias/FLF.EDU/monografia.pdf. Acesso em 3 de novembro de 2008.
115
Perspectiva Amazônica - Santarém v.1 n.1 p.106-117 jan 2011
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.
AMBLER, S. Modelagem Ágil – Práticas Eficazes para a Programação Extrema e o Processo Unificado.
Porto Alegre: Bookmann, 2004.
ASTELS, D. et al. Extreme Programming: Guia Prático. Campus, 2002.
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 2006.
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 2005.
CABRAL, Fátima A. .Jogos Eletrônicos: técnica ilusionista ou emancipadora?.Revista da USP, São Paulo, v.
000, p. 00, 2003.
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. 2007.95 f. Tese (Mestrado
em Design). Universidade Federal de Pernambuco, Recife, 2007.
Perspectiva
PerspectivaAmazônica
Amazônica--Santarém
Santarémv.1
v.1n.1
n.1p.82-93
p.106-117
jul/dez
jan 2011
2010
FALKENBACH, G. “Concepção e Desenvolvimento de Material Educativo Digital”. Novas Tecnologias na
Educação. V.3 No 1. Maio de 2005.
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, 2004.
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 - 2009, ISSN: 21764301. Disponível em: http://www.proativa.virtual.ufc.br/sbie2009/
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, 2003.
JUNIOR, A. et al. Um Estudo Sobre os Processos de Desenvolvimento de Jogos Eletrônicos. Universidade
Federal do Paraná. 2002. Disponível em: http://www.ademar.org/texts/processo-desenv-games.pdf. Acessoem 3 de
novembro de 2008.
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. 2008. 59 f. Trabalho de Conclusão de Curso (Graduação em Engenharia da Computação) – Universidade Federal do Pará, Belém,
2008.
OLIVEIRA, A. et. al. Interface Homem Computador para Software Educativo. In IV Congresso Brasileiro de
Computação. CBComp 2004.
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, 2007.
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, 2003.
SCHUYTEMA, P. Design de Games: UmaAbordagem Prática. São Paulo: Cengage, 2008.
SCHWABER, K..Scrum Development Process, OOPSLA'95 Workshop on Business Object Design and
116
Implementation. Springer-Verlag, 1995.
SCHWABER, K. e BEEDLE, M. Agile Software Development with SCRUM, Prentice-Hall, 2002.
TELES, Vinícius M. Extreme Programming. São Paulo: Novatec, 2004.
WILLIAMS, L. et al. Agile Software Development. It's About Feedback and Change InIEEE Computer Society, june, 2003.
__________.
Va l v e S o f t w a r e .
SourceEngine,
2007
Disponível
em:
Perspectiva Amazônica - Santarém v.1 n.1 p.106-117 jan 2011
http://www.valvesoftware.com/sourcelicense/enginefeatures.htm. Acesso em 25 de outubro de 2008.
117