DESENVOLVIMENTO DE SISTEMAS COM

EXTREME PROGRAMMING E RUP

Gerenciando projetos de desenvolvimento de software
Leonardo Willrich1
Cesar Griebeler2
Resumo
Este artigo se propem a fazer uma abordagem do gerenciamento de projeto no
desenvolvimento de softwares utilizando as metodologias Rational Unified Process (RUP) e
Extreme Programming (XP), avaliando se possvel a utilizao de boas prticas conforme
descrito no Project Management Book of Knolodge (PMBoK). Tambm feita uma
abordagem sobre a aderncia da forma de gerenciar de cada metodologia aos processos do
Capability Maturity Model Integration (CMMI).
Palavras-chaves: Rational Unified Process (RUP). Extreme Programming (XP). PMBoK.
CMMI.
1 INTRODUO
Atualmente existe duas vertentes dentro da engenharia de software de metodologias
para desenvolvimento de sistemas, uma vertente so metodologias tradicionais, tambm
chamadas de pesada ou rigorosas. Uma das metodologias mais conhecidas dessas tradicionais
a Rational Unified Process RUP, na qual atualmente mantida pela empresa IBM. Outra
vertente que est emergente a de metodologias geis, onde podemos citar a Extreme
Programming sendo uma dessas metodologias que tem ganhado destaque nos ltimos anos.
Ambas as metodologias, RUP e Extreme Programming, tem o mesmo objetivo,
atender necessidades da rea de desenvolvimento de softwares. Porm cada uma possui uma
particularidade e atende ou foca melhor em determinados requisitos. Dessa forma, acaba
deixando de atender outros requisitos. Podemos assim chamar de pontos fortes e fracos de
cada metodologia.
Segundo Larman (2004), a Engenharia de Software uma busca continua de
melhorias no processo de desenvolvimento de software. Cada vez mais os prazos e custos tem
se tornado uma restrio inalcanvel, mesmo com a evoluo de recursos, novas tecnologias
e mtodos. E um dos principais motivos para isso a excessiva formalidade nos modelos de
processos colocados nos ltimos 30 anos, atravs das metodologias pesadas ou rigorosas.
Por esse motivo, as metodologias geis tm ganhado cada vez mais espao e destaque
dentro do cenrio de desenvolvimento de software. Recentemente o PMI (Project
Management Institute) publicou a primeira certificao em gerenciamento geis, isso
1 MBA Gerenciamento de Projetos. E-mail: leokari14@hotmail.com
2 Mestre em Cincias da Computao. E-mail: cesar@senior.com.br

demonstra o crescimento de profissionais em busca de qualificaes, maiores informaes

podem ser obtidas atravs do site http://www.pmi.org/agile.aspx. Mas embora em alta,
tambm possuem seus pontos fracos, ainda existem casos que a opo pela metodologia
tradicional ainda a melhor escolha, principalmente quando requisitos do sistema so
complexos, estveis e previsveis.
A grande questo como fica o gerenciamento do projeto considerando essas duas
metodologias de software. Ser que possvel gerenciar projetos da mesma maneira, sem que
aja um impacto nos processos de gerenciamento. Muitas empresas tem se apoiado no guia de
boas prticas de gerenciamento de projeto baseada no PMBoK, mantido pelo PMI. Com isso,
porm, fica a dvida se para desenvolver sistemas com a metodologia Extreme Programming
necessrio ou possvel apoiar-se nos processos sugeridos pelo PMBoK.
Nas prximas sees teremos um embasamento terico desses assuntos para
finalmente chegar-se a uma concluso do que possvel construir com essas metodologias
aliadas as boas prticas de gerenciamento de projeto conforme o PMBoK. Tambm ser
avaliado a aderncia dessas metodologias junto ao Capability Maturity Model Integration
(CMMI).
2 RATIONAL UNIFIED PROCESS RUP
Os processos do IBM Rational Unified Process, conhecido como RUP, possuem uma
abordagem que se caracteriza por ser iterativo voltado a casos de uso, centrado na arquitetura
e riscos. Esses processos descrevem o que, quem e como deve ser realizado o
desenvolvimento e a instalao de software.
Conforme Kroll e Kruchten (2003) existem trs definies para o Rational Unified
Process (RUP). A primeira dela que se trata de uma metodologia que se caracteriza por ser
iterativo, voltado a casos de uso e centrado na arquitetura. A segunda define como sendo um
processo de engenharia de software bem definido e bem estruturado, onde se tem bem
definido quem responsvel pelo o que, como as coisas devem ser feitas e quando faz-las.
Compreende tambm o ciclo de vida de um projeto, deixando bem claro os marcos para
pontos de deciso do projeto. A terceira e ltima definio diz que RUP tambm um produto
do processo que oferece uma estrutura de processo customizvel para engenharia de software.
Essa adaptao tem como objetivo suportar equipes pequenas ou grandes e tambm tcnicas
de desenvolvimento diferentes, podendo ter menos ou mais disciplinadas e serem mais ou
menos formais.
O RUP utiliza a Linguagem Unificada de Modelagem (UML Unified Modeling
Language), para especificar, modelar e documentar artefatos. A UML um padro definido
pelo OMG e tem se tornado o padro empresarial para a modelagem orientada a objetos. A
primeira verso do RUP 5.0 surgiu em 1998 provinda da evoluo de projetos anteriores,
como o Rational Objectory Process que teve seu inicio em 1996. Desde ento varias
melhorias foram implementadas at a verso RUP 2000.
2.1 FASES DO CICLO DE VIDA DO RUP
Existem quatro fases no ciclo de desenvolvimento da metodologia RUP, cada uma possui
marcos de finalizao, tambm chamados de milestones. Os milestones so utilizados como
indicadores de progresso do projeto e so usados durante o projeto como base de decises
para continuar, abortar ou mudar o rumo do projeto. Essas quatro fases do RUP so:

1. Inception (Incio): Tem como objetivo conceber o escopo do desenvolvimento,

levando-se em conta a viso do produto final utilizando-se a definies de casos de
uso.
2. Elaboration (Elaborao): Nessa fase realizado o planejamento das atividades e
recursos necessrios. Deve-se focar nos riscos tcnicos e arquiteturais, revisar-se o
escopo e compreender bem os requisitos.
3. Construction (Construo): Essa fase a que consome mais esforo durante o projeto,
normalmente executada em mais de uma iterao em projetos grandes. Aqui
comeam-se a implementao do software atravs da construo do cdigo. Toda
ateno voltada aos riscos lgicos.
4. Transition (Transio): Nessa fase acontece o envolvimento com os usurios,
geralmente atravs de treinamentos e verses betas. Os riscos nessa fase esto
associados a logstica de distribuio do produto para a base dos usurios.
2.2 OS ELEMENTOS DO RUP
Conforme Luiz (2005), a metodologia RUP possui cinco elementos, so eles:
atividades, papis, disciplinas, artefatos e fluxo de trabalho. Papel responsvel por definir a
responsabilidade e comportamento de um indivduo ou grupo dentro do trabalho de equipe.
Pode-se citar como exemplo de papeis o analista de sistema e o projetista. Atividade uma
unidade de trabalho onde executada por um individuo quando est exercendo um
determinado papel com a finalidade de produzir um resultado. Artefatos so produtos do
projeto e um pedao de informao criado, modificado ou utilizado por um processo. O
fluxo de trabalho o seqenciamento das atividades para que possam ser produzidos artefatos
de valor para o projeto. E por fim, uma disciplina um conjunto de atividades de possuem
relacionamento entre si fazendo parte de um contexto comum dentro do projeto.
A diviso de atividades por disciplinas torna o entendimento mais fcil, porm,
dificulta do planejamento. Existem nove disciplinas, que so classificadas em disciplinas do
processo e de suporte. De processo so: modelagem de negcios, requisitos, anlise e projeto,
implementao, teste e distribuio. As de suporte so: configurao e gerenciamento de
mudanas, gerenciamento de projeto, e ambiente.
A figura abaixo demonstra de forma ilustrada a iterao entre as fases, iteraes de
disciplinas.

Figura 1: Arquitetura geral do RUP

Fonte: Luiz (2005)
3 EXTREME PROGRAMMING
Conforme Wells (2011), Extreme Programming uma metodologia gil de
desenvolvimento com objetivo na satisfao do cliente e de entregar somente o software como
o cliente precisa, nem com requisitos a mais e nem a menos. Para isso, essencial o feedback
constante de todo time, gerente e cliente, fazendo com que o nvel de comunicao seja alto.
Para entregar o que foi somente pedido necessrio simplicidade, sem pensar muito em
arquiteturas complexas e grandes solues complexas. E, para conduzir projetos dessa forma,
preciso principalmente de coragem.
Com isso, surgem os valores pregados pelo XP, que so: feedback, comunicao,
simplicidade e coragem. Com base nesses valores que os processos so concebidos e que
acontece o desenvolvimento de software.
Uma das caractersticas importante do XP que no existe um planejamento integral
do projeto, somente se planeja o que vai ser desenvolvido nas prximas semanas. Essa prtica
conhecida como desenvolvimento incremental. Com isso a metodologia fora a envolver o
time do projeto, gerente e cliente no trabalho, formando um grande time colaborativo no qual
todos so responsveis pelo trabalho. O corao do planejamento so os user stories. Estes
por sua vez podem ser impressos ou escritos a mo em cartes, servem para o time ter uma
viso clara e estruturada dos objetivos do ciclo. Assim, pode-se rapidamente definir o escopo
e planejar o projeto manipulando estes cartes atravs de um exerccio iterativo com o time.
Abaixo se pode observar os ciclos do planejamento e codificao do software, baseado
num dos valores do XP, o feedback.

Figura 2: Planejamento e feedbacks

Fonte: Wells, 2011
Segundo Wells (2011), esta metodologia deve ser usada em casos onde os requisitos no so
estveis e mudam a todo instante, ou seja, o cliente no tem uma idia firme do que quer
fazer. Por isso nesse ambiente os valores de XP se adaptam bem e conseguem se mostrar
como um diferencial. recomendado para um grupo de pequenos de desenvolvedores, sendo
este de 2 a 12, embora se tenha conhecimento que projetos com mais de 30 desenvolvedores
tenham obtido sucesso utilizando a metodologia XP.
Com finalidade de tornar todo desenvolvimento e gerenciamento do projeto de forma
gil, XP adota algumas prticas, algumas delas so: cliente presente, jogo do planejamento,
stand up meeting, programao em par, desenvolvimento guiado pelos testes, refactoring,
cdigo coletivo e padronizado e design simples.
Alguns comentrios sobre essas prticas conforme Gomes (2008):
A prtica de cliente presente ajuda bastante o desenvolvimento do sistema.
Entretanto, h um ponto timo nesta questo. Nenhum programador gostaria
ter que mudar um campo de lugar toda vez que o cliente sentar ao seu lado.
O stand up meeting uma tima prtica, no? Algum j ficou numa reunio
que durou 4 horas e no resolveu coisa alguma? Ou tambm em uma reunio
to longa que o assunto poderia ser resolvido em 20 minutos! Isso impacta na
produtividade da equipe!
A programao em par interessante, pois um programador d opinio no
cdigo do outro. Assim, o resultado um cdigo mais discutido e mais
otimizado. O problema aqui o custo. Remunerar dois programadores para

fazer o trabalho de um oneroso! Mesmo que o cdigo saia com uma

qualidade muito superior, teoricamente, uma pessoa j deveria construir um
cdigo otimizado.
Outra caracterstica importante de citar a relao do impacto do custo das mudanas
num projeto utilizando-se a metodologia XP. Ao contrrio das metodologias tradicionais, que
quanto mais tarde se solicita uma mudana, mais impacto no custo ela tem, as metodologias
geis mitigam esse risco trazendo o feedback constante do cliente para prximo da equipe e
solicitaes de mudanas acontecem mais cedo. Essa caracterstica pode se demonstrada
atravs das ilustraes abaixo.

Metodologias tradicionais
Metodologias geis
Figura 3: Comparao do custo de mudanas
Fonte: Adaptado de Gomes (2008)

4 GERENCIANDO PROJETOS COM PMBoK

Conforme PMI (2008), o gerenciamento de projetos se d em 5 grupos de processos
que esto divididos em 9 reas do conhecimento totalizando 42 processos. Os grupos de
processo so focados no ciclo de vida do projeto, so eles: iniciao, planejamento, execuo,
controle e monitoramento e por fim encerramento. As reas abordadas so: escopo, tempo,
custo, qualidade, recursos humanos, comunicao, riscos, aquisies e integrao. As fases do
projeto so iterativas e normalmente o planejamento em ondas (wave planning). A ilustrao
abaixo demonstra essa iterao entre os projetos.

Figura 4: Grupos de processos

Fonte: DAVILA (2010)
Cada processo dividido em trs partes, que so as entradas, as ferramentas e tcnicas
e sadas. As entradas so todos os subsdios que so necessrios para produzir o produto do
processo atravs das ferramentas e tcnicas de cada processo. Normalmente, pelo fato desses
processos serem interligados entre si, sadas de alguns processos so entradas para outros. Na
ilustrao abaixo pode-se ver a iterao de todos processos, por rea de conhecimento,
conforme quarta edio publicada do PMBoK em 2008.

Figura 5: Processos PMBoK quarta edio

Fonte: DAVILA (2010)
5 COMPARANDO XP E RUP E SUAS APLICAES
Pode-se dizer que em projeto pequenos a relao ao tempo total necessrio para o
desenvolvimento do software praticamente o mesmo entre as duas metodologias e que cada
verso produzida pelo XP equivale-se a uma iterao do RUP. Em equipes grandes, quando
aplica-se RUP, todo trabalho dividido em subsistemas dentro de equipes divididas e a
programao ocorre paralelamente. J com XP, a programao ocorre em pares e no existe a
diviso do trabalho em subsistemas (Moreira, 2011).
Outra diferena bastante notvel entre XP e RUP, conforme cita Moreira (2011), a
forma de comunicao. RUP baseia-se principalmente em artefatos que so produzidos,
modificados e usados por processos. J no XP tem-se a comunicao direta, via oral, sem
nenhum tipo de formalizao. Isso restringe XP com relao a times virtuais, que esto em
posies diferentes geograficamente. Por isso quando se utiliza XP extremamente necessrio
que se tenha confiana mutua entre as partes, caso contrrio, com esse tipo de comunicao
tente-se a repudiar as informaes e a distorcer os fatos.
De acordo com a tabela 1 pode-se observar as principais diferenas dentre XP e RUP
considerando-se as principais prticas ou conceitos das metodologias. Desse forma pode-se
claramente visualizar que cada uma possui pontos fortes e fracos, enquanto o foco do RUP
so projetos complexos, onde necessrio um maior controle e formalizao, XP possui seu
foco em projetos mais simples, no qual busca-se obter ganho de tempo evitando uma
formalizao exagerada que gera uma burocracia desnecessria.

Prtica ou
conceito
Iterativo e incremental
Voltado para a
arquitetura
Voltado para a validao
Interao
desenvolvedor/cliente
Interao
desenvolvedor/gerente
Interao
desenvolvedor/suporte
Gerenciamento de risco
Qualidade de cdigo
Gerenciamento dos
pontos-chave
Equipes grandes
Equipes pequenas
Projetos complexos
Casos de uso

RU
P XP
SIM

SIM

SIM

NO

NO

SIM

NO

SIM

SIM

NO

SIM

SIM

SIM

SIM

NO

SIM

SIM

NO

SIM

NO

NO

SIM

SIM

NO

SIM

SIM

Tabela 1: Comparativo entre XP e RUP

Fonte: adaptado de Moreira (2011).
6 CONSIDERAES FINAIS
Estas metodologias, tanto a tradicional como gil, exigem realizar esforo de
gerenciamento do projeto. Embora o RUP aponte alguns processos nesse sentido, ele ainda
carente no gerenciamento completo do projeto onde alguns processos no so atendidos. E
quanto ao XP pode-se ver que alm de ser uma forma diferenciada de desenvolver sistema
tambm traz uma forma diferencia de gerenciamento. Pode-se dizer que no XP exige maior
habilidade do gerente de projeto no quesito comunicao, pois a maior parte do projeto
integrando equipe do projeto com o cliente.
Agora, como se pode dizer que o guia de boa prticas de gerenciamento de projeto
mantido pelo PMI, o PMBoK, pode auxiliar no gerenciamento utilizando essas duas
metodologias de desenvolvimento. Essa uma questo simples, visto que o PMBoK no
trata-se de uma metodologia e pode-se pinar as melhores prticas e adotar o uso de processos
avulsos, sem a necessidade de seguir uma metodologia propriamente dita.
Porm, no se pode afirmar que estas metodologias so aderentes as prticas do
CMMI, isso pode ser comprovado pois XP no possui um planejamento integral do projeto,
visto que seu desenvolvimento incremental. Por essa razo empresas geis tem dificuldade
de se certificar com nvel de maturidade, justamente por causa do gerenciamento do projeto.
J o RUP, por ser uma metodologia tradicional, pode ser facilmente complementada
pelas boas prticas do PMBoK a fim de se constituir uma metodologia customizada com o

objetivo de atender as prticas do CMMI, por sua vezes, a possibilidade de empresas que
utilizam essa metodologia se certificarem CMMI grande. Existem muitos estudos que
demonstram como complementar a disciplina de gerenciamento de projeto do RUP com o
PMBoK. Um deles demonstrado por De Campos e Lima (2011) onde cita-se essas lacunas e
como podem ser preenchidas utilizando as boas prticas de gerenciamento do PMBoK.
Tambm aponta-se as dificuldades que existe em convergir esses dois assuntos a comear pela
prpria estruturao, pois o RUP esta estruturado num website enquanto o PMBoK num livro.
Apesar dessa dificuldade, pode-se criar uma metodologia de desenvolvimento de software,
tradicional, capaz de ser aderente as prticas do CMMI.
Segundo Gomes (2008), o XP e o PMBoK so completamente opostos, com focos
diferentes, mas podem se complementar a fim de criar-se uma metodologia adaptada que
assegura alguns pontos fracos do XP, entre eles a documentao do projeto. Uma das
principais divergncias est na priorizao, o PMBoK prioriza o escopo em primeiro lugar,
para depois planejar o tempo, j XP prioriza primeiro o tempo.
Considerando que possvel a criao de uma metodologia com base no XP,
aprofundando-se nos requisitos de documentao, passvel de se pensar que tambm
possvel essa ser aderente as prticas do CMMI. Porm, certo que a agilidade no seria a
mesma, mas nada impediria de se adotar algumas prticas do PMBoK para tornar o
gerenciamento mais completo e com requisitos possveis de serem rastreados.
Pode-se ento concluir que vivel a adaptao do PMBoK juntamente com as
metodologias RUP ou XP para conceber uma metodologia adaptvel, procurando foco no
cliente ou no tempo de acordo com as prioridades da empresa, e que seja aderente as prticas
do CMMI garantido a possibilidade de uma avaliao de maturidade em desenvolvimento de
software.
6 REFERNCIAS
D'VILA, Mrcio. PMBOK e Gerenciamento de Projetos. Reviso 3, 4 de maio de 2010.
Disponvel em: < http://www.mhavila.com.br/topicos/gestao/pmbok.html >. Acesso em: 20
maro 2011.
DE CAMPOS, Ldio Mauro Lima e LIMA, Alberto Sampaio. Gerenciamento de Projetos de
Desenvolvimento de Software com o RUP e o PMBOK. Disponvel em:
<http://www.aedb.br/seget/artigos09/163_seget_2009.pdf >. Acessado em: 20 maro 2011.
GOMES, Gleison Carneiro. Integrando o Extreme Programming com o PMBOK. Publicado
17
de
fevereiro
de
2008.
Disponvel
em:
<http://www.imasters.com.br/artigo/7958/desenvolvimento/integrando_o_extreme_programm
ing_com_o_pmbok/>. Acessado em: 20 maro 2011.
KROLL, P. e KRUCHTEN, P. (2003) The Rational Unified Process Made Easy: A
Practitioner ' s Guide to the RUP , Addison Wesley
LARMAN, C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis
and Design and Iterative Development. 3. ed. Prentice Hall, 2004.
LUIZ, R. (2005) Obtendo Qualidade de Software com o RUP, TCC, Universidade de
Uberaba.

MOREIRA, Albert Menezes. Metodologias de desenvolvimento: um comparativo entre extreme

programming e rational unified process. Disponvel em: < http://albertmoreira.com.br/wpcontent/conteudo/academico/Artigo%20XP%20x%20RUP%20v3.pdf>. Acesso em: 01 maio
2011.

PROJECT MANAGEMENT INSTITUTE (PMI), Guia de Conhecimentos em Gerenciamento

de Projetos, Quarta Edio, Pensilvnia , 2008.
WELLS, Don. Extreme Programming: A gentle introduction. Disponvel em:
<http://www.extremeprogramming.org/> Acesso em: 20 maro 2011.