1

METODOLOGIAS DE DESENVOLVIMENTO: UM COMPARATIVO ENTRE

EXTREME PROGRAMMING E RATIONAL UNIFIED PROCESS

CASTRO, Izabel Cristina Andion 1

MOREIRA, Albert Menezes2

RESUMO

Atualmente, no âmbito da Engenharia de Software, uma boa metodologia de projetos tem se

tornado um fator diferencial, visto que influencia diretamente na qualidade do produto final.
Este artigo apresenta o histórico do processo de desenvolvimento de software e faz uma
comparação entre a metodologia rigorosa Rational Unified Process (RUP) e a ágil Extreme
Programming (XP). Finalmente, são mostrados casos de sucesso das duas abordagens.

Palavras-chave: Engenharia de Software, metodologias rigorosas, metodologias ágeis,

Extreme Programming, Rational Unified Process.

1. INTRODUÇÃO

O que se busca na Engenharia de Software é o incessante melhoramento do processo de

desenvolvimento de software. Os prazos e custos estipulados podem não chegar a serem
alcançados, mesmo com a crescente evolução da tecnologia, métodos e recursos. Um dos
principais motivos é a excessiva formalidade nos modelos de processos colocados nos últimos
30 anos (LARMAN, 2004). Existe então a necessidade de desenvolver software de forma
mais rápida, sem que se perca a qualidade. O novo paradigma em desenvolvimento de
software é que se pode obter esse resultado por meio da utilização de métodos ágeis.

Embora as metodologias ágeis tenham sido apontadas como alternativa às abordagens

tradicionais para o desenvolvimento de software, as metodologias tradicionais, conhecidas
também como rigorosas, pesadas ou orientadas a planejamentos, possuem utilização garantida
no que diz respeito a situações em que os requisitos do sistema são complexos e estáveis e
requisitos futuros são previsíveis.

Este artigo aborda vantagens e desvantagens de metodologias ágeis e de metodologias

rigorosas, particularmente, da metodologia rigorosa Rational Unified Process e da ágil
Extreme Programming, além de citar casos de sucesso da aplicação de ambas. Na seção 2, é
apresentado o histórico do processo de desenvolvimento de software, desde o uso restrito das
metodologias tradicionais até a criação do Manifesto Ágil. Nas seções 3 e 4 são apresentados
conceitos básicos sobre os métodos ágeis e tradicionais, respectivamente, além de suas
aplicações. Na seção 5, é apresentado um comparativo entre o método RUP e o XP e, na
sessão 6, casos de sucesso relacionados a estas. Por fim, na seção 7, estão as considerações
finais.

1
Izabel Cristina Andion Castro é mestra em Redes pela UNIFACS.
2
Albert Menezes Moreira é graduando do curso de Sistemas de Informação da Faculdade Ruy Barbosa.
 2

2. HISTÓRICO

Baseadas em mainframes e terminais burros, as metodologias tradicionais fizeram parte,

inicialmente, de um contexto de desenvolvimento de software muito diferente do atual
(ROYCE, 1970). O custo para que modificações fossem feitas era alto, devido às limitações
dos computadores e falta de ferramentas modernas para apoiar a criação do software, tais
como depuradores e analisadores de código. Sendo assim, o software era antes planejado e
documentado para então ser implementado. O modelo Clássico caracterizado como
metodologia tradicional é utilizado até hoje.

Nos últimos anos, novas metodologias foram aplicadas, sempre visando a rapidez no
fornecimento aliada à qualidade do processo e do produto. Surgem, então, os métodos ágeis,
popularizados quando Beck et al. (2001) criaram o Manifesto Ágil, indicando alguns
princípios compartilhados por tais métodos:

a) indivíduos e interações são mais importantes que processos e ferramentas;

b) software funcionando é mais importante do que documentação detalhada;
c) colaboração dos clientes é mais importante do que negociação de contratos;
d) adaptação às mudanças é mais importante do que seguir um plano.

Nesta nova abordagem a reutilização de software é uma prática comum durante o

desenvolvimento. Os padrões de projeto contribuem para o reuso em situações em que é
preciso um nível alto de abstração, sobretudo na fase de análise, na definição da arquitetura do
sistema, em questões organizacionais e de otimização dos processos, sendo que esses dois
últimos têm por objetivo apoiar a construção do software e melhorar o seu desenvolvimento.
O uso de componentes é outro aspecto possível. Deste modo, a integração dos padrões
organizacionais e de processo proporciona rapidez e qualidade no desenvolvimento.

3. METODOLOGIAS RIGOROSAS

Essas metodologias são assim denominadas porque enfatizam o rigor nas premissas e
propostas. Prezam pela documentação detalhada em todas as fases do desenvolvimento.
Geralmente são implementadas em ambientes onde se deve exercer controle rígido, como por
exemplo quando é grande o número de indivíduos que participam do projeto. Também são
conhecidas como metodologias pesadas, uma referência à quantidade de documentos, papéis,
atividades e processos considerados necessários para a implementação. O resultado disso é
que os desenvolvedores passam boa parte do tempo ocupados com atividades que não são
necessariamente ligadas à programação ou seu processo criativo.

O modelo Clássico foi o primeiro processo de desenvolvimento de software publicado

(PRESSMAN, 2001). É um modelo que apresenta uma seqüência a ser seguida. Cada etapa
tem uma documentação que precisa ser aprovada para que se dê início à etapa seguinte. De
uma forma geral fazem parte do modelo Clássico as etapas de definição de requisitos, projeto
do software, implementação e teste unitário, integração e teste do sistema, operação e
manutenção (SOMMERVILLE, 2003). A figura 1 mostra a disposição dessas fases,
juntamente com a ordem de aplicação:
 3

Figura 1: Fases do modelo Clássico

Adaptado de: SOMMERVILLE, 2003

O problema deste modelo, também chamado de modelo em Cascata, é a impossibilidade de

criação de fases intermediárias ou até mesmo revisão de fases anteriores antes que o processo
termine. Fred Brooks, em seu artigo “No Silver Bullet: Essence and Accidents of Software
Engineering”, sustenta essa idéia na afirmação de que é impossível especificar totalmente um
software antes da sua implementação (BROOKS, 1987). Isso dificulta alterações, fator
comum no desenvolvimento de um projeto. Sua utilização é feita quando os requisitos estão
bem compreendidos. O modelo Clássico ainda perdurou até a década de 90 como forma de
desenvolvimento e foi utilizado com sucesso quando os requisitos estavam bem
compreendidos.

Rational Unified Process

Atualmente, um grande representante das metodologias rigorosas é o RUP, um recurso de

Engenharia de Software, criado pela empresa Rational Software Corporation que descreve a
maneira de desenvolver um software usando técnicas comerciais e objetivando o aumento da
qualidade do produto gerado. É classificado também como um processo de Engenharia de
Software, que tem como principal objetivo garantir o desenvolvimento de sistemas com
qualidade, respeitando os requisitos solicitados pelo cliente, em prazos e custos determinados.
Pode ser considerado como um conjunto de experiências e boas práticas adquiridas por
diversas pessoas e empresas envolvidas com o desenvolvimento de softwares.

Sua primeira versão, o RUP 5.0, surgiu em 1998, oriunda da evolução de projetos anteriores,
como o Rational Objectory Process, iniciado em 1996. Várias características foram
melhoradas e acrescentadas até a versão RUP 2000.

A aplicação do RUP se dá em variados projetos, sendo tratado como um arcabouço

(framework) genérico para os processos de desenvolvimento, considerando a configuração
adequada para o tamanho e a necessidade do projeto e os padrões aplicados na empresa.
Associada a este modelo, a Rational Software construiu também um conjunto de ferramentas
de suporte ao desenvolvimento (RUP, 2007). A Unified Modeling Language - UML, que
oferece um conjunto de modelos para auxiliar o desenvolvimento de software, é um exemplo
de linguagem que foi criada para apoiar a utilização do RUP.
 4

Como bases para a criação deste método foram adotadas algumas características de qualidade
de software, que permitem atingir os objetivos desejados. Dentre elas, seis características
merecem destaque especial:

a) o uso de interações com o cliente para desenvolvimento de softwares;

b) gerenciamento de requisitos;
c) utilização de artefatos visuais, a exemplo de modelos UML;
d) controle de qualidade;
e) controle de mudanças;
f) a necessidade da utilização de uma metodologia de desenvolvimento de sistemas.

No modelo RUP, um projeto é dividido diversas fases, desde a Modelagem do Negócio até o
Ambiente. Estas ainda possuem outras 4 subdivisões, que constituem o ciclo de construção de
uma versão, como é mostrado na figura 2:

Figura 2: Ciclo de construção de uma versão usando RUP

Adaptado de: KRUCHTEN, 2000.

A fase de Concepção, Inception phase, é quando deve ser definido o escopo da versão,
especificando o produto a ser gerado. É nessa etapa que se avaliará a viabilidade do projeto,
pois neste momento os requisitos operacionais e os critérios de aceitação serão apresentados.
Devem ser levantados os riscos que possam comprometer o andamento do projeto, levando
em consideração questões de arquitetura. É pertinente também a aplicação de um cronograma
preliminar. Dentre os produtos finais desta fase estão o cronograma, o diagrama de caso de
uso inicial, o caso de uso do negócio que, quando aplicado em sistemas comerciais, deve
fornecer uma estimativa de retorno do investimento e o protótipo preliminar (MAGALHÃES,
2003).

O objetivo da fase de Elaboração, Elaboration phase, é analisar o domínio do problema, criar

o plano de projeto, a arquitetura e remover os elementos de alto risco. Tratam-se de riscos de
requerimentos, tecnológicos em relação à capacidade das ferramentas disponíveis, de
habilidades dos integrantes do projeto e políticos (RUP, 2007). É uma etapa crítica, pois o que
for definido nesta fase será utilizado como base para as próximas e à medida que o projeto
avança aumenta o custo de modificações.
 5

A fase de Construção, Construction phase, consiste no desenvolvimento do produto. É a etapa

de construção do código, com ênfase no gerenciamento de recursos e controle das operações,
adotando medida de redução dos custos. Nesta fase, os componentes gerados são também
testados e submetidos aos critérios de aceitação que foram definidos na fase anterior. Ao fim
desta fase, o produto estará pronto para ser entregue ao usuário, integrado às plataformas
necessárias, com manual de usuários e uma descrição sobre esta versão (MAGALHÃES,
2003).

Na fase final do processo, que é chamada de Transição, Transition phase, o produto será
entregue. Engloba também os procedimentos de treinamento, suporte e manutenção. Esta fase
inclui os testes finais de aceitação, no intuito de captar o feedback do usuário a respeito dos
resultados, além de comparações com outros sistemas antigos, conversões de banco de dados
(se for o caso) e a divulgação do novo produto.

As interações mostradas na figura 2 evidenciam o compromisso do RUP com o

desenvolvimento incremental, que é construir o código e fazer os testes com componentes do
sistema, gerando releases a cada fase. No fim da fase de Elaboração, o protótipo da
arquitetura está disponível para avaliação. Durante cada iteração da fase de Construção,
componentes terminados são integrados ao projeto. O ponto chave para este elemento é um
conjunto de testes que acompanham a construção do produto (PROBASCO, 2000). O RUP
permite a divisão do projeto em partes que serão desenvolvidas através de iterações, ou seja,
repetição de todo o ciclo para cada uma das partes que serão integradas e incrementadas até o
produto final.

O RUP também pode ser utilizado no desenvolvimento e manutenção de projetos de pequeno

ou de médio porte. Para que isso seja possível, algumas etapas ou passos podem ser
eliminados a depender das características do projeto para simplificar ou diminuir as
necessidades de documentação, minimizando a formalização (KOHRELL e WONCH ,2005).
As diferentes configurações do RUP possibilitam o suporte de equipes grandes e pequenas,
além de técnicas de desenvolvimento disciplinadas ou menos formais (KRUCHTEN, 2000).

Vale ressaltar que existe a coerência do modelo de processos RUP com os requisitos para
certificação do processo de desenvolvimento Capability Maturity Model - CMM, onde as
empresas de desenvolvimento podem certificar seu modelo de processo de desenvolvimento
no quesito de maturidade e garantia de qualidade dos produtos gerados. Por exemplo, no
terceiro nível do CMM, o conceito de processo é fortemente introduzido na organização. A
arquitetura implantada do CMM nível 3 servirá como base para a execução das práticas de
todas as áreas chave. Essa arquitetura torna-se, então, peça fundamental para a organização
dos processos e sucesso do projeto. Com a adoção do RUP uma empresa já possui os pré-
requisitos para passar para o nível 3 do CMM (PIRES et al., 2007).

4. METODOLOGIAS ÁGEIS

Como foi apresentado no segundo capítulo, o termo Metodologias Ágeis se tornou popular
quando dezessete especialistas em processos de desenvolvimento de software estabeleceram
conceitos comuns a serem compartilhados por todos esses métodos. Foi então criada por
BECK et al. (2007) a Aliança Ágil e instaurado o Manifesto Ágil.
 6

O objetivo do Manifesto Ágil não é desconsiderar processos, ferramentas, documentação,

negociação de contratos ou planejamento, mas mostrar o valor secundário que estes possuem
diante dos indivíduos e interações, do bom funcionamento do software, da colaboração do
cliente e das respostas velozes às modificações. Esses conceitos estão mais relacionados à
forma que as pequenas e médias empresas trabalham, devido a estarem habituadas a
mudanças. A mais conhecida dentre as metodologias ágeis é a Extreme Programming.

Extreme Programming

A Extreme Programming - XP - é uma metodologia ágil voltada às equipes pequenas e médias

que desenvolvem software baseado em requisitos vagos e que se alteram com rapidez (BECK,
1999). As principais diferenças da XP em relação às outras metodologias são feedback
constante e abordagem incremental. A figura 3 mostra algumas das características da Extreme
Programming:

Figura 3: Características da XP
Adaptado de: XP, 2007.

Nesta prática, é interessante que haja comunicação entre os indivíduos. O projeto C3, da
Chrysler, foi o primeiro a usar a XP. Depois de anos tentando outras metodologias sem
resultado, o uso da nova metodologia trouxe resultados satisfatórios em pouco mais de um
ano (HIGHSMITH et al., 2000).

Grande parte das regras aplicadas à metodologia XP podem não fazer sentido à primeira vista,
no entanto o diferencial são as partes que se complementam, o conjunto. A preocupação
maior é com o rápido de desenvolvimento e satisfação do cliente, cumprindo as estimativas de
tempo e custo. Os valores aplicados na Extreme Programming oferecem um ambiente
propício para o progresso no trabalho. De acordo com definições da metodologia XP (2007),
seus principais valores são: comunicação, simplicidade, feedback e coragem.

O objetivo da comunicação é criar e manter o melhor relacionamento possível entre cliente e

provedor de serviços, dando preferência, neste caso, a conversas pessoais do que através de
outros meios. É encorajada também a comunicação entre desenvolvedores e gerente do
 7

projeto. Este se caracteriza como um dos fatores principais na XP: conversar ao máximo
pessoalmente, evitando o uso do telefone e mensagens de e-mail.

A simplicidade visa a minimizar do código, desprezando funções consideradas desnecessárias

ou não essenciais. Isto quer dizer que deve ser implementado o menor número de classes e
métodos. Deve-se também estar sempre procurando atender os requisitos emergenciais,
evitando adicionar funcionalidades ligadas à evolução do produto. O importante é ter em
mente que os requisitos são mutáveis. Sendo assim, o interessante na prática da Extreme
Programming é implementar apenas que é estritamente necessário.

O contato incessante com o cliente a respeito do projeto é o que se pode chamar de feedback
constante. Informações sobre o código são dadas por testes periódicos, os quais indicam erros
tanto individuais quanto do software integrado. Além disso, o cliente terá sempre uma parte
do software funcional para avaliar. Com isso, novas características e informações são
repassadas aos desenvolvedores, que por sua vez devem implementá-las nas próximas
versões. Desta maneira, o que se pretende é entregar o software de acordo com as expectativas
do cliente.

A coragem se encaixa na implantação dos três valores anteriores. São necessários

profissionais comunicativos e com facilidade de se relacionar. A coragem auxilia a
simplicidade, quando a possibilidade de simplificar o software é detectada. Por fim, a
coragem é necessária para garantir que o feedback do cliente ocorra com freqüência, pois esta
abordagem implicará na possibilidade de mudanças constantes do produto.

A orientação para o perfil das equipes no XP é de programadores experientes, já que é

necessária a boa utilização do tempo de desenvolvimento do projeto. No que diz respeito à
certificação CMM, a metodologia XP não possui os pré-requisitos necessários para sua
implementação.

5. COMPARATIVO ENTRE RUP E XP E SUAS APLICAÇÕES

No que diz respeito ao quesito tempo, é provável que o que é gasto pelas versões usando XP
coincida com as iterações do RUP. Tal ocorrência não se aplica a projetos grandes, por se
caracterizarem pela grande duração de suas iterações. Em projetos maiores, as equipes no
RUP são geralmente divididas para se desenvolver paralelamente, cada uma com um
subsistema. Embora a XP aplique a programação em duplas, o projeto é tratado como um
todo, não em subsistemas.

Na visão de Kruchten (2000), artefato é uma parte de uma informação produzida, modificada
ou usada por um processo. São exemplos de artefato modelos, documentação, código fonte e
arquivos executáveis. No Rational Unified Process, a comunicação é feita por meio de
artefatos. A XP é baseada em comunicação oral, direta, restringindo ou limitando o uso da XP
em projetos nos quais os desenvolvedores se encontram geograficamente dispersos. A partir
da premissa de que os artefatos da XP possuem foco em estórias de usuário e código, o risco
de projeto pode aumentar. Neste momento, a confiança recíproca é um fator vital.

Acerca das atividades e dos papéis dentro do desenvolvimento do projeto, o RUP divide as
tarefas de forma específica, ao passo que a divisão da XP não distingue funções específicas
dentro das atividades. Isto quer dizer que o programador de um projeto que adote a Extreme
 8

Programming não está necessariamente preso a determinada atividade, podendo se encaixar

em outra, caso seja necessário.

O RUP especifica e utiliza softwares da IBM, como o Rational Rose, embora já existam
várias ferramentas que podem ser utilizadas. Por outro lado, a XP não especifica uma
ferramenta para o processo, ainda que possa utilizar ferramentas livres como o Junit e o
XPlanner (XP, 2007).

Para tratar o código, o Rational Unified Process o subdivide em subsistemas (quando se trata
de um sistema grande), delegando também membros responsáveis para cuidar de cada uma
das partes (IBM, 2007). O XP trata o código coletivamente, permitindo que qualquer
programador modifique o código caso encontre algum problema ou solução de otimização.

Para garantir a veracidade do conhecimento nas metodologias, existem as certificações, que

têm como finalidade atestar publicamente e por escrito que o produto, serviço, sistema, ou
neste caso, o indivíduo, está em conformidade com as normas, requisitos ou regulamentos. No
caso do RUP, o Rational Unified Process v2003 Certification test é considerado o ponto de
partida, por ser a certificação base desta metodologia (IBM, 2007). Por outro lado, de acordo
com Brewer (2007), não existe entidade certificadora para a Extreme Programming, não
havendo, então, um teste para abordar conhecimentos desta metodologia.

A tabela 1 apresenta algumas características presentes nas metodologias RUP e XP:

Tabela 1: Comparativo entre RUP e XP. Adaptado de: RAWSTHORNE, 2007

Prática ou conceito RUP XP

Iterativo e incremental SIM SIM
Voltado para a arquitetura SIM NÃO
Voltado para a validação NÃO SIM
Interação desenvolvedor/cliente NÃO SIM
Interação desenvolvedor/gerente SIM NÃO
Interação desenvolvedor/suporte SIM SIM
Gerenciamento de risco SIM SIM
Qualidade de código NÃO SIM
Gerenciamento dos pontos-chave SIM NÃO
Equipes grandes SIM NÃO
Equipes pequenas NÃO SIM
Projetos complexos SIM NÃO
Casos de uso SIM SIM

De acordo com as comparações da tabela 1, pode-se concluir que ambas as abordagens têm
pontos fortes e fracos (MOLPECERES, 2007). Enquanto o foco do Rational Unified
Programming são projetos complexos, nos quais são necessárias especificações maiores do
projeto, a Extreme Programming possui seu foco em projetos mais simples, nos quais a
burocracia e o excesso de documentos se caracterizam como perda de tempo.

O objetivo futuro dos representantes das metodologias ágeis é eliminar os pontos fracos,
como por exemplo a falta de análise de riscos, sem que isso as tornem metodologias pesadas.
Não está no escopo da Extreme Programming a preocupação formal com o planejamento de
 9

riscos. Visto que riscos acontecem com freqüência em projetos de desenvolvimento de

software, a falta de análise de risco torna-se um fator negativo (SOARES, 2004).

Outro aspecto é que para tornar as metodologias ágeis soluções para grandes empresas e
equipes, visto que nestas empresas cada vez mais os indivíduos que participam de equipes se
encontram dispersos geograficamente, será importante resolver os problemas de comunicação.

6. CASOS DE SUCESSO

Os tópicos abaixo apresentam dois casos de sucesso. O primeiro deles do sistema de

desenvolvimento para negócio da empresa Ford Moto Credit, usando o RUP. O segundo do
sistema de apoio a RH, na Assembléia Legislativa do Estado de São Paulo, desenvolvido
pelos membros da AgilCoop - formada por professores e alunos da USP - usando a XP.

A empresa Ford Motor Credit padroniza metodologia de desenvolvimento usando IBM

Rational Unified Process

Ford Motor Credit é uma das maiores empresas de financiamento de automóveis do mundo,
com operações em 36 países. Promove financiamento para produtos de montadoras como
Ford, Aston Martin, Jaguar, Land Rover, Mazda, dentre outras.

O departamento de TI da Ford Motor Credit estava procurando por um software de processo

de desenvolvimento consistente. Cada equipe do projeto usou sua metodologia própria,
dificultando o compartilhamento de conhecimento e rodízio entre as equipes. Além disso, os
processos estabelecidos ofereciam suporte pobre ao desenvolvimento em Java 2 Enterprise
Edition - J2EE, o que resultou em riscos de projeto (IBM, 2007).

Como solução a companhia adotou o Rational Unified Process, personalizando para as

necessidades específicas. O departamento de TI também implantou um programa para prover
treinamento e servir como guia para equipes de projeto.

Desta forma, a Ford Motor Credit padronizou suas iniciativas de TI para desenvolvimento de
software na metodologia IBM Rational Unified Process. Tomando como base um viés similar
ao de outras empresas, o RUP foi customizado de acordo com as necessidades específicas. A
equipe utilizou a metodologia RUP com gerentes de projetos, times de serviço e experts para
customizá-la e adequá-la às suas necessidades. Com base em Java 2 Enterprise Edition, o
departamento de TI implantou a Metodologia de Entrega de Soluções Unificada - Unified
Solution Delivery Methodology (USDM), para seus projetos de software. Para viabilizar a
adoção da USDM, a qual é baseada na abordagem iterativa característica do RUP, a empresa
criou um detalhado programa de treinamento. Durante o processo, os instrutores ensinavam
ao time de desenvolvimento os primeiros passos para usar a nova metodologia. Depois que os
membros das equipes adquirem experiência com um ou dois projetos com a ajuda dos
instrutores, eles já se tornam preparados para desenvolver sem acompanhamento (IBM,
2007).

Para lidar com os riscos de projeto foi criada uma ferramenta para mapeamento de caso de
uso para riscos. Dirigindo-se a riscos precocemente no ciclo de vida do desenvolvimento, e
dando prioridade aos casos do uso baseados no retorno no investimento, as equipes do
desenvolvimento da Ford Motor Credit estabeleceram uma arquitetura estável, dando mais
 10

prioridade à entrega das funcionalidades críticas. Com isso, o departamento de TI da Ford

Motor Credit passou a identificar e endereçar os riscos de projeto com mais rapidez no
processo de desenvolvimento e as equipes passaram a entregar as soluções a tempo e atingir
os padrões de qualidade.

Assembléia Legislativa do Estado de São Paulo: Assessoria e capacitação em

desenvolvimento de software

Durante o ano de 2005, uma equipe de professores e alunos da AgilCoop, uma empresa de
desenvolvimento formada por alunos e professores da USP, que utilizam metodologias ágeis,
prestaram uma assessoria à Assembléia Legislativa do Estado de São Paulo - ALESP. Iniciou-
se o desenvolvimento de um projeto para a área de Recursos Humanos. Por se tratar de um
projeto de grande complexidade, com diversas especificações, foi preciso fazer antes uma
minuciosa análise de requisitos.

Ao invés de entender e documentar a lógica do negócio, o grupo optou por desenvolver este
entendimento ao mesmo tempo em que capacitava a equipe, através de um treinamento
intensivo. Depois de três meses de treinamento já se começava a notar os primeiros
resultados, explicitados nas linhas de código iniciais. Após oito meses de assessoria, com o
uso dos princípios da XP, o projeto foi entregue com resultados satisfatórios (AGILCOOP,
2007).

No período de 2006, foi expandida a parceria com a ALESP: são mais membros da AgilCoop
e alunos da USP implementando métodos ágeis na criação e manutenção do sistema de
Recursos Humanos, do portal e do sistema de apoio ao legislativo.

Este projeto conta com a participação de programadores experientes, dentre os quais Alfredo
Goldman e Fabio Kon, professores doutores do departamento de ciência da computação da
Universidade de São Paulo (AGILCOOP, 2007). Isso mostra que o desenvolvimento usando a
XP demanda profissionais com considerável conhecimento em programação.

7. CONSIDERAÇÕES FINAIS

O objetivo deste artigo não é apontar um método nem mostrar que um anula o outro, visto que
suas características devem ser adotadas em situações de desenvolvimento diversas. É
importante para o desenvolvedor conhecer o que há de melhor nos dois mundos e suas
limitações a fim de que a adoção de um método possa atender suas expectativas de
gerenciamento, custo e prazo.

Para que surja interesse nas grandes organizações pela abordagem dos métodos ágeis muitas
respostas ainda devem ser obtidas, como por exemplo: como gerenciar o risco, como
viabilizar a comunicação em locais dispersos, como garantir a certificação, dentre outras.
Todo novo paradigma exige um tempo de maturação, em que os pioneiros acreditam na idéia
e quebram barreiras no intuito de adquirir a confiança do mercado.
 11

8. REFERÊNCIAS

AGILCOOP. Assembléia Legislativa do Estado de São Paulo: Assessoria e capacitação em

desenvolvimento de software.
Disponível em: <http://agilcoop.incubadora.fapesp.br/portal/sucessos/alesp/>
Acesso em: 18/03/07.

BECK, K. et al. Manifesto for Agile Software Development, 2001.

Disponível em: <http://www.agilemanifesto.org/>
Acesso em: 15/03/07.

BREWER, J. Extreme Programming FAQ.

Disponível em: <http://www.jera.com/techinfo/xpfaq.html>
Acesso em: 24/03/07.

BROOKS, F. No Silver Bullet: Essence and Accidents of Software Engineering. Proc.

IFIP, IEEE CS Press, pp. 1069-1076; reprinted in IEEE Computer, pp. 10-19, Apr, 1987.

CAMPELO, R.E.C. XP-CMM2: Um Guia para Utilização de Extreme Programming em um

Ambiente Nível 2 do CMM. Dissertação de Mestrado, 2003.

HIGHSMITH et al. Extreme Programming. E-Business Application Delivery, Feb., p. 4-17,

2000.

IBM. Rational Unified Process.

Disponível em: <http://www-306.ibm.com/software/awdtools/rup/>
Acesso em: 16/03/07.

KOHRELL, D.; WONCH, B. Using RUP to manage small projects and teams. Rational
Software White Paper, 2005.

KRUCHTEN, Philippe. The Rational Unified Process An Introdution. Massachusetts,

Addison Wesley, 2000.

LARMAN, C. Applying UML and Patterns: An Introduction to Object-Oriented Analysis

and Design and Iterative Development. 3. ed. Prentice Hall, 2004.

MAGALHÃES, A. P. F. RUXP: Integrando o RUP e o XP em uma metodologia para o

desenvolvimento de software. Monografia de Especialização, 2003.

MOLPECERES, A. Procesos de Desarollo: RUP, XP y FDD.

Disponível em: <www.javahispano.org/licencias/>
Acesso: 18/03/07.

PIRES, C. G. et al. Uma Arquitetura de Processos para SW-CMM Nível 3 Baseada no RUP.
Disponível em: <http://www.sbc.org.br/bibliotecadigital/download.php?paper=232>
Acesso em: 23/03/07.

PRESSMAN, R. Engenharia de Software. McGraw-Hill, 2001.

 12

PROBASCO, L. The Ten Essentials of RUP: The Essence of an Effective Development

Process. Rational Software White Paper, 2000.

RAWSTHORNE, D. Comparing/Combining RUP, XP and Scrum

Disponível em: <www.netobjectives.com>
Acesso em: 18/03/07.

ROYCE, W.W. Managing the development of large software systems: concepts and
techniques. Proc. IEEE Westcon, Los Angeles, CA.

SMITH, J. A Comparison of the IBM Rational Unified Process and Extreme Programming.
Rational Software White Paper, 2003.

SOARES, M. S. Metodologias Ágeis Extreme Programming e Scrum para o Desenvolvimento

de Software. Revista Eletrônica de Sistemas de Informação, 2004.

SOMMERVILLE, I. Engenharia de Software. Editora Addison-Wesley, 2003.

XP. Extreme Programming.

Disponível em: <http://www.extremeprogramming.org/>
Acesso em: 24/03/07.