UNIVERSIDADE FEDERAL DA BAHIA INSTITUTO DE MATEMATICA

DEPARTAMENTO DE CIENCIA DA COMPUTACAO

ABELMON DE OLIVEIRA BASTOS

MAPEAMENTO DO PROCESSO DE MODELAGEM EM EXTREME PROGRAMMING NO DOMINIO DE JOGOS

Salvador 2005

ABELMON DE OLIVEIRA BASTOS

MAPEAMENTO DO PROCESSO DE MODELAGEM EM EXTREME PROGRAMMING NO DOMINIO DE JOGOS

Monograa apresentada ao Curso de graduacao em Ci ncia da Computacao, e Departamento de Ci ncia da Computacao, e Instituto de Matem tica, Universidade Fea deral da Bahia, como requisito parcial para obtencao do grau de Bacharel em Ci ncia da e Computacao. Orientadora: Profa . Christina von Flach Garcia Chavez

Salvador 2005

A Deus por toda a caminhada. Aos meus pais por permitirem os caminhos abertos.

AGRADECIMENTOS
Primeiramente, a Deus por permitir as mudancas no mundo; aos meus pais, Rosa Maria de O. Bastos e Abelmon Lima Bastos, por n o mudarem e mesmo sendo as mesmas pessoas podea rem me surpreender com licoes de vida (embora eu agradece tamb m a inu ncia materna pelo e e gosto a mudancas); a minhas irm s, Maria C ndida e Ros ngela, por todo o apoio; aos mes a a a tres do DCC e Matem tica, principalmente minha orientadora, Christina, por ter a paci ncia a e de quem acompanhou minha mudanca gil de um ano de projeto nal; aos participantes do a projeto SuperNova por terem suportado comigo as mudancas de rumo; e aos amigos (da InfoJr UFBA, da Open, do trabalho, da faculdade - principalmente 1999.1 a 2000.2 - e da vida - e at e do Orkut!) e demais familiares pela torcida incondicional e imut vel. a

Mortal algum recebeu educacao sem sofrer. S focles o

RESUMO

O desenvolvimento de jogos e uma tarefa complexa por ser multidisciplinar e exigir alto grau de qualidade. No Brasil, os desenvolvedores de jogos est o utilizando como metodologia, a a eXtreme Programming (XP). Por m uma d vida crucial surge: sendo XP uma Metodologia e u Agil que prioriza mais um software desenvolvido do que documentacao abrangente, como e tra tada a modelagem? O projeto tem o objetivo de mapear o processo de Modelagem em eXtreme Programming no domnio de jogos, apresentando a implementacao de um caso dentro deste guiada por um uxo exvel de processo a ser identicontexto usando XP com Modelagem Agil cado. Este trabalho tamb m apresenta discuss es para esclarecer diversos mitos que envolvem e o o mal entendimento da eXtreme Programming e sua conseq ente aplicacao falha. u Palavras-chave: extreme programming, modelagem agil, jogos

ABSTRACT

Game development is a complex task involving a heterogenous team and demands a high quality work. At Brazil, the game developers are using like metodology, the eXtreme Programming (XP). However a crucial doubt appears: being XP a Agile Methodology that values working software over comprehensive documentation, how is treated the modeling activity? 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. This work also show discussions to clarify some mites involving misunderstanding about eXtreme Programming and its consecutive fail application. Keywords: extreme programming, agile modeling, games

LISTA DE FIGURAS

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Custos de manutencao. (BECK, 2000) . . . . . . . . . . . . . . . . . . . . . . Comunicacao em projetos sem e com uma abordagem agil: (A) e (B) . . . . . . Relacionamento entre as pr ticas MA . . . . . . . . . . . . . . . . . . . . . . a Cart o Class-Responsability-Collaborator . . . . . . . . . . . . . . . . . . . . a XP visto como um processo . . . . . . . . . . . . . . . . . . . . . . . . . . . Escopo de XP (COCKBURN, 2002) . . . . . . . . . . . . . . . . . . . . . . . . XP + MA + XGD se complementando . . . . . . . . . . . . . . . . . . . . . . Prot tipo de interface com o usu rio essencial (baixa denicao) . . . . . . . . o a Vis o do processo geral de producao do jogo (software) . . . . . . . . . . . . . a Um dos radiadores de informacao usados . . . . . . . . . . . . . . . . . . . . Prot tipo 2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o Exemplo de cart o de usu rio utilizado . . . . . . . . . . . . . . . . . . . . . . a a Modelo agil de arquitetura de rede . . . . . . . . . . . . . . . . . . . . . . . . Cart o de tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a

13 16 28 40 43 43 47 51 55 58 59 59 60 60

LISTA DE TABELAS

Fases de producao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

 SUMARIO

1 2

Introducao Metodologias Ageis 2.1 2.2 Contexto das mudancas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manifesto Agil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 2.3 2.4 Princpios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 12 12 13 14 15 16 19 20 20 21 24 24 26 28 28 29 29 30 31

O ponto-chave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Modelagem Agil 3.1 3.2 3.3 3.4 Denicoes gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Princpios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pr ticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 B sicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a Suplementares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modelagem Agil na pr tica . . . . . . . . . . . . . . . . . . . . . . . . a Criacao de uma cultura agil . . . . . . . . . . . . . . . . . . . . . . . Sess es de Modelagem Agil . . . . . . . . . . . . . . . . . . . . . . . o Usando as ferramentas mais simples . . . . . . . . . . . . . . . . . . . Documentacao Agil . . . . . . . . . . . . . . . . . . . . . . . . . . .

Domnio de Jogos

4.1

Domnio do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31 31 32 32 33 33 34 36 36 38 38 38 39 39 40 40 41 42 43 43 44 45 46 46 46

4.2 4.3

G neros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Caractersticas do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 4.3.2 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . Requisitos n o-funcionais . . . . . . . . . . . . . . . . . . . . . . . . a

4.4 5

Desenvolvimento de jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Analisando eXtreme Programming 5.1 5.2 Resumo sobre XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XP e a modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 5.2.2 5.2.3 5.2.4 5.3 Met fora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a Jogo do Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . Design Simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sess es CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o

XP como processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 5.3.2 5.3.3 5.3.4 Pap is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ciclo de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . Escopo de XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4

XP e Desenvolvimento de Jogos . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 5.4.2 Pap is . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e Pr ticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . a

Descricao da abordagem 6.1 6.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XP + Modelagem Agil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.2.1 6.3 6.4 6.5

Refatoracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48 48 49 49 53 54 56 56 56 57 57 57 57 58 58 59 59 60 61 61 61 62 63 64 64

Modelagem Agil + XGD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abordagens complementares . . . . . . . . . . . . . . . . . . . . . . . . . . . Processo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 6.5.2 Documentacao do sistema . . . . . . . . . . . . . . . . . . . . . . . . Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Estudo de caso 7.1 Conceitos preliminares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.1.1 7.1.2 7.2 Jogos de Empresas . . . . . . . . . . . . . . . . . . . . . . . . . . . . MMOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Descricao do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7.3

Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.1 7.3.2 7.3.3 7.3.4 Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tecnologias e ferramentas . . . . . . . . . . . . . . . . . . . . . . . . Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fases de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . 7.3.4.1 7.3.4.2 7.3.5 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . Documentacao do sistema . . . . . . . . . . . . . . . . . . .

Modelagem Agil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3.5.1 Pr ticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . a

7.4 8

Consideracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclus es o 8.1 8.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diculdades encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8.3

Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64 66

Refer ncias e

10

INTRODUCAO

O mercado de jogos mundial v m crescendo 20,1% em m dia ao ano, superando as cifras e e do cinema (PICCINNO, 2003). A grande demanda por novos jogos tem atrado a atencao de grandes corporacoes e incentivado a entrada de novas playwares(empresas especializadas em desenvolvimento de jogos) na disputa por este mercado. No Brasil, este mercado movimenta anualmente R$120 milh es, o que justica um crescimento acentuado na comunidade de deseno volvimento de jogos brasileira (JOGOS. . . , 2004) e o surgimento de cursos focados em Game Design. A producao de um software e uma atividade complexa, especialmente quando nos referi mos a jogos, pois seu projeto e multidisciplinar, demandando especialistas de diversas sub reas a da computacao como redes, sistemas distribudos, computacao gr ca, intelig ncia articial, a e processamento de audio, realidade virtual entre outras. Dependendo do g nero do jogo a ser e criado, podem exister tamb m intersecoes com outras areas (design gr co, matem tica, fsica, e a a hist ria...) e com outros domnios. o 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 (PRESSMAN, 2005). Muitos destes requisitos s o a a identicados ap s uma an lise do domnio do problema, onde alguns requisitos do domnio de o a jogos como usabilidade s o considerados ainda mais crticos que de softwares convencionais. a Segundo Ian Somerville (SOMERVILLE, 2003), neste s culo, a Engenharia de Software e enfrenta tr s desaos principais: e

 Manutencao e atualizacao de Sistemas legados de forma economicamente viavel e garantindo a entrega dos servicos prestados por estes sistemas.

 Desenvolvimento de software conavel e exvel o bastante para ser bem-sucedido num

ambiente computacional heterog neo. e

 Diminuicao dos prazos de software de qualidade, ao mesmo tempo com aumento da com-

11

plexidade deste. Felizmente, surgiram as Metodologias Ageis (COCKBURN, 2002) que focam justamente na solucao deste ultimo ponto. Uma das principais metodologias ageis e eXtreme Programming (XP) (BECK, 2000) que defende a aplicacao extrema de boas pr ticas de desenvolvimento, focando mais o software em a funcionamento do que documentacao abrangente. Esta metodologia apresenta algumas carac tersticas peculiares como a programacao em pares, e desde seu surgimento tem sido bastante utilizada pela ind stria internacional de software. u No Brasil, eXtreme Programming tem demonstrado boa adaptacao no desenvolvimento de jogos (VALADARES, 2003) 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 Engenharia a o de Software, sendo que at 2003, freq entemente as atividades de programacao eram feitas por e u prossionais de outras areas, que obviamente n o tinham conhecimento adequado na area. a A producao de modelos e freq entemente usada em diversas etapas da producao de um u software segundo a Engenharia de 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 Metodologias Ageis, uma d vida crucial surge: sendo u XP uma metodologia agil que prioriza mais um software desenvolvido do que documentacao abrangente (BECK, 2000), 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 e o modelagem em eXtreme Programming deve ser considerada, gerando um software de melhor qualidade. O captulo seguinte far uma introducao sobre as Metodologias Ageis de modo geral. Os a captulos 3 e 4 introduzir o conceitos-chave como Modelagem Agil e Projeto de Jogos atrav s a e da explanacao sobre o domnio de jogos e seu desenvolvimento peculiar. O captulo 5 apresen tar uma An lise sobre eXtreme Programming esclarencendo alguns pontos obscuros de sua a a aplicacao. Depois a abordagem seguida para o t pico de pesquisa ser descrita no captulo 6 e o a o estudo de caso utilizado, no captulo 7. Por m, uma breve an lise e conclus es no captulo a o 8.

12

METODOLOGIAS AGEIS

Este trabalho relata a atividade de modelagem na metodologia eXtreme Programming, no domnio de de jogos. Como XP e a Modelagem Agil s o metodologias ageis, esse captulo e a ` dedicado a introducao dos conceitos que envolvem as metodologias ageis, abordando tamb m e o contexto do surgimento deste novo paradigma na Engenharia de Software.

2.1

CONTEXTO DAS MUDANCAS

De uma maneira geral, pode-se armar que os projetos de desenvolvimento de software tem sido de preocupacao constante para clientes do sistema (stakeholders), gerentes de projeto e para os pr prios desenvolvedores. Adiamentos nos prazos de entrega do produto, longas o fases de an lise de requisitos, estouro no orcamento do projeto, fases de testes insucientes, a cancelamento de projetos, produtos com alta taxa de defeitos e requisitos que n o satisfazem as a necessidades reais dos clientes s o apenas alguns exemplos que servem para ilustrar a gravidade a dos problemas encontrados durante o desenvolvimento de software at hoje. Tal cen rio pode e a ser descrito como uma crise. Para lidar com esta Crise do software, in meros prossionais de computacao estabeleceram u pr ticas e princpios baseados na Engenharia para a producao de software con vel e funcioa a nalmente eciente, reforcando o conceito de Engenharia de Software e do conseq ente uso da u met fora da Engenharia Civil para as atividades de desenvolvimento de software. Entretanto, a 30 anos ap s a denicao e aplicacao dos paradigmas da Engenharia de Software, ainda se o vive esta crise. Segundo (PRESSMAN, 2005), Crise seria um ponto decisivo no curso de algo(...). Contudo, para o sofware, n o tem havido nenhum ponto decisivo (...) temos tido uma crise que a nos acompanha h quase 30 anos, e essa e uma contradicao em termos. Paradigmas como o a ciclo de vida cl ssico deveriam ter posto m a v rios problemas de desenvolvimento de softa a ware, j que proviam fases ordenadas e bem denidas como: Engenharia de Sistemas, An lise a a

13

de Requisitos, Projeto de Software, Codicacao, Testes e Manutencao. Verica-se que durante o ciclo de vida cl ssico, 60% dos custos s o de desenvolvimento a a e 40% s o de testes, sendo que para softwares customizados, os custos de evolucao excedem a os de desenvolvimento (SOMERVILLE, 2003). De fato, os custos de mudancas do software se elevam na proporcao de 60 a 100 vezes durante fases nais, no ciclo de vida cl ssico, como a de a manutencao. Por m, este fato apenas reforca a contradicao citada por Pressman, j que o longo e a planejamento inicial era feito para evitar custos futuros. Por m com o surgimento de novas tecnologias de desenvolvimento como as ferramentas e de quarta-geracao, novas t cnicas de programacao e de Engenharia de Software (orientacao e a aspectos , desenvolvimento orientado a testes, refatoracao, padr es de projeto entre outros) o , podemos vericar que os custos de manutencao podem ser considerados menores segundo a gura 1.

Figura 1: Custos de manutencao. (BECK, 2000) Voltando a quest o da Engenharia de Software, a reducao dos custos de manutencao reforca a a d vida: Por que n o e possvel a entrega de software util de qualidade e com eci ncia? u a e Com a evolucao das ferramentas e m todos, o problema provavelmente reside nas pessoas, e ou melhor, no lado humano do processo de software. Em fevereiro de 2001, em Uthan, um grupo inicial de 17 metodologistas analisou a quest o e formando a Agile Software Development a Alliance (ALLIANCE, 2001) ou somente Agile Alliance, deniram um manifesto para encorajar melhores meios de desenvolvimento de software.

2.2

MANIFESTO AGIL

` Este manifesto tem como principais motivacoes: o rompimento as resist ncias aos proces e sos usuais, tornando o processo de desenvolvimento mais simples e natural para os desenvolve-

14

dores, e possibilindo a mudanca de requisitos durante o projeto, reetindo as necessidades do cliente e minimizando os riscos de fracasso do projeto. O Manifesto Agil e denido pelas simples declaracoes de valores que denem prefer ncias, e n o alternativas, encorajando o enfoque de certas areas, mas sem eliminar outras (AMBLER, a 2004). S o elas: a  Indivduos e interacoes valem mais que processos e ferramentas  Um software funcionando vale mais do que documentacao abrangente  A colaboracao do cliente vale mais que a renegociacao do contrato  Responder a mudancas vale mais que seguir um plano Com base neste manifesto, a Agile Alliance deniu um conjunto de princpios que s o a seguidos nos processos de desenvolvimento agil de software.

2.2.1

PRINCIPIOS

 A maior prioridade e a satisfacao do cliente atraves da entrega rapida e contnua de soft ware util.

 A mudanca de requisitos sera bem recebida em qualquer momento do desenvolvimento,

mesmo em uma fase mais avancada no desenvolvimento.

 A entrega de software devera ser freq ente, em poucas semanas ou meses, mas sempre u
preferindo a menor escala.

 Pessoas que entendem o neg cio e desenvolvedores devem trabalhar juntos diariamente. o  Construa projetos com pessoas motivadas, dando todo o suporte necessario a elas e
conanca.

 O metodo mais eciente e ecaz de entregar/disseminar a informacao em uma equipe de

desenvolvimento e a conversa frente-a-frente.

 Software em funcionamento deve ser a metrica de progresso.  Processos ageis promovem substancialmente o desenvolvimento. Clientes, desenvolvedores e usu rios deveriam ser capazes de manter a paz indenidamente a

15

 Atencao contnua a excelecia tecnica e o bom projeto aumentam a agilidade.  Simplicidade - a arte de maximizar a quantidade de trabalho a nao ser feito - e essencial.  As melhores arquiteturas, requisitos, e projetos emergem de equipes organizadas.  Em intervalos regulares, a equipe deve reetir sobre como podem ser mais efetivos, entao
devem ajustar seu comportamento de acordo com isso. As metodologias ageis devem se adequar a tais princpios ou correm o risco de n o per a tencer a tal classicacao. At ent o, muitas metodologias novas eram rgidas como a Personal e a Software Process. As metodologias ageis vieram romper com esta l gica, j que s o metodoloo a a gias baseadas no comportamento humano natural. Entretanto, as principais metodologias ageis como eXtreme Programming, Crystal Clear (COCKBURN, 2002), Dynamic System Development Method (CONSORTIUM, 1994) e Feature Driven-Development (NEBULON, 2002) entre outras surgiram antes do Manifesto Agil. Ali s, a ` alguns autores destas metodologias zeram parte do grupo inicial que deu origem a Agile Alliance e os princpios que norteiam as metodologias ageis foram extrados das experi ncias e pr ticas destes autores com suas metodologias. a

2.3

O PONTO-CHAVE

Na realidade, os valores e princpios da Agile Alliance n o explicitam o que podemos con a siderar como o ponto-chave das metodologias ageis : a comunicacao. As metodologias ageis sugerem sutilmente o m da met fora da Engenharia Civil em prol do jogo cooperativo, comunia cativo e inventivo com recursos limitados ou simplesmente jogo cooperativo da comunicacao com os seguintes objetivos claros (COCKBURN, 2002):

 entregar o software com qualidade e valor ao cliente como objetivo principal;  preparar-se para a pr xima jogada como objetivo secundario. o
Assim, esta nova denicao se aproxima mais do domnio e entendimento humano. Os parti cipantes deste jogo seriam: programadores, patrocinadores, gerentes, especialistas, consultores, designers e testadores. Cada membro da equipe deve se comportar como um especialista da comunicacao, interagindo e desenvolvendo com todos os participantes. E os produtos de traba lho gerados devem ser trabalhados at um ponto suciente ao prop sito de encaminhar a tarefa e o ` o a pr xima pessoa.

16

No exemplo, da gura 2, a equipe de desenvolvimento do projeto (A) n o trabalha com a metodologias ageis enquanto a equipe do projeto (B), sim; demonstrando a participacao ativa de todos os participantes. No caso (B), existe incentivo para a participacao do cliente dentro da equipe, tornando-se fonte de requisitos diretamente para os desenvolvedores.

Figura 2: Comunicacao em projetos sem e com uma abordagem agil: (A) e (B) Para as Metodologias Ageis o desenvolvimento de software n o deve ser considerado um a jogo plug&play ou posicional. Isto e, quando se substitui ou adiciona-se novas pessoas a um projeto, estas podem n o conseguir descobrir pela documentacao o estado em que o desenvolvia mento se encontra, porque as pessoas possuem comportamentos diferentes e n o reagem como a funcoes lineares (COCKBURN, 2002). Desta forma, a comunicacao e considerado um fator t o crucial para o projeto que muitas a Metodologias Ageis delimitam inclusive o ambiente de desenvolvimento. Em (COCKBURN, 2002), Alistar Cockburn apresenta o conceito de erg-seconds como uma unidade usada para medir a quantidade de energia gasta para mover uma id ia de uma mente para a outra. Ele e usa a met fora de dispers o de g s como exemplo para demonstrar a dispers o da informacao a a a a em um ambiente de trabalho e armando que o layout deste deve ser favor vel para uma boa a comunicacao entre as pessoas da equipe ( comunicacao osm tica). o

2.4

EXEMPLOS

Em comparacao ao desenvolvimento tradicional de software, o desenvolvimento agil e me nos orientado-a-documentos e mais orientado-a-c digo. Por m, sendo isto um reexo de o e duas diferencas mais profundas entre os dois estilos: M todos ageis s o mais adaptativos que e a preditivos, acolhendo bem as mudancas e mais orientado-a-pessoas, conando mais em ha bilidades, compet ncia e colaboracao, que orientado-a-processos (PAETSCH, 2003). Abaixo e uma descricao de algumas metodologias ageis.

17

 eXtreme Programming (BECK, 2000): e uma disciplina de desenvolvimento de software

baseada nos valores de simplicidade, comunicacao, feedback, e coragem. Ela funciona reunindo toda a equipe sobre pr ticas simples, com feedback suciente para que todos a saibam onde est o no desenvolvimento. Mais sobre XP ser discutido no captulo 5. a a  Modelagem Agil (AMBLER, 2004): tem seu foco em um conjunto de basicos e suple mentares princpios e pr ticas de modelagem. A Modelagem Agil e inspirada em XP, a pontuando que as mudancas no desenvolvimento de software s o comuns e devem afetar a a forma de desenvolvimento, e por extens o, a forma de modelar. Mais sobre Modelagem a Agil ser discutido no captulo 3. a

 Scrum (GROUP, 1995): e um metodo para gerenciar o processo de desenvolvimento de

sistemas, aplicando id ias da teoria de controle de processos industriais como exibilie dade, adaptabilidade e produtividade. Scrum n o prop e nenhuma t cnica particular de a o e implementacao, focando em como uma equipe deve trabalhar junta para produzir trabalho de qualidade em ambientes de mudanca.

 Crystal Methodologies (COCKBURN, 2002): sao uma famlia de diferentes metodologias. Alistair Cockburn, seu desenvolvedor, acredita que para cada tipo diferente de projeto deva existir uma metodologia que se adeque mais. As metodologias est o indea xadas por diferentes cores para indicar sua dureza (m trica originada do tamanho do e projeto e seu peso).  Feature Driven Development (NEBULON, 2002): e um processo de iteracoes curtas (duas semanas) focando no projeto (design) e na fase de construcao. Feature Driven Development (FDD) n o recomenda um modelo de processo especco. FDD consiste de a cinco processos seq enciais: u Desenvolvimento de um modelo geral; Construcao de uma lista de funcionalidades(features); Planejamento por funcionalidade; Projeto por funcionalidade; e Construcao por funcionalidade.

 Dynamic Systems Development Method (CONSORTIUM, 1994): prove um framework

para desenvolvimento r pido de aplicacoes. Dynamic System Development Method (DSDM) a consiste de cinco fases, e suas iteracoes s o denominadas time boxes, que duram entre a poucos dias ou semanas.

18

 Adaptive Software Development (ASD) (HIGHSMITH, 1996): prove um framework

para o desenvolvimento de sistemas grandes e complexos com coordenacao suciente que evite caos no projeto. Seus princpios v em de pesquisa em desenvolvimento iterativo, e encorajando tal tipo de desenvolvimento com o a contrucao de prototipagem constante. O processo ASD cont m tr s fases n o-lineares e sobrepostas: especulacao, colaboracao e e a e aprendizagem (PAETSCH, 2003).

19

MODELAGEM AGIL

A Modelagem Agil e uma metodologia agil baseada na pr tica para modelagem e documentacao a ecazes de sistemas baseados em software. Ela e um conjunto de pr ticas guiado por princpios a (derivados dos princpios da Agile Alliance) e valores para desenvolvedores aplicarem no seu dia-a-dia, fornecendo conselhos sobre como ser um modelador eciente (AMBLER, 2004), focando no desenvolvedor m dio. e A Modelagem Agil n o e um processo prescritivo, em vez disso, e independente de outros a processos de software, mesclando o caos de pr ticas simples de modelagem com a ordem a inerente a artefatos de modelagem de software, num processo ca rdico. Ela n o se refere o a a nenhuma t cnica de Engenharia de Requisitos (ER), mas suas pr ticas d o suporte a v rias e a a a t cnicas ER (PAETSCH, 2003). e Para aplicar Modelagem Agil deve-se considerar que h duas raz es b sicas para modelar: a o a para entender o que se est construindo ou para melhorar a comunicacao, seja dentro da equipe a ou com os clientes do projeto. Assim, sua denicao segue tr s objetivos: e

 Denir e mostrar como colocar em pratica um conjunto de valores, princpios e praticas

relativas a uma modelagem ecaz e leve. O que torna a modelagem agil uma catalisadora de melhorias e como aplicar as t cnicas de modelagem e n o as t cnicas em si. e a e

 Lidar com a questao de como aplicar tecnicas de modelagem em projetos de software

adotando uma perspectiva agil.

 Discutir como melhorar as atividades de modelagem adotando uma perspectiva quase

agil mesmo para uma equipe que esteja adotando processos n o- geis como Rational a a Unied Process (RUP).

20

3.1

DEFINICOES GERAIS

Para um melhor entendimento sobre o que e uma Modelagem Agil Scott Ambler (AMBLER, 2004) dene alguns t picos como: o  Modeladores ageis: qualquer pessoa que siga a Modelagem Agil.  Modelos ageis: sao modelos bons o suciente. Isto e, eles:

cumprem com o seu

prop sito (seja compreens o do problema ou comunicacao); s o sucientemente como a a preensveis, precisos, consistentes e detalhados; proporcionam valor positivo (os recursos gastos na construcao do modelo s o menores que o retorno ao projeto); e s o os mais a a simples possveis. Desta forma, a Modelagem Agil e uma esp cie de atitude, um suplemento dos m todos e e pr -existentes, complementar aos processos de modelagem, ecaz, eciente e deve ser feita em e a equipe. Analogamente, a MA n o e um processo prescritivo, nem uma metodologia completa, nem uma bala-de-prata, n o elimina a criacao de documentacao e nem o uso de ferramentas a CASE.

3.2

VALORES

Assim com eXtreme Programming, a Modelagem Agil tamb m usa a id ia de valores para e e contruir uma base para a metodologia. A Modelagem Agil foi inspirada 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 dos valores das metodologias e ageis n o e por simples ret rica, mas para provocar nos desenvolvedores um envolvimento a o los co sobre novas formas de projetar e desenvolver software. Portanto, os valores da MA o s o: a  Comunicacao: e uma via de mao dupla onde ambas fornecem e obtem informacoes como resultado. A comunicacao e fundamental para uma modelagem. Seja para informar o estado de tarefas, de projetos, id ias de modelagem, requisitos ou prioridades, ela e e e um requisito para o sucesso do desenvolvimento de software. Segundo Ambler, os problemas ocorrem quando ela termina. Outros detalhes da import ncia da comunicacao a para as Metodologias Ageis foram discutidos em 2.3.

21

 Simplicidade: e a arte de maximizar a quantidade de trabalha a nao ser feito. E um valor ` diretamente ligado a regra KISS (Keep It Simple Stupid - Matenha Isto Simples, Idiota). A simplicidade pode ser conquistada, ao se evitar: aplicar padr es complexos cedo deo mais; criar arquiteturas em excesso para suportar requisitos futuros; ou desenvolver uma infra-estrutura complexa.  Feedback: e o unico modo de determinar se o trabalho (em qualquer nvel, inclundo os modelos) est correto, atrav s de algumas formas: desenvolva o modelo em equipe; rea e vise o modelo com seu p blico-alvo; implemente o modelo; e execute testes de aceitacao. u Quanto mais r pido for o retorno, menor a possibilidade do modelo desviar-se das necesa sidades reais e maior a aprendizagem sobre a modelagem executada.

 Coragem: signica ser aberto a mudancas; trabalhar em equipe, conando nas pessoas e
em seu pr prio trabalho. Separar as decis es t cnicas para a equipe t cnica e as decis es o o e e o de neg cios para o pessoal de neg cios e ter coragem. E necess rio coragem para validar o o a modelos com c digo, para reconhecer erros e conar que poder superar no futuro os o a problemas que surgir o. a

 Humildade: signica que todos devem aprender com todos, nao existindo donos da
verdade. A melhor forma de aprender, e admitir que e preciso a ajuda de outra pessoa para realizar bem o seu trabalho. Isto e uma premissa para um bom trabalho em equipe, e por extens o, um bom desenvolvimento de software. a

3.3

PRINCIPIOS

Os valores s o denicoes muito abstratas para serem colocadas em pr tica. Por isso, a a tamb m s o denidos princpios b sicos e suplementares da Modelagem Agil conceitos muito e a a mais concretos. Na Modelagem Agil os princpios b sicos devem ser adotados integralmente a para se armar que se est modelando com agilidade. J os suplementares, apoiam os b sicos, a a a denindo conceitos importantes que ajudam a melhorar a eci ncia no trabalho de modelagem. e Seus principais princpios b sicos s o: a a 1. Lembre-se que o software e o objetivo principal: e efetivamente uma nova express o do a princpio da Agile Alliance, o software funcionando e a principal medida de progresso. Criar documentacao irrelevante pode trazer algum tipo de falso conforto, levando a se acreditar que est havendo progresso, enquanto na verdade n o est . a a a

22

2. Saiba que possibilitar o pr ximo trabalho e o seu objetivo secund rio: e desej vel o a a n o s desenvolver um software de qualidade, mas tamb m uma documentacao suciente a o e para que as pessoas que jogar o a pr xima partida possam faz -lo de forma eciente, a o e transferir habilidades de seus desenvolvedores para outros, motivar a equipe j existente a a permanecer no projeto ou na empresa. 3. Diminua a carga de trabalho: a documentacao e os modelos criados devem ser suci entes para se ir adiante, sem perda de tempo, diminuindo assim a carga de trabalho. Cada artefato mantido no projeto dever receber algum tipo de manutencao. Isto inclui docua mentos, modelos e artefatos de gerenciamento do projeto, como cronogramas, conjuntos de teste e c digo-fonte por exemplo. Quanto maior o n mero de artefatos mantidos, o u maior a possibilidade de que seja difcil efetivar uma mudanca. De forma semelhante ocorre com a complexidade e detalhamento dos modelos mantidos. A diminuicao de carga possibilita a simplicidade da estrat gia de desenvolvimento porque o trabalho de e manutencao de artefatos diminuir drasticamente. a a 4. Adote a Simplicidade: a solucao mais simples funciona bem e, por ser simples, e f cil de implementar, de manter e de melhorar. N o modele em excesso seu sistema hoje, modele a ` baseado nos requisitos existentes atualmente e refaca seu trabalho no futuro a medida que os requisitos evolurem. N o e garantido que sempre as solucoes mais simples funcio a nar o, mas os recursos gastos anteriormente com uma solucao simples n o prejudicar a a a tanto quando elas falharem, servindo de aprendizagem. 5. Encapsule a mudanca: os modeladores ageis n o culpam os clientes quando estes tra a zem as mudancas, pois entendem que elas ocorrem naturalmente nos projetos. Por isso, os modeladores ageis trabalham ativamente com os clientes para entender e comunicar as conseq encias dessas mudancas e para permitir que tomem decis es ecazes, por exemu o plo, se, como e quando a mudanca ser contemplada pelo trabalho de desenvolvi a mento. Compreender os requisitos ao m ximo no momento e sempre um bom conselho a que n o e abandonado pelos modeladores ageis. a 6. Mude incrementalmente: para encapsular a mudanca, uma estrat gia incremental no e trabalho de desenvolvimento e necess ria, assim como mudar pequenas partes do sistema a de cada vez. E possvel executar uma grande alteracao como uma s rie de pequenas e mudancas incrementais. E necess rio aceitar e ter humildade de que pode-se n o acertar a a da primeira vez.

23

7. Modele com um prop sito: ou se n o for possvel identicar a raz o e o p blico-alvo o a a u de um modelo, a tarefa de cri -lo deve ser questionada. N o se deve modelar apenas pela a a satisfacao pessoal de modelar, mas para satisfazer as necessidades dos clientes. Existem in meros outros motivos inv lidos para se criar um modelo: por exig ncia de um processo u a e prescritivo apenas; solicitacao de terceiros que n o conseguem explicar a raz o disto; a a ou criar um modelo para comunicar algo a algu m, sendo que existe a possibilidade de e conversar com a pessoa e tamb m a opcao de faz -lo ou n o. e e a 8. Tenha mais de um modelo: considerando que deve-se modelar para entender ou para comunicar, ent o deve-se observar que cada artefato tem seus pontos fortes e fracos, cada a um e apropriado para determinada situacao. Como o software moderno e complexo, nenhum artefato sozinho, nem no caso da famlia de artefatos UML, e aplic vel a todas a as situacoes. Deve-se usar os modelos segundo os seus pontos fortes para se conseguir representar o sistema adequadamente. Scott Ambler arma que o modelador agil deve possuir uma caixa de ferramentas intelectual, isto e, ele deve conhecer e aplicar uma boa variedade de artefatos, assim seu trabalho ser mais eciente. a 9. Incentive o trabalho de qualidade: e uma premissa b sica para desenvolvimento de a software de forma geral. Desta forma, os desenvolvedores ageis compreendem que devem investir na criacao de artefatos permanentes, como o c digo-fonte, a documentacao de o usu rio e adocumentacao t cnica do sistema. Da mesma forma, eles n o investem muito a e a tempo em artefatos que pretendem descartar como esbocos ou artefatos de pouca precis o. a a 10. Feedback r pido: e um dos cinco valores. Ele e t o direto que n o necessita de um a a princpio para concretiz -lo. O retorno r pido e importante pois cometem-se a maior a a parte dos erros nos incio do desenvolvimento e o custo de correcao de defeitos aumenta com o tempo do ciclo de desenvolvimento. 11. Maximize o retorno que seus clientes obter o: logo a decis o de documentar o sistema a a e uma decis o de neg cio, n o uma decis o t cnica. a o a a e Os principais princpios suplementares da modelagem agil s o: a 1. O conte do e mais importante que a forma: Isto e, o mais importante e o que se pretende u comunicar com o modelo ao inv s de se preocupar com o embelezamento e formalidades e deste. A preocupacao com a formalidade deve ser de acordo com o p blico-alvo do u modelo. Se um modelo for destinado como documentacao a um cliente, vale a pena investir um tempo para criar uma boa apresentacao deste documento.

24

2. Todos podem aprender com todos: E uma das pr ticas que mais concretizam bem o valor a Humildade da Modelagem Agil. Trabalhar com outros e uma boa oportunidade de aprender e de tentar novas maneiras de se fazer algo (PAETSCH, 2003). 3. Conheca seus modelos: O modelador agil deve aperfeicoar a sua caixa de ferramentas intelectual, conhecendo os pontos fortes e fracos de tipos de artefatos para sua pr pria o aprendizagem. Este princpio e suplementar ao Tenha mais de um modelo. 4. Adaptacao local: Para contextos e pessoas diferentes com culturas diferentes, e bem prov vel que uma adaptacao local para o uso de princpios e pr ticas seja mais ecaz para a a a aplicacao da Modelagem Agil. 5. Comunicacao aberta e honesta: Deve ser o objetivo de todos, principalmente dos mo deladores ageis, pois isto melhora o feedback e prov mais conancas as decis es que e ` o passam a contar com informacoes mais precisas. Para auxiliar a comunicacao aberta e honesta pode-se usar radiadores de informacao, ou seja, mecanimos simples como pa redes para xar atividades e o cronograma do projeto, transparecendo uma vis o geral do a projeto para todos os envolvidos (COCKBURN, 2002). 6. Trabalhe com o instinto das pessoas: Este princpio deve ser levado em consideracao, por exemplo, quando o modelador agil se encontrar em uma situacao de d vida entre duas u ou mais solucoes onde n o existam motivos convincentes para escolher entre uma delas. a Geralmente as pessoas relacionam incoscientemente m tricas baseadas em experi ncias e e para se ter a impress o de algo. a

3.4

PRATICAS

As pr ticas s o divididas em dois grupos: b sicas e suplementares. Assim como os princpios a a a b sicas, as pr ticas devem ser seguidas integralmente. a a

3.4.1

BASICAS

As pr ticas b sicas est o divididas em quatro categorias: a a a

 Modelagem iterativa e incremental:

1. Aplique os artefatos corretos: Cada artefato tem uma aplicacao especca onde ele e mais valioso. Por exemplo, a representacao de uma estrutura est tica de banco a

25

de dados e melhor representada por um modelo fsico de dados ao inv s de qualquer e outro diagrama UML. 2. Crie diversos modelos em paralelo: Como cada artefato possui pontos positivos e negativos, nenhum e suciente para todas as necessidades de modelagem. Deste modo, as sess es de um s artefato n o s o recomendadas. o o a a 3. Itere em outro artefato: Geralmente podem ocorrer situacoes onde a modelagem usando um certo artefato n o gera o resultado desejado (ou nenhum resultado), a isto e, o processo de modelagem e o modelo em si n o ajudaram no entendimento a ou comunicacao do problema. Nestes casos, considere iterar (repetir o processo) em outro tipo de artefato para modelar o mesmo problema. De uma maneira ` los ca, esta pr tica e uma analogia a refactoring em XP, onde se busca simplio a car a abstracao e conseq ente entendimento do problema modelado. Desde a u documentacao inicial da UML, existe a indicacao de se iterar entre artefatos, por exemplo, na fase de An lise do Domnio do Problema e indicada uma iteracao entre a use case e modelo de objeto (COPE, 2001). 4. Modele incrementalmente: Deixe um problema futuro para o futuro (para a pr xima semana, por exemplo). Organize o seu trabalho mais abrangente em paro tes menores (semanas ou meses), modelando incrementalmente. Assim as sess es o de modelagem (explicadas na secao 3.4.5) dever o durar de 10 a 20 minutos ou no a m ximo poucos dias. a

 Trabalho de equipe:
1. Modele com outras pessoas: A participacao de v rias pessoas ajuda a desenvolver a uma vis o compartilhada em relacao ao projeto, al m de pr -validar o modelo. a e e 2. Organize uma participacao ativa do cliente: E uma extens o da pr tica XP Cli a a ente sempre no local. No caso, organize a participacao dos stakeholders tamb m e na modelagem. 3. Promova a posse coletiva: Desenvolva o modelo em p blico e ganhe r pido feu a edback. Esta e uma boa pr tica pois permite uma aprendizagem coletiva (Todos a podem aprender com todos). 4. Mostre os modelos publicamente: Esta pr tica suporta o princpio Comunicacao a aberta e honesta. Use p ginas web ou paredes de prefer ncia por serem mais a e acessveis e simples.

 Simplicidade:

26

1. Crie conteudo simples: Para aplicar esta pr tica, e necess rio ter em mente tr s a a e perguntas: O modelo comunica tudo que se voc pretende comunicar? e O modelo n o cont m informacao duplicada? a e O modelo tem a menor quantidade de elementos possveis? 2. Mostre seus modelos de forma simples: E suciente mostrar as caractersticas principais que se est desejando entender. Durante a modelagem, evite: cruzamento a de linhas, linhas curvas, linhas diagonais, bal es de tamanhos diferentes, detalhes o desnecess rios e bal es demais (n o maior que 7 com variacao de 2 bal es). a o a o 3. Use as ferramentas mais simples: Quando se modela com a intencao de entender o problema, as ferramentas usadas podem ser as mais simples possveis, pois e no raciocnio para criar o modelo que reside a funcao da tarefa. Esta pr tica n o e a a contra ferramentas CASE, e que apenas existem poucas ferramentas pr ticas que a permitem modelar com facilidade. Como exemplos de ferramentas simples, temos ip-charts, cart es de ndice, papel e caneta. o  Validacao: 1. Considere a testabilidade: Se uma equipe n o puder testar um software, ent o ela a a n o deve constru-lo. a 2. Comprove com c digo: Esta pr tica se resume a modelar um pouco e codicar, o a que e uma atividade diferente a criar um modelo, revis -lo, retrabalhar nele e dea pois codicar. Esta pr tica funciona melhor quando as pessoas que executam a a modelagem s o as mesmas respons veis pelo c digo. Como exemplo podemos ter a a o a validacao de interfaces com c digo HTML, e a de diagramas UML de atividades o poderiam ser validados atrav s de algum c digo de teste e de neg cios. e o o

3.4.2

SUPLEMENTARES

Assim como as pr ticas b sicas, as pr ticas suplementares tamb m est o divididas em caa a a e a tegorias:

 Produtividade:
1. Aplique as convencoes da modelagem: Assim como em eXtreme Programming, estabeleca convencoes de modelagem com sua equipe no incio do projeto e procure

27

usar padr es reconhecidos como UML. Lembrando que a UML n o e completa e o a ser necess rio usar outros tipos de artefatos tamb m. a a e 2. Utilize os padr es com moderacao: Sejam padr es de projeto, arquiteturais ou de o o an lise, procure aplic -los com moderacao, de forma a implement -los minimaa a a mente de acordo com a funcionalidade necess ria, e de forma f cil de refaz -los a a e mais tarde. 3. Reuse os recursos j existentes: E importante que se tenha a disposicao um repoa sit rio de modelos para reuso como produtos de trabalho de projetos antigos. Deveo se procurar reusar desde padr es de projeto ou an lise, a modelos de requisitos, o a frameworks e templates de documentos.  Documentacao: 1. Descarte os modelos tempor rios: A maioria dos modelos criados durante o dea senvolvimento de um projeto s o tempor rios e podem ser descartado ap s terem a a o cumprido o seu papel. Descartar modelos e uma boa pr tica, pois eles se tornam a rapidamente inconsistentes com o c digo e entre si. Philippe Kruchten em (KRUo
CHTEN, 2005) considera esta inconsist ncia um dos obst culos para o desenvolvie a

e mento da Engenharia de SoftwarePor m segundo esta pr tica sugerida por Ambler, a este problema e resolvido de forma simples. 2. Formalize os modelos de contrato: Ao se criar um modelo de contrato, os grupos envolvidos devem estar de comum acordo e prontos mutuamente a mudar o modelo de contrato com o passar do tempo quando necess rio. Como esta manutencao e a prevista, o uso de uma ferramenta eletr nica e aconselh vel. o a 3. Atualize apenas quando necess rio: Deve-se atualizar um modelo, quando sua a desatualizacao causar mais transtornos que o trabalho de atualizacao. J que a a producao de software e o principal objetivo, n o faz sentido gastar recursos para a manter artefatos em sincronia desnecessariamente. A melhor forma de assegurar que duas equipes de desenvolvimento estejam desenvolvendo a mesma vis o n o a a e ter documentos e modelos consistentes, e sim, permitir que estes grupos se comuniquem de forma ecaz, colaborando entre si na denicao e criacao da vis o a compartilhada.  Motivacao: 1. Modele para entender: Para entender o espaco-problema, identicar e analisar re quisitos.

28

2. Modele para comunicar: Modelos encorajam e suportam a comunicacao. Um efeito desta pr tica e que ela ajuda a contruir um vocabul rio comum dentro da equipe e a a com os clientes de seu projeto.

3.4.3

MODELAGEM AGIL NA PRATICA

` As pr ticas da Modelagem Agil s o sin rgicas: se ap iam e muitas vezes habilitam umas as a a e o outras. Elas s o ca rdicas, denindo harmoniosamente ordem e caos. A gura 3 exibe uma a o maneira de visualizar os relacionamentos entre os grupos de pr ticas citados. a

Figura 3: Relacionamento entre as pr ticas MA a A aplicacao da Modelagem Agil, envolve uma mudanca cultural, onde conceitos antigos e err neos s o descartados e novos s o introduzidos. Por m, caractersticas como valores s o o a a e a quase as mais difceis de se modicar dentro das organizacoes. Por isso, Ambler defende que deve-se preparar o ambiente para a aplicacao de metodologias ageis, atrav s da criacao de uma e cultura agil.

3.4.4

CRIACAO DE UMA CULTURA AGIL

A mudanca cultural e sempre mais f cil em equipes pequenas ou iniciantes. Para se aplicar a a Modelagem Agil alguns pontos devem ser esclarecidos logo de incio:  Modelos sao mais uteis que documentos. E durante a criacao de um modelo que se

agrega valor ao trabalho, pois esta tarefa permite validar id ias, aumentar a comunicacao e

29

e o aprendizado. A modelagem pode ser simples ou mais complexa a depender do que se escolhe. Entretanto, nem todos os desenvolvedore est o habilitados para modelar. a

 Nao se deve congelar os requisitos. Ao contrario, deve-se admitir a mudanca como algo
real e estar preparado para ela, encapsulando as mudancas durante o desenvolvimento, sempre buscando gerar um software de qualidade. Desta forma, e simples vericar que n o se consegue prever tudo desde o incio. Mudancas em projeto devem fazer parte do a jogo, inclusive para o aperfeicoamento desse.

 Apesar da modelagem ser muitas vezes uma tarefa complexa, uma ferramenta CASE s o
e necess ria quando existe uma necessidade real para us -la. a a Se pequeno e agil, ent o deve-se preferir pensar pequeno. Isto e: a

 faca sess es curtas (pequenas) de modelagem, focalizando em poucas funcionalidades o

por vez;

 tenha preferencia por equipes pequenas, simplicando o gerenciamento;  contrua modelos pequenos, que sao mais faceis de entender;  e crie documentos pequenos, que facilitam a manutencao.
3.4.5 SESSOES DE MODELAGEM AGIL

Uma sess o de modelagem e uma atividade na qual diversas pessoas focalizam um ou mais a modelos (AMBLER, 2004). As sess es de modelagem agil variam de de alguns minutos a o poucos dias. E prov vel que as longas sess es se situem no incio do projeto, onde h grande a o a necessidade de denicao do escopo, estabelecimento de requisitos iniciais e identicacao de um arquitetura candidata. As sess es de modelagem de um unico artefato s o consideradas anti-padr o, pois s o o a a a uma forma muito restrita de representar seu sistema. Assim outros tipos de sess es devem ser o consideradas: como

 Sess o de modelagem de fases: Criacao de modelos relacionados a`s fases mais impora
tantes do desenvolvimento (requisitos, an lise, arquitetura e projeto). a  Sess o de Modelagem Agil: Na Modelagem Agil, uma exibilidade adicional e que se a itere entre as fases, produzindo vers es mais maduras durante o desenvolvimento iterao tivo. Mesmo as sess es formais podem se tornar ageis. o

30

Assim, os participantes de uma Sess o de Modelagem Agil se dividem em dois grupos: a

 Ativos: stakeholders, analistas (geralmente analistas de requisitos ou neg cios) e deseno

volvedores (que trabalham nos modelos).

 De apoio: facilitador (responsavel pelo planejamento e orientacao durante as sess es), o

escriv o, e observador(es). a

3.4.6

USANDO AS FERRAMENTAS MAIS SIMPLES

Dando suporte ao princpio Use as ferramentas mais simples, quadros e marcadores apresentam-se como boas alternativas se o modelo a ser criado for logo descartado. Tamb m e deve-se tentar balancear o uso de ferramentas CASE com ferramentas simples, desde que seja util usar uma ferramenta CASE para gerar c digo a partir de um modelo por exemplo. o Eventualmente, as ferramentas simples (cart es de ndice, quadros, post-its, linhas) precio sar o de algum suporte tecnol gico como c meras, software de edicao de imagens, HTML etc. a o a Por exemplo, se se deseja documentar um prot tipo de interface com o usu rio essencial feito o a num ip-chart, uma c mera digital pode ser uma solucao pr tica (e agil). a a

3.4.7

DOCUMENTACAO AGIL

Levando-se em consideracao que alguns modelos evoluir o para a documentacao ocial a do sistema, o entendimento sobre este tema e necess rio para se reconhecer quando um moa delo deve ser tornar parte da documentacao. Um modelo tempor rio ir se tornar permanente a a quando:

 Existe um motivo claro e importante para isto: seja para denir um modelo de contrato
ou apoiar a comunicacao com um grupo externo por exemplo.

 Existe um p blico-alvo para o qual o modelo comunica algo importante. u  Se os clientes do projeto estao dispostos a dispensar recursos para que o modelo vire parte
da documentacao.

31

DOMINIO DE JOGOS

Cada problema (software) a ser modelado possui o seu domnio. E durante a An lise do a Domnio do problema que encontramos outros requisitos funcionais e n o-funcionais n o a a detectados durante a An lise de Requisitos (PRESSMAN, 2005). a Sem a satisfacao dos requisitos de um software, e difcil armar que este possui qualidade. E como a preocupacao com a qualidade de software deve comecar muito antes do c digo a ser o gerado, este captulo se prop e a elaborar um estudo sobre o Domnio de jogos, evidenciando o seus requisitos gerais.

4.1

DOMINIO DO PROBLEMA

As abstracoes do domnio do problema correspondem aos conceitos da area de aplicacao do problema, compreendendo suas caractersticas e abrang ncia. Pode-se armar que o domnio de e jogos e relativamente extenso, apresentando pelo menos 50 termos (ART; GAMES, a). Para en tendermos o domnio de jogos, e necess rio antes uma delimitacao sobre o conceito de jogo. a

4.1.1

JOGOS

A atividade de jogo n o pode ser denida de forma exata em termos l gicos, biol gicos ou a o o est ticos, por m podemos tentar den-la atrav s de suas principais caractersticas: apresentar e e e prazer e divertimento; e volunt ria, livre e representa a liberdade, apesar de possuir regras que a s o respeitadas religiosamente; e e uma evas o da vida real. As principais funcoes de um jogo a a s o: disputa por algo ou representacao de algo (HUIZINGA, 2004). De fato, a caracterstica a mais marcante de um jogo e sua separacao espacial em relacao a vida cotidiana. ` Segundo a denicao acima de jogo, nem todo software e um jogo, pois precisa possuir tais caractersticas principais. Por m todo jogo eletr nico e um software. E para a garantia da e o qualidade deste software, deve-se vericar os requisitos que motivam seu desenvolvimento.

32

4.2

GENEROS

Existe muitas classicacoes de jogos, e muitas delas se contradizem, apresentando con fus o de forma, de conte do, de p blico-alvo e de contexto entre si. As distincoes de g neros a u u e apresentadas aqui s o construcoes analticas somente, n o devendo ser analisadas segundo sua a a veracidade, mas sim em sua adequacao. Elas ser o baseadas em crit rios de sucesso (ART; a e GAMES, b), isto e, em crit rios que o jogador deve possuir para obter o sucesso. e  Jogos de acao: Crit rios de sucesso: reexos r pidos e habilidade de coordenacao. e a

Exemplos de subcategorias deste g nero: jogos de plataforma, jogos de luta, jogos de e nave, jogos de carro e jogos de tiro.

 Jogos de aventura: Criterios de sucesso: pensamento l gico e persistencia. Estes tipos o

de jogos, geralmente, apresentam-se com um enredo trabalhado, passando uma id ia de e lme interativo. Exemplos de subcategorias deste g nero: MUD (Multi-User Dungeon) e e MMORPG (Massive Multiplayer Online Role-Playing Games).

 Jogos de estrategia: Demandam habilidades analticas e taticas coordenadas, balanceando a relacao entre recursos e v rios elementos no jogo. Exemplos de subcategorias a deste g nero: jogos baseados em turnos, jogos de estrat gia de tempo-real, jogos empree e sariais.  Jogos de simulacao: Criterios de sucesso: dominar princpios complexos que fazem relacao direta com a realidade externa. Estes tipos de jogos se prop em a simular ex o peri ncias concretas com alto grau de realismo. Exemplos de subcategorias deste g nero: e e jogos de simulacao de v o, jogos empresariais. o

4.3

CARACTERISTICAS DO PRODUTO

A maioria dos jogos apresentam-se como produtos de uso geral orientados para um grande n mero de usu rios. Um software de uso geral tem seu desenvolvimento segundo uma especicacao u a de requisitos mais abrangente possvel. No domnio de jogos, os requisitos de qualidade para o usu rio s o relativos tanto ao software quanto ao conte do do jogo. a a u

33

4.3.1

REQUISITOS FUNCIONAIS

Fatores de qualidade como usabilidade podem ser considerados requisitos funcionais, no domnio de jogos. Usabilidade ou user friendliness e o esforco para aprender, operar, prepa rar a entrada e interpretar a sada de um programa. Jogabilidade e um termo que deriva de usabilidade, quando se trata de jogos, e conseq entemente tamb m e um requisito. u e Os requisitos funcionais relativos ao conte do s o subjetivos, existindo alguns consenso em u a torno de:

 Gr cos: e, de forma simplicada, relativo a` toda a parte visual de um jogo: gracos, a

modelos 3D e animacoes.

 Jogabilidade: esta normalmente relacionada ao controle dos personagens, movimentacao

de objetos pela tela, desao, dentre outros (FINALBOSS.COM, 2005). Jogabilidade se confunde com usabilidade, pois trata de assuntos relacionados a ergonomia, projeto de interfaces e experi ncia do usu rio. e a  Audio: e relativo a todas as m sicas, efeitos sonoros e vozes (quando houver). u Se as

m sicas n o s o repetitivas, os efeitos sonoros s o condizentes com o estilo adotado pelo u a a a game, e se as falas est o sincronizadas e bem interpretadas, a nota provavelmente ser a a mais alta do que as dadas em um jogo que tenha um ou mais destes quesitos n o t o bem a a elaborados.

 Fator Replay: ou Replayability e uma media relativa ao n mero de vezes que um usuario u
jogaria denovo sem enjoar. Existe uma relacao com todos os crit rios acima, por m este e e requisito depende tamb m do tipo de jogo e seu enredo. e A criatividade (ou originalidade) e fator que inuencia as avaliacoes sobre o a dio, joga u bilidade e gr cos. De uma forma geral, a criatividade reete a inovacao das id ias centrais do a e jogo.

4.3.2

REQUISITOS NAO-FUNCIONAIS

Podemos citar diversos requisitos n o-funcionais para o domnio de jogos. Os principais a s o: conabilidade, integridade, testabilidade, reusabilidade, corretude, eci ncia (operacional a e por exemplo), manutenibilidade, exibilidade, portabilidade e desempenho.

34

Como portabilidade e o esforco exigido para transferir o programa de um ambiente de sis tema de hardware e/ou software para outro, eventualmente, este fator e considerado um requisito funcional exigido pelo pr prio cliente. o

4.4

DESENVOLVIMENTO DE JOGOS

A tabela 1 mostra na sequ ncia as principais fases de desenvolvimento de um jogo, podendo e ocorrer atividades em paralelo com diferentes focos de producao: uma no software e outra no conteudo. FASES DE PRODUCAO SOFTWARE CONTEUDO Denicao do escopo e Planejamento geral Engenharia de Requisitos Enredo Game Design An lise a Projeto Arte, animacao e audio Desenvolvimento Testes de aceitacao Testes de jogabilidade (Homologacao) Balanceamento Ajustes nais Tabela 1: Fases de producao

Abaixo a descricao de algumas fases:  Denicao do escopo e Planejamento geral: e a denicao geral do escopo e planejamento dos recursos, pode incluir tamb m atividades iniciais de emphGame Design (GD) e e pesquisa sobre as principais tecnologias necess rias para o projeto. a

 Enredo: denicao de uma hist ria que envolva o jogador num mundo imaginario. Nem o
todos os jogos possuem enredos.

 Balanceamento: e uma atividade que busca o equilbrio entre os diferentes elementos do

jogo e o grau de diculdade para o usu rio. S o feitas medicoes e ajustes para determinar a a se a experi ncia ser agrad vel ou n o para o jogador. e a a a Justamente por este processo ter fases com abordagens diferentes, surge a necessidade de um prossional que tenha conhecimento em ambas as frentes de producao, que seja capaz de

35

fazer o planejamento geral do produto. Assim, a pross o de game designer surgiu da nea cessidade da ind stria de jogos e est se tornando uma ci ncia. Existindo cursos no Brasil, na u a e PUC-RIO, UNICENP, UNISINOS entre outras... Level Design e uma atividade equivalente ao Game Design por m e especca para cada e fase ou est gio do jogo que foi previsto pelo projeto geral. O level designer e respons vel a a pela composicao coerente de fases, cen rios e paisagens. Em casos, onde o jogo ter v rias a a a fases, uma abordagem iterativa de desenvolvimento e indicada. O gerenciamento do desenvolvimento de um jogo e uma atividade crtica e muitas vezes complexa. Como maneira de minimizar isto, a ind stria de jogos, produz ao nal do ciclo de u vida de um jogo, um detalhado relat rio de avaliacao gerencial do projeto chamado de postmoro tem (DEXTERITY, 1999). O projeto de um jogo possui intersecao com areas de computacao heterog neas como in e telig ncia articial, redes, computacao gr ca, sistemas distribudos, engenharia de software, e a sistemas de tempo real, realidade virtual e processamento de audio. A tabela 1 demonstrou que o desenvolvimento de jogos, n o envolve somente prossionais a da area de computacao, mas tamb m outras pross es de mesma relev ncia para o projeto. O e o a desenvolvimento de jogos possui interseccoes com as mais variadas areas: ergonomia, peda gogia, matem tica, psicologia, fsica, telefonia m vel, cinema, jornalismo, artes gr cas, artes a o a pl sticas, m sica entre outras. a u De modo generalizado, a producao de um game, requer os seguintes prossionais (AHE
ARN, 2001): programador com conhecimentos em intelig ncia articial, redes e banco de dae

dos; gerente de projetos; analista de testes; artista com habilidades em 2D/3D, animacoes e design; level e game designer; compositor de trilhas e produtor de efeitos sonoros. Alguns prossionais podem ter mais de uma dessas habilidades ou pode-se inserir especialistas de outras areas na equipe.

36

ANALISANDO EXTREME PROGRAMMING

Este captulo e dedicado a analisar eXtreme Programming sobre o ponto de vista da modela gem e de aplicacoes dessa metodologia. Como XP e um tema bastante difundido, este trabalho apenas apresenta um sucinto resumo. Outras informacoes sobre eXtreme Programming podem ser encontradas em (COSTA, 2003) ou em (JEFFRIES, 2005).

5.1

RESUMO SOBRE XP

A Programacao Extrema ou eXtreme Programming (XP) e uma Metodologia Agil para pe quenas e m dias equipes (com menos de 10 pessoas) de desenvolvimento frente a requisitos e vagos e em constante mudanca (BECK, 2000), que surgiu antes do Manifesto Agil. O termo extreme quer dizer que esta metodologia leva princpios e pr ticas de senso comum ao ex a tremo. De fato, as pr ticas de XP, assim como das demais metodologias ageis, requerem uma a mudanca los ca na maneira de se desenvolver software, e quando aplicadas corretamente o e em conjunto produzem bons resultados. XP e uma metodologia intensiva em atividades, prescrevendo o que os pap is executam e ` durante o dia (COCKBURN, 2002), focalizando na participacao do cliente junto a equipe de desenvolvimento, em Test Driven-Development, e em refactoring (FOWLER et al., 2000). XP pode ser classicada como Test Driven-Development ao focar bastante as atividades de teste, descrevendo testes de unidade e testes funcionais como atividades determinantes para o prosseguimento do projeto. Os quatro valores de XP s o: Comunicacao, Simplicidade, Feedback e Coragem. As a pr ticas buscam aproveitar os instintos naturais dos programadores e comportamentos n o ima a postos, de forma a deixar a aplicacao de eXtreme Programming simples. As principais pr ticas a s o: a

 O Jogo do Planejamento:

Pr tica que determina rapidamente o escopo da pr xima a o

vers o combinando prioridades do cliente e estimativas t cnicas, sobrepondo e atualia e

37

zando o planejamento. Mais detalhes sobre esta pr tica est o na secao 5.2.2. a a

 Pequenas vers es: Consiste em colocar uma simples parte do sistema em producao rapio
damente, depois deve-se lancar novas vers es em curtas iteracoes. o

 Met fora: A ideia da metafora e compartilhar uma hist ria simples sobre todo o funa o
cionamento do sistema (e sua arquitetura) com todos da equipe. Mais detalhes sobre met fora est o na secao 5.2.1. a a

 Design simples: O sistema deve ser projetado o mais simples possvel em qualquer mo mento, removendo-se a complexidade extra. O Design simples e analisado na secao 5.2.3.

 Testes: Pratica de onde os programadores continuamente escrevem testes de unidade para

validar o sistema. O desenvolvimento progride a medida que estes testes forem sendo satisfeitos. Os clientes escrevem testes funcionais para indicar quando a funcionalidade estar validada. a  Refatoracao: Ou refactoring, e a reestruturacao do sistema sem mudar seu comportamento para eliminar duplicacoes, melhorar a comunicacao, simplicidade ou adicionar mais exibilidade.  Programacao em pares: Toda a producao de c digo e feita com dois programadores em o uma m quina. Enquanto um pilota, usando o teclado e mouse, o outro revisa o c digo a o e analisa possibilidades de refactoring e redesign.

 Propriedade coletiva: Qualquer pessoa pode modicar qualquer parte do c digo do siso
tema a qualquer momento. Para suportar esta pr tica um controle autom tico de vers o e a a a recomendado.

 Jornada de 40h: Ninguem deve trabalhar mais de 40 horas por semana como regra.  Cliente sempre presente: Inclui um cliente/usuario real na equipe, disponvel para responder as quest es do projeto. o  Padr es de codicacao: No incio de cada projeto, devem ser estabelecidos padr es o o de codicacao para serem seguidos durante o desenvolvimento e auxiliar a comunicacao atrav s do c digo. Tais padr es de codicacao incluem nomenclaturas de pacotes, m dulos, e o o o classes, m todos e vari veis, al m de especicacao de alinhamentos, margens, ferramene a e tas e coment rios. a

38

5.2

XP E A MODELAGEM

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 principais bia e bliograas de XP. Por exemplo, em (BECK, 2000), fala-se sobre padr es de codicacao, mas o nem se comenta sobre padr es de modelagem. Uma situacao mais estranha ocorre quando Kent o Beck comenta sobre o papel de diagramas no design. E uma secao sucinta que n o esclarece o a papel da modelagem em XP. O resultado disso e que muitos praticantes 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, haver um u a ponto onde ser necess rio um redesign do sistema. Se este redesign e um sinal de modelagem a a falha em eXtreme Programming, n o est claro, mas e prov vel. Na seq encia, est o listadas a a a u a algumas pr ticas que lidam com a modelagem do sistema. a

5.2.1

METAFORA

A id ia da met fora e compartilhar elementos comuns para representar como o sistema ir e a a funcionar, ou seja e uma esp cie de descricao arquitetural com uma linguagem comum aos e desenvolvedores e stakeholders. Cada projeto XP deve ser guiado por uma unica e abrangente met fora de prefer ncia que ser usada como base para um projeto arquitetural mais detalhado a e a ao longo do desenvolvimento. Tamb m pode-se trabalhar com v rias met foras para partes e a a diferentes do sistema, ao inv s de se usar somente uma unica met fora. e a Boas met foras s o colhidas do domnio do problema e se reproduzem no c digo, dando a a o ` nomes as classes e m todos criados. Uma boa estrat gia para implementar uma met fora e e e a abordada na secao 5.2.2.

5.2.2

JOGO DO PLANEJAMENTO

A t cnica do Jogo do Planejamento e usada para criar um ambiente de negociacao e cooperacao e entre os participantes. As pessoas de neg cios cam respons veis em decidir sobre escopo, o a prioridades, datas e composicao das vers es; enquanto a equipe t cnica prov estimativas, con o e e seq encias t cnicas, organizacao dos processos e calend rio detalhado. Ambas tentam dialogar u e a para chegar num acordo sobre estas decis es. o O cliente fornece o escopo atrav s de requisitos funcionais detalhados em story cards, sime ples cart es de ndice com descricao resumida sobre uma funcionalidade do sistema que pode o

39

ser test vel e estim vel. a a O Jogo do Planejamento e dividido em tr s etapas: e 1. Exploracao: Fase de criacao de cart es de usu rio test veis e estim veis. o a a a 2. Comprometimento: O cliente escolhe os cart es de usu rio que agregem mais valor ao o a projeto e com menor risco, denindo o escopo e data da pr xima vers o. o a 3. Direcao: A etapa de direcao abrange todo o jogo do planejamento. Trata-se de situacoes onde o plano precisa ser ajustado de acordo com os dados de iteracoes passadas. Na primeira iteracao, por exemplo, deve-se escolher um conjunto de cart es de usu rio que o a consiga criar um esqueleto funcional do sistema (sua arquitetura), que ser implementado a segundo a met fora do sistema. a

5.2.3

DESIGN SIMPLES

Kent Beck e enf tico quando fala sobre a import ncia de um Design Simples no desenvolvia a mento. Segundo (BECK, 2000), um design simples e aquele que obdece as seguintes restricoes, em ordem de prioridade: 1. O sistema (c digo e testes juntos) deve comunicar tudo que se deseja comunicar. o 2. O sistema n o deve conter funcionalidades duplicadas, procurando-se modulariz -lo. a a 3. O sistema deve ter o menor n mero de classes possvel. u 4. 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, sendo locaa lizados em apenas um local. Todas as restricoes de eXtreme Programming est o de acordo com a Object Thinking (WEST, 2004) que ser abordado posteriormente em 6.4. a

5.2.4

SESSOES CRC

Em eXtreme Programming, ap s a escolha dos cart es de usu rio, estes s o agrupados seo o a a gundo funcionalidades. E feita uma reuni o em p (stand-up meeting) para discutir as possveis a e classes envolvidas nestas funcionalidades, identicando-as. Para cada objeto (classe) identi cado e feito um cart o Class-Responsability-Collaborator (CRC) respectivo (veja a gura 4). a

40

Muitos requisitos, neste momento, podem estar vagos, ent o e feita uma reuni o com o cliente a a que provavelmente estar disponvel, para retirar d vidas. a u

Figura 4: Cart o Class-Responsability-Collaborator a Nesta reuni o, os cart es CRC s o colocadas sobre a mesa. Cada participante da reuni o a o a a (clientes e desenvolvedores) vai falando sobre as responsabilidades (comportamentos) desej veis a para o objeto e quais os colaboradores s o envolvidos para satisfaz -las. Todos contribuem com a e a descricao do objeto, anotando os dados sobre o cart o. a ` 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 maioria da pese soas n o est acostumada, como An lise de Comportamento do Objeto (WEST, 2004). Um a a a pouco mais sobre este t pico e discutido na secao 6.4. o

5.3

XP COMO PROCESSO

O escopo de uma metodologia consiste no alcance dos p peis e atividades, sendo caracteria zado sobre a abrang ncia do ciclo de vida, dos pap is e das atividades. e e

5.3.1

PAPEIS

Alguns pap is descritos por XP s o exveis podendo ser desempenhados pela mesma pese a soa, a depender do tamanho da equipe de desenvolvimento. Os pap is envolvidos com a modee lagem s o: a

 Programador: em XP, o programador assume papel de analista, modelador e programador. Por este fato, uma melhor identicacao para este papel seria desenvolvedor. O

41

programador e o papel principal da XP e tamb m o principal respons vel pela modelagem e a do sistema. Na secao 5.3.2 este aspecto car mais detalhado. a

 Coach: ou tecnico.

E uma esp cie de uma pessoa respons vel por todo o processo e e a

acompanhar a equipe de XP na aplicacao da metodologia. Geralmente, o coach tamb m e e um desenvolvedor, contribuindo com a equipe para a geracao de um bom design.

 Cliente: esta envolvido indiretamente com a modelagem do sistema. Nas sess es CRC, o
ele entra com os requisitos e freq entemente modela em um nvel mais alto ao preencher u alguns campos dos cart es CRC. o

5.3.2

ATIVIDADES

XP se baseia em atividades, cujo rigor reside nas pessoas cumprirem-nas adequadamente. Pode-se aplicar XP em equipes maiores de dez pessoas, mas ser o necess rias adaptacoes, o a a que tornaria a metodologia mais pesada, aumentando o n mero de elementos de controle e a u quantidade de toler ncia. Entretanto, pode-se expandir XP em relacao ao tamanho do problema a (COCKBURN, 2002). As atividades s o apoiadas sobre as pr ticas e o relacionamento entre elas. Existem quatro a a atividades b sicas: Codicacao, Testes, Escutar e Projetar. Todas as atividades de XP podem a ocorrer ao mesmo tempo num projeto, envolvendo diferentes participantes.  Codicacao: A atividade de codicacao gera um feedback sobre o design. Quando se codica, verica se com facilidade a estrutura do c digo e percebe-se se existe um entendimento soo bre o projeto necess rio. A codicacao tamb m ajuda a comunicar, principalmente na a e programacao em pares.

 Testes:
eXtreme Programming usa a abordagem Test First Design. Ela consiste em se implementar testes para cada nova funcionalidade a ser inserida antes mesmo de implement -la. a O teste dever ser executado regularmente para vericar se o c digo passou, se sim, ent o a o a a nova funcionalidade est pronta. Com esta atitude, o desenvolvedor ir pensar sobre o a a que ele quer independentemente de como ser implementado, depois os testes dir o se foi a a implementado o que se pensou.

42

Segundo Kent Beck, criar testes tamb m e fazer design, pois dene-se a interface da e classe primeiro, pensando em seus m todos, propriedades e relacionamentos, antes de e implement -la. a

 Escutar:
Os programadores devem ter em mente que quem fornece os requisitos e o cliente, o usu rio do sistema. Algumas pr ticas XP incentivam a exist ncia de di logo entre os a a e a programadores e clientes.

 Projetar:
Em XP, projetar (Designing) tem como foco a criacao de uma estrutura que organize a l gica do sistema de forma modular, encapsulando a mudanca. Desta forma, um bom o design ser aquele que assegurar a n o-duplicidade da l gica do sistema, a proximidade a a o entre a l gica e os dados a serem operados e a extens o do sistema com mudancas em o a somente um lugar.

5.3.3

CICLO DE DESENVOLVIMENTO

Durante o desenvolvimento de um software usando eXtreme Programming, vericamos a exist ncia das seguintes fases: e  Fase de exploracao: Fase importante para a exploracao do escopo do sistema, pratica da equipe nas tecnologias a serem usadas e treinamento do cliente em XP.

 Jogo do Planejamento: Descrito anteriormetne em 5.2.2, esta fase tem como objetivo
planejar a vers o, acordando a entrega de software de maior valor para o cliente com a investimento mnimo.  Planejamento da Iteracao: O nome Planejamento da Iteracao identica tambem toda a iteracao incluindo seu planejamento (AMBLER, 2004). Abaixo algumas observacoes sobre a Iteracao.  Iteracao: E a fase de desenvolvimento propriamente dito, onde sao elaboradas sess es o CRC, a programacao em pares e refactoring. Em cada iteracao, tamb mn podem estar e ocorrendo as quatro atividades de XP simultaneamente num projeto. O desenvolvimento em XP pode ser considerado como uma fase de manutencao do sistema em producao (considerando uma ao menos uma vers o j publicada). a a

43

 Testes de aceitacao: Testes funcionais elaborados pelo cliente e executados com ajuda do testador.  Publicacao: Fase de publicacao de nova versao ou entrega do produto nal.

Figura 5: XP visto como um processo Na pr tica, muitas equipes XP n o enxergam as distincoes entre as fases, uma vez que o a a processo e iterativo, podendo ser analisado de forma simples seguindo suas quatro atividades e artefatos bem conhecidos.

5.3.4 ESCOPO DE XP
O escopo de uma metodologia consiste na abrang ncia dos pap is e atividades que ela e e intenta cobrir. Na pr tica, para diferentes preocupacoes se adequam a diferentes metodologias, a

44

reetindo nos pap is necess rios. Para nalizar esta an lise sobre eXtreme Programming, e e a a necess rio observar o escopo dela no ciclo de vida de um projeto de software. a Na gura 6, verica-se a falta de uma abordagem sobre projeto de interfaces em XP, o que pode ser complementado com metodologias especcas como a descrita em (CONSTANTINE; LOCKWOOD, 1999) ou outra abordagem. A gura 6 e uma vis o de Cockburn (COCKBURN, a 2002) sobre o ciclo de vida de um projeto XP enfatizando esta quest o. a

Figura 6: Escopo de XP (COCKBURN, 2002) Portanto, existe a necessidade de se ter uma abordagem alternativa para o projeto de interface com o usu rio visto que XP n o trata de nenhuma atividade relacionada ao projeto de a a interface.

5.4

XP E DESENVOLVIMENTO DE JOGOS

No desenvolvimento de jogos, existem pap is e atividades distintos para cada fase de e producao. Entretanto, durante muito tempo n o existiu um processo de desenvolvimento dis a ciplinado e bem documentado para jogos. Cada equipe de desenvolvimento utilizava-se de m todos arbitr rios e com pouca engenharia de software. Por este e outros motivos era comum e a o atraso na entrega do jogo. Felizmente, surgiu eXtreme Programming e v rios desenvolvedores a de jogos tiveram a boa id ia de us -lo para jogos, surgindo naturalmente o que se est chamando e a a

45

de eXtreme Game Development (XGD) (DEMACHY, 2003). eXtreme Game Development(XGD) e uma metodologia de desenvolvimento de jogos baseada em eXtreme Programming, estendendo-a (EXTREMEGAMEDEV, 2005). As adaptacoes da XGD em relacao a XP s o simples e focadas no domnio de jogos. Pode-se considerar XGD a como sendo XP para n o-programadores, redenindo alguns pap is, princpios, pr ticas e proa e a cessos. Observando-se a tabela 1 (secao 4.4), existem duas frentes de desenvolvimento: uma vol tada para a producao do jogo como software, e outra para a producao do conte do. O pro u cesso de producao do software e dependente da producao de conte do para atingir determinados u est gios de desenvolvimento e vice-versa. Assim, ambas as frentes devem estar coordenadas a segundo um mesmo processo. Por exemplo, n o se deve aplicar eXtreme Game Development a a para n o-programadores, enquanto os programadores executam RUP. E necess rio sincronizar a as duas equipes numa s para atingirem o mesmo objetivo: a producao do jogo. o Pode-se indicar eXtreme Game Development como um processo unico que envolve todos os desenvolvedores, procurando formar um time coeso (whole team). Para isto, n o devem a existir super-especializacoes como o designer-da-fase-do-gelo ou o programador-do-editor de-mapas. Cada compet ncia individual deve ser compartilhada para o bem do projeto. e Os valores de XGD s o os mesmos de XP. Por exemplo, Simplicidade em XGD, se refere a a eliminacao da complexidade extra aos jogos, tornando a jogabilidade mais agrad vel, assim a como tamb m evitar perder tempo na adicao de detalhes ou funcionalidades que n o ser o noe a a tadas no jogo. Comunicacao e um valor crucial para o projeto em jogos, por se tratar de uma equipe multidisciplinar com potencial para conitos internos em muitas etapas do desenvolvimento.

5.4.1

PAPEIS

Os pap is do XGD s o: e a

 Produtor: e o equivalente ao cliente em XP, pois e o produtor do jogo quem fornece

os requisitos e pode decidir sobre o escopo e data das vers es. Pode-se vericar uma o pequena variacao deste papel entre projetos pequenos e grandes. O termo produtor deriva de projetos que contam com equipe de producao de arte ou producao cultural. Em projetos menores que n o existem produtores, o papel do cliente e desempenhado pelo a game designer.

46

 Desenvolvedores: engloba todos os prossionais da area tecnica: game designers, level

designers, artistas 2D/3D, animadores e programadores,

 Coach: aparentemente com o mesmo nome de um dos papeis XP, o coach em XGD
e o gerente do projeto e tamb m um auditor que verica se a equipe est seguindo as e a pr ticas. Uma ferramenta de apoio ao seu trabalho e o painel XGD ou XGD dashboard a (DEMACHY, 2003), onde o coach pontua de 0 a 5 cada pr tica usada pela equipe. a  Distribuidor: ou publisher. E o patrocinador do projeto ou o gold-owner para XP. Apesar do produtor ser identicado como cliente, e aconselh vel que o game designer o a auxilie para fazer os testes funcionais (DEMACHY, 2003), assumindo um papel semelhante ao testador em XP.

5.4.2

PRATICAS

Na denicao de XGD, as pr ticas s o consideradas a mesma coisa que os princpios, que s o a a a adaptacoes das pr ticas de XP. Este trabalho pretende focar mais o desenvolvimento de jogos a como producao de software, portanto apenas algumas pr ticas ser o citadas: a a  Propriedade coletiva da criacao: e uma adaptacao de XP da pratica Propriedade coletiva. A criacao pertence a toda a equipe, e todos est o livres para mudar, excetuando-se a as diferentes atribuicoes dos prossionais. Isto e, os programadores tem a propriedade coletiva do c digo, modeladores 3D dos modelos 3D, e assim por diante. o

 Produtor sempre presente: esta pratica e mais facil de ser aplicada em projetos de XGD
do que em projetos tradicionais, pois o produtor geralmente e algu m dentro da empresa e com disponibilidade.  Vers es frequentes: vers es executaveis do jogo sao disponibilizadas com boa freq encia o o u em intervalos pequenos. Com isto os game designers podem analisar uma vers o, os disa tribuidores podem acompanhar o progresso do projeto e o gerente pode antecipar problemas podendo negociar com mais tranq ilidade. u

47

DESCRICAO DA ABORDAGEM

Neste captulo, ser descrita a abordagem seguida para aplicar modelagem em eXtreme a Programming ecientemente, no domnio de jogos.

6.1

OBJETIVO

E fato que eXtreme Programming possui modelagem, por m como foi dito na secao 3.4.2 e existem dois motivos v lidos para se modelar: para entender o domnio do problema ou comua nicar. Pode-se vericar que um simples rascunho de diagrama pode comunicar mais eciente mente do que escrever um c digo inteiro para demonstrar uma id ia, como e feito normalmente o e em XP. A Modelagem Agil e um metodologia indenpendente de outros processos, focalizando mo delagem e documentacao ecazes. A aplicacao dela junta a XP e recomendada, pois ela agrega ` qualidade ao processo e tem um ajuste natural a XP. Na secao 4.4, foi discutido sobre as diferentes atividades de desenvolvimento demandadas pelo domnio de jogos. Tais atividades, n o est o descritas por XP, por m devem ser conside a a e radas, assim como novos processos de suporte e diferentes artefatos relacionados a elas. O objetivo desta abordagem e capturar estas especicacoes e reet-las numa aplicacao pr tica de eXtreme Programming localizado. Assim, nas pr ximas secoes, ser o abordadas a o a intersecoes e conseq ente modicacoes para agregar metodologias que suportem a modelagem u e desenvolvimento de jogos, como eXtreme Game Development (XGD) detalhada na secao 5.4. Uma visualizacao do resultado prentendido e demonstrado na gura 7.

6.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 em XP, como foi dito em 5.2. As vezes, quando estes modelos n o s o sucientes para se a a

48

Figura 7: XP + MA + XGD se complementando entender um problema ou comunicar, os desenvolvedores XP usam outros artefatos como citado em (BECK, 2000) (p g. 111). a J que existe modelagem em XP, pode-se aplicar modelagem agil nela. Naturalmente, a ` muitas das pr ticas da modelagem agil s o mapeadas diretamente a XP. Abaixo est o listadas a a a ` algumas pr ticas que s o novas ou alternativas as pr ticas XP convencionais: a a a

 Aplique o(s) artefato(s) correto(s): uso de ferramenta ou tecnica mais apropriada que
estiver disponvel para o trabalho. E preciso ter conhecimento de v rios artefatos para a escolh -los bem. e

 Crie diversos modelos em paralelo: Os desenvolvedores XP podem criar diversos modelos em paralelo: cart es CRC, conjuntos de testes de aceitacao e esbocos opcionalmente. o Entretanto, quando se aplica modelagem agil a XP, n o deve se restringir a apenas estes a ` modelos.

 Mostre os modelos de forma simples: Pratica complementar a` pratica XP Design simples (em 5.2.3). Os modelos n o precisam ser bonitos para serem ecazes. a

 Descarte os modelos tempor rios: a

Ao descartar modelos que n o se precisa mais, a

tamb m se est diminuindo a carga de trabalho futura, pois ser o menos modelos para e a a manutencao. Sempre que um modelo j tiver cumprido seu papel, e hora de descart -lo. a a

 Formalize os modelos de contrato: Um modelo de contrato serve para ajudar a comunicacao

entre equipes diferentes de desenvolvimento quando uma delas desenvolve um sistema que necessite da fonte de informacao controlada por outra equipe. Esta pr tica foi in a cluda para auxiliar em situacoes durante integracoes com outros sistemas, por exemplo.

49

Nestes casos, e evidente a necessidade de comunicacao, seja por documentos ou qualquer outro meio. Scott Ambler (AMBLER, 2004) indica que, nestes casos, uma boa opcao para auxiliar a comunicacao e a formalizacao de um modelo de contrato.  Modele para comunicar: E uma das raz es validas para se criar modelos, apoiando o o princpio da Comunicacao Aberta e Honesta.

 Modele para entender: Generalizacao da ideia de se usar cart es CRC para explorar o
temas relacionados ao projeto.

 Reuse os recursos existentes: Nova pratica includa para agilizar a modelagem em XP.
6.2.1 REFATORACAO

Os desenvolvedores XP aplicam refactoring com freq encia. Logo, podem existir situacoes u em que o c digo-fonte que fora de sincronia com um modelo de projeto ap s uma refatoracao. o o Para resolver este impasse com agilidade, deve-se questionar a 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 modelo. Neste caso, existem ferramentas diso ponveis que geram diagramas de classe ou de seq encia. u Quando a equipe precisar refatorar todo um sistema para eliminar uma hierarquia de herancas complexas, por exemplo, uma sess o de modelagem agil e recomendada, incentivando os dea senvolvedores a projetar as mudancas. Esta pr tica permitir maior agilidade para se buscar a a a melhor solucao e e recomendada tanto por (AMBLER, 2004) quanto por (BECK, 2000). Assim, a Modelagem Agil e naturalmente aplic vel a XP mesmo quando se trata de grandes refatoracao. a

6.3

MODELAGEM AGIL + XGD

Como a Modelagem Agil e aplic vel a XP, ela tamb m ser aplic vel a XGD sem mudancas a e a a ` signicativas para o programadores. Por m para os n o-programadores, algumas pr ticas ese a a senciais mudam, tornando a modelagem e a documentacao mais ecazes. A principal delas e relativa a documentacao e ao projeto de interface com o usu rio, descritos nas secoes 6.5 e 6.5.1 a respectivamente.

50

6.4

ABORDAGENS COMPLEMENTARES

Object Thinking (OT) e uma nova abordagem para a modelagem de sistemas orientada a objetos, que prop e que se pense como um objeto ao inv s de se pensar como um computador o e (o que e ensinado atualmente em programacao). David West, autor do livro Object Thinking enfatiza que n o se pode entender eXtreme Programming sem um pr vio entendimento sobre a e Object Thinking (WEST, 2004) (p g. XXV). a Object Thinking inuencia nos quatro valores XP da seguinte forma:

 Comunicacao: Object Thinking seria uma linguagem comum entre usuarios, gerentes,
especialistas do domnio e desenvolvedores.

 Simplicidade: OT possibilita a simplicidade numerica (n mero de classes e metodos) u

e criacao de objetos simples. Object Thinking se prop e a facilitar a identicacao de o objetos e a delegacao de responsabilidades baseada no domnio do problema, oferecendo uma simplicidade natural entre o mundo real e a modelagem.

 Coragem: Para aplicar OT sera preciso coragem para contrapor aos pensamentos tradicionais usados em OO e enfrentar os custos da mudanca no processo de desenvolvimento.

 Feedback: OT inuencia indiretamente o feedback. A maior vantagem e que sera mais

f cil vericar se os modelos est o de acordo com a implementacao. a a Object Thinking e baseada no comportamento dos objetos (Behavior-based), apontando os cart es CRC como artefatos poderosos para se capturar e entender o comportamento dos objeo tos. Nesta vis o, os cart es de usu rio representam responsabilidades dos objetos identicadas a o a pelos clientes.

6.5

PROCESSO GERAL

A abordagem apresentada neste captulo n o se prop e a ser uma nova metodologia, ela e a o 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 o ambiente de a desenvolvimento local. Anal, modicar uma metodologia existente e mais f cil que criar uma a ou mais efetivo que usar outra metodologia projetada para uma nova situacao (COCKBURN, 2002).

51

A seguir, ser feita uma abordagem desta localizacao de eXtreme Programming segundo a as etapas cl ssicas de desenvolvimento de software: a

 Coleta de Requisitos:
A coleta de requisitos na abordagem XP+XGD+modelagem agil e a mesma de XP, onde o cart es de usu rio ou cart o de hist ria e a unidade de requisitos funcionais. J a coleta o a a o a de requisitos n o-funcionais n o e bem clara em XP, assim como nas metodologias ageis a a em geral (PAETSCH, 2003), cabendo a cada equipe o trabalho de detect -los e transform a a los em cart es de tarefa. Isto e, os pap is do produtor e game designer, que agem como o e clientes, t m uma boa nocao dos requisitos n o-fucionais de um jogo, como performance e a 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 e a a a vericado se este e consistente e test vel (PAETSCH, 2003). Outras vericacoes como se a o requisito n o-ambguo e completo, s o resolvidos com a presenca constante do cliente a a 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 necess rio atrav s de a e uma sess o de modelagem agil para criar a met fora do sistema. Segundo West (WEST, a a 2004), tal met fora deve ser t o forte a ponto de eliminar o projeto arquitetural detalhado. a a Se uma unica met fora n o puder satisfazer esta condicao, pode-se criar mais de uma a a met fora para partes do sistema. a Entretanto, pode-se considerar a met fora apenas como uma base arquitetural geral, onde a o detalhamento da arquitetura vai sendo trabalhado ao longo do desenvolvimento.

 Projeto de Interface:
Na secao 4.3.1, foi abordado os requisitos funcionais de um jogo, sendo que a jogabili dade, ou usabilidade, e um dos principais. A usabilidade abrange o estudo sobre o uso de um produto por usu rios especcos para alcancar objetivos especcos com efetividade, a eci ncia e satisfacao em um contexto de uso especco (WIKIPEDIA, 2005). Ela est e a diretamente ligada ao Projeto de Interface com o Usu rio e e a capacidade do software a em permitir que o usu rio alcance suas metas de interacao com o sistema. a

52

O Projeto de Interface com o Usu rio entra no processo de design para melhorar a exa peri ncia do usu rio (user experience). Como XP n o cita t cnicas de modelagem de e a a e interface (veja gura 6 no captulo 5), prop e-se o uso parcial da metodologia Goals o User Interface Design (GUIDe) (LAAKSO; LAAKSO, 2004) 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 qualquer tipo a 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 os seguintes passos adaptados: 1. A entrada de requisitos e feita atrav s de cart es de usu rio que originam tamb m e o a e os testes de validacao da interface ou funcionalidade iterativa a ser criada. Os cart es de usu rio foram criados pelo produtor com auxlio do game designer. Os o a cart es de usu rio podem apresentar gr cos ou modelos de tela como rascunho em o a a substituicao ou em anexo ao texto. 2. Os desenvolvedores elaboram especicacoes da interface com o usu rio e testam a atrav s de simulacoes de um jogador executando a tarefa. A partir destas simulacoes e r pidas, surge um modelo mais renado da interface que ser anexado aos cart es de a a o tarefa (task cards). Segundo a GUIDe, os modelos resultantes seriam use cases, mas seguindo a pr tica Aplique o(s) artefato(s) correto(s) da Modelagem Agil, outros a artefatos podem se apresentar mais adequados ou complementares como o diagrama de atividades para funcionalidades interativas. A Modelagem Agil tamb m alerta e que a UML e ampla, mas n o e suciente para representar interface com o usu rio. a a Usa-se neste caso, prot tipos de interface com o usu rio essenciais, por exemplo. o a Veja gura 8. A fase seguinte e de implementacao.  Implementacao: A implementacao em XP, e feita em duplas (pair programming (PAIR. . . , 2001)): en quanto 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 vericar quando a o desenvolvimento da tarefa est encerrado. No domnio de jogos, como temos duas frena tes de desenvolvimento integradas: a producao do software e a producao do conte do, u os cart es de tarefa s o repassados por todos os prossionais requeridos na atividade, o a

53

Figura 8: Prot tipo de interface com o usu rio essencial (baixa denicao) o a seguindo a seq encia similar a da tabela 1 (secao 4.4). Mais detalhes sobre testes est o u a nas secoes seguintes. Ap s cada atividade executada, o desenvolvedor registra a data e o hora 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 funcional (hist ria a o de usu rio), segundo a vis o de um programador: a a 1. O cliente elabora uma hist ria que depois e estimada pela equipe. Se a equipe n o o a consegue estim -la, o cart o de usu rio e dividido. Nesta divis o e comum que a a a a funcionalidades ligadas ao desenvolvimento de software se separem das atividades ` ligadas as demais areas, para se ter uma boa estimativa. Por m e importante vericar e os cart es de usu rio que em conjunto implementam uma funcionalidade maior do o a sistema para agrup -loss na iteracao corrente ou na seguinte. a 2. A equipe de programadores transforma os cart es de usu rio em objetos. Agruo a pando 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 na iteracao o a corrente. A equipe aproveita este tempo para discutir a implementacao seguindo a met fora do sistema (sua arquitetura). Idealmente, e feita uma sess o de modelagem a a agil em p . Depois os cart es de usu rio selecionados s o nalmente divididos entre e o a a os pares. 4. Cada dupla, realiza uma r pida sess o de modelagem para discutir os detalhes da a a implementacao e construir os testes.

 Testes:

54

Existem dois tipos de testes a serem realizados: autom ticos (sobre o c digo) e de game a o design (testes de jogabilidade, de design, balanceamento, harmonia visual entre outros). Os pares XP devem criar os testes autom ticos possveis e sucentes para vericar quando a a tarefa est nalizada. a A validacao de um design eventualmente se transforma em uma tarefa subjetiva. Por m, e pode-se considerar a exist ncia de padr es de interface para vericar se a interface e e o us vel (LAAKSO, 2003). a ` Os testes de validacao relativos a producao de conte do s o elaborados pelo produtor u a com o auxlio de um game design. Nesta etapa, muitos testes s o focados na usabilidade a (jogabilidade). Durante a execucao dos testes de validacao gerais, e aconselh vel que exista um meca a nismo que registre as atividades do jogador para que o erro possa ser reproduzido novamente (PAETSCH, 2003). Existem muitos testes n o-funcionais sobre requisitos como performance. Alguns exema plos: Testes usando como m tricas o n mero de polgonos e tamanho de arquivos (i.e.: e u imagens, vdeos). Testes entre a camada de renderizacao e o hardware. Testes sobre a IA dos Non-Player-Characters (NPCs). S o testes para vericar se a as acoes executadas por jogadores controlados pelo software correspondem a um padr o inteligente. a

 Revis es arquiteturais: o
O objetivo do uso da Modelagem Agil com XP e o de tornar a modelagem e documentacao ecazes, mas n o se resume a isto. Opcionalmente, a depender da complexidade do proa jeto, pode-se agendar revis es arquiteturais simplicadas ao nal de cada iteracao. Tais o revis es teriam o mesmo formato de sess es de modelagem agil, com a participacao dos o o desenvolvedores. Seriam levantados diagramas simples da arquitetura corrente gerados a partir da processos de engenharia reversa realizados automaticamente por ferramentas CASE. Durante a sess o, seriam levantados problemas crticos da arquitetura corrente a pontuados de 1 a 4 em ordem de relev ncia (MARANZANO et al., 2005). Caso o problema a fosse bastante crtico, no nvel 1 por exemplo, deve-se corrigir o problema, fazendo-se o redesign e refactoring especcados em novos cart es de tarefa para a nova iteracao ou o divididos entre v rias iteracoes. a

55

Entretanto, e importante que a abordagem de revis o arquitetural acima e apenas um a m todo simplicado que e a melhor opcao do que n o existir revis o arquitetural no e a a projeto, visto que eXtreme Programming prev a exist ncia de situacoes que necessie e tem de algum retrabalho de design, mas deixa a deteccao a cargo dos desenvolvedores. Uma abordagem melhor para revis es arquiteturais convencionais pode ser encontrada o em (MARANZANO et al., 2005).

6.5.1

DOCUMENTACAO DO SISTEMA

A documentacao tamb m faz parte de XP, e geralmente ela ocorre ao nal do projeto, pois e o objetivo secund rio e se preparar para a pr xima jogada. Os diferentes tipos de documentos a o t m o seu prop sito e vantagens. Por m a decis o de se fazer documentacao deve ser uma e o e a decis o de neg cios. O cliente dever estar ciente que ao inv s de produzir software, parte da a o a e equipe estar alocada na producao de documentacao. a Existem quatro tipos de documentacao, relativas a producao do jogo como software:

 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 neste tipo de a a u documento.  De operacoes: e um resumo dos requisitos nao-funcionais do sistema com informacoes como disponibilidade e conabilidade.

 De suporte: inclui materiais de treinamento para a equipe de suporte.  De usu rio: sao os helps, Perguntas freq entes respondidas (FAQs) e manual do jogo a u
contendo guia da interface. ` Al m dos tipos de modelo citados, existem outros ligados a area de Game Design como e o Documento de Game Design (FREEMAN, 1997). Seguindo-se a Modelagem Agil, alguns destes 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 n o trar nenhum a a a benefcio ao jogo em desenvolvimento. Uma forma de agilizar isto e a producao de Early Post mortems (postmortems parciais) durante a fase de manutencao do projeto. Se o jogo estiver em producao e disponvel para ao p blico, por exemplo, a ger ncia poder se beneciar deste u e a

56

resultado, podendo prever estrat gias de vendas. De qualquer forma, a equipe de desenvole vimento vai ter um benefcio maior, pois poder analisar o que deu certo ou n o, seguindo o a a princpio agil Regularmente, a equipe deve reetir em como ser mais efetiva, ent o se ajustar a adequadamente (ALLIANCE, 2001).

6.5.2

RESUMO

As Metodologias Ageis em geral surgem para maximizar a concorr ncia entre as atividae des, existindo 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 jogo, a a abordagem descrita neste captulo pode ser visualizada da seguinte forma:

Figura 9: Vis o do processo geral de producao do jogo (software) a Note que as iteracoes possuem o mesmo tempo de duracao de duas a tr s semanas. e

57

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 9 do captulo anterior.

7.1

CONCEITOS PRELIMINARES

Antes do relato do caso implementacao, os conceitos de jogos de empresas e massive mul tiplayer online game (MMOG) ser o abordados para ns did ticos. a a

7.1.1

JOGOS DE EMPRESAS

Um Jogo de Empresa e uma simulacao planejada que encaixa os jogadores em um sis tema de neg cios simulado que assumem o papel de tomadores de decis es em organizacoes. o o Suas escolhas geralmente afetam as condicoes do sistema onde a decis o subseq ente deve ser a u tomada (GRAMIGNA, 1994). Nasceram nos Estados Unidos, como simulacoes de guerra, sendo hoje uma pr tica muito a comum comprovada estatsticamente (ABSEL, 2005). Jogos de Empresa tamb m s o chamados e a de Business Games ou Business Simulation. No Brasil s o usados como ferramentas no ensino a em cursos de p s-graduacao, graduacao de Ci ncias Cont beis, Administracao e Economia. o e a S o classicados de duas formas: a

 Gerais: elaborados para desenvolver habilidades gerenciais de executivos.  Funcionais: elaborados para desenvolver habilidades em areas especcas da organizacao
(nancas, producao, vendas etc).

58

7.1.2

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 nou a vas arquiteturas como multi-servidoras, descentralizadas/distribudas ou hbridas (CECIN; BAR
BOSA; GEYE, 2003).

Geralmente, um MMOG n o e jogado em turnos, mas sim em tempo indenido. Os joa gadores se conectam ao jogo usando um cliente ou servant em aplicacoes peer-to-peer (RULE, 2004).

7.2

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). E um projeto em desenvolvimento e apresenta aqui seus resultados parciais utilizando Modelagem Agil em eXtreme Programming.

7.2.1

ESCOPO

O jogo foi dividido em duas partes: jogos ofine singleplayer (somente o usu rio contra o a computador) e jogos online massivos (v rios jogadores disputando em rede simultaneamente). a Foi denido o desenvolvimento da parte ofine primeiro. No nicio desta parte foi previsto um mecanismo de aprendizagem, como tutoriais inteligentes (MASCARENHAS; CARVALHO, 2002), para que o usu rio se habituasse com facilidade ao ambiente e alguns conceitos de jogos a de 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 o din mica de cadeias produtivas pr prio. O objetivo do jogo e conseguir o sucesso da empresa a o virtual, sua expans o, e o aprendizado pela experi ncia. Muito similar ao SimCity (ALVES, a e 2004), por m a simulacao era baseada na administracao b sica de empresas. e a

7.3

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 cona

59

tendo poucas refer ncias e pesquisas existentes. Grande parte do projeto descrito em abordagem e foi elaborado com o intuito de acrescentar novas informacoes a XGD. ` Para o ambiente de desenvolvimento, foi utilizado um espaco adequado para implementacao de eXtreme Programming, segundo a indicacao caves and commons (BECK, 2000), onde os computadores s o pr ximos uns aos outros com espaco suciente para os pares de programacao, a o radiadores de informacao (veja a gura 10) e espacos extras para modelagem, reuni es ou o tarefas reservadas.

Figura 10: Um dos radiadores de informacao usados

7.3.1

EQUIPE

No projeto, existem pap is XP e relativos ao desenvolvimento de jogos: um game desige ner/artista gr co; dois clientes (sendo um especialista em jogos empresariais); quatro proa gramadores; um coach; e um testador. Entretando a equipe e pequena e mista, o que d um a total de seis pessoas, exceto um modelador 3D e um artista gr co em car ter de contratacao a a futura at a data deste documento. e A equipe de desenvolvimento e, em geral, iniciante, deixando o desenvolvimento em car ter a experimental, pois e a primeira aplicacao de XP e de Modelagem Agil para todos os desenvol vedores. Dos quatro desenvolvedores, apenas dois tinham participado ativamente de modelagem de sistemas em projetos anteriores, o que fez muitas sess es de modelagem agil serem realizadas o

60

apenas por uma dupla. A equipe fez auto-treinamento em refactoring e CppUnit(WHITLOCK; MELNIKOV; LEPILLEUR, 2005) para os testes de unidade, sendo feita duas apresentacoes sobre eXtreme Pro

gramming uma sobre Modelagem Agil e uma simulacao de XP para todos incluindo o cliente, chamada por muitos de eXtreme Hour (COCKBURN, 2002)(p g. 139). a

7.3.2

TECNOLOGIAS E FERRAMENTAS

Foram utilizadas as seguintes ferramentas para suportar comunicacao: Twiki, quadro-branco e ip chart. Para modelar ou criar documentacao agil tamb m foram utilizadas Umbrello, Dia e e plugin EclipseUML, al m de uma ferramenta CASE de engenharia reversa. O ambiente de e desenvolvimento contou com um sistema de controle de vers o CVS (Concurrent Versions Sysa tem) (CVS, ), Eclipse IDE (ECLIPSE. . . , ) e CppUnit. As plataformas Windows XP e Debian GNU/Linux foram utilizadas para o desenvolvimento.

7.3.3

CRONOGRAMA

A execucao do projeto passou por uma grande mudanca de requisitos na sua primeira iteracao, forcando o projeto a recomecar. O primeiro projeto de Game Design previa um jogo 2D isom trico como na gura 11, por m o cliente, ap s uma an lise de mercado, decidiu mudar e e o a para 3D, fazendo investimento numa game engine (ou motor de jogo) 3D (MENEZES, 2004), mudando o projeto, a plataforma de desenvolvimento, prossionais requeridos entre outras coisas. At o presente momento o projeto passou pela sua primeira iteracao ocial, deixando e uma vers o em producao. A Fase exploracao foi de 5 semanas e o tempo de duracao da iteracao a foi tamb m de 5 semanas. As iteracoes seguintes devem durar de 2 a 3 semanas. e

7.3.4

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. Entretanto por existirem dois clientes, notou-se algumas vezes uma falta de sincronia entre os clientes, onde um precisava consultar o outro sobre determinado requisito. O cart es de usu rio iniciais foram digitados no computador, por m era freq ente as vezes o a e u em que mais informacoes precisavam ser adicionadas a eles (veja a gura 12). Para agilizar

61

Figura 11: Prot tipo 2D o o processo, o cliente passou a escrever as hist rias numa folha padr o e todos os cart es de o a o usu rio cavam disponveis numa pasta. a Os requisitos n o-funcionais inuenciaram, no incio do projeto, sobre a tecnologia e fera ramentas a serem escolhidas. Buscou-se deixar o cliente alheio em relacao a escolha das tecno ` logias envolvidas, exceto quando a aquisicao de alguma ferramenta incorreria em custo para o projeto. Na primeira aplicacao de XP, nem todos os cart es de usu rio foram vericados se eram o a consistentes e test veis, incorrendo em requisitos mal coletados. Por m, este problema foi a e resolvido logo em seguida com a divis o de cart es de usu rio, permitindo uma Validacao de a o a Requisitos mais consistente. Os novos cart es de usu rio gerados eram mais simples, contendo o a funcionalidades e com maior facilidade de se gerar testes funcionais. Para uma base de Projeto Arquitetural foi utilizada uma met fora centrada no pr prio a o projeto do jogo, onde as objetos principais eram os simuladores ofine e online. Esta n o foi a uma boa met fora, pois a maioria dos participantes desconhecia o conceito de simulacao. A a segunda met fora elaborada foi baseada na din mica do jogo, onde os objetos identicados a a eram de f cil compreens o pelo cliente e pelos desenvolvedores. a a A met fora n o eliminou a necessidade de um diagrama para a arquitetura de rede, que teve a a que ser modelado para comunicar ao cliente a necessidade de construcao de um middleware (veja gura 13).

62

Figura 12: Exemplo de cart o de usu rio utilizado a a Para o Projeto de Interface, foram utilizadas Sess es de modelagem agil, onde partiao se dos cart es de usu rio passando por use cases at chegar ao prot tipo de interface com o o a e o usu rio essencial, seguindo uma GUIDe adaptada. a 7.3.4.1 IMPLEMENTACAO

Logo no incio da iteracao, notou-se a necessidade de adicionar mais espaco nos cart es de o tarefa para anotacoes e coment rios sobre cada tarefa do dia, principalmente quando a tarefa a teria que continuar no dia seguinte. O cart o de tarefas e demonstrado na gura 14. a Algumas tarefas de interface foram executadas por demanda do cliente e/ou dos pr prios o programadores. No estudo de caso, procurou-se separar as tarefas relativas a producao da in terface em cart es de tarefa diferentes dos de programacao de regras de neg cio. Por exemplo, o o existiram cart es de usu rio para especicando a producao da telas de entrada no sistema e o a outros que deniam como validar o usu rio. a

63

Figura 13: Modelo agil de arquitetura de rede Ap s a grande mudanca de requisitos citada na secao 7.3.3, passou-se a usar um motor o de jogos de c digo aberto. Entretanto, o c digo disponvel possua uma hierarquia de classes o o muito complexa (muito verticalizada) al m de n o ter classes de teste (para realizacao de testes e a autom ticos), requerendo uma grande refatoracao que ainda est em execucao. a a N o foi feita nenhuma revis o arquitetural, at o momento. As classes adicionais ao motor a a e de jogos tiveram um design muito simples e preferiu-se agendar para o nal da pr xima iteracao. o 7.3.4.2 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. Existiram o a o ` outro documentos produzidos como cart es de tarefa, cronogramas e prot tipos anteriores a o o aplicacao de XP.

7.3.5

MODELAGEM AGIL

Para deixar mais claro os resultados e aplicacoes da Modelagem Agil no caso apresentado, alguns exemplos ser o adicionados em relacao a pr ticas desta metodologia. a ` a 7.3.5.1 PRATICAS

Para a modelagem iterativa e incremental: 1. Aplique os artefatos corretos: Durante a modelagem da interface de login usou-se prot tipos de interface com o usu rio essenciais. o a

64

Figura 14: Cart o de tarefas a 2. Crie diversos modelos em paralelo: Mesmo usando cart es CRC tamb m foram criados o e diagramas de seq encia. u 3. Itere em outro artefato: Enquanto modelava um caso de uso, era preciso tamb m ene tender os uxos de atividades o que n o parecia ser possvel com o caso de uso. Um a diagrama de atividades foi usado para se iterar. 4. Modele incrementalmente: A modelagem era feita de acordo com a necessidade da semana ou do dia. Para o um trabalho de equipe ecaz 1. Modele com outras pessoas: Foram feitas sess es de modelagem com outros deseno volvedores e at com o cliente num sess o de modelagem de alto nvel usando cart es e a o CRC. 2. Organize uma participacao ativa do cliente: Mesmo caso citado acima. 3. Promova a posse coletiva: N o existe eu nas modelagens, s n s. a o o 4. Mostre os modelos publicamente: Foram realizadas pequenas apresentacoes com mo delos de telas por exemplo.

65

Pr ticas que permitem simplicidade a 1. Criem conteudo simples: Os cart es CRC deram um bom suporte para se conseguir o aplicar esta pr tica. a 2. Mostre seus modelos de forma simples: Evitou-se adicionar detalhes desnecess rios a sempre. 3. Use as ferramentas mais simples: As ferramentas mais usadas foram: papel, caneta e ip chart. Pr ticas para validar o trabalho a 1. Considere a testabilidade: Cada modelo foi criado pensando-se nos testes. 2. Comprove com c digo: E a maneira ideal para responder a d vida se o projeto est certo. o u a

7.4

CONSIDERACOES

A aplicacao de eXtreme Programming envolve um planejamento inicial sobre uma s rie de e quest es: n mero de pessoas no desenvolvimento, condicoes do ambiente de trabalho e respono u sabilidades desempenhadas. Neste caso, por n o existir uma estimativa anterior semelhante, a n o foi possvel estimar com precis o, aumentando o risco do projeto. Com o passar do tempo, a a este risco diminui. Deve-se considerar n meros pares para a pr tica de pair programming, al m de dividir u a e adequadamente pessoas com mesmas habilidades entre as duplas, fazendo-as circular o conhecimento. Pela experi ncia, podemos considerar tr s pap is importantes para o acompanhamento e e e e desempenho das tarefas: o tracker, um papel de projetos XP respons vel por acompanhar o a progresso e velocidade da equipe; o coach; e o game designer. eXtreme Programming de fato, p e muita responsabilidade nas habilidades do membros da equipe, potencializando as o qualidades ou defeitos humanos.

66

CONCLUSOES

Hoje, os desenvolvedores brasileiros de jogos ainda enfrentam problemas como: orcamento reduzido; press es mercadol gicas por qualidade e muitas funcionalidades nos jogos; pouca o o experi ncia em desenvolvimento de jogos; reducao de prazos de entrega; pouco planejamento e gerencial; 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 bu rocr ticos mais leves. Entretanto, a aplicacao de eXtreme Programming n o e recomendada a a sem uma base s lida sobre os fundamentos e pr ticas da Engenharia de Software como a moo a delagem. De fato, eXtreme Programming e as demais Metodologias Ageis eliminam cada vez mais a necessidade de indivduos especializados em prol de indivduos com compet ncias que abragem e mais o desenvolvimento de software. Este e um fato tanto positivo quanto negativo, a diferenca est em se ter tais pessoas na equipe. a A aplicacao da Modelagem Agil em eXtreme Programming foi f cil e intuitiva, melho a rando o entendimento sobre a modelagem num projeto e reforcando pr ticas XP. Ao se aplicar a 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 antes. O que e equivaa a ` lente a eXtreme Programming, pois antes mesmo de se implementar o c digo desejado, deve-se o implementar testes. E nem por estas raz es existe perda de eci ncia. Muito pelo contr rio. o e a As metodologias ageis est o revolucionando a Engenharia de Software, porque elas valorizam a 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 defei tos humanos. Existem at formas de se deixar metodologias tradicionais como Rational Unied Process e (RUP) mais ageis como e dito em (SMITH, 2001) sobre o RUP congur vel, por m o que a e

67

diferencia Metodologias Ageis como XP e a base los ca (valores e princpios diferentes). o ` Portanto, mesmo que se aplique RUP congurado, se estar sujeito a mesma base los ca a o antiga.

8.1

RESULTADOS

Como resultado parcial da aplicacao da Modelagem Agil em XP no domnio de jogos, vericou-se que a Modelagem Agil tornou os processos de modelagem e documentacao mais ecazes. As dicas uteis fornecidas pelas pr ticas, auxiliaram a aprendizagem e aumento de a ec cia dos modeladores. A principal diferenca e que a tarefa de modelar deixou de ser vista a como um fardo para se tornar atividade prazerosa que agrege valor ao desenvolvimento de software.

8.2

DIFICULDADES ENCONTRADAS

Uma das diculdades em se aplicar Modelagem Agil e seguir a pr tica Modele incremena a talmente, 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 em UML os livros e UML na Pr tica - Do Problema ao Sistema (CARDOSO, 2003) e UML 2 - Guia de Consulta a R pida (GUEDES, 2003), para correlacionar a simplicidade e agilidade oferecidas pelos moa delos/diagramas UML. Outras refer ncias sobre modelagem de Interface com o Usu rio por e a exemplo, foram buscadas na internet atrav s de v rias fontes como (USERNOMICS, 2005). e a

8.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 desen a volvedores n o-programadores. Um segundo ponto, seria como obter melhores estimativas a de desenvolvimento. Pode-se indicar ainda outros trabalhos futuros como:

68

 Investigacao maior da aplicacao sobre Object Thinking com XP: As Metodologias Ageis requerem novas formas de pensar, logo podemos aplicar XP+modelagem agil aliada a OT.  Investigacao maior da aplicacao sobre Naked Objects com XP: Naked Objects e uma outra forma de se pensar a orientacao a objetos focando o comportamento de objetos. ` Existem poucos trabalhos realizados sobre esta abordagem que une a agilidade de XP a simplicidade de um framework (MATTHEWS, 2004).  Investigacao mais profunda da GUIDe em jogos: E provavel que metodos como GUIDe e modelagem agil juntos formem um m todo de modelagem maduro o suciente para pose sibilitar o estado-da-arte em interfaces, mesmo assim, faltariam pr ticas para a criacao a de interatividade como e vista em jogos.  Investigacao sobre Game Design Patterns e User Interface Design Patterns: Tal

investigacao buscaria a melhoria o desenvolvimento de jogos de forma ecaz, atrav s da e aplicacao de User Interface Design Patterns (LAAKSO, 2003) e Game Design Patterns (KREIMEIER, 2002).

69

REFERENCIAS

ABSEL. ABSEL- Association for Business Simulation and Experiential Learning. 2005. Ultimo acesso em 14 de marco de 2005. Disponvel em: <http://www.absel.org>. AHEARN, L. Budgeting and Scheduling your game. Gamasutra - The Art & Science of Making Games, 2001. Ultimo acesso em 18 de dezembro de 2004. Disponvel em: <http://www.gamasutra.com/features/20010504/ahearn 01.htm>. ALLIANCE, A. Agile Alliance. 2001. Ultimo acesso em 07 de dezembro de 2004. Disponvel em: <http://www.agilealliance.org>. ALVES, L. Sim City. 2004. Ultimo acesso em 24 de julho de 2005. Disponvel em: <http://www.comunidadesvirtuais.pro.br/ead/simcity.htm>. AMBLER, S. W. Modelagem Agil - pr ticas ecazes para a Programacao eXtrema e o a Processo Unicado. S o Paulo: Addison Wesley, 2004. a ART, b. Game Research the; GAMES science of computer. Dictionary. Ultimo acesso em 20 de julho de 2005. Disponvel em: <http://www.game-research.com/dictionary.asp>. ART, b. Game Research the; GAMES science of computer. History and genre. Ultimo acesso em 23 de julho de 2005. Disponvel em: <http://www.game-research.com/history.asp>. BECK, K. Extreme Programming Explained: Embrace Change. [S.l.]: Addison Wesley Professional, 2000. CARDOSO, C. UML na Pr tica - Do Problema ao Sistema. [S.l.]: Editora Ci ncia Moderna, a e 2003. CECIN, F. R.; BARBOSA, J. L. V.; GEYE, C. F. R. Freemmg: 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. [S.l.]: Sociedade Brasileira de Computacao, 2003. COCKBURN, A. Agille Software Development. 3th. ed. [S.l.]: Addison Wesley Professional, 2002. CONSORTIUM, D. DSDM Consortium - Helping you deliver on time. Dynamic Systems Development Method Ltd, 1994. Ultimo acesso em 27 de julho de 2005. Disponvel em: <http://www.dsdm.org>. CONSTANTINE, L.; LOCKWOOD, L. Design For Use. [S.l.]: Addison Wesley, 1999. COPE, M. C. Object Oriented Analysis and Design Using UML. Ratio Group Ltd, 2001. Ultimo acesso em 19 de julho de 2005. Disponvel em: <http://www.ratio.co.uk/white.html>.

70

COSTA, D. S. P. Um estudo sobre programacao extrema (extreme programming). Departamento de Ci ncia da Computacao, UFBA, p. 36, 2003. Monograa de nal de curso. e CVS. Ultimo acesso em 25 de julho de 2005. Disponvel em:

<https://www.cvshome.org>.

DEMACHY, T. Extreme Game Development: Right on Time, Every Time. Gamasutra - The Art & Science of Making Games, 2003. Ultimo acesso em 16 de dezembro de 2004. Disponvel em: <http://www.gamasutra.com/resource guide/20030714/demachy 01.shtml>. DEXTERITY, S. Project Postmortems. 1999. Ultimo acesso em 11 de janeiro de 2005. Disponvel em: <http://www.dexterity.com/postmortem>. ECLIPSE.ORG - Development Resources. Ultimo acesso em 25 de julho de 2005. Disponvel em: <https://www.eclipse.org>. EXTREMEGAMEDEV. ExtremeGameDev Wiki: ExtremeGameDev. 2005. Ultimo acesso em 22 de julho de 2005. Disponvel em: <http://www.extremegamedev.org/>. FINALBOSS.COM. Sobre as noteas. 2005. Ultimo acesso em 21 de julho de 2005. Disponvel em: <http://www.nalboss.com.br/fb3/p sobrenotas.asp>. FOWLER, M. et al. Refactoring: Improving the Design of Existing Code. [S.l.]: AddisonWesley, 2000. FREEMAN, T. Creating a Great Design Document. Gamasutra - The Art & Science of Making Games, 1997. URL. Ultimo acesso em 20 de julho de 2005. Disponvel em: <http://www.gamasutra.com/features/19970912/design doc.htm>. GRAMIGNA, M. R. M. Jogos de Empresas. S o Paulo: Makron Books, 1994. a GROUP, O. M. Controlled chaos: Living on the edge. p. 10, 1995. GUEDES, G. T. A. UML 2 - Guia de Consulta R pida. [S.l.]: Editora Novatec, 2003. ISBN a 8575220659. HIGHSMITH, J. Adaptive Software Development. [S.l.]: Dorsen House Publishing, 1996. HUIZINGA, J. Homo Ludens - O Jogo Como Elemento da Cultura. 5th. ed. [S.l.]: Perspectiva, 2004. ISBN 8527300753. JEFFRIES, R. E. XProgramming.com - an Agile Software Development Resource. 2005. Ultimo acesso em 25 de julho de 2005. Disponvel em: <http://www.xprogramming.com>. JOGOS made in Brazil. Universia Brasil, 2004. Ultimo acesso em 17 de setembro de 2004. Disponvel em: <http://www.universiabrasil.net/html/noticia ibfhg.html>. KREIMEIER, B. The Case For Game Design Patterns. Gamasutra - The Art & Science of Making Games, 2002. URL. Ultimo acesso em 20 de julho de 2005. Disponvel em: <http://www.gamasutra.com/features/20020313/kreimeier 03.htm>. KRUCHTEN, P. Software design in a postmodern era. IEEE Computer Society, April 2005. IEEE Software.

71

LAAKSO, S. A. User Interface Design Patterns. University of Helsinki, 2003. URL. Ultimo acesso em 19 de julho de 2005. Disponvel em: <http://www.cs.helsinki./u/salaakso/patterns>. LAAKSO, S. A.; LAAKSO, K.-P. Ensuring quality of the user interface with the GUIDe process model. University of Helsinki, 2004. URL. Ultimo acesso em 19 de julho de 2005. Disponvel em: <http://www.cs.helsinki./u/salaakso/papers/GUIDe.html>. MARANZANO joseph et al. Architecture reviews: Practice and experience. IEEE Computer Society, April 2005. MASCARENHAS, A.; CARVALHO, M. de. Um gerador de sistemas tutoriais inteligentes para auxlio a alfabetizacao em portugu s. In: Anais do Congresso da SBC - VIII WIE (SBC 2002). ` e Florian polis, Santa Catarina, BRA: Sociedade Brasileira de Computacao, 2002. P.249-54. o MATTHEWS, R. Naked Objects. Naked Objects Group Ltd, 2004. Ultimo acesso em 26 de julho de 2005. Disponvel em: <http://www.nakedobjects.org>. MENEZES, J. R. de B. Um Framework para Criacao de Jogos Computadorizados Multiplataforma. Dissertacao (Mestrado) Pontifcia Universidade Cat lica do Rio Grande o do Sul, Porto Alegre, 2004. NEBULON. Feature Driven Development. Nebulon Pty Ltd, 2002. Ultimo acesso em 27 de julho de 2005. Disponvel em: <http://www.featuredrivendevelopment.com>. PAETSCH, F. Requeriments engineering in agile software development. p. 72, 2003. Diploma Thesis. PAIR Programming, an Extreme Programming practice. Object Mentor Incor porated, 2001. Ultimo acesso em 17 de dezembro de 2004. Disponvel em: <http://www.pairprogramming.com>. PICCINNO, D. E-Opportunity in the Computer Game Industry. Gamasutra - The Art & Science of Making Games, 2003. 46 p. Ultimo acesso em 16 de dezembro de 2004. Disponvel em: <http://www.gamasutra.com/education/theses/20030623/piccinno 01.shtml>. PRESSMAN, R. S. Engenharia de Software. S o Paulo: Makron Books, 2005. a RULE, D. S. Generic P2P Architecture, Tutorial and Exam ple. 2004. Ultimo acesso em 6 de julho de 2005. Disponvel em: <http://www.codeproject.com/vbscript/Generic P2P Architecture.asp>. SMITH, J. A comparison of rup c and xp. Rational Software Corporation, May 2001. Rational Software White Paper. SOMERVILLE, I. Software Engineering. 6th. ed. [S.l.]: Addison Wesley Professional, 2003. USERNOMICS. User Interface Design & Usability Testing. Usernomics, 2005. URL. Ultimo acesso em 19 de julho de 2005. Disponvel em: <http://www.usernomics.com/user-interface design.html>. VALADARES, R. G. V. J. L. F. Extreme game development. In: Proceedings of WJogos 2003, Games and Digital Entertainment Workshop. Salvador, BA, BRA: Sociedade Brasileira de Computacao, 2003.

72

WEST, D. Object Thinking. [S.l.]: Microsoft Press, 2004. ISBN 0735619654. WHITLOCK, J.; MELNIKOV, A.; LEPILLEUR, B. CppUnit Wiki. 2005. Ultimo acesso em 25 de julho de 2005. Disponvel em: <http://cppunit.sourceforge.net/cgi-bin/moin.cgi>. WIKIPEDIA. ISO 9241-11. 2005. Ultimo acesso em 21 de julho de 2005. Disponvel em: <http://pt.wikipedia.org/wiki/ISO 9241-11>.