Processo Unificado

Profa. Maria Istela Cagnin Machado

Roteiro
• Considerações Iniciais
• Modelo Incremental
• Processo Unificado
• O que é?
• Elementos
• Princípios básicos
• Fases

2
Considerações Iniciais

• Desenvolver software geralmente é uma tarefa complexa

3
 TAREFAS DE
ENGENHARIA DE
SOFTWARE
ATIVIDADES DE OBJETIVOS
APOIO DEFINIÇÃO ORGANIZACIONAIS

CONSTRUÇÃO
MÉTODOS POLÍTICAS
SOFTWARE PRODUTO

FERRAMENTAS
MANUTENÇÃO PESSOAS

COMPROMETIMENTOS
4
Considerações Iniciais
• Necessidade de estabelecer processos sistemáticos para
desenvolvimento: Modelos de processo de Software
• Modelo em Cascata
• Modelo de Prototipação
• Desenvolvimento Baseado em Componentes
• Modelo de Métodos formais
• Modelo incremental (Processo Unificado, RUP, …)
• Métodos ágeis (eXtremme Programming (XP), Scrum, OpenUp, …)
• … 5
Modelo em Cascata

6
Modelo em Cascata -
Problemas
💣 Projetos reais raramente seguem o fluxo sequencial que o
modelo propõe

💣 Logo no início é difícil estabelecer explicitamente todos os

requisitos. No começo dos projetos sempre existe uma
incerteza natural

💣 O cliente deve ter paciência. Uma versão executável do

software só fica disponível numa etapa avançada do 7
desenvolvimento
Prototipação

8
Prototipação - Problemas
💣 Cliente não sabe que o software que ele vê não considerou,
durante o desenvolvimento, a qualidade global e a
manutenibilidade a longo prazo

💣 desenvolvedor frequentemente faz uma implementação

comprometida (utilizando o que está disponível) com o
objetivo de produzir rapidamente um protótipo

9
O Modelo Incremental
• O modelo incremental combina elementos do modelo cascata
(aplicado repetidamente) com a filosofia iterativa da
prototipação

• Objetivo: trabalhar junto com o usuário para descobrir seus

requisitos, de maneira incremental, até que o produto final seja
obtido

10
O Modelo Incremental
• A versão inicial é frequentemente o núcleo do
produto (a parte mais importante)
• A evolução acontece quando novas características
são adicionadas à medida que são sugeridas pelo
usuário
• Este modelo é importante quando é difícil
estabelecer a priori uma especificação detalhada dos
requisitos ou quando os requisitos mudam com 11
frequência
 Processo Unificado (PU)
• O PU foi proposto pelos três gurus da orientação a objetos
(Jacobson, Booch & Rumbaugh, 1999):
• Ivar Jacobson
• Grady Booch
• James Rumbaugh

• É o resultado de mais de trinta anos de experiência

acumulada
12
 Processo Unificado- História
• Raízes no trabalho de Jacobson na Ericsson no final da década de
1960

• 1987 – Jacobson criou uma empresa chamada Objectory AB –

desenvolvimento de um processo chamado Objectory

• 1995 – a Rational comprou a Objectory AB, aperfeiçoou o

Objectory criando o Processo Objectory da Rational (ROP)
(Jacobson, Rumbaugh e Booch)
13

• Paralelamente, desenvolviam a UML

 Processo Unificado - História
• Progresso do processo ROP e a aquisição e desenvolvimento
de ferramentas de desenvolvimento agregaram valor ao ROP

• 1998 – Rational mudou o nome do ROP para Processo

Unificado da Rational (RUP- Rational Unified Process)

• RUP é uma especialização, com refinamento detalhado, do

PU
14
O que é o Processo Unificado (PU)?
• É um modelo de processo de software baseado no modelo
incremental, visando a construção de software orientado a
objetos
• Usa como notação de apoio a UML (Unified Modeling
Language)
• É um processo de software: conjunto de atividades
executadas para transformar um conjunto de requisitos do
cliente em um sistema de software
• Um processo de desenvolvimento de software descreve uma
abordagem para a construção, implantação e manutenção
15
do software
O que é o Processo Unificado?

• É um framework que pode ser personalizado de

acordo com as necessidades específicas e
recursos disponíveis para cada projeto
• Instanciações do PU
• RUP (Rational Unified Process)
• OpenUp (versão ágil do PU) 16
 Elementos do Processo
Unificado
•Um processo descreve
quem (papel)
está fazendo o quê (artefato),
como (atividades) e
17
quando (disciplina)
 Quem? Dev/Ana/Arq/Tester
• Um trabalhador é alguém que desempenha um papel e é
responsável pela realização de atividades para produzir ou
modificar um artefato

18
 O quê? Artefatos
• Um artefato é uma porção significativa de informação
interna ou que será fornecida a interessados externos
que desempenhem um papel no desenvolvimento do
sistema
• Um artefato é algum documento, relatório, modelo ou
código que é produzido, manipulado ou consumido

• Exemplos: modelo de caso de uso, modelo do projeto,

um caso de uso, um subsistema, um caso de negócio, um
documento de arquitetura de software, código fonte, 19
executáveis, etc
 Como? Atividades
• Uma atividade é uma tarefa que um trabalhador
executa a fim de produzir ou modificar um
artefato

20
 Quando? Disciplina
• A disciplina descreve as sequências das atividades
que produzem algum resultado significativo e mostra
as interações entre os participantes

• São realizadas a qualquer momento durante o ciclo

de desenvolvimento (Fases do PU)

• Requisitos, Análise, Projeto, Implementação, Teste,

21
Gerência de Projeto, Gerência de Configuração, …
Disciplinas do PU

22
Princípios básicos do PU

•Desenvolvimento iterativo

•Baseado em casos de uso

•Centrado na arquitetura 23
Desenvolvimento iterativo
• O desenvolvimento de um software é dividido em vários
ciclos de iteração, cada qual produzindo um sistema
testado, integrado e executável

• Em cada ciclo ocorrem as atividades de análise de

requisitos, projeto, implementação e teste, bem como a
integração dos artefatos produzidos com os artefatos já
existentes
24
Desenvolvimento iterativo

Produto
v1 v2 v3 Final 25
Desenvolvimento iterativo

26
Exemplo: pág. 48 (Larman, 2005)
Desenvolvimento iterativo
• Planejar quantos ciclos de desenvolvimento serão
necessários para alcançar os objetivos do sistema

• As partes mais importantes (requisitos) devem ser

priorizadas e alocadas nos primeiros ciclos de
acordo com os seguintes critérios:
• (1) possuem alto valor de negócio
• (2) possuem alto risco (ex. devem poder manipular 500
transações concorrentes) 27
• (3) são arquiteturalmente significativas
Desenvolvimento iterativo

•As partes mais complexas do sistema devem

ser atacadas já no primeiro ciclo, pois são
elas que apresentam maior risco de
inviabilizar o projeto

28
Desenvolvimento iterativo
•O tamanho de cada ciclo pode variar de
uma empresa para outra e conforme o
tamanho do sistema
• Por exemplo, uma empresa pode desejar
ciclos de 3 semanas, outra pode preferir 6
semanas
• recomenda-se que a duração de uma iteração seja 29
entre duas e seis semanas
Desenvolvimento iterativo

CUIDADO!
•Uma iteração muito longa perde o
objetivo do desenvolvimento iterativo!
30
Desenvolvimento iterativo
•Se o projetista observar que será difícil
cumprir o prazo da iteração, é
recomendável remover tarefas ou requisitos
da iteração atual e incluí-las em uma
iteração futura, em vez de não cumprir o
prazo
31
Desenvolvimento iterativo
• Cada iteração exige a escolha de um pequeno
subconjunto de requisitos, além da sua rápida
construção e teste
• requisitos complexos: podem ser tratados ao longo de várias
iterações
• requisitos simples: podem ser completados em uma iteração
• Nas iterações iniciais o resultado pode não ser
exatamente o que é desejado em última 32
instância
Desenvolvimento iterativo
No entanto, o ato de executar rapidamente um
pequeno passo antes de finalizar todos os
requisitos leva a uma realimentação rápida

• Essa realimentação é muito importante:

• ao invés de especular sobre os requisitos corretos e
completos, a equipe procura a realimentação a partir de
uma construção e teste realístico de alguma coisa 33
buscando uma percepção prática do sistema
Desenvolvimento iterativo
• Os usuários têm a oportunidade de ver um sistema e dizer:
“sim! Foi isso que eu pedi, mas agora que o experimentei, o que eu
realmente quero é algo ligeiramente diferente!”

• Esse “sim! Mas…” não é um sinal de erro. É um modo hábil de

progredir e descobrir o que é de real valor no sistema para os
interessados (stakeholders)

34
 Baseado em Casos de Uso
• Um caso de uso é uma sequência de ações,
executadas por um ou mais atores e pelo próprio
sistema, que produz um ou mais resultados de valor
para um ou mais atores

• O PU é dirigido por casos de uso, pois os utiliza para

dirigir todo o trabalho de desenvolvimento, desde a
captação inicial e negociação dos requisitos até a
aceitação do código (testes) 35
 Baseado em Casos de Uso
• Os casos de uso são centrais ao PU e outros
métodos iterativos, pois:
• os requisitos funcionais são registrados
preferencialmente por meio deles
• o planejamento do desenvolvimento é feito em
função dos casos de uso identificados,
tratando-se prioritariamente os mais complexos
36
• o teste é baseado neles
 Centrado na Arquitetura
•Arquitetura é a organização fundamental
do sistema como um todo

•Arquitetura descreve o sistema em termos

de sua organização em camadas, pacotes,
classes, interfaces e subsistemas
37
 Centrado na Arquitetura
• A análise arquitetural está envolvida na
identificação e na resolução dos requisitos
não-funcionais (ex., qualidade) do sistema, no
contexto dos requisitos funcionais

• A arquitetura se refere a questões como:

• desempenho, escalabilidade, reuso e restrições 38
econômicas e tecnológicas
 Centrado na Arquitetura
• O PU prioriza a construção de uma arquitetura de sistema
que permita a realização dos requisitos
• Essa arquitetura baseia-se na identificação de uma
estrutura de classes, produzida a partir de um modelo
conceitual
• A cada ciclo de trabalho realizado, novas características
são adicionadas à arquitetura do sistema, deixando-a mais
completa e mais próxima do sistema final 39
 Centrado na Arquitetura
• No PU, a arquitetura do sistema em construção é o
alicerce fundamental sobre o qual ele se erguerá
• Deve ser uma das preocupações da equipe de
projeto
• A arquitetura, juntamente com os casos de uso,
deve orientar a exploração de todos os aspectos do
sistema
40
Fases do PU
•O PU é dividido em quatro fases:
•Concepção
•Elaboração
•Construção
•Transição
41
Fases e Disciplinas do PU

42

Iterações
 Fases do PU: Concepção
• Inception em inglês
• Estuda a viabilidade de implantação do sistema
• Definição do escopo do sistema
• Estimativas de custos e cronograma
• Identificação dos potenciais riscos que devem ser
gerenciados ao longo do projeto
• Esboço da arquitetura do sistema, que servirá como 43
alicerce para a sua construção
 Fases do PU: Elaboração
• Visão refinada do sistema, com a definição dos
requisitos funcionais, detalhamento da
arquitetura criada na fase anterior e
gerenciamento contínuo dos riscos envolvidos
• Incorpora:
• Maior parte da análise de requisitos
• Projeto (design) 44
 Fases do PU: Construção
• O sistema é efetivamente desenvolvido e, em
geral, tem condições de ser operado, mesmo
que em ambiente de teste, pelos clientes
• Incorpora:
• Implementação
• Testes

45
 Fases do PU: Transição
• O sistema é entregue ao cliente para uso em
produção
• Testes são realizados
• Um ou mais incrementos do sistema são
implantados
• Defeitos são corrigidos, se necessário
• Incorpora:
46
• Instalação e manutenção
Cenário 1 - Fases do PU

Construção

Concepção

Transição
Elaboração

Pag. 24 -Wazlawick 47
Cenário 2 - Fases do PU
Transição

Construção

Elaboração

Concepção

48
Ágil?
•Apesar de ser um processo prescritivo, o
Processo Unificado pode também ser realizado
como um processo ágil, com poucos artefatos e
burocracia, permitindo o desenvolvimento de
software de forma eficiente, uma vez que o que
interessa ao cliente é o software pronto e não
uma pilha de documentos justificando porque
não ficou pronto 49
•Para que isso seja obtido, a documentação deve ser
dirigida à produção do software

•Cada atividade realizada pelos membros da equipe

deve ter um objetivo muito claro e cada artefato
deve ter uma utilização precisa visando sempre à
produção de um código que atenda aos requisitos
da melhor forma possível no menor tempo 50
 51

http://calvinberschscherer.blogspot.com.br/2014/06/projeto-balanco-no-agile.html
 52

http://calvinberschscherer.blogspot.com.br/2014/06/projeto-balanco-no-agile.html
Disciplinas do PU Uma iteração de 4 semanas (por exemplo).
Um miniprojeto que inclui trabalho na maioria das
Disciplinas, terminando com um executável estável.

Note que,
embora uma
iteração inclua
trabalho na
maior parte das
disciplinas, o
esforço relativo
e a ênfase
mudam ao
longo tempo.

Este exemplo
sugestivo, e não
literal.

53
Qual a relação entre disciplinas e
fases em uma iteração?
• Durante uma iteração, o trabalho prossegue na
maioria ou em todas as disciplinas
• Contudo, o esforço relativo no decorrer destas
disciplinas muda ao longo do tempo
• As iterações iniciais tendem a dar uma ênfase maior
aos requisitos e ao projeto enquanto que nas
últimas possuem menor ênfase, à medida em que os
requisitos e o projeto central se estabilizam 54
Mudança do esforço em relação
às fases

O esforço relativo
nas disciplinas muda
ao longo das fases.

Este exemplo é uma

sugestão e não deve
ser tomado ao “pé
da letra”.

55
Práticas importantes do PU
• Ideia central: usar iterações curtas, com duração
fixa, em um processo de desenvolvimento iterativo,
evolutivo e adaptativo.

• Melhores práticas do PU:

• enfrentar os problemas que envolvem altos riscos
e alto valor já na primeira iteração
56
• envolver continuamente os usuários
Práticas importantes do PU (cont.)
• construir uma arquitetura central coesa nas iterações
iniciais
• verificar continuamente a qualidade; fazer testes logo no
início
• considerar casos de uso
• modelar visualmente o software (com UML)
• gerenciar requisitos
• gerenciar solicitações de mudanças e gerenciar 57
configurações
Personalizando o PU
• Quase tudo no PU é opcional!
• Algumas práticas são invariáveis:
• desenvolvimento iterativo e orientado ao
controle de riscos
• controle da qualidade
• Um aspecto chave do PU é que todas as
atividades e os artefatos (modelos, diagramas, 58
etc) são opcionais. Talvez não o código!
Analogia
• O conjunto de possíveis artefatos descritos no PU
deve ser visto como um conjunto de
medicamentos em uma farmácia
• assim como as pessoas ajustam a escolha de
acordo com os sintomas, em um projeto de PU
a equipe deve selecionar um pequeno
subconjunto de artefatos que atenda a seus
59
problemas e necessidades
Disciplinas do PU
• Modelagem de Negócio
• Requisitos
• Análise e Projeto Foco de APSOO
• Implementação
• Teste
• Implantação
• Gestão de Configuração e Mudanças
• Gestão de Projetos
• Ambiente 60
Concepção
1ª fase do PU
Fase de Concepção
• Concepção não é a fase de requisitos
• É um passo inicial curto, no qual os seguintes
tipos de questões são exploradas:
• Qual é a visão de negócio para este projeto?
• Ele é viável?
• Devemos construir ou comprar?
• Estimativa aproximada de custo 62

• Devemos continuar ou parar?

Fase de Concepção
Objetivo: fazer uma investigação inicial para formar
uma opinião da finalidade geral e da viabilidade do
novo sistema, para decidir se vale a pena investir em
uma exploração mais profunda (fase de elaboração).
Não é finalidade executar tal exploração!

63
Fase de Concepção
• Atividades da fase de concepção:
• Entendimento do negócio
• Levantamento de requisitos (Visão geral)
• Organização de requisitos
• Planejamento do desenvolvimento
64
 Artefatos que podem ser iniciados
na fase de Concepção
• Visão e caso de negócio (objetivos e restrições de alto nível)
• Lista de requisitos
• Modelo de casos de uso (requisitos funcionais)
• Especificações suplementares (requisitos não funcionais)
• Glossário (terminologia-chave do domínio)
• Lista de riscos e plano de gestão de riscos (ideias para minimização ou solução dos
riscos)
• Protótipos e provas de conceito (esclarecem a visão do negócio)
• Plano das iterações
• Estimativas de baixa precisão e planos (duração e esforço, ferramentas, pessoal,
treinamento, etc)
• Pasta de desenvolvimento (passos e artefatos que serão personalizados para o 65
projeto)
Ex. de Pasta de desenvolvimento
Disciplina Artefato Concepção Elaboração Construção Transição
Iteração C1 E1..En Ct1..Ctn T1..Tn

Modelagem de Modelo de Processos de Negócio i (iniciar) r (refinar)

Negócio
Requisitos Modelo de Casos de uso i r
Visão i r
Especificações suplementares i r

Glossário i r
Projeto Modelo de Projeto i r
Documento de Arquitetura de i r
Software
Modelo de Dados i r
Implementação Modelo de Implementação i r r

Gestão de Projetos Plano de desenvolvimento de software i r r r

66
Teste Modelo de teste i r
Ambiente Pasta de desenvolvimento i r r
• Modelos de casos de uso: um conjunto de cenários típicos do uso
de um sistema. Principalmente para requisitos funcionais
• Especificação suplementar: basicamente tudo o que não está nos
casos de uso. Está relacionada principalmente aos requisitos não
funcionais.
• Glossário: define termos importantes. Registra requisitos
relativos aos dados, tais como regras de validação, valores
aceitáveis, etc.
• Visão Geral: resume requisitos de alto nível que são detalhados
no modelo de casos de uso e especificação suplementar.
• Regras de negócio: descrevem requisitos ou políticas de um
projeto de software. 67
• Exemplo: leis sobre impostos governamentais
Artefatos que podem ser iniciados
na fase de Concepção
Mas isso não é documentação demais???

• Esses artefatos são opcionais!

• O gerente de projeto deve selecionar o que for necessário
para cada sistema

68
Na Fase de Concepção (1)...
•O modelo de casos de uso pode listar os
nomes de casos de uso e atores mais
esperados, mas talvez descreva apenas
10% dos casos de uso em detalhe

69
Na fase de Concepção (2)...
•Pode ocorrer algum trabalho de
programação com o objetivo de criar
protótipos para “prova de conceitos”

70
Importante
•Crie somente os artefatos que realmente
acrescentem valor ao projeto

•Como se trata de um desenvolvimento evolutivo, o

ponto não é criar especificações completas durante
esta fase, mas um esboço de documentos iniciais,
que serão refinados em resposta à realimentação 71
Artefatos que serão iniciados na fase
de Concepção do trabalho prático
• Documento de Requisitos:
• Visão
• Lista de requisitos
• Especificações suplementares (requisitos não funcionais)
• Glossário e Modelo de Casos de Uso (indicação dos casos de uso
e descrição geral)

• Modelo de Processos de Negócios

• Plano de iterações
72
Referências bibliográficas
• Wazlawick, R. S. Análise e Projeto de Sistemas de
Informação Orientados a Objetos, 2011, editora
Campus.

73