RUP Fases, Disciplinas e Atividades

Fases, Disciplinas e Atividades
Fernando Pedrosa fpedrosa@gmail.com
Fernando Pedrosa Lopes
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
Eixo
dinmico
Eixo
esttico
So quatro fases sequenciais, cada uma

concluda por um marco principal
Cada fase basicamente um intervalo de
tempo entre dois marcos principais
As fases no so idnticas em termos de

programao e esforo
Uma passagem pelas quatro fases um

ciclo de desenvolvimento
As prximas geraes do produto tm
nfase em fases diferentes e so geradas
por ciclos de evoluo
Meta principal: atingir o consenso

sobre os objetivos do ciclo de vida do
projeto
Muito importante para projetos novos
Para projetos evolutivos, uma fase mais
rpida
Compensa fazer o projeto?

possvel fazer o projeto?
10
Estabelecer o escopo do Software

Estimar custos
Estimar tempo (cronograma)
Estimar riscos
Identificar casos de uso crticos e
principais cenrios operacionais
Propor pelo menos uma opo de
arquitetura para alguns cenrios
bsicos
11
Viso
Necessidades e caractersticas mais
importantes do sistema
Caso de Negcio
Informaes do ponto de vista do negcio
Determina se vale a pena investir no
projeto (ROI)
Plano de Desenvolvimento de Software

Rene todas as informaes necessrias
ao gerenciamento do projeto
12
Modelo de Casos de Uso

Contm as funes pretendidas do
sistema
Serve como um contrato estabelecido
entre os clientes e os desenvolvedores
Glossrio
Define termos importantes usados pelo
projeto
13
14
Entender a estrutura e a dinmica da

organizao-alvo, identificando
oportunidades de melhoria
Assegurar que todos os interessados
tenham um entendimento comum
sobre a organizao
Derivar os requisitos de sistema
necessrios para sustentar a
organizao-alvo
15
Principal Papel e suas Atividades

Analista de Processo de Negcios
Identificar os processos na organizao

Descrever os processos
Definir o que pode e deve ser melhorado
Redesenhar os processos, se necessrio
Artefato importante para o marco

Modelo de Domnio (modelo de objetos de
negcio)
16
Captura os tipos mais importantes de

objetos no contexto de domnio
Sistema de Check-in
17
Requisitos
Utiliza modelos de negcio como subsdio
para entender os requisitos do sistema
Anlise e Design
Utiliza entidades de negcio para
identificar classes de entidade no projeto
Ambiente
Desenvolve e mantm artefatos de
suporte, como o Guia de Modelagem de
Negcios
18
19
Estabelecer o que o sistema deve fazer

Definir as fronteiras (escopo) do
sistema
Fornecer uma base para planejar o
contedo tcnico das iteraes
Fornecer uma base para estimar o
custo e o tempo de desenvolvimento
do sistema
20
Principais Papeis e Atividades

Analista de Sistemas
Levantar Requisitos do Sistema (Atores e CDUs)
Estruturar Modelo de Casos de Uso
Especificador de Requisitos
Detalhar Especificao de Casos de Uso
Artefatos importantes para o marco

Viso
Glossrio
Modelo de Casos de Uso
21
Modelo das funes pretendidas do

sistema. Serve como contrato entre o
cliente e desenvolvedores.
Sistema de
Mquina de Reciclagem
22
o documento que define a viso que

os envolvidos tm do produto a ser
desenvolvido
Contm as necessidades e
caractersticas mais importantes do
sistema
Fornece uma base de alto nvel para
que o leitor possa compreender o
sistema a ser desenvolvido
23
Modelagem de Negcios
Fornece as regras de negcio e um
contexto organizacional para o sistema
Anlise e Design
Obtm suas informaes primrias dos
Requisitos. Pode encontrar falhas nos
modelos de Caso de Uso
Teste
Valida o sistema com base nos casos de
uso
24
Gerenciamento de Configurao e
Mudana
Fornece o mecanismo de controle para as
mudanas nos requisitos
Gerenciamento de Projeto
Usa o modelo de casos de uso para
planejar as iteraes
Ambiente
Desenvolve e mantm os artefatos
utilizados na disciplina de Requisitos
25
o primeiro marco mais importante

do projeto
Critrios de avaliao
Os casos de uso definem claramente o

escopo?
Caso necessrio, foi possvel fazer um
prottipo da arquitetura?
Todos os riscos crticos foram
encontrados? Se sim, foram mitigados?
H condies de se fazer o projeto?
26
(BASA - CESPE 2007)

[53] Na fase de concepo (inception), h atividades voltadas para a
definio do escopo do sistema, identificao de atores e casos de
uso, definio de vocabulrio que possa ser usado nas descries
textuais do sistema, e definio de uma arquitetura candidata para o
sistema que est sendo desenvolvido.
(Min. Comunicaes - CESPE 2008)
[72] So objetivos da fase de concepo (inception): preparar ambiente
para o projeto; elaborar plano para o projeto; definir escopo do
sistema; identificar atores e casos de uso; identificar as necessidades
dos stakeholders; definir nveis de prioridade dos casos de uso; propor
arquitetura candidata; e definir objetivos do esforo de teste.
27
(CGU - ESAF 2008)

[22] No Processo Unificado (PU), o termo Modelo de Domnio significa
uma representao visual de classes conceituais ou objetos do
mundo real. Assinale a opo que apresenta uma afirmativa
correta quanto ao Modelo de Domnio.
A) No trata da representao de objetos de software.
B) Significa um conjunto de diagramas que descreve classes de
software.
C) Representa a camada de domnio de uma arquitetura de
software.
D) Representa objetos de software com responsabilidades.
E) Aplicando a notao UML, ilustrado como um conjunto de
diagramas de classe em que so definidas as operaes.
28
(Sergipe Gs - FCC 2010)

[31] No Processo Unificado, o Modelo de Domnio um
a) diagrama de classes em nvel de anlise.
b) diagrama de classes em nvel de desenho.
c) produto da modelagem de negcios e, como tal, captura o
vocabulrio do sistema ou negcio sob modelagem.
d) modelo que carrega todo o detalhamento do comportamento e
estrutura, que devem estar presentes em um modelo de anlise.
e) modelo de domnio que carrega informaes de armazenamento de
informaes ou normalizaes, que devem estar presentes em um DER
29
30
31
32
A meta principal da fase de Elaborao

fornecer uma base estvel para o
esforo de Construo
A arquitetura desenvolvida a partir
dos requisitos que tm maior impacto
na arquitetura
A estabilidade da arquitetura
avaliada atravs de um ou mais
prottipos de arquitetura
33
Assegurar que a arquitetura e os requisitos

estejam estveis para mitigar riscos
Ultrapassar esta marca significa passar de uma
operao rpida e de baixo risco para uma
operao de alto custo e alto risco
Tratar todo os riscos significativos do ponto

de vista da arquitetura do projeto
Selecionar componentes e criar planos de
iteraes detalhados para a fase de
Construo
34
Prottipos
So usados de uma maneira direta para
reduzir o risco e elicitar requisitos
significativos.
Documento de Arquitetura de
Software
Fornece a viso geral de arquitetura
abrangente do sistema, usando diversas
vises de arquitetura para descrever
diferentes aspectos do sistema.
35
Modelo de Projeto
um modelo de objeto que descreve a
realizao dos casos de uso e serve como
uma abstrao do modelo de
implementao e seu cdigo-fonte.
Modelo de Dados
um subconjunto do modelo de
implementao que descreve a
representao lgica e fsica dos dados
persistentes no sistema.
36
37
Transformar os requisitos em um
projeto do sistema a ser criado
Desenvolver uma arquitetura refinada
para o sistema
Adaptar o projeto para que
corresponda ao ambiente de
implementao, considerando
restries de tecnologia
38
Principais Papeis e atividades

Arquiteto de Software
Projetar arquitetura
Designer (Projetista)
Analisar casos de uso
Projetar casos de uso
Projetar subsistemas
Projetista de Banco de Dados

Projetar base de dados
39

Prottipos
Quanto ao que exploram:
Comportamentais
Estruturais
Quanto ao seu resultado:

Exploratrios (ou de descarte)
Evolutivos
Documento de Arquitetura de Software

Modelo de Design
40
Modelo que
descreve as
realizaes dos
casos de uso e
serve como uma
abstrao do
modelo de
implementao
41
Modelagem de negcio
Fornece o contexto organizacional para o
sistema
Requisitos
Fornece a viso das funcionalidades
crticas a serem implementadas
Teste
Testa o sistema projetado durante a
disciplina de Anlise e Design
Ambiente, Gerenciamento de Projeto

42
o segundo marco mais importante do

projeto. Deve-se analisar a arquitetura
executvel e a resoluo dos principais
riscos
Critrios de Avaliao
A arquitetura estvel e robusta, comportando
requisitos atuais e futuros?
Riscos crticos foram resolvidos?
O planejamento est bem definido em termos de
cronograma, oramento e nveis de qualidade?
Devemos fechar o contrato?
43
(SERPRO - CESPE 2010)

[73] No modelo RUP, a primeira linha de base da arquitetura de um
software produzida ao final da fase de elaborao.
(ISJN - CESPE 2010)
[57] Modelo de domnio, descrio da arquitetura de software e verso
preliminar do manual so resultados-alvo da fase elaborao do RUP.
[54] Na fase de elaborao, muitos componentes do sistema so
implementados, testados e integrados. Essas atividades, que partem
de uma arquitetura definida, validada e implementada em fases
anteriores do ciclo de desenvolvimento, produzem um sistema
operacional pronto para ser instalado em um ambiente em que sero
feitos testes beta.
44
(PETROBRAS - CESGRANRIO 2010)

[39] A anlise de risco no RUP algo constante nas diversas fases do
processo de desenvolvimento. Em cada uma das fases, o foco da
gerncia de riscos se diferencia em funo do objetivo de cada fase.
Assim, a manipulao dos riscos est relacionada, na fase de
(A) anlise, ao refinamento do modelo de requisitos e sua possvel
alterao.
(B) construo, instalao e distribuio do produto no ambiente do
cliente.
(C) transio, logstica, uma vez que a fase que envolve o maior
nmero de profissionais.
(D) requisitos, modelagem de negcio.
(E) elaborao, a questes tcnicas, envolvendo a arquitetura
escolhida.
45
46
47
48
Esclarecer os requisitos restantes

Concluir o desenvolvimento do
sistema com base na arquitetura
estvel
, de certa forma, um processo de
manufatura
A nfase est no gerenciamento de
recursos e controle de operaes para
alcanar maior produtividade e
qualidade
49
Minimizar custos de desenvolvimento,

otimizar recursos e evitar retrabalho
Atingir as verses teis (alfa, beta e
outros releases de teste) com rapidez
Concluir
a anlise, o projeto, o
desenvolvimento e o teste de todas as
funcionalidades necessrias.
Decidir se o software est pronto para
ser implantado
50
O Sistema
O prprio sistema executvel, pronto para iniciar
os testes beta
Plano de Implantao
Verso inicial desenvolvida, analisada e com
baseline
Em projetos menores pode estar embutido no
Plano de Desenvolvimento do Software
Conjunto de testes
Testes implementados e executados para validar
a estabilidade dos releases
51
52
Definir o cdigo em subsistemas e

camadas
Implementar classes e objetos em
termos de componentes
Testar os componentes desenvolvidos
como unidades
Integrar os resultados produzidos por
implementadores individuais (ou
equipes) ao sistema executvel
53

Implementador
Implementar componente
Realizar testes unitrios
Integrador
Integrar o sistema

O Sistema
Componentes
Builds
54
Anlise e Design
Representa o propsito da implementao, sendo o
Modelo de Design a principal entrada desta
disciplina
Teste
Descreve como realizar o teste de integrao de
cada build
Descreve tambm como testar o sistema
Implantao
Descreve como usar o modelo de implementao
para produzir e liberar o cdigo para o cliente final
Ambiente, Gerenciamento de Projeto

55
56
Localizar e documentar defeitos na

qualidade do software
Validar
as suposies feitas nas
especificaes de design e requisito
atravs de demonstrao concreta
Validar
as funes do software
conforme projetadas
Verificar
se os requisitos foram
implementados de forma adequada
57

Analista de Teste
Elaborar plano de testes
Projetista de Teste
Projetar testes
Testador
Implementar teste
Executar Testes

Conjunto de testes
58
Requisitos
Os casos de uso fornecem a base para o que vai ser
testado na disciplina de Teste
Anlise e Design
Fornece o projeto a ser testado pela disciplina de
Teste
Implementao
Produz os builds do software que sero validados
pelos testes
Ambiente, Gerenciamento de Projeto,

Gerenciamento de Configurao e Mudanas
59
Neste marco, o produto est pronto para

ser passado para a Equipe de Transio.
Toda a funcionalidade j foi desenvolvida e
todos os testes alfa foram concludos.
O manual do usurio produzido e uma
existe uma descrio do release atual
Critrios de avaliao
O produto est estvel para ser implantado?
O resultado est coerente com o planejado?
Os envolvidos esto prontos para a Transio?
60
(PETROBRAS - CESPE 2007)

[98] Na fase de construo, so implementados os casos de uso que
tenham impacto sobre a arquitetura; na fase de transio, os casos
sem impacto sobre a arquitetura, mas que descrevam funcionalidades
que devero estar presentes na verso que est sendo desenvolvida.
(PGE/PA - CESPE 2007)
[34] Na disciplina de teste, entre os artefatos que podem ser
produzidos, tem-se o plano de teste. O plano de teste pode definir os
objetivos dos testes no escopo de uma iterao ou do projeto, os itens
a serem testados e as abordagens dos testes.
61
(Min. Comunicaes - CESPE 2008)

[73] A fase de construo (construction) tem os seguintes objetivos:
detalhar casos de uso e requisitos do software; refinar a arquitetura
proposta e demonstrar que essa arquitetura suporta os requisitos do
sistema; testar e avaliar prottipos visando demonstrar que os
principais riscos foram avaliados; e construir prottipos executveis
para a avaliao da arquitetura proposta.
62
63
64
65
O foco da fase de Transio disponibilizar

o software aos usurios finais
Pode atravessar vrias iteraes e inclui
testar os releases e ajustar pequenos
defeitos com base no feedback do usurio
O feedback prioriza apenas ajustes finos
todos os problemas estruturais mais graves
devem ter sido trabalhados muito antes no
ciclo de vida do projeto
Pode ser uma fase muito fcil ou muito
complexa, dependendo do tipo do produto
66
Teste beta para validar o novo sistema

Treinamento de usurios e equipe de
manuteno
Atividades de ajuste, como correo
de erros, melhoria no desempenho e
na usabilidade.
Consentimento dos envolvidos que o
software implantado atende a viso
inicial
67
Notas de Release
Artefatos de instalao
Material de treinamento
68
69
Coordenar e gerenciar os testes beta e

de aceitao
Desenvolver artefatos de instalao e
materiais de treinamento
Liberar para fabricao
H trs tipos de instalao

a instalao personalizada
o produto em uma forma "compacta"

acesso ao software por meio da Internet
70

Gerente de Implantao
Desenvolver plano de implantao
Escrever notas de release
Desenvolver do curso
Desenvolver materiais de treinamento
Implementador
Desenvolver artefatos de instalao
71

O Build do produto
Notas de Release
Artefatos de instalao
Material de treinamento
72
Requisitos
As especificaes de requisitos constituem
a principal fonte para a elaborao de
materiais de suporte e treinamento para o
usurio final
Teste
Os testes so indispensveis para a
implantao do sistema
Ambiente, Gerenciamento de Projeto,

Ger. de Configurao e Mudanas
73
Neste marco, voc decide se os

objetivos foram atendidos e se outro
ciclo de desenvolvimento deve ser
iniciado
Critrios de avaliao
As despesas reais com recursos so

aceitveis se comparadas s planejadas?
O usurio est satisfeito?
74
(CGU - ESAF 2008)

[25] No RUP (Rational Unified Process), dois dos exemplos dos
artefatos de Implantao so:
A) Guia de design e Arte final do produto.
B) Material de suporte para o usurio e Guia de teste.
C) Plano de implantao e Manual de guia de estilo.
D) Notas de release e Materiais de treinamento.
E) Artefatos de Instalao e Guia de ferramentas.
75
76
Controla mudanas feitas nos artefatos de

um projeto e mantm a integridade entre
eles
77
Identificar e controlar itens de

configurao
Restringir as mudanas nesses itens
Auditar as mudanas nesses itens
Evitar confuses de:

Atualizao simultnea
Notificao limitada
Vrias verses
78
Preservao da estabilidade e
integridade do produto
Suporte a mtodos de desenvolvimento
Restrio das mudanas feitas nos
artefatos com base nas polticas do
projeto
Trilha de auditoria indicando por que,
quando e por quem um artefato foi
alterado
79

Gerente Configurao
Configurar ambiente de CM
Estabelecer polticas de CM
Gerente de Mudanas
Estabelecer processo de controle de mudanas

Confirmar ou recusar CR
Principais artefatos
Repositrio do projeto
Solicitaes de mudanas
80
81
Gerenciar pessoas, equipes fases e

iteraes para executar e monitorar o
projeto
Planejar o cronograma do projeto
Gerenciar a qualidade e realizar
revises
Gerenciar os riscos do projeto
82
No cobre problemas como:

Gerenciamento de Pessoal: contratao,
treinamento, ensino
Gerenciamento de Oramento: definio,
alocao, etc.
Gerenciamento de contratos com
fornecedores e clientes
para isso que temos o PMBOK!
83

Gerente de Projeto
Planejar Fases e Iteraes
Identificar e Avaliar Riscos
Monitorar o Projeto e Resolver Problemas
Plano de Desenvolvimento de Software

Planos de Iterao
Lista de Riscos
84
85
Configurar o processo para o projeto
Selecionar e adquirir ferramentas
Desenvolver ou adaptar templates

especficos para o projeto
Desenvolver ou adaptar guias de
atividades
Oferecer organizao o ambiente de
desenvolvimento de software que dar
suporte equipe de desenvolvimento.
86

Engenheiro de Processo
Configurar o processo
Iniciar Caso de Desenvolvimento
Especialista em Ferramentas
Selecionar, adquirir e configurar ferramentas
Caso de Desenvolvimento
87
Descreve o processo de desenvolvimento

escolhido para ser seguido no projeto
A finalidade capturar o processo
adaptado para o projeto individual
criado no incio da fase de Iniciao e
atualizado durante todo o projeto
medida que o projeto progride, voc

adiciona mais disciplinas a cada iterao
o documento que configura o prprio

processo de desenvolvimento
88
(IJSN - CESPE 2010)

[55] Na disciplina gerncia de configurao e mudanas do RUP
(rational unified process), garantir a integridade dos artefatos
relacionados ao projeto de software funo da gerncia de
solicitao de mudanas.
89
(TJ/SE - FCC 2009)

[54] De acordo com o RUP, balancear objetivos, administrar
riscos e superar restries para entregar um produto que
atenda s necessidades de clientes e usurios papel do
(A) Gerente de Projetos.
(B) Analista de Sistemas.
(C) Administrador de Dados.
(D) Analista de Requisitos.
(E) Arquiteto de Software.
90
(BNDES - CESGRANRIO 2008)

[1] Considerando o processo de desenvolvimento de software
unificado, associe cada produto de trabalho com a fase em que deve
Ser realizado. Marque a opo que ilustra a associao correta.
a) I-P, II-S, III-R, IV-P, V-Q
b) I-P, II-S, III-Q, IV-P, V-Q
c) I-P, II-R, III-Q, IV-P, V-R
d) I-Q, II-R, III-Q, IV-P, V-R
e) I-Q, II-S, III-R, IV-Q, V-S
91
[1]
[2]
[3]
[4]
[5]
53
73
98
25
55
C, 72 C, 22 A, 31 C
C, 57 E, 54 E, 39 E
E, 34 C, 73 E
D
E, 54 A, 1 A
92
93

RUP Fases, Disciplinas e Atividades

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

RUP Fases, Disciplinas e Atividades

Diunggah oleh

Hak Cipta:

Format Tersedia

Fases, Disciplinas e Atividades

Fernando Pedrosa fpedrosa@gmail.com

Fernando Pedrosa Lopes

O RUP tem duas dimenses

A segunda dimenso representa o

Fernando Pedrosa Lopes

So quatro fases sequenciais, cada uma

Fernando Pedrosa Lopes

As fases no so idnticas em termos de

Fernando Pedrosa Lopes

Uma passagem pelas quatro fases um

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Meta principal: atingir o consenso

Compensa fazer o projeto?

Fernando Pedrosa Lopes

Estabelecer o escopo do Software

Fernando Pedrosa Lopes

Plano de Desenvolvimento de Software

Modelo de Casos de Uso

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Entender a estrutura e a dinmica da

Fernando Pedrosa Lopes

Principal Papel e suas Atividades

Identificar os processos na organizao

Artefato importante para o marco

Fernando Pedrosa Lopes

Captura os tipos mais importantes de

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Estabelecer o que o sistema deve fazer

Fernando Pedrosa Lopes

Principais Papeis e Atividades

Detalhar Especificao de Casos de Uso

Artefatos importantes para o marco

Modelo das funes pretendidas do

Fernando Pedrosa Lopes

o documento que define a viso que

Fernando Pedrosa Lopes

o primeiro marco mais importante

Os casos de uso definem claramente o

(BASA - CESPE 2007)

Fernando Pedrosa Lopes

(CGU - ESAF 2008)

Fernando Pedrosa Lopes

(Sergipe Gs - FCC 2010)

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

A meta principal da fase de Elaborao

Fernando Pedrosa Lopes

Assegurar que a arquitetura e os requisitos

Tratar todo os riscos significativos do ponto

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Fernando Pedrosa Lopes

Principais Papeis e atividades

Projetista de Banco de Dados

Fernando Pedrosa Lopes