GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO 
DISCIPLINA: ENGENHARIA DE SOFTWARE 
DOCENTE: CICÍLIA RAQUEL 
RATIONAL UNIFIED PROCESS ...
ROTEIRO 
Rational 
Unified 
Process - RUP 
Fases do RUP Workflows 
Pontos 
importantes 
RUP - IBM
RATIONAL UNIFIED PROCESS - RUP
RATIONAL UNIFIED PROCESS - RUP 
• Modelo de processo moderno, derivado do trabalho sobre a UML e do 
Processo Unificado de...
RATIONAL UNIFIED PROCESS - RUP 
FIGURA 1 – FINALIDADE RUP
RATIONAL UNIFIED PROCESS - RUP 
• RUP ≠ Processo Unificado. 
• Processo considerado pesado e preferencialmente aplicável a...
RATIONAL UNIFIED PROCESS - RUP 
• RUP é, por si só, um produto de software. É modular e automatizado. 
• Bom exemplo de mo...
RATIONAL UNIFIED PROCESS - RUP 
FIGURA 2 – MAPA DE PROCESSOS
FASES DO RUP
FASES DO RUP 
• Divisão do projeto em fases. 
• Cada fase precede um marco no projeto. 
• Série de artefatos e critérios d...
CONCEPÇÃO 
• Estabelecer um business case para o sistema; 
• Identificar todas as entidades externas, e definir suas inter...
LCO - ARTEFATOS 
• Visão: documentação dos requisitos, restrições e elementos chave do 
projeto; 
• Riscos: identificar os...
LCO - ARTEFATOS 
• Plano de iteração: Atividades e tarefas divididas, com recursos e 
dependência; 
• Caso de desenvolvime...
CONCEPÇÃO - PERGUNTAS 
• Os stakeholders estão confiantes de que a equipe do projeto entendeu o 
problema a ser resolvido?...
ELABORAÇÃO 
• Desenvolver um entendimento do domínio do problema; 
• Estabelecer um framework de arquitetura para o sistem...
ELABORAÇÃO 
• Modelo de requisitos para o sistema (os casos de uso da UML são 
especificados); 
• Uma descrição de arquite...
LCA - ARTEFATOS 
• Protótipos: explorar a funcionalidade crítica e os cenários significativos; 
• Lista de riscos: atualiz...
LCA - ARTEFATOS 
• Documento de arquitetura de software: visão geral de arquitetura 
abrangente do sistema; 
• Modelo de d...
LCA - ARTEFATOS 
• Visão: compreensão sólida dos casos de uso mais críticos; 
• Plano de desenvolvimento de software: atua...
LCA - ARTEFATOS 
• Conjunto de testes: validar a estabilidade do build para cada release 
executável; 
• Arquitetura para ...
ELABORAÇÃO - PERGUNTAS 
• Os stakeholders tem confiança de que a equipe do projeto tem capacidade 
de implementar a soluçã...
CONSTRUÇÃO 
• Fase essencialmente relacionada ao projeto, programação e teste de 
sistema. 
• As partes do sistema são des...
IOC - ARTEFATOS 
• Sistema: sistema executável pronto para começar o teste beta; 
• Plano de implantação: coordena e lista...
IOC - ARTEFATOS 
• Plano de iteração: Plano de iteração para a próxima fase, concluído e 
analisado; 
• Modelo de design: ...
IOC - ARTEFATOS 
• Modelo de dados: Atualizado com a experiência adquirida no processo de 
construção.
CONSTRUÇÃO - PERGUNTAS 
• O produto está completo o suficiente e com a qualidade mínima aceitável 
para iniciar o teste de...
TRANSIÇÃO 
• Transferência do sistema da comunidade de desenvolvimento para a 
comunidade de usuários. 
• Entrada do siste...
PR - ARTEFATOS 
• Build do produto: sistema concluído; 
• Notas de release: identificam mudanças e erros; 
• Artefatos de ...
PR - ARTEFATOS 
• Material de suporte para o usuário final: aprendizagem, manutenção e 
utilização do sistema.
TRANSIÇÃO - PERGUNTAS 
• Os objetivos do projeto foram atingidos de acordo com os critérios de 
medição? 
• As variações d...
RELAÇÃO RECURSO X TEMPO 
FIGURA 3 – RELAÇÃO RECURSO X TEMPO DAS FASES DO RUP
WORKFLOWS
WORKFLOWS 
• São atividades que ocorrem durante o processo de desenvolvimento; 
• Também chamado de disciplina; 
• Um work...
WORKFLOWS 
• Há 9 Workflows 
• 6 principais 
• 3 de apoio
WORKFLOWS PRINCIPAIS 
 Modelagem de Negócios 
 Casos de uso. Identificação dos processos. 
 Requisitos 
 Identificar i...
WORKFLOWS DE APOIO 
 Gerenciamento de Configuração e Mudança 
 Gerencia as mudanças e planejamento de controle. 
 Geren...
FIGURA 4 –Workflows
RUP - IBM
RUP - IBM 
• Aprimora a produtividade com técnicas e práticas configuráveis comprovadas 
no mercado para adaptar as necess...
PRINCÍPIOS - IBM 
• Adaptar o processo; 
• Balancear as prioridades dos stakeholders; 
• Colaboração entre as equipes; 
• ...
BIBLIOTECA RUP - IBM 
• Projetos pequenos, médios e grandes; 
• Desenvolvimento de aplicativos de pacote ou comerciais pad...
PRINCÍPIOS - IBM 
• Elevar o nível de abstração; 
• Foco na qualidade.
BIBLIOTECA RUP - IBM 
• Modelagem de negócio; 
• Manutenção; 
• Desenvolvimento SOA; 
• Desenvolvimento baseado em ativos;
BIBLIOTECA RUP - IBM 
• Gerenciamento de Compliance; 
• The Departament of Defense; 
• Architecture Framework (DoDAF).
PROCESS ADVISOR 
• IBM Rational Team Unifying Platform; 
• IBM Rational Software Architect; 
• IBM Rational Application De...
PROCESS ADVISOR 
FIGURA N – PROCESS ADVISOR
DÚVIDAS?
OBRIGADO!
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO 
DISCIPLINA: ENGENHARIA DE SOFTWARE 
DOCENTE: CICÍLIA RAQUEL 
RATIONAL UNIFIED PROCESS ...
Próximos SlideShares
Carregando em…5
×

Apresentação RUP

655 visualizações

Publicada em

Apresentação do método RUP.

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
655
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
24
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • 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 é...
  • 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
  • 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
  • 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.
  • 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, ...
  • 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
  • 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
  • 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
  • Para saber se essa fase foi proveitosa, fazemos as seguintes perguntas:
  • 1, 2, 3, e 4 – Os objetivos dessa fase são...
  • 1, 2 e 3 – Ao concluir essa fase deve-se ter...
  • 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
  • 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
  • 1 – Casos de uso que conduzem as decisões de arquitetura e planejamento 3 – Modelo esteja ¾ do modelo conclusivo
  • 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).
  • Podemos avaliar sua consistência e confiabilidade dessa fase através das seguintes perguntas
  • 2 – durante esta fase
  • 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
  • 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
  • A maturação da fase de Construção pode ser mensurada pelos critérios de avaliação descritos abaixo. O formato em perguntas persiste:
  • 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...
  • 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
  • 1 – Material que colabora com a...
  • Através dos Critérios de Avaliação descritos a seguir, podemos avaliar o andamento da fase de Transição.
  • Esses princípios ajudam você a melhorar a produtividade individual e a colaboração de equipe para criar software e sistemas de alta qualidade
  • 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.
  • 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.
  • 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:

    ×