UNIVERSIDADE FEDERAL DO MATO GROSSO
ENGENHARIA DE
SOFTWARE II
Rational Unified Process (RUP)
AULA 2
Profª MSc. MICHELLE DE OLIVEIRA
PARREIRA
[email protected]
RATIONAL UNIFIED
PROCESS - RUP
RUP
2
O que é o RUP

Abordagem de desenvolvimento de software
◦ iterativa, centrada em arquitetura, e dirigida por casos de uso.

Processo de engenharia de software definido e estruturado:
◦ define quem faz o que, como e quando. Possui ainda uma
estrutura definida para o ciclo de vida de um projeto, articulando
marcos e pontos de decisão.

Produto (IBM/Rational):
◦ framework de processo personalizável para
engenharia de software.
RUP
3
Princípios essenciais

“Filho” do Processo Unificado (UP).

Define uma arquitetura executável no início.

Acomoda mudanças desde o início.

Ataca os maiores riscos primeiro.

Garante entregas significativas ao cliente.

Mantém o foco em software executável.

Visa Construir sistemas a partir de componentes.

Trabalho em equipe é requerido.

Faz da qualidade um “modo de vida”, não um alvo.
RUP
4
Paradigma do RUP

Centrado na arquitetura

Iterativo e incremental

Dirigido por casos de uso
RUP
5
Centrado na arquitetura

A arquitetura é a organização fundamental do
sistema como um todo, incluindo elementos
estáticos e dinâmicos e sua interação.

Consequências:
◦
◦
◦
◦
◦
Possibilita o entendimento da visão geral;
Organiza o esforço de desenvolvimento;
Facilita as possibilidades de reuso;
Facilita a evolução do sistema;
Dirige a seleção de casos de uso relevantes.
RUP
6
Arquitetura como Ponte
REQUISITOS
ARQUITETURA
CÓDIGO
Fonte: Garlan (2000)
RUP
7
Dirigido por casos de uso

Os casos de uso dirigem (guiam) todo o trabalho de
desenvolvimento, desde a captação inicial e negociação de
requisitos até a aceitação do código.

Justificativas:
◦ São expressos sob a perspectiva do usuário;
◦ São expressos em linguagem natural;
◦ Oferecem uma habilidade maior para a compreensão dos requisitos
reais do sistema;
◦ Oferecem a habilidade para atingir um alto grau de rastreabilidade de
requisitos;
◦ Oferecem um meio simples de decompor os requisitos em partes
(módulos, pacotes), que permitem a alocação de trabalho a
subequipes, facilitando a gerência do projeto.
RUP
8
Abordagem iterativa
Acomoda mudanças de requisitos.
 Integração não é mais feita como “big bang”,
no final do projeto.
 Riscos descobertos e tratados durante as
integrações iniciais.
 Gerenciamento tem um significado de fazer
mudanças táticas no produto.
 Reuso é facilitado.

RUP
9
Abordagem iterativa
Defeitos podem ser encontrados e corrigidos
ao longo das iterações.
 Otimiza a execução de funções da equipe de
projeto.
 Membros da equipe aprendem ao longo do
projeto.
 O processo de desenvolvimento é evoluido e
refinado ao longo do projeto.

RUP
10
Organização estrutural do RUP
RUP
11
Estruturas
Estrutura dinâmica: dimensão horizontal que
representa o tempo do processo. Mostra
como o processo, expresso em termos de
ciclos, fases, iterações e marcos, desenvolve-se
ao longo do ciclo de vida de um projeto.
 Estrutura estática: dimensão vertical que
descreve como os elementos do processo
(atividades, disciplinas, artefatos e papéis) são
logicamente agrupados em temas (disciplinas
ou fluxos).

RUP
12
Estrutura dinâmica
RUP
13
Ciclo
Um ciclo de desenvolvimento é um período
de tempo que envolve do começo do projeto
até a entrega do produto (ou cancelamento).
 Há diferentes ciclos dependendo do produto
como ciclo inicial de desenvolvimento e ciclo
de evolução ou manutenção.

RUP
14
Fase

Cada ciclo no processo é dividida em uma
sequência de quatro fases: Concepção,
Elaboração, Construção, Transição.

As fases sempre existem e são fundamentais,
não por causa do que é executado ou pelo
seu tamanho, mas pelo que é atingido pelos
marcos principais que concluem cada fase.
RUP
15
Ciclos típicos
RUP
16
Marcos principais
O propósito das fases não é particionar as
atividades por tipo (análise, codificação, etc) e
sim executar o suficiente de cada disciplina
para atingir os objetivos da fase no momento
que os marcos são atingidos.
 Os marcos principais do RUP não são
expressos em termos de completar certos
artefatos ou documentos, mas principalmente
em termos de mitigação de riscos e
completude do produto.

RUP
17
Fluxos variáveis
Os marcos principais são constantes em todos
projetos que utilizam o RUP.
 Entretanto, isso não significa que há uma
prescrição fixa ou pré-determinada de um
conjunto de atividades a seguir em todas as
fases.
 Alguns fatores influenciam o trabalho a ser
feito, tais como: tamanho e natureza do
projeto, riscos, número de envolvidos.

RUP
18
Artefatos congelados



Os objetivos de uma fase não estão descritos em termos
de terminar um artefato, mas trazer o nível adequado de
maturidade para tornar-se capaz de tomar as decisões
corretas.
À medida que o projeto evolui mais entendimento é
obtido a respeito dos objetivos, à medida que novas
dificuldades são descobertas, mudanças são introduzidas,
artefatos são revisados, atualizados e corrigidos.
Portanto, atividades já realizadas são executadas
novamente, com maior grau de refinamento.
RUP
19
Fase concepção

Objetivos:
◦
◦
◦
◦
◦

Entender o que será construído;
Identificar funcionalidades-chave do sistema;
Determinar pelo menos uma solução possível;
Entender o cronograma, custos e riscos do projeto;
Decidir qual processo e ferramentas seguir.
Marco:
◦ Objetivo do ciclo de vida.

Identifique um produto:
___________________
RUP
20
Fase elaboração

Objetivos:
◦ Ter um entendimento detalhado dos requisitos;
◦ Desenhar, implementar e validar a arquitetura;
◦ Mitigar riscos essenciais e produzir um plano mais
refinado;
◦ Preparar o ambiente de desenvolvimento.

Marco:
◦ Arquitetura do ciclo de vida.

Identifique um produto:
___________________
RUP
21
Fase construção

Objetivos:
◦ Minimizar custos de desenvolvimento e atingir certo
grau de paralelismo para melhorar o desempenho no
projeto;
◦ Desenvolver iterativamente um produto pronto para
a comunidade de usuários.

Marco:
◦ Capacidade operacional inicial.

Identifique um produto: __________________
RUP
22
Fase Transição

Objetivos:
◦ Realizar testes beta para validar expectativas dos usuários;
◦ Treinar usuários e demais envolvidos visando sua
independência.
◦ Preparar ambiente e converter banco de dados;
◦ Preparar empacotamento e distribuição;
◦ Obter lições aprendidas;

Marco:
◦ Liberação do produto para produção.

Identifique um produto: _____________________________
RUP
23
Iteração



Dentro de cada fase podem existir uma ou mais
iterações.
Software é desenvolvido em cada iteração, que é
concluída em uma revisão secundária (minor milestone),
incluindo uma liberação (release) interna ou externa
que torna-se um ponto de avaliação do progresso do
projeto.
O produto cresce de forma incremental, à medida que
são feitas as iterações e suas atividades.
RUP
24
Iterações por fase
RUP
25
Build
Dentro de cada iteração, os vários
desenvolvedores ou times podem produzir
builds de software; em alguns casos em
frequências elevadas, até diariamente.
 Isso permite integração contínua, testes
(inclusive de regressão) e indicadores gerais
de progresso.
 Frequentemente, o último build de uma
iteração é parte da liberação daquela iteração.

RUP
26
Fluxo
Sequência organizada e coerente, que produz
algum resultado significativo.
 Mostra a interação entre papéis, atividades e
artefatos.
 Os principais tipos de fluxo são:

◦ Disciplinas
◦ Detalhes das disciplinas.
RUP
27
Disciplina

As disciplinas representam uma partição de todos os papéis
e atividades em agrupamentos lógicos, organizados por
áreas de conhecimento ou especialidade.

Dividem-se em:
◦ Disciplinas técnicas.
◦ Disciplinas de apoio.
RUP
28
Disciplinas

Disciplinas técnicas
◦ Modelagem de negócio;
◦ Requisitos;
◦ Análise e desenho;
◦ Implementação;
◦ Implantação;
◦ Teste;

Disciplinas de apoio:
◦ Gerenciamento de projetos;
◦ Gerencia de configuração;
◦ Ambiente.
RUP
29
Atividade
Uma unidade de trabalho que deve ser
desenvolvida. Tem um propósito claro,
usualmente expresso em termos de criação
ou atualização de algum artefato, modelo,
componente ou plano.
 Atividade é uma subdivisão de Iteração.
 A cada atividade é atribuído um papel
específico. Exemplos:

◦ Elaborar caso de uso => Analista de requisitos;
◦ Preparar plano de projeto => Gerente de projeto.
RUP
30
Papel
É um “chapéu” que um indivíduo ou grupo
coloca em um dado momento, no projeto.
 Um indivíduo pode desempenhar vários
papéis, que não podem ser confundidos com
cargos na organização.
 Exemplos de papéis:

◦ Desenhista (designer);
◦ Analista de requisitos;
◦ Testador.
RUP
31
Artefato
Conjunto de informações produzido,
modificado ou utilizado num processo.
 Traduz-se num produto (plano, desenho,
código, etc).
 São elementos tangíveis de um projeto: coisas
que um projeto produz ou usa enquanto o
trabalho é executado.
 Tipos de artefato: modelos, elementos de
modelo, documento, código fonte, executável.

RUP
32
Elementos adicionais
Guias
 Gabaritos (templates)
 Mentor de ferramenta
 Conceitos
 Roteiros

RUP
33
Planejamento de projetos

Conceitos-chave:
◦
◦
◦
◦
Ciclo.
Fase.
Iteração.
Build.
RUP
34
Estratégia de planejamento
Devido ao fato do processo iterativo ser
altamente dinâmico, adaptável e desenhado
para acomodar mudanças, não é interessante
gastar tempo e esforço produzindo planos
detalhados que ultrapassem o horizonte do
projeto.
 Planos “burocráticos” são difíceis de manter,
tornando-se rapidamente obsoletos; são
tipicamente ignorados pela organização, após
algumas semanas.

RUP
35
Plano de projeto e iterações

A abordagem iterativa e incremental
estabelece dois tipos de planejamento:
◦ Alto-nível (coarse-grain): contido no plano de
projeto, que aborda as fases, iterações, seus
objetivos e informações gerais. Há um plano
por projeto.
◦ Baixo-nível (fine-grain): contido em planos
de iteração, que traz as atividades e
recursos individuais. Há um plano por
iteração.
RUP
36
Plano de projeto



Gerentes de níveis superiores e stakeholders raramente
se interessam por detalhes sobre quem está fazendo o
que e quando. O foco gerencial está no produto final,
datas de liberação, marcos significativos…
Decisões importantes devem ser tomadas pelo gerente,
no sentido de avaliar o progresso geral do projeto e
solucionar problemas.
O plano de projeto é um plano de alto nível, que atua
como um “envelope” para os planos detalhados de cada
iteração.
RUP
37
Plano de iteração
Plano detalhado e com tempo bem definido,
com um intervalo de tempo suficientemente
pequeno para prover a equipe de um tipo de
detalhamento com o qual ela está acostumada.
 Deve definir tarefas e alocação de cada
membro da equipe.
 Em alguns projetos, o plano de iteração
corresponde a uma simples lista de “tarefas
por fazer”.

RUP
38
Problemas gerenciais - gerais




Organização funcionalmente especializada, ao invés de
equipes multifuncionais (burocracia).
Falta de definição clara sobre as expectativas dos
stakeholders, que podem esperar os mesmos resultados de
um processo cascata.
Alocação de muitos desenvolvedores no começo do
projeto, antes de entender bem o que fazer.
Resolver as questões fáceis primeiro ao invés de tratar as
questões de maior risco.
RUP
39
Problemas gerenciais - tempo
Iteração inicial muito longa, tentando fazer
muitas coisas no começo.
 Iterações sobrepostas, iniciando a próxima
iteração sem o feedback da anterior. Confusão
típica de quem não domina o RUP.
 Mudanças excessivas nos momentos finais do
projeto, levando a atrasos.

RUP
40
Problemas técnicos - equipe




Número excessivo de casos de uso, tratando-os como uma
decomposição funcional e tornando os requisitos
incompreensíveis.
“Paralisia da análise”, devido ao excesso de detalhes.
Inclusão de decisões de desenho nos requisitos, forçando
decisões prematuras.
Falta de comprometimento dos clientes, levando a um
sistema potencialmente rejeitável.
RUP
41
Problemas técnicos - gerente
Mentalidade “o que não foi inventado aqui não
presta”, reduzindo reuso.
 Fim da elaboração antes da maturidade da
arquitetura, causando retrabalho.
 Foco em inspeções e revisões ao invés de
software executando, causando um processo de
garantia de qualidade ineficiente, abordando
apenas documentos ao invés do executável.

RUP
42
Alguns dados históricos sobre o RUP

Durações típicas de projetos:
◦ De 6 semanas a 54 meses.

Durações típicas de uma iteração:
◦ De 2 semanas a 6 meses.

Quantidade típica de iterações por projeto:
◦ De 3 a 9 iterações.

Quantidade de artefatos definidos:
◦ Aproximadamente 100.

Quantidade de papéis definidos:
◦ Aproximadamente 30.
RUP
43
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
tamanho médio deve prever a seguinte distribuição de esforço e programação:
Esforço
Programação
Iniciação
~5 %
10 %
Elaboração
20 %
30 %
Construção
65 %
50 %
Transição
10%
10%
Fonte: http://www.wthreex.com/rup/portugues/index.html
RUP
44
Iterações por fase
Tamanho do
projeto (pessoas)
3
10
80
Duração do
projeto (m)
4
8
20
Iterações por fase
Duração por Concepção Elaboração Construção Transição
iteração (s)
2-3
1
1
3
1
4
1
2
3
2
7-8
2
3
4
2
RUP
45
Detalhamento das disciplinas

Disciplinas técnicas
◦ Modelagem de negócio;
◦ Requisitos;
◦ Análise e desenho;
◦ Implementação;
◦ Implantação;
◦ Teste;

Disciplinas de apoio:
◦ Gerenciamento de projetos;
◦ Gerencia de configuração;
◦ Ambiente.
RUP
46
Modelagem de negócio

Objetivos
◦ Entender a estrutura e a dinâmica da organização na
qual o sistema deve ser implantado.
◦ Entender os problemas atuais e identificar melhorias
potenciais.
◦ Garantir um entendimento comum entre clientes,
usuários e desenvolvedores.
◦ Derivar os requisitos de sistemas necessários.
RUP
47
Modelagem de negócio

Principais papéis:
◦
◦
◦
◦

Analista de negócio
Desenhista de processo de negócio
Stakeholders
Revisores
Principais artefatos:
◦
◦
◦
◦
◦
Documento de visão de negócios
Modelo de casos de uso de negócio
Modelo de objetos de negócio
Especificação suplementar de negócio
Glossário de negócio
RUP
48
Requisitos

Objetivos
◦ Estabelecer e manter acordo entre stakeholders sobre
o que o sistema deve fazer
◦ Prover aos desenvolvedores um melhor
entendimento dos requisitos do sistema
◦ Definir as fronteiras do sistema
◦ Prover a base para planejamento do conteúdo técnico
das iterações
◦ Prover a base para estimativas de duração e custo
RUP
49
Requisitos

Principais papéis :
◦ Analista de sistemas
◦ Especificador de casos de uso
◦ Desenhista de interfaces com usuário

Principais artefatos:
◦ Glossário
◦ Descrição dos casos de uso
◦ Protótipos de interface com usuário
RUP
50
Análise e desenho

Objetivos
◦ Traduzir os requisitos em uma especificação que
descreva como implementar o sistema
◦ Selecionar a melhor estratégia de implementação
◦ Estabelecer uma arquitetura robusta para a aplicação
RUP
51
Análise e desenho

Principais papéis :
◦
◦
◦
◦

Arquiteto
Desenhista
Desenhista de banco de dados
Revisor
Principais artefatos:
◦ Modelo de análise
◦ Modelo de desenho
◦ Documento de arquitetura de software
RUP
52
Implementação

Objetivos
◦ Definir a organização do código em termos de
subsistemas e camadas
◦ Implementar classes, objetos e componentes
◦ Testar unidades criadas
◦ Integrar em um ambiente executável os resultados
produzidos individualmente
RUP
53
Implementação

Principais papéis :
◦
◦
◦
◦

Implementador
Integrador de sistemas
Arquiteto
Revisor de código
Principais artefatos:
◦ Implementação de subsistema
◦ Componente
◦ Plano de integração
RUP
54
Testes

Objetivos
◦ Verificar a interação dos atores com cada
componente.
◦ Verificar a integração entre os componentes.
◦ Verificar a implementação correta de todos os
requisitos.
◦ Identificar e garantir que todos os defeitos
descobertos sejam tratados.
RUP
55
Testes

Principais papéis :
◦ Desenhista de testes
◦ Testador

Principais artefatos:
◦
◦
◦
◦
◦
Plano de testes
Modelo de testes
Resultados dos testes
Modelo de carga
Defeitos gerados
RUP
56
Gerenciamento de configuração e mudanças

Objetivos
◦ Rastrear e manter a integridade do projeto.
◦ Habilitar membros da equipe a identificar e localizar
artefatos, selecionar a versão adequada e avaliar o
histórico do artefato.
◦ Acompanhar a evolução do projeto.
RUP
57
Gerenciamento de configuração e mudanças

Principais papéis :
◦
◦
◦
◦
◦

Gerente de configuração
Gerente de controle de mudanças
Implementador
Integrador
Arquiteto
Principais artefatos:
◦
◦
◦
◦
Plano de gerenciamento de configurações
Requisições de mudança
Modelo de implementação
Métricas e relatórios de status
RUP
58
Gerenciamento de projetos

Objetivos
◦ Prover uma estrutura para gerenciar projetos de
desenvolvimento.
◦ Prover diretrizes práticas para planejar, executar,
apoiar e monitorar projetos.
◦ Prover uma estrutura para gerenciar riscos.
RUP
59
Gerenciamento de projetos

Principais papéis:
◦ Gerente de projetos

Principais artefatos:
◦
◦
◦
◦
Plano de desenvolvimento de projeto
Plano de iterações
Modelo de negócio
Medidas do projeto
RUP
60
Ambiente

Objetivos
◦
◦
◦
◦
◦
Seleção e aquisição de ferramentas
Configuração e personalização de ferramentas
Configuração de processos
Melhoria dos processos
Prover serviços de apoio: infra-estrutura,
administração de contas, backup, etc.
RUP
61
Ambiente

Principais papéis:
◦
◦
◦
◦
◦
◦
◦

Analista de processos de negócio
Analista de sistemas
Desenhista de interfaces com usuário
Arquiteto
Redator
Administrador do sistema
Especialista em ferramentas
Principais artefatos:
◦ Diretrizes gerais
RUP
62
Implantação

Objetivos
◦
◦
◦
◦
◦
◦
Testar o software no ambiente final (produção).
Empacotar o software para implantação.
Distribuir o software.
Instalar o software.
Treinar os usuários finais.
Migrar o software existente (se for o caso) e
converter sua base de dados
RUP
63
Implantação

Principais papéis:
◦
◦
◦
◦

Gerente de implantação
Gerente de projetos
Redator
Implementador
Principais artefatos:
◦
◦
◦
◦
Software executável.
Artefatos de instalação: scripts, ferramentas, arquivos, guias, etc.
Notas de release.
Material de apoio e treinamento.
RUP
64
ATIVIDADE
65
Exercícios
1) O ciclo de vida de um processo unificado consiste de
quatro fases e nove disciplinas. Cite quais são essas fases
e disciplinas.
2) Explique as quatro fases da representação gráfica do
RUP.
3) Especifique o processo do RUP.
4) Existem problemas no desenvolvimento do software.
Quais os sintomas comuns em projetos que falham?
5) A maioria dos projetos que falham tem algumas causas
em comum. Quais são essas causas?
66
Exercícios
1) O ciclo de vida de um processo unificado consiste de
quatro fases e nove disciplinas. Cite quais são essas
fases e disciplinas.
Fases: concepção, elaboração, construção, transição.
Disciplinas: modelagem de negócios, requisitos, análise e
design, implementação, teste, implantação, gerenciamento
de configuração e mudança, gerenciamento de projeto,
ambiente.
2) Explique as quatro fases da representação gráfica do
RUP.
Concepção: fase que define o escopo do projeto.
Elaboração: fase que define os requisitos e a arquitetura.
Construção: fase de desenvolvimento do sistema.
Transição: fase de implantação do sistema.
67
Exercícios
3)
Especifique o processo do RUP.
Os processos são organizados em disciplinas, para posteriormente
definirem os fluxos de trabalho e outros elementos do processo.
As disciplinas são descritas por meio de fluxos de trabalho que
mostram uma sequência de grupos de atividades que produz um
determinado resultado. Cada grupo de atividades é descrito por
um diagrama de atividade que detalha o fluxo de trabalho. Esses
diagramas mostram todas as atividades do grupo, os papéis
envolvidos e os artefatos de entrada e saída.
4)
Existem problemas no desenvolvimento do software. Quais os
sintomas comuns em projetos que falham?
Entendimento impreciso das necessidades do usuário final; Falta de
habilidade para lidar com mudanças nos requisitos; Módulos que
não se comunicam; Softwares difíceis de manter ou entender;
Descobertas tardias de falhas graves no projeto; Qualidade de
software pobre; Desempenho inaceitável; E processo de
construção-entrega não confiável.
68
Exercícios
5)
A maioria dos projetos que falham tem algumas causas em
comum. Quais são essas causas?
Gerenciamento de requisitos Ad Hoc; Comunicação ambígua e
imprecisa; Arquiteturas falhas; Complexidade alta; Inconsistências não
detectadas nos requisitos, projeto e implementação; Testes
insuficientes; Medição subjetiva do status do projeto;
69
BIBLIOGRAFIA BÁSICA

Engenharia de Software - Ian
Sommerville.
 8ª edição. Pearson
Education

Engenharia de Software
Roger Pressman
 6ª edição. McGraw-Hill

Engenharia de Software
Wilson de Pádua Paula Filho
 2ª edição. LTC
70
AGUARDEM
PRÓXIMO
CONTEÚDO !!!
Contato: [email protected]
Professora MSc. Michelle Parreira
“Aprender é a única coisa de que a mente nunca
se cansa, nunca tem medo e nunca se arrepende”
Leonardo da Vinci
72