Rational Unified Process
O Valor do Software




O 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ícia
 A economia mundial depende cada vez mais de software.
Notí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.
Resultado
 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
usuários
Falta de habilidade de lidar com a necessidade de
mudanças
Uma descoberta tardia de uma séria falha de projeto
Software com baixa qualidade
Um processo não confiável de construção
Arquitetura frágil
Testes insuficientes
Falha no ataque aos riscos
Processo

Define quem irá fazer o que, quando, e como será
alcançado o objetivo.
Requisitos novos
Processo de Engenharia
ou alterados
de Software
Sistema novo
ou melhorado
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 iterativamente
Gerenciar requisitos
Usar arquiteturas baseadas em componentes
Modelar o software visualmente
Verificar continuamente a qualidade do
software
Controlar 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
uso (use-case driven)
Casos 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 arquitetura
Histórico
2000
Rational Unified
Process 2000
1999
Rational Unified
Process 5.5
UML 1.3
1998
Rational Unified
Process 5.0
UML 1.2
1997
Rational Objectory
Process 4.1
UML 1.1
1996
Rational Objectory
Process 4.0
UML 0.8
1995
Rational
Approach
Objectory
Process 3.8
RUP
End_user
Functionality
Programmers
Software Management
Implemation
View
Logical
View
Use-Case
View
Analysts/Tester
Behavior
Process
View
System Integrator
Performance
Scalability
Throughput
Deployment
View
System Engineering
System Topology
Delivery, Installation
Communication
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 Iterativo
Gerência de Requisitos
Arquitetura Baseada em Componentes
Modelagem Visual
Verificação Contínua da Qualidade
Gerência de Mudanças
Desenvolvimento Iterativo

O que é desenvolvimento iterativo
Desenvolvimento em
Cascata
Desenvolvimento
Iterativo
Desenvolvimento Iterativo
Teste
Requisitos
Modelagem
de Negócio
Análise & Projeto
Implementação
Deployment
Avaliação
Teste
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

Workflow

Workers ou Papel

Atividades

Artefatos
Elementos do RUP
Papel
desempenhado por
um indivíduo ou
grupo
Unidade de
trabalho
Atividade
Worker
Analista
Descrever um Caso de Uso
Responsável por
Caso de Uso
Artefato
Informação que é produzida,
modificada, ou usada pelo
processo
Pacote de Caso de Uso
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
Workflow
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
Modelagem de
Negócio
Modelo de Negócio
Requisitos
realizado pelo
Modelo de Caso de Uso
Análise &
Projeto
Modelo de
Projeto
implementado pelo
Implementação
verificado pelo
Modelo de
Implementação
Teste
Modelo de Teste
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:



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:

Identificar casos de uso e atores


Revisar o projeto


Worker: Analista de Sistemas
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
Usuário final
Funcionalidade
Programadores
Gerenciamento de Software
Visão de
Implementação
Visão Lógica
Visão de
Casos de Uso
Visão de Processo
Integradores
Performance
Escalabilidade
Visão de
“Deployment”
Engenharia
Topologia
Instalação
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?


Sem processo?


O projeto pode perder escopo ou desviar do
propósito
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?


Sem Business Case?


Você pode focar no ponto errado e pisar em
“minas”
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?


Sem avaliação?


Tenha coragem e enfrente a verdade!
Sem Change Request?


Como você e o usuário saberão que o sistema
funciona?
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
Inception
tempo
Elaboration
Construction
Transition
Fases e Iterações
Inception
Elaboration
Iteração Iteração
Prelim.
#1
…
Construction
Iteração Iteração
#n
#n+1
Transition
…
Versões
Iteração Iteração
#m+1
#m
…
Milestone
Inception
Elaboration
Construction
Transition
tempo
Lifecycle
Objectives

Lifecycle
Architecture
Initial Operational
Capability
Cada fase deve ser concluída com um
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:

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
Core Workflows
Fases
Workflows de Engenharia
Inception
Elaboration
Construction
Transition
Modelagem do Negócio
Requisitos
Análise & Projeto
Implementação
Teste
Deployment
Workflows de Suporte
Ger. de Configuração
Gerência do Projeto
Ambiente
Preliminary
Iteration(s)
Tempo
Iter.
#1
Iter.
#2
Iter.
#n
Iter.
#n+1
Iterações
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Descargar

Rational Unified Process - Federal University of Rio de