Apresentação RUP

1.000 visualizações

Publicada em

Apresentação do método RUP.

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Apresentação RUP

  1. 1. GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DISCIPLINA: ENGENHARIA DE SOFTWARE DOCENTE: CICÍLIA RAQUEL RATIONAL UNIFIED PROCESS - RUP MODELOS DE PROCESSO DE SOFTWARE DISCENTES: FERNANDO NOGUEIRA, GILBERTO MARIANO, PRICILA MELO
  2. 2. ROTEIRO Rational Unified Process - RUP Fases do RUP Workflows Pontos importantes RUP - IBM
  3. 3. RATIONAL UNIFIED PROCESS - RUP
  4. 4. RATIONAL UNIFIED PROCESS - RUP • Modelo de processo moderno, derivado do trabalho sobre a UML e do Processo Unificado de Desenvolvimento de Software. • Criado pela Rational Software Corporation, adquirida pela IBM. • Usa uma abordagem da orientação a objetos; é projetado e documentado utilizando a notação UML (Unified Modeling Language). • Produzir software de qualidade, atendendo aos requisitos estabelecidos pelo cliente, e respeitando um orçamento e cronograma previamente definidos.
  5. 5. RATIONAL UNIFIED PROCESS - RUP FIGURA 1 – FINALIDADE RUP
  6. 6. RATIONAL UNIFIED PROCESS - RUP • RUP ≠ Processo Unificado. • Processo considerado pesado e preferencialmente aplicável a grandes equipes e a grandes projetos. • O planejamento é baseado num conjunto de processos, que buscam atingir certos objetivos no tempo. • Projeto é abordado de forma dinâmica e iterativa.
  7. 7. RATIONAL UNIFIED PROCESS - RUP • RUP é, por si só, um produto de software. É modular e automatizado. • Bom exemplo de modelo híbrido de processo. • Cleanroom, XP(Extreme Programming), Scrum, FDD (Feature Driven Development). • Geralmente descrito a partir de três perspectivas: • Perspectiva dinâmica; • Perspectiva estática; • Perspectiva prática.
  8. 8. RATIONAL UNIFIED PROCESS - RUP FIGURA 2 – MAPA DE PROCESSOS
  9. 9. FASES DO RUP
  10. 10. FASES DO RUP • Divisão do projeto em fases. • Cada fase precede um marco no projeto. • Série de artefatos e critérios de avaliação de sucesso são pré-estabelecidos. • Processo de software é tratado em fases que, quando finalizadas, atingem marcos, que serão validados através de diretivas, e trarão uma série de produtos necessários para a próxima etapa.
  11. 11. CONCEPÇÃO • Estabelecer um business case para o sistema; • Identificar todas as entidades externas, e definir suas interações. • Contribuição do sistema com o negócio é avaliada; • Dependendo da contribuição, o projeto pode até ser cancelado.
  12. 12. LCO - ARTEFATOS • Visão: documentação dos requisitos, restrições e elementos chave do projeto; • Riscos: identificar os riscos do projeto; • Caso de negócio: documento que contém as informações e suposições sobre o retorno do investimento; • Plano de desenvolvimento de software: Fases iniciais, duração e objetivo;
  13. 13. LCO - ARTEFATOS • Plano de iteração: Atividades e tarefas divididas, com recursos e dependência; • Caso de desenvolvimento: descrição do processo de desenvolvimento para servir de guia; • Ferramentas: tudo que será necessário para o desenvolvimento do software; • Glossário: termos importantes no projeto.
  14. 14. CONCEPÇÃO - PERGUNTAS • Os stakeholders estão confiantes de que a equipe do projeto entendeu o problema a ser resolvido? • Os stakeholders estão confiantes de que os riscos mais críticos foram identificados? • As estimativas iniciais foram refinadas com base no conhecimento adquirido? • As estimativas de custo e prazo são aceitáveis para os stakeholders?
  15. 15. ELABORAÇÃO • Desenvolver um entendimento do domínio do problema; • Estabelecer um framework de arquitetura para o sistema; • Desenvolver o plano de projeto; • Identificar os principais riscos do projeto.
  16. 16. ELABORAÇÃO • Modelo de requisitos para o sistema (os casos de uso da UML são especificados); • Uma descrição de arquitetura; • Um plano de desenvolvimento para o software.
  17. 17. LCA - ARTEFATOS • Protótipos: explorar a funcionalidade crítica e os cenários significativos; • Lista de riscos: atualização e revisão dos riscos identificados na fase anterior; • Caso de desenvolvimento: atualização do artefato já elaborado; • Ferramentas: ferramentas pertinentes ao trabalho de elaboração são instaladas;
  18. 18. LCA - ARTEFATOS • Documento de arquitetura de software: visão geral de arquitetura abrangente do sistema; • Modelo de design: realização dos casos de uso; guia para o modelo de implementação; • Modelo de dados: descreve a representação lógica e física dos dados persistentes no sistema; • Modelo de implementação: conjunto de componentes;
  19. 19. LCA - ARTEFATOS • Visão: compreensão sólida dos casos de uso mais críticos; • Plano de desenvolvimento de software: atualizar o plano existente com objetivo de abranger as próximas fases; • Modelo de casos de uso: um modelo de casos de uso praticamente concluído; • Especificações suplementares: Os requisitos suplementares são documentados e analisados;
  20. 20. LCA - ARTEFATOS • Conjunto de testes: validar a estabilidade do build para cada release executável; • Arquitetura para automatização de testes: composição de diversos elementos de automatização de testes e suas especificações.
  21. 21. ELABORAÇÃO - PERGUNTAS • Os stakeholders tem confiança de que a equipe do projeto tem capacidade de implementar a solução proposta? • A arquitetura reflete os requisitos funcionais? • Todos os riscos foram eliminados ou mitigados? • As variações de custo e prazo são aceitáveis para os stakeholders?
  22. 22. CONSTRUÇÃO • Fase essencialmente relacionada ao projeto, programação e teste de sistema. • As partes do sistema são desenvolvidas paralelamente e integradas. • Ao término dessa fase deve-se ter: • Um sistema de software em funcionamento; • Documentação associada pronta para ser liberada para os usuários.
  23. 23. IOC - ARTEFATOS • Sistema: sistema executável pronto para começar o teste beta; • Plano de implantação: coordena e lista as atividades envolvidas na transferência do sistema da comunidade de desenvolvimento para a comunidade de usuários; • Conjunto de testes: testes implementados e executados de cada release; • Materiais de treinamento: manuais do usuário e outros materiais de treinamento;
  24. 24. IOC - ARTEFATOS • Plano de iteração: Plano de iteração para a próxima fase, concluído e analisado; • Modelo de design: atualizado com novos elementos de design; • Caso de desenvolvimento: refinamento do ambiente de desenvolvimento; • Ferramentas: ferramentas da fase de construção;
  25. 25. IOC - ARTEFATOS • Modelo de dados: Atualizado com a experiência adquirida no processo de construção.
  26. 26. CONSTRUÇÃO - PERGUNTAS • O produto está completo o suficiente e com a qualidade mínima aceitável para iniciar o teste de aceitação? • O usuário e a organização estão preparados para o início da implementação (transição do sistema)? • As variações de custo e prazo são aceitáveis para os stakeholders?
  27. 27. TRANSIÇÃO • Transferência do sistema da comunidade de desenvolvimento para a comunidade de usuários. • Entrada do sistema em funcionamento no ambiente real. • Atividade onerosa e, às vezes, problemática. • Sistema de software documentado e funcionando corretamente em seu ambiente operacional.
  28. 28. PR - ARTEFATOS • Build do produto: sistema concluído; • Notas de release: identificam mudanças e erros; • Artefatos de instalação: elementos de instalação do software, como também a documentação associada; • Material de treinamento: a partir dele o cliente poderá utilizar o sistema;
  29. 29. PR - ARTEFATOS • Material de suporte para o usuário final: aprendizagem, manutenção e utilização do sistema.
  30. 30. TRANSIÇÃO - PERGUNTAS • Os objetivos do projeto foram atingidos de acordo com os critérios de medição? • As variações de custo e prazo são aceitáveis pelos stakeholders? • Os usuários estão satisfeitos?
  31. 31. RELAÇÃO RECURSO X TEMPO FIGURA 3 – RELAÇÃO RECURSO X TEMPO DAS FASES DO RUP
  32. 32. WORKFLOWS
  33. 33. WORKFLOWS • São atividades que ocorrem durante o processo de desenvolvimento; • Também chamado de disciplina; • Um workflow mostra todas as atividades que deverá realizar para construir um artefato. • Não são temporais ou fixos nas fases.
  34. 34. WORKFLOWS • Há 9 Workflows • 6 principais • 3 de apoio
  35. 35. WORKFLOWS PRINCIPAIS  Modelagem de Negócios  Casos de uso. Identificação dos processos.  Requisitos  Identificar indivíduos, restrições, fronteiras.  Análise e Design  Arquitetura, componentes, BD.  Implementação  Teste  Implantação  Aceitação, suporte.
  36. 36. WORKFLOWS DE APOIO  Gerenciamento de Configuração e Mudança  Gerencia as mudanças e planejamento de controle.  Gerenciamento de Projeto  Gerencia o desenvolvimento.  Ambiente  Ferramentas.
  37. 37. FIGURA 4 –Workflows
  38. 38. RUP - IBM
  39. 39. RUP - IBM • Aprimora a produtividade com técnicas e práticas configuráveis comprovadas no mercado para adaptar as necessidades de projetos individuais; • Suporta colaboração de equipe e profissionais individuais com guias de contexto através de regiões geográficas e funções; • Possibilita facilmente a mitigação de risco usando processos iterativos centrados em prioridades de negócios e necessidades dos stakeholders; • Promove transformação organizacional com serviços de educação, consultoria extensiva e um ecossistema de Parceiros de Negócios IBM.
  40. 40. PRINCÍPIOS - IBM • Adaptar o processo; • Balancear as prioridades dos stakeholders; • Colaboração entre as equipes; • Demonstrar valor iterativamente;
  41. 41. BIBLIOTECA RUP - IBM • Projetos pequenos, médios e grandes; • Desenvolvimento de aplicativos de pacote ou comerciais padrão; • Desenvolvimento de aplicativos Mainframe e IBM System Z; • Engenharia de sistemas;
  42. 42. PRINCÍPIOS - IBM • Elevar o nível de abstração; • Foco na qualidade.
  43. 43. BIBLIOTECA RUP - IBM • Modelagem de negócio; • Manutenção; • Desenvolvimento SOA; • Desenvolvimento baseado em ativos;
  44. 44. BIBLIOTECA RUP - IBM • Gerenciamento de Compliance; • The Departament of Defense; • Architecture Framework (DoDAF).
  45. 45. PROCESS ADVISOR • IBM Rational Team Unifying Platform; • IBM Rational Software Architect; • IBM Rational Application Developer; • IBM Rational Functional Tester; • IBM Rational Performance Tester.
  46. 46. PROCESS ADVISOR FIGURA N – PROCESS ADVISOR
  47. 47. DÚVIDAS?
  48. 48. OBRIGADO!
  49. 49. GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO DISCIPLINA: ENGENHARIA DE SOFTWARE DOCENTE: CICÍLIA RAQUEL RATIONAL UNIFIED PROCESS - RUP FERNANDO NOGUEIRA: fernando.nogueiraq@gmail.com GILBERTO MARIANO: gilbermariano@gmail.com PRICILA MELO:

×