PROCESSO UNIFICADO

PROF. RAUL SIDNEI WAZLAWICK

UFSC-CTC-INE
2010

UP UNIFIED PROCESS
PROCESSO UNIFICADO
Foi criado por trs importantes luzes da
orientao a objetos dos anos 90 (Jacobson, Booch
& Rumbaugh, 1999), sendo o resultado de mais
de 30 anos de experincia acumulada em projetos
notaes e processos.

o primeiro modelo de processo inteiramente
adaptado ao uso com a UML (Unified Modelling
Language), desenvolvida pelo mesmo grupo.

Sua concepo foi baseada nas prticas de maior
retorno de investimento (ROI) do mercado.

CARACTERSTICAS
dirigido por casos de uso.

centrado na arquitetura.

iterativo e incremental.

focado em riscos.

DIRIGIDO POR CASOS DE USO

Um caso de uso um processo compreendido do
ponto de vista do usurio.

Para o UP o conjunto de casos de uso deve definir
e esgotar toda a funcionalidade possvel do
sistema.

Wazlawick (2004) apresenta vrias tcnicas para
identificar casos de uso de boa granularidade.

UTILIDADE DE CASOS DE USO

Definio e validao da arquitetura do sistema.

Criao dos casos de teste.

Os casos de uso podem ser vistos como um roteiro para teste onde as
funcionalidades so testadas do ponto de vista do cliente.
Estes so os testes de sistema e aceitao.

Planejamento das iteraes.

Classes e atributos usualmente so obtidos a partir dos textos dos casos de

uso expandidos.

Os casos de uso so priorizados e o esforo para desenvolve-los estimado

de forma que cada iterao desenvolva um certo numero deles.

Base para a documentao do usurio.

Os casos de uso so descries de fluxos normais de operao de um

sistema bem como de fluxos alternativos representando o tratamento de
possveis excees nos fluxos normais.
Estas descries so uma excelente base para iniciar o manual de operao
do sistema, pois todas as funcionalidades possveis estaro descritas a de
forma estruturada e completa.

CENTRADO NA ARQUITETURA
O UP preconiza que uma slida arquitetura de
sistema deve ser desenvolvida.

As funcionalidades aprendidas com a elaborao
dos diversos casos de uso devem ser integradas a
esta arquitetura de forma incremental.

A arquitetura inicialmente pode ser
compreendida como o conjunto de classes,
possivelmente agrupadas em componentes, que
realizam as operaes definidas pelo sistema.

A arquitetura uma estrutura que prov
funcionalidades.

CENTRADO NA ARQUITETURA
Os casos de uso so a descrio dos processos que
realizam ou usam essas funcionalidades.

A arquitetura ento existe para que as
funcionalidades sejam possveis.

A arquitetura basicamente um modelo que
define a estrutura da informao, suas possveis
operaes e sua organizao em componentes ou
mesmo em camadas.

CENTRADO NA ARQUITETURA
Segundo UP a cada ciclo iterativo deve-se
incorporar arquitetura existente as
funcionalidades aprendidas com a anlise e
projeto de cada um dos casos de uso abordados no
ciclo.

Assim, fazendo-se a priorizao dos casos de uso
a partir dos mais crticos ou complexos para os
mais triviais e simples, desenvolve-se em um
primeiro momento todos os elementos de maior
risco para a arquitetura, no ficando muitas
surpresas para depois.

ITERATIVO E INCREMENTAL

Assim como nos mtodos geis, o UP sugere o

desenvolvimento baseado em ciclos iterativos de durao
fixa, onde a cada iterao a equipe incorpora arquitetura
as funcionalidades necessrias para realizar os casos de uso
abordados no ciclo.
Cada ciclo iterativo produz um incremento no projeto do
sistema, seja produzindo mais conhecimento sobre seus
requisitos e arquitetura, seja produzindo cdigo executvel.
Espera-se que em cada iterao todas as disciplinas
previstas sejam executadas com maior ou menor
intensidade (ver Figura 5.2).
Ento, assim como nos mtodos geis, cada ciclo iterativo
vai implicar em executar todas as atividades usuais de
desenvolvimento de software.

ITERATIVO E INCREMENTAL

A integrao contnua reduz riscos, facilita os testes e

melhora o aprendizado da equipe sobre o sistema,
especialmente nos primeiros momentos, quando decises
crticas precisam ser tomadas com relativamente pouco
conhecimento sobre o sistema em si.
Usualmente a fase de concepo, por ser curta, executada
em um nico ciclo.
J as fases de elaborao, construo e transio, podem
ser executadas a partir de uma srie de ciclos iterativos.
Porm, no caso de projetos muito grandes, mesmo a fase de
concepo pode ser subdividida em ciclos nos quais se
exploram diferentes caractersticas de um sistema.

FOCADO EM RISCOS

Em funo das priorizaes dos casos de uso mais

crticos nos primeiros ciclos iterativos, pode-se
dizer que o UP focado em riscos, pois se estes
casos de uso so os que apresentam maior risco
de desenvolvimento, ento devem ser tratados o
quanto antes para que os riscos sejam resolvidos
enquanto o custo de trat-los ainda baixo e o
tempo disponvel para acomodar surpresas ainda
relativamente grande.

TAREFAS BEM DEFINIDAS

Elas tm uma descrio clara e precisa.

Apresentam responsveis.

So definidos artefatos de entrada e sada.

So definidas dependncias entre tarefas.

Seguem um modelo de ciclo de vida bem definido.

Acompanha uma descrio sistemtica de como
executar cada tarefa (atividades e
procedimentos).

Preconizam o uso da linguagem UML.

DISCIPLINA UP
As DISCIKINA incluem workflows, que so
grafos que descrevem as dependncias entre
diferentes tarefas.

Workflows so associados s disciplinas do
processo unificado, que variam de implementao
para implementao.

FASES DO UP

Concepo (inception).

Trata-se da elaborao de uma viso em abrangncia do sistema.

So levantados os principais requisitos, um modelo conceitual preliminar
construdo, bem como so identificados os casos de uso de alto nvel
(Wazlawick, 2004) que implementam a funcionalidade requerida pelo
cliente.
Nesta fase se calcula o esforo de desenvolvimento dos casos de uso e se
constri o plano de desenvolvimento composto por um conjunto de ciclos
iterativos nos quais so acomodados os casos de uso.

Elaborao (elaboration).

Nesta fase faz-se o detalhamento da anlise, expandindo os casos de uso,

para obter sua descrio detalhada e situaes excepcionais (fluxos
alternativos).
O modelo conceitual preliminar ser transformado em um modelo
definitivo, cada vez mais refinado e sobre o qual so aplicados padres de
anlise e uma descrio funcional poder ser feita, bem como o projeto
lgico e fsico do sistema.

FASES DO UP

Construo (construction).

A fase de construo implica na gerao de cdigo e
testes do sistema.

Com a automatizao da gerao de cdigo bem como
com a introduo de modelos de desenvolvimento
dirigidos a teste, pressupe-se que um bom projeto possa
dar origem rapidamente a cdigo de alta qualidade.
Transio (deployment).

A fase de transio consiste na implantao do sistema
no ambiente final, com a realizao de testes de
operao.

Tambm feita a transferncia de dados de possveis
sistemas antigos para o novo sistema e o treinamento de
usurios, bem como outras adaptaes necessrias que
variam de caso a caso.

ESTIMATIVA DE TEMPO/ESFORO PARA

CADA FASE

MILESTONES
Uma das caractersticas do UP tambm o fato
de que a cada fase um macro-objetivo (milestone)
atingido.

Ao final da fase de concepo o objetivo ter
entendido o escopo do projeto.

Ao final de fase de elaborao os requisitos devem
ter sido extensivamente compreendidos e uma
arquitetura definida.

Ao final da fase de construo o sistema deve
estar programado e testado.

Ao final da fase de transio o software deve
estar instalado e sendo usado pelos usurios
finais (West, 2002).

FASE DE CONCEPO

A fase de concepo no processo unificado no deve ser

muito longa.
De duas semanas a dois meses o que se recomenda
dependendo da dimenso relativa do projeto.
Nesta etapa so analisados os requisitos de projeto da
melhor forma possvel.
Eles so analisados em abrangncia, no em profundidade.
importante que o analista perceba claramente a
diferena entre as necessidades lgicas e tecnolgicas do
cliente e os possveis projetos de implementao que ele
poderia fazer.
A idia que o analista no polua a descrio dos requisitos
com possibilidades tecnolgicas de implementao que no
foram expressamente requisitadas pelo cliente.

OPES: REQUISITOS E/OU CASOS DE USO

Obter casos de uso a partir de uma organizao
dos requisitos, onde cada grupo de requisitos
poder dar origem a um ou mais casos de uso.

Inicialmente proceder a uma anlise de cenrios,
que nada mais so do que instncias de casos de
uso, e posteriormente extrair os requisitos destes
cenrios.

Trabalhar apenas com casos de uso. Eles so a
nica expresso dos requisitos, no havendo
outros documentos, exceto, talvez, para os
requisitos suplementares que no se encaixam
em nenhuma funo individual do sistema.

PRIORIZAO DOS CASOS DE USO

Descubra os casos de uso que so meros relatrios, ou seja,

que no alteram a informao armazenada, e classifique
estes casos de uso como os mais simples de todos.
Verifique se existem casos de uso que seguem algum
padro conhecido, como CRUD ou mestre-detalhe.

Estes casos de uso sero de mdia complexidade, pois embora

possuam um comportamento bem conhecido e padronizado, podem
esconder algumas surpresas nas suas regras de negcio, ou seja,
incluses, alteraes e excluses possivelmente s podero ser
feitas mediante determinadas condies.

Os demais casos de uso sero considerados os mais

complexos.

PRIORIZAO DOS COMPLEXOS

recomendvel que os casos de uso complexos
ainda sejam organizados do mais importante
para o menos importante em relao ao negcio
da empresa.

O analista deve se perguntar, qual dos processos
o mais crtico para o sucesso da empresa.

Em funo disso, far a ordenao.

Por exemplo, uma venda possivelmente ser mais

importante do que uma compra, uma compra mais
importante do que uma reserva, uma reserva mais
importante do que um cadastro, etc.

ESTIMATIVAS
Na fase de concepo a equipe deve produzir
estimativas de esforo para casos de uso.

A partir desse clculo, deve-se fazer um
planejamento de longo prazo, procurando
acomodar os casos de uso, de acordo com sua
prioridade nos diferentes ciclos ao longo do
processo de desenvolvimento.

Mas esse planejamento no deve ser muito
detalhado.

PLANEJAMENTO
Apenas o primeiro ciclo deve ter um
planejamento mais detalhado, com suas tarefas
definidas de acordo com o processo em uso e os
tempos, responsveis e recursos para execuo de
cada tarefa bem definidos.

Os demais ciclos tero seu planejamento
detalhado um pouco antes de iniciarem apenas.

VIABILIDADE

A fase de concepo envolve tambm o estudo de

viabilidade, pois ao seu final a equipe deve
decidir se vivel prosseguir com o projeto,
analisadas as questes tecnolgicas, de
oramento e de cronograma.

FASE DE ELABORAO
A fase de elaborao consiste em um
detalhamento da anlise e realizao do projeto
para o sistema como um todo.

A elaborao ocorre em ciclos, com partes de
projeto sendo desenvolvidas e integradas ao longo
de cada ciclo.

OBJETIVOS DA ELABORAO
Analisar o domnio do problema de forma mais
refinada, permitindo definir uma arquitetura
mais adequada e slida.

Eliminar ou mitigar os elementos de projeto que
apresentem o maior risco.

FASE DE CONSTRUO
Na fase de construo, um produto completo e
usvel deve estar desenvolvido, testado e
adequado para uso pelo usurio final.

A fase de construo tambm realizadas em
ciclos iterativos.

O projeto desenvolvido tambm de forma
incremental, com novas funcionalidades sendo
adicionadas ao sistema a cada ciclo.

FASE DE TRANSIO
A fase de transio consiste da colocao do
sistema em uso no ambiente final.

So necessrios testes de aceitao e operao,
treinamento de usurios e transio de dados a
partir de sistemas antigos, que podem ser
capturados automaticamente ou digitados.

Aps a concluso da fase de transio o sistema
entra em evoluo, ou seja, aps aceito e colocado
em operao no ambiente final, ele passa a
receber atualizaes peridicas de forma a
corrigir possveis erros ou implantar novas
funcionalidades necessrias.

IMPLEMENTAES DO UP

O UP um modelo de processo com vrias implementaes

conhecidas.
A maioria das implementaes varia a maneira como as
diferentes disciplinas so definidas e organizadas.
As implementaes tambm podem variar a importncia
que do a diferentes artefatos.

As implementaes geis do UP, por exemplo,
simplificam as disciplinas e reduzem o nmero de
artefatos esperados.
O nmero de implementaes do UP bastante grande, j
que cada empresa pode implementar o modelo de acordo
com suas necessidades.
Wikipdia (2010) enumera vrias implementaes
importantes.

RATIONAL UNIFIED PROCESS - RUP

A mais detalhada e mais antiga implementao
conhecida como RUP (Rational Unified Process),
criada por Booch, Rumbaugh e Jacobson atravs
da empresa Rational, desde 2003 subsidiria da
IBM.

Antes de pertencer IBM, a empresa Rational
em 1997 adquiriu vrias outras empresas:

Verdix, Objectory, Requisite, SQA, Performance

Awareness e Pure-Atria.

A verso RUP to importante que normalmente

confundida ou considerada sinnimo de UP.

FILOSOFIA RUP

Desenvolver iterativamente tendo o risco como

principal fator de determinao de iteraes.

Gerenciar requisitos.

prefervel conhecer todos os requisitos antes de iniciar o

desenvolvimento propriamente dito, mas isso normalmente
no vivel, de forma que o desenvolvimento iterativo
orientado a reduo de risco bastante adequado.
Deve-se manter controle sobre o grau de incorporao dos
requisitos do cliente ao produto.

Empregar uma arquitetura baseada em

componentes.

Quebrar um sistema complexo em componentes no s

necessrio, como inevitvel. A organizao permite diminuir o
acoplamento, o que possibilita testes mais confiveis e maior
possibilidade de reuso.

FILOSOFIA RUP

Modelar software e forma visual com diagramas.

Verificar a qualidade de forma contnua.

UML indicada como padro de modelagem de diagramas.

O processo deve ser to orientado a testes quanto possvel. Se
for o caso, utiliza-se tcnicas de desenvolvimento orientados a
testes, como TDD, ou Test-driven development.

Controlar as mudanas.

A integrao deve ser contnua e gerenciada adequadamente.

BUILDING BLOCKS

Quem.

Um papel define um conjunto de habilidades

necessrio para realizar determinadas atividades.

O qu.

O produto do trabalho (work product) define algo

produzido por alguma tarefa ou atividade, como
diagramas, relatrios ou cdigo funcionando.

Trata-se dos artefatos no dialeto RUP.

Como.

Uma tarefa descreve uma unidade de trabalho

atribuda a um papel que produz um determinado
conjunto de produtos do trabalho.

DISCIPLINAS RUP

De projeto:

Modelagem de negcio.
Requisitos.
Anlise e projeto.
Implementao.
Teste.
Implantao.

De suporte:
Gerenciamento de mudana e configurao.

Gerenciamento de projeto.

Ambiente.

NFASES

Fonte: Ambler (2005) IBM

DISCIPLINA: MODELAGEM DE NEGCIO

A modelagem de negcio consiste em estudar e

compreender a empresa e seus processos, visto que o
sistema e software a ser desenvolvido no ser um produto
isolado na empresa, mas parte de seu funcionamento.
Um dos pontos crticos para o sucesso de um projeto de
desenvolvimento de software o seu financiamento.

Para que o cliente se mantenha interessado no
desenvolvimento de um produto, ele deve estar sempre
convencido de que o investimento no produto
representar uma vantagem para ele e no uma despesa
intil.

A compreenso do modelo de negcio fundamental
para que a equipe de desenvolvimento permanea
sintonizada com esta compreenso e mantenha o cliente
interessado.

DISCIPLINA: MODELAGEM DE NEGCIO

Outro aspecto importante da modelagem de

negcio aproximar as equipes de engenharia de
negcio e engenharia de software, de forma que
os reais problemas e necessidades da organizao
sejam entendidos, analisados e solucionados com
tecnologia da informao.

DISCIPLINA: REQUISITOS
Requisitos so a expresso mais detalhada sobre
aquilo que o usurio ou cliente precisa em termos
de um produto de software.

O workflow RUP para a disciplina inclui cinco
papeis: analista de sistemas, especificador de
caso de uso, projetista de interface com usurio,
arquiteto e revisor de requisitos.

As tarefas associadas, suas dependncias e
responsveis so mostrados no diagrama de
atividades UML seguinte:

WORKFLOW DE REQUISITOS RUP

RESPONSABILIDADES

O analista de sistemas deve produzir:

a viso geral do sistema, as necessidades dos
interessados (documento de requisitos com atributos da
anlise de requisitos), o modelo (diagrama) de casos de
uso, o glossrio e especificaes suplementares.
O especificador de casos de uso responsvel pelos casos de
uso expandidos.
O arquiteto e responsvel pela definio da arquitetura do
sistema.
O projetista de interfaces responsvel por:

definir os atores, storyboards dos casos de uso,
prottipos de interface e pela definio da classe de
interface (boundary).
O revisor de requisitos apenas deve aprovar os documentos
em sua forma final ou indicar correes quando necessrio.

DISCIPLINA: ANLISE E PROJETO

Anlise implica no estudo do problema de forma
mais aprofundada.

Requisitos so detalhados e includos em modelos
de anlise como o modelo conceitual, de interao
e funcional.

J o projeto consiste em apresentar uma possvel
soluo tecnolgica para o modelo de anlise.

Os modelos de projeto podem ser o modelo
dinmico, de interface, de persistncia, alm de
outros.

Wazlawick (2004) apresenta muitas informaes
sobre como realizar esta disciplina do UP.

DISCIPLINA: IMPLEMENTAO
A implementao mais do que simplesmente
produzir cdigo.

Ela implica tambm na organizao deste cdigo
em componentes ou pacotes, na definio de
possveis camadas de implementao, nos testes
de unidade e na integrao de cdigo de forma
incremental.

DISCIPLINA: TESTE

O propsito da disciplina de testes :

Verificar a interao entre objetos.

Verificar se todos os componentes foram integrados
adequadamente.

Verificar se todos os requisitos foram corretamente
implementados.

Verificar e garantir que defeitos tenham sido
identificados e tratados antes da entrega do produto
final.

Garantir que todos os defeitos tenham sido consertados,
retestados e estancados.
No processo unificado a disciplina de teste executada ao
longo de todos os ciclos, o que facilita a deteco prematura
de erros de requisitos e de implementao.

DISCIPLINA: IMPLANTAO
O propsito da disciplina de implantao a
produo de verses (releases) do produto a
serem entregues aos usurios finais.

Entre outras atividades inclui-se a produo do
software, eu empacotamento, instalao,
migrao de dados e apoio aos usurios
(treinamento e suporte).

Apesar da disciplina de implantao se
concentrar na fase de transio, quando se est
entregando o produto definitivo, podero haver
vrias releases ao longo do projeto, quando
produtos preliminares podero ser entregues,
mesmo nas fases de elaborao ou construo.

DISCIPLINA: GERENCIAMENTO DE
MUDANA E CONFIGURAO

Trs reas:
Gerenciamento de configurao.

Gerenciamento de requisies de mudana.

Gerenciamento de status e medio.

GERENCIAMENTO DE CONFIGURAO
Responsvel pela estruturao sistemtica dos
produtos.

Artefatos como documentos e diagramas devem
estar sob controle de verso e mudanas feitas
devem ser visveis e localizveis.

Tambm necessrio manter um registro de
dependncias ou rastreabilidade entre artefatos
de forma que artefatos relacionados sejam
atualizados quando necessrio.

GERENCIAMENTO DE REQUISIES DE
MUDANA

A rea de CRM (Change Request Management)

cuidar do controle das requisies de mudana
em artefatos que produzem as diferentes verses
destes.

GERENCIAMENTO DE STATUS E MEDIO

Requisies de modificaes tm estados como:
novo, atribudo, concludo e entregue.

Elas tambm podem ter atributos como causa,
fonte, natureza, prioridade, etc.

O gerenciamento de status coloca todos estes
atributos em um sistema de informao tal que o
andamento de cada solicitao seja verificvel a
todo momento pelo gerente do projeto.

DISCIPLINA: GERENCIAMENTO DO
PROJETO
O planejamento no RUP ocorre em dois nveis:
fase e iterao.

Ambos focam importantes aspectos do controle do
projeto como gerenciamento de riscos,
planejamento, aplicao de mtricas, controle de
qualidade e monitoramento.

Entretanto, RUP no trata os seguintes aspectos:

Gerenciamento de pessoas, incluindo contratao e

treinamento.

Gerenciamento de oramento.

Gerenciamento de contratos.

PLANOS
A disciplina de gerenciamento de projeto produz
planos.

Existem os planos de fase e os planos de iterao.

PLANOS DE FASE SO SUBORDINADOS A:

O plano de medio (measurement plan), que estabelece as

mtricas a serem usadas para definir o andamento do projeto ao
longo de sua execuo.

O plano de gerenciamento de riscos, que detalha como os riscos

sero tratados ao longo do projeto, criando tarefas de mitigao e
monitoramento de riscos e atribuindo responsabilidades quando
necessrio.

A lista de riscos, que uma lista ordenada dos riscos conhecidos e

ainda no resolvidos, em ordem decrescente de, juntamente com
planos de mitigao e contingncia quando for o caso.

O plano de resoluo de problemas, que descreve como problemas

identificados ao longo do projeto devem ser reportados, analisados
e resolvidos.

O plano de aceitao de produto, que descreve como o produto

ser avaliado pelo cliente para verificar se satisfaz as
necessidades. O plano deve incluir a identificao dos testes de
aceitao.

PLANO DE ITERAO
O plano de iterao um plano mais detalhado
do que o plano de fase.

Ele inclui um cronograma de tarefas ou
atividades atribudas a responsveis, com
recursos alocados, prazos e dependncias.

Usualmente h sempre um plano de iterao
sendo seguido enquanto o da iterao seguinte j
vai se delineando, para ser finalizado ao final do
ciclo corrente.

ELEMENTOS NECESSRIOS PARA DEFINIR

UM PLANO DE ITERAO
O plano da fase corrente includo no plano de
projeto.

Informao sobre o status do projeto (por
exemplo, atrasado, em dia, com grandes riscos em
aberto, etc.).

Uma lista de casos de uso que pelo plano da fase
devem ser finalizados na iterao corrente.

Uma lista dos riscos que devem ser tratados na
iterao corrente.

Uma lista das modificaes que devem ser
incorporadas ao produto na iterao corrente
(defeitos e erros encontrados ou mudanas de
funcionalidade).

PLANO DE ITERAO

Todas as listas acima devem ser ordenadas do

mais importante para o menos importante, de
forma que se a iterao for muito mais trabalhosa
do que esperado os itens menos importantes
possam ser deixados para iteraes posteriores.

DISCIPLINA: AMBIENTE

Trata principalmente da configurao do prprio processo para o

projeto.

Em funo do processo especfico escolhido essa disciplina deve

tambm tratar das ferramentas de apoio necessrias para que a
equipe tenha sucesso no projeto.

Se uma equipe tenta implementar RUP integralmente sem

perceber que ele na verdade um framework para adaptao de
processos, poder ficar a impresso de que se trata de um
processo altamente complexo e virtualmente impraticvel.

necessrio que um especialista em RUP avalie o escopo do

projeto e a realidade da equipe para decidir quais elementos do
RUP efetivamente devem ser usados.

Algumas verses mais simples de RUP, como AUP e OpenUP, j

se estabeleceram como implementaes independentes e sero
vistas mais adiante.

AGILE UNIFIED PROCESS - AUP

O Agile Unified Process, ou AUP, uma verso
simplificada do RUP desenvolvida por Scott
Ambler (Ambler & Jeffries, 2002).

AUP aplica tcnicas geis como desenvolvimento
dirigido por testes (TDD Test Driven
Development), modelagem gil e refatorao.

APENAS 7 DISCIPLINAS:

Modelagem.

Implementao.

Gerenciar o acesso aos artefatos do projeto.

Gerenciamento de projeto.

Planejar as entregas de sistema para tornar o sistema acessvel para usurios.

Gerenciamento de configurao.

Efetuar testes de integrao, de sistema e de aceitao para garantir que o sistema

tenha qualidade e implemente os requisitos corretos corretamente.

Implantao.

Transformar os modelos em cdigo executvel e criar testes de unidade.

Teste.

Entender o negcio da empresa atravs de modelos produzidos que buscam tambm

identificar possveis solues para estes problemas.

Controlar as atividades de projeto, garantindo que tarefas sejam atribudas s pessoas

certas e executadas no prazo.

Ambiente.

Dar suporte equipe garantindo que as ferramentas, guias e padres estejam

disponveis quando necessrio.

FILOSOFIA AUP

Sua equipe sabe o que est fazendo.

Simplicidade.

O foco est nas atividades que realmente produzem valor, no em qualquer coisa
que eventualmente poderia ser feita.

Independncia de ferramentas.

AUP aceita e se conforma aos princpios geis.

Foco em atividades de alto valor.

Tudo deve poder ser descrito com simplicidade em algumas pginas, e no

milhares de pginas.

Agilidade.

As pessoas dificilmente gostaro de ter que ler instrues detalhadas sobre como
fazer o seu trabalho, mas de tempos em tempos precisaro de alguma instruo
para gui-las.
importante identificar o ponto de equilbrio entre as necessidades da equipe e
a saturao com instrues demasiadas.

A equipe pode usar qualquer ferramenta para desenvolver o projeto desde que
seja bem adaptada s suas necessidades.

AUP pode ser ajustado para satisfazer suas necessidades.

Como outros processos geis, AUP no possui clusulas ptreas e pode ser
ajustado de acordo com a necessidade.

AUP DISTINGUE DOIS TIPOS DE ITERAES

Iteraes de desenvolvimento, que tem como
objetivo desenvolver resultados para garantia de
qualidade, prova de conceito ou reduo de risco.

Iteraes de produo, que tem como objetivo a
produo de uma nova verso de cdigo usvel.

OPEN UNIFIED PROCESS - OPENUP

Anteriormente conhecido como Basic Unified
Process (BUP) ou OpenUP/Basic, o Open Unified
Process (OpenUP) uma implementao aberta
do UP desenvolvida como parte do Eclipse Process
Framework (EPF).

A primeira verso do modelo, conhecida como
BUP foi originada pela IBM que abriu a definio
de uma verso mais leve do RUP.

Entre 2005 e 2006 essa verso foi abraada pela
Fundao Eclipse (Eclipse Foundation, 2010) e
passou a ser um de seus projetos.

OPENUP
OpenUP aceita, embora de forma simplificada, a
maioria dos princpios UP.

Porm, um mtodo independente de ferramenta
e de baixa cerimnia, ou seja, no exigida
grande preciso e detalhes nos documentos.

O ciclo de vida tambm estruturado em quatro
fases, como no UP.

As fases tambm so divididas em iteraes.

As equipes se auto-organizam para planejar cada
iterao.

OPENUP
O esforo pessoal organizado em microincrementos, que representam pequenas
unidades de trabalho que produz um ritmo mais
fino e mensurvel para o projeto.

Em relao ao RUP, a maioria das prticas
opcionais foram eliminadas e outras foram
mescladas. O resultado um processo mais
simples mas ainda fiel aos princpios de RUP.

OPENUP
Em OpenUP cada prtica pode ser adotada como
um princpio independente que agrega valor
equipe.

Desta forma, as prticas podem ser adotadas de
forma progressiva, ao longo de vrios projetos.

Alm disso, como nos modelos de software livre
de cdigo aberto, novas prticas podem ser
sugeridas pela comunidade e passar a ser
adotadas se houver interesse de outros.

ENTERPRISE UNIFIED PROCESS EUP

O Enterprise Unified Process, ou EUP, foi inicialmente

definido por Ambler e Constantine em 1999 e
posteriormente refinado por Ambler, Nalbone e Vizdos
(2005).
O modelo EUP v o desenvolvimento de software no
apenas como um projeto executado, mas como algo
intrnseco ao ciclo de vida da prpria empresa.
EUP foi proposto como uma extenso ao modelo RUP para
prover, alm das fases de RUP duas novas fases para tratar
a evoluo ou suporte ao sistema e a aposentadoria do
sistema.
Alm destas duas fases, vrias novas disciplinas
relacionadas a empresas foram adicionadas.

NOVAS FASES DO EUP

Produo.
O desenvolvimento de sistemas usualmente no
acaba quando o produto entregue e colocado em uso.

A fase de produo trata exatamente das atividades
que ocorrem aps a transio, incluindo o suporte,
correo e ajustes e evoluo do sistema.

Aposentadoria.
A fase de aposentadoria consiste na retirada de um
sistema de operao.

a fase final de qualquer sistema.

Sistemas antigos retirados de operao para serem
substitudos por sistemas novos podem causar srios
danos empresa se o processo no for gerenciado
adequadamente.

NOVA DISCIPLINA DE PROJETO: OPERAO

E SUPORTE
O objetivo principal da disciplina de operao e
suporte manter o produto funcionando no
ambiente de produo.

Deve-se garantir que o software funcione
corretamente, que a rede esteja funcionando, que
os dados sejam guardados em backups e possam
ser restaurados se necessrio.

Planos de recuperao de desastre devem ser
criados e se for o caso executados (Ambler, 2010).

NOVAS DISCIPLINAS DE EMPRESA

Modelagem de negcio de empresa.

Gerenciamento de portflio.

Arquitetura de empresa.

Reuso estratgico.

Gerenciamento de pessoas.

Administrao de empresa.

Melhoramento de processo de software.

MODELAGEM DE NEGCIO DE EMPRESA

O RUP j apresenta uma disciplina de
modelagem de negcio, mas do ponto de vista do
sistema a ser desenvolvido.

A modelagem de negcio de empresa mais
abrangente, incluindo todos os processos da
empresa e, desta forma, relaes entre diferentes
sistemas.

GERENCIAMENTO DE PORTFLIO
Um portflio uma coleo e projetos de software
em progresso e concludos.

Trata-se de projetos de alto risco alto retorno e
projetos e baixo risco e baixo retorno que devem
ser gerenciados como aes para satisfazer as
necessidades estratgicas da empresa.

ARQUITETURA DE EMPRESA
A arquitetura de empresa define como ela
trabalha.

Essa disciplina especialmente til se a empresa
possuiu muitos produtos de software.

Deve haver consistncia na forma como eles so
desenvolvidos, negociados e entregues.

A arquitetura de empresa a chave para
compreender isso como um processo.

REUSO ESTRATGICO
O reuso estratgico vai alm do reuso que se
consegue dentro de um nico projeto.

Ele se estende entre diferentes projetos.

Esse tipo de reuso costuma produzir mais valor
do que o reuso simples dentro de um nico
projeto.

GERENCIAMENTO DE PESSOAS
Esta disciplina define uma abordagem para
gerenciamento de recursos humanos da rea de
Tecnologia de Informao.

preciso gerenciar o pessoal, contratar, demitir,
substituir, alocar pessoas a projetos e investir em
seu crescimento.

ADMINISTRAO DE EMPRESA

Esta disciplina define como a empresa cria,

mantm, gerencia, e entrega produtos fsicos e
informaes de forma segura.

MELHORAMENTO DE PROCESSO DE
SOFTWARE

Esta disciplina trata da adequao e evoluo do

processo de software para a empresa como um
todo, no apenas a adequao do processo a cada
projeto individual.

ORACLE UNIFIED METHOD (OUM)

O Oracle Unified Method, ou OUM (Oracle,

2009), um framework de processo de
desenvolvimento de software iterativo e
incremental adequado a uso com produtos Oracle:
bancos de dados, aplicaes e middleware.

OUM

OUM uma implementao do processo unificado

que suporta, entre outras caractersticas:

Service Oriented Architecture (SOA)

Enterprise Integration
software personalizado
gerenciamento de identidade (Identity Magagement,
IdM)
governana, risco e adequao (Governance, Risk and
Compliance, GRC)
segurana de banco de dados
gerenciamento de performance
inteligncia empresarial.

RATIONAL UNIFIED PROCESSSYSTEM

ENGINEERING RUP-SE
RUP-SE uma extenso do modelo RUP para
Engenharia de Sistemas (Cantor, 2003).

Em outras palavras, uma verso de RUP
especialmente adequada para desenvolvimento
de sistemas de grande porte, envolvendo,
software, hardware, pessoas e componentes de
informao.

RUP-SE
RUP-SE inclui um framework de arquitetura que
permite considerar o sistema a partir de
diferentes perspectivas (lgica, fsica,
informacional, etc.).

Isso pode ser bastante til quando se deseja
demonstrar ou discutir aspectos de um sistema
com diferentes interessados (cliente, analistas
programadores, engenheiro de informao, etc.).

RUP-SE ADEQUADO A PROJETOS COM S

SEGUINTES CARACTERSTICAS:
So grandes o suficiente para comportar vrias
equipes de desenvolvimento trabalhando em
paralelo.

Necessitam desenvolvimento concorrente de
hardware e software.

A arquitetura impactada por questes relativas
implantao.

Incluem a reengenharia de uma infraestrutura
de tecnologia informao para suportar a
evoluo do negcio.

BIBLIOGRAFIA

Ambler, S. W. (2005). A Managers Introduction to The Rational Unified Process (RUP). Ambsoft.
Disponvel em: http://www.ambysoft.com/downloads/managersIntroToRUP.pdf. Consultado em
23/03/2010.

Ambler, S. W., Jeffries, R. (2002). Agile Modeling: Effective practices for eXtreme Programming and
the Unified Process. John Willey and Sons.

Ambler, S. W., Nalbone, J., Vizdos, M. J. (2005). The Enterprise Unified Process: Extending the
Rational Unified Process. Prentice-Hall.

Ambler, S. W. (2010). The Operations and Support Discipline: Scaling agile software development.
Disponvel em: http://www.enterpriseunifiedprocess.com/essays/operationsAndSupport.html.
Consultado em: 23/03/2010.

Cantor, M. (2003). Rational Unified Process for Systems Engineering. IBM. Disponvel em:
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/aug03/f_rupse_mc.pdf.
Consultado em 23/03/2010.

Eclipse Foundation (2010). Introduction to OpenUP. Disponvel em:

http://epf.eclipse.org/wikis/openup/index.htm. Consultado em 23/03/2010.

Jacobson, I., Booch, G., Rumbaugh, J. (1999). The Unified Software Development Process. AddisonWesley.

Wazlawick, R. S. (2004). Anlise e Projeto de Sistemas de Informao Orientados a Objetos. Rio de

Janeiro: Elsevier.

West, D. (2002). Planning a Project with the Rational Unified Process. Rational Software White
Paper. TP 151, 08/02. Disponvel em: http://www.scribd.com/doc/41162/Planning-a-project-with-RUP.
Acessado em: 24/03/2010.

Wikipdia: IBM Rational Unified Process (2010) IBM Rational Unified Process. Disponvel em:
http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process. Consultado em: 23/03/2010.