U PU P (R U P)
Rational Unified ProcessUnified 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 FuncionalTeste de DesempenhoGerência de RequisitosGerência de ConfiguraçãoEngenharia de NegóciosEngenharia de Dados
Rational Unified Process 5.01998
Rational Objectory Process 4.11996-1997
Objectory Process 1.0-3.81987-1995
Abordagem Ericsson
Abordagem RationalU 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 amodelagem 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çãoArquitetura
... IteraçãoDesenv
IteraçãoDesenv
... IteraçãoTransição
...
Release Release Release Release Release Release Release Produto
IteraçãoPreliminar
...
Concepção Elaboração Construção Transição
Processo Unificado
Ciclo de VidaWorkflows: passos dentro de uma iteração
RequisitosRequisitos
ProjetoProjeto
ImplementaçãoImplementação
TestesTestes
AnáliseAnálise
Modelo Modelo Use CaseUse Case
Modelo Modelo AnáliseAnálise
ModeloModeloTesteTeste
ModeloModeloProjetoProjeto
ModeloModeloImplantaçãoImplantação
ModeloModeloImplementaçãoImplementação
Conceitos Relacionados
• Pessoas:Pessoas:Worker: papel representado por uma pessoa ou grupo no processo de software.
Cada worker é responsável por um conjunto de atividades.
• Projeto:Projeto:Possui uma seqüência de mudanças / várias iterações / um padrão organizacional.
Conceitos Relacionados
• Produto: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:Processo:Direciona o projeto.
Template para criação de instâncias (projetos).
Conceitos-ChaveProcesso Dirigido pelos Use Cases
• Benefícios: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-ChaveProcesso Centrado na Arquitetura
• Benefícios: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-ChaveProcesso Iterativo e Incremental
• Benefícios: 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 PR 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çãoConcepçã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üidadesnos 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çãoElaboraçã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çãoConstruçã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 ResumoFase 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çãoTransiçã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
Top Related