Estudo comparativo entre RUP e XP

DANILO HELENO DO NASCIMENTO (dnlhnas@gmail.com)

MARCIA SUMIE SANGARA (sumies.sangara@gmail.com)

PAULA ANTONIA DOS SANTOS MENDES (paula.mendes@fatec.sp.gov.br)

Faculdade de Tecnologia da Zona Leste – FATEC ZL
Avenida Águia de Haia, 2983 - CEP 03685-000 – São Paulo – SP

Resumo
Atualmente, existem vários estudos relacionados à área de
metodologias desenvolvedoras de software, principalmente
quando se fala de RUP e XP. Esses dois métodos são
recentes, o primeiro é um refinamento de metodologias
orientadas a objetos, contendo suas técnicas e práticas, já o
XP é considerado uma metodologia ágil, visando o código
como atividade principal. Para a melhor escolha de uma
dessas metodologias, foi elaborado um estudo com as
melhores práticas de cada uma, para que futuros artefatos
de software possam ser desenvolvidos utilizando o melhor
método, em menos tempo e com o menor custo. No caso do
eXtreme Programming, utilizaremos as práticas, já na
metodologia RUP são utilizadas suas fases e atividades. O
artigo irá apresentar as principais características dessas duas
metodologias, fazendo uma relação entre seus pontos mais
relevantes e os resultados que esses métodos conseguem
alcançar quando bem empregadas no processo de produção
de software. Comparando essas duas metodologias, o artigo
mostra os tipos de projeto para que cada uma delas é
indicada. Isso pode ajudar o grupo desenvolvedor a
entender melhor cada tipo de projeto, e avaliar qual é a
melhor metodologia a ser utilizada. Este artigo visa
esclarecer qual é a metodologia mais indicada para que
projetos sejam feitos de acordo com suas funcionalidades e
especificações.
Abstract
Currently, there are several studies related to the area of
software development methodologies, especially when
speaking of RUP and XP. These two methods are recent,
the first is a refinement of object-oriented methodologies,
containing his techniques and practices, since XP is
considered an agile methodology, targeting the main
activity code. To the best choice of one of these methods, a
study was undertaken with the best of each one, so that
future software artifacts can be developed using the best
method, in less time and with less cost. In the case of
eXtreme Programming, we will use the practices already
used in the RUP methodology are its phases and activities.
The article will present the main characteristics of these
two approaches, making a connection between its most
relevant and the results that these methods can achieve
when properly used in the process of software production.
Comparing these two methodologies, the article shows the
project types for which each is indicated. This can help the
developer understand group each type of project, and
evaluate what is the best methodology to be used. This
article aims to clarify what is the most appropriate
methodology for projects that are made according to its
features and specifications.
Keywords: RUP, XP, methodologies, best practices.

1 Objetivo
Palavras-chave: RUP, XP, metodologias, melhores
práticas. Abordar as principais características das
metodologias de desenvolvimento de software

1
RUP (Rational Unified Process) e XP (eXtreme
Programming). Fazendo uma comparação dessas
características, definindo para a melhor
metodologia para cada tipo de projeto. Este
artigo foi elaborado com pesquisas em outros
artigos, teses e livros que abordam comparações
entre essas duas metodologias. No capitulo 2, foi
apresentado conceitos sobre os processos de
desenvolvimento de software. Na seção 3 e 4,
são descritas as características das metodologias
rigorosas e ágeis, respectivamente, incluindo
seus processos de desenvolvimento. No capitulo
5, é apresentado a comparação dessas duas
metodologias. Por fim, na seção 6, estão as
considerações finais.
2 Processos de desenvolvimento
de software
Segundo Nonemacher 2003, os processos de
desenvolvimento de software foram criados para
representar as atividades envolvidas na produção
de software em alto nível. Existem várias
metodologias de desenvolvimento de software,
cada uma delas apresenta atividades e níveis de
detalhes diferentes. Um mesmo artefato pode ser
produzido de diversas formas, mas alguns
processos são mais indicados para aplicações
especificas. Caso seja aplicado um método
ineficiente, isso pode comprometer
funcionalidade e qualidade do artefato de
software.
3 Metodologias Rigorosas
Segundo Oliveira (et al.), quando o padrão de
desenvolvimento de software passou a ser
baseado em orientação a objeto, por volta de
1990, surgiram vários métodos trazendo esse tipo
de desenvolvimento. Os modelos de processos
de software voltados a orientação a objeto
apresentam como característica criar e manter
modelos, e por ter uma documentação detalhada
em todas as fases do seu desenvolvimento.
Segundo Moreira 2007, essas metodologias são
denominadas rigorosas porque apresentam muito
rigor em suas premissas e propostas, além da
grande quantidade de papeis, documentos,
atividades e pessoas em sua implementação, por
isso, também são conhecidas como metodologias
pesadas. Nessas metodologias, o emprego de
tantas pessoas mostra que boa parte do tempo
elas estão ocupadas com atividades que não estão
diretamente ligadas ao desenvolvimento do
projeto.
3.1 Rational Unified Process - RUP
Segundo Nonemacher 2003, o Rational Unified
Process (RUP) é a concretização da utilização do
Unified Process feita pela Rational. A Rational é
uma organização que resultou da junção de três
dos grandes protagonistas dos métodos de
análise, concepção e desenvolvimento orientado
aos objetos. Foi efetuado um esforço das várias
notações e fases dos processos defendidos por
a
Grady Booch, James Rumbaugh e Ivar Jacobson,
tendo convergido numa abordagem comum, que
dá origem a uma ferramenta comercial que usa
como linguagem de modelação a UML. Segundo
Moreira 2007, o RUP teve sua primeira versão
2
em 1998, chamada RUP 5.0, sendo gerado da
evolução de projetos anteriores.
3.1.1 Elementos do RUP
Segundo Vasco 2007 (et al.), a organização do
modelo do RUP é baseada nos elementos
essenciais, definidos como estruturais e de
comportamento. Esses elementos podem criar
um conjunto de pacotes componentes de
processo, eles definem o modelo de processo. No
RUP, as atividades são realizadas por papeis, ou
melhor, pessoas e grupos assumem determinados
papeis no projeto. Os artefatos são produtos de
trabalho do processo.
Um tipo de elementos existente no RUP, que
complementa os elementos principais com
orientações adicionais sobre o processo é
definido como atividades de suporte. Não
apresentam terminologia em UML, portanto não
são elementos de processo. O RUP apresenta
algumas perspectivas típicas:
 Ciclo de vida: planejamento de atividades
e medição de progresso.
 Disciplinas: apresentam diagramas dos
fluxos de trabalho, representado as atividades
que realiza.
 Papeis: descrevem os elementos do
processo para cada individuo. Cada papel tem
atividades que devem ser realizadas ou artefatos
que devem ser modificados.
 Ferramentas: o RUP utiliza softwares da
IBM como ferramentas. Exemplos: Rational
3
Rose, Rational RequisitePro, Rational ClearCase,
Rational ClearQuest, Rational Suite TestStudio.
Segundo Moreira 2007, o RUP é uma
metodologia de desenvolvimento de software
que utiliza técnicas comerciais para que o
produto seja gerado com mais qualidade. Tem
como principal objetivo garantir que o produto
desenvolvido tenha um alto grau de qualidade,
respeitando os requisitos do cliente, com prazos e
custos determinados.
3.1.2 Dimensões dos processos
Segundo Nonemacher 2003, os processos no
RUP podem ser divididos em duas dimensões: a
primeira dimensão apresenta os aspectos
dinâmicos e sua ordenação, ciclos, fases,
iterações, entre outros itens. Já a segunda
dimensão mostra aspectos estáticos, descrevendo
atividades, artefatos, participantes e os fluxos do
trabalho.
3.1.2.1 Componentes Dinâmicos
O ciclo de vida de um software é dividido em
etapas, cada uma tentando atingir seu objetivo
para que ao final de todo processo, o produto de
software esteja finalizado. Segundo Nonemacher
2003, quatro tipos de atividades podem ser
identificadas em cada ciclo de desenvolvimento
do projeto no RUP: As fases são:
 Inicio: elaborado uma visão do produto
final a partir de caso de uso;
 Elaboração: idealização das atividades e
recursos que serão utilizados, definição das
funcionalidades e da arquitetura a ser
implementado;
 Construção: Implementação do código.
Em grandes projetos essa fase é dividida em
várias iterações, para que sejam resolvidos em
partes menores, mais fáceis de gerenciar;
 Transição: o artefato é entregue ao
cliente. Pode haver treinamento para futuros
usuários e avaliação do produto.
Com a divisão do RUP em fases, isso acaba
permitindo que cada etapa será desenvolvida
através da repetição de todo o ciclo, para que
todos os detalhes do projeto sejam somados para
gerar o produto final.
Segundo Moreira 2007, o RUP também pode ser
utilizado em projetos de pequeno e médio porte,
tanto no desenvolvimento quanto manutenção.
Para que isso possa ser possível, algumas das
fases seriam eliminadas, diminuindo
documentação, deixando o RUP mais informal.
3.1.2.2 Componentes Estáticos
O RUP utiliza quatro elementos
modelagem: trabalhos, atividades, artefatos e
fluxos de trabalho ou disciplinas. A visão de
componentes estáticos se baseia no conceito de
fluxo de trabalho, tanto de processamento quanto
de suporte. Segundo Nonemacher 2003, são
apresentados como Fluxo de trabalho de
processamento:
 Modelagem do negocio (Business
Modeling): criação de um modelo com tecnicas
baseado nas informações da organização.
 Requisitos (Requirements): descreve o
que o sistema deve fazer, sendo elo de ligação e
concordância entre o programador e o cliente.
 Análise e Design (Analysis and Design):
mostra como a implementação será realizada,
tem como resultado o desenho e a análise de
modelo.
 Implementação (Implementation): define
a organização do código;
 Testes (Test): verificam a integridade
entre os objetos, e entre todos os componentes do
software, garante que todos os requisitos tenham
sido implementados, e que os defeitos foram
identificados antes da instalação do software.
 Implantação (Deployment): disponibiliza
o sistema para seus usuários finais, tem como
atividades o lançamento externo, distribuição,
instalação e suporte aos usuários.
a Os fluxos de trabalho de suporte possuem
atividades que acontecem ao decorrer do projeto,
e contribuem com o sucesso do produto final. As
atividades são:
para  Gestão do projeto (Project Management):
aplicação de conhecimentos, habilidades e
técnicas na elaboração de atividades para atingir
um conjunto de objetivos pré-definidos, num
certo prazo, com certo custo e qualidade.
 Gerenciamento de configuração e
mudança (Configuration and change
management): fornece apoio para desenvolver
software. Suas principais atribuições são o
controle de versão, o controle de mudança e a
auditoria das configurações.
4
  Ambiente (Enviroment): é o termo usado desenvolver e implantar o sistema, como, por
para todos os itens de que o projeto precisa para exemplo, ferramentas, processo e templates.

Figura 1 – Fluxo de trabalho de processamento e de suporte e fases do RUP

3.1.3 Papeis  Gerentes: Engenheiro de Processo,

Segundo Vasco 2007 (et al.), um papel é a Gerente de Projeto, Gerente de Controle de

realização de um trabalho, uma atividade do Mudança, Gerente de Configuração, Gerente de

RUP. Os papeis definem o comportamento e as Implantação, Revisor do Projeto, Gerente de

responsabilidades do individuo. O RUP possui Testes;

papeis que são distribuídos em suas atividades.  Outros papeis: Envolvidos,

 Analistas: Analista de Sistemas, Desenvolvedor do Curso, Artista Gráfico,

Designer de Negócios, Revisor do Modelo de Especialista em Ferramentas, Administrador de

Negócios, Analista do Processo de Negócios, Sistema, Redator Técnico.

Revisor de Requisitos, Especificador de 3.1.4 Práticas do RUP

Requisitos, Analista de Teste, Designer de Segundo Nonemacher 2003, essa metodologia
Interface de Usuário; possui as melhores práticas em
 Desenvolvedores: Designer de Cápsula, desenvolvimento de software. As práticas do
Revisor de Código, Designer de Banco de RUP são:
Dados, Implementador, Integrador, Arquiteto
 Develop Software Iteravely
de Software, Revisor de Arquitetura, Revisor
(Desenvolver iterativamente): Cada iteração
de Design, Designer, Designer de Teste;
apresenta um objetivo a ser alcançado. As

 Testadores: Testador; iterações provêem várias vantagens, como

5
identificar requisitos com mais facilidade; - Qualidade de processo: qualidade dentro
descobrindo os riscos de melhor forma. do projeto de desenvolvimento.

 Manage Requirements (Gerenciamento  Control Changes To Software (Controle

de requisitos): descreve formas de produzir, de mudanças): Controlar as mudanças durante
comunicar e organizar os requisitos de um todo o projeto é prática fundamental para
projeto. Os casos de uso e cenários capturam manter a qualidade do projeto.
requisitos. O RUP é uma metodologia dirigida
a casos-de-uso (use-driven-case), de modo que
3.1.5 Linguagem de Modelagem
é possível utilizar os mesmos casos de uso
Unificada (UML)
definidos no sistema como base para o resto do
Utilizada na modelagem de sistemas em forma
processo.
de diagrama. A UML utiliza conceitos de
 Component-Based architectures
orientação a objetos. Surgiu como uma
(Arquiteturas Baseadas em Componentes):
tentativa de padronizar os artefatos de software,
desenvolve em módulos, através do uso de
de análise e design, unindo as notações
componentes, de modo a criar um sistema
baseadas em objeto. Segundo Moreira 2007, a
flexível, adaptável, entendível e reutilizável. O
UML oferece um conjunto de modelos de
RUP entende componentes como módulos
desenvolvimento de software para apoiar o
incomuns ou subsistemas com uma função
RUP.
clara e específica. Refere-se a utilização de
componentes reutilizáveis ao invés de
programar todo sistema. 3.1.6 RUP e o CMM

 Visually Model Software (Modelar Segundo Flower 2005, o RUP sendo aplicado

visualmente): A modelagem visual permite como metodologia de software pode ser

entender a concepção e a complexidade do certificado pelo CMM, no quesito de

sistema, e facilitar a identificação e solução de maturidade e garantia de qualidade dos

problemas. produtos gerados, existindo uma coerência

entre o RUP e o CMM.
 Verify Software Quality (Verificação
Continua de Qualidade): A responsabilidade de 4. Metodologias ágeis
manter a qualidade é de todos os integrantes do
Segundo Soares, um encontro que reuniu
projeto. A qualidade é focada especialmente em
representantes de metodologias como Scrum e
duas áreas:
eXtreme Programming, até então chamadas de
- Qualidade de produto: qualidade do
metodologias “peso leve”, o Manifesto for
produto desenvolvido;
Agile Software Development foi colocado em
discussão uma alternativa para o
6
desenvolvimento de Software tradicional. Esse
encontro apresentou alguns valores:
 Pessoas e interações são mais
importantes que ferramentas e processos;
 Funcionamento do software é mais
importante que documentação excessiva;
 Colaboração do cliente é mais
importante que negociação do contrato;
 Reagir a mudanças é mais importante
que seguir um plano.
Um dos objetivos dessa metodologia é eliminar
pontos fracos, como o analise de riscos, sem
que isso as deixem com características de
metodologias pesadas.
4.1 Extreme Programming
Segundo Soares, o XP é uma metodologia para
equipes pequenas e médias, e projetos com
requisitos vagos e voláteis. Os requisitos são
apresentados pelos clientes em documentos
chamados de estórias (stories). Após
compreensão das estórias, a equipe planeja as
tarefas necessárias para a implementação das
estórias. Essas tarefas são realizadas por papeis,
cada papel é responsável por determinados
artefatos. Os artefatos são produtos
processo. Segundo Flower 2005, o XP não
possui pré-requisitos para obter certificação do
CMM.
4.1.4 Ciclo de vida do XP
O XP é uma metodologia passível a mudanças.
Possui iterações curtas, tendo muitas versões do
produto, os comentários e opiniões do cliente
alimentam a próxima iteração. A duração das
iterações permite avaliar o processo do projeto
e realizar seu planejamento de forma simples e
viável. Em cada iteração é definido um plano
de ação com base nos artefatos de revisão e
erros. Segundo Nonemacher 2003, o XP torna o
projeto flexível, diminui os custos das possíveis
mudanças. O código é como um índice de
progresso de projeto. O ciclo de vida do XP é
dividido em seis fases:
 Exploração: cliente escreve cartões com
estórias, contendo funcionalidades para a
primeira versão;
 Planejamento: definição da prioridade
entre as estórias junto com os clientes. Nessa
fase os programadores definem o esforço e
cronograma para cada estória;
 Iterações: divisão em diversas fases ate
a 1º versão ser completada. Na 1º iteração é
criado o sistema com sua arquitetura, nas
a próximas iterações serão adicionados as
funcionalidades estabelecidas desse sistema;
 Validação: testes extensivos e
validações de software são realizados;
 Manutenção: após a 1º versão, existem
do outras funcionalidades a ser adicionadas ao
sistema;
 Morte: não havendo mais estórias a ser
implementadas e cliente estando satisfeito com
o código, o desenvolvimento chega ao final.
7
 Figura 2 - Fases do XP
4.1.2 Valores do XP
Segundo Nonemacher 2003, o XP é uma
disciplina baseada em valores, que servem
como base para as praticas usadas nessa
metodologia. Os valores do XP são:
 Comunicação: quanto mais continua a
comunicação entre os envolvidos no projeto,
mais evidente fica o que deve ser feito;
 Simplicidade: design simples, sem
adicionar itens desnecessariamente, mantendo o
código claro;
 Feedback: meio para orientação e
tomada de decisão. É direcionado ao estado de
desenvolvimento do software.
 Coragem: caso alguma falha ocorra, a
equipe precisa de coragem para não parar
quando estiver cansada, e jogar o código e fora
e recomeçar;
8
4.1.1 Papeis do XP
Segundo Martin (et al.) 2004, o XP identifica
sete papeis:
 Programador: escreve o código e realiza
testes;
 Cliente: escreve as estórias;
 Testador: auxilia o cliente a criar testes
funcionais;
 Tracker: provê o feedback no processo,
compara estimativas com resultados. Analisa o
progresso de cada iteração, avaliando se os
objetivos podem ser alcançados com os
recursos disponíveis;
 Técnico (Coach): o projeto é sua
responsabilidade, guia a equipe;
 Consultor: membro externo, auxilia em
assuntos técnicos e específicos;
  “Big Boss”: responsável pelo projeto,
toma as decisões, mantêm comunicação com a
equipe para diagnosticar problemas ou falhas
no processo.
4.1.3 Praticas do XP
As praticas do XP são uma de suas forças. Elas
se apóiam mutuamente, já que individualmente
mostram falhas. Segundo Nonemacher 2003, as
praticas do XP são divididas em três categorias:
 Programação
- Projeto simples (Simple design): simplicidade
no projeto, removendo complexidades
desnecessárias;
- Testes (Testing): testes de unidade devem ser
executados desde o inicio ao final de cada
funcionalidade adicionada;
- Reconstrução (Refactoring): melhoria do
código sem alterar seu resultado;
- Código padrão (Coding standards): o código
escrito segue um padrão da equipe;
 Equipe
- Propriedade coletiva (Collective ownership):
o código pertence a equipe, sendo assim,
qualquer dupla de programadores pode alterar o
código;
- Integração continua (Continuous integration):
integrar e atualizar versões dos projetos
periodicamente;
5. RUP x XP
Segundo Vasco 2007 (et al.), essas duas
metodologias em alguns aspectos são muito
9
- Metáfora (Metaphor): analogia que facilita o
entendimento da equipe em relação ao projeto;
- Código padrão (Coding standards): o código
escrito segue um padrão da equipe;
- 40 horas por semana (40-hour week): a
semana de trabalho deve possuir 40 horas
semanais;
- Programação em par (Pair programming):
desenvolvimento em pares, melhorando a
qualidade do código e design;
- Versões pequenas (small releases): colocar
em funcionamento um sistema simples,
liberando novas versões em ciclos curtos;
 Processos
- Cliente presente (On-site customer): incluir o
cliente na equipe para que ele responda
perguntas e defina prioridades referentes ao
projeto que devem ser implementadas;
- Testes (Testing): testes de unidade devem ser
executados desde o inicio ao final de cada
funcionalidade adicionada;
- Versões pequenas (small releases): implantar
um sistema simples, liberando novas versões
em ciclos curtos;
- Planejamento do jogo (Planning game):
determina o escopo da próxima versão,
combinando estimativas técnicas com
prioridades do negocio.
parecidas, possuindo um grande número de
iterações, sendo orientada ao cliente e
possuindo um volume grande de papel. Um
estudo mais aprofundado, podemos perceber
diferenças no que se diz respeito a forma e
freqüência que os artefatos de software são
gerados, volume de papeis, entre outros.
5.1 Divisão de tempo
Cada fase do RUP possui um grande numero de
iterações, produzindo ao final delas uma nova
versão de software. No XP o item relacionado
ao tempo é o código produzido. O tempo é
gasto com as iterações do RUP é o mesmo
gasto nas versões do XP.
5.2 Artefatos
Segundo Nonemacher 2003, artefato é uma
informação que pode ser produzida, modificada
ou usada por um processo. No RUP, a
comunicação é feita através de artefato. Já no
XP, a comunicação é baseada em comunicação
oral, direta, podendo aLumentar o risco do
projeto.
5.3 Atividades e papeis
Segundo Vasco 2007 (et al.), cada atividade do
RUP é considerado como um trabalho realizado
por um papel, utilizando artefatos de entrada
para gerar artefatos de saída. Os papeis
utilizados no RUP (descritos no item 3.1.3)
estão agrupados em suas atividades. O XP
apresenta como atividades a produção de
código, testes, listening e design. Com isso,
define sete papeis: Programador, Cliente,
Testador, Tracker, Técnico, Consultor e o “Big
10
Boss”, mas não distingue as funções, sendo que
um programador pode atuar em outro papel.
5.4 Ferramentas
Segundo Vasco 2007 (et al.), o RUP utiliza
softwares da IBM como ferramenta, como o
Rational Rose. O XP não utiliza nenhuma
ferramenta especifica no seu processo, mas
existem ferramentas livres como o XPlanner e
Junit.
5.5 Código
Segundo Vasco 2007 (et al.), o RUP divide o
código em subsistemas, cada subsistema tem
membros responsáveis pela sua execução. No
XP, o código é tratado coletivamente, qualquer
programador que encontrar um erro ou trecho a
ser otimizado, pode alterar o código.
5.6 Certificações
Segundo Moreira 2007, as certificações
existem para garantir o conhecimento nessas
metodologias. Atesta quem está em
conformidade com as requisitos, normas ou
regulamentos. O Rational Unified Process
v2003 Certification test é a certificação base do
RUP. Já no XP, não existe uma unidade
certificadora.
5.7 Diretivas de projeto
Segundo Vasco 2007 (et al.), o RUP se baseia
em casos de uso. No XP, o projeto é baseado
em testes. O projeto é guiado por estórias do
cliente, mostrando aos programadores o que 6 Considerações Finais
deve ser implementado. As estórias utilizadas
As metodologias de desenvolvimento de
no XP mais simples se comparadas com os
software Rational Unified Process e eXtreme
casos de uso usados no RUP. Nenhuma duas
Programming buscam em suas praticas e
das metodologias indicam planejamento de
processos reduzir custos e aumentar a
detalhes. O RUP indica modificações continua
qualidade do software produzido. Tanto o RUP
dos planos, o XP planeja os detalhes só no
como o XP buscam alcançar estes objetivos,
futuro.
mas de formas diferentes, implementando de
Prática ou conceito RUP XP formas diferentes. De forma geral, o XP é mais
Iterativo e incremental Sim Sim indicado para equipes pequenas, e projetos com
requisitos voláteis ou que mudem com
Voltado para a arquitetura Sim Não
freqüência. Sua ênfase está na comunicação,
Voltado para a validação Não Sim
restringindo sua aplicação em projetos distantes
Desenvolvedor/cliente Não Sim geograficamente. As atividades são dividas em
Desenvolvedor/gerente Sim Não papeis, mas não são muito específicos, já que
Desenvolvedor/suporte Sim Sim os envolvidos no projeto podem mudar de
função. O RUP possui uma boa definição de
Gerenciamento de Risco Sim Sim
suas atividades. A estruturação do RUP
Qualidade de código Não Sim
baseada na utilização de softwares permite que
Pré – requisitos CMM Sim Não o RUP seja usado em projetos grandes,
Equipes grandes Sim Não podendo atingir longas distancias com um
Equipes pequenas Não Sim custo adicional na gerencia do projeto, item que
seria injustificável em pequenas equipes.Além
Projetos complexos Sim Não
disso, essas metodologias apresentam em
Casos de uso Sim Sim
comum o envolvimento com o cliente,
Tabela 1: Comparativo entre RUP e XP.
iterações, testes contínuos e flexibilidade.
Com a analise da tabela abaixo (tabela 1),
Contudo, seria mais indicado para projetos
podemos concluir que, enquanto o RUP tem
menores a utilização do XP, e o uso do RUP
foco em projetos complexos, onde se fazem
para projetos maiores, devido sua maior
necessárias especificações maiores do projeto.
complexidade de requisitos, comunicação e
O XP tem seu foco em projetos mais simples,
documentação.
onde a burocracia caracterizam perda de tempo.

11
7 Referências bibliográficas L.F.A. Integração de UP, RUP e XP na
definição de um processo de desenvolvimento
de software. Cornélio Procópio, p.12.
FLOWER, H. UML essencial: um breve guia
para a linguagem-padrão de modelagem de
objetos. 3ª ed. Artmed.Porto Alegre, 2005. OKTABA. H.; PIATTINI. M. Software

160p. Process Improvement for Small and Medium

MARTIN P.V; SILVA A.R. Comparação de
Metamodelos de Processos
Desenvolvimento de Software. Qualidade nas
Tecnologias da Informação e Comunicações ,
pp.179-186, 2004.
MARTINS, J.C. Gerenciando projetos de
desenvolvimento: de software com PMI, RUP e
UML. 4ª ed. Brasport, Rio de Janeiro, 2007.
323p.
Enterprises: Techniques and Case Studies.
Nova York: IGI Global, 2008. 376 p.
ROCHA P.C.; BELCHIOR A.D. Mapeamento
de
do Gerenciamento de Riscos no PMBOK,
CMMI-SW e RUP, Fortaleza. p.12, 2004
SCOTT. K. Processos Unificados Explicado.
São Paulo, Bookman, 2002.142 p.
SOARES. M. S. entre Metodologias Ágeis e
Tradicionais para o Desenvolvimento de
Software. Conselheiro Lafaiete. 6 p.

MOREIRA, A. M. Metodologias de
desenvolvimento: um comparativo entre VASCO C. G.; VITHOFT M. H.; ESTANTE
eXtreme Programming e Rational Unified. São P. R. C. Comparação entre Metodologias RUP
Paulo. 12 p. e XP. Curitiba, p.8.

NONEMACHER, L. M. Comparação e ZUSER W.; HEIL S.; GRECHENIG T.

avaliação entre o processo RUP de Software Quality Development and Assurance
desenvolvimento de software e a metodologia in RUP, MSF and XP - A Comparative Study.
eXtreme Programming. 2003. 164f. Dissertação Missouri, Estamos Unidos, 6 p. 2005.
(Mestrado em Ciência da Computação)-
Universidade Federal de Santa Catarina,
Florianópolis. 2003

OLIVEIRA K. S.; MATTOS H.D.; MARINHO

D.A.; SILVA J.S.; BASTIANI J.A.; BATISTA
12