O documento descreve o Processo Unificado (RUP), apresentando seus principais conceitos e características. O RUP é um framework genérico e customizável para gerenciar o processo de engenharia de software, utilizando a UML para modelagem e definindo um ciclo de vida iterativo e incremental guiado por casos de uso e centrado na arquitetura.

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

16. Processo Unificado

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