Desenvolvendo a REDEPESQ utilizando uma abordagem ágil

898 visualizações

Publicada em

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
898
No SlideShare
0
A partir de incorporações
0
Número de incorporações
13
Ações
Compartilhamentos
0
Downloads
18
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Desenvolvendo a REDEPESQ utilizando uma abordagem ágil

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

×