U P (R U P) Rational Unified Process

Apresentação em tema: "U P (R U P) Rational Unified Process"— Transcrição da apresentação:

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

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. 2

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

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. 4

5 Contexto Os métodos não evoluíam a contento: Solução apresentada:
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). 5

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

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

8 Processo Unificado 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. 8

9 Processo Unificado 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. 9

10 Processo Unificado 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. 10

11 Processo Unificado 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. 11

12 Processo Unificado 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: 12

13 Processo Unificado 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. 13

14 Processo Unificado 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) 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ção Elaboração Construção Transição 14

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

16 Processo Unificado 16

17 Ciclo de Vida Workflows: passos dentro de uma iteração Requisitos
Projeto Implementação Testes Análise Modelo Use Case Teste Implantação 17

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

19 Conceitos Relacionados
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: Direciona o projeto. Template para criação de instâncias (projetos). 19

20 Conceitos-Chave Processo Dirigido pelos Use Cases
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. 20

21 Conceitos-Chave Processo Centrado na Arquitetura
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. 21

22 Conceitos-Chave Processo Iterativo e Incremental
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. 22

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. 23

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 24

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 25

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

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. 27

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

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ção Elaboração Construção Transição 29

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 Arquiteto Desenvolvedor
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 Capturando os requisitos
Capturar requisitos funcionais Capturar requisitos não-funcionais

42 Capturando os requisitos como use-cases
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

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 Executar core workflows - requisitos a teste
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.

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 estruturar modelo de 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 Análise arquitetural análise de use case análise de classe
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

60 Projeto 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

61 Implementação 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

62 Teste Planejar teste projetar teste executar teste de integração
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

63 Caso de Negócio 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

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

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 Análise de use cases
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 Projeto use cases Projeto classes
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 Implementar classe/subsistema
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 Projetar 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
80

81 Modelos – tipo mais importante de artefato do RUP
81