Aula 01

Aula 01
Caixa Econômica Federal - CEF (Técnico

Bancário - TI) Passo Estratégico de
Conhecimentos Específicos - 2024
(Pós-Edital)
Autor:
Fernando Pedrosa Lopes
12 de Março de 2024
85764731518 - Anna Clara nascimento

Aula 01
PROCESSO UNIFICADO (RUP)

Sumário
Conteúdo ...................................................................................................................................... 2
ANÁLISE ESTATÍSTICA ..................................................................................................................... 2
Glossário de termos ..................................................................................................................... 3
Roteiro de revisão ........................................................................................................................ 6
Introdução .................................................................................................................................... 6
Características .............................................................................................................................. 7
Estrutura e "Gráfico das Baleias" ................................................................................................. 8
Fases ........................................................................................................................................... 10
Iterações ..................................................................................................................................... 14
Disciplinas ................................................................................................................................... 16
Boas Práticas .............................................................................................................................. 27
Questões Estratégicas ............................................................................................................... 33
Questionário de revisão e aperfeiçoamento ............................................................................. 39
Perguntas.................................................................................................................................... 39
Perguntas e Respostas ............................................................................................................... 40
Lista de Questões Estratégicas ................................................................................................... 42
Gabaritos .................................................................................................................................... 45
Caixa Econômica Federal - CEF (Técnico Bancário - TI) Passo Estratégico de Conhecimentos Específicos - 2024 (Pós-Edit
www.estrategiaconcursos.com.br

. Túlio Lages
Aula 00
Aula 01
CONTEÚDO
RUP. Conceitos. Estrutura. Boas Práticas. Fases, marcos iterações. Disciplinas, atividades, papeis
e artefatos.
ANÁLISE ESTATÍSTICA
Inicialmente, convém destacar o percentual de incidência do assunto, dentro da disciplina

Engenharia de Software em concursos/cargos similares. Quanto maior o percentual de cobrança
de um dado assunto, maior sua importância.
Obs.: um mesmo assunto pode ser classificado em mais de um tópico devido à

multidisciplinaridade de conteúdo.
Relevância na disciplina em
Assunto
concursos similares
UML 11.0 %
Processos de Software - Desenvolvimento Ágil 8.4 %
Engenharia de Requisitos 8.2 %
Teste de Software 6.7 %
Métricas de Software 5.1 %
Desenvolvimento de Software 4.6 %
Inteligencia Artificial 4.6 %
Processos de Software 4.6 %
Orientação a Objetos 4.5 %
Gestão de Projetos em Engenharia de Software 3.6 %
Qualidade de Software 3.4 %
Metodologia de desenvolvimento de software 2.5 %
Gerência de Configuração 1.9 %
Geoprocessamento em Engenharia de Software 1.6 %

. Túlio Lages
Aula 00
Aula 01
Prototipação 1.2 %
Conceitos Básicos em Engenharia de Software 0.7 %
Análise Estruturada 0.6 %
Ferramentas CASE 0.4 %
Ferramentas de Desenvolvimento de Software 0.4 %
Software livre 0.3 %
Manutenção de Software 0.1 %
Análise Essencial 0.1 %
Web 2.0 0.1 %
Portal Web 0.1 %
Refatoração 0.1 %
Engenharia da Informação 0.1 %
GLOSSÁRIO DE TERMOS
Faremos uma lista de termos que são relevantes ao entendimento do assunto desta aula. Caso
tenha alguma dúvida durante a leitura, esta seção pode lhe ajudar a esclarecer.
RUP: Sigla de Rational Unified Process (Processo Unificado da Rational). É um framework de

desenvolvimento de software que enfatiza um ciclo de vida iterativo e incremental.
Gráfico das baleias: Representação gráfica das fases e disciplinas no RUP. Chamado de "gráfico
das baleias" por causa de sua aparência visual, o gráfico mostra como as disciplinas são
enfatizadas ao longo das quatro fases do RUP.
Dimensão estática: Representa as disciplinas (ou fluxos de trabalho) que são aplicadas durante
o desenvolvimento de um projeto no RUP.
Dimensão dinâmica: Representa as fases do ciclo de vida e suas iterações de um projeto no RUP.
Fase de Iniciação ou Concepção: A primeira fase do RUP, onde a visão do projeto é definida, os
principais riscos são identificados e uma solução viável é proposta.

. Túlio Lages
Aula 00
Aula 01
Fase de Elaboração: A segunda fase do RUP, onde a arquitetura do sistema é definida e os riscos
são mitigados.
Fase de Construção: A terceira fase do RUP, onde o produto é construído, com todos os recursos
completos e integrados.
Fase de Transição: A quarta e última fase do RUP, onde o produto é transferido para seus
usuários finais.
Iteração: Uma passagem pelas disciplinas técnicas dentro do ciclo de vida de desenvolvimento
do RUP que resulta em um release (interno ou externo) de um sistema executável.
Marco: Um ponto importante no tempo que indica a conclusão de uma fase.
Disciplina: Uma categoria de tarefas relacionadas que acontecem ao longo das fases do RUP.
Atividade: Uma unidade de trabalho que um indivíduo ou equipe pode ser encarregado de
realizar.
Papel: Uma definição das responsabilidades e comportamentos esperados de um indivíduo ou

equipe.
Artefato: Um resultado tangível e verificável de uma atividade.
Disciplina de Modelagem de Negócios: Realiza a modelagem dos aspectos de negócios de um

sistema.
Disciplina de Requisitos: Disciplina que faz a definição dos requisitos do sistema.
Disciplina de Análise e Projeto: Disciplina realiza a modelagem da arquitetura do sistema.
Disciplina de Implementação: Disciplina que faz a programação do sistema.
Disciplina de Testes: Disciplina que envolve a verificação e validação do sistema.
Disciplina de Implantação: Disciplina que envolve a distribuição do sistema no seu ambiente-

alvo.
Disciplina de Gestão de Configuração e Mudanças: Envolve o gerenciamento de versões do

sistema e de mudanças.

. Túlio Lages
Aula 00
Aula 01
Disciplina de Gestão de Projetos: Envolve o planejamento, acompanhamento e controle de

projetos.
Disciplina de Ambiente: Envolve a configuração do ambiente de desenvolvimento e do próprio

processo a ser utilizado.
Modelo de Domínio: Representação visual das principais classes ou conceitos do sistema e seus
relacionamentos.
Documento de Requisitos: Documento que captura os requisitos do sistema de forma completa

e precisa.
Modelo de Casos de Uso: Diagrama que mostra as interações entre os atores e o sistema em
termos de casos de uso.
Modelo de Design: Representação visual da arquitetura de software do sistema.
Teste Unitário: Procedimento que valida a funcionalidade de um componente de software

específico.
Componente: Uma unidade de software modular, independente e substituível que cumpre um

conjunto claro de responsabilidades.
Plano de Teste: Documento que descreve o escopo, a abordagem, os recursos e o cronograma

de atividades de teste.
Caso de Teste: Conjunto de condições sob as quais um tester determinará se um sistema de

aplicação está funcionando corretamente.
Controle de Versão: Processo de gerenciar diferentes versões de artefatos de software.
Controle de Mudança: Processo de gerenciar alterações nos requisitos de um sistema.
Auditoria de Configuração: Verificação independente de que os produtos de um projeto são

identificados e que as mudanças são controladas.
Item de Configuração: Parte do produto que é tratada como uma unidade para fins de
gerenciamento de configuração.
Solicitação de Mudança (Change Request): Pedido formal para alterar algum aspecto do
sistema.

. Túlio Lages
Aula 00
Aula 01
Plano de Desenvolvimento de Software: Documento que descreve o escopo, a abordagem, os

recursos e o cronograma de um projeto de software.
Caso de Desenvolvimento: Descrição de um cenário de desenvolvimento específico, incluindo os

atores envolvidos e suas interações.
Boas Práticas: Métodos ou técnicas que foram geralmente aceitas como superiores a qualquer
alternativa prática devido aos resultados que foram produzidos.
ROTEIRO DE REVISÃO
A ideia desta seção é apresentar um roteiro para que você realize uma revisão completa do
assunto e, ao mesmo tempo, destacar aspectos do conteúdo que merecem atenção.
Introdução
Processo Unificado (RUP - Rational Unified Process) é uma abordagem de engenharia de software
que fornece um conjunto de melhores práticas, diretrizes e tarefas para projetar e desenvolver
software de alta qualidade. Desenvolvido pela Rational Software Corporation, o RUP é um
framework estruturado, mas altamente adaptável, que utiliza uma abordagem orientada a
objetos e é focada na arquitetura do sistema.
Veja um breve histórico do RUP:
1980s - A ideia de um processo unificado começou a ser formada na década de 1980, quando a
Rational Software Corporation foi fundada por Paul Levy e Mike Devlin. Durante esse tempo, a
empresa focou no desenvolvimento de ferramentas para modelagem orientada a objetos.
1990s - Durante a década de 1990, a Rational Software começou a consolidar as melhores

práticas e experiências em um processo de software unificado. Isso foi inspirado pelo trabalho
de três principais metodologistas de software - Grady Booch, James Rumbaugh e Ivar Jacobson -
que desenvolveram as notações de modelagem orientadas a objetos que mais tarde se tornariam
a base para a UML (Unified Modeling Language).

. Túlio Lages
Aula 00
Aula 01
2003 - A Rational Software Corporation foi adquirida pela IBM, que continuou a desenvolver e
promover o RUP como parte de seu portfólio de ferramentas e processos de desenvolvimento
de software. Durante este tempo, o RUP começou a ser implementado em uma escala mais
ampla em projetos de desenvolvimento de software.
Pós-2010 - Com a popularização das metodologias ágeis (como Scrum e XP), a relevância do RUP
diminuiu, pois é considerado mais pesado e prescritivo. No entanto, ele ainda é usado em
algumas organizações que precisam de um processo mais formal e bem definido, especialmente
em indústrias como aeroespacial e médica, onde o gerenciamento de riscos e a conformidade
regulatória são importantes.
Características
O Processo Unificado é composto por cinco características fundamentais que definem o

funcionamento e filosofia do framework de processos. Veja a seguir.
Iterativo e Incremental:
O RUP é um processo iterativo, isso significa que o desenvolvimento de software é dividido em

vários "miniprojetos" chamados iterações. Cada iteração pode passar por várias disciplinas do
desenvolvimento de software: requisitos, análise, design, implementação e teste. Isso permite
que o projeto receba feedback regular e que as mudanças sejam feitas ao longo do processo de
desenvolvimento, em vez de esperar até o final. Isso também permite que as equipes lidem
melhor com a mudança, pois as revisões podem ser planejadas para futuras iterações. A
abordagem incremental significa que cada iteração entrega uma parte do sistema totalmente
funcional, permitindo que a funcionalidade seja construída e ampliada ao longo do tempo.
Guiado por Casos de Uso:
Casos de uso descrevem como os usuários finais irão interagir com o sistema e quais serão os
resultados dessas interações. Esses casos de uso orientam o desenvolvimento em RUP, servindo
como a base para o planejamento de iteração, a definição de requisitos, o design e o teste. Além
disso, eles ajudam a garantir que o software finalizado atenda às necessidades dos usuários e
fornecem uma maneira de comunicar efetivamente os requisitos do sistema entre as equipes de
projeto.
Centrado na Arquitetura:

. Túlio Lages
Aula 00
Aula 01
No RUP, a arquitetura do software é a peça central do projeto. A arquitetura define a estrutura

e organização do sistema, incluindo componentes de software, suas propriedades externas e
seus relacionamentos com outros softwares e sistemas. A visão da arquitetura do sistema é
fundamental e a qualidade do software depende fortemente da qualidade da arquitetura.
Orientado a Objetos:
O RUP utiliza uma abordagem de desenvolvimento orientada a objetos. Isso significa que o
software é dividido em "objetos" que representam entidades do mundo real. Esses objetos têm
seus próprios atributos (dados) e métodos (comportamentos). Esta abordagem facilita a
modelagem e a compreensão do sistema, pois reflete a maneira como vemos e interagimos com
o mundo.
Planejado por Riscos:
O RUP é orientado a riscos, o que significa que os riscos são identificados e mitigados o mais
cedo possível no ciclo de vida do projeto. Isso pode incluir riscos técnicos (como a adoção de uma
nova tecnologia), riscos de projeto (como atrasos no cronograma) e riscos de negócios (como
mudanças no mercado). Em cada iteração, a priorização de atividades é feita com base na
mitigação dos maiores riscos.
Estrutura e "Gráfico das Baleias"
O "Gráfico das Baleias" é uma representação visual do RUP que ilustra a natureza iterativa e
incremental do processo e o foco em diferentes disciplinas ao longo do ciclo de vida do projeto.
Veja sua representação:

. Túlio Lages
Aula 00
Aula 01
O gráfico é dividido em quatro fases principais de desenvolvimento de software: Concepção (ou

Iniciação), Elaboração, Construção e Transição. Cada fase é representada como uma coluna
vertical no gráfico.
Cada uma dessas fases é composta por várias iterações. As iterações são representadas como
seções horizontais dentro de cada coluna. Isso demonstra a natureza iterativa do RUP, onde cada
iteração passa por todas as fases do desenvolvimento de software.
Ao final de cada fase existe uma linha pontilhada que delimita o Marco daquela fase. Um marco
se refere a um evento significativo ou um ponto no tempo que marca uma mudança importante
ou um estágio de progresso no projeto. Os marcos são usados para monitorar o progresso do
projeto e garantir que ele está se movendo na direção certa. Cada fase do RUP tem um marco
específico.
Além disso, ao longo do gráfico, você consegue ver várias disciplinas ou fluxos de trabalho que
ocorrem em cada fase do processo. As disciplinas incluem Modelagem de Negócios, Requisitos,
Análise e Design, Implementação, Teste e Implantação. Estas são representadas como linhas
onduladas que atravessam o gráfico, dando a aparência de "baleias".
A área "pintada" de cada disciplina representa o nível de esforço que é esperado para cada uma
delas em diferentes pontos do projeto. Por exemplo, você pode ver que a disciplina de Requisitos
é mais proeminente durante as fases de Iniciação e Elaboração, enquanto a Implementação e o
Teste são mais proeminentes durante a fase de Construção.

. Túlio Lages
Aula 00
Aula 01
Finalmente, por convenção, costumamos dividir o gráfico em dois eixos ou "dimensões":
• Eixo Dinâmico: visto na horizontal, expresso em termos de fases, marcos e iterações.

• Eixo Estático: visto na vertical, expresso em termos de disciplinas e suas atividades, papeis
e artefatos.
Para entender o RUP, precisamos estudar os principais conceitos que compõem o framework de
processos. São os conceitos de Fases e Iterações, Disciplinas/Fluxo de Atividades,
Atividades/Tarefas, Artefatos/Produtos de Trabalho e Papéis.
Fases
Fases no Processo Unificado referem-se a grandes segmentos no ciclo de vida de

desenvolvimento de um software. O RUP divide o ciclo de desenvolvimento em quatro fases
distintas, cada uma terminando com um marco bem definido. As quatro fases são: Iniciação
(sinônimo de Concepção), Elaboração, Construção e Transição.
A figura a seguir resume, de forma geral, os objetivos de cada fase:
Concepção Elaboração Construção Transição
Assegurar
Desenvolver
que os
de modo
Estabelecer principais Disponibilizar
iterativo e
o escopo, e riscos foram o Software
incremental
estimar diminuídos para seus
um produto
custos e e definir usuários
completo
riscos uma finais
para a
arquitetura
Transição
executável

. Túlio Lages
Aula 00
Aula 01
Fase de Iniciação
A Fase de Iniciação, também conhecida como Concepção, é a primeira fase no Processo

Unificado. Esta fase é sobre definir a visão e o escopo do projeto e estabelecer um caso de
negócio sólido para o desenvolvimento do sistema.
Objetivos:
• Estabelecer o escopo e a visão do sistema: Durante esta fase, a equipe de desenvolvimento

tenta obter uma compreensão clara do sistema que será desenvolvido e do problema que está
sendo resolvido. Eles identificam os principais requisitos e restrições do sistema, e estabelecem
uma visão geral de como o sistema funcionará.
• Avaliar a viabilidade do projeto: A equipe deve avaliar se o projeto é tecnicamente e
financeiramente viável. Isso geralmente envolve uma análise inicial de custos, benefícios, riscos
e prazos.
• Identificar os principais riscos: Os riscos iniciais que podem afetar o sucesso do projeto são
identificados e planos são feitos para mitigá-los.
• Estabelecer um caso de negócios (business case): Um caso de negócios é desenvolvido para
justificar o investimento no projeto. Ele deve identificar os benefícios esperados, os custos
associados e um cronograma de retorno do investimento.
Principais Documentos:
• Documento de Visão: Fornece uma visão geral do sistema proposto, incluindo os principais
recursos e restrições, as necessidades dos usuários e partes interessadas, e uma visão geral de
alto nível do sistema planejado.
• Plano de Negócios ou Caso de Negócios: Detalha o caso de negócios para o projeto, incluindo
uma análise de custo-benefício e um plano para a realização dos benefícios.
• Avaliação de Risco Inicial: Identifica os riscos principais associados ao projeto e propõe
estratégias para gerenciá-los.
• Plano de Projeto Inicial: Define o escopo do projeto, os recursos necessários, a programação e
os marcos.
Marco:
O marco ao final da fase de iniciação é chamado de Marco de Objetivos do Ciclo de Vida. Este
marco é alcançado quando o caso de negócios é sólido, a visão e o escopo do projeto são
entendidos, os principais riscos foram identificados e um plano de projeto inicial foi estabelecido.
Uma decisão é tomada neste ponto sobre se deve prosseguir com a fase de elaboração.

. Túlio Lages
Aula 00
Aula 01
Fase de Elaboração
A fase de Elaboração é a segunda fase do Processo Unificado e, nela, o objetivo principal é

estabelecer uma base sólida para a arquitetura do sistema, detalhar as necessidades e os
requisitos do usuário, e mitigar os principais riscos do projeto.
Objetivos:
• Desenvolver uma compreensão mais aprofundada dos requisitos do sistema: Os casos de uso
são desenvolvidos para detalhar as interações do usuário com o sistema e os requisitos são
completamente detalhados.
• Estabelecer a arquitetura do sistema: A estrutura básica do sistema é estabelecida, incluindo
a identificação e a descrição dos principais componentes e a forma como eles interagem.
• Mitigar os principais riscos: Os riscos identificados na fase de iniciação são abordados, e
estratégias para a mitigação de riscos são implementadas. Isso pode incluir a realização de
protótipos para testar tecnologias ou abordagens incertas.
• Desenvolver um plano de projeto detalhado para as fases de construção e transição: Com
uma compreensão mais clara do sistema, é possível desenvolver um plano mais preciso e
detalhado para as fases restantes do projeto.
• Modelo de Casos de Uso: Fornece detalhes completos dos casos de uso que foram
identificados, incluindo as interações dos usuários com o sistema.
• Especificação de Requisitos de Software: Detalha os requisitos completos para o sistema,
incluindo funcionalidades, desempenho, design e atributos do sistema.
• Descrição da Arquitetura de Software: Descreve a arquitetura do sistema, incluindo os
principais componentes e suas interações.
• Plano de projeto revisado: Este é um plano detalhado para as fases restantes do projeto,
incluindo estimativas de tempo e recursos.
Marco:
O marco ao final da fase de Elaboração é chamado de Marco de Arquitetura do Ciclo de Vida.

Este marco é alcançado quando a arquitetura do sistema está estabelecida e os principais riscos
foram mitigados. Uma decisão é tomada neste ponto sobre se deve prosseguir para a fase de
construção.
Fase de Construção

. Túlio Lages
Aula 00
Aula 01
A fase de Construção é a terceira fase no Processo Unificado e, muitas vezes, é a mais longa. O
principal objetivo desta fase é construir o produto do software.
Objetivos:
• Desenvolver o sistema completo: Isso envolve a codificação, compilação, integração e teste de

todos os componentes do sistema.
• Preparar para a implantação: Incluir a preparação de manuais de usuário, planos de
treinamento e procedimentos de instalação.
• Minimizar os custos de desenvolvimento: Os custos são minimizados através da otimização
dos recursos e da eficiência na codificação e teste.
Os principais documentos produzidos durante a fase de construção incluem:
• O Software: Este é o produto real, o software que foi escrito e compilado.

• Testes e Relatórios de Resultados: Estes incluem todos os testes que foram realizados e os
resultados deles. Isso também pode incluir relatórios de bugs e problemas encontrados.
• Manual do Usuário: É um guia para os usuários finais sobre como usar o software.
• Plano de Implantação: Este documento detalha como o software será implantado no ambiente
do usuário, incluindo qualquer configuração necessária e planos de treinamento para os
usuários.
Marco:
O marco ao final da fase de construção é o Marco de Capacidade Operacional Inicial. Este marco
é alcançado quando o software está pronto para ser implantado no ambiente do usuário. O
software foi completamente testado e os manuais de usuário e planos de treinamento estão
prontos. Uma decisão é tomada neste ponto sobre se o software está pronto para ser lançado
para a fase de transição.
Fase de Transição
A fase de Transição é a fase final do Processo Unificado. Durante esta fase, o software é entregue
aos usuários finais. O objetivo principal é garantir que o software atenda às necessidades do
usuário e que qualquer problema ou defeito seja resolvido.
Objetivos:

. Túlio Lages
Aula 00
Aula 01
• Implantação do sistema no ambiente do usuário: Envolve a instalação do software no

ambiente do usuário, a configuração conforme necessário e a garantia de que o software está
funcionando corretamente.
• Treinamento dos usuários finais: Compreende a condução de sessões de treinamento para os
usuários finais, a fim de garantir que eles saibam como usar o software.
• Avaliação do sistema: O sistema é avaliado para garantir que atenda às necessidades e
requisitos dos usuários.
• Resolução de problemas e defeitos: Qualquer problema ou defeito encontrado pelos usuários
é resolvido.
• Manual de Operação: Fornece instruções detalhadas sobre como operar o sistema em um

ambiente de produção.
• Relatório de Avaliação do Sistema: Fornece uma avaliação do desempenho do sistema em um
ambiente de produção e se ele atende aos requisitos do usuário.
• Relatórios de Problemas e Soluções: Documentam quaisquer problemas encontrados pelos
usuários, bem como as soluções ou correções implementadas.
Marco:
O marco ao final da fase de transição é o Marco de Release de Produto. Este marco é alcançado
quando o software foi entregue, está sendo usado pelos usuários finais e atende às suas
necessidades e requisitos. Além disso, todos os problemas conhecidos foram resolvidos. Neste
ponto, o projeto é considerado completo.
Iterações
Uma iteração é um ciclo de desenvolvimento distinto dentro de uma das quatro fases. Cada
iteração envolve a execução de atividades que abrangem as disciplinas de desenvolvimento de
software, como requisitos, design, implementação e teste, para entregar uma versão
incrementada do sistema.
O RUP é caracterizado como um processo iterativo e incremental, o que significa que o

desenvolvimento do software é dividido em várias iterações menores. Cada iteração resulta em
um incremento do sistema que possui funcionalidade adicional ou melhorada em comparação
com o incremento anterior.

. Túlio Lages
Aula 00
Aula 01
Durante uma iteração, a equipe de desenvolvimento:
• Identifica e detalha os requisitos para essa iteração

• Projeta o sistema para atender a esses requisitos
• Implementa o design na forma de código de software
• Testa o sistema para garantir que ele atenda aos requisitos
O número de iterações em cada fase pode variar dependendo das necessidades do projeto.
Alguns projetos podem ter muitas iterações curtas, enquanto outros podem ter algumas
iterações mais longas.
Cada iteração é, idealmente, um miniprojeto por si só, incluindo todas as tarefas necessárias para
entregar um incremento do produto final: planejamento, requisitos, análise e design,
implementação, teste e avaliação.

. Túlio Lages
Aula 00
Aula 01
A principal vantagem do enfoque iterativo e incremental é que ele permite um desenvolvimento

de software mais flexível e a capacidade de incorporar feedback e mudanças mais rapidamente,
já que as lições aprendidas em uma iteração podem ser aplicadas nas próximas.
Disciplinas
Uma disciplina se refere a uma categoria de atividades que são relacionadas e que juntas
alcançam um grande objetivo no processo de desenvolvimento do software. Cada disciplina
abrange várias atividades que são realizadas durante as várias iterações em todas as quatro fases
do projeto.
As disciplinas no RUP são divididas em disciplinas de engenharia e disciplinas de suporte.
Disciplinas de engenharia:
• Modelagem de Negócios: Foca na compreensão do contexto de negócios e na criação de um

modelo de negócios que descreva a estrutura e os processos do negócio.
• Requisitos: Envolve a coleta, análise e gerenciamento dos requisitos do sistema.
• Análise e Design: Envolve a transformação dos requisitos em uma arquitetura e design do
sistema.
• Implementação: Envolve a codificação do sistema com base na arquitetura e design.
• Teste: Compreende a verificação de que o sistema atende aos requisitos especificados.
• Implantação: Inclui a preparação do software para entrega e entrega ao cliente ou usuário final.
Disciplinas de suporte:
• Gerenciamento de Configuração e Mudanças: Abrange o gerenciamento de alterações no

software e na sua documentação.
• Gerenciamento de Projeto: Envolve o planejamento, monitoramento e controle de recursos
para atingir os objetivos do projeto.
• Ambiente: Faz a provisão de software e hardware adequados para a equipe de
desenvolvimento.
A seguir, vamos ver as disciplinas em mais detalhes. Em cada uma delas, veremos o seu objetivo
e principais papéis, atividades e artefatos. Note que não iremos listar todos os papéis, atividades
e artefatos de cada disciplina, pois são, literalmente, centenas, mas apenas os mais importantes
ou significativos para o entendimento delas.

. Túlio Lages
Aula 00
Aula 01
Por exemplo, a figura a seguir mostra um recorte da disciplina de Requisitos. Nela, podemos
observar um papel que executa uma atividade e que gera um artefato (produto de trabalho ao
final). Essa estrutura de "quem faz o quê" aparece detalhada em cada disciplina.
Modelagem de Negócios
A disciplina de Modelagem de Negócios tem como objetivo entender o contexto e a estrutura do

negócio para o qual o sistema de software está sendo desenvolvido. Envolve a identificação dos
processos de negócios, dos stakeholders e dos requisitos do negócio, a fim de desenvolver um
modelo que descreva como o negócio opera.
Papéis:
• Analista de Processo de Negócios: Este é o principal papel envolvido na Modelagem de

Negócios. O Analista de Negócios trabalha para entender os processos de negócios, identificar
problemas e oportunidades e definir os requisitos do negócio.
• Stakeholder: Os stakeholders são qualquer pessoa ou grupo que tenha um interesse no
negócio. Eles fornecem informações úteis sobre os processos de negócios e os requisitos.
Atividades:
• Identificação de processos de negócios: Mapeamento dos processos de negócios atuais e a

identificação de áreas de melhoria.

. Túlio Lages
Aula 00
Aula 01
• Definição de requisitos do negócio: Coleta e a definição dos requisitos do negócio com base
nos processos de negócios identificados.
• Desenvolvimento do modelo de negócios: Criação de um modelo que descreva os processos
de negócios e os requisitos.
Artefatos:
• Modelo de Negócios: Descreve os processos de negócios e os requisitos do negócio.

• Diagramas de Processos de Negócios: Diagramas que visualizam os processos de negócios e
mostram como as várias partes do negócio se relacionam entre si.
• Requisitos de Negócios: Documentos que detalham os requisitos do negócio que o sistema de
software deve atender.
• Modelo de Domínio: Descreve os objetos de negócio e como eles se relacionam.
A figura a seguir ilustra um exemplo de Modelo de Domínio:
Requisitos
A disciplina de Requisitos é focada em entender o que o sistema de software precisa fazer para
atender às necessidades e expectativas dos usuários e stakeholders. Ela envolve a coleta, análise,
documentação e validação dos requisitos do sistema.
Papéis:
• Analista de Sistemas: Levanta os requisitos e estrutura o modelo de casos de uso.

• Especificador de requisitos: Detalha as especificações de casos de uso.
Atividades:

. Túlio Lages
Aula 00
Aula 01
• Elicitação de Requisitos: Coleta de requisitos de várias fontes, como stakeholders, documentos

existentes, regulamentações e padrões do setor.
• Análise de Requisitos: Compreensão e clarificação dos requisitos coletados. Os requisitos
podem precisar ser refinados ou detalhados mais para garantir que sejam completos,
consistentes e não ambíguos.
• Documentação de Requisitos: Criação de uma documentação clara e concisa dos requisitos que
podem ser entendidos por todos os membros da equipe de projeto.
• Validação de Requisitos: Revisão dos requisitos com os stakeholders para garantir que os
requisitos documentados atendam às suas necessidades e expectativas.
Artefatos:
• Documento de Visão: Fornece uma visão geral de alto nível do sistema, incluindo os principais
recursos, as necessidades do usuário, as restrições e as oportunidades de negócio.
• Especificação de Requisitos de Software: Detalha todos os requisitos do sistema, incluindo
requisitos funcionais (o que o sistema deve fazer) e requisitos não funcionais (como o sistema
deve ser, por exemplo, desempenho, segurança, usabilidade).
• Modelos de Caso de Uso: Diagramas que descrevem as interações entre os usuários (ou outros
sistemas) e o sistema que está sendo desenvolvido. Cada caso de uso representa uma
funcionalidade específica que o sistema deve fornecer.
• Suplemento do Caso de Uso: Fornece detalhes adicionais para cada caso de uso, descrevendo
o fluxo de interação, pré-condições, pós-condições, regras de negócios, etc.
A figura a seguir ilustra um exemplo de Modelo de Casos de Uso:
Análise e Design (Análise e Projeto)
A disciplina de Análise e Projeto é onde os requisitos coletados na fase de Requisitos são

transformados em uma arquitetura de software. O foco está em como o sistema irá cumprir os

. Túlio Lages
Aula 00
Aula 01
requisitos, incluindo a estrutura geral do sistema, os principais componentes de software e suas

interações.
Papéis:
• Arquiteto de Software: Responsável por definir a arquitetura geral do sistema, incluindo a

identificação e o design dos principais componentes e suas interações.
• Designer de Software ou Projeto: Responsável por detalhar o design de componentes
individuais, incluindo a definição de interfaces e a especificação de comportamento.
Atividades:
• Análise de Requisitos de Software: Revisão detalhada dos requisitos coletados para entender
completamente o que precisa ser construído.
• Definição da Arquitetura do Sistema: Criação de uma visão geral de alto nível do sistema,
incluindo os principais componentes e suas interações.
• Projeto Detalhado: Especificação detalhada de cada componente do sistema, incluindo a
definição de interfaces e a especificação de comportamento.
• Revisão de Design: Revisão do design proposto para garantir que ele atenda aos requisitos e
que seja robusto, escalável e manutenível.
Artefatos:
• Modelo de Design: Diagrama ou conjunto de diagramas que representam a arquitetura geral

do sistema, incluindo os principais componentes e suas interações.
• Especificações de Design: Documentos detalhados que descrevem o design de componentes
individuais, incluindo a definição de interfaces e a especificação de comportamento.
• Diagramas de Classe e Sequência: Diagramas UML usados para representar o design do
sistema. Diagramas de classe representam a estrutura do sistema e as relações entre as classes,
enquanto os diagramas de sequência representam as interações entre as classes ao longo do
tempo.
A figura a seguir ilustra um exemplo de Modelo de Design:

. Túlio Lages
Aula 00
Aula 01
Implementação
A disciplina de Implementação é a etapa na qual a arquitetura de software e o design detalhado

são transformados em código de software. A codificação, a realização de testes unitários, a
integração e a correção de erros são todas tarefas importantes nesta disciplina.
Papéis:
• Desenvolvedor: O Desenvolvedor é o principal papel na disciplina de Implementação. Ele é

responsável por codificar, testar e corrigir erros no software.
Atividades:
• Codificação: A atividade de codificação transforma o design do software em código usando a

linguagem de programação escolhida.
• Teste Unitário (também conhecido como Teste do Desenvolvedor no RUP): Os
desenvolvedores realizam testes unitários para verificar se as partes individuais do software
funcionam como esperado.
• Integração: Na atividade de integração, as partes individuais do software são combinadas para
criar o sistema completo. Isso também inclui a realização de testes de integração para garantir
que todas as partes do software funcionem juntas corretamente.

. Túlio Lages
Aula 00
Aula 01
Artefatos:
• Código Fonte: O Código Fonte é o resultado da atividade de codificação. Inclui todos os arquivos
de código fonte que compõem o software.
• Testes Unitários: Os Testes Unitários são scripts de teste específicos que verificam a corretude
de partes individuais do código.
• Componentes Integrados: Os Componentes Integrados são o resultado da atividade de
integração. Isso inclui o software totalmente integrado pronto para testes de sistema e
implantação.
Testes
A disciplina de Testes é dedicada a verificar e validar que o sistema de software atende aos
requisitos definidos e funciona como esperado. A atividade de testes ajuda a identificar
problemas e defeitos no software para que possam ser corrigidos antes do lançamento.
Papéis:
• Analista de Testes: Responsável por elaborar o plano de testes.

• Projetista de Testes: Responsável por projetar os testes.
• Testador: O Testador é responsável por implementar e executar testes, documentar os
resultados dos testes e reportar quaisquer defeitos encontrados.
Atividades:
• Planejamento de Testes: Durante o planejamento de testes, o testador define a estratégia de

testes, incluindo quais tipos de testes serão realizados, que ferramentas serão usadas e como
os resultados serão avaliados.
• Criação de Casos de Teste: Os casos de teste são desenvolvidos com base nos requisitos do
sistema. Cada caso de teste é uma situação específica que o software deve ser capaz de lidar.
• Execução de Testes: Durante a execução de testes, o testador aplica os casos de teste ao
software e registra os resultados.
• Registro de Defeitos: Se um caso de teste falhar, um defeito é registrado. O registro de defeitos
inclui informações sobre o problema, incluindo como ele pode ser reproduzido.
Artefatos:
• Plano de Teste: Documento que descreve a estratégia de testes. Ele inclui informações sobre
quais tipos de testes serão realizados, que ferramentas serão usadas e como os resultados
serão avaliados.

. Túlio Lages
Aula 00
Aula 01
• Casos de Teste: São descrições específicas de uma situação que o software deve ser capaz de
lidar.
• Resultados de Testes: Registro das passagens e falhas para cada caso de teste.
• Relatórios de Defeitos: Registro de quaisquer problemas encontrados durante o teste. Eles
incluem informações sobre o problema e como ele pode ser reproduzido.
Implantação
A disciplina de Implantação abrange todas as atividades necessárias para tornar o sistema

disponível para os usuários finais. Isso envolve preparação para a implantação, embalagem do
produto, distribuição, instalação e suporte ao usuário.
Papéis:
• Gerente de Implantação: O Gerente de Implantação é responsável pela coordenação de todas

as atividades de implantação, incluindo planejamento, embalagem, distribuição e instalação do
sistema."
• Desenvolvedor do curso: Responsável por elaborar materiais de treinamento.
Atividades:
• Planejamento de Implantação: Nesta atividade, a equipe de implantação define um plano para

como o sistema será embalado, distribuído e instalado.
• Build do Produto: Envolve a criação de uma versão do sistema que pode ser facilmente
distribuída e instalada pelos usuários finais.
• Distribuição do Produto: O produto embalado é então distribuído para os usuários finais.
• Instalação do Produto: A equipe de implantação auxilia os usuários na instalação do sistema
em seu ambiente.
• Suporte ao Usuário: Após a instalação, a equipe de implantação fornece suporte contínuo aos
usuários para resolver quaisquer problemas que possam ter com o sistema.
Artefatos:
• Plano de Implantação: Documento que detalha como o sistema será embalado, distribuído e
instalado.
• Build do Produto: É uma versão do sistema que foi preparada para distribuição e instalação.
• Manual do Usuário e Materiais de Treinamento: O Manual do Usuário é um documento que
fornece instruções sobre como instalar e usar o sistema.

. Túlio Lages
Aula 00
Aula 01
• Relatórios de Suporte: São criados para documentar quaisquer problemas que os usuários
encontram ao usar o sistema e como esses problemas foram resolvidos.
A disciplina de Implantação é a última disciplina "de Engenharia" do RUP. As próximas disciplinas

são consideradas disciplinas "de Suporte/Apoio" e focam mais no gerenciamento do processo do
que na sua execução propriamente dita.
Gestão de Configuração e Mudanças
A disciplina de Gestão de Configuração e Mudanças lida com a identificação de configurações,

controle de versões, controle de mudanças e auditorias de configuração.
Veja, graficamente, ideia geral por trás desta disciplina:
Papéis:
• Gerente de Configuração: Configurar ambiente de CM, Estabelecer políticas de CM

• Gerente de Mudanças: Estabelecer processo de controle de mudanças. Configurar ou recusar
solicitações de mudanças.
Atividades:
• Identificação de Configuração: Nesta atividade, os itens de configuração são identificados e

documentados. Um item de configuração é um artefato que é criado durante o processo de
desenvolvimento e que deve ser gerenciado e controlado.
• Controle de Versões: A atividade de rastrear e controlar as diferentes versões de um item de
configuração.

. Túlio Lages
Aula 00
Aula 01
• Controle de Mudanças: Atividade de gerenciar solicitações de mudança no software. Isso inclui

a avaliação da solicitação de mudança, a decisão sobre se a mudança deve ser implementada,
e a coordenação da implementação da mudança.
• Auditoria de Configuração: A auditoria de configuração é a atividade de verificar se os itens de
configuração e as mudanças feitas neles estão em conformidade com os requisitos e
procedimentos especificados.
Artefatos:
• Itens de Configuração: São os artefatos gerenciados e controlados durante o processo de

gestão de configuração. Isso pode incluir código-fonte, artefatos de design, planos de teste, e
documentação.
• Registros de Versão: Documentos que registram as diferentes versões de um item de
configuração.
• Solicitações de Mudança: Documentos que registram uma solicitação para mudar um item de
configuração.
• Relatórios de Auditoria de Configuração: Documentos que registram os resultados de uma
auditoria de configuração.
Gestão de Projetos
A disciplina de Gestão de Projetos é voltada para o planejamento, monitoramento e controle do

projeto de desenvolvimento de software. Ela ajuda a garantir que o projeto seja concluído a
tempo, dentro do orçamento e atenda aos requisitos definidos.
Papéis:
• Gerente de Projeto: O Gerente de Projeto é responsável pelo planejamento, monitoramento e

controle do projeto. Ele coordena a equipe, toma decisões estratégicas e é o principal ponto de
comunicação para todas as partes interessadas do projeto.
Atividades:
• Planejamento do Projeto: No planejamento do projeto, o gerente de projeto define os

objetivos do projeto, estabelece um cronograma, identifica recursos necessários e planeja as
atividades que devem ser realizadas.
• Monitoramento do Projeto: Durante o monitoramento, o gerente de projeto acompanha o
progresso do projeto em relação ao plano. Inclui o acompanhamento do trabalho realizado, do
tempo gasto e dos recursos utilizados.

. Túlio Lages
Aula 00
Aula 01
• Controle do Projeto: No controle do projeto, o gerente de projeto toma medidas para corrigir
quaisquer desvios do plano. Compreende a reprogramação de atividades, a realocação de
recursos ou a negociação de mudanças nos requisitos.
Artefatos:
• Plano de Desenvolvimento de Software: Documento que detalha os objetivos do projeto, as

atividades que serão realizadas, o cronograma e os recursos necessários.
• Relatórios de Status do Projeto: Documentos que fornecem uma visão atualizada do progresso
do projeto. Eles incluem informações sobre o trabalho realizado, o tempo gasto e os recursos
utilizados. ==a2a0d==
• Lista de Riscos: Documentos que identificam potenciais problemas que podem afetar o sucesso
do projeto. Eles incluem uma descrição do risco, a probabilidade de o risco ocorrer e um plano
para mitigar o risco.
Ambiente
A disciplina de Ambiente foca no estabelecimento e manutenção do ambiente de software,

abrangendo a seleção de ferramentas, a configuração de hardware e software, e a criação de
scripts e automatizações para facilitar o trabalho da equipe de desenvolvimento.
Papéis:
• Engenheiro de Processo: O Engenheiro de Processo é responsável por configurar, manter e

melhorar o ambiente de software. Inclui a seleção de ferramentas, a instalação de software e
a criação de scripts para automatizar tarefas.
Atividades:
• Seleção de Ferramentas: Envolve a identificação e escolha das ferramentas que a equipe de

desenvolvimento usará. Pode abranger ferramentas de desenvolvimento de software, sistemas
de controle de versão, ferramentas de teste e ferramentas de gerenciamento de projeto.
• Configuração do Ambiente: Instalação e configuração do hardware e software necessários para
a equipe de desenvolvimento.
• Manutenção do Ambiente: Atualização de ferramentas e a solução de problemas que possam
surgir no ambiente de software.
• Automação de Tarefas: Envolve a criação de scripts e outras automatizações para facilitar o
trabalho da equipe de desenvolvimento. Pode abranger a automação de builds, testes e
implantações.

. Túlio Lages
Aula 00
Aula 01
Artefatos:
• Caso de Desenvolvimento: Descreve o processo de desenvolvimento escolhido para ser

seguido no projeto. A finalidade é capturar o processo adaptado para o projeto individual. É
criado no início da fase de Iniciação e atualizado durante todo o projeto. É o documento que
"configura" o próprio processo de desenvolvimento.
Boas Práticas
As boas práticas do RUP consistem em habilidades que precisam ser desenvolvidas para que o
incremento seja realizado da melhor maneira possível. O objetivo dessas práticas é gerenciar que
a produção seja feita com qualidade, dentro dos prazos, com orçamentos previsíveis e de forma
satisfatória para as partes interessadas.
O RUP possui seis boas práticas: Desenvolver o software iterativamente, Gerenciar requisitos,
Usar arquiteturas baseadas em componentes, Modelar software visualmente, Verificar a
qualidade do software e Controlar as mudanças do software.
Desenvolvimento Iterativo
O desenvolvimento iterativo refere-se à abordagem de dividir o desenvolvimento de software

em várias iterações ou ciclos menores. Cada iteração resulta em uma versão incremental do
software que oferece mais funcionalidade do que a anterior. Essa prática permite que as equipes
se ajustem rapidamente às mudanças e incorporem feedback contínuo durante todo o processo
de desenvolvimento.
Desenvolver iterativamente é uma estratégia de resolução de problemas. Ao invés de seguirmos

um fluxo estritamente sequencial apenas uma vez, como tradicionalmente ocorre no modelo em
Cascata, uma maneira mais flexível (e menos arriscada) de continuar é percorrer várias vezes as
diversas disciplinas de desenvolvimento, ou seja, em várias iterações. Cada vez que você executa
uma iteração, você constrói um melhor entendimento dos requisitos, planeja uma arquitetura
mais robusta, e eleva a organização do desenvolvimento, liberando uma série de
implementações que são gradualmente mais completas.
Veja a comparação entre o modelo em Cascata e o modelo Iterativo e Incremental como no RUP:

. Túlio Lages
Aula 00
Aula 01
Nós costumamos dizer que o modelo em Cascata acumula riscos, enquanto que o modelo
Iterativo diminui os riscos na medida em que você progride.
Gerência de Requisitos
A gerência de requisitos envolve a identificação, documentação, análise e acompanhamento de

requisitos ao longo de todo o ciclo de vida do projeto. O objetivo é garantir que o software atenda
às necessidades do negócio e dos usuários, e que todas as mudanças nos requisitos sejam
gerenciadas efetivamente.
RUP utiliza a técnica de Casos de Uso como ferramenta de elicitação de requisitos. Eles fornecem
uma maneira eficaz de capturar, documentar e organizar os requisitos funcionais de um sistema
de software a partir da perspectiva do usuário final.
Um caso de uso descreve uma sequência de ações que um sistema realiza para produzir um
resultado observável de valor para um ator particular. Um "ator" pode ser um usuário humano,
outro sistema ou até mesmo uma parte do próprio sistema.
Cada caso de uso é uma narrativa que detalha uma situação específica na qual o sistema interage
com um ou mais atores para cumprir um objetivo específico. Isso torna os casos de uso
particularmente úteis para entender como os diferentes usuários irão interagir com o sistema e
quais funcionalidades eles precisarão para realizar suas tarefas.

. Túlio Lages
Aula 00
Aula 01
Veja um exemplo de Diagrama de Caso de Uso:
Arquitetura de Componentes
A arquitetura de componentes se concentra no projeto e na organização do software em

componentes modulares e independentes. Essa abordagem promove a reutilização de
componentes, facilita a manutenção e melhora a compreensão geral do sistema.
Segundo a IEEE, arquitetura é "o conceito de mais alto nível de um sistema em seu ambiente". Ou
seja, a arquitetura de um sistema é a sua organização ou estrutura de componentes significativos
que interagem através de interfaces.
Já componentes são grupos coesos de código fonte ou executável com interfaces e

comportamentos bem definidos.
O RUP utiliza cinco visões arquiteturais para representar diferentes aspectos do sistema. Cada
visão oferece uma perspectiva diferente sobre o sistema e é modelada usando diagramas UML
apropriados. A imagem a seguir mostra as cinco visões:

. Túlio Lages
Aula 00
Aula 01
Visão de Casos de Uso: Esta visão é o ponto de partida para a maioria dos projetos RUP. Ela
descreve a funcionalidade do sistema conforme percebida pelos usuários finais. O modelo de
casos de uso fornece uma visão das funcionalidades do sistema em termos de atores (usuários
ou outros sistemas externos) e seus objetivos (os casos de uso).
Visão Lógica: Esta visão centra-se na funcionalidade do sistema do ponto de vista do

desenvolvedor. Ela fornece uma visão detalhada dos principais elementos do sistema - as classes
e objetos - e suas interações. A visão lógica é normalmente expressa em termos de diagramas de
classes, diagramas de objetos, diagramas de estados e diagramas de sequência.
Visão de Processos: Aqui o foco é desempenho, escalabilidade e throughput do sistema. Ela

descreve aspectos do sistema que estão relacionados à simultaneidade, distribuição, integração
e sincronização de atividades. Normalmente é expressa usando diagramas de atividades e
diagramas de sequência, bem como esquemas e gráficos de desempenho.
Visão de Implementação: Esta visão foca na organização do código, do ambiente de compilação

e dos componentes de software conforme são distribuídos em arquivos e pastas. Ela está
interessada em como o software é fisicamente armazenado em arquivos e diretórios, e é
geralmente representada por diagramas de componentes.
Visão de Implantação: Concentra-se na distribuição de componentes de software em hardware

e mostra como os diferentes componentes de hardware no sistema (computadores, dispositivos,
etc.) se comunicam. Ela é tipicamente representada usando diagramas de implantação.

. Túlio Lages
Aula 00
Aula 01
Essas visões ajudam a abordar diferentes preocupações no projeto do sistema e garantem que o
sistema seja projetado de forma integral, considerando todos os aspectos importantes, desde os
requisitos funcionais até a distribuição e o desempenho do sistema.
Modelagem Visual com UML
A Modelagem Visual com a Linguagem Unificada de Modelagem (UML) ajuda a representar e

comunicar os aspectos do sistema de forma clara e padronizada. Isso inclui a arquitetura do
sistema, o fluxo de processos, os relacionamentos entre os componentes e muito mais.
UML é uma linguagem padrão para a especificação, visualização, construção e documentação

dos artefatos de um sistema de software. Foi criada para fornecer uma maneira padronizada de
visualizar a arquitetura de um sistema, e é usada por profissionais de software para criar
diagramas de sistemas de software.
No RUP, a ideia é utilizar a UML, junto com ferramentas de modelagem e as melhores práticas
do processo para alcançar sucesso. A imagem a seguir ilustra isso:
Verificação de Qualidade
A verificação de qualidade envolve atividades como revisão de código, testes, inspeções e

auditorias para garantir que o software atenda a padrões de qualidade específicos. Elas ajudam

. Túlio Lages
Aula 00
Aula 01
a identificar e corrigir defeitos precocemente, melhorando a confiabilidade e a performance do

software.
Para o RUP, qualidade é definida como “a característica de ter demonstrado a realização da

criação de um produto que atende ou excede os requisitos acordados, conforme avaliado por
medidas e critérios acordados, e que é criado em um processo acordado".
Além disso, o Processo Unificado diferencia as atividades de Controle de Qualidade e Garantia

de Qualidade:
• Controle da Qualidade
• Tem foco no produto, e em encontrar defeitos específicos.
• Preza pelos resultados do seu trabalho.
• Garantia da Qualidade
• Tem foco nos processos e como eles estão sendo executados
• Garante que você está fazendo as coisas de maneira correta.
Gerenciar a qualidade é importante porque, com o passar do tempo, o custo de correção de

defeitos aumenta exponencialmente como podemos ver na imagem a seguir:
Gerenciamento de Mudanças
O gerenciamento de mudanças abrange a identificação, avaliação, aprovação e implementação

de mudanças no projeto. Isso pode incluir mudanças nos requisitos, design, código, planos de
teste, documentação, entre outros. O objetivo é controlar as mudanças para minimizar o impacto
nos objetivos do projeto e garantir que todas as mudanças sejam devidamente rastreadas e
gerenciadas.
No RUP, abrange as atividades de:

. Túlio Lages
Aula 00
Aula 01
• Coordenação de atividades e artefatos

• Procedimentos repetíveis para gerenciar mudanças sobre os artefatos.
• Coordenação de iterações e releases
• Mantém o controle sobre os releases ao final de cada iteração (baselines).
• Controle de mudanças no software
• Mantém uma estrutura bem definida para gerenciar mudanças no software.
QUESTÕES ESTRATÉGICAS
Nesta seção, apresentamos e comentamos uma amostra de questões objetivas selecionadas

estrategicamente: são questões com nível de dificuldade semelhante ao que você deve esperar
para a sua prova e que, em conjunto, abordam os principais pontos do assunto.
A ideia, aqui, não é que você fixe o conteúdo por meio de uma bateria extensa de questões, mas
que você faça uma boa revisão global do assunto a partir de, relativamente, poucas questões
1. (VUNESP / Prefeitura de Campinas - SP – 2019) O RUP (Rational Unified Process)

apresenta disciplinas cujas atividades são distribuídas por quatro fases. Em relação a
tais disciplinas e atividades, é correto afirmar que a disciplina:
a) Análise e Projeto tem suas atividades distribuídas igualmente pelas quatro fases.
b) Modelagem de Negócio tem menor atividade na fase de Elaboração.
c) Configuração e Gerenciamento de Mudança tem menor atividade na fase de
Iniciação
d) de Requisitos tem suas atividades distribuídas igualmente pelas quatro fases.
e) Modelagem de Negócio tem perfil de distribuição de atividades idêntico ao da
disciplina Implantação, ao longo das quatro fases.
Comentários:

. Túlio Lages
Aula 00
Aula 01
De acordo com o Gráfico de Baleias, é possível notar que a disciplina de Configuração

e Gerenciamento de Mudanças tem menor atividade na fase de Iniciação.
Gabarito: C
2. (VUNESP / Prefeitura de Presidente Prudente - SP – 2016) A arquitetura geral do RUP

(Rational Unified Process) estabelece fases e disciplinas. Segundo o RUP,
a) o número de iterações da fase de Elaboração deve ser maior do que 3.

b) o número de iterações da fase de Transição deve ser maior do que o da fase de
Elaboração.
c) o número de iterações em cada fase do RUP depende de cada projeto.
d) o número de iterações na fase de Construção deve ser de, no máximo, 5.
e) todas as fases do RUP devem possuir o mesmo número de iterações.
Comentários:
Não existe número máximo de iterações em nenhuma fase – tudo dependerá das
particularidades de cada projeto.
Gabarito: C
3. (VUNESP / Prefeitura de Presidente Prudente - SP – 2016) No RUP, a disciplina que

tem por objetivo produzir versões do produto software e entregar esse produto
software a seus usuários finais é:
a) Ambiente.
b) Análise e Projeto.
c) Deployment.

. Túlio Lages
Aula 00
Aula 01
d) Modelagem de Negócio.
e) Testes.
Comentários:
A disciplina que tem por objetivo produzir versões do produto software e entregar esse
produto software a seus usuários finais é a fase de deployment (implantação).
Gabarito: C
4. (VUNESP / CETESB – 2009) Em RUP, a integração contínua, no contexto do ciclo de vida

iterativo, significa:
a) integração no fim de cada construção.

b) integração no fim de cada iteração.
c) integração no fim de cada transição.
d) integração apenas no fim da elaboração e construção.
e) integrações apenas com as releases externas.
Comentários:
A Integração Contínua é uma prática que busca integrar e criar o sistema sempre que
uma tarefa for concluída. O RUP suporta essa prática através de builds no nível de
sistema e de subsistema (dentro de uma iteração). Os componentes testados em
unidades são integrados e testados no contexto do sistema emergente.
Gabarito: B
5. (VUNESP / CETESB – 2009) Em RUP, a iteratividade ajuda no gerenciamento de

recursos e custos porque:
a) ajuda o gerente de projetos a alocar os requisitos por fase, com base na

disponibilidade dos recursos durante o tempo de vida do projeto.
b) ajuda o gerente de projetos a organizar recursos e custos por fases. Os artefatos do
projeto evoluem conforme requerido por cada fase e aumenta-se a precisão na
estimativa de custo fase a fase.
c) permite mover os requisitos do projeto por entre as fases para garantir que os
recursos possam ser mais bem gerenciados durante todo o ciclo de desenvolvimento.

. Túlio Lages
Aula 00
Aula 01
d) permite planejar as interações prévia e detalhadamente para todas as fases. Além

disso, permite estabelecer custo e criar um perfil de uso de recurso para o projeto.
Comentários:
(a) Errado. Alocar os requisitos por fase? Requisitos? Não! (b) Correto. A iteratividade
reduz riscos, organizando recursos e custos. Como se repete diversas vezes, melhora a
precisão de diversas estimativas. (c) Errado. Isso não tem relação com recursos e
custos. (d) Errado. Interações não tem nada a ver com gerenciamento de recursos e
custos. (e) Errado. Não vejo nada de errado nesse item, mas a letra (b) é mais completa
Gabarito: B
6. (VUNESP / CETESB – 2009) Os planos de desenvolvimento de software cobertos em

RUP são:
a) Iteração, Construção e Publicação.

b) Gerenciamento de Requisitos, Métricas de Produto e Garantia de Teste de Software.
c) Gerenciamento de Recursos, Gerenciamento de Requisitos, Métricas e
Gerenciamento de Risco.
d) Gerenciamento de Requisitos, Validação Mestre, Teste de Qualidade e
e) Resolução de Problemas, Aceitação do Produto, Métricas, Gerenciamento de Risco
e Garantia de Qualidade.
Comentários:
Os Planos de Desenvolvimento de Software são: Plano de Infraestrutura, Plano de

Aceitação do Produto, Plano de Gerenciamento de Configuração, Plano de
Documentação, Plano de Garantia de Qualidade, Plano de Resolução de Problemas,
Plano de Gerenciamento de Subfornecedores, Plano de Melhoria de Processo, Plano
de Iteração, Plano de Gerenciamento de Requisitos, Plano de Métricas, Plano de
Gerenciamento de Riscos.
Gabarito: E
7. (FGV / MPE-AL – 2018) O Processo Unificado de software é uma tentativa de

aproveitar os melhores recursos e características dos modelos tradicionais de processo
de software. Sobre o Processo Unificado de software, assinale a afirmativa correta:

. Túlio Lages
Aula 00
Aula 01
a) O software é dirigido a casos de uso, centrado na arquitetura, sequencial e

incremental.
b) O software é entregue aos usuários finais na fase de transição.
c) Os modelos de caso de uso, análise, projeto e implementação são desenvolvidos na
fase de concepção.
d) O planejamento é realizado na fase de elaboração.
e) Os requisitos não funcionais são descritos em um conjunto de casos de uso
preliminares
Comentários:
(a) Errado. Essa é uma definição do RUP e, não, do software; (b) Correto. Uma atividade
clássica da fase de Transição é disponibilizar o produto para os usuários finais; (c)
Errado. Todos esses podem ser executados na fase de concepção, mas não é a fase
principal para análise, projeto e implementação; (d) Errado, é realizado na fase de
concepção; (e) Errado, são requisitos funcionais que são descritos em um conjunto de
casos de uso preliminares.
Gabarito: B
8. (FGV / ALERJ – 2017) Um sistema está sendo desenvolvido com a utilização do

processo unificado, que contém diversas fases. Na fase atual do processo será feita a
implantação do sistema e a análise de lições aprendidas. Os analistas de requisitos e
de negócio, praticamente, já terminaram suas atividades. É necessário ainda analisar a
possibilidade de se executar outro ciclo de desenvolvimento. O sistema está na fase
de:
a) produção;
b) concepção;
c) elaboração;
d) transição;
e) construção
Comentários:
Se na fase atual do processo será feita a implantação do sistema e a análise de lições
aprendidas, o sistema claramente está na fase de transição.
Gabarito: D

. Túlio Lages
Aula 00
Aula 01
9. (FGV / Prefeitura de Paulínia - SP – 2016) Um sistema está sendo desenvolvido com a

utilização do processo unificado. Este processo contém diversas fases. O foco da fase
atual é assegurar que o software esteja disponível para seus usuários finais. Nessa fase,
o usuário é consultado e este feedback deve priorizar o ajuste fino do produto, a
configuração, a instalação e os problemas de usabilidade. O sistema está na fase
denominada:
a) produção.
b) transição.
c) elaboração.
d) concepção.
e) construção.
Comentários:
Se o foco da fase atual é assegurar que o software esteja disponível para seus usuários
finais, trata-se da fase de transição.
Gabarito: B
10. (FGV / SEE-PE – 2016) O sistema SISFORÇA está sendo desenvolvido com a utilização
do processo unificado. Este processo contém diversas fases. Na fase atual do processo
do SISFORÇA está sendo realizada a fusão de vários artefatos de software,
possibilitando que o sistema seja implementado quase que completamente. Nessa
fase, tem-se uma visão geral de como a Baseline do projeto está sendo seguida. De
acordo com o fragmento acima, o sistema SISFORÇA está na fase de:
a) produção.
b) transição.
c) elaboração.
d) concepção.
e) construção.
Comentários:
Se a fase atual do processo do SISFORÇA está sendo realizada a fusão de vários

artefatos de software, possibilitando que o sistema seja implementado quase que
completamente, então trata-se da fase de construção. Os artefatos mencionados são
os componentes!

. Túlio Lages
Aula 00
Aula 01
Gabarito: E
QUESTIONÁRIO DE REVISÃO E APERFEIÇOAMENTO
A ideia do questionário é elevar o nível da sua compreensão no assunto e, ao mesmo tempo,

proporcionar uma outra forma de revisão de pontos importantes do conteúdo, a partir de
perguntas que exigem respostas subjetivas.
São questões um pouco mais desafiadoras, porque a redação de seu enunciado não ajuda na sua
resolução, como ocorre nas clássicas questões objetivas.
O objetivo é que você realize uma auto explicação mental de alguns pontos do conteúdo, para
consolidar melhor o que aprendeu ;)
Além disso, as questões objetivas, em regra, abordam pontos isolados de um dado assunto. Assim,
ao resolver várias questões objetivas, o candidato acaba memorizando pontos isolados do
conteúdo, mas muitas vezes acaba não entendendo como esses pontos se conectam.
Assim, no questionário, buscaremos trazer também situações que ajudem você a conectar melhor
os diversos pontos do conteúdo, na medida do possível.
É importante frisar que não estamos adentrando em um nível de profundidade maior que o exigido
na sua prova, mas apenas permitindo que você compreenda melhor o assunto de modo a facilitar
a resolução de questões objetivas típicas de concursos, ok?
Nosso compromisso é proporcionar a você uma revisão de alto nível!
Vamos ao nosso questionário:
Perguntas
1. O que é o Processo Unificado Rational (RUP)?

2. O que é o "gráfico das baleias" no RUP?
3. Quais são as quatro fases do RUP?

. Túlio Lages
Aula 00
Aula 01
4. O que é uma iteração no RUP?

5. Quais são as principais disciplinas no RUP?
6. O que é um marco no RUP?
7. O que são atividades, papeis e artefatos no contexto do RUP?
8. O que é a disciplina de Modelagem de Negócios no RUP?
9. O que é a disciplina de Requisitos no RUP?
10. O que é a disciplina de Análise e Projeto no RUP?
11. O que é a disciplina de Implementação no RUP?
12. O que é a disciplina de Testes no RUP?
13. O que é a disciplina de Implantação no RUP?
14. O que é a disciplina de Gestão de Configuração e Mudanças no RUP?
15. O que é a disciplina de Gestão de Projetos no RUP?
16. O que é a disciplina de Ambiente no RUP?
17. Quais são as seis melhores práticas do RUP?
18. O que é a técnica de Casos de Uso no RUP?
19. Quais são as cinco visões arquiteturais do RUP?
20. O que é UML e como é utilizado no RUP?
Perguntas e Respostas
1. O que é o Processo Unificado Rational (RUP)?

Resposta: O RUP é um framework de desenvolvimento de software que enfatiza um ciclo de
vida iterativo e incremental. Foi criado pela Rational Software, que agora faz parte da IBM.
2. O que é o "gráfico das baleias" no RUP?
Resposta: É uma representação gráfica das fases e disciplinas do RUP. Chamado de "gráfico
das baleias" devido à sua aparência, o gráfico mostra como as disciplinas são enfatizadas ao
longo das quatro fases do RUP.
3. Quais são as quatro fases do RUP?
Resposta: As quatro fases do RUP são: Iniciação, Elaboração, Construção e Transição.
4. O que é uma iteração no RUP?
Resposta: Uma iteração é uma passagem pelas disciplinas técnicas dentro do ciclo de vida de
desenvolvimento do RUP que resulta em um release (interno ou externo) de um sistema
executável.
5. Quais são as principais disciplinas no RUP?
Resposta: As disciplinas no RUP incluem: Modelagem de Negócios, Requisitos, Análise e

. Túlio Lages
Aula 00
Aula 01
Projeto, Implementação, Testes, Implantação, Gestão de Configuração e Mudanças, Gestão

de Projetos, e Ambiente.
6. O que é um marco no RUP?
Resposta: Um marco é um ponto importante no tempo que indica a conclusão de uma ou
mais atividades significativas, geralmente de uma Fase.
7. O que são atividades, papeis e artefatos no contexto do RUP?
Resposta: Atividades são unidades de trabalho que um indivíduo ou equipe pode ser
encarregado de realizar. Papeis são definições das responsabilidades e comportamentos
esperados de um indivíduo ou equipe. Artefatos são resultados tangíveis e verificáveis de uma
atividade.
8. O que é a disciplina de Modelagem de Negócios no RUP?
Resposta: A disciplina de Modelagem de Negócios envolve a modelagem dos aspectos de
negócios de um sistema.
9. O que é a disciplina de Requisitos no RUP?
Resposta: A disciplina de Requisitos envolve a definição dos requisitos do sistema.
10. O que é a disciplina de Análise e Projeto no RUP?
Resposta: A disciplina de Análise e Projeto envolve a modelagem da arquitetura do sistema.
11. O que é a disciplina de Implementação no RUP?
Resposta: A disciplina de Implementação envolve a programação do sistema.
12. O que é a disciplina de Testes no RUP?
Resposta: A disciplina de Testes envolve a verificação e validação do sistema.
13. O que é a disciplina de Implantação no RUP?
Resposta: A disciplina de Implantação envolve a distribuição do sistema.
14. O que é a disciplina de Gestão de Configuração e Mudanças no RUP?
Resposta: A disciplina de Gestão de Configuração e Mudanças envolve o gerenciamento de
versões do sistema e de mudanças.
15. O que é a disciplina de Gestão de Projetos no RUP?
Resposta: A disciplina de Gestão de Projetos envolve o planejamento, monitoramento e
controle do projeto.
16. O que é a disciplina de Ambiente no RUP?
Resposta: A disciplina de Ambiente envolve a configuração do ambiente de desenvolvimento.
17. Quais são as seis melhores práticas do RUP?
Resposta: As seis melhores práticas do RUP são: Desenvolvimento Iterativo, Gerência de
Requisitos, Arquitetura de Componentes, Modelagem Visual com UML, Verificação de
Qualidade e Gerenciamento de Mudanças.

. Túlio Lages
Aula 00
Aula 01
18. O que é a técnica de Casos de Uso no RUP?

Resposta: Casos de Uso são uma técnica para capturar requisitos funcionais de um sistema,
descrevendo como o sistema interage com seus atores para cumprir um objetivo.
19. Quais são as cinco visões arquiteturais do RUP?
Resposta: As cinco visões arquiteturais do RUP são: visão lógica, visão de processos, visão de
implementação, visão de implantação e visão de casos de uso.
20. O que é UML e como é utilizado no RUP?
Resposta: UML, ou Linguagem de Modelagem Unificada, é um padrão de linguagem para a
criação de diagramas de software. No RUP, a UML é usada para visualizar, especificar,
construir e documentar os artefatos de um sistema de software.
LISTA DE QUESTÕES ESTRATÉGICAS
1. (VUNESP / Prefeitura de Campinas - SP – 2019) O RUP (Rational Unified Process)

apresenta disciplinas cujas atividades são distribuídas por quatro fases. Em relação a
tais disciplinas e atividades, é correto afirmar que a disciplina:
a) Análise e Projeto tem suas atividades distribuídas igualmente pelas quatro fases.
b) Modelagem de Negócio tem menor atividade na fase de Elaboração.
c) Configuração e Gerenciamento de Mudança tem menor atividade na fase de
Iniciação
d) de Requisitos tem suas atividades distribuídas igualmente pelas quatro fases.
e) Modelagem de Negócio tem perfil de distribuição de atividades idêntico ao da
disciplina Implantação, ao longo das quatro fases.
2. (VUNESP / Prefeitura de Presidente Prudente - SP – 2016) A arquitetura geral do RUP

(Rational Unified Process) estabelece fases e disciplinas. Segundo o RUP,
a) o número de iterações da fase de Elaboração deve ser maior do que 3.

b) o número de iterações da fase de Transição deve ser maior do que o da fase de
Elaboração.
c) o número de iterações em cada fase do RUP depende de cada projeto.
d) o número de iterações na fase de Construção deve ser de, no máximo, 5.
e) todas as fases do RUP devem possuir o mesmo número de iterações.

. Túlio Lages
Aula 00
Aula 01
3. (VUNESP / Prefeitura de Presidente Prudente - SP – 2016) No RUP, a disciplina que

tem por objetivo produzir versões do produto software e entregar esse produto
software a seus usuários finais é:
a) Ambiente.
b) Análise e Projeto.
c) Deployment.
d) Modelagem de Negócio.
e) Testes.
4. (VUNESP / CETESB – 2009) Em RUP, a integração contínua, no contexto do ciclo de vida

iterativo, significa:
a) integração no fim de cada construção.

b) integração no fim de cada iteração.
c) integração no fim de cada transição.
d) integração apenas no fim da elaboração e construção.
e) integrações apenas com as releases externas.
5. (VUNESP / CETESB – 2009) Em RUP, a iteratividade ajuda no gerenciamento de

recursos e custos porque:
a) ajuda o gerente de projetos a alocar os requisitos por fase, com base na

disponibilidade dos recursos durante o tempo de vida do projeto.
b) ajuda o gerente de projetos a organizar recursos e custos por fases. Os artefatos do
projeto evoluem conforme requerido por cada fase e aumenta-se a precisão na
estimativa de custo fase a fase.
c) permite mover os requisitos do projeto por entre as fases para garantir que os
recursos possam ser mais bem gerenciados durante todo o ciclo de desenvolvimento.
d) permite planejar as interações prévia e detalhadamente para todas as fases. Além
disso, permite estabelecer custo e criar um perfil de uso de recurso para o projeto.
6. (VUNESP / CETESB – 2009) Os planos de desenvolvimento de software cobertos em

RUP são:
a) Iteração, Construção e Publicação.

b) Gerenciamento de Requisitos, Métricas de Produto e Garantia de Teste de Software.
c) Gerenciamento de Recursos, Gerenciamento de Requisitos, Métricas e
d) Gerenciamento de Requisitos, Validação Mestre, Teste de Qualidade e

. Túlio Lages
Aula 00
Aula 01
e) Resolução de Problemas, Aceitação do Produto, Métricas, Gerenciamento de Risco

e Garantia de Qualidade.
7. (FGV / MPE-AL – 2018) O Processo Unificado de software é uma tentativa de

aproveitar os melhores recursos e características dos modelos tradicionais de processo
de software. Sobre o Processo Unificado de software, assinale a afirmativa correta:
a) O software é dirigido a casos de uso, centrado na arquitetura, sequencial e

incremental.
b) O software é entregue aos usuários finais na fase de transição.
c) Os modelos de caso de uso, análise, projeto e implementação são desenvolvidos na
fase de concepção.
d) O planejamento é realizado na fase de elaboração.
e) Os requisitos não funcionais são descritos em um conjunto de casos de uso
preliminares
8. (FGV / ALERJ – 2017) Um sistema está sendo desenvolvido com a utilização do

processo unificado, que contém diversas fases. Na fase atual do processo será feita a
implantação do sistema e a análise de lições aprendidas. Os analistas de requisitos e
de negócio, praticamente, já terminaram suas atividades. É necessário ainda analisar a
possibilidade de se executar outro ciclo de desenvolvimento. O sistema está na fase
de:
a) produção;
b) concepção;
c) elaboração;
d) transição;
e) construção
9. (FGV / Prefeitura de Paulínia - SP – 2016) Um sistema está sendo desenvolvido com a

utilização do processo unificado. Este processo contém diversas fases. O foco da fase
atual é assegurar que o software esteja disponível para seus usuários finais. Nessa fase,
o usuário é consultado e este feedback deve priorizar o ajuste fino do produto, a
configuração, a instalação e os problemas de usabilidade. O sistema está na fase
denominada:
a) produção.
b) transição.
c) elaboração.
d) concepção.
e) construção.

. Túlio Lages
Aula 00
Aula 01
10. (FGV / SEE-PE – 2016) O sistema SISFORÇA está sendo desenvolvido com a utilização
do processo unificado. Este processo contém diversas fases. Na fase atual do processo
do SISFORÇA está sendo realizada a fusão de vários artefatos de software,
possibilitando que o sistema seja implementado quase que completamente. Nessa
fase, tem-se uma visão geral de como a Baseline do projeto está sendo seguida. De
acordo com o fragmento acima, o sistema SISFORÇA está na fase de:
a) produção.
b) transição.
c) elaboração.
d) concepção.
e) construção.
Gabaritos
1. C
2. C
3. C
4. B
5. B
6. E
7. B
8. D
9. B
10. E

Aula 01 - RUP

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula 01 - RUP

Enviado por

Direitos autorais:

Formatos disponíveis

Caixa Econômica Federal - CEF (Técnico

85764731518 - Anna Clara nascimento

PROCESSO UNIFICADO (RUP)

ANÁLISE ESTATÍSTICA ..................................................................................................................... 2

Glossário de termos ..................................................................................................................... 3

Roteiro de revisão ........................................................................................................................ 6

Estrutura e "Gráfico das Baleias" ................................................................................................. 8

Boas Práticas .............................................................................................................................. 27

Questões Estratégicas ............................................................................................................... 33

Questionário de revisão e aperfeiçoamento ............................................................................. 39

Perguntas e Respostas ............................................................................................................... 40

Lista de Questões Estratégicas ................................................................................................... 42

85764731518 - Anna Clara nascimento

Inicialmente, convém destacar o percentual de incidência do assunto, dentro da disciplina

Obs.: um mesmo assunto pode ser classificado em mais de um tópico devido à

Processos de Software - Desenvolvimento Ágil 8.4 %

Engenharia de Requisitos 8.2 %

Teste de Software 6.7 %

Métricas de Software 5.1 %

Desenvolvimento de Software 4.6 %

Inteligencia Artificial 4.6 %

Processos de Software 4.6 %

Orientação a Objetos 4.5 %

Gestão de Projetos em Engenharia de Software 3.6 %

Qualidade de Software 3.4 %

Metodologia de desenvolvimento de software 2.5 %

Gerência de Configuração 1.9 %

Geoprocessamento em Engenharia de Software 1.6 %

85764731518 - Anna Clara nascimento

Conceitos Básicos em Engenharia de Software 0.7 %

Análise Estruturada 0.6 %

Ferramentas CASE 0.4 %

Ferramentas de Desenvolvimento de Software 0.4 %

Software livre 0.3 %

Manutenção de Software 0.1 %

Análise Essencial 0.1 %

Web 2.0 0.1 %

Portal Web 0.1 %

Engenharia da Informação 0.1 %

RUP: Sigla de Rational Unified Process (Processo Unificado da Rational). É um framework de

85764731518 - Anna Clara nascimento

Marco: Um ponto importante no tempo que indica a conclusão de uma fase.

Papel: Uma definição das responsabilidades e comportamentos esperados de um indivíduo ou

Artefato: Um resultado tangível e verificável de uma atividade.

Disciplina de Modelagem de Negócios: Realiza a modelagem dos aspectos de negócios de um

Disciplina de Requisitos: Disciplina que faz a definição dos requisitos do sistema.

Disciplina de Análise e Projeto: Disciplina realiza a modelagem da arquitetura do sistema.

Disciplina de Implementação: Disciplina que faz a programação do sistema.

Disciplina de Testes: Disciplina que envolve a verificação e validação do sistema.

Disciplina de Implantação: Disciplina que envolve a distribuição do sistema no seu ambiente-

Disciplina de Gestão de Configuração e Mudanças: Envolve o gerenciamento de versões do

85764731518 - Anna Clara nascimento

Disciplina de Gestão de Projetos: Envolve o planejamento, acompanhamento e controle de

Disciplina de Ambiente: Envolve a configuração do ambiente de desenvolvimento e do próprio

Documento de Requisitos: Documento que captura os requisitos do sistema de forma completa

Modelo de Design: Representação visual da arquitetura de software do sistema.

Teste Unitário: Procedimento que valida a funcionalidade de um componente de software

Componente: Uma unidade de software modular, independente e substituível que cumpre um

Plano de Teste: Documento que descreve o escopo, a abordagem, os recursos e o cronograma

Caso de Teste: Conjunto de condições sob as quais um tester determinará se um sistema de

Controle de Versão: Processo de gerenciar diferentes versões de artefatos de software.

Controle de Mudança: Processo de gerenciar alterações nos requisitos de um sistema.