Desenvolvendo a REDEPESQ utilizando uma abordagemágil

Vilnei L. Bottari, Marcos J. R. Barrêto, Leonardo A. Z. Brum, Rafael M. França,Gabriel V. Passos, Rogério P. C. Nascimento

∗

Universidade Federal de SergipeDepartamento de Computação

Sergipe, Brazilvilneilb@gmail.com, marcosjrbarreto@gmail.com, lazb18@yahoo.com.br,

rafaelmf@dcomp.ufs.br, gabrielpassos@yahoo.com.br, rogerio@ufs.br

ABSTRACTThis paper shows a short introduction to Web applicationsdevelopment with agile methodologies. For this, the pin-ciples and values of the Agile Manifesto will be presented.Later, many examples of these methodologies will be dis-cussed, with more attention on XP and Scrum, introducingtheir practices and project’s life cicle. Beside this, characte-ristics of Web applications will be described and the Ruby onRails, a tool for developing these applications and that alsouses some aspects in agile methodologies, will be shown. Atthe end, a case study, using these methodologies and tools,will be proposed and some points will discussed about theresearch that was made.

RESUMOEste artigo apresenta uma breve introducao ao uso de meto-dologias ageis no desenvolvimento de aplicacoes Web. Paratanto, sao apresentados os princıpios e valores do ManifestoAgil. Em seguida, diversas metodologias sao apresentadas,com enfase no XP e no Scrum, introduzindo as suas praticase seus respectivos ciclos de vida. Alem disso, sao descritasas caracterısticas das aplicacoes Web, e e apresentada umaferramenta para o desenvolvimento das mesmas, o Ruby onRails, a qual aborda aspectos das metodologias ageis. Aofinal, e proposto um estudo de caso utilizando as metodo-logias e ferramentas apresentadas neste artigo e sao feitasconsideracoees sobre a pesquisa realizada.

Categorias e Descritores de TemasD.2.18 [Software Engineering]: Software Engineering Pro-cess; D.2.0 [Software Engineering]: General—Softwareengineering for Internet projects; J.8 [Computer Appli-cations]: Internet Applications

∗orientador

Palavras-chaveScrum, XP, agil, ruby, rails, Web, Desenvolvimento de soft-ware

1. INTRODUÇÃOAs metodologias ageis vem ganhando popularidade na in-dustria de software por elas utilizarem uma serie de prati-cas aceitaveis e controversas. A industria de acordo com ascaracterısticas do projeto (objetivo, escopo, requisitos, fer-ramentas, arquitetura e tamanho) vai determinar qual e ametodologia que melhor se adapta.

Segundo Scott W. Ambler [3], “modelagem agil e uma meto-dologia baseada na pratica para modelagem efetiva de siste-mas baseados em software. A modelagem agil e uma colecaode praticas, guiadas por princıpios e valores que podem seraplicados por profissionais de software no dia a dia. Mo-delagem agil nao e um processo prescritivo, ela nao defineprocedimentos detalhados de como criar um dado tipo demodelo (...) ela prove conselhos de como ser efetivo comomodelador. Pense em metodologia agil como uma arte, naocomo uma ciencia”.

As metodologias ageis surgiram devido as experiencias enecessidades de alguns desenvolvedores que estavam cansa-dos da burocracia existente nas metodologias de desenvol-vimento tradicionais e resolveram utilizar praticas que visa-vam aumentar a produtividade e diminuir trabalhos desne-cessarios.

Este artigo esta organizado na seguinte forma: na secao 1.1serao apresentados os princıpios e valores contidos no ma-nifesto agil; na secao 2 serao introduzidos os exemplos maiscomuns de metodologias ageis; na secao 3 o XP e Scrum se-rao abordados profundamente e sera discutido o frameworkRuby on Rails juntamente a sua relacao com as aplicacoesWeb; na secao 4 sera apresentado e discutido o estudo decaso que consiste na aplicacao REDEPESQ; na secao 5 se-rao feitas as consideracoes finais e mostradas algumas des-vantagens deste tipo de metodologia.

1.1 Manifesto ÁgilEstes desenvolvedores perceberam em 2001, que suas meto-dologias tinham muito em comum e decidiram criar a Ali-

anca Agil e um manifesto para o desenvolvimento de sofwareutilizando as metodologias ageis [6]. O manifesto foca emalguns valores como:

i. Individualidade e interacoes sobre processos e ferramentas;

ii. Software funcional sobre documentacao compreensiva;

iii. Colaboracao do cliente sobre negociacao de contrato;

iv. Responder a mudancas mais do que seguir um plano.

Alem desse valores o manifesto ainda apresenta 12 princıpiosque os desenvolvedores ageis devem seguir:

i. Nossa maior prioridade e satisfazer o cliente mediante arapida e contınua entrega de software valioso;

ii. Sao bem-vindas as mudancas nos requisitos, ainda quetardiamente no desenvolvimento. Os processos ageis trans-formam as mudancas em vantagem competitiva para os cli-entes;

iii. Entregar software funcional com frequencia, a partir dealgumas semana a alguns meses, com preferencia para prazoscurtos;

iv. Empresarios e desenvolvedores devem trabalhar juntosdiariamente durante todo o projeto;

v. Desenvolva projeto em torno de indivıduos motivados.Deem-lhes o ambiente e o apoio que precisarem, e confiemneles para fazer o trabalho;

vi. O metodo mais eficiente e eficaz de transmitir informacaopara e com a equipe de desenvolvimento esta na conversacara-a-cara;

vii. Software funcional e a principal medida de progresso;

viii. Processos ageis promovem o desenvolvimento sustenta-vel. Os patrocinadores, desenvolvedores e usuarios devemser capazes de manter um ritmo constante indefinidamente;

ix. Atencao contınua a excelencia da tecnica e bom designaumenta a agilidade;

x. Simplicidade - a arte de maximizar a quantidade de tra-balho nao feito - e essencial;

xi. As melhores arquiteturas, requisitos, e modelos emergemde equipes auto-organizaveis;

xii. Periodicamente, a equipe reflete sobre como se tornarmais eficaz e, em seguida, sintoniza e ajusta o seu compor-tamento em conformidade.

2. METODOLOGIAS E TECNOLOGIASExistem diversas metodologias ageis, dentre elas as mais co-nhecidas sao: XP (eXtrem Programming); SCRUM; FDD(Feature Driven Development); Crystal Family; DSDM (Dy-namic Systems Development Method); OpenUP (Open Uni-fied Process); AUP (Agile Unified Process) e ASD (Adapta-

tive Software Development).

A seguir iremos fazer uma breve descricao sobre algumasmetodologias citadas acima.

2.1 Crystal FamilyAlistair Cockburn e o criador das metodologias que com-poem a Crystal Family. Tais metodologias possuem carac-terısticas em comum porem sao diversas, de forma a satisfa-zer projetos individuais, de uma maneira geral pequenos, deacordo com os requisitos apresentados, atraves de princıpiosque atendem circunstancias variadas de diferentes projetos.

Cada metodologia integrante desta famılia e associada a umacor que indica o grau de complexidade da mesma, ou seja,quanto mais escura a cor, mais complexa a metodologia. Se-gundo Cockburn [5], ha tres metodologias Crystal: CrystalClear, Crystal Orange e Cristal Web Orange. Ainda se-gundo o mentor destas metodologias, a principal diferencaentre as cores esta na quantidade de pessoas envolvidas nasequipes. Ja que essa diferenciacao de cores baseia-se na com-plexidade do projeto, por conseguinte, este demandara umamaior quantidade de pessoas envolvidas a medida em que acor escurece.

2.2 FDDDesenvolvimento Dirigido a Funcionalidades. Como o prı-prio nome sugere, as funcionalidades sao o objeto desta me-todologia. Sendo assim, Palmer definiu que “FDD consisteem cinco processos sequenciais e prove os metodos, tecni-cas, e diretrizes necessarias para que os membros do projetopossam entregar um sistema funcional. Alem disso, FDD in-clui os papeis, regras, metas e fases de desenvolvimento bemdefinidas, os quais sao necessarios dentro de um projeto” [9].

2.3 DSDMDSDM e um framework para desenvolvimento de RAD (Ra-pid Application Development) mantido por um consorcio[1],que nao visa lucro. A ideia fundamental atras da DSDMe abranger a maior quantia possıvel de funcionalidades emum produto, e ir ajustando tempo e recursos para alcancaressa funcionalidade. DSDM e dividido em cinco fases: es-tudo de viabilidade, estudo empresarial, repeticao funcionaldo modelo, repeticoes de planejamento/desenvolvimento eimplementacao XP e SCRUM.

2.4 ASDASD possui seu foco de atuacao principalmente nos proble-mas de sistemas complexos, para grandes desenvolvimentos.O metodo estimula fortemente o desenvolvimento com repe-ticoes e uma constante prototipacao. Um projeto de ASDe dividido em ciclos compostos de tres fases. As fases dosciclos sao Especulacao, Colaboracao, e Aprendizado, carac-terizadas em [7].

i. Especulacao: utilizada no lugar de planejamento, pois, umplano geralmente e visto como algo onde incerteza e umafraqueza, e no qual divergencias indicam fracasso;

ii. Colaboracao: realca a importancia de trabalho de equi-pe como o meio de sistemas de automudancaa em desenvol-vimento;

iii. Aprendizado: devido a necessidade para reconhecer ereagir a decisoes erradas e o fato que os requisitos podemmudar durante o desenvolvimento.

2.5 XP e SCRUMComo um dos objetivos deste trabalho e a utilizacao deProgramacao Extrema (XP), juntamente com SCRUM, taismetodologias de desenvolvimento agil serao abordadas commais profundidade em seguida.

3. DESENVOLVENDO APLICAÇÕES WEBUTILIZANDO XP, SCRUM E RUBY ONRAILS

Neste trabalho iremos abordar uma metodologia mista deXP e SCRUM. Utilizaremos as diversas praticas existentesnestas metodologias para desenvolver software. Falaremosprimeiramente sobre cada uma delas separadamente e de-pois iremos mostrar que e possıvel utilizarmos as duas me-todologias no processo de desenvolvimento.

3.1 XPA metodologia agil mais conhecida e estudada e a Progra-macao Extrema (do ingles eXtreme Programming). SegundoBeck[4], trata-se de uma ”metodologia agil para equipes pe-quenas a medias desenvolvendo software com requerimentosvagos ou que mudam frequentemente”. Como toda meto-dologia agil, o codigo e a principal tarefa. Tal metodologiabaseia-se nos ditames do manifesto agil.

3.1.1 Ciclo de vida em XPO ciclo de vida do software em programacao extrema e cons-tituıdo por seis fases, conforme exibe a Figura 1. Cada umadelas sera descrita imediatamente a seguir.

Figura 1: Fases do ciclo de vida do software em XP[8]

Na fase de exploracao, o cliente descreve os requisitos funci-onais que o primeiro release deve conter atraves dos chama-dos cartoes de estoria (story cards) em linguagem simples.Ha tambem nesta fase a familiarizacao da equipe de projetocom as tecnologias, ferramentas, e praticas a serem utiliza-das, alem de serem exploradas as possıveis arquitetura dosistema.

Durante a fase de planejamento, ocorre a priorizacao das es-torias de usuario, resultando na determinacao definitiva de

quais delas farao parte do primeiro release. O planejamentotambem abrange estimativas de esforco para a implementa-cao de cada estoria.

A fase de iteracoes para release consiste de diversas iteracoesantes do primeiro release do sistema. Estas iteracoes sao de-finidas tomando por base as informacoes obtidas durante afase de planejamento. Na primeira iteracao sao implemen-tadas apenas as principais funcionalidades, conforme foramdocumentadas pelo cliente. Ja na ultima, o sistema estapreparado para entrar em producao.

Na fase de producao, sao feitos testes adicionais no sistema,alem de uma verificacao de seu desempenho, no intuito delibera-lo sem problemas ao cliente. E possıvel detectar novasalteracoes a serem feitas no sistema nesta fase.

A primeira liberacao do sistema, segue-se a fase de manu-tencao, cuja finalidade e dar suporte ao sistema em funcio-namento. Nesta fase, ha uma divisao do esforco da equipede projeto, pois simultaneamente novas iteracoes do sistemasao implementadas.

A ultima fase do ciclo de vida em XP e a de morte, queocorre quando nao ha mais estorias de usuario a serem im-plementadas e requisitos nao-funcionais, como desempenho,estao satisfatoriamente atendidos. Resta, entao, realizar adocumentacao do sistema. A morte tambem pode acontecerquando se constata a inviabilidade de uma iteracao adicionalao sistema.

3.1.2 Práticas do XPA programacao extrema objetiva um rapido desenvolvimentode software com sucesso. Iteracoes curtas e feedback rapido,participacao do cliente, comunicacao e coordenacao, integra-cao continuada e testes, posse coletiva do codigo, documen-tacao limitada e programacao em par estao entre as princi-pais praticas do XP. Essas sao apresentadas logo abaixo:

i. Jogo de planejamento - Estreita interacao entre progra-madores e clientes. Estes contam suas historias, enquandoaqueles estimam os esforcos que se farao necessarios para aimplementa-las, para decidirem sobre o escopo e tempo dasliberacoes.

ii. Liberacoes em curto tempo - Um sistema nao muitocomplexo e construıdo rapidamente e atualizado frequente-mente em ciclos bastante curtos. Novas versoes sao liberadasno mınimo mensalmente.

iii. Metafora - O sistema e definido por uma metafora oupor um conjunto de metaforas entre o cliente e os progra-madores. Estas guiam todo o desenvolvimento descrevendocomo o sistema funciona, onde as equipes de desenvolvi-mento utilizam um “sistema de nomes” e uma descricao dosistema sem a utilizacao de termos tecnicos. Ou seja, umametafora e uma forma dos programadores conseguirem secomunicar de forma adequada com os clientes.

iv. Design simples - Um programa construıdo atraves dometodo XP deve ser o mais simples possıvel satisfazendo asatuais necessidades, sendo que o foco esta em prover valorde negocio. A enfase esta em desenvolver a solucao mais

simples possıvel que possa ser implementada no momento.Codigo muito complexo e removido imediatamente.

v. Teste - O desenvolvimento do software e dirigido por tes-tes, sendo que ha dois tipos de testes: testes unitarios saoimplementados antes do codigo pelos proprios desenvolvedo-res para testar a estoria implementada e os testes de aceita-cao sao desenvolvidos pelos usuarios ou por uma equipe detestes externa a equipe de desenvolvimento que tem comointuito testar todo o sistema.

vi. Reconstrucao - As equipes XP reestruturam o sistemaremovendo possıveis duplicacoes, melhorando a comunica-cao, simplificando e adicionando flexibilidade durante todoo desenvolvimento, mantendo a clareza do software, sem am-biguidade, com alta comunicacao, simples, porem completo.

vii. Programacao em par - Os programadores XP produ-zem o codigo em duplas, ou seja, dois programadores traba-lhando juntos na mesma maquina. Muitos experimentos temmostrado que a programacao em dupla produz software demelhor qualidade com um custo similar ou menor do que oproduzido por programadores trabalhando individualmente.

viii. Posse coletiva - Qualquer um pode mudar qualquerparte do codigo a qualquer momento. Todo o codigo per-tence a todos os programadores. Essa caracterıstica permiteque a equipe trabalhe com velocidade maxima, uma vez queas alteracoes podem ser feitas sem atrasos, pois todos temliberdade para faze-las.

ix. Integracao Continuada - Um novo pedaco de codigo eintegrado ao codigo base assim que ele estiver pronto. Assim,o sistema e integrado e construıdo varias vezes ao dia. Issomantem todos os programadores em sintonia e possibilitaum progresso rapido. Todos os testes sao realizados e devempassar pelas modificacoees de codigo para serem aceitos.

x. 40 horas por semana - Programadores exaustos co-metem mais erros. As equipes XP nao trabalham por umtempo excessivo; elas trabalham no maximo 40 horas porsemana. Nao e permitido que duas semanas em seguida ex-cedam esse tempo. Se isso acontecer, deve ser tratado comoum problema a ser resolvido.

xi. Cliente no local - O cliente tem que estar presentee disponıvel todo o tempo com a equipe para determinaras suas necessidades e responder as duvidas dos programa-dores. Essa pratica melhora a comunicacao e gera menosdocumentos, o que, em geral, e uma das partes mais carasem um projeto de software.

xii. Padroes de codigo - As regras de codigo existem e saoseguidas pelos programadores. A comunicacao atraves docodigo deve ser enfatizada, de modo que todos os programa-dores o escrevam da mesma forma para garantir a clarezado codigo.

xiii. Area de trabalho aberta - Uma sala grande comdiversos cubıculos e prioridade. Pares de programadores de-vem ser colocados no centro do local.

xiv. Regras justas - A equipe tem as suas proprias regrasa serem seguidas, mas podem ser modificadas a qualquerhora, desde que se chegue a um acordo e seu impacto sejaavaliado.

3.2 SCRUMEntre as metodologias ageis para desenvolvimento de soft-ware esta o Scrum, que parte do pressuposto de que o pro-cesso de desenvolvimento e complexo e imprevisıvel, reque-rendo, portanto, um gerenciamento diferente em relacao aoque e proporcionado pelas abordagens das metodologias tra-dicionais. Ken Schwaber [10], valendo-se de conceitos oriun-dos do controle de processo industrial, classifica os processosem teoricos, que sao totalmente definidos em seus passos, eempıricos, em que as atividades sao tratadas como caixas-pretas. Segundo Schwaber, as metodologias tradicionais tra-tam o desenvolvimento de software a partir da abordagemteorica, o que muitas vezes produz resultados imprevisıveise fora da capacidade de controle da metodologia utilizada.Scrum, ao contrario, prove flexibilidade ao desenvolvimentocom sua abordagem predominantemente empırica, tratandoo processo como uma “caixa-preta controlada”, ou seja, haflexibilidade suficiente para que eventuais mudancas duranteo processo, ainda que imprevisıveis, permanecam sob con-trole.

Como e caracterıstico das metodologias ageis, Scrum se pautano princıpio da mutabilidade. Variaveis como requisitos docliente, tempo, competitividade, qualidade e recursos saoutilizadas na elaboracao de um planejamento inicial do pro-cesso de desenvolvimento. Porem, ao longo do processo,pode haver alteracoes nos requisitos em relacao ao que foidefinido inicialmente, devendo tais alteracoes serem geren-ciadas pela metodologia.

Entre as empresas que ja utilizaram Scrum com sucesso emprojetos de desenvolvimento de software estao Fuji-Xerox,Honda, Canon, Epson, NEC, Brother, 3M, e Hewlett-Packard.A seguir, serao apresentadas em maiores detalhes as fases doprocesso de desenvolvimento na metodologia Scrum.

3.2.1 Cilco de vida do ScrumComo ja foi mencionado, Scrum assume que as etapas deanalise, projeto e desenvolvimento do software sao imprevi-sıveis. Diante disso, a metodologia utiliza um mecanismo decontrole para gerenciar os riscos e assegurar a flexibilidadedo processo. A Figura 2 apresenta as fases do processo nametodologia Scrum.

Scrum divide o processo de software em tres grandes etapas:pregame, onde ha o planejamento inicial do desenvolvimentoe definicao da arquitetura do software; game, em que ocorrea maior parte das atividades de desenvolvimento; postgame,na qual o software e preparado para seu release final. Pode-se afirmar que as fases de pregame e postgame encaram oprocesso valendo-se da abordagem teorica, conforme foi de-finida anteriormente, enquanto a fase de game, que e o “co-racao” do Srcum, e totalmente empırica.

A fase de pregame e constituıda basicamente de duas ativi-dades: o planejamento inicial do desenvolvimento, em queos requisitos do sistema sao documentados em um artefatochamado product backlog, sendo tambem feitas estimativas

Figura 2: Fases do processo na metodologia Scrum[10]

de prazos e custos para o release definido; a outra atividadedefine a arquitetura do sistema, ou seja, de que maneira osrequisitos do product backlog serao implementados.

A fase de game constitui-se de um ciclo iterativo de de-senvolvimento no qual os requisitos do product backlog saointerpretados no intuito de definir tarefas concretas, denomi-nadas sprints pela metodologia. Cada sprint e documentadoem seu respectivo sprint backlog. O ciclo dos sprints, similarao PDCA - plan, do, check and act, utilizado em gestao dequalidade - e composto por quatro etapas e implementamo que foi definido em um determinado sprint backlog. Asetapas do ciclo sao as seguintes:

i. Desenvolvimento (develop): define as mudancas ne-cessarias para a implementaao do sprint backlog, implemen-tando, testando e documentando cada uma delas;

ii. Corte (wrap): cria uma versao executavel daquilo quefoi implementado na etapa anterior;

iii. Revisao (review): analisa o progresso do desenvolvi-mento, soluciona eventuais problemas, avalia os riscos e adi-ciona novos itens ao sprint backlog, se necessario;

iv. Ajuste (adjust): consolida as informacoes obtidas nafase de revisao a fim de preparar o ciclo para o retorno afase de desenvolvimento.

A fase de postgame corresponde a uma atividade denomi-nada pelo Scrum de fechamento (closure), em que e efetuadoo release final do software, juntamente com outras atividadesnecessarias, como testes, documentacao final e integracao.

3.3 Aplicações WebAs Aplicacoes Web tem como principal caracterıstica a dis-tribuicao das aplicacoes, que podem ser acessadas por variosusuarios de qualquer lugar e ao mesmo tempo, utilizandoapenas um navegador web. Essas aplicacoes geralmente pas-sam por constantes mudancas, para se adaptaram as neces-sidades dos negocios e acompanharem a constante evolucaotecnologica que ocorre na internet.

No inıcio da era da internet, existiam poucas aplicacoes Web

e as que existiam eram utilizadas para fins especıficos e limi-tados. Com a evolucao das linguagens de programacao paraa Web, surgiram novas aplicacaes focadas nos mais diversosnegocios e grandes empresas passaram a oferecer servicos viaInternet.

Com o advento da Web 2.0 o foco das aplicacoes deixou deser somente nos negocios e comecou a ter um foco maiorcom a interatividade com o usuario. O usuario deixou deser um mero utilizador das aplicacoes e passou a participardo processo de criacao de conteudo. Neste contexto, as mu-dancas nestas aplicacoes passam a ser mais frequentes, jaque as aplicacoes tendem a serem desenvolvidas para satis-fazer o mais rapido possıvel as necessidades dos usuarios, eacompanhar a evolucao acelerada das diversas tecnologiasque fazem as aplicacoes Web.

Pratica ageis como entregas frequentes, flexibilidade paraaceitar mudanca e simplicidade sao bastante propıcias paraeste tipo de aplicacao.

3.4 Ruby on RailsO Ruby on Rails e um meta-framework para desenvolvi-mento de aplicacoes Web. Ele foi desenvolvido sobre a lin-guagem Ruby, e e distruibuıdo como software livre. Este fra-mework permite a geracao de uma estrutura bem definadapara aplicacoes Web utilizando o padrao MVC (Model-View-Controller).

O MVC e um padrao arquitetural criado em 1979 por TrygveReenskaug para desenvolvimento de aplicacoes interativas.No desenvilmento, a aplicacao e quebrada em tres tipos decomponentes: Modelo, Visao e Controlador, como mostradona Figura 3.

O modelo e responsavel por manter o estado da aplicacao.Este estado pode ser permanente (que sera guardado embanco de dados) ou transacional (fara apenas algumas inte-racoes com o usuario). O modelo alem de guardar os dados,ele tambem realiza todas as regras de negocio [13].

A visao e responsavel por apresentar os dados do modelopara o usuario, e fazer as requisicoes para o controlador.

O controlador recebe as requisicoes do visao, interage comos modelos e apresenta a visao apropriada para o usuario.Ele e responsavel pelo fluxo da aplicacao.

Figura 3: Ilustracao do MVC[13]

O Rails cria a estrutura das aplicacoes utilizando esse pa-

drao, e a programacao e feita em cada uma das camadasseparadamente e elas se integram quando o programa e exe-cutado.

Os projetos em Rails seguem uma dupla de concentos cha-ves. Esses conceitos agilizam o desenvolvimente de aplica-coes Web. O primeiro deles, o DRY(Don’t Repeat Yourself),prega que as repeticoes de codigo devem ser evitadas, paraagilizar o desenvolvimente e facilitar as modificacoes, ja queos codigos tendem a ser mais limpos.

O segundo conceito, Conversao sobre Configuracao, possi-bilita que aplicacoes Rails sejam desenvolvidas e postas emproducao sem que haja a configuracao de diversas coisas, quegeralmente sao feitas em arquivos XML complicados. Comesses dois conceitos os codigos das aplicacoes Rails tendema ser simples e de facil entendimento.

Outro fator positivo para os aplicacoes Rails e a linguagemRuby[2]. Esta linguagem criada por Yukihiro Matsumoto,foi projetada tanto para a programacao em larga escala comopara a codificacao rapida aproveitando as melhores ideiasdas linguagens da epoca. Ela e um linguagem interpretada,com tipagem dinamica e tipagem forte, orientada a objetos.Tem diversas semelhancas com o Python, Perl e Smalltalk.A linguagem possui uma sintaxe enxuta e de facil compre-ensao, alem de possibilitar a criacao de metodos em temporeal.

4. DESENVOLVENDO A REDEPESQNeste trabalho iremos utilizar praticas ageis para o desenvol-vimento de uma aplicacao Web, utilizando o Ruby on Railscomo framework. Essa aplicacao consiste numa rede socialentre pesquisadores, com informacoes pessoais e proficionaisque podem ser disponibilizadas pelo pesquisador para com-por o seu perfil. Essas informacoes incluem os trabalhosde pesquisa que ele desenvolveu assim como seus resultado,dados de patentes que possui, e dados profissionais diversos.

A REDEPESQ possibilita uma maior interacao entre os pes-quisadores, que poderao trocar informacoes profissionais eformar grupos de pesquisa, utilizando a aplicacao. A aplica-cao tambem visa possibilitar o acompanhamento de projetosde pesquisa que estao sendo desenvolvidos pelos grupos depesquisa ou pesquisadores cadastrados.

4.1 Unindo XP e ScrumPara o desenvolvimento da REDEPESQ utilizaremos umconjunto de praticas do Scrum e da XP. A escolha dessaspraticas visa a adaptacao das metodologias ao ambiente emque esta aplicacao sera desenvolvida. Citaremos nessa se-cao as praticas que serao utilizadas e tambem os possıveisbenefıcios que elas trarao ao ambiente de desenvolvimento.

Da XP retiramos algumas praticas pertinentes para o desen-volvimento:

i. Desenvolvimento dirigido a testes: esta pratica primapela qualidade do software. Os testes sao implementadosantes de qualquer funcionalidade. Isso ajuda a equipe aconhecer melhor os requisitos antes de implementa-los. Ostestes servem tambem como documentacao executavel.

ii. Integracao continuada: ferramentas de integracao ede versionamente de codigo, quando utilizadas no desenvol-vimento de software, possibilitam uma menor repeticao decodigo e uma maior qualidade da aplicacao.

iii. Estorias do usuario: As funcionalidades serao descri-tas pelo usuario na forma de historia.

Ja do Scrum, alguma praticas devem ser destacadas:

i. Reuniao diaria: Esta reuniao que serve para que aequipe apresente os resultados diarios e conheca e discutaos problemas encontrados, auxilia na integracao da equipe,e motiva os participantes.

ii. Product Backlog: As funcionalidades da REDEPESQdepois de discutidas na fase de pregame serao adicionadasao product backlog. Depois cada item da Produckt Backlogpodera ser dividido e fazer parte do Sprint Backlog. Nafigura 4 temos um exemplo do Product Backlog.

iii. Sprint Backlog: Todas as funcionalidades presentes noSprint Backlog serao transformadas em historias, e depoisserao implementadas.

Figura 4: Ilustracao do product backlog

4.2 Utilizando o Ruby on Rails como frameworkUtilizaremos o Ruby on Rails em conjunto com as praticasexpostas no item anterior para obter um maior benefıcio doframework e das metodologias aplicadas. O Rails foi desen-volvido para incorporar grande parte dessas praticas cita-remos a seguir as principais funcionalidades que ele oferecepara auxiliar o desenvolvimento:

i. ORM (Object-Relational Mapping): Essa bibliotecamapeia tableas de banco de dados em classes. Se o banco dedados tem uma tabela chamada pesquisadores, o programatera uma classe chamada Pesquisador. Linhas da tabelasao representados como objetos desta classe. Os modelosdo Rails sao geralmente classes ORM. O ORM diminui aprogramacao em SQL e centraliza todas as chamadas a basede dados na camada de modelo.

ii. Migrations: Esta funcionalidade do Rails permite quemodificacoes no banco de dados sejam feitas facilmente du-rante o desenvolvimento, diminuindo os erros que possamocorrer caso o sistema esteja em producao.

iii. Generator : Esta funcionalidade permir que diversaspartes de sua aplicacao sejam geradas automaticamente se-guindo um padrao definido. E possivel criar modelos, con-troladores, visoes e testes automaticamente utilizando os ge-nerators. Ele ajuda a manter o estrutura da aplicacao.

iv. Templates: Seguindo o conceito de DRY, os templatesservem para que sejam evitadas repeticoes de codigos des-necessarias.

v. Plugins: Possibilitam que o conceito de reuso de com-ponentes seja utilizando. Diversos plugins estao disponıveispara a comunidade Rails, evitando assim que a equipe sepreocupe em implementar funcionalidades gerais que ja es-tao implementadas e foquem no negocio especıfico da suaaplicacao.

5. CONCLUSÃO E TRABALHOS FUTUROSConcluımos neste trabalho que apesar das metodologias ageisauxiliarem muito o desenvolvimento de aplicacoes Web elasainda possuem algumas falhas[14], como a negociacao decontrato com os clientes, utilizacao de algumas praticas emequipes distribuıdas geograficamente[11], gerenciamento deequipes grandes[12], etc. Porem existem casos de sucesso emdiversas empresas que acreditaram e utilizam essas metodo-logias. Algumas dessas empresas sao bastante conhecidas naarea, como a IBM e a Microsoft.

Acreditamos que para o sucesso do desenvolvimento de umaaplicacao utilizando metodologias ageis a equipe deve, antesde tudo, incorporar os princıpios e valores da metodologia,e adaptar a metodologia para a realidade da sua empresa,desta forma, os projetos terao uma grande possibilidade desucesso.

5.1 Trabalhos futurosComo trabalhos futuros propomos um estudo aprofundadode como as praticas das metodologias ageis podem ser adap-tadas para a obtencao de algumas das diversas certificacoesexistentes no mercado (MPS.BR, CMM, PMBOK) nos seusdiversos nıveis, sem que as caracterısticas dessa forma dedesenvolvimento sejam perdidas.

6. REFERÊNCIAS[1] DSDM site. http://www.dsdm.org. visitado em 8 de

dezembro de 2008.

[2] Ruby language site. http://ruby-lang.org. visitadoem 8 de dezembro de 2008.

[3] Ambler, S. W. Agile Modeling (AM): Modeling anddocumentation rethunk.http://tarpit.rmc.ca/cficse/2002/lectures/GL/

Agile%20Modeling%20and%20Agile%20Data.pdf.Visitado em 12 de novembro de 2008, 2002.

[4] Beck, K. eXtreme Programming explained: Embracechange. Addison-Wesley, 2000.

[5] Cockburn, A. Agile Software Development.Cockburn & Highsmith Series Editors, 2002.

[6] Fowler, M., and Highsmith, J. The AgileManifesto.http://hristov.com/andrey/fht-stuttgart/The_

Agile_Manifesto_SDMagazine.pdf. Visitado em 12 denovembro de 2008, 2001.

[7] Highsmith III, J. A. Adaptive Software Development:A Collaborative Approach to Managing ComplexSystems, 1a ed. Dorset House Publishing Company,Incorporated, 1999.

[8] Man, L. C., Mendes, P. H. R., and de Queiroz,R. N. eXtreme programming. http://www.dc.ufscar.br/~rosangel/mds/Seminarios/xp.doc.Visitado em 20 de novembro de 2008, 2006.

[9] Palmer, S. R., and Felsing, J. M. A PracticalGuide to Feature-Driven Development, 1a ed. PrenticeHall, 2002.

[10] Schwaber, K. Scrum development process.http://jeffsutherland.com/oopsla/schwapub.pdf.Visitado em 20 de novembro de 2008.

[11] Schummer1, T., and Schummer, J. Support fordistributed teams in eXtreme programming.http://www.ipsi.fraunhofer.de/~publications/

concert/2001/xp00.pdf. Visitado em 12 de novembrode 2008, 2001.

[12] Sutherland, J., Viktorov, A., and Viktorov, A.Adaptive engineering of large software projects withdistributed/outsourced teams.http://necsi.org/events/iccs6/papers/

ee6637fd0a1f958002d8f242162b.pdf. Visitado em 12de novembro de 2008, 2006.

[13] Thomas, D., and Hansson, D. H. Agile WebDevelopment with Rails, 2a ed. The PragmaticBookshelf, 2007.

[14] Turk, D., France, R., and Rumpe, B. Limitationsof agile software processes. http://www4.in.tum.de/publ/papers/XP02.Limitations.pdf. Visitado em 12de novembro de 2008, 2002.