RUP. Prof. Edison A M Morais.

Transcrição

1 Prof. Edison A M Morais prof@edison.eti.br

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 2

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] 3

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 acrescente uma nova funcionalidade ao produto. Mais Informações: Página 101, Ref. [1] e Ref. [2] 4

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 Mais Informações: Página 101, Ref. [1] e Ref. [2] 5

6 UP X RUP WorkFlow UP Requisitos Análise Desenho Implementação Testes Obter os requisitos do produto. Detalhar, estruturar e validar os requisitos. Formular um modelo estrutural do produto. Desenvolver o código. Verificar o que foi implementado. Mais Informações: Página 101, Ref. [1] e Ref. [2] 6

7 UP X RUP Disciplinas RUP Mais Informações: Página 101, Ref. [1]. 7

8 Variações do RUP RUP 7.5 Português Para projetos maiores e menores Aproximadamente 120 MB OpenUp Disponível On Line Mais Informações: Ref. [3] 8

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: 9

10 OpenUP Mais Informações: 10

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? Mais Informações: Ref. [3] 11

12 O que é o RUP? É um Processo de Desenvolvimento de Software Mais Informações: Ref. [3] 12

13 O 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) Mais Informações: Ref. [3] 13

14 Quem deve utilizar o RUP? Principalmente empresas que precisam desenvolver software ITERATIVAMENTE. O que é Desenvolvimento Iterativo? Veja bem, não é Interativo! Mais Informações: Ref. [3] 14

15 Desenvolvimento 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. Mais Informações: Ref. [3] 15

16 Desenvolvimento Iterativo 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. Mais Informações: Ref. [3] 16

17 Desenvolvimento Iterativo 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. Mais Informações: Ref. [3] 17

18 Desenvolvimento Iterativo 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. Mais Informações: Ref. [3] 18

19 Desenvolvimento Iterativo 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? + Mais Informações: Ref. [3] 19

20 Desenvolvimento Iterativo 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. Mais Informações: Ref. [3] 20

21 Desenvolvimento Iterativo Importância dos Builds Pode ser apropriado e conveniente em alguns projetos construir builds diariamente, mas eles não representam iterações quando o 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 linhas de código), seria muito difícil alcançar uma duração de iteração de menos de uma semana. Mais Informações: Ref. [3] 21

22 Desenvolvimento Iterativo 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. Mais Informações: Ref. [3] 22

23 Desenvolvimento Iterativo Consequência Os conjuntos de artefatos crescem e amadurecem o tempo todo: Mais Informações: Ref. [3] 23

24 Como 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. Mais Informações: Ref. [3] 24

25 Ciclo 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. 25

26 Ciclo de Vida 26

27 Ciclo de Vida, Iterações e Releases 27

28 Ciclo 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. 28

29 Ciclos de Evolução Mais Informações: Ref. [3] 29

30 Ciclo 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? 30

31 Fases do Ciclo de Vida Esforço x Tempo Comportamento Típico para Projetos de Tamanho Médio Recurso x Tempo 31

32 Fases do Ciclo de Vida 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? 32

33 Fases do Ciclo de Vida 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 33

34 Fases do Ciclo de Vida 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" 34

35 Fases do Ciclo de Vida 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. 35

36 Fases do Ciclo de Vida Padrão Incremental na Prática 36

37 Fases do Ciclo de Vida Padrão Incremental Quando Usar? O domínio do problema é familiar. Os riscos são bem entendidos. A equipe do projeto é experiente. Mais Informações: Ref. [3] 37

38 Fases do Ciclo de Vida 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." 38

39 Fases do Ciclo de Vida 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. 39

40 Fases do Ciclo de Vida Padrão Evolutivo na Prática 40

41 Fases do Ciclo de Vida Padrão Evolutivo Quando Usar? O domínio do problema é novo ou não é familiar. A equipe é inexperiente. Mais Informações: Ref. [3] 41

42 Fases do Ciclo de Vida 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." 42

43 Fases do Ciclo de Vida 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. 43

44 Fases do Ciclo de Vida Padrão Entrega Incremental na Prática 44

45 Fases do Ciclo de Vida 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. Mais Informações: Ref. [3] 45

46 Fases do Ciclo de Vida 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". Mais Informações: Ref. [3] 46

47 Fases do Ciclo de Vida 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." 47

48 Fases do Ciclo de Vida 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. 48

49 Fases do Ciclo de Vida Padrão Design Principal na Prática 49

50 Fases do Ciclo de Vida 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. Mais Informações: Ref. [3] 50

51 Fases do Ciclo de Vida 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 " 51

52 Fases do Ciclo de Vida 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. 52

53 Fases do Ciclo de Vida Recomendações Para problemas de desenvolvimento mais complexos, nos quais há complexidade de tradução do design em código: aumente o número de iterações na fase de construção e seu comprimento. 53

54 Fases do Ciclo de Vida Recomendações Para entregar software em uma série de releases incrementais: aumente o número de iterações na fase de transição e seu comprimento. 54

55 Fases do Ciclo de Vida O que é feito em cada fase do RUP? Iniciação Elaboração Construção Transição 55

56 Iniciaçã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. 56

57 Iniciaçã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. 57

58 Iniciaçã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. 58

59 Iniciação Fluxo da Iteração 59

60 Iniciação Fluxo da Iteração (cont...) 60

61 Iniciaçã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. 61

62 Iniciação Artefatos Obrigatórios Exemplo Visão Exemplo Especificação Suplementar Exemplo Plano de Desenvolvimento de Software 62

63 Iniciação Artefatos Obrigatórios 63

64 Iniciação Artefatos Opcionais 64

65 Elaboraçã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. 65

66 Elaboraçã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. 66

67 Elaboraçã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. 67

68 Elaboração Fluxo da Iteração 68

69 Elaboraçã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. 69

70 Elaboraçã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. 70

71 Elaboração Artefatos Obrigatórios 71

72 Elaboração Artefatos Obrigatórios 72

73 Elaboração Artefatos Obrigatórios 73

74 Elaboração Artefatos Opcionais 74

75 Construçã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. 75

76 Construçã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). Conduzido pelo cliente no ambiente do desenvolvedor. Concluir a análise, o design, o desenvolvimento e o teste de todas as funcionalidades necessárias. 76

77 Construçã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. 77

78 Construção Fluxo da Iteração 78

79 Construçã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? 79

80 Construção Artefatos Obrigatórios 80

81 Construção Artefatos Opcionais 81

82 Transiçã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. 82

83 Transiçã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. 83

84 Transiçã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. 84

85 Transição Fluxo da Iteração 85

86 Transição Fluxo da Iteração (Cont...) 86

87 Transiçã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? 87

88 Transição Artefatos Obrigatórios 88

89 Transição Artefatos Opcionais 89

90 Fases do Ciclo de Vida Atividade Resolver a terceira lista de exercícios disponível no site. 90

91 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, [2] Larman, Craig. Utilizando UML e padrões - Uma introdução a análise e ao projeto orientados. Bookman, [3] RUP 7.5 em Português. Disponível em 91