CENTRO ESTADUAL DE EDUCAÇÃO

PROFISSIONALIZANTE

RATIONAL UNIFIED PROCESS – RUP

PROCESSO RACIONAL UNIFICADO

PROF. MARCONDES
ROTEIRO

Rational
Pontos
Unified Fases do RUP Workflows RUP - IBM
importantes
Process - RUP
RATIONAL UNIFIED PROCESS - RUP
RATIONAL UNIFIED PROCESS - RUP
• Modelo de processo moderno, derivado do trabalho sobre a UML e do
Processo Unificado de Desenvolvimento de Software.

• Criado pela Rational Software Corporation, adquirida pela IBM.

• Usa uma abordagem da orientação a objetos; é projetado e documentado

utilizando a notação UML (Unified Modeling Language).

• Produzir software de qualidade, atendendo aos requisitos estabelecidos pelo

cliente, e respeitando um orçamento e cronograma previamente definidos.
RATIONAL UNIFIED PROCESS - RUP

FIGURA 1 – FINALIDADE RUP

RATIONAL UNIFIED PROCESS - RUP
• RUP ≠ Processo Unificado.

• Processo considerado pesado e preferencialmente aplicável a grandes

equipes e a grandes projetos.

• O planejamento é baseado num conjunto de processos, que buscam atingir

certos objetivos no tempo.

• Projeto é abordado de forma dinâmica e iterativa.

RATIONAL UNIFIED PROCESS - RUP
• RUP é, por si só, um produto de software. É modular e automatizado.

• Bom exemplo de modelo híbrido de processo.

• Cleanroom, XP(Extreme Programming), Scrum, FDD (Feature Driven

Development).

• Geralmente descrito a partir de três perspectivas:

• Perspectiva dinâmica;
• Perspectiva estática;
• Perspectiva prática.
RATIONAL UNIFIED PROCESS - RUP

FIGURA 2 – MAPA DE PROCESSOS

FASES DO RUP
FASES DO RUP
• Divisão do projeto em fases.

• Cada fase precede um marco no projeto.

• Série de artefatos e critérios de avaliação de sucesso são pré-estabelecidos.

• Processo de software é tratado em fases que, quando finalizadas, atingem

marcos, que serão validados através de diretivas, e trarão uma série de
produtos necessários para a próxima etapa.
CONCEPÇÃO
• Estabelecer um business case para o sistema;

• Identificar todas as entidades externas, e definir suas interações.

• Contribuição do sistema com o negócio é avaliada;

• Dependendo da contribuição, o projeto pode até ser cancelado.

LCO( Lifecycle Objetive )- ARTEFATOS
• Visão: documentação dos requisitos, restrições e elementos chave do
projeto;

• Riscos: identificar os riscos do projeto;

• Caso de negócio: documento que contém as informações e suposições sobre

o retorno do investimento;

• Plano de desenvolvimento de software: Fases iniciais, duração e objetivo;

• Lifecycle Objetive - Objetivo do ciclo de vida
LCO - ARTEFATOS
• Plano de iteração: Atividades e tarefas divididas, com recursos e
dependência;

• Caso de desenvolvimento: descrição do processo de desenvolvimento para

servir de guia;

• Ferramentas: tudo que será necessário para o desenvolvimento do software;

• Glossário: termos importantes no projeto.

CONCEPÇÃO - PERGUNTAS
• Os stakeholders estão confiantes de que a equipe do projeto entendeu o
problema a ser resolvido?

• Os stakeholders estão confiantes de que os riscos mais críticos foram

identificados?

• As estimativas iniciais foram refinadas com base no conhecimento

adquirido?

• As estimativas de custo e prazo são aceitáveis para os stakeholders?

ELABORAÇÃO
• Desenvolver um entendimento do domínio do problema;

• Estabelecer um framework de arquitetura para o sistema;

• Desenvolver o plano de projeto;

• Identificar os principais riscos do projeto.

ELABORAÇÃO
• Modelo de requisitos para o sistema (os casos de uso da UML são
especificados);

• Uma descrição de arquitetura;

• Um plano de desenvolvimento para o software.

LCA(Lifecycle Architecture) - ARTEFATOS
• Protótipos: explorar a funcionalidade crítica e os cenários significativos;

• Lista de riscos: atualização e revisão dos riscos identificados na fase

anterior;

• Caso de desenvolvimento: atualização do artefato já elaborado;

• Ferramentas: ferramentas pertinentes ao trabalho de elaboração

são instaladas;
• Lifecycle Architecture - Arquitetura do ciclo de vida
LCA - ARTEFATOS
• Documento de arquitetura de software: visão geral de arquitetura
abrangente do sistema;

• Modelo de design: realização dos casos de uso; guia para o modelo de

implementação;

• Modelo de dados: descreve a representação lógica e física dos dados

persistentes no sistema;

• Modelo de implementação: conjunto de componentes;

LCA - ARTEFATOS
• Visão: compreensão sólida dos casos de uso mais críticos;

• Plano de desenvolvimento de software: atualizar o plano existente com

objetivo de abranger as próximas fases;

• Modelo de casos de uso: um modelo de casos de uso praticamente

concluído;

• Especificações suplementares: Os requisitos suplementares são

documentados e analisados;
LCA - ARTEFATOS
• Conjunto de testes: validar a estabilidade do build para cada release
executável;

• Arquitetura para automatização de testes: composição de diversos

elementos de automatização de testes e suas especificações.
ELABORAÇÃO - PERGUNTAS
• Os stakeholders tem confiança de que a equipe do projeto tem capacidade
de implementar a solução proposta?

• A arquitetura reflete os requisitos funcionais?

• Todos os riscos foram eliminados ou mitigados?

• As variações de custo e prazo são aceitáveis para os stakeholders?

CONSTRUÇÃO
• Fase essencialmente relacionada ao projeto, programação e teste de
sistema.

• As partes do sistema são desenvolvidas paralelamente e integradas.

• Ao término dessa fase deve-se ter:

• Um sistema de software em funcionamento;
• Documentação associada pronta para ser liberada para os usuários.
IOC(Initial Operational Capability) - ARTEFATOS
• Sistema: sistema executável pronto para começar o teste beta;

• Plano de implantação: coordena e lista as atividades envolvidas na

transferência do sistema da comunidade de desenvolvimento para a
comunidade de usuários;

• Conjunto de testes: testes implementados e executados de cada release;

• Materiais de treinamento: manuais do usuário e outros materiais de

treinamento;
• Initial Operational Capability – Capacidade Operacional Inicial
IOC - ARTEFATOS
• Plano de iteração: Plano de iteração para a próxima fase, concluído e
analisado;

• Modelo de design: atualizado com novos elementos de design;

• Caso de desenvolvimento: refinamento do ambiente de desenvolvimento;

• Ferramentas: ferramentas da fase de construção;

IOC - ARTEFATOS
• Modelo de dados: Atualizado com a experiência adquirida no processo de
construção.
CONSTRUÇÃO - PERGUNTAS
• O produto está completo o suficiente e com a qualidade mínima aceitável
para iniciar o teste de aceitação?

• O usuário e a organização estão preparados para o início da implementação

(transição do sistema)?

• As variações de custo e prazo são aceitáveis para os stakeholders?

TRANSIÇÃO
• Transferência do sistema da comunidade de desenvolvimento para a
comunidade de usuários.

• Entrada do sistema em funcionamento no ambiente real.

• Atividade onerosa e, às vezes, problemática.

• Sistema de software documentado e funcionando corretamente em seu

ambiente operacional.
PR - ARTEFATOS
• Build do produto: sistema concluído;

• Notas de release: identificam mudanças e erros;

• Artefatos de instalação: elementos de instalação do software, como também

a documentação associada;

• Material de treinamento: a partir dele o cliente poderá utilizar o sistema;

PR - ARTEFATOS
• Material de suporte para o usuário final: aprendizagem, manutenção e
utilização do sistema.
TRANSIÇÃO - PERGUNTAS
• Os objetivos do projeto foram atingidos de acordo com os critérios de
medição?

• As variações de custo e prazo são aceitáveis pelos stakeholders?

• Os usuários estão satisfeitos?

RELAÇÃO RECURSO X TEMPO

FIGURA 3 – RELAÇÃO RECURSO X TEMPO DAS FASES DO RUP

WORKFLOWS
WORKFLOWS
• São atividades que ocorrem durante o processo de desenvolvimento;
• Também chamado de disciplina;
• Um workflow mostra todas as atividades que deverá realizar para
construir um artefato.
• Não são temporais ou fixos nas fases.
WORKFLOWS
• Há 9 Workflows
• 6 principais
• 3 de apoio
WORKFLOWS PRINCIPAIS
➢ Modelagem de Negócios
➢ Casos de uso. Identificação dos processos.
➢ Requisitos
➢ Identificar indivíduos, restrições, fronteiras.
➢ Análise e Design
➢ Arquitetura, componentes, BD.
➢ Implementação
➢ Teste
➢ Implantação
➢ Aceitação, suporte.
WORKFLOWS DE APOIO
➢ Gerenciamento de Configuração e Mudança
➢ Gerencia as mudanças e planejamento de controle.
➢ Gerenciamento de Projeto
➢ Gerencia o desenvolvimento.

➢ Ambiente
➢ Ferramentas.
FIGURA 4 – Workflows
DÚVIDAS?
OBRIGADO!