https://www.ibm.

com/developerworks/rational/library/content/03July/1000/1251/1
251_bestpractices_TP026B.pdf

What is the Rational Unified Process?

The Rational Unified Process® is a Software Engineering Process. It provides a

disciplined approach to assigning tasks and responsibilities within a development
organization. Its goal is to ensure the production of high-quality software that
meets the needs of its end-users, within a predictable schedule and budget. [11,
13]

O Rational Unified Process é um processo de engenharia de software. Ele fornece

uma abordagem disciplinada para atribuir tarefas e responsabilidades dentro de uma
organização de desenvolvimento. Sua meta é garantir a produção de software de alta
qualidade que atenda às necessidades de seus usuários finais, dentro de um
cronograma e um orçamento previsíveis.
[11, 13]

The Rational Unified Process is a process product, developed and maintained by

Rational® Software. The development team for the Rational Unified Process are
working closely with customers, partners, Rational's product groups as well as
Rational's consultant organization, to ensure that the process is continuously
updated and improved upon to reflect recent experiences and evolving and proven
best practices.

O Rational Unified Process é um processo produto, desenvolvido e mantido pela

Rational Software. A equipe de desenvolvimento para o Rational Unified Process está
trabalhando em estreita colaboração com clientes, parceiros, grupos de produtos da
Rational, bem como a organização do consultor da Rational, para garantir que o
processo é continuamente atualizado e melhorado para refletir as experiências
recentes e em evolução e as melhores práticas comprovadas.

The Rational Unified Process enhances team productivity, by providing every team
member with easy access to a knowledge base with guidelines, templates and tool
mentors for all critical development activities. By having all team members
accessing the same knowledge base, no matter if you work with requirements,
design, test, project management, or configuration management, we ensure that all
team members share a common language, process and view of how to develop
software.

O Rational Unified Process aumenta a produtividade da equipe, fornecendo cada

membro da equipe, com fácil acesso a uma base de conhecimento com as diretrizes,
modelos e mentores de ferramentas para todas as atividades de desenvolvimento de
críticas. Por ter todos os membros da equipe que acessam a mesma base de
conhecimento, não importa se você trabalha com os requisitos, design, teste,
gerenciamento de projetos, ou gerenciamento de configuração, podemos garantir que
todos os membros da equipa partilham uma língua comum, o processo e visão de
como desenvolver software.

The Rational Unified Process activities create and maintain models. Rather than
focusing on the production of large amount of paper documents, the Unified Process
emphasizes the development and maintenance of models—semantically rich
representations of the software system under development. [3, 7, 8]

As atividades Rational Unified Process criar e manter modelos. Ao invés de focar na

produção de grande quantidade de documentos em papel, o Unified Process enfatiza
o desenvolvimento e manutenção de modelos-semanticamente ricas representações
do sistema de software em desenvolvimento. [3, 7, 8]

The Rational Unified Process is a guide for how to effectively use the Unified
Modeling Language (UML). The UML is an industry-standard language that allows us
to clearly communicate requirements, architectures and designs. The UML was
originally created by Rational Software, and is now maintained by the standards
organization Object Management Group (OMG). [4]

O Rational Unified Process é um guia de como utilizar eficazmente a Unified Modeling

Language (UML). A UML é uma linguagem padrão da indústria que nos permite
comunicar claramente os requisitos, arquiteturas e designs. A UML foi originalmente
criado por Rational Software, e agora é mantido pelo Grupo de Gestão de organização
de padrões de Objetos (OMG). [4]

The Rational Unified Process is supported by tools, which automate large parts of
the process. They are used to create and maintain the various artifacts—models in
particular—of the software engineering process: visual modeling, programming,
testing, etc. They are invaluable in supporting all the bookkeeping associated with
the change management as well as the configuration management that
accompanies each iteration.

O Rational Unified Process é suportado por ferramentas que automatizam grande

parte do processo. Eles são usados para criar e manter os diversos artefatos-modelos
em particular, do processo de engenharia de software: modelagem visual,
programação, testes, etc Eles são de valor inestimável para apoiar toda a escrituração
associada à gestão da mudança, bem como o gerenciamento de configuração que
acompanha cada iteração.

The Rational Unified Process is a configurable process. No single process is suitable

for all software development. The Unified Process fits small development teams as
well as large development organizations. The Unified Process is founded on a simple
and clear process architecture that provides commonality across a family of
processes. Yet, it can be varied to accommodate different situations. It contains a
Development Kit, providing support for configuring the process to suit the needs of
a given organization.

O Rational Unified Process é um processo configurável. No processo único é

adequado para todo o desenvolvimento de software. O Unified Process encaixa
equipes de desenvolvimento pequenas, bem como as organizações de
desenvolvimento de grande porte. O Unified Process é fundada sobre uma arquitetura
de processos simples e claro que fornece a freqüência em uma família de processos.
No entanto, ela pode ser variada para acomodar diferentes situações. Ele contém um
kit de desenvolvimento, fornecendo suporte para a configuração do processo para
atender às necessidades de uma determinada organização.

The Rational Unified Process captures many of the best practices in modern
software development in a form that is suitable for a wide range of projects and
organizations. Deploying these best practices using the Rational Unified Process as
your guide offers development teams a number of key advantages. In next section,
we describe the six fundamental best practices of the Rational Unified Process.

O Rational Unified Process captura muitas das melhores práticas em desenvolvimento

de software moderno, de forma que é adequado para uma ampla gama de projetos e
organizações. A implantação dessas melhores práticas usando o Rational Unified
Process como seu guia oferece equipes de desenvolvimento de uma série de
vantagens importantes. Na próxima seção, descrevemos os seis melhores práticas
fundamentais do Rational Unified Process.

Two Dimensions

The process can be described in two dimensions, or along two axis:

• the horizontal axis represents time and shows the dynamic aspect of the process
as it is enacted, and it is expressed in terms of cycles, phases, iterations, and
milestones.

• the vertical axis represents the static aspect of the process: how it is described in
terms of activities, artifacts, workers and workflows.

O processo pode ser descrito em duas dimensões, ou ao longo de dois eixos:

• o eixo horizontal representa o tempo e mostra o aspecto dinâmico do processo, uma

vez que é decretada, e é expressa em termos de ciclos, fases, iterações e marcos.

• o eixo vertical representa o aspecto estático do processo: como ele é descrito em

termos de atividades, artefatos, os trabalhadores e os fluxos de trabalho.

Phases and Iterations - The Time Dimension

This is the dynamic organization of the process along time.

The software lifecycle is broken into cycles, each cycle working on a new generation
of the product. The Rational Unified Process divides one development cycle in four
consecutive phases [10]
• Inception phase
• Elaboration phase
• Construction phase
• Transition phase

Each phase is concluded with a well-defined milestone—a point in time at which

certain critical decisions must be made, and therefore key goals must have been
achieved [2].

Esta é a organização dinâmica do processo ao longo do tempo.

O ciclo de vida do software é dividido em ciclos, cada ciclo de trabalho em uma nova
geração do produto. O Rational Unified Process divide um ciclo de desenvolvimento
em quatro fases consecutivas [10]

• Fase de Iniciação
• Fase de Elaboração
• Fase de construção
• fase de Transição

Cada fase é concluída com um-um marco ponto bem definido no tempo em que
devem ser feitas certas decisões críticas e, portanto, objetivos principais devem ter
sido alcançado [2].

Inception Phase

During the inception phase, you establish the business case for the system and
delimit the project scope. To accomplish this you must identify all external entities
with which the system will interact (actors) and define the nature of this interaction
at a high-level. This involves identifying all use cases and describing a few
significant ones. The business case includes success criteria, risk assessment, and
estimate of the resources needed, and a phase plan showing dates of major
milestones. [10, 14]

Durante a fase inicial, você estabelece o caso de negócio para o sistema e delimitar o
escopo do projeto. Para conseguir isso, você deve identificar todas as entidades
externas com as quais o sistema irá interagir (atores) e definem a natureza dessa
interação em um alto nível. Isto envolve a identificação de todos os casos de uso e
descrever alguns dos mais significativos. O caso de negócios inclui critérios de
sucesso, avaliação de riscos e estimativa dos recursos necessários, e um plano de
fase mostrando datas dos principais marcos. [10, 14]

The outcome of the inception phase is:

• A vision document: a general vision of the core project's requirements, key
features, and main constraints.
• A initial use-case model (10% -20%) complete).
• An initial project glossary (may optionally be partially expressed as a domain
model).
• An initial business case, which includes business context, success criteria
(revenue projection, market
recognition, and so on), and financial forecast.
• An initial risk assessment.
• A project plan, showing phases and iterations.
• A business model, if necessary.
• One or several prototypes.
O resultado da fase de iniciação é:
• Um documento de visão: uma visão geral dos requisitos do projeto do núcleo,
principais características e limitações principais.
• Um modelo inicial de casos de uso (10% -20%) completa).
• Um glossário projecto inicial (pode ser opcionalmente parcialmente expresso como
um modelo de domínio).
• Um caso de negócio inicial, que inclui o contexto do negócio, critérios de sucesso
(projeção da receita, mercado reconhecimento, e assim por diante), e previsão
financeira.
• Uma avaliação inicial de riscos.
• Um plano de projeto, mostrando as fases e iterações.
• Um modelo de negócio, se necessário.
• Um ou vários protótipos.

Elaboration Phase

The purpose of the elaboration phase is to analyze the problem domain, establish a
sound architectural foundation, develop the project plan, and eliminate the highest
risk elements of the project. To accomplish these objectives, you must have the
“mile wide and inch deep” view of the system. Architectural decisions have to be
made with an understanding of the whole system: its scope, major functionality
and nonfunctional requirements such as performance requirements.

O objetivo da fase de elaboração é analisar o domínio do problema, estabelecer uma

base sólida de arquitetura, desenvolver o plano do projeto e eliminar os elementos de
maior risco do projeto. Para atingir esses objetivos, é necessário ter o "milha de
largura e polegada de profundidade" visão do sistema. Decisões de arquitetura tem
que ser feito com uma compreensão de todo o sistema: o seu âmbito de aplicação,
maior funcionalidade e requisitos não-funcionais, tais como requisitos de desempenho.

It is easy to argue that the elaboration phase is the most critical of the four phases.
At the end of this phase, the hard “engineering” is considered complete and the
project undergoes its most important day of reckoning: the decision on whether or
not to commit to the construction and transition phases. For most projects, this
also corresponds to the transition from a mobile, light and nimble, low-risk
operation to a high-cost, high-risk operation with substantial inertia. While the
process must always accommodate changes, the elaboration phase activities ensure
that the architecture, requirements and plans are stable enough, and the risks are
sufficiently mitigated, so you can predictably determine the cost and schedule for
the completion of the development. Conceptually, this level of fidelity would
correspond to the level necessary for an organization to commit to a fixed-price
construction phase.

É fácil argumentar que a fase de elaboração é o mais crítico dos quatro fases. No final
desta fase, a "engenharia" hard é considerado concluído eo projeto passa por seu dia
mais importante da prestação de contas: a decisão sobre se deve ou não se
comprometer com as fases de construção e transição. Para a maioria dos projetos, o
que também corresponde à transição de um móvel, leve e ágil, uma operação de baixo
risco de um alto-custo, operação de alto risco com a inércia substancial. Enquanto o
processo deve sempre acomodar as mudanças, as atividades da fase de elaboração
garantir que a arquitetura, os requisitos e os planos sejam estáveis o suficiente e os
riscos estão suficientemente mitigados, para que você possa previsivelmente
determinar o custo e cronograma para a conclusão do desenvolvimento.
Conceitualmente, este nível de fidelidade corresponderia ao nível necessário para uma
organização se comprometer com uma fase de construção a preço fixo.
In the elaboration phase, an executable architecture prototype is built in one or
more iterations, depending on the scope, size, risk, and novelty of the project. This
effort should at least address the critical use cases identified in the inception phase,
which typically expose the major technical risks of the project. While an
evolutionary prototype of a production-quality component is always the goal, this
does not exclude the development of one or more exploratory, throwaway
prototypes to mitigate specific risks such as design/requirements trade-offs,
component feasibility study, or demonstrations to investors, customers, and end-
users.

Na fase de elaboração, um protótipo de arquitetura executável é construído em uma

ou mais iterações, dependendo do escopo, tamanho, risco e inovação do projeto. Este
esforço deve, pelo menos, tratar os casos de uso críticos identificados na fase de
iniciação, que normalmente expõem os maiores riscos técnicos do projeto. Enquanto
um protótipo evolutivo de um componente de qualidade de produção é sempre o
objetivo, isso não exclui o desenvolvimento de um ou mais exploratórias, protótipos
descartáveis para mitigar os riscos específicos, tais como design / requisitos trade-offs,
estudo de viabilidade de componentes, ou demonstrações para investidores , clientes
e usuários finais.

The outcome of the elaboration phase is:

• A use-case model (at least 80% complete) — all use cases and actors have been
identified, and most use case descriptions have been developed.
• Supplementary requirements capturing the non functional requirements and any
requirements that are not associated with a specific use case.
• A Software Architecture Description.
• An executable architectural prototype.
• A revised risk list and a revised business case.
• A development plan for the overall project, including the coarse-grained project
plan, showing iterations” and evaluation criteria for each iteration.
• An updated development case specifying the process to be used.
• A preliminary user manual (optional).

O resultado da fase de elaboração é:

• Um modelo de caso de uso (pelo menos 80% concluído) - todos os casos de uso e
atores foram identificados ea maioria das descrições de casos de uso têm sido
desenvolvidos.
• Requisitos suplementares abrangendo os requisitos não funcionais e todos os
requisitos que não estão associados a um caso de uso específico.
• A Arquitetura de Software Descrição.
• Um protótipo arquitetural executável.
• Uma lista de risco revisto e um caso de exploração revisto.
• Um plano de desenvolvimento para o projecto global, incluindo o plano de projeto de
granulação grossa, mostrando iterações "e critérios de avaliação para cada iteração.
• Um caso de desenvolvimento actualização especificando o processo a ser usado.
• Um manual do usuário preliminar (opcional).

Construction Phase

During the construction phase, all remaining components and application features
are developed and integrated into the product, and all features are thoroughly
tested. The construction phase is, in one sense, a manufacturing process where
emphasis is placed on managing resources and controlling operations to optimize
costs, schedules, and quality. In this sense, the management mindset undergoes a
transition from the development of intellectual property during inception and
elaboration, to the development of deployable products during construction and
transition.

Durante a fase de construção, todos os demais componentes e recursos do aplicativo

são desenvolvidas e integradas no produto, e todos os recursos são exaustivamente
testados. A fase de construção é, em certo sentido, um processo de fabricação em
que a ênfase é colocada sobre a gestão de recursos e controle de operações para
otimizar custos, programações e qualidade. Neste sentido, a mentalidade do
gerenciamento passa por uma transição do desenvolvimento da propriedade
intelectual durante a iniciação e elaboração, para o desenvolvimento de produtos
implantáveis durante a construção e transição.

Many projects are large enough that parallel construction increments can be
spawned. These parallel activities can significantly accelerate the availability of
deployable releases; they can also increase the complexity of resource
management and workflow synchronization. A robust architecture and an
understandable plan are highly correlated.
In other words, one of the critical qualities of the architecture is its ease of
construction. This is one reason why the balanced development of the architecture
and the plan is stressed during the elaboration phase. The outcome of the
construction phase is a product ready to put in hands of its end-users. At minimum,
it consists of:

• The software product integrated on the adequate platforms.

• The user manuals.
• A description of the current release.

Muitos projetos são grandes o suficiente para que incrementos de construção

paralelas podem ser gerados. Essas atividades paralelas pode acelerar
significativamente a disponibilidade de versões implementáveis; eles também podem
aumentar a complexidade da gestão de recursos e de sincronização de fluxo de
trabalho. A arquitetura robusta e um plano compreensível estão altamente
correlacionados.
Em outras palavras, uma das qualidades fundamentais da arquitectura é a sua
facilidade de construção. Esta é uma razão pela qual o desenvolvimento equilibrado
da arquitetura e do plano está estressado durante a fase de elaboração. O resultado
da fase de construção é um produto pronto para colocar nas mãos de seus usuários
finais. No mínimo, ele consiste em:

• O produto de software integrado em plataformas adequadas.

• Os manuais do usuário.
• A descrição da versão atual.

Transition Phase

The purpose of the transition phase is to transition the software product to the user
community. Once the product has been given to the end user, issues usually arise
that require you to develop new releases, correct some problems, or finish the
features that were postponed.

O objetivo da fase de transição é fazer a transição do produto de software para a

comunidade de usuários. Uma vez que o produto tem sido dada para o usuário final,
as questões geralmente exigem a você para desenvolver novos lançamentos, corrigir
alguns problemas, ou terminar os recursos que foram adiadas.
The transition phase is entered when a baseline is mature enough to be deployed in
the end-user domain. This typically requires that some usable subset of the system
has been completed to an acceptable level of quality and that user documentation
is available so that the transition to the user will provide positive results for all
parties.

A fase de transição é inserido quando uma linha de base é maduro o suficiente para
ser implantado no domínio do usuário final.
Isso normalmente requer que algum subconjunto usável do sistema foi concluída com
um nível aceitável de qualidade e que a documentação do usuário está disponível para
que a transição para o usuário fornecerá resultados positivos para todas as partes.

This includes:

• “beta testing” to validate the new system against user expectations

• parallel operation with a legacy system that it is replacing
• conversion of operational databases
• training of users and maintainers
• roll-out the product to the marketing, distribution, and sales teams

Isto inclui:

• "teste beta" para validar o novo sistema contra as expectativas do usuário

• operação em paralelo com um sistema legado que ele está substituindo
• conversão de bases de dados operacionais
• treinamento de usuários e mantenedores
• roll-out do produto à comercialização, distribuição e equipes de vendas

The transition phase focuses on the activities required to place the software into the
hands of the users. Typically, this phase includes several iterations, including beta
releases, general availability releases, as well as bug-fix and enhancement
releases. Considerable effort is expended in developing user-oriented
documentation, training users, supporting users in their initial product use, and
reacting to user feedback. At this point in the lifecycle, however, user feedback
should be confined primarily to product tuning, configuring, installation, and
usability issues.

A fase de transição concentra-se nas actividades necessárias para colocar o software

para as mãos dos usuários. Normalmente, esta fase inclui várias iterações, incluindo
versões beta, disponibilidade geral lançamentos, bem como de correção de bugs e
as versões otimizadas. Um esforço considerável é gasto no desenvolvimento de
documentação orientada para o utilizador, treinamento de usuários, suporte a usuários
em seu uso inicial do produto, e reagindo aos comentários dos usuários. Neste ponto
do ciclo de vida, no entanto, o feedback do usuário deve limitar-se principalmente a
sintonia produto, a configuração, instalação e problemas de usabilidade.

The primary objectives of the transition phase include:

• Achieving user self-supportability

• Achieving stakeholder concurrence that deployment baselines are complete and
consistent with the evaluation criteria of the vision
• Achieving final product baseline as rapidly and cost effectively as practical

Os objetivos principais da fase de transição incluem:

• Atingir usuário auto-suportabilidade
• Atingir consentimento dos envolvidos de que as baselines de implantação são
completos e coerentes com os critérios de avaliação da visão
• Atingir baseline produto final tão rapidamente e com baixo custo, como prática

This phase can range from being very simple to extremely complex, depending on
the type of product. For example, a new release of an existing desktop product may
be very simple, whereas replacing a nation's air-traffic control system would be
very complex.

Esta fase pode variar de ser muito simples, extremamente complexa, dependendo do
tipo de produto. Por exemplo, uma nova versão de um produto de desktop existente
pode ser muito simples, ao passo que a substituição do sistema de uma nação
controle de tráfego aéreo seria muito complexo.

Iterations

Each phase in the Rational Unified Process can be further broken down into
iterations. An iteration is a complete development loop resulting in a release
(internal or external) of an executable product, a subset of the final product
under development, which grows incrementally from iteration to iteration to
become the final system [10].

Cada fase no Rational Unified Process podem ser subdivididas em iterações. Uma
iteração é um ciclo completo de desenvolvimento, resultando em um release (interno
ou externo) de um produto executável, um subconjunto do produto final em
desenvolvimento, que cresce gradativamente a cada iteração, para se tornar o sistema
final [10].

Benefits of an iterative approach

Compared to the traditional waterfall process, the iterative process has the
following advantages:

• Risks are mitigated earlier

• Change is more manageable
• Higher level of reuse
• The project team can learn along the way
• Better overall quality

Benefícios de uma abordagem iterativa

Em comparação com o processo tradicional de cascata, o processo iterativo tem as

seguintes vantagens:

• Os riscos são mitigados mais cedo

• A mudança é mais manejável
• Maior nível de reutilização
• A equipe do projeto pode aprender ao longo do caminho
• Melhor qualidade geral

Static Structure of the Process

A process describes who is doing what, how, and when. The Rational Unified
Process is represented using four primary modeling elements:
• Workers, the ‘who’
• Activities, the ‘how’
• Artifacts, the ‘what’
• Workflows, the ‘when’

Um processo descreve quem faz o quê, como e quando. O Rational Unified Process é
representado com quatro elementos de modelagem principais:

• Trabalhadores, o "quem"
• Atividades, o 'como'
• Artefatos, o 'o que'
• Fluxos de trabalho, o "quando"

Worker

A worker defines the behavior and responsibilities of an individual, or a group of

individuals working together as a team. You could regard a worker as a "hat" an
individual can wear in the project. One individual may wear many different hats.
This is an important distinction because it is natural to think of a worker as the
individual or team itself, but in the Unified Process the worker is more the role
defining how the individuals should carry out the work. The responsibilities we
assign to a worker includes both to perform a certain set of activities as well as
being owner of a set of artifacts.

Trabalhador

Um trabalhador define o comportamento e as responsabilidades de um indivíduo, ou

um grupo de indivíduos que trabalham juntos como uma equipe. Você poderia
considerar um trabalhador como um "chapéu" que um indivíduo pode usar no projeto.
Um indivíduo pode usar muitos chapéus diferentes. Esta é uma distinção importante
porque é natural pensar em um trabalhador como o indivíduo ou a própria equipe, mas
no Unified Process o trabalhador é mais o papel que define a forma como os
indivíduos devem realizar o trabalho. As responsabilidades que atribuir a um
trabalhador inclui tanto para executar um determinado conjunto de atividades, além de
ser proprietário de um conjunto de artefatos.

Activity

An activity of a specific worker is a unit of work that an individual in that role may
be asked to perform. The activity has a clear purpose, usually expressed in terms of
creating or updating some artifacts, such as a model, a class, a plan. Every activity
is assigned to a specific worker. The granularity of an activity is generally a few
hours to a few days, it usually involves one worker, and affects one or only a small
number of artifacts. An activity should be usable as an element of planning and
progress; if it is too small, it will be neglected, and if it is too large, progress would
have to be expressed in terms of an activity’s parts.

Example of activities:

• Plan an iteration, for the Worker: Project Manager

• Find use cases and actors, for the Worker: System Analyst
• Review the design, for the Worker: Design Reviewer
• Execute performance test, for the Worker: Performance Tester

Atividade
Uma atividade de um trabalhador específico é uma unidade de trabalho que um
indivíduo em que o papel pode ser solicitado a executar. A atividade tem uma
finalidade clara, normalmente expressa em termos de criação ou atualização de
alguns artefatos, como um modelo, uma classe, um plano. Cada atividade é atribuída
a um trabalhador específico. A granularidade de uma atividade é geralmente de
algumas horas a alguns dias, ele geralmente envolve um trabalhador, e afeta um ou
apenas um pequeno número de artefatos. Uma actividade deve ser usado como um
elemento de planejamento e de progresso; se for demasiado pequeno, ele vai ser
negligenciada, e se for demasiado grande, o progresso teria de ser expresso em
termos de partes de uma actividade.

Exemplo de actividades de:

• Planejar uma iteração, para o trabalhador: Project Manager

• Encontrar casos de uso e atores, para o trabalhador: Analista de Sistemas
• Rever o design, para o trabalhador: Revisor de Design
• Executar testes de desempenho, para o trabalhador: Performance Tester

Artifact

An artifact is a piece of information that is produced, modified, or used by a

process. Artifacts are the tangible products of the project, the things the project
produces or uses while working towards the final product. Artifacts are used as
input by workers to perform an activity, and are the result or output of such
activities. In object-oriented design terms, as activities are operations on an active
object (the worker), artifacts are the parameters of these activities.

• Artifacts may take various shapes or forms:

• A model, such as the Use-Case Model or the Design Model
• A model element, i.e. an element within a model, such as a class, a use case or a
subsystem
• A document, such as Business Case or Software Architecture Document
• Source code
• Executables

Artefato

Um artefato é um pedaço de informação que é produzida, modificada ou usada por um

processo. Os artefatos são os produtos tangíveis do projeto, as coisas que o projeto
produz ou usa, enquanto trabalhava para o produto final. Artefatos são utilizados como
entrada de trabalhadores para realizar uma atividade, e são o resultado ou saída de
tais atividades. Em termos de design orientado a objetos, como as atividades são
operações em um objeto ativo (o trabalhador), os artefatos são os parâmetros dessas
atividades.

• Artefatos pode assumir diversas formas ou formas:

• Um modelo, como o Modelo de Casos de Uso ou o Modelo de Design
• Um elemento do modelo, ou seja, um elemento dentro de um modelo, tal como uma
classe, um caso de utilização ou a um subsistema
• Um documento, como Business Case ou Software Architecture Document
• O código-fonte
• executáveis

Workflows
A mere enumeration of all workers, activities and artifacts does not quite constitute
a process. We need a way to describe meaningful sequences of activities that
produce some valuable result, and to show interactions between workers.
A workflow is a sequence of activities that produces a result of observable value.
In UML terms, a workflow can be expressed as a sequence diagram, a collaboration
diagram, or an activity diagram.
We use a form of activity diagrams in this white paper.

Note that it is not always possible or practical to represent all of the dependencies
between activities. Often two activities are more tightly interwoven than shown,
especially when they involve the same worker or the same individual. People are
not machines, and the workflow cannot be interpreted literally as a program for
people, to be followed exactly and mechanically.

In the next section we will discuss the most essential type of workflows in the
process, called Core Workflows.

Workflows

A mera enumeração de todos os trabalhadores, atividades e artefatos não constitui um

processo bastante. Precisamos de uma maneira de descrever seqüências
significativas de atividades que produzem algum resultado valioso, e para mostrar as
interações entre trabalhadores.
Um fluxo de trabalho é uma seqüência de atividades que produz um resultado de valor
observável.

Em termos de UML, um fluxo de trabalho pode ser expresso como um diagrama de

sequência, um diagrama de colaboração, ou um diagrama de atividades.
Usamos uma forma de diagramas de atividades neste white paper.

Note-se que nem sempre é possível ou prático para representar todas as

dependências entre as atividades. Muitas vezes, duas atividades são mais fortemente
entrelaçados do que o mostrado, especialmente quando envolvem o mesmo
trabalhador ou o mesmo indivíduo. As pessoas não são máquinas, eo fluxo de trabalho
não pode ser interpretado literalmente como um programa para as pessoas, a ser
seguido exatamente como mecanicamente.

Na próxima seção, vamos discutir o tipo mais essencial de fluxos de trabalho no

processo, chamada Core Workflows.

Core workflows

There are nine core process workflows in the Rational Unified Process, which
represent a partitioning of all workers and activities into logical groupings.

The core process workflows are divided into six core “engineering” workflows:

1. Business modeling workflow

2. Requirements workflow
3. Analysis & Design workflow
4. Implementation workflow
5. Test workflow
6. Deployment workflow And three core “supporting” workflows:
1. Project Management workflow
2. Configuration and Change Management workflow
3. Environment workflow
Há nove fluxos de trabalho de processo central no Rational Unified Process, que
representam uma partição de todos os trabalhadores e atividades em grupos lógicos.

Os fluxos de trabalho de processos núcleo estão divididas em seis principais fluxos de

trabalho de "engenharia":

1. Fluxo de trabalho de modelagem de negócios

2. Requisitos de fluxo de trabalho
3. Análise e Design de fluxo de trabalho
4. Fluxo de trabalho de Implementação
5. Fluxo de trabalho Teste
6. fluxo de trabalho de implantação e três core "apoiar" os fluxos de trabalho:
1. Fluxo de trabalho de Gerenciamento de Projetos
2. Fluxo de trabalho de Configuração e Gerenciamento de Mudanças
3. Ambiente fluxo de trabalho

Although the names of the six core engineering workflows may evoke the
sequential phases in a traditional waterfall process, we should keep in mind that the
phases of an iterative process are different and that these workflows are revisited
again and again throughout the lifecycle. The actual complete workflow of a project
interleaves these nine core workflows, and repeats them with various emphasis and
intensity at each iteration.

Embora os nomes dos seis fluxos de trabalho de engenharia do núcleo pode evocar as
fases seqüenciais em um processo em cascata tradicional, devemos ter em mente que
as fases de um processo iterativo são diferentes e que estes fluxos de trabalho são
revisitados e outra vez durante todo o ciclo de vida. O fluxo de trabalho completo real
de um projeto intercala estes nove fluxos de trabalho essenciais, e repete-los com
vários ênfase e intensidade a cada iteração.

Business Modeling

One of the major problems with most business engineering efforts, is that the
software engineering and the business engineering community do not communicate
properly with each other. This leads to the output from business engineering is not
being used properly as input to the software development effort, and vice-versa.
The Rational Unified Process addresses this by providing a common language and
process for both communities, as well as showing how to create and maintain direct
traceability between business and software models.

In Business Modeling we document business processes using so called business use

cases. This assures a common understanding among all stakeholders of what
business process needs to be supported in the organization. The business use cases
are analyzed to understand how the business should support the business
processes. This is documented in a business object-model. Many projects may
choose not to do business modeling.

Modelagem de Negócios

Um dos grandes problemas com a maioria dos esforços de engenharia de negócios, é

que a engenharia de software e para a comunidade de engenharia de negócios não se
comunicam adequadamente com os outros. Isso leva à saída de engenharia de
negócios não está sendo usado corretamente como entrada para o esforço do
desenvolvimento de software, e vice-versa. O Rational Unified Process aborda isso,
fornecendo uma linguagem comum e processo para ambas as comunidades, bem
como mostrar como criar e manter a rastreabilidade direta entre os modelos de
negócios e de software.

Na Modelagem de Negócios documentamos processos de negócios utilizando os

chamados casos de uso de negócios. Isto assegura um entendimento comum entre
todos os interessados de que processos de negócios deve ser apoiada na
organização. Os casos de uso de negócios são analisados para entender como o
negócio deve apoiar os processos de negócios. Isso está documentado em um objeto-
modelo de negócio. Muitos projetos podem optar por não fazer a modelagem de
negócios.

Requirements

The goal of the Requirements workflow is to describe what the system should do
and allows the developers and the customer to agree on that description. To
achieve this, we elicit, organize, and document required functionality and
constraints; track and document tradeoffs and decisions.

requisitos

O objetivo da disciplina Requisitos é descrever o que o sistema deve fazer e permite

que os desenvolvedores e o cliente para acordar nessa descrição. Para conseguir
isso, obter, organizar e funcionalidade necessária documento e restrições;
acompanhar e compromissos e decisões de documentos.

A Vision document is created, and stakeholder needs are elicited. Actors are
identified, representing the users, and any other system that may interact with the
system being developed. Use cases are identified, representing the behavior of the
system. Because use cases are developed according to the actor's needs, the
system is more likely to be relevant to the users. The following figure shows an
example of a use-case model for a recycling-machine system.

Um documento Visão é criado, e necessidades das partes interessadas são extraídas.

Atores são identificados, representando os usuários, e qualquer outro sistema que
pode interagir com o sistema que está sendo desenvolvido. Os casos de utilização são
identificados, que representa o comportamento do sistema. Porque os casos de uso
são desenvolvidos de acordo com as necessidades do ator, o sistema é mais provável
que seja relevante para os usuários. A figura a seguir mostra um exemplo de um
modelo de caso de uso para um sistema de reciclagem da máquina.

Each use case is described in detail. The use-case description shows how the
system interacts step by step with the actors and what the system does. Non-
functional requirements are described in Supplementary Specifications.

Cada caso de uso é descrito em pormenor. A descrição de caso de uso mostra como o
sistema interage passo a passo com os atores e que o sistema faz. Requisitos não-
funcionais são descritos nas Especificações Suplementares.

The use cases function as a unifying thread throughout the system's development
cycle. The same use-case model is used during requirements capture, analysis &
design, and test.

Os casos de uso funcionam como um unificador em todo o ciclo de desenvolvimento

do sistema. O mesmo modelo de caso de uso é utilizado durante a captura de
requisitos, análise e design, e teste.
Analysis & Design

The goal of the Analysis & Design workflow is to show how the system will be
realized in the implementation phase. You want to build a system that:

• Performs—in a specific implementation environment—the tasks and functions

specified in the use-case descriptions.
• Fulfills all its requirements.
• Is structured to be robust (easy to change if and when its functional requirements
change).

Análise e Design

O objetivo da disciplina Análise e Design é mostrar como o sistema vai ser realizado
na fase de implementação. Você quer construir um sistema que:

• Execute-num ambiente de implementação específico- as tarefas e funções

especificadas nas descrições de casos de uso.
• Atenda todos os seus requisitos.
• Esteja estruturado para ser robusto (fácil de mudar se e quando seus requisitos
funcionais mudarem).

Analysis & Design results in a design model and optionally an analysis model. The
design model serves as an abstraction of the source code; that is, the design model
acts as a 'blueprint' of how the source code is structured and written.

Análise e Design resulta em um modelo de design e, opcionalmente, um modelo de

análise. O modelo de design serve como uma abstração do código fonte; ou seja, o
modelo de design atua como um "modelo" de como o código-fonte está estruturado e
escrito.

The design model consists of design classes structured into design packages and
design subsystems with welldefined interfaces, representing what will become
components in the implementation. It also contains descriptions of how objects of
these design classes collaborate to perform use cases. The next figure shows part
of a sample design model for the recycling-machine system in the use-case model
shown in the previous figure.

O modelo de design consiste em classes de design estruturado em pacotes de design

e subsistemas de design com interfaces bem definidas, o que representa o que será
componentes na implementação. Ele também contém descrições de como objetos
dessas classes de design colaboram para realizar os casos de uso. A figura a seguir
mostra parte de um modelo de projeto de amostra para o sistema de reciclagem de
máquina no modelo de casos de uso mostrado na figura anterior.

The design activities are centered around the notion of architecture. The production
and validation of this architecture is the main focus of early design iterations.
Architecture is represented by a number of architectural views [9]. These views
capture the major structural design decisions. In essence, architectural views are
abstractions or simplifications of the entire design, in which important
characteristics are made more visible by leaving details aside. The architecture is
an important vehicle not only for developing a good design model, but also for
increasing the quality of any model built during system development.

As atividades do projeto estão centradas em torno da noção de arquitetura. A

produção e validação dessa arquitetura é o principal foco de iterações iniciais do
projeto. Arquitectura é representada por um número de visões arquiteturais [9]. Essas
visões capturam as principais decisões de projeto estrutural. Em essência, visões
arquiteturaia são abstrações ou simplificações de todo o projeto, nas quais as
características importantes ganham visibilidade, deixando os detalhes de lado. A
arquitetura é um veículo importante não só para o desenvolvimento de um modelo de
design bom, mas também para aumentar a qualidade de qualquer modelo criado
durante o desenvolvimento do sistema.

Implementation

The purpose of implementation is:

• To define the organization of the code, in terms of implementation subsystems

organized in layers.
• To implement classes and objects in terms of components (source files, binaries,
executables, and others).
• To test the developed components as units.
• To integrate the results produced by individual implementers (or teams), into an
executable system.

Implementação

A finalidade da implementação é:

• Definir a organização do código em termos de subsistemas de implementação

organizados em camadas.
• Implementar classes e objetos em termos de componentes (arquivos-fonte, binários,
executáveis e outros).
• Testar os componentes desenvolvidos como unidades.
• Integrar os resultados produzidos por implementadores individuais (ou equipes), em
um sistema executável.

The system is realized through implementation of components. The Rational Unified

Process describes how you reuse existing components, or implement new
components with well defined responsibility, making the system easier to maintain,
and increasing the possibilities to reuse.

O sistema é realizado através da implementação de componentes. O Rational Unified

Process descreve como a reutilização de componentes existentes ou implementar
novos componentes com responsabilidade bem definida, tornando o sistema mais fácil
de manter e aumentar as possibilidades de reutilização.

Components are structured into Implementation Subsystems. Subsystems take the

form of directories, with additional structural or management information. For
example, a subsystem can be created as a directory or a folder in a file system, or
a subsystem in Rational/Apex for C++ or Ada, or packages using Java.™

Os componentes são estruturados em Subsistemas de Implementação. Subsistemas

tomam a forma de diretórios, com informações estruturais ou de gestão adicionais. Por
exemplo, um subsistema pode ser criado como um diretório ou uma pasta em um
sistema de arquivos, ou de um subsistema no Rational / Apex para C ++ ou Ada, ou
pacotes usando Java. ™

Test

The purposes of testing are: