347842.ppt
- 1. U P (R U P) 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 5.0 1998 Rational Objectory Process 4.1 1996-1997 Objectory Process 1.0-3.8 1987-1995 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. Processo Unificado • 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 • 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 Release Release Release Release Release Release Produto Iteração Preliminar ... Concepção Elaboração Construção Transição
- 17. Ciclo de Vida Workflows: passos dentro de uma iteração Requisitos Projeto Implementação Testes Análise Modelo Use Case Modelo Análise Modelo Teste Modelo Projeto Modelo Implantação Modelo Implementação
- 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.
- 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).
- 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.
- 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.
- 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.
- 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álise Projeto Implement Teste 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ção Elaboração Construção Transiçã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