RUP - professor.pucgoias.edu.brprofessor.pucgoias.edu.br/.../17315/material/Aula_RUP.pdf · •O ciclo de vida de software do RUP é dividido em quatro fases seqüenciais: ... –À

RUP

Prof. Elias FerreiraElaborado por: Prof. Edison A M Morais

2

Agenda

• Definir Processo Unificado (UP)

• Definir RUP

• Comparar UP x RUP

• Mostrar as Variações do RUP

• Mostrar o Ciclo de Vida do RUP

3

O Processo Unificado Unified Process (UP)

• Proposto por Booch, Jacobson e

Rumbaugh.

• Descende de métodos anteriores (OOSE

e OMT).

• Utiliza a UML como como notação.

• Suas principais características são:

Mais Informações: Página 101, Ref. [1] e Ref. [2]

4

Processo Unificado Principais Características

• Dirigido por Casos de Uso (Use Case Driven);

• Centrado na arquitetura;

– Arquitetura definida nas fases iniciais.

• Iterativo

– Repetição de etapas similares.

• Incremental

– Cada iteração acrescenta uma nova funcionalidade ao produto.


5

Processo Unificado da Rational Rational Unified Process (RUP)

• É um produto comercial, produzido pela Rational (IBM), baseado no UP.

• RUP e UP possuem estruturas diferentes;

– Utilizam as mesmas fases;

– Possuem atividades diferentes (com nomes diferentes)

• UP – Fluxo de Trabalho ou Workflow

• RUP - Disciplinas


6

UP X RUP

• WorkFlow UP

Requisitos Obter os requisitos do produto.

Análise Detalhar, estruturar e validar os requisitos.

Desenho Formular um modelo estrutural do produto.

Implementação Desenvolver o código.

Testes Verificar o que foi implementado.


7

UP X RUP

• Disciplinas RUP

Mais Informações: Página 101, Ref. [1].

8

Variações do RUP

• RUP 7.5 Português

– Para projetos maiores e menores

– Aproximadamente 120 MB

• OpenUp

– Disponível On Line

– http://www.wthreex.com/rup/OpenUP/index.htm

Mais Informações: Ref. [3]

http://www.wthreex.com/rup/OpenUP/index.htm

9

OpenUP

• É um Processo Unificado;

• Aplica uma abordagem iterativa e incremental dentro de um ciclo de vida estruturado;

• Abraça uma filosofia pragmática e ágil que foca na natureza colaborativa do desenvolvimento de software;

• É um processo independente de ferramenta que pode ser utilizado para vários tipos de projeto.

Mais Informações: http://www.wthreex.com/rup/OpenUP/index.htm


10

OpenUP

Mais Informações: http://www.wthreex.com/rup/OpenUP/index.htm


11

Processo Unificado da Rational Rational Unified Process (RUP)

• O que é o RUP?

• Quem deve utilizar o RUP?

• Como configurar o RUP para seu projeto?


12

RUPO que é o RUP?

• É um Processo de Desenvolvimento de Software


13

RUPO que é o RUP?

• É um conjunto de Filosofias e Princípios para Desenvolvimento de

Software Bem-sucedido.

– 1. Visão: Desenvolver uma Visão

– 2. Plano: Gerenciar para o Plano

– 3. Riscos: Mitigar Riscos e Rastrear Problemas Relacionados

– 4. Caso de Negócios: Examine o Caso de Negócios

– 5. Arquitetura: Projete uma Arquitetura de Componente

– 6. Protótipo: Progressivamente Construir e Testar o Produto

– 7. Avaliação: Acessar Resultados Regularmente

– 8. Controle de Mudanças: Gerenciar e Controlar Alterações

– 9. Suporte ao Usuário: Implementar um Produto Utilizável

– 10. Processo: Adotar um Processo que se Ajuste ao Projeto (seja

configurável)


14

RUPQuem deve utilizar o RUP?

• Principalmente empresas que precisam

desenvolver software ITERATIVAMENTE.

• O que é Desenvolvimento Iterativo?

• Veja bem, não é Interativo!


15

RUPDesenvolvimento Iterativo

• É uma maneira mais flexível (e menos arriscada) de continuar é percorrer várias vezes as diversas disciplinas de desenvolvimento;

• Benefícios:– Construir um melhor entendimento dos requisitos;

– Planejar uma arquitetura robusta, o que eleva a organização do desenvolvimento;

– Libera uma série de implementações que são gradualmente mais completas.


16


• Principais Características

– Do ponto de vista do desenvolvimento, o ciclo de vida do

software é uma sucessão de iterações, por meio das quais o

software se desenvolve de maneira incremental.


A cada passagem, a seqüência de disciplinas do processo chama-se iteração.

17


• ITERAÇÃO

– Abrange as atividades de desenvolvimento

que conduzem à liberação de um produto

– Produto:

• Uma versão do produto estável e executável

• Qualquer outro elemento periférico necessário

para usar esse release.


+

18


• RELEASE

– É uma versão do produto

– Não é necessariamente um produto

completo.

– Uma das funções dos releases é forçar a

equipe de desenvolvimento a fazer

fechamentos em intervalos regulares.


19


• Duração da Iteração

– Varia de acordo com o tamanho e a natureza

do projeto.

– Durante a Iteração vários Builds podem ser

construídos:

– Build

• Subconjunto testável dos recursos e funções em

tempo de execução do sistema.

• Por que isso é importante?


+

20


• Importância dos Builds– Quando os componentes testados da unidade ficam

disponíveis, eles são integrados;

– Em seguida, um build é produzido e fica sujeito ao teste de integração.

– Dessa maneira, a capacidade do software integrado cresce quando a iteração continua em direção às metas definidas quando a iteração foi planejada.


21


• Importância dos Builds

– Pode ser apropriado e conveniente em alguns

projetos construir builds diariamente, mas eles não

representam iterações no RUP (talvez, para um

projeto muito pequeno de uma única pessoa).

– Mesmo em projetos pequenos com várias pessoas

(por exemplo, envolvendo cinco pessoas criando

10.000 linhas de código), seria muito difícil alcançar

uma duração de iteração de menos de uma

semana.


22


• Observações Importantes:

– Cada iteração termina com a liberação de um produto

executável, que pode ser um subconjunto da visão

completa, mas mesmo assim ser útil do ponto de

vista da engenharia ou do usuário.

– Cada release deve ser acompanhado de artefatos de

suporte:

• descrição do release, documentação do usuário, planos etc.,

bem como modelos atualizados do sistema.


23


• Consequência

– Os conjuntos de

artefatos

crescem e

amadurecem o

tempo todo:


24

RUPComo configurar o RUP para seu projeto?

• Não tente "executar" todo o RUP ao mesmo tempo.

• Inicie avaliando o processo existente e selecionando uma ou duas áreas-chave que você gostaria de aprimorar.

• Comece utilizando o RUP para aprimorar primeiro essas áreas e, depois, em iterações ou ciclos de desenvolvimento posteriores, fazer aprimoramentos incrementais em outras áreas.

• Siga o CICLO DE VIDA definido pelo RUP.


25

RUPCiclo de Vida

• O ciclo de vida de software do RUP é dividido

em quatro fases seqüenciais:

– Cada uma concluída por um marco principal, ou seja,

cada fase é basicamente um intervalo de tempo entre

dois marcos principais.

– À cada final de fase, uma avaliação é executada para

determinar se os objetivos da fase foram alcançados.

Uma avaliação satisfatória permite que o projeto

passe para a próxima fase.

Mais Informações: Ref. [3], Item Ciclo de Vida do RUP

26

RUPCiclo de Vida


27

RUPCiclo de Vida, Iterações e Releases


28

RUPCiclo de Vida de Evolução

• É uma passagem pelas quatro fases é um ciclo de desenvolvimento;

• Cada passagem produz uma geração do software;

• A cada nova passagem repete-se a mesma seqüência de fases, mas agora com ênfase diferente nas diversas fases;

• Esses ciclos subseqüentes são chamados ciclos de evolução.


29

RUPCiclos de Evolução


30

RUPCiclo de Vida de Evolução

• Os ciclos de evolução podem ser disparados por:– melhorias sugeridas pelos usuários;

– mudanças no contexto do usuário;

– mudanças na tecnologia;

– reação à concorrência, etc.

• Normalmente, os ciclos de evolução têm fases de Iniciação e Elaboração bem menores, pois a definição e a arquitetura básicas do produto foram determinadas pelos ciclos de desenvolvimento anteriores. – São exceções a essa regra os ciclos de evolução, em que

ocorre uma redefinição significativa do produto ou da arquitetura.

• Mas qual esforço geralmente gasto em cada fase?


31

RUPFases do Ciclo de Vida

• Esforço x Tempo

• Recurso x Tempo

Comportamento Típico para

Projetos de Tamanho Médio


32


• Esta distribuição pode variar. Por exemplo:– Utilização de ferramentas que gerem código e

etapas de teste podem diminuir a fase de construção.

– Para um ciclo de evolução do produto, as fases de iniciação e de elaboração seriam consideravelmente menores, já que uma visão e arquitetura básicas já estão estabelecidas.

• E como “conduzir” o ciclo de vida?


33


• Existem diversos Padrões de Iteração

– Ciclo de Vida Incremental

– Ciclo de Vida Evolutivo

– Ciclo de Vida Entrega Incremental

– Ciclo de Vida Design Principal

(Grande)

– Estratégias Híbridas


34


• Padrão de Ciclo de Vida Incremental

– "A estratégia incremental determina as

necessidades do usuário e define os

requisitos do sistema e, em seguida,

desempenha o restante do desenvolvimento

em uma seqüência de construções. A

primeira construção incorpora partes dos

recursos planejados, a próxima construção

inclui mais recursos e assim por diante até o

sistema estar completo"


35


• Padrão Incremental na Prática– Uma iteração curta de Iniciação para estabelecer:

• Escopo, visão e caso de negócio.

– Uma única iteração de Elaboração, durante a qual:• Os requisitos são definidos e a arquitetura estabelecida.

– Várias iterações de Construção durante as quais:• Os casos de uso são realizados e a arquitetura é

aprimorada.

– Várias iterações de Transição para:• Migrar o produto para a comunidade de usuários.


36


• Padrão Incremental na Prática


37


• Padrão Incremental – Quando Usar?

– O domínio do problema é familiar.

– Os riscos são bem entendidos.

– A equipe do projeto é experiente.


38


• Padrão de Ciclo de Vida Evolutivo

– "A estratégia evolutiva é diferente da

incremental, pois reconhece que as

necessidades do usuário não são

totalmente entendidas e que os

requisitos não podem ser definidos

antecipadamente, sendo refinados em

cada build sucessivo."


39


• Padrão Evolutivo na Prática– Uma iteração curta de Iniciação.

– Várias iterações de Elaboração, durante as quais:• Os requisitos são refinados em cada iteração.

– Uma única iteração de Construção, durante a qual:• Os casos de uso são realizados e a arquitetura é expandida.

– Várias iterações de Transição para• Migrar o produto para a comunidade de usuários.


40


• Padrão Evolutivo na Prática


41


• Padrão Evolutivo – Quando Usar?

– O domínio do problema é novo ou não é familiar.

– A equipe é inexperiente.


42


• Padrão de Ciclo de Vida Entrega

Incremental

– “Entregas da funcionalidade incremental

para o cliente. Isso pode ser necessário

quando há pressões de mercado sobre o

tempo restrito, onde a liberação antecipada

de certos recursos importantes pode render

benefícios de negócio significativos."


43


• Padrão Entrega Incremental na Prática– Uma iteração curta de Iniciação.

– Uma única iteração de Elaboração.

– Uma única iteração de Construção.

– Várias iterações de Transição para.


44


• Padrão Entrega Incremental na Prática


45


• Padrão Entrega Incremental – Quando Usar?

• O domínio do problema é familiar: • A arquitetura e os requisitos podem ser

estabilizados antecipadamente no ciclo de desenvolvimento.

• Há um baixo grau de novidade no problema.

• A equipe é experiente.

• Releases incrementais de funcionalidade têm alto valor para o cliente.


46


• Padrão Entrega Incremental – Quando Usar?

• “Em termos da abordagem da iteração de fase, a fase de transição começa cedo e tem a maioria das iterações. Essa estratégia requer uma arquitetura bastante estável, que é difícil de se conseguir em um ciclo de desenvolvimento inicial, para um sistema pouco conhecido ou sem precedentes".


47


• Padrão de Ciclo de Vida Design Principal

– “A abordagem em cascata tradicional pode

ser vista como um caso degenerado em que

há apenas uma iteração na fase de

construção. Chamado ‘design principal’ ou

‘design grande’. Na prática, é difícil evitar

iterações adicionais na fase de transição."


48


• Padrão Design Principal na Prática– Uma iteração curta de Iniciação.

– Uma única iteração muito longa de Construção, durante a qual os casos de uso são realizados e a arquitetura é aprimorada.

– Várias iterações de Transição.


49


• Padrão Design Principal na Prática


50


• Padrão Design Principal – Quando Usar?– Um pequeno incremento de funcionalidade bem

definida está sendo adicionado a um produto muito estável.

– A nova funcionalidade é bem definida e bem entendida.

– A equipe é experiente, tanto no domínio do problema quando no produto existente.


51


• Estratégias Híbridas

– “Na prática, poucos projetos seguem estritamente

uma estratégia. Você frequentemente acaba com

uma evolução híbrida, no início, uma construção

incremental e várias entregas. Uma das vantagens

do modelo de iteração de fase é que ele permite

acomodar uma abordagem híbrida, simplesmente

aumentando o tamanho e o número de iterações em

determinadas fases "


52


• Recomendações– Para domínios complexos ou de problemas

não familiares, nos quais há um alto grau de

exploração:

• aumente o número de iterações na fase de

elaboração e seu comprimento.


53


• Recomendações– Para problemas de desenvolvimento mais

complexos, nos quais há complexidade de

tradução do design em código:


construção e seu comprimento.


54


• Recomendações– Para entregar software em uma série de

releases incrementais:


transição e seu comprimento.


55


• O que é feito em cada fase do RUP?– Iniciação

– Elaboração

– Construção

– Transição


56

RUPIniciação - Meta

• Atingir o consenso entre todos os investidores

sobre os objetivos do ciclo de vida do projeto.

• Quando é mais importante?

– Esforços dos desenvolvimentos novos;

– Há muitos riscos de negócios;

– Requisitos que devem ser tratados para que o projeto

possa prosseguir.

– Em projetos de melhoria em sistemas existentes

geralmente esta fase é mais curta.


57

RUPIniciação - Objetivos

• Estabelecer o escopo do software:

– Uma visão operacional

– Critérios de aceitação

– O que deve ou não estar no produto.

• Discriminar

– os casos de uso críticos do sistema

– os principais cenários de operação que direcionarão o design.


58

RUPIniciação – Objetivos (cont...)

• Exibir pelo menos uma opção de arquitetura

para alguns cenários básicos.

• Estimar o custo geral do projeto inteiro.

• Calcular os riscos em potencial.

• Preparar o ambiente de suporte para o projeto.


59

RUPIniciação – Fluxo da Iteração


60


RUPIniciação – Fluxo da Iteração (cont...)

61

RUPIniciação - Marcos

• Ao avaliar o Marco da Iniciação você analisa os objetivos do ciclo de vida do projeto e decide prosseguir com o projeto ou cancelá-lo.

• Critérios de Avaliação– Consentimento dos envolvidos sobre a definição do escopo e as

estimativas de custo/programação.

– Consenso de que o conjunto correto de requisitos foi capturado e de que existe uma compreensão compartilhada desses requisitos.

– Consenso de que as estimativas de custo, as prioridades, os riscos e o processo de desenvolvimento são adequados.

– Todos os riscos foram identificados e existe uma estratégia atenuante para cada um.


62

RUPIniciação – Artefatos Obrigatórios


Exemplo Visão

Exemplo Especificação Suplementar

Exemplo Visão

Exemplo Especificação Suplementar

Exemplo Plano de Desenvolvimento de

Software

http://www.edison.eti.br/arquivos/Template_Visao.doc

http://www.edison.eti.br/arquivos/Template_Especificacao_Suplementar.doc

http://www.edison.eti.br/arquivos/Template_Visao.pdf

http://www.edison.eti.br/arquivos/Template_Especificacao_Suplementar.pdf

http://www.edison.eti.br/arquivos/Template_Plano_de_Desenvolvimento_de_Software.pdf

63

RUPIniciação – Artefatos Obrigatórios


64

RUPIniciação – Artefatos Opcionais


65

RUPElaboração - Meta

• Criar a baseline* para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção.

• Baseline– É um release revisto e aprovado dos artefatos que constitui uma

base ajustada para evolução ou desenvolvimento posterior e que só pode ser alterada através de um procedimento formal, como gerenciamento de mudanças e controle de configuração.

• A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco.


66

RUPElaboração - Objetivos

• Assegurar que:– a arquitetura, os requisitos e os planos sejam estáveis o

suficiente.

– que os riscos sejam suficientemente diminuídos a fim de determinar com segurança o custo para a conclusão do desenvolvimento.

• Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto.

• Estabelecer uma arquitetura de baseline derivada do tratamento dos cenários significativos do ponto de vista da arquitetura, que normalmente expõem os maiores riscos técnicos do projeto.


67

RUPElaboração - Objetivos

• Produzir um protótipo evolutivo e um ou mais protótipos descartáveis, para diminuir riscos específicos como:– trocas de design/requisitos

– reutilização de componentes

– possibilidade de produção do produto ou demonstrações para investidores, clientes e usuários finais.

• Demonstrar que a arquitetura suportará os requisitos do sistema a um custo justo e em tempo justo.

• Estabelecer um ambiente de suporte.– Configurar o ambiente de suporte para o projeto.

– Adaptar o processo para o projeto.

– Configurar ferramentas.


68

RUPElaboração – Fluxo da Iteração


69

RUPElaboração - Marcos

• No Marco da Arquitetura de Ciclo de Vida são examinados:– Objetivos e o escopo detalhados do sistema

– A opção de arquitetura

– A resolução dos principais riscos.

• Critérios de Avaliação– A Visão e os requisitos do produto são estáveis.

– A arquitetura é estável.

– As abordagens principais a serem usadas no teste e na avaliação foram comprovadas.


70

RUPElaboração - Marcos

• Critérios de Avaliação (cont...)– O teste e a avaliação de protótipos executáveis

demonstraram que os principais elementos de risco foram tratados e resolvidos com credibilidade.

– Os planos de iteração para a fase de construção:• Têm detalhes e fidelidade suficientes para permitir o avanço do

trabalho.

• São garantidos por estimativas confiáveis.

– Todos os envolvidos concordam que a visão atual poderá ser atendida se o plano atual for executado para desenvolver o sistema completo, no contexto da arquitetura atual.

– A despesa real em oposição à despesa planejada com recursos é aceitável.


71

RUPElaboração – Artefatos Obrigatórios


72



73



74

RUPElaboração – Artefatos Opcionais


75

RUPConstrução - Meta

• Esclarecer os requisitos restantes e

concluir o desenvolvimento do sistema

com base na arquitetura da baseline.

• Ênfase

– Gerenciamento de recursos.

– Controle de operações para otimizar custos.

– Programação.

– Qualidade.


76

RUPConstrução - Objetivos

• Minimizar custos de desenvolvimento;

• Otimizar a utilização de recursos;

• Evitar– Retalhamento.

– Retrabalho.

• Atingir a qualidade adequada.

• Desenvolver as versões úteis (alfa, beta e outros releases de teste).

• Concluir a análise, o design, o desenvolvimento e o teste de todas as funcionalidades necessárias.


Conduzido pelo

cliente no

ambiente do

desenvolvedor.

77

RUPConstrução - Objetivos

• Desenvolver de modo iterativo e incremental um produto completo.

• Decidir se o software, os locais e os usuários estão prontos para que o aplicativo seja implantado.

• Atingir um grau de paralelismo no trabalho das equipes de desenvolvimento. – Mesmo em projetos menores, normalmente há componentes que

podem ser desenvolvidos um independente do outro, permitindo o paralelismo natural entre as equipes (se os recursos permitirem).

– O paralelismo pode acelerar bastante as atividades de desenvolvimento; mas também aumenta a complexidade do gerenciamento de recursos e da sincronização dos fluxos de trabalho. Uma arquitetura sofisticada será essencial para atingir um paralelismo significativo.


78

RUPConstrução – Fluxo da Iteração


79

RUPConstrução - Marcos

• O produto está pronto para ser passado para a Equipe de Transição.

• Todos os testes alfa (se houver algum) foram concluídos.

• Desenvolvimento de um manual do usuário.

• Critérios de Avaliação– Este release do produto é estável e desenvolvido o suficiente para ser

implantado na comunidade de usuários?

– Todos os envolvidos estão prontos para a transição para a comunidade de usuários?

– As despesas reais com recursos ainda são aceitáveis se comparadas com as planejadas?


80

RUPConstrução – Artefatos Obrigatórios


81

RUPConstrução – Artefatos Opcionais


82

RUPTransição - Meta

• Assegurar que o software esteja disponível a seus usuários.

• Esta fase pode atravessar várias iterações;

• Inclui – Testar o produto em preparação para release.

– Ajustes pequenos com base no feedback do usuário.

• Nesse momento do ciclo de vida, o feedback do usuário deve priorizar:– O ajuste fino do produto

– A configuração

– A instalação

– Os problemas de usabilidade;

• Todos os problemas estruturais mais graves devem ter sido trabalhado muito antes no ciclo de vida do projeto.


83

RUPTransição - Objetivos

• O projeto deve estar em uma posição para

encerramento.

• Após fechamento dois caminhos podem ser

seguidos:

– Início de outro ciclo de vida no mesmo produto,

conduzindo à nova geração ou versão do produto.

– Liberação total dos artefatos a terceiros que

poderão ser responsáveis pela operação,

manutenção e melhorias.


84

RUPTransição – Objetivos (Cont...)

• Teste beta do novo sistema;

• Operação paralela relativa a um sistema legado que está sendo substituído;

• Conversão de bancos de dados operacionais;

• Treinamento de usuários e equipe de manutenção;

• Introdução a marketing, distribuição e equipe de vendas;

• Preparação para:– Empacotamento e produção comercial;

– Introdução a vendas;

– Treinamento de pessoal em campo;

• Atividades de ajuste, como:– Correção de erros;

– Melhoria no desempenho;

– Melhoria na usabilidade.


85

RUPTransição – Fluxo da Iteração


86

RUPTransição – Fluxo da Iteração (Cont...)


87

RUPTransição - Marcos

• Marco da Liberação do Produto– É o quarto marco mais importante do projeto;

– Verifca-se:• Se os objetivos foram atendidos;

• Se outro ciclo de desenvolvimento deve ser iniciado.

• Em alguns casos, esse marco pode coincidir com o fim da fase de iniciação do próximo ciclo.

• O Marco da Liberação do Produto é o resultado da revisão e aceitação pelo cliente das liberações do projeto.

• Critérios de Avaliação– O usuário está satisfeito?

– As despesas reais com recursos são aceitáveis se comparadas com as planejadas?


88

RUPTransição – Artefatos Obrigatórios


89

RUPTransição – Artefatos Opcionais


90

Referências

• [1] Filho, Wilson de Pádua Paula. Engenharia de Software: Fundamentos,

Métodos e Padrões. 3a Edição, Rio de Janeiro, LTC, 2009.

• [2] Larman, Craig. Utilizando UML e padrões - Uma introdução a análise e

ao projeto orientados. Bookman, 2007.

• [3] RUP 7.5 em Português. Disponível em http://www.wthreex.com/rup/

• [4] OpenUP. Disponível em http://www.wthreex.com/rup/OpenUP/index.htm

http://www.wthreex.com/rup/


RUP - professor.pucgoias.edu.brprofessor.pucgoias.edu.br/.../17315/material/Aula_RUP.pdf · •O ciclo de vida de software do RUP é dividido em quatro fases seqüenciais: ... –À

Documents