RUP

Rational Unified Proccess

(Processo Unificado da
Rational)
Equipe WEB Cercomp
web@cercomp.ufg.br
 1. Introdução
 É  um  processo  proprietário  de  Engenharia  de  software 
criado  pela  Rational  Software  Corporation,  adquirida 
pela  IBM,  então  o  RUP  ganhou  o  nome  de  IRUP  IBM 
Rational  Unified  Software  (porém  o  nome  mais 
conhecido ainda é RUP);
 Fornece  técnicas  às  equipes  de  desenvolvimento  de 
software  objetivando  o  aumento  da  produtividade 
seguindo uma abordagem prescritiva (normatização);
 O RUP se baseia no paradigma de Orientação a Objetos e é 
projetado  e  documentado  utilizando  a  notação  UML 
(Unified  Modeling  Language)  para  ilustrar  os  processos 
em ação. 2
 1. Introdução
 É  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.

3
 1. Introdução
 O RUP se baseia nos 4 “P”s:
 Pessoas;
 Projeto;
 Produto;
 Processo.

4
 2. Linhas Mestras
 O  RUP  define  as  seguintes  linhas­mestras  e  esqueletos 
(templates)  para  os  membros  da  equipe  de  um  ciclo  de 
produção:
 Parte do cliente;
 Avaliação do progresso do projeto pela sua gerência.
 Ajuda  os  programadores  a  manterem­se  concentrados  no 
projeto.

5
 2.1. Gestão de requisitos
 Descreve como documentar a funcionalidade, restrições de 
sistema,  restrições  de  projeto  e  requisitos  de  negócio 
(Uma documentação apropriada é essencial para qualquer 
grande projeto).
 Os casos de uso (Use Cases) e os cenários são exemplos de 
artefatos  (produtos  de  trabalho  finais  ou  intermediários 
produzidos e usados durante os projetos) dependentes do 
processo, que têm sido considerados muito mais eficazes 
na  captura  de  requisitos  funcionais  ­  descrição  das 
diversas  funções  que  clientes  e  usuários  querem  ou 
precisam que o software faça.
6
2.1. Gestão de requisitos

7
2.2. Arquitetura baseada em
componentes
 Sistema que pode ser facilmente extensível;
 Reutilização de software e um entendimento intuitivo;
 Um componente normalmente se relaciona com um objeto 
na programação orientada a objetos;
 Arquitetura executável nas fases iniciais do projeto, ou seja, 
antes de comprometer recursos em larga escala;
 Estes  componentes  são  normalmente  incluídos  em 
infraestruturas  existentes  como  o  CORBA  e  o  COM 
(Modelo de Componentes de Objetos).

8
 2.3. Software de modelos
visuais
 Elaborar de modo efetivo uma maneira de se ter uma visão 
geral de uma solução;
 Melhor  entendimento  por  parte  de  pessoas  com  menor 
conhecimento técnico (ex: cliente) de um dado problema, 
e assim se envolvam mais no projeto como um todo;
 A  linguagem  de  modelagem  UML  tornou­se  um  padrão 
industrial  para  representar  projetos  e  é  amplamente 
utilizada pelo RUP.

9
 2.4. Verificação da
qualidade do software
 Não  assegurar  a  qualidade  do  software  é  a  falha  mais 
comum  em  todos  os  projetos  de  sistemas 
computacionais. Normalmente pensa­se em qualidade de 
software  após  o  término  dos  projetos,  ou  a  qualidade  é 
responsabilidade  de  uma  equipe  diferente  da  equipe  de 
desenvolvimento;
 O  RUP  visa  auxiliar  no  controle  do  planejamento  da 
qualidade,  verificando­a  na  construção  de  todo  o 
processo  e  envolvendo  todos  os  membros  da  equipe  de 
desenvolvimento.

10
 2.5. Gestão e Controle de
Mudanças do Software
 Em todos os projetos de software a existência de mudanças 
é  inevitável.  O  RUP  define  métodos  para  controlar  e 
monitorar mudanças. Como uma pequena mudança pode 
afetar aplicações de formas inteiramente imprevisíveis, o 
controle  de  mudanças  é  essencial  para  o  sucesso  de  um 
projeto;
 O  RUP  também  define  áreas  de  trabalho  seguras, 
garantindo a um programador que as mudanças efetuadas 
noutro sistema não afetarão o seu sistema.

11
 3. Fases
 Indicam  a  ênfase  que  é  dada  ao  projeto  em  um  momento 
específico;
 Um projeto é dividido em quatro fases:
    1. Concepção: ênfase no escopo do sistema;
    2. Elaboração: ênfase na arquitetura;
    3. Construção: ênfase no desenvolvimento;
    4. Transição: ênfase na implantação.

12
 3.1. Fase de concepção
 Delimitação do âmbito do projeto e do business case¹, afim 
de  que  as  partes  interessadas  (stakeholders)  concordem 
com  os  objetivos,  arquitetura  e  o  planejamento  do 
projeto.

[1]. Forma profissional de justificar o investimento para aprovar um projeto estratégico que agrega valor ao negócio da 
empresa. 

13
 3.2. Fase de Elaboração
 Análise  da  extensão  do  sistema  (ex:  problemas  a  serem 
resolvidos);
 Definição de uma arquitetura estável e robusta para todo o 
sistema, tendo em consideração os seus requisitos;
 Busca  complementar  o  levantamento/documentação  dos 
casos de uso.

14
 3.3. Fase Construção
 Na fase de construção, começa o desenvolvimento físico do 
software, produção de códigos, testes alfa e beta;
 Deve­se aceitar testes, e processos de testes estáveis, e se os 
códigos  do  sistema  constituem  "baseline"  ­  imagem  de 
uma versão de cada artefato.

15
 3.4. Fase de Transição
 Nesta  fase  ocorre  a  entrega  ("deployment")  do  software,  é 
realizado  o  plano  de  implantação  e  entrega, 
acompanhamento e qualidade do software;
 Produtos (releases, versões) devem ser entregues, e ocorrer 
a satisfação do cliente;
 Nesta fase também é realizada a capacitação dos usuários.

16
4. Processo RUP - Gráfico

17
 Referências
 Wthreex ­ RUP 2002.05.00 Portugues
 http://www.wthreex.com/
 Wikipedia – RUP
 http://pt.wikipedia.org/wiki/IBM_Rational_Unified_
Process

18