Mapeamento do processo de modelagem em Extreme Programming no domínio de jogos

UNIVERSIDADE FEDERAL DA BAHIA

INSTITUTO DE MATEM ATICADEPARTAMENTO DE CI ENCIA DA COMPUTAC AO

ABELMON DE OLIVEIRA BASTOS

MAPEAMENTO DO PROCESSO DE MODELAGEM EM

EXTREME PROGRAMMING NO DOM INIO DE JOGOS

Salvador

2005

ABELMON DE OLIVEIRA BASTOS

MAPEAMENTO DO PROCESSO DEMODELAGEM EM EXTREME

PROGRAMMING NO DOM INIO DE JOGOS

Monografia apresentada ao Curso degraduacao em Ciencia da Computacao,Departamento de Ciencia da Computacao,Instituto de Matematica, Universidade Fe-deral da Bahia, como requisito parcial paraobtencao do grau de Bacharel em Ciencia daComputacao.

Orientadora: Profa . Christina von Flach GarciaChavez

Salvador

2005

ADeus 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 deO. Bastos e Abelmon Lima Bastos, por nao mudarem e mesmo sendo as mesmas pessoas pode-rem me surpreender com licoes de vida (embora eu agradece tambem a influencia materna pelogosto a mudancas); a minhas irmas, Maria Candida e Rosangela, por todo o apoio; aos mes-tres do DCC e Matematica, principalmente minha orientadora, Christina, por ter a pacienciade quem acompanhou minha mudanca “agil” de um ano de projeto final; aos participantes doprojeto SuperNova por terem suportado comigo as mudancas de rumo; e aos amigos (da InfoJrUFBA, da Open, do trabalho, da faculdade - principalmente 1999.1 a 2000.2 - e da vida - e atedo Orkut!) e demais familiares pela torcida incondicional e imutavel.

“Mortal algum recebeu educacao sem sofrer.”

Sofocles

RESUMO

O desenvolvimento de jogose uma tarefa complexa por ser multidisciplinar e exigir altograu de qualidade. No Brasil, os desenvolvedores de jogos estao utilizando como metodologia,a eXtreme Programming(XP). Porem uma duvida crucial surge: sendoXP umaMetodologiaAgil que prioriza mais um software desenvolvido do que documentacao abrangente, comoe tra-tada a modelagem? O projeto tem o objetivo de mapear o processo de Modelagem emeXtremeProgrammingno domınio de jogos, apresentando a implementacao de um caso dentro destecontexto usandoXPcomModelagemAgil guiada por um fluxo flexıvel de processo a ser identi-ficado. Este trabalho tambem apresenta discussoes para esclarecer diversos mitos que envolvemo mal entendimento daeXtreme Programminge sua consequente aplicacao falha.

Palavras-chave:extreme programming, modelagemagil, jogos

ABSTRACT

Game development is a complex task involving a heterogenous team and demands a highquality work. At Brazil, the game developers are using like metodology, theeXtreme Program-ming(XP). However a crucial doubt appears: beingXPaAgile Methodologythat values workingsoftware over comprehensive documentation, how is treated the modeling activity? The maingoal of this project is to map the Modeling process intoeXtreme Programmingat the specificdomain of games, showing the case implementation inside this context usingXP with AgileModelingguided by a flexible process flow to be identify. This work also show discussions toclarify some mites involving misunderstanding abouteXtreme Programmingand its consecutivefail application.

Keywords: extreme programming, agile modeling, games

LISTA DE FIGURAS

1 Custos de manutencao. (BECK, 2000) . . . . . . . . . . . . . . . . . . . . . . 13

2 Comunicacao em projetos sem e com uma abordagemagil: (A) e (B) . . . . . . 16

3 Relacionamento entre as praticas MA . . . . . . . . . . . . . . . . . . . . . . 28

4 Cartao Class-Responsability-Collaborator . . . . . . . . . . . . . . . . . . . .40

5 XP visto como um processo . . . . . . . . . . . . . . . . . . . . . . . . . . .43

6 Escopo de XP (COCKBURN, 2002) . . . . . . . . . . . . . . . . . . . . . . . . 43

7 XP + MA + XGD se complementando . . . . . . . . . . . . . . . . . . . . . .47

8 Prototipo deinterface com o usuario essencial (baixa definicao) . . . . . . . . 51

9 Visao do processo geral de producao do jogo (software) . . . . . . . . . . . . .55

10 Um dos radiadores de informacao usados . . . . . . . . . . . . . . . . . . . .58

11 Prototipo 2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59

12 Exemplo de cartao de usuario utilizado . . . . . . . . . . . . . . . . . . . . . . 59

13 Modeloagil de arquitetura de rede . . . . . . . . . . . . . . . . . . . . . . . .60

14 Cartao de tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60

LISTA DE TABELAS

1 Fases de producao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

SUMARIO

1 Introduc ao 10

2 MetodologiasAgeis 12

2.1 Contexto das mudancas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

2.2 ManifestoAgil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Princıpios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

2.3 O ponto-chave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

2.4 Exemplos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

3 ModelagemAgil 19

3.1 Definicoes gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

3.2 Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

3.3 Princıpios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

3.4 Praticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

3.4.1 Basicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

3.4.2 Suplementares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

3.4.3 ModelagemAgil na pratica . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.4 Criacao de uma culturaagil . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.5 Sessoes de ModelagemAgil . . . . . . . . . . . . . . . . . . . . . . . 29

3.4.6 Usando as ferramentas mais simples . . . . . . . . . . . . . . . . . . .29

3.4.7 DocumentacaoAgil . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Domınio de Jogos 31

4.1 Domınio do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

4.1.1 Jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

4.2 Generos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

4.3 Caracterısticas do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

4.3.1 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . .33

4.3.2 Requisitos nao-funcionais . . . . . . . . . . . . . . . . . . . . . . . .33

4.4 Desenvolvimento de jogos . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

5 Analisando eXtreme Programming 36

5.1 Resumo sobre XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

5.2 XP e a modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

5.2.1 Metafora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

5.2.2 Jogo do Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . .38

5.2.3 Design Simples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

5.2.4 Sessoes CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

5.3 XP como processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

5.3.1 Papeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

5.3.2 Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

5.3.3 Ciclo de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . .42

5.3.4 Escopo de XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

5.4 XP e Desenvolvimento de Jogos . . . . . . . . . . . . . . . . . . . . . . . . .43

5.4.1 Papeis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44

5.4.2 Praticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

6 Descricao da abordagem 46

6.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

6.2 XP + ModelagemAgil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2.1 Refatoracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.3 ModelagemAgil + XGD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.4 Abordagens complementares . . . . . . . . . . . . . . . . . . . . . . . . . . .49

6.5 Processo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

6.5.1 Documentacao do sistema . . . . . . . . . . . . . . . . . . . . . . . .53

6.5.2 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

7 Estudo de caso 56

7.1 Conceitos preliminares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

7.1.1 Jogos de Empresas . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

7.1.2 MMOG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

7.2 Descricao do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

7.2.1 Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

7.3 Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

7.3.1 Equipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58

7.3.2 Tecnologias e ferramentas . . . . . . . . . . . . . . . . . . . . . . . .58

7.3.3 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59

7.3.4 Fases de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . .59

7.3.4.1 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . 60

7.3.4.2 Documentacao do sistema . . . . . . . . . . . . . . . . . . .61

7.3.5 ModelagemAgil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.3.5.1 Praticas . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

7.4 Consideracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62

8 Conclusoes 63

8.1 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

8.2 Dificuldades encontradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

8.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64

Referencias 66

10

1 INTRODUCAO

O mercado de jogos mundial vem crescendo 20,1% em media ao ano, superando as cifras

do cinema (PICCINNO, 2003). A grande demanda por novos jogos tem atraıdo a atencao de

grandes corporacoes e incentivado a entrada de novasplaywares(empresas especializadas em

desenvolvimento de jogos) na disputa por este mercado. No Brasil, este mercado movimenta

anualmente R$120 milhoes, o que justifica um crescimento acentuado na comunidade de desen-

volvimento de jogos brasileira (JOGOS. . ., 2004) e o surgimento de cursos focados emGame

Design.

A producao de um softwaree uma atividade complexa, especialmente quando nos referi-

mos a jogos, pois seu projetoe multidisciplinar, demandando especialistas de diversas subareas

da computacao como redes, sistemas distribuıdos, computacao grafica, inteligencia artificial,

processamento deaudio, realidade virtual entre outras. Dependendo do genero do jogo a ser

criado, podem exister tambem intersecoes com outrasareas (design grafico, matematica, fısica,

historia...) e com outros domınios.

A principal preocupacao no desenvolvimento de um jogoe sua qualidade. Uma das formas

de se medir a qualidade de um softwaree segundo o atendimento de seus requisitos funcionais e

nao-funcionais ao longo de seu ciclo de vida (PRESSMAN, 2005). Muitos destes requisitos sao

identificados apos umaanalise do domınio do problema, onde alguns requisitos do domınio de

jogos comousabilidadesao considerados ainda mais crıticos que de softwares convencionais.

Segundo Ian Somerville (SOMERVILLE, 2003), neste seculo, a Engenharia de Software

enfrenta tres desafios principais:

� Manutencao e atualizacao deSistemas legadosde forma economicamente viavel e garan-

tindo a entrega dos servicos prestados por estes sistemas.

� Desenvolvimento de software confiavel e flexıvel o bastante para ser bem-sucedido num

ambiente computacional heterogeneo.

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

11

plexidade deste.

Felizmente, surgiram asMetodologiasAgeis (COCKBURN, 2002) que focam justamente na

solucao desteultimo ponto.

Uma das principais metodologiasageise eXtreme Programming(XP) (BECK, 2000) que

defende a aplicacao extrema de boas praticas de desenvolvimento, focando mais o software em

funcionamento do que documentacao abrangente. Esta metodologia apresenta algumas carac-

terısticas peculiares como a programacao em pares, e desde seu surgimento tem sido bastante

utilizada pela industria internacional de software.

No Brasil,eXtreme Programmingtem demonstrado boa adaptacao no desenvolvimento de

jogos (VALADARES, 2003) em contraste com processos de software tradicionais. Pela primeira

vez, as empresas de jogos estao associando as questoes de qualidade do produtoa Engenharia

de Software, sendo que ate 2003, frequentemente as atividades de programacao eram feitas por

profissionais de outrasareas, que obviamente nao tinham conhecimento adequado naarea.

A producao de modelose frequentemente usada em diversas etapas da producao de um

softwaresegundo aEngenharia de Software, auxiliando a projetar o sistema, entender suas

partes componentes, a configuracao requerida do sistema, fatores relevantes para o problema e

capacidade de se suprir estes fatores.

Entretanto, quando nos referimos aMetodologiasAgeis, uma duvida crucial surge: sendo

XP uma metodologiaagil que prioriza mais um software desenvolvido do que documentacao

abrangente (BECK, 2000), comoe tratada amodelagem? O desenvolvimento deste projeto

tem a finalidade de auxiliar os desenvolvedores brasileiros de jogos a entenderemXPa partir de

uma observacao mais atenta sobre a importante atividade demodelagem, dismistificando alguns

mitos desta metodologia. De um modo geral, o trabalho tambem se propoe a indicar como a

modelagem emeXtreme Programmingdeve ser considerada, gerando um software de melhor

qualidade.

O capıtulo seguinte fara uma introducao sobre asMetodologiasAgeisde modo geral. Os

capıtulos 3 e 4 introduzirao conceitos-chave comoModelagemAgil e Projeto de Jogosatraves

da explanacao sobre o domınio de jogos e seu desenvolvimento peculiar. O capıtulo 5 apresen-

tara uma Analise sobreeXtreme Programmingesclarencendo alguns pontos obscuros de sua

aplicacao. Depois a abordagem seguida para o topico de pesquisa sera descrita no capıtulo 6 e

o estudo de caso utilizado, no capıtulo 7. Por fim, uma breve analise e conclusoes no capıtulo

8.

12

2 METODOLOGIAS AGEIS

Este trabalho relata a atividade de modelagem na metodologiaeXtreme Programming, no

domınio de de jogos. ComoXP e aModelagemAgil sao metodologiasageis, esse capıtulo e

dedicadoa introducao dos conceitos que envolvem asmetodologiasageis, abordando tambem

o contexto do surgimento deste novo paradigma naEngenharia de Software.

2.1 CONTEXTO DAS MUDANCAS

De uma maneira geral, pode-se afirmar que os projetos de desenvolvimento de software

tem sido de preocupacao constante para clientes do sistema (stakeholders), gerentes de projeto

e para os proprios desenvolvedores. Adiamentos nos prazos de entrega do produto, longas

fases de analise de requisitos, estouro no orcamento do projeto, fases de testes insuficientes,

cancelamento de projetos, produtos com alta taxa de defeitos e requisitos que nao satisfazem as

necessidades reais dos clientes sao apenas alguns exemplos que servem para ilustrar a gravidade

dos problemas encontrados durante o desenvolvimento de software ate hoje. Tal cenario pode

ser descrito como umacrise.

Para lidar com estaCrise do software, inumeros profissionais de computacao estabeleceram

praticas e princıpios baseados na Engenharia para a producao de software confiavel e funcio-

nalmente eficiente, reforcando o conceito deEngenharia de Softwaree do consequente uso da

metafora daEngenharia Civil para as atividades de desenvolvimento desoftware. Entretanto,

30 anos apos a definicao e aplicacao dosparadigmas da Engenharia de Software, ainda se

vive estacrise.

Segundo (PRESSMAN, 2005), “Crise seria um ponto decisivo no curso de algo(...). Con-

tudo, para o sofware, nao tem havido nenhum ’ponto decisivo’ (...) temos tido uma ’crise’ que

nos acompanha ha quase 30 anos, e essae uma contradicao em termos”. Paradigmas como o

ciclo de vida classicodeveriam ter posto fim a varios problemas de desenvolvimento de soft-

ware, ja que proviam fases ordenadas e bem definidas como: Engenharia de Sistemas, Analise

13

de Requisitos, Projeto de Software, Codificacao, Testes e Manutencao.

Verifica-se que durante ociclo de vida classico, 60% dos custos sao de desenvolvimento

e 40% sao de testes, sendo que para softwares customizados, os custos de evolucao excedem

os de desenvolvimento (SOMERVILLE, 2003). De fato, os custos de mudancas do software se

elevam na proporcao de 60 a 100 vezes durante fases finais, no ciclo de vida classico, como a de

manutencao. Porem, este fato apenas reforca a contradicao citada por Pressman, ja que o longo

planejamento inicial era feito para evitar custos futuros.

Porem com o surgimento de novas tecnologias de desenvolvimento como asferramentas

de quarta-geracao, novas tecnicas de programacao e deEngenharia de Software(orientacao

a aspectos , desenvolvimento orientado a testes, refatoracao, padroes de projeto entre outros)

, podemos verificar que os custos de manutencao podem ser considerados menores segundo a

figura 1.

Figura 1: Custos de manutencao. (BECK, 2000)

Voltando a questao daEngenharia de Software, a reducao dos custos de manutencao reforca

a duvida: Por que nao e possıvel a entrega de softwareutil de qualidade e com eficiencia?

Com a evolucao das ferramentas e metodos, o problema provavelmente reside nas pessoas,

ou melhor, no lado humano do processo de software. Em fevereiro de 2001, em Uthan, um

grupo inicial de 17 metodologistas analisou a questao e formando aAgile Software Development

Alliance(ALLIANCE , 2001) ou somenteAgile Alliance, definiram ummanifestopara encorajar

melhores meios de desenvolvimento desoftware.

2.2 MANIFESTO AGIL

Estemanifestotem como principais motivacoes: o rompimentoas resistencias aos proces-

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, refletindo as necessidades do

cliente e minimizando os riscos de fracasso do projeto.

O ManifestoAgil e definido pelas simples declaracoes de valores que definem preferencias,

nao alternativas, encorajando o enfoque de certasareas, mas sem eliminar outras (AMBLER,

2004). Sao elas:

� Indiv ıduos 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 nestemanifesto, a Agile Alliancedefiniu um conjunto deprincıpios que sao

seguidos nos processos de desenvolvimentoagil desoftware.

2.2.1 PRINCIPIOS

� A maior prioridadee a satisfacao do cliente atraves da entrega rapida e contınua de soft-

wareutil.

� 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 frequente, em poucas semanas ou meses, mas sempre

preferindo a menor escala.

� Pessoas que entendem o negocio e desenvolvedores devem trabalhar juntos diariamente.

� Construa projetos com pessoas motivadas, dando todo o suporte necessario a elas e

confianca.

� O metodo mais eficiente e eficaz de entregar/disseminar a informacao em uma equipe de

desenvolvimentoe a conversa frente-a-frente.

� Software em funcionamento deve ser a metrica de progresso.

� Processosageis promovem substancialmente o desenvolvimento. Clientes, desenvolve-

dores e usuarios deveriam ser capazes de manter a paz indefinidamente

15

� Atencao contınua 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 refletir sobre como podem ser mais efetivos, entao

devem ajustar seu comportamento de acordo com isso.

As metodologiasageisdevem se adequar a tais princıpios ou correm o risco de nao per-

tencer a tal classificacao. Ate entao, muitas metodologias novas eram rıgidas como aPersonal

Software Process. As metodologiasageisvieram romper com esta logica, ja que sao metodolo-

gias baseadas no comportamento humano natural.

Entretanto, as principaismetodologiasageiscomoeXtreme Programming, Crystal Clear

(COCKBURN, 2002),Dynamic System Development Method(CONSORTIUM, 1994) eFeature

Driven-Development(NEBULON, 2002) entre outras surgiram antes doManifestoAgil. Ali as,

alguns autores destas metodologias fizeram parte do grupo inicial que deu origema Agile Al-

liance e os princıpios que norteiam asmetodologiasageis foram extraıdos das experiencias

praticas destes autores com suas metodologias.

2.3 O PONTO-CHAVE

Na realidade, osvalorese princıpiosdaAgile Alliancenao explicitam o que podemos con-

siderar como o ponto-chave dasmetodologiasageis: a comunicacao. As metodologiasageis

sugerem sutilmente o fim da metafora da Engenharia Civil em prol dojogo cooperativo, comuni-

cativo e inventivo com recursos limitadosou simplesmentejogo 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 proxima jogada como objetivo secundario.

Assim, esta nova definicao se aproxima mais do domınio 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 ate um pontosuficienteao proposito de encaminhar a tarefa

a proxima pessoa.

16

No exemplo, da figura 2, a equipe de desenvolvimento do projeto(A) nao trabalha com

metodologiasageisenquanto 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 abordagemagil: (A) e (B)

Para asMetodologiasAgeiso desenvolvimento desoftwarenao deve ser considerado um

jogo plug&play ou posicional. Istoe, quando se substitui ou adiciona-se novas pessoas a um

projeto, estas podem nao conseguir descobrir pela documentacao o estado em que o desenvolvi-

mento se encontra, porqueas pessoas possuem comportamentos diferentes e nao reagem como

funcoes lineares(COCKBURN, 2002).

Desta forma, a comunicacao e considerado um fator tao crucial para o projeto que muitas

MetodologiasAgeisdelimitam inclusive o ambiente de desenvolvimento. Em (COCKBURN,

2002), Alistar Cockburn apresenta o conceito deerg-secondscomo uma unidade usada para

medir a quantidade de energia gasta para mover uma ideia de uma mente para a outra. Ele

usa a metafora de dispersao de gas como exemplo para demonstrar a dispersao da informacao

em um ambiente de trabalho e afirmando que o layout deste deve ser favoravel para uma boa

comunicacao entre as pessoas da equipe (comunicacao osmotica).

2.4 EXEMPLOS

Em comparacao ao desenvolvimento tradicional de software, odesenvolvimentoagil e me-

nos “orientado-a-documentos” e mais “orientado-a-codigo”. Porem, sendo isto um reflexo de

duas diferencas mais profundas entre os dois estilos: Metodosageis saomais adaptativosque

preditivos, acolhendo bem as mudancas e mais “orientado-a-pessoas”, confiando mais em ha-

bilidades, competencia e colaboracao, que “orientado-a-processos” (PAETSCH, 2003). Abaixo

uma descricao de algumasmetodologiasageis.

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 praticas simples, com feedback suficiente para que todos

saibam onde estao no desenvolvimento. Mais sobreXPsera discutido no capıtulo 5.

� ModelagemAgil (AMBLER, 2004): tem seu foco em um conjunto de basicos e suple-

mentares princıpios e praticas de modelagem. AModelagemAgil e inspirada emXP,

pontuando que as mudancas no desenvolvimento de software sao comuns e devem afetar

a forma de desenvolvimento, e por extensao, a forma de modelar. Mais sobreModelagem

Agil sera discutido no capıtulo 3.

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

sistemas, aplicando ideias da teoria de controle de processos industriais como flexibili-

dade, adaptabilidade e produtividade. Scrum nao propoe nenhuma tecnica particular de

implementacao, focando em como uma equipe deve trabalhar junta para produzir trabalho

de qualidade em ambientes de mudanca.

� Crystal Methodologies (COCKBURN, 2002): sao uma famılia de diferentes metodo-

logias. Alistair Cockburn, seu desenvolvedor, acredita que para cada tipo diferente de

projeto deva existir uma metodologia que se adeque mais. As metodologias estao inde-

xadas por diferentes cores para indicar sua “dureza” (metrica originada do “tamanho” do

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) nao recomenda um modelo de processo especıfico. FDD consiste de

cinco processos sequenciais:

– 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 rapido de aplicacoes.Dynamic System Development Method(DSDM)

consiste de cinco fases, e suas iteracoes sao denominadastime boxes, que duram entre

poucos dias ou semanas.

18

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

para o desenvolvimento de sistemas grandes e complexos com coordenacao suficiente que

evite caos no projeto. Seus princıpios veem de pesquisa em desenvolvimento iterativo,

encorajando tal tipo de desenvolvimento com o a contrucao de prototipagem constante.

O processo ASD contem tres fases nao-lineares e sobrepostas: especulacao, colaboracao

e aprendizagem (PAETSCH, 2003).

19

3 MODELAGEM AGIL

A ModelagemAgil e uma metodologiaagil baseada na pratica para modelagem e documentacao

eficazes de sistemas baseados emsoftware. Elae um conjunto de praticas guiado por princıpios

(derivados dos princıpios daAgile Alliance) e valores para desenvolvedores aplicarem no seu

dia-a-dia, fornecendo conselhos sobre como ser um modelador eficiente (AMBLER, 2004), fo-

cando no desenvolvedor medio.

A ModelagemAgil naoe um processo prescritivo, em vez disso,e independente de outros

processos desoftware, mesclando o “caos” de praticas simples de modelagem com a ordem

inerente a artefatos de modelagem desoftware, num processo “caordico”. Ela nao se refere

a nenhuma tecnica de Engenharia de Requisitos (ER), mas suas praticas dao suporte a varias

tecnicas ER (PAETSCH, 2003).

Para aplicarModelagemAgil deve-se considerar que ha duas razoes basicas para modelar:

para entender o que se esta construindo ou para melhorar a comunicacao, seja dentro da equipe

ou com os clientes do projeto. Assim, sua definicao segue tres objetivos:

� Definir e mostrar como colocar em pratica um conjunto de valores, princıpios e praticas

relativas a uma modelagem eficaz e leve. O que torna amodelagemagil uma catalisadora

de melhoriase como aplicar as tecnicas de modelagem e nao as tecnicas em si.

� Lidar com a questao de como aplicar tecnicas de modelagem em projetos desoftware

adotando uma perspectivaagil.

� Discutir como melhorar as atividades de modelagem adotando uma perspectiva “quase

agil” mesmo para uma equipe que esteja adotando processos nao-ageis como Rational

Unified Process (RUP).

20

3.1 DEFINICOES GERAIS

Para um melhor entendimento sobre o quee umaModelagemAgil Scott Ambler (AMBLER,

2004) define alguns topicos como:

� Modeladoresageis: qualquer pessoa que siga aModelagemAgil.

� Modelos ageis: sao modelos “bons o suficiente”. Istoe, eles: cumprem com o seu

proposito (seja compreensao do problema ou comunicacao); sao suficientementecom-

preensıveis, precisos, consistentes e detalhados; proporcionam valor positivo (os recursos

gastos na construcao do modelo sao menores que o retorno ao projeto); e sao os mais

simples possıveis.

Desta forma, aModelagemAgil e uma especie de “atitude”, um suplemento dos metodos

pre-existentes, complementar aos processos de modelagem, eficaz, eficiente e deve ser feita em

equipe. Analogamente, a MA nao e um processo prescritivo, nem uma metodologia completa,

nem uma “bala-de-prata”, nao elimina a criacao de documentacao e nem o uso de ferramentas

CASE.

3.2 VALORES

Assim comeXtreme Programming, aModelagemAgil tambem usa a ideia de valores para

contruir uma base para a metodologia. AModelagemAgil foi inspirada emXP possuindo

muitos conceitos similares ou equivalentes. De fato, dos cinco valores da MA, apenas um

diverge dos valores deXP. E importante lembrar que a existencia dos valores dasmetodologias

ageisnao e por simples retorica, mas para provocar nos desenvolvedores um envolvimento

filosofico sobre novas formas de projetar e desenvolversoftware. Portanto, os valores da MA

sao:

� Comunicacao: e uma via de mao dupla onde ambas fornecem e obtem informacoes

como resultado. A comunicacaoe fundamental para uma modelagem. Seja para informar

o estado de tarefas, de projetos, ideias de modelagem, requisitos ou prioridades, elae

e um requisito para o sucesso do desenvolvimento de software. Segundo Ambler, “os

problemas ocorrem quando ela termina”. Outros detalhes da importancia da comunicacao

para asMetodologiasAgeisforam discutidos em 2.3.

21

� Simplicidade: e a arte de maximizar a quantidade de trabalha a nao ser feito.E um valor

diretamente ligadoa regra KISS (Keep It Simple Stupid - Matenha Isto Simples, Idiota).

A simplicidade pode ser conquistada, ao se evitar: aplicarpadroescomplexos cedo de-

mais; criar arquiteturas em excesso para suportar requisitos futuros; ou desenvolver uma

infra-estrutura complexa.

� Feedback: e ounico modo de determinar se o trabalho (em qualquer nıvel, incluındo os

modelos) esta correto, atraves de algumas formas: desenvolva o modelo em equipe; re-

vise o modelo com seu publico-alvo; implemente o modelo; e execute testes de aceitacao.

Quanto mais rapido for o retorno, menor a possibilidade do modelo desviar-se das neces-

sidades reais e maior a aprendizagem sobre a modelagem executada.

� Coragem: significa ser aberto a mudancas; trabalhar em equipe, confiando nas pessoas e

em seu proprio trabalho. Separar as decisoes tecnicas para a equipe tecnica e as decisoes

de negocios para o pessoal de negociose ter coragem.E necessario coragem para validar

modelos com codigo, para reconhecer erros e confiar que podera superar no futuro os

problemas que surgirao.

� Humildade: significa que todos devem aprender com todos, nao existindo “donos da

verdade”. A melhor forma de aprender,e admitir quee preciso a ajuda de outra pessoa

para realizar bem o seu trabalho. Istoe uma premissa para um bom trabalho em equipe,

e por extensao, um bom desenvolvimento desoftware.

3.3 PRINCIPIOS

Os valores sao definicoes muito abstratas para serem colocadas em pratica. Por isso,

tambem sao definidos princıpios basicos e suplementares daModelagemAgil conceitos muito

mais concretos. NaModelagemAgil os princıpios basicos devem ser adotados integralmente

para se afirmar que se esta “modelando com agilidade”. Ja os suplementares, apoiam os basicos,

definindo conceitos importantes que ajudam a melhorar a eficiencia no trabalho de modelagem.

Seus principaisprinc ıpios basicossao:

1. Lembre-se que osoftwaree o objetivo principal: e efetivamente uma nova expressao do

princıpio daAgile Alliance, “o software funcionandoe a principal medida de progresso”.

Criar documentacao irrelevante pode trazer algum tipo de falso conforto, levando a se

acreditar que esta havendo progresso, enquanto na verdade nao esta.

22

2. Saiba que possibilitar o proximo trabalho e o seu objetivo secundario: e desejavel

nao so desenvolver umsoftwarede qualidade, mas tambem uma documentacao suficiente

para que as pessoas que jogarao a “proxima partida” possam faze-lo de forma eficiente,

transferir habilidades de seus desenvolvedores para outros, motivar a equipe ja existente

a permanecer no projeto ou na empresa.

3. Diminua a carga de trabalho: a documentacao e os modelos criados devem ser sufici-

entes para se ir adiante, sem perda de tempo, diminuindo assim a carga de trabalho. Cada

artefato mantido no projeto devera receber algum tipo de manutencao. Isto inclui docu-

mentos, modelos e artefatos de gerenciamento do projeto, como cronogramas, conjuntos

de teste e codigo-fonte por exemplo. Quanto maior o numero de artefatos mantidos,

maior a possibilidade de que seja difıcil efetivar uma mudanca. De forma semelhante

ocorre com a complexidade e detalhamento dos modelos mantidos. A diminuicao de

carga possibilita a simplicidade da estrategia de desenvolvimento porque o trabalho de

manutencao de artefatos diminuira drasticamente.

4. Adote a Simplicidade: a solucao mais simples funciona bem e, por ser simples,e facil de

implementar, de manter e de melhorar. Nao modele em excesso seu sistema hoje, modele

baseado nos requisitos existentes atualmente e refaca seu trabalho no futuroa medida que

os requisitos evoluırem. Nao e garantido que sempre as solucoes mais simples funcio-

narao, mas os recursos gastos anteriormente com uma solucao simples nao prejudicara

tanto quando elas falharem, servindo de aprendizagem.

5. Encapsule a mudanca: os modeladoresageis nao culpam os clientes quando estes tra-

zem as mudancas, pois entendem que elas ocorrem naturalmente nos projetos. Por isso,

os modeladoresageis trabalham ativamente com os clientes para entender e comunicar as

consequencias dessas mudancas e para permitir que tomem decisoes eficazes, por exem-

plo, ‘se’, ‘como’ e ‘quando’ a mudanca sera contemplada pelo trabalho de desenvolvi-

mento. Compreender os requisitos ao maximo no momentoe sempre um bom conselho

que naoe abandonado pelos modeladoresageis.

6. Mude incrementalmente: para encapsular a mudanca, uma estrategia incremental no

trabalho de desenvolvimentoe necessaria, assim como mudar pequenas partes do sistema

de cada vez.E possıvel executar uma grande alteracao como uma serie de pequenas

mudancas incrementais.E necessario aceitar e ter humildade de que pode-se nao acertar

da primeira vez.

23

7. Modele com um proposito: ou se nao for possıvel identificar a razao e o publico-alvo

de um modelo, a tarefa de cria-lo deve ser questionada. Nao se deve modelar apenas pela

satisfacao pessoal de modelar, mas para satisfazer as necessidades dos clientes. Existem

inumeros outros motivos invalidos para se criar um modelo: por exigencia de um processo

prescritivo apenas; solicitacao de terceiros que nao conseguem explicar a razao disto;

ou criar um modelo para comunicar algo a alguem, sendo que existe a possibilidade de

conversar com a pessoa e tambem a opcao de faze-lo ou nao.

8. Tenha mais de um modelo: considerando que deve-se modelar para entender ou para

comunicar, entao deve-se observar que cada artefato tem seus pontos fortes e fracos, cada

um e apropriado para determinada situacao. Como osoftwaremodernoe complexo,

nenhum artefato sozinho, nem no caso da famılia de artefatos UML,e aplicavel a todas

as situacoes. Deve-se usar os modelos segundo os seus pontos fortes para se conseguir

representar o sistema adequadamente. Scott Ambler afirma que omodeladoragil deve

possuir umacaixa de ferramentas intelectual, istoe, ele deve conhecer e aplicar uma boa

variedade de artefatos, assim seu trabalho sera mais eficiente.

9. Incentive o trabalho de qualidade: e uma premissa basica para desenvolvimento de

softwarede forma geral. Desta forma, osdesenvolvedoresageiscompreendem que devem

investir na criacao de artefatos permanentes, como o codigo-fonte, a documentacao de

usuario e adocumentacao tecnica do sistema. Da mesma forma, eles nao investem muito

tempo em artefatos que pretendem descartar como esbocos ou artefatos de pouca precisao.

10. Feedback rapido: e um dos cinco valores. Elee tao direto que nao necessita de um

princıpio para concretiza-lo. O retorno rapido e importante pois cometem-se a maior

parte dos erros nos inıcio do desenvolvimento e o custo de correcao de defeitos aumenta

com o tempo do ciclo de desenvolvimento.

11. Maximize o retorno que seus clientes obterao: logo a decisao de documentar o sistema

e uma decisao de negocio, nao uma decisao tecnica.

Os principaisprinc ıpios suplementaresdamodelagemagil sao:

1. O conteudoe mais importante que a forma: Isto e, o mais importantee o que se pretende

comunicar com o modelo ao inves de se preocupar com o embelezamento e formalidades

deste. A preocupacao com a formalidade deve ser de acordo com o publico-alvo do

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 praticas que mais concretizam bem o valor

“Humildade” daModelagemAgil. Trabalhar com outrose uma boa oportunidade de

aprender e de tentar novas maneiras de se fazer algo (PAETSCH, 2003).

3. Conheca seus modelos: O modeladoragil deve aperfeicoar a sua “caixa de ferramentas

intelectual”, conhecendo os pontos fortes e fracos de tipos de artefatos para sua propria

aprendizagem. Este princıpio e suplementar ao“Tenha mais de um modelo”.

4. Adaptacao local: Para contextos e pessoas diferentes com culturas diferentes,e bem

provavel que uma adaptacao local para o uso de princıpios e praticas seja mais eficaz para

a aplicacao daModelagemAgil.

5. Comunicacao aberta e honesta: Deve ser o objetivo de todos, principalmente dosmo-

deladoresageis, pois isto melhora ofeedbacke prove mais confiancasas decisoes que

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 fixar atividades e o cronograma do projeto, transparecendo uma visao geral do

projeto para todos os envolvidos (COCKBURN, 2002).

6. Trabalhe com o instinto das pessoas: Este princıpio deve ser levado em consideracao, por

exemplo, quando omodeladoragil se encontrar em uma situacao de duvida entre duas

ou mais solucoes onde nao existam motivos convincentes para escolher entre uma delas.

Geralmente as pessoas relacionam incoscientemente metricas baseadas em experiencias

para se ter a impressao de algo.

3.4 PRATICAS

As praticas sao divididas em dois grupos:basicasesuplementares. Assim como os princıpios

basicas, as praticas devem ser seguidas integralmente.

3.4.1 BASICAS

As praticas basicas estao divididas em quatro categorias:

� Modelagem iterativa e incremental:

1. Aplique os artefatos corretos: Cada artefato tem uma aplicacao especıfica onde

elee mais valioso. Por exemplo, a representacao de uma estrutura estatica de banco

25

de dadose melhor representada por um modelo fısico de dados ao inves de qualquer

outro diagrama UML.

2. Crie diversos modelos em paralelo: Como cada artefato possui pontos positivos

e negativos, nenhume suficiente para todas as necessidades de modelagem. Deste

modo,as sessoes de “um so artefato” nao sao recomendadas.

3. Itere em outro artefato: Geralmente podem ocorrer situacoes onde a modelagem

usando um certo artefato nao gera o resultado desejado (ou nenhum resultado),

isto e, o processo de modelagem e o modelo em si nao ajudaram no entendimento

ou comunicacao do problema. Nestes casos, considere iterar (repetir o processo)

em outro tipo de artefato para modelar o mesmo problema. De uma maneira fi-

losofica, esta pratica e uma analogiaa refactoringem XP, onde se busca simpli-

ficar a abstracao e consequente entendimento do problema modelado. Desde a

documentacao inicial da UML, existe a indicacao de se iterar entre artefatos, por

exemplo, na fase de Analise do Domınio do Problemae indicada uma iteracao entre

use caseemodelo de objeto(COPE, 2001).

4. Modele incrementalmente: “Deixe um problema futuro para o futuro” (para a

proxima semana, por exemplo). Organize o seu trabalho mais abrangente em par-

tes menores (semanas ou meses), modelando incrementalmente. Assim as sessoes

de modelagem (explicadas na secao 3.4.5) deverao durar de 10 a 20 minutos ou no

maximo poucos dias.

� Trabalho de equipe:

1. Modele com outras pessoas: A participacao de varias pessoas ajuda a desenvolver

uma visao compartilhada em relacao ao projeto, alem de pre-validar o modelo.

2. Organize uma participacao ativa do cliente: E uma extensao da praticaXP “Cli-

ente sempre no local”. No caso, organize a participacao dosstakeholderstambem

na modelagem.

3. Promova a posse coletiva: Desenvolva o modelo em publico e ganhe rapido fe-

edback. Estae uma boa pratica pois permite uma aprendizagem coletiva (“Todos

podem aprender com todos”).

4. Mostre os modelos publicamente: Esta pratica suporta o princıpio “Comunicacao

aberta e honesta”. Use paginas web ou paredes de preferencia por serem mais

acessıveis e simples.

� Simplicidade:

26

1. Crie conteudo simples: Para aplicar esta pratica, e necessario ter em mente tres

perguntas:

– O modelo comunica tudo que se voce pretende comunicar?

– O modelo nao contem informacao duplicada?

– O modelo tem a menor quantidade de elementos possıveis?

2. Mostre seus modelos de forma simples: E suficiente mostrar as caracterısticas

principais que se esta desejando entender. Durante a modelagem, evite: cruzamento

de linhas, linhas curvas, linhas diagonais, baloes de tamanhos diferentes, detalhes

desnecessarios e baloes demais (nao maior que 7 com variacao de 2 baloes).

3. Use as ferramentas mais simples: Quando se modela com a intencao de entender

o problema, as ferramentas usadas podem ser as mais simples possıveis, poise no

raciocınio para criar o modelo que reside a funcao da tarefa. Esta pratica nao e

contra ferramentas CASE,e que apenas existem poucas ferramentas praticas que

permitem modelar com facilidade. Como exemplos de ferramentas simples, temos

flip-charts, cartoes deındice, papel e caneta.

� Validacao:

1. Considere a testabilidade: Se uma equipe nao puder testar um software, entao ela

nao deve construı-lo.

2. Comprove com codigo: Esta pratica se resume a “modelar um pouco e codificar”,

quee uma atividade diferente a “criar um modelo, revisa-lo, retrabalhar nele e de-

pois codificar”. Esta pratica funciona melhor quando as pessoas que executam a

modelagem sao as mesmas responsaveis pelo codigo. Como exemplo podemos ter

a validacao de interfaces com codigo HTML, e a de diagramas UML de atividades

poderiam ser validados atraves de algum codigo de teste e de negocios.

3.4.2 SUPLEMENTARES

Assim como as praticas basicas, as praticas suplementares tambem estao divididas em ca-

tegorias:

� Produtividade:

1. Aplique as convencoes da modelagem: Assim como emeXtreme Programming,

estabeleca convencoes de modelagem com sua equipe no inıcio do projeto e procure

27

usar padroes reconhecidos como UML. Lembrando que a UML nao e completa e

sera necessario usar outros tipos de artefatos tambem.

2. Utilize os padroes com moderacao: Sejam padroes de projeto, arquiteturais ou de

analise, procure aplica-los com moderacao, de forma a implementa-los minima-

mente de acordo com a funcionalidade necessaria, e de forma facil de refaze-los

mais tarde.

3. Reuse os recursos ja existentes: E importante que se tenha a disposicao um repo-

sitorio de modelos para reuso como produtos de trabalho de projetos antigos. Deve-

se procurar reusar desde padroes de projeto ou analise, a modelos de requisitos,

frameworkse templatesde documentos.

� Documentacao:

1. Descarte os modelos temporarios: A maioria dos modelos criados durante o de-

senvolvimento de um projeto sao temporarios e podem ser descartado apos terem

cumprido o seu papel. Descartar modelose uma boa pratica, pois eles se tornam

rapidamente inconsistentes com o codigo e entre si. Philippe Kruchten em (KRU-

CHTEN, 2005) considera esta inconsistencia um dos obstaculos para o desenvolvi-

mento daEngenharia de SoftwarePorem segundo esta pratica sugerida por Ambler,

este problemae “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 necessario. Como esta manutencao e

prevista, o uso de uma ferramenta eletronicae aconselhavel.

3. Atualize apenas quando necessario: Deve-se atualizar um modelo, quando sua

desatualizacao causar mais transtornos que o trabalho de atualizacao. Ja que a

producao desoftwaree o principal objetivo, nao faz sentido gastar recursos para

manter artefatos em sincronia desnecessariamente. A melhor forma de assegurar

que duas equipes de desenvolvimento estejam desenvolvendo a mesma visao nao

e ter documentos e modelos consistentes, e sim, permitir que estes grupos se co-

muniquem de forma eficaz, colaborando entre si na definicao e criacao da visao

compartilhada.

� Motivacao:

1. Modele para entender: Para entender o espaco-problema, identificar e analisar re-

quisitos.

28

2. Modele para comunicar: Modelos encorajam e suportam a comunicacao. Um efeito

desta praticae que ela ajuda a contruir um vocabulario comum dentro da equipe e

com os clientes de seu projeto.

3.4.3 MODELAGEM AGIL NA PR ATICA

As praticas daModelagemAgil sao sinergicas: se apoiam e muitas vezes habilitam umasas

outras. Elas sao “caordicas”, definindo harmoniosamente ordem e caos. A figura 3 exibe uma

maneira de visualizar os relacionamentos entre os grupos de praticas citados.

Figura 3: Relacionamento entre as praticas MA

A aplicacao daModelagemAgil, envolve uma mudanca cultural, onde conceitos antigos e

“erroneos” sao descartados e novos sao introduzidos. Porem, caracterısticas como valores sao

quase as mais difıceis de se modificar dentro das organizacoes. Por isso, Ambler defende que

deve-se preparar o ambiente para a aplicacao demetodologiasageis, atraves da criacao de uma

cultura agil.

3.4.4 CRIACAO DE UMA CULTURA AGIL

A mudanca culturale sempre mais facil em equipes pequenas ou iniciantes. Para se aplicar

aModelagemAgil alguns pontos devem ser esclarecidos logo de inıcio:

� Modelos sao maisuteis que documentos.E durante a criacao de um modelo que se

agrega valor ao trabalho, pois esta tarefa permite validar ideias, aumentar a comunicacao

29

e o aprendizado. A modelagem pode ser simples ou mais complexa a depender do que se

escolhe. Entretanto, nem todos os desenvolvedore estao habilitados para modelar.

� 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 umsoftwarede qualidade. Desta forma,e simples verificar que

nao se consegue prever tudo desde o inıcio. Mudancas em projeto devem fazer parte do

“jogo”, inclusive para o aperfeicoamento desse.

� Apesar da modelagem ser muitas vezes uma tarefa complexa, uma ferramenta CASE so

e necessaria quando existe uma necessidade real para usa-la.

Se “pequeno”e agil, entao deve-se preferir “pensar pequeno”. Istoe:

� faca sessoes curtas (pequenas) de modelagem, focalizando em poucas funcionalidades

por vez;

� tenha preferencia por equipes pequenas, simplificando 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 sessao de modelageme uma atividade na qual diversas pessoas focalizam um ou mais

modelos (AMBLER, 2004). Assessoes de modelagemagil variam de de alguns minutos a

poucos dias.E provavel que as longas sessoes se situem no inıcio do projeto, onde ha grande

necessidade de definicao do escopo, estabelecimento de requisitos iniciais e identificacao de um

arquitetura candidata.

As “sessoes de modelagem de umunico artefato” sao consideradas anti-padrao, pois sao

uma forma muito restrita de representar seu sistema. Assim outros tipos de sessoes devem ser

consideradas: como

� Sessao de modelagem de fases: Criacao de modelos relacionadosas fases mais impor-

tantes do desenvolvimento (requisitos, analise, arquitetura e projeto).

� Sessao de ModelagemAgil : Na ModelagemAgil, uma flexibilidade adicionale que se

itere entre as fases, produzindo versoes mais maduras durante o desenvolvimento itera-

tivo. Mesmo as sessoes formais podem se tornarageis.

30

Assim, os participantes de umaSessao de ModelagemAgil se dividem em dois grupos:

� Ativos: stakeholders, analistas (geralmente analistas de requisitos ou negocios) e desen-

volvedores (que trabalham nos modelos).

� De apoio: facilitador (responsavel pelo planejamento e orientacao durante as sessoes),

escrivao, e observador(es).

3.4.6 USANDO AS FERRAMENTAS MAIS SIMPLES

Dando suporte ao princıpio “Use as ferramentas mais simples”, quadros e marcadores

apresentam-se como boas alternativas se o modelo a ser criado for logo descartado. Tambem

deve-se tentar balancear o uso de ferramentas CASE com ferramentas simples, desde que seja

util usar uma ferramenta CASE para gerar codigo a partir de um modelo por exemplo.

Eventualmente, as ferramentas simples (cartoes deındice, quadros, post-its, linhas) preci-

sarao de algum suporte tecnologico como cameras, software de edicao de imagens, HTML etc.

Por exemplo, se se deseja documentar um prototipo deinterface com o usuario essencial feito

num flip-chart, uma camera digital pode ser uma solucao pratica (eagil).

3.4.7 DOCUMENTACAO AGIL

Levando-se em consideracao que alguns modelos evoluirao para a documentacao oficial

do sistema, o entendimento sobre este temae necessario para se reconhecer quando um mo-

delo deve ser tornar parte da documentacao. Um modelo temporario ira se tornar permanente

quando:

� Existe um motivo claro e importante para isto: seja para definir um modelo de contrato

ou apoiar a comunicacao com um grupo externo por exemplo.

� Existe um publico-alvo para o qual o modelo comunica algo importante.

� Se os clientes do projeto estao dispostos a dispensar recursos para que o modelo vire parte

da documentacao.

31

4 DOMINIO DE JOGOS

Cada problema (software) a ser modelado possui o seudomınio. E durante a Analise do

Domınio do problema que encontramos outrosrequisitos funcionaise nao-funcionaisnao-

detectados durante a Analise de Requisitos (PRESSMAN, 2005).

Sem a satisfacao dos requisitos de umsoftware, e difıcil afirmar que este possui qualidade.

E como a preocupacao com a qualidade desoftwaredeve comecar muito antes do codigo a ser

gerado, este capıtulo se propoe a elaborar um estudo sobre o Domınio de jogos, evidenciando

seus requisitos gerais.

4.1 DOMINIO DO PROBLEMA

As abstracoes do domınio do problema correspondem aos conceitos daarea de aplicacao do

problema, compreendendo suas caracterısticas e abrangencia. Pode-se afirmar que o domınio de

jogose relativamente extenso, apresentando pelo menos 50 termos (ART; GAMES, a). Para en-

tendermos o domınio de jogos,e necessario antes uma delimitacao sobre o conceito de “jogo”.

4.1.1 JOGOS

A atividade de jogo nao pode ser definida de forma exata em termos logicos, biologicos ou

esteticos, porem podemos tentar definı-la atraves de suas principais caracterısticas: apresentar

prazer e divertimento;e voluntaria, livre e representa a liberdade, apesar de possuir regras que

sao respeitadas religiosamente; ee uma evasao da vida real. As principais funcoes de um jogo

sao: disputa por algo ou representacao de algo (HUIZINGA , 2004). De fato, a caracterıstica

mais marcante de um jogoe sua separacao espacial em relacaoa vida cotidiana.

Segundo a definicao acima de “jogo”, nem todo softwaree um jogo, pois precisa possuir

tais caracterısticas principais. Porem todo jogo eletronicoe um software. E para a garantia da

qualidade destesoftware, deve-se verificar os requisitos que motivam seu desenvolvimento.

32

4.2 GENEROS

Existe muitas classificacoes de jogos, e muitas delas se contradizem, apresentando con-

fusao de forma, de conteudo, de publico-alvo e de contexto entre si. As distincoes de generos

apresentadas aqui sao construcoes analıticas somente, nao devendo ser analisadas segundo sua

veracidade, mas sim em sua adequacao. Elas serao baseadas emcriterios de sucesso(ART;

GAMES, b), istoe, em criterios que o jogador deve possuir para obter o sucesso.

� Jogos de acao: Criterios de sucesso: reflexos rapidos e habilidade de coordenacao.

Exemplos de subcategorias deste genero: jogos de plataforma, jogos de luta, jogos de

nave, jogos de carro e jogos de tiro.

� Jogos de aventura: Criterios de sucesso: pensamento logico e persistencia. Estes tipos

de jogos, geralmente, apresentam-se com um enredo trabalhado, passando uma ideia de

filme interativo. Exemplos de subcategorias deste genero: MUD (Multi-User Dungeon)

e MMORPG (Massive Multiplayer Online Role-Playing Games).

� Jogos de estrategia: Demandam habilidades analıticas e taticas coordenadas, balance-

ando a relacao entre recursos e varios elementos no jogo. Exemplos de subcategorias

deste genero: jogos baseados em turnos, jogos de estrategia de tempo-real, jogos empre-

sariais.

� Jogos de simulacao: Criterios de sucesso: dominar princıpios complexos que fazem

relacao direta com a realidade externa. Estes tipos de jogos se propoem a simular ex-

periencias concretas com alto grau de realismo. Exemplos de subcategorias deste genero:

jogos de simulacao de voo, jogos empresariais.

4.3 CARACTERISTICAS DO PRODUTO

A maioria dos jogos apresentam-se comoprodutos de uso geralorientados para um grande

numero de usuarios. Um software de uso geral tem seu desenvolvimento segundo uma especificacao

de requisitos mais abrangente possıvel. No domınio de jogos, os requisitos de qualidade para o

usuario sao relativos tanto aosoftwarequanto ao conteudo do jogo.

33

4.3.1 REQUISITOS FUNCIONAIS

Fatores de qualidade como usabilidade podem ser considerados requisitos funcionais, no

domınio de jogos. Usabilidade ouuser friendlinesse o esforco para aprender, operar, prepa-

rar a entrada e interpretar a saıda de um programa. Jogabilidadee um termo que deriva de

usabilidade, quando se trata de jogos, e consequentemente tambeme um requisito.

Os requisitos funcionais relativos ao conteudo sao subjetivos, existindo alguns consenso em

torno de:

� Graficos: e, de forma simplificada, relativoa toda a parte visual de um jogo: graficos,

modelos 3D e animacoes.

� Jogabilidade: esta normalmente relacionada ao controle dos personagens, movimentacao

de objetos pela tela, desafio, dentre outros (FINALBOSS.COM, 2005). Jogabilidade se

confunde com usabilidade, pois trata de assuntos relacionados a ergonomia, projeto de

interfaces e experiencia do usuario.

� Audio: e relativo a todas as musicas, efeitos sonoros e vozes (quando houver). Se as

musicas nao sao repetitivas, os efeitos sonoros sao condizentes com o estilo adotado pelo

game, e se as falas estao sincronizadas e bem interpretadas, a nota provavelmente sera

mais alta do que as dadas em um jogo que tenha um ou mais destes quesitos nao tao bem

elaborados.

� Fator Replay: ouReplayabilitye uma media relativa ao numero de vezes que um usuario

jogaria denovo sem “enjoar”. Existe uma relacao com todos os criterios acima, porem este

requisito depende tambem do tipo de jogo e seu enredo.

A criatividade (ou originalidade)e fator que influencia as avaliacoes sobre o audio, joga-

bilidade e graficos. De uma forma geral, a criatividade reflete a inovacao das ideias centrais do

jogo.

4.3.2 REQUISITOS NAO-FUNCIONAIS

Podemos citar diversos requisitos nao-funcionais para o domınio de jogos. Os principais

sao: confiabilidade, integridade, testabilidade, reusabilidade, corretude, eficiencia (operacional

por exemplo), manutenibilidade, flexibilidade, portabilidade e desempenho.

34

Como portabilidadee o esforco exigido para transferir o programa de um ambiente de sis-

tema de hardware e/ou software para outro, eventualmente, este fatore considerado um requisito

funcional exigido pelo proprio cliente.

4.4 DESENVOLVIMENTO DE JOGOS

A tabela 1 mostra na sequencia as principais fases de desenvolvimento de um jogo, podendo

ocorrer atividades em paralelo com diferentes focos de producao: uma nosoftware e outra no

conteudo.

FASES DE PRODUCAOSOFTWARE CONTEUDO

Definicao do escopo e Planejamento geralEngenharia de Requisitos Enredo

Analise Game DesignProjeto Arte, animacao e audio

DesenvolvimentoTestes de aceitacao Testes de jogabilidade

(Homologacao) BalanceamentoAjustes finais

Tabela 1: Fases de producao

Abaixo a descricao de algumas fases:

� Definicao do escopo e Planejamento geral: e a definicao geral do escopo e planeja-

mento dos recursos, pode incluir tambem atividades iniciais de emphGame Design(GD)

e pesquisa sobre as principais tecnologias necessarias para o projeto.

� Enredo: definicao de uma historia que envolva o jogador num mundo imaginario. Nem

todos os jogos possuem enredos.

� Balanceamento: e uma atividade que busca o equilıbrio entre os diferentes elementos do

jogo e o grau de dificuldade para o usuario. Sao feitas medicoes e ajustes para determinar

se a experiencia sera agradavel ou nao para o jogador.

Justamente por este processo ter fases com abordagens diferentes, surge a necessidade de

um profissional que tenha conhecimento em ambas as frentes de producao, que seja capaz de

35

fazer o planejamento geral do produto. Assim, a profissao de“game designer”surgiu da ne-

cessidade da industria de jogos e esta se tornando uma ciencia. Existindo cursos no Brasil, na

PUC-RIO, UNICENP, UNISINOS entre outras...

Level Designe uma atividade equivalente aoGame Designporem e especıfica para cada

“fase” ou “estagio” do jogo que foi previsto pelo projeto geral. Olevel designere responsavel

pela composicao coerente de fases, cenarios e paisagens. Em casos, onde o jogo tera varias

fases, uma abordagem iterativa de desenvolvimentoe indicada.

O gerenciamento do desenvolvimento de um jogoe uma atividade crıtica e muitas vezes

complexa. Como maneira de minimizar isto, a industria de jogos, produz ao final do ciclo de

vida de um jogo, um detalhado relatorio de avaliacao gerencial do projeto chamado depostmor-

tem(DEXTERITY, 1999).

O projeto de um jogo possui intersecao comareas de computacao heterogeneas como in-

teligencia artificial, redes, computacao grafica, sistemas distribuıdos, engenharia de software,

sistemas de tempo real, realidade virtual e processamento de audio.

A tabela 1 demonstrou que o desenvolvimento de jogos, nao envolve somente profissionais

daarea de computacao, mas tambem outras profissoes de mesma relevancia para o projeto. O

desenvolvimento de jogos possui interseccoes com as mais variadasareas: ergonomia, peda-

gogia, matematica, psicologia, fısica, telefonia movel, cinema, jornalismo, artes graficas, artes

plasticas, musica entre outras.

De modo generalizado, a producao de umgame, requer os seguintes profissionais (AHE-

ARN, 2001): programador com conhecimentos em inteligencia artificial, redes e banco de da-

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

fissionais podem ter mais de uma dessas habilidades ou pode-se inserir especialistas de outras

areas na equipe.

36

5 ANALISANDO EXTREME PROGRAMMING

Este capıtulo e dedicado a analisareXtreme Programmingsobre o ponto de vista da modela-

gem e de aplicacoes dessa metodologia. ComoXP e um tema bastante difundido, este trabalho

apenas apresenta um sucinto resumo. Outras informacoes sobreeXtreme Programmingpodem

ser encontradas em (COSTA, 2003) ou em (JEFFRIES, 2005).

5.1 RESUMO SOBRE XP

A Programacao Extremaou eXtreme Programming(XP) e umaMetodologiaAgil para pe-

quenas e medias equipes (com menos de 10 pessoas) de desenvolvimento frente a requisitos

vagos e em constante mudanca (BECK, 2000), que surgiu antes doManifestoAgil. O termo

extremequer dizer que esta metodologia leva princıpios e praticas de senso comum ao ex-

tremo. De fato, as praticas deXP, assim como das demaismetodologiasageis, requerem uma

“mudanca filosofica” na maneira de se desenvolver software, e quando aplicadas corretamente

e em conjunto produzem bons resultados.

XP e uma metodologia intensiva em atividades, prescrevendo o que os papeis executam

durante o dia (COCKBURN, 2002), focalizando na participacao do cliente juntoa equipe de

desenvolvimento, emTest Driven-Development, e emrefactoring(FOWLER et al., 2000). XP

pode ser classificada comoTest Driven-Developmentao focar bastante as atividades de teste,

descrevendo testes de unidade e testes funcionais como atividades determinantes para o prosse-

guimento do projeto.

Os quatro valores deXP sao: Comunicacao, Simplicidade, Feedbacke Coragem. As

praticas buscam aproveitar os instintos naturais dos programadores e comportamentos nao im-

postos, de forma a deixar a aplicacao deeXtreme Programmingsimples. As principais praticas

sao:

� O Jogo do Planejamento: Pratica que determina rapidamente o escopo da proxima

versao combinando prioridades do cliente e estimativas tecnicas, sobrepondo e atuali-

37

zando o planejamento. Mais detalhes sobre esta pratica estao na secao 5.2.2.

� Pequenas versoes: Consiste em colocar uma simples parte do sistema em producao rapi-

damente, depois deve-se lancar novas versoes em curtas iteracoes.

� Metafora: A ideia da metafora e compartilhar uma historia simples sobre todo o fun-

cionamento do sistema (e sua arquitetura) com todos da equipe. Mais detalhes sobre

metafora estao na secao 5.2.1.

� Design simples: O sistema deve ser projetado o mais simples possıvel em qualquer mo-

mento, removendo-se a complexidade extra. O Design simplese 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

estara validada.

� Refatoracao: Ou refactoring, e a reestruturacao do sistema sem mudar seu comporta-

mento para eliminar duplicacoes, melhorar a comunicacao, simplicidade ou adicionar

mais flexibilidade.

� Programacao em pares: Toda a producao de codigoe feita com dois programadores em

uma maquina. Enquanto um “pilota”, usando o teclado e mouse, o outro revisa o codigo

e analisa possibilidades derefactoringe redesign.

� Propriedade coletiva: Qualquer pessoa pode modificar qualquer parte do codigo do sis-

tema a qualquer momento. Para suportar esta pratica um controle automatico de versaoe

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, disponıvel para res-

ponder as questoes do projeto.

� Padroes de codificacao: No inıcio de cada projeto, devem ser estabelecidos padroes

de codificacao para serem seguidos durante o desenvolvimento e auxiliar a comunicacao

atraves do codigo. Tais padroes de codificacao incluem nomenclaturas de pacotes, modulos,

classes, metodos e variaveis, alem de especificacao de alinhamentos, margens, ferramen-

tas e comentarios.

38

5.2 XP E A MODELAGEM

A modelagem emeXtreme Programminge um assunto que incomoda muitos engenheiros

de software, pois sao poucas ou muito vagas as referencias a esta atividade nas principais bi-

bliografias deXP. Por exemplo, em (BECK, 2000), fala-se sobre padroes de codificacao, mas

nem se comenta sobre padroes de modelagem. Uma situacao mais estranha ocorre quando Kent

Beck comenta sobre o papel de diagramas no design.E uma secao sucinta que nao esclarece o

papel da modelagem emXP. O resultado dissoe que muitos praticantes deXP, simplesmente

ignoram a modelagem, partindo logo para a programacao.

Kent Beck ainda alerta que mesmo executando as atividades deXPna sequencia, havera um

ponto onde sera necessario umredesigndo sistema. Se esteredesigne um sinal de modelagem

falha emeXtreme Programming, nao esta claro, mase provavel. Na sequencia, estao listadas

algumas praticas que lidam com a modelagem do sistema.

5.2.1 METAFORA

A ideia da metaforae compartilhar elementos comuns para representar como o sistema ira

funcionar, ou sejae uma especie de “descricao arquitetural” com uma linguagem comum aos

desenvolvedores estakeholders. Cada projetoXP deve ser guiado por umaunica e abrangente

metafora de preferencia que sera usada como base para um projeto arquitetural mais detalhado

ao longo do desenvolvimento. Tambem pode-se trabalhar com varias metaforas para partes

diferentes do sistema, ao inves de se usar somente umaunica metafora.

Boas metaforas sao colhidas do domınio do problema e se reproduzem no codigo, dando

nomesas classes e metodos criados. Uma boa estrategia para implementar uma metafora e

abordada na secao 5.2.2.

5.2.2 JOGO DO PLANEJAMENTO

A tecnica doJogo do Planejamentoe usada para criar um ambiente de negociacao e cooperacao

entre os participantes. As pessoas de negocios ficam responsaveis em decidir sobre escopo,

prioridades, datas e composicao das versoes; enquanto a equipe tecnica prove estimativas, con-

sequencias tecnicas, organizacao dos processos e calendario detalhado. Ambas tentam dialogar

para chegar num acordo sobre estas decisoes.

O cliente fornece o escopo atraves de requisitos funcionais detalhados emstory cards, sim-

ples cartoes deındice com descricao resumida sobre uma funcionalidade do sistema que pode

39

ser testavel e estimavel.

O Jogo do Planejamentoe dividido em tres etapas:

1. Exploracao: Fase de criacao decartoes de usuario testaveis e estimaveis.

2. Comprometimento: O cliente escolhe oscartoes de usuario que agregem mais valor ao

projeto e com menor risco, definindo o escopo e data da proxima versao.

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 decartoes de usuario que

consiga criar um esqueleto funcional do sistema (sua arquitetura), que sera implementado

segundo ametafora do sistema.

5.2.3 DESIGN SIMPLES

Kent Becke enfatico quando fala sobre a importancia de umDesign Simplesno desenvolvi-

mento. Segundo (BECK, 2000), um design simplese aquele que obdece as seguintes restricoes,

em ordem de prioridade:

1. O sistema (codigo e testes juntos) deve comunicar tudo que se deseja comunicar.

2. O sistema nao deve conter funcionalidades duplicadas, procurando-se modulariza-lo.

3. O sistema deve ter o menor numero de classes possıvel.

4. O sistema deve ter o menor numero de metodos possıvel.

As duas primeiras restricoes constituem a regra “Uma e somente uma vez” que em outras

palavras siginifica que o sistema nao pode ter funcionalidades ou dados duplicados, sendo loca-

lizados em apenas um local. Todas as restricoes deeXtreme Programmingestao de acordo com

Object Thinking(WEST, 2004) que sera abordado posteriormente em 6.4.

5.2.4 SESSOES CRC

Em eXtreme Programming, apos a escolha doscartoes de usuario, estes sao agrupados se-

gundo funcionalidades.E feita uma reuniao em pe (stand-up meeting) para discutir as possıveis

classes envolvidas nestas funcionalidades, identificando-as. Para cada objeto (classe) identifi-

cadoe feito um cartao Class-Responsability-Collaborator(CRC) respectivo (veja a figura 4).

40

Muitos requisitos, neste momento, podem estar vagos, entaoe feita uma reuniao com o cliente

que provavelmente estara disponıvel, para retirar duvidas.

Figura 4: Cartao Class-Responsability-Collaborator

Nesta reuniao, oscartoes CRCsao colocadas sobre a mesa. Cada participante da reuniao

(clientes e desenvolvedores) vai falando sobre as responsabilidades (comportamentos) desejaveis

para o objeto e quais os colaboradores sao envolvidos para satisfaze-las. Todos contribuem com

a descricao do objeto, anotando os dados sobre o cartao.

Esta abordagem pode parecer estranha e ineficiente como modelagema primeira vista,

porem ela envolve conceitos de Orientacao a Objetos (Object Thinking) que a maioria da pes-

soas nao esta acostumada, como Analise de Comportamento do Objeto (WEST, 2004). Um

pouco mais sobre este topicoe discutido na secao 6.4.

5.3 XP COMO PROCESSO

O escopo de uma metodologia consiste no alcance dos papeis e atividades, sendo caracteri-

zado sobre a abrangencia do ciclo de vida, dos papeis e das atividades.

5.3.1 PAPEIS

Alguns papeis descritos porXPsao flexıveis podendo ser desempenhados pela mesma pes-

soa, a depender do tamanho da equipe de desenvolvimento. Os papeis envolvidos com a mode-

lagem sao:

� Programador: em XP, o programador assume papel de analista, modelador e progra-

mador. Por este fato, uma melhor identificacao para este papel seria “desenvolvedor”. O

41

programadore o papel principal daXPe tambem o principal responsavel pela modelagem

do sistema. Na secao 5.3.2 este aspecto ficara mais detalhado.

� Coach: ou tecnico. E uma especie de uma pessoa responsavel por todo o processo e

acompanhar a equipe deXP na aplicacao da metodologia. Geralmente, o coach tambem

e um desenvolvedor, contribuindo com a equipe para a geracao de um bom design.

� Cliente: esta envolvido indiretamente com a modelagem do sistema. Nas sessoes CRC,

ele entra com os requisitos e frequentemente modela em um nıvel mais alto ao preencher

alguns campos dos cartoes CRC.

5.3.2 ATIVIDADES

XP se baseia em atividades, cujo rigor reside nas pessoas cumprirem-nas adequadamente.

Pode-se aplicarXP em equipes maiores de dez pessoas, mas serao necessarias adaptacoes, o

que tornaria a metodologia mais pesada, aumentando o numero de elementos de controle e a

quantidade de tolerancia. Entretanto, pode-se expandirXPem relacao ao tamanho do problema

(COCKBURN, 2002).

As atividades sao apoiadas sobre as praticas e o relacionamento entre elas. Existem quatro

atividades basicas:Codificacao, Testes, Escutar eProjetar . Todas as atividades deXPpodem

ocorrer ao mesmo tempo num projeto, envolvendo diferentes participantes.

� Codificacao:

A atividade de codificacao gera um feedback sobre odesign. Quando se codifica, verifica-

se com facilidade a estrutura do codigo e percebe-se se existe um entendimento so-

bre o projeto necessario. A codificacao tambem ajuda a comunicar, principalmente na

programacao em pares.

� Testes:

eXtreme Programmingusa a abordagem “Test First Design”. Ela consiste em se imple-

mentar testes para cada nova funcionalidade a ser inserida antes mesmo de implementa-la.

O teste devera ser executado regularmente para verificar se o codigo passou, se sim, entao

a nova funcionalidade esta pronta. Com esta atitude, o desenvolvedor ira pensar sobre o

que ele quer independentemente de como sera implementado, depois os testes dirao se foi

implementado o que se pensou.

42

Segundo Kent Beck, criar testes tambem e fazerdesign, pois define-se a interface da

classe primeiro, pensando em seus metodos, propriedades e relacionamentos, antes de

implementa-la.

� Escutar:

Os programadores devem ter em mente que quem fornece os requisitose o cliente, o

usuario do sistema. Algumas praticasXP incentivam a existencia de dialogo entre os

programadores e clientes.

� Projetar :

Em XP, projetar (Designing) tem como foco a criacao de uma estrutura que organize a

logica do sistema de forma modular, “encapsulando a mudanca”. Desta forma, um bom

design sera aquele que assegurar a nao-duplicidade da logica do sistema, a proximidade

entre a logica e os dados a serem operados e a extensao do sistema com mudancas em

somente um lugar.

5.3.3 CICLO DE DESENVOLVIMENTO

Durante o desenvolvimento de um software usandoeXtreme Programming, verificamos a

existencia das seguintes fases:

� Fase de exploracao: Fase importante para a exploracao do escopo do sistema, pratica da

equipe nas tecnologias a serem usadas e treinamento do cliente emXP.

� Jogo do Planejamento: Descrito anteriormetne em 5.2.2, esta fase tem como objetivo

planejar a versao, acordando a entrega desoftwarede maior valor para o cliente com

investimento mınimo.

� Planejamento da Iteracao: O nome Planejamento da Iteracao identifica 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 sessoes

CRC, a programacao em pares erefactoring. Em cada iteracao, tambemn podem estar

ocorrendo as quatro atividades deXP simultaneamente num projeto. O desenvolvimento

em XP pode ser considerado como uma fase de manutencao do sistema em producao

(considerando uma ao menos uma versao ja publicada).

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

Figura 5: XP visto como um processo

Na pratica, muitas equipesXP nao enxergam as distincoes entre as fases, uma vez que o

processoe 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 abrangencia dos papeis e atividades que ela

intenta cobrir. Na pratica, para diferentes preocupacoes se adequam a diferentes metodologias,

44

refletindo nos papeis necessarios. Para finalizar esta analise sobreeXtreme Programming, e

necessario observar o escopo dela no ciclo de vida de um projeto desoftware.

Na figura 6, verifica-se a falta de uma abordagem sobre projeto de interfaces emXP, o que

pode ser complementado com metodologias especıficas como a descrita em (CONSTANTINE;

LOCKWOOD, 1999) ou outra abordagem. A figura 6e uma visao de Cockburn (COCKBURN,

2002) sobre o ciclo de vida de um projetoXP enfatizando esta questao.

Figura 6: Escopo de XP (COCKBURN, 2002)

Portanto, existe a necessidade de se ter uma abordagem alternativa para o projeto dein-

terface com o usuario visto queXP nao trata de nenhuma atividade relacionada ao projeto de

interface.

5.4 XP E DESENVOLVIMENTO DE JOGOS

No desenvolvimento de jogos, existem papeis e atividades distintos para cada fase de

producao. Entretanto, durante muito tempo nao existiu um processo de desenvolvimento dis-

ciplinado e bem documentado para jogos. Cada equipe de desenvolvimento utilizava-se de

metodos arbitrarios e com pouca engenharia de software. Por este e outros motivos era comum

o atraso na entrega do jogo. Felizmente, surgiueXtreme Programminge varios desenvolvedores

de jogos tiveram a boa ideia de usa-lo para jogos, surgindo naturalmente o que se esta chamando

45

deeXtreme Game Development(XGD) (DEMACHY, 2003).

eXtreme Game Development(XGD) e uma metodologia de desenvolvimento de jogos base-

ada emeXtreme Programming, estendendo-a (EXTREMEGAMEDEV, 2005). As adaptacoes da

XGD em relacao aXP sao simples e focadas no domınio de jogos. Pode-se considerarXGD

como sendoXP para nao-programadores, redefinindo alguns papeis, princıpios, praticas e pro-

cessos.

Observando-se a tabela 1 (secao 4.4), existem duas frentes de desenvolvimento: uma vol-

tada para a producao do jogo comosoftware, e outra para a producao do conteudo. O pro-

cesso de producao dosoftwaree dependente da producao de conteudo para atingir determinados

estagios de desenvolvimento e vice-versa. Assim, ambas as frentes devem estar coordenadas

segundo um mesmo processo. Por exemplo, nao se deve aplicareXtreme Game Development

para nao-programadores, enquanto os programadores executamRUP. E necessario sincronizar

as duas equipes numa so para atingirem o mesmo objetivo: “a producao do jogo”.

Pode-se indicareXtreme Game Developmentcomo um processounico que envolve todos

os desenvolvedores, procurando formar um time coeso (whole team). Para isto, nao devem

existir super-especializacoes como o “designer-da-fase-do-gelo” ou o “programador-do-editor-

de-mapas”. Cada competencia individual deve ser compartilhada para o bem do projeto.

Os valores deXGDsao os mesmos deXP. Por exemplo, “Simplicidade” emXGD, se refere

a eliminacao da complexidade extra aos jogos, tornando a jogabilidade mais agradavel, assim

como tambem evitar perder tempo na adicao de detalhes ou funcionalidades que nao serao no-

tadas no jogo. “Comunicacao” e um valor crucial para o projeto em jogos, por se tratar de uma

equipe multidisciplinar com potencial para conflitos internos em muitas etapas do desenvolvi-

mento.

5.4.1 PAPEIS

Os papeis doXGDsao:

� Produtor : e o equivalente ao cliente emXP, pois e o produtor do jogo quem fornece

os requisitos e pode decidir sobre o escopo e data das versoes. Pode-se verificar uma

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 nao existem produtores, o papel do clientee desempenhado pelo

game designer.

46

� Desenvolvedores: engloba todos os profissionais daarea tecnica: game designers, level

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

� Coach: aparentemente com o mesmo nome de um dos papeis XP, o coachem XGD

e o gerente do projeto e tambem um auditor que verifica se a equipe esta seguindo as

praticas. Uma ferramenta de apoio ao seu trabalhoe opainel XGD ou XGD dashboard

(DEMACHY, 2003), onde ocoachpontua de 0 a 5 cada pratica usada pela equipe.

� Distribuidor : ou “publisher”.E o patrocinador do projeto ou o“gold-owner” paraXP.

Apesar do produtor ser identificado como cliente,e aconselhavel que ogame designero

auxilie para fazer os testes funcionais (DEMACHY, 2003), assumindo um papel semelhante ao

testadoremXP.

5.4.2 PRATICAS

Na definicao deXGD, as praticas sao consideradas a mesma coisa que os princıpios, que sao

adaptacoes das praticas deXP. Este trabalho pretende focar mais o desenvolvimento de jogos

como producao desoftware, portanto apenas algumas praticas serao citadas:

� Propriedade coletiva da criacao: e uma adaptacao deXP da pratica “Propriedade cole-

tiva”. A criacao pertence a toda a equipe, e todos estao livres para mudar, excetuando-se

as diferentes atribuicoes dos profissionais. Istoe, os programadores tem a propriedade

coletiva do codigo, modeladores 3D dos modelos 3D, e assim por diante.

� Produtor sempre presente: esta praticae mais facil de ser aplicada em projetos deXGD

do que em projetos tradicionais, pois o produtor geralmentee alguem dentro da empresa

com disponibilidade.

� Versoes frequentes: versoes executaveis do jogo sao disponibilizadas com boa frequencia

em intervalos pequenos. Com isto osgame designerspodem analisar uma versao, os dis-

tribuidores podem acompanhar o progresso do projeto e o gerente pode antecipar proble-

mas podendo negociar com mais tranquilidade.

47

6 DESCRICAO DA ABORDAGEM

Neste capıtulo, sera descrita a abordagem seguida para aplicar modelagem emeXtreme

Programmingeficientemente, no domınio de jogos.

6.1 OBJETIVO

E fato queeXtreme Programmingpossui modelagem, porem como foi dito na secao 3.4.2

existem dois motivos validos para se modelar: para entender o domınio do problema ou comu-

nicar. Pode-se verificar que um simples rascunho de diagrama pode comunicar mais eficiente-

mente do que escrever um codigo inteiro para demonstrar uma ideia, comoe feito normalmente

emXP.

A ModelagemAgil e um metodologia indenpendente de outros processos, focalizando mo-

delagem e documentacao eficazes. A aplicacao dela junta aXP e recomendada, pois ela agrega

qualidade ao processo e tem um ajuste naturalaXP.

Na secao 4.4, foi discutido sobre as diferentes atividades de desenvolvimento demandadas

pelo domınio de jogos. Tais atividades, nao estao descritas porXP, porem devem ser conside-

radas, assim como novos processos de suporte e diferentes artefatos relacionados a elas.

O objetivo desta abordageme capturar estas especificacoes e refletı-las numa aplicacao

pratica deeXtreme Programminglocalizado. Assim, nas proximas secoes, serao abordadas

intersecoes e consequente modificacoes para agregar metodologias que suportem a modelagem

e desenvolvimento de jogos, comoeXtreme Game Development(XGD) detalhada na secao 5.4.

Uma visualizacao do resultado prentendidoe demonstrado na figura 7.

6.2 XP + MODELAGEM AGIL

Oscartoes de usuario e oscartoes CRCsao modelos. Logoe obvio que existe modelagem

em XP, como foi dito em 5.2.As vezes, quando estes modelos nao sao suficientes para se

48

Figura 7: XP + MA + XGD se complementando

entender um problema ou comunicar, os desenvolvedoresXPusam outros artefatos como citado

em (BECK, 2000) (pag. 111).

Ja que existe modelagem emXP, pode-se aplicarmodelagemagil nela. Naturalmente,

muitas das praticas damodelagemagil sao mapeadas diretamentea XP. Abaixo estao listadas

algumas praticas que sao novas ou alternativasas praticasXPconvencionais:

� Aplique o(s) artefato(s) correto(s): uso de ferramenta ou tecnica mais apropriada que

estiver disponıvel para o trabalho.E preciso ter conhecimento de varios artefatos para

escolhe-los bem.

� Crie diversos modelos em paralelo: Os desenvolvedoresXPpodem criar diversos mode-

los em paralelo:cartoes CRC, conjuntos de testes de aceitacao e esbocos opcionalmente.

Entretanto, quando se aplicamodelagemagil a XP, nao deve se restringir a apenas estes

modelos.

� Mostre os modelos de forma simples: Pratica complementara praticaXP “Design sim-

ples” (em 5.2.3). Os modelos nao precisam ser bonitos para serem eficazes.

� Descarte os modelos temporarios: Ao descartar modelos que nao se precisa mais,

tambem se esta diminuindo a carga de trabalho futura, pois serao menos modelos para

manutencao.Sempreque um modelo ja tiver cumprido seu papel,e hora de descarta-lo.

� 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 pratica foi in-

cluıda 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 comunicacaoe a formalizacao de um modelo de contrato.

� Modele para comunicar: E uma das razoes validas para se criar modelos, apoiando o

princıpio daComunicacao Aberta e Honesta.

� Modele para entender: Generalizacao da ideia de se usarcartoes CRCpara explorar

temas relacionados ao projeto.

� Reuse os recursos existentes: Nova pratica incluıda para agilizar a modelagem emXP.

6.2.1 REFATORACAO

Os desenvolvedoresXPaplicamrefactoringcom frequencia. Logo, podem existir situacoes

em que o codigo-fonte fique fora de sincronia com um modelo de projeto apos uma refatoracao.

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 reversado codigo-fonte para um modelo. Neste caso, existem ferramentas dis-

ponıveis que geram diagramas de classe ou de sequencia.

Quando a equipe precisar refatorar todo um sistema para eliminar uma hierarquia de herancas

complexas, por exemplo, uma sessao de modelagemagil e recomendada, incentivando os de-

senvolvedores a projetar as mudancas. Esta pratica permitira maior agilidade para se buscar a

melhor solucao ee recomendada tanto por (AMBLER, 2004) quanto por (BECK, 2000). Assim,

aModelagemAgil e naturalmente aplicavel aXPmesmo quando se trata de grandes refatoracao.

6.3 MODELAGEM AGIL + XGD

Como aModelagemAgil e aplicavel aXP, ela tambem sera aplicavelaXGDsem mudancas

significativas para o programadores. Porem para os nao-programadores, algumas praticas es-

senciais mudam, tornando a modelagem e a documentacao mais eficazes. A principal delase

relativa a documentacao e ao projeto deinterface com o usuario, descritos nas secoes 6.5 e 6.5.1

respectivamente.

50

6.4 ABORDAGENS COMPLEMENTARES

Object Thinking(OT) e uma nova abordagem para a modelagem de sistemas orientada a ob-

jetos, que propoe que se “pense como um objeto” ao inves de se “pensar como um computador”

(o quee ensinado atualmente em programacao). David West, autor do livro “Object Thinking”

enfatiza que nao se pode entendereXtreme Programmingsem um previo entendimento sobre

Object Thinking(WEST, 2004) (pag. XXV).

Object Thinkinginfluencia nos quatro valoresXPda seguinte forma:

� Comunicacao: Object Thinkingseria uma linguagem comum entre usuarios, gerentes,

especialistas do domınio e desenvolvedores.

� Simplicidade: OT possibilita a simplicidade numerica (numero de classes e metodos)

e criacao de objetos simples.Object Thinkingse propoe a facilitar a identificacao de

objetos e a delegacao de responsabilidades baseada no domınio do problema, oferecendo

uma simplicidade natural entre o mundo real e a modelagem.

� Coragem: Para aplicar OT sera preciso coragem para contrapor aos pensamentos tradici-

onais usados em OO e enfrentar os custos da mudanca no processo de desenvolvimento.

� Feedback: OT influencia indiretamente o feedback. A maior vantageme que sera mais

facil verificar se os modelos estao de acordo com a implementacao.

Object Thinkinge baseada no comportamento dos objetos (Behavior-based), apontando os

cartoes CRCcomo artefatos poderosos para se capturar e entender o comportamento dos obje-

tos. Nesta visao, oscartoes de usuario representam responsabilidades dos objetos identificadas

pelos clientes.

6.5 PROCESSO GERAL

A abordagem apresentada neste capıtulo nao se propoe a ser uma nova metodologia, elae

apenas uma “localizacao” deXP. A “localizacao” e recomendada por Kent Beck no princıpio

secundario Adaptacao local, lembrando queXP deve ser adaptada segundo o ambiente de

desenvolvimento local. Afinal, modificar uma metodologia existentee mais facil que criar uma

ou mais efetivo que usar outra metodologia projetada para uma nova situacao (COCKBURN,

2002).

51

A seguir, sera feita uma abordagem desta “localizacao deeXtreme Programming” segundo

as etapas classicas de desenvolvimento desoftware:

� Coleta de Requisitos:

A coleta de requisitos na abordagemXP+XGD+modelagemagil e a mesma deXP, onde o

cartoes de usuario ou cartao de historia e a unidade de requisitos funcionais. Ja a coleta

de requisitos nao-funcionais naoe bem clara emXP, assim como nasmetodologiasageis

em geral (PAETSCH, 2003), cabendo a cada equipe o trabalho de detecta-los e transforma-

los emcartoes de tarefa. Isto e, os papeis doprodutore game designer, que agem como

clientes, tem uma boa nocao dos requisitos nao-fucionais de um jogo, como performance

e confiabilidade, transformando-os emcartoes de usuario, naturalmente.

� Validacao de Requisitos:

XP ja faz uma validacao de requisitos naturalmente, pois a cadacartao de usuario e

verificado se esteeconsistente e testavel (PAETSCH, 2003). Outras verificacoes como se

o requisitonao-ambıguo e completo, sao resolvidos com a presenca constante do cliente

e com desenvolvimento incremental respectivamente.

� Projeto Arquitetural :

O trabalho de construcao de um esqueleto arquitetural de todo o sistemae feito naFase

de exploracao, onde o trabalho de uma equipe de modelagem se faz necessario atraves de

umasessao de modelagemagil para criar a metafora do sistema. Segundo West (WEST,

2004), tal metafora deve ser tao forte a ponto de eliminar o projeto arquitetural detalhado.

Se umaunica metafora nao puder satisfazer esta condicao, pode-se criar mais de uma

metafora para partes do sistema.

Entretanto, pode-se considerar a metafora apenas como uma base arquitetural geral, onde

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 usuarios especıficos para alcancar objetivos especıficos com efetividade,

eficiencia e satisfacao em um contexto de uso especıfico (WIKIPEDIA , 2005). Ela esta

diretamente ligada ao Projeto deInterface com o Usuario e e a capacidade do software

em permitir que o usuario alcance suas metas de interacao com o sistema.

52

O Projeto deInterface com o Usuario entra no processo dedesignpara melhorar a ex-

periencia do usuario (user experience). ComoXP nao cita tecnicas de modelagem de

interface (veja figura 6 no capıtulo 5), propoe-se o uso parcial da metodologiaGoals -

User Interface Design(GUIDe) (LAAKSO; LAAKSO , 2004) com adaptacoes paraXGDe

ModelagemAgil. A GUIDe e uma metodo iterativo e inspirado nasmetodologiasageis.

A GUIDenao especifica sua fase de aplicacao, podendo se adaptar bem em qualquer tipo

de processo, inclusive nos que seguem o “modelo cascata”. De forma resumida, aGUIDe

orienta como transformar requisitos em forma deuse casesem interfaces implementadas.

No caso da abordagem proposta neste trabalho, teremos os seguintes passos adaptados:

1. A entrada de requisitose feita atraves decartoes de usuario que originam tambem

os testes de validacao da interface ou funcionalidade iterativa a ser criada. Os

cartoes de usuario foram criados pelo produtor com auxılio do game designer. Os

cartoes de usuario podem apresentar graficos ou modelos de tela como rascunho em

substituicao ou em anexo ao texto.

2. Os desenvolvedores elaboram especificacoes dainterface com o usuario e testam

atraves de simulacoes de um jogador executando a tarefa. A partir destas simulacoes

rapidas, surge um modelo mais refinado da interface que sera anexado aoscartoes de

tarefa(task cards). Segundo aGUIDe, os modelos resultantes seriamuse cases, mas

seguindo a pratica “Aplique o(s) artefato(s) correto(s)” daModelagemAgil, outros

artefatos podem se apresentar mais adequados ou complementares como o diagrama

de atividades para funcionalidades interativas. A ModelagemAgil tambem alerta

que a UMLe ampla, mas naoe suficiente para representarinterface com o usuario.

Usa-se neste caso, prototipos deinterface com o usuario essenciais, por exemplo.

Veja figura 8.

A fase seguintee de implementacao.

� Implementacao:

A implementacao emXP, 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 codigo gerado.

Antes de implementar, inicia-se com a criacao dos testes automaticos para verificar quando

o desenvolvimento da tarefa esta encerrado. No domınio de jogos, como temos duas fren-

tes de desenvolvimento integradas: a producao dosoftwaree a producao do conteudo,

os cartoes de tarefasao repassados por todos os profissionais requeridos na atividade,

53

Figura 8: Prototipo deinterface com o usuario essencial (baixa definicao)

seguindo a sequencia similar a da tabela 1 (secao 4.4). Mais detalhes sobre testes estao

nas secoes seguintes. Apos cada atividade executada, o desenvolvedor registra a data e

hora de inıcio e data e hora de finalizacao, repassando o cartao de tarefa para o proximo

profissional requerido.

Abaixo estao listados os passos gerais de implementacao de um requisito funcional (historia

de usuario), segundo a visao de um programador:

1. O cliente elabora umahistoria que depoise estimada pela equipe. Se a equipe nao

consegue estima-la, ocartao de usuario e dividido. Nesta divisao e comum que

funcionalidades ligadas ao desenvolvimento desoftwarese separem das atividades

ligadasas demaisareas, para se ter uma boa estimativa. Poreme importante verificar

oscartoes de usuario que em conjunto implementam uma funcionalidade maior do

sistema para agrupa-loss na iteracao corrente ou na seguinte.

2. A equipe de programadores transforma oscartoes de usuario em objetos. Agru-

pando oscartoes de usuario que tratam dos mesmos objetos.

3. escolhido um dos grupos decartoes de usuario para implementacao na iteracao

corrente. A equipe aproveita este tempo para discutir a implementacao seguindo a

metafora do sistema (sua arquitetura). Idealmente,e feita umasessao de modelagem

agil em pe. Depois os cartoes de usuario selecionados sao finalmente divididos entre

os pares.

4. Cada dupla, realiza uma rapida sessao de modelagem para discutir os detalhes da

implementacao e construir os testes.

� Testes:

54

Existem dois tipos de testes a serem realizados: automaticos (sobre o codigo) e degame

design(testes de jogabilidade, de design, balanceamento, harmonia visual entre outros).

Os paresXPdevem criar os testes automaticos possıveis e suficentes para verificar quando

a tarefa esta finalizada.

A validacao de um design eventualmente se transforma em uma tarefa subjetiva. Porem,

pode-se considerar a existencia de padroes de interface para verificar se a interfacee

“usavel” (LAAKSO, 2003).

Os testes de validacao relativosa producao de conteudo sao elaborados pelo produtor

com o auxılio de umgame design. Nesta etapa, muitos testes sao focados na usabilidade

(jogabilidade).

Durante a execucao dos testes de validacao gerais,e aconselhavel que exista um meca-

nismo que registre as atividades do jogador para que o erro possa ser reproduzido nova-

mente (PAETSCH, 2003).

Existem muitos testes nao-funcionais sobre requisitos como performance. Alguns exem-

plos:

– Testes usando como metricas o numero de polıgonos e tamanho de arquivos (i.e.:

imagens, vıdeos).

– Testes entre a camada de renderizacao e o hardware.

– Testes sobre a IA dosNon-Player-Characters(NPCs). Sao testes para verificar se

as acoes executadas por jogadores controlados pelo software correspondem a um

“padrao inteligente”.

� Revisoes arquiteturais:

O objetivo do uso daModelagemAgil comXP e o de tornar a modelagem e documentacao

eficazes, mas nao se resume a isto. Opcionalmente, a depender da complexidade do pro-

jeto, pode-se agendar revisoes arquiteturais simplificadas ao final de cada iteracao. Tais

revisoes teriam o mesmo formato desessoes de modelagemagil, com a participacao dos

desenvolvedores. Seriam levantados diagramas simples da arquitetura corrente gerados

a partir da processos de engenharia reversa realizados automaticamente por ferramen-

tas CASE. Durante a sessao, seriam levantados problemas crıticos da arquitetura corrente

pontuados de 1 a 4 em ordem de relevancia (MARANZANO et al., 2005). Caso o problema

fosse bastante crıtico, no nıvel 1 por exemplo, deve-se corrigir o problema, fazendo-se o

redesigne refactoringespecıficados em novoscartoes de tarefapara a nova iteracao ou

divididos entre varias iteracoes.

55

Entretanto,e importante que a abordagem de revisao arquitetural acimae apenas um

metodo simplificado quee a melhor opcao do que nao existir revisao arquitetural no

projeto, visto queeXtreme Programmingpreve a existencia de situacoes que necessi-

tem de algum retrabalho dedesign, mas deixa a deteccao a cargo dos desenvolvedores.

Uma abordagem melhor para revisoes arquiteturais convencionais pode ser encontrada

em (MARANZANO et al., 2005).

6.5.1 DOCUMENTACAO DO SISTEMA

A documentacao tambem faz parte deXP, e geralmente ela ocorre ao final do projeto, pois

o objetivo secundario e se preparar para “a proxima jogada”. Os diferentes tipos de documentos

tem o seu proposito e vantagens. Porem a decisao de se fazer documentacao deve ser uma

decisao de negocios. O cliente devera estar ciente que ao inves de produzirsoftware, parte da

equipe estara alocada na producao de documentacao.

Existem quatro tipos de documentacao, relativas a producao do jogo como software:

� Do sistema: e a documentacao mais importante para a manutencao do mesmo, forne-

cendo uma visao geral. Diagramas em nıvel de arquitetura sao frequentes neste tipo de

documento.

� De operacoes: e um resumo dos requisitos nao-funcionais do sistema com informacoes

como disponibilidade e confiabilidade.

� De suporte: inclui materiais de treinamento para a equipe de suporte.

� De usuario: sao os“helps” , Perguntas frequentes respondidas (FAQs) e manual do jogo

contendo guia da interface.

Al em dos tipos de modelo citados, existem outros ligadosa area deGame Designcomo

o “Documento deGame Design” (FREEMAN, 1997). Seguindo-se aModelagemAgil, alguns

destes documentos podem ser minimizados ao mesmo tempo que se encontra novas formas de

comunicar.

Para asMetodologiasAgeis, a producao tradicional depostmortemao final do ciclo de vida

de um jogo, nao faz sentido, pois o feedback recebidoe tardio e com certeza nao trara nenhum

benefıcio ao jogo em desenvolvimento. Uma forma de agilizar istoe a producao deEarly Post-

mortems(postmortemsparciais) durante a fase de manutencao do projeto. Se o jogo estiver

em producao e disponıvel para ao publico, por exemplo, a gerencia podera se beneficiar deste

56

resultado, podendo prever estrategias de vendas. De qualquer forma, a equipe de desenvol-

vimento vai ter um benefıcio maior, pois podera analisar o que deu certo ou nao, seguindo o

princıpio agil “Regularmente, a equipe deve refletir em como ser mais efetiva, entao se ajustar

adequadamente” (ALLIANCE , 2001).

6.5.2 RESUMO

As MetodologiasAgeisem geral surgem para maximizar a concorrencia entre as ativida-

des, existindo fluxos paralelos de desenvolvimento. Pode-se verificar isto, principalmente na

abordagem descrita se as duas frentes de producao (softwaree conteudo) forem consideradas.

Ao se focalizar a visao dos desenvolvedores desoftwarepara a producao de um jogo, a

abordagem descrita neste capıtulo pode ser visualizada da seguinte forma:

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

Note que as iteracoes possuem o mesmo tempo de duracao de duas a tres semanas.

57

7 ESTUDO DE CASO

O estudo de caso apresentado a seguire uma aplicacao deeXtreme Programmingcom

ModelagemAgil, no domınio de jogos. O processo pode ser visualizado como na figura 9 do

capıtulo anterior.

7.1 CONCEITOS PRELIMINARES

Antes do relato do caso implementacao, os conceitos de jogos de empresas emassive mul-

tiplayer online game(MMOG) serao abordados para fins didaticos.

7.1.1 JOGOS DE EMPRESAS

Um Jogo de Empresae uma simulacao planejada que encaixa os jogadores em um sis-

tema de negocios simulado que assumem o papel de tomadores de decisoes em organizacoes.

Suas escolhas geralmente afetam as condicoes do sistema onde a decisao subsequente deve ser

tomada (GRAMIGNA, 1994).

Nasceram nos Estados Unidos, como simulacoes de guerra, sendo hoje uma pratica muito

comum comprovada estatısticamente (ABSEL, 2005). Jogos de Empresa tambem sao chamados

deBusiness Gamesou Business Simulation. No Brasil sao usados como ferramentas no ensino

em cursos de pos-graduacao, graduacao de Ciencias Contabeis, Administracao e Economia.

Sao classificados de duas formas:

� Gerais: elaborados para desenvolver habilidades gerenciais de executivos.

� Funcionais: elaborados para desenvolver habilidades emareas especıficas da organizacao

(financas, 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 numero nao-limitado de jogadores. Este requisito demanda o uso de no-

vas arquiteturas como multi-servidoras, descentralizadas/distribuıdas ou hıbridas (CECIN; BAR-

BOSA; GEYE, 2003).

Geralmente, um MMOG nao e jogado em turnos, mas sim em tempo indefinido. Os jo-

gadores se conectam ao jogo usando um cliente ouservantem aplicacoes peer-to-peer (RULE,

2004).

7.2 DESCRICAO DO PROBLEMA

O objetivo do casoe a criacao de um jogo com caracterıstica de jogo de empresas (geral e

funcional) e demassive multiplayer online game(MMOG). E um projeto em desenvolvimento

e apresenta aqui seus resultados parciais utilizandoModelagemAgil emeXtreme Programming.

7.2.1 ESCOPO

O jogo foi dividido em duas partes: jogos offline singleplayer (somente o usuario contra o

computador) e jogos online massivos (varios jogadores disputando em rede simultaneamente).

Foi definido o desenvolvimento da parte offline primeiro. Noınicio desta parte foi previsto

um mecanismo de aprendizagem, como tutoriais inteligentes (MASCARENHAS; CARVALHO,

2002), para que o usuario se habituasse com facilidade ao ambiente e alguns conceitos de jogos

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 economicos e

dinamica de cadeias produtivas proprio. O objetivo do jogoe conseguir o sucesso da empresa

virtual, sua expansao, e o aprendizado pela experiencia. Muito similar ao SimCity (ALVES,

2004), porem a simulacao era baseada na administracao basica de empresas.

7.3 DESENVOLVIMENTO

O desenvolvimento do projeto em questao foi pouco influenciado pela abordagem deeX-

treme Game Development, pois esta encontra-se em estagio inicial de desenvolvimento con-

59

tendo poucas referencias e pesquisas existentes. Grande parte do projeto descrito em abordagem

foi elaborado com o intuito de acrescentar novas informacoesaXGD.

Para o ambiente de desenvolvimento, foi utilizado um espaco adequado para implementacao

deeXtreme Programming, segundo a indicacao “caves and commons” (BECK, 2000), onde os

computadores sao proximos uns aos outros com espaco suficiente para os pares de programacao,

radiadores de informacao (veja a figura 10) e espacos extras para modelagem, reunioes ou

tarefas reservadas.

Figura 10: Um dos radiadores de informacao usados

7.3.1 EQUIPE

No projeto, existem papeisXP e relativos ao desenvolvimento de jogos: umgame desig-

ner/artista gr afico; doisclientes(sendo umespecialistaem jogos empresariais); quatropro-

gramadores; um coach; e umtestador. Entretando a equipee pequena e mista, o que da um

total de seis pessoas, exceto ummodelador 3De umartista gr aficoem carater de contratacao

futura ate a data deste documento.

A equipe de desenvolvimentoe, em geral, iniciante, deixando o desenvolvimento em carater

experimental, poise a primeira aplicacao deXP e deModelagemAgil para todos os desenvol-

vedores.

Dos quatro desenvolvedores, apenas dois tinham participado ativamente de modelagem de

sistemas em projetos anteriores, o que fez muitassessoes de modelagemagil serem realizadas

60

apenas por uma dupla.

A equipe fez auto-treinamento emrefactoring e CppUnit(WHITLOCK; MELNIKOV; LE-

PILLEUR, 2005) para os testes de unidade, sendo feita duas apresentacoes sobreeXtreme Pro-

gramminguma sobreModelagemAgil e uma simulacao deXP para todos incluindo o cliente,

chamada por muitos deeXtreme Hour(COCKBURN, 2002)(pag. 139).

7.3.2 TECNOLOGIAS E FERRAMENTAS

Foram utilizadas as seguintes ferramentas para suportar comunicacao:Twiki, quadro-branco

e flip chart. Para modelar ou criar documentacao agil tambem foram utilizadas Umbrello, Dia

e plugin EclipseUML, alem de uma ferramenta CASE de engenharia reversa. O ambiente de

desenvolvimento contou com um sistema de controle de versao CVS (Concurrent Versions Sys-

tem) (CVS, ), Eclipse IDE (ECLIPSE. . ., ) e CppUnit. As plataformasWindows XPe Debian

GNU/Linuxforam 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 deGame Designprevia um jogo

2D isometricocomo na figura 11, porem o cliente, apos uma analise de mercado, decidiu mudar

para 3D, fazendo investimento numagame engine(ou motor de jogo) 3D (MENEZES, 2004),

mudando o projeto, a plataforma de desenvolvimento, profissionais requeridos entre outras coi-

sas.

Ate o presente momento o projeto passou pela sua primeira iteracao “oficial”, deixando

uma versao em producao.A Fase exploracao foi de 5 semanas e o tempo de duracao da iteracao

foi tambem de 5 semanas. As iteracoes seguintes devem durar de 2 a 3 semanas.

7.3.4 FASES DE DESENVOLVIMENTO

A coleta de requisitosno presente estudo de caso, foi feita atraves decartoes de usuario.

Algumas vezes, o cliente era representado pelogame designerque estava constantemente pre-

sente 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 cartoes de usuario iniciais foram digitados no computador, porem era frequente as vezes

em que mais informacoes precisavam ser adicionadas a eles (veja a figura 12). Para agilizar

61

Figura 11: Prototipo 2D

o processo, o cliente passou a escrever as historias numa folha padrao e todos oscartoes de

usuario ficavam disponıveis numa pasta.

Os requisitos nao-funcionais influenciaram, no inıcio do projeto, sobre a tecnologia e fer-

ramentas a serem escolhidas. Buscou-se deixar o cliente alheio em relacaoa escolha das tecno-

logias envolvidas, exceto quando a aquisicao de alguma ferramenta incorreria em custo para o

projeto.

Na primeira aplicacao deXP, nem todos oscartoes de usuario foram verificados se eram

consistentes e testaveis, incorrendo em requisitos mal coletados. Porem, este problema foi

resolvido logo em seguida com a divisao decartoes de usuario, permitindo umaValidacao de

Requisitosmais consistente. Os novoscartoes de usuario gerados eram mais simples, contendo

funcionalidades e com maior facilidade de se gerar testes funcionais.

Para uma base deProjeto Arquitetural foi utilizada uma metafora centrada no proprio

projeto do jogo, onde as objetos principais eram os simuladores offline e online. Esta nao foi

uma boa metafora, pois a maioria dos participantes desconhecia o conceito de simulacao. A

segunda metafora elaborada foi baseada na dinamica do jogo, onde os objetos identificados

eram de facil compreensao pelo cliente e pelos desenvolvedores.

A metafora nao eliminou a necessidade de um diagrama para a arquitetura de rede, que teve

que ser modelado para comunicar ao cliente a necessidade de construcao de ummiddleware

(veja figura 13).

62

Figura 12: Exemplo de cartao de usuario utilizado

Para oProjeto de Interface, foram utilizadasSessoes de modelagemagil, onde partia-

se doscartoes de usuario passando poruse casesate chegar ao prototipo deinterface com o

usuario essencial, seguindo umaGUIDeadaptada.

7.3.4.1 IMPLEMENTAC AO

Logo no inıcio da iteracao, notou-se a necessidade de adicionar mais espaco noscartoes de

tarefa para anotacoes e comentarios sobre cada tarefa do dia, principalmente quando a tarefa

teria que continuar no dia seguinte. Ocartao de tarefase demonstrado na figura 14.

Algumas tarefas de interface foram executadas por demanda do cliente e/ou dos proprios

programadores. No estudo de caso, procurou-se separar as tarefas relativas a producao da in-

terface emcartoes de tarefadiferentes dos de programacao de regras de negocio. Por exemplo,

existiramcartoes de usuario para especificando a producao da telas de entrada no sistema e

outros que definiam como validar o usuario.

63

Figura 13: Modeloagil de arquitetura de rede

Apos a grande mudanca de requisitos citada na secao 7.3.3, passou-se a usar ummotor

de jogosde codigo aberto. Entretanto, o codigo disponıvel possuıa uma hierarquia de classes

muito complexa (muito verticalizada) alem de nao ter classes de teste (para realizacao de testes

automaticos), requerendo uma grande refatoracao que ainda esta em execucao.

Nao foi feita nenhuma revisao arquitetural, ate o momento. As classes adicionais aomotor

de jogostiveram umdesignmuito simples e preferiu-se agendar para o final da proxima iteracao.

7.3.4.2 DOCUMENTACAO DO SISTEMA

Seguindo o princıpio daModelagemAgil “Minimize a carga de trabalho”, somente osuse

casesprincipais,cartoes de usuario e cartoes CRCviraram documentacao oficial. Existiram

outro documentos produzidos comocartoes de tarefa, cronogramas e prototipos anterioresa

aplicacao deXP.

7.3.5 MODELAGEM AGIL

Para deixar mais claro os resultados e aplicacoes daModelagemAgil no caso apresentado,

alguns exemplos serao adicionados em relacaoa praticas desta metodologia.

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

prototipos deinterface com o usuario essenciais.

64

Figura 14: Cartao de tarefas

2. Crie diversos modelos em paralelo: Mesmo usandocartoes CRCtambem foram criados

diagramas de sequencia.

3. Itere em outro artefato: Enquanto modelava um caso de uso, era preciso tambem en-

tender os fluxos de atividades o que nao parecia ser possıvel com o caso de uso. Um

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 eficaz

1. Modele com outras pessoas: Foram feitas sessoes de modelagem com outros desen-

volvedores e ate com o cliente num sessao de modelagem de alto nıvel usandocartoes

CRC.

2. Organize uma participacao ativa do cliente: Mesmo caso citado acima.

3. Promova a posse coletiva: Nao existe “eu” nas modelagens, so “nos”.

4. Mostre os modelos publicamente: Foram realizadas pequenas apresentacoes com mo-

delos de telas por exemplo.

65

Praticas que permitem simplicidade

1. Criem conteudo simples: Os cartoes CRCderam um bom suporte para se conseguir

aplicar esta pratica.

2. Mostre seus modelos de forma simples: Evitou-se adicionar detalhes desnecessarios

sempre.

3. Use as ferramentas mais simples: As ferramentas mais usadas foram: papel, caneta e

flip chart.

Praticas para validar o trabalho

1. Considere a testabilidade: Cada modelo foi criado pensando-se nos testes.

2. Comprove com codigo: E a maneira ideal para responder a duvida se o projeto esta certo.

7.4 CONSIDERACOES

A aplicacao deeXtreme Programmingenvolve um planejamento inicial sobre uma serie de

questoes: numero de pessoas no desenvolvimento, condicoes do ambiente de trabalho e respon-

sabilidades desempenhadas. Neste caso, por nao existir uma estimativa anterior semelhante,

nao foi possıvel estimar com precisao, aumentando o risco do projeto. Com o passar do tempo,

este risco diminui.

Deve-se considerar numeros pares para a pratica depair programming, alem de dividir

adequadamente pessoas com mesmas habilidades entre as duplas, fazendo-as circular o conhe-

cimento.

Pela experiencia, podemos considerar tres papeis importantes para o acompanhamento e

desempenho das tarefas: otracker, um papel de projetosXP responsavel por acompanhar o

progresso e velocidade da equipe; ocoach; e o game designer. eXtreme Programmingde

fato, poe muita responsabilidade nas habilidades do membros da equipe, potencializando as

qualidades ou defeitos humanos.

66

8 CONCLUSOES

Hoje, os desenvolvedores brasileiros de jogos ainda enfrentam problemas como: orcamento

reduzido; pressoes mercadologicas por qualidade e muitas funcionalidades nos jogos; pouca

experiencia em desenvolvimento de jogos; reducao de prazos de entrega; pouco planejamento

gerencial; e equipes pequenas (o que invalida, parcialmente, aplicacoes de metodologias mais

pesadascomoRUP).

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-

rocraticos maisleves. Entretanto, a aplicacao deeXtreme Programmingnao e recomendada

sem uma base solida sobre os fundamentos e praticas daEngenharia de Softwarecomo a mo-

delagem.

De fato,eXtreme Programminge as demaisMetodologiasAgeiseliminam cada vez mais a

necessidade de indivıduos especializados em prol de indivıduos com competencias que abragem

mais o desenvolvimento desoftware. Estee um fato tanto positivo quanto negativo, a diferenca

esta em se ter tais pessoas na equipe.

A aplicacao daModelagemAgil em eXtreme Programmingfoi f acil e intuitiva, melho-

rando o entendimento sobre a modelagem num projeto e reforcando praticasXP. Ao se aplicar

a ModelagemAgil, verifica-se o significado da frase de Scott Ambler: “Na verdade, muitos

desenvolvedores acharao que estarao fazendo mais modelagem do que antes”. O quee equiva-

lenteaeXtreme Programming, pois antes mesmo de se implementar o codigo desejado, deve-se

implementar testes. E nem por estas razoes existe perda de eficiencia. Muito pelo contrario.

As metodologiasageis estao revolucionando aEngenharia de Software, porque elas valorizam

mais os indivıduos do que processos e ferramentas.E uma abordagem diferente que foca o

maior causador de erros, o indivıduo, podendo potencializar tanto as qualidades como os defei-

tos humanos.

Existem ate formas de se deixar metodologias tradicionais comoRational Unified Process

(RUP) mais ageis comoe dito em (SMITH, 2001) sobre o “RUP configuravel”, porem o que

67

diferenciaMetodologiasAgeiscomoXP e a base filosofica (valores e princıpios diferentes).

Portanto, mesmo que se aplique “RUPconfigurado”, se estara sujeitoa mesma base filosofica

antiga.

8.1 RESULTADOS

Como resultado parcial da aplicacao daModelagemAgil em XP no domınio de jogos,

verificou-se que aModelagemAgil tornou os processos de modelagem e documentacao mais

eficazes. As dicasuteis fornecidas pelas praticas, auxiliaram a aprendizagem e aumento de

eficacia dos modeladores. A principal diferencae que a tarefa de modelar deixou de ser vista

como um fardo para se tornar atividade prazerosa que agrege valor ao desenvolvimento desoft-

ware.

8.2 DIFICULDADES ENCONTRADAS

Uma das dificuldades em se aplicarModelagemAgil e seguir a pratica “Modele incremen-

talmente”, pois sempree facil cair na armadilha de se modelar todo o sistema de uma vez,

tentando “congelar os requisitos”.

Outro problemae que aModelagemAgil exige que se conheca muitos artefatos diferentes.

A equipe teve que buscar bibliografia complementar, usando para referencia em UML os livros

“UML na Pratica - Do Problema ao Sistema” (CARDOSO, 2003) e “UML 2 - Guia de Consulta

Rapida” (GUEDES, 2003), para correlacionar a simplicidade e agilidade oferecidas pelos mo-

delos/diagramas UML. Outras referencias sobre modelagem deInterface com o Usuario por

exemplo, foram buscadas na internet atraves de varias fontes como (USERNOMICS, 2005).

8.3 TRABALHOS FUTUROS

Um trabalho futuro deste projetoe a complementacao daeXtreme Game Development, visto

quee uma metodologia baseada emeXtreme Programmingmuito recente e pouco definida. Um

ponto de investigacao daXGDseria o processo de desenvolvimento segundo a visao dos desen-

volvedores “nao-programadores”. Um segundo ponto, seria como obter melhores estimativas

de desenvolvimento.

Pode-se indicar ainda outros trabalhos futuros como:

68

� Investigacao maior da aplicacao sobreObject Thinking com XP: As Metodologias

Ageisrequerem novas formas de pensar, logo podemos aplicarXP+modelagemagil aliada

aOT.

� Investigacao maior da aplicacao sobreNaked Objectscom XP: Naked Objectse 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 deXP a

simplicidade de umframework(MATTHEWS, 2004).

� Investigacao mais profunda daGUIDeem jogos: E provavel que metodos comoGUIDe

emodelagemagil juntos formem um metodo de modelagem maduro o suficiente para pos-

sibilitar o “estado-da-arte” em interfaces, mesmo assim, faltariam praticas para a criacao

de interatividade comoe vista em jogos.

� Investigacao sobre Game Design Patterns e User Interface Design Patterns: Tal

investigacao buscaria a melhoria o desenvolvimento de jogos de forma eficaz, atraves da

aplicacao deUser Interface Design Patterns(LAAKSO, 2003) eGame Design Patterns

(KREIMEIER, 2002).

69

REFERENCIAS

ABSEL. ABSEL- Association for Business Simulation and Experiential Learning. 2005.Ultimo acesso em 14 de marco de 2005. Disponıvel em:<http://www.absel.org>.

AHEARN, L. Budgeting and Scheduling your game. Gamasutra - The Art & Scienceof Making Games, 2001.Ultimo acesso em 18 de dezembro de 2004. Disponıvel em:<http://www.gamasutra.com/features/20010504/ahearn01.htm>.

ALLIANCE, A. Agile Alliance. 2001.Ultimo acesso em 07 de dezembro de 2004. Disponıvelem:<http://www.agilealliance.org>.

ALVES, L. Sim City. 2004.Ultimo acesso em 24 de julho de 2005. Disponıvel em:<http://www.comunidadesvirtuais.pro.br/ead/simcity.htm>.

AMBLER, S. W. ModelagemAgil - praticas eficazes para a Programacao eXtrema e oProcesso Unificado. Sao Paulo: Addison Wesley, 2004.

ART, b. Game Research the; GAMES science of computer.Dictionary. Ultimo acesso em 20de julho de 2005. Disponıvel em:<http://www.game-research.com/dictionary.asp>.

ART, b. Game Research the; GAMES science of computer.History and genre. Ultimo acessoem 23 de julho de 2005. Disponıvel em:<http://www.game-research.com/history.asp>.

BECK, K. Extreme Programming Explained: Embrace Change. [S.l.]: Addison WesleyProfessional, 2000.

CARDOSO, C.UML na Pratica - Do Problema ao Sistema. [S.l.]: Editora Ciencia Moderna,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:Proceedingsof WJogos 2003, Brazilian Workshop of Games and Digital Entertainment. [S.l.]: SociedadeBrasileira 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 SystemsDevelopment Method Ltd, 1994.Ultimo acesso em 27 de julho de 2005. Disponıvel 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. Disponıvel em:<http://www.ratio.co.uk/white.html>.

70

COSTA, D. S. P. Um estudo sobre programacao extrema (extreme programming).Departamento de Ciencia da Computacao, UFBA, p. 36, 2003. Monografia de final de curso.

CVS.Ultimo acesso em 25 de julho de 2005. Disponıvel 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. Disponıvelem:<http://www.gamasutra.com/resourceguide/20030714/demachy01.shtml>.

DEXTERITY, S. Project Postmortems. 1999.Ultimo acesso em 11 de janeiro de 2005.Disponıvel em:<http://www.dexterity.com/postmortem>.

ECLIPSE.ORG - Development Resources.Ultimo acesso em 25 de julho de 2005. Disponıvelem:<https://www.eclipse.org>.

EXTREMEGAMEDEV.ExtremeGameDev Wiki: ExtremeGameDev. 2005.Ultimo acesso em22 de julho de 2005. Disponıvel em:<http://www.extremegamedev.org/>.

FINALBOSS.COM.Sobre as noteas. 2005.Ultimo acesso em 21 de julho de 2005. Disponıvelem:<http://www.finalboss.com.br/fb3/psobrenotas.asp>.

FOWLER, M. et al.Refactoring: Improving the Design of Existing Code. [S.l.]: Addison-Wesley, 2000.

FREEMAN, T. Creating a Great Design Document. Gamasutra - The Art & Scienceof Making Games, 1997. URL.Ultimo acesso em 20 de julho de 2005. Disponıvel em:<http://www.gamasutra.com/features/19970912/designdoc.htm>.

GRAMIGNA, M. R. M. Jogos de Empresas. Sao Paulo: Makron Books, 1994.

GROUP, O. M. Controlled chaos: Living on the edge. p. 10, 1995.

GUEDES, G. T. A.UML 2 - Guia de Consulta Rapida. [S.l.]: Editora Novatec, 2003. ISBN8575220659.

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. Disponıvel em:<http://www.xprogramming.com>.

JOGOS made in Brazil. Universia Brasil, 2004.Ultimo acesso em 17 de setembro de 2004.Disponıvel em:<http://www.universiabrasil.net/html/noticiaibfhg.html>.

KREIMEIER, B. The Case For Game Design Patterns. Gamasutra - The Art & Scienceof Making Games, 2002. URL.Ultimo acesso em 20 de julho de 2005. Disponıvel em:<http://www.gamasutra.com/features/20020313/kreimeier03.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. Disponıvel em:<http://www.cs.helsinki.fi/u/salaakso/patterns>.

LAAKSO, S. A.; LAAKSO, K.-P.Ensuring quality of the user interface with the GUIDeprocess model. University of Helsinki, 2004. URL.Ultimo acesso em 19 de julho de 2005.Disponıvel em:<http://www.cs.helsinki.fi/u/salaakso/papers/GUIDe.html>.

MARANZANO joseph et al. Architecture reviews: Practice and experience. IEEE ComputerSociety, April 2005.

MASCARENHAS, A.; CARVALHO, M. de. Um gerador de sistemas tutoriais inteligentes paraauxılio a alfabetizacao em portugues. In:Anais do Congresso da SBC - VIII WIE (SBC 2002).Florianopolis, Santa Catarina, BRA: Sociedade Brasileira de Computacao, 2002. P.249-54.

MATTHEWS, R.Naked Objects. Naked Objects Group Ltd, 2004.Ultimo acesso em 26 dejulho de 2005. Disponıvel em:<http://www.nakedobjects.org>.

MENEZES, J. R. de B.Um Framework para Criacao de Jogos ComputadorizadosMultiplataforma. Dissertacao (Mestrado) — Pontifıcia Universidade Catolica do Rio Grandedo Sul, Porto Alegre, 2004.

NEBULON. Feature Driven Development. Nebulon Pty Ltd, 2002.Ultimo acesso em 27 dejulho de 2005. Disponıvel em:<http://www.featuredrivendevelopment.com>.

PAETSCH, F. Requeriments engineering in agile software development. p. 72, 2003. DiplomaThesis.

PAIR Programming, an Extreme Programming practice. Object Mentor Incor-porated, 2001.Ultimo acesso em 17 de dezembro de 2004. Disponıvel 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. Disponıvelem:<http://www.gamasutra.com/education/theses/20030623/piccinno01.shtml>.

PRESSMAN, R. S.Engenharia de Software. Sao Paulo: Makron Books, 2005.

RULE, D. S. Generic P2P Architecture, Tutorial and Exam-ple. 2004. Ultimo acesso em 6 de julho de 2005. Disponıvel em:<http://www.codeproject.com/vbscript/GenericP2PArchitecture.asp>.

SMITH, J. A comparison of rupc and xp. Rational Software Corporation, May 2001. RationalSoftware White Paper.

SOMERVILLE, I. Software Engineering. 6th. ed. [S.l.]: Addison Wesley Professional, 2003.

USERNOMICS.User Interface Design & Usability Testing. Usernomics, 2005. URL.Ultimoacesso em 19 de julho de 2005. Disponıvel 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 deComputacao, 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 25de julho de 2005. Disponıvel em:<http://cppunit.sourceforge.net/cgi-bin/moin.cgi>.

WIKIPEDIA. ISO 9241-11. 2005.Ultimo acesso em 21 de julho de 2005. Disponıvel em:<http://pt.wikipedia.org/wiki/ISO9241-11>.

Mapeamento do processo de modelagem em Extreme Programming no domínio de jogos

Documents

Transcript of Mapeamento do processo de modelagem em Extreme Programming no domínio de jogos