Upload
abelmon-bastos
View
172
Download
54
Embed Size (px)
DESCRIPTION
Monografia apresentada ao Curso de graduação em Ciência da Computação pela Universidade Federal da Bahia, como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação (2005).Orientadora: Profa. Christina von Flach Garcia Chavez
Citation preview
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>.