Rational Unified Process

O Valor do Software O software é um parte indispensável no mundo modernoO software é um parte indispensável no mundo moderno

Faz com que as sociedades se conectem melhor Nos ajuda a criar, acessar e visualizar informação em

formas e modos não concebíveis anteriormente. Boa notíciaBoa notícia

A economia mundial depende cada vez mais de software.

Notícia ruimNotícia ruim O pessoal qualificado não consegue acompanhar o

mesmo ritmo da demanda. Softwares estão crescendo em importância, tamanho,

complexidade e distribuição. ResultadoResultado

A construção e manutenção de software são difíceis.

Sintomas e Origem das Causas de Problemas de Desenvolvimento de Software

Entendimento impreciso das necessidades dos Entendimento impreciso das necessidades dos usuáriosusuários

Falta de habilidade de lidar com a necessidade Falta de habilidade de lidar com a necessidade de mudançasde mudanças

Uma descoberta tardia de uma séria falha de Uma descoberta tardia de uma séria falha de projetoprojeto

Software com baixa qualidadeSoftware com baixa qualidade Um processo não confiável de construçãoUm processo não confiável de construção Arquitetura frágilArquitetura frágil Testes insuficientesTestes insuficientes Falha no ataque aos riscosFalha no ataque aos riscos

Processo Define Define quemquem irá fazer o irá fazer o queque, , quandoquando, e , e comocomo

será alcançado o objetivo.será alcançado o objetivo.

Requisitos novos

ou alterados

Sistema novo

ou melhoradoProcesso de Engenharia

de Software

Processo Regras

Prover um guia para as atividades Especificar que artefatos e quando

devem ser desenvolvidos Direcionar as tarefas dos grupos e

indivíduos Oferecer um critério para monitorar e

medir o processo

Melhores Práticas Desenvolver software iterativamenteDesenvolver software iterativamente Gerenciar requisitosGerenciar requisitos Usar arquiteturas baseadas em Usar arquiteturas baseadas em

componentescomponentes Modelar o software visualmenteModelar o software visualmente Verificar continuamente a qualidade do Verificar continuamente a qualidade do

softwaresoftware Controlar as alterações no softwareControlar as alterações no software

Best Practices

RUP Um processo de engenharia de

software Um framework para outros

processos Utiliza as 6 melhores práticas de

desenvolvimento de software

RUP RUP é uma abordagem dirigida por caso de RUP é uma abordagem dirigida por caso de

uso (use-case driven)uso (use-case driven) Casos de uso dirigem inumerosas atividadesCasos de uso dirigem inumerosas atividades

Criação e validação dos modelos de projeto Definição dos casos de teste no modelo de teste Planejamento de iterações Criação do manual do usuário

Processo centrado na arquiteturaProcesso centrado na arquitetura

Histórico

RationalApproach

Rational ObjectoryProcess 4.0

ObjectoryProcess 3.8

Rational ObjectoryProcess 4.1

Rational UnifiedProcess 5.0

Rational UnifiedProcess 5.5

Rational UnifiedProcess 2000

1995

1996

1997

1999

1998

2000

UML 0.8

UML 1.1

UML 1.2

UML 1.3

RUP

LogicalView

ImplemationView

ProcessView

DeploymentView

Use-CaseView

End_userFunctionality

Analysts/TesterBehavior

System IntegratorPerformanceScalabilityThroughput

ProgrammersSoftware Management

System EngineeringSystem TopologyDelivery, InstallationCommunication

RUP

Visão Geral Concepção – onde são estabelecidos lógica do

domínio da aplicação e escopo do projeto

Elaboração – coleta de requisitos mais detalhados, análise e plano para construção do sistema

Construção – consiste de várias iterações

Transição – teste, ajuste de performance e treinamento de usuário

RUP

RUP - Melhores Práticas Desenvolvimento IterativoDesenvolvimento Iterativo Gerência de RequisitosGerência de Requisitos Arquitetura Baseada em ComponentesArquitetura Baseada em Componentes Modelagem VisualModelagem Visual Verificação Contínua da QualidadeVerificação Contínua da Qualidade Gerência de MudançasGerência de Mudanças

Desenvolvimento Iterativo O que é desenvolvimento iterativo

Desenvolvimento em Cascata

Desenvolvimento Iterativo

Desenvolvimento Iterativo

TesteTeste

Modelagem Modelagem de Negóciode Negócio

RequisitosRequisitos

Análise & ProjetoAnálise & Projeto

DeploymentDeployment

AvaliaçãoAvaliação

TesteTeste

ImplementaçãImplementaçãoo

Desenvolvimento Iterativo Vantagens

Os riscos são atacados mais cedo Mudanças nos requisitos Refinamento de arquitetura Aprendizado e aprimoramento Aumento do reuso

Gerência de Requisitos Dificuldades

Requisitos não são óbvios Requisitos não são sempre facilmente

epresso em palavras Existem vários tipos de requisitos em

diferentes níveis de detalhes O número de requisitos pode explodir Requisitos estão interligados Existem várias pessoas interessadas nos

requisitos Requisitos mudam.

Gerência de Requisitos Atacando

Analisando o problema Entendendo as necessidades dos

“stakeholders” Definindo o sistema Gerenciando o escopo do projeto Refinando a definição do sistema Gerenciando mudança de requisitos

Arquitetura Baseada em Componentes

Desenvolvimento Baseado em Componentes Definem uma arquitetura modular Desenvolvidos para reuso Arquiteturas e componentes prontos

Arquitetura Baseada em Componentes

Suporte ao Desenvolvimento Baseado em Componentes Com o processo itrativo Baseado na arquitetura Através da UML - com pacotes,

camadas e subsistemas Testes graduais

Arquitetura Baseada em Componentes

Modelagem Visual

Modelagem Visual

Modelagem Visual

Modelagem Visual Ajuda a entender sistemas complexos Explora e compara alterntivas a um

preço baixo Forma uma base para a

implementação Facilita a captura dos requisitos Comunica as decisões sem

ambiguidades

Verificação Contínua da Qualidade

Verificação Contínua da Qualidade

O que é qualidade?

"...the characteristic of having demonstrated the achievement of producing a product that meets or

exceeds agreed-on requirements—as measured by agreed-on measures and

criteria—and that is produced by an agreed-on process."

Verificação Contínua da Qualidade

O que é qualidade? Onde está a qualidade? Gerência da qualidade no RUP

Identificar metricas Identificar medidas Identificar os pontos que afetam a

qualidade o quanto antes

Gerência de Mudanças

Gerência de Mudanças Coordenação das Atividades e

Artefatos Coordenação das Iterações e Releases Controlando Mudanças de Software

Workspaces isolados reduzem interferências

Estatísticas provêem boas métricas Mudanças podem ser confinadas e as

propagações medidas

Conceitos Chave

Elementos do RUP

WorkflowWorkflow

Workers ou PapelWorkers ou Papel

AtividadesAtividades

ArtefatosArtefatos

Elementos do RUP

Descrever um Caso de Uso

Pacote de Caso de UsoCaso de Uso

Responsável por

Analista

Artefato

Informação que é produzida, modificada, ou usada pelo processo

Worker

Papel desempenhado por um indivíduo ou grupo

Atividade

Unidade de trabalho

Disciplina Workflow de atividades correlatas Alguns elementos, como risco e

testes, são introduzidos em diferentes disciplinas

Relação entre disciplina e modelos

Disciplina

Workflow Sequência de atividades que

produzem um resultado de valor observável

Geralmente expresso em um diagrama de atividade

Organização Disciplinas Detalhes do Workflow

WorkflowWorkflows essenciais (Core Workflows):Workflows essenciais (Core Workflows): Engenharia:

Modelagem de Negócio Requisitos Análise & Projeto Implementação Teste Deployment

Suporte: Gerência do Projeto Gerência de Configuração Ambiente

Workflow

Modelo deProjeto

Modelo deImplementação

Modelo de Teste

realizado pelo

implementado pelo

Requisitos

Implementação

Teste

Modelo de Caso de Uso

Modelagem deNegócio

verificado pelo

Modelo de Negócio

Análise & Projeto

Workflow

Workflow Details As atividades não são feitas em

sequência Mostra os artefatos necessários e

os gerados Agrupa atividades relacionadas de

outras disciplinas

Workflow Details

Workflow Details

Workers - Papel Define o comportamento e as

responsabilidades de um indivíduo um uma equipe

Exercidos por pessoal interno ou externo à equipe de desenvolvimento

Workers - Papel Exemplos:Exemplos:

Analista de Sistemas Revisor de Projeto Testador de desempenho

Workers - Papel

Workers - Papel

Atividade Unidade de trabalho com um

propósito claro Utilizado para planejamento e

verificação de progresso Passos

Planejando Executando Revisando

Atividade Exemplos:Exemplos:

Identificar casos de uso e atores Worker: Analista de Sistemas

Revisar o projeto Worker: Revisor de Projeto

Executar teste de desempenho Worker: Testador de desempenho

Atividade

Atividade A atividade Find use case and

actors se decompõe nos passos: Identificar os atores Identificar os casos de uso Descrever a interação entre os atores

e uc Organizar em pacotes Apresentar o modelo em um diagrama Avaliar os resultados

Artefatos Unidade produzida por um

atividade Pode assumir as formas:

Modelo (UC Model) Elemento de Modelo (Ator) Documento (Visão) Código (Componente)

Artefatos

Artefatos Mantidos por controle de versão Artefatos geralmente não estão na

forma de documentos O artefato esta sempre atualizado

Guias e checkpoints Fornecem uma referência de como fazer Permitem verificar a qualidade do

artefato

Artefatos Templates

Documento de visão (MS Word) Exemplos

Modelo (Modelo de Caso de Uso, de Projeto, etc)

Documento (Documento da Arquitetura do Software)

Código-Fonte Executáveis

Documentos Documentos de Visão

Documentos de Risco

Documentos de Análise de Negócio (Processo)

Tool Mentors Guiam a execução das atividades

em uma ferramenta Ex:

Documenting the Deployment Model Using Rational Rose

Fundamentos

Visão Concordar com o problema a ser

resolvido Identificar os stakeholders Definir os limites do sistema Identificar as restrições

Políticas Econômicas Ambientais Praticabilidade Sistema

Visão Formular a expressão do problema

O problema <descrição do problema>

Afeta <os stakeholders afetados> O impacto deste é <qual é o impacto

do problema> Uma solução adequada poderia <lista

de beneficios>

Planejamento Software development plan

Bom entendimento do que vai ser criado

Plano da Fase: granularidade alta Plano de Iteração: granularidade

baixa“The product is only as good as the plan for the product” Charles Fishman“The plan is nothing; the planning is everything.”Dwight D. Eisenhowe

Riscos Definição: é uma variavel que pode

obter um valor que dificulte ou até mesmo torne o desenv. inviável

Tipos Risco direto Risco indireto

Atributos Probabilidade de ocorrência Impacto no projeto

Riscos Investigando e avaliando riscos

Identificar os riscos Analisar e priorizar os riscos Definir estratégias de evasão Definir estratégias de ataque Definir estratégias de contingência

Indicadores “Plano B”

Rever os ricos durante a iteração Rever os riscos no final da iteração

Tipos de Riscos Riscos de Requisitos

Riscos Tecnológicos

Riscos de Habilidades

Riscos Políticos

Riscos de Requisitos Ponto inicial do processo de desenvolvimento:

Casos de Uso (interação típica que o usuário tem com o sistema)

Esboçar esqueleto do modelo conceitual do domínio – Modelo de domínio.

Fornece muita compreensão. Ponto inicial para construção de classes

Encontrar detalhes importantes e se concentrar neles

Construção de Protótipo

Riscos Tecnológicos Construir um protótipo que experimente as

partes da tecnologia que você está pensando em utilizar

Como os componentes do projeto se encaixam

Dificuldade de serem modificados

Riscos de Habilidades

Treinamento é um bom modo de evitar erros

Bom instrutor Treinamento em pequenas porções Se não puder ter consultores, faça

revisões de tempo em tempo Leitura e grupos de estudo

Riscos Políticos

Política Corporativa

Planos de governo

Riscos“Quem estiver primeiro no campo de batalha e esperar a aparição do inimigo estará descansado para o combate; quem vier depois e tiver de apressar-se, chegará exausto.”Sun Tzu

Business Case Plano econômico para realizar a

Visão, isto é, saber se o projeto vale a pena.

Avaliação do ROI (Return On Investment)

Template

Arquitetura Artefato: Software Architecture

Document Quais são os componentes? Como os componentes se

encaixam? Existe algum framework? Visões arquiteturais

Arquitetura

Visão Lógica

Usuário finalFuncionalidade

Visão de Processo

Visão deImplementação

Visão de“Deployment”

Visão deCasos de Uso

IntegradoresPerformanceEscalabilidade

EngenhariaTopologiaInstalação

ProgramadoresGerenciamento de Software

Prototipagem Iterativamente e

incrementalmente criar versões do sistema.

Verificação dos requisitos Redução de riscos

Avaliação Regular Foco nos problemas no processo e

os problemas no produto

Mudanças Artefato: Change Request

Provê um histórico das mudanças e das decisões tomadas

Gerenciar o escopo do projeto Avaliar o impacto das decisões

Suporte do Usuário Criar um produto utilizável Manuais, ajuda e treinamento

Processo Adotar um processo que se

encaixa ao projeto A produção de artefatos varia de

projeto a projeto

Conclusões Sem visão?

O projeto pode perder escopo ou desviar do propósito

Sem processo? A equipe pode perder a visão de quem esta

fazendo o que e quando Sem planejamento?

Você perde a capacidade de rastrear o progresso

Conclusões Sem controle de riscos?

Você pode focar no ponto errado e pisar em “minas”

Sem Business Case? Você corre-se o risco de jogar tempo e

investimento fora Sem arquitetura?

Podem ocorrer problemas com escalabilidade, falso reuso e performance

Conclusões Sem prototipagem?

Como você e o usuário saberão que o sistema funciona?

Sem avaliação? Tenha coragem e enfrente a verdade!

Sem Change Request? Como rastrear, priorizar os pedidos do cliente

Sem suporte do usuário? Como o usuário vai obter informação sobre o

sistema?

Fases

Fases

tempo

Inception Elaboration Construction Transition

Fases e Iterações

Inception Elaboration Construction Transition

Iteração#1

… … …Iteração#n

Iteração#n+1

Iteração#m

Iteração#m+1

IteraçãoPrelim.

Versões

Milestone

LifecycleObjectives

LifecycleArchitecture

Initial OperationalCapability

tempo

Inception Elaboration Construction Transition

Cada fase deve ser concluída com um Cada fase deve ser concluída com um Milestone (Major Milestone)Milestone (Major Milestone)

Concepção

Estabelecer o escopo e os limites, com critérios de aceitação bem definidos

Discriminar os casos de usos críticos Exibir uma arquitetura candidata “Adivinhar” o custo e o calendário Preparar o ambiente do projeto

Concepção - Milestone

Examina os objetivos e decide seguir ou cancelar o projeto - Viabilidade

Critério de avaliação Entendimento e acordo com os requisitos Credibilidade do custo/tempo Acerto das prioridades

Concepção - Milestone

Produtos:Produtos: Visão geral dos requisitos do projeto:

Modelo de Caso de Uso inicial (10-20%) Estimativa dos recursos necessários Mini Mundo

Elaboração

Assegurar que os requisitos e planos estão estáveis

Estabelecer uma arquitetura Provar que a arquitetura funciona Produzir um protótipo evolucionário Estabelecer um ambiente

Elaboração

Deve terminar em torno de um quinto do tempo do projeto

Desenvolvedores já sentem a vontade para dar estimativas de tempo

Todos os riscos significativos foram identificados

Elaboração - Milestone

Examina os objetivos, arquitetura e riscos do projeto

Critério de avaliação Requisitos, visão e arquitetura estáveis Verificar que, com os protótipos, todos os

riscos foram atacados Planos de Iteração da fase de construção Despesas atuais batem com estimadas

Elaboração - Milestone

Todos o Stakeholders concordam que a visão atual pode ser alcançada se o plano atual for executado para desenvolver o sistema completo, no contexto da arquitetura atual ?

Produtos: Modelo de Caso de Uso (80%) Plano de desenvolvimento Avaliação revisada dos riscos Protótipo da arquitetura

Construção

Atingir qualidade o mais breve possível Desenvolver incrementalmente e

lançar as versões de teste (alpha, beta)

Completar o desenvolvimento de todos os Casos de Uso

Construção

Estabelecer(detalhar) as iterações e definir que funcionalidades entregar em cada uma delas

Casos de Uso com maior prioridade e/ou risco de desenvolvimento primeiro

Cada iteração é um mini-projeto: Análise, projeto,codificação, teste e integração

As iterações são incrementais na função Integração contínua

Construção - Milestone

Sistema e manual Critério de avaliação

O sistema já esta maduro o suficiente pra ser entregue?

Os stakeholders estão prontos para usá-lo? Despesas reais versus planejadas

continuam aceitaveis?

Construção - Milestone

Produtos: Modelo de Caso de Uso e de Projeto

completos Manual do usuário O software integrado e pronto para a

utilização dos usuários

Transição

Teste de validação Conversão do ambiente para produção Treinamento de usuários e manutenção Otimização Alcançando auto-suporte do usuário

Transição - Milestone

Os objetivos foram cumpridos Coincide com o fim da fase de

concepção de outro ciclo Critério de avaliação

O usuário está satisfeito Despesas reais versus planejadas

continuam aceitaveis?

Transição - Milestone

Produtos: Versão final do produto Manual do usuário atualizado Modelos atualizados

RUP

Gerência do Projeto

Ambiente

Modelagem do Negócio

Implementação

Teste

Análise & Projeto

Preliminary Iteration(s)

Iter.#1

FasesCore Workflows

Iterações

Workflows de Suporte

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Deployment

Ger. de Configuração

Requisitos

Elaboration TransitionInception Construction

Tempo

Workflows de Engenharia