SlideShare uma empresa Scribd logo
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
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
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.
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
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)
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
Processo Unificado
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
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.
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
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
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 Implement Teste
SW
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
• Capturar requisitos funcionais
• Capturar requisitos não-funcionais
Capturando os requisitos
• 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
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
– 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
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 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
• 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
• 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
• 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
– 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
– 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
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

Mais conteúdo relacionado

Semelhante a 347842.ppt

Aula 3 - Processos de Software.pdf
Aula 3 - Processos de Software.pdfAula 3 - Processos de Software.pdf
Aula 3 - Processos de Software.pdf
FChico2
 
IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
Robson Silva Espig
 
[IFMG][ENGENHARIA DE SOFTWARE] - RUP
[IFMG][ENGENHARIA DE SOFTWARE] - RUP[IFMG][ENGENHARIA DE SOFTWARE] - RUP
[IFMG][ENGENHARIA DE SOFTWARE] - RUP
Universidade Federal de Minas Gerais
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
Elaine Cecília Gatto
 
Es capítulo 2 - processos de software
Es   capítulo 2  - processos de softwareEs   capítulo 2  - processos de software
Es capítulo 2 - processos de software
Felipe Oliveira
 
Organizando demandas de desenvolvimento com o microsoft team foundation server
Organizando demandas de desenvolvimento com o microsoft team foundation serverOrganizando demandas de desenvolvimento com o microsoft team foundation server
Organizando demandas de desenvolvimento com o microsoft team foundation server
Vinicius Moura
 
03 Modelo de processo de software
03 Modelo de processo de software03 Modelo de processo de software
03 Modelo de processo de software
Waldemar Roberti
 
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Cloves da Rocha
 
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile AppAula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Cloves da Rocha
 
FES_SENAIPR_Processos.pdf
FES_SENAIPR_Processos.pdfFES_SENAIPR_Processos.pdf
FES_SENAIPR_Processos.pdf
FChico2
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
wilsonguns
 
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
a29398
 
Rational Unfied Process
Rational Unfied ProcessRational Unfied Process
Rational Unfied Process
Jerônimo Medina Madruga
 
Modelos de Processo de Software Parte 5
Modelos de Processo de Software Parte 5Modelos de Processo de Software Parte 5
Modelos de Processo de Software Parte 5
Elaine Cecília Gatto
 
Aula03_04_ModelosProcessos.pdf
Aula03_04_ModelosProcessos.pdfAula03_04_ModelosProcessos.pdf
Aula03_04_ModelosProcessos.pdf
Jadna Almeida
 
Aula 2 - Modelos de processos
Aula 2 -  Modelos de processosAula 2 -  Modelos de processos
Aula 2 - Modelos de processos
Leinylson Fontinele
 
2 engenharia de software
2   engenharia de software2   engenharia de software
2 engenharia de software
Felipe Bugov
 
Aula 2 - Processos de Software
Aula 2 - Processos de SoftwareAula 2 - Processos de Software
Aula 2 - Processos de Software
Rudson Kiyoshi Souza Carvalho
 
Ciclo de Vida
Ciclo de VidaCiclo de Vida
Ciclo de Vida
Wagner Zaparoli
 
Modelos de desenvolvimento de software (dino brasilis)
Modelos de desenvolvimento de software (dino brasilis)Modelos de desenvolvimento de software (dino brasilis)
Modelos de desenvolvimento de software (dino brasilis)
djadrianodez
 

Semelhante a 347842.ppt (20)

Aula 3 - Processos de Software.pdf
Aula 3 - Processos de Software.pdfAula 3 - Processos de Software.pdf
Aula 3 - Processos de Software.pdf
 
IBM Rational Unified Process
IBM Rational Unified ProcessIBM Rational Unified Process
IBM Rational Unified Process
 
[IFMG][ENGENHARIA DE SOFTWARE] - RUP
[IFMG][ENGENHARIA DE SOFTWARE] - RUP[IFMG][ENGENHARIA DE SOFTWARE] - RUP
[IFMG][ENGENHARIA DE SOFTWARE] - RUP
 
Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1Modelos de Processo de Software Parte 1
Modelos de Processo de Software Parte 1
 
Es capítulo 2 - processos de software
Es   capítulo 2  - processos de softwareEs   capítulo 2  - processos de software
Es capítulo 2 - processos de software
 
Organizando demandas de desenvolvimento com o microsoft team foundation server
Organizando demandas de desenvolvimento com o microsoft team foundation serverOrganizando demandas de desenvolvimento com o microsoft team foundation server
Organizando demandas de desenvolvimento com o microsoft team foundation server
 
03 Modelo de processo de software
03 Modelo de processo de software03 Modelo de processo de software
03 Modelo de processo de software
 
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
Aula Modelos de Processos Tradicionais para Desenvolvimento de Software
 
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile AppAula - Modelos de Processos de Desenvolvimento de Software / Mobile App
Aula - Modelos de Processos de Desenvolvimento de Software / Mobile App
 
FES_SENAIPR_Processos.pdf
FES_SENAIPR_Processos.pdfFES_SENAIPR_Processos.pdf
FES_SENAIPR_Processos.pdf
 
Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9Engenharia de-software-1217199594686494-9
Engenharia de-software-1217199594686494-9
 
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf1 - APS – Iniciação Desenvolvimento Requisitos.pdf
1 - APS – Iniciação Desenvolvimento Requisitos.pdf
 
Rational Unfied Process
Rational Unfied ProcessRational Unfied Process
Rational Unfied Process
 
Modelos de Processo de Software Parte 5
Modelos de Processo de Software Parte 5Modelos de Processo de Software Parte 5
Modelos de Processo de Software Parte 5
 
Aula03_04_ModelosProcessos.pdf
Aula03_04_ModelosProcessos.pdfAula03_04_ModelosProcessos.pdf
Aula03_04_ModelosProcessos.pdf
 
Aula 2 - Modelos de processos
Aula 2 -  Modelos de processosAula 2 -  Modelos de processos
Aula 2 - Modelos de processos
 
2 engenharia de software
2   engenharia de software2   engenharia de software
2 engenharia de software
 
Aula 2 - Processos de Software
Aula 2 - Processos de SoftwareAula 2 - Processos de Software
Aula 2 - Processos de Software
 
Ciclo de Vida
Ciclo de VidaCiclo de Vida
Ciclo de Vida
 
Modelos de desenvolvimento de software (dino brasilis)
Modelos de desenvolvimento de software (dino brasilis)Modelos de desenvolvimento de software (dino brasilis)
Modelos de desenvolvimento de software (dino brasilis)
 

347842.ppt

  • 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
  • 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