�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

(rogerio@fct.unesp.br)

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