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

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

U P U P (R U P) Unified Process Rational Unified Process Processo Unificado de Desenvolvimento de Software Márcia Moita Machado.

Apresentações semelhantes


Apresentação em tema: "U P U P (R U P) Unified Process Rational Unified Process Processo Unificado de Desenvolvimento de Software Márcia Moita Machado."— Transcrição da apresentação:

1 U P U P (R U P) Unified Process Rational Unified Process Processo Unificado de Desenvolvimento de Software Márcia Moita Machado

2 Processo Conjunto de passos, parcialmente ordenados, com a intenção de atingir uma meta. A meta da Engenharia de Software é entregar, de modo eficiente e previsível, um produto de software que atenda às necessidades de seu negócio.

3 UML e Processo A UML é independente de processo. É possível utilizá-la, com vários processos de Engenharia de Software. O RUP consiste em uma maneira de desenvolvimento de software iterativa, centrada à arquitetura e guiada por casos de uso, sendo uma abordagem de ciclo de vida, especialmente adequada à UML.

4 Contexto Necessidade de software cada vez mais complexo: Cliente sempre quer mais, melhor e mais rápido. Não era suficiente apenas a presença de desenvolvedores altamente treinados: Precisava-se de um guia organizacional: um processo.

5 Contexto Os métodos não evoluíam a contento: Havia necessidade de um processo que integrasse as muitas facetas do desenvolvimento. Solução apresentada: Um processo unificado de desenvolvimento de software: UP (Unified Process).

6 Histórico UP Teste Funcional Teste de Desempenho Gerência de Requisitos Gerência de Configuração Engenharia de Negócios Engenharia de Dados Rational Unified Process RationalObjectory Process Objectory Process Abordagem Ericsson Abordagem Rational U M L

7 Processo Unificado UP é um framework* genérico de um processo de desenvolvimento. UP é baseado em componentes. UP utiliza toda da definição da UML. UP é dirigido pelos casos de uso, centrado na arquitetura, iterativo e incremental (conceitos- chave). * Framework: padrão de arquitetura que fornece um template extensível para aplicações em um domínio.

8 O RUP é um processo de engenharia de software bem definido e bem estruturado que define claramente quem é responsável pelo que, como as coisas devem ser feitas e quando fazê- las. O RUP também provê uma estrutura bem definida para o ciclo de vida de um projeto RUP, articulando claramente os marcos essenciais e pontos de decisão. Processo Unificado

9 O RUP é um produto de processo que oferece uma estrutura de processo customizável para a Engenharia de Software. O produto IBM RUP suporta a customização e autoria de processos, e uma vasta variedade de processos, ou configuração de processos, podem ser montadas nele. Essas configurações do RUP podem ser criadas para suportar equipes grandes e pequenas, e técnicas de desenvolvimento disciplinadas ou menos formais. Processo Unificado

10 O produto IBM RUP contém várias configurações e visões de processos prontas que guiam analistas, desenvolvedores, testadores, gerentes de projeto, gerentes de configuração, analistas de dados, e outros membros da equipe de desenvolvimento em como desenvolver o software. Processo Unificado

11 O RUP utiliza a Linguagem Unificada de Modelagem (UML 2) para especificar, modelar e documentar artefatos. A UML é um padrão definido pelo OMG (Object Management Group - organização internacional que aprova padrões abertos para aplicações orientadas a objetos). Por isso se tornou o padrão empresarial para a modelagem orientada a objetos. Processo Unificado

12 Não existe uma maneira exata de aplicar o RUP, pois ele pode ser aplicado de várias formas e será diferente em cada projeto e organização. Porém, existem alguns princípios que podem caracterizar e diferenciar o RUP de outros métodos iterativos: Processo Unificado

13 Atacar os riscos cedo e continuamente; Certificar-se de entregar algo de valor ao cliente; Focar no software executável; Acomodar mudanças cedo; Liberar um executável da arquitetura cedo; Construir o sistema com componentes; Trabalhar junto como um time; Fazer da qualidade um estilo de vida, não algo para depois. Processo Unificado

14 UP repete vários ciclos até a aposentadoria do sistema. Cada ciclo gera um produto liberado para uso. Cada ciclo possui 4 fases: tempo ConcepçãoElaboraçãoConstrução Transição Ciclo de Desenvolvimento - 4 fases: -Concepção (define o escopo do projeto) -Elaboração (define os requisitos e a arquitetura) -Construção (desenvolve o sistema) -Transição (implanta o sistema)

15 Processo Unificado Cada fase é subdividida em iterações. - Um conjunto de artefatos (release) é gerado a cada iteração. - Um milestone (marco) é gerado a cada fase. Iteração Arquitetura...Iteração Desenv Iteração Desenv...Iteração Transição... Release Produto Iteração Preliminar... ConcepçãoElaboraçãoConstrução Transição

16 Processo Unificado

17 Ciclo de Vida Workflows: passos dentro de uma iteração Requisitos Projeto Implementação Testes Análise Modelo Use Case ModeloAnálise ModeloTeste ModeloProjetoModeloImplantação ModeloImplementação

18 Conceitos Relacionados Pessoas:Pessoas: Worker: papel representado por uma pessoa ou grupo no processo de software. Cada worker é responsável por um conjunto de atividades. Projeto:Projeto: Possui uma seqüência de mudanças / várias iterações / um padrão organizacional.

19 Conceitos Relacionados Produto:Produto: Não é apenas código. Artefato: qualquer tipo de informação criada. Artefatos são criados pelos workers em cada uma de suas atividades. Processo:Processo: Direciona o projeto. Template para criação de instâncias (projetos).

20 Conceitos-Chave Processo Dirigido pelos Use Cases Benefícios:Benefícios: use cases associam todos os workflows de forma conjunta. Dirigem várias atividades de desenvolvimento: –Criação e validação da arquitetura do sistema –Criação de casos de teste –Planejamento das iterações –Criação de documentação do usuário –Implantação do sistema Sincronizam conteúdo dos modelos criados em cada workflow.

21 Conceitos-Chave Processo Centrado na Arquitetura Benefícios:Benefícios: –Fornecer uma base sólida para a construção do software. –Melhor compreensão do sistema e organização do desenvolvimento. Descrição: arquitetura envolve elementos de modelo mais importantes - coleção de visões dos modelos do sistema. UP prescreve um refinamento sucessivo à arquitetura. A arquitetura representa a forma, enquanto que os use cases representam funcionalidades. Arquitetura e use cases devem ser balanceados.

22 Conceitos-Chave Processo Iterativo e Incremental Benefícios:Benefícios: –Identificação de riscos é adiantada. –Preparação do Sistema para requisitos que mudam. –Integração contínua (facilita testes e aprendizado). Iteração: mini-projeto - transversal pelos workflows Modelos evoluem nas iterações. Resultado de uma iteração: incremento.

23 Precisa-se de um processo que Defina um guia que controle as atividades do time de desenvolvimento. Direcione as tarefas para desenvolvedores específicos. Especifique que artefatos precisam ser desenvolvidos nas etapas do desenvolvimento. Ofereça critérios para monitorar as atividades e os produtos de um projeto.

24 R U P Processo de Software Unificado (Rational Unified Process) –Processo + Métodos + Linguagem (UML) –Framework para gerar processos especializar o processo para vários tipos diferentes de sistema processo configurável

25 R U P Define um conjunto de atividades –bem definidas –com responsáveis –com artefatos de entrada e saída –com dependências e ordem de execução –com modelo de ciclo de vida –com uma descrição sistemática de como executá-las –UML

26 Características Principais O desenvolvimento de sistemas seguindo o RUP é guiado por casos de uso (use cases) centrado na arquitetura iterativo e incremental

27 Processo Iterativo e Incremental O custo associado ao mini-projeto é menor, logo, se houver erros, o custo de correção também é menor, em relação ao custo do projeto como um todo. Deadlines mais curtos e tarefas mais objetivas tiram mais proveito do esforço de programadores Os requisitos são capturados e refinados durante o desenvolvimento –condizente com a realidade: o cliente pode não ter condição de definir os mesmos por completo no início.

28 Ciclo de Desenvolvimento Elementos genéricos de uma iteração (workflows) Análise de Requisitos AnáliseProjetoImplementTeste SW

29 Ciclo de vida de desenvolvimento de um SW FASES / DISCIPLINAS Fluxos de Trabalho do Processo Modelagem de Negócio Requisitos Análise e Projeto Implementação Teste Entrega Fluxos de Trabalho de Suporte Gerência de Alterações e Config Gerenciamento de Projeto Ambiente ConcepçãoElaboraçãoConstruçãoTransição

30 Concepção Definir –as funções principais do sofware modelo de caso de uso, simplificado –como poderia ser a arquitetura de desenvolvimento para este software tentativa de propor uma arquitetura de desenvolvimento –planejamento e estimativas de custo identificação de riscos planejamento da fase seguinte

31 Concepção lança o projeto Realizar o business case inicial –Delimitar claramente o escopo do projeto –Estimar custo, tempo e retorno do investimento Formular a arquitetura candidata Identificar e eliminar riscos Efetuar o planejamento (cronograma, custos, retorno)

32 Inicialmente Obter uma visão geral do projeto –Capturar o máximo de informação –Organiza-lá –Verificar se algum ponto não foi contemplado –Custo é inversamente proporcional à originalidade do projeto O planejamento inicial é uma tentativa –o melhor entendimento do problema pode muda o planejamento

33 O Time inicial 1 gerente 1 arquiteto 1 ou 2 desenvolvedores 1 engenheiro de teste

34 Definindo o escopo do sistema O que deve ser feito está claro? –não uma idéia, mas uma definição precisa Todos os atores estão definidos? A natureza geral das interfaces com os atores é determinada? Existe uma parte do sistema que pode se comportar como um sistema funcional (subsistema)

35 Resolvendo ambigüidades nos requisitos desta fase Um número limitado de use-cases de requisitos necessários para atingir os objetivos desta fase foram identificados e detalhados? Requisitos suplementares tem sido identificados e detalhados?

36 Estabelecendo uma arquitetura candidata A arquitetura vai ao encontro das necessidades do usuário ou vai de encontro às necessidades? A arquitetura parece funcionar (promissora)? –Não há um protótipo

37 Identificar e eliminar os riscos críticos Todos os riscos foram identificados? Todos os riscos identificados foram eliminados, ou existe um plano para eliminá-los? –modificar os requisitos –plano de cotingência –reduzir risco, minimizar efeito caso ocorra

38 Julgando o business case inicial O business case inicial é bom o suficiente para justificar ir adiante com o projeto?

39 Papel dos workers Analista –identifica os use-cases e atores Arquiteto –prioriza use-cases e seleciona os relevantes para propor a arquitetura candidata Desenvolvedor –implementa o protótipo Engenheiro de testes –planeja testes

40 Capturando os requisitos Listar requisitos candidatos –requisitos de sistemas similares –requisitos obtidos com pesquisas de mercado (sistemas de prateleira) Entender o contexto do sistema –modelo de negócio –identificar use-cases de negócio e técnicos que relatam que processos suportar

41 Capturar requisitos funcionais Capturar requisitos não-funcionais Capturando os requisitos

42 Encontrar atores e use-cases –priorizar use-cases que definem o escopo do projeto e ajudam a planejar a arquitetura –detalhar os use-cases e cenários necessários para que os riscos possam ser identificados e eliminados, e para que uma arquitetura seja proposta Cerca de 10% dos use-cases é detalhada na fase de concepção Capturando os requisitos como use-cases

43 Análise Analisar os requisitos para refiná-los e estruturá-los num modelo que funciona como um modelo de projeto inicial Resulta num modelo de análise inicial –definir precisamente os use-cases –guia a definição da arquitetura candidata aproximadamente 5% da análise é executada na fase de concepção

44 Análise Priorizar os use-cases e/ou cenários –refinar (detalhar) e entendê-los Refina-se aproximadamente a metade dos use-cases detalhados na fase anterior, ou seja 5% dos use-cases do sistema Se for feita análise de classe e pacote é feita minimamente

45 Projeto Projetar a arquitetura candidata –se preciso desenvolver um protótipo do projeto (utilizando alguma técnica de desenvolvimento rápido) validar a os requisitos dos clientes/usuários Iniciar a definição do modelo de projeto –contemplar requisitos funcionas e não-funcionais Projeto de use-cases, classes e pacotes é mínimo (se existir)

46 Implementação e teste Protótipo para validar a arquitetura –se for necessário novas tecnologias projeto sem similares Planejamento de testes –que tipos de testes serão necessários para um sistema dessa natureza

47 Produzindo o Business case inicial Transformar a visão (arquitetura candidata, riscos) em termos econômicos, considerando: –recursos –custos –aceitação do mercado (interna)

48 O valor investido (custo) Usar fórmulas –O tamanho do produto na fase de concepção pode diferir em 50% do tamanho do produto final –estimativa de custo inicial pode diferir em 50% do custo final

49 Retorno de investimento Difícil de ser estimado –geralmente a margem de erro é bem grande –sistemas de prateleira estimativa de cópias a serem vendidas valor de cada cópia –no caso de sistemas internos qual a economia que o sistema trará para a empresa?

50 O que fazer ao final da fase de concepção Baseado no entendimento do projeto, análise de riscos, arquitetura candidata, decidir se o projeto deve ou não continuar Planejar a fase de Elaboração –descrever de 80% dos use-cases –analisar metade destes –implementar 10%

51 Resultado da fase de concepção primeira versão do modelo de negócio (descreve o contexto do sistema) primeira versão dos modelos de use-case primeira versão da arquitetura candidata protótipo demostrando o uso do sistema lista de riscos e suas prioridade planejamento geral das demais fases primeira versão do business case (estimativas e retorno)

52 Elaboração Identificar a maioria dos casos de uso –realizar os casos de uso mais críticos modelo de análise Projetar e validar a arquitetura do sistema –o esqueleto do sistema com alguns músculos Planejar atividades e estimar recursos necessários para completar o projeto

53 Introdução Capturar quase todos use cases; Estabelecer uma arquitetura sólida para guiar as fases de construção e transição; Monitorar riscos e seu impacto no caso de negócio; Refinar plano de projeto.

54 No início da elaboração Planejando a fase de elaboração; montando a equipe; modificando o ambiente de implementação; estabelecer critério de avaliação; –Estender os requisitos; –Estabelecer a linha base da arquitetura; –Atenuar riscos significativos; –Julgar o valor do Caso de Negócio

55 Típico workflow de iteração da Elaboração –Atividades em paralelo: core workflows || planejamento das iterações || avaliação || ajuste do ambiente de desenvolvimento; –Capturar e refinar maior parte dos requisitos; –Desenvolver linha base da arquitetura; –Iterar enquanto a equipe é pequena

56 –Use cases representando riscos críticos e importantes do ponto de vista da arquitetura (80%); –Cobertura maior dos use cases para permitir oferta mais realista; –Achar linha base da arquitetura, considerando qualidade e extensibilidade de 10 % dos use cases. Executar core workflows - requisitos a teste

57 Capturar Requisitos Achar use cases e atores –80% dos use cases prototipar interfaces gráficas –geralmente não necessário priorizar use cases –Considerar riscos e importância a nível de arquitetura;

58 Capturar Requisitos detalhar use cases –cenários mais relevantes estruturar modelo de use cases –mais extensível e fácil de manter Renegociar requisitos com cliente –pouca diferença semântica –mais tratável pela arquitetura –Menor custo e maior qualidade

59 Análise arquitetural –particionamento do sistema em pacotes de análise –pode usar arquitetura em camadas –usa use cases, glossário e conhecimento do domínio análise de use case –mais relevantes para arquitetura ( 20% - 40% do total) –descrição usando classes e responsabilidades análise de classe –refinar classes identificadas análise de pacote –refinar pacotes identificados na análise arquitetural Análise

60 Projeto da arquitetura –arquitetura em camadas; –subsistemas e suas interfaces; –classes de projeto mais importantes para arquitetura; –nós e configuração de rede (se o sistema for distribuído). projeto de use cases mais importantes para arquitetura projetar classe projetar subsistema Projeto

61 Implementação arquitetural –identificação dos componentes para implementar subsistema de serviço; –mapeamento de componentes a nós na rede de computadores. implementação de classe e subsistema integrar sistema –incrementalmente numa seqüência ferramenta controlando linha base da arquitetura Implementação

62 Planejar teste –definir objetivos projetar teste –caso de teste e procedimentos executar teste de integração –nível de builds (construções) executar teste de sistema –linha base da arquitetura Teste

63 –Preparar a oferta linha base da arquitetura: estimativa mais precisa –Atualizar o retorno sobre Investimento sabe-se o custo da construção e da transição cálculo do retorno é mais difícil Caso de Negócio

64 –Critérios definidos no plano de iteração foram alcançados? –Atividades não terminadas seguem nas próximas iterações. Avaliar iterações na Elaboração

65 Planejando a construção Quantidade de iterações planejar investigação dos riscos rever ordem de realização dos use cases e cenários identificar oportunidades de paralelismo (interfaces)

66 Construção Construir o software –preencher o esqueleto com todos os músculos –implementar o sistema por completo Testar o sistema Gerar uma versão beta Planejar a transição

67 Fase de Construção em Resumo Início a partir do executável da base arquitetural Desenvolvimento de um produto pronto para operação inicial (beta) Ênfase no desenvolvimento

68 Logo cedo na fase de Construção... Gerente planejou construção ainda na fase anterior e recebe autorização para continuar O plano pode ser modificado por dois fatores: –Gap possível entre elaboração e construção –Finanças e cronograma podem ser alterados Alocação de recursos –Aumento significativo de pessoas Definição do critério de avaliação

69 Iteration Workflow - Construção 4 atividades principais em paralelo –5 workflows principais –Planejar iterações –Business case (acompanhamento) –Avaliação Agora a ênfase é em completar as realizações dos use cases, projetar as classes e subsistemas, implementá-los como componentes, fazendo testes individuais ou em builds.

70 Requisitos Achar atores e use cases –Apenas uma pequena fração restante Prototipar interface com o usuário –Agora, grande ênfase Priorizar use cases –Apenas os encontrados aqui Detalhar use cases –Completo (todos os use cases) Estruturar modelo –Poucas mudanças

71 Análise (Opcional) Análise arquitetural –Apenas eventuais atualizações Análise de use cases –Completa com todos os use cases Análise de classes –Refina todas as classes Análise de pacotes –Refina todos os pacotes de análise

72 Projeto Projeto arquitetural –Adição de poucos elementos Projeto use cases –Completa com todos os use cases Projeto classes –Refina todas as classes de projeto Projeto subsistemas –Refina todos os subsistemas

73 Implementação Implementação Arquitetural –Apenas atualização Implementar classe/subsistema –Completo, todos os componentes Realizar testes de unidade –Teste dos componentes implementados Integrar sistema –Criar plano de integração em cada iteração –Juntar componentes de acordo com o plano

74 Testes Planejar testes –Objetivos estabelecidos para os testes de builds e do sistema Projetar testes –Criar casos e procedimentos de teste para um conjunto de builds em cada iteração Executar testes de integração/sistema –Builds/sistema a cada iteração Avaliar testes –Atingiram-se os objetivos?

75 Controlando o business case Comparar progresso real com o planejado, acompanhando cronograma, orçamento e esforço (baseado em métricas) Atualizar o documento, se necessário

76 Avaliar as iterações Revisar o que foi executado, com o critério de avaliação Determinar se o build está pronto para a próxima iteração

77 Planejando a fase de transição Planejamento com menos detalhes que nas outras fases Não se sabe como vai ser feedback dos usuários

78 Deliverables - construção Plano de projeto para a transição Software executável - build final da construção Todos os artefatos (modelos) Descrição da arquitetura mantida e atualizada Business case, com mudanças refletidas Manual de usuário preliminar

79 Transição Evolução do produto da versão beta para a versão final –alguns usuários utilizam o sistema e reportam defeitos e sugestões de melhorias –correção dos erros –prover treinamento e assistência ao usuário (help) Classificar os problemas que –justificam uma versão delta imediata –serão corrigidos na próxima versão

80 Fluxos de Trabalho de Processo do RUP

81 Modelos – tipo mais importante de artefato do RUP


Carregar ppt "U P U P (R U P) Unified Process Rational Unified Process Processo Unificado de Desenvolvimento de Software Márcia Moita Machado."

Apresentações semelhantes


Anúncios Google