Aula 01

Engenharia de Software para Concursos - Curso Regular

Professor: Diego Carvalho
 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

AULA 01

SUMÁRIO PÁGINA
Apresentação 01
- Métodos Formais 03
- Modelo Baseado em Componentes 06
- Modelos Iterativos e Incrementais 14
- Modelos em Prototipagem 19
- Modelo em Espiral 32
Lista de Exercícios Comentados 56
Gabarito 68

16712855225

Prof. Diego Carvalho [Link] Pág. 1 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Engenharia de Software. Conceitos Básicos ou Gerais. Ciclo de vida do software. Modelos,

Metodologias ou Processos de Desenvolvimento de Software: Modelo em Cascata. Modelo Orientado
a Reuso. Modelo em Prototipagem, Modelo Evolucionário, Modelo Espiral, Modelo Formal, RAD, Modelo
Iterativo e Incremental. Processo Unificado: Conceitos Básicos, Dimensões Dinâmica, Estática e
Prática, Gráfico das Baleias, Fases (Iniciação, Elaboração, Construção e Transição), Disciplinas ou
Fluxo de Processos (Modelagem de Negócio, Requisitos, Análise e Projeto, Implementação, Teste,
Implantação, Gestão de Configuração e Mudança, Gestão de Projetos, Ambiente), Artefatos,
Atividades, Melhores Práticas, Principais Marcos, Princípios Chaves. Metodologias Ágeis de
Desenvolvimento de Software: Scrum, eXtreme Programming (XP), Feature-driven Development
(FDD), Test-driven Development (TDD), Acceptance Test-driven Development (ATDD), Kanban.
Definição de Requisito, Classificação de Requisitos (Funcional, Não- Funcional, Domínio; Produto,
Organizacional, Externo; Confiabilidade, Proteção, Desempenho, etc); Engenharia de Requisitos:
Estudo de Viabilidade, Elicitação e Análise de Requisitos, Especificação de Requisitos, Validação de
Requisitos, Gestão de Requisitos. Técnicas de Elicitação e Técnicas de Validação. Linguagem de
Modelagem: Unified Modeling Language (UML) 2.x – Contexto Histórico, Conceitos Básicos, Tipos de
Diagramas (Estruturais, Comportamentais, Interação). Diagramas de Classes, Componentes,
Implantação, Perfil, Objetos, Estrutura Composta, Pacotes, Máquina de Estados, Casos de Uso,
Atividades, Sequência, Comunicação, Interação Geral e Tempo. Conceitos Básicos do Paradigma
Estruturado. Conceitos Básicos de Orientação a Objetos: Classes, Objetos, Atributos, Métodos,
Mensagens, Abstração, Encapsulamento, Polimorfismo, Herança, Relacionamentos). Análise e
Projeto: Conceitos Básicos, Diferenças, Modelos, Classes de Fronteira, Controle e Entidade. Análise
de Pontos de Função: IFPUG – Definição e Contexto, Benefícios e Vantagens, Componentes de Dados
(AIE, ALI) e Transação (EE, SE, CE), Etapas do Procedimento de Contagem: Determinar Tipo de
Contagem, Determinar Escopo e Fronteira, Cálculo dos Pontos de Função Não-Ajustados, Cálculo do
Fator de Ajuste, Cálculo dos Pontos de Função Ajustados. NESMA - Tipos de Contagem e Deflatores.
Qualidade de Software: Garantia e Controle, Principais Características, Verificação & Validação,
Erro, Falha, Falta e Defeito. Testes de Software: Conceitos Básicos, Processo de Testes, Técnicas de
Testes (Teste Caixa Banca, Cinza e Preta), Níveis de Testes (Teste de Unidade, Módulo, Componente;
16712855225

Teste de Integração; Teste de Aceitação, Validação, Release; Teste de Sistema/Funcional). Tipos de

Testes: Carga, Estresse, Volume, Desempenho, Usabilidade, Cenários, Regressão, Back-to-Back,
Comparação, Recuperação, Alfa, Beta, Compatibilidade, Estático, Dinâmico). Arquitetura de
Software. Arquitetura em Camadas (Cliente/Servidor). Arquitetura MVC. Arquitetura Distribuída.
Arquitetura Hub. Arquitetura Microsserviços. Arquitetura Mainframe. Arquitetura Orientada a
Serviços (SOA): Conceitos Básicos, SOAP, WSDL, UDDI. REST. WS-Security. Interoperabilidade de
Sistemas. e- PING: Conceitos Básicos, Interoperabilidade, Escopo, Políticas Gerais, Segmentação,
Gestão. Acessibilidade de Sistemas. e-MAG 3.1: Conceitos Básicos, Acessibilidade, Acesso, Passos
para um Sítio Acessível, Segmentos, Recomendações. Engenharia de Usabilidade. Gerenciamento
Eletrônico de Documentos (GED). Portais Corporativos e Colaborativos.

Prof. Diego Carvalho [Link] Pág. 2 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

MÉTODOS FORMAIS

Agora vamos falar sobre os modelos específicos! Professor, por que esse nome? Bem,
é só para agrupar modelos que não se encaixam diretamente em outros grupos.
Comecemos pelos Métodos Formais, termo usado para indicar atividades que
contem com representações matemáticas de software, especificação formal, prova
de especificação, desenvolvimento transformacional, etc.

Esse modelo é utilizado em ambientes extremamente complexos. São bastante

lentos e dispendiosos, além de exigirem um treinamento intensivo. Em geral, são
16712855225

utilizados para o desenvolvimento de sistemas que necessitam de grande robustez

e confiabilidade diante da possibilidade de perda de vidas ou sério prejuízo, caso
haja falhas.

Os chamados Métodos Formais de Desenvolvimento de Software não são

amplamente usados no desenvolvimento de software industrial. A maioria das
empresas de desenvolvimento de software não os considera adequados com
relação aos seus custos para aplicá-los em seus processos de desenvolvimento de
software.

Prof. Diego Carvalho [Link] Pág. 3 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Contudo, a especificação formal é uma excelente maneira para descobrir erros de

especificação e apresentar a especificação do sistema de modo não ambíguo. As
poucas organizações que têm feito investimentos em métodos formais têm
constatado menos erros no software entregue aos clientes e tudo isso sem aumento
de custos.

Os métodos formais podem ser adequados em termos de custo caso seu uso seja
limitado a partes do núcleo do sistema e caso as empresas desejem fazer alto
investimento inicial nessa tecnologia. Professor, pode dar um exemplo de método
formal? Sim, o Método Cleanroom, que trata o desenvolvimento semelhante a uma
sala limpa de cirurgia.

16712855225

Prof. Diego Carvalho [Link] Pág. 4 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

(CESPE – – SERPRO – Analista de Sistemas) Para a especificação de software

e verificação de sistemas, uma alternativa que se fundamenta na matemática
discreta e na lógica é o modelo incremental.

Comentários:

Na verdade, a alternativa é a utilização de métodos formais!

Gabarito: E

ACERTEI ERREI

16712855225

Prof. Diego Carvalho [Link] Pág. 5 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

MODELO BASEADO EM COMPONENTES

Pessoal, vocês já pararam para pensar por que a disciplina de Engenharia de Software
é denominada Engenharia de Software? Vamos contar essa história: esse conceito
surgiu em 1968, em uma conferência organizada para discutir a Crise do Software.
Essa crise foi o resultado da introdução de circuitos integrados em computadores. E
isso era ruim, professor?

Não, pelo contrário! Desde o ingresso dos circuitos

integrados, tornou-se possível e viável fazer aplicações
16712855225

extremamente complexas. No entanto, o desenvolvimento

de software era bastante informal e incipiente, criando
softwares, cujo custo superava as previsões, não confiáveis,
difíceis de manter e de desempenho insatisfatório.

Naquela época, os custos de hardware estavam caindo, enquanto os custos de

software aumentavam rapidamente. Novas técnicas e métodos eram necessários
para controlar a complexidade inerente aos grandes sistemas de software. Agora eu
volto a perguntar: por que Engenharia de Software se chama Engenharia de
Software?

Prof. Diego Carvalho [Link] Pág. 6 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Por que foi uma tentativa de contornar a crise ao utilizar sólidos princípios de
Engenharia a fim de obter um software de maneira econômica, que seja confiável e
que trabalhe em máquinas reais, dando um tratamento mais sistemático e
controlado (comum à Engenharia) ao desenvolvimento de sistemas de software
complexos.

Pessoal, pensem comigo: a engenharia evolui seus métodos há centenas de anos,

enquanto o desenvolvimento de software é bastante recente! Logo, faz sentido
utilizar os conceitos consolidados de engenharia para melhorar seus processos de
desenvolvimento de software. Não acham? Ok, professor! Mas o que isso tem a ver
com reúso de componentes?

Ora, a Engenharia é especializada em produzir componentes reusáveis. Engenheiros

raramente fabricam um componente a partir do nada. Eles baseiam seus projetos
em componentes exaustivamente testados em outros sistemas. Quando se fala em
Modelo baseado em Componentes, refere-se a uma estratégia de engenharia de
software na qual o processo de desenvolvimento é voltado à reusabilidade.

E qual a vantagem disso? Isso resulta em redução de custos de produção e

manutenção, entregas mais rápidas e aumento de qualidade. A abordagem para
desenvolvimento de software Component-Based Software Engineering (CBSE) tem
utilizado o reúso como peça principal. Essa abordagem depende de uma grande
base de componentes reusáveis e algum framework de integração.

Galera, não há ainda valores precisos dos custos de diferentes atividades de

desenvolvimento de software nessa abordagem. Contudo, sabemos que os custos
de desenvolvimento são menores que os custos de integração e de teste. Esses
custos aumentam porque é necessário assegurar que os componentes utilizados
realmente satisfazem às especificações e funcionam com outros componentes.
16712855225

Agora voltando um pouco: o que seria exatamente um componente? Pressman

afirma que um componente é um bloco de construção modular! Em outras palavras,
é uma parte do sistema modular, executável, implantável, independente,
padronizada e reutilizável que encapsula a implementação e expõe um conjunto de
interfaces do sistema. Bacana?

Prof. Diego Carvalho [Link] Pág. 7 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

O Modelo Genérico de Engenharia de Software Baseada em Componentes:

 Especificação de Requisitos: tem o objetivo de traduzir as informações

coletadas durante a atividade de análise em um documento que define um
conjunto de requisitos de software. Devem ser incluídos dois tipos de
requisitos nesse documento: os Requisitos de Usuário e Requisitos de
Sistema.

 Análise de Componentes: nesta fase, é feita uma busca pelos componentes

16712855225

para implementar essa especificação. Geralmente, não existe uma

correspondência exata entre o componente encontrado e o procurado.
Muitas vezes, os componentes que podem ser usados fornecem apenas parte
da funcionalidade necessária.

 Modificação de Requisitos: os requisitos são analisados usando as

informações sobre os componentes encontrados, que são modificados para
refletir os componentes disponíveis. Quando as modificações são impossíveis,
a atividade de análise de componentes pode ser novamente realizada para
procurar alternativas.

Prof. Diego Carvalho [Link] Pág. 8 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

 Projeto de Sistema com Reúso: o framework do sistema é projetado ou um

framework existente é reutilizado. Os projetistas levam em consideração os
componentes reusados. Pode ser necessário projetar algum software novo
caso os componentes reusáveis não estejam disponíveis para aquisição para
o sistema.

 Desenvolvimento e Integração: software que não pode ser adquirido

externamente é desenvolvido e os componentes e os sistemas COTS são
integrados para criar os novos sistemas. A integração de sistema, neste
modelo, pode ser parte do processo de desenvolvimento, em vez de ser uma
atividade separada.

 Validação de Sistema: processo de verificação de se um sistema atende às

necessidades e expectativas do cliente. Professor, o que são Sistemas COTS?
Esse é o acrônimo de Commercial Off-The-Shelf, que é um conjunto de
soluções pré-fabricadas e disponíveis no mercado, podendo ser compradas
ou licenciadas, i.e., uma grande biblioteca de componentes prontos.

Os Componentes COTS são desenvolvidos por vendedores que os oferecem como

produtos, disponibilizam a funcionalidade almejada juntamente com as interfaces
bem definidas, sendo que essas interfaces permitem que o componente seja
integrado ao software a ser desenvolvido. O modelo de desenvolvimento baseado
em componentes incorpora muitas das características do modelo espiral.

Ele é evolucionário por natureza, demandando uma abordagem iterativa para a

criação de software. O modelo de desenvolvimento baseado em componentes
desenvolve aplicações a partir de componentes de software pré-empacotados e
conduz ao reúso do software; sendo que essa reusabilidade proporciona uma série
de benefícios mensuráveis aos engenheiros de software.
16712855225

Prof. Diego Carvalho [Link] Pág. 9 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

(CESPE – 2010 – TRE/BA – Técnico Judiciário – Programação de Sistemas) Na

engenharia de software baseada em componentes, na qual se supõe que partes
do sistema já existam, o processo de desenvolvimento concentra-se mais na
integração dessas partes que no seu desenvolvimento a partir do início. Essa
abordagem é baseada em reúso para o desenvolvimento de sistemas de
software.

Comentários:

Ora, a Engenharia é especializada em produzir componentes reusáveis. Engenheiros

raramente fabricam um componente a partir do nada. Eles baseiam seus projetos em
componentes exaustivamente testados em outros sistemas. Quando se fala em
Modelo baseado em Componentes, refere-se a uma estratégia de engenharia de
software na qual o processo de desenvolvimento é voltado à reusabilidade.

Percebam, portanto, que há uma concentração dos esforços mais na integração de

partes existentes do que no seu desenvolvimento desde o início.

Gabarito: C

(UFBA - - UFBA - Analista de Tecnologia da Informação No processo de

software baseado em componentes, cada componente projetado para reuso é
16712855225

uma entidade executável independente, que deve manipular exceções.

Comentários:

Agora voltando um pouco: o que seria exatamente um componente? Pressman

afirma que um componente é um bloco de construção modular! Em outras palavras,
é uma parte do sistema modular, executável, implantável, independente, padronizada
e reutilizável que encapsula a implementação e expõe um conjunto de interfaces do
sistema. Bacana?

Prof. Diego Carvalho [Link] Pág. 10 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Portanto, a primeira parte está correta! A segunda parte afirma que os componentes
devem manipular exceções. Concurseiro lê um “deve” e já fica de olho aberto! Na
verdade, de acordo com Sommerville:

“Os componentes não devem tratar as exceções por si mesmos, pois cada aplicação
terá seus próprios requisitos para tratamento de exceções. Antes, o componente deve
definir quais exceções podem surgir e publicá-las como parte da interface”.

Gabarito: E

(CESPE – – MPE/AM – Analista Judiciário – Analista de Sistemas) A utilização

de um modelo de desenvolvimento embasado em componentes é uma forma
de desenvolvimento em espiral que busca a reutilização de trechos de software
desenvolvidos e testados em projetos anteriores e armazenados em um
repositório.

Comentários:

Os Componentes COTS são desenvolvidos por vendedores que os oferecem como

produtos, disponibilizam a funcionalidade almejada juntamente com as interfaces
bem definidas, sendo que essas interfaces permitem que o componente seja integrado
ao software a ser desenvolvido. O modelo de desenvolvimento baseado em
componentes incorpora muitas das características do modelo espiral.

De fato, o modelo de desenvolvimento baseado em componentes incorpora

características do modelo em espiral, preconizando o uso de Componentes
Comerciais Prontos para Uso (COTS).

16712855225

Gabarito: C

(CESPE – 2004 – SERPRO – Analista de Sistemas) O grande objetivo do uso de

engenharia de software por componentes é a produção de software de alta
qualidade e baixo custo.

Comentários:

E qual a vantagem disso? Isso resulta em redução de custos de produção e

manutenção, entregas mais rápidas e aumento de qualidade. A abordagem para
desenvolvimento de software Component-Based Software Engineering (CBSE) tem

Prof. Diego Carvalho [Link] Pág. 11 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

utilizado o reúso como peça principal. Essa abordagem depende de uma grande base
de componentes reusáveis e algum framework de integração.

De fato, cria componentes de alta qualidade e baixo de produção e manutenção.

Gabarito: C

(CESPE – 2004 – SERPRO – Analista de Sistemas) Enquanto o reúso em

engenharia de software convencional está geralmente limitado à extensão e à
manutenção de um sistema específico, o reúso, em engenharia de software por
componentes, é um requisito de desenvolvimento, independentemente do
projeto em consideração.

Comentários:

E qual a vantagem disso? Isso resulta em redução de custos de produção e

manutenção, entregas mais rápidas e aumento de qualidade. A abordagem para
desenvolvimento de software Component-Based Software Engineering (CBSE) tem
utilizado o reúso como peça principal. Essa abordagem depende de uma grande base
de componentes reusáveis e algum framework de integração.

Portanto, a CBSE é uma abordagem dependente da reusabilidade para o

desenvolvimento do software.

Gabarito: C

(CESPE – 2004 – SERPRO – Analista de Sistemas) O uso de componentes pode

estar condicionado a regras de licenciamento. Essa preocupação, no entanto,
não existe se os componentes forem classificados como software livre.
16712855225

Comentários:

Validação de Sistema: processo de verificação de se um sistema atende às

necessidades e expectativas do cliente. Professor, o que são Sistemas COTS? Esse é o
acrônimo de Commercial Off-The-Shelf, que é um conjunto de soluções pré-
fabricadas e disponíveis no mercado, podendo ser compradas ou licenciadas, i.e., uma
grande biblioteca de componentes prontos.

Prof. Diego Carvalho [Link] Pág. 12 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Galera, há regras de licenciamento, sim. Não confundam componentes livres com

componentes gratuitos. Não é porque um software é classificado como software
livre que ele é grátis ou não possui regras de licenciamento.

Gabarito: E

(CESPE – 2008 – SERPRO – Analista de Sistemas) O modelo orientado a reúso

parte de um software existente para que se crie outro, no todo ou apenas em
parte de seus componentes.

Comentários:

Ora, a Engenharia é especializada em produzir componentes reusáveis. Engenheiros

raramente fabricam um componente a partir do nada. Eles baseiam seus projetos
em componentes exaustivamente testados em outros sistemas. Quando se fala em
Modelo baseado em Componentes, refere-se a uma estratégia de engenharia de
software na qual o processo de desenvolvimento é voltado à reusabilidade.

Portanto, parte de um software ou componente existente para se criar outro!

Gabarito: C

ACERTEI ERREI

16712855225

Prof. Diego Carvalho [Link] Pág. 13 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

MODELOS ITERATIVOS E INCREMENTAIS

Como foi dito anteriormente, o Modelo em Cascata acumulava riscos e vários

projetos começaram a fracassar ao utilizá-lo no mundo inteiro. Então surgiu o
Modelo Iterativo como uma tentativa de resolver esse problema de acúmulo de
riscos. Vejamos a diferença fundamental entre o Modelo em Cascata e o Modelo
Iterativo:

 No Modelo em Cascata, caso haja cem requisitos, analisa-se os cem

requisitos, projeta-se os cem requisitos, codifica-se os cem requisitos, testa-
16712855225

se os cem requisitos, e assim, por diante, sequencialmente.

 No Modelo Incremental, caso haja cem requisitos no projeto, divide-se os

cem requisitos em vinte miniprojetos de cinco requisitos e utiliza-se o modelo
em cascata para cada miniprojeto.

Galera, pensem só: é possível combinar a abordagem incremental com uma

abordagem iterativa para desenvolver os miniprojetos em paralelo e entregar partes
diferentes do projeto. A imagem abaixo apresenta os miniprojetos de cinco
requisitos sendo feitos iterativamente e paralelamente em um modelo iterativo e
incremental.

Prof. Diego Carvalho [Link] Pág. 14 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Assim, os resultados são mais rápidos, há maior interação com o usuário e há um

feedback mais intenso – é possível reagir mais facilmente a mudanças. Essa
abordagem permite gerenciamento e mitigação de riscos. Professor, mas eu fiquei
com uma dúvida: qual a diferença entre Modelo Iterativo e Modelo Incremental? Ou
eles são exatamente a mesma coisa?

Bem, galera... eu nunca vi nenhuma prova cobrar essa diferença entre modelo
iterativo e modelo incremental! Na verdade, quando se fala em modelo iterativo,
presume-se que é incremental e quando se fala em modelo incremental, presume-
se que é iterativo. Eles frequentemente andam lado a lado, mas há pequenas
diferenças.

IMPORTANTE
16712855225

Galera, já vi essas palavras serem trocadas dezenas de vezes (inclusive no próprio edital).
No entanto, muitas vezes a própria banca erra e, às vezes, não volta atrás! Infelizmente isso
acontece =(

 Iterativo: reiterado ou repetitivo.

 Interativo: participação ou ação mútua.

Professor, mas e se cair em prova? Ora, caso caia em prova, a diferença é que, no
modelo incremental, há várias equipes desenvolvendo uma parte do software a

Prof. Diego Carvalho [Link] Pág. 15 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

serem integradas no fim e, no modelo iterativo, lança-se a versão 1.0, adicionam-se

funcionalidades, lança uma versão 2.0, adicionam-se mais funcionalidades e assim
por diante.

Modelo Incremental: observem que a imagem mostra um artista com uma ideia
completa sobre o quadro, mas ele desenvolve cada parte separadamente até
integrar as partes em uma imagem completa. É como se fosse um quebra-cabeças
em que cada parte é entregue funcionando e depois integrada. Produz builds, i.e.,
partes do software.

Modelo Iterativo: observem que a imagem mostra um artista com um esboço do

quadro, sendo que ele desenvolve várias versões do quadro até chegar ao resultado
final. É como se fosse uma visão abstrata da imagem, que em seguida vai sendo
melhorada até chegar a uma visão mais concreta. Produz releases, i.e., versões
constantemente melhoradas da imagem.

Uma das vantagens do modelo iterativo e incremental é que o cliente pode receber
16712855225

e avaliar as entregas do produto mais cedo, já no início do desenvolvimento do

software. Além disso, há maior tolerância a mudanças com consequência direta de
redução do risco de falha do projeto, i.e., ele acomoda melhor mudanças. Ele
aumenta o reúso e a qualidade.

Prof. Diego Carvalho [Link] Pág. 16 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

(CESPE - 2011 – TJ/ES - Analista Judiciário - Análise de Sistemas - Específicos) O

modelo de processo incremental de desenvolvimento de software é iterativo,
assim como o processo de prototipagem. Contudo, no processo incremental,
diferentemente do que ocorre no de prototipagem, o objetivo consiste em
apresentar um produto operacional a cada incremento.

Comentários:

De fato, no modelo iterativo e incremental, apresenta-se sempre um produto a cada

incremento. Já na prototipação, não. Idealmente, ele serve apenas para identificar
requisitos.

Gabarito: C

(CESPE - – TJ/DF - Analista Judiciário - Análise de Sistemas) No modelo de

desenvolvimento incremental, embora haja defasagem entre os períodos de
desenvolvimento de cada incremento, os incrementos são desenvolvidos em
paralelo.

Comentários:

Questão perfeita. Os incrementos são codificados não exatamente em paralelo – há

16712855225

uma pequena defasagem.

Gabarito: C

(CESPE - – UNIPAMPA - Análise de Sistemas) No modelo de

desenvolvimento incremental, a cada iteração são realizadas várias tarefas. Na
fase de análise, pode ser feito o refinamento de requisitos e o refinamento do
modelo conceitual.

Comentários:

Prof. Diego Carvalho [Link] Pág. 17 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Perfeito, é a fase seguinte à fase de requisitos e busca refiná-los.

Gabarito: C

ACERTEI ERREI

16712855225

Prof. Diego Carvalho [Link] Pág. 18 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

MODELOS EM PROTOTIPAGEM

A Prototipagem é utilizada quando não se conhece bem os requisitos. É uma forma

de entendê-los melhor para posteriormente desenvolver o software. Ela se
configura como um processo iterativo, interativo e rápido de desenvolvimento e o
protótipo serve como um mecanismo de identificação dos requisitos do software,
que servirão para uma futura especificação.

Um protótipo é uma versão inicial de um sistema de software utilizado para

demonstrar conceitos, experimentar opções de projeto e, geralmente, conhecer
16712855225

mais sobre o problema e suas possíveis soluções. Assim, os custos são controlados
e as partes interessadas do sistema podem experimentar o protótipo mais cedo no
processo de desenvolvimento. A Prototipagem pode ocorrer de duas maneiras:

Desenvolvimento Exploratório: objetivo do processo é trabalhar com o cliente

para explorar os requisitos e entregar um sistema final. O desenvolvimento
começa com as partes do sistema compreendidas. O sistema evolui por meio da
adição de novas características propostas pelo cliente.

Prototipação Throwaway: o objetivo do processo de desenvolvimento

evolucionário é compreender os requisitos do cliente e, a partir disso,

Prof. Diego Carvalho [Link] Pág. 19 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

desenvolver melhor definição de requisitos para o sistema. O protótipo se

concentra na experimentação dos requisitos mal compreendidos do cliente.

IMPORTANTE

Quando uma questão não especifica o tipo de prototipação, geralmente se trata de Prototipação
Throw-away/Descartável e, não, Evolucionária/Exploratória. Sommerville declara: “Uso o termo
prototipação no sentido de processo iterativo de desenvolvimento de um sistema experimental que
não é destinado à disponibilização ao cliente”.

Um protótipo de software pode ser utilizado em um processo de desenvolvimento

de diversas maneiras! Veremos três modos possíveis de utilização:

a) No processo de engenharia de requisitos, um protótipo pode ajudar na

descoberta e validação dos requisitos do sistema.

b) Processo de projeto do sistema, um protótipo pode ser usado para explorar

soluções específicas de software e apoiar o projeto de interface com o usuário.

c) No processo de teste, um protótipo pode ser usado para realizar testes

completos com o sistema que será entregue para o cliente.

A metodologia de Prototipagem Evolutiva (ou Evolucionária) é uma abordagem que

visualiza o desenvolvimento de concepções do sistema conforme o andamento do
projeto até chegar ao resultado final. Esta metodologia baseia-se na utilização de
prototipagem visual ou modelos do sistema final. Estes modelos podem ser simples
desenhos ou imagens do sistema.

Protótipos permitem que os usuários introduzam novas ideias para os requisitos e

16712855225

encontrem pontos fortes e fracos no software. Ademais, protótipos podem revelar

erros e omissões nos requisitos propostos, além de reduzirem o tempo e esforço de
desenvolvimento, treinamento e documentação o sistema. Professor, só há
vantagens? Não, há desvantagens também! Olha só...

Análise insuficiente, devido a desenvolvedores que se focam só no protótipo e

esquecem de analisar o problema global; usuários confundem protótipo com o
sistema final, sendo que serão descartados posteriormente; documentação pode ser
prejudicada; falta de visibilidade do progresso quando o sistema evolui, mas nunca
termina; tempo excessivo para desenvolver o protótipo; etc.

Prof. Diego Carvalho [Link] Pág. 20 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Como apresenta a imagem acima, o paradigma de prototipação começa com a

comunicação. Encontra-se com as partes interessadas para definir os objetivos
gerais do software, identificar os requisitos conhecidos e definir áreas em que uma
definição mais profunda é obrigatória. Uma iteração de prototipação é planejada
rapidamente e, então, ocorre a modelagem dessa iteração.

Um plano rápido se foca na representação daqueles aspectos do software que serão

visíveis aos usuários finais e leva à construção do protótipo. O protótipo é
implantado e avaliado pelas partes interessadas, que fornecem feedbacks que serão
utilizados para refinar os requisitos. A iteração ocorre à medida que o protótipo é
16712855225

ajustado para satisfazer as necessidades dos diversos stakeholders.

Ao mesmo tempo, ele ajuda a entender melhor o que precisa ser feito! Idealmente,
o protótipo serve como um mecanismo para identificar requisitos de software. Se
um protótipo será construído, pode-se utilizar partes existentes de programas ou
aplicar ferramentas que permitem que programas sejam gerados rapidamente. E o
que fazer com o protótipo construído?

Na maioria dos casos, o protótipo é inviável de ser utilizado, por ser muito lento
e/ou muito grande e/ou difícil de utilizar. Em geral, os protótipos são descartados
assim que os objetivos de levantamento de requisitos são alcançados. No entanto,

Prof. Diego Carvalho [Link] Pág. 21 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

alguns preferem refiná-los iterativamente até evoluir ao sistema final requisitado

pelo usuário. Captaram?

16712855225

Prof. Diego Carvalho [Link] Pág. 22 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

(CESPE – – UNIPAMPA – Analista de Sistemas) No modelo de

desenvolvimento prototipagem, um protótipo é desenvolvido para ajudar no
entendimento dos requisitos do sistema.

Comentários:

A Prototipagem é utilizada quando não se conhece bem os requisitos. É uma forma

de entendê-los melhor para posteriormente desenvolver o software. Ela se configura
como um processo iterativo, interativo e rápido de desenvolvimento e o protótipo
serve como um mecanismo de identificação dos requisitos do software, que servirão
para uma futura especificação.

Conforme vimos em aula, um protótipo é em geral desenvolvido para ajudar no

entendimento dos requisitos do sistema.

Gabarito: C

(CESPE – 2010 – E/MT – Analista de Sistemas - C) A metodologia de

prototipagem evolutiva é uma abordagem que visualiza o desenvolvimento de
concepções do sistema conforme o andamento do projeto, por meio de
protótipos visuais.

Comentários: 16712855225

A metodologia de Prototipagem Evolutiva (ou Evolucionária) é uma abordagem que

visualiza o desenvolvimento de concepções do sistema conforme o andamento do
projeto até chegar ao resultado final. Esta metodologia baseia-se na utilização de
prototipagem visual ou modelos do sistema final. Estes modelos podem ser simples
desenhos ou imagens do sistema.

Conforme vimos em aula, a questão está perfeita!

Gabarito: C

Prof. Diego Carvalho [Link] Pág. 23 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

(CESPE – 2004 – TRE/AL – Analista de Sistemas) No modelo de prototipação, o

desenvolvedor cria inicialmente um modelo de software que será posteriormente
implementado.

Comentários:

A metodologia de Prototipagem Evolutiva (ou Evolucionária) é uma abordagem que

visualiza o desenvolvimento de concepções do sistema conforme o andamento do
projeto até chegar ao resultado final. Esta metodologia baseia-se na utilização de
prototipagem visual ou modelos do sistema final. Estes modelos podem ser simples
desenhos ou imagens do sistema.

Na maioria dos casos, o protótipo é inviável de ser utilizado, por ser muito lento e/ou
muito grande e/ou difícil de utilizar. Em geral, os protótipos são descartados assim
que os objetivos de levantamento de requisitos são alcançados. No entanto, alguns
preferem refiná-los iterativamente até evoluir ao sistema final requisitado pelo
usuário. Captaram?

Conforme vimos em aula, cria-se, inicialmente, um modelo do sistema final! Além

disso, o protótipo pode ser implementado e se tornar esse sistema final. Galera, essa
questão foi retirada literalmente do Pressman (1995): "Prototyping is a process that
enables the construction of a model of the software which is to be built". Qual o
problema dessa questão? Sua tradução!

Pressman afirma que a Prototipação é um processo que permite ao desenvolvedor

a construção de um modelo software que será construído. Em outras palavras, a
prototipação é um modelo/esboço do software que posteriormente será construído.
Pensem em um software qualquer! Antes de construir o software, faremos um
modelo/esboço dele (não importando se iremos descartá-lo ou não).
16712855225

Gabarito: C

(CESPE – 2007 – TSE – Analista de Sistemas) Um possível objetivo da

prototipação é criar rapidamente um sistema experimental que possa ser
avaliado por usuários finais. Um protótipo aprovado pelos usuários pode vir a
ser usado como ponto de partida para a construção do sistema.

Comentários:

Prof. Diego Carvalho [Link] Pág. 24 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Na maioria dos casos, o protótipo é inviável de ser utilizado, por ser muito lento e/ou
muito grande e/ou difícil de utilizar. Em geral, os protótipos são descartados assim
que os objetivos de levantamento de requisitos são alcançados. No entanto, alguns
preferem refiná-los iterativamente até evoluir ao sistema final requisitado pelo
usuário. Captaram?

Conforme vimos em aula, é uma alternativa, i.e., posso usá-lo como ponto de
partida para construção do sistema, em vez de descartá-lo!

Gabarito: C

(CESPE – – MPE/AM – Analista de Sistemas) No modelo de prototipação,

a especificação de requisitos tem pouca importância, pois o software é
continuamente adaptado em função dos desejos do usuário.

Comentários:

A Prototipagem é utilizada quando não se conhece bem os requisitos. É uma forma

de entendê-los melhor para posteriormente desenvolver o software. Ela se configura
como um processo iterativo, interativo e rápido de desenvolvimento e o protótipo
serve como um mecanismo de identificação dos requisitos do software, que servirão
para uma futura especificação.

Conforme vimos em aula, a prototipação serve não só para o levantamento de

requisitos, mas também para sua especificação. Galera, como não tem importância?
É para isso que ele serve!

Gabarito: E
16712855225

(CESPE – – TJ/DF – Analista de Sistemas) Uma vantagem da prototipação

é promover a participação e o comprometimento do usuário em relação ao
sistema em desenvolvimento.

Comentários:

Protótipos permitem que os usuários introduzam novas ideias para os requisitos e

encontrem pontos fortes e fracos no software. Ademais, protótipos podem revelar
erros e omissões nos requisitos propostos, além de reduzirem o tempo de
desenvolvimento, treinamento e documentação o sistema. Professor, só há
vantagens? Não, há desvantagens também! Olha só...

Prof. Diego Carvalho [Link] Pág. 25 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Conforme vimos em aula, percebam que a prototipação promove uma grande

participação dos usuários no processo de desenvolvimento.

Gabarito: C

(CESPE – – TJ/DF – Analista de Sistemas) A prototipação de um software é

uma técnica de desenvolvimento não-interativa porque o teste do sistema só
ocorre na versão final.

Comentários:

A Prototipagem é utilizada quando não se conhece bem os requisitos. É uma forma

de entendê-los melhor para posteriormente desenvolver o software. Ela se configura
como um processo iterativo, interativo e rápido de desenvolvimento e o protótipo
serve como um mecanismo de identificação dos requisitos do software, que servirão
para uma futura especificação.

Conforme vimos em aula, ela é tanto iterativa (repete-se diversas vezes) quanto
interativa (conta com a participação ativa dos usuários).

Gabarito: E

(CESPE – – TJ/DF – Analista de Sistemas) Uma das finalidades da

prototipação é reduzir o esforço de desenvolvimento de um software.

Comentários:

Protótipos permitem que os usuários introduzam novas ideias para os requisitos e

16712855225

encontrem pontos fortes e fracos no software. Ademais, protótipos podem revelar

erros e omissões nos requisitos propostos, além de reduzirem o tempo e esforço de
desenvolvimento, treinamento e documentação o sistema. Professor, só há
vantagens? Não, há desvantagens também! Olha só...

Conforme vimos em aula, a questão está perfeita! Ela realmente ajuda a reduzir o
esforço!

Gabarito: C

Prof. Diego Carvalho [Link] Pág. 26 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

(CESPE – 2010 – INMETRO – Analista de Sistemas – Um dos benefícios da

prototipação é a documentação normalmente gerada, que facilita a manutenção
dos sistemas a longo prazo e a elaboração de casos de teste.

Comentários:

Análise insuficiente, devido a desenvolvedores que se focam só no protótipo e

esquecem de analisar o problema global; usuários confundem protótipo com o
sistema final, sendo que serão descartados posteriormente; documentação pode ser
prejudicada; falta de visibilidade do progresso quando o sistema evolui, mas nunca
termina; tempo excessivo para desenvolver o protótipo; etc.

Conforme vimos em aula, é justamente o inverso! A documentação geralmente é

prejudicada quando se utiliza a prototipação! Imaginem só: você precisa entregar
algo rápido para o usuário verificar se satisfaz seus requisitos, não é viável fazer uma
documentação formal.

Gabarito: E

10. (CESPE – 2010 – INMETRO – Analista de Sistemas – D) Um dos riscos da

prototipação é o usuário confundir o protótipo com o sistema verdadeiro e criar
falsas expectativas com relação a prazos e recursos.

Comentários:

Análise insuficiente, devido a desenvolvedores que se focam só no protótipo e

esquecem de analisar o problema global; usuários confundem protótipo com o
sistema final, sendo que serão descartados posteriormente; documentação pode ser
prejudicada; falta de visibilidade do progresso quando o sistema evolui, mas nunca
16712855225

termina; tempo excessivo para desenvolver o protótipo; etc.

Conforme vimos em aula, esse é um erro comum!

Gabarito: C

11. (CESPE – 2010 – INMETRO – Analista de Sistemas – E) Na abordagem evolutiva

para desenvolvimento de software, um protótipo do software é produzido e
utilizado para identificar possíveis problemas com os requisitos, sendo
descartado logo em seguida, e o desenvolvimento do software propriamente
dito é, então, iniciado.

Prof. Diego Carvalho [Link] Pág. 27 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Comentários:

A metodologia de Prototipagem Evolutiva (ou Evolucionária) é uma abordagem que

visualiza o desenvolvimento de concepções do sistema conforme o andamento do
projeto até chegar ao resultado final. Esta metodologia baseia-se na utilização de
prototipagem visual ou modelos do sistema final. Estes modelos podem ser simples
desenhos ou imagens do sistema.

Conforme vimos em aula, se o protótipo é descartado, então não se trata de uma

abordagem evolutiva!

Gabarito: E

12. (CESPE – 1 – – Analista de Sistemas) No modelo de prototipação, o

processo de desenvolvimento de software é modelado como uma sequência
linear de fases, enfatizando um ciclo de desenvolvimento de breve duração.

Comentários:

A Prototipagem é utilizada quando não se conhece bem os requisitos. É uma forma

de entendê-los melhor para posteriormente desenvolver o software. Ela se configura
como um processo iterativo, interativo e rápido de desenvolvimento e o protótipo
serve como um mecanismo de identificação dos requisitos do software, que servirão
para uma futura especificação.

Conforme vimos em aula, não é linear, mas iterativo!

16712855225

Gabarito: E

13. (CESPE – 2013 – TRT/10 – Analista Judiciário – Tecnologia da Informação) No

modelo prototipação, a construção de software tem várias atividades que são
executadas de forma sistemática e sequencial.

Comentários:

Na verdade, quem constrói software por meio de atividades executadas de forma

sistemática e sequencial é o Modelo em Cascata; a prototipação é iterativa.

Gabarito: E

Prof. Diego Carvalho [Link] Pág. 28 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

14. (CESPE – – TCE/RN – Assessor Técnico de Informática) A prototipação, uma

abordagem para desenvolvimento de software na qual se cria um modelo do
software que será implementado, é composta de quatro etapas: planejamento,
análise de risco, engenharia e avaliação do cliente.

Comentários:

Conforme vimos em aula, as etapas são Comunicação, Plano Rápido, Modelagem

de Plano Rápido, Construção do Protótipo, e Implementação, Entrega e Feedback.
As etapas mencionadas na questão são do Modelo em Espiral. Além disso, não será
necessariamente implementado.

Gabarito: E
16712855225

15. (CESPE – – DETRAN/DF – Analista de Sistemas) O modelo de processo de

desenvolvimento de software evolucionário parte do desenvolvimento de uma
implementação inicial cujos resultados são apresentados aos clientes e refinados
por meio de várias versões até que se alcance o sistema adequado. A
prototipação, como processo, tem por objetivo compreender as especificações
do software para se chegar aos requisitos para o sistema.

Comentários:

Desenvolvimento Exploratório: objetivo do processo é trabalhar com o cliente para

explorar os requisitos e entregar um sistema final. O desenvolvimento começa

Prof. Diego Carvalho [Link] Pág. 29 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

com as partes do sistema compreendidas. O sistema evolui por meio da adição

de novas características propostas pelo cliente.

Prototipação Throwaway: o objetivo do processo de desenvolvimento

evolucionário é compreender os requisitos do cliente e, a partir disso, desenvolver
melhor definição de requisitos para o sistema. O protótipo se concentra na
experimentação dos requisitos mal compreendidos do cliente.

Conforme vimos em aula, a Prototipação Throwaway busca, na verdade,

compreender os requisitos para chegar à especificação – a segunda sentença
inverteu esses conceitos!

Gabarito: E

16. (CESPE – – TJ/DF – Analista de Sistemas) A prototipação evolucionária

permite que a versão inicial do protótipo seja desenvolvida e refinada em
estágios sequenciados, até que se chegue à versão final do sistema.

Comentários:

Um protótipo é uma versão inicial de um sistema de software utilizado para

demonstrar conceitos, experimentar opções de projeto e, geralmente, conhecer mais
sobre o problema e suas possíveis soluções. Assim, os custos são controlados e as
partes interessadas do sistema podem experimentar o protótipo mais cedo no
processo de desenvolvimento. A Prototipagem pode ocorrer de duas maneiras:

Desenvolvimento Exploratório: objetivo do processo é trabalhar com o cliente para

explorar os requisitos e entregar um sistema final. O desenvolvimento começa
com as partes do sistema compreendidas. O sistema evolui por meio da adição
16712855225

de novas características propostas pelo cliente.

Conforme vimos em aula, a questão está perfeita! Trata da prototipação

evolucionária ou exploratória.

Gabarito: C

17. (CESPE – 2011 – MEC – Análise de Sistemas) No modelo de prototipação, o

processo de desenvolvimento de software é modelado como uma sequência
linear de fases, enfatizando um ciclo de desenvolvimento de breve duração.

Prof. Diego Carvalho [Link] Pág. 30 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Comentários:

Na verdade, não é linear – é iterativo.

Gabarito: E

18. (VUNESP - 2009 - CETESB - Analista de Tecnologia da Informação - Banco de

Dados) Considere um sistema cujos requisitos de interface são definidos apenas
quando o cliente realiza um test-drive na aplicação e aprova essa interface.
Assinale a alternativa que apresenta o modelo mais adequado para o
desenvolvimento da interface desse sistema.

a) Ágil.
b) Cascata.
c) Iterativo incremental.
d) Prototipação.
e) Rapid Application Development.

Comentários:

A Prototipagem é utilizada quando não se conhece bem os requisitos. É uma forma

de entendê-los melhor para posteriormente desenvolver o software. Ela se configura
como um processo iterativo, interativo e rápido de desenvolvimento e o protótipo
serve como um mecanismo de identificação dos requisitos do software, que servirão
para uma futura especificação.

A afirmativa diz que o sistema possui requisitos de interface que são definidos
apenas quando o cliente realiza um test-drive, i.e., um teste inicial na aplicação e
aprova essa interface. Em outras palavras, o cliente valida ou não esses requisitos a
16712855225

partir de uma primeira utilização do sistema. Que metodologia de desenvolvimento

de software pode ser utilizada para levantar e validar/aprovar requisitos? Trata-se da
Prototipação!

Gabarito: D

ACERTEI ERREI

Prof. Diego Carvalho [Link] Pág. 31 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

MODELO EM ESPIRAL

O Modelo em Espiral
foi proposto
originalmente, em
1988, por Boehm. Sua
ideia era representar
um processo de
software orientado a
riscos. Em vez de
16712855225

representar o processo
como uma sequência
de atividades com
lgum retorno entre
uma atividade e outra,
o processo
representado como
uma espiral. Ele
combina atividades de
desenvolvimento com
aspectos gerenciais (Planejamento, Tomada de Decisão, Análise de Riscos, etc).

Prof. Diego Carvalho [Link] Pág. 32 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

É conhecido como prototipagem-em-etapas, por combinar o modelo em cascata

com a prototipação. Cada loop representa uma fase do processo de software. Dessa
forma, o loop mais interno pode estar relacionado à viabilidade do sistema; o
próximo loop, à definição de requisitos; o próximo, ao projeto de sistema e assim
por diante. De acordo com Sommerville, divide-se em quatro setores:

 Determinar objetivos, alternativas e restrições: definem-se os objetivos da do

projeto (aumentar performance, consertar funcionalidade, melhorar
qualidade), identificam-se alternativas (reúso de componentes, comprar
pronto) e identificam-se restrições impostas (custo, cronograma, etc).

 Avaliar alternativas, identificar e resolver riscos: avaliam-se as alternativas

identificadas em relação aos objetivos e restrições. Frequentemente, esse
processo identifica áreas de incerteza (custos excessivos, falta de recursos) e
resolve ou reduz os riscos identificados - um protótipo pode ser construído.

 Desenvolv e test : após a redução dos riscos, um modelo de

desenvolvimento para o sistema é selecionado (Ex: prototipação
evolucionária, modelos formais, modelo em cascata, modelos baseados em
componentes). O software é desenvolvido e, posteriormente, testado.

 Planejar próximas fases: revisa-se o projeto e decide-se sobre o

prosseguimento ao próximo loop da espiral. Se a decisão for pelo
prosseguimento, são elaborados planos para a próxima fase do projeto, e
terminamos um loop.

De acordo com Pressman, cada espiral é dividida em cinco setores 1:

16712855225

 Comunicação: é a comunicação em si;

 Planejamento: estimativa de custos, cronograma e análise de riscos;
 Modelagem: análise e design;
 Construção: codificação e teste;
 Implantação: entrega e feedback;

1
Na versão anterior, eram seis etapas no Modelo em Espiral (Planejamento, Análise de Riscos, Engenharia,
Construção e Liberação, Avaliação do Cliente e Comunicação com Cliente). Variações do modelo consideram
entre três e seis setores da espiral. Infelizmente, cada autor pega a versão original e adapta, criando sua versão.
Portanto, vocês verão muitos nomes diferentes para cada setor.

Prof. Diego Carvalho [Link] Pág. 33 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

IMPORTANTE

Cada loop na espiral representa uma fase no processo, entretanto essas fases não são fixas, i.e., escolhem-
se quais fases se deseja realizar. Já as atividades são fixas (Comunicação, Planejamento, etc), no entanto
não são obrigatórias. Em outras palavras, eu escolho as fases que eu desejo realizar (Ex: Para o meu
projeto, a primeira pode ser Viabilidade, a segunda Planejamento, a terceira Projeto, etc). As atividades são
fixas (Planejamento, Modelagem, Construção, Implantação, Comunicação), i.e., não posso criar uma nova
atividade. No entanto, não são obrigatórias, i.e., posso eventualmente não realizar todas as atividades.

16712855225

Vocês entenderam isso? O Pressman explica isso por meio da imagem acima!
Percebam que o loop mais interno (1) pode tratar do projeto de desenvolvimento
de conceito, o segundo loop (2) pode tratar do projeto de desenvolvimento de um
produto, o terceiro loop (3) pode tratar do projeto de melhoria e o último (4), mais
claro, pode tratar do projeto de manutenção. Pode tratar de todo ciclo de vida...

Cada loop é uma fase e a fase é escolhida de acordo com as necessidades do

negócio! Já as atividades do processo são fixas para todos os loops (não
obrigatórias). No entanto, Boehm utiliza uma divisão de atividades diferente do
Pressman. No caso de dúvida, considerem a versão original do Modelo de Boehm.
Além disso, ao final de cada loop, há uma tomada de decisão a respeito do projeto.

Prof. Diego Carvalho [Link] Pág. 34 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Vocês perceberam, pela imagem acima, que existem protótipos que são utilizados
para verificar a viabilidade do projeto. Ao final de cada loop na espiral, deve-se
decidir se o projeto continuará ou se será interrompido. Pessoal, por que esse
modelo se destaca em relação aos outros modelos? Porque ele enfatiza bastante um
aspecto que o diferencia dos demais: Análise de Riscos.

Este é um modelo complexo que precisa ser gerenciado por pessoas que tenham
grande experiência na avaliação de riscos. Geralmente, o modelo é utilizado em
sistemas críticos e grandes! Por fim, vamos ver um tema mais polêmico: ele é
evolucionário ou é incremental? Pressman diz que é iterativo, mas, não, incremental
– sendo, então, evolucionário. Logo, é nele em que vamos nos basear2!

O conceito essencial do modelo é minimizar os riscos pelo uso repetido de

protótipos e outros meios. Ao contrário de outros modelos, em cada fase a análise
de risco é realizada. O modelo funciona através da construção de versões
progressivamente mais completas do software, iniciando no centro da espiral para
o exterior. A cada volta, o cliente avalia o trabalho e são feitas sugestões.

O modelo, então, se diferencia por ter uma abordagem cíclica, para aumentar
incrementalmente o grau de definição e de implementação de um sistema
enquanto diminui seu grau de risco; e por ter conjunto de marcos de ancoragem,
para garantir o comprometimento dos interessados com soluções exequíveis e
mutuamente satisfatórias para o sistema.

VANTAGENS DESVANTAGENS
Suporta mecanismos de redução de riscos. Exige analistas de risco bastante experientes.

Obtêm-se versões do sistema a cada iteração. Exige uma equipe de desenvolvimento extremamente
16712855225

qualificada.
Entregando produtos cada vez mais refinados e de Exige um gerenciamento de processo mais complexo.
melhor qualidade.
Reflete as práticas reais de engenharia atual. Não é recomendado resolver problemas mais
simples e pequenos.
Apresenta uma abordagem sistemática.

Apresenta estimativas realísticas.

2
Apesar disso, é comum outros autores tratarem o Modelo em Espiral como iterativo e incremental.

Prof. Diego Carvalho [Link] Pág. 35 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

ESQUEMA

Somente com esse esquema, responde-se grande parte das questões a seguir...

16712855225

Prof. Diego Carvalho [Link] Pág. 36 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

(FCC - 2012 - TST - Analista Judiciário - Análise de Sistemas) O Ciclo de Vida de

um Sistema especifica todas as fases de desenvolvimento, desde sua concepção
até o processo de manutenção e declínio. No que diz respeito ao
desenvolvimento de software, existem alguns processos conhecidos. Um destes
processos, possui característica iterativa e incremental, inicia cada fase do projeto
realizando um planejamento prévio, realiza a execução da fase, verifica o
progresso e os resultados da fase (riscos, lições aprendidas) e incrementa novos
objetivos para a fase seguinte, seguindo para a próxima iteração. O processo de
software em questão é o:

a) Modelo espiral.
b) Ciclo de vida em cascata.
c) Modelo de desenvolvimento evolucionário (prototipação).
d) Modelo de desenvolvimento ágil.
e) Método de desenvolvimento Cleanroom (Sala Limpa).

Comentários:

Conforme vimos no esquema, ele citou todos os setores do Modelo Espiral (os
nomes estão um pouco diferentes, mas é apenas uma variação). Essa questão tem
um detalhe: ela afirma que o modelo espiral é iterativo e incremental, mas já vimos
que o Pressman afirma que ele é iterativo e evolucionário, mas não incremental.
16712855225

Gabarito: A

(FCC - 2010 - TRT - 20ª REGIÃO (SE) - Analista Judiciário - Tecnologia da

Informação) À medida que se avança pelo modelo ocorre uma iteração e o
software evolui para estágios superiores, normalmente com aumento da
complexidade. Cada iteração está provida das atividades determinadas pelos
quadrantes planejamento, avaliação de alternativas e riscos, desenvolvimento do
software e avaliação do cliente. No ciclo de vida de desenvolvimento de software,
trata-se da propriedade do modelo:

a) Cascata.

Prof. Diego Carvalho [Link] Pág. 37 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

b) Incremental.
c) Espiral.
d) Prototipação.
e) Balbúrdia.

Comentários:

Conforme vimos em aula, a questão fala de iteração, logo não pode ser Modelo em
Cascata! Por outro lado, a questão fala em avaliação de alternativas e riscos,
enfatizada (em verde em nosso esquema). Logo, trata-se claramente do Modelo em
Espiral. Percebam que a questão faz uma confusão com os setores de cada autor,
mas está correta.

Gabarito: C

(FCC - 2 0 – MPE/RN – Analista de Sistemas) O modelo em espiral difere

principalmente dos outros modelos de processo de software por:

a) não contemplar o protótipo.

b) reconhecer explicitamente o risco.
c) não ter fases.
d) possuir uma fase única evolucionária.
e) não contemplar o projeto do produto.

Comentários:

Vocês perceberam, pela imagem acima, que existem protótipos que são utilizados
para verificar a viabilidade do projeto. Ao final de cada loop na espiral, deve-se decidir
se o projeto continuará ou se será interrompido. Pessoal, por que esse modelo se
16712855225

destaca em relação aos outros modelos? Porque ele enfatiza bastante um aspecto
que o diferencia dos demais: Análise de Riscos.

Conforme vimos em aula, reconhecimento explícito no risco.

Gabarito: B

( - 2012 – TRE/CE – Analista de Sistemas) No desenvolvimento de software

em espiral (Boehm), cada loop está dividido em quatro setores. NÃO se trata da
denominação de um destes setores:

Prof. Diego Carvalho [Link] Pág. 38 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

a) levantamento.
b) definição de objetivos.
c) avaliação e redução de riscos
d) desenvolvimento e validação.
e) planejamento.

Comentários:

 Determinar objetivos, alternativas e restrições: definem-se os objetivos da do

projeto (aumentar performance, consertar funcionalidade, melhorar
qualidade), identificam-se alternativas (reúso de componentes, comprar
pronto) e identificam-se restrições impostas (custo, cronograma, etc).

 Avaliar alternativas, identificar e resolver riscos: avaliam-se as alternativas

identificadas em relação aos objetivos e restrições. Frequentemente, esse
processo identifica áreas de incerteza (custos excessivos, falta de recursos) e
resolve ou reduz os riscos identificados - um protótipo pode ser construído.

 Desenvolver e testar: após a redução dos riscos, um modelo de

desenvolvimento para o sistema é selecionado (Ex: prototipação evolucionária,
modelos formais, modelo em cascata, modelos baseados em componentes). O
software é desenvolvido e, posteriormente, testado.

 Planejar próximas fases: revisa-se o projeto e decide-se sobre o

prosseguimento ao próximo loop da espiral. Se a decisão for pelo
prosseguimento, são elaborados planos para a próxima fase do projeto, e
terminamos um loop.

Conforme vimos em aula, levantamento não é um dos setores.

16712855225

Gabarito: E

(FCC – 2010 – BAHIAGÁS – Analista de Sistemas) No modelo em espiral do

processo de software cada loop na espiral representa:

a) uma disciplina de requisitos.

b) um enfoque de banco de dados.
c) uma tomada de decisão.
d) uma fase do processo.
e) um ciclo de programa.

Prof. Diego Carvalho [Link] Pág. 39 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Comentários:

É conhecido como prototipagem-em-etapas, por combinar o modelo em cascata com

a prototipação. Cada loop representa uma fase do processo de software. Dessa forma,
o loop mais interno pode estar relacionado à viabilidade do sistema; o próximo loop,
à definição de requisitos; o próximo, ao projeto de sistema e assim por diante. De
acordo com Sommerville, divide-se em quatro setores:

Conforme vimos em aula, levantamento não é um dos setores.

Gabarito: B

(CESPE – 2011 – MEC – Gerente de Projetos) O modelo de processo denominado

em espiral combina as atividades de desenvolvimento com o gerenciamento de
riscos, de modo a minimizá-los e controlá-los.

Comentários:

Vocês perceberam, pela imagem acima, que existem protótipos que são utilizados
para verificar a viabilidade do projeto. Ao final de cada loop na espiral, deve-se decidir
se o projeto continuará ou se será interrompido. Pessoal, por que esse modelo se
destaca em relação aos outros modelos? Porque ele enfatiza bastante um aspecto
que o diferencia dos demais: Análise de Riscos.

Conforme vimos em aula, está perfeito!

Gabarito: C
16712855225

(CESPE – – TJ/DF – Analista Judiciário – Tecnologia da Informação) O

modelo em espiral é um modelo de processos de software que reúne a natureza
iterativa da prototipação com os aspectos sistemáticos e controlados do modelo
sequencial linear.

Comentários:

É conhecido como prototipagem- -etapas, por combinar o modelo em cascata com

a prototipação. Cada loop representa uma fase do processo de software. Dessa forma,
o loop mais interno pode estar relacionado à viabilidade do sistema; o próximo loop,

Prof. Diego Carvalho [Link] Pág. 40 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

à definição de requisitos; o próximo, ao projeto de sistema e assim por diante. De

acordo com Sommerville, divide-se em quatro etapas:

Conforme vimos em aula, Modelo em Espiral é também conhecido como

Prototipagem-Em-Etapas, por conta disso!

Gabarito: C

(CESPE – 2004 – COHAB – Analista Judiciário – Tecnologia da Informação) O

modelo espiral é um modelo de processo de software que combina a natureza
iterativa da prototipagem com os aspectos controlados e sistemáticos do modelo
sequencial linear.

Comentários:

É conhecido como prototipagem- -etapas, por combinar o modelo em cascata com

a prototipação. Cada loop representa uma fase do processo de software. Dessa forma,
o loop mais interno pode estar relacionado à viabilidade do sistema; o próximo loop,
à definição de requisitos; o próximo, ao projeto de sistema e assim por diante. De
acordo com Sommerville, divide-se em quatro etapas:

Conforme vimos em aula, está perfeito! Galera, eu não errei! Essa questão é quase
idêntica à anterior: é o CESPE copiando do CESPE!

Gabarito: C

(CESPE - – TJ/DF - Analista Judiciário - Tecnologia da Informação)

Empregando o modelo de desenvolvimento em espiral, o software é
desenvolvido em uma série de versões intermediárias incrementais.
16712855225

Comentários:

Este é um modelo complexo que precisa ser gerenciado por pessoas que tenham
grande experiência na avaliação de riscos. Geralmente, o modelo é utilizado em
sistemas críticos e grandes! Por fim, vamos ver um tema mais polêmico: ele é
evolucionário ou é incremental? Pressman diz que é iterativo, mas, não, incremental
– sendo, então, evolucionário. Logo, é nele em que vamos nos basear!

Conforme vimos em aula, o Pressman discorda! A questão fala que o software é

desenvolvido em uma série de versões intermediárias incrementais. Ora, modelos

Prof. Diego Carvalho [Link] Pág. 41 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

iterativos geram uma série de versões intermediárias; modelos incrementais geram

incrementos. Logo, pode-se assumir que a questão afirma que se trata de um
modelo iterativo e incremental. Pressman discorda, mas não é incomum autores
tratarem o modelo em espiral como iterativo e incremental.

Gabarito: C

10. (CESPE – 2010 – SERPRO - Analista – Desenvolvimento De Sistemas) O modelo

em espiral de ciclo de vida de software é iterativo e incremental, uma vez que a
mesma sequência de atividades relacionadas à produção de software é realizada
a cada ciclo da espiral.

Comentários:

IMPORTANTE

Cada loop na espiral representa uma fase no processo, entretanto essas fases não são fixas, i.e., escolhem-se
quais fases se deseja realizar. Já as atividades são fixas (Comunicação, Planejamento, etc), no entanto não são
obrigatórias. Em outras palavras, eu escolho as fases que eu desejo realizar (Ex: Para o meu projeto, a primeira
pode ser Viabilidade, a segunda Planejamento, a terceira Projeto, etc). As atividades são fixas (Planejamento,
Modelagem, Construção, Implantação, Comunicação), não posso criar uma atividade entre essas. No entanto,
não são obrigatórias, i.e., posso eventualmente não fazer três últimas fases.

Conforme vimos em aula, nem sempre a mesma sequência de atividades é

realizada. Portanto, questão errada!

Gabarito: E

11. (CESPE – 2010 – SERPRO - Analista – Desenvolvimento De Sistemas) O modelo

de desenvolvimento em espiral permite repensar o planejamento diversas vezes
16712855225

durante o desenrolar do projeto.

Comentários:

Este é um modelo complexo que precisa ser gerenciado por pessoas que tenham
grande experiência na avaliação de riscos. Geralmente, o modelo é utilizado em
sistemas críticos e grandes! Por fim, vamos ver um tema mais polêmico: ele é
evolucionário ou é incremental? Pressman diz que é iterativo, mas, não, incremental
– sendo, então, evolucionário. Logo, é nele em que vamos nos basear!

Prof. Diego Carvalho [Link] Pág. 42 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Conforme vimos em aula, ele é iterativo, portanto permite replanejamento a cada

nova iteração.

Gabarito: C

12. (CESPE - - ANTAQ - Analista Administrativo - Informática) O modelo em

espiral, que descreve o processo de desenvolvimento de um software, apresenta
uma espiral em que cada loop representa uma fase distinta desse processo. A
ausência de risco nesse modelo o diferencia dos demais modelos de software.

Comentários:

Vocês perceberam, pela imagem acima, que existem protótipos que são utilizados
para verificar a viabilidade do projeto. Ao final de cada loop na espiral, deve-se decidir
se o projeto continuará ou se será interrompido. Pessoal, por que esse modelo se
destaca em relação aos outros modelos? Porque ele enfatiza bastante um aspecto
que o diferencia dos demais: Análise de Riscos.

Na verdade, é a presença da Análise de Riscos que o diferencia.

Gabarito: E

13. (CESPE – – IPEA – Analista de Sistemas) O modelo espiral é um modelo

evolucionário de processo de software que combina a prototipagem com o
modelo em cascata. Contudo, a incerteza em relação ao número de ciclos
necessários para construir o projeto, leva tal abordagem a empregar o modelo
de métodos formais para viabilizá-lo.

Comentários: 16712855225

É conhecido como prototipagem- -etapas, por combinar o modelo em cascata com

a prototipação. Cada loop representa uma fase do processo de software. Dessa forma,
o loop mais interno pode estar relacionado à viabilidade do sistema; o próximo loop,
à definição de requisitos; o próximo, ao projeto de sistema e assim por diante. De
acordo com Sommerville, divide-se em quatro etapas:

Conforme vimos em aula, a primeira parte está perfeita! No entanto, não faz sentido
empregar o modelo de métodos formais porque não se sabe estimar o número de
ciclos para construir um projeto. Ele tem uma natureza iterativa que permite reduzirs
riscos a cada loop.

Prof. Diego Carvalho [Link] Pág. 43 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Gabarito: E

14. (CESPE – – UNIPAMPA – Analista de Sistemas) O modelo espiral admite

retorno às fases anteriores de desenvolvimento, suportando ainda a execução
paralela de fases.

Comentários:

Agora vamos analisar o Modelo em Espiral. Ele foi proposto originalmente, em 1988,
por Boehm. Sua ideia era, em vez de representar um processo de software orientado
a riscos. Em vez de representar o processo como uma sequência de atividades com
algum retorno entre uma atividade e outra, o processo é representado como uma
espiral.

Conforme vimos em aula, ele não admite retorno às fases anteriores e, como espiral
que é, não permite a execução paralela de fases.

Gabarito: E

15. (CESPE – – UNIPAMPA – Analista de Sistemas) O modelo em cascata é

linear e sequencial. Modelos como o espiral e o Rational Unified Process pregam
o desenvolvimento iterativo.

Comentários:

Este é um modelo complexo que precisa ser gerenciado por pessoas que tenham
grande experiência na avaliação de riscos. Geralmente, o modelo é utilizado em
sistemas críticos e grandes! Por fim, vamos ver um tema mais polêmico: ele é
16712855225

evolucionário ou é incremental? Pressman diz que é iterativo, mas, não, incremental

– sendo, então, evolucionário. Logo, é nele em que vamos nos basear!

Conforme vimos em aula, está perfeito!

Gabarito: C

16. (CESPE – 2004 – BASA – Analista de Sistemas) O modelo em espiral evolui à

medida que o processo avança, permitindo ao desenvolvedor e ao cliente
entenderem melhor os riscos e reagirem em cada nível evolucionário.

Prof. Diego Carvalho [Link] Pág. 44 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Comentários:

Vocês perceberam, pela imagem acima, que existem protótipos que são utilizados
para verificar a viabilidade do projeto. Ao final de cada loop na espiral, deve-se decidir
se o projeto continuará ou se será interrompido. Pessoal, por que esse modelo se
destaca em relação aos outros modelos? Porque ele enfatiza bastante um aspecto
que o diferencia dos demais: Análise de Riscos.

Conforme vimos em aula, está perfeito!

Gabarito: C

17. (CESPE – 2004 – PBV/RR – Analista de Sistemas) O modelo em espiral para

desenvolvimento de software é fundamentado no faseamento comumente
adotado em projetos de engenharia a partir da década de 70 do século passado.
Tal modelo considera as seguintes fases: análise de requisitos, definição, projeto,
implementação, integração e testes, operação e manutenção.

Comentários:

Conforme vimos em nosso esquema, as fases são: Comunicação, Planejamento,

Modelagem, Construção e Implantação. As fases mencionadas são do Modelo em
Cascata.

Gabarito: E

18. ESPE – 2004 – PBV/RR – Analista de Sistemas) O modelo em espiral de

desenvolvimento proposto por Boehm apresenta a análise de riscos como uma
das suas fases essenciais. 16712855225

Comentários:

Vocês perceberam, pela imagem acima, que existem protótipos que são utilizados
para verificar a viabilidade do projeto. Ao final de cada loop na espiral, deve-se decidir
se o projeto continuará ou se será interrompido. Pessoal, por que esse modelo se
destaca em relação aos outros modelos? Porque ele enfatiza bastante um aspecto
que o diferencia dos demais: Análise de Riscos.

Conforme vimos em aula, está errado! A análise de riscos não é uma fase, mas uma
atividade. No entanto, a banca não entendeu dessa maneira :(

Prof. Diego Carvalho [Link] Pág. 45 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Gabarito: C

19. (CESPE – 2004 – STJ – Analista de Sistemas) O modelo de desenvolvimento em

espiral requer a consideração dos riscos técnicos em todos os estágios ou
interações do projeto, o que permite reduzir os riscos antes que se concretizem.

Comentários:

Vocês perceberam, pela imagem acima, que existem protótipos que são utilizados
para verificar a viabilidade do projeto. Ao final de cada loop na espiral, deve-se decidir
se o projeto continuará ou se será interrompido. Pessoal, por que esse modelo se
destaca em relação aos outros modelos? Porque ele enfatiza bastante um aspecto
que o diferencia dos demais: Análise de Riscos.

Conforme vimos em aula, está perfeito, i.e., deve-se considerar os riscos para reduzi-
los.

Gabarito: C

(CESPE – 2004 – TRE/AL – Analista de Sistemas) O modelo de desenvolvimento

em espiral engloba o que há de melhor no modelo cascata e no modelo de
prototipação, acrescentando a análise de risco, inexistente nestes dois modelos.

Comentários:

Vocês perceberam, pela imagem acima, que existem protótipos que são utilizados
para verificar a viabilidade do projeto. Ao final de cada loop na espiral, deve-se decidir
se o projeto continuará ou se será interrompido. Pessoal, por que esse modelo se
16712855225

destaca em relação aos outros modelos? Porque ele enfatiza bastante um aspecto
que o diferencia dos demais: Análise de Riscos.

Conforme vimos em aula, existe sim Análise de Riscos no Modelo em Espiral. No

entanto, isso não significa que ela seja inexistente no Modelo em Cascata e no
Modelo de Prototipação, ela apenas não é explícita como no Modelo em Espiral.

Gabarito: E

Prof. Diego Carvalho [Link] Pág. 46 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

21. (CESPE – – CENSIPAM – Analista de Sistemas) O modelo espiral é iterativo

e incremental, assim como são os modelos de processo unificado, de
prototipação, de desenvolvimento rápido de aplicações e em cascata.

Comentários:

Conforme vimos em aula, o Modelo Espiral é Evolucionário (ok, alguns autores

afirmam que é incremental). No entanto, Modelo em Cascata é Sequencial Linear!

Gabarito: E

(CESPE – – SERPRO – Analista de Sistemas) O modelo iterativo e o modelo

em espiral possuem características semelhantes: ambos permitem que as
atividades do processo sejam planejadas e avaliadas ao longo do ciclo de vida.

Comentários:

 Determinar objetivos, alternativas e restrições: definem-se os objetivos da do

projeto (aumentar performance, consertar funcionalidade, melhorar
qualidade), identificam-se alternativas (reúso de componentes, comprar
pronto) e identificam-se restrições impostas (custo, cronograma, etc).

 Avaliar alternativas, identificar e resolver riscos: avaliam-se as alternativas

identificadas em relação aos objetivos e restrições. Frequentemente, esse
processo identifica áreas de incerteza (custos excessivos, falta de recursos) e
resolve ou reduz os riscos identificados - um protótipo pode ser construído.

 Desenvolver e testar: após a redução dos riscos, um modelo de

desenvolvimento para o sistema é selecionado (Ex: prototipação evolucionária,
16712855225

modelos formais, modelo em cascata, modelos baseados em componentes). O

software é desenvolvido e, posteriormente, testado.

 Planejar próximas fases: revisa-se o projeto e decide-se sobre o

prosseguimento ao próximo loop da espiral. Se a decisão for pelo
prosseguimento, são elaborados planos para a próxima fase do projeto, e
terminamos um loop.

Perfeito, conforme vimos em aula! Lembrando que o Modelo Espiral é um tipo de

Modelo Iterativo.

Prof. Diego Carvalho [Link] Pág. 47 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Gabarito: C

(CESPE – – ANATEL – Analista de Sistemas) Entre os modelos de ciclo de

vida de software, o modelo espiral possui maior proximidade com as práticas da
engenharia clássica empregadas, por exemplo, na construção de casas, quando
comparado aos modelos cascata e de componentes reusáveis.

Comentários:

É conhecido como prototipagem- -etapas, por combinar o modelo em cascata com

a prototipação. Cada loop representa uma fase do processo de software. Dessa forma,
o loop mais interno pode estar relacionado à viabilidade do sistema; o próximo loop,
à definição de requisitos; o próximo, ao projeto de sistema e assim por diante. De
acordo com Sommerville, divide-se em quatro etapas:

Conforme vimos em aula, possui maior proximidade com Modelo em Cascata e de

Componentes Reusáveis, que são processos de desenvolvimento mais sistemáticos.
A construção de casas seria um modelo iterativo e incremental, eu acredito!

Gabarito: E

24. (CESPE – – INMETRO – Analista de Sistemas) Uma das características

marcantes do modelo de desenvolvimento em espiral é o fato de ele ser cíclico,
e não linear, como o modelo de desenvolvimento em cascata.

Comentários:

16712855225

Prof. Diego Carvalho [Link] Pág. 48 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Conforme vimos em aula, é exatamente isso! Cuidado para não escorregar no

português: a questão parece ambígua, mas ela afirma que uma das características
marcantes do modelo de desenvolvimento em espiral é o fato de o modelo espiral
ser cíclico, diferente do modelo em cascata, que é linear.

Gabarito: C

(CESPE – – UNIPAMPA – Analista de Sistemas) O modelo de

desenvolvimento espiral foi desenvolvido somente para abranger as melhores
características do ciclo de vida clássico.
16712855225

Comentários:

É conhecido como prototipagem- -etapas, por combinar o modelo em cascata com

a prototipação. Cada loop representa uma fase do processo de software. Dessa forma,
o loop mais interno pode estar relacionado à viabilidade do sistema; o próximo loop,
à definição de requisitos; o próximo, ao projeto de sistema e assim por diante. De
acordo com Sommerville, divide-se em quatro etapas:

Conforme vimos em aula, esse item não faz qualquer sentido! Ele não é uma
implementação do Modelo em Cascata – ele é um modelo híbrido que combina
características do Modelo em Cascata com o Modelo de Prototipagem.

Prof. Diego Carvalho [Link] Pág. 49 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Gabarito: E

(CESPE – – UNIPAMPA – Analista de Sistemas) No modelo de

desenvolvimento em espiral, a análise de riscos não impacta na elaboração de
um produto ou protótipo.

Comentários:

Vocês perceberam, pela imagem acima, que existem protótipos que são utilizados
para verificar a viabilidade do projeto. Ao final de cada loop na espiral, deve-se decidir
se o projeto continuará ou se será interrompido. Pessoal, por que esse modelo se
destaca em relação aos outros modelos? Porque ele enfatiza bastante um aspecto
que o diferencia dos demais: Análise de Riscos.

Conforme vimos em aula, é claro que impacta! Tanto que ela é considerada
explicitamente.

Gabarito: E

27. (CESPE – 2010 – INMETRO – Analista de Sistemas – No modelo em espiral,

um exemplo de modelo iterativo, cada loop da espiral representa uma fase do
processo de software. Nesse modelo, os riscos não são considerados, pois
podem impactar o projeto.

Comentários:

Vocês perceberam, pela imagem acima, que existem protótipos que são utilizados
para verificar a viabilidade do projeto. Ao final de cada loop na espiral, deve-se decidir
16712855225

se o projeto continuará ou se será interrompido. Pessoal, por que esse modelo se

destaca em relação aos outros modelos? Porque ele enfatiza bastante um aspecto
que o diferencia dos demais: Análise de Riscos.

Conforme vimos em aula, riscos são considerados!

Gabarito: E

(CESPE – 2010 – TRE/MT – Analista de Sistemas – E) O modelo de

desenvolvimento em espiral, que tem a codificação como segunda etapa, gera
o código do sistema muito mais rapidamente que o modelo de prototipação.

Prof. Diego Carvalho [Link] Pág. 50 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Comentários:

Conforme vimos em aula, é a terceira etapa e não gera o código mais rapidamente
que o modelo de prototipação, que é bem mais rápido.

Gabarito: E

(CESPE - 2013 - STF - Técnico Judiciário - Tecnologia da Informação) O processo

de software fundamentado no modelo em espiral apresenta o processo em
loops compostos basicamente por setores, como, por exemplo, definição de
objetivos, avaliação de riscos, planejamento e desenvolvimento e avaliação.
16712855225

Comentários:

 Determinar objetivos, alternativas e restrições: definem-se os objetivos da do

projeto (aumentar performance, consertar funcionalidade, melhorar
qualidade), identificam-se alternativas (reúso de componentes, comprar
pronto) e identificam-se restrições impostas (custo, cronograma, etc).

 Avaliar alternativas, identificar e resolver riscos: avaliam-se as alternativas

identificadas em relação aos objetivos e restrições. Frequentemente, esse

Prof. Diego Carvalho [Link] Pág. 51 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

processo identifica áreas de incerteza (custos excessivos, falta de recursos) e

resolve ou reduz os riscos identificados - um protótipo pode ser construído.

 Desenvolver e testar: após a redução dos riscos, um modelo de

desenvolvimento para o sistema é selecionado (Ex: prototipação evolucionária,
modelos formais, modelo em cascata, modelos baseados em componentes). O
software é desenvolvido e, posteriormente, testado.

 Planejar próximas fases: revisa-se o projeto e decide-se sobre o

prosseguimento ao próximo loop da espiral. Se a decisão for pelo
prosseguimento, são elaborados planos para a próxima fase do projeto, e
terminamos um loop.

Conforme vimos em aula, está perfeito!

Gabarito: C

(CESPE - 2013 – TRT/17 – Analista de Sistemas) O modelo espiral de modelagem

de processos para desenvolvimento de software é finalizado quando o software
é implantado.

Comentários:

Vocês entenderam isso? O Pressman explica isso por meio da imagem acima!
Percebam que o loop mais interno (1) pode tratar do projeto de desenvolvimento de
conceito, o segundo loop (2) pode tratar do projeto de desenvolvimento de um
produto, o terceiro loop (3) pode tratar do projeto de melhoria e o último (4), mais
claro, pode tratar do projeto de manutenção. Pode tratar de todo ciclo de vida...
16712855225

Conforme vimos em aula, Modelo Espiral de Modelagem de Processos de

Desenvolvimento de Software não existe! A questão viajou agora! Ele é finalizado
quando o software é implantado? Não, necessariamente – mas é possível.

Gabarito: E

31. (CESPE - 1 – AL/ES - Analista Judiciário - Tecnologia da Informação) No ciclo

de vida em espiral, a de análise de risco é realizada na etapa da modelagem do
produto.

Comentários:

Prof. Diego Carvalho [Link] Pág. 52 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

De acordo com Pressman, cada espiral é dividida em cinco etapas:

 Comunicação: é a comunicação em si;

 Planejamento: estimativa de custos, cronograma e análise de riscos;
 Modelagem: análise e design;
 Construção: codificação e teste;
 Implantação: entrega e feedback;

Conforme vimos em aula, está de acordo com Pressman (última versão); é realizada
na etapa de Planejamento e, não, Modelagem.

Gabarito: E

(CESPE – 2004 – PBV/RR – Analista de Sistema) O modelo em cascata é linear e

seqüencial. Modelos como o espiral e o Rational Unified Process pregam o
desenvolvimento iterativo.

Comentários:

Conforme vimos em aula, está perfeito!

Gabarito: C

(ESAF – 2010 – MPOG – Analista de Sistemas) As atividades do modelo espiral

de Engenharia de Software são:

a) Planejamento, Análise dos Componentes, Análise de Hierarquia e Avaliação

feita pelo cliente. 16712855225

b) Planejamento, Análise dos Riscos, Engenharia e Avaliação feita pelo cliente.

c) Projeto, Análise dos Benefícios, Engenharia e Avaliação feita pelo gestor.
d) Planejamento, Eliminação dos Riscos, Análise de Contingência e Avaliação
feita pelo cliente.
e) Planejamento, Projeto, Análise dos Riscos e Engenharia.

Comentários:

Conforme vimos em aula, levantamento não é um dos setores.

Gabarito: B

Prof. Diego Carvalho [Link] Pág. 53 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

34. (FUNCAB - 2010 – PRODAM/AM - Analista de Sistemas) Qual das alternativas a

seguir corresponde ao modelo de processo, proposto no final da década de 80,
que tem como principais características ser evolucionário, iterativo e focado na
redução dos riscos?

a) Modelo em Espiral.
b) Modelo em Cascata.
c) Modelo em V.
d) Modelo Transformacional.
e) Modelo de Especificação Operacional.

Comentários:

Ele foi proposto originalmente, em 1988, por Boehm. Vocês perceberam, pela imagem
acima, que existem protótipos que são utilizados para verificar a viabilidade do
projeto. Ao final de cada loop na espiral, deve-se decidir se o projeto continuará ou
se será interrompido. Pessoal, por que esse modelo se destaca em relação aos outros?
Porque ele enfatiza bastante um aspecto: Análise de Riscos.

Conforme vimos em aula, a questão está perfeita! Ele disse que o modelo é
evolucionário e iterativo – além de falar dos riscos! É claro que é o Modelo em
Espiral.

Gabarito: A

(ESAF - 2010 – MPOG – Analista de Sistemas) As atividades do modelo espiral de

Engenharia de Software são:
16712855225

a) Planejamento, Análise dos Componentes, Análise de Hierarquia e Avaliação

feita pelo cliente.

b) Planejamento, Análise dos Riscos, Engenharia e Avaliação feita pelo cliente.

c) Projeto, Análise dos Benefícios, Engenharia e Avaliação feita pelo gestor.

d) Planejamento, Eliminação dos Riscos, Análise de Contingência e Avaliação

feita pelo cliente.

e) Planejamento, Projeto, Análise dos Riscos e Engenharia.

Prof. Diego Carvalho [Link] Pág. 54 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

Comentários:

Conforme vimos em aula, trata-se da última variação: Planejamento, Análise de

Riscos, Engenharia e Avaliação do Cliente.
16712855225

Gabarito: B

ACERTEI ERREI

Prof. Diego Carvalho [Link] Pág. 55 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

LISTA DE EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

MÉTODOS FORMAIS

(CESPE – – SERPRO – Analista de Sistemas) Para a especificação de software

e verificação de sistemas, uma alternativa que se fundamenta na matemática
discreta e na lógica é o modelo incremental.

16712855225

Prof. Diego Carvalho [Link] Pág. 56 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

LISTA DE EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

BASEADO EM COMPONENTES OU ORIENTADO A REÚSO

(CESPE – 2010 – TRE/BA – Técnico Judiciário – Programação de Sistemas) Na

engenharia de software baseada em componentes, na qual se supõe que partes
do sistema já existam, o processo de desenvolvimento concentra-se mais na
integração dessas partes que no seu desenvolvimento a partir do início. Essa
abordagem é baseada em reúso para o desenvolvimento de sistemas de
software.

(UFBA - - UFBA - Analista de Tecnologia da Informação No processo de

software baseado em componentes, cada componente projetado para reuso é
uma entidade executável independente, que deve manipular exceções.

(CESPE – – MPE/AM – Analista Judiciário – Analista de Sistemas) A utilização

de um modelo de desenvolvimento embasado em componentes é uma forma
de desenvolvimento em espiral que busca a reutilização de trechos de software
desenvolvidos e testados em projetos anteriores e armazenados em um
repositório.

(CESPE – 2004 – SERPRO – Analista de Sistemas) O grande objetivo do uso de

engenharia de software por componentes é a produção de software de alta
qualidade e baixo custo.

(CESPE – 2004 – SERPRO – Analista de Sistemas) Enquanto o reúso em

engenharia de software convencional está geralmente limitado à extensão e à
manutenção de um sistema específico, o reúso, em engenharia de software por
16712855225

componentes, é um requisito de desenvolvimento, independentemente do

projeto em consideração.

(CESPE – 2004 – SERPRO – Analista de Sistemas) O uso de componentes pode

estar condicionado a regras de licenciamento. Essa preocupação, no entanto,
não existe se os componentes forem classificados como software livre.

(CESPE – 2008 – SERPRO – Analista de Sistemas) O modelo orientado a reúso

parte de um software existente para que se crie outro, no todo ou apenas em
parte de seus componentes.

Prof. Diego Carvalho [Link] Pág. 57 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

LISTA DE EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

MODELOS ITERATIVOS E INCREMENTAIS

(CESPE - 2011 – TJ/ES - Analista Judiciário - Análise de Sistemas - Específicos) O

modelo de processo incremental de desenvolvimento de software é iterativo,
assim como o processo de prototipagem. Contudo, no processo incremental,
diferentemente do que ocorre no de prototipagem, o objetivo consiste em
apresentar um produto operacional a cada incremento.

(CESPE - – TJ/DF - Analista Judiciário - Análise de Sistemas) No modelo de

desenvolvimento incremental, embora haja defasagem entre os períodos de
desenvolvimento de cada incremento, os incrementos são desenvolvidos em
paralelo.

(CESPE - – UNIPAMPA - Análise de Sistemas) No modelo de

desenvolvimento incremental, a cada iteração são realizadas várias tarefas. Na
fase de análise, pode ser feito o refinamento de requisitos e o refinamento do
modelo conceitual.

16712855225

Prof. Diego Carvalho [Link] Pág. 58 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

LISTA DE EXERCÍCIOS COMENTADOS

MODELO EM PROTOTIPAGEM

(CESPE – – UNIPAMPA – Analista de Sistemas) No modelo de

desenvolvimento prototipagem, um protótipo é desenvolvido para ajudar no
entendimento dos requisitos do sistema.

(CESPE – 2010 – E – Analista de Sistemas - C) A metodologia de

prototipagem evolutiva é uma abordagem que visualiza o desenvolvimento de
concepções do sistema conforme o andamento do projeto, por meio de
protótipos visuais.

(CESPE – 2004 – TRE/AL – Analista de Sistemas) No modelo de prototipação, o

desenvolvedor cria inicialmente um modelo de software que será posteriormente
implementado.

(CESPE – 2007 – TSE – Analista de Sistemas) Um possível objetivo da

prototipação é criar rapidamente um sistema experimental que possa ser
avaliado por usuários finais. Um protótipo aprovado pelos usuários pode vir a
ser usado como ponto de partida para a construção do sistema.

(CESPE – – MPE/AM – Analista de Sistemas) No modelo de prototipação,

a especificação de requisitos tem pouca importância, pois o software é
continuamente adaptado em função dos desejos do usuário.

(CESPE – – TJ/DF – Analista de Sistemas) Uma vantagem da prototipação

é promover a participação e o comprometimento do usuário em relação ao
16712855225

sistema em desenvolvimento.

(CESPE – – TJ/DF – Analista de Sistemas) A prototipação de um software é

uma técnica de desenvolvimento não-interativa porque o teste do sistema só
ocorre na versão final.

(CESPE – – TJ/DF – Analista de Sistemas) Uma das finalidades da

prototipação é reduzir o esforço de desenvolvimento de um software.

Prof. Diego Carvalho [Link] Pág. 59 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

(CESPE – 2010 – INMETRO – Analista de Sistemas – Um dos benefícios da

prototipação é a documentação normalmente gerada, que facilita a manutenção
dos sistemas a longo prazo e a elaboração de casos de teste.

10. (CESPE – 2010 – INMETRO – Analista de Sistemas – D) Um dos riscos da

prototipação é o usuário confundir o protótipo com o sistema verdadeiro e criar
falsas expectativas com relação a prazos e recursos.

11. (CESPE – 2010 – INMETRO – Analista de Sistemas – E) Na abordagem evolutiva

para desenvolvimento de software, um protótipo do software é produzido e
utilizado para identificar possíveis problemas com os requisitos, sendo
descartado logo em seguida, e o desenvolvimento do software propriamente
dito é, então, iniciado.

12. (CESPE – 1 – – Analista de Sistemas) No modelo de prototipação, o

processo de desenvolvimento de software é modelado como uma sequência
linear de fases, enfatizando um ciclo de desenvolvimento de breve duração.

13. (CESPE – 2013 – TRT/10 – Analista Judiciário – Tecnologia da Informação) No

modelo prototipação, a construção de software tem várias atividades que são
executadas de forma sistemática e sequencial.

14. (VUNESP - 2009 - CETESB - Analista de Tecnologia da Informação - Banco de

Dados) Considere um sistema cujos requisitos de interface são definidos apenas
quando o cliente realiza um test-drive na aplicação e aprova essa interface.
Assinale a alternativa que apresenta o modelo mais adequado para o
desenvolvimento da interface desse sistema.

a) Ágil. 16712855225

b) Cascata.
c) Iterativo incremental.
d) Prototipação.
e) Rapid Application Development.

15. (CESPE – – TCE/RN – Assessor Técnico de Informática) A prototipação, uma

abordagem para desenvolvimento de software na qual se cria um modelo do
software que será implementado, é composta de quatro etapas: planejamento,
análise de risco, engenharia e avaliação do cliente.

Prof. Diego Carvalho [Link] Pág. 60 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

16. (CESPE – – DETRAN/DF – Analista de Sistemas) O modelo de processo de

desenvolvimento de software evolucionário parte do desenvolvimento de uma
implementação inicial cujos resultados são apresentados aos clientes e refinados
por meio de várias versões até que se alcance o sistema adequado. A
prototipação, como processo, tem por objetivo compreender as especificações
do software para se chegar aos requisitos para o sistema.

17. (CESPE – – TJ/DF – Analista de Sistemas) A prototipação evolucionária

permite que a versão inicial do protótipo seja desenvolvida e refinada em
estágios sequenciados, até que se chegue à versão final do sistema.

18. (CESPE – 2011 – MEC – Análise de Sistemas) No modelo de prototipação, o

processo de desenvolvimento de software é modelado como uma sequência
linear de fases, enfatizando um ciclo de desenvolvimento de breve duração.

16712855225

Prof. Diego Carvalho [Link] Pág. 61 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

LISTA DE EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

MODELO EM ESPIRAL

(FCC - 2012 - TST - Analista Judiciário - Análise de Sistemas) O Ciclo de Vida de

um Sistema especifica todas as fases de desenvolvimento, desde sua concepção
até o processo de manutenção e declínio. No que diz respeito ao
desenvolvimento de software, existem alguns processos conhecidos. Um destes
processos, possui característica iterativa e incremental, inicia cada fase do projeto
realizando um planejamento prévio, realiza a execução da fase, verifica o
progresso e os resultados da fase (riscos, lições aprendidas) e incrementa novos
objetivos para a fase seguinte, seguindo para a próxima iteração. O processo de
software em questão é o:

a) Modelo espiral.
b) Ciclo de vida em cascata.
c) Modelo de desenvolvimento evolucionário (prototipação).
d) Modelo de desenvolvimento ágil.
e) Método de desenvolvimento Cleanroom (Sala Limpa).

(FCC - 2010 - TRT - 20ª REGIÃO (SE) - Analista Judiciário - Tecnologia da

Informação - À medida que se avança pelo modelo ocorre uma iteração e o
software evolui para estágios superiores, normalmente com aumento da
complexidade. Cada iteração está provida das atividades determinadas pelos
quadrantes planejamento, avaliação de alternativas e riscos, desenvolvimento do
software e avaliação do cliente. No ciclo de vida de desenvolvimento de software,
trata-se da propriedade do modelo:
16712855225

a) Cascata.
b) Incremental.
c) Espiral.
d) Prototipação.
e) Balbúrdia.

(FCC - 0 – MPE/RN – Analista de Sistemas) O modelo em espiral difere

principalmente dos outros modelos de processo de software por:

a) não contemplar o protótipo.

b) reconhecer explicitamente o risco.

Prof. Diego Carvalho [Link] Pág. 62 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

c) não ter fases.

d) possuir uma fase única evolucionária.
e) não contemplar o projeto do produto.

(FCC - 2012 – TRE/CE – Analista de Sistemas) No desenvolvimento de software

em espiral (Boehm), cada loop está dividido em quatro setores. NÃO se trata da
denominação de um destes setores:

a) levantamento.
b) definição de objetivos.
c) avaliação e redução de riscos
d) desenvolvimento e validação.
e) planejamento.

(FCC – 2010 – BAHIAGÁS – Analista de Sistemas) No modelo em espiral do

processo de software cada loop na espiral representa:

a) uma disciplina de requisitos.

b) um enfoque de banco de dados.
c) uma tomada de decisão.
d) uma fase do processo.
e) um ciclo de programa.

(CESPE – 2011 – MEC – Gerente de Projetos) O modelo de processo denominado

em espiral combina as atividades de desenvolvimento com o gerenciamento de
riscos, de modo a minimizá-los e controlá-los.

(CESPE – – TJ/DF – Analista Judiciário – Tecnologia da Informação) O

modelo em espiral é um modelo de processos de software que reúne a natureza
16712855225

iterativa da prototipação com os aspectos sistemáticos e controlados do modelo

sequencial linear.

(CESPE – 2004 – HAB – Analista Judiciário – Tecnologia da Informação) O

modelo espiral é um modelo de processo de software que combina a natureza
iterativa da prototipagem com os aspectos controlados e sistemáticos do modelo
sequencial linear.

(CESPE - – TJ/DF - Analista Judiciário - Tecnologia da Informação)

Empregando o modelo de desenvolvimento em espiral, o software é
desenvolvido em uma série de versões intermediárias incrementais.

Prof. Diego Carvalho [Link] Pág. 63 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

10. (CESPE – 2010 – SERPRO - Analista – Desenvolvimento De Sistemas) O modelo

em espiral de ciclo de vida de software é iterativo e incremental, uma vez que a
mesma sequência de atividades relacionadas à produção de software é realizada
a cada ciclo da espiral.

11. (CESPE – 2010 – SERPRO - Analista – Desenvolvimento De Sistemas) O modelo

de desenvolvimento em espiral permite repensar o planejamento diversas vezes
durante o desenrolar do projeto.

12. (CESPE - - ANTAQ - Analista Administrativo - Informática) O modelo em

espiral, que descreve o processo de desenvolvimento de um software, apresenta
uma espiral em que cada loop representa uma fase distinta desse processo. A
ausência de risco nesse modelo o diferencia dos demais modelos de software.

13. (CESPE – – IPEA – Analista de Sistemas) O modelo espiral é um modelo

evolucionário de processo de software que combina a prototipagem com o
modelo em cascata. Contudo, a incerteza em relação ao número de ciclos
necessários para construir o projeto, leva tal abordagem a empregar o modelo
de métodos formais para viabilizá-lo.

14. (CESPE – – UNIPAMPA – Analista de Sistemas) O modelo espiral admite

retorno às fases anteriores de desenvolvimento, suportando ainda a execução
paralela de fases.

15. (CESPE – – UNIPAMPA – Analista de Sistemas) O modelo em cascata é

linear e sequencial. Modelos como o espiral e o Rational Unified Process pregam
o desenvolvimento iterativo.
16712855225

16. (CESPE – 2004 – BASA – Analista de Sistemas) O modelo em espiral evolui à

medida que o processo avança, permitindo ao desenvolvedor e ao cliente
entenderem melhor os riscos e reagirem em cada nível evolucionário.

17. (CESPE – 2004 – PBV/RR – Analista de Sistemas) O modelo em espiral para

desenvolvimento de software é fundamentado no faseamento comumente
adotado em projetos de engenharia a partir da década de 70 do século passado.
Tal modelo considera as seguintes fases: análise de requisitos, definição, projeto,
implementação, integração e testes, operação e manutenção.

Prof. Diego Carvalho [Link] Pág. 64 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

18. (CESPE – 2004 – PBV/RR – Analista de Sistemas) O modelo em espiral de

desenvolvimento proposto por Boehm apresenta a análise de riscos como uma
das suas fases essenciais.

19. (CESPE – 2004 – STJ – Analista de Sistemas) O modelo de desenvolvimento em

espiral requer a consideração dos riscos técnicos em todos os estágios ou
interações do projeto, o que permite reduzir os riscos antes que se concretizem.

(CESPE – 2004 – TRE/AL – Analista de Sistemas) O modelo de desenvolvimento

em espiral engloba o que há de melhor no modelo cascata e no modelo de
prototipação, acrescentando a análise de risco, inexistente nestes dois modelos.

21. ESPE – – CENSIPAM – Analista de Sistemas) O modelo espiral é iterativo

e incremental, assim como são os modelos de processo unificado, de
prototipação, de desenvolvimento rápido de aplicações e em cascata.

(CESPE – – SERPRO – Analista de Sistema O modelo iterativo e o modelo

em espiral possuem características semelhantes: ambos permitem que as
atividades do processo sejam planejadas e avaliadas ao longo do ciclo de vida.

(CESPE – – ANATEL – Analista de Sistemas) Entre os modelos de ciclo de

vida de software, o modelo espiral possui maior proximidade com as práticas da
engenharia clássica empregadas, por exemplo, na construção de casas, quando
comparado aos modelos cascata e de componentes reusáveis.

24. (CESPE – – INMETRO – Analista de Sistemas) Uma das características

marcantes do modelo de desenvolvimento em espiral é o fato de ele ser cíclico,
e não linear, como o modelo de desenvolvimento em cascata.
16712855225

(CESPE – – UNIPAMPA – Analista de Sistemas) O modelo de

desenvolvimento espiral foi desenvolvido somente para abranger as melhores
características do ciclo de vida clássico.

(CESPE – – UNIPAMPA – Analista de Sistemas) No modelo de

desenvolvimento em espiral, a análise de riscos não impacta na elaboração de
um produto ou protótipo.

27. (CESPE – 2010 – INMETRO – Analista de Sistemas – No modelo em espiral,

um exemplo de modelo iterativo, cada loop da espiral representa uma fase do

Prof. Diego Carvalho [Link] Pág. 65 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

processo de software. Nesse modelo, os riscos não são considerados, pois

podem impactar o projeto.

(CESPE – 2010 – TRE/MT – Analista de Sistemas – E) O modelo de

desenvolvimento em espiral, que tem a codificação como segunda etapa, gera
o código do sistema muito mais rapidamente que o modelo de prototipação.

(CESPE - 2013 - STF - Técnico Judiciário - Tecnologia da Informação) O processo

de software fundamentado no modelo em espiral apresenta o processo em
loops compostos basicamente por setores, como, por exemplo, definição de
objetivos, avaliação de riscos, planejamento e desenvolvimento e avaliação.

(CESPE - 2013 – TRT/17 – Analista de Sistemas) O modelo espiral de modelagem

de processos para desenvolvimento de software é finalizado quando o software
é implantado.

31. (CESPE - 1 – AL/ES - Analista Judiciário - Tecnologia da Informação) No ciclo

de vida em espiral, a de análise de risco é realizada na etapa da modelagem do
produto.

(CESPE – 2004 – PBV/RR – Analista de Sistema) O modelo em cascata é linear e

seqüencial. Modelos como o espiral e o Rational Unified Process pregam o
desenvolvimento iterativo.

(ESAF – 2010 – MPOG – Analista de Sistemas) As atividades do modelo espiral

de Engenharia de Software são:

a) Planejamento, Análise dos Componentes, Análise de Hierarquia e Avaliação

feita pelo cliente. 16712855225

b) Planejamento, Análise dos Riscos, Engenharia e Avaliação feita pelo cliente.

c) Projeto, Análise dos Benefícios, Engenharia e Avaliação feita pelo gestor.
d) Planejamento, Eliminação dos Riscos, Análise de Contingência e Avaliação
feita pelo cliente.
e) Planejamento, Projeto, Análise dos Riscos e Engenharia.

34. (FUNCAB - 2010 – PRODAM/AM - Analista de Sistemas) Qual das alternativas a

seguir corresponde ao modelo de processo, proposto no final da década de 80,
que tem como principais características ser evolucionário, iterativo e focado na
redução dos riscos?

Prof. Diego Carvalho [Link] Pág. 66 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

a) Modelo em Espiral.
b) Modelo em Cascata.
c) Modelo em V.
d) Modelo Transformacional.
e) Modelo de Especificação Operacional.

(ESAF - 2010 – MPOG – Analista de Sistemas) As atividades do modelo espiral de

Engenharia de Software são:

a) Planejamento, Análise dos Componentes, Análise de Hierarquia e Avaliação

feita pelo cliente.

b) Planejamento, Análise dos Riscos, Engenharia e Avaliação feita pelo cliente.

c) Projeto, Análise dos Benefícios, Engenharia e Avaliação feita pelo gestor.

d) Planejamento, Eliminação dos Riscos, Análise de Contingência e Avaliação

feita pelo cliente.

e) Planejamento, Projeto, Análise dos Riscos e Engenharia.

16712855225

Prof. Diego Carvalho [Link] Pág. 67 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

MÉTODOS FORMAIS

1 2 3 4 5 6 7 8 9 10
E

GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

BASEADO EM COMPONENTES OU ORIENTADO A REÚSO

1 2 3 4 5 6 7 8 9 10
C E C C C E C

GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

MODELOS ITERATIVOS E INCREMENTAIS

1 2 3 4 5 6 7 8 9 10
C C C

GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

MODELO EM PROTOTIPAGEM

1 2 3 4 5 16712855225
6 7 8 9 10
C C C C E C E C E C
11 12 13 14 15 16 17 18 19 20
E E E E E C E D - -

GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

MODELO EM ESPIRAL

1 2 3 4 5 6 7 8 9 10
A C B E B C C C C E

Prof. Diego Carvalho [Link] Pág. 68 de 69

 Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 01

11 12 13 14 15 16 17 18 19 20
C E E E C C E C C E
21 22 23 24 25 26 27 28 29 30
E C E C E E E E C E
31 32 33 34 35 36 37 38 39 40
E C B A B

16712855225

Prof. Diego Carvalho [Link] Pág. 69 de 69