A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

RUP1 Prof. Pedro A. Oliveira PUC Minas – São Gabriel Sistemas de Informação Engenharia de Software II Rational Unified Process - RUP.

Apresentações semelhantes


Apresentação em tema: "RUP1 Prof. Pedro A. Oliveira PUC Minas – São Gabriel Sistemas de Informação Engenharia de Software II Rational Unified Process - RUP."— Transcrição da apresentação:

1 RUP1 Prof. Pedro A. Oliveira PUC Minas – São Gabriel Sistemas de Informação Engenharia de Software II Rational Unified Process - RUP

2 RUP2 O que é o RUP Abordagem de desenvolvimento de software iterativa, centrada em arquitetura, e dirigida por casos de uso. Processo de engenharia de software definido e estruturado: define quem faz o que, como e quando. Possui ainda uma estrutura definida para o ciclo de vida de um projeto, articulando marcos e pontos de decisão. Produto (IBM/Rational): framework de processo personalizável para engenharia de software.

3 RUP3 Princípios essenciais Filho do Processo Unificado (UP). Define uma arquitetura executável no início. Acomoda mudanças desde o início. Ataca os maiores riscos primeiro. Garante entregas significativas ao cliente. Mantem o foco em software executável. Visa Construir sistemas a partir de componentes. Trabalho em equipe é requerido. Faz da qualidade um modo de vida, não um alvo.

4 RUP4 Paradigma do RUP Centrado na arquitetura Iterativo e incremental Dirigido por casos de uso

5 RUP5 Centrado na arquitetura A arquitetura é a organização fundamental do sistema como um todo, incluindo elementos estáticos e dinâmicos e sua interação. Consequências: Possibilita o entendimento da visão geral; Organiza o esforço de desenvolvimento; Facilita as possibilidades de reuso; Facilita a evolução do sistema; Dirige a seleção de casos de uso relevantes.

6 RUP6 Arquitetura como Ponte REQUISITOS CÓDIGO ARQUITETURA Fonte: Garlan (2000)

7 Diagrama de Pacotes RUPProcesso de software PBH/Prodabel7

8 RUP8 Dirigido por casos de uso Os casos de uso dirigem (guiam) todo o trabalho de desenvolvimento, desde a captação inicial e negociação de requisitos até a aceitação do código. Justificativas: São expressos sob a perspectiva do usuário; São expressos em linguagem natural; Oferecem uma habilidade maior para a compreensão dos requisitos reais do sistema; Oferecem a habilidade para atingir um alto grau de rastreabilidade de requisitos; Oferecem um meio simples de decompor os requisitos em partes (módulos, pacotes), que permitem a alocação de trabalho a subequipes, facilitando a gerência do projeto.

9 RUP9 Múltiplas visões

10 RUP10 Abordagem iterativa Acomoda mudanças de requisitos. Integração não é mais feita como big bang, no final do projeto. Riscos descobertos e tratados durante as integrações iniciais. Gerenciamento tem um significado de fazer mudanças táticas no produto. Reuso é facilitado.

11 RUP11 Abordagem iterativa Defeitos podem ser encontrados e corrigidos ao longo das iterações. Otimiza a execução de funções da equipe de projeto. Membros da equipe aprendem ao longo do projeto. O processo de desenvolvimento é evoluido e refinado ao longo do projeto.

12 RUP12 Organização estrutural do RUP

13 RUP13 Estruturas Estrutura dinâmica: dimensão horizontal que representa o tempo do processo. Mostra como o processo, expresso em termos de ciclos, fases, iterações e marcos, desenvolve-se ao longo do ciclo de vida de um projeto. Estrutura estática: dimensão vertical que descreve como os elementos do processo (atividades, disciplinas, artefatos e papéis) são logicamente agrupados em temas (disciplinas ou fluxos).

14 RUP14 Estrutura dinâmica

15 RUP15 Ciclo Um ciclo de desenvolvimento é um período de tempo que envolve do começo do projeto até a entrega do produto (ou cancelamento). Há diferentes ciclos dependendo do produto como ciclo inicial de desenvolvimento e ciclo de evolução ou manutenção.

16 RUP16 Fase Cada ciclo no processo é dividida em uma sequência de quatro fases: Concepção, Elaboração, Construção, Transição. As fases sempre existem e são fundamentais, não por causa do que é executado ou pelo seu tamanho, mas pelo que é atingido pelos marcos principais que concluem cada fase.

17 RUP17 Ciclos típicos

18 RUP18 Marcos principais O propósito das fases não é particionar as atividades por tipo (análise, codificação, etc) e sim executar o suficiente de cada disciplina para atingir os objetivos da fase no momento que os marco são atingidos. Os marcos principais do RUP não são expressos em termos de completar certos artefatos ou documentos, mas principalmente em termos de mitigação de riscos e completude do produto.

19 RUP19 Fluxos variáveis Os marcos principais são constantes em todos projetos que utilizam o RUP. Entretanto, isso não significa que há uma prescrição fixa ou pré-determinada de um conjunto de atividades a seguir em todas as fases. Alguns fatores influenciam o trabalho a ser feito, tais como: tamanho e natureza do projeto, riscos, número de envolvidos.

20 RUP20 Artefatos congelados Os objetivos de uma fase não estão descritos em termos de terminar um artefato, mas trazer o nível adequado de maturidade para tornar-se capaz de tomar as decisões corretas. À medida que o projeto evolui mais entendimento é obtido a respeito dos objetivos, à medida que novas dificuldades são descobertas, mudanças são introduzidas, artefatos são revisados, atualizados e corrigidos. Portanto, atividades já realizadas são executadas novamente, com maior grau de refinamento.

21 RUP21 Fase concepção Objetivos: Entender o que será construído; Identificar funcionalidades-chave do sistema; Determinar pelo menos uma solução possível; Entender o cronograma, custos e riscos do projeto; Decidir qual processo e ferramentas seguir. Marco: Objetivo do ciclo de vida. Identifique um produto: ___________________

22 RUP22 Fase elaboração Objetivos: Ter um entendimento detalhado dos requisitos; Desenhar, implementar e validar a arquitetura; Mitigar riscos essenciais e produzir um plano mais refinado; Preparar o ambiente de desenvolvimento. Marco: Arquitetura do ciclo de vida. Identifique um produto: ___________________

23 RUP23 Fase construção Objetivos: Minimizar custos de desenvolvimento e atingir certo grau de paralelismo para melhorar o desempenho no projeto; Desenvolver iterativamente um produto pronto para a comunidade de usuários. Marco: Capacidade operacional inicial. Identifique um produto: ___________________

24 RUP24 Fase Transição Objetivos: Realizar testes beta para validar expectativas dos usuários; Treinar usuários e demais envolvidos visando sua independência. Preparar ambiente e converter banco de dados; Preparar empacotamento e distribuição; Obter lições aprendidas; Marco: Liberação do produto para produção. Identifique um produto: _____________________________

25 RUP25 Iteração Dentro de cada fase podem existir uma ou mais iterações. Software é desenvolvido em cada iteração, que é concluída em uma revisão secundária (minor milestone), incluindo uma liberação (release) interna ou externa que torna-se um ponto de avaliação do progresso do projeto. O produto cresce de forma incremental, à medida que são feitas as iterações e suas atividades.

26 RUP26 Iterações por fase

27 RUP27 Build Dentro de cada iteração, os vários desenvolvedores ou times podem produzir builds de software; em alguns casos em frequências elevadas, até diariamente. Isso permite integração contínua, testes (inclusive de regressão) e indicadores gerais de progresso. Frequentemente, o último build de uma iteração é parte da liberação daquela iteração.

28 RUP28 Estrutura estática - RUP

29 RUP29 Fluxo Sequência organizada e coerente, que produz algum resultado significativo. Mostra a interação entre papéis, atividades e artefatos. Os principais tipos de fluxo são: Disciplinas Detalhes das disciplinas.

30 RUP30 Disciplina As disciplinas representam uma partição de todos os papéis e atividades em agrupamentos lógicos, organizados por áreas de conhecimento ou especialidade. Dividem-se em: Disciplinas técnicas. Disciplinas de apoio.

31 RUP31 Disciplinas Disciplinas técnicas Modelagem de negócio; Requisitos; Análise e desenho; Implementação; Implantação; Teste; Disciplinas de apoio: Gerenciamento de projetos; Gerencia de configuração; Ambiente.

32 RUP32 Atividade Uma unidade de trabalho que deve ser desenvolvida. Tem um propósito claro, usualmente expresso em termos de criação ou atualização de algum artefato, modelo, componente ou plano. Atividade é uma subdivisão de Iteração. A cada atividade é atribuído um papel específico. Exemplos: Elaborar caso de uso => Analista de requisitos; Preparar plano de projeto => Gerente de projeto.

33 RUP33 Papel É um chapéu que um indivíduo ou grupo coloca em um dado momento, no projeto. Um indivíduo pode desempenhar vários papéis, que não podem ser confundidos com cargos na organização. Exemplos de papéis: Desenhista (designer); Analista de requsitos; Testador.

34 RUP34 Artefato Conjunto de informações produzido, modificado ou utilizado num processo. Traduz-se num produto (plano, desenho, código, etc). São elementos tangíveis de um projeto: coisas que um projeto produz ou usa enquanto o trabalho é executado. Tipos de artefato: modelos, elementos de modelo, documento, código fonte, executável.

35 RUP35 Elementos adicionais Guias Gabaritos (templates) Mentor de ferramenta Conceitos Roteiros Como o PSP trata isto?

36 RUP36 Planejamento de projetos Conceitos-chave: Ciclo. Fase. Iteração. Build.

37 RUP37 Estratégia de planejamento Devido ao fato do processo iterativo ser altamente dinâmico, adaptável e desenhado para acomodar mudanças, não é interessante gastar tempo e esforço produzindo planos detalhados que ultrapassem o horizonte do projeto. Planos burocráticos são difíceis de manter, tornando-se rapidamente obsoletos; são tipicamente ignorados pela organização, após algumas semanas.

38 RUP38 Plano de projeto e iterações A abordagem iterativa e incremental estabelece dois tipos de planejamento: Alto-nível (coarse-grain): contido no plano de projeto, que aborda as fases, iterações, seus objetivos e informações gerais. Há um plano por projeto. Baixo-nível (fine-grain): contido em planos de iteração, que traz as atividades e recursos individuais. Há um plano por iteração.

39 RUP39 Planejamento de alto nível e detalhado

40 RUP40 Plano de projeto Gerentes de níveis superiores e stakeholders raramente se interessam por detalhes sobre quem está fazendo o que e quando. O foco gerencial está no produto final, datas de liberação, marcos significativos… Decisões importantes devem ser tomadas pelo gerente, no sentido de avaliar o progresso geral do projeto e solucionar problemas. O plano de projeto é um plano de alto nível, que atua como um envelope para os planos detalhados de cada iteração.

41 RUP41 Plano de iteração Plano detalhado e com tempo bem definido, com um intervalo de tempo suficientemente pequeno para prover a equipe de um tipo de detalhamento com o qual ela está acostumada. Deve definir tarefas e alocação de cada membro da equipe. Em alguns projetos, o plano de iteração corresponde a uma simples lista de tarefas por fazer.

42 RUP42 Problemas gerenciais - gerais Organização funcionalmente especializada, ao invés de equipes multifuncionais (burocracia). Falta de definição clara sobre as expectativas dos stakeholders, que podem esperar os mesmos resultados de um processo cascata. Alocação de muitos desenvolvedores no começo do projeto, antes de entender bem o que fazer. Resolver as questões fáceis primeiro ao invés de tratar as questões de maior risco. Outro: _____________________________________

43 RUP43 Problemas gerenciais - tempo Iteração inicial muito longa, tentando fazer muitas coisas no começo. Iterações sobrepostas, iniciando a próxima iteração sem o feedback da anterior. Confusão típica de quem não domina o RUP. Mudanças excessivas nos momentos finais do projeto, levando a atrasos. Outro: __________________________________

44 RUP44 Problemas técnicos - equipe Número excessivo de casos de uso, tratando-os como uma decomposição funcional e tornando os requisitos incompreensíveis. Paralisia da análise, devido ao excesso de detalhes. Inclusão de decisões de desenho nos requisitos, forçando decisões prematuras. Falta de comprometimento dos clientes, levando a um sistema potencialmente rejeitável. Outro: ________________________________

45 RUP45 Problemas técnicos - gerente Mentalidade o que não foi inventado aqui não presta, reduzindo reuso. Fim da elaboração antes da maturidade da arquitetura, causando retrabalho. Foco em inspeções e revisões ao invés de software executando, causando um processo de garantia de qualidade ineficiente, abordando apenas documentos ao invés do executável. Outro: __________________________________

46 RUP46 Alguns dados históricos sobre o RUP Durações típicas de projetos: De 6 semanas a 54 meses. Durações típicas de uma iteração: De 2 semanas a 6 meses. Quantidade típica de iterações por projeto: De 3 a 9 iterações. Quantidade de artefatos definidos: Aproximadamente 100. Quantidade de papéis definidos: Aproximadamente 30.

47 RUP47 IniciaçãoElaboraçãoConstruçãoTransição Esforço~5 %20 %65 %10% Programação10 %30 %50 %10% Fases de Planejamento As fases não são idênticas em termos de programa ç ão e esfor ç o. Embora isso varie muito de acordo com o projeto, um ciclo de desenvolvimento inicial t í pico para um projeto de tamanho médio deve prever a seguinte distribui ç ão de esfor ç o e programação: Fonte:

48 RUP48 Iterações por fase

49 RUP49 Dados sobre projetos com o RUP Duração de cada iteração em semanas Duração do projeto em meses PF (pontos por função) é uma técnica para estimativa de tamanho Um PF corresponde aproximadamente a 50 linhas de código Java Produtividade histórica: 7,4; 7 e 6,5 PF/pessoa-mês, respectivamente.

50 RUP50 Detalhamento das disciplinas Disciplinas técnicas Modelagem de negócio; Requisitos; Análise e desenho; Implementação; Implantação; Teste; Disciplinas de apoio: Gerenciamento de projetos; Gerencia de configuração; Ambiente.

51 RUP51 Modelagem de negócio Objetivos Entender a estrutura e a dinâmica da organização na qual o sistema deve ser implantado. Entender os problemas atuais e identificar melhorias potenciais. Garantir um entendimento comum entre clientes, usuários e desenvolvedores. Derivar os requisitos de sistemas necessários.

52 RUP52 Modelagem de negócio Principais papéis: Analista de negócio Desenhista de processo de negócio Stakeholders Revisores Principais artefatos: Documento de visão de negócios Modelo de casos de uso de negócio Modelo de objetos de negócio Especificação suplementar de negócio Glossário de negócio

53 RUP53 Requisitos Objetivos Estabelecer e manter acordo entre stakeholders sobre o que o sistema deve fazer Prover aos desenvolvedores um melhor entendimento dos requisitos do sistema Definir as fronteiras do sistema Prover a base para planejamento do conteúdo técnico das iterações Prover a base para estimativas de duração e custo

54 RUP54 Requisitos Principais papéis : Analista de sistemas Especificador de casos de uso Desenhista de interfaces com usuário Principais artefatos: Glossário Descrição dos casos de uso Protótipos de interface com usuário

55 RUP55 Análise e desenho Objetivos Traduzir os requisitos em uma especificação que descreva como implementar o sistema Selecionar a melhor estratégia de implementação Estabelecer uma arquitetura robusta para a aplicação

56 RUP56 Análise e desenho Principais papéis : Arquiteto Desenhista Desenhista de banco de dados Revisor Principais artefatos: Modelo de análise Modelo de desenho Documento de arquitetura de software

57 RUP57 Implementação Objetivos Definir a organização do código em termos de subsistemas e camadas Implementar classes, objetos e componentes Testar unidades criadas Integrar em um ambiente executável os resultados produzidos individualmente

58 RUP58 Implementação Principais papéis : Implementador Integrador de sistemas Arquiteto Revisor de código Principais artefatos: Implementação de subsistema Componente Plano de integração

59 RUP59 Testes Objetivos Verificar a interação dos atores com cada componente. Verificar a integração entre os componentes. Verificar a implementação correta de todos os requisitos. Identificar e garantir que todos os defeitos descobertos sejam tratados.

60 RUP60 Testes Principais papéis : Desenhista de testes Testador Principais artefatos: Plano de testes Modelo de testes Resultados dos testes Modelo de carga Defeitos gerados

61 RUP61 Gerenciamento de configuração e mudanças Objetivos Rastrear e manter a integridade do projeto. Habilitar membros da equipe a identificar e localizar artefatos, selecionar a versão adequada e avaliar o histórico do artefato. Acompanhar a evolução do projeto.

62 RUP62 Gerenciamento de configuração e mudanças Principais papéis : Gerente de configuração Gerente de controle de mudanças Implementador Integrador Arquiteto Principais artefatos: Plano de gerenciamento de configurações Requisições de mudança Modelo de implementação Métricas e relatórios de status

63 RUP63 Gerenciamento de projetos Objetivos Prover uma estrutura para gerenciar projetos de desenvolvimento. Prover diretrizes práticas para planejar, executar, apoiar e monitorar projetos. Prover uma estrutura para gerenciar riscos.

64 RUP64 Gerenciamento de projetos Principais papéis: Gerente de projetos Principais artefatos: Plano de desenvolvimento de projeto Plano de iterações Modelo de negócio Medidas do projeto

65 RUP65 Ambiente Objetivos Seleção e aquisição de ferramentas Configuração e personalização de ferramentas Configuração de processos Melhoria dos processos Prover serviços de apoio: infra-estrutura, administração de contas, backup, etc.

66 RUP66 Ambiente Principais papéis: Analista de processos de negócio Analista de sistemas Desenhista de interfaces com usuário Arquiteto Redator Administrador do sistema Especialista em ferramentas Principais artefatos: Diretrizes gerais

67 RUP67 Implantação Objetivos Testar o software no ambiente final (produção). Empacotar o software para implantação. Distribuir o software. Instalar o software. Treinar os usuários finais. Migrar o software existente (se for o caso) e converter sua base de dados

68 RUP68 Implantação Principais papéis: Gerente de implantação Gerente de projetos Redator Implementador Principais artefatos: Software executável. Artefatos de instalação: scripts, ferramentas, arquivos, guias, etc. Notas de release. Material de apoio e treinamento.

69 RUP69 Referências Bibliográficas KRUCHTEN, Philippe, The Rational Unified Process – An Introdution, 2a ed., Adisson Wesley, KROLL, Per, KRUCHTEN, Philippe, The Rational Unified Process Made Easy, Adisson Wesley,


Carregar ppt "RUP1 Prof. Pedro A. Oliveira PUC Minas – São Gabriel Sistemas de Informação Engenharia de Software II Rational Unified Process - RUP."

Apresentações semelhantes


Anúncios Google