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. ROTEIRO
Rational
Unified
Process - RUP
Fases do RUP Workflows
Pontos
importantes
RUP - IBM

3. RATIONAL UNIFIED PROCESS - RUP

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. FASES DO RUP

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
• 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. 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
• 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. 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. 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
• 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. 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ê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. 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 X TEMPO
FIGURA 3 – RELAÇÃO RECURSO X TEMPO DAS FASES DO RUP

32. WORKFLOWS

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. 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. FIGURA 4 –Workflows

38. RUP - IBM

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
FIGURA N – PROCESS ADVISOR

47. DÚVIDAS?

48. OBRIGADO!

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: