RUP – Rational Unified Process

É composto por quatro fases e nove disciplinas (workflow/fluxo de trabalho). É uma

metodologia de desenvolvimento incremental e iterativa. Sua meta é produzir software de alta
qualidade que atenda aos requisitos dos usuários dentro de um cronograma e orçamento
previsíveis.
Um processo define quem (papel) está fazendo o quê (artefatos), como (atividades) e
quando (fluxo) de modo a alcançar determinado objetivo.
• Um papel descreve quem executa as atividades que geram os artefatos.
o uma pessoa pode representar diversos papéis
• Artefatos são quaisquer produtos resultantes do processo de software.
• Atividade é uma unidade de trabalho que um indivíduo desempenhando um papel
pode ser chamado a realizar.

O RUP possui duas dimensões:

• O eixo horizontal representa o aspecto dinâmico do processo e é expresso em
termos de fases, iterações e marcos.
• O eixo vertical representa o aspecto estático do processo, representa as
disciplinas.

PRECISA DECORAR ESTE GRÁFICO

1
 Uma passagem pelas quatro fases é um ciclo de desenvolvimento; cada passagem pelas
quatro fases produz uma geração do software. À medida que o produto atravessa vários ciclos,
são produzidas novas gerações.
Uma passagem pelas nove disciplinas é uma iteração. O número de iterações para
completar um projeto depende da complexidade do mesmo.

FASES DO RUP
Iniciação/Concepção

Objetivos
• Estabelecer o escopo do software do projeto
• Discriminar os casos de uso críticos do sistema
• Exibir pelo menos uma opção de arquitetura básica
• Estimar o custo geral e a programação para o projeto inteiro
• Estimar riscos
• Preparar o ambiente e dar suporte para o projeto

Atividades Básicas
• Formular o escopo do projeto
• Planejar e preparar um caso de negócio
• Sintetizar uma possível arquitetura
o Arquitetura é a organização lógica do conjunto de classes que vai compor o
software
• Preparar o ambiente para o projeto

Marco: Objetivos do Ciclo de vida

• Decide se o projeto é financeiramente viável e se vai ou não prosseguir com ele

Artefatos
• Visão
• Caso de Negócio
o Para determinar se vale ou não a pena investir no projeto
• Plano de Desenvolvimento de Software
o Informações necessárias ao desenvolvimento do software
• Modelo de Casos de Uso (20%)
• Glossário
o Define os termos importantes usados no projeto

2
Elaboração
Criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o
esforço da fase de construção

Objetivos
• Assegurar que a arquitetura, os requisitos e os planos estejam estáveis o suficiente e
que os riscos sejam suficientemente diminuídos
• Tratar os riscos significativos do ponto de vista da arquitetura
• Demonstrar que a arquitetura suportará os requisitos do sistema a um custo/tempo
justo
• Estabelecer um ambiente de suporte

Atividades
• Definir, validar e criar a baseline da arquitetura
• Refinar a visão
• Criar planos de iteração detalhados
• Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento
• Refinar a arquitetura e selecionar componentes

Marco: Arquitetura do Ciclo de Vida

• Arquitetura estável
o Um dos critérios de avaliação é comparar a despesa real com a planejada

Artefatos
• Protótipos
• Lista de Riscos
• Documento de Arquitetura de Software
• Modelo de Projeto
• Modelo de Dados
• Modelo de Casos de Uso (80%)

Construção
A meta é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema
com base na arquitetura da baseline.

Objetivos
• Minimizar os custos do desenvolvimento
• Atingir a qualidade adequada
• Atingir as versões úteis (alfa, beta e etc.)
• Concluir a análise, o projeto, o desenvolvimento e o teste de todas as funcionalidades
necessárias
• Decidir se o software, os locais e os usuários estão prontos para a implantação
• Atingir um paralelismo entre o trabalho das equipes para acelerar o desenvolvimento do
software

Atividades
• 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

3
Marco: Capacidade Operacional Inicial
• Determina se o produto está pronto para ser implantado num ambiente de teste beta

Artefatos
• Manuais de Usuário Completos
• Sistema executável para iniciar testes beta
• Conjunto de Testes
• Plano de Implantação

Transição
O objetivo é assegurar que o software esteja disponível para seus usuários finais. Inclui
testar o produto em preparação para release e ajustes pequenos com base no feedback do
usuário, que deve priorizar o ajuste fino do produto, a instalação, configuração e problemas de
usabilidade. Problemas estruturais mais graves já devem ter sido tratados antes.

Objetivos
• Teste beta para validar o novo sistema
• 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
• Atividades de ajuste
• Obtenção do consentimento dos envolvidos de que as baselines estão consistentes com
os critérios de avaliação da visão

Atividades
• Executar os 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 e ajustar o produto com base nele
• Disponibilizar o produto para os usuários finais

Marco: Release do Produto

• Você decide se os objetivos foram atendidos e se outro ciclo de desenvolvimento deve
ser iniciado.

Artefatos
• Notas de Release
• Artefatos de Instalação
• Materiais de Treinamento e Suporte
• Build do Produto

4
Disciplinas do RUP (Workflow/Fluxo de Trabalho) (MRAITIGGA)
Uma disciplina mostra todas as atividades que devem ser realizadas para produzir um
determinado conjunto de artefatos. O RUP descreve detalhadamente as suas nove disciplinas.

Modelagem de Negócios
• Entender a estrutura e a dinâmica da organização na qual o sistema deve ser
implantado. Entender como funciona a organização.
• Entender os problemas atuais da organização-alvo e identificar as possibilidades de
melhoria.
• Assegurar que os clientes, usuários e desenvolvedores tenham um entendimento
comum da organização-alvo.
• Derivar os requisitos de sistemas necessários para sustentar a organização-alvo

Requisitos
• Estabelecer e manter concordância com os clientes e outros envolvidos sobre o que o
sistema deve fazer
• Oferecer aos desenvolvedores uma compreensão melhor dos requisitos do sistema
• Definir as fronteiras do sistema
• Base para planejar o conteúdo técnico das iterações
• Base para estimar o custo e o tempo de desenvolvimento do sistema
• Definir uma interface de usuário para o sistema

5
Análise e Design (Análise e Projeto)
• Transformar os requisitos em um design do sistema a ser criado
• Desenvolver uma arquitetura sofisticada para o sistema
• Adaptar o design para que corresponda ao ambiente de implementação, projetando-o
para fins de desempenho

Implementação
• Definir a organização do código em termos de subsistemas de implementação
organizados em camadas
• Implementar classes e objetos em termos de componentes
• Teste de unidade dos componentes
• Integrara os resultados produzidos ao sistema executável

Testes
• O teste enfatiza a avaliação da qualidade do produto
• Localizar e documentar defeitos na qualidade do software
• Avisar de forma geral sobre a qualidade observada no software
• Validar as suposições feitas na Análise e Design/Requisitos
• Validar as funções do software conforme projetadas
• Verificar se os requisitos foram implementados de maneira adequada

6
Implantação
• Descrevem as atividades que garantem que o produto de software será disponibilizado a
seus usuários finais.
• Existem 3 modos de implantação:
o Caixa comercializável
o Download pela web
o Ir à empresa e instalar o produto

Gerenciamento de Configuração e Mudança

• Controla mudanças feitas nos artefatos de um projeto e mantém a integridade deles
• Evita:
o Atualização simultânea
o Notificação limitada
o Várias versões

7
Gerenciamento de Projetos
• Fornecer um framework para gerenciar projetos intensivos de software.
• Fornecer diretrizes práticas para planejar, montar a equipe, executar e monitorar os
projetos.
• Fornecer um framework de gerenciamento de risco.
• O Gerenciamento de Projetos não cobre:
o Gerenciamento de pessoal
o Gerenciamento de custos
o Gerenciamento de contratos, entre outros

Ambiente
• Atividades necessárias à configuração do processo para um projeto
• Fornece à organização o ambiente de desenvolvimento de software (ferramentas e
processos) que dará suporte à equipe de desenvolvimento
• Disciplina ligada a garantia de qualidade de processos

8
Arquitetura 4 + 1
Visão de Arquitetura
• Visão de um sistema a partir de uma determinada perspectiva
• Foco na estrutura, modularidade, componentes essenciais e nos principais fluxos de
controle
• São cinco visões no total (4 + 1)

Visão de Casos de Uso

• Descreve como casos de uso críticos são executados no sistema, dando ênfase
principalmente a componentes arquiteturalmente significativos.

Visão de Implantação
• Descreve uma ou várias configurações do sistema. É o mapeamento dos componentes
de software para nós de computação nessas configurações.

Visão de Implementação
• Descreve a organização dos elementos estáticos do software no ambiente de
desenvolvimento em termos de empacotamento, divisão em camadas e gerenciamento
da configuração.

Visão de Processos
• Descreve o aspecto simultâneo do sistema, tarefas (processos) e suas interações.

Visão Lógica
• Descreve as principais classes no design do sistema: classes relacionadas aos principais
negócios e classes que definem os principais mecanismos estruturais e
comportamentais (persistência, comunicações, tolerância e falhas, interface do usuário)
• Endereça as exigências funcionais do sistema, isto é, expressa o que o sistema deveria
fazer para os seus usuários finais.
• É uma abstração do modelo de projeto e identifica pacotes de projetos principais,
subsistemas e classes.