01 - RUP - Conceitos

Introduo
Fernando Pedrosa fpedrosa@gmail.com
Fernando Pedrosa Lopes
Phillip Kruchten Rational Unified

Process Made Easy. Addison Wesley
www.ibm.com (RMC)
www.wthreex.com/rup
Segundo Kruchten:
Necessidades do usurio mal
compreendidas
Falta de habilidade para tratar
mudanas de requisitos
Descoberta tardia de problemas srios
Baixa qualidade de software
Problemas com papis e
responsabilidades
Criado por Booch, Jacobson e

Rumbaugh, e implementado pela
Rational
Em seu livro, os amigos se referem a
ele como Unified Process. RUP o
nome comercial dado pela Rational
Em 2003 a IBM compra a Rational. RUP
continua sendo, at hoje, o principal
framework de processos no qual as
metodologias se baseiam
uma plataforma de processos

Adaptvel
Deve ser configurada para selecionar os
elementos apropriados s necessidades da
organizao
Fornece atividades, artefatos e guias

ligados
s ferramentas IBM/Rational
linguagem UML
Iterativo e Incremental
O ciclo de vida do produto dividido em
iteraes, cada uma entregando
incrementos (partes acabadas) do software
Guiado por casos de uso

Os casos de uso conectam todas as fases e
vises, sendo utilizados por todos os
stakeholders
Centrado na arquitetura
Envolve aspectos estticos e dinmicos
Evolui a partir das necessidades do produto
Orientado a Objetos
Componentes so construdos atravs de
Objetos e estes colaboram entre si para
realizar os casos de uso
Planejado por riscos

Os riscos so analisados continuamente e
os de maior criticidade so tratados
prioritariamente
(CAIXA - CESPE 2010)

[45] No se utilizam diagramas de caso de uso em projetos
desenvolvidos de acordo com o RUP (rational unified process).
(CEHAP CESPE 2009)
[27A] O RUP foi projetado em conjunto com a UML e os processos
de negcios so modelados usando casos de uso que,
posteriormente, sero desenvolvidos para modelar os requisitos
de sistema.
(TCU CESPE 2010)
[109] O processo unificado de software centrado na arquitetura
e orientado por casos de uso, o que sugere um fluxo de processo
iterativo e incremental.
(PETROBRAS - CESGRANRIO 2008)

[48] Um princpio fundamental do Processo Unificado
(A) ser centrado em arquitetura.
(B) empregar times auto-dirigidos e auto-organizados.
(C) o desenvolvimento em cascata.
(D) a programao em pares.
(E) a propriedade coletiva do cdigo fonte.
(BASA CESPE 2010)
[80] A metodologia RUP, que consiste no desenvolvimento
interativo com foco na reduo dos riscos do projeto, agrega um
valor real organizao que necessita manter padres relativos
s comunicaes externas e comunicao com a equipe de
desenvolvimento.
Eixo
dinmico
Eixo
esttico
10
O RUP tem duas dimenses

A primeira dimenso representa o
aspecto dinmico do processo
Eixo horizontal
Expresso em termos de fases, marcos e
iteraes
A segunda dimenso representa o

aspecto esttico do processo
Eixo vertical
Expresso em termos de componentes,
disciplinas, atividades, artefatos, papis
11
(SECONT/ES - CESPE 2010)

[76] O processo unificado estruturado em duas dimenses. A
dimenso horizontal representa o aspecto dinmico do
processo, onde esto representadas suas fases, s quais esto
associados marcos que determinam sua finalizao. Na outra
dimenso esto representadas as disciplinas, que agrupam
logicamente as atividades. possvel haver disciplina que no
esteja presente em todas as fases.
(EMBASA CESPE 2009)
[70] A primeira dimenso do RUP representa o aspecto dinmico
do processo quando ele aprovado e expressa em termos de
fases, iteraes e marcos.
12
13
Processo de Desenvolvimento
Conjunto de mtodos e prticas bem
definidas
Com responsveis
Entradas/Sadas
Ordem de precedncia
Inclui:
Ferramentas, Tecnologias, Pessoas, Padres e
guias
Quem? O qu? Como? Quando?

14
Modelos, Padres
e Guias
Equipes Treinadas
Ferramentas
Linguagem Padro
15
Qualidade de software
Maior produtividade
Maior previsibilidade
Maior controle sobre custos e prazos
16
Fases e Iteraes
Disciplinas/Fluxo de Atividades
Atividades/Tarefas
Artefatos/Produtos de Trabalho
Papis
17
Concepo
Elaborao
Construo
Transio
Estabelecer
o escopo, e
estimar
custos e
riscos
Assegurar
que os
principais
riscos foram
diminudos
e definir
uma
arquitetura
executvel
Desenvolver
de modo
iterativo e
incremental
um produto
completo
para a
Transio
Disponibilizar
o Software
para seus
usurios
finais
18
Cada fase termina com um Marco
19
Cada passagem pela sequncia

de disciplinas do projeto se
chama iterao
20
Cada fase pode ser dividida em

iteraes
21
(SERPRO CESPE 2010)

[72] O framework de processo RUP (rational unified process)
organiza o ciclo de vida de um produto de software desde o
incio de sua concepo at a sua aposentadoria, na seguinte
sequncia de etapas: concepo, elaborao, construo e
transio
(CEHAP CESPE 2009)
[27 C] Ao contrrio do modelo em cascata, no qual as fases
coincidem com as atividades do processo, o RUP compreende
as fases de concepo, elaborao, construo e transio.
22
(MPE/RR CESPE 2008)

[80] No Processo Unificado, a vida de um sistema dividida em
ciclos; cada ciclo, por sua vez, dividido em fases e, entre as
fases, tem-se a fase Construo, na qual as atividades visam
capturar requisitos ainda no capturados na fase anterior e
produzir uma arquitetura executvel, a ser usada na fase
Elaborao.
[81] O Processo Unificado iterativo e incremental. Ao final de

cada iterao, a qual um miniprojeto, os modelos que
representam o sistema encontram-se em um determinado
estado, denominado baseline. As atividades de cada fase de um
ciclo de vida podem ser distribudas entre vrias iteraes.
23
(ANATEL - CESPE 2006)

[86] O ciclo apresentado na figura, que compreende uma
execuo seqenciada das atividades de modelagem de
negcios, requisitos, anlise e desenho, implementao, testes,
avaliao etc., forma o denominado ciclo de vida de software
no modelo RUP.
24
So um conjunto de atividades
(fluxo de trabalho) relacionadas a
uma rea de interesse do
projeto
Ajudam a compreender o projeto
a partir de uma perspectiva em
cascata
25
Algumas disciplinas esto

associadas a conjuntos
especficos de modelos
26
Cada disciplina
possui um fluxo
de trabalho (ex:
Anlise e Design)
27
Disciplinas bsicas
Modelagem de
Negcios
Requisitos
Anlise e projeto
Implementao
Testes
Implantao
Disciplinas de suporte
Gerenciamento de Projeto
Gerenc. de configurao e
mudanas
Ambiente
MRAITIGGA
28
Definem o comportamento e as
responsabilidades no processo
Karina
Programador
Fbio
ris
Lus
Jorge
Testador
No representam pessoas!
Unidade de trabalho
desempenhada por um papel
Inseridas no contexto de uma
Disciplina
Compostas de:
Finalidade
Passos
Entradas e sadas
Papel responsvel
Guias e padres
30
So o resultado de um processo
de trabalho
Utilizados como entradas e/ou
sadas na execuo das
atividades
Podem ser:
Modelos
Documentos
Cdigo fonte
Executveis, etc
31
Papis executam Atividades que

geram Artefatos
32
Cada disciplina
tem uma viso
geral de
atividades
executadas
Ex:
Disciplina de
Requisitos
33
Cada disciplina tem uma viso geral dos

artefatos relacionados (ex: Requisitos)
34
(MPE/RR - CESPE 2008)

[79] No Processo Unificado, atividades so organizadas em
fluxos de atividades. Algumas atividades produzem artefatos,
que podem ser de engenharia ou gerenciais. Entre os artefatos
criados, h modelos que visam especificar o sistema a partir de
certos pontos de vista e nveis de abstrao.
(TRE/MT CESPE 2010)
[32-C] As disciplinas de suporte (apoio) do RUP so:
gerenciamento de classes; gerenciamento de produto; e
ambiente.
35
[32-D] Um papel uma definio abstrata de um conjunto de

atividades executadas e dos respectivos artefatos. Exemplos de
papis no RUP so: analistas, desenvolvedores e testadores.
Explicitamente, papis de gerentes no fazem parte dos papis
possveis no RUP.
[32-E] As disciplinas de engenharia do RUP so: modelagem de
negcios; requisitos; anlise e projeto; implementao; teste;
qualidade; e implantao.
36
37
38
Desenvolvimento Iterativo lida com

mudanas
As tticas e os requisitos variveis so
acomodados
Diminui riscos
Os riscos so reduzidos mais cedo, pois
os elementos so integrados
progressivamente
Busca melhor qualidade

A melhoria e o refinamento do produto
so facilitados, tornando-o mais robusto
39
Aprende e melhora
As organizaes podem aprender a
partir dessa abordagem e melhorar seus
processos
Aumenta o reuso
Identificar partes comuns quando esto
parcialmente projetadas ou
implementadas mais fcil que
identificar todas as semelhanas no
incio
40
Incorporam um conjunto quase

seqencial de atividades:
41
Com a abordagem em cascata, tudo

parece bem at quase no final do
projeto; s vezes, at a metade da
integrao. A, tudo desmorona. Com a
abordagem iterativa, muito difcil
esconder a verdade durante muito
tempo cliente da Rational
42
Jogue fora um pouco do trabalho

durante o caminho, para no ter
que jogar todo o trabalho fora ao
final. Grady Booch
43
(TRE/MT - CESPE 2010)

[44-A] Uma das principais caractersticas do RUP o uso da
iterao, que, por meio de refinamentos sucessivos, melhora o
entendimento do problema.
[44-C] Pelo fato de o RUP ser muito complexo, seu foco evita a
reduo dos riscos do projeto. Essa fase tratada diretamente
na UML.
44
45
Um requisito uma condio ou uma

restrio com a qual o sistema dever
estar em conformidade
O gerenciamento de requisitos uma
abordagem sistemtica para:
Localizar,
Documentar,
Organizar e Controlar os requisitos
variveis em um sistema.
46
Nem sempre os requisitos so

bvios e podem vir de vrias fontes.
Requisitos relacionam-se entre si,
mas deve haver consistncia nos
relacionamentos
Cada requisito diferente, eles no
so igualmente importantes ou
fceis de entender
47
H vrias partes interessadas

O nmero de requisitos pode se
tornar impossvel de gerenciar se
eles no forem controlados
Os requisitos so alterados
48
Analise o problema
Entenda o problema por trs do
problema
Estabelea um vocabulrio comum
Proponha solues em alto nvel
49
Entenda a necessidade das partes

interessadas
Todos querem algo. Determine qual a
melhor fonte
Utilize tcnicas de elicitao de

requisitos
Faa acordos, balanceie prioridades
50
Defina o sistema
Defina o que sistema deve fazer, em
termos gerais, utilizando linguagem
natural e grfica
Gerencie o escopo do sistema

O que est dentro? O que est fora?
Estabelea prioridades!
51
Gerencie requisitos variveis

Garanta que os requisitos tenham uma
estrutura que os tornem facilmente
atualizveis
Rastreie os requisitos
52
O RUP recomenda a utilizao de

Casos de Uso como mtodo para a
organizao dos requisitos
funcionais
Em vez de fazer uma lista de
requisitos, organize-os na viso de
como o usurio poder utilizar o
sistema
Utilize Casos de Uso!
53
Um caso de uso define um conjunto

de cenrios
Cada cenrio descreve o

comportamento do sistema em
termos de sequncias de aes
Um caso de uso deve produzir um
resultado de valor observvel para
um ator
Atores so as entidades que interagem
com o sistema
54
Clientes
Para entenderem o comportamento do
sistema e aprovar o fluxo de eventos
Arquitetos de Software
Para identificar caractersticas da
arquitetura
Analistas, Projetistas, Desenvolvedores

Para entender o comportamento do sistema
e refin-lo
55
Testadores
Utilizam os casos de uso como base para
gerar casos de teste
Gerentes
Para planejar e acompanhar o progresso do
projeto
E outras partes interessadas...

Por isso se diz que o RUP guiado por
Casos de Uso
56
(EMBASA CESPE 2010)

[72] No RUP, os manuais dos sistemas e as rotinas de teste so
definidos a partir dos casos de uso. Entretanto, os elementos
da arquitetura e a estratgia de implantao do sistema, por se
relacionarem com a infraestrutura e no com os requisitos
funcionais, no so definidos com base nos casos de uso.
57
58
Segundo a IEEE:
O conceito de mais alto nvel de

um sistema em seu ambiente
A arquitetura de um sistema a sua

organizao ou estrutura de
componentes significativos que
interagem atravs de interfaces
59
Arquitetura de Software inclui:
As decises significativas sobre a

organizao de um sistema
A seleo de elementos
estruturadores e suas interfaces
A especificao do comportamento
dos elementos do sistema e como
eles colaboram entre si
60
No se preocupa apenas com

estrutura e comportamento, mas
tambm com:
Funcionalidade
Desempenho
Segurana
Reuso
Manutenibilidade
Decises tecnolgicas e econmicas, ...

61
O que so?
Grupos coesos de cdigo fonte ou
executvel com interfaces e
comportamentos bem definidos
Fornecem forte encapsulamento de
contedo
Substituveis
Exemplos: mdulos, pacotes,
subsistemas, componentes OTS
62
<<Segurana>>
Autorizar
Autenticar
...
<<Relatrios>>
Como estes
componentes
colaboram
entre si?
Impresso
Gerao de
planilhas
...
<<Servios>>
Quais so suas
interfaces?
Log
Monitoramento
...
Aonde eles
esto
localizados?
63
Permite reuso em grande escala

Permite gerenciar a complexidade
do projeto e manter a integridade
do sistema
Identifica, isola, projeta,
desenvolve e testa pedaos bem
formados do sistema
Possibilita usar componentes de
prateleira (off the shelf)
64
No RUP a arquitetura representada

por uma srie de vises de
arquitetura diferentes
Em sua essncia, as Vises so

fragmentos que ilustram os
elementos significativos em termos
de arquitetura
conhecido como o modelo de
viso 4+1
65
66
Contm Casos de Uso e cenrios

que abrangem comportamentos
significativos em termos de
arquitetura, classes ou riscos
tcnicos
uma viso obrigatria do
documento de arquitetura de
software
67
68
Contm as classes de projeto mais

importantes e sua organizao em
pacotes e subsistemas, e a
organizao desses pacotes em
camadas
uma viso obrigatria do
documento de arquitetura de
software
69
70
Contm uma viso geral do Modelo de

Implementao e sua organizao em
termos de mdulos em pacotes e
camadas
Detalha os pacotes e mdulos da Viso
Lgica (detalhes fsicos)
uma viso opcional do documento de

arquitetura de software
Deve ser usada apenas se a implementao
no for derivada diretamente do modelo de
projeto (isto , h detalhes adicionais)
71
Contm a descrio das tarefas

(processos e threads) envolvidas,
suas interaes e configuraes e a
alocao dos objetos e classes de
projeto em tarefas
uma viso opcional do documento
de arquitetura de software
S precisa ser usada se o sistema tiver
alto grau de paralelismo
72
Caixa Eletrnico
73
Contm a descrio dos vrios ns

fsicos do sistema e a alocao de
tarefas atribudas a eles
uma viso opcional do documento

de arquitetura de software
S precisar ser usada se o sistema
estiver distribudo em vrios ns fsicos
74
75
(TRE/BA - CESPE 2010)

[62] Na engenharia de software baseada em componentes, na
qual se supe que partes do sistema j existam, o processo de
desenvolvimento concentra-se mais na integrao dessas
partes que no seu desenvolvimento a partir do incio. Essa
abordagem baseada em reso para o desenvolvimento de
sistemas de software.
(SAD/PE - CESPE 2010)

[35-D] desejvel que o valor da coeso e o do acoplamento,
duas importantes propriedades da arquitetura de um software,
sejam maximizados durante a engenharia de software.
76
77
Fazer uso de notao de design

grfica e visual para capturar o
projeto do software
Permitir que o nvel de abstrao
seja aumentado
Capturar requisitos com preciso

Melhorar a comunicao da equipe
(acabando com a ambiguidade)
78
UML Unified Modeling Language

Notao padro para modelagem de
Software
Oferece mltiplas perspectivas de um
problema
Mantm projeto e implementao
consistentes
79
UML
Melhoria da comunicao
Elevao da abstrao
Processo
Melhores prticas
O que fazer
Como fazer
Responsabilidades
Ferramenta
Produtividade
80
(TCU - CESPE 2010)

[108] UML (unified modeling language) uma tecnologia
concorrente com o processo unificado, no que diz respeito ao
apoio prtica de engenharia de software orientada a objetos.
(TJ/CE - CESPE 2008)
[90] O modelo de ciclo de vida prescrito pela metodologia RUP
iterativo, incremental, direcionado por riscos, adota as reas
de processos de gerncia de processos prescritas pelo modelo
CMMI e baseado em modelagem visual com UML e
ferramentas CASE.
81
82
Para as finalidades do RUP,

definida como:
...a caracterstica de ter demonstrado a
realizao da criao de um produto que

atende ou excede os requisitos
acordados, conforme avaliado por
medidas e critrios acordados, e que
criado em um processo acordado
83
Controle da Qualidade
Tem foco no produto, e em encontrar
defeitos especficos
Preza pelos resultados do seu trabalho
Garantia da Qualidade
Tem foco nos processos e como eles
esto sendo executados
Garante que voc est fazendo as

coisas de maneira correta
84
Qualidade multidimensional
Andamento: progresso do projeto

Variao: diferena entre planejado
e executado
Confiabilidade: robustez
Funcionalidade: casos de uso
implementados
Desempenho: tempo de execuo
em diversas situaes reais
85
O custo sobe exponencialmente...

Verificar a qualidade durante o ciclo
de vida essencial!
86
(TRE/BA - CESPE 2010)

[53] Uma falha comum em projetos de sistemas
computacionais no assegurar a qualidade do software.
Normalmente, essa questo discutida aps o trmino dos
projetos, ou a qualidade fica sob a responsabilidade de equipe
diferente da equipe de desenvolvimento. O RUP, proposto pela
IBM, um processo que prov uma soluo disciplinada sobre
como assinalar tarefas e responsabilidades dentro de uma
organizao de desenvolvimento de software, porm, no
auxilia no controle do planejamento e verificao da qualidade.
87
88
Vrios desenvolvedores
Diferentes equipes
Diferentes locais
Vrias iteraes, releases, produtos,

plataformas
Na ausncia de controle disciplinado,

o processo de desenvolvimento
rapidamente se transforma no caos!
89
Uma entidade que satisfaz algum

propsito para o usurio final e que
pode ser unicamente identificada
Podem ser
Arquivos-fonte, Executveis, DLLs, etc.
Planos, especificaes, modelos, etc.
Casos de teste, manuais, documentao
de apoio, etc.
Esto sob a Gesto da Configurao

90
Gerncia de Mudanas o processo

de avaliar, coordenar e decidir sobre
a realizao de mudanas propostas
a itens de configurao (ICs)
Apenas mudanas aprovadas so
implementadas nos ICs e nos
dados e documentos relacionados
91
No RUP, abrange as atividades de:
Coordenao de atividades e artefatos

Procedimentos repetveis para gerenciar
mudanas sobre os artefatos
Coordenao de iteraes e releases

Mantm o controle sobre os releases ao final
de cada iterao (baselines)
Controle de mudanas no software

Mantm uma estrutura bem definida para
gerenciar mudanas no software
92
(TRE/MT - CESPE 2010)

[32-B] O RUP promove o uso de seis melhores prticas:
desenvolva iterativamente; gerencie requisitos; use arquiteturas
de componentes; modele visualmente (UML); verifique
qualidade de software continuamente; e gerencie mudanas.
93
(BNDES - CESGRANRIO 2009)

[51] A gerncia de desenvolvimento de sistemas de uma
empresa est reformulando seu processo de software. Para
isso, deseja criar uma metodologia de desenvolvimento
baseada no Processo Unificado. A respeito desse processo,
INCORRETO afirmar que o(a)
(A) desenvolvimento iterativo, incremental e orientado por
casos de uso.
(B) caso de uso mais crtico deve ser atacado,
preferencialmente, no final.
(C) fase de transio envolve treinamento de usurios e
assistncia no uso do produto.
94
(D) arquitetura se desenvolve a partir das vises do usurio

expressas em casos de uso.
(E) arquitetura, na fase de construo, estvel, ainda que
possa ser evoluda.
95
96
Casos de Uso
Aps levantados os
principais requisitos
(fase de Iniciao),
por onde devo
comear?
UC001
UC002
UC003
UC004
UC005
UC006
Casos de Uso
arriscados
UC007
UC008
UC009
UC010
UC011
UC012
97
feita uma matriz,

que estabelece uma
relao entre a
importncia dos
requisitos e o quo
arriscados eles so
Risco
Importncia
UC001
UC002
UC003
UC004
UC005
UC006
UC007
10
10
UC008
UC009
UC010
UC011
UC012
10
98
Segundo o RUP, as funcionalidades mais

arriscadas e importantes devem ser
implementadas primeiro
Elas devem ser estabilizadas j nas iteraes da
fase de Elaborao
Ao final da fase de Iniciao, j existe o

planejamento (de alto nvel) do projeto feito
O detalhamento das funcionalidades feito apenas
para aquelas que sero feitas na prxima iterao
Este ciclo de re-planejamento se d ao longo

das iteraes, at o produto estar completo
99
[1] - [45] E, [27A] C, [109] C, [48] A, [80] C (E)
[2] - [76] C, [70] C
[3] - [72] E, [27 C] C, [80] E, [81] C, [86] E
[4] - [79] C, [32-C] E, [32-D] E, [32-E] E
[5] - [44-A] C, [44-C] E
[6] - [72] E
[7] - [62] C, [35-D] E
[8] - [108] E, [90] E
[9] - [53] E
[10] - [32-B] C, [51] B
100
101

01 - RUP - Conceitos

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

01 - RUP - Conceitos

Încărcat de

Drepturi de autor:

Formate disponibile

Introduo

Fernando Pedrosa fpedrosa@gmail.com

Fernando Pedrosa Lopes

Phillip Kruchten Rational Unified

Fernando Pedrosa Lopes

Criado por Booch, Jacobson e

Fernando Pedrosa Lopes

uma plataforma de processos

Fornece atividades, artefatos e guias

Fernando Pedrosa Lopes

Guiado por casos de uso

Planejado por riscos

Fernando Pedrosa Lopes

(CAIXA - CESPE 2010)

(PETROBRAS - CESGRANRIO 2008)

Fernando Pedrosa Lopes

O RUP tem duas dimenses

A segunda dimenso representa o

(SECONT/ES - CESPE 2010)

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Quem? O qu? Como? Quando?

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Cada fase termina com um Marco

Fernando Pedrosa Lopes

Cada passagem pela sequncia

Fernando Pedrosa Lopes

Cada fase pode ser dividida em

Fernando Pedrosa Lopes

(SERPRO CESPE 2010)

Fernando Pedrosa Lopes

(MPE/RR CESPE 2008)

[81] O Processo Unificado iterativo e incremental. Ao final de

Fernando Pedrosa Lopes

(ANATEL - CESPE 2006)

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Algumas disciplinas esto

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Papis executam Atividades que

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Cada disciplina tem uma viso geral dos

Fernando Pedrosa Lopes

(MPE/RR - CESPE 2008)

Fernando Pedrosa Lopes

[32-D] Um papel uma definio abstrata de um conjunto de

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Desenvolvimento Iterativo lida com

Busca melhor qualidade

Fernando Pedrosa Lopes

Incorporam um conjunto quase

Fernando Pedrosa Lopes

Com a abordagem em cascata, tudo

Fernando Pedrosa Lopes

Jogue fora um pouco do trabalho

Fernando Pedrosa Lopes