Rational Unified Process: Viso Geral

O Rational Unified Process (tambm chamado de processo RUP) um processo de engenharia

de software. Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e
responsabilidades dentro de uma organizao de desenvolvimento. Sua meta garantir a produo
de software de alta qualidade que atenda s necessidades dos usurios dentro de um cronograma e
de um oramento previsveis.

A figura acima mostra a arquitetura geral do RUP.

O RUP tem duas dimenses:
-

O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo

medida que se desenvolve
O eixo vertical representa as disciplinas, que agrupam as atividades de maneira lgica, por
natureza.

A primeira dimenso representa o aspecto dinmico do processo quando ele aprovado e

expressa em termos de fases, iteraes e marcos.
A segunda dimenso representa o aspecto esttico do processo, como ele descrito em termos de
componentes, disciplinas, atividades, fluxos de trabalho, artefatos e papis do processo
(consulte Conceitos-chave)
O grfico mostra como a nfase varia atravs do tempo. Por exemplo, nas iteraes iniciais,
dedicamos mais tempo aos requisitos. J nas iteraes posteriores, gastamos mais tempo com
implementao.

Rational Unified Process: Introduo

O processo unificado consiste da repetio de uma srie de ciclos durante a vida de um sistema,
como mostrado a seguir. Cada ciclo concludo com uma verso do produto pronta para
distribuio. Essa verso um conjunto relativamente completo e consistente de artefatos,
possivelmente incluindo manuais e um mdulo executvel do sistema, que podem ser distribudos
para usurios internos ou externos.

Modelo de Ciclo de Vida Proposto pelo RUP

Cada ciclo consiste de quatro fases: Iniciao, Elaborao, Construo e Transio. Cada fase
tambm subdividida em iteraes, como discutido anteriormente, vide figura a seguir.

Um ciclo com suas fases e iteraes

Rational Unified Process: Fases

As fases e os marcos de um projeto

A partir de uma perspectiva de gerenciamento, o ciclo de vida de software do Rational Unified

Process (RUP) dividido em quatro fases seqenciais, cada uma concluda por um marco
principal, ou seja, cada fase basicamente um intervalo de tempo entre dois marcos principais. Em

cada final de fase executada uma avaliao para determinar se os objetivos da fase foram
alcanados. Uma avaliao satisfatria permite que o projeto passe para a prxima fase.
Fases de Planejamento
As fases no so idnticas em termos de programao e esforo. Embora isso varie muito de acordo
com o projeto, um ciclo de desenvolvimento inicial tpico para um projeto de mdio tamanho deve
prever a seguinte distribuio de esforo e programao:
Esforo
Programa
o

Iniciao
~5 %
10 %

Elaborao
20 %
30 %

Construo
65 %
50 %

Transio
10%
10%

que pode ser descrito graficamente da seguinte forma:

Para um ciclo de evoluo, as fases de Iniciao e de elaborao seriam bem menores. Ferramentas
que automatizam parte do esforo de Construo podem amenizar isso, tornando a fase Construo
muito menor do que as fases de Iniciao e de Elaborao juntas.
Uma passagem pelas quatro fases um ciclo de desenvolvimento; cada passagem pelas quatro
fases produz uma verso do software. A menos que o produto "desaparea", ele ir se desenvolver
na prxima verso, repetindo a mesma seqncia de fases de Iniciao, Elaborao, Construo e
Transio, mas agora com nfase diferente nas diversas fases. Esses ciclos subseqentes so
chamados de ciclos de evoluo. medida que o produto atravessa vrios ciclos, so produzidas
novas geraes.

Os ciclos de evoluo podem ser disparados por melhorias sugeridas pelos usurios, mudanas no
contexto do usurio, mudanas na tecnologia subjacente, reao concorrncia e assim por diante.
Normalmente, os ciclos de evoluo tm fases de Iniciao e Elaborao bem menores, pois a
definio e a arquitetura bsicas do produto foram determinadas por ciclos de desenvolvimento
anteriores. So excees a essa regra os ciclos de evoluo em que ocorre uma redefinio
significativa do produto ou da arquitetura.

Fase: Iniciao (Inception)

Objetivos
A meta dominante da fase Iniciao atingir o consenso entre todos os envolvidos sobre os
objetivos do ciclo de vida do projeto. A fase Iniciao tem muita importncia principalmente para
os esforos dos novos desenvolvimentos, nos quais h muitos riscos de negcios e de requisitos
que precisam ser tratados para que o projeto possa prosseguir. Para projetos que visam melhorias
em um sistema existente, a fase Iniciao mais rpida, mas ainda se concentra em assegurar que o
projeto seja compensatrio e que seja possvel faz-lo.
Os objetivos principais da fase Iniciao incluem:

Estabelecer o escopo do projeto do software e as condies limite, incluindo uma viso

operacional, critrios de aceitao e o que deve ou no estar no produto.
Discriminar os casos de uso crticos do sistema, os principais cenrios de operao e o que
direcionar as principais trocas de design.
Exibir, e talvez demonstrar, pelo menos uma opo de arquitetura para alguns cenrios
bsicos.
Estimar o custo geral e a programao para todo o projeto (e estimativas detalhadas para a
fase Elaborao, imediatamente a seguir).
Estimar riscos em potencial (as origens de imprevistos)
Preparar o ambiente de suporte para o projeto.

Atividades bsicas

Formular o escopo do projeto. Isso envolve capturar o contexto, bem como os requisitos e
as restries mais importantes, para que seja possvel depreender critrios de aceitao para o
produto final.
Planejar e preparar um caso de negcio. Avaliar alternativas para o gerenciamento de
riscos, a organizao da equipe, o plano do projeto e as mudanas de
custo/programao/lucros.
Sintetizar uma possvel arquitetura, avaliando as mudanas no design e em
fazer/comprar/reutilizar, para que seja possvel estimar custo, programao e recursos. O
objetivo aqui demonstrar a possibilidade de execuo atravs de alguma forma de prova de
conceito. Isso pode ter a forma de um modelo que simula o que exigido, ou de um
prottipo inicial que explora as reas consideradas de alto risco. O esforo do prottipo
durante a Iniciao deve se limitar a ganhar confiana na possibilidade de uma soluo - a
soluo ser executada durante a elaborao e a construo.
Preparar o ambiente para o projeto, avaliando o projeto e a organizao, selecionando
ferramentas e decidindo quais partes do processo devem ser melhoradas.
Marco: Objetivos do Ciclo de Vida (Lifecycle Objectives Milestone)
No final da fase Iniciao (Inception) est o primeiro marco mais importante do projeto ou Marco
dos Objetivos do Ciclo de Vida. Nesse momento, so analisados os objetivos do ciclo de vida do
projeto e decidido sobre prosseguir com o projeto ou cancel-lo.

Critrios de Avaliao
Consentimento dos envolvidos sobre a definio do escopo e as estimativas de
custo/programao.
Consenso de que o conjunto correto de requisitos foi capturado e de que existe uma
compreenso compartilhada desses requisitos.
Consenso de que as estimativas de custo/programao, as prioridades, os riscos e o processo
de desenvolvimento so adequados.
Todos os riscos foram identificados e existe uma estratgia de mitigao para cada um.
O projeto poder ser cancelado ou completamente repensado caso ele no atinja este marco.
Artefatos
Artefatos Bsicos

Estado no marco
Viso
Os requisitos principais, as caractersticas-chave e as principais
restries do projeto foram documentados.
Caso de Negcio
Definido e aprovado.
Lista de Riscos
Riscos iniciais do projeto identificados.
Plano de Desenvolvimento de Identificao das fases iniciais, durao e objetivo de cada uma.
Software
Estimativas de recursos (particularmente o tempo, o pessoal e os
custos com ambiente de desenvolvimento) no Plano de
Desenvolvimento de Software devem ser consistentes com o Caso
de Negcio.
A estimativa de recursos pode abranger o projeto inteiro at a
liberao, ou apenas uma estimativa de recursos necessrios para a
fase Elaborao. As estimativas de recursos para o projeto inteiro
devem ser vistas como brutas nesse momento. Essa estimativa
atualizada em cada fase e cada iterao, e se torna mais exata a
cada iterao.
Dependendo das necessidades do projeto, um ou mais artefatos de
"Plano" includo pode ser concludo condicionalmente. Um Plano
de Aceitao do Produto inicial deve ser analisado e receber uma
baseline. O Plano de Aceitao do Produto refinado nas iteraes
subseqentes medida que forem descobertos requisitos
adicionais.

Plano de Iterao
Caso de Desenvolvimento
Ferramentas
Glossrio

Alm disso, os artefatos de "Guias" includos normalmente esto

pelo menos na forma de "rascunho".
O plano de iterao para a primeira iterao de Elaborao
concludo e analisado.
Adaptaes e extenses ao Rational Unified Process,
documentadas e analisadas.
Todas as ferramentas para suportar o projeto so selecionadas. So
instaladas as ferramentas necessrias para o trabalho na Iniciao.
Termos importantes definidos; glossrio analisado.

Modelo de Casos de Uso

(Atores, Casos de Uso)
Repositrio do Projeto,
Solicitao de Mudana
Artefatos Opcionais
Diretrizes de Modelagem de
Casos de Uso
Modelo de Domnio (tambm
conhecido como Modelo de
Objeto de Negcio)
Templates Especficos do
Projeto
Prottipos

Atores e casos de uso importantes identificados, e fluxos de

eventos descritos apenas para os casos de uso mais crticos.
O ambiente de Gerenciamento de Configurao deve estar
configurado.
Estado no marco
Com baseline.
Os conceitos-chave usados no sistema, documentados e
analisados. Usado como uma extenso do Glossrio nos casos em
que h relacionamentos especficos entre conceitos de captura
essencial.
Os templates de documentos usados para desenvolver os artefatos
de documentos.
Uma ou mais provas de conceitos (prottipos), para suportar a
Viso e o Caso de Negcio e para tratar riscos especficos.

Fase: Elaborao (Elaboration)

Objetivos
A meta da fase Elaborao criar uma base para a arquitetura do sistema a fim de fornecer
sustentabilidade ao esforo da fase Construo. A arquitetura se desenvolve a partir de um exame
dos requisitos mais significativos (aqueles que tm grande impacto na arquitetura do sistema) e de
uma avaliao dos riscos. A estabilidade da arquitetura avaliada atravs de um ou mais prottipos
de arquitetura.
Os objetivos primrios da fase Elaborao incluem:
Assegurar que a arquitetura, os requisitos e os planos sejam estveis o suficiente e que os
riscos sejam suficientemente diminudos a fim de determinar com segurana o custo e a
programao para a concluso do desenvolvimento. Para a maioria dos projetos, ultrapassar
essa marca tambm corresponde transio de uma operao rpida e de baixo risco para
uma operao de alto custo e alto risco com uma inrcia organizacional freqente.
Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto.
Estabelecer uma arquitetura de base derivada do tratamento dos cenrios significativos do
ponto de vista da arquitetura, que normalmente expem os maiores riscos tcnicos do
projeto.
Produzir um prottipo evolutivo dos componentes de qualidade de produo, assim como
um ou mais prottipos descartveis para diminuir riscos especficos como:
o Trocas de design/requisitos
o Reutilizao de componentes
o Possibilidade de produo do produto ou demonstraes para investidores, clientes e
usurios finais
Demonstrar que a arquitetura de base suportar os requisitos do sistema a custo e tempo
justos.
Estabelecer um ambiente de suporte.

Para atingir esses objetivos bsicos, tambm importante configurar o ambiente de suporte para o
projeto. Isso inclui criar um caso de desenvolvimento, criar templates e diretrizes, e configurar
ferramentas.
Atividades bsicas
Definir, validar e criar a arquitetura de base com rapidez e eficincia.
Refinar a Viso, com base nas informaes novas obtidas durante a fase, estabelecendo uma
compreenso slida dos casos de uso mais crticos que conduzem as decises de arquitetura e
planejamento.
Criar planos de iterao detalhados e bases de referncia para a fase Construo.
Refinar o caso de desenvolvimento e posicionar o ambiente de desenvolvimento,
incluindo o processo, as ferramentas e o suporte de automatizao necessrios para dar
assistncia equipe de construo.
Refinar a arquitetura e selecionar os componentes. Os componentes potenciais so
avaliados e as decises de fazer/comprar/reutilizar so bem compreendidas para determinar o
custo da fase Construo e programar com confiana. Os componentes de arquitetura
selecionados so integrados e avaliados em comparao com os cenrios bsicos. As lies
aprendidas dessas atividades podem resultar em um novo design da arquitetura, levando em
considerao designs alternativos ou reconsiderando os requisitos.
Marco: Arquitetura do Ciclo de Vida (Lifecycle Architecture Milestone)
No final na fase Elaborao est o segundo marco mais importante do projeto, o Marco da
Arquitetura do Ciclo de Vida. Nesse momento, so examinados os objetivos e o escopo
detalhados do sistema, a opo de arquitetura e a resoluo dos principais riscos. O marco
Arquitetura do Ciclo de Vida estabelece uma base de referncia gerenciada para a arquitetura do
sistema e permite o escalonamento da equipe do projeto na fase Construo.
Critrios de Avaliao

A Viso e os requisitos do produto so estveis.

A arquitetura estvel.
As abordagens principais a serem usadas no teste e na avaliao foram comprovadas.
O teste e a avaliao de prottipos executveis demonstraram que os principais elementos de
risco foram tratados e resolvidos com credibilidade.
Os planos de iterao para a fase Construo tm detalhes e fidelidade suficientes para
permitir o avano do trabalho.
Os planos de iterao para a fase Construo so garantidos por estimativas confiveis.
Todos os envolvidos concordam que a viso atual poder ser atendida se o plano atual for
executado para desenvolver o sistema completo, no contexto da arquitetura atual.
A despesa real em oposio despesa planejada com recursos aceitvel.

O projeto poder ser cancelado ou completamente repensado caso ele no atinja este marco.
Artefatos
Artefatos Bsicos

Estado no marco

Prottipos

Um ou mais prottipos de arquitetura foram criados para

explorar a funcionalidade crtica e os cenrios significativos do
ponto de vista da arquitetura. Consulte a observao abaixo sobre
o papel do prottipo.

Lista de Riscos

Atualizada e analisada. Os novos riscos tendem a ser de natureza

da arquitetura, relacionados basicamente ao gerenciamento de
requisitos no funcionais.

Caso de Desenvolvimento

Refinado com base na experincia inicial do projeto. O ambiente

de desenvolvimento, incluindo o processo, as ferramentas e o
suporte automatizado necessrios para dar assistncia equipe de
construo j estar posicionada.

Ferramentas

As ferramentas usadas para suportar o trabalho de Elaborao

so instaladas.

Documento de Arquitetura
de Software

Criado e com baseline, incluindo descries detalhadas para os

casos de uso significativos para a arquitetura (viso de caso de
uso), identificao dos mecanismos principais e dos elementos de
design (viso lgica), mais a definio da viso de processos e da
viso da implantao (do Modelo de Implantao) caso o sistema
seja distribudo ou deva lidar com problemas de concorrncia.

Modelo de Design (e todos

os artefatos constituintes)

Definido e com baseline. Realizaes de caso de uso para

cenrios significativos do ponto de vista da arquitetura foram
definidas, e o comportamento necessrio foi alocado para os
elementos de design apropriados. Os componentes foram
identificados, e as decises de fazer/comprar/reutilizar foram
compreendidas para determinar o custo da fase Construo e
programar com confiana. Os componentes de arquitetura
selecionados so integrados e avaliados em comparao com os
cenrios bsicos. As lies aprendidas dessas atividades podem
resultar em um novo design da arquitetura, levando em
considerao designs alternativos ou reconsiderando os
requisitos.

Modelo de Dados

Definido e com baseline. Os elementos de modelo de dados

principais (por exemplo, entidades, relacionamentos, tabelas
importantes) definidos e analisados.

Modelo de Implementao (e Estrutura inicial criada e componentes principais identificados e

todos os artefatos
com prottipos.
constituintes, incluindo
Componentes)
Viso

Refinada, com base nas informaes novas obtidas durante a

fase, estabelecendo uma compreenso slida dos casos de uso
mais crticos que conduzem as decises de arquitetura e
planejamento.

Plano de Desenvolvimento
de Software

Atualizado e expandido para cobrir as fases de Construo e

Transio.

Guias, como Guia de Design

e Guia de Programao

Os guias usados para suportar o trabalho.

Plano de Iterao

Plano de iterao para a fase Construo concludo e analisado.

Modelo de Casos de Uso

(Atores,Casos de Uso)

Um modelo de casos de uso (aproximadamente 80% concludo)

todos os casos de uso sendo identificados na pesquisa de
modelo de casos de uso, todos os atores sendo identificados e a
maioria das descries de caso de uso (captura de requisitos)
sendo desenvolvida.

Especificaes
Suplementares

Os requisitos suplementares abrangendo os requisitos no

funcionais so documentados e analisados.

Conjunto de Testes ("teste de Testes implementados e executados para validar a estabilidade do

regresso")
build para cada release executvel criado durante a fase
Elaborao.
Arquitetura para
Automatizao de Testes

Uma composio de baseline de vrios mecanismos e elementoschave de software que compem as caractersticas fundamentais
do sistema de software de automatizao de teste.

Artefatos Opcionais

Estado no marco

Caso de Negcio

Atualizado se as investigaes sobre a arquitetura descobrirem

problemas que mudem premissas fundamentais do projeto.

Modelo de Anlise

Pode ser desenvolvido como um artefato formal; freqentemente

mantido de forma no formal, evoluindo, em vez disso, para uma
verso inicial do Modelo de Design.

Materiais de Treinamento

Manuais do Usurio e outros materiais de treinamento. Rascunho

preliminar, baseado em casos de uso. Poder ser necessrio se o
sistema tiver um forte aspecto de interface de usurio.

Templates Especficos do
Projeto

Os templates de documentos usados para desenvolver os

artefatos de documentos.

O Papel da Criao de Prottipo

O Rational Unified Process d ao arquiteto de software e ao gerente de projeto a liberdade de
construir prottipos de vrios tipos (consulte Conceitos: Prottipos) como uma estratgia de
reduo de riscos. Alguns desses prottipos podem ser puramente exploratrios e sero
posteriormente descartados. Contudo, provvel (para sistemas grandes e sem precedentes) que a
arquitetura tenha sido construda como uma srie de prottipos evolucionrios abrangendo
diferentes problemas no decorrer da elaborao e, no fim da elaborao, ter atingido o ponto
mximo em uma base de arquitetura estvel e integrada. No queremos sugerir com isso que o
esforo de criao de prottipos durante a elaborao deva resultar em um conjunto de fragmentos
de arquitetura que no precisam ser integrados.

Fase: Construo (Construction)

Objetivos
A meta da fase Construo esclarecer os requisitos restantes e concluir o desenvolvimento do
sistema com base na arquitetura definida. A fase Construo de certa forma um processo de
manufatura, em que a nfase est no gerenciamento de recursos e controle de operaes para
otimizar custos, programaes e qualidade. Nesse sentido, a mentalidade do gerenciamento passa
por uma transio de desenvolvimento da propriedade intelectual durante a Iniciao e Elaborao,
para o desenvolvimento de produtos que podem ser implantados durante a Construo e Transio.
Os objetivos principais da fase Construo incluem:

Minimizar os custos de desenvolvimento, otimizando recursos e evitando retalhamento e

retrabalho desnecessrios.
Atingir a qualidade adequada com rapidez e eficincia.
Atingir as verses teis (alfa, beta e outros releases de teste) com rapidez e eficincia.
Concluir a anlise, o design, o desenvolvimento e o teste de todas as funcionalidades
necessrias.
Desenvolver de modo iterativo e incremental um produto completo que esteja pronto para a
transio para a sua comunidade de usurios. Isso implica descrever os casos de uso restantes
e outros requisitos, incrementar o design, concluir a implementao e testar o software.
Decidir se o software, os locais e os usurios esto prontos para que o aplicativo seja
implantado.
Atingir certo paralelismo entre o trabalho das equipes de desenvolvimento. Mesmo em
projetos menores, normalmente h componentes que podem ser desenvolvidos um
independente do outro, permitindo o paralelismo natural entre as equipes (se os recursos
permitirem). O paralelismo pode acelerar bastante as atividades de desenvolvimento; mas
tambm aumenta a complexidade do gerenciamento de recursos e da sincronizao dos
fluxos de trabalho. Uma arquitetura sofisticada ser essencial para atingir um paralelismo
significativo.

Atividades Bsicas

Gerenciamento de recursos, otimizao de controle e processo

Desenvolvimento completo dos componentes e teste dos critrios de avaliao definidos
Avaliao dos releases do produto de acordo com os critrios de aceitao para a viso

Marco: Capacidade Operacional Inicial (Initial Operational Capability)

No Marco da Capacidade Operacional Inicial, o produto est pronto para ser passado para a Equipe
de Transio. Todas as funcionalidades j foram desenvolvidas e todos os alfa-testes (se houver
algum) foram concludos. Alm do software, um manual do usurio foi desenvolvido, e existe uma
descrio do release atual. O marco Capacidade Operacional Inicial determina se o produto est
pronto para ser implantado em um ambiente de teste beta.
Critrios de Avaliao
Os critrios de avaliao para a fase Construo envolvem as respostas para estas questes:

 Este release do produto estvel e desenvolvido o suficiente para ser implantado na

comunidade de usurios?
Todos os envolvidos esto prontos para a transio para a comunidade de usurios?
As despesas reais com recursos ainda so aceitveis se comparadas com as planejadas?
Talvez a transio tenha de ser adiada por um release se o projeto no atingir esse marco.
Artefatos
Artefatos Bsicos

Estado no marco

"O Sistema"

O prprio sistema executvel, pronto para comear o teste "beta".

Plano de Implantao

Verso inicial desenvolvida, analisada e com baseline. Em

projetos menores, isso pode ser embutido no Plano de
Desenvolvimento de Software.

Modelo de Implementao (e Expandido a partir daquele criado durante a fase Elaborao;

todos os artefatos
todos os componentes criados no final da fase Construo.
constituintes, incluindo
Componentes)
Conjunto de Testes ("teste de Testes implementados e executados para validar a estabilidade do
regresso")
build de cada release executvel criado durante a fase
Construo.
Materiais de Treinamento

Manuais do Usurio e outros materiais de treinamento. Rascunho

preliminar, baseado em casos de uso, poder ser necessrio se o
sistema tiver um forte aspecto de interface de usurio.

Plano de Iterao

Plano de iterao para a fase Transio concludo e analisado.

Modelo de Design (e todos

os artefatos constituintes)

Atualizado com novos elementos de design identificados durante

a concluso de todos os requisitos.

Caso de Desenvolvimento

Refinado com base na experincia inicial do projeto. O ambiente

de desenvolvimento, incluindo o processo, as ferramentas e o
suporte automatizado necessrios para dar assistncia equipe de
transio j estar posicionada.

Ferramentas

As ferramentas usadas para dar suporte ao trabalho de

Construo so instaladas.

Modelo de Dados

Atualizado com todos os elementos necessrios para suportar a

implementao persistente (por exemplo, tabelas, ndices, etc.).

Artefatos Opcionais

Estado no marco

Templates Especficos do
Projeto

Os templates de documentos usados para desenvolver os

artefatos de documentos.

Especificaes
Suplementares

Atualizadas com novos requisitos (se houver) descobertos

durante a fase Construo.

Modelo de Casos de Uso

(Atores,Casos de Uso)

Atualizado com novos casos de uso (se houver) descobertos

durante a fase Construo.

Fase: Transio (Transition)

Objetivos
O foco da Fase Transio assegurar que o software esteja disponvel para seus usurios finais. A
Fase Transio pode atravessar vrias iteraes e inclui testar o produto em preparao para
liberao e pequenos ajustes com base no feedback do usurio. Nesse momento do ciclo de vida, o
feedback do usurio deve priorizar o ajuste fino do produto, a configurao, a instalao e os
problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhados
muito antes no ciclo de vida do projeto.
No fim do ciclo de vida da fase Transio, os objetivos devem ter sido atendidos e o projeto deve
estar em uma posio para fechamento. Em alguns casos, o fim do ciclo de vida atual pode
coincidir com o incio de outro ciclo de vida no mesmo produto, conduzindo nova gerao ou
verso do produto. Para outros projetos, o fim da Transio pode coincidir com uma liberao total
dos artefatos a terceiros que podero ser responsveis pela operao, manuteno e melhorias no
sistema liberado.
A fase Transio pode ser muito fcil ou muito complexa, dependendo do tipo de produto. Um
novo release de um produto de mesa existente pode ser muito simples, ao passo que a substituio
do sistema de controle do trfego areo de um pas pode ser excessivamente complexa.
As atividades realizadas durante uma iterao na fase Transio dependem da meta. Por
exemplo, ao corrigir erros, normalmente bastam a implementao e o teste. Se, no entanto, novas
caractersticas tiverem de ser adicionadas, a iterao ser semelhante a uma fase Construo,
exigindo anlise, design, etc.
A fase Transio entra quando uma base estiver desenvolvida o suficiente para ser implantada no
domnio do usurio final. Isso normalmente requer que algum subconjunto usvel do sistema tenha
sido concludo com nvel de qualidade aceitvel e documentao do usurio, de modo que a
transio para o usurio fornea resultados positivos para todas as partes.
Os objetivos principais da fase Transio so:

Teste beta para validar o novo sistema em confronto com as expectativas do usurio
Teste beta e operao paralela relativa a um sistema legado que est sendo substitudo
Converso de bancos de dados operacionais
Treinamento de usurios e equipe de manuteno
Introduo ao marketing, distribuio e equipe de vendas
Engenharia voltada para implantao, como preparao, empacotamento e produo
comercial, introduo a vendas, treinamento de pessoal em campo
Atividades de ajuste, como correo de erros, melhoria no desempenho e na usabilidade
Avaliao das bases de implantao tendo como guia a viso completa e os critrios de
aceitao para o produto
Obteno de auto-suportabilidade do usurio
Obteno do de acordo dos envolvidos de que as bases de implantao esto completas
Obteno do de acordo dos envolvidos de que as bases de implantao so consistentes
com os critrios de avaliao da viso

Atividades bsicas

Executar planos de implantao

Finalizar o material de suporte para o usurio final
Testar o produto liberado no local do desenvolvimento
Criar um release do produto
Obter feedback do usurio
Ajustar o produto com base em feedbacks
Disponibilizar o produto para os usurios finais

Marco: Release do Produto (Product Release)

No fim na fase Transio est o quarto marco mais importante do projeto, o Marco Release do
Produto. Nesse momento, voc avalia se os objetivos foram alcanados, e se outro ciclo de
desenvolvimento deve ser iniciado. Em alguns casos, esse marco pode coincidir com o fim da fase
Iniciao do prximo ciclo. O Marco Release do Produto o resultado da concluso com xito da
Atividade: Reviso da Aceitao do Projeto.
Critrios de Avaliao
Os critrios bsicos de avaliao para a fase Transio envolvem as respostas para estas questes:
O usurio est satisfeito?
As despesas reais com recursos so aceitveis se comparadas com as planejadas?
No Marco Release do Produto, o produto est em produo e o ciclo de manuteno posterior ao
release se inicia. Isso pode envolver o incio de um novo ciclo de desenvolvimento ou de algum
release de manuteno adicional.
Artefatos
Artefatos Bsicos

Estado no marco

O Build do Produto

Concludo de acordo com os requisitos do produto. O produto

final deve ser utilizvel pelo consumidor.

Notas de Release

Concludas.

Artefatos de Instalao

Concludos.

Material de Treinamento

Concludo para assegurar que o cliente possa ser auto-suficiente

na utilizao e manuteno do produto.

Material de Suporte para o

Usurio Final

Concludo para assegurar que o cliente possa ser auto-suficiente

na utilizao e manuteno do produto.

Artefatos Opcionais

Estado no marco

Conjunto de Testes ("teste de O conjunto de testes desenvolvidos para validar a estabilidade de

regresso")
cada build pode ser fornecido na situao em que o cliente deseja
executar um nvel bsico de teste no local.

Empacotamento Compacto
do Produto

No caso de criar um produto compacto, o contratante precisar

dos artefatos de empacotamento necessrios para ajudar a colocar
o produto no varejo.