AULA 4 TI MPOG

Prévia do material em texto

de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 1 de 88 
AULA 4 – ENGENHARIA DE SOFTWARE 
Olá queridos (as) amigos (as), meus cumprimentos! 
 
 
 
 
 
Vamos em frente, dando prosseguimento aos estudos! 
Profa Patrícia Lima Quintão 
Twitter: http://www.twitter.com/pquintao 
Facebook: http://www.facebook.com/professorapatriciaquintao 
 
Conteúdo desta Aula Página 
 Lista de Questões Comentadas Nesta Aula. 02 
 Considerações Finais. 68 
 Questões Apresentadas na Aula. 70 
 Gabarito. 88 
"São as nossas escolhas que revelam o que realmente somos, 
muito mais do que as nossas qualidades." 
(Alvo Dumbledore, personagem do livro Harry Potter) 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 2 de 88 
QUESTÕES DE PROVAS COMENTADAS 
 
1. (Cesgranrio/Funasa/2009) À luz da Engenharia de Software, o ciclo de 
vida clássico, também chamado de modelo sequencial linear ou modelo em 
cascata, é um paradigma aplicável ao desenvolvimento de sistemas de 
informações que 
 
(A) enfatiza a análise de riscos, que é feita no início do projeto e revisada a 
cada fase, incluindo um plano de ataque e ações de mitigação dos riscos, 
aumentando as chances de sucesso do projeto. 
(B) prevê uma sequência (ou cascata) de entregas de versões do sistema 
ao longo do desenvolvimento do mesmo, o que proporciona uma avaliação 
de progresso baseada em código funcionando, em vez de quantidade de 
documentação gerada. 
(C) exige que todos os requisitos sejam conhecidos e corretamente 
especificados no início do ciclo de vida, dificultando a acomodação de 
mudanças que surjam nas fases posteriores. 
(D) foi sempre pouco utilizado na prática, pois se apoia em analogias com 
práticas de engenharia convencional que não se aplicam bem ao 
desenvolvimento de sistemas de informação. 
(E) utiliza a estratégia dividir para conquistar (divide to conquer), prevendo 
que cada fase do ciclo de vida seja desdobrada em um miniciclo de vida 
sequencial completo, formando uma cascata de ciclos de vida até o limite 
adequado para lidar com a complexidade do sistema. 
 
 
Comentários 
O modelo em Cascata (Waterfall), também chamado de Clássico, é o mais 
tradicional processo de desenvolvimento de software. Este modelo sugere uma 
abordagem sequencial para o desenvolvimento de software, aplicando as 
atividades de maneira linear. Esse modelo possui como vantagem principal a 
simplicidade para a sua aplicação e gerência. No entanto, algumas 
desvantagens podem ser observadas: 
• projetos reais raramente seguem este fluxo seqüencial. 
• dificuldade do cliente em declarar todas as suas necessidades no início do 
projeto, dificultando a implementação de mudanças que surjam nas fases 
posteriores; 
• demora em apresentar resultados ao cliente. 
Gabarito: letra C. 
 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 3 de 88 
2. (Cesgranrio/MD/2009) A fase que deve acontecer primeiro no 
desenvolvimento de sistemas de uma empresa que utiliza o modelo de ciclo 
de vida em cascata é a de 
(A) testes. 
(B) análise e projeto. 
(C) especificação de requisitos. 
(D) implantação. 
(E) implementação. 
 
Comentários 
Em cada fase do modelo de ciclo de vida em cascata desenvolvem-se artefatos 
(produtos de software) que servem de base para as fases seguintes. 
A figura seguinte, proposta por Eduardo Bezerra, mostra o modelo do ciclo 
de vida clássico da engenharia de software, que é dividido em seis 
atividades. São elas: 
 
A figura a seguir apresenta outra possibilidade de esquema deste modelo, 
apresentada pelo Pressman. 
 
Comunicação
Planejamento
Modelagem
Construção
Implantação
 
Em seguida, a proposta de Kruchten (2003). 
 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 4 de 88 
 
Dentre as fases apresentadas na questão, conforme visto na explicação acima, 
é a especificação de requisitos que deve acontecer primeiro no 
desenvolvimento de sistemas de uma empresa que utiliza o modelo de ciclo de 
vida em cascata. 
Gabarito: letra C. 
 
3. (Cesgranrio/Petrobrás/Processo de Negócio/2010) No Ciclo de Vida 
Clássico, também chamado de Modelo Sequencial Linear ou Modelo Cascata, 
é apresentada uma abordagem sistemática composta pelas seguintes 
atividades: 
(A) Análise de Requisitos de Software, Projeto, Geração de Código, Teste e 
Manutenção. 
(B) Modelagem e Engenharia do Sistema/Informação, Análise de Requisitos 
de Software, Projeto, Geração de Código, Teste e Manutenção. 
(C) Modelagem e Engenharia do Sistema/Informação, Projeto, Geração de 
Código, Teste e Manutenção. 
(D) Levantamento de Requisitos de Software, Projeto, Geração de Código e 
Manutenção e Análise de Requisitos de Software. 
(E) Levantamento de Requisitos de Software, Projeto, Geração de Código, 
Teste Progressivo e Manutenção. 
 
Comentários 
Dentre as assertivas, a B é a que destaca as principais atividades do modelo 
em Cascata. Uma especificação das fases desse modelo pode ser vista na 
questão anterior. 
Gabarito: letra B. 
 
4. (Cesgranrio/Petrobrás/Engenhariade Software/2010) O modelo de 
ciclo de vida em cascata 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 5 de 88 
(A) enfatiza a realização sequencial das atividades do desenvolvimento de 
um produto de software. 
(B) enfatiza a comunicação estreita com o cliente durante o 
desenvolvimento do produto de software. 
(C) envolve a ideia principal de criar um protótipo executável e, por meio de 
transformações sucessivas, chegar ao sistema completamente 
implementado. 
(D) envolve a análise dos riscos envolvidos no desenvolvimento dos 
requisitos identificados para produto de software. 
(E) recomenda a geração de versões incompletas do sistema, que podem 
ser passadas para o usuário final, o que permite a retroalimentação do 
processo de desenvolvimento. 
 
Comentários 
O modelo de ciclo de vida em cascata enfatiza a progressão sequencial entre 
uma fase e a seguinte. 
Gabarito: letra A. 
 
5. (Cesgranrio/BNDES/Desenvolvimento/2009) No ciclo de vida em 
cascata, o custo de correção é menor na fase de 
(A) testes. 
(B) transição. 
(C) implementação. 
(D) requisitos. 
(E) manutenção. 
 
Comentários 
Se eu detectar um erro no início do projeto, ou seja, na fase de requisitos, 
melhor. Quanto mais tarde eu detectar um problema, pior será. 
Gabarito: letra D. 
 
6. (Cesgranrio/Petrobrás/Processos de Negócios/2008) Analise as 
afirmativas a seguir, sobre requisitos em projetos de software. 
I - O rastreamento de requisitos é de grande importância para conduzir 
análises de impacto quando há mudanças em requisitos. 
II - O acrônimo FURPS+ se refere aos requisitos não funcionais das 
categorias de Feasibility, Usability, Reliability, Performance e Supportability. 
III - Um requisito pode conter, além da especificação, atributos que sirvam 
ao seu gerenciamento. 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 6 de 88 
IV - Casos de uso são descrições da interação entre um ator e o sistema e, 
portanto, especificam apenas requisitos funcionais. 
Estão corretas APENAS as afirmativas 
(A) I e II. 
(B) I e III. 
(C) II e III. 
(D) II e IV. 
(E) III e IV. 
 
Comentários 
Item I. Item correto. A rastreabilidade de requisitos é essencial para que o 
controle de mudanças possa avaliar o impacto de uma solicitação de mudança. 
 
Importante 
Define-se rastreabilidade dentro de um ambiente de desenvolvimento como 
a capacidade de relacionar um elemento a outros correlatos, especialmente 
àqueles relacionados a requisitos. Os elementos do projeto envolvidos em 
rastreabilidade são chamados de itens de rastreabilidade. Os itens típicos 
de rastreabilidade incluem diferentes tipos de requisitos, elementos de modelo 
de projeto e de análise, artefatos de testes, entre outros. Para que o controle 
de mudanças avalie o impacto de uma solicitação é necessário identificar, 
portanto, seus itens de rastreabilidade. 
 
Item II. Item errado. O acrônimo FURPS+ é um sistema para a classificação 
de requisitos. Representa categorias que podem ser usadas na definição de 
requisitos, assim como representa atributos de Qualidade de Software, sendo 
ele parte do Rational Unified Process (RUP): 
• Functionality (Funcionalidade): representa todo aspecto funcional do 
software, ou seja, seus requisitos. É uma categoria com diversas 
subcategorias que variam de acordo com a aplicação. Sua medição 
considera, principalmente, o cumprimento dos requesitos especificados. 
• Usability (Usabilidade): é o atributo que avalia a interface com o usuário. 
Possui diversas subcategorias, entre elas: prevenção de erros; estética e 
design; ajudas (Help) e documentação; consistência e padrões. 
• Reliability (Confiabilidade): refere-se à integridade, conformidade e 
interoperabilidade do software. Os requisitos a serem considerados são: 
freqüência e gravidade de falha; possibilidade de recuperação; 
possibilidade de previsão; exatidão; tempo médio entre falhas (MTBF). 
• Performance (Desempenho): avalia os requisitos de desempenho do 
software. Podendo usar como medida diversos aspectos, entre eles: 
tempo de resposta, consumo de memória, utilização da CPU, capacidade 
de carga e disponibilidade da aplicação. 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 7 de 88 
• Supportability (Suportabilidade): os requisitos de suportabilidade 
agrupam várias características, como: testabilidade, adaptabilidade, 
manutenibilidade, compatibilidade, configurabilidade, instalabilidade, 
escalabilidade, localizabilidade entre outros. 
 
O + engloba também outros requisitos não-funcionais que devem ser 
lembrados: 
• Requisitos de design (desenho): freqüentemente chamado de uma 
restrição de design, especifica ou restringe o design de um sistema. 
Exemplos: linguagens de programação, processo de software, uso de 
ferramentas de desenvolvimento, biblioteca de classes, etc. 
• Requisitos de implementação: especificam ou restringem o código ou 
a construção de um sistema. Exemplos: padrões obrigatórios; linguagens 
de implementação; políticas de integridade de banco de dados; limites 
de recursos; ambientes operacionais. 
• Requisitos de interface: especifica ou restringe as funcionalidades 
inerentes à interface do sistema com usuário. 
• Requisitos físicos: especifica uma limitação física pelo hardware 
utilizado, por exemplo: material, forma, tamanho ou peso. Podendo 
representar requisitos de hardware, como as configurações físicas de 
rede obrigatórias. 
Fonte: http://qualidadebr.wordpress.com/2008/07/10/furps/. 
 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i ra b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 8 de 88 
Figura. FURPS+ (Fonte: 
http://www.ibm.com/developerworks/rational/library/content/04March/3073/3
073_fig3.jpg) 
 
Item III. Item correto. Na fase de gestão de requisitos é feita a administração 
dos requisitos, bem como o acompanhamento dos mesmos quanto a 
alterações, com as tabelas de rastreamento. Nesse contexto, um requisito 
pode conter, além da especificação, atributos que sirvam ao seu 
gerenciamento. 
 
Item IV. Item errado. Um caso de uso pode especificar requisitos não-
funcionais. Exemplo de requisito: ao clicar em um botão, o sistema deverá 
responder em menos de um segundo, mostrando a resposta em uma página 
diferente e de forma gráfica. 
Gabarito: letra B. 
 
7. (Cesgranrio/Petrobras/Engenharia de Software/2006) Sobre a 
Análise e o Gerenciamento de Requisitos, é FALSO afirmar que: 
(A) quanto mais tarde for identificado um problema na análise de requisitos, 
maior será o custo com o retrabalho. 
(B) a elicitação é o processo de identificação e entendimento das 
necessidades e restrições dos usuários, enquanto que a especificação é o 
processo de formalização das necessidades e restrições dos usuários em 
requisitos funcionais de software. 
(C) na análise de requisitos o cliente utiliza as melhores práticas de 
engenharia de requisitos na tarefa de descrever suas necessidades. 
(D) o gerenciamento de requisitos corresponde ao conjunto de atividades 
que auxilia a equipe do projeto a identificar, controlar e rastrear os 
requisitos, bem como a fazer as alterações nos requisitos durante o projeto. 
(E) o gerenciamento de requisitos implica a alteração, inclusão e/ou 
exclusão de requisitos ao produto de software, o que pode levar a 
alterações de prazos, de recursos humanos, de equipamentos e de 
tecnologia. 
 
Comentários 
Dentre as assertivas apresentadas, a única falsa é a letra C, já que é o analista 
que irá utilizar as melhores práticas de engenharia de requisitos na tarefa de 
descrever as necessidades do cliente. 
 
 
 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 9 de 88 
 
 
 
Algumas observações: 
Engenharia de Requisitos 
É o uso sistemático de princípios, técnicas, linguagens e ferramentas 
comprovadas para análise, documentação, evolução continuada das 
necessidades dos usuários e especificação do comportamento externo de um 
sistema para satisfazer as necessidades do usuário, que sejam efetivas em 
termos de custos. Visa, principalmente, o entendimento escrito do problema. 
 
Algumas considerações importantes: 
• é uma abordagem sistemática, ou seja, constituída por um conjunto 
de processos estruturados para extrair, validar e manter os requisitos 
de um sistema; 
• composta principalmente por atividades de Análise (identificar) e 
Documentação (validar); e 
• constitui a ponte entre a comunicação com o cliente, a documentação 
gerada, o projeto e o desenvolvimento. 
 
A Engenharia de Requisitos é composta pelos seguintes passos: 
• Concepção; 
• Levantamento (Especificação); 
• Elaboração; 
• Negociação; 
• Especificação; 
• Validação; 
• Gestão de Requisitos. 
 
Concepção 
O primeiro passo da Engenharia de requisitos é a Concepção, onde é realizada 
a definição do escopo e a natureza do problema, a análise da sua viabilidade, o 
reconhecimento dos interessados (stakeholders). 
Observação: Stakeholders são as pessoas que têm interesse direto no sistema 
a ser desenvolvido ou que se beneficie dele. Deve-se observar que para cada 
classe de interessados, podem ser definidos diferentes pontos de vista, 
gerando requisitos conflitantes. 
Na literatura, é sugerido que, nesta fase, os engenheiros de software adotem a 
estratégia do P&R (pergunta e resposta), empregando questões de livre 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 10 de 88 
contexto. As perguntas não são fixas, podendo surgir novas perguntas durante 
a realização das entrevistas. As perguntas são elaboradas e respondidas a 
partir das seguintes fontes de informação: 
• Interessados (stakeholders), como clientes, usuários e desenvolvedores; 
• Documentos; 
• Livros; 
• Sistemas de Software; 
• Livros relacionados à aplicação em discussão; e 
• Documentos mais referenciados pelos atores. 
 
Levantamento de Requisitos 
Neste passo busca-se descobrir, tornar explícito (elicitar), obter o máximo de 
informações para o conhecimento do software em questão. Para tanto, é 
necessário: 
• Identificar as fontes de informação; 
• Coletar os fatos; 
• Comunicação. 
 
Pretende-se, portanto, conhecer o domínio de aplicação do software, 
identificando e coletando os requisitos (funcionais e não-funcionais) de forma 
organizada. Este passo deve ser realizado em conjunto com todos os 
envolvidos, inclusive e de forma especial, os interessados. 
Alguns problemas são comuns durante a execução destas atividades: 
• Problemas de entendimento 
o Interessados não compreendem o domínio 
o Interessados omitem informações 
o Interessados possuem visões conflitantes 
o Interessados definem requisitos ambíguos 
o Interessados definem requisitos impossíveis de serem 
tratados (economicamente ou tecnologicamente) 
• Problema de escopo 
• Problemas de volatilidade 
Em um levantamento de requisitos, geralmente um engenheiro de software se 
depara com duas importantes questões: 
• Entre os muitos relatórios, formulários e documentos gerados pelos 
membros de uma organização, quais deverão ser objeto de 
investigação? 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 11 de 88 
• Pode haver um grande número de pessoas afetadas pelo sistema de 
informação proposto. Quais delas devem ser entrevistadas, 
observadas ou questionadas? 
 
Elaboração do Documento de Requisitos 
O documento de requisitos do sistema deve ser composto por sentenças em 
linguagem natural, seguindo determinados padrões, como o padrão IEEE-830, 
que contém os seguintes itens: 
1. Introdução 
1.1. Propósito 
1.2. Escopo 
1.3. Definições 
1.4. Referências 
1.5. Visão Geral 
2. Descrição Geral 
2.1 Perspectivas do Produto 
2.2. Funções do Produto 
2.3. Características do Usuário 
2.4. Restrições 
2.5. Dependências 
3. Requisitos Específicos 
3.1. Requisitos Funcionais 
3.2. Requisitos Não-Funcionais 
 
Deve-se ressaltar que nem todos os itens serão sempre necessários. Com 
relação aos requisitos funcionais, algumas regras devem ser observadas: 
Iniciar os requisitos com “O sistema deverá...” 
Os requisitos devem estar organizados logicamente. Por exemplo, inicialmente 
todos os requisitos de entrada depois os de processamento e por último os 
requisitos de saída. 
Cada requisito deve ter um identificador único, por exemplo, um número, para 
posterior referência, e deve conter sempre uma única ação. 
Gabarito: letra C. 
 
8. (Cesgranrio/Petrobrás/Engenharia de Software/2006) Analise as 
afirmativas abaixo a respeito de técnicas de levantamento de requisitos: 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 12 de 88 
I - Uma entrevista não estruturada deve “fluir” entre o entrevistado e o 
entrevistador e, para isso, as questões a serem feitas não se devem ser 
definidas previamente. 
II - A Implantação da Função de Qualidade (IFQ) é uma técnica que traduz 
as necessidades do cliente para requisitos técnicos de software, 
identificando três tipos de requisitos: normais, esperados e excitantes. 
III - Amostragem é o processo de seleção sistemática de elementos 
representativos de uma população, que permite revelar informações úteis 
acerca da população como um todo. 
IV - Uma técnica importante no levantamento de requisitos é observar o 
comportamento e o ambiente do indivíduo tomador de decisões, já que 
muitas informações passam desapercebidas com a utilização de outras 
técnicas. 
Estão corretas apenas as afirmativas: 
(A) I e II. 
(B) III e IV. 
(C) I, II e III. 
(D) I, II e IV. 
(E) II, III e IV. 
 
Comentários 
Dentre as assertivas, a incorreta é a letra I. Uma entrevista não estruturada 
deve “fluir” entre o entrevistado e o entrevistador e, para isso, questões a 
serem feitas podem ser definidas previamente. 
 
Cabe um complemento nesta questão quanto às técnicas para Levantamento 
de Requisitos. 
Servindo de base para todas as técnicas de levantamento de requisitos, 
entre elas investigação, entrevistas e observação, estão as decisões cruciais 
dizendo respeito ao que examinar e a quem questionar ou observar. Estas 
decisões podem ser apoiadas por uma abordagem estruturada chamada 
amostragem. 
 
A amostragem é o processo de seleção sistemática de elementos 
representativos de uma população. Quando os elementos selecionados em 
uma amostragem são analisados, pode-se assumir que esta análise revelará 
informações úteis acerca da população como um todo. 
 
Por que usar amostragem? 
• diminuir custos; 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 13 de 88 
• acelerar o processo de levantamento de informações; 
• eficiência: a informação tende a ser mais apurada, já que menos 
elementos podem ser analisados, mas estes podem ser analisados 
com mais detalhes; 
• reduzir tendências. 
 
A investigação de documentos é uma técnica que auxilia no levantamento 
de requisitos, pois nos documentos podem-se identificar os temos comuns do 
sistema que se pretende desenvolver e as informações necessárias para a 
empresa. 
 
A técnica de estudos etnográficos é proveniente das disciplinas de 
Antropologia, que consiste no estudo de um objeto por vivência direta da 
realidade onde este se insere. Permitindo analisar a componente social das 
tarefas desempenhadas numa dada organização tornam-se, no âmbito da 
Engenharia de Requisitos, extremamente úteis para ultrapassar a dificuldade 
que existe na recolha dos requisitos derivados de formas rotineiras e tácitas de 
trabalhar. 
O objetivo deste estudo é identificar o modo como realmente as pessoas 
executam as suas funções que muitas vezes difere da forma como as 
definições dos processos sugerem que elas devem fazer; como ocorre a 
cooperação e conhecimento das atividades entre as pessoas. 
Esta técnica se refere a uma análise da componente social das tarefas 
desempenhadas numa dada organização. Quando um dado conjunto de tarefas 
se torna rotineiro para uma pessoa, é de esperar que esta sinta dificuldade em 
articular todos os passos que segue ou todas as pessoas com as quais 
interage. Através de uma observação direta das atividades realizadas durante 
um período de trabalho de um funcionário é possível encontrar requisitos que 
não seriam observáveis usando técnicas convencionais. Esta observação pode 
ser acompanhada de registros áudio/vídeo, porém não convém usá-los em 
demasia visto que o tempo necessário para os processar pode ser demasiado. 
Nesta técnica assume-se que o interessado observado desempenha as suas 
funções "corretamente“. Portanto, é necessário ter cuidado na escolha do(s) 
interessado(s) a observar. 
 
Outra alternativa para levantamento de requisitos é a utilização de Cenários. 
Esta técnica pode ser definida como uma forma de levar as pessoas a imaginar 
o comportamento de um sistema. Através de exemplos práticos descritivos do 
comportamento de um sistema, os seus usuários podem comentar acerca do 
seu comportamento e da interação que esperam ter com ele. Trata-se de uma 
abordagem informal, prática e aplicável a qualquer tipo de sistema. De um 
modo geral, os cenários devem incluir os seguintes elementos: 
• Estado do sistema no início do cenário; 
• Sequência de eventos esperada (na ausência de erros) no cenário; 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 41 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 14 de 88 
• Listagem de erros que podem ocorrer no decorrer dos eventos do 
cenário e de como estes erros serão tratados; 
• Outras atividades que podem ser executadas ao mesmo tempo que as 
deste cenário; 
• Estado do sistema depois de o cenário terminar. 
Pode-se, também, aplicar entrevistas com representantes dos usuários do 
sistema. Nestas entrevistas, em geral, são aplicados os seguintes tipos de 
questões: 
• Questões subjetivas: permitem respostas “abertas” 
o O que você acha de ...? 
o Explique como você ...? 
 
• Questões objetivas: limitam as respostas possíveis 
o Ex: Quantos ...? Quem ...? 
o Quanto tempo ...? Qual das seguintes informações ...? 
Estas entrevistas podem ser estruturadas de diferentes formas: 
• Estrutura de Pirâmide - inicia com questões bastante detalhadas, 
geralmente objetivas, e, à medida que a entrevista progride, questões 
mais gerais, subjetivas, são colocadas; 
• Estrutura de Funil - inicia com questões gerais subjetivas e, à medida 
que a entrevista avança, perguntas mais específicas, usando questões 
objetivas, são feitas; 
• Estrutura de Diamante - combinação das duas estruturas anteriores, 
começa com questões objetivas (específicas), passa para questões 
gerais e fecha com questões específicas; e 
• Não estruturada. 
 
Quanto à questão, como os itens II, III e IV são verdadeiros, a resposta é a 
letra E. 
Gabarito: letra E. 
 
9. (Cesgranrio/Petrobrás/Engenharia de Software/2008) Estudos 
baseados na análise de diversos projetos de desenvolvimento de software 
sugerem que tais projetos têm maior chance de sucesso quando empregam 
metodologia e gerenciamento alinhados ao paradigma de desenvolvimento 
de novos produtos, em contraponto ao paradigma de produção industrial. 
Com base nessas observações, a maioria das metodologias modernas de 
desenvolvimento de software recomenda: 
 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 15 de 88 
(A) concluir o trabalho de especificações dos requisitos do sistema, antes de 
iniciar as atividades de projeto e implementação. 
(B) planejar detalhadamente no início do projeto todas as fases e atividades 
do mesmo, de forma que seja possível estimar com precisão o esforço 
necessário e os prazos de cada atividade. 
(C) providenciar, desde o início do projeto, mecanismos para prevenir e 
bloquear solicitações de mudanças de forma a garantir que será entregue 
exatamente o que foi especificado. 
(D) dividir o trabalho em iterações curtas, com prazos fixos, e não permitir 
que as mesmas avancem sobre os prazos, reduzindo o escopo da iteração, 
se necessário. 
(E) não produzir documentação técnica para o sistema, tendo em vista que 
a mesma já nasce condenada a ficar desatualizada, investindo melhor o 
tempo em atividades de implementação e testes exaustivos. 
 
Comentários 
Item a. Item errado. Abordagem antiga, que apresenta inconvenientes, usada 
no modelo em Cascata. 
Item b. Item errado. Realizar essa estimativa com precisão logo no início é 
bastante difícil. 
Item c. Item errado. Não se tem essa exigência de providenciar, desde o início 
do projeto, mecanismos para prevenir e bloquear solicitações de mudanças. 
Isso contradiz com metodologias de desenvolvimento modernas. 
Item d. Item correto. A maioria das metodologias modernas de 
desenvolvimento de software recomenda a divisão do trabalho em iterações 
curtas, com prazos fixos, e não permitir que as mesmas avancem sobre os 
prazos, reduzindo o escopo da iteração, em caso de necessidade. 
Item e. Item errado Recomenda-se documentar pelo menos o essencial! 
Gabarito: letra D. 
 
10. (Cesgranrio/IBGE/Desenvolvimento/2009) Os processos de 
desenvolvimento de software utilizam, muitas vezes, procedimentos 
estatísticos para, por exemplo, apoiar a tomada de decisão. Dentro desse 
contexto, o Diagrama de Pareto é baseado na clássica regra de que 
(A) 20% das ocorrências causam 80% dos problemas. 
(B) 60% das amostras de um processo normal encontram-se nos limites do 
desvio padrão. 
(C) pontos fora dos limites de um desvio padrão revelam a ocorrência de 
problemas aleatórios. 
(D) três pontos consecutivos abaixo da média indicam um processo em 
melhoria contínua. 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 16 de 88 
(E) um índice de erro acima dos cinco sigmas indica um processo que 
alcançou a qualidade. 
 
 
 
Comentários 
Importante A Lei de Pareto (também conhecido como princípio 80-20), 
afirma que para muitos fenômenos, 80% das consequências advém de 20% 
das causas. 
Na questão, tem-se a Lei do Pareto na letra A, que destaca que 20% das 
ocorrências causam 80% dos problemas. 
Uma outra adaptação do princípio de Pareto: 80% de uma aplicação pode ser 
entregue em 20% do tempo total do projeto. 
Gabarito: letra A. 
 
11. (Cesgranrio/Petrobrás/Processo de Negócios/2010) Existem 
vários Modelos de Ciclo de Vida do Processo de Software. O 
desenvolvimento em espiral é um modelo 
(A) iterativo. 
(B) para modificar requisitos. 
(C) para analisar componentes. 
(D) para analisar interface gráfica. 
(E) para modularizar o sistema. 
 
Comentários 
Um modelo de ciclo de vida do software deve conter a descrição precisa 
dos produtos de software gerados e dos critérios de término para cada fase, 
pois sem os mesmos o modelo em questão é considerado de pouca utilidade 
prática. 
A escolha de um modelo de processo de software deve considerar as 
características do sistema, os métodos e as ferramentas a serem utilizados, os 
prazos e custos e ainda, os produtos de software a serem entregues. Alguns 
exemplos de modelos de ciclo de vida: Modelo em Cascata, Modelo 
Incremental, Modelo Espiral, etc. 
O Modelo Espiral foi proposto por Boehm, em 1988, como forma de 
integrar os diversos modelos existentes, eliminando suas dificuldades 
e explorando seus pontos fortes. Combina a natureza iterativa da 
prototipagem com os aspectos controlados e sistemáticos do modelo cascata. 
Iterações sucessivas constroem um conjunto de artefatos a partir do 
estado em que estes foram deixados ao término da iteração passada. 
 
de
jan
ira
 be
ze
rra
 de
 fr
eit
0125
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 17 de 88 
Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que 
consiste em várias iterações. Uma iteração incorpora um conjunto quase 
sequencial de atividades em modelagem de negócios, requisitos, análise e 
projeto, implementação, teste e implantação, em várias proporções, 
dependendo do local em que ela está localizada no ciclo de desenvolvimento. 
 
No modelo Espiral, assume-se que o processo de desenvolvimento ocorre 
em ciclos, cada um contendo fases de avaliação e planejamento onde a opção 
de abordagem para a próxima fase (ou ciclo) é determinada. Neste modelo 
acrescenta-se a Análise dos Riscos ao ciclo de vida para auxiliar as 
decisões a respeito da próxima iteração. A próxima figura apresenta o 
esquema deste modelo. 
 
 
Comunicação com o 
cliente
Planejamento
Análise de 
Risco
Engenharia 
Construção e EntregaImplantação
 
Apesar desse modelo reunir as melhores características dos outros, algumas 
críticas podem ser feitas: 
• Exige gerentes e técnicos experientes; 
• Uma vez que o modelo em espiral pode levar ao desenvolvimento em 
paralelo de múltiplas partes do projeto, as tarefas gerenciais para 
acompanhamento e controle do projeto são mais complexas; 
• É necessário o uso de técnicas específicas para estimar e sincronizar 
cronogramas, bem como para determinar os indicadores de custo e 
progresso mais adequados. 
Gabarito: letra A. 
 
12. (ESAF/2007/SEFAZ-CE) Analise a descrição a seguir. 
O paradigma do ciclo de vida clássico da engenharia de software abrange seis 
atividades. Na atividade de _____________ são traduzidas as exigências de 
uma representação do software que podem ser avaliadas quanto à qualidade 
antes que se inicie a codificação. 
Escolha a opção que preenche corretamente a lacuna acima. 
a) análise 
b) engenharia de sistemas 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 18 de 88 
c) teste e análise de riscos 
d) coleta de requisitos 
e) projeto 
 
Comentários 
Como todo produto industrial, o produto de software tem seu ciclo de vida: 
• ele é concebido para tentar atender a uma necessidade; 
• é especificado, quando essas necessidades são traduzidas em requisitos 
viáveis; 
• é desenvolvido, transformando-se em um conjunto formado por código e 
outros itens, como modelos, documentos e dados; 
• passa por algum procedimento de aceitação e é entregue a um cliente; 
• entra em operação, é usado, e sofre atividades de manutenção, quando 
necessário; 
• é retirado de operação ao final de sua vida útil. 
 
O ciclo de vida compreende muitas atividades, que são assunto das diferentes 
áreas da Engenharia de Software. 
 
A figura seguinte mostra um modelo do ciclo de vida clássico da 
engenharia de software, que é dividido em seis atividades. São elas: 
 
 
Figura. Modelo em Cascata proposto por Bezerra. 
 
• Levantamento de Requisitos: tem por objetivo propiciar que usuários e 
desenvolvedores tenham a mesma compreensão do problema a ser 
resolvido. 
• Análise: tem por objetivo construir modelos que determinam qual é o 
problema para o qual estamos tentando conceber uma solução de software. 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 19 de 88 
• Projeto: estágio no qual o modelo de análise terá de ser adaptado de tal 
modo que possa servir como base para implementação no ambiente alvo. 
• Codificação (implementação): a codificação do sistema é efetivamente 
executada. 
• Teste: consiste na verificação do software. 
• Implantação: entrada em produção do sistema. 
 
Foi mencionado nessa questão que a atividade procurada é realizada antes da 
atividade de codificação, ou seja, antes da implementação do sistema. 
A atividade que procuramos é responsável por descrever COMO o sistema será 
implementado, através da cobertura completa dos requisitos, traduzindo-os 
numa especificação (KRUCHTEN, 2003), e a resposta correta é Projeto! 
Gabarito: letra E. 
 
13. (ESAF/2007/SEFAZ-CE) Analise a seguinte descrição relacionada ao 
modelo espiral para a engenharia de software. 
O modelo espiral para a engenharia de software, além de abranger as 
características do ciclo de vida clássico e o da prototipação, apresenta um 
novo elemento, denominado _____________, que faltava a esses 
paradigmas. 
Escolha a opção que preenche corretamente a lacuna acima. 
a) análise de riscos 
b) planejamento 
c) engenharia 
d) projeto 
e) teste 
 
Comentários 
O modelo em espiral foi originalmente proposto por Boehm (BOEHM, 1988), 
em que a sequência de atividades é substituída pelo processo em espiral. Cada 
loop na espiral representa uma fase do processo de software. Dessa forma, 
segundo Sommerville (2007), o loop mais interno pode estar relacionado à 
viabilidade do sistema; o loop seguinte, à definição de requisitos; o próximo, 
ao projeto do sistema e assim por diante. 
Cada loop na espiral está dividido em quatro setores: 
• Definição de objetivos: os objetivos específicos dessa fase do projeto são 
definidos. As restrições sobre o processo e o produto são identificadas e um 
plano detalhado de gerenciamento é elaborado. Os riscos de projeto são 
identificados. Dependendo disso, estratégias alternativas podem ser 
planejadas. 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 20 de 88 
• Avaliação e redução de riscos. Para cada risco de projeto identificado, uma 
análise detalhada é realizada. Providências são tomadas para reduzir o 
risco. Por exemplo, se houver risco de que os requisitos não sejam 
aprovados, um protótipo do sistema poderá ser desenvolvido. 
• Desenvolvimento e validação. Após a avaliação de risco, um modelo de 
desenvolvimento para o sistema é selecionado. 
• Planejamento. O projeto é revisado e uma decisão é tomada para 
prosseguimento ao próximo loop da espiral. Se a decisão for pelo 
prosseguimento, serão elaborados planos para a próxima fase do projeto. 
Abortar um projeto se ele apresentar um alto fator de risco. 
A elaboração dos objetivos representa o início do ciclo em espiral, como 
desempenho e funcionalidade. Os caminhos alternativos para alcançar esses 
objetivos e as restrições impostas sobre cada um deles são, então, 
enumerados. Cada alternativa é avaliada em relação a cada objetivo e as 
fontes de riscos de projeto são identificadas. 
O próximo passo é resolver esses riscos por meio de atividades de coleta de 
informações, tais como análise mais detalhada, prototipação e simulação. 
Após a avaliação dos riscos, é realizada uma parte do desenvolvimento, 
seguida pela atividade de planejamento para a próxima fase do processo 
(SOMMERVILLE, 2007). 
 
 
 
Figura. Modelo espiral representando um ciclo de vida inteiro 
Fonte: (PRESSMAN, 1997). 
Gabarito: letra A. 
 
14. (UEL/POSCOMP/2010) Sobre o Ciclo de Desenvolvimento de 
Software, é correto afirmar: 
I. O desenvolvimento em cascata tem como base a ideia de desenvolver 
uma implementação inicial, mostrar e discutir tal implementação com o 
usuário e fazer seu aprimoramento por meio de versões subsequentes, até 
que um sistema adequado tenha sido desenvolvido. 
II. No modelo de processo de desenvolvimento em espiral, cada loop na 
espiral representa uma fase do processo de software. Este modelo exige a 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 21 de 88 
consideração direta dos riscos técnicos em todos os estágios do projeto e, 
se aplicado adequadamente, deve reduzir os riscos antes que eles se 
tornem problemáticos. 
III. O Rapid Application Development (Desenvolvimento Rápido de 
Aplicação) é um modelo de processo se software incremental que enfatiza 
um ciclo de desenvolvimento rápido. Este modelo é uma adaptação de 
modelo cascata, no qual o desenvolvimento rápido é conseguido com o uso 
de uma abordagem de construção baseada em componentes. 
IV. O modelo incremental combina elementos do modelo em cascata 
aplicado de maneira iterativa. Em um processo de desenvolvimento 
incremental, os clientes identificam (esboçam) as funções a serem 
fornecidas pelo sistema e a importância das mesmas. Em seguida, é 
definida uma série de estágios de entrega, com cada estágio fornecendo um 
subconjunto das funcionalidades do sistema. 
Assinale a alternativa correta. 
a) Somente as afirmativas I e II estão corretas. 
b) Somente as afirmativas I e III estão corretas. 
c) Somente as afirmativas III e IV estão corretas. 
d) Somente as afirmativas I, II e IV estão corretas. 
e) Somente as afirmativas II, III e IV estão corretas. 
 
Comentários 
Somente a alternativa I está incorreta, isso porque o modelo em cascata é 
sequencial, e cada uma das fases integrantes do mesmo é entrada para a 
próxima, o que significa que não existe uma etapa de implementação inicial e 
uma conversa com o usuário para aprimorar tal implementação, só na fase de 
entrega é que o desenvolvedor saberá se fora realizado o que o cliente 
desejava. 
Gabarito: letra E. 
 
15. (Cesgranrio/BR Distribuidora/Desenvolvimento/2008) Considere 
os seguintes elementos: 
I - baseados em cenários – como diagramas de casos de uso e de 
atividades; 
II - orientados a fluxos – como diagramas de fluxo de dados e de controle; 
III - baseados em classes – como diagramas de classes e de colaboração; 
IV - baseados em comportamentos – como diagramas de estado e de 
sequência. 
São elementos do modelo de análise de desenvolvimento de um sistema: 
(A) II e III, somente. 
(B) I, II e III, somente. 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 22 de 88 
(C) I, III e IV, somente. 
(D) II, III e IV, somente. 
(E) I, II, III e IV. 
 
Comentários 
Cabe destacar que a banca misturou elementos da análise estruturada com a 
análise orientada a objetos, mas todas as respostas estão corretas já que são 
elementos do modelo de análise e que podem fazer parte da análise de 
desenvolvimento de um sistema. 
Gabarito: letra E. 
 
16. (ESAF/2005/AFRF) Analise as seguintes afirmações relacionadas à 
análise e ao projeto orientados a objetos: 
I. O principal propósito do diagrama entidade relacionamento (E-R) é 
representar os objetos e suas relações. 
II. As tabelas de objetos de dados podem ser “normalizadas”, aplicando-se 
um conjunto de regras de normalização, resultando em um “modelo 
relacional” para os dados. Uma dessas regras especifica que: determinada 
instância de um objeto tem um e somente um valor para cada atributo. 
III. Um objeto em potencial não poderá ser utilizado ou considerado 
durante a análise se a informação sobre ele precisar ser lembrada para que 
o sistema possa funcionar. 
IV. Devido à característica da reusabilidade da orientação a objetos, a 
prototipação é um modelo de desenvolvimento de software que não pode 
ser considerado nem utilizado na análise orientada a objetos. 
 
Indique a opção que contenha todas as afirmações verdadeiras. 
a) I e III 
b) II e III 
c) III e IV 
d) I e II 
e) II e IV 
 
Comentários 
Item I. O diagrama de entidades descreve o modelo de dados de um 
sistema com alto nível de abstração. Ele é a principal representação do modelo 
de entidades e relacionamentos. É usado para representar o modelo conceitual 
do negócio. ITEM VERDADEIRO. 
Item II. As tabelas de objetos podem ser "normalizadas" aplicando-se um 
conjunto de regras de normalização, resultando num modelo relacional de 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 12 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 23 de 88 
dados. As regras de normalização, quando aplicadas às tabelas de objetos de 
dados, resultam em mínima redundância - ou seja, a quantidade de 
informações que precisamos manter para satisfazer um problema em particular 
é minimizada. ITEM VERDADEIRO. 
Item III. A identificação de objetos inicia-se ao examinar a declaração do 
problema ou ao executar uma "análise gramatical" da narrativa de 
processamento do sistema a ser construído. Objetos são determinados 
sublinhando-se cada nome ou cláusula nominal e colocando-se numa tabela. O 
objeto em potencial será útil durante a análise somente se a informação sobre 
ele precisar ser lembrada de forma que o sistema possa funcionar. Este deve 
ter um conjunto de operações identificáveis que podem mudar o valor de seus 
atributos de alguma forma. Esse conceito foi cunhado por Yourdon de 
informação retida, necessária para identificação de objetos, tornando-a falsa. 
ITEM FALSO. 
Item IV. Prototipação é uma abordagem baseada numa visão evolutiva do 
desenvolvimento de software, afetando o processo como um todo. Esta 
abordagem envolve a produção de versões iniciais, ou seja, protótipos 
(análogo a maquetes para a arquitetura) de um sistema futuro com o qual se 
pode realizar verificações e experimentações para se avaliar algumas de suas 
qualidades antes que o sistema venha realmente a ser construído. ITEM 
FALSO. 
Gabarito: letra D. 
 
17. (ESAF/2006/TRF) Analise as seguintes afirmações relacionadas a 
Análise e Projeto Orientados a Objetos: 
I. Um diagrama de estado para uma classe mostra os estados que os 
objetos dessa classe podem assumir e suas transições de estado para 
estado. 
II. Um diagrama de interação exibe as mensagens passadas entre objetos 
em run-time. 
III. Um diagrama de classe retrata uma série de elementos dinâmicos, 
juntamente com suas associações, estruturas de superclasses e subclasses 
e outros inter-relacionamentos dinâmicos. 
IV. Uma classe abstrata é geralmente utilizada como fonte para a geração 
de objetos em classes descendentes. 
Indique a opção que contenha todas as afirmações verdadeiras. 
a) II e III 
b) I e II 
c) III e IV 
d) I e III 
e) II e IV 
 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 24 de 88 
Comentários 
Item I. O Diagrama de Estados mostra todos os estados possíveis nos quais 
objetos de uma certa classe podem se encontrar e mostra quais os eventos 
que provocam mudanças entre estes estados. Os estados representam as 
condições dos objetos em um determinado momento. Os eventos representam 
incidentes que causam a mudança de um estado para outro. As linhas de 
transição descrevem o movimento de um estado para o outro. É este o tipo de 
diagrama adequado para modelar o fluxo de navegação entre páginas web. As 
páginas seriam encaradas como os objetos e os eventos de links e botões 
seriam modelados como os estímulos. ITEM VERDADEIRO. 
 
Item II. O Diagrama de Interação mostra vários objetos e as mensagens 
que são passadas entre estes objetos em um caso de uso. ITEM 
VERDADEIRO. 
 
Item III. O Diagrama de Classes mostra um conjunto de classes, interfaces e 
colaborações e seus relacionamentos. Estes são os diagramas mais 
encontrados em sistemas de modelagem orientados a objetos. São utilizados 
para ilustrar a visão estática do projeto de um sistema. Eles incluem classes 
ativas são empregados para direcionar a visão estática do processo de um 
sistema. Diante dessa questão, podemos observar que esse item está 
incorreto, pois a afirmativa diz que este diagrama retrata uma série de 
elementos dinâmicos. ITEM FALSO. 
 
Item IV. Uma classe abstrata está destinada apenas a servir como base para a 
criação de outras classes, quando criamos métodos e/ou propriedades na 
classe abstrata podemos desejar que eles sejam sobrepostos ou não. Se 
desejamos que um método seja sobreposto na classe que vai herdar da classe 
abstrata devemos prepará-los para serem sobrescritos. Logo esta não é 
utilizada para geração de objetos em classes descendentes. ITEM FALSO. 
Gabarito: letra B. 
 
18. (Cesgranrio/Petrobrás/Engenharia de Software/2008) Um 
princípio fundamental do Processo Unificado é 
(A) ser centrado em arquitetura. 
(B) empregar times auto-dirigidos e auto-organizados. 
(C) o desenvolvimento em cascata. 
(D) a programação em pares. 
(E) a propriedade coletiva do código fonte. 
 
Comentários 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 25 de 88 
Importante O Processo Unificado possui características específicas, como 
ser orientado a casos de uso, ser centrado na arquitetura, ser iterativo e 
incremental. Quanto ao princípio “ser centrado em arquitetura” cabe 
destacar: 
• A arquitetura é a visão de todos os modelos que juntos representam o 
sistema como um todo. 
• O conceito de arquitetura de software engloba os aspectos estáticos e 
dinâmicos mais significantes do sistema. A arquitetura cresce além das 
necessidades do empreendimento, como percebido pelos usuários e 
suporte, e refletido nos casos de uso. 
• “Significante” em um sistema depende do ponto de vista de cada 
desenvolvedor 
• A arquitetura também é influenciada por muitos outros fatores, como a 
plataforma na qual o software será implantado, os blocos de construção 
reutilizáveis, requisitos de desenvolvimento e requisitos não funcionais. 
• A arquitetura é a visão do projeto do sistema como um todo, destacando 
suas características mais importantes, mas sem entrar em detalhes. 
• O processo ajuda o arquiteto a concentrar-se nas metas corretas, como 
inteligibilidade, poder de recuperação para mudanças futuras e 
reutilização. 
• A relação existente entre casos de uso e a arquitetura é que os casos de 
uso estão ligados à funcionalidade de um sistema e a arquitetura, por 
sua vez está ligada à forma deste. 
• Funcionalidade e forma devem estar balanceadas para se alcançar um 
produto final de qualidade, ou seja, casos de uso e arquitetura devem 
estar ligados a tal ponto que o primeiro seja desenvolvido de acordo com 
a arquitetura, e esta por sua vez, forneça um ambiente para a realização 
de todos os requisitos dos casosde uso. 
• A arquitetura de um sistema deve ser projetada a ponto de permitir que 
o sistema evolua, não apenas durante o início de seu desenvolvimento, 
mas através de gerações futuras. 
• Para alcançar este objetivo, os arquitetos devem trabalhar com as 
funções chaves de um sistema, ou seja, os casos de uso chaves de um 
sistema. 
Gabarito: letra A. 
 
19. (Cesgranrio/Petrobrás/Engenharia de Software/2006) Um 
gerente de projeto decidiu utilizar o Processo Unificado (RUP – rational 
unified process) como seu processo de desenvolvimento de software. Com 
base no RUP, quais os objetivos que o gerente deve direcionar para a fase 
de Elaboração? 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 26 de 88 
(A) Produzir Documento Visão completo e estável; detalhar os atores e 
casos de uso chave; determinar pelo menos uma solução possível para o 
problema. 
(B) Produzir Documento Visão completo e estável; fazer o design dos casos 
de uso críticos; obter um entendimento mais detalhado dos requerimentos. 
(C) Fazer o design dos casos de uso críticos; obter um entendimento mais 
detalhado dos requerimentos; implementar e testar cenários críticos. 
(D) Fazer o design do Banco de Dados; implementar e testar cenários 
críticos; liberar uma versão beta do produto. 
(E) Detalhar os atores e casos de uso chave; fazer o design, 
implementação, validação e estabelecer uma linha de base para a 
arquitetura; determinar pelo menos uma solução possível para o problema. 
 
Comentários 
O Rational Unified Process (RUP) é um exemplo de modelo de processo de 
desenvolvimento baseado no Unified Process (Processo Unificado) desenvolvido 
pela Rational. 
Segundo Philippe, Kruchten, no seu livro Introdução ao RUP – Rational Unified 
Process O RUP (Rational Unified Process) é um processo de engenharia de 
software, o qual implementa as melhores práticas comerciais a fim de obter 
um processo de desenvolvimento de software bem definido. Tem o objetivo de 
assegurar a produção de sistemas de qualidade, de forma repetível e previsível 
e também que satisfaça as necessidades de seus usuários finais dentro de 
prazo e orçamento previsíveis. O RUP consiste em um processo de 
desenvolvimento Orientado a Objetos, utilizando-se da UML como 
padrão para representação dos modelos. 
O RUP oferece uma abordagem baseada em disciplinas para atribuir tarefas e 
responsabilidades dentro de uma organização de desenvolvimento. Sua meta 
é garantir a produção de software de alta qualidade que atenda às 
necessidades dos usuários dentro de um cronograma e de um orçamento 
previsíveis. 
 
O Rational Unified Process é um processo de desenvolvimento iterativo e 
incremental, no qual o software não é implementado em um instante no fim 
do projeto, mas é, ao contrário, desenvolvido e implementado em partes. A 
cada iteração deste processo utilizam-se quatro fases, a saber: Concepção, 
Elaboração, Construção e Transição. 
• Durante a Concepção ou Início (Inception) estabelece-se a lógica do 
domínio da aplicação para o projeto e decide o escopo do projeto. É aqui 
que se obtém o comprometimento do patrocinador do projeto para 
seguir adiante. Nesta fase compreende-se o problema da tecnologia 
empregada por meio da definição dos use cases mais críticos. Define-se 
aqui o caso de negócio e escopo do projeto. 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 27 de 88 
• Na Elaboração (Elaboration) coletam-se requisitos mais detalhados, 
faz uma análise e um projeto de alto nível para estabelecer uma 
arquitetura básica, e cria um plano para a construção do sistema. 
Deve-se analisar o domínio do problema, estabelecer a arquitetura, 
desenvolver o plano do projeto e eliminar elementos de alto risco. 
• A fase de Construção (Construction) consiste de várias iterações, 
nas quais cada iteração constrói software de qualidade de produção, 
testado e integrado, que satisfaz um subconjunto de requisitos de 
projeto. Cada iteração contém todas as fases usuais do ciclo de vida da 
análise, do projeto, da implementação e do teste. Desenvolve-se o 
software e prepara-se o mesmo para a transição para os usuários. Além 
do código, também são produzidos os casos de teste e a documentação. 
• Mesmo com este tipo de processo iterativo, algum trabalho tem que ser 
deixado para ser feito no fim, na fase de Transição (Transition). Nesta 
fase são realizados os treinamentos dos usuários e a transição do 
produto para utilização. Este trabalho pode incluir também testes beta e 
ajuste de performance. 
Os projetos variam de acordo com o volume de formalidade que eles têm. 
Projetos de muita formalidade têm muitos documentos formais a serem 
entregues, reuniões formais, encerramentos formais. Projetos de pouca 
formalidade podem ter uma fase de concepção que consiste de um bate-papo 
de uma hora com o patrocinador do projeto e um plano que cabe em uma 
folha de papel. Naturalmente quanto maior o projeto, mais formalidade 
precisa. O fundamental de cada fase ainda acontece, mas de formas bem 
diferentes. 
Após a fase de Transição de uma iteração completa, o produto pode voltar a 
percorrer cada uma das fases para se produzir uma nova versão do produto. 
Cada uma das quatro fases do RUP é dividida em iterações, onde cada 
uma delas é um ciclo completo de desenvolvimento resultando em uma versão 
de um produto executável que constitui um subconjunto do produto final. 
Cada iteração é organizada em fluxos de trabalho (workflows) de 
processo, com uma ênfase diferente em cada fase. 
Gabarito: letra C. 
 
Complementando…. 
 
Os fluxos de trabalho de processo do RUP são: 
• Gerenciamento de Projeto (Project Management); 
• Modelagem Comercial ou de Negócio (Business Modeling); 
• Requisitos ou Exigências (Requirements); 
• Análise e Projeto (Analisys & Design); 
• Implementação (Implementation); 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia LimaQuintão www.pontodosconcursos.com.br 28 de 88 
• Testes (Test); 
• Distribuição ou Entrega (Deployment); 
• Gerência de Configuração e Mudanças (Configuration and Change 
Management); e 
• Ambiente (Enviroment). 
 
A figura ilustrada a seguir apresenta o relacionamento entre as fases e o 
esforço de desenvolvimento em cada fluxo de trabalho de processo. 
 
O RUP é composto por nove disciplinas e quatro fases!!!! 
 
Figura. Fases e disciplinas do RUP. Fonte: (KRUCHTEN, 2003) 
Na figura, o eixo horizontal representa o tempo e mostra os aspectos do ciclo 
de vida do processo como se desdobra. Já o eixo vertical representa os fluxos 
essenciais do processo, que agrupa logicamente as atividades por natureza. 
 
20. (ESAF/2008/AFC/STN/ TI/Infraestrutura) No RUP (Rational Unified 
Process), a descrição de critérios de aceitação para o projeto ocorre na fase 
de 
a) Concepção. 
b) Elaboração. 
c) Construção. 
d) Transição. 
e) Testes. 
 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 29 de 88 
Comentários 
Item a. A fase de concepção contém os workflows necessários para que as 
partes interessadas (stakeholders) concordem com os objetivos, arquitetura e 
o planejamento do projeto. Se as partes interessadas tiverem bons 
conhecimentos, então, pouca análise será requerida. Caso contrário, uma 
análise maior será requerida. Como cita o RUP, o ideal é que sejam feitas 
iterações. Porém estas devem ser bem definidas quanto a sua quantidade e 
objetivos. Complementando, é na fase de Concepção que deve ser definido o 
escopo da versão, especificando o produto a ser gerado. É nessa etapa que se 
avaliará a viabilidade do projeto, pois neste momento os requisitos 
operacionais e os critérios de aceitação serão apresentados. Devem ser 
levantados os riscos que possam comprometer o andamento do projeto, 
levando em consideração questões de arquitetura. É pertinente também a 
aplicação de um cronograma preliminar. Dentre os produtos finais desta fase 
estão o cronograma, o diagrama de caso de uso inicial, o caso de uso do 
negócio que, quando aplicado em sistemas comerciais, deve fornecer uma 
estimativa de retorno do investimento e o protótipo preliminar (MAGALHÃES, 
2003). Item VERDADEIRO. 
Item b. A fase de elaboração será apenas para o projeto do sistema, 
buscando complementar o levantamento / documentação dos casos de uso, 
voltado para a arquitetura do sistema, revisa a modelagem do negócio para os 
projetos e inicia a versão do manual do usuário. Deve-se aceitar: visão geral 
do produto (incremento + integração) verificando se o mesmo está estável; se 
o plano do projeto é confiável; se os custos são admissíveis. Item FALSO. 
Item c. Na fase de construção, começa o desenvolvimento físico do software, 
produção de códigos, testes alfa e beta. Devem-se aceitar testes, e processos 
de testes estáveis, e se os códigos do sistema constituem "baseline". Item 
FALSO. 
Item d. Nesta fase ocorre a entrega ("deployment") do software, é realizado o 
plano de implantação e entrega, acompanhamento e qualidade do software. 
Produtos (releases, versões) devem ser entregues, e ocorrer a satisfação do 
cliente. Item FALSO. 
Item e. Não existe uma fase específica de testes no RUP. Os testes são 
realizados em todas as fases. Item FALSO. 
Gabarito: letra A. 
 
21. (ESAF/2008/MPOG) O RUP - Rational Unified Process é um modelo 
que identifica fases discretas no processo de software. Com referência ao 
RUP, é correto afirmar que: 
a) a disponibilização de ferramentas apropriadas de software para a equipe 
de desenvolvimento é um dos objetivos da fase denominada ambiente. 
b) uma descrição de arquitetura para o software é obtida na fase de 
construção. 
c) no modelo do RUP, as fases coincidem com as atividades do processo. 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
de
jan
ira
 be
ze
rra
 de
 fr
eit
01
25
06
14
12
0 d
eja
nir
a b
ez
er
ra
 de
 fr
eit
01
25
06
14
12
0 
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
d e j a n i r a b e z e r r a d e f r e i t 0 1 2 5 0 6 1 4 1 2 0
O conteúdo deste curso é de uso exclusivo de dejanira bezerra de freit01250614120, vedada, por quaisquer meios e a qualquer título, a sua
reprodução, cópia, divulgação e distribuição, sujeitando-se os infratores à responsabilização civil e criminal.
TI EM EXERCÍCIOS P/ MPOG 
ANALISTA EM TECNOLOGIA DA INFORMAÇÃO 
 
Prof
a
. Patrícia Lima Quintão www.pontodosconcursos.com.br 30 de 88 
d) as fases do RUP estão mais estritamente relacionadas aos negócios do 
que a assuntos técnicos. 
e) na fase de construção é construído o modelo de projeto e o protótipo 
arquitetural executável. 
 
Comentários 
Vamos à resolução da questão ☺... 
Item a. As fases encontradas no RUP são: Iniciação ou Concepção, 
Elaboração, Construção e Transição. Quando é mencionado que ambiente é 
uma fase, isso está INCORRETO, pois ambiente é um FLUXO (disciplina) do 
Processo Unificado da Rational. Esse fluxo representa o ambiente de trabalho 
da empresa que desenvolverá o projeto. Ele pode ser caracterizado pelo tipo 
de plataforma, pela rede, pela organização dos diretórios no qual ficarão os 
artefatos e os códigos fonte, pelo sistema de backup etc. Pode-se perceber que 
no final de cada iteração têm-se ajustes no ambiente. Esses ajustes podem ser 
do tipo: criação de diretórios, o backup das versões do software, etc. Item 
FALSO. 
Item b. A descrição da arquitetura de software é obtida na fase de 
elaboração!! A fase de construção está essencialmente relacionada ao 
projeto, programação e teste de sistema. As partes do sistema são 
desenvolvidas paralelamente e integradas durante esta fase. Ao concluir esta 
fase, você deve ter um sistema de software em funcionamento e a 
documentação associada pronta para ser liberada para os usuários. Item 
FALSO. 
Item c. As atividades podem ser repetidas várias vezes no mesmo artefato, 
inclusive de uma iteração para outra, quando o sistema é refinado e 
expandido. Em relação às fases, cada uma delas são divididas em iterações. 
Cada iteração é planejada, realiza uma sequência de atividades como: 
levantamento dos requisitos, análise e projeto, implementação, entre outras 
(KRUCHTEN, 2003). Item FALSO. 
Item d. As fases do RUP estão mais relacionadas aos negócios do que à parte 
técnica. A parte técnica fica por conta dos fluxos de trabalho, que são as 
iterações de cada fase. Sendo assim, seria descrito com maiores detalhes nos 
fluxos, como por exemplo, no fluxo de distribuição ou entrega. Item 
VERDADEIRO. 
Item e. Pois é na fase de elaboração que um protótipo executável de 
arquitetura é construído em uma ou mais iterações, dependendo da extensão, 
tamanho, risco e novidade do projeto (KRUCHTEN, 2003). Durante essa fase, a 
maioria dos casos de uso são especificados e detalhados. A arquitetura do 
sistema é projetada utilizando artefatos que podem ser estáticos ou dinâmicos. 
Neste instante são apresentados o Baseline completo do projeto, os 
componentes que formarão a equipe de desenvolvimento, etc. No final dessa 
fase os envolvidos devem estar aptos a planejar a fase de construção em 
detalhes. Item FALSO.