Rational Unified Process - RUP http://www.baguete.com.br/print/artigos/731/adilson-taub-junior/04/11...

Publicado em Baguete - Tecnologia e Informação (http://www.baguete.com.br)

Início > Artigos > Rational Unified Process - RUP > Rational Unified Process - RUP

Rational Unified Process - RUP

Por Adilson Taub Júnior
Criado em 03/11/2009 - 23:00

Criado na década de 90 (a partir do Objectory [ver Jacobson, 1990] e utilizando os conceitos

do Modelo em Espiral [ver Boehm, 1988]) como alternativa para resolução dos problemas
encontrados no então atual modelo de desenvolvimento de software (o modelo “cascata”), o
Rational Unified Process (RUP) é um produto/processo iterativo, incremental e customizável
de Engenharia de Software que foi inicialmente desenvolvido e comercializado pela Rational,
e desde 2003 pertencente à IBM.
“Processo” por definição e “produto” pela maneira como é comercializado (passível de
suporte, atualizações, etc.), o RUP prove de uma maneira disciplinada, a atribuição de
tarefas e responsabilidades dentro de um time de desenvolvimento. Seu maior objetivo é
garantir a produção de softwares de alta qualidade e que satisfaçam as expectativas e
necessidades dos usuários finais dentro de um prazo e orçamento aceitáveis por parte dos
patrocinadores.

A arquitetura básica do RUP se divide em duas dimensões (figura 01):

Horizontal: Representam o tempo de vida de um projeto, os aspectos do ciclo de vida do
processo de engenharia de um sistema, de acordo com o decorrer do projeto. Essa
dimensão demonstra o aspecto dinâmico do processo, suas fases, iterações e
milestones;Vertical: Representam os grupos de atividades lógicas que são realizadas
durante o decorrer do tempo. Essa dimensão demonstra o aspecto estático do processo,
que será composto por disciplinas, atividades, fluxos, artefatos e papéis.
O RUP incorpora as melhores práticas de desenvolvimento de software (http://spmn.com [1])
de acordo com as causas de sucesso apontadas pela indústria de software:
1) Desenvolvimento iterativo;2) Gerenciamento de requisitos;3) Arquitetura baseada em
componentes;4) Modelo visual de software;5) Verificação contínua da qualidade de
software;6) Controle de mudança de software;
Desenvolvimento Interativo e Incremental
O RUP trata o desenvolvimento de software de uma maneira iterativa e incremental, ou seja,
substitui o modelo clássico de desenvolvimento em cascata (Waterfall) para uma abordagem
um pouco mais dinâmica, dividida em iterações, onde, dentro de cada iteração, teremos a
execução de cada uma de suas Disciplinas (figura 02), em proporção de acordo com a Fase
do projeto

Arquitetura e Casos de Uso

Em sua essência, dizemos que o RUP é “centrado na arquitetura” e “dirigido por casos de
uso”.
Isso significa que, para o RUP, os aspectos mais importantes do desenvolvimento de
softwares (ou seja, os aspectos relacionados aos maiores riscos de um projeto de
desenvolvimento) estão intimamente ligados à arquitetura, visto que ele mesmo define
arquitetura como “tudo o que sobra quando você não pode mais tirar nada mais do sistema,
mas ainda continua entendendo-o e explicando como ele funciona”. Sendo assim, devemos

1 de 4 19/04/2011 11:09
Rational Unified Process - RUP http://www.baguete.com.br/print/artigos/731/adilson-taub-junior/04/11...

então tratar como centro (core) do nosso desenvolvimento, nossos requisitos arquiteturais do
projeto.
Além disso, quando dizemos que o RUP é dirigido por casos de uso, mostramos que para
solucionarmos um problema (o grande e único motivo para a criação de um sistema),
devemos primeiro entender da melhor forma possível esse problema, dividi-lo e organizá-lo
de uma maneira que todos os envolvidos no projeto de construção desse sistema (todos os
stakeholders) possam compreender a situação. Para realizar essas atividades, o RUP
encontra na UML a solução: Use Cases e seus atores.
Fases
Como dito anteriormente, o RUP é dividido em fases. Cada uma de suas quatro fases
compreende um momento distinto dentro do ciclo de vida de um projeto de engenharia de
software e, portanto, dão maior ou menor foco em algumas disciplinas, de acordo com a
necessidade do projeto no decorrer de sua execução. São elas:
Início (Inception): Deve-se aqui conseguir dos stakeholders do projeto um consenso
relacionado aos objetivos do ciclo de vida do projeto. Essa fase é focada em endereçar
riscos de requisitos e negócio antes de continuar com o projeto. Primariamente, para
projetos de novos sistemas, essa fase certamente será mais demorada, porém, para projetos
relacionados a sistemas já existentes, a fase de início é mais breve, porém continuará com
foco em garantir que o projeto é possível e viável.
Os objetivos primários da fase de início incluem:• Estabelecer a visão do projeto: escopo,
limites, condições, critérios de aceitação, etc.;• Elencar os casos de uso críticos do sistema
e conhecer os principais cenários das funcionalidades “core” do sistema;• Exibir e
demonstrar ao menos uma arquitetura candidata para atender a esses casos de uso
críticos;• Estimar o custo e prazo total do projeto como um todo e estimar de maneira
detalhada a fase seguinte (Elaboração);• Estimar os potenciais riscos do projeto;•
Preparar o ambiente de suporte para o projeto;
As disciplinas mais aplicadas nessa fase são: Modelagem de Negócio, Requisitos,
Gerenciamento de Projeto e Ambiente.Elaboração (Elaboration): Aqui se fecha a baseline
da arquitetura do sistema, estabelecendo uma base sólida para o design e implementação
do sistema. A arquitetura deverá considerar os requisitos mais significantes (aqueles que
impactam muito a arquitetura do sistema) e uma avaliação de riscos. Essa arquitetura deverá
ser avaliada através de um ou mais protótipos arquiteturais.
Objetivos primários da fase de elaboração incluem:
• Garantir que a arquitetura, seus requisitos e planejamento do projeto estão estáveis o
suficiente para que seja possível prever custo e prazo da completude do
desenvolvimento;• Endereçar todos os riscos arquiteturais significantes do projeto;•
Estabelecer a baseline arquitetural do projeto;• Demonstrar que a arquitetura selecionada
suportará os requisitos do sistema através de custo e prazo razoáveis;• Estabelecer o
ambiente de suporte para o projeto;
As disciplinas mais aplicadas nessa fase são: Requisitos (já em declínio), Análise e Design,
Implementação, Testes, Gerenciamento de Projeto e Ambiente.Construção (Construction):
Na fase de construção, fecham-se os requisitos restantes e se completa o desenvolvimento
do sistema, baseado na arquitetura definida. A ênfase aqui é passarmos do desenvolvimento
de propriedade intelectual criado nas fases anteriores para o desenvolvimento de um
produto passível de entrega.
Objetivos primários da fase de construção incluem:• Minimizar custos de desenvolvimento,
evitando retrabalho desnecessário;• Alcançar uma qualidade adequada para o produto;•
Criar-se versões utilizáveis do sistema;• Completar a Análise e Design e os testes da
aplicação;• Desenvolver um produto completo de maneira incremental e iterativa;• Decidir
se o sistema e os usuários estão prontos para o Deploy;• Alcançar certo nível de
paralelismo nos trabalhos dos times de desenvolvimento;
As disciplinas mais aplicadas nessa fase são: Análise e Design (já em declínio),
Implementação, Testes, Deployment, Gerenciamento de Configuração e Mudança,
Gerenciamento de Projeto e Ambiente.

2 de 4 19/04/2011 11:09
Rational Unified Process - RUP http://www.baguete.com.br/print/artigos/731/adilson-taub-junior/04/11...

Transição (Transition): O foco da fase de transição é garantir que o produto desenvolvido

esteja disponível para seus usuários finais. Essa fase pode estar dividida em várias iterações
e inclui testar o produto na preparação para seu lançamento, pequenos ajustes de mercado
baseados no feedback de usuários, etc. Ao final da fase de transição, os objetivos do ciclo
de vida do projeto deverão ter sido alcançados e o projeto está prestes a ser finalizado.
Objetivos primários da fase de transição incluem:• Teste beta para validar o novo sistema
de acordo com as expectativas dos usuários;• Operação paralela com os sistemas legados
que serão substituídos;• Conversão de base de dados;• Treinamento de usuários;•
Roll-out para forças de mercado, distribuição e vendas;• Empacotamento e Deploy do
sistema;• Validação da baseline de Deploy em relação à visão completa do projeto e seus
critérios de aceitação do produto;• Alcançar o auto-suporte dos usuários;• Conseguir a
validação final do usuário em relação ao produto;
As disciplinas mais aplicadas nessa fase são: Deployment, Gerenciamento de Configuração
e Mudança e Gerenciamento de Projeto e Ambiente.
Disciplinas
Durante cada fase do RUP, faz-se uso de suas nove disciplinas. Cada uma dessas
disciplinas possui atividades que serão executadas por um papel distinto no processo e
poderão ou não gerar artefatos. Seus focos e objetivos podem ser resumidos
em:Modelagem de Negócio (Business Modeling): Garantir que os objetivos e expectativas
de todos os stakeholders do projeto estejam alinhados com os objetivos da organização
derivar desses objetivos, os requisitos de sistema que deverão ser atendidos para solucionar
problemas e/ou necessidades;
Requisitos (Requirements): Definir os limites do sistema e, de acordo com os requisitos
desse novo sistema, criar os casos de uso que serão a base sólida para se estimar os custos
e esforços de desenvolvimento desse sistema. Aqui, todos os stakeholders do projeto devem
compreender e aceitar tudo que o sistema deverá fazer; Análise e Design (Analysis &
Design): Transformar os requisitos em desenhos do sistema que será construído. Devem-se
produzir as especificações técnicas que deverão ser seguidas na implementação de cada
caso de uso do sistema;
Implementação (Implementation): Transformar os modelos lógicos e físicos criados na
Análise e Design em código-fonte utilizável e testar unitariamente o código produzido;
Testes (Test): Encontrar, documentar e endereçar os defeitos encontrados na qualidade do
software produzido. Esses defeitos surgem da comparação entre o que foi produzido com o
que foi exposto nos requisitos e modelos lógicos e físicos do produto; Deployment
(Deployment): Garantir que o software produzido fique disponível para seus usuários
finais; Gerenciamento de Configuração e Mudança (Configuration & Change
Management): Controlar as mudanças e manter a integridade de cada um dos artefatos
produzidos no projeto. Cada um desses artefatos (ou itens de configuração) deve ser
identificado, auditado e possuir níveis de configuração e manutenção definidos;
Gerenciamento de Projeto (Project Management): Balancear objetivos que competem
entre si, gerenciar riscos, monitorar o projeto e tratar regras que garantirão a entrega de um
produto que irá atender às expectativas de Clientes (os patrocinadores do projeto) e
usuários finais; Ambiente (Environment): Configurar o ambiente para que o processo e
suas atividades possam ser executados. Devem-se prover aqui os processos e ferramentas
necessárias para que todas as atividades do projeto possam ser devidamente executadas
por cada papel.
RUP hoje - Conclusão
Em uma era onde metodologias Agile estão emergindo como respostas para problemas
persistentes na produção de softwares de qualidade, falar em RUP pode parecer, em uma
rápida e errônea análise, um passo para trás. Porém, se entendermos os conceitos por trás
de cada modelo, processo ou framework, passamos a compreender que nenhum desses
arcabouços deve prometer (e sequer faz essa promessa) a resolução de todos os problemas
encontrados no dia-a-dia da Tecnologia de Informação.

3 de 4 19/04/2011 11:09
Rational Unified Process - RUP http://www.baguete.com.br/print/artigos/731/adilson-taub-junior/04/11...

O desenvolvimento iterativo e incremental apareceu no mercado na década de 90 e,

infelizmente, vem sendo muito mal utilizado, principalmente quando analisamos empresas
que dizem utilizar o RUP, por exemplo.
Vale ressaltar que os conceitos básicos desse processo/produto são: Iteratividade,
Desenvolvimento Incremental e Customização.
Por ser um produto que traz uma série de modelos de artefatos (templates e guidelines) e
uma quase infinidade de fluxos, atividades, etc., usuários do RUP geralmente esquecem o
conceito “Customização” do tripé citado acima e passam a acreditar que, para se ter bons
resultados com o processo, é necessária a adoção de todo o “pacote”. Bem, se pensarmos
assim, e cotarmos a terceira perna dessa mesa, a mesa certamente irá cair ao primeiro sinal
de movimento rumo a um projeto.
Além disso, o conceito de iterações, muito pregado também por frameworks como o SCRUM,
por exemplo, nem sempre são levados a sério quando tratamos da implantação do RUP.
Isso se dá, muitas vezes, por essa informação vital ser ofuscada por tantas outras que o
processo traz, diferente do framework SCRUM, onde as Sprints ficam sempre muito claras
em todas as palestras, workshops, etc. Sendo assim, tiramos do RUP outro de seu alicerce
e, comprometemos nossos objetivos, investindo muito, para obter muito pouco.
O RUP é um processo fabuloso e que, certamente traz ótimos resultados e controle sobre as
atividades de produção de um software com qualidade, desde que seja bem implementado
e, como qualquer outra ferramenta, seja devidamente entendida e que dela se utilize apenas
o que é útil para um determinado cenário.
A aplicação do RUP em parceria com metodologias ágeis, processos em cascatas e em
ambientes com muita documentação ou pouca (ou quase nenhuma!) é possível e todos
ficariam gratamente surpresos ao constatar resultados provenientes de projetos de
processos como esses.
Ainda vale a máxima que devemos sempre utilizar quando tratamos de processo: Um bom
processo é um processo que atende às nossas necessidades. E, sendo assim, o RUP
obviamente traz grandes ferramentas e conceitos que podem ser aproveitados para atender
a essas necessidades, basta saber do que se fala, e como se utiliza.
* Adilson Taub Júnior é Process manager da TecPro.IT.

Baguete Jornalismo Digital Todos os direitos reservados © Copyright 2010 - Notas legais

URL de origem: http://www.baguete.com.br/artigos/731/adilson-taub-junior/04/11/2009/rational-unified-

process-rup

Links:
[1] http://spmn.com

4 de 4 19/04/2011 11:09