modelo seja suficiente. O desenvolvimento de software agil nao e serial, e iterativo e incremental, evolucionario. Com uma abordagem evolucionaria, a modelagem do modelo e feita no momento em que e necessaria (just in time), durante as iteracoes de desenvolvimento e sessoes de discussao do modelo. No que diz respeito as iteracoes do modelo, no inicio de cada iteracao de construcao, a equipe deve planejar o trabalho que sera feito naquela iteracao. Times ageis implementam requisitos por ordem de prioridade. Para isso poder ser feito com sucesso, a equipe deve ser capaz de estimar exatamente o trabalho necessario para cada requisito, e entao com base em seu conhecimento das iteracoes anteriores, estimar o esforco que sera necessario para a iteracao corrente, conforme ilustra a figura 2 [1]. Figura 2. Processo de gerenciamento de mudanca de requisitos ageis. O AMDD funciona por diversas razoes: Atende as necessidades de planejamento de projeto, pois atraves da identificacao dos requisitos (em alto nivel), e atraves da identificacao de uma arquitetura na primeira fase, se tem informacoes suficientes para uma estimativa inicial de custo e de tempo.Riscos tecnicos sao gerenciaveis, pois os esforcos iniciais de modelagem arquiteturais permitem que sejam identificadas areas de maior risco tecnico.Minimizacao de perdas, pois uma abordagem just in time permite focar somente em aspectos do sistema que irao ser construidos (e nao em aspectos do modelo que nao tem muita importancia para o usuario).Melhores questoes sao levantadas, pois quanto mais se discute o requisito de um modelo, mais conhecimento do dominio se adquire.Usuarios dao melhores respostas, pois estes tambem tem um melhor conhecimento do sistema que esta sendo construido, porque lhes e entregue regularmente pacotes de software, e dessa forma ele esta habilitado a fornecer feedbacks concretos. 2. TRABALHOS RELACIONADOS 2.1. Trabalho 1 O objetivo do trabalho [3] e investigar se, e como, alguns principios e praticas ageis podem ser aplicadas no desenvolvimento de jogos. Esta pesquisa pode ajudar a desmistificar a impressao de que a adocao de praticas ageis para o desenvolvimento de jogos e um processo dificil. Foi possivel identificar um ciclo comum de desenvolvimento em diferentes times: o modelo em cascata, que foi adaptado para a producao de jogos. Dois estagios deste modelo podem ser salientados: a definicao das regras do jogo e a producao da documentacao do projeto [3]. As regras do jogo determinam o comportamento e interacao entre os personagens e o ambiente, e podem ser vistos como requisitos. O projeto de um jogo envolve nada mais do que a criacao de um conjunto de regras, geralmente atraves de um processo informal, que envolve a equipe de desenvolvimento. A documentacao do projeto e a principal (e unica) documentacao do jogo. Seu objetivo e descrever e detalhar os mecanismos do jogo (o que cada jogador e capaz de fazer dentro do ambiente do jogo, e como isso pode leva-lo a uma experiencia satisfatoria). Tambem contem os componentes principais da historia e a descricao dos cenarios do jogo e das acoes dos jogadores. Muitos desenvolvedores a utilizam como especificacao funcional, servindo como base para o design arquitetural [3]. Uma