Upload
dinhdang
View
218
Download
0
Embed Size (px)
Citation preview
�1
Faculdade de Ciências e Tecnologia
Departamento de Matemática e Computação
Bacharelado em Ciência da Computação
Engenharia de Software II
Aula 07
Rogério Eduardo Garcia
Conceitos Básicos do Rational Unified Process
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
2
�2
Processo de Engenharia de Software
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
32
3/0
3/2
01
5R
og
éri
o E
du
ard
o G
arc
ia4
�3
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
52
3/0
3/2
01
5R
og
éri
o E
du
ard
o G
arc
ia6
Conteúdo
� RUP – Rational Unified Process
– Introdução
– Fase 1: Concepção
– Fase 2: Elaboração
– Fase 3: Construção
– Fase 4: Transição
�4
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
7
Introdução
� Processo de desenvolvimento de software criado pelaRational/IBM
� Baseado no ciclo de vida em espiral (refinamentos sucessivos)
� Guia para utilizar efetivamente a UML
– Desenvolvimento dirigido por Casos de Uso
� Processo configurável
� Aumento da produtividade da equipe
� Incentivo das boas práticas:
– desenvolver o software iterativamente,
– gerenciar requisitos,
– usar arquitetura baseada em componentes,
– modelar o software visualmente,
– verificar a qualidade do software,
– controlar as mudanças do software
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
8
O processo tem 4 fases:
Introdução
�5
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
9
Conceitos básicos
� Iteração
– Ciclo completo de desenvolvimento.
� Atividade
– Unidade de trabalho composta de objetivos,passos, entradas/saídas , responsáveis, guias epadrões.
� Fluxo de Atividade
– Agrupam atividades correlacionadas (fluxo desuporte, fluxo básico)
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
10
Conceitos básicos
� Artefato: documento, relatório, modelo, códigoou executável que é manipulado, produzido ouconsumido
� Responsáveis: representam perfis ou papéis(ex: gerente de projeto, analista,programador...)
� Stakeholder: cliente
� Milestone: ponto de controle
� O ciclo de vida é dividido em 4 fases e cadafase é dividida em iterações
�6
Principais Artefatos
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
11
Análise e Design: Visão Geral do Artefato
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
12
�7
Análise e Design: Visão Geral das Atividades
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
13
Papel: Designer de Negócios
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
14
�8
Detalhamento do Fluxo de Trabalho: Projetar Componentes
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
15
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
16
Conceitos básicos
� Fluxo de trabalho (núcleo)
– Modelagem de negócios
– Requisitos
– Análise e Projeto
– Implementação
– Teste
– Entrega (deployment)
� Fluxo de trabalho (suporte)
– Gerenciamento de versões e configurações
– Gerenciamento de projeto
– Ambiente
�9
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
17
Conceitos básicos
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
18
Conceitos básicos
Atividades e Modelos
�10
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
19
Conceitos básicos
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
20
Conceitos básicos
�11
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
21
O processo tem 4 fases:
Introdução
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
22
Concepção
� Objetivos
– Visa a entender o escopo geral do projeto e os seus
objetivos
– Colher informações sobre o que deve ser feito
– Decidir sobre a continuidade do projeto
�12
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
23
Atividades Essenciais
� Entender o que produzir
� Identificar os pontos chave do sistema
� Determinar no mínimo uma solução possível
� Planejar custos, agenda e riscos
� Decidir qual processo seguir e quaisferramentas
� OBS: Podem (devem) ser feitos em paralelo
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
24
Atividades Essenciais
� Todos devem ter o mesmo entendimentosobre o que será construído
� Passos:
– Validar uma Visão de alto nível
– Prover uma descrição “mile-wide, inch-deep” do
sistema
– Detalhar Atores e Casos de Uso
�13
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
25
Atividades Essenciais
� Produzindo uma Visão
– Descrição geral do sistema
– Deve Conter
� Benefícios da aplicação e oportunidades que a mesma
poderá gerar
� Os problemas que a mesma irá resolver
� Quem são os usuários-alvo
� Em termos gerais, o que a aplicação deverá fazer
� Requisitos não funcionais essenciais: SO e BD
suportados, escalabilidade, etc, além de licença e preço
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
26
Atividades Essenciais
� Gerando uma descrição “Mile-Wide, Inch-Deep”
– Identificar e descrever brevemente os atores e os
casos de uso
– Não entrar em detalhes
– Atenção especial para os casos de uso mais
importantes
– Gerado após Brainstorming ou Workshop
�14
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
27
Atividades Essenciais
� Brainstorms e Workshops
� 7 passos básicos
� Comum limitar tempo em cada etapa
– Passo 1: Identificar máximo de atores
– Passo 2: Associar cada ator com caso de uso
– Passo 3: Relacionar interações dos casos de uso
com outros atores ou sistemas
� Ao final é gerado diagrama de casos de uso
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
28
Atividades Essenciais
� 7 passos básicos (cont.)
– Passo 4: Fazer breves descrições de cada ator e
use cases
– Passo 5: Criar um glossário
– Passo 6: Revisar os casos de uso, baseado nas
relações do sistemas (com usuário ou outros
sistemas)
– Passo 7: Identificar os casos de uso essenciais ou
críticos
�15
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
29
Atividades Essenciais
� Detalhando Atores Chave e Casos de Uso
– Detalhar bastante os Atores e Casos de Uso
identificados no último passo do Brainstorm/
Workshop
– Gerar, em paralelo, um Protótipo
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
30
Atividades Essenciais
� Identificar os Casos de Uso mais essenciais oudeterminantes para a arquitetura a serselecionada: críticos
� Será gasto mais tempo nesses itens
� Critérios para seleção:
– Funcionalidade principal da aplicação e principaisinterfaces
– A funcionalidade DEVE ser entregue
– Funcionalidade cobre uma área da arquitetura nãocoberta por nenhum outro caso de uso principal
� Cerca de 20% de funcionalidades chave
�16
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
31
Atividades Essenciais
� Identificar pelo menos uma possívelarquitetura para o desenvolvimento
� Verificar o nível de risco e custo para utilizaçãodas arquiteturas identificadas
� Ex.: Cliente x Servidor
– 2 camadas: Aplicação Cliente e BD
– 3 Camadas: Browser + Webserver + BD
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
32
Atividades Essenciais
� Já foi entendido o que fazer
� Verificar a viabilidade
� Construir um Plano de Negócios para o projeto
– Contém os custos estimados, agenda e riscos do
projeto
– Documento de valor econômico/monetário
�17
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
33
Atividades Essenciais
� Escolha do método: Como o software serádesenvolvido
� Escolha das ferramentas a serem utilizadas
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
34
Milestone – Lifecycle Objective
� Ao fim da fase Concepção é gerado o primeiro
Milestone do projeto.
� Checar com os objetivos definidos inicialmente: Se
falhar, cancelar ou repensar o projeto
– Stakeholders validam a definição do escopo e custo/prazo
inicial
– Concordância sobre a correta obtenção e entendimento dos
requisitos do sistema
– Concordância com custo e prazo estimados, prioridades,
riscos e processo de desenvolvimento
– Concordância na identificação dos riscos iniciais e estratégias
para atenuá-los
�18
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
35
Milestone – Artefatos
� Visão
� Business Case
� Lista de Riscos
� Plano de Desenvolvimento de Software
� Plano de Iteração
� Development Case
� Ferramentas
� Glossário
� Entre outros...
Conjunto de Artefatos de Gerenciamento de Projeto
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
36
�19
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
37
O processo tem 4 fases:
Introdução
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
38
Elaboração – Objetivos
� Desenvolver a arquitetura do sistema
– Requisitos mais significantes
– Avaliação dos riscos
�20
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
39
Elaboração – Atividades Essenciais
� Obtenha uma compreensão detalhada dos requisitos.
– Casos de uso mais detalhados.
– Protótipos de interface validados pelo usuário.
– Glossário.
� Modele, implemente, valide e defina as linhas base da
arquitetura.
– Mais importantes blocos de construção, interfaces, decisões
de implementação e reuso.
– Descrição da interação dos blocos nos cenários mais
importantes
– Implementação e validação da arquitetura.
– Faça os casos de teste unitários
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
40
Elaboração – Atividades Essenciais
� Minimize os riscos essenciais e produza umaagenda mais precisa e estimativas de custo.
– requisitos detalhados.
– A implementação do esqueleto minimiza osproblemas mais difíceis.
– Os riscos já foram quase todos minimizados.
– Nessa fase a potencialidade da equipe e dasferramentas já pode ser avaliada
� Refine o Development Case e o coloque emuso.
– Esta etapa define o modo de usar o RUP.
�21
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
41
Elaboração – Primeira Iteração
� Modele, implemente e teste cenários críticos.
� Identifique e implemente alguns mecanismosarquiteturais.
� Faça um modelo preliminar da base de dados.
� Faça fluxos de eventos de metade dos casosde uso.
� Faça testes para identificar riscos arquiteturaise pequenas distorções
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
42
Elaboração – Segunda Iteração
� Conserte o que não estava correto na primeira iteração.
� Modele, implemente e teste os cenários arquiteturais maissignificantes remanescentes.
� Esboce e implemente concorrência, threads e distribuição físicapara identificar riscos de alta tecnologia.
� Modele, implemente e teste mecanismos arquiteturais novos.
� Modele e implemente uma versão preliminar da base de dados.
� Faça a outra parte dos fluxos de evento com os casos de uso quefaltavam.
� Teste, valide e refine o modelo da arquitetura. Faça outrasinterações até que este modelo esteja estável.
�22
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
43
Elaboração - Milestone – Lifecycle Architecture
� A visão do sistema e os requisitos estão estáveis?
� A arquitetura está estável?
� As abordagens de teste e avaliação estão providas?
� Os testes e avaliações de protótipos provam que os
grandes riscos estão identificados e resolvidos?
� Os planos de iteração da Construção estão detalhados
e fiéis para prover o trabalho ocorra?
� Todos os stakeholders concordam com a Visão
corrente?
� Os custos da aplicação estão de acordo com os
recursos disponíveis?
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
44
Elaboração - Artefatos
� Protótipos
� Lista de Risco
� Development Case
� Ferramentas
� Documento de Arquitetura
� Visão
� Plano de desenvolvimento de software
� Entre outros...
�23
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
45
O processo tem 4 fases:
Introdução
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
46
Construção - Objetivo
� Minimizar custos de desenvolvimento
� Alcançar um determinado grau de paralelismode desenvolvimento
� Desenvolver iterativamente um produtocompleto que esteja pronto para a transição
�24
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
47
Construção – Atividades Essenciais
� Descrever Casos de Uso remanescentes
� Completar o projeto de componentes esubsistemas
� Completar o projeto do banco de dados
� Implementar e fazer testes de unidade
� Integração e testes do sistema
� Feedback dos clientes
� Prerelease e versão final do sistema
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
48
Construção - Iterações
� Geralmente de 2 a 4
� Plano de iteração guiado pelos casos de uso
� Implementar os casos de uso mais importantespara os clientes
� Procurar eliminar os maiores riscos
� Identificar e implementar os componentes queprecisam colaborar para prover asfuncionalidades
�25
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
49
Construção – Milestone – Initial Operational Capability
� O produto é estável e maduro o suficiente paraser implantado na comunidade do usuário?
� Todos os clientes estão prontos para atransição?
� Os recursos atuais despendidos são coerentescom os previstos?
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
50
Construção – Artefatos
� O sistema
� Plano de implantação
� Conjunto de testes aplicados
� Material de treinamento
� Modelo de Implementação
� Modelo de Dados
�26
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
51
O processo tem 4 fases:
Introdução
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
52
Transição - Objetivos
� Validar o sistema de acordo com aespecificação do usuário
� Treinar usuários e mantenedores
� Preparar o local de implantação
� ...
� Assegurar disponibilidade do software paraos usuários finais
�27
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
53
Transição - Atividades Essenciais
� Executar planos de deployment
� Finalizar material de suporte ao usuário
� Testar, no ambiente de desenvolvimento, oproduto pronto para entrega
� Gerar release do produto (beta)
� Coletar informações de feedback do usuário
� Ajustar o produto de acordo com o feedback
� Disponibilizar o produto para os usuários finais
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
54
Transição - Plano de Iteração
�28
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
55
Transição - Plano de Iteração
� Requisitos, análise e projeto
� Requisitos estáveis (frozen)
� Alterações entendidas e controladas
� Análise e projeto: integridade arquitetural
� Implementação
� Base no feedback (correção de defeitos)
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
56
Transição – Milestone: Product Release
� Critérios:
� O usuário está satisfeito?
� Os recursos que o sistema está utilizando sãoaceitáveis de acordo com o planejadoanteriormente?
�29
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
57
Transição – Artefatos
� Essenciais:
– Produto
– Notas de release
– Artefatos de instalação
– Material para treinamento
– Material de suporte ao usuário final
Elementos Básicos
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
58
�30
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
59
O processo tem 4 fases:
Revisando...
23
/03
/20
15
Ro
gé
rio
Ed
ua
rdo
Ga
rcia
60
Bibliografia
� KROLL, P. and KRUNCHTEN, P. The RationalUnified Process Made Easy: A Practitioner'sGuide to the RUP, Addison-WesleyProfessional, April, 2003
� Site do RUP� http://www-01.ibm.com/software/br/rational/rup.shtml