Baixado 90 vezes
Carregado porFernando Nogueira
Apresentação RUP
O documento apresenta o Rational Unified Process (RUP) como um modelo de processo de software iterativo e incremental derivado do trabalho sobre a UML e do Processo Unificado de Desenvolvimento de Software. O RUP divide o projeto em concepção, elaboração, construção e transição, produzindo artefatos em cada fase. Ele também descreve workflows como atividades que ocorrem durante o desenvolvimento e a abordagem do RUP implementada pela IBM.
Mais conteúdo relacionado
![[Caipira Ágil 2015] Dinâmicas para formação de equipes de desenvolvimento de ...](https://cdn.slidesharecdn.com/ss_thumbnails/caipiraagil2015dinmicasparaformaodeequipesdedesenvolvimentodesoftware-150922141109-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
Apresentação RUP
- 1. GRADUAÇÃO EM CIÊNCIADA 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. ROTEIRO Rational Unified Process - RUP Fases do RUP Workflows Pontos importantes RUP - IBM
- 3.
- 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. RATIONAL UNIFIED PROCESS- RUP FIGURA 1 – FINALIDADE RUP
- 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. 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. RATIONAL UNIFIED PROCESS- RUP FIGURA 2 – MAPA DE PROCESSOS
- 9.
- 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. CONCEPÇÃO • Estabelecerum 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. 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. 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. 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. ELABORAÇÃO • Desenvolverum 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. ELABORAÇÃO • Modelode 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. 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. 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. 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. 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. 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. CONSTRUÇÃO • Faseessencialmente 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. 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. 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. IOC - ARTEFATOS • Modelo de dados: Atualizado com a experiência adquirida no processo de construção.
- 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. TRANSIÇÃO • Transferênciado 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. 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. PR - ARTEFATOS • Material de suporte para o usuário final: aprendizagem, manutenção e utilização do sistema.
- 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. RELAÇÃO RECURSO XTEMPO FIGURA 3 – RELAÇÃO RECURSO X TEMPO DAS FASES DO RUP
- 32.
- 33. WORKFLOWS • Sãoatividades 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. WORKFLOWS • Há9 Workflows • 6 principais • 3 de apoio
- 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. 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.
- 38.
- 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. PRINCÍPIOS - IBM • Adaptar o processo; • Balancear as prioridades dos stakeholders; • Colaboração entre as equipes; • Demonstrar valor iterativamente;
- 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. PRINCÍPIOS - IBM • Elevar o nível de abstração; • Foco na qualidade.
- 43. BIBLIOTECA RUP -IBM • Modelagem de negócio; • Manutenção; • Desenvolvimento SOA; • Desenvolvimento baseado em ativos;
- 44. BIBLIOTECA RUP -IBM • Gerenciamento de Compliance; • The Departament of Defense; • Architecture Framework (DoDAF).
- 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. PROCESS ADVISOR FIGURAN – PROCESS ADVISOR
- 47.
- 48.
- 49. GRADUAÇÃO EM CIÊNCIADA 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:
Notas do Editor
- #5 1 – O RUP é um... 2 – Foi...; ficando conhecido também por IRUP 3 – O RUP... em sua concepção ... para ilustrar os processos em ação; utilizando técnicas e práticas aprovadas comercialmente 4 – O objetivo do RUP é...
- #7 1 – Apesar de ser um produto comercial com as mesmas raízes que o Processo Unificado, não deve ser confundido com o Processo Unificado: ele tem estrutura diferente, usando as mesmas fases e as mesmas características básicas, mas as coleções de atividades técnicas são diferentes, e são chamadas de disciplina 2 - Porém o fato de ser amplamente costumizável torna possível que seja adaptado para projetos de qualquer escala 4 – Na metodologia RUP, o ... permitindo um melhor balanceamento entre os objetivos a serem alcançados e as necessidades dos clientes. Esta abordagem é adaptativa, pois permite incorporar facilmente as mudanças de requisitos que ocorrem com o passar do tempo
- #8 1 –e toda a sua metodologia é apoiada por diversas ferramentas de desenvolvimento integradas e vendidas pela IBM através de seus “Rational Suites” 2 – Traz elementos de todos os modelos genéricos de processo, apóia a iteração e ilustra boas práticas de especificação e projeto 3 – Métodos concorrentes no campo da engenharia de software 4 – Dinâmica: Mostra as fases do modelo ao longo do tempo; Estática: Mostra as atividades realizadas no processo Prática: Sugere as boas práticas a serem usadas durante o processo
- #9 As fases e ciclos (iterações), associados à perspectiva dinâmica, estão dispostos horizontalmente, enquanto as atividades estão representadas verticalmente – perspectiva estática. Observe que não existe um critério fixo para a colocação de uma atividade em determinada fase. De espera que, a partir do contexto apresentado na figura, as atividades estejam mais associadas a determinados momentos no projeto, mas nada impede de serem utilizadas em outro instante – outra fase. O gráfico Modelo de Iteração mostra como a ênfase em cada Disciplina varia através do tempo. Nas Iterações iniciais, dedicamos mais tempo aos Requisitos. Já nas Iterações posteriores, gastamos mais tempo com Implementação, por exemplo.
- #11 1 –Divisão do projeto no RUP ao longo do tempo é constituída por fases 2 – ou seja, terminado uma fase, espera-se alcançar alguns objetivos principais – e consequentemente alcançar um importante marco 3 – Além dos objetivos principais, uma série de artefatos é pré-estabelecida juntamente com alguns critérios de avaliação do sucesso da fase 4 – Em resumo, ao se utilizar o RUP, ...
- #12 1 – O objetivo dessa fase é... 2 – (pessoas e sistemas) que irão interagir com o sistema, ... 3 – Com as informações em mãos, a... 4 – ou seja, se ela for de pouca importância; depois dessa fase
- #13 Na fase final encontra-se o marco Objetivos do Ciclo de Vida – LCO: Lifecycle Objetive, espera-se conseguir os seguintes artefatos: 1 – Documento de maior importância nesta fase 2 – Pois como em todo gerenciamento, é essencial conhecer a amplitude e gravidade dos riscos 3 – É realizado a pergunta: é válido realizar o projeto? 4 – Documentação que identifica as... Especifica também estimativas do tempo, RH e custos envolvidos. Valores esses que podem ser brutos, já que ao decorrer do projeto, teremos mais informações sobre ele
- #14 1 – Um conjunto de atividades e tarefas divididas por seqüências de tempo, com recursos atribuídos e dependência de tarefas, para a iteração. 4 – ou seja, se ela for de pouca importância; depois dessa fase 4 – Uma espécie de índice que será utilizado como referência
- #15 Para saber se essa fase foi proveitosa, fazemos as seguintes perguntas:
- #16 1, 2, 3, e 4 – Os objetivos dessa fase são...
- #17 1, 2 e 3 – Ao concluir essa fase deve-se ter...
- #18 A fase de elaboração termina com o marco Ciclo de Vida da Arquitetura, LCA: Lifecycle Architecture; onde se deve ter os seguintes artefatos 1 – São criados a fim de... 3 – considerando questões sobre o ambiente de desenvolvimento, ferramentas e processo
- #19 1 - Deve conter uma descrição detalhada para os casos de usos significativos para a arquitetura, e elementos de design (elementos lógicos a serem definidos como linguagem de programação e banco de dados) 2 – Descreve a... e serve como 4 – produtos liberados – executáveis – elementos dos quais os produtos foram criados – código fonte
- #20 1 – Casos de uso que conduzem as decisões de arquitetura e planejamento 3 – Modelo esteja ¾ do modelo conclusivo
- #21 1 – Testes implementados e executados para... criada nesta fase 2 – Especificações que representam as características fundamentais do sistema de software de automatização de testes (Wthreex, em Referências).
- #22 Podemos avaliar sua consistência e confiabilidade dessa fase através das seguintes perguntas
- #23 2 – durante esta fase
- #24 Ao concluir esta fase, chegamos no marco Capacidade Operacional Inicial, IOC: Initial Operational Capability que deve ter os seguintes artefatos: 1 – Teste geralmente realizado pela comunidade de usuários 3 – construído nessa fase
- #25 1 – A fase de transição 2 – Elementos identificados durante a conclusão de todos os requisitos 3 – processos e ferramentas, com o objetivo de auxiliar a equipe da próxima fase
- #27 A maturação da fase de Construção pode ser mensurada pelos critérios de avaliação descritos abaixo. O formato em perguntas persiste:
- #28 1 – Fase relacionada a... 3 – Isso é algo ignorado na maioria dos modelos de processo de software, mas é, de fato, uma... 4 – Ao concluir essa fase, deverá se ter um...
- #29 Ao final dessa fase encontra-se o marco Release do Produto, PR: Product Release, que deve ter os seguintes artefatos 1 – de acordo com os requisitos do produto, onde o consumidor final utiliza o sistema 2 - em uma versão de um build ou em uma unidade de implantação que tenha sido disponibilizada para uso
- #30 1 – Material que colabora com a...
- #31 Através dos Critérios de Avaliação descritos a seguir, podemos avaliar o andamento da fase de Transição.
- #41 Esses princípios ajudam você a melhorar a produtividade individual e a colaboração de equipe para criar software e sistemas de alta qualidade
- #42 A solução Rational Unified Process fornece uma coleção de processos inovadores que você pode personalizar para abordar um conjunto diverso de necessidades de projeto e estilos de desenvolvimento.
- #46 1: A função Process Advisor habilita sua equipe de desenvolvimento a trabalhar com um processo de desenvolvimento comum configurado para um ambiente específico para os profissionais que usam o Rational Software Architect mostrado aqui. O resultado é uma instrução sensível ao contexto.