Este artigo apresenta uma breve introdução ao uso de metodologias ágeis no desenvolvimento de aplicações Web, como Scrum e XP. Primeiro, descreve os princípios do Manifesto Ágil e exemplos de metodologias como Crystal, FDD e DSDM. Em seguida, detalha XP e Scrum, introduzindo o framework Ruby on Rails. Por fim, propõe um estudo de caso utilizando essas metodologias e ferramentas.

1. 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 Sergipe
Departamento de Computação
Sergipe, Brazil
vilneilb@gmail.com, marcosjrbarreto@gmail.com, lazb18@yahoo.com.br,
rafaelmf@dcomp.ufs.br, gabrielpassos@yahoo.com.br, rogerio@ufs.br
ABSTRACT Palavras-chave
This paper shows a short introduction to Web applications Scrum, XP, agil, ruby, rails, Web, Desenvolvimento de soft-
´
development with agile methodologies. For this, the pin- ware
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, introducing
their practices and project’s life cicle. Beside this, characte-
1. INTRODUÇÃO
As metodologias ageis vem ganhando popularidade na in-
´
ristics of Web applications will be described and the Ruby on
d´stria de software por elas utilizarem uma s´rie de pr´ti-
u e a
Rails, a tool for developing these applications and that also
cas aceit´veis e controversas. A ind´stria de acordo com as
a u
uses some aspects in agile methodologies, will be shown. At
caracter´
ısticas do projeto (objetivo, escopo, requisitos, fer-
the end, a case study, using these methodologies and tools,
ramentas, arquitetura e tamanho) vai determinar qual ´ a e
will be proposed and some points will discussed about the
metodologia que melhor se adapta.
research that was made.
Segundo Scott W. Ambler [3], “modelagem agil ´ uma meto-
´ e
RESUMO dologia baseada na pr´tica para modelagem efetiva de siste-
a
Este artigo apresenta uma breve introdu¸ao ao uso de meto-
c˜ mas baseados em software. A modelagem agil ´ uma cole¸ao
´ e c˜
dologias ageis no desenvolvimento de aplica¸oes Web. Para
´ c˜ de pr´ticas, guiadas por princ´
a ıpios e valores que podem ser
tanto, s˜o apresentados os princ´
a ıpios e valores do Manifesto aplicados por profissionais de software no dia a dia. Mo-
´ a
Agil. Em seguida, diversas metodologias s˜o apresentadas, ´ a e
delagem agil n˜o ´ um processo prescritivo, ela n˜o define
a
com ˆnfase no XP e no Scrum, introduzindo as suas pr´ticas
e a procedimentos detalhados de como criar um dado tipo de
e seus respectivos ciclos de vida. Al´m disso, s˜o descritas
e a modelo (...) ela provˆ conselhos de como ser efetivo como
e
as caracter´ ısticas das aplica¸oes Web, e ´ apresentada uma
c˜ e ´
modelador. Pense em metodologia agil como uma arte, n˜o a
ferramenta para o desenvolvimento das mesmas, o Ruby on como uma ciˆncia”.
e
Rails, a qual aborda aspectos das metodologias ageis. Ao
´
final, ´ proposto um estudo de caso utilizando as metodo-
e As metodologias ageis surgiram devido as experiˆncias e
´ ` e
logias e ferramentas apresentadas neste artigo e s˜o feitas
a necessidades de alguns desenvolvedores que estavam cansa-
considera¸oees sobre a pesquisa realizada.
c˜ dos da burocracia existente nas metodologias de desenvol-
vimento tradicionais e resolveram utilizar pr´ticas que visa-
a
vam aumentar a produtividade e diminuir trabalhos desne-
Categorias e Descritores de Temas cess´rios.
a
D.2.18 [Software Engineering]: Software Engineering Pro-
cess; D.2.0 [Software Engineering]: General—Software Este artigo est´ organizado na seguinte forma: na se¸ao 1.1
a c˜
engineering for Internet projects; J.8 [Computer Appli- ser˜o apresentados os princ´
a ıpios e valores contidos no ma-
cations]: Internet Applications nifesto agil; na se¸ao 2 ser˜o introduzidos os exemplos mais
´ c˜ a
∗orientador comuns de metodologias ageis; na se¸ao 3 o XP e Scrum se-
´ c˜
r˜o abordados profundamente e ser´ discutido o framework
a a
Ruby on Rails juntamente a sua rela¸ao com as aplica¸oes
c˜ c
Web; na se¸ao 4 ser´ apresentado e discutido o estudo de
c˜ a
caso que consiste na aplica¸ao REDEPESQ; na se¸ao 5 se-
c˜ c˜
r˜o feitas as considera¸oes finais e mostradas algumas des-
a c˜
vantagens deste tipo de metodologia.
1.1 Manifesto Ágil
Estes desenvolvedores perceberam em 2001, que suas meto-
dologias tinham muito em comum e decidiram criar a Ali-

2. c ´
an¸a Agil e um manifesto para o desenvolvimento de sofware tive Software Development).
utilizando as metodologias ageis [6]. O manifesto foca em
´
alguns valores como: A seguir iremos fazer uma breve descri¸ao sobre algumas
c˜
metodologias citadas acima.
i. Individualidade e intera¸oes sobre processos e ferramentas;
c˜
2.1 Crystal Family
ii. Software funcional sobre documenta¸ao compreensiva;
c˜ Alistair Cockburn ´ o criador das metodologias que com-
e
p˜em a Crystal Family. Tais metodologias possuem carac-
o
iii. Colabora¸ao do cliente sobre negocia¸ao de contrato;
c˜ c˜ ter´
ısticas em comum por´m s˜o diversas, de forma a satisfa-
e a
zer projetos individuais, de uma maneira geral pequenos, de
iv. Responder a mudan¸as mais do que seguir um plano.
c acordo com os requisitos apresentados, atrav´s de princ´
e ıpios
que atendem circunstˆncias variadas de diferentes projetos.
a
Al´m desse valores o manifesto ainda apresenta 12 princ´
e ıpios
que os desenvolvedores ageis devem seguir:
´ Cada metodologia integrante desta fam´ ´ associada a uma
ılia e
cor que indica o grau de complexidade da mesma, ou seja,
i. Nossa maior prioridade ´ satisfazer o cliente mediante a
e quanto mais escura a cor, mais complexa a metodologia. Se-
r´pida e cont´
a ınua entrega de software valioso; gundo Cockburn [5], h´ trˆs metodologias Crystal: Crystal
a e
Clear, Crystal Orange e Cristal Web Orange. Ainda se-
ii. S˜o bem-vindas as mudan¸as nos requisitos, ainda que
a c gundo o mentor destas metodologias, a principal diferen¸a c
tardiamente no desenvolvimento. Os processos ageis trans-
´ entre as cores est´ na quantidade de pessoas envolvidas nas
a
formam as mudan¸as em vantagem competitiva para os cli-
c equipes. J´ que essa diferencia¸ao de cores baseia-se na com-
a c˜
entes; plexidade do projeto, por conseguinte, este demandar´ uma
a
maior quantidade de pessoas envolvidas ` medida em que a
a
iii. Entregar software funcional com frequencia, a partir de cor escurece.
algumas semana a alguns meses, com preferˆncia para prazos
e
curtos;
2.2 FDD
iv. Empres´rios e desenvolvedores devem trabalhar juntos
a Desenvolvimento Dirigido a Funcionalidades. Como o pr´ ı-
diariamente durante todo o projeto; prio nome sugere, as funcionalidades s˜o o objeto desta me-
a
todologia. Sendo assim, Palmer definiu que “FDD consiste
v. Desenvolva projeto em torno de indiv´ıduos motivados. u e e
em cinco processos seq¨enciais e provˆ os m´todos, t´cni-
e
Dˆem-lhes o ambiente e o apoio que precisarem, e confiem
e cas, e diretrizes necess´rias para que os membros do projeto
a
neles para fazer o trabalho; possam entregar um sistema funcional. Al´m disso, FDD in-
e
clui os pap´is, regras, metas e fases de desenvolvimento bem
e
vi. O m´todo mais eficiente e eficaz de transmitir informa¸ao
e c˜ definidas, os quais s˜o necess´rios dentro de um projeto” [9].
a a
para e com a equipe de desenvolvimento est´ na conversa
a
cara-a-cara; 2.3 DSDM
DSDM ´ um framework para desenvolvimento de RAD (Ra-
e
vii. Software funcional ´ a principal medida de progresso;
e pid Application Development) mantido por um cons´rcio[1],
o
que n˜o visa lucro. A id´ia fundamental atr´s da DSDM
a e a
viii. Processos ageis promovem o desenvolvimento sustent´-
´ a ´ abranger a maior quantia poss´
e ıvel de funcionalidades em
vel. Os patrocinadores, desenvolvedores e usu´rios devem
a um produto, e ir ajustando tempo e recursos para alcan¸arc
ser capazes de manter um ritmo constante indefinidamente; essa funcionalidade. DSDM ´ dividido em cinco fases: es-
e
tudo de viabilidade, estudo empresarial, repeti¸ao funcional
c˜
c˜
ix. Aten¸ao cont´ e
ınua a excelˆncia da t´cnica e bom design
e do modelo, repeti¸oes de planejamento/desenvolvimento e
c˜
aumenta a agilidade; implementa¸ao XP e SCRUM.
c˜
x. Simplicidade - a arte de maximizar a quantidade de tra- 2.4 ASD
balho n˜o feito - ´ essencial;
a e
ASD possui seu foco de atua¸ao principalmente nos proble-
c˜
mas de sistemas complexos, para grandes desenvolvimentos.
xi. As melhores arquiteturas, requisitos, e modelos emergem
O m´todo estimula fortemente o desenvolvimento com repe-
e
de equipes auto-organiz´veis;
a
ti¸oes e uma constante prototipa¸ao. Um projeto de ASD
c˜ c˜
´ dividido em ciclos compostos de trˆs fases. As fases dos
e e
xii. Periodicamente, a equipe reflete sobre como se tornar
ciclos s˜o Especula¸ao, Colabora¸ao, e Aprendizado, carac-
a c˜ c˜
mais eficaz e, em seguida, sintoniza e ajusta o seu compor-
terizadas em [7].
tamento em conformidade.
i. Especula¸ao: utilizada no lugar de planejamento, pois, um
c˜
2. METODOLOGIAS E TECNOLOGIAS plano geralmente ´ visto como algo onde incerteza ´ uma
e e
Existem diversas metodologias ageis, dentre elas as mais co-
´ fraqueza, e no qual divergˆncias indicam fracasso;
e
nhecidas s˜o: XP (eXtrem Programming); SCRUM; FDD
a
(Feature Driven Development); Crystal Family; DSDM (Dy- ii. Colabora¸ao: real¸a a importˆncia de trabalho de equi-
c˜ c a
namic Systems Development Method ); OpenUP (Open Uni- pe como o meio de sistemas de automudan¸aa em desenvol-
c
fied Process); AUP (Agile Unified Process) e ASD (Adapta- vimento;

3. iii. Aprendizado: devido a necessidade para reconhecer e
` quais delas far˜o parte do primeiro release. O planejamento
a
reagir a decis˜es erradas e o fato que os requisitos podem
o tamb´m abrange estimativas de esfor¸o para a implementa-
e c
mudar durante o desenvolvimento. cao de cada est´ria.
¸˜ o
2.5 XP e SCRUM A fase de itera¸oes para release consiste de diversas itera¸oes
c˜ c˜
Como um dos objetivos deste trabalho ´ a utiliza¸ao de
e c˜ antes do primeiro release do sistema. Estas itera¸oes s˜o de-
c˜ a
Programa¸ao Extrema (XP), juntamente com SCRUM, tais
c˜ finidas tomando por base as informa¸oes obtidas durante a
c˜
metodologias de desenvolvimento agil ser˜o abordadas com
´ a fase de planejamento. Na primeira itera¸ao s˜o implemen-
c˜ a
mais profundidade em seguida. tadas apenas as principais funcionalidades, conforme foram
documentadas pelo cliente. J´ na ultima, o sistema est´
a ´ a
preparado para entrar em produ¸ao. c˜
3. DESENVOLVENDO APLICAÇÕES WEB
UTILIZANDO XP, SCRUM E RUBY ON Na fase de produ¸ao, s˜o feitos testes adicionais no sistema,
c˜ a
RAILS al´m de uma verifica¸ao de seu desempenho, no intuito de
e c˜
´
liber´-lo sem problemas ao cliente. E poss´ detectar novas
a ıvel
Neste trabalho iremos abordar uma metodologia mista de
XP e SCRUM. Utilizaremos as diversas pr´ticas existentes
a altera¸oes a serem feitas no sistema nesta fase.
c˜
nestas metodologias para desenvolver software. Falaremos
´
A primeira libera¸ao do sistema, segue-se a fase de manu-
c˜
primeiramente sobre cada uma delas separadamente e de-
pois iremos mostrar que ´ poss´
e ıvel utilizarmos as duas me- ten¸˜o, cuja finalidade ´ dar suporte ao sistema em funcio-
ca e
todologias no processo de desenvolvimento. namento. Nesta fase, h´ uma divis˜o do esfor¸o da equipe
a a c
de projeto, pois simultaneamente novas itera¸˜es do sistema
co
s˜o implementadas.
a
3.1 XP
A metodologia agil mais conhecida e estudada ´ a Progra-
´ e A ultima fase do ciclo de vida em XP ´ a de morte, que
´ e
c˜ e
ma¸ao Extrema (do inglˆs eXtreme Programming). Segundo a
ocorre quando n˜o h´ mais est´rias de usu´rio a serem im-
a a o
Beck[4], trata-se de uma ”metodologia agil para equipes pe-
´ plementadas e requisitos n˜o-funcionais, como desempenho,
a
quenas a m´dias desenvolvendo software com requerimentos
e est˜o satisfatoriamente atendidos. Resta, ent˜o, realizar a
a a
vagos ou que mudam freq¨entemente”. Como toda meto-
u documenta¸ao do sistema. A morte tamb´m pode acontecer
c˜ e
dologia ´gil, o c´digo ´ a principal tarefa. Tal metodologia
a o e quando se constata a inviabilidade de uma itera¸ao adicional
c˜
baseia-se nos ditames do manifesto agil.
´ ao sistema.
3.1.1 Ciclo de vida em XP
O ciclo de vida do software em programa¸ao extrema ´ cons-
c˜ e
3.1.2 Práticas do XP
titu´ por seis fases, conforme exibe a Figura 1. Cada uma
ıdo A programa¸ao extrema objetiva um r´pido desenvolvimento
c˜ a
delas ser´ descrita imediatamente a seguir.
a de software com sucesso. Itera¸oes curtas e feedback r´pido,
c˜ a
participa¸ao do cliente, comunica¸ao e coordena¸ao, integra-
c˜ c˜ c˜
cao continuada e testes, posse coletiva do c´digo, documen-
¸˜ o
ta¸ao limitada e programa¸ao em par est˜o entre as princi-
c˜ c˜ a
pais pr´ticas do XP. Essas s˜o apresentadas logo abaixo:
a a
i. Jogo de planejamento - Estreita intera¸ao entre progra-
c˜
madores e clientes. Estes contam suas hist´rias, enquando
o
aqueles estimam os esfor¸os que se far˜o necess´rios para a
c a a
implement´-las, para decidirem sobre o escopo e tempo das
a
libera¸oes.
c˜
ii. Libera¸oes em curto tempo - Um sistema n˜o muito
c˜ a
complexo ´ constru´ rapidamente e atualizado freq¨ente-
e ıdo u
mente em ciclos bastante curtos. Novas vers˜es s˜o liberadas
o a
no m´ ınimo mensalmente.
Figura 1: Fases do ciclo de vida do software em XP
[8] iii. Met´fora - O sistema ´ definido por uma met´fora ou
a e a
por um conjunto de met´foras entre o cliente e os progra-
a
madores. Estas guiam todo o desenvolvimento descrevendo
Na fase de explora¸ao, o cliente descreve os requisitos funci-
c˜ como o sistema funciona, onde as equipes de desenvolvi-
onais que o primeiro release deve conter atrav´s dos chama-
e mento utilizam um “sistema de nomes” e uma descri¸ao do
c˜
dos cart˜es de est´ria (story cards) em linguagem simples.
o o sistema sem a utiliza¸ao de termos t´cnicos. Ou seja, uma
c˜ e
a e c˜
H´ tamb´m nesta fase a familiariza¸ao da equipe de projeto met´fora ´ uma forma dos programadores conseguirem se
a e
com as tecnologias, ferramentas, e pr´ticas a serem utiliza-
a comunicar de forma adequada com os clientes.
das, al´m de serem exploradas as poss´
e ıveis arquitetura do
sistema. iv. Design simples - Um programa constru´ atrav´s do
ıdo e
m´todo XP deve ser o mais simples poss´ satisfazendo as
e ıvel
Durante a fase de planejamento, ocorre a prioriza¸ao das es-
c˜ atuais necessidades, sendo que o foco est´ em prover valor
a
o a c˜
t´rias de usu´rio, resultando na determina¸ao definitiva de o e a ca
de neg´cio. A ˆnfase est´ em desenvolver a solu¸˜o mais

4. simples poss´
ıvel que possa ser implementada no momento. xiv. Regras justas - A equipe tem as suas pr´prias regras
o
C´digo muito complexo ´ removido imediatamente.
o e a serem seguidas, mas podem ser modificadas a qualquer
hora, desde que se chegue a um acordo e seu impacto seja
v. Teste - O desenvolvimento do software ´ dirigido por tes-
e avaliado.
tes, sendo que h´ dois tipos de testes: testes unit´rios s˜o
a a a
implementados antes do c´digo pelos pr´prios desenvolvedo-
o o 3.2 SCRUM
res para testar a est´ria implementada e os testes de aceita-
o Entre as metodologias ageis para desenvolvimento de soft-
´
c˜o s˜o desenvolvidos pelos usu´rios ou por uma equipe de
¸a a a ware est´ o Scrum, que parte do pressuposto de que o pro-
a
testes externa a equipe de desenvolvimento que tˆm como
` e cesso de desenvolvimento ´ complexo e imprevis´
e ıvel, reque-
intuito testar todo o sistema. rendo, portanto, um gerenciamento diferente em rela¸˜o aoca
que ´ proporcionado pelas abordagens das metodologias tra-
e
vi. Reconstru¸˜o - As equipes XP reestruturam o sistema
ca dicionais. Ken Schwaber [10], valendo-se de conceitos oriun-
removendo poss´ ıveis duplica¸oes, melhorando a comunica-
c˜ dos do controle de processo industrial, classifica os processos
c˜o, simplificando e adicionando flexibilidade durante todo
¸a em te´ricos, que s˜o totalmente definidos em seus passos, e
o a
o desenvolvimento, mantendo a clareza do software, sem am- emp´ ıricos, em que as atividades s˜o tratadas como caixas-
a
big¨idade, com alta comunica¸ao, simples, por´m completo.
u c˜ e pretas. Segundo Schwaber, as metodologias tradicionais tra-
tam o desenvolvimento de software a partir da abordagem
vii. Programa¸˜o em par - Os programadores XP produ-
ca te´rica, o que muitas vezes produz resultados imprevis´
o ıveis
zem o c´digo em duplas, ou seja, dois programadores traba-
o e fora da capacidade de controle da metodologia utilizada.
lhando juntos na mesma m´quina. Muitos experimentos tˆm
a e Scrum, ao contr´rio, provˆ flexibilidade ao desenvolvimento
a e
mostrado que a programa¸ao em dupla produz software de
c˜ com sua abordagem predominantemente emp´ ırica, tratando
melhor qualidade com um custo similar ou menor do que o o processo como uma “caixa-preta controlada”, ou seja, h´ a
produzido por programadores trabalhando individualmente. flexibilidade suficiente para que eventuais mudan¸as durante
c
o processo, ainda que imprevis´ ıveis, permane¸am sob con-
c
viii. Posse coletiva - Qualquer um pode mudar qualquer trole.
parte do c´digo a qualquer momento. Todo o c´digo per-
o o
tence a todos os programadores. Essa caracter´
ıstica permite Como ´ caracter´
e ıstico das metodologias ageis, Scrum se pauta
´
que a equipe trabalhe com velocidade m´xima, uma vez que
a no princ´ıpio da mutabilidade. Vari´veis como requisitos do
a
as altera¸oes podem ser feitas sem atrasos, pois todos tˆm
c˜ e cliente, tempo, competitividade, qualidade e recursos s˜o a
liberdade para fazˆ-las.
e utilizadas na elabora¸ao de um planejamento inicial do pro-
c˜
cesso de desenvolvimento. Por´m, ao longo do processo,
e
ca c
ix. Integra¸˜o Continuada - Um novo peda¸o de c´digo ´ o e pode haver altera¸oes nos requisitos em rela¸ao ao que foi
c˜ c˜
integrado ao c´digo base assim que ele estiver pronto. Assim,
o definido inicialmente, devendo tais altera¸˜es serem geren-
co
o sistema ´ integrado e constru´ v´rias vezes ao dia. Isso
e ıdo a ciadas pela metodologia.
mantˆm todos os programadores em sintonia e possibilita
e
um progresso r´pido. Todos os testes s˜o realizados e devem
a a Entre as empresas que j´ utilizaram Scrum com sucesso em
a
passar pelas modifica¸oees de c´digo para serem aceitos.
c˜ o projetos de desenvolvimento de software est˜o Fuji-Xerox,
a
Honda, Canon, Epson, NEC, Brother, 3M, e Hewlett-Packard.
x. 40 horas por semana - Programadores exaustos co- A seguir, ser˜o apresentadas em maiores detalhes as fases do
a
metem mais erros. As equipes XP n˜o trabalham por um
a processo de desenvolvimento na metodologia Scrum.
tempo excessivo; elas trabalham no m´ximo 40 horas por
a
semana. N˜o ´ permitido que duas semanas em seguida ex-
a e 3.2.1 Cilco de vida do Scrum
cedam esse tempo. Se isso acontecer, deve ser tratado como
Como j´ foi mencionado, Scrum assume que as etapas de
a
um problema a ser resolvido.
an´lise, projeto e desenvolvimento do software s˜o imprevi-
a a
s´
ıveis. Diante disso, a metodologia utiliza um mecanismo de
xi. Cliente no local - O cliente tem que estar presente
controle para gerenciar os riscos e assegurar a flexibilidade
e dispon´ıvel todo o tempo com a equipe para determinar
do processo. A Figura 2 apresenta as fases do processo na
as suas necessidades e responder as d´vidas dos programa-
u
metodologia Scrum.
dores. Essa pr´tica melhora a comunica¸ao e gera menos
a c˜
documentos, o que, em geral, ´ uma das partes mais caras
e
Scrum divide o processo de software em trˆs grandes etapas:
e
em um projeto de software.
pregame, onde h´ o planejamento inicial do desenvolvimento
a
e defini¸ao da arquitetura do software; game, em que ocorre
c˜
xii. Padr˜es de c´digo - As regras de c´digo existem e s˜o
o o o a
a maior parte das atividades de desenvolvimento; postgame,
seguidas pelos programadores. A comunica¸ao atrav´s do
c˜ e
na qual o software ´ preparado para seu release final. Pode-
e
c´digo deve ser enfatizada, de modo que todos os programa-
o
se afirmar que as fases de pregame e postgame encaram o
dores o escrevam da mesma forma para garantir a clareza
processo valendo-se da abordagem te´rica, conforme foi de-
o
do c´digo.
o
finida anteriormente, enquanto a fase de game, que ´ o “co-
e
´ ra¸˜o” do Srcum, ´ totalmente emp´
ca e ırica.
xiii. Area de trabalho aberta - Uma sala grande com
diversos cub´
ıculos ´ prioridade. Pares de programadores de-
e
A fase de pregame ´ constitu´ basicamente de duas ativi-
e ıda
vem ser colocados no centro do local.
dades: o planejamento inicial do desenvolvimento, em que
os requisitos do sistema s˜o documentados em um artefato
a
chamado product backlog, sendo tamb´m feitas estimativas
e

5. e as que existiam eram utilizadas para fins espec´
ıficos e limi-
tados. Com a evolu¸ao das linguagens de programa¸ao para
c˜ c˜
a Web, surgiram novas aplica¸aes focadas nos mais diversos
c˜
neg´cios e grandes empresas passaram a oferecer servi¸os via
o c
Internet.
Com o advento da Web 2.0 o foco das aplica¸oes deixou de
c˜
ser somente nos neg´cios e come¸ou a ter um foco maior
o c
com a interatividade com o usu´rio. O usu´rio deixou de
a a
ser um mero utilizador das aplica¸˜es e passou a participar
co
do processo de cria¸ao de conte´do. Neste contexto, as mu-
c˜ u
dan¸as nestas aplica¸oes passam a ser mais frequentes, j´
c c˜ a
que as aplica¸oes tendem a serem desenvolvidas para satis-
c˜
fazer o mais r´pido poss´
a ıvel as necessidades dos usu´rios, e
a
Figura 2: Fases do processo na metodologia Scrum acompanhar a evolu¸ao acelerada das diversas tecnologias
c˜
[10] que fazem as aplica¸oes Web.
c˜
Pr´tica ageis como entregas frequentes, flexibilidade para
a ´
aceitar mudan¸a e simplicidade s˜o bastante prop´
c a ıcias para
de prazos e custos para o release definido; a outra atividade este tipo de aplica¸ao.
c˜
define a arquitetura do sistema, ou seja, de que maneira os
requisitos do product backlog ser˜o implementados.
a 3.4 Ruby on Rails
O Ruby on Rails ´ um meta-framework para desenvolvi-
e
A fase de game constitui-se de um ciclo iterativo de de- mento de aplica¸oes Web. Ele foi desenvolvido sobre a lin-
c˜
senvolvimento no qual os requisitos do product backlog s˜o a guagem Ruby, e ´ distruibu´ como software livre. Este fra-
e ıdo
interpretados no intuito de definir tarefas concretas, denomi- mework permite a gera¸˜o de uma estrutura bem definada
ca
nadas sprints pela metodologia. Cada sprint ´ documentado
e para aplica¸oes Web utilizando o padr˜o MVC (Model-View-
c˜ a
em seu respectivo sprint backlog. O ciclo dos sprints, similar Controller).
ao PDCA - plan, do, check and act, utilizado em gest˜o dea
qualidade - ´ composto por quatro etapas e implementam
e O MVC ´ um padr˜o arquitetural criado em 1979 por Trygve
e a
o que foi definido em um determinado sprint backlog. As Reenskaug para desenvolvimento de aplica¸oes interativas.
c˜
etapas do ciclo s˜o as seguintes:
a No desenvilmento, a aplica¸˜o ´ quebrada em trˆs tipos de
ca e e
componentes: Modelo, Vis˜o e Controlador, como mostrado
a
i. Desenvolvimento (develop): define as mudan¸as ne- c na Figura 3.
cess´rias para a implementa˜o do sprint backlog, implemen-
a a
tando, testando e documentando cada uma delas; O modelo ´ respons´vel por manter o estado da aplica¸ao.
e a c˜
Este estado pode ser permanente (que ser´ guardado em
a
ii. Corte (wrap): cria uma vers˜o execut´vel daquilo que
a a banco de dados) ou transacional (far´ apenas algumas inte-
a
foi implementado na etapa anterior; ra¸˜es com o usu´rio). O modelo al´m de guardar os dados,
co a e
ele tamb´m realiza todas as regras de neg´cio [13].
e o
iii. Revis˜o (review ): analisa o progresso do desenvolvi-
a
mento, soluciona eventuais problemas, avalia os riscos e adi- A vis˜o ´ respons´vel por apresentar os dados do modelo
a e a
ciona novos itens ao sprint backlog, se necess´rio;
a para o usu´rio, e fazer as requisi¸oes para o controlador.
a c˜
iv. Ajuste (adjust): consolida as informa¸˜es obtidas na
co O controlador recebe as requisi¸oes do vis˜o, interage com
c˜ a
fase de revis˜o a fim de preparar o ciclo para o retorno a
a ` os modelos e apresenta a vis˜o apropriada para o usu´rio.
a a
fase de desenvolvimento. Ele ´ respons´vel pelo fluxo da aplica¸ao.
e a c˜
A fase de postgame corresponde a uma atividade denomi-
nada pelo Scrum de fechamento (closure), em que ´ efetuado
e
o release final do software, juntamente com outras atividades
necess´rias, como testes, documenta¸ao final e integra¸˜o.
a c˜ ca
3.3 Aplicações Web
As Aplica¸oes Web tem como principal caracter´
c˜ ıstica a dis-
tribui¸ao das aplica¸oes, que podem ser acessadas por v´rios
c˜ c˜ a
usu´rios de qualquer lugar e ao mesmo tempo, utilizando
a
apenas um navegador web. Essas aplica¸oes geralmente pas-
c˜
sam por constantes mudan¸as, para se adaptaram as neces-
c Figura 3: Ilustra¸˜o do MVC
ca
sidades dos neg´cios e acompanharem a constante evolu¸ao
o c˜ [13]
tecnol´gica que ocorre na internet.
o
No in´ da era da internet, existiam poucas aplica¸oes Web
ıcio c˜ O Rails cria a estrutura das aplica¸oes utilizando esse pa-
c˜

6. dr˜o, e a programa¸ao ´ feita em cada uma das camadas
a c˜ e ii. Integra¸˜o continuada: ferramentas de integra¸ao e
ca c˜
separadamente e elas se integram quando o programa ´ exe-
e de versionamente de c´digo, quando utilizadas no desenvol-
o
cutado. vimento de software, possibilitam uma menor repeti¸ao de
c˜
c´digo e uma maior qualidade da aplica¸ao.
o c˜
Os projetos em Rails seguem uma dupla de concentos cha-
ves. Esses conceitos agilizam o desenvolvimente de aplica- iii. Est´rias do usu´rio: As funcionalidades ser˜o descri-
o a a
c˜es Web. O primeiro deles, o DRY(Don’t Repeat Yourself),
¸o tas pelo usu´rio na forma de hist´ria.
a o
prega que as repeti¸oes de c´digo devem ser evitadas, para
c˜ o
agilizar o desenvolvimente e facilitar as modifica¸oes, j´ que
c˜ a J´ do Scrum, alguma pr´ticas devem ser destacadas:
a a
os c´digos tendem a ser mais limpos.
o
i. Reuni˜o di´ria: Esta reuni˜o que serve para que a
a a a
O segundo conceito, Convers˜o sobre Configura¸ao, possi-
a c˜ equipe apresente os resultados di´rios e conhe¸a e discuta
a c
bilita que aplica¸˜es Rails sejam desenvolvidas e postas em
co os problemas encontrados, auxilia na integra¸ao da equipe,
c˜
produ¸˜o sem que haja a configura¸˜o de diversas coisas, que
ca ca e motiva os participantes.
geralmente s˜o feitas em arquivos XML complicados. Com
a
esses dois conceitos os c´digos das aplica¸oes Rails tendem
o c˜ ii. Product Backlog: As funcionalidades da REDEPESQ
a ser simples e de f´cil entendimento.
a depois de discutidas na fase de pregame ser˜o adicionadas
a
ao product backlog. Depois cada item da Produckt Backlog
Outro fator positivo para os aplica¸oes Rails ´ a linguagem
c˜ e poder´ ser dividido e fazer parte do Sprint Backlog. Na
a
Ruby[2]. Esta linguagem criada por Yukihiro Matsumoto, figura 4 temos um exemplo do Product Backlog.
foi projetada tanto para a programa¸ao em larga escala como
c˜
para a codifica¸˜o r´pida aproveitando as melhores id´ias
ca a e iii. Sprint Backlog: Todas as funcionalidades presentes no
das linguagens da ´poca. Ela ´ um linguagem interpretada,
e e Sprint Backlog ser˜o transformadas em hist´rias, e depois
a o
com tipagem dinˆmica e tipagem forte, orientada a objetos.
a ser˜o implementadas.
a
Tem diversas semelhan¸as com o Python, Perl e Smalltalk.
c
A linguagem possui uma sintaxe enxuta e de f´cil compre-
a
ens˜o, al´m de possibilitar a cria¸ao de m´todos em tempo
a e c˜ e
real.
4. DESENVOLVENDO A REDEPESQ
Neste trabalho iremos utilizar pr´ticas ageis para o desenvol-
a ´
vimento de uma aplica¸˜o Web, utilizando o Ruby on Rails
ca
como framework. Essa aplica¸ao consiste numa rede social
c˜
entre pesquisadores, com informa¸oes pessoais e proficionais
c˜
que podem ser disponibilizadas pelo pesquisador para com-
por o seu perfil. Essas informa¸oes incluem os trabalhos
c˜
de pesquisa que ele desenvolveu assim como seus resultado,
dados de patentes que possui, e dados profissionais diversos.
Figura 4: Ilustra¸˜o do product backlog
ca
A REDEPESQ possibilita uma maior intera¸ao entre os pes-
c˜
quisadores, que poder˜o trocar informa¸oes profissionais e
a c˜
formar grupos de pesquisa, utilizando a aplica¸ao. A aplica-
c˜
c˜o tamb´m visa possibilitar o acompanhamento de projetos
¸a e 4.2 Utilizando o Ruby on Rails como framework
de pesquisa que est˜o sendo desenvolvidos pelos grupos de
a Utilizaremos o Ruby on Rails em conjunto com as pr´ticas
a
pesquisa ou pesquisadores cadastrados. expostas no item anterior para obter um maior benef´ do
ıcio
framework e das metodologias aplicadas. O Rails foi desen-
volvido para incorporar grande parte dessas pr´ticas cita-
a
4.1 Unindo XP e Scrum remos a seguir as principais funcionalidades que ele oferece
Para o desenvolvimento da REDEPESQ utilizaremos um para auxiliar o desenvolvimento:
conjunto de pr´ticas do Scrum e da XP. A escolha dessas
a
pr´ticas visa a adapta¸ao das metodologias ao ambiente em
a c˜ i. ORM (Object-Relational Mapping ): Essa biblioteca
que esta aplica¸˜o ser´ desenvolvida. Citaremos nessa se-
ca a mapeia tableas de banco de dados em classes. Se o banco de
¸a a a
c˜o as pr´ticas que ser˜o utilizadas e tamb´m os poss´
e ıveis dados tem uma tabela chamada pesquisadores, o programa
benef´
ıcios que elas trar˜o ao ambiente de desenvolvimento.
a ter´ uma classe chamada Pesquisador. Linhas da tabela
a
s˜o representados como objetos desta classe. Os modelos
a
Da XP retiramos algumas pr´ticas pertinentes para o desen-
a do Rails s˜o geralmente classes ORM. O ORM diminui a
a
volvimento: programa¸ao em SQL e centraliza todas as chamadas a base
c˜
de dados na camada de modelo.
i. Desenvolvimento dirigido a testes: esta pr´tica prima
a
pela qualidade do software. Os testes s˜o implementados
a ii. Migrations: Esta funcionalidade do Rails permite que
antes de qualquer funcionalidade. Isso ajuda a equipe a modifica¸oes no banco de dados sejam feitas facilmente du-
c˜
conhecer melhor os requisitos antes de implement´-los. Os
a rante o desenvolvimento, diminuindo os erros que possam
testes servem tamb´m como documenta¸ao execut´vel.
e c˜ a ocorrer caso o sistema esteja em produ¸ao.
c˜

7. iii. Generator : Esta funcionalidade permir que diversas [7] Highsmith III, J. A. Adaptive Software Development:
partes de sua aplica¸ao sejam geradas automaticamente se-
c˜ A Collaborative Approach to Managing Complex
´
guindo um padr˜o definido. E possivel criar modelos, con-
a Systems, 1a ed. Dorset House Publishing Company,
troladores, vis˜es e testes automaticamente utilizando os ge-
o Incorporated, 1999.
nerators. Ele ajuda a manter o estrutura da aplica¸ao.
c˜ [8] Man, L. C., Mendes, P. H. R., and de Queiroz,
R. N. eXtreme programming. http://www.dc.
iv. Templates: Seguindo o conceito de DRY, os templates ufscar.br/~rosangel/mds/Seminarios/xp.doc.
servem para que sejam evitadas repeti¸oes de c´digos des-
c˜ o Visitado em 20 de novembro de 2008, 2006.
necess´rias.
a [9] Palmer, S. R., and Felsing, J. M. A Practical
Guide to Feature-Driven Development, 1a ed. Prentice
v. Plugins: Possibilitam que o conceito de reuso de com- Hall, 2002.
ponentes seja utilizando. Diversos plugins est˜o dispon´
a ıveis [10] Schwaber, K. Scrum development process.
para a comunidade Rails, evitando assim que a equipe se http://jeffsutherland.com/oopsla/schwapub.pdf.
preocupe em implementar funcionalidades gerais que j´ es-
a Visitado em 20 de novembro de 2008.
a o
t˜o implementadas e foquem no neg´cio espec´ ıfico da sua [11] Sch¨ mmer1, T., and Sch¨ mmer, J. Support for
u u
aplica¸ao.
c˜ distributed teams in eXtreme programming.
http://www.ipsi.fraunhofer.de/~publications/
5. CONCLUSÃO E TRABALHOS FUTUROS concert/2001/xp00.pdf. Visitado em 12 de novembro
Conclu´ ımos neste trabalho que apesar das metodologias ageis
´ de 2008, 2001.
auxiliarem muito o desenvolvimento de aplica¸oes Web elas
c˜ [12] Sutherland, J., Viktorov, A., and Viktorov, A.
ainda possuem algumas falhas[14], como a negocia¸ao de
c˜ Adaptive engineering of large software projects with
contrato com os clientes, utiliza¸ao de algumas pr´ticas em
c˜ a distributed/outsourced teams.
equipes distribu´ıdas geograficamente[11], gerenciamento de http://necsi.org/events/iccs6/papers/
equipes grandes[12], etc. Por´m existem casos de sucesso em
e ee6637fd0a1f958002d8f242162b.pdf. Visitado em 12
diversas empresas que acreditaram e utilizam essas metodo- de novembro de 2008, 2006.
logias. Algumas dessas empresas s˜o bastante conhecidas na
a [13] Thomas, D., and Hansson, D. H. Agile Web
area, como a IBM e a Microsoft.
´ Development with Rails, 2a ed. The Pragmatic
Bookshelf, 2007.
Acreditamos que para o sucesso do desenvolvimento de uma [14] Turk, D., France, R., and Rumpe, B. Limitations
aplica¸ao utilizando metodologias ageis a equipe deve, antes
c˜ ´ of agile software processes. http://www4.in.tum.de/
de tudo, incorporar os princ´ıpios e valores da metodologia, publ/papers/XP02.Limitations.pdf. Visitado em 12
e adaptar a metodologia para a realidade da sua empresa, de novembro de 2008, 2002.
desta forma, os projetos ter˜o uma grande possibilidade de
a
sucesso.
5.1 Trabalhos futuros
Como trabalhos futuros propomos um estudo aprofundado
de como as pr´ticas das metodologias ageis podem ser adap-
a ´
tadas para a obten¸ao de algumas das diversas certifica¸oes
c˜ c˜
existentes no mercado (MPS.BR, CMM, PMBOK) nos seus
diversos n´ıveis, sem que as caracter´
ısticas dessa forma de
desenvolvimento 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. visitado
em 8 de dezembro de 2008.
[3] Ambler, S. W. Agile Modeling (AM): Modeling and
documentation 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: Embrace
change. Addison-Wesley, 2000.
[5] Cockburn, A. Agile Software Development.
Cockburn & Highsmith Series Editors, 2002.
[6] Fowler, M., and Highsmith, J. The Agile
Manifesto.
http://hristov.com/andrey/fht-stuttgart/The_
Agile_Manifesto_SDMagazine.pdf. Visitado em 12 de
novembro de 2008, 2001.