Comparao entre Metodologias RUP e XP

Carlos G. Vasco, Marcelo Henrique Vithoft, Paulo Roberto C. Estante Programa de Ps Graduao em Informtica Aplicada Pontifcia Universidade Catlica do Paran (PUCPR) Curitiba, PR Brasil
cgvasco@gmail.com, vithoft@ppgia.pucpr.br, estantep@ppgia.pucpr.br

Abstract. This paper compares the software development methodology RUP and XP, two methods that aim at risk reduction by making the system development in an incremental fashion. The paper focus on the structure of the processes and in the activity division, concluding that XP is most suitable for minor projects, and RUP being the most suitable for major projects due to requirements, communication and documentation. Resumo. Este artigo compara as metodologias de desenvolvimento de software RUP e XP, dois mtodos que buscam a reduo de riscos desenvolvendo o sistema de forma incremental. O artigo tem como foco a estruturao dos processos e a diviso das atividades, concluindo com uma indicao de uso do XP para projetos menores, e com o uso do RUP para projetos maiores, devido a requerimentos, comunicao e documentao.

1. Introduo
O sucesso de um projeto de desenvolvimento de software comea no devido planejamento e na escolha de uma metodologia compatvel com as caractersticas do mesmo. A etapa do planejamento deve estruturar o processo de desenvolvimento em torno dos recursos disponveis (i.e. oramento, fora de trabalho, tempo) visando entrega de um produto de qualidade que atenda s necessidades do cliente dentro do prazo previsto. A metodologia tradicional de desenvolvimento, em cascata (waterfall), consiste em etapas que so seguidas estritamente de forma seqencial: o produto de cada etapa tomado como base para o incio da prxima. Esta metodologia implica que um enorme esforo deve ser empregado nas fases de levantamento de requerimentos e de desenho da arquitetura. Se durante uma das fases finais do projeto (i.e. implementao, testes) for localizado uma falha, ou mesmo ocorrer uma alterao de requisitos, o projeto pode sofrer enormes (e dispendiosas) alteraes. Tanto o Rational Unified Process (RUP) quanto o Extreme Programming (XP) so metodologias que dividem o desenvolvimento de um projeto em ciclos, visando reduo de riscos (e custos) nos casos de alteraes de requisitos ou funcionalidades. O presente trabalho tem o propsito de analisar as similaridades e diferenas presentes nas metodologias empregadas pelos processos RUP e XP. O captulo 2 apresenta os tipos de metodologia de projeto, j o 3 define os processos RUP e XP, o 4 compara duas metodologias. Por fim o captulo 5 sintetiza as idias apresentadas.

2. Tipos de Metodologias de Projeto

2.1. Metodologias Iterativas Metodologias iterativas tm como objetivo o desenvolvimento de projetos de forma incremental. A cada iterao uma parte do sistema desenvolvida, sendo o produto de cada nova iterao superior da iterao anterior. Desenvolver um sistema de forma incremental traz vantagens ao projeto. Ao se construir gradualmente o sistema, os prprios desenvolvedores aprendem sobre o mesmo, possibilitando a localizao de futuros problemas em fases iniciais. Outra vantagem de se construir um sistema gradualmente a inata acomodao para mudanas, dado que o todo no desenvolvido em apenas uma etapa. 2.2. Metodologias geis Metodologias geis tambm dividem o desenvolvimento do software em iteraes, buscando reduo de riscos ao projeto. Ao final de cada iterao, uma verso (release) funcional do produto, embora restrita em funcionalidades, liberada ao cliente. As metodologias geis destacam aspectos humanos no desenvolvimento do projeto, promovendo interao na equipe de desenvolvimento e o relacionamento de cooperao com o cliente. Comunicao face-a-face preferida documentao compreensiva. 2.3. Contrastes de Metodologias Iterativas e geis As metodologias geis compartilham as idias de construo incremental de sistemas provenientes das metodologias iterativas, porm os perodos das iteraes so geralmente menores, medidos em semanas, enquanto iteraes de processos iterativos so geralmente medidos em meses.

3. Metodologias de Desenvolvimento
3.1. Rational Unified Process RUP uma metodologia iterativa de desenvolvimento. RUP adaptvel, podendo ser customizada para diversos tipos e tamanhos de produtos e projetos de software. A Rational Software (atual diviso da IBM) desenvolveu e mantm o RUP. A metodologia RUP identifica cada ciclo de desenvolvimento do projeto em quatro fases, cada uma com respectivos marcos de finalizao definidos (chamados milestones). Os milestones so os indicadores de progresso do projeto, e so usados como base para decises para continuar, abortar, ou mudar o rumo do projeto. As fases do RUP so: 1. Incio (Inception): determinao do escopo do desenvolvimento, sendo levantado uma viso do produto final a partir de um caso de uso (bsico) definido. 2. Elaborao (Elaboration): planejamento de atividades e recursos necessrios, onde so definidas funcionalidades e a arquitetura a ser desenvolvida.

3. Construo (Construction): implementao do software, contruo do cdigo. Em projetos grandes esta fase pode ser segmentada em vrias iteraes, visando diviso em partes menores e mais facilmente gerenciadas. 4. Transio (Transition): o produto passado aos usurios. Nesta fase ocorre treinamento dos usurios (e possveis mantenedores) e a avaliao do produto (beta-testing).

Figura 1. Fases do RUP - Adaptado de [Luiz 2005]

A Figura 1 apresenta a arquitetura de projetos que seguem a metodologia RUP. O eixo horizontal define aspectos dinmicos, como ciclos, fases, iteraes e marcos (milestones), j a vertical define os aspectos estticos, como atividades, disciplinas, artefatos e papis. Alguns dos fatores citados sero abordados ao longo do captulo 4. Os valores do RUP so [Beck apud Runeson 2004]: desenho do sistema via casos de uso, ajuste do processo, e ferramenta de suporte. 3.2. Extreme Programming XP uma metodologia gil, para o desenvolvimento de projetos de IT cujas especificaes so passveis a alteraes. As iteraes do XP costumam ser curtas, provendo constantes verses do produto (releases) para o cliente, que por sua vez prov comentrios e opinies que realimentam a prxima iterao. O objetivo do XP tornar o projeto flexvel, diminuindo o custo a possveis mudanas. O cdigo produzido tomado como indicador de progresso do projeto. O ciclo XP dividido em seis fases:

1. Explorao: nessa fase o cliente escreve cartes de estrias, cada um contendo uma funcionalidade desejada para o primeiro release. 2. Planejamento: ocorre definio de prioridades entre as estrias junto com o cliente. Nesta etapa os programadores estimam o esforo e o cronograma para cada uma das estrias. 3. Iteraes para Release: nessa fase ocorrem diversas iteraes at o primeiro release ser completado. Na primeira iterao criado o sistema com toda a arquitetura, nas iteraes seguintes sero adicionadas s funcionalidades de acordo com as prioridades estabelecidas. 4. Validao para Produo (Productionizing): nessa fase so feitos testes extensivos e verificaes para validao do software para ser utilizado em ambientes de produo. 5. Manuteno: aps o primeiro release para produo, h novas edies do sistema com novas funcionalidades. 6. Morte: quando no h mais estrias a serem implementadas, quando o cliente est satisfeito com o cdigo.

Figure 2. Fases do XP Adaptado de [Abrahamsson et al 2002]

Os valores do XP so: simplicidade, coragem, feedback, e comunicao.

4. Comparao entre RUP e XP

As metodologias RUP e XP tm seu funcionamento baseado em iteraes, so orientadas ao cliente e baseadas em papel. Uma anlise superficial nos diria que tratam a dinmica de desenvolvimento de software da mesma forma. Porm atravs da anlise dos tpicos descritos pelo presente captulo as diferenas sero verificadas por aspectos como a forma e freqncia que os artefatos so gerados, quantidade de papis, etc.

4.1. Alocao de Tempo e Esforos RUP segue 4 fases seqenciais (descritas no item 3.1) constituindo um ciclo de desenvolvimento, produzindo uma nova verso de software. Em cada fase h um nmero de iteraes, as quatro fases tm seu foco em diferentes atividades, podendo ocorrer em paralelo. A primeira fase, chamada de incio foca o modelamento do negcio e a definio dos requisitos. A fase de elaborao foca em projetar (design), a de construo d enfoque a implementao e aos testes e por fim a fase de transio onde a implantao e o gerenciamento de modificaes so verificados. O aspecto tempo em XP diretamente relacionado com cdigo produzido. No comeo do projeto o foco o ncleo do sistema, e aps facilidades extras. Porm como as liberaes so definidas pelos clientes, os mesmos iro delimitar o tempo do projeto a partir de seu grau de satisfao com o software recebido. 4.2. Artefatos Um artefato um pedao de informao que produzida, modificada ou usada por um processo [Kruchten 2000]. Como exemplos de artefatos tm-se modelos, cdigo fonte e arquivos executveis. A comunicao dentro de um processo RUP baseada em artefatos. J em XP baseada em comunicao oral, direta, o que restringe o uso de XP em projetos com grande distribuio geogrfica. A pouca evidncia de artefatos do XP, com foco em estrias de usurio e cdigo, visto como um fator que aumenta o risco do projeto, o conhecimento fica vinculado aos desenvolvedores e ao cdigo. 4.3. Atividades e Papis RUP define uma atividade como sendo o trabalho realizado por um papel, usando artefatos de entrada e produzindo artefatos de sada. Os papis (total de 30) definem o comportamento e as responsabilidades do individuo, esto agrupados em nove disciplinas: 1. Gerncia de Projeto (2 papis): tem como objetivo prover meios para a entrega do produto para o cliente que atenda as suas necessidades, gerenciando os riscos do projeto. 2. Modelamento de Negcio (3 papis): visa o entendimento da estrutura onde o software ser aplicado e os problemas atuais do cliente. Esta atividade deve assegurar que o cliente, os seus usurios e os desenvolvedores tenham um entendimento comum do produto a ser entregue. 3. Requerimentos (5 papis): traduz as necessidades do sistema em forma de casos de uso, desenhando a interface com o usurio. 4. Analise e Desenho (6 papis): especifica a forma de implementao (arquitetura) dos requerimentos (casos de uso). 5. Implementao (3 papis): implementa as classes e os objetos em formas de componentes, os quais so individualmente testados.

6. Teste (2 papis): testa e verifica se o produto funciona como o esperado, documentando falhas e problemas. Prov feedback gerncia do projeto sobre a qualidade do software. 7. Deployment (4 papis): tem como objetivo a distruibuio, instalao e teste (quando beta) em campo, provendo treinamento e possveis migraes (banco de dados) entre o sistema anterior e o atual. 8. Configurao e Controle de Mudanas (2 papis): o objetivo destas atividades (Gerncia de Configurao e Controle de Mudanas) concentra-se na garantia da rastreabilidade de verses dentro de um projeto. Atravs do definio de uma poltica adequada e de ferramentas especficas para versionamento (ClearCase, CVS, SVN) possvel garantir o mapeamento de alteraes efetuadas bem como a recuperao de cdigos e verses antigas. 9. Ambiente (3 papis): prov suporte adequado organizao do projeto, em ferramentas, mtodos e processos. XP [Beck e Fowler 2000] apresenta apenas quatro atividades bsicas: produo de cdigo, testes, listening (escutar o cliente), e desenho. XP define sete papis: 1. Programador: escreve o cdigo e realiza testes individuais. 2. Cliente: o responsvel por escrever as estrias e as prioridades das mesmas. 3. Testador: tem como objetivo auxiliar o cliente a criar testes funcionais. Os testes devem ser realizados regularmente e seus resultados divulgados. 4. Tracker: prov feedback no processo, comparando as estimativas com os resultados obtidos. Analisa o progresso de cada iterao e avalia se os objetivos podem ser alcanados com os recursos providos. 5. Tcnico (Coach): tem como responsabilidade o projeto como um todo, guiando os outros membros da equipe. 6. Consultor: membro externo que auxilia o time com assuntos (problemas) tcnicos especficos. 7. Big Boss: responsvel pelo projeto, toma decises e est em constante comunicao com a equipe para diagnosticar possveis problemas ou falhas no processo. Ao compararmos as definies das atividades (disciplinas) e os papis, temos que o RUP faz uma diviso de tarefas de forma especfica, enquanto a diviso de papis proposta pelo XP tem um carter de uso-geral, sem atribuies especficas dentro das atividades. 4.4 Ferramentas O XP no especifica nenhuma ferramenta em especfico para o processo, embora haja ferramentas livres como o XPlanner e o Junit. J o processo no RUP utiliza softwares, como o Rational Rose, que devem ser adquiridos da prpria IBM, juntamente com a documentao. 4.5 Responsabilidade do Cdigo RUP trata o cdigo (geralmente de sistemas grandes) em subsistemas, e para cada subsistema existem membros responsveis pelo mesmo.

J o XP trata o cdigo como coletivo, qualquer programador que encontre algum problema, ou algum trecho que possa ser otimizado, tem permisso para faz-lo. Isso pode agilizar o processo no caso de um programador necessitar corrigir algum mdulo para interagir corretamente com o seu. Porm isso pode ser algo prejudicial, pois podem ocorrer casos onde o cdigo aparentemente incorreto teve um motivo para ser estruturado da maneira que foi. 4.6 Diretivas de Projeto RUP baseado em casos de uso, as descries do uso do sistema so continuamente implementadas, integradas e testadas. J o XP aplica o projeto baseado em teste, casos de teste so implementados antes da escrita do cdigo. XP possui estrias de usurio para guiar o que deve ser implementado. Essas estrias so descries mais simples se comparadas aos casos de uso do RUP. As duas metodologias indicam que o projeto completo no pode ser planejado em detalhe. RUP indica modificao continua dos planos, enquanto o XP prope planejar em detalhes somente o futuro prximo.

5. Concluso
Metodologias para o desenvolvimento de software independente de seus processos especficos buscam reduzir riscos e aumentar a qualidade do produto gerado. As metodologias RUP e XP tm esse fim, pois apresentam mesmos valores como, envolvimento do cliente, iteraes, testes contnuos e flexibilidade. Porm busca-se esses objetivos de forma diferente, atravs de implementaes diferentes. De forma geral o XP se apresenta como uma metodologia a ser utilizada em projetos onde os requisitos so volteis ou no claros sendo assim muito flexvel, porm existe uma limitao de uso em equipes pequenas, pois no d nfase documentao e sim a comunicao oral restringindo sua aplicao em projetos com equipes distribudas geograficamente. A diviso de atividades (tarefas e papis) no XP tambm no muito especfica, sendo uma desvantagem para a diviso de responsabilidades em projetos grandes. O RUP estrutura o projeto fazendo uma diviso bem definida de atividades (tarefas e papis) e define uma coleo de artefatos que so usados como produtos de entrada e de sada de processos. Essa estruturao (com auxlio de softwares) do processo permite que o RUP seja utilizado em projetos grandes, e com distribuio geogrfica, com um custo (esforo) adicional de gerncia do projeto. Esse custo adicional pode no ser justificvel em pequenas equipes.

Referncias
Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta J. (2002) "Agile Software Development Methods: Review and Analysis", Espoo 2002, VTT Publications 478. Beck, K. and Fowler, M. (2000) "Planning Extreme Programming", Addison Wesley, 1a edio. Kruchten, P. (2000) "The Rational Unified Process An Introduction", Addison-Wesley 2a edio.

Luiz, R. (2005) Obtendo Qualidade de Software com o RUP, TCC, Universidade de Uberaba. Pollice, G. (2003) "Using the IBM Rational Unified Process for Small Projects: Expanding Upon eXtreme Programming", IBM whitepaper, ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/TP183.pdf, Abril. Runeson, P. and Greberg, P. (2004) "Extreme Programming and Rational Unified Process Contrasts or Synonyms?", Lund University, Sweden. Smith, J. (2003) "A Comparison of the IBM Rational Unified Process and eXtreme Programming", IBM Whitepaper, ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/TP167.pdf, Abril.