Você está na página 1de 70

Study Guide

IBM Rational Unified Process and


Certification Guide
V.7

Esse documento foi criado a partir dos Livros IBM Rational


Unified Process Reference and Certification Guide e Study
Guide – IBM Rational Unified Process – RUP 2003, e não tem o
objetivo de substitui-los em parte ou em sua totalidade, sendo
portanto, apenas um guia de referência rápida.
Sumário

1 Introducing The Rational Unified Process ............................................................................................................ 4


1.1 O Que é Rup? .................................................................................................................................................. 4
1.2 Rup e o Desenvolvimento em Cascata ............................................................................................................. 4
1.3 The Rup - A Well-Defined Software Engineering Process............................................................................... 6
1.4 The RUP - A Customizable Process Product ................................................................................................... 7
1.5 Architectural Views ......................................................................................................................................... 9

2 Key Principals........................................................................................................................................................ 10
2.1 Adapt the Process .......................................................................................................................................... 10
2.2 Balance Competing Stakeholder Priorities ................................................................................................... 11
2.3 Collaborate Across Teams ............................................................................................................................. 11
2.4 Demonstrate Value Iteratively ....................................................................................................................... 12
2.5 Elevate the Level of Abstraction .................................................................................................................... 12
2.6 Focus Continuously on Quality ..................................................................................................................... 13

3 UMA ....................................................................................................................................................................... 14
3.1 Method Content ............................................................................................................................................. 15
3.2 Guidance........................................................................................................................................................ 17
3.3 Process .......................................................................................................................................................... 18
3.4 Method Package ............................................................................................................................................ 22

4 Disciplines .............................................................................................................................................................. 23
4.1 Business Modeling ......................................................................................................................................... 24
4.2 Requirements ................................................................................................................................................. 25
4.3 Analysis and Design ...................................................................................................................................... 26
4.4 Implementation .............................................................................................................................................. 27
4.5 Test ................................................................................................................................................................ 28
4.6 Deployment .................................................................................................................................................... 30
4.7 Configuration and Change Management ...................................................................................................... 31
4.8 Project Management...................................................................................................................................... 32
4.9 Environment................................................................................................................................................... 33

5 Ciclo de Vida do RUP ........................................................................................................................................... 35


5.2 Inception ........................................................................................................................................................ 38
5.3 Elaboration .................................................................................................................................................... 39
5.4 Construction .................................................................................................................................................. 41
5.5 Transition ...................................................................................................................................................... 42

6 Key Concepts ......................................................................................................................................................... 43


6.1 Coarse-Grain And Fine-Grain Plans: Project Plans And Iteration Plans .................................................... 43
6.2 Risk Management .......................................................................................................................................... 44

7 A Plataforma RMC (Rational Method Composer) ............................................................................................ 46


8 Roteiro para a prova RUP 839 ............................................................................................................................. 48

9 SIMULADOS ........................................................................................................................................................ 50
Simulado Pass4-Sure ................................................................................................................................................... 50
Simulado do Livro ........................................................................................................................................................ 57
Simulado ePlanetLabs ................................................................................................................................................. 64
Versão 2.0

1 Introducing The Rational Unified Process


1.1 O Que é Rup?

Em sua essência, o RUP é um conjunto de práticas coletadas de engenharia de software que são
continuamente aprimoradas, com regularidade, para refletirem alterações nas práticas do segmento de
mercado. Há três elementos centrais que definem o RUP:

 Key principles for business-driven development


 A framework of reusable method content and process building blocks
 The underlying method and process definition language

1.2 Rup e o Desenvolvimento em Cascata

Muitas equipes ainda utilizam o processo chamado waterfall onde cada fase (requisitos, análise & desenho,
implementação, testes) deve ser completamente concluída antes de iniciar a próxima. Esse tipo de processo
faz com que membros importantes da equipe fiquem ociosos ou fora do projeto por muito tempo e também
retém os testes para o fim do projeto quando problemas tendem a ser difíceis e caros de se resolver. RUP
utiliza um processo Iterativo(repetitivo) que é uma seqüência de passos incrementais.
Incremental: Qualifica uma estratégia de desenvolvimento iterativo em que o sistema é construído pela
inclusão de mais e mais funcionalidade a cada iteração.
Iterativo: Diz-se do processo que se repete diversas vezes para se chegar a um resultado e a cada vez
gera um resultado parcial que será usado na vez seguinte.
Nesse processo as seguintes características são marcantes:

Uma das principais vantagens da abordagem iterativa em relação à abordagem em cascata é que as
iterações fornecem marcos naturais para avaliar o progresso e os riscos limites. Na iteração, a avaliação do
progresso e do risco deverá continuar (se realizada informalmente) para garantir que as dificuldades não
desviem o projeto.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 4


Lucélia Viera Mota
Versão 2.0

O processo iterativo tem provado ser melhor do que o processo waterfall pelos seguintes motivos:
 Ele acomoda melhor e mais cedo as mudanças de requisitos;
 Integra melhor a equipe do projeto pois todos atuam em conjunto:
Deixar a integração para o fim do projeto resulta e retrabalho o que algumas vezes chega a consumir
40% do tempo total do projeto.
 Riscos são geralmente descobertos e resolvidos durante o início da integração:
Desde as primeiras iterações exercita-se vários aspectos do projeto como: ferramentas, circulação do
software e skill dos membros da equipe.
 Gerencialmente é possível mudar a tática ou mudar o projeto já que em pouco tempo um
release executável é liberado;
 A reutilização é facilitada quando partes inicias são desenhada e implementadas;
 Defeitos podem ser encontrados e corrigidos sob inúmeras iterações;
 Faz um melhor uso das pessoas envolvidas no projeto;
Como muitas pessoas ficam muito tempo sem por as mãos no projeto no processo waterfall elas
sentem-se menos responsáveis pelo produto final o que também causa muitos erros e mal-
entendidos;
 Os membros da equipe aprendem ao longo do caminho;
Membros da equipe têm mais oportunidades de aprender com os próprios erros realizando ajustes
entre uma iteração e outra;
 O processo de desenvolvimento é evoluído e refinado ao longo do caminho;

An iterative approach is generally superior to a linear or waterfall approach for many different reasons.
 Mitigating risks.
 Accommodating changes.
 Reaching higher quality.
 Learning and improving.
 Increasing reuse.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 5


Lucélia Viera Mota
Versão 2.0
An iterative development is guide for:
 Early baselining of architecture.
 Allow stability in planning, content and organization.
 Scope validated by stakeholders

1.3 The Rup - A Well-Defined Software Engineering Process

O próprio RUP foi desenhado com técnicas similares às utilizadas em Desenho de Softwares.
Particularmente falando, RUP foi desenhado em SPEM (Software Process Engineering Metamodel), um padrão
de modelagem de processo baseado em UML.
A arquitetura do RUP apresenta duas estrutura, ou dimensões, como também são chamadas.

Figure 1 - RUP Architecture (source: IBM Rational Unified Process v7.0)

Estrutura Dinâmica:
O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo à medida que se
desenvolve. Ela expressa o processo em termos de ciclo, fase (Inception, Elaboration, Construction, and
Transition), iteração e milestones.

Estrutura Estática:
O eixo vertical representa, por natureza, disciplinas que agrupam logicamente as atividades. Ela descreve
como elementos do processo (atividades) e os elementos de métodos são logicamente agrupados em
disciplinas através do fluxo de trabalho (workflow).
O gráfico mostra como a ênfase varia ao longo do tempo. Por exemplo, nas iterações iniciais, dedicamos
mais tempo aos requisitos; em iterações posteriores, dedicamos mais tempo à implementação.
Um processo descreve quem faz o que, como e quando conforme os elementos de modelagem abaixo:

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 6


Lucélia Viera Mota
Versão 2.0

Papéis(roles) -> Quem


Representa o chapéu que um individuo usa pondendo o mesmo ter diferentes papéis durante o projeto.
Geralmente confunde-se papéis como sendo um indivíduo ou posição fixa no projeto mas para o RUP papel
simplesmente define que individuo deve realizar o trabalho.
Tarefas -> O que
Unidade de trabalho que um indivíduo em um papel pode ser questionado a executar. Geralmente cria ou
atualiza algum artefato.
Artefatos -> Como
São elementos tangíveis de um projeto. Pode assumir várias formas como: modelo, documento, código
fonte ou executável.
Workflow -> Quando
Uma forma de descrever seqüência significantes de atividade (blocos de construção) para montar
Processos de Entrega ou Padrões de Capacidades.

1.4 The RUP - A Customizable Process Product

Project complexity

In most cases, the more complex and technical the project, the greater the formality and control required to ensure its
successful completion and timely delivery. This formality normally involves greater plan-driven development and more
discipline. The term commonly used in RUP to determine the level of formality and control that is required within the
process is ceremony. The figure below shows the relationship between complexity and ceremony. Accordingly, the level of
ceremony affects the number of artifacts and details of the workflow descriptions.

Nível de Cerimônia: refere-se a quantidade de formalismo na produção de documentos e artefatos;


Iterativo: refere-se ao fato do processo ser iterativo ou waterfall;

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 7


Lucélia Viera Mota
Versão 2.0

Figure 2 - Complexity and ceremony (source: IBM Rational Unified Process v7.0)

Organizational maturity

Less mature organizations might require more discipline than more mature ones.

Organization culture

Culture plays an important role in the successful adaptation and adoption of the process.

Regulatory compliance and policy requirements

Some industries, especially financial and healthcare, might require more controls, which in turn require a high
ceremony process and more artifacts.

Development type

The type of software development, such as green field versus COTS based, affects the process.

Organization size

The size of the organization determines how to customize the RUP to enable successful development and timely
delivery of the software solutions.

Project size

The size of the project determines how to customize the RUP to enable successful development.

QUÃO ITERATIVO VOCÊ QUER SER?


Existe um consenso na industria de software sobre os benefícios do processo iterativo, mas o que impede
uma organização de utilizar um alto nível de iteração?
Conhecimento: pode ser difícil para equipes inexperientes adotar um alto nível de iteração sem
nenhuma mentoria;
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 8
Lucélia Viera Mota
Versão 2.0
Processos: desenvolvimento iterativo introduz um grande conjunto de novos desafios, especialmente
para gerentes e arquitetos. Dessa forma, deve existir um processo que guie o desenvolvimento introduzindo
boas práticas;
Ferramentas: é extremamente difícil realizar desenvolvimento iterativo sem ferramentas para
automatizar: testes, configurações, gerência de mudanças entre outros.

QUANTA CERIMÔNIA VOCÊ QUER?


Baixa cerimônia significa produzir menos documentação como, por exemplo, não rastrear mudanças em
requisitos, design e casos de uso. Dessa forma, muito tempo seria economizado e mudanças teriam um custo
reduzido o que pode ser importante para empresas que tem um grande restrição de data ou atuam em
mercados em constante mudança. Por outro lado, alta cerimônia pode ser deseja em desenvolvimentos de
larga escala, distribuídos, tecnicamente complexos ou onde a relação com stakeholder é complexa.

1.5 Architectural Views

RUP represents the software architecture in multiple architectural views. Each architectural view addresses
concerns specific to stakeholders in the development process. These stakeholders might include users, designers,
managers, and maintainers. The architectural views capture the major design decisions by presenting the software
architecture in terms of how components connect to produce useful forms (Perry & Wolf, 1992).
The typical set of views in the RUP, called the 4+1 view model, is composed of the following.

 Use-Case view

This view provides a basis for planning the technical content of iterations. It is used in the
Requirements discipline.

 Logical view

This view provides a basis for understanding the structure and organization of the design of the
system. Logical view is used in the Analysis and Design discipline.

 Implementation view

This view captures the enumeration of all subsystems in the Implementation Model, the component
diagrams illustrating how subsystems are organized in layers, and hierarchies and illustrations
showing important dependencies between subsystems.

 Process view

This view illustrates the process decomposition of the system, including the mapping of classes and
subsystems on to processes and threads. The Process view is used in the Analysis and Design
discipline.

 Deployment view

This view illustrates the distribution of processing across a set of nodes in the system, including
physical distribution of processes and threads. This view is used in the Analysis and Design discipline.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 9


Lucélia Viera Mota
Versão 2.0

2 Key Principals
Como toda boa metodologia que se preze o RUP traz um conjunto de 6 princípios chaves que formam a
base de toda sua estrutura. Se bem compreendidos e corretamente aplicados podem apresentar um ganho
significativo de qualidade no ciclo de vida do software. Para facilitar a vida os 6 princípios começam com as
letras ABCDEF. São eles:

 Adapt the Process


 Balance Competing Stakeholder Priorities
 Collaborate Across Teams
 Demonstrate Value Iteratively
 Elevate the Level of Abstraction
 Focus Continuously on Quality

 Os benefícios derivados da aplicação do princípio,


 O padrão de comportamento que melhor inclui o princípio e
 Os "anti-padrões" ou comportamentos contrários mais reconhecidos para o princípio, que pode
prejudicar projetos de desenvolvimento de software.

2.1 Adapt the Process

Este é um princípio simples e que talvez por isso seja tão subestimado. Vejo muitas pessoas alegarem que
o RUP é “muito pesado” e possui muitos artefatos. É aí que mora o desconhecimento, pois esse princípio diz
respeito justamente a adaptar o nível de cerimônia ao seu contexto. É importante entender que o RUP é como
um banquete, ou seja, você deve escolher o que deseja ao invés de se empanturrar.
É extremamente importante para o sucesso de um projeto que o processo seja adequado e que o nível de
cerimônia seja ajustado, pois documentação em excesso não trará produtividade e documentação superficial
trará problemas de comunicação.
Outro erro comum que esse princípio trata é a criação de planos e estimativas estáticas. Todos sabem que
o nível de incerteza no início de um projeto é alto e tentar estabelecer um plano estático e absoluto na fase de
Iniciação nunca funciona, pois apenas na fase de Elaboração é que se pode ter uma visão mais estável dos
requisitos e da arquitetura.

Benefits:
 Lifecycle Efficiency
 Communication of risks
Patterns:
 Right size de process to project
 Adapt processes ceremony to Lifecycle phase
 Continuous Process Improvement
 Uncertainty-Driven Planning and Estimating
Anti-Patterns:
 Early Baselining of Estimates
 Developing Static Plans
 Using a Static Process

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 10


Lucélia Viera Mota
Versão 2.0
2.2 Balance Competing Stakeholder Priorities

Balancear prioridades sempre é uma tarefa difícil já que na visão de cada stakeholder seus requisitos são
sempre mais importantes do que os requisitos dos outros. Desenvolver um software sem estabelecer nas
fases iniciais o que realmente é prioritário significa apenas que foco desnecessário será dado em algo que não
agrega valor ao negócio e muito menos atende as expectativas dos usuários.
Outro fator importante quanto ao processo de priorização de requisitos é que ele não deve levar em conta
apenas às necessidades de alguns stakeholders. Priorizar os requisitos significa entender o negócio, as
necessidades de cada stakeholder e então balancear cada uma das necessidades.
Outro fator importante relacionado a este princípio é a redução do desenvolvimento customizado. Isso
significa avaliar os prós e contras do desenvolvimento de um software/componente customizado e a utilização
de um já pronto que atenda parcialmente os requisitos.

Benefits:
 Increased business alignment
 Reduced custom development
 Optimized business value
Patterns:
 Define, Understand, and Prioritize Business and User Needs
 Prioritize Projects and Requirements and Couple Needs with Software Capabilities
 Understand What Assets You Can Leverage
 Balance Asset Reuse with User Needs
Anti-Patterns:
 Thoroughly Document Precise Requirements and Force Stakeholder Acceptance
 Architect a System Only to Meet the Needs of the Most Vocal Stakeholders

2.3 Collaborate Across Teams

Dentro do ciclo de vida de um processo cascata o trabalho em equipe geralmente não é estimulado, pois o
que freqüentemente ocorre é que um grande volume de requisitos é “empurrado” para a equipe de analistas,
que por sua vez, “empurra” a análise & desenho para os desenvolvedores e assim por diante. Esse
comportamento faz com que cada um se sinta menos responsável pelo produto final do que o outro.
Dentro do processo iterativo toda a equipe é envolvida desde o início do projeto o que estimula a
integração e aguça o senso de responsabilidade pelo produto final, pois todos estão empenhados em gerar um
produto executável ao fim de pequenas iterações.
Estimular a colaboração funcional é outro fator importante. As barreiras que geralmente separam cada
função não devem existir, ou seja, não deve existir a “equipe” de analistas, a “equipe” de desenvolvedores, a
“equipe” de testers pois isso acaba distorcendo o foco. O importante é que exista uma única equipe cujo
objetivo é entregar um software com qualidade. Isso significa que basicamente todos são responsáveis por
compreender o que está sendo produzido e que qualidade não é uma função apenas dos Testers.
Outro ponto importante e que estimula a colaboração é a existência de um ambiente integrado onde
ferramentas podem automatizar tarefas, coletar métricas, gerar status reports, auxiliar na gerencia de
configuração e mudanças, etc. Isso libera a equipe para realizar atividades que realmente são importantes e
agregam valor ao ciclo de desenvolvimento.

Benefits:

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 11


Lucélia Viera Mota
Versão 2.0
 Team Productivity
 Better Coupling Between Business Needs, the Development, and IT Operations
Patterns:
 Motivate People to Perform at Their Best
 Create Self-Managed Teams
 Encourage Cross-Functional Collaboration
 Provide an Effective Collaborative Environment
 Manage Evolving Artifacts and Tasks
 Integrate Business, Software, and Operation Teams
Anti-Patterns:
 Nurture Heroic Developers Willing to Work Extremely Long Hours, Including Weekends
 Have Highly Specialized Well-Equipped People with Limited Collaboration
 Assume That If Just Everybody Does His Job, The Result Will Be Good

2.4 Demonstrate Value Iteratively

Demonstrar Valor Iterativamente significa beneficiar-se do processo iterativo que basicamente visa a
execução de vários ciclos onde cada um realiza todo o conjunto de disciplinas desde o requisito até a
implantação. Daí nota-se a grande diferença onde uma aplicação executável já é colocada em prova em um
curto espaço de tempo. Em contra-partida, no processo cascata, o release de um software executável é a
última prioridade onde geralmente tem-se essa saída quase que no final do projeto onde já não existe mais
tempo para resolver os problemas.

Benefits:
 Early Risk Reduction
 Higher Predictability throughout the Project
 Trust Among the Stakeholders
Patterns:
 Enabling Feedback
 Embracing Change
 Removing Risk
 Adapting Plans
Anti-Patterns:
 Plan the Entire Project in Detail
 Rely on Deliverables Other Than Test Results or Demonstrations

2.5 Elevate the Level of Abstraction

É basicamente por causa desse princípio que hoje não programamos mais em Assembly ou C++, ou seja,
quanto mais elevado o nível de abstração mais a complexidade de um projeto é reduzida. Essa abstração pode
se manifestar de várias formas como adoção de uma linguagem de alto nível como .NET ou JAVA, adoção de
um componente de mercado ou mesmo pelo uso de serviços disponibilizados através de WebServices.
Quando esse conceito não é corretamente observado o projeto é guiado pela complexidade e baixa
produtividade ficando o business em segundo plano. Outra abordagem para gerenciar a complexidade é
focalizar na arquitetura através do desenvolvimento de uma que seja estável e testada atuando como
referência para os projetos que ainda serão desenvolvidos.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 12


Lucélia Viera Mota
Versão 2.0

Benefits:
 Improved Productivity
 Reduced Complexity
Patterns:
 Re-use Existing Assets
 Patterns and Re-Use
 Services and Re-Use
 Use Higher-Level Tools and Languages
 Focus on Architecture
Anti-Patterns:
 Go Directly from Vague, High-Level Requirements to Custom-Crafted Code

2.6 Focus Continuously on Quality

Este é o último princípio do RUP e pelos motivos óbvios quase dispensa apresentações se não fosse pelo
fato de ser um dos mais mal aplicados. Foco contínuo na qualidade não significa apenas atender os requisitos
ou ter uma equipe de teste como muitos imaginam. Um conceito errôneo comum é que a qualidade pertence a
um grupo ou é responsabilidade dele. Esse mito é geralmente perpetuado pela criação de um grupo, algumas
vezes denominado Garantia de Qualidade, outros nomes incluem Teste, Controle de Qualidade e Engenharia
de Qualidade, e atribuindo a eles a missão e a responsabilidade relacionadas à qualidade.
Segundo o RUP qualidade também inclui identificar as métricas e critérios que demonstram sua existência,
assim como, a implementação de um processo para garantir que o produto atinja o grau desejado de
qualidade de forma que isso possa ser repetido e gerenciado.
O próprio RUP demonstra em Supporting Materials -> Quality Management que os problemas de software
ficam de 100 a 1.000 vezes mais caros para serem localizados e reparados após a implementação do
software.
Por fim, um dos maiores benefícios do desenvolvimento Iterativo está relacionado à abordagem de testes
que reforça os conceitos de qualidade desde o início sendo uma das vantagens desse processo em relação ao
processo cascata.

Benefits:
 Higher Quality
 Earlier Insight into Progress and Quality
Patterns:
 Ensure Team Ownership of Quality for the Product
 Test Early and Continuously in Step with Integration of the Demonstrable Capabilities
 Incrementally Build Test Automation
Anti-Patterns:
 Conduct In-Depth Peer Review
 Complete Unit Testing Before Integration Testing

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 13


Lucélia Viera Mota
Versão 2.0

3 UMA
A UMA (Unified Method Architecture) é um metamodelo de engenharia que define esquema e terminologia,
para representar métodos que consistem no conteúdo e em processos do método.
O princípio chave da UMA é a clara separação entre Elementos de Conteúdo (Method Content) e Elementos de
Processo. O primeiro refere-se a relação de elementos como Roles, Task e Work Products e existem
independentemente do processo em si. Já o segundo (Process) ajuda a organizar os Elementos de Conteúdo em
atividades gerando assim uma estrutura seqüencial que forma o processo, ou seja, o RUP é formado pela relação
entre os Elementos de Conteúdo e de Processo.

A unified method architecture (UMA) meta-model provides a language for describing method content and processes.
UMA is an architecture to conceive, specify, and store method and process metadata. UMA clearly separates Method Content
definitions from their application in delivery processes. It does this by defining the reusable core Method Content in the form of
general content descriptions and the project-specific applications in the form of process descriptions.”

A figura a seguir mostra a diferença entre o conteúdo e o processo do método, representando-os como duas
dimensões diferentes:

 O conteúdo do método que descreve como o trabalho de desenvolvimento sendo desempenhado é


categorizado pelas disciplinas. Cada disciplina é formada por tarefas (não visíveis na figura) que
fornecem descrições passo a passo de como as metas de desenvolvimento passo a passo são
atingidas.
 Para um processo, as tarefas foram mencionadas pelo processo a partir do conteúdo do método e
foram colocadas em estruturas de interrupção e fluxos de trabalho prontos para instanciação,
alocando recursos para desempenhar o trabalho e produtos de trabalhos reais como as entradas e
saídas das tarefas.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 14


Lucélia Viera Mota
Versão 2.0
Se você acha a navegação do site do RUP confusa e tem dificuldade para encontrar algo dentro dele você
provavelmente ainda não entendeu os conceitos da UMA - Unified Method Architecture. Para simplificar o
entendimento pense na UMA como uma espécie de UML sendo que a diferença é que enquanto a UML auxília a
modelar o comportamento de um sistema a UMA auxília a modelar processos como o próprio RUP.
Logo, entender os conceitos da UMA significa entender como o RUP é estruturado, de que é composto e como
seus elementos se relacionam entre si. Vale lembrar ainda que esse é um dos assuntos mais cobrados na
certificação 839 e um dos pontos onde várias mudanças foram introduzidas em relação a versão 2003 do RUP.
Em resumo o que importa entender até aqui é que todo processo (RUP) é composto de Elementos de
Conteúdo (Roles, Task, Steps, Work Products, Guidances e Categories) e Elementos de Processos (Activities,
Iterations, Phases, Capability Patterns e Delivery Process). No gráfico temos um representação em intersecção que
são os guias ou Orientação (Checklist, Concept, Example, Guideline, Practice, Report, Reusable Asset, Roadmap,
Supporting Material, Template, Term Definition, Tool Mentor, Whitepaper ) que podem ser aplicados para ambos.

Basic elements of UMA are shown in figure below.

Elemento do
Conteúdo

Elemento do
Processo
Elementos/Pacotes do
Método

3.1 Method Content

3.1.1 Method Content Elements

3.1.1.1 Work Products


There are three kinds of work products: Artifacts (tangible), Outcome (intangible), Deliverable is intended to be value
provided to stakeholders and consists of artifacts and outcomes.

Um dos principais elementos de conteúdo são os Work Products. No RUP 2003 os Work
Products eram referenciados como Artefatos e agora no RUP 7 se dividem em 03 tipos:
- Artefatos: são tangíveis e podem agrupar outros artefatos. Um exemplo de Work Product
desse tipo é o Software Development Plan que contém cinco outros artefatos. Diga-se de passagem
esse Work Product é um dos mais cobrados na prova de Certificação 839.
- Outcome: são saídas geralmente intangíveis e não reutilizáveis o que pode ser um estado ou
resultado. Exemplos de Outcome pode ser uma otimização de performance ou uma instalação de
software.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 15


Lucélia Viera Mota
Versão 2.0
- Deliverable: é um entregável que provê valor ao stakeholder seja ele interno ou externo. Um
deliverable pode ser composto de Artefatos ou Outcomes.

3.1.1.2 Role
Uma Role é definida como um conjunto de skills, competências e deveres responsável por executar
tasks e produzir Work products. Exemplos de Roles:

Roles: a set of related skills, competencies, and responsibilities that perform tasks and produce work products. Only
one designated role is responsible for each work product.”

3.1.1.3 Task/Steps
Tasks são ações executadas por Roles e são dirigidas por Work Products de entrada e saída. Tasks
são compostas de Steps que representam uma unidade de trabalho mais granular.
Task: is an action performed by roles, associated with input and output (work products), and driven by a goal. Tasks
are often repeated in iterations and are often too small for planning purposes.
Step: most granular unit of work to be performed. They are treated as optional and can be executed in any order.
O workflow abaixo, muito comum no RUP, pode ser lido da seguinte forma: a Task “Identify
Security Patterns” recebe e atualiza o Work Product “Software Architecture Document” que é de
responsabilidade da Role “Security Architect”.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 16


Lucélia Viera Mota
Versão 2.0
3.1.2 Categories

As categorias oferecem maneiras diferentes de organizar de forma lógica os elementos de Conteúdo do


Método. Existem 04 tipos de categorias: Discipline, Domain, Role Set, Tool Category.

 Discipline: a collection of Tasks that are related to a major "area of concern".


Uma Disciplina é uma categorização de Tarefas baseadas na semelhança de preocupações e cooperação
de esforço de trabalho.
 Domain: grouping of work products which have an affinity to each other based on resources, timing, or relationship.
Domínio é uma Categoria Padrão que é um agrupamento lógico de produtos de trabalho, o qual possui
uma afinidade entre si baseado em recursos, sincronização ou relacionamento.
 Role Set: grouping of Roles together that have certain commonalities. Ex.: Analysts
Esta Categoria Padrão organiza Funções em categorias.
 Tool Category: is a container for Tool Mentors.
Esta Categoria Padrão é um contêiner para Mentores de Ferramentas. Ela também fornece descrições
gerais da ferramenta e suas capacidades gerais.

3.2 Guidance

As Guidances estão na área de intersecção do gráfico da UMA portanto pode-se afirmar que elas são
generalizações que tem o objetivo de prover explicações sobre os elementos do Processo e do Conteúdo
do Método.
Resumindo: As Guidances são orientações que podem auxiliar ou detalhar a execução de elementos do
tipo: Task, Roles, Work Product ou Process Elements.

Guidance: optional elements that can be associated with tasks, work products, or process elements(Checklist, Concept,
Example, Guideline, Practice, Report, Reusable Asset, Roadmap(explica um processo), Supporting Material, Template, Term
Definition, Tool Mentor, Whitepaper(document externo)).

Existem várias tipos de Guidances como:

Checklist: Uma Lista de Verificação identifica uma série de itens que precisam ser concluídos ou
verificados. As listas de verificação são freqüentemente utilizadas em revisões, como por exemplo
tentativas ou inspeções.
Concept: Um Conceito destaca idéias principais e princípios básicos dando suporte a um tópico central
para o método. Os Conceitos normalmente endereçam tópicos mais gerais do que Orientações e se
estendem através de vários Produtos de Trabalho, Tarefas ou atividades.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 17


Lucélia Viera Mota
Versão 2.0
Examples: Este Tipo de Orientação representa uma instância de amostra normal, parcialmente concluída
de um ou mais Elementos de Conteúdo. Geralmente, os exemplos são fornecidos para Produtos de
Trabalho.
Guideline: Esse tipo de Orientação fornece detalhes adicional sobre como tratar de um Elemento de
Conteúdo específico. As Diretrizes geralmente são mais aplicadas a Tarefas e Produtos de Trabalho.
Practice: Esse Tipo de Orientação apresenta uma maneira comprovada ou estratégia de realização do
trabalho, para atingir uma meta que possui impacto positivo no Produto de Trabalho ou qualidade do
processo.
Report: Os Relatórios são gabaritos predefinidos de um resultado gerado na base de outros Produtos de
Trabalho como uma saída de algum formulário de automação de ferramentas.
Reusable Asset: Este Tipo de Orientação descreve um recurso que pode ser reutilizado em um contexto
diferente.
Roadmap(passo-a-passo): Este Guia de Orientação resume um Processo, muitàs vezes, de uma
perspectiva específica.
Supporting Material: Este Tipo de Orientação é um catchall para todos os outros tipos de Orientação,
não especificamente definidos em outro lugar.
Template: Esse Tipo de orientação especifica a estrutura de um Produto de Trabalho, fornecendo uma
tabela predefinida de conteúdos, seções, pacotes e/ou títulos, um formato padronizado, bem como
descrições como as seções e pacotes supostos a serem utilizados e concluídos.
Term Definition: Este Tipo de Orientação define conceitos que são utilizados para construir o Glossário.
Tool Mentor: Mentores de Ferramentas fornecem uma descrição completa de como executar atividades
de processos específicos ou etapas, ou produzir artefato ou relatório utilizando uma ou mais ferramentas.
Whitepaper: Este Tipo de Orientação é um documento externamente publicado incorporado como um
anexo.

3.3 Process

3.3.1 Process Elements

Vimos que para a UMA um processo é formado por Elementos de Conteúdo + Elementos de Processos. Já
vimos também que Elementos de Conteúdo são (Roles, Task, Steps, Work Products) e que estes refletem
apenas o “o que” e “como” as coisas devem ser feitas mas não refletem exatamente o “quando”. É justamente
com esse objetivo que surgem os Elementos de Processo (Activities, Iterations, Phases, Capability Patterns e
Delivery Process) cuja principal função é organizar os Elementos de Conteúdo em atividades e ciclos de vida
dando aos mesmos uma estrutura seqüencial de execução.

3.3.1.1 Activities
The fundamental concept for defining processes defining the breakdown (nested into each other) as well as flow of
work (predecessor relationships). They can contain references to Task, Roles, and Work Products called Descriptor.

Uma Atividade suporta o aninhamento e o agrupamento lógico de elementos do processo relacionados


também conhecidos como Elementos de Interrupção (por ex.,, outras Atividades ou Descritores de Tarefas).
Os conceitos Fase, Iteração, Processo de Entrega e Padrão de Capacidade são definidos como Atividades
especiais.

Special forms of activities (stereotypes):


 Iteration: group activities that are planned to be repeated more than once.
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 18
Lucélia Viera Mota
Versão 2.0
Uma iteração é um loop completo de desenvolvimento que resulta em um release (interno ou externo) de
um sistema executável, geralmente, um subconjunto do produto final em desenvolvimento, que cresce
por incrementos, a cada iteração, para se tornar o produto entregue.
Uma iteração envolve as atividades de desenvolvimento que levam ao release de um produto - uma
versão estável e executável do produto, junto com qualquer outro elemento periférico necessário para
utilizar esse release.
 Phase: groups process elements into a significant period in a project.
Do ponto de vista do gerenciamento, o ciclo de vida de software do Rational Unified Process (RUP) é
dividido em quatro fases seqüenciais, cada uma concluída por um marco principal, ou seja, cada fase é
basicamente um intervalo de tempo entre dois marcos principais.

RUP apresenta quatro fases principais que são: Iniciação, Elaboração, Construção e Transição.

3.3.1.2 Delivery Process


Is a special process describing a complete and integrated approach for performing a specific project type. RUP is
delivered with three Delivery Processes: classic, small, and medium RUP.
Um Processo de Entrega é um Processo especial que descreve uma abordagem completa e integrada, para
desempenhar um tipo específico de projeto.

3.3.1.3 Capability Pattern


Are incomplete process fragments that can contain activities and milestones enabling re-use.
Um Padrão de Capacidade é um Processo especial que descreve um cluster reutilizável de Atividades em
áreas comuns de processo, que produz um resultado de valor observável.
Os Padrões de Capacidades da UMA são blocos de construção reutilizáveis para criação de novos
Processos de desenvolvimento.
Por exemplo o Diagrama de atividades de amostra, da Disciplina de Ambiente no RUP, mostrando fluxo de
trabalho e transições.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 19


Lucélia Viera Mota
Versão 2.0

3.3.1.3.1 Process View


The structure of a Capability Pattern is the WBS, which you can use to configure and align the elements in a
hierarchy and order. By default, RUP provides three views on the breakdown structure and its activities:
 Work Breakdown Structure listing all the activities and task descriptors
 Team Allocation, which boundless work and artifacts to the responsible party or performer
 Work Product Usage, which lists all the artifacts associated with the process element

3.3.1.3.2 Process Diagrams


Process Diagrams are visual representations of process elements.
The three diagrams are the workflow diagram, Activity detail diagram, Work-product dependency diagram.

1. workflow diagram
Which is a tailored version of the UML activity diagram, can contain a start and end point, decision
nodes, links, activities, synchronization bars, task descriptors phases, and milestones.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 20


Lucélia Viera Mota
Versão 2.0

2. Activity detail diagram:


Gives a visual overview of the task descriptiors within an activity, the responsible role descriptors
associated with the task descriptors, and the input and output work product descriptor.

Descriptor
Represent an occurrence of one Content Element (like inherits in OO) in an activity providing a
proxy-like representation within breakdown structures. It allows overriding the Content Elements'
structural relationships by defining its own sets of associations.
Um Descritor é um Elemento do Processo que representa o uso ou aplicativo de um
elemento de Conteúdo do Método no Processo. O Descritor fornece a capacidade de substituir

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 21


Lucélia Viera Mota
Versão 2.0
ou incluir o que é definido no Elemento de Conteúdo do Método original. Os Descritores incluem
Role Descriptors, task Descriptors e work-product Descriptors.
Descriptors geralmente são representados em WBS permitindo ajustes necessários sem
mudar o elementos de conteúdo em si. Uma Task Descriptor, por exemplo, pode remover Steps
de uma Task flexibilizando assim os elementos de conteúdo.

3. Work-product dependency diagram


Ilustrates the relationships and dependencies among various work products.

3.4 Method Package

Esta estrutura de pacotes define como os Elementos do Método podem ser fisicamente organizados
em hierarquias de pacotes.

Há dois tipos de Pacote de Método:


 Content Package
Um Pacote de Conteúdo é um Pacote de Método especial que contém exclusivamente os
Elementos de Conteúdo. Exemplos de Elemento de Conteúdo são Artefatos, Tarefas, Funções
e assim por diante.
 Process Package: a special Method Package that contains: Capability Patterns or Delivery Processes
Um Pacote de Processo é um Pacote de Método especial que contém apenas Processos tais
como Padrões de Capacidade ou Processos de Entrega.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 22


Lucélia Viera Mota
Versão 2.0

4 Disciplines
O RUP possui 09 disciplinas sendo 06 delas diretamente relacionadas à engenharia de software também
conhecidas como “core disciplines”, são elas:
 Business Modeling
 Requirements
 Analysis and Design
 Implementation
 Test
 Deployment

As outras 03 disciplinas são chamadas de “umbrella” ou “supporting disciplines”, são elas:

 Configuration and Change Management


 Project Management
 Environment

Disciplinas são coleções de Tasks organizadas por áreas de interesse cujo principal objetivo é auxiliar no
entendimento do projeto a partir de uma perspectiva cascata tradicional. Uma disciplina o orienta como executar
as atividades do projeto de forma estruturada. O benefício de agrupar atividades em disciplinas é:
 Facilitar a compreensão das atividades;
 Facilitar a customização das atividades para o contexto de um projeto;
 Facilitar a definição de responsabilidades através das Roles;
 Permitir que gerentes de projeto monitorem e controlem mais efetivamente as atividades do projeto.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 23


Lucélia Viera Mota
Versão 2.0
Um erro comum para quem está habituado ao processo cascata é confundir Disciplina com Fase o que no
contexto do processo Iterativo não possui relação direta. Por exemplo: na fase de Iniciação você pode e deve
implementar, o que não significa que você está na fase de Construção.

4.1 Business Modeling

Como o próprio nome diz a Modelagem de Negócio tem um foco na organização e em seu
funcionamento, o que antecede a criação de qualquer sistema. Para quem conhece ou trabalha em empresas
certificadas pela ISO 9001, segue processos do ITIL ou mesmo do CMMI fica fácil entender o papel da
modelagem de negócio. Todas essas certificações exigem processos e métodos de trabalho claros,
institucionalizados e publicados, suportados ou não por sistemas de TI.
The purposes of business modeling are:
 To understand current problems in the organization and identify improvement potentials.
 To assess the impact of organizational change.
 To ensure that customers, users and developers have a common understanding of the organization.
 To derive the software system requirements needed to support the target organization.
 To understand how a to-be-deployed software system fits into the organization.

4.1.1 Activities

Assess Business Status: assessing the status of the organization and setting the business modeling objectives.
Describe Current Business: understanding the as-is business and refining the objectives of the business-modeling
effort.
Define Business: covers the work around defining the to-be business:
Identify Business Processes activity: the B.P that need detailed description are identified and prioritized
Refine Business Process Definitions: high-priority business use cases are then further detailed. Design
Business
Process Realizations: the to-be UC realizations are defined in terms of collaborations .
Define Business Operations: defining operations provided by the business.
Refine Roles and Responsibilities: the business systems, workers, entities and events are detailed.
Explore Process Automation: details how software’s that are to be acquired or developed will fit into the
organization.
Develop Domain Model: developing a subset of the Business Analysis Model - the Domain Model.

4.1.2 WorkProducts

Business Analysis Model: Its from system analyst derives Requirements. Describes realization of Business Use
Cases.
Business Architecture Document: present views that reflect what is, how it is, and where the business is
conducted.
Business Deployment Model: shows the mapping between the logical elements of the business and the physical
ones.
Business Design Model: is a realization of the Business Analysis Model.
Business Architectural Proof-of-Concept: describes a potential solution to the architecturally business
requirements.
Business Use-Case Model: contains business actors, business use cases, and business goals work products.
Business Vision: describe the objectives and goals of the business modeling effort.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 24


Lucélia Viera Mota
Versão 2.0
Target Organization Assessment: Describes the current status of the organization in which the system is to be
deployed.

4.1.3 Roles and Responsibilities

Business Process Analyst: owns the business requirements gathering process and articulates the business vision.
WorkProduct: Business Glossary , Business Goal, Business Rule, Business Use Case Model, Business Vision,
Supplementary Business Specification, Target-Organization Assessment.
Business Architect: describe the statics (structure) and the dynamics (behavior) of a business architecture.
WorkProduct: Business Analysis Model, Business Architectural Proof-of-Concept, Business Architecture
Document, Business Deployment Model, Business Design Model, Business System.
Business Designer: develops the business use cases including business worker, business entity, business event.
WorkProduct: Business Actor, Business Entity, Business Event, Business Operation, Business Operation
Realization, Business Use Case, Business Use-Case Realization, Business Worker.
Technical Reviewer: provides feedback concerning the Business Use-Case Model and the Business Analysis
Model.

4.2 Requirements

Pense na disciplina de Requisitos como a fronteira entre as necessidades dos usuários e o sistema a ser
construído. É nessa disciplina, obrigatória pelo RUP, que as necessidades dos stakeholders são mapeadas,
documentadas e gerenciadas por um Analista de Requisitos. Também é nessa disciplina que moram os dois
principais motivos causadores de falhas em projetos de software, o primeiro é justamente o levantamento
incompleto dos requisitos e o segundo refere-se ao baixo envolvimento dos usuários durante o levantamento
de requisitos.

Um requisito é algo que esperamos que o sistema faça. De acordo com o RUP ele é definido como:
“uma condição ou um recurso com o qual um sistema deve estar em conformidade”

The purpose of the Requirements discipline is:


 To establish and maintain agreement with the customers and other stakeholders on what the system should do.
 To provide system developers with a better understanding of the system requirements.
 To define the boundaries of the system.
 To provide a basis for planning the technical contents of iterations.
 To provide a basis for estimating cost and time to develop the system.
 To define a user-interface for the system, focusing on the needs and goals of the users.

4.2.1 Activities

Analyze the Problem: we need to understand who the stakeholders are, what the scope is. Understand
Stakeholder Needs: understand what the stakeholders want from the proposed solution.
Define the System: gains agreement on the scope of the system and outlines the key requirements.
Manage the Scope of the System: manages changes to requirements and assesses their overall impact.
Refine the System Definition: details the requirements to be developed in the current development cycle.
Manage Changing Requirements: manages changes to requirements and assesses their overall impact.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 25


Lucélia Viera Mota
Versão 2.0
4.2.2 WorkProducts

Vision: The stakeholders' view of the product, in terms of needs and features, is captured in the Vision artifact.
Glossary: defines important terms used by the project.
Requirements Management Plan: describes the requirements artifacts, types, and attributes.
Software Requirement: is a specification for a condition or capability to which a system must conform.
Software Requirements Specification: captures the software requirements for the complete or a portion of that
system.
Stakeholder Requests: contains any type of requests a stakeholder might have on the system to be developed.
Storyboard: is a logical and conceptual description of system functionality for a specific scenario.
Supplementary Specifications: captures requirements that are not readily captured in behavioral requirements
artifacts.
Use-Case Model: is a model of the system's functions and environment. An essential input to analysis, design, and
test.
Requirements Attributes: describes a repository of project requirements, attributes and dependencies.

4.2.3 Roles and Responsibilities

System Analyst: leads and coordinates requirements elicitation by outlining the system's functionality.
WorkProduct: Glossary, Stakeholder Requests, Storyboard, Vision, Supplementary Specifications Use-Case
Model, Requirements Attributes, Requirements Management Plan.
Requirements Specifier: specifies and maintains the detailed system requirements.
WorkProduct: Actor, Software Requirement, Software Requirements Specification, Use Case.

4.3 Analysis and Design

A Modelo de Análise permite uma melhor compreensão dos requisitos e seu domínio antes da realização
do Modelo de Design da aplicação. O processo de análise geralmente é aplicado em projetos maiores onde
uma transição direta para o modelo de Design não é viável devido a complexidade identificada nos requisitos.

Já o Modelo de Design representa a solução tecnológica para o problema exposto pelo Modelo de
Análise e se aplica mesmo em projetos pequenos. Este modelo deve ser criado antes da implementação do
software evitando retrabalhos no processo de implementação. Nesse processo também são utilizadas
ferramentas para geração de código e/ou engenharia reversa.

The purposes of Analysis & Design are:


 To transform the requirements into a design of the system-to-be.
 To evolve a robust architecture for the system.
 To adapt the design to match the implementation environment, designing it for performance

4.3.1 Activities

Perform Architectural Synthesis: constructs and assesses an architectural proof-of-concept. Define a Candidate
Architecture: creates an initial sketch of the software architecture.
Analyze Behavior: transforms the behavioral of the requirements into elements upon which the design can be
based.
Design Components: It refines the definitions of design elements, refines and updates the use-case realizations

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 26


Lucélia Viera Mota
Versão 2.0
Design the Database: identifies the design classes to be persisted in a database and designs the corresponding
database.
Design Services: provide detailed specification of service behavior and model the service portfolio. Refine the
Architecture: provides that natural transition between finishing analysis and beginning design work.

4.3.2 Work Products

Analysis Model: defines an object model describing the realization of UC. Serves as an abstraction of the Design
Model.
Design Model: is an object model describing the realization of UC. Serves as an abstraction of the
implementation.
Architectural Proof-of-Concept: is a solution(may simply be conceptual), to the architecturally-significant
requirements.
Data Model: describes the logical and physical representations of persistent data that the application uses.
Reference Architecture: is a predefined architectural pattern, or set of patterns.
Software Architecture Document: provides a comprehensive architectural overview of the system. Navigation
Map: express the principal user interface paths through the system.
Service Model: is defined as a model of the core elements of a service-oriented architecture (SOA).

4.3.3 Roles and Responsibilities

Software Architect: leads the development of the system's software architecture.


WorkProduct: Analysis Model , Architectural Proof-of-Concept, Deployment Model, Design Model,
Event, Goal-Service Model, Implementation Model, Interface, Protocol, Reference Architecture, Signal,
Software, Architecture Document.
System Analyst: leads and coordinates requirements elicitation by outlining the system's functionality.
WorkProduct: Glossary, Stakeholder Requests, Storyboard, Vision, Supplementary Specifications Use-
Case Model, Requirements Attributes, Requirements Management Plan.
Designer: leads the design of a part of the system, within the constraints of the requirements, architecture
WorkProduct: Analysis Class, Design Class, Design Package, Design Subsystem, Message, Operation,
Operation Realization, Service, Service Channel, Service Component, Service Contract, Service Gateway,
Service Specification, Testability Class, Use-Case Realization.
User Interface Designer: coordinates the design of the user interfaces
WorkProduct: Navigation Map, User-Interface Prototype.
Database Designer: leads the design of the persistent data storage structure to be used by the system
WorkProduct: Data Model, Data Migration Specification.

4.4 Implementation

Esta disciplina explica como desenvolver, organizar, testar a unidade e integrar os componentes
implementados de acordo com as especificações do design.
Para explicar o trabalho envolvido na disciplina Implementação, as atividades e os produtos de trabalho
são organizados em um padrão de capacidade para a disciplina.
Cada atividade representa uma meta de alto nível que precisa ser alcançada, para concluir
eficientemente a implementação. A Estrutura do Modelo de Implementação é realizada logo no início da fase
de Elaboração. Para cada iteração, iniciando na Elaboração, você deve Planejar a Integração, Implementar

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 27


Lucélia Viera Mota
Versão 2.0
Componentes, Integrar Cada Subsistema e, por último, Integrar o Sistema. As duas últimas atividades estão
relacionados às atividades de teste de integração.

The Implementation discipline has the following purposes:


 To define the organization of the code in terms of implementation subsystems organized in layers
 To implement the design elements in terms of implementation elements (source files, binaries, executable
programs, and others)
 To test the developed components as units
 To integrate the results produced by individual implementers (or teams) into an executable system

4.4.1 Activities

Structure the Implementation Model: structures the implementation.


Plan the Integration: plans the integration of the system for the current iteration.
Implement Components: completes a part of the implementation so that it can be delivered for integration.
Integrate Each Subsystem: integrates changes from multiple implementers to create a new consistent version.
Integrate the System: integrates implementation subsystems to create a new consistent version of the overall
system.

4.4.2 Work Products

Integration Build Plan: provides a detailed plan for integration within an iteration.
Implementation Model: represents the physical composition of the implementation.
Build: is an operational version of a system or a part of the system that demonstrates a subset of the capabilities.
Developer Test: provide the implementation of a subset of required tests in an efficient and effective manner..

4.4.3 Roles and Responsibilities

Software Architect: leads the development of the system's software architecture.


WorkProduct: Analysis Model , Architectural Proof-of-Concept, Deployment Model, Design Model,
Event, Goal-Service Model, Implementation Model, Interface, Protocol, Reference Architecture, Signal,
Software, Architecture Document.
Implementer: develops software components and performs developer testing for integration into larger
subsystems.
WorkProduct: Developer Test, Implementation Element, Implementation Element, Implementation
Subsystem, Implementation Subsystem, Testability Element, Test Stub. Integrator: This role leads the
planning and execution of implementation element integration to produce builds.

4.5 Test

Essa disciplina fornece orientação sobre como avaliar a qualidade do produto.


Para explicar o trabalho envolvido na disciplina Teste, as atividades e os produtos de trabalho são
organizados em um padrão de capacidade para a disciplina.
Cada atividade representa uma meta de alto nível que precisa ser alcançada, para desempenhar o teste
efetivo do produto.
Essa capacidade pode requerer variações com base nas necessidades específicas de cada iteração e
projeto.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 28


Lucélia Viera Mota
Versão 2.0

The purposes of the Test discipline are as follows:


 To find and document defects in software quality
 To generally advise on perceived software quality
 To prove the validity of the assumptions made in the design and requirement specification through concrete
demonstration
 To validate that software product functions as designed
 To validate that the requirements have been implemented appropriately

4.5.1 Activities

Define Evaluation Mission: identifies and agree with stakeholders the appropriate focus of the test for the
iteration.
Validate Build Stability: validates that the build is stable enough for a detailed test and evaluation effort to begin.
Test and Evaluate: achieves a breadth and depth of the test to enable a evaluation of the items tested.
Achieve Acceptable Mission: delivers a useful evaluation result to the stakeholders of the test effort.
Improve Test Assets: maintains and improves the test assets.
Verify Test Approach: demonstrates that the various techniques outlined in the Test Approach will facilitate the
planned test effort

4.5.2 Work Products

Test Strategy: defines the strategic plan for how the test effort will be conducted.
Test Plan: defines the goals and objectives of testing within the scope of the iteration.
Test-Ideas List: enumerates ideas, often partially formed, that identify potentially useful tests to conduct.
Test Environment Configuration: specifies an arrangement of hardware, software, and environment settings.
Test Cases: specifies and communicates the conditions that need to be validated to enable an assessment.
Test Data: defines a collection of test input values that are consumed during the execution of a test.
Test Script: is a set of step-by-step instructions that realize a test, enabling its execution..
Uma coleção de instruções passo a passo que efetuam um teste, permitindo sua execução.
Test Suite: defines a collection of tests and provides a means of managing the complexity of the test
implementation.
Test Log: provides a detailed, typically time-based, record that provides verification that a set of tests was
executed.
Workload Analysis Model: is a model that identifies one or more workload profiles.
Test Evaluation Summary: organizes and presents a summary analysis of the Test Results and key measures of
testing.
Test Results: summarizes the analysis of one or more Test Logs and Change Requests.
Test Automation Architecture: specifies various test automation design and implementation elements.
Test Interface Specification: specifies the provision of a set of behaviors by a classifier for the purposes of test
access.

4.5.3 Roles and Responsibilities

Test Manager: leads the overall test effort.


Test Analyst: identifies and defines the required tests, monitors detailed testing progress and results in each test
cycle.
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 29
Lucélia Viera Mota
Versão 2.0
Test Designer: leads defining the test approach and ensuring its successful implementation.
Tester: conducts tests and logs the outcomes of his testing.
Reviewer: provides timely feedback to project team members on the work products they have submitted for
review.

4.6 Deployment

A disciplina de implantação descreve as atividades associadas a garantir que o produto de software


esteja disponível a seus usuários.
A Disciplina implantação descreve três modos de implementação de produto:
 a instalação personalizada
 o produto "comprado em loja"
 acesso ao software por meio da Internet
Em cada instância, a ênfase é testar o produto no local de desenvolvimento, seguido de testes beta,
antes de ele ser finalmente oferecido ao cliente.
Embora o pico das atividades de implementação seja na Fase de Transição, algumas das atividades
ocorrem em fases anteriores para planejar e preparar a implementação.

The Deployment discipline describes three modes of product deployment:


 The custom install
 The shrink-wrapped product offering
 Access to software over the Internet

4.6.1 Activities

Plan Deployment: plans the product deployment.


Develop Support Material: covers the information that will be required to install, operate, use, maintain the
system.
Manage Acceptance Test: ensuring that the product is well tested prior to its release to the customer base.
Produce Deployment Unit: produces a deployment unit that enables the software to be effectively installed and
used.
Beta Test Product: implementing a beta program to solicit feedback on the product under development.
Manage Acceptance Test for Custom Install: handle the special case of a custom install at the customer's site.
Package Product: creates the "shrink-wrapped" product.
Provide Access to Download Site: describes the tasks to make the product available for purchase and download..

4.6.2 Work Products

Deployment Plan: describes the set of tasks necessary to install and test the developed product.
Manual Styleguide: describe the stylistic conventions to be used to develop user support materials.
Deployment Model: shows the configuration of processing nodes at run-time and the inter-communication.
Deployment Unit: consists of a build, documents and installation artifacts.
Product: product or solution to be delivered to the customer.
User Support Material: consists of materials that assist the end user in learning, using and operating the product.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 30


Lucélia Viera Mota
Versão 2.0
4.6.3 Roles and Responsibilities

Deployment Manager: leads the planning of the product's transition to the user community.
Configuration Manager: Supports the product development activity.
Course Developer: develops training materials for training users on how to use the product.
Technical Writer: is responsible for producing end user support material such as user guides, help texts and so.
Graphic Artist: This role performs the Create Product Artwork task and is responsible for the Product Artwork
artifact.

4.7 Configuration and Change Management

Esta disciplina explica como controlar e sincronizar a evolução do conjunto de Produtos de Trabalho que
compõem o sistema de software.
Um Sistema CM é essencial para controlar os vários Produtos de Trabalho produzidos por muitas
pessoas que trabalham em um projeto em comum. O controle ajuda a evitar confusões dispendiosas, e
assegura que os Produtos de Trabalho resultantes não entrem em conflito devido a alguns dos seguintes tipos
de problemas:
 Atualização simultânea
 Notificação Limitada
 Múltiplas Versões
O Sistema de CM de uma organização é utilizado durante todo o ciclo de vida do produto, desde a
iniciação até a implementação. Como o repositório de ativos de uma organização, o sistema de CM contém as
versões atuais e históricas dos arquivos de origem dos artefatos de requisitos, de design e de implementação
que definem uma determinada versão de um sistema ou de um componente do sistema

The purpose of the CCM discipline is to control changes to and maintain the integrity of a project's artifacts. In doing
so, CCM allows for an effective CM process that:
 Is built into the software development process
 Helps manage the evolution of the software development work products
 Allows developers to execute CM tasks with minimal intrusion into the development process

4.7.1 Activities

Plan Project Configuration and Change Control: establishes an plan for managing change to the artifacts.
Create Project Configuration Management (CM) Environment: environment where the product can be
developed, built.
Monitor and Report Configuration Status: provides visibility to configuration change activity.
Configuration Items: manages project artifacts and the work involved from their initial creation.
Manage Baselines and Releases: ensures that consistent sets of related artifacts can be identified as part of a
baseline.
Manage Change Requests: ensures that approved changes are made within a project in a consistent manner.

4.7.2 Work Products

Change Request: used to document and track requests for a change to the product.
CM Plan: describes all Configuration and Change Control Management activities you will perform during a
lifecycle.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 31


Lucélia Viera Mota
Versão 2.0
Configuration Audit Findings: identifies a baseline, any missing artifacts, and incompletely tested or failed
requirements.
Project Repository: stores all versions of project files and directories.
Workspace: enables controlled access to the artifacts and other resources required to develop the consumable
product.

4.7.3 Primary Roles and Responsibilities

Configuration Manager: manages the overall CM infrastructure and environment for the product development
team.
Esta função gerencia a infra-estrutura e o ambiente do Gerenciamento de Configuração (CM) geral
para a equipe de desenvolvimento de produto.
Change Control Manager: defines and oversees the change control process.
Essa função define e supervisiona o processo de controle de mudanças
Integrator: leads the planning and execution of implementation element integration to produce builds.
Essa função orienta o planejamento e a execução da integração dos elementos de implementação
para produzir builds.
Any Role: This role characterizes the tasks that any team member can perform.
Essa função caracteriza as tarefas que qualquer membro da equipe pode executar.

4.8 Project Management

Esta disciplina enfoca o planejamento do projeto, gerenciamento de riscos, monitoramento do


progresso e métricas.
Nosso objetivo com esta seção é facilitar a tarefa fornecendo algum contexto para o Gerenciamento do
Projeto. Não se trata de uma receita de sucesso, mas apresenta uma abordagem para gerenciar o projeto que
melhorará muito as vantagens de se entregar um software bem-sucedido.
Management discipline has three purposes:
-To provide a framework for managing software-intensive projects
-To provide practical guidelines for planning, staffing, executing, and monitoring projects
-To provide a framework for managing risk

4.8.1 Activities

Conceive New Project: obtain enough funding to proceed with the scoping and planning effort.
Valuate Project Scope and Risk: reappraises the project's scope and risk and updates the business case.
Plan the Project: involves developing the components and enclosures of the Software Development Plan.
Plan Remainder of Initial Iteration: is essentially the same as Plan for Next Iteration.
Manage Iteration: contains the tasks that begin, end, and review an iteration.
Reevaluate Project Scope and Risk: reappraises the project's scope and risk and updates the Business Case.
Close-Out Phase: brings the phase to closure by ensuring that the phase objectives have been achieved.
Plan for Next Iteration: creates an Iteration Plan, which is a fine-grained plan to guide the next iteration.
Refine the Development Plan: refines the Software Development Plan, as needed.
Monitor and Control Project: routine daily, weekly, and monthly tasks of the project management(Report status, etc).
Close-Out Project: prepares for project close-out after the final delivery of software in the Transition Phase.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 32


Lucélia Viera Mota
Versão 2.0
4.8.2 Work Products

Business Case: provides information from a business standpoint to determine whether this project is worth
investing in.
Software Development Plan: provides a project overview, describes the project team and a project plan (by
phases).
Iteration Plan: is a time-sequenced set of activities and tasks, with resources and task dependencies for the
iteration.
Review Record: capture the results of a review activity in which one or more project artifacts are reviewed.
Risk List: is a sorted list of known and open risks to the project, sorted in decreasing order of importance.
Issues List: is a way to record and track problems, exceptions, anomalies, or other incomplete tasks.
Status Assessment: provides a mechanism for managing everyone's expectations throughout the project lifecycle.
Work Order: is the Project Manager's means of communicating to the responsible staff what is to be done and
when.
Deployment Plan: includes a description of the set of tasks necessary to install and test the developed product.

4.8.3 Primary Roles and Responsibilities

Project Manager: plans, manages, and allocates resources; shapes priorities; coordinates customers and users.
Management Reviewer: evaluates project planning and project assessment work products.
Review Coordinator: facilitates formal reviews and inspections, ensures that they occur when required.

4.9 Environment

A categoria de conteúdo da disciplina de ambiente organiza os elementos do método que fornecem o


ambiente de desenvolvimento de software que suporte a equipe de desenvolvimento, incluindo os processos e
ferramentas.
A finalidade da disciplina de Ambiente é fornecer a organização de desenvolvimento de software com o
ambiente de desenvolvimento de software -- para processos e ferramentas -- que oferecerão suporte à equipe
de desenvolvimento.
A disciplina de ambiente fornece o ambiente de suporte para um projeto. Assim, ele suporta todas as
outras disciplinas.

The purpose of the Environment discipline is to provide the software development organization with the software
development environment—both processes and tools—that will support the development team. Regarding the tools, the
Environment discipline also aims to support tool selection, acquisition, setup, and configuration.

4.9.1 Activities

Prepare Environment for Project: It ensures that an appropriate development environment is prepared for the
project.
Prepare Environment for an Iteration: refinements are made to the Development Case.
Support Environment During an Iteration: might involve required software and hardware to develop de system.

4.9.2 Work Products

Development Process: It is a configuration of the RUP that meets the specific needs of the project. Development
Case: describes the development process that you have tailored for a specific project.
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 33
Lucélia Viera Mota
Versão 2.0
Project-Specific Guidelines: provides guidance on how to perform a certain task in the context of the project.
Project-Specific Templates: These are the templates required for artifacts used in the project. Development
Infrastructure: includes the hardware and software, such as the computers and operating systems.
Development Organization Assessment: describes the status of the organization and guide the tailoring the
process.
Manual Styleguide: helps to ensure consistency across the style and quality of user support material.

4.9.3 Primary Roles and Responsibilities

Process Engineer: equip the project team with an appropriate development process.
System Administrator: maintains the development infrastructure, both hardware and software.
Tool Specialist: supports the tools used by the project.
Technical Writer: produces end user support material such as user guides, help texts, release notes, and so on.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 34


Lucélia Viera Mota
Versão 2.0

5 Ciclo de Vida do RUP


A lifecycle is a complete (start-to-end) description of a process; in UMA terms, it is called a Delivery Process. Method
content elements are grouped resulting in Classic RUP and the Business Modeling Lifecycle. These lifecycles separate a project
into sequential phases: Inception, Elaboration, Construction, and Transition.
Do ponto de vista do gerenciamento, o ciclo de vida de software do Rational Unified Process (RUP) é dividido
em quatro fases seqüenciais, cada uma concluída por um marco principal, ou seja, cada fase é basicamente um
intervalo de tempo entre dois marcos principais. À cada final de fase, uma avaliação é executada para determinar
se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima
fase. (Marco)

Phase are UMA activities that conclude with a milestone. Each phase consists of iterations that are expressed as
Capability Patterns. The advantage of this process engineering approach is that process can be assembled faster by sharing the
same tasks across phases. Each Capability Pattern can contain activities, including phases and iterations (stereotyped activities
in RUP) Furthermore, Capability Pattern can include milestones and task descriptors.
The phases are important, not because of what is executed or because of their length, but because of what is achieved at
the major milestone that concludes them.
As fases fornecem um foco para a equipe chegar a um determinado objetivo da gerência. A cada final
de fase, uma avaliação(marco) é executada para determinar se os objetivos da fase foram alcançados.
Somente uma avaliação satisfatória permite que o projeto passe para a próxima fase.
Cada fase possui suas próprias metas, seu próprio estilo de Iteração e, geralmente, customiza suas
Tarefas e Produtos de Trabalho de forma diferente.
Cada fase pode ser ainda mais dividida em iterações. O Diagrama a seguir fornece um exemplo de
uma decomposição de projeto em fases e iterações.

Iteration Inside each phase there may be one or more iterations. Software is developed in each iteration, which is concluded by
a minor milestone, including a release (internal or external) that is a point for assessing the project progress. The software
product grows incrementally as you iterate over the activities.
Uma iteração é um período de tempo definido dentro de um projeto em que você produz uma versão estável e
executável do produto, junto com toda a documentação de apoio, scripts de instalação e similares, necessários
para usar a liberação. É também conhecida como ciclo ou tempo definido. A finalidade das iterações é produzir um

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 35


Lucélia Viera Mota
Versão 2.0
executável que possa ser avaliado de forma que você possa obter feedback e fazer correções de rumo. Este
executável lhe coloca uma etapa mais perto do produto final.
 Cada iteração inclui algumas ou todas as disciplinas;
 Cada iteração deve ter um conjunto bem definido de objetivos e produz uma parte funcional do
sistema;
 Cada iteração sucessiva é construída sob o trabalho da iteração anterior;
 As primeiras iterações têm uma grande ênfase em requisitos e análise & desenho;
 Iterações posteriores têm uma grande ênfase em implementação e testes;

Determining the Length of each Iteration


 size of the development organization;
 degree of familiarity of the organization with the iterative approach
 the level of automation the team is using to manage code

Time-Boxing is a top-down technique that tries to confine the achievement of a specific goal within a small time interval. It is
not about setting impossible or irrational goals and delivering anything of poor quality within the time-box. It is a tool used to
balance scope and schedule but also to force convergence and to limit analysis-paralysis or gold plating.
No RUP, é preferível reduzir o escopo do que adicionar recursos para gerenciar uma programação adiada. As
motivações para essa abordagem são tornar os resultados de uma iteração visíveis para os envolvidos e avaliar a
iteração, para que as lições aprendidas possam ser aplicadas a iterações posteriores.

Build Inside each iteration, the various developers or teams may produce software builds. Often the last build of the iteration is
part of the iteration's release.
Build é uma versão operacional de um sistema ou de parte de um sistema que demonstra um subconjunto dos
recursos a serem fornecidos no produto final. A build final da iteração é a realease da iteração e compõe a release
final da fase.
Release (Liberação): Um release é uma versão estável e executável do produto, que vem acompanhada dos
artefatos necessários para sua utilização (como notas de release ou instruções de instalação, por exemplo).
Releases que coincidem com o final de uma fase são de maior significado (releases maiores) que aqueles
produzidos para uma simples Iteração ( releases menores).

Milestone (Marco): São pontos de controle que podem ser realizados em atividades, padrões de recurso, fase ou
iterações.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 36


Lucélia Viera Mota
Versão 2.0
Milestone: decision points that might follow an activity, capability pattern, phase, or iteration. Milestones monitor the
completion of work and the achievement of set goals.

Analisando sob a ótica das fase, marcos são pontos de verificação atrelados a cada fase do projeto. São
utilizados para assegurar certas situações, por exemplo: o Lifecycle Objective (LCO) que é executado ao fim da
fase de Iniciação e visa garantir que todos os devidos artefatos foram coletados dando subsídio à decisão de
prosseguir ou não com o projeto.

5.1.1 Fases de Planejamento

As fases não são idênticas em termos de programação e esforço. Embora isso varie muito de acordo com
o projeto, um ciclo de desenvolvimento inicial típico para um projeto de médio tamanho deve prever a
seguinte distribuição de esforço e programação:

que pode ser descrito graficamente como:

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 37


Lucélia Viera Mota
Versão 2.0
Esta distribuição pode variar. Por exemplo, ferramentas que gerem código e etapas de teste podem
diminuir a fase de construção. Além disso, para um ciclo de evolução, as fases de iniciação e de elaboração
seriam consideravelmente menores, já que uma visão e arquitetura básicas já estão estabelecidas.

5.1.2 Movendo de Um Ciclo para o Próximo

Cycle A development cycle is the period of time that elapses from the very start of the project until product release. We
often distinguish initial development cycles from evolution cycles or maintenance cycles. An initial development cycle, leading
to the very first release of a system, is often referred to as a "green-field" development. An evolution cycle is referred as
“brown-filed” development.

Uma passagem pelas quatro fases é um ciclo de desenvolvimento; cada passagem pelas quatro fases
produz uma geração do software. A menos que o produto "desapareça", ele irá se desenvolver na próxima
geração, repetindo a mesma seqüência de fases de iniciação, elaboração, construção e transição, mas agora
com ênfase diferente nas diversas fases. Esses ciclos subseqüentes são chamados ciclos de evolução. À
medida que o produto atravessa vários ciclos, são produzidas novas gerações.

Os ciclos de evolução podem ser disparados por melhorias sugeridas pelos usuários, mudanças no
contexto do usuário, mudanças na tecnologia subjacente, reação à concorrência e assim por diante.
Normalmente, os ciclos de evolução têm fases de Iniciação e Elaboração bem menores, pois a definição e a
arquitetura básicas do produto foram determinadas pelos ciclos de desenvolvimento anteriores. São
exceções a essa regra os ciclos de evolução, em que ocorre uma redefinição significativa do produto ou da
arquitetura.

5.2 Inception

A meta dominante da fase de iniciação é atingir o consenso entre todos os investidores sobre os objetivos do
ciclo de vida do projeto.
A fase de iniciação tem muita importância principalmente para os esforços dos desenvolvimentos novos, nos
quais há muitos riscos de negócios e de requisitos que devem ser tratados para que o projeto possa prosseguir.
Para projetos que visam melhorias em um sistema existente, a fase de iniciação é mais rápida, mas ainda se
concentra em assegurar que o projeto seja compensatório e que seja possível fazê-lo.

The inception phase is of significance primarily for new development efforts, in which there are significant business and
requirements risks which must be addressed before the project can proceed.
The primary objectives include these:
 Establishing the project's software scope
 Discriminating the critical UC, the primary scenarios of operation that will drive the major design trade-
offs

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 38


Lucélia Viera Mota
Versão 2.0
 Exhibiting at least one candidate architecture against some of the primary scenarios
 Estimating the overall cost and schedule for the entire project
 Estimating potential risks
 Preparing the supporting environment for the project

The essential activities of the Inception phase include:


 Formulating the scope of the project: involves capturing the context and the most important
requirements.
 Planning and preparing a business case: evaluating risk management, staffing, project plan, cost, sched.
 Synthesizing a candidate architecture: demonstrate feasibility through some kind of proof of concept.
 Preparing the environment for the project: selecting tools, deciding which parts of the process to
improve.

5.2.1 Lifecycle Objective (LCO) Milestone

The project team focuses primarily on producing work products that will help the project get the necessary
funding for the next phase. Therefore, none of the artifacts are necessarily expected to be completed:
 Vision (core requirements, features, and constraints)
 Business Case (assessment of the situation and projects)
 Risk List (initial draft)
 Software Development Plan (high-level initial estimate, phase plan)
 Iteration Plan (plan for the first iteration of Elaboration)
 Development Process (agreement on chosen software engineering process)
 Development Infrastructure (the tools for Elaboration are in place)
 Glossary (initial Glossary capturing important terms)
 Use-Case Model (most critical use cases and actors are defined, and some of them are briefly outlined)

The evaluation criteria for the LCO milestone include the following:
 Stakeholder concurrence on scope definition and cost/schedule estimates
 Agreement that the right set of requirements has been captured and that there is a shared
understanding of those requirements
 Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate
 Identification of all risks and a mitigation strategy for each

5.3 Elaboration

A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base
estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de um exame dos requisitos
mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A
estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.

The main purpose is to baseline the architecture of the system and provide a stable basis (baseline) for the bulk of the
design and implementation effort in the next phase. The primary objectives include these:
 The architecture, requirements, and plans are stable enough and the risks sufficiently mitigated.
 Addressing all architecturally significant risks of the project.
 Establishing a baselined architecture derived from addressing the architecturally significant scenarios.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 39


Lucélia Viera Mota
Versão 2.0
 Producing an evolutionary prototype of production-quality components and one or more exploratory.
 Demonstrating that the baselined architecture will support the requirements considering cost/schedule.
 Establishing the supporting environment.

The essential activities of the Elaboration phase include:


 Defining, validating (testing) and baselining the architecture as rapidly as practical.
 Refining the Vision, based on new information obtained during the phase.
 Creating and baselining detailed iteration plans for the construction phase.
 Refining the development process and putting in place the development environment.
 Refining the architecture and selecting components.

5.3.1 Lifecycle Architecture (LCA) Milestone

The emphasis on work products during Elaboration includes the following:


 Prototypes (executables that validate different architectural approaches)
 Risk List (revised)
 Development Process (the process as well as guidelines and templates have been refined, tailored)
 Development Infrastructure (tools and process automation support for Construction are in place)
 Software Architecture Document (created and updated with architectural findings)
 Demonstration that the baselined architecture will support the requirements
 Design Model (defined and architecturally important components assessed against scenarios)
 Data Model (created and entities, relationships and tables listed)
 Implementation Model (major components prototyped)
 Vision (revised based on the architectural findings)
 Software Development Plan (updated for Construction and Transition phases)
 Iteration Plan (plan for the first iteration of Construction)
 Use-Case Model (the vast majority of use cases are specified)
 Supplementary Specifications (nonfunctional are documented)
 Test Suite (tests for the architectural scenarios are implemented)
 Test Automation Architecture (creates and defines the various test automation techniques for
Construction)
 Business Case (revised based on the exploratory work during Elaboration)

The evaluation criteria for the LCA milestone include these:


 The product vision and requirements are stable.
 The architecture is stable.
 The key approaches to be used in test and evaluation are proven.
 Testing has demonstrated that the major risk elements have been addressed.
 The iteration plans for the Construction phase are of sufficient detail.
 The iteration plans for the Construction phase are supported by credible estimates.
 All stakeholders agree that the current vision can be met if the current plan is executed.
 Actual resource expenditure versus planned expenditure is acceptable.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 40


Lucélia Viera Mota
Versão 2.0
5.4 Construction

A meta da fase de construção é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema


com base na arquitetura da baseline. A fase de construção é de certa forma um processo de manufatura, em que
a ênfase está no gerenciamento de recursos e controle de operações para otimizar custos, programações e
qualidade. Nesse 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 dos produtos que podem ser
implantados durante a construção e transição.

Construction is usually the most resource-intensive phase, which affects the financial and timely success of the project.
These are the primary objectives:
 Minimizing development costs by optimizing use of resources and avoiding unnecessary scrap and rework.
 Achieving adequate quality as rapidly as practical.
 Achieving useful versions (alpha, beta, and other test releases) as rapidly as practical.
 Completing the analysis, design, development, and testing of all required functionality.
 Iteratively and incrementally developing a complete product that is ready to transition to its user.
 Deciding if the software, the sites, and the users are ready for the application to be deployed.
 Achieving some degree of parallelism in the work of development teams.

The essential activities of the Construction phase include:


 Resource management, control and process optimization
 Complete component development and testing against the defined evaluation criteria
 Assessment of product releases against acceptance criteria for the vision.

5.4.1 Initial Operational Capability (IOC) Milestone

Many of the following artifacts have come to completion:


 The System (the build, ready for beta testing)
 Deployment Plan (initial version, containing the deployment strategy)
 Implementation Model (iteratively expanded model from the Elaboration phase)
 Test Suite (proven tests that validate the stability of the system)
 User Support Material (preliminary drafts of training and user manuals based on use cases)
 Iteration Plan (a plan for the next iteration in Transition or the remainder of the project)
 Design Model (evolved to near completion)
 Development Process (revised and constantly improved throughout the project, ready for Transition)
 Development Infrastructure (process automation and tool support for the Transition phase is in place)
 Data Model (updated with all remaining details throughout Construction; mirrors the actual executable)
 Review of the business modeling work products

The evaluation criteria for IOC include the following:


 The product release is stable and mature enough to be deployed in the user community.
 All the stakeholders are ready for the transition into the user community.
 The resource expenditures are still acceptable.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 41


Lucélia Viera Mota
Versão 2.0
5.5 Transition

O foco da Fase de transição é assegurar que o software esteja disponível a seus usuários. A Fase de
Transição pode atravessar várias iterações e inclui testar o produto em preparação para release e ajustes
pequenos com base no feedback do usuário. Nesse momento do ciclo de vida, o feedback do usuário deve priorizar
o ajuste fino do produto, a configuração, a instalação e os problemas de usabilidade; todos os problemas
estruturais mais graves devem ter sido trabalhado muito antes no ciclo de vida do projeto.
During Transition, a project is rolled out into its planned environment. The training plan for the staff is executed, final
acceptance tests are executed, and paperwork is submitted. The primary objectives of the Transition phase include the
following:
 Beta testing to validate the new system against user expectations
 Beta testing and parallel operation relative to a legacy system that it's replacing
 Converting operational databases
 Training of users and maintainers
 Rolling out to the marketing, distribution, and sales forces
 Deployment-specific engineering such as cutover, commercial packaging and production, sales rollout.
 Tuning activities such as bug fixing, enhancement for performance, and usability
 Assessing the deployment baselines against the complete vision and acceptance criteria for the product
 Achieving user self-supportability
 Achieving stakeholder concurrence that deployment baselines are complete
 Achieving stakeholder concurrence that deployment baselines are consistent with the evaluation criteria of the
vision

5.5.1 Product Release (PR) Milestone

Many of the following artifacts are now complete:


 The Product Build (in-line with the requirements stated throughout the project)
 User Support Material.
 Implementation Elements (the documentation and the finalized product are in synch)

The evaluation criteria for the Transition phase involve the answers to these questions:
 Is the user satisfied?
 Did the resource expenditures turn out to be acceptable?

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 42


Lucélia Viera Mota
Versão 2.0

6 Key Concepts
6.1 Coarse-Grain And Fine-Grain Plans: Project Plans And Iteration Plans

Because the iterative process is highly dynamic and adaptive and is meant to accommodate changes to goals and tactics,
there is no purpose in spending an inordinate amount of time producing detailed plans that extend beyond the current project
horizon. Such plans are difficult to maintain, rapidly become obsolete, and are typically ignored by the performing organization
after a few weeks.

In an iterative process, two kinds of plans are recommended:


- A coarse-grained plan. The project plan, which focuses on phases and iterations, their objectives, and the overall
staffing level
- A series of fine-grained plans. The iteration plans, one per iteration, which bring RUP activities and individual
resources into perspective

The Project Plan Top management and external stakeholders are rarely interested in the details of who is doing what and
when. They are interested in the final product. The project plan is a coarse-grained plan.

The project plan(Software Development Plan) includes the following:


Business Case: develop an economic plan for realizing the project. Used to make an accurate assessment of the ROI.
Software Development Plan: is a comprehensive, composite artifact that gathers all information required to manage the
project.
 Measurement Plan: defines the measurement goals, the associated metrics, and the primitive metrics to be
collected in the project to monitor its progress.
 Problem Resolution Plan: describes the process used to report, analyze, and resolve problems that occur
during the project.
 Product Acceptance Plan: describes how the customer will evaluate the deliverable artifacts from a project to
determine if they meet a predefined set of acceptance criteria.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 43


Lucélia Viera Mota
Versão 2.0
 Quality Assurance Plan: provides a clear view of how product, artifact, and process quality are to be assured. It
contains the Review and Audit Plan, and references a number of other artifacts developed during the Inception
phase.
 Risk Management Plan: details how to manage the risks associated with a project. It details the risk
management tasks that will be carried out, assigned responsibilities, and any additional resources required for the
risk management activity

Iteration Plan: is a time-sequenced set of activities and tasks, with assigned resources, containing task dependencies, for the
iteration; a fine-grained plan Iteration Assessment: captures the result of an iteration, the degree to which the evaluation
criteria were met, lessons learned, and changes to be done.

An iteration plan is a fine-grained, time-boxed plan; there is one plan per iteration. A project usually has two iteration plans
"active" at any time:
 The current iteration plan (for the current iteration), which is used to track progress
 The next iteration plan (for the upcoming iteration), which is built toward the second half of the current iteration
and is ready at the end of the current iteration

While the team is executing the current iteration plan, the project manager is writing the plan for the next iteration.
The iteration plan is built using traditional planning techniques and tools (Gantt charts and so on) to define the tasks and help
allocate them to individuals and teams.
You can picture the iteration plan as a window moving through the project plan (or phase plan), acting as a magnifier.

Issues List: record and track problems, exceptions, anomalies, or other incomplete tasks.
Deployment Plan: provides a detailed schedule of events, persons responsible, and event dependencies required to ensure
successful cutover to the new system.
Project Measurements: provides the storage for the project's metrics data
Review Record: Created to capture the results of a review activity in which one or more project artifacts are reviewed
Risk List: is a sorted list of known and open risks to the project
Status Assessment: To provide a mechanism for addressing, communicating, and resolving management issues, technical
issues, and project risks.
Work Order: is the Project Manager's means of communicating what is to be done, and when, to the responsible staff

6.2 Risk Management

Risco é uma variável que, em sua distribuição normal, pode assumir um valor que comprometa ou
acabe com o sucesso de um projeto. Atributos de um risco:
Probabilidade de ocorrência (Ranking)
Impacto sobre o projeto (gravidade - magnitude)

Estratégias Para cada risco observado, você decide antecipadamente o que pretende fazer. Existem 3
principais rotas possíveis:
 Evitação de risco: reorganizar o projeto de modo que não seja afetado por um risco.
 Transferência de risco: reorganizar o projeto de modo que alguém ou algo assuma o risco (o
cliente, o fornecedor, o banco, um outro elemento etc.).

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 44


Lucélia Viera Mota
Versão 2.0
 Aceitação de risco: decidir conviver com o risco como uma contingência. Monitore o sintoma do
risco e escolha um plano de contingência que o oriente sobre o procedimento a ser tomado em caso
de risco

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 45


Lucélia Viera Mota
Versão 2.0

7 A Plataforma RMC (Rational Method Composer)


Durante muitos anos de esforço de desenvolvimento, o RUP evoluiu em uma plataforma de engenharia de
processo valiosa, chamada RMC (Rational Method Composer). O RMC permite que equipes definam, configurem,
ajustem e pratiquem um processo consistente. Os elementos chave da plataforma são:

 Ferramentas de Entrega de Método


O RUP é entregue aos profissionais como um Web site interativo utilizando a tecnologia de navegador
padrão de mercado. As ferramentas para entregar o RUP incluem:

 O Web site do RUP no qual Você Está Navegando no momento


Um Web site do RUP é uma apresentação do processo publicado do Rational Method Composer ,
configurada para seu projeto e ajustada para suas necessidades específicas. O Web site é criado
utilizando páginas HTML geradas dinamicamente, as quais o RMC permite que sejam publicadas na
forma de vários Web sites do RUP, cada um representando uma definição de processo configurada e
ajustada.

 Um Conjunto de Ferramentas de Navegação do Navegador da Web


Os applets de Navegador do RUP permitem que o Web site do RUP seja acessado dinamicamente por
meio de uma série de navegadores da Web padrão com a ajuda de applets adicionais de navegação.

 Ferramenta de Método Configuração


O RMC (Rational Method Composer) suporta configuração de tempo de publicação de granulação fina de
conteúdo de método e processos, para alcançar as variadas necessidades de diferentes projetos e
usuários finais. O Method Composer permite a inclusão opcional de extensões de método e de processo,
utilizando a tecnologia de plug-in do Method Composer. Ele também permite configurar variantes nos
processos, que são publicadas diferentemente, dependendo das seleções específicas do usuário.

 Um Marketplace para Extensões de Processo


A seção do RUP do Web site do developerWorks®: Rational® fornece um local para os engenheiros de
processo na comunidade de desenvolvimento de software, para compartilharem suas extensões de
método como Plug-Ins consumíveis e fornece uma origem valiosa de extensões de método para o
coordenador de projeto.

 Ferramenta de Autoria de Método


A ferramenta RMC (Rational Method Composer) é projetada especificamente para gerenciamento de
conteúdo de método e autoria de processo com funções, tais como forma- e autoria baseadas em
estrutura de breakdown, navegação de conteúdo, procura de conteúdo e importação e exportação do
conteúdo de método. O Method Composer também fornece mecanismos para montagem de processo
rápida, utilizando padrões de processo e elementos de método reutilizáveis. Ele suporta a criação de
plug-ins de método, que fornecem maneiras eficientes de estender e modificar o conteúdo existente,
simplificando o conteúdo de método e o gerenciamento do processo e manutenção.

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 46


Lucélia Viera Mota
Versão 2.0

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 47


Lucélia Viera Mota
Versão 2.0

8 Roteiro para a prova RUP 839

Antes de começar a estudar é importante entender como funciona a prova. Ela não é muito diferente de

outras certificações podendo ser marcada pelos centros Prometric e custando U$ 100,00. É composta de 52

questões e pode ser feita em até 75min sendo a nota mínima para aprovação de 62%, ou seja, erre no máximo 19

questões para ser aprovado.


Outro ponto importante sobre a prova é entender o foco da mesma. Como pode ser visto no site oficial da
Certificação o foco é distribuído conforme abaixo:

 Iterative Development Principles (16.6%)

 Iterative Development Work Products (16.6%)

 Basic Method Elements and their Relationships (16.6%)

 Basic Process Elements and their Relationships (16.6%)

 Basic Content of Disciplines (33.6%)

Passo 01: O caminho das pedras:

 O Livro IBM Rational Unified Process Reference and Certification Guide: Solution Designer (RUP) de

Ahmad K. Shuja e Jochen Krebs foi o primeiro a ser lançado sobre RUP 7 em Jan/2008. Recomendo

fortemente a leitura pois nele ficam claras as diferenças do RUP 2003 em relação ao 7. A cada capítulo os

autores apresentam o conteúdo do RUP atrelado a um simulado para ajudar a fixar o assunto.

 No último capitulo também é apresentado um simulado dentro das condições reais da prova, ou seja, 52

questões divididas dentro dos focos da prova;

 Depois de finalizada a leitura do livro explore o site do RUP. Alguns conteúdos sugeridos por Hans

Admiraal em "Learning RUP 7.0" são realmente fundamentais e de leitura obrigatória.

Passo 02: Não entre na sala de exames sem ter “decorado”:

 Os 6 Key Principals do RUP e seus benefícios. Não é necessário decorar os Patterns e Anti-Patterns mas o

benefícios com certeza sim;

 As disciplinas do RUP e os propósitos de cada uma delas;

 O que é UMA e quais são exatamente cada um dos elementos de conteúdo (Roles, Tasks, Steps,

WorkProducts, etc..) e dos elementos de processo (Activities, Iterations, Phases, Capability Pattern, etc);
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 48
Lucélia Viera Mota
Versão 2.0

 As fases do RUP e os objetivos de cada uma, assim como, os Milestones;

 No site do RUP leia com atenção todo o conteúdo disponível em: Work Products > RUP Domains > Project

Management. Vários WorkProducts de gerenciamento são cobrados, principalmente o Software

Development Plan e seus cinco sub-artefatos devem ser decorados.

Passo 03: Os simulados:

 A essa altura você já deveria estar aplicando os próprios conceitos do RUP para evitar que seu projeto de

Certificação falhe. Sendo assim podemos dizer que os simulados são a sua Arquitetura Executável.

Infelizmente, como a própria certificação 839 é recente você não encontrará muitos simulados

facilmente;
 Para ter uma idéia real das questões da prova o próprio site oficial do RUP dá cinco questões de
demonstração que vale a leitura;
 Por último no site de Hans Admiraal é possível fazer um simulado do RUP 2003 gratuitamente e outro

de RUP 7, porém pago.

 No final deste material eu colhi e coloquei para vocês os três simulados que comprei para minha prova

espero que ajude.

Passo 04: O grande dia:

 Se você fez tudo como sugerido somando uma grande vontade de não perder U$ 100,00 você terá

grandes chances de atingir os 62% da prova e se tornar um IBM Certified Solution Designer - IBM

Rational Unified Process V7.0.

Boa Sorte!!

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 49


Lucélia Viera Mota
Versão 2.0

9 SIMULADOS
Simulado Pass4-Sure

1. Which two factors determine the duration of iteration? (Choose two.)


a. The size of the project
b. The priority set by customer on particular features
c. The requirement for a minimum of six iterations in a project
d. The level of automation used to manage code, distribute information and perform testing

2. Which of the seven core metrics for iterative development are used as management indicators?
a. Change traffic and stability, breakage and modularity
b. Work and progress; budgeted cost and expenditures; staffing and team dynamics
c. Defect rates from design document reviews
d. Rework and adaptability, mean time between failures(MTBF); maturity

3. Which two statements are true about executable architecture? (Choose two.)
a. It is a disposable prototype of the application
b. It is a simulation of the executing system
c. It is a validation (testable) of the architecture
d. It is the baseline for the rest of development

4. Which two concepts guide iterative development? (Choose two.)


a. Early completion of simple features, to show progress to the customer
b. Informal plans, allowing features to be moved to future iterations
c. Early baselining of architecture, allowing stability in planning, content and organization
d. Scope validation by stakeholders, to account for their needs

5. Which two statements are true about iterations? (Choose two.)


a. Working software is always delivered to the customer
b. An iterations always has a plan and evaluation criteria
c. An iteration is a mini project with a plan, deliverables and assessment
d. There are always multiple iterations in each phase

6. Why does the risk-time profile decline more rapidly for iterative development than waterfall
development? (Choose two.)
a. Iterative development exposes design flaws and enables resolution earlier in the lifecycle
b. With iterative development, customer satisfaction is maintained by early, incremental deliveries of capability
c. In iterative development , the software architecture can be revised in any iteration to support new features
and overcome performance problems
d. Iterative development allows key, non-functional requirements (i.e performance, fault tolerance and
maintainability) to be addressed early in development

7. How does an iterative approach help with resource and cost control?
a. It allows the project manager to control allocation of resources by phase. Artifacts evolve as required by
each phase and there is increased precision of cost estimates from phase to phase
b. It allows the project manager to make budgetary requests with each iteration, These requests are based on
the expansion of project scope as requested by the customer
c. It allows iterations to be planned in advance and in detail for all phases. It helps establish costs and a profile
of resource usage can be generated in advance for the entire project
d. It allows iterations to be de-scoped as required, at the direction of the project manager. It allows better
management of costs as features can be moved to later iterations when resources are available

8. Which is part of the evaluation criteria for successful completion of the elaboration phase?
a. A final set of requirements is agreed upon
b. All detailed design documents are reviewed
c. The architecture is stable
d. Less than 50% of project budget is expended
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 50
Lucélia Viera Mota
Versão 2.0

9. Which is a fine-grained plan?


a. Software Development plan
b. Business Case
c. Iteration Plan
d. Risk Management Plan

10. What does the project Manager identify in a risk list?


a. Risk magnitude and ranking
b. Requirements to risk mapping
c. Test to risk mapping
d. Risk strategy definition

11. In planning for iterative, the project plan referred to as a ______.


a. Roadmap
b. Fine-grained plan
c. Detailed plan
d. Risk management tool

12. In the construction phase, what are two areas of focus of the iteration plan? (Choose two.)
a. Development efficiency
b. Project scoping
c. Architectural risks
d. Product quality

13. What is the purpose of the project plan?


a. To assess the feasibility of the project
b. To establish project staffing
c. To describe the phases and major milestones of the project
d. To provide a sound rationale for project funding

14. The iteration plan belongs to ________.


a. The project management domain and the Specification work product kind
b. The assessment domain and the project management work product kind
c. The planning domain and the project management work product kind
d. project management domain and the plan work product kind

15. What are two functions of a status assessment? (Choose two.)


a. manages expectations
b. Provides a mechanism for resolving management issues
c. Rates the overall project quality
d. Resolves risk items

16. Which three work products belong in the project management discipline? (Choose three.)
a. Risk management plan
b. Business case
c. Test evaluation summary report
d. Project plan

17. What are three types of work products? (Choose three.)


a. Artifact
b. Deliverable
c. Milestone
d. Outcome

18. Which element of RUP typically applies to several work products, task or activities?
a. A concept
b. A guideline
c. A tool mentor
d. A practice
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 51
Lucélia Viera Mota
Versão 2.0

19. Which two model elements can be linked to descriptor? (Choose two.)
a. Phase
b. Task
c. Activity
d. Role

20. What relationship(s) can a work product have to a task?


a. Input only
b. Output only
c. Input and output
d. Optional input, mandatory input, and output

21. A role is a set of related responsibilities, ________.


a. Skills and competencies
b. Skills and tasks
c. Tasks and artifacts
d. Tasks and work products

22. Where are a tasks input and output work products shown?
a. Task checklist
b. Task element description pages
c. Work product element description pages
d. Discipline workflow pages

23. Where can an analyst find the guidelines that address how to perform the task identify actors?
a. Task descriptor page
b. Role descriptor page
c. Actor descriptor page
d. Analyst set descriptor page

24. What are three characteristics of a task? (Choose three.)


a. Is work a role performs
b. Occurs once in an iteration
c. Has granularity of a few hours to a few days
d. Usually affects only one or a small number of work products

25. Which three views show the work performed in a delivery process and its elements? (Choose three.)
a. Work-breakdown-structure
b. Description
c. Team allocation
d. Work production usage

26. As a process engineer, you are asked develop a process element for tasks and steps in an activity called
plan for nest iteration. The tasks and order of steps will be the same during inception, elaboration,
construction and transition phases. With a focus on future maintenance, what is the most appropriate
process element you can develop?
a. Task descriptor
b. Capability Pattern
c. Delivery Process
d. Activity descriptor

27. Which statement is true about the relationship between tasks, activities and delivery processes?
a. Activities can be repeated wherever necessary in the delivery process
b. Activities must be repeated wherever necessary in the delivery process
c. Activities can NOT be repeated wherever necessary in the delivery process
d. Activities are not related to delivery processes

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 52


Lucélia Viera Mota
Versão 2.0

28. What is the purpose of a capability pattern?


a. Iteratively shows project team capabilities
b. Publishes end-to-end processes
c. Assigns capabilities to a role
d. Composes delivery processes

29. Which two are delivery processes in the RUP view? (Choose two.)
a. Lifecycle Objective Milestone
b. Supporting process with tools
c. Classic RUP lifecycle
d. Business Modeling lifecycle

30. 30. Each pug-in separates method content from processes. What re two subcategories of processes?
(Choose two.)
a. Content Packages
b. Capability patterns
c. Custom category
d. Delivery process

31. What is the top-down, hierarchy of process elements in the classic RUP lifecycle delivery process?
a. Activity, task, iteration phase
b. Phase, iteration, activity, activity descriptor
c. Iteration, phase, activity, Milestone
d. Phase, iteration, activity, sub-activity

32. What two are process elements? (Choose two.)


a. Task
b. Activity
c. Capability pattern
d. Guideline

33. What is the main benefit of the principle of demonstrating value iteratively?
a. Simplified project planning
b. Early reduction of risk
c. Minimizing change
d. Better product quality

34. What is benefit of adapting the process?


a. More precise planning
b. Better product quality
c. More accurate early estimates
d. Better lifecycle efficiency

35. Which three are RUP disciplines? (Choose three.)


a. Program management
b. Configuration and change management
c. Requirements
d. Analysis and design

36. What are three purpose of the project management discipline? (Choose three.)
a. T o provide projects status and measures
b. To provide a framework managing software-intensive projects
c. To provide practical guidelines for planning, staffing, executing and monitoring projects
d. To provide a framework for managing risk

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 53


Lucélia Viera Mota
Versão 2.0

37. What are two benefits that result from implementing the principle of focusing continuously on
quality? (Choose two.)
a. Better quality
b. Easier testing cycle
c. More regression testing
d. Earlier insight progress

38. Business Modeling is input to _______. (Choose two.)


a. Requirements
b. Analysis and design
c. Environments
d. Tests

39. What are two functions of configuration management? (Choose two.)


a. Addresses the organizational infrastructure
b. Provides a history and rationale for changes
c. Describes the project structure
d. Identifies the product constituent configuration items

40. What is often the result of applying the key principle of collaboration across teams?
a. Specialized skills
b. Employees that better know their roles
c. Motivated workforce
d. Earlier integration

41. What are two benefits of implementing the business-driven principle elevating the level of
abstraction? (Choose two.)
a. Increases productivity
b. Removes risks early in the process
c. Improves product quality
d. Reduces product complexity

42. What is the key benefit of implementing the principle of elevating of abstraction?
a. better requirements
b. More rapid code access
c. Modeling the architecture
d. Reduce complexity

43. What are three purpose of the requirements discipline? (Choose three.)
a. Defines system boundaries
b. Defines a user interface for the system
c. Details a user interface for the system
d. Provides a basis for planning the content for iterations

44. What are three benefits of implementing the business-driven principle demonstrate value iteratively?
(Choose three.)
a. Early risk reduction
b. Improved specification reviews
c. Higher predictability throughout the project
d. Trust among stakeholders

45. Which two activities does deployment discipline manage? (Choose two.)
a. Activities associated with testing at the installation and target sites
b. Activities associated wih creating end-user support material and creating user training material
c. Activities associated with ensuring that the software product is available for end users
d. Activities associated with beta testing

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 54


Lucélia Viera Mota
Versão 2.0

46. What is a benefit of balancing competing stakeholder priorities?


a. Achievement of business value
b. Reduction in custom development
c. A better understanding of what assets can be leveraged
d. Ability to understand and prioritize business and user needs

47. What are two benefits of implementing the business-driven principle focus continually on quality?
(Choose two.)
a. Greater productivity
b. Higher product quality
c. Improved reuse
d. Earlier insights into measures of progress and quality

48. What is the focus of the environment discipline?


a. The current process
b. Activities necessary to configure the process for a project
c. Current tools
d. Current staff skills and capabilities

49. The requirements discipline describes how to _______. (Choose two.)


a. Translate the vision into a use –case model
b. Create a use-case model
c. Create requirements types
d. Create a vision

50. What are three key principles of business-driven development? (Choose three.)
a. Adapt the artifacts
b. Demonstrate value iteratively
c. Collaborate across teams
d. Focus continuously on quality

51. Why is it important to balance competing stakeholder priorities?


a. To optimize the business value
b. To obtain early requirements agreement
c. To better architect the system
d. To minimize cost

52. A benefit of a right-sized process is an improvement in ________.


a. Lifecycle efficiency
b. Requirements
c. Delivered code
d. Quality

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 55


Lucélia Viera Mota
Versão 2.0
Gabarito

1 A, D 27 A
2 B 28 D
3 C, D 29 C, D
4 C, D 30 B, D
5 B, C 31 D
6 A, D 32 B, C
7 A 33 B
8 C 34 D
9 C 35 B, C, D
10 A 36 B, C, D
11 A 37 A, D
12 A, D 38 A, B
13 C 39 C, D
14 D 40 C
15 A, B 41 A, D
16 A, B, D 42 D
17 A, B, D 43 A, B, D
18 A 44 A, C, D
19 B, D 45 B, C
20 D 46 B
21 A 47 B, D
22 B 48 B
23 A 49 A, D
24 A, C, D 50 B, C, D
25 A, C, D 51 A
26 B 52 A

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 56


Lucélia Viera Mota
Versão 2.0

Simulado do Livro

1. Which of the following concepts is the most coarse-grained of the four that follow?
a. Step
b. Activity
c. Task
d. Task Descriptor

2. The team is developing use cases that are not critical to the architecture. Which phase is the project
in?
a. testing
b. Elaboration
c. Collaboration
d. Construction

3. Which of the following work products is part of the project management discipline? (02)
a. Project repository
b. Business case
c. Glossary
d. Review record

4. An inexperienced project manager makes four different statements about iteration. Which ones are
correct? (02)
a. Every project consist of four phases, and each phase always consist of only one iteration
b. An iteration can include all disciplines
c. Iterations are optional and are only needed when ask for them
d. Iterations should be between 2 and 8 weeks long

5. 5. On which concepts does iterative development have a positive impact? (03)


a. Syntax
b. Risks
c. Customer feedback
d. Quality

6. Which of the following is a RUP discipline? (02)


a. Environment
b. Configuration and change management
c. Quality Assurance
d. Quality control

7. Which of the following is true about risks in iterative development?


a. They increase over time and peak at the end of the project
b. Architectural risks are addressed early in the project
c. Risks are transferred during transition
d. Without any high risks, iterative development is not necessary

8. Which of the following is a “type” of test in RUP? (02)


a. Stress
b. Safety
c. Refactoring
d. Load

9. For which of the following work products is the RUP project manager responsible? (02)
a. Every work product
b. Business vision
c. Business case
d. Iteration plan

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 57


Lucélia Viera Mota
Versão 2.0
10. Configuration management tools support project team members with doing which of the following?
(02)
a. Performing version control
b. Eliciting change request
c. Enabling human collaboration
d. Creating a baseline

11. Who is responsible for the requirements management plan?


a. System analyst
b. Project manager
c. Change control manager
d. Configuration manager

12. What artifact references the iteration plan, the iteration objectives, and the evaluation criteria of an
iteration?
a. Status assessment
b. Risk list
c. Deployment plan
d. Software development plan

13. You are playing the role of a project manager, and you have estimated the length of the entire project.
Now you need to allocate a length to each phase. Without prior project experience, you want to apply
the template recommendation of RUP. Which one would you chose?
a. Inception (10%), Elaboration (30%), Construction (50%), transition (10%)
b. Inception (5%), Elaboration (20%), Construction (65%), transition (10%)
c. Inception (20%), Elaboration (20%), Construction (40%), transition (20%)
d. Inception (25%), Elaboration (25%), Construction (25%), transition (25%)

14. Who is responsible for the deployment plan?


a. Deployment architect
b. Deployment manager
c. Configuration Manager
d. Technical writer

15. The risk-list contains high-ranked architectural risks, and software architect is leading a team of
developers to create an architectural prototype for a use-case scenario. What RUP phase is this
project in?
a. Elaboration
b. Inception
c. Construction
d. Prototyping

16. Use cases are a basis for which of the following? (03)
a. System Modeling
b. Iteration Planning
c. Process Planning
d. Test Planning

17. How many iterations would a RUP project have during the construction phase when the “Grand
design” strategy for iterative development was chosen?
a. 4
b. 1
c. One more than elaboration
d. Not possible to determine

18. Which of the following statements best defines the relationship between roles and a team member?
a. Roles might or might not be assigned to team members
b. A team members fills one role, and a role is filled by exactly team member
c. A team can fill one or more roles, and a role can be filled by one or more team members
d. A team member can fill one role only, but a role can be filled by one or more team members
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 58
Lucélia Viera Mota
Versão 2.0

19. Which of the following is a phase in a RUP development project? (02)


a. test
b. Transition
c. Collaboration
d. Construction

20. Which of the following terms characterizes a role? (03)


a. Competency
b. Skills
c. Integrity
d. Responsibility

21. Which of the following statements is true about the software development plan? (02)
a. It is only useful for inexperienced project managers
b. It describes all iterations in depth from project start to end
c. It contains the risk management plan
d. It outlines the phases and major milestones of the project

22. A customer asks you to assemble and publish a process that is similar to the existing one but only
slightly different in one area. Which elements do you focus your attention on first?
a. Delivery Processes
b. Capability patterns
c. Reusable assets
d. Practices

23. Which of the following is a work product type? (03)


a. Package
b. Deliverable
c. Outcome
d. Artifact

24. Which of the following is correct about the primary and the secondary performer of a task?
a. The primary performer is supposed to do the work; the secondary performer is the backup
b. The primary performer does the planning of the work; the secondary executes
c. The primary performer is responsible for the task; the secondary assits
d. There is no difference. It is useful only for senior management to have a point of contact each task

25. A project is considered low ceremony. What characteristics apply to it? (02)
a. large project
b. Small project
c. Few stakeholders
d. Distributed teams

26. Which of the following elements contains a practical explanation of how to create or revise a work
product?
a. Concept
b. Template
c. Guideline
d. Roadmap

27. A content page provides a general purpose, primary, and additional performer, optional and
mandatory input work products, and steps. Which content element is described?
a. Task
b. Checklist
c. Work-Product descriptor
d. Activity

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 59


Lucélia Viera Mota
Versão 2.0

28. What is the benefit of the key principle balance stakeholder needs?
a. perform version control
b. Forecast future change request
c. Align applications with business and user needs
d. Get agreement of the acceptance test

29. Which of the following is a process element?


a. Capability Pattern
b. Role descriptor
c. Practice
d. Task

30. Which of the following statements is correct about a capability pattern? (02)
a. it allows reuse of common process fragments
b. It is used to compose delivery processes
c. It shows the capabilities assigned to a role
d. Ii is a mandatory process element

31. A process engineer wants to organize capability patterns. Which folder could she group them in? (02)
a. process Package
b. parcel
c. Content package
d. Capability Pattern

32. Which statement is true about the relationship between capability pattern, activities, and tasks?
a. Activities assemble task, tasks assemble capability patterns
b. Task assemble capability patterns, capability patterns assemble activities
c. Task assemble activities, activities assemble capability patterns
d. There is no relationship

33. Which process element is synonymous with RUP for large projects?
a. Delivery process
b. Capability pattern
c. Milestone
d. Discipline

34. Who is responsible for the vision document?


a. Business analyst
b. System analyst
c. Project analyst
d. Business process analyst

35. What type of process element is the product release or initial operation capability?
a. Milestone
b. Reusable asset
c. Roadmap
d. Practice

36. Which of the following statements best describes the term Discipline?
a. A collection of activities that are all related to a major area of concern
b. A collection of capabilities that are all related to a minor area of concern
c. A collection of delivery processes that are all related to a major area of concern
d. A collection of tasks that are all related to a major area concern

37. Which work product captures requirements of the type feature?


a. Functional requirements
b. Supplementary specification
c. Use case
d. Vision
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 60
Lucélia Viera Mota
Versão 2.0

38. Which discipline will result in the definition of a system boundary?


a. requirements
b. Analysis and design
c. Project management
d. Deployment

39. What is a scenario?


a. Just another term for use case
b. An instance of a use case
c. A problem for project managers
d. Another term for change control

40. What elements are illustrated in a use case diagram? (02)


a. Actor
b. Scenario
c. Use case
d. Non-functional requirements

41. Which discipline is considered an optional discipline prior to the requirements discipline?
a. Environments
b. Analysis and design
c. Business modeling
d. Testing

42. The following three elements have something in common: whitepaper, example, reusable asset. They
are which type of element?
a. Subactivity
b. Deliverable
c. Outcome
d. Guidance

43. Which of the following roles is responsible for promoting baselines?


a. Integrator
b. Baseline manager
c. Supervisor
d. Configuration manager

44. Which of the following can be said about a task? (02)


a. Describes a unit of work
b. Serves as the basis of planning
c. Performed by a role
d. Is usually coarse grained

45. Why are tool mentors useful? (03)


a. They keep the task content independent from vendor-specific details
b. They provide immediate online assistance with tech support from the tool vendor
c. They increase maintainability of the content when software tools update
d. They provide just-in-time technical details for administrator and team members when the tools is being used

46. Which of the following work products is part of the environment discipline? (02)
a. Development process
b. Target organization assessment
c. Development case
d. Test environment configuration

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 61


Lucélia Viera Mota
Versão 2.0
47. Select the key principles of business-driven development from the following choices. (02)
a. Demonstrate value iteratively
b. Adapt the process
c. Communicate among team members
d. Elevate level of generalization

48. Who is responsible for the work product developer test?


a. Integrator
b. Implementer
c. Any role
d. Software architect

49. Which “level” of process element is used to publish a process to a consumer?


a. Task
b. Capability process
c. Activity
d. Delivery process

50. Which type of information would you find in a Risk-list? (03)


a. Mitigation strategy
b. Magnitude
c. Ranking
d. Requirements Traceability

51. Your customer does not like the idea of frequent checkpoints throughout the project. In previous
projects, she got used to signing off on requirements specification and acceptance testing. Which type
of project was she exposed to?
a. Iterative
b. Incremental
c. Waterfall
d. Upstream

52. Which of the following is a factor that affects process rightsizing? (02)
a. project size
b. Compliance requirements
c. Version of RMC
d. Skill level of stakeholders

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 62


Lucélia Viera Mota
Versão 2.0
Gabarito

1 B 27 A
2 D 28 C
3 B, D 29 A
4 B, D 30 A, B
5 B, C, D 31 A, D
6 A, B 32 C
7 B 33 A
8 D 34 B
9 C, D 35 A
10 A, D 36 D
11 A 37 D
12 D 38 A
13 A 39 B
14 B 40 A, C
15 A 41 C
16 A, B, D 42 D
17 B 43 A
18 C 44 A, C
19 B, D 45 A, C, D
20 A, B, D 46 A, C
21 C, D 47 A, B
22 B 48 B
23 B, C, D 49 D
24 C 50 A, B, C
25 B, C 51 C
26 C 52 A, B

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 63


Lucélia Viera Mota
Versão 2.0

Simulado ePlanetLabs

1. In what lifecycle phase is software architecture the primary focus?


a. Elaboration
b. Implementation
c. Design
d. Transition
e. Inception

2. Which of the following statements characterize a typical iteration in the construction phase? (02)
a. It involves more work on requirements than implementation
b. It makes significant changes to the architecture established during elaboration
c. It involves a significant amount of testing
d. It includes creation of the development case for the project
e. It updates the risk list

3. When does an iterative lifecycle enable user/customers to participate in the development process?
a. Only at the beginning and at the end of the schedule
b. In potentially every iteration, to review realeses and provide input
c. When documentation must be generated
d. Only at major milestones

4. How do you represent an actor in basic UML notation?


a. Rectangle containing the actor’s name
b. Arrow
c. Rectangle with three compartments
d. Oval
e. Stick figure

5. Which of the following are evaluation criteria for reaching the lifecycle objectives Milestone? (03)
a. Stakeholders concur on scope definition and cost/schedule estimates
b. The key approaches to be used in test and evaluation are proven
c. There is a shared understanding of the subset or requirements that have been captured so far
d. All risks have been identified and a mitigation strategy exists for each

6. UML activity diagrams are used to describe what part of rational unified process?
a. Activates within a workflow detail
b. Role responsibilities
c. Workflow diagrams for each discipline
d. The flow of information between major artifacts

7. What role is primarily responsible for the artifact project-specific guidelines?


a. Project manager
b. Technical writer
c. Process engineer
d. Tool specialist

8. What is a model?
a. An item that is only needed if an OO coding language used
b. The semantic equivalent of the software architecture document
c. A complete yet typically abstract description of a system from a particular perspective
d. The same thing as a diagram

9. Which of the following is true with respect to a typical RUP iterative lifecycle
a. Detailed iteration plans must be completed during the inception phase for the entire project
b. Planning is done incrementally, starting with coarse-grained planning followed by fine-rained planning
c. Planning is rarely done
d. Detailed iteration planning is done first

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 64


Lucélia Viera Mota
Versão 2.0
10. Which of the following workflow details belong to the project management discipline? (03)
a. Evaluate project scope and risk
b. Monitor and control project
c. Management iteration
d. Understand stakeholder needs

11. Which of the following statements characterize project metrics in rational unified process? (04)
a. They provide insight into progress and quality
b. They are useful tracking trends in important variables such as rework
c. They should not be collected on early iterations
d. They must be collected manually to be accurate
e. They are the basis for iteration assessment

12. Which of the following are software engineering best practices recommended by Rational Unified
Process? (03)
a. Develop iteratively
b. Use component architectures
c. Manage change
d. Maximize reuse
e. Freeze requirements at project inception

13. Which of the following statements characterize a typical iteration in the elaboration phase? (04)
a. It contributes significantly to the software architecture document
b. It produces executable software
c. It updates the risk list
d. It request the leadership of the software architect
e. Its focus is on the development of the vision and business case

14. What statement is true of iterations?


a. you establish plans for each phase, but not for iterations
b. Only transition iterations result in executable releases
c. A lifecycle phase will be addressed by at least one iteration
d. A construction iteration cannot include any requirements activities
e. As a general rule, iterations contain many lifecycle phases

15. Which of the following are phases in Rational Unified Process? (03)
a. Implementation
b. Transition
c. Inception
d. Planning
e. Elaboration

16. Which of the following statements are true concerning requirements? (02)
a. Use cases are used to represent functional requirements
b. Legal and regulatory requirements are usually best captured in use cases
c. Most system do not need any supplementary specifications
d. Most system have no performance requirements
e. Supplementary specifications capture requirements that cannot easily be expressed as use cases

17. Which of the following are within the scope of implementation on discipline? (04)
a. Integration the results produced by individual implementers (or teams)into an executable system
b. Defining the organization of the code in terms of implementation subsystems
c. Implementing independent quality tests of the system or subsystem
d. Testing implementation elements
e. Implementing classes and objects

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 65


Lucélia Viera Mota
Versão 2.0
18. Which of the following statements characterize a typical iteration in the transition phase? (02)
a. It produces end-user support materials such as release notes
b. It results in creation of the development case for the project
c. It results in selection of an architectural baseline
d. It makes the products available for use by its intended end users
e. It requires significant reviews of and changes to the vision

19. Which of the following statements characterize a typical iteration in the inception phase? (04)
a. It includes development of the development case for the project
b. It includes creating detailed, fine-grained plans for all subsequent iterations
c. It involves high-level coarse-grained plans for all subsequent iterations
d. It identifies the initial business and technical risks that must be addressed by the project
e. A significant amount of efforts is spent on the development of the vision and business case

20. Which one of the following test artifacts is the step-by-step instructions that realize a test, enabling its
execution?
a. Test case
b. Test class
c. Test script
d. Test suite

21. Which of the following are important decisions an analysis and design? (04)
a. Whether to generate code
b. How to perform the workflow
c. How to use artifacts
d. Which reports to use
e. How to monitor and control the project

22. Which of the following belong is a typical set of architectural views? (04)
a. Logical view
b. Use-case view
c. Design view
d. Deployment view
e. Implementation view

23. Which of the following statements characterize a class diagram? (03)


a. It can be drawn using UML notation
b. It shows a sequence of interactions between classes
c. It can be used to represent information within the logical and process views
d. It can provide a view of high-level packages or detail of a single package
e. It shows the states and transition of a class

24. Which of the following statements characterize good software architectures? (04)
a. They enable economically reuse
b. They are maintainable and extensible
c. They are highly complex
d. They permit a clear division of work among teams of developers
e. They encapsulate hardware and system dependencies

25. Which of the following are recommended practices according to the implementation discipline? (03)
a. You can use code reviews in place of developer testing
b. Implementation occurs only in the construction phase
c. Implementers debug and test the elements they implement
d. The software architectures the implementation model
e. You implement classes and objects

26. Which of the following phrases characterize the deployment view of architecture in Rational Unified
Process? (03)
a. It shows mapping of processes onto physical nodes
b. It shows communication lines among physical nodes
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 66
Lucélia Viera Mota
Versão 2.0
c. It describe the physical network configuration
d. It describes how the software is developed using distributed development teams and computing resources

27. What phrase best describes round-trip engineering?


a. Another name for a development cycle
b. A term for the rework done in an iterative lifecycle
c. A techniques for keeping the design model synchronized with the source code through a development cycle
d. Another name for iterative lifecycle
e. The practice of developing software in parallel with installation and testing of the hardware

28. Which of the following statements are true regarding risk management in rational unified process? (04)
a. You must actively manage the risk list in each iteration
b. Strategies to address risks include risk avoidance transfer and acceptance
c. Risk reduction drives iterations
d. The risk list should include technical, business and management risks
e. It is best to develop low-risk portions of the system in early iterations to ensure early success

29. When does integration occur in an iterative lifecycle?


a. In elboration, construction and transition iterations, and sometimes in inception
b. Only at the end of elaboration and construction
c. Only iterations that produce external releases
d. Only at the end of elaboration, construction, and transition

30. Which of the following help to define the iteration plan? (03)
a. The current status of the project
b. The development-organization assessment artifact
c. A list of risks you must address by the end of the iteration
d. A list scenarios or use cases you must complete by the end of the iteration

31. Which of the following are purpose of a workflow detail? (03)


a. To show how activities are performed parallel to each other rather than in sequence or all at once
b. To show involved roles, activities and input and output artifacts
c. To show grouping of activities that are often performed together
d. To define all acitivities that are a part of the project

32. Which of the following are major milestones of rational unified process? (04)
a. Lifecycle objectives (LCO)
b. Preliminary Design review (PDR)
c. Product release
d. Initial operational capability (IOC)
e. Lifecycle architecture (LCA)

33. Which two factors determine the duration of na iteration? (Choose two.)
e. The size of the project
f. The priority set by customer on particular features
g. The requirement for a minimum of six iterations in a project
h. The level of automation used to manage code, distribute information and perform testing

34. Which of the following is true about generalization relationship?


a. Is is represented by a dashed arrow
b. Is is represented by a diamond symbol
c. It is a special form of aggregation
d. It is often called inheritance

35. Which of the following statements are true concerning the development case? (03)
a. You can use it specify the degree of formality ssociated with an artifact
b. Is is fixed during inception and does not generally change over the course of a project
c. You can use it to specify the tools used to produce an artifact
d. It tells you which artifacts to produce
Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 67
Lucélia Viera Mota
Versão 2.0

36. How is a class represented in basic UML notation?


a. Arrow
b. Rectangle containing the object’s name
c. Oval
d. Rectangle with three compartments

37. Which of the following are models in rational unified process? (02)
a. Construction model
b. Implementation model
c. Requirements model
d. Design model

38. Which of the following workflow details belong to the configuration & change management discipline?
(03)
a. Manage baseline and releases
b. Change and delivery configuration items
c. Manage iteration
d. Manage change request
e. Define the system

39. What is a development case?


a. The development process that you have chosen to fllow in your project
b. A sample architectural design used to guide architectural decisions
c. A development cycle specifically devoted to maintenance
d. Another name for a key mechanism

40. What is a typical breakdown of a total project effort across the phases?
a. Inception 20% elaboration50% construction 20% transition 10%
b. Inception 5% elaboration 20% construction 45% transition 30%
c. Inception 10% elaboration 10% construction 70% transition 10%
d. Inception 5% elaboration 20% construction 65% transition 10%

41. In RUP, what does the software development plain contain?


a. Iteration plan
b. Requirements management plan, master validation plan, quality test plan and risk management plan
c. Problem resolution plan, product acceptance plan, measurement plan, risk management plan, and quality
assurance plan
d. Requirements management plan, product metrics plan. And software test assurance plan

42. Which three are process views? (03)


a. Work Breakdown structure
b. Team allocation
c. Work product usage
d. Process workflow

43. Which statement is true about delivery processes?


a. They represent a complete end-to-end lifecycle
b. They must contain capability patterns
c. They are only useful to publish a process
d. They replace activities and tasks

44. What are three purposes of the business modeling discipline? (03)
a. Ensures a common understanding concerning the product to be built
b. Provides information about the structure and dynamics of organizations in which the system is to be deployed
c. Derives system requirements
d. Provides a basis for planning the content for iterations

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 68


Lucélia Viera Mota
Versão 2.0

45. What are two benefits of implementing the business-driven principle collaboration across teams? (02)
a. Increased motivation
b. Integrated business, software and operation teams
c. Increased team productivity
d. Better business and development cohesion

46. In RUP, what does the software development plan contain?


a. Iteration plan
b. Requirements management plan, master validation plan, quality test plan, ad risk management plan
c. Problem resolution plan, product acceptance plan, measurement plan, risk management plan, and quality
assurance plan
d. Requirements management plan, product metrics, and software test assurance plan

47. Which statement is true about delivery processes?


a. They represent a complete end-to-end lifecycle
b. They must contain capability patterns
c. They are only useful to publish a process
d. They replace activities an tasks

48. What are three purposes of the business modeling discipline? (03)
a. Ensures a common understanding concerning the product be built
b. Provides information about the structure and dynamics of organizations in which the system is to be deployed
c. Derives system requirements
d. Provides a basis for planning the content for iterations

49. What is a benefit of balancing competing stakeholder priorities?


a. Achievement of business value
b. Reduction in custom development
c. A better understanding of what assets can be leveraged
d. Ability to understand and prioritize business and user needs

50. What are three key principles of business-driven development? (03)


a. Adapt the artifacts
b. Demonstrate value iteratively
c. Collaborate across teams
d. Focus continuously on quality

51. Why is it important to balance competing stakeholder priorities?


a. To optimize the business value
b. To obtain early requirements agreement
c. To better architect the system
d. To minimize cost

52. What is the key benefit of implementing the principle of elevating of abstraction?
a. better requirements
b. More rapid code access
c. Modeling the architecture
d. Reduce complexity

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 69


Lucélia Viera Mota
Versão 2.0
Gabarito
1 A 27 C
2 C, E 28 A, B, C, D
3 B 29 A
4 E 30 A, C, D
5 A, C, D 31 A,B,C
6 C 32 A, C, D, E
7 C 33 A, D
8 C 34 D
9 B 35 A, C, D
10 A, B, C 36 D
11 A, C, D, E 37 B, D
12 A, B, C 38 A, B, D
13 A, B, C, D 39 A
14 B 40 D
15 B, C, E 41 C
16 A, E 42 A, B, C
17 A, B, D, E 43 A
18 A, D 44 B, C, D
19 A, C, D, E 45 C, D
20 C 46 C
21 A, B, C, D 47 A
22 A, B, D, E 48 B, C, D
23 A, C, D 49 B
24 A, B, D, E 50 B, C, D
25 C, D, E 51 A
26 A,B,C 52 D

Bluestar Ensino e Tecnologia – www.bluestar.inf.br (61) 3347-9255 70


Lucélia Viera Mota

Você também pode gostar