U P (R U P)
Rational Unified Process
Processo Unificado de Desenvolvimento de Software
Márcia Moita Machado
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.
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.
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.
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).
Histórico UP
Rational Unified Process 5.0
1998
Rational
Objectory Process 4.1
1996-1997
UML
Abordagem Rational
Objectory Process 1.0-3.8
1987-1995
Abordagem Ericsson
Teste Funcional
Teste de Desempenho
Gerência de Requisitos
Gerência de Configuração
Engenharia de Negócios
Engenharia de Dados
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 (conceitoschave).
* Framework: padrão de arquitetura que fornece um template extensível
para aplicações em um domínio.
Processo Unificado
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
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
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
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
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
•
•
•
•
•
•
•
•
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
• 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)
• UP repete vários ciclos até a aposentadoria do sistema.
Cada ciclo gera um produto liberado para uso.
• Cada ciclo possui 4 fases:
Concepção
tempo
Elaboração
Construção
Transição
Processo Unificado
• Cada fase é subdividida em iterações.
Concepção
Iteração
Preliminar
...
Elaboração
Iteração
Arquitetura
Release
...
Construção
Iteração
Desenv
Iteração
Desenv
Release Release Release Release
Transição
...
Iteração
Transição
Release
Release
- Um conjunto de artefatos (release) é gerado a cada iteração.
- Um milestone (marco) é gerado a cada fase.
...
Produto
Processo Unificado
Ciclo de Vida
Workflows: passos dentro de uma iteração
Requisitos
Análise
Projeto
Implementação
Testes
Modelo
Use Case
Modelo
Análise
Modelo
Projeto
Modelo
Implantação
Modelo
Implementação
Modelo
Teste
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.
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).
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.
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.
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.
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.
RUP
• 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
RUP
• 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
Características Principais
O desenvolvimento de sistemas seguindo o RUP é
guiado por casos de uso (use cases)
centrado na arquitetura
iterativo e incremental
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.
Ciclo de Desenvolvimento
• Elementos genéricos de uma iteração (workflows)
Análise de
Requisitos
Análise
Projeto
SW
Implement
Teste
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
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
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)
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
O Time inicial
•
•
•
•
1 gerente
1 arquiteto
1 ou 2 desenvolvedores
1 engenheiro de teste
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)
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?
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
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
Julgando o business case inicial
• O business case inicial é bom o
suficiente para justificar ir adiante com o
projeto?
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
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
Capturando os requisitos
• Capturar requisitos funcionais
• Capturar requisitos não-funcionais
Capturando os requisitos como use-cases
• 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
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
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
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)
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
Produzindo o Business case inicial
• Transformar a visão (arquitetura
candidata, riscos) em termos
econômicos, considerando:
– recursos
– custos
– aceitação do mercado (interna)
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
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?
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%
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)
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
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.
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
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
Executar core workflows - requisitos a teste
– 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.
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;
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
Análise
• 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
Projeto
• 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
Implementação
• 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
Teste
• 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
Caso de Negócio
– 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
Avaliar iterações na Elaboração
– Critérios definidos no plano de iteração foram
alcançados?
– Atividades não terminadas seguem nas próximas
iterações.
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)
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
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
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
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.
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
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
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
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
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?
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
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
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
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
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
Fluxos de Trabalho de Processo do RUP
Modelos – tipo mais importante de artefato do
RUP