Escolar Documentos
Profissional Documentos
Cultura Documentos
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.
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.
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
ITERATIVO E INCREMENTAL
FOCADO EM RISCOS
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).
Elaborao (elaboration).
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.
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
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
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
FILOSOFIA RUP
Gerenciar requisitos.
FILOSOFIA RUP
Controlar as mudanas.
BUILDING BLOCKS
Quem.
O qu.
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
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:
RESPONSABILIDADES
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
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
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:
PLANOS
A disciplina de gerenciamento de projeto produz
planos.
Existem os planos de fase e os planos de iterao.
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.
PLANO DE ITERAO
DISCIPLINA: AMBIENTE
APENAS 7 DISCIPLINAS:
Modelagem.
Implementao.
Gerenciamento de projeto.
Gerenciamento de configurao.
Implantao.
Teste.
Ambiente.
FILOSOFIA AUP
Simplicidade.
O foco est nas atividades que realmente produzem valor, no em qualquer coisa
que eventualmente poderia ser feita.
Independncia de ferramentas.
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.
Como outros processos geis, AUP no possui clusulas ptreas e pode ser
ajustado de acordo com a necessidade.
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.
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.
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
MELHORAMENTO DE PROCESSO DE
SOFTWARE
OUM
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.).
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.
Jacobson, I., Booch, G., Rumbaugh, J. (1999). The Unified Software Development Process. AddisonWesley.
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.