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