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

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

Rational Unified Process. O Valor do Software O software é um parte indispensável no mundo moderno O software é um parte indispensável no mundo moderno.

Apresentações semelhantes


Apresentação em tema: "Rational Unified Process. O Valor do Software O software é um parte indispensável no mundo moderno O software é um parte indispensável no mundo moderno."— Transcrição da apresentação:

1 Rational Unified Process

2 O Valor do Software O software é um parte indispensável no mundo moderno O software é um parte indispensável no mundo moderno Faz com que as sociedades se conectem melhor Nos ajuda a criar, acessar e visualizar informação em formas e modos não concebíveis anteriormente. Boa notícia Boa notícia A economia mundial depende cada vez mais de software. Notícia ruim Notícia ruim O pessoal qualificado não consegue acompanhar o mesmo ritmo da demanda. Softwares estão crescendo em importância, tamanho, complexidade e distribuição. Resultado Resultado A construção e manutenção de software são difíceis.

3 Sintomas e Origem das Causas de Problemas de Desenvolvimento de Software Entendimento impreciso das necessidades dos usuários Entendimento impreciso das necessidades dos usuários Falta de habilidade de lidar com a necessidade de mudanças Falta de habilidade de lidar com a necessidade de mudanças Uma descoberta tardia de uma séria falha de projeto Uma descoberta tardia de uma séria falha de projeto Software com baixa qualidade Software com baixa qualidade Um processo não confiável de construção Um processo não confiável de construção Arquitetura frágil Arquitetura frágil Testes insuficientes Testes insuficientes Falha no ataque aos riscos Falha no ataque aos riscos

4 Processo Define quem irá fazer o que, quando, e como será alcançado o objetivo. Define quem irá fazer o que, quando, e como será alcançado o objetivo. Requisitos novos ou alterados Sistema novo ou melhorado Processo de Engenharia de Software

5 Processo Regras Prover um guia para as atividades Especificar que artefatos e quando devem ser desenvolvidos Direcionar as tarefas dos grupos e indivíduos Oferecer um critério para monitorar e medir o processo

6 Melhores Práticas Desenvolver software iterativamente Desenvolver software iterativamente Gerenciar requisitos Gerenciar requisitos Usar arquiteturas baseadas em componentes Usar arquiteturas baseadas em componentes Modelar o software visualmente Modelar o software visualmente Verificar continuamente a qualidade do software Verificar continuamente a qualidade do software Controlar as alterações no software Controlar as alterações no software

7 Best Practices

8 RUP Um processo de engenharia de software Um framework para outros processos Utiliza as 6 melhores práticas de desenvolvimento de software

9 RUP RUP é uma abordagem dirigida por caso de uso (use-case driven) RUP é uma abordagem dirigida por caso de uso (use-case driven) Casos de uso dirigem inumerosas atividades Casos de uso dirigem inumerosas atividades Criação e validação dos modelos de projeto Definição dos casos de teste no modelo de teste Planejamento de iterações Criação do manual do usuário Processo centrado na arquitetura Processo centrado na arquitetura

10 Histórico Rational Approach Rational Objectory Process 4.0 Objectory Process 3.8 Rational Objectory Process 4.1 Rational Unified Process 5.0 Rational Unified Process 5.5 Rational Unified Process UML 0.8 UML 1.1 UML 1.2 UML 1.3

11 RUP Logical View Implemation View Process View Deployment View Use-Case View End_user Functionality Analysts/Tester Behavior System Integrator Performance Scalability Throughput Programmers Software Management System Engineering System Topology Delivery, Installation Communication

12 RUP

13 Visão Geral Concepção – onde são estabelecidos lógica do domínio da aplicação e escopo do projeto Elaboração – coleta de requisitos mais detalhados, análise e plano para construção do sistema Construção – consiste de várias iterações Transição – teste, ajuste de performance e treinamento de usuário

14 RUP

15 RUP - Melhores Práticas Desenvolvimento Iterativo Desenvolvimento Iterativo Gerência de Requisitos Gerência de Requisitos Arquitetura Baseada em Componentes Arquitetura Baseada em Componentes Modelagem Visual Modelagem Visual Verificação Contínua da Qualidade Verificação Contínua da Qualidade Gerência de Mudanças Gerência de Mudanças

16 Desenvolvimento Iterativo O que é desenvolvimento iterativo Desenvolvimento em Cascata Desenvolvimento Iterativo

17 Teste Modelagem de Negócio Requisitos Análise & Projeto Deployment Avaliação Teste Implementação

18 Desenvolvimento Iterativo Vantagens Os riscos são atacados mais cedo Mudanças nos requisitos Refinamento de arquitetura Aprendizado e aprimoramento Aumento do reuso

19 Gerência de Requisitos Dificuldades Requisitos não são óbvios Requisitos não são sempre facilmente epresso em palavras Existem vários tipos de requisitos em diferentes níveis de detalhes O número de requisitos pode explodir Requisitos estão interligados Existem várias pessoas interessadas nos requisitos Requisitos mudam.

20 Gerência de Requisitos Atacando Analisando o problema Entendendo as necessidades dos stakeholders Definindo o sistema Gerenciando o escopo do projeto Refinando a definição do sistema Gerenciando mudança de requisitos

21 Arquitetura Baseada em Componentes Desenvolvimento Baseado em Componentes Definem uma arquitetura modular Desenvolvidos para reuso Arquiteturas e componentes prontos

22 Arquitetura Baseada em Componentes Suporte ao Desenvolvimento Baseado em Componentes Com o processo itrativo Baseado na arquitetura Através da UML - com pacotes, camadas e subsistemas Testes graduais

23 Arquitetura Baseada em Componentes

24 Modelagem Visual

25

26

27 Ajuda a entender sistemas complexos Explora e compara alterntivas a um preço baixo Forma uma base para a implementação Facilita a captura dos requisitos Comunica as decisões sem ambiguidades

28 Verificação Contínua da Qualidade

29 O que é qualidade? "...the characteristic of having demonstrated the achievement of producing a product that meets or exceeds agreed-on requirementsas measured by agreed-on measures and criteriaand that is produced by an agreed-on process."

30 Verificação Contínua da Qualidade O que é qualidade? Onde está a qualidade? Gerência da qualidade no RUP Identificar metricas Identificar medidas Identificar os pontos que afetam a qualidade o quanto antes

31 Gerência de Mudanças

32 Coordenação das Atividades e Artefatos Coordenação das Iterações e Releases Controlando Mudanças de Software Workspaces isolados reduzem interferências Estatísticas provêem boas métricas Mudanças podem ser confinadas e as propagações medidas

33 Conceitos Chave

34 Elementos do RUP Workflow Workflow Workers ou Papel Workers ou Papel Atividades Atividades Artefatos Artefatos

35 Elementos do RUP Descrever um Caso de Uso Pacote de Caso de Uso Caso de Uso Responsável por Analista Artefato Informação que é produzida, modificada, ou usada pelo processo Worker Papel desempenhado por um indivíduo ou grupo Atividade Unidade de trabalho

36 Disciplina Workflow de atividades correlatas Alguns elementos, como risco e testes, são introduzidos em diferentes disciplinas Relação entre disciplina e modelos

37 Disciplina

38 Workflow Sequência de atividades que produzem um resultado de valor observável Geralmente expresso em um diagrama de atividade Organização Disciplinas Detalhes do Workflow

39 Workflow Workflows essenciais (Core Workflows): Engenharia: Modelagem de Negócio Requisitos Análise & Projeto Implementação Teste Deployment Suporte: Gerência do Projeto Gerência de Configuração Ambiente

40 Workflow Modelo de Projeto Modelo de Implementação Modelo de Teste realizado pelo implementado pelo Requisitos Implementação Teste Modelo de Caso de Uso Modelagem de Negócio verificado pelo Modelo de Negócio Análise & Projeto

41 Workflow

42 Workflow Details As atividades não são feitas em sequência Mostra os artefatos necessários e os gerados Agrupa atividades relacionadas de outras disciplinas

43 Workflow Details

44

45 Workers - Papel Define o comportamento e as responsabilidades de um indivíduo um uma equipe Exercidos por pessoal interno ou externo à equipe de desenvolvimento

46 Workers - Papel Exemplos: Exemplos: Analista de Sistemas Revisor de Projeto Testador de desempenho

47 Workers - Papel

48

49 Atividade Unidade de trabalho com um propósito claro Utilizado para planejamento e verificação de progresso Passos Planejando Executando Revisando

50 Atividade Exemplos: Exemplos: Identificar casos de uso e atores Worker: Analista de Sistemas Revisar o projeto Worker: Revisor de Projeto Executar teste de desempenho Worker: Testador de desempenho

51 Atividade

52 A atividade Find use case and actors se decompõe nos passos: Identificar os atores Identificar os casos de uso Descrever a interação entre os atores e uc Organizar em pacotes Apresentar o modelo em um diagrama Avaliar os resultados

53 Artefatos Unidade produzida por um atividade Pode assumir as formas: Modelo (UC Model) Elemento de Modelo (Ator) Documento (Visão) Código (Componente)

54 Artefatos

55 Mantidos por controle de versão Artefatos geralmente não estão na forma de documentos O artefato esta sempre atualizado Guias e checkpoints Fornecem uma referência de como fazer Permitem verificar a qualidade do artefato

56 Artefatos Templates Documento de visão (MS Word) Documento de visão Exemplos Modelo (Modelo de Caso de Uso, de Projeto, etc) Documento (Documento da Arquitetura do Software) Código-Fonte Executáveis

57 Documentos Documentos de Visão Documentos de Risco Documentos de Análise de Negócio (Processo)

58 Tool Mentors Guiam a execução das atividades em uma ferramenta Ex: Documenting the Deployment Model Using Rational Rose

59 Fundamentos

60 Visão Concordar com o problema a ser resolvido Identificar os stakeholders Definir os limites do sistema Identificar as restrições Políticas Econômicas Ambientais Praticabilidade Sistema

61 Visão Formular a expressão do problema O problema Afeta O impacto deste é Uma solução adequada poderia

62 Planejamento Software development plan Bom entendimento do que vai ser criado Plano da Fase: granularidade alta Plano de Iteração: granularidade baixa The product is only as good as the plan for the product Charles Fishman The plan is nothing; the planning is everything. Dwight D. Eisenhowe

63 Riscos Definição: é uma variavel que pode obter um valor que dificulte ou até mesmo torne o desenv. inviável Tipos Risco direto Risco indireto Atributos Probabilidade de ocorrência Impacto no projeto

64 Riscos Investigando e avaliando riscos Identificar os riscos Analisar e priorizar os riscos Definir estratégias de evasão Definir estratégias de ataque Definir estratégias de contingência Indicadores Plano B Rever os ricos durante a iteração Rever os riscos no final da iteração

65 Tipos de Riscos Riscos de Requisitos Riscos Tecnológicos Riscos de Habilidades Riscos Políticos

66 Riscos de Requisitos Ponto inicial do processo de desenvolvimento: Casos de Uso (interação típica que o usuário tem com o sistema) Esboçar esqueleto do modelo conceitual do domínio – Modelo de domínio. Fornece muita compreensão. Ponto inicial para construção de classes Encontrar detalhes importantes e se concentrar neles Construção de Protótipo

67 Riscos Tecnológicos Construir um protótipo que experimente as partes da tecnologia que você está pensando em utilizar Como os componentes do projeto se encaixam Dificuldade de serem modificados

68 Riscos de Habilidades Treinamento é um bom modo de evitar erros Bom instrutor Treinamento em pequenas porções Se não puder ter consultores, faça revisões de tempo em tempo Leitura e grupos de estudo

69 Riscos Políticos Política Corporativa Planos de governo

70 Riscos Quem estiver primeiro no campo de batalha e esperar a aparição do inimigo estará descansado para o combate; quem vier depois e tiver de apressar-se, chegará exausto. Sun Tzu

71 Business Case Plano econômico para realizar a Visão, isto é, saber se o projeto vale a pena. Avaliação do ROI (Return On Investment) Template

72 Arquitetura Artefato: Software Architecture Document Quais são os componentes? Como os componentes se encaixam? Existe algum framework? Visões arquiteturais

73 Arquitetura Visão Lógica Usuário final Funcionalidade Visão de Processo Visão de Implementação Visão de Deployment Visão de Casos de Uso Integradores Performance Escalabilidade Engenharia Topologia Instalação Programadores Gerenciamento de Software

74 Prototipagem Iterativamente e incrementalmente criar versões do sistema. Verificação dos requisitos Redução de riscos

75 Avaliação Regular Foco nos problemas no processo e os problemas no produto

76 Mudanças Artefato: Change Request Provê um histórico das mudanças e das decisões tomadas Gerenciar o escopo do projeto Avaliar o impacto das decisões

77 Suporte do Usuário Criar um produto utilizável Manuais, ajuda e treinamento

78 Processo Adotar um processo que se encaixa ao projeto A produção de artefatos varia de projeto a projeto

79 Conclusões Sem visão? O projeto pode perder escopo ou desviar do propósito Sem processo? A equipe pode perder a visão de quem esta fazendo o que e quando Sem planejamento? Você perde a capacidade de rastrear o progresso

80 Conclusões Sem controle de riscos? Você pode focar no ponto errado e pisar em minas Sem Business Case? Você corre-se o risco de jogar tempo e investimento fora Sem arquitetura? Podem ocorrer problemas com escalabilidade, falso reuso e performance

81 Conclusões Sem prototipagem? Como você e o usuário saberão que o sistema funciona? Sem avaliação? Tenha coragem e enfrente a verdade! Sem Change Request? Como rastrear, priorizar os pedidos do cliente Sem suporte do usuário? Como o usuário vai obter informação sobre o sistema?

82 Fases

83 tempo InceptionElaborationConstruction Transition

84 Fases e Iterações InceptionElaborationConstruction Transition Iteração #1 … …… Iteração #n Iteração #n+1 Iteração #m Iteração #m+1 Iteração Prelim. Versões

85 Milestone Lifecycle Objectives Lifecycle Architecture Initial Operational Capability tempo InceptionElaborationConstruction Transition Cada fase deve ser concluída com um Milestone (Major Milestone) Cada fase deve ser concluída com um Milestone (Major Milestone)

86 Concepção Estabelecer o escopo e os limites, com critérios de aceitação bem definidos Discriminar os casos de usos críticos Exibir uma arquitetura candidata Adivinhar o custo e o calendário Preparar o ambiente do projeto

87 Concepção - Milestone Examina os objetivos e decide seguir ou cancelar o projeto - Viabilidade Critério de avaliação Entendimento e acordo com os requisitos Credibilidade do custo/tempo Acerto das prioridades

88 Concepção - Milestone Produtos: Produtos: Visão geral dos requisitos do projeto: Modelo de Caso de Uso inicial (10-20%) Estimativa dos recursos necessários Mini Mundo

89 Elaboração Assegurar que os requisitos e planos estão estáveis Estabelecer uma arquitetura Provar que a arquitetura funciona Produzir um protótipo evolucionário Estabelecer um ambiente

90 Elaboração Deve terminar em torno de um quinto do tempo do projeto Desenvolvedores já sentem a vontade para dar estimativas de tempo Todos os riscos significativos foram identificados

91 Elaboração - Milestone Examina os objetivos, arquitetura e riscos do projeto Critério de avaliação Requisitos, visão e arquitetura estáveis Verificar que, com os protótipos, todos os riscos foram atacados Planos de Iteração da fase de construção Despesas atuais batem com estimadas

92 Elaboração - Milestone Todos o Stakeholders concordam que a visão atual pode ser alcançada se o plano atual for executado para desenvolver o sistema completo, no contexto da arquitetura atual ? Produtos: Modelo de Caso de Uso (80%) Plano de desenvolvimento Avaliação revisada dos riscos Protótipo da arquitetura

93 Construção Atingir qualidade o mais breve possível Desenvolver incrementalmente e lançar as versões de teste (alpha, beta) Completar o desenvolvimento de todos os Casos de Uso

94 Construção Estabelecer(detalhar) as iterações e definir que funcionalidades entregar em cada uma delas Casos de Uso com maior prioridade e/ou risco de desenvolvimento primeiro Cada iteração é um mini-projeto: Análise, projeto,codificação, teste e integração As iterações são incrementais na função Integração contínua

95 Construção - Milestone Sistema e manual Critério de avaliação O sistema já esta maduro o suficiente pra ser entregue? Os stakeholders estão prontos para usá-lo? Despesas reais versus planejadas continuam aceitaveis?

96 Construção - Milestone Produtos: Modelo de Caso de Uso e de Projeto completos Manual do usuário O software integrado e pronto para a utilização dos usuários

97 Transição Teste de validação Conversão do ambiente para produção Treinamento de usuários e manutenção Otimização Alcançando auto-suporte do usuário

98 Transição - Milestone Os objetivos foram cumpridos Coincide com o fim da fase de concepção de outro ciclo Critério de avaliação O usuário está satisfeito Despesas reais versus planejadas continuam aceitaveis?

99 Transição - Milestone Produtos: Versão final do produto Manual do usuário atualizado Modelos atualizados

100 RUP Gerência do Projeto Ambiente Modelagem do Negócio Implementação Teste Análise & Projeto Preliminary Iteration(s) Iter. #1 Fases Core Workflows Iterações Workflows de Suporte Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Deployment Ger. de Configuração Requisitos ElaborationTransitionInceptionConstruction Tempo Workflows de Engenharia


Carregar ppt "Rational Unified Process. O Valor do Software O software é um parte indispensável no mundo moderno O software é um parte indispensável no mundo moderno."

Apresentações semelhantes


Anúncios Google