Mapeamento do processo de Modelagem em eXtreme Programming no domnio de jogos

Abelmon de Oliveira Bastos1 , Christina von Flach Garcia Chavez1

1

Instituto de Matem tica Departamento de Ci ncia da Computacao a e Universidade Federal da Bahia 40170-110 Salvador, BA
abelmon@gmail.com, flach@im.ufba.br

Abstract. The main goal of this project is to map the Modeling process into eXtreme Programming at the specic domain of games, showing the case implementation inside this context using XP with Agile Modeling guided by a exible process ow to be identify. Keywords: extreme programming, agile modeling, games Resumo. O projeto tem o objetivo de mapear o processo de Modelagem em eXtreme Programming no domnio de jogos, apresentando a implementacao de guiada por um um caso dentro deste contexto usando XP com Modelagem Agil uxo exvel de processo a ser identicado. Palavras-chave: extreme programming, modelagem agil, jogos

1. Introducao
A producao de um software e uma atividade complexa, especialmente quando nos refe rimos a jogos, pois seu projeto e multidisciplinar, demandando especialistas de diversas sub reas da computacao. Dependendo do g nero do jogo a ser criado, podem exister a e tamb m intersecoes com outras areas (design gr co, matem tica, fsica, hist ria...) e e a a o com outros domnios. A principal preocupacao no desenvolvimento de um jogo e sua qualidade. Uma das formas de se medir a qualidade de um software e segundo o atendimento de seus requisitos funcionais e n o-funcionais ao longo de seu ciclo de vida [18]. Muitos destes a requisitos s o identicados ap s uma an lise do domnio do problema, onde alguns rea o a quisitos do domnio de jogos como usabilidade s o considerados ainda mais crticos que a de softwares convencionais. No Brasil, eXtreme Programming tem demonstrado boa adaptacao no desenvolvi mento de jogos [13] em contraste com processos de software tradicionais. Pela primeira ` vez, as empresas de jogos est o associando as quest es de qualidade do produto a Ena o genharia de Software, sendo que at 2003, freq entemente as atividades de programacao e u eram feitas por prossionais de outras areas, que obviamente n o tinham conhecimento a adequado na area. Segundo a Engenharia de Software, a producao de modelos e usada nas mais diversas etapas da producao de um software, auxiliando a projetar o sistema, entender suas partes componentes, a conguracao requerida do sistema, fatores relevantes para o problema e capacidade de se suprir estes fatores. Entretanto, quando nos referimos a Me todologias Ageis, uma d vida crucial surge: sendo XP uma metodologia agil que prioriza u mais um software desenvolvido do que documentacao abrangente [5], como e tratada a

modelagem? O desenvolvimento deste projeto tem a nalidade de auxiliar os desenvolvedores brasileiros de jogos a entenderem XP a partir de uma observacao mais atenta sobre a importante atividade de modelagem, dismisticando alguns mitos desta metodologia. De um modo geral, o trabalho tamb m se prop e a indicar como a modelagem em eXtreme e o Programming deve ser considerada, gerando um software de melhor qualidade. A secao seguinte far uma breve apresentacao de conceitos e posteriormente ser a a descrita a abordagem e o estudo de caso utilizado no presente trabalho.

2. Conceitos
Antes da explicacao da abordagem, e necess ria uma breve introducao dos conceitos abor a e eXtreme Game Dedados neste trabalho como eXtreme Programming, Modelagem Agil velopment. 2.1. eXtreme Programming A Programacao Extrema ou eXtreme Programming (XP) e uma Metodologia Agil para pequenas e m dias equipes (com menos de 10 pessoas) de desenvolvimento frente a ree quisitos vagos e em constante mudanca [5]. A modelagem em eXtreme Programming e um assunto que incomoda muitos engenheiros de software, pois s o poucas ou muito vagas as refer ncias a esta atividade nas a e principais bibliograas de XP. Por exemplo, em [5], fala-se sobre padr es de codicacao, o mas nem se comenta sobre padr es de modelagem. Uma situacao mais estranha ocorre o quando Kent Beck comenta sobre o papel de diagramas no design. E uma secao sucinta que n o esclarece o papel da modelagem em XP. O resultado disso e que muitos praticana tes de XP, simplesmente ignoram a modelagem, partindo logo para a programacao. Kent Beck ainda alerta que mesmo executando as atividades de XP na seq encia, u haver um ponto onde ser necess rio um redesign do sistema. Se este redesign e um sinal a a a de modelagem falha em eXtreme Programming, n o est claro, mas e prov vel. Mesmo a a a com a pouca refer ncia de XP sobre a atividade de modelagem, pode-se listar algumas e pr ticas que lidam com a modelagem do sistema: a met fora, o Jogo do Planejamento a a e o princpio do Design simples.

2.1.1. Design Simples Kent Beck e enf tico quando fala sobre a import ncia de um Design Simples no desena a volvimento. Segundo [5], um design simples e aquele que obdece as seguintes restricoes, em ordem de prioridade: 1. 2. 3. 4. O sistema (c digo e testes juntos) deve comunicar tudo que se deseja comunicar. o O sistema n o deve conter funcionalidades duplicadas, modularizando-as. a O sistema deve ter o menor n mero de classes possvel. u O sistema deve ter o menor n mero de m todos possvel. u e

As duas primeiras restricoes constituem a regra Uma e somente uma vez que em outras palavras siginica que o sistema n o pode ter funcionalidades ou dados duplicados, a sendo localizados em apenas um local. Em eXtreme Programming, durante o planejamento da iteracao, logo ap s a es o colha dos cart es de usu rio, estes s o agrupados segundo funcionalidades. E feita o a a

uma reuni o em p para discutir as possveis classes envolvidas nestas funcionalidaa e des, identicando-as. Para cada objeto (classe) identicado e feito um cart o Classa Responsability-Collaborator (CRC) respectivo. Muitos requisitos, neste momento, podem estar vagos, ent o e feita uma reuni o com o cliente que provavelmente estar disa a a ponvel, para retirar d vidas. u ` Esta abordagem pode parecer estranha e ineciente como modelagem a primeira vista, por m ela envolve conceitos de Orientacao a Objetos (Object Thinking) que a maie oria da pessoas n o est acostumada, como An lise de Comportamento do Objeto [20]. a a a Durante o ciclo de desenvolvimento de um software usando eXtreme Programming, vericamos a exist ncia das seguintes fases: Fase de exploracao, Jogo do Planee jamento, Planejamento da Iteracao, Iteracao, Testes de aceitacao e Publicacao. Na pr tica, muitas equipes XP n o enxergam as distincoes entre as fases, uma vez que o proa a cesso e iterativo, podendo ser analisado de forma simples seguindo suas quatro atividades e artefatos bem conhecidos. 2.2. Modelagem Agil A Modelagem Agil e uma metodologia agil baseada na pr tica para modelagem e a documentacao ecazes de sistemas baseados em software. Ela e um conjunto de pr ticas a guiado por princpios (derivados dos princpios da Agile Alliance) e valores para desenvol vedores aplicarem no seu dia-a-dia, fornecendo conselhos sobre como ser um modelador eciente [4], focando no desenvolvedor m dio. e Assim como eXtreme Programming, a Modelagem Agil tamb m usa a id ia de e e foi inspirada valores para construir uma base para a metodologia. A Modelagem Agil em XP possuindo muitos conceitos similares ou equivalentes. De fato, dos cinco valores da MA, apenas um diverge dos valores de XP. E importante lembrar que a exist ncia e dos valores das metodologias ageis n o e por simples ret rica, mas para provocar nos a o desenvolvedores um envolvimento los co sobre novas formas de projetar e desenvolver o a software. Portanto, os valores da MA s o: comunicacao, simplicidade, feedback, coragem e humildade. As pr ticas b sicas da Modelagem Agil est o divididas em quatro categorias: a a a 1. Modelagem iterativa e incremental: As pr ticas desta categoria visam adaptar a ` o processo de modelagem a abordagem de desenvolvimento incremental, aconselhando a escolha adequada de artefatos, a criacao de v rios artefatos em paralelo a (para atender as necessidades de modelagem) e a organizacao do trabalho de mo delagem em partes menores. 2. Trabalho de equipe: Incluindo a participacao ativa do cliente. 3. Simplicidade: Este grupo de pr ticas visa a simplicidade como forma de aumena tar a agilidade do trabalho. Por exemplo, para aplicar a pr tica Crie conte do a u simples, e necess rio ter em mente tr s quest es: se o modelo comunica tudo a e o que se pretende; se o modelo n o cont m informacao duplicada e se ele tem a a e menor quantidade de elementos possveis. 4. Validacao: Na modelagem agil, a abordagem de validacao de modelos e um pouco diferente do tradicional, propondo que se modele um pouco e codique, comprovando com c digo. o 2.3. eXtreme Game Development eXtreme Game Development(XGD) e uma metodologia de desenvolvimento de jogos baseada em eXtreme Programming, estendendo-a [10]. As adaptacoes da XGD em relacao a

XP s o simples e focadas no domnio de jogos. Pode-se considerar XGD como sendo XP a para n o-programadores, redenindo alguns pap is, princpios, pr ticas e processos [9]. a e a Os valores de XGD s o os mesmos de XP. Por exemplo, Simplicidade em XGD, a se refere a eliminacao da complexidade extra aos jogos, tornando a jogabilidade mais agrad vel, assim como tamb m evitar perder tempo na adicao de detalhes ou funcioa e nalidades que n o ser o notadas no jogo. Comunicacao e um valor crucial para o a a projeto em jogos, por se tratar de uma equipe multidisciplinar com potencial para conitos internos em muitas etapas do desenvolvimento. Os pap is do XGD s o: produtor, e a desenvolvedores, coach e distribuidor ou publisher.

3. Abordagem
Nesta secao, ser descrita a abordagem seguida para aplicar modelagem em eXtreme Pro a gramming ecientemente, no domnio de jogos. 3.1. Objetivo E fato que XP possui modelagem, por m existem dois motivos v lidos para se modelar: e a para entender o domnio do problema ou comunicar. Pode-se vericar que um simples rascunho de diagrama pode comunicar mais ecientemente do que escrever um c digo o inteiro para demonstrar uma id ia, como e feito normalmente em XP. e A Modelagem Agil e um metodologia indenpendente de outros processos, focali zando modelagem e documentacao ecazes. A aplicacao dela junta a XP e recomendada, ` pois ela agrega qualidade ao processo e tem um ajuste natural a XP. As diferentes atividades de desenvolvimento demandadas pelo domnio de jogos, n o est o descritas por XP, por m devem ser consideradas, assim como novos processos a a e de suporte e diferentes artefatos relacionados a elas. O objetivo desta abordagem e capturar estas especicacoes e reet-las numa aplicacao pr tica de XP localizado. Assim, a nas pr ximas secoes, ser o abordadas intersecoes e conseq ente modicacoes para agreo a u gar metodologias que suportem a modelagem e desenvolvimento de jogos, como eXtreme Game Development (XGD) detalhada na subsecao 2.3. Uma visualizacao do resultado prentendido e demonstrado na gura 1.

Figura 1: XP + MA + XGD se complementando

3.2. XP + Modelagem Agil Os cart es de usu rio e os cart es CRC s o modelos. Logo e obvio que existe modelagem o a o a vezes, quando estes modelos n o s o sucientes para se entender um problema em XP. As a a ou comunicar, os desenvolvedores XP usam outros artefatos como citado em [5] (p g. a 111).

J que existe modelagem em XP, pode-se aplicar modelagem agil nela. Naturala ` mente, muitas das pr ticas da modelagem agil s o mapeadas diretamente a XP. Abaixo a a ` est o listadas algumas pr ticas que s o novas ou alternativas as pr ticas XP convencioa a a a nais: Aplique o(s) artefato(s) correto(s): escolha adequada de ferramentas ou t cnicas e disponveis mais apropriadas. Crie diversos modelos em paralelo: Os desenvolvedores XP podem criar diversos modelos em paralelo: cart es CRC, conjuntos de testes de aceitacao e esbocos o ` opcionalmente. Entretanto, quando se aplica modelagem agil a XP, n o deve se a restringir a apenas estes modelos. ` a Mostre os modelos de forma simples: Pr tica complementar a pr tica XP Dea sign simples. Os modelos n o precisam ser bonitos para serem ecazes. a Descarte os modelos tempor rios: Ao descartar modelos que n o se precisa a a mais, tamb m se est diminuindo a carga de trabalho futura para se manter modee a los. Formalize os modelos de contrato. Modele para comunicar. Modele para entender. Reuse os recursos existentes. Os desenvolvedores XP aplicam refactoring com freq encia. Logo, podem exisu tir situacoes em que o c digo-fonte que fora de sincronia com um modelo de projeto o ap s uma refatoracao. Para resolver este impasse com agilidade, deve-se questionar a o necessidade do modelo. Se ele tiver que ser mantido como documentacao, pode-se usar ferramentas CASE que automatizem a engenharia reversa do c digo-fonte para um moo delo. Neste caso, existem ferramentas disponveis que geram diagramas de classe ou de seq encia. A Modelagem Agil e naturalmente aplic vel a XP mesmo quando se trata de u a grandes refatoracao. 3.3. Modelagem Agil + XGD ` Como a Modelagem Agil e aplic vel a XP, ela tamb m ser aplic vel a XGD sem a e a a mudancas signicativas para o programadores. Por m para os n o-programadores, algu e a mas pr ticas essenciais mudam, tornando a modelagem e a documentacao mais ecazes. a A principal delas e relativa a documentacao e ao projeto de interface com o usu rio. a 3.4. Processo geral A abordagem apresentada nesta secao n o se prop e a ser uma nova metodologia, ela a o e apenas uma localizacao de XP. A localizacao e recomendada por Kent Beck no princpio secund rio Adaptacao local, lembrando que XP deve ser adaptada segundo a o ambiente de desenvolvimento local. Anal, segundo [8], modicar uma metodologia existente e mais f cil que criar uma ou mais efetivo que usar outra metodologia projetada a para uma nova situacao. A seguir, ser feita uma abordagem desta localizacao de XP segundo as etapas a cl ssicas de desenvolvimento de software: a Coleta de Requisitos: A coleta de requisitos na abordagem XP+XGD+modelagem agil e a mesma de a unidade de requisitos XP, onde o cart es de usu rio ou cart o de hist ria e o a a o funcionais. J a coleta de requisitos n o-funcionais n o e bem clara em XP, assim a a a como nas metodologias ageis em geral [17], cabendo a cada equipe o trabalho de detect -los e transform -los em cart es de tarefa. Isto e, os pap is do produtor e a a o e

game designer, que agem como clientes, t m uma boa nocao dos requisitos n oe a fucionais de um jogo, como performance e conabilidade, transformando-os em cart es de usu rio, naturalmente. o a Validacao de Requisitos: XP j faz uma validacao de requisitos naturalmente, pois a cada cart o de usu rio a a a e vericado se este e consistente e test vel [17]. Outras vericacoes como se o a requisito n o-ambguo e completo, s o resolvidos com a presenca constante do a a cliente e com desenvolvimento incremental respectivamente. Projeto Arquitetural: O trabalho de construcao de um esqueleto arquitetural de todo o sistema e feito na Fase de exploracao, onde o trabalho de uma equipe de modelagem se faz ne cess rio atrav s de uma sess o de modelagem agil para criar a met fora do sisa e a a tema. Segundo West [20], tal met fora deve ser t o forte a ponto de eliminar o a a projeto arquitetural detalhado. Se uma unica met fora n o puder satisfazer esta a a o, pode-se criar mais de uma met fora para partes do sistema. condica a Entretanto, pode-se considerar a met fora apenas como uma base arquitetural gea ral, onde o detalhamento da arquitetura vai sendo trabalhado ao longo do desenvolvimento. Projeto de Interface: A usabilidade (ou jogabilidade) e um dos principais requisitos funcionais de um jogo. Ela abrange o estudo sobre o uso de um produto por usu rios especcos a para alcancar objetivos especcos com efetividade, eci ncia e satisfacao em um e contexto de uso especco [22]. Ela est diretamente ligada ao Projeto de Interface a com o Usu rio e e a capacidade do software em permitir que o usu rio alcance a a suas metas de interacao com o sistema. O Projeto de Interface com o Usu rio entra no processo de design para melhorar a a experi ncia do usu rio (user experience). Como XP n o cita t cnicas de modelae a a e gem de interface, prop e-se o uso parcial da metodologia Goals - User Interface o Design (GUIDe) [15] com adaptacoes para XGD e Modelagem Agil. A GUIDe e uma m todo iterativo e inspirado nas metodologias ageis. e A GUIDe n o especica sua fase de aplicacao, podendo se adaptar bem em quala quer tipo de processo, inclusive nos que seguem o modelo cascata. De forma resumida, a GUIDe orienta como transformar requisitos em forma de use cases em interfaces implementadas. No caso da abordagem proposta neste trabalho, teremos alguns passos adaptados. Implementacao: A implementacao em XP, e feita em duplas (pair programming [1]): enquanto uma pessoa pilota o computador, usando o mouse e o teclado; a outra pensa na solucao, modela e revisa o c digo gerado. o Antes de implementar, inicia-se com a criacao dos testes autom ticos para veri a car quando o desenvolvimento da tarefa est encerrado. No domnio de jogos, a como temos duas frentes de desenvolvimento integradas: a producao do software e a producao do conte do, os cart es de tarefa s o repassados por todos os pro u o a ssionais requeridos na atividade. Mais detalhes sobre testes est o nas secoes a seguintes. Ap s cada atividade executada, o desenvolvedor registra a data e hora o de incio e data e hora de nalizacao, repassando o cart o de tarefa para o pr ximo a o prossional requerido. Abaixo est o listados os passos gerais de implementacao de um requisito funcioa nal (hist ria de usu rio), segundo a vis o de um programador: o a a 1. O cliente elabora uma hist ria que depois e estimada pela equipe. Se o a equipe n o consegue estim -la, o cart o de usu rio e dividido. Nesta a a a a

divis o e comum que funcionalidades ligadas ao desenvolvimento de softa ` ware se separem das atividades ligadas as demais areas, para se ter uma boa estimativa. Por m e importante vericar os cart es de usu rio que em e o a conjunto implementam uma funcionalidade maior do sistema para agrup a loss na iteracao corrente ou na seguinte. 2. A equipe de programadores transforma os cart es de usu rio em objetos. o a Agrupando os cart es de usu rio que tratam dos mesmos objetos. o a 3. escolhido um dos grupos de cart es de usu rio para implementacao o a na iteracao corrente. A equipe aproveita este tempo para discutir a implementacao seguindo a met fora do sistema (sua arquitetura). Ideal a mente, e feita uma sess o de modelagem agil em p . Depois os cart es de a e o usu rio selecionados s o nalmente divididos entre os pares. a a 4. Cada dupla, realiza uma r pida sess o de modelagem para discutir os dea a talhes da implementacao e construir os testes. Testes: Existem dois tipos de testes a serem realizados: autom ticos (sobre o c digo) e de a o game design (testes de jogabilidade, de design, balanceamento, harmonia visual entre outros). Os pares XP devem criar os testes autom ticos possveis e sucentes a para vericar quando a tarefa est nalizada. a o de um design eventualmente se transforma em uma tarefa subjetiva. A validaca Por m, pode-se considerar a exist ncia de padr es de interface para vericar se a e e o ` interface e us vel [14]. Os testes de validacao relativos a producao de conte do a u s o elaborados pelo produtor com o auxlio de um game design. Nesta etapa, a muitos testes s o focados na usabilidade (jogabilidade). a Durante a execucao dos testes de validacao gerais, e aconselh vel que exista um a mecanismo que registre as atividades do jogador para que o erro possa ser reproduzido novamente [17]. Existem muitos testes n o-funcionais sobre requisitos como performance. Por a exemplo: usar como m tricas o n mero de polgonos e tamanho de arquivos (i.e.: e u imagens, vdeos). 3.4.1. Documentacao do sistema A documentacao tamb m faz parte de XP, e geralmente ela ocorre ao nal do projeto, e pois o objetivo secund rio e se preparar para a pr xima jogada. Os diferentes tipos de a o documentos t m o seu prop sito e vantagens. Por m a decis o de se fazer documentacao e o e a deve ser uma decis o de neg cios. O cliente dever estar ciente que ao inv s de produzir a o a e software, parte da equipe estar alocada na producao de documentacao. a Existem quatro tipos de documentacao, relativas a producao do jogo como soft ware: Do sistema: e a documentacao mais importante para a manutencao do mesmo, fornecendo uma vis o geral. Diagramas em nvel de arquitetura s o freq entes a a u neste tipo de documento. De operacoes: e um resumo dos requisitos n o-funcionais do sistema com a informacoes como disponibilidade e conabilidade. De suporte: inclui materiais de treinamento para a equipe de suporte. De usu rio: s o os helps, Perguntas freq entes respondidas (FAQs) e manual a a u do jogo contendo guia da interface. ` Al m dos tipos de modelo citados, existem outros ligados a area de Game Design e como o Documento de Game Design [11]. Seguindo-se a Modelagem Agil, alguns des-

tes documentos podem ser minimizados ao mesmo tempo que se encontra novas formas de comunicar. Para as Metodologias Ageis, a producao tradicional de postmortem ao nal do ciclo de vida de um jogo, n o faz sentido, pois o feedback recebido e tardio e com certeza a n o trar nenhum benefcio ao jogo em desenvolvimento. Uma forma de agilizar isto e a a a producao de Early Postmortems (postmortems parciais) durante a fase de manutencao do projeto. Se o jogo estiver em producao e disponvel para ao p blico, por exemplo, a u ger ncia poder se beneciar deste resultado, podendo prever estrat gias de vendas. De e a e qualquer forma, a equipe de desenvolvimento vai ter um benefcio maior, pois poder a analisar o que deu certo ou n o, seguindo o princpio agil Regularmente, a equipe deve a reetir em como ser mais efetiva, ent o se ajustar adequadamente [2]. a 3.5. Vis o geral da abordagem a As Metodologias Ageis surgem para maximizar a concorr ncia entre as atividades, exise tindo uxos paralelos de desenvolvimento. Pode-se vericar isto, principalmente na abordagem descrita se as duas frentes de producao (software e conte do) forem consideradas. u Ao se focalizar a vis o dos desenvolvedores de software para a producao de um a jogo, a abordagem descrita nesta secao pode ser visualizada da seguinte forma (com iteracoes que duram de duas a tr s semanas): e

Figura 2: Visao do processo geral de producao do jogo (software)

4. Estudo de caso
O estudo de caso apresentado a seguir e uma aplicacao de eXtreme Programming com Modelagem Agil, no domnio de jogos. O processo pode ser visualizado como na gura 2 da secao anterior. 4.1. Descricao do problema O objetivo do caso e a criacao de um jogo com caracterstica de jogo de empresas (geral e funcional) e de massive multiplayer online game (MMOG). Um massive multiplayer online game (jogo multiplayer massivo) e um jogo disputado em tempo-real com um n mero n o-limitado de jogadores. Este requisito demanda o uso de novas arquiteturas u a como multi-servidoras, descentralizadas/distribudas ou hbridas [7]. E um projeto em desenvolvimento e apresenta aqui seus resultados parciais utilizando Modelagem Agil em XP. 4.1.1. Escopo O jogo foi dividido em duas partes: jogos ofine singleplayer (somente o usu rio contra a o computador) e jogos online massivos (v rios jogadores disputando em rede simultaa neamente). Foi denido o desenvolvimento da parte ofine primeiro. No nicio desta parte foi previsto um mecanismo de aprendizagem, como tutoriais inteligentes [16], para que o usu rio se habituasse com facilidade ao ambiente e alguns conceitos de jogos de a empresas. De forma resumida, cada jogador, receberia uma quantia em dinheiro virtual para criar uma empresa num ambiente de simulacao representado por um mapa com dados econ micos e din mica de cadeias produtivas pr prio. O objetivo do jogo e conseguir o o a o sucesso da empresa virtual, sua expans o, e o aprendizado pela experi ncia. Muito similar a e ao SimCity [3], por m a simulacao era baseada na administracao b sica de empresas. e a 4.2. Desenvolvimento O desenvolvimento do projeto em quest o foi pouco inuenciado pela abordagem de eXa treme Game Development, pois esta encontra-se em est gio inicial de desenvolvimento a contendo poucas refer ncias e pesquisas existentes. Grande parte do projeto descrito em e abordagem foi elaborado com o intuito de acrescentar novas informacoes a XGD. ` Para o ambiente de desenvolvimento, foi utilizado um espaco adequado para implementacao de XP, segundo a indicacao caves and commons [5], onde os computa dores s o pr ximos uns aos outros com espaco suciente para os pares de programacao, a o radiadores de informacao e espacos extras para modelagem, reuni es ou tarefas reserva o das. No projeto, existem pap is XP e relativos ao desenvolvimento de jogos: um game e designer/artista gr co; dois clientes (sendo um especialista em jogos empresariais); a quatro programadores; um coach; e um testador. Entretando a equipe e pequena e mista, o que d um total de seis pessoas, exceto um modelador 3D e um artista gr co a a em car ter de contratacao futura at a data deste documento. a e A equipe de desenvolvimento e, em geral, iniciante, deixando o desenvolvimento a primeira aplicacao de XP e de Modelagem Agil para em car ter experimental, pois e a todos os desenvolvedores. Dos quatro desenvolvedores, apenas dois tinham participado ativamente de modelagem de sistemas em projetos anteriores, o que fez muitas sess es de o modelagem agil serem realizadas apenas por uma dupla.

A equipe fez auto-treinamento em refactoring e CppUnit[21] para os testes de unidade, sendo feita duas apresentacoes sobre XP uma sobre Modelagem Agil e uma simulacao de XP para todos incluindo o cliente, chamada por muitos de eXtreme Hour [8](p g. 139). a Foram utilizadas as seguintes ferramentas para suportar comunicacao: Twiki, quadro-branco e ip chart. Para modelar ou criar documentacao agil tamb m foram utili e zadas Umbrello, Dia e plugin EclipseUML, al m de uma ferramenta CASE de engenharia e reversa. A execucao do projeto passou por uma grande mudanca de requisitos na sua pri meira iteracao, forcando o projeto a recomecar. O primeiro projeto de Game Design previa um jogo 2D isom trico como na gura 3, por m o cliente, ap s uma an lise de e e o a mercado, decidiu mudar para 3D, mudando o projeto, a plataforma de desenvolvimento, prossionais requeridos entre outras coisas. At o momento da producao da monograa, e

Figura 3: Prototipo 2D

o projeto passou por duas iteracoes. A primeira iteracao ocial, deixou uma vers o em a producao. A Fase exploracao foi de 5 semanas e o tempo de duracao m dio das iteracoes e foi tamb m de 4 semanas. As iteracoes seguintes devem durar de 2 a 3 semanas. e 4.2.1. Fases de desenvolvimento A coleta de requisitos no presente estudo de caso, foi feita atrav s de cart es de usu rio. e o a Algumas vezes, o cliente era representado pelo game designer que estava constantemente presente no local. Na primeira aplicacao de XP, nem todos os cart es de usu rio foram vericados o a se eram consistentes e test veis, incorrendo em requisitos mal coletados. Por m, este a e problema foi resolvido logo em seguida com a divis o de cart es de usu rio, permitindo a o a uma Validacao de Requisitos mais consistente. Os novos cart es de usu rio gerados o a eram mais simples, contendo funcionalidades e com maior facilidade de se gerar testes funcionais. Para uma base de Projeto Arquitetural foi utilizada uma met fora centrada no a pr prio projeto do jogo, onde as objetos principais eram os simuladores ofine e online. o Esta n o foi uma boa met fora, pois a maioria dos participantes desconhecia o conceito a a de simulacao. A segunda met fora elaborada foi baseada na din mica do jogo, onde os a a objetos identicados eram de f cil compreens o pelo cliente e pelos desenvolvedores. a a

Para o Projeto de Interface, foram utilizadas Sess es de modelagem agil, onde o partia-se dos cart es de usu rio passando por use cases at chegar ao prot tipo de intero a e o face com o usu rio essencial, seguindo uma GUIDe adaptada. a 4.2.2. Implementacao Logo no incio da iteracao, notou-se a necessidade de adicionar mais espaco nos cart es o de tarefa para anotacoes e coment rios sobre cada tarefa do dia, principalmente quando a a tarefa teria que continuar no dia seguinte. Algumas tarefas de interface foram executadas por demanda do cliente e/ou dos pr prios programadores. No estudo de caso, procurou-se separar as tarefas relativas a o producao da interface em cart es de tarefa diferentes dos de programacao de regras de o neg cio. Por exemplo, existiram cart es de usu rio para especicando a producao da o o a telas de entrada no sistema e outros que deniam como validar o usu rio. a N o foi feita nenhuma revis o arquitetural at a segunda iteracao. As classes a a e adicionais ao motor de jogos tiveram um design muito simples e preferiu-se agendar para o nal da pr xima iteracao. o 4.2.3. Documentacao do sistema Seguindo o princpio da Modelagem Agil Minimize a carga de trabalho, somente os use cases principais, cart es de usu rio e cart es CRC viraram documentacao ocial. o a o Existiram outro documentos produzidos como cart es de tarefa, cronogramas e prot tipos o o ` anteriores a aplicacao de XP. 4.3. Consideracoes No caso apresentado, por n o existir uma estimativa anterior semelhante, n o foi possvel a a estimar com precis o, aumentando o risco do projeto. Com o passar do tempo, este risco a diminuiu. Deve-se considerar n meros pares de desenvolvedores para a pr tica de pair u a programming, al m de dividir adequadamente pessoas com mesmas habilidades entre as e duplas, fazendo-as circular o conhecimento. Pela experi ncia, podemos considerar tr s pap is importantes para o acompanhae e e mento e desempenho das tarefas: o tracker, um papel de projetos XP respons vel por a acompanhar o progresso e velocidade da equipe; o coach; e o game designer.

5. Conclus o a
Hoje, os desenvolvedores brasileiros de jogos ainda enfrentam problemas como reducao de prazos de entrega e equipes pequenas (o que invalida, parcialmente, aplicacoes de metodologias mais pesadas como RUP). Assim, XP torna-se uma metodologia candidata natural por dar suporte ao aprendizado durante o desenvolvimento, agilidade, lidar com mudancas de requisitos e ter processos burocr ticos mais leves. Entretanto, a aplicacao a de eXtreme Programming n o e recomendada sem uma base s lida sobre os fundamentos a o e pr ticas da Engenharia de Software como a modelagem. a A aplicacao da Modelagem Agil em eXtreme Programming foi f cil e intuitiva, a melhorando o entendimento sobre a modelagem num projeto e reforcando pr ticas XP. a Ao se aplicar a Modelagem Agil, verica-se o signicado da frase de Scott Ambler: Na verdade, muitos desenvolvedores achar o que estar o fazendo mais modelagem do que a a

 ` antes. O que e equivalente a eXtreme Programming, pois antes mesmo de se implementar o c digo desejado, deve-se implementar testes. E nem por estas raz es existe o o perda de eci ncia. Muito pelo contr rio. As metodologias ageis est o revolucionando e a a a Engenharia de Software, porque elas valorizam mais os indivduos do que processos e ferramentas. E uma abordagem diferente que foca o maior causador de erros, o indivduo, podendo potencializar tanto as qualidades como os defeitos humanos. 5.1. Resultados Como resultado parcial da aplicacao da abordagem no domnio de jogos, vericou-se que tornou os processos de modelagem e documentacao mais ecazes. As a Modelagem Agil dicas uteis fornecidas pelas pr ticas, auxiliaram a aprendizagem e aumento de ec cia a a dos modeladores. A principal diferenca e que a tarefa de modelar deixou de ser vista como um fardo para se tornar atividade prazerosa que agrege valor ao desenvolvimento de software. 5.2. Diculdades encontradas Uma das diculdades em se aplicar Modelagem Agil e seguir a pr tica Modele increa a mentalmente, pois sempre e f cil cair na armadilha de se modelar todo o sistema de uma vez, tentando congelar os requisitos. Outro problema e que a Modelagem Agil exige que se conheca muitos artefatos diferentes. A equipe teve que buscar bibliograa complementar, usando para refer ncia e em UML os livros UML na Pr tica - Do Problema ao Sistema [6] e UML 2 - Guia de a Consulta R pida [12], para correlacionar a simplicidade e agilidade oferecidas pelos moa delos/diagramas UML. Outras refer ncias sobre modelagem de Interface com o Usu rio e a por exemplo, foram buscadas na internet atrav s de v rias fontes como [19]. e a 5.3. Trabalhos futuros Um trabalho futuro deste projeto e a complementacao da eXtreme Game Development, visto que e uma metodologia baseada em eXtreme Programming muito recente e pouco denida. Um ponto de investigacao da XGD seria o processo de desenvolvimento segundo a vis o dos desenvolvedores n o-programadores. Um segundo ponto, seria como obter a a melhores estimativas de desenvolvimento.

Refer ncias e
[1] Pair programming, an extreme programming practice. URL: http://www. pairprogramming.com, 2001. Ultimo acesso em 17 de dezembro de 2004. [2] Agile Alliance. Agile alliance. URL: http://www.agilealliance.org, 2001. Ultimo acesso em 07 de dezembro de 2004. [3] Lynn Alves. Sim city. URL: http://www.comunidadesvirtuais.pro.br/ ead/simcity.htm, 2004. Ultimo acesso em 24 de julho de 2005. [4] Scott W. Ambler. Modelagem Agil - pr ticas ecazes para a Programacao eXtrema e o a Processo Unicado. Addison Wesley, S o Paulo, 2004. a [5] Kent Beck. Extreme Programming Explained: Embrace Change. Addison Wesley Professional, 2000. [6] Caque Cardoso. UML na Pr tica - Do Problema ao Sistema. Editora Ci ncia Moderna, a e 2003.

[7] F bio Reis Cecin, Jorge Luis Vict ria Barbosa, and Cl udio Fernando Resin Geye. Frea o a emmg: An hybrid peer-to-peer, client-server and distributed massively multiplayer game simulation model. In Proceedings of WJogos 2003, Brazilian Workshop of Games and Digital Entertainment. Sociedade Brasileira de Computacao, 2003. [8] Alistair Cockburn. Agille Software Development. Addison Wesley Professional, 3th edition, 2002. [9] Thomas Demachy. Extreme game development: Right on time, every time. URL: http://www.gamasutra.com/resource\_guide/20030714/ demachy\_01.shtml, 2003. Ultimo acesso em 16 de dezembro de 2004. [10] ExtremeGameDev. Extremegamedev wiki: Extremegamedev. URL: http://www. extremegamedev.org/, 2005. Ultimo acesso em 22 de julho de 2005. [11] Tzvi Freeman. Creating a great design document. URL: http://www.gamasutra. com/features/19970912/design\_doc.htm, 1997. Ultimo acesso em 20 de julho de 2005. [12] Gilleanes T. A. Guedes. UML 2 - Guia de Consulta R pida. Editora Novatec, 2003. a [13] Reginaldo G. Valadares Jefferson L. F. Valadares. Extreme game development. In Proceedings of WJogos 2003, Games and Digital Entertainment Workshop, Salvador, BA, BRA, 2003. Sociedade Brasileira de Computacao. [14] Sari A. Laakso. User interface design patterns. URL: http://www.cs.helsinki. fi/u/salaakso/patterns, 2003. Ultimo acesso em 19 de julho de 2005. [15] Sari A. Laakso and KarriPekka Laakso. Ensuring quality of the user interface with the guide process model. URL: http://www.cs.helsinki.fi/u/salaakso/ papers/GUIDe.html, 2004. Ultimo acesso em 19 de julho de 2005. [16] A.C.R. Mascarenhas and M.A. de Carvalho. Um gerador de sistemas tutoriais inteligentes para auxlio a alfabetizacao em portugu s. In Anais do Congresso da SBC - VIII ` e WIE (SBC 2002), Florian polis, Santa Catarina, BRA, 2002. Sociedade Brasileira o de Computacao. p.249-54. [17] Frauke Paetsch. Requeriments engineering in agile software development. page 72, 2003. Diploma Thesis. [18] Roger S. Pressman. Engenharia de Software. Makron Books, S o Paulo, 2005. a [19] Usernomics. User interface design & usability testing. URL: http://www. usernomics.com/user-interface-design.html, 2005. Ultimo acesso em 19 de julho de 2005. [20] David West. Object Thinking. Microsoft Press, 2004. [21] John Whitlock, Andrey Melnikov, and Baptiste Lepilleur. Cppunit wiki. URL: http:// cppunit.sourceforge.net/cgi-bin/moin.cgi, 2005. Ultimo acesso em 25 de julho de 2005. [22] Wikipedia. Iso 9241-11. URL: http://pt.wikipedia.org/wiki/ISO\ _9241-11, 2005. Ultimo acesso em 21 de julho de 2005.