INTRODUÇÃO

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.
O QUE É

O Rational Unified Process® (também chamado de processo RUP®) é um processo de

engenharia de software. Ele oferece uma abordagem baseada em disciplinas para
atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento.
Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades
dos usuários dentro de um cronograma e de um orçamento previsíveis.

O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e

documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os
processos em ação. Utiliza técnicas e práticas aprovadas comercialmente.

É um processo considerado pesado e preferencialmente aplicável a grandes equipes de

desenvolvimento e a grandes projetos, porém o fato de ser amplamente customizável
torna possível que seja adaptado para projetos de qualquer escala. Para a gerência do
projeto, o RUP provê uma solução disciplinada de como assinalar tarefas e
responsabilidades dentro de uma organização de desenvolvimento de software.

O RUP é, por si só, um produto de software. É modular e automatizado, e toda a sua

metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e
vendidas pela IBM através de seus "Rational Suites".

O RUP tem duas dimensões:

• O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do

processo à medida que se desenvolve
• O eixo vertical representa as disciplinas, que agrupam as atividades de maneira
lógica, por natureza.

A primeira dimensão representa o aspecto dinâmico do processo quando ele é aprovado

e é expressa em termos de fases, iterações e marcos.

A segunda dimensão representa o aspecto estático do processo, como ele é descrito em

termos de componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papéis do
processo.
O gráfico mostra como a ênfase varia através do tempo. Por exemplo, nas iterações
iniciais, dedicamos mais tempo aos requisitos. Já nas iterações posteriores, gastamos
mais tempo com implementação.

As fases e os marcos de um projeto

O ciclo de vida de software do Rational Unified Process (RUP) é dividido em quatro

fases sequenciais, cada uma concluída por um marco principal, ou seja, cada fase é
basicamente um intervalo de tempo entre dois marcos principais. Em cada final de fase
é executada uma avaliação para determinar se os objetivos da fase foram alcançados.
Uma avaliação satisfatória permite que o projeto passe para a próxima fase.
FASES DE PLANEJAMENTO

As fases não são idênticas em termos de programação e esforço. Embora isso varie
muito de acordo com o projeto, um ciclo de desenvolvimento inicial típico para um
projeto de médio tamanho deve prever a seguinte distribuição de esforço e
programação:

Iniciação Elaboração Construção Transição

Esforço ~5 % 20 % 65 % 10%

Programação 10 % 30 % 50 % 10%

Para um ciclo de evolução, as fases de iniciação e de elaboração seriam bem menores.

Ferramentas que automatizam parte do esforço de Construção podem amenizar isso,
tornando a fase de construção muito menor do que as fases de iniciação e de elaboração
juntas.

Uma passagem pelas quatro fases é um ciclo de desenvolvimento; cada passagem pelas
quatro fases produz uma geração do software. A menos que produto "desapareça", ele
irá se desenvolver na próxima geração, repetindo a mesma seqüência de fases de
iniciação, elaboração, construção e transição, mas agora com ênfase diferente nas
diversas fases. Esses ciclos subseqüentes são chamados de ciclos de evolução. À
medida que o produto atravessa vários ciclos, são produzidas novas gerações.
Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários,
mudanças no contexto do usuário, mudanças na tecnologia subjacente, reação à
concorrência e assim por diante. Normalmente, os ciclos de evolução têm fases de
Iniciação e Elaboração bem menores, pois a definição e a arquitetura básicas do produto
foram determinadas por ciclos de desenvolvimento anteriores. São exceções a essa
regra os ciclos de evolução em que ocorre uma redefinição significativa do produto ou
da arquitetura.

FASE ELABORAÇÃO
 As fases e os marcos de um projeto

A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do Rational

Unified Process (RUP) é dividido em quatro fases sequenciais, cada uma concluída por
um marco principal, ou seja, cada fase é basicamente um intervalo de tempo entre dois
marcos principais. Em cada final de fase é executada uma avaliação (Atividade: Revisar
Marcos do Ciclo de Vida) para determinar se os objetivos da fase foram alcançados.
Uma avaliação satisfatória permite que o projeto passe para a próxima fase.

CONSTRUÇÃO
A meta da fase de construção é esclarecer os requisitos restantes e concluir o
desenvolvimento do sistema com base na arquitetura da baseline. A fase de construção é
de certa forma um processo de manufatura, em que a ênfase está no gerenciamento de
recursos e controle de operações para otimizar custos, programações e qualidade. Nesse
sentido, a mentalidade do gerenciamento passa por uma transição do desenvolvimento
da propriedade intelectual durante a iniciação e elaboração, para o desenvolvimento dos
produtos que podem ser implantados durante a construção e transição.

Os objetivos principais da fase de construção incluem:

• Minimizar os custos de desenvolvimento, otimizando recursos e evitando

retalhamento e retrabalho desnecessários.
• Atingir a qualidade adequada com rapidez e eficiência.

• Atingir as versões úteis (alfa, beta e outros releases de teste) com rapidez e
eficiência.
• Concluir a análise, o design, o desenvolvimento e o teste de todas as
funcionalidades necessárias.
• Desenvolver de modo iterativo e incremental um produto completo que esteja
pronto para a transição para a sua comunidade de usuários. Isso implica descrever os
casos de uso restantes e outros requisitos, incrementar o design, concluir a
implementação e testar o software.
• Decidir se o software, os locais e os usuários estão prontos para que o aplicativo
seja implantado.
• Atingir um certo paralelismo entre o trabalho das equipes de desenvolvimento.
Mesmo em projetos menores, normalmente há componentes que podem ser
desenvolvidos um independente do outro, permitindo o paralelismo natural entre as
equipes (se os recursos permitirem). O paralelismo pode acelerar bastante as
atividades de desenvolvimento; mas também aumenta a complexidade do
gerenciamento de recursos e da sincronização dos fluxos de trabalho. Uma
arquitetura sofisticada será essencial para atingir um paralelismo significativo.

Atividades Básicas
 • Gerenciamento de recursos, otimização de controle e processo
• Desenvolvimento completo do componente e teste dos critérios de avaliação
definidos
• Avaliação dos releases do produto de acordo com os critérios de aceitação para a
visão

CAPACIDADE OPERACIONAL INICIAL

O marco Capacidade Operacional Inicial determina se o produto está pronto para ser
implantado em um ambiente de teste beta.

No Marco da Capacidade Operacional Inicial, o produto está pronto para ser passado
para a Equipe de Transição. Toda a funcionalidade já foi desenvolvida e todos os testes
alfa (se houver algum) foram concluídos. Além do software, um manual do usuário foi
desenvolvido, e existe uma descrição do release atual.

Critérios de Avaliação

Os critérios de avaliação para a fase de construção envolvem as respostas para estas

questões:

• Este release do produto é estável e desenvolvido o suficiente para ser implantado

na comunidade de usuários?
• Todos os envolvidos estão prontos para a transição para a comunidade de
usuários?
• As despesas reais com recursos ainda são aceitáveis se comparadas com as
planejadas?

PLANO DE ITERAÇÃO DE EXEMPLO: FASE DE CONSTRUÇÃO

A ilustração mostra o relacionamento dos fluxos de trabalho em uma iteração inicial da
construção. Ela será construída a partir dos Detalhamentos do Fluxo de Trabalho da
forma como aparecerem naquele momento. O intuito é indicar as dependências e
mostrar onde ocorrem fluxos de trabalho em paralelo. Os comprimentos das barras no
gráfico (indicando a duração) não têm significado absoluto. Por exemplo, não se
pretende dizer que Planejar a Integração e Planejar Teste devem ter a mesma duração.
Também não é a intenção sugerir a aplicação de um nível de esforço uniforme no
decorrer dos fluxos de trabalho. Uma indicação do esforço relativo pode ser vista em
Visão Geral do Processo. É possível navegar para as páginas correspondentes do
Detalhamento do Fluxo de Trabalho a partir de cada linha do gráfico; basta clicar no
nome do Detalhamento do Fluxo de Trabalho. Essa ilustração foi criada a partir de um
Plano do Microsoft Project.

Observe que há muito trabalho de design contínuo mostrado nessa iteração, indicando
que ela é uma das primeiras no ciclo de construção. Em interações de construção
posteriores, isso diminuirá à medida que o trabalho de design for concluído, e o trabalho
de design restante se relacionará às Solicitações de Mudança (defeitos e melhorias) que
afetam o design. A descoberta e o refinamento de requisitos são mostrados como
concluídos nesse estágio, o esforço restante se refere inteiramente ao gerenciamento de
mudança.
O principal resultado de uma iteração no final da fase de construção é que mais
funcionalidade é adicionada, o que proporciona um sistema muito mais completo. Os
resultados da iteração atual ficam visíveis para os desenvolvedores formarem a base de
desenvolvimento para as iterações subseqüentes.
FASE TRANSIÇÃO

Objetivos

O foco da Fase de Transição é assegurar que o software esteja disponível para seus
usuários finais. A Fase de Transição pode atravessar várias iterações e inclui testar o
produto em preparação para release e ajustes pequenos com base no feedback do
usuário. Nesse momento do ciclo de vida, o feedback do usuário deve priorizar o ajuste
fino do produto, a configuração, a instalação e os problemas de usabilidade; todos os
problemas estruturais mais graves devem ter sido trabalhado muito antes no ciclo de
vida do projeto.

No fim do ciclo de vida da Fase de Transição, os objetivos devem ter sido atendidos e o
projeto deve estar em uma posição para fechamento. Em alguns casos, o fim do ciclo de
vida atual pode coincidir com o início de outro ciclo de vida no mesmo produto,
conduzindo à nova geração ou versão do produto. Para outros projetos, o fim da
Transição pode coincidir com uma liberação total dos artefatos a terceiros que poderão
ser responsáveis pela operação, manutenção e melhorias no sistema liberado.

Essa Fase de Transição pode ser muito fácil ou muito complexa, dependendo do tipo de
produto. Um novo release de um produto de mesa existente pode ser muito simples, ao
passo que a substituição do sistema de controle do tráfego aéreo de um país pode ser
excessivamente complexa.

As atividades realizadas durante uma iteração na Fase de Transição dependem da meta.

Por exemplo, ao corrigir erros, normalmente bastam a implementação e o teste. Se, no
entanto, novas características tiverem de ser adicionadas, a iteração será semelhante a
uma da fase de construção, exigindo análise, design, etc.

A Fase de Transição entra quando uma baseline estiver desenvolvida o suficiente para
ser implantada no domínio do usuário final. Isso normalmente requer que algum
subconjunto usável do sistema tenha sido concluído com nível de qualidade aceitável e
documentação do usuário, de modo que a transição para o usuário forneça resultados
positivos para todas as partes.
Os objetivos principais da Fase de Transição são:

• Teste beta para validar o novo sistema em confronto com as expectativas do

usuário
• Teste beta e operação paralela relativa a um sistema legado que está sendo
substituído
• Conversão de bancos de dados operacionais
• Treinamento de usuários e equipe de manutenção
• Introdução a marketing, distribuição e equipe de vendas
• Engenharia voltada para implantação, como preparação, empacotamento e
produção comercial, introdução a vendas, treinamento de pessoal em campo
• Atividades de ajuste, como correção de erros, melhoria no desempenho e na
usabilidade
• Avaliação das baselines de implantação tendo como base a visão completa e os
critérios de aceitação para o produto
• Obtenção de auto-suportabilidade do usuário
• Obtenção do consentimento dos envolvidos de que as baselines de implantação
estão completas
• Obtenção do consentimento dos envolvidos de que as baselines de implantação
são consistentes com os critérios de avaliação da visão

Atividades básicas

• Executar planos de implantação

• Finalizar o material de suporte para o usuário final
• Testar o produto liberado no local do desenvolvimento
• Criar um release do produto
• Obter feedback do usuário
• Ajustar o produto com base em feedback
• Disponibilizar o produto para os usuários finais

No fim na fase de transição está o quarto marco mais importante do projeto, o Marco
do Release do Produto. Nesse momento, você decide se os objetivos foram atendidos,
e se outro ciclo de desenvolvimento deve ser iniciado. Em alguns casos, esse marco
pode coincidir com o fim da fase de iniciação do próximo ciclo. O Marco do Release do
Produto é o resultado da conclusão com êxito de Atividade: Revisão da Aceitação do
Projeto.

Critérios de Avaliação

Os critérios básicos de avaliação para a fase de transição envolvem as respostas para

estas questões:

• O usuário está satisfeito?

• As despesas reais com recursos são aceitáveis se comparadas com as planejadas?

No Marco do Release do Produto, o produto está em produção e o ciclo de manutenção

posterior ao release inicia. Isso pode envolver o início de um novo ciclo ou de algum
release de manutenção adicional
PLANO DE ITERAÇÃO DE EXEMPLO: FASE DE TRANSIÇÃO

A ilustração mostra o relacionamento dos fluxos de trabalho em uma iteração tardia da

fase de transição — se o 'Fechamento do Projeto' do Detalhamento do Fluxo de
Trabalho for chamado, essa será a iteração final. Ela será construída a partir dos
Detalhamentos do Fluxo de Trabalho da forma como aparecerem naquele momento. O
intuito é indicar as dependências e mostrar onde ocorrem fluxos de trabalho em
paralelo. Os comprimentos das barras no gráfico (indicando a duração) não têm
significado absoluto. Por exemplo, não se pretende transmitir que Refinar a Arquitetura
e Teste de Aceitação (no site de desenvolvimento) têm a mesma duração. Também não
é a intenção sugerir a aplicação de um nível de esforço uniforme no decorrer dos fluxos
de trabalho. Uma indicação do esforço relativo pode ser vista em Visão Geral do
Processo. É possível navegar para as páginas correspondentes do Detalhamento do
Fluxo de Trabalho a partir de cada linha do gráfico; basta clicar no nome do
Detalhamento do Fluxo de Trabalho. Essa ilustração foi criada a partir de um Plano do
Microsoft Project.
Essa iteração final na fase de transição atinge o ponto máximo na liberação para o
cliente de um sistema completo (e artefatos de suporte auxiliares) com a funcionalidade
e o desempenho que foram especificados e demonstrados no teste de aceitação. O
cliente apropria-se do software após um teste de aceitação bem-sucedido.
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.

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