Aula 01

Aula 01
Tecnologia da Informao (parte II) p/ Auditor de TI do TCU

Professor: Diego Carvalho
71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

Tecnologia da Informao para TCU/2017 (Parte II)
Curso de Teoria e Exerccios
Prof. Diego Carvalho Aula 01
AULA 01
SUMRIO PGINA
Apresentao 01
- Engenharia de Software: Conceitos Gerais 12
- Ciclo de Vida de Software 27
- Processos de Desenvolvimento de Software 29
- Modelo em Cascata 33
- Modelo Baseado em Componentes 52
- Mtodos Formais 60
- Modelos Iterativos e Incrementais 62
- Rapid Application Development (RAD) 68
- Modelos Evolucionrios 76
- Modelos em Prototipagem 81
- Modelo em Espiral 94
Lista de Exerccios Comentados 118
Gabarito 142
5 Engenharia de software. 5.1 Ciclo de vida do software. 5.2 Metodologias de desenvolvimento de software.
5.3 Mtricas e estimativas de software: Anlise por pontos de funo. 6 Engenharia de requisitos: conceitos
bsicos, tcnicas de elicitao e especificao. 7 Metodologias geis: Scrum, XP, Kanban, TDD, BDD e DDD.
8 Testes de software (Unidade, Integrao, Sistema, Aceitao, Regresso, Desempenho e Carga). 1.5
Linguagens de programao Java. 1.7 Frontend Web: HTML5, CSS3, JavaScript, 1.9 Noes e conceitos de
desenvolvimento para dispositivos mveis. 1.10 Anlise esttica de cdigo fonte (Clean Code e ferramenta
SonarQube). 1.8 Java EE e frameworks: Java Server Faces (JSF 1.x e 2.x), Enterprise Java Beans (EJB 3.x),
Java Persistence API (JPA 2.x), Hibernate, Spring Framework (4.x) e Spring Security. 2 Arquitetura de
software. Padres de Projeto. 2.2 Service Oriented Architecture (SOA). Princpios (Service-Orientation
71410392104
Design Principles). Padres SOA (SOA Patterns). Sistema de Governana SOA. SOAP. REST. JAX-RS (2.x), 1.6
Ferramentas de desenvolvimento e versionamento de cdigo-fonte (Eclipse IDE, Subversion, Git, Maven e
Artifactory). 4 Continuous Integration e Continuous Delivery. 4.1 Prticas de Integrao Contnua. 4.2
Deployment Pipelines. 4.3 Noes de DevOps. 2.1 Enterprise Integration Patterns (EAI). WebSocket, Single
Page Application (SPA).
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 1 de 144

APRESENTAO
Ol, pessoal. Sejam bem-vindos! O concurso do TCU passou e vocs viram que no
d para estudar em cima da hora, no ? Um concurso desse tamanho demanda
preparao e planejamento! A validade dele de 180 dias + 180 dias, logo possvel
termos outro em breve. E a, vai esperar de novo? O salrio sensacional, fora um
monte de outras vantagens de se trabalhar no legislativo. Comee logo...
DVIDAS DOS ALUNOS
TOP 5
1. Peo encarecidamente que leiam as instrues dessa primeira aula. Eu sei que chato, mas assim
ns alinhamos nossas expectativas e todos ficamos felizes.
2. Essa a Aula Demonstrativa (est disponvel para todos na internet) o restante do contedo estar
disponvel na Aula 01 (apenas para aqueles que adquirirem o curso).
71410392104
3. Esse curso no possui vdeo-aulas! Estamos trabalhando para disponibiliz-las em cursos futuros a
partir do segundo semestre, logo isso no ocorrer ainda neste curso.
4. Esse curso contempla somente aquilo que est em seu cronograma. Ele no contempla todo edital de
tecnologia da informao, nem outras disciplinas, nem discursivas, estudos de caso, etc.
5. Existem questes de Mltipla Escolha (A, B, C, D, E) e existem questes de Certo/Errado (C, E). Quando
no h itens para escolha na questo, porque a questo da Modalidade Certo/Errado.

O PROFESSOR
Uma breve apresentao: meu nome Diego Carvalho, bacharel em Cincia da

Computao pela Universidade de Braslia, ps-graduado em Gesto de Tecnologia
da Informao na Administrao Pblica e Analista de Finanas e Controle da
Secretaria do Tesouro Nacional. J passei por esses perrengues de concurseiro e sei
de duas coisas: a estrada difcil, mas o prmio compensa! E muito!
www.facebook.com/professordiegocarvalho
REA RGOS PARA OS QUAIS J MINISTREI CURSOS
Agncia ANCINE ANTAQ ANATEL
Jurdica TRT/1 TRT/2 TRT/3 TRT/4

TJ/BA CNMP MP/PB TRT/15
Legislativa CMARA DOS
DEPUTADOS
Auditoria TCE/RS TCE/SP TCE/CE TCM/GO
TCU TCM/SP
Fiscal ISS/SP ISS/BA
Outros CEF DATAPREV DEPEN INMETRO
Galera, l no site, ns professores temos algumas mtricas para medir se o nosso

71410392104
desempenho nos cursos est bacana! Os alunos podem avaliar com notas e,
inclusive, escrever anonimamente o que acharam do professor e do curso.
Apresento abaixo o resultado de alguns cursos ministrados recentemente. Portanto,
confiem em mim... vocs vo aprender muito com esse curso!

71410392104

71410392104

71410392104

O CONCURSO
CONCURSO DO TRIBUNAL DE CONTAS DA UNIO (TCU) - 2017

AUDITOR FEDERAL DE CONTROLE EXTERNO TECNOLOGIA DA INFORMAO
71410392104
REMUNERAO VAGAS
R$ 14.078,66 -
EDITAL/AUTORIZAO:
NO DISPONVEL

O CURSO...
Antes de comear o curso, vamos alinhar algumas expectativas! O curso que eu

proponho abranger todo o contedo do meu cronograma, entretanto impossvel
e invivel esgotar cada ponto do edital em uma aula escrita. Como se ministra Java
em uma aula? Teramos uma aula de 800 pginas e no chegaramos nem perto de
matar todo contedo! Imaginem agora cada ponto do Edital.
Portanto, vou direcion-los pelo contedo da melhor maneira possvel. O nosso

foco ter uma viso geral, mas objetiva do que de fato cai em prova e, no,
elucubraes sobre cada tema. Meu foco aqui te fazer passar! Eu sei como
complicado ler muita coisa (ainda mais de TI) e vocs tm outras disciplinas para
estudar. Logo, vou ser simples e objetivo! Tranquilo? ;)
Alm disso, o cronograma ser seguido com a maior fidelidade possvel, mas ele
no esttico e poder haver alteraes no decorrer do curso. Eventualmente,
posso tirar o contedo de uma aula e colocar em outra de forma que o estudo de
vocs fique mais lgico, coeso e fcil de acompanhar; posso tambm inverter a
ordem das aulas (adiantar uma aula e atrasar outra) sem prejudic-los.
Alm disso, vamos usar questes de diversas bancas. Enfim, confiem em mim: o
curso vai ajudar bastante! Qualquer dvida, s me chamar! Caso haja alguma
reclamao, problema, sugesto, comentrios, erros de digitao, etc, podem enviar
para o nosso frum que eu tento responder da maneira mais tempestiva possvel.
Ainda duvidam que PDF no d certo com Concursos de TI? Veja abaixo:
6 Lugar ISS/Salvador 71410392104
https://www.youtube.com/watch?v=b1w4H3l6mC4#t=1678
1 Lugar TRT/RJ
https://www.facebook.com/video.php?v=790616534367672
2 Lugar ISS/Salvador
https://www.youtube.com/watch?v=vmU1n1J-aqQ
1 Lugar Dataprev
http://www.estrategiaconcursos.com.br/blog/entrevista-andre-furtado-aprovado-em-1o-lugar-
no-concurso-dataprev-para-o-cargo-de-analistaarea-de-tecnologia-da-informacao/

CRONOGRAM
Aula Data Tpicos do Edital

00 05/02 Aula demonstrativa
01 25/02 5 Engenharia de software. 5.1 Ciclo de vida do software. 5.2

Metodologias de desenvolvimento de software.
02 15/03 5.3 Mtricas e estimativas de software: Anlise por pontos de funo.
03 05/04 6 Engenharia de requisitos: conceitos bsicos, tcnicas de elicitao e

especificao.
04 25/04 7 Metodologias geis: Scrum, XP, Kanban, TDD, BDD e DDD.
05 15/05 8 Testes de software (Unidade, Integrao, Sistema, Aceitao,

Regresso, Desempenho e Carga).
06 05/06 1.5 Linguagens de programao Java.
07 25/06 1.7 Frontend Web: HTML5, CSS3,

71410392104
08 15/07 JavaScript, 1.9 Noes e conceitos de desenvolvimento para

dispositivos mveis. 1.10 Anlise esttica de cdigo fonte (Clean Code e
ferramenta SonarQube).
09 05/08 1.8 Java EE e frameworks: Java Server Faces (JSF 1.x e 2.x),
Enterprise Java Beans (EJB 3.x), Java Persistence API (JPA 2.x),
Hibernate, Spring Framework (4.x) e Spring Security.
10 25/08 2 Arquitetura de software. Padres de Projeto.

11 15/09 2.2 Service Oriented Architecture (SOA). Princpios (Service-
Orientation Design Principles). Padres SOA (SOA Patterns). Sistema
de Governana SOA. SOAP. REST. JAX-RS (2.x),
12 30/09 1.6 Ferramentas de desenvolvimento e versionamento de cdigo-fonte

(Eclipse IDE, Subversion, Git, Maven e Artifactory). 4 Continuous
Integration e Continuous Delivery. 4.1 Prticas de Integrao Contnua.
4.2 Deployment Pipelines. 4.3 Noes de DevOps. 2.1 Enterprise
Integration Patterns (EAI). WebSocket, Single Page Application (SPA).
71410392104

AS AULAS E AS DICAS
1 Pargrafos pequenos: observem que os pargrafos 2 Viso Geral: no se atenham a detalhes antes de
tm, no mximo, cinco linhas. Isso serve para que a entender o bsico. Por que? Ora, no h nada mais
leitura no fique cansativa e para que vocs no irritante do que ir para uma prova que vai cair, por
desanimem no meio do material! Para tal, eu tento dividir exemplo, RUP, saber vrios detalhes, mas no saber as
as disciplinas de maneira que as aulas fiquem objetivas e fases e disciplinas. Portanto, caso estejam iniciando os
pequenas (em termos de teoria), mas extensa (em estudos sobre uma matria, foquem em saber o bsico
termos de exerccios). para depois se especializarem.
3 Destaques em vermelho: quase todos os 4 Faam muitos exerccios: ler vrias bibliografias
pargrafos possuem alguma palavra ou frase destacada muito trabalhoso e, geralmente, no vale o custo-
em negrito e em vermelho. Isso ocorre por suas razes: benefcio. Acredito que o que funciona mesmo entender
primeiro, para enfatizar alguma informao importante; o bsico, depois fazer muitos exerccios e,
segundo, para facilitar a leitura vertical, i.e., aps uma eventualmente, caso encontrarem algo que no
primeira leitura, a segunda pode ser passando apenas souberem, pesquisem-no separadamente. Alm disso,
pelos pontos em destaque. voc vai pegando as manhas da banca.
5 Linguagem natural: essa uma aula para ser lida, o 6 Faam resumos: essa dica somente serve caso
que por si s j pode ser cansativo. Tentarei colocar a vocs tenham disponibilidade. Caso haja pouco tempo
linguagem mais coloquial possvel, simulando uma para estudar ou pouco tempo at a prova, no compensa!
conversa. Portanto, caso virem frases ou palavras em Se no, faam resumos organizados, pois eles
itlico, ou uma palavra estrangeira ou a simulao de economizaro um bom tempo de estudo em suas
uma conversa com vocs. Pode dar um exemplo, prximas provas e sempre que descobrirem novas
professor? Acabei de dar! :-) informaes, insiram-nas no resumo.
7 Diversas figuras: essas aulas estaro em constante 8 Revisem antes da prova: no adianta querer
evoluo, sempre procura de explicar as matrias de estudar coisas novas at o ltimo minuto antes da prova
maneira mais compreensvel e com novas e no revisar o que estudou h um ms. Vocs iro
informaes/questes. Para tal, na minha opinio, esquecer e iro se irritar na hora da prova por no
fundamental a utilizao de figuras, grficos, painis, etc. lembrarem de conceitos simples. Tirem uma semana
Em minha experincia, bem mais fcil memorizar a para revisar seus resumos, decorarem algumas coisas
partir de imagens. e, certamente, iro mais confiantes para a prova.
9 Fazer Exerccios: muitos exerccios o meio pelo 10 Simulado Final: ora, fazer um bloco de questes
qual vocs se situaro. Como assim, professor? na hora 71410392104
depois de estudar a teoria tranquilo. No entanto,
de fazer os exerccios que vocs descobriro se esto lembrem-se que a memria de vocs no infinita e
bem ou mal e avaliaro se precisam estudar mais ou vocs tm um milho de outras coisas para estudar e
menos. Para tal, h um quadrinho ao final de cada bloco decorar. Portanto, se possvel, ao fim do curso faremos
de exerccios para vocs anotarem a quantidade de um simulado com questes escolhidas que foram
questes respondidas corretamente ou incorretamente. comentadas dentro das aulas.
Bem, pessoal! isso... sejam bem-vindos! Espero que vocs curtam e tenham uma
leitura leve e despojada da aula, mas com muito foco, ateno e dedicao.
Qualquer dvida, podem entrar em contato comigo ficarei feliz em ajud-los. Bons
estudos, estou torcendo por vocs! Fiquem agora com algumas mensagens de
incentivo para anim-los ;-)

R$ 14.078,66
R$ 14.078,66
R$ 14.078,66
R$ 14.078,66
R$ 14.078,66
71410392104

ENGENHARIA DE SOFTWARE: CONCEITOS GERAIS
Vamos l, galera! Apesar de hoje em dia haver milhes de profissionais que mexem
com software no mundo inteiro, faz pouco tempo que a Engenharia de Software
alcanou o status de profisso reconhecida e de disciplina legtima de engenharia.
Pois , ela ganhou tanta importncia que cobrada at em concursos pblicos! Ok,
professor... mas o que a Engenharia de Software?
A IEEE define engenharia de software como a aplicao de uma abordagem

sistemtica, disciplinada e quantificvel de desenvolvimento, operao
manuteno de software. J Friedrich Bauer conceitua como a criao e a utilizao
de slidos princpios de engenharia a fim de obter software de maneira econmica,
que seja confivel e que trabalhe em mquinas reais.
Em suma, uma disciplina de engenharia que se ocupa de todos os aspectos da

produo de software, desde os estgios iniciais de especificao do sistema at a
manuteno desse sistema, aps sua entrada em produo passando por
aspectos humanos, hardware tambm, etc. A meta principal da Engenharia de
Software desenvolver sistemas de software com boa relao custo-benefcio.
Alis, vamos voltar um pouquinho: o que seria um software? Bem, em uma viso
restritiva, muitas pessoas costumam associar o termo software aos programas de
computador. Software no apenas o programa, mas tambm todos os dados de
documentao e configurao associados, necessrios para que o programa opere
corretamente. Vamos prosseguir...
Sommerville define processo de software como a abordagem sistemtica usada pela

71410392104
engenharia de software para produo de software. Pode-se identificar as seguintes

atividades: Especificao; Desenvolvimento; Validao; e Evoluo. O Processo de
Software uma caracterizao descritiva ou prescritiva de como um produto de
software deve ser desenvolvido. E o que diz Pressman?
De acordo com Pressman: A Engenharia de Software ocorre como consequncia de

um processo chamado Engenharia de Sistemas. Em vez de se concentrar somente no
software, a engenharia de sistemas focaliza diversos elementos, analisando,
projetando, e os organizando em um sistema que pode ser um produto, um servio
ou uma tecnologia para transformao da informao ou controle.

Ademais, nosso renomadssimo autor afirma que a engenharia de sistemas pode
tomar duas formas dependendo do domnio em que ele aplicado: Engenharia de
Processo de Negcio ou Engenharia de Produto. Ambas tentam colocar ordem no
desenvolvimento de sistemas computacionais e ambas buscam contextualizar o
software. Entenderam direitinho?
A Engenharia de Software tem por objetivos a aplicao de teoria, modelos,

formalismos, tcnicas e ferramentas da cincia da computao e reas afins para a
desenvolvimento sistemtico de software. Associado ao desenvolvimento, preciso
tambm aplicar processos, mtodos e ferramentas sendo que a pedra fundamental
que sustenta a engenharia de software a qualidade.
Isto envolve planejamento de custos e prazos, montagem da equipe e garantia de

qualidade do produto e do processo. Finalmente, a engenharia de software visa a
produo da documentao formal do produto, do processo, dos critrios de
qualidade e dos manuais de usurios finais. Todos esses aspectos devem ser levados
em considerao.
Alis, nosso outro renomadssimo autor (Sommerville) afirma que: A engenharia de

software no est relacionada apenas com os processos tcnicos de desenvolvimento
71410392104
de software, mas tambm com atividades como o gerenciamento de projeto de

software e o desenvolvimento de ferramentas, mtodos e teorias que apoiem a
produo de software.
A Engenharia de Software surgiu em meados da dcada de sessenta como uma

tentativa de contornar a crise do software e dar um tratamento de engenharia ao
desenvolvimento de software completo. Naquela poca, o processo de
desenvolvimento era completamente fora de controle e tinha grandes dificuldades
em entregar o que era requisitado pelo cliente.

J na dcada de oitenta, surgiu a Anlise Estruturada e algumas Ferramentas CASE
que permitiam automatizar algumas tarefas. Na dcada de noventa, surgiu a
orientao a objetos, linguagens visuais, processo unificado, entre outros. E na
ltima dcada, surgiram as metodologias geis e diversos paradigmas de
desenvolvimento.
A Engenharia de Software possui alguns princpios, tais como: Formalidade, em que

o software deve ser desenvolvido de acordo com passos definidos com preciso e
seguidos de maneira efetiva; Abstrao, preocupa-se com a identificao de um
determinado fenmeno da realidade, sem se preocupar com detalhes,
considerando apenas os aspectos mais relevantes.
H a Decomposio, em que se divide o problema em partes, de maneira que cada

uma possa ser resolvida de uma forma mais especfica; Generalizao, maneira
usada para resolver um problema, de forma genrica, com o intuito de reaproveitar
essa soluo em outras situaes; Flexibilizao o processo que permite que o
software possa ser alterado, sem causar problemas para sua execuo.
Certa vez, um aluno me perguntou: professor, como a formalidade pode reduzir

inconsistncias? Cenrio 1: Estamos na fase de testes de software. O testador afirma
que fez todos os testes, voc - lder de projeto - acredita, e passa o software ao
cliente. Esse tenta utilizar o software e verifica que ele no est funcionando
corretamente. Bacana?
Cenrio 2: Estamos na fase de testes de software. O testador afirma que fez todos
os testes e entrega um documento de testes com tudo que foi verificado
formalmente. Voc - lder de projeto - l o documento de testes e verifica que no
foram feitos testes de carga e testes de segurana. Retorna para o testador e pede
para ele refazer os testes. 71410392104
Feito isso, ele passa o software ao cliente, que fica feliz e satisfeito com tudo
funcionando corretamente. Vocs percebem que essas formalidades evitam aquele
"telefone-sem-fio"? Quanto mais eu seguir o processo, o passo-a-passo, o que foi
definido por vrias pessoas a partir de suas experincias com vrios projetos, mais
tenho chance de obter xito na construo do meu software. Bacana?
Bem, galera... a Engenharia de Software se divide em algumas disciplinas genricas

como: Requisitos de Negcio, Requisitos de Software, Anlise de Software, Projeto
de Software, Construo de Software, Testes de Software, Implantao de Software

e Manuteno de Software. Galera, essas disciplinas e seus nomes so bem
genricos e variam de acordo com os autores.
A disciplina de Requisitos de Negcio busca entender como o negcio funciona. J

a disciplina de Requisitos de Software busca entender e levantar os requisitos. Na
Anlise de Software, desenha-se o problema e no Projeto de Software, desenha-se
a soluo do problema. A Construo de Software a implementao ou
codificao em si.
Na disciplina de Testes de Software, realizam-se verificaes para garantir sua

consistncia e funcionamento. Na disciplina de Implantao de Software, coloca-se
o software em produo na organizao. Por fim, a disciplina de Manuteno de
Software busca manter o software funcionando. Bem, isso... ns nos
aprofundaremos mais adiante.
ESQUEMA
71410392104

(FCC - 2012 - TRT - 6 Regio (PE) - Tcnico Judicirio - Tecnologia da

Informao - E) Considere: uma disciplina que se ocupa de todos os aspectos
da produo de software, desde os estgios iniciais de especificao do sistema
at a manuteno desse sistema, depois que ele entrou em operao. Seu
principal objetivo fornecer uma estrutura metodolgica para a construo de
software com alta qualidade. A definio refere-se Engenharia de Software.
Comentrios:

manuteno desse sistema, aps sua entrada em produo passando por aspectos
humanos, hardware, etc. A meta principal da Engenharia de Software desenvolver
sistemas de software com boa relao custo-benefcio.
Pura definio de Engenharia de Software! Fcil, n?!
Gabarito: C
(CESPE - 2013 - TRT - 10 REGIO (DF e TO) - Analista Judicirio - Tecnologia da

Informao A engenharia de software engloba processos, mtodos e
ferramentas. Um de seus focos a produo de software de alta qualidade a
71410392104
custos adequados.
Comentrios:
A Engenharia de Software tem por objetivos a aplicao de teoria, modelos,


Basta visualizar a imagem para responder questo!
Gabarito: C
(FCC - 2012 - TST - Analista Judicirio - Anlise de Sistemas A Engenharia de

Software:
a) uma rea da computao que visa abordar de modo sistemtico as questes

tcnicas e no tcnicas no projeto, implantao, operao e manuteno no
desenvolvimento de um software.
b) consiste em uma disciplina da computao que aborda assuntos relacionados

a tcnicas para a otimizao de algoritmos e elaborao de ambientes de
desenvolvimento.
c) trata-se de um ramo da TI que discute os aspectos tcnicos e empricos nos

processos de desenvolvimento de sistemas, tal como a definio de artefatos
para a modelagem gil.
71410392104
d) envolve um conjunto de itens que abordam os aspectos de anlise de

mercado, concepo e projeto de software, sendo independente da engenharia
de um sistema.
e) agrupa as melhores prticas para o concepo, projeto, operao e

manuteno de artefatos que suportam a execuo de programas de
computador, tais como as tcnicas de armazenamento e as estruturas em
memria principal.
Comentrios:


(a) Perfeito, observem as palavras-chave: modo sistemtico; questes tcnicas e no

tcnicas; projeto, implantao, operao e manuteno de desenvolvimento de
software. (b) Tcnicas para otimizao de algoritmos e elaborao de ambientes de
desenvolvimento? No, isso no Engenharia de Software. (c) Pessoal, discordo do
gabarito! Certa vez, um aluno me disse que talvez fosse porque aspectos empricos
so mais voltados para metodologias geis. Sim, verdade! No entanto, a
engenharia de software trata tambm de metodologias geis. Se algum encontrar
o erro, avise :-] (d) A Anlise de Mercado serve mais como uma tcnica para Anlise
de Interfaces, mas pode ser vista como um dos aspectos que envolvem a Engenharia
de Software. Pressman afirma que: A Anlise de Mercado pode ser inestimvel na
definio de segmentos de mercado e no entendimento de como cada segmento
poderia usar o software de modos sutilmente diferentes. De todo modo, a questo
est errada porque a Engenharia de Software depende da Engenharia de Sistema
(como mostrado acima). (e) Suportam a execuo? No, suportam o
desenvolvimento de programas de computador.
Gabarito: A

Informao) Considere: uma disciplina que se ocupa de todos os aspectos da
manuteno desse sistema, depois que ele entrou em operao. Seu principal
71410392104
objetivo fornecer uma estrutura metodolgica para a construo de software

com alta qualidade. A definio refere-se:
a) ao ciclo de vida do software.

b) programao orientada a objetos.
c) anlise de sistemas.
d) engenharia de requisitos.
e) engenharia de software.
Comentrios:

Tranquilo, n?! a Engenharia de Software!
Gabarito: E
(CESPE - 2011 - MEC - Gerente de Projetos A engenharia de software, disciplina

relacionada aos aspectos da produo de software, abrange somente os
processos tcnicos do desenvolvimento de software.
Comentrios:
Alis, nosso outro renomadssimo autor (Sommerville) afirma que: A engenharia de

software no est relacionada apenas com os processos tcnicos de desenvolvimento
de software, mas tambm com atividades como o gerenciamento de projeto de
software e o desenvolvimento de ferramentas, mtodos e teorias que apoiem a
produo de software.
Portanto, no so apenas processos tcnicos!

Gabarito: E
(FGV - 2010 - BADESC - Analista de Sistemas - Desenvolvimento de Sistemas De

acordo com Pressman, a engenharia de software baseada em camadas, com
foco na qualidade.
Essas camadas so:
a) mtodos, processo e teste.

b) ferramentas, mtodos e processo.
c) mtodos, construo, teste e implantao.
d) planejamento, modelagem, construo, validao e implantao.
71410392104
e) comunicao, planejamento, modelagem, construo e implantao.
Comentrios:

Basta visualizar a imagem para responder questo!
Gabarito: B
(CESPE - 2010 - Banco da Amaznia - Tcnico Cientfico - Tecnologia da

Informao Os princpios de engenharia de software definem a necessidade de
formalidades para reduzir inconsistncias e a decomposio para lidar com a
complexidade.
Comentrios:

seguidos de maneira efetiva; H a Decomposi , em que se divide o problema em
partes, de maneira que cada uma possa ser resolvida de uma forma mais especfica;
Perfeito, so princpios: Formalidade e Decomposio.
Gabarito: C
71410392104
(FCC - 2010 - TRE- - Analista Judicirio - Tecnologia da Informao - A A

Engenharia de Software:
a) no tem como mtodo a abordagem estruturada para o desenvolvimento de

software, pois baseia-se exclusivamente nos modelos de software, notaes,
regras e tcnicas de desenvolvimento.
b) se confunde com a Cincia da Computao quando ambas tratam do

desenvolvimento de teorias, fundamentaes e prticas de desenvolvimento de
software.

c) tendo como foco apenas o tratamento dos aspectos de construo de
software, subsidia a Engenharia de Sistemas no tratamento dos sistemas
baseados em computadores, incluindo hardware e software.
d) tem como foco principal estabelecer uma abordagem sistemtica de

desenvolvimento, atravs de ferramentas e tcnicas apropriadas, dependendo
do problema a ser abordado, considerando restries e recursos disponveis.
e) segue princpios, tais como, o da Abstrao, que identifica os aspectos

importantes sem ignorar os detalhes e o da Composio, que agrupa as
atividades em um nico processo para distribuio aos especialistas.
Comentrios:
A IEEE define engenharia de software como a aplicao de uma abordagem

sistemtica, disciplinada e quantificvel de desenvolvimento, operao e manuteno
de software. J Friedrich Bauer conceitua como a criao e a utilizao de slidos
princpios de engenharia a fim de obter software de maneira econmica, que seja
confivel e que trabalhe em mquinas reais.
(a) Pelo contrrio, ela se baseia em uma abordagem estruturada e sistemtica!
A Engenharia de Software tem por objetivos a aplicao de teoria, modelos

(b) Na verdade, Engenharia de Software uma disciplina da Cincia da Computao.

71410392104
(c) Apenas o tratamento dos aspectos de construo de software? S construo?

No!
(d) Perfeito, exatamente isso!
H a Decomposio, em que se divide o problema em partes, de maneira que cada

uma possa ser resolvida de uma forma mais especfica; Generalizao, maneira
usada para resolver um problema, de forma genrica, com o intuito de reaproveitar
essa soluo em outras situaes; Flexibilizao o processo que permite que o
software possa ser alterado, sem causar problemas para sua execuo.


seguidos de maneira efetiva; Abstrao, preocupa-se com a identificao de um
determinado fenmeno da realidade, sem se preocupar com detalhes, considerando
apenas os aspectos mais relevantes.
(e) Composio? No, Decomposio! Divide-se o problema em partes para que

cada uma possa ser resolvida de uma forma mais especfica. Alm disso, a abstrao
ignora detalhes!
Gabarito: D
(FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI Em relao

Engenharia de Software, INCORRETO afirmar:
a) O design de software, ao descrever os diversos aspectos que estaro presentes

no sistema quando construdo, permite que se faa a avaliao prvia para
garantir que ele alcance os objetivos propostos pelos interessados.
b) A representao de um design de software mais simples para representar

apenas as suas caractersticas essenciais busca atender ao princpio da abstrao.
c) Iniciar a entrevista para obteno dos requisitos de software com perguntas

mais genricas e finalizar com perguntas mais especficas sobre o sistema o
que caracteriza a tcnica de entrevista estruturada em funil.
d) No contexto de levantamento de requisitos, funcionalidade um dos aspectos

que deve ser levado em conta na abordagem dos requisitos funcionais.
71410392104
e) A representao a linguagem do design, cujo nico propsito descrever

um sistema de software que seja possvel construir.
Comentrios:
Galera, descrever um sistema de software que seja possvel construir no o nico,

mas um dos objetivos da representao. Ela auxilia a comunicao entre as partes
interessadas e serve tambm como documentao.
Gabarito: E

10. (FCC AFR/SP - Analista de Sistemas A engenharia de software est

inserida no contexto:
a) das engenharias de sistemas, de processo e de produto.

b) da engenharia de sistemas, apenas.
c) das engenharias de processo e de produto, apenas.
d) das engenharias de sistemas e de processo, apenas.
e) das engenharias de sistemas e de produto, apenas.
Comentrios:

Ademais, nosso renomadssimo autor afirma que a engenharia de sistemas pode

tomar duas formas dependendo do domnio em que ele aplicado: Engenharia de
Processo de Negcio ou Engenharia de Produto. Ambas tentam colocar ordem no
desenvolvimento de sistemas computacionais e ambas buscam contextualizar o
software. Entenderam direitinho?
Portanto, est inserida no contexto das Engenharias de Sistemas, de Processo e de

Produto.
Gabarito: A
71410392104
11. (CESPE 2015 STJ Analista de Sistemas Embora os engenheiros de software

geralmente utilizem uma abordagem sistemtica, a abordagem criativa e menos
formal pode ser eficiente em algumas circunstncias, como, por exemplo, para
o desenvolvimento de sistemas web, que requerem uma mistura de habilidades
de software e de projeto.
Comentrios:
Apesar de soar um pouco estranho, isso est no Sommerville:

No entanto, engenharia tem tudo a ver com selecionar o mtodo mais adequado
para um conjunto de circunstncias, ento uma abordagem mais criativa e menos
formal pode ser eficiente em algumas circunstncias. Desenvolvimento menos formal
particularmente adequado para o desenvolvimento de sistemas Web, que requerem
uma mistura de habilidades de software e de projeto.
Gabarito: C
12. (CESPE 2015 STJ Analista de Sistemas) O foco da engenharia de software

inclui especificao do sistema, desenvolvimento de hardware, elaborao do
projeto de componentes de hardware e software, definio dos processos e
implantao do sistema.
Comentrios:

manuteno desse sistema, aps sua entrada em produo passando por aspectos
humanos, hardware tambm, etc. A meta principal da Engenharia de Software
desenvolver sistemas de software com boa relao custo-benefcio.
Conforme vimos em aula, at trata de alguns aspectos de hardware; mas

desenvolvimento de hardware, no.
Gabarito: E
13. (CESPE 1 Analista de Sistemas) O processo de desenvolvimento de

software uma caracterizao descritiva ou prescritiva de como um produto de
software deve ser desenvolvido. 71410392104
Comentrios:

Conforme vimos em aula, a questo est perfeita!

Gabarito: C
14. (CESPE 3 TRT/10 Analista de Sistemas) As atividades fundamentais

relacionadas ao processo de construo de um software incluem a especificao,
o desenvolvimento, a validao e a evoluo do software.
Comentrios:

Gabarito: C
15. (CESPE 0 TRE/BA Analista de Sistemas) Um modelo de processo de

software consiste em uma representao complexa de um processo de software,
apresentada a partir de uma perspectiva genrica.
Comentrios:
No, trata-se de uma representao simplificada de um processo de software,

Gabarito: E
71410392104
16. (CESPE 1 MEC Analista de Sistemas) Atividades comuns a todos os

processos de software incluem a especificao, o projeto, a implementao e a
validao.
Comentrios:


Vejam que ele dividiu a atividade de Desenvolvimento em Projeto e Implementao,

mas no invalida a questo. Professor, ele no falou sobre a evoluo! Sim, mas a
questo apenas afirma que essas so atividades comuns e, no, que so as nicas.
Gabarito: C
17. (CESPE 5 STJ Analista de Sistemas) As principais atividades de

engenharia de software so especificao, desenvolvimento, validao e
evoluo.
Comentrios:

Gabarito: C
ACERTEI ERREI
71410392104

CICLO DE VIDA DE SOFTWARE
O Ciclo de Vida de Software se refere s fases pelas quais um sistema de software

atravessa desde sua concepo at sua retirada de produo. Galera, no
confundam Ciclo de Vida de Software com Ciclo de Vida de Desenvolvimento de
Software (inclusive, muitas bancas erram nesse ponto), entretanto fiquem relaxados,
porque essa diferena geralmente no cobrada.
Fazendo um paralelo com o PMBOK, o Ciclo de Vida do Projeto seria o Ciclo de

Vida do Desenvolvimento de Software e o Ciclo de Vida do Produto seria o Ciclo de
Vida do Software. O PMBOK diz que cada projeto deve especificar seu prprio ciclo
de vida, mas sugere fases genricas: Incio do Projeto, Organizao e Preparao,
Execuo do Trabalho e Encerramento do Projeto.
71410392104
Da mesma forma que o Ciclo de Vida do Projeto est contido em um Ciclo de Vida
do Produto, o Ciclo de Vida de Desenvolvimento de Software est contido em um
Ciclo de Vida do Software. Fazendo um paralelo, podemos ver cada fase do ciclo
de vida do software como um projeto! Em outras palavras, podemos tratar a
Definio, Desenvolvimento, Operao e Retirada como um projeto.
O Ciclo de Vida apenas a ordem global das atividades desempenhadas no s no

desenvolvimento de software, mas tambm em sua evoluo, manuteno e

retirada. Infelizmente no h um consenso entre os autores a respeito dos estgios,
mas comum as seguintes fases: Definio ou Concepo, Desenvolvimento ou
Construo, Operao ou Utilizao e Retirada ou Aposentadoria.
Na Definio, busca-se entender o problema a ser resolvido pelo software. No

Desenvolvimento, busca-se construir o software de acordo com uma srie de
requisitos. Na Operao, ocorre a entrega, distribuio, instalao, configurao,
71410392104
utilizao e manuteno do software. Por fim, na Retirada, aposenta-se o software

de vez! isso... simples, no?! ;)

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
De acordo com Sommerville, o termo Ciclo de Vida de Desenvolvimento de

Software foi criado originalmente para se referir ao Modelo em Cascata, sendo
atualmente bastante utilizado como um sinnimo de Processo ou Metodologia de
Desenvolvimento Software. E o que seria isso? Um conjunto de atividades cuja meta
o desenvolvimento ou a evoluo de um software.
Sendo mais detalhista, o processo de desenvolvimento de software refere-se s

atividades, relacionamentos, artefatos, ferramentas, papis, etc necessrios para
construir, entregar, manter e evoluir um produto de software. J o ciclo de vida de
desenvolvimento de software apresenta uma representao mais alto nvel do
processo de software executado.
Galera, vocs no precisam se preocupar com isso! Nunca vi essa diferena ser
cobrada em prova. Alis, comum que as bancas as tratem como sinnimos.
Pessoal, coloquei na imagem abaixo os principais grupos de modelos de
desenvolvimento de software. Essa classificao no um consenso entre os autores
e nem so mutuamente exclusivas, podendo haver combinao entre elas.
71410392104

A tabela abaixo apresenta um comparativo entre os principais modelos de processos
de desenvolvimento de software, com as principais caractersticas a serem
observadas antes de escolher o ciclo de vida adequado. Pessoal, isso uma
orientao genrica, no exato para todos os conceitos, mas ajuda bastante a
entend-los. Vejamos a tabela:
GERENCIAM
MODELO FOCO REQUISITOS 1 VERSO P/ CLIENTE
ENTO
Documentos e Bem conhecidos e estticos Fim do ciclo 1

CASCATA
artefatos
INCREMENTAL
Incrementos Mais abstratos; tratados em Prottipos operacionais 3
operacionais mdulos
EVOLUTIVO
Evoluo dos Pouco conhecidos Prottipos operacionais 4
requisitos
Rapidez de Escopo restrito; mais Prottipos operacionais 5
RAD
desenvolvimento abstratos; tratado em mdulos
PROTOTIPAGEM
Dvidas nos Mais abstratos Prottipos no 5
requisitos operacionais
ESPIRAL
Anlise Mais abstratos; evoludos com o Prottipos operacionais 5
de Risco tempo ou no operacionais
RUP
Frameworks e Mais abstratos; evoludos com o Prottipos operacionais 5
boas prticas tempo ou no operacionais
A ltima coluna, referente ao gerenciamento, revela em uma escala de 1 a 5 a

dificuldade de gerenciamento de cada processo (sendo 1 mais simples e 5 mais
complexo). O que diferencia um processo de software de outro a ordem em que
as fases vo ocorrer, o tempo e a nfase dados a cada fase, as atividades presentes
em cada um, e os produtos entregues como resultado.
Pessoal, a qualidade de um produto de software depende fortemente da qualidade

71410392104
do processo de software utilizado em seu desenvolvimento. Logo, essencial ter

um processo de software adequado para se obter produtos de software de
qualidade. Seguir um processo de software mal escolhido ou definido pode
ocasionar prejuzos no andamento do projeto.

(CESPE TCE/TO Analista de Sistemas - Quanto maior e mais

complexo o projeto de software, mais simples deve ser o modelo de processo a
ser adotado.
Comentrios:
Galera, no existe essa relao! Em geral, quanto mais complexo o projeto mais
complexo o modelo. No entanto, isso tambm no uma regra.
Gabarito: E
(CESPE TCE/TO Analista de Sistemas - O modelo de ciclo de vida

do software serve para delimitar o alvo do software. Nessa viso, no so
consideradas as atividades necessrias e o relacionamento entre elas.
Comentrios:
Pelo contrrio, o alvo do software serve para delimitar o modelo de ciclo de vida a
ser escolhido. Ademais, so consideradas as atividades necessrias e o
relacionamento entre elas.
71410392104
Gabarito: E
(CESPE TCE/TO Analista de Sistemas - A escolha do modelo do

ciclo de vida no depende de caractersticas especficas do projeto, pois o melhor
modelo sempre o mais usado pela equipe do projeto.
Comentrios:
No faz o menor sentido! A escolha depende das caractersticas do projeto.
Gabarito: E

ACERTEI ERREI
71410392104

MODELO EM CASCATA
Citado inicialmente em 1970 por W. Royce, tambm designado Cascata ou Clssico

ou Sequencial ou Linear ou Tradicional ou Waterfall ou Rgido ou Monoltico (todos
esses nomes j caram em prova!). Esse nome devido ao encadeamento simples
de uma fase com a outra. Os estgios do modelo demonstram as principais
atividades de desenvolvimento. Observem a imagem mais abaixo!
No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase

anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a
71410392104
Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada

aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que
complica, porque cada autor resolve criar suas fases!
De acordo com Vasconcelos (2006), no Modelo em Cascata, o projeto segue uma

srie passos ordenados, ao final de cada fase, a equipe de projeto finaliza uma
reviso. Alm disso, o desenvolvimento no continua at que o cliente esteja
satisfeito com os resultados alcanados. Vocs conseguem perceber como essas
restries engessam o desenvolvimento?

Por Por Por Pressman Por Pressman Por

Sommerville Yourdon (4 Ed.) (6 Ed.) Royce
Definio de Requisitos Requisitos de Modelagem e Engenharia Comunicao Elicitao de
Sistema do Sistema/Informao Requisitos
Projeto de Sistema e Requisitos de Anlise de Requisitos de Planejamento Projeto
Software Software Software
Implementao e Teste Anlise Projeto Modelagem Construo
de Unidade
Integrao e Teste de Projeto Gerao de Cdigo
71410392104
Construo Integrao
Sistema
Operao e Manuteno Codificao Teste e Manuteno Implantao Teste de
Depurao
Teste Instalao
Operao Manuteno de
Software
Percebam que h diferenas gritantes entre os autores! Inclusive, h divergncias

at entre autor e ele mesmo, dependendo da verso do livro (Exemplo: Pressman
mudou as fases na ltima edio de seu livro). Professor, voc j viu isso cair em

prova? Sim, j vi! E o que aconteceu? Bem, polmica, recursos, etc! No h o que
fazer... minha classificao preferida a do Yourdon.
Na prtica, esses estgios no so completamente sequenciais, i.e., eles se

sobrepem e trocam informaes entre si. Na teoria, so fases sequenciais com o
resultado de cada fase consistindo em um ou mais documentos aprovados ou no,
dependendo dos problemas. Por exemplo: durante o projeto, so identificados
problemas com requisitos.
De modo geral, grande parte dos modelos possuem as seguintes fases:
Planejamento: faz-se o esboo do escopo e dos requisitos, alm de estimativas

razoveis sobre recursos, custos e prazos.
Anlise e Especificao de Requisitos: durante essa fase, refina-se os requisitos e

o escopo e desenha-se o problema em questo.
Projeto: durante essa fase, incorpora-se requisitos tecnolgicos aos requisitos

essenciais do sistema e projeta-se a arquitetura do sistema.
plementao: durante essa fase, codifica-se o software como um conjunto de

programas executveis pela mquina.
Teste: o programa testado como um sistema completo para garantir que os

requisitos de software foram atendidos.
Implantao, Operao e Manuteno: o sistema de software liberado para o

cliente, treina-se usurios, gerencia servios e realiza manutenes.
71410392104

Professor, o que voc quer dizer com atrasar a reduo de riscos? Bem, essa uma
desvantagem recorrente em provas. Como uma fase s se inicia aps o trmino da
fase anterior, s possvel em geral verificar se houve erros nas ltimas fases como
pode ser visto na imagem abaixo. Em outros modelos, os riscos so reduzidos desde
as primeiras fases do processo de desenvolvimento.
Percebam que os riscos deveriam ser descobertos logo no incio do processo de

desenvolvimento, porm eles so descobertos somente aps o incio dos testes e
integrao. Vocs podem notar que, nesse instante (parte vermelha), o progresso
do projeto avana e retrai diversas vezes, porque o sistema est sendo corrigido
devido a requisitos modificados.
Vejam, tambm, que o projeto no terminou em seu deadline original. Como a

reduo dos riscos atrasou, todo andamento do projeto tambm atrasou. Dessa
forma, no se cumpriu nem o prazo do projeto e, provavelmente, nem o oramento
e talvez seu escopo tendo em vista que, quanto mais ao fim do projeto um erro
identificado, mais caras se tornam as modificaes.
Entenderam essa parte direitinho? Um erro na fase de requisitos, por exemplo, que
no foi corrigido e foi descoberto no final do processo de desenvolvimento, ter um
custo de correo altssimo, visto que provavelmente ter que se refazer tudo
novamente. Ora, se eu peo a construo de um carro e voc constri uma moto,
o custo para corrigir esse erro ser altssimo.
71410392104

Portanto no confundam essas duas coisas: o erro ocorreu no incio e foi

identificado no incio, ter baixo custo de correo; se o erro ocorreu no incio e foi
identificado no final, ter alto custo de correo. O custo de correo de um erro
est mais focado no momento em que um erro identificado do que no momento
em que ele ocorre. Bacana?
Outra maneira de visualizar o atraso por meio de um grfico Risco x Tempo,

comparando o modelo em cascata com o Modelo Iterativo e Incremental. Observem
que o Modelo Iterativo e Incremental j comea a reduzir os riscos desde o incio
do processo, em contraste com o Modelo em Cascata que acumula os riscos at a
fase de testes, integrao e implantao do sistema.
Galera, a grande vantagem do Modelo em Cascata que o desenvolvimento

dividido em fases distintas, padronizadas, etc (antigamente, os softwares eram
construdos artesanalmente). possvel colocar pessoas com perfis especficos para
cada fase, i.e., quem tem facilidade de se comunicar vai ser analista de requisitos,
programadores vo fazer a codificao, etc.
A grande desvantagem que - em projetos complexos demora-se muito para

chegar at a fase de testes, sendo que o cliente no v nada rodando at a
implantao. Ento, pode acontecer de, nas fases finais, os requisitos da organizao
no serem mais os mesmos daqueles do incio e o software no ter mais utilidade
para organizao.
Professor, ento o Modelo em Cascata no deve ser usado em nenhuma hiptese?

Calma l, ele pode ser usado! No entanto, sua utilizao deve ocorrer
preferencialmente quando os requisitos forem bem compreendidos e houver pouca
probabilidade de mudanas radicais durante o desenvolvimento do sistema. Vocs
71410392104
entenderam?
VANTAGENS DESVANTAGENS
simples de entender e fcil de aplicar, Diviso inflexvel do projeto em estgios

facilitando o planejamento. distintos.
Fixa pontos especficos para a entrega de Dificuldade em incorporar mudanas de
artefatos. requisitos.

Funciona bem para equipes tecnicamente Clientes s visualizam resultados prximos
fracas. ao final do projeto.
fcil de gerenciar, devido a sua rigidez. Atrasa a reduo de riscos.
Realiza documentao extensa por cada Apenas a fase final produz um artefato de
fase ou estgio. software entregvel.
Possibilita boa aderncia a outros modelos Cliente deve saber todos os requisitos no
de processo. incio do projeto.
Funciona bem com projetos pequenos e Modelo inicial (Royce) no permitia
com requisitos bem conhecidos. feedback entre as fases do projeto.
Pressupe que os requisitos ficaro
estveis ao longo do tempo.
No funciona bem com projetos complexos
e OO, apesar de compatvel.
Podemos afirmar, ento, que o Modelo em Cascata considerado um mtodo

tradicional e fortemente prescritivo, i.e., ele busca sempre dizer o que fazer, em
geral, por meio de planos definidos no incio do projeto. Que planos, professor?
Escopo, custo, cronograma... tudo isso bem detalhado em uma extensa
documentao. Mudanas so bem-vindas? Claro que no!
ESQUEMA
71410392104

(FCC - 2012 - - - Analista Judicirio - Anlise de Sistemas - E) Dos diferentes

modelos para o ciclo de vida de desenvolvimento de um software correto
afirmar que o modelo em cascata o mais recente e complexo.
Comentrios:

esses nomes j caram em prova!). Esse nome devido ao encadeamento simples de
uma fase com a outra. Os estgios do modelo demonstram as principais atividades
de desenvolvimento. Observem a imagem mais abaixo!
Mais recente? No, muito antigo! Complexo? No, possui um encadeamento simples
de fases.
Gabarito: E
(FC - - SEFAZ- - Agente Fiscal de Rendas - Tecnologia da Informao

- Prova 3 - O processo de engenharia de software denominado ciclo de vida
clssico refere-se ao modelo incremental.
Comentrios:
71410392104

No, modelo clssico se refere a modelo em cascata, sequencial, linear, tradicional,

waterfall, rgido ou monoltico.
Gabarito: E

(CESPE INMETRO Analista de Sistemas) Em uma empresa que tenha
adotado um processo de desenvolvimento de software em cascata, falhas no
levantamento de requisitos tm maior possibilidade de gerar grandes prejuzos
do que naquelas que tenham adotado desenvolvimento evolucionrio.
Comentrios:

Funciona bem com projetos pequenos e No fornece feedback entre as fases.
com requisitos bem conhecidos.
71410392104

O Modelo em Cascata, de fato, no reage bem a mudanas. J Modelo

evolucionrio mais adaptvel a mudanas por se utilizar de iteraes.
Gabarito: C
(CESPE 2011 MEC Analista de Sistemas) O modelo Waterfall tem a vantagem

de facilitar a realizao de mudanas sem a necessidade de retrabalho em fases
j completadas.

Comentrios:

Pelo contrrio, h dificuldade de lidar com requisitos volteis, tendo em vista que
dependendo do erro, necessrio refaz-lo desde seu incio.
71410392104
Gabarito: E
(CESPE 2008 TST Analista de Sistemas) No modelo de desenvolvimento

sequencial linear, a fase de codificao a que gera erros de maior custo de
correo.
Comentrios:

Entenderam essa parte direitinho? Um erro na fase de requisitos, por exemplo, que
no foi corrigido e foi descoberto no final do processo de desenvolvimento, ter um
custo de correo altssimo, visto que provavelmente ter que se refazer tudo
novamente. Ora, se eu peo a construo de um carro e voc constri uma moto, o
custo para corrigir esse erro ser altssimo.
Portanto no confundam essas duas coisas! Percebam o que eu disse: quanto mais
tarde se descobre um erro, mais caro se torna sua correo. Dizendo isso de outra
forma: erros nas fases iniciais possuem custo de correo altssimo. Uma coisa o
momento em que o erro ocorre (quanto mais cedo, mais caro); outra coisa o
momento em que um erro identificado (quanto mais tarde, mais caro). Bacana?
Percebam que erros nas fases iniciais possuem custos de correo mais altos. Logo,
o maior custo est na fase de codificao? No, est na fase de requisitos que a
fase inicial!
Gabarito: E
(CESPE INMETRO Analista de Sistemas) Em um processo de

desenvolvimento em cascata, os testes de software so realizados todos em um
mesmo estgio, que acontece aps a finalizao das fases de implementao.
Comentrios:

Definio de Requisitos Requisitos de Modelagem e Engenharia do Comunicao Elicitao de
Sistema Sistema/Informao Requisitos
71410392104
Implementao e Teste de Anlise Projeto Modelagem Construo

Unidade
Integrao e Teste de Projeto Gerao de Cdigo Construo Integrao
Sistema
Depurao
Teste Instalao
Operao Manuteno de
Software
Todos em um mesmo estgio, no. A grande maioria dos testes ocorrem, de fato,
aps a finalizao das fases de implementao. No entanto, podem ocorrer testes
unitrios durante a prpria implementao, como mostra o quadro acima.

Gabarito: E
(CESPE 2008 SERPRO Analista de Sistemas) O modelo em cascata consiste

de fases e atividades que devem ser realizadas em sequncia, de forma que uma
atividade requisito da outra.
Comentrios:

complica, porque cada autor resolve criar suas fases! Vejamos: (...)
Vimos isso exaustivamente: no modelo em cascata, uma fase s se inicia aps o

trmino e aprovao da fase anterior.
Gabarito: C
(CESPE AL/ES Analista de Sistemas - O modelo de desenvolvimento

em cascata descreve ciclos sequenciais, incrementais e iterativos, possuindo,
entre outras, as fases de requisitos e implementao.
Comentrios:
No! Ele no descreve ciclos, muito menos ciclos iterativos. Na verdade, essa a
definio de Modelo Iterativo e Incremental.
71410392104
Gabarito: E
(CESPE 2004 STJ Analista de Sistemas) O modelo de desenvolvimento

seqencial linear, tambm chamado modelo clssico ou modelo em cascata,
caracteriza-se por no acomodar adequadamente as incertezas que existem no
incio de um projeto de software, em especial as geradas pela dificuldade do
cliente de explicitar todos os requerimentos que o programa deve contemplar.
Comentrios:

Professor, o que voc quer dizer com atrasar a reduo de riscos? Bem, essa uma
desvantagem recorrente em provas. Como uma fase s se inicia aps o trmino da
fase anterior, s possvel em geral verificar se houve erros nas ltimas fases como
pode ser visto na imagem abaixo. Em outros modelos, os riscos so reduzidos desde
as primeiras fases do processo de desenvolvimento.
Perfeito, lembrem-se que ele acumula riscos e no lida bem com requisitos volteis.
Gabarito: C
10. (CESPE IPEA Analista de Sistema) No modelo em cascata de processo

de desenvolvimento, os clientes devem definir os requisitos apenas durante a
fase de projeto; e os projetistas definem as estratgias de projeto apenas durante
a fase de implementao. As fases do ciclo de vida envolvem definio de
requisitos, projeto, implementao, teste, integrao, operao e manuteno.
Em cada fase do ciclo de vida, podem ser produzidos diversos artefatos.
Comentrios:
Essa questo no faz sentido! Os clientes definem os requisitos durante a fase de

Definio de Requisitos. J os projetistas definem as estratgias de projeto apenas
durante a fase Projeto.
Gabarito: E
11. (CESPE 2008 TCE/TO Analista de Sistema No ciclo de vida em cascata,

possvel realizar alternadamente e simultaneamente as atividades de
desenvolvimento de software.
71410392104
Comentrios:

No, sequencial e linear. No pode ser alternado e simultneo!
Gabarito: E

12. (CESPE 2004 TJ/PA Analista de Sistema A abordagem sistemtica

estritamente linear para o desenvolvimento de software denominada modelo
em cascata ou modelo sequencial linear.
Comentrios:

Perfeito! Modelo em Cascata, Linear, Sequencial, Waterfall, etc.
Gabarito: C
13. (CESPE 2006 TSE Analista de Sistema O modelo em cascata organiza

o desenvolvimento em fases. Esse modelo encoraja a definio dos requisitos
antes do restante do desenvolvimento do sistema. Aps a especificao e a
anlise dos requisitos, tm-se o projeto, a implementao e o teste.
Comentrios:

71410392104

Unidade
Sistema
Depurao
Teste Instalao
Operao Manuteno de
Software
Perfeito! De fato, segue essa ordem!

Gabarito: C
14. (CESPE INMTRO Analista de Sistema) No desenvolvimento de

software, o modelo em cascata estruturado de tal maneira que as fases que
compem o desenvolvimento so interligadas. Nessa situao, o final de uma
fase implica o incio de outra.
Comentrios:

Perfeito, conforme a definio.
Gabarito: C
15. (CESPE 2010 BASA Analista de Sistema) No modelo em cascata, o projeto

segue uma srie de passos ordenados. Ao final de cada projeto, a equipe de
projeto finaliza uma reviso. O desenvolvimento continua e, ao final, o cliente
avalia a soluo proposta.
Comentrios:
De acordo com Vasconcelos (2006), no Modelo em Cascata, o projeto segue uma

srie passos ordenados, ao final de cada fase, a equipe de projeto finaliza uma
reviso. Alm disso, o desenvolvimento no continua at que o cliente esteja satisfeito
71410392104
com os resultados alcanados. Vocs conseguem perceber como essas restries

engessam o desenvolvimento?
Ao final de cada projeto? No! Ao final de cada fase.
Gabarito: E
16. (CESPE TRE/MT Analista de Sistema - O modelo em cascata

apropriado para software em que os requisitos ainda no foram bem
compreendidos, pois focado na criao de incrementos.

Comentrios:
Professor, ento o Modelo em Cascata no deve ser usado em nenhuma hiptese?

Calma l, ele pode ser usado! No entanto, sua utilizao deve ocorrer
preferencialmente quando os requisitos forem bem compreendidos e houver pouca
probabilidade de mudanas radicais durante o desenvolvimento do sistema. Vocs
entenderam?
Pelo contrrio, totalmente errado!
Gabarito: E
17. (CESPE 2009 UNIPAMPA Analista de Sistema O modelo em cascata

sugere uma abordagem sistemtica e sequencial para o desenvolvimento de
software. Sua natureza linear leva a estados de bloqueio nos quais, para que
nova etapa seja iniciada, necessrio que a documentao associada fase
anterior tenha sido aprovada.
Comentrios:

Perfeito! No basta terminar uma fase, necessrio que a sua documentao tenha
sido aprovada.
71410392104
Gabarito: C
18. (CESPE 2004 ABIN Analista de Sistema) O modelo de desenvolvimento

seqencial linear, tambm denominado modelo em cascata, incompatvel com
o emprego de tcnica de anlise orientada a objetos no desenvolvimento de um
sistema de informao.
Comentrios:


No funciona bem com projetos
complexos e OO, apesar de compatvel.
Ele compatvel, mas no recomendado! Por que, no? Imagina um projeto super
complexo que utiliza uma anlise orientada a objetos (que um modelo mais
sofisticado que a anlise estruturada). Lembre-se que, no Modelo em Cascata, voc
no pode errar, porque se voc errar, os riscos de o projeto falhar so enormes! Por
essa razo, ele no recomendvel, apesar de compatvel!
71410392104
Gabarito: E
19. (CESPE 2004 TRE/AL Analista de Sistema) O modelo cascata ou ciclo de

vida clssico necessita de uma abordagem sistemtica, que envolve, em primeiro
lugar, o projeto e, em seguida, a anlise, a codificao, os testes e a manuteno.
Comentrios:


Unidade
Sistema
Depurao
Teste Instalao
Operao Manuteno de
Software
Primeiro Projeto e depois Anlise? No, Anlise vem antes do Projeto!
Gabarito: E
(CESPE MPE/AM Analista de Sistema) O modelo de desenvolvimento

seqencial linear tem como caracterstica principal a produo de uma verso
bsica, mas funcional, do software desde as primeiras fases.
Comentrios:

Fixa pontos especficos para a entrega de 71410392104
Dificuldade em incorporar mudanas de
Funciona bem para equipes tecnicamente Clientes s visualizam resultados
fracas. prximos ao final do projeto.
Realiza documentao extensa por cada Apenas a fase final produz um artefato
fase ou estgio. de software entregvel.

Pelo contrrio, somente nas fases finais que se tem uma verso! Essa definio est
mais com cara de modelo de desenvolvimento em prototipagem.
Gabarito: E
21. (VUNESP - 2012 - SPTrans - Analista de Informtica) Uma das abordagens do

processo de desenvolvimento da engenharia de software prev a diviso em
etapas, em que o fim de uma a entrada para a prxima. Esse processo
conhecido como modelo:
a) Transformao.
b) Incremental.
c) Evolutivo.
d) Espiral.
e) Cascata.
Comentrios:

71410392104
complica, porque cada autor resolve criar suas fases!
Conforme vimos em aula, trata-se do Modelo em Cascata.
Gabarito: E
(CESGRANRIO 2010 PETROBRS Analista de Sistemas Processos de

Negcio) No Ciclo de Vida Clssico, tambm chamado de Modelo Sequencial
Linear ou Modelo Cascata, apresentada uma abordagem sistemtica composta
pelas seguintes atividades:

a) Anlise de Requisitos de Software, Projeto, Gerao de Cdigo, Teste e

Manuteno.
b) Modelagem e Engenharia do Sistema/Informao, Anlise de Requisitos de

Software, Projeto, Gerao de Cdigo, Teste e Manuteno.
c) Modelagem e Engenharia do Sistema/Informao, Projeto, Gerao de

Cdigo, Teste e Manuteno.
d) Levantamento de Requisitos de Software, Projeto, Gerao de Cdigo e

Manuteno e Anlise de Requisitos de Software.
e) Levantamento de Requisitos de Software, Projeto, Gerao de Cdigo, Teste

Progressivo e Manuteno.
Comentrios:

Unidade
Sistema
Depurao
Teste Instalao
71410392104
Operao Manuteno de
Software
A Letra B est correta de acordo com o Pressman 4 Edio, mas est errada de
acordo com o Pressman 6 Edio. Ademais, na questo ele sequer disse que era
de acordo com o Pressman. Portanto, percebam que um assunto polmico e que
as bancas deveriam ignorar, mas eventualmente elas cobram mesmo assim.
Gabarito: B
ACERTEI ERREI

MODELO BASEADO EM COMPONENTES
Pessoal, vocs j pararam para pensar por que a disciplina de Engenharia de Software
denominada Engenharia de Software? Vamos contar essa histria: esse conceito
surgiu em 1968, em uma conferncia organizada para discutir a Crise do Software.
Essa crise foi o resultado da introduo de circuitos integrados em computadores. E
isso era ruim, professor?
No, pelo contrrio! Desde o ingresso dos circuitos

integrados, tornou-se possvel e vivel fazer aplicaes
71410392104
extremamente complexas. No entanto, o desenvolvimento

de software era bastante informal e incipiente, criando
softwares, cujo custo superava as previses, no confiveis,
difceis de manter e de desempenho insatisfatrio.
Naquela poca, os custos de hardware estavam caindo, enquanto os custos de

software aumentavam rapidamente. Novas tcnicas e mtodos eram necessrios
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?

Por que foi uma tentativa de contornar a crise ao utilizar slidos princpios de
Engenharia a fim de obter um software de maneira econmica, que seja confivel e
que trabalhe em mquinas reais, dando um tratamento mais sistemtico e
controlado (comum Engenharia) ao desenvolvimento de sistemas de software
complexos.
Pessoal, pensem comigo: a engenharia evolui seus mtodos 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. No acham? Ok, professor! Mas o que isso tem a ver
com reso de componentes?
Ora, a Engenharia especializada em produzir componentes reusveis. 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 estratgia de engenharia de
software na qual o processo de desenvolvimento voltado reusabilidade.
E qual a vantagem disso? Isso resulta em reduo de custos de produo e

manuteno, entregas mais rpidas e aumento de qualidade. A abordagem para
desenvolvimento de software Component-Based Software Engineering (CBSE) tem
utilizado o reso como pea principal. Essa abordagem depende de uma grande
base de componentes reusveis e algum framework de integrao.
Galera, no h ainda valores precisos dos custos de diferentes atividades de

desenvolvimento de software nessa abordagem. Contudo, sabemos que os custos
de desenvolvimento so menores que os custos de integrao e de teste. Esses
custos aumentam porque necessrio assegurar que os componentes utilizados
realmente satisfazem s especificaes e funcionam com outros componentes.
71410392104
Agora voltando um pouco: o que seria exatamente um componente? Pressman

afirma que um componente um bloco de construo modular! Em outras palavras,
uma parte do sistema modular, executvel, implantvel, independente,
padronizada e reutilizvel que encapsula a implementao e expe um conjunto de
interfaces do sistema. Bacana?

O Modelo Genrico de Engenharia de Software Baseada em Componentes:
Especificao de Requisitos: tem o objetivo de traduzir as informaes

coletadas durante a atividade de anlise em um documento que define um
conjunto de requisitos de software. Devem ser includos dois tipos de
requisitos nesse documento: os Requisitos de Usurio e Requisitos de
Sistema.
Anlise de Componentes: nesta fase, feita uma busca pelos componentes

71410392104
para implementar essa especificao. Geralmente, no existe uma

correspondncia exata entre o componente encontrado e o procurado.
Muitas vezes, os componentes que podem ser usados fornecem apenas parte
da funcionalidade necessria.
Modificao de Requisitos: os requisitos so analisados usando as

informaes sobre os componentes encontrados, que so modificados para
refletir os componentes disponveis. Quando as modificaes so impossveis,
a atividade de anlise de componentes pode ser novamente realizada para
procurar alternativas.

Projeto de Sistema com Reso: o framework do sistema projetado ou um
framework existente reutilizado. Os projetistas levam em considerao os
componentes reusados. Pode ser necessrio projetar algum software novo
caso os componentes reusveis no estejam disponveis para aquisio para
o sistema.
Desenvolvimento e Integrao: software que no pode ser adquirido

externamente desenvolvido e os componentes e os sistemas COTS so
integrados para criar os novos sistemas. A integrao de sistema, neste
modelo, pode ser parte do processo de desenvolvimento, em vez de ser uma
atividade separada.
Validao de Sistema: processo de verificao de se um sistema atende s

necessidades e expectativas do cliente. Professor, o que so Sistemas COTS?
Esse o acrnimo de Commercial Off-The-Shelf, que um conjunto de
solues pr-fabricadas e disponveis no mercado, podendo ser compradas
ou licenciadas, i.e., uma grande biblioteca de componentes prontos.
Os Componentes COTS so 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 caractersticas do modelo espiral.
Ele evolucionrio por natureza, demandando uma abordagem iterativa para a

criao de software. O modelo de desenvolvimento baseado em componentes
desenvolve aplicaes a partir de componentes de software pr-empacotados e
conduz ao reso do software; sendo que essa reusabilidade proporciona uma srie
de benefcios mensurveis aos engenheiros de software.
71410392104

(CESPE 2010 TRE/BA Tcnico Judicirio Programao de Sistemas) Na

engenharia de software baseada em componentes, na qual se supe que partes
do sistema j existam, o processo de desenvolvimento concentra-se mais na
integrao dessas partes que no seu desenvolvimento a partir do incio. Essa
abordagem baseada em reso para o desenvolvimento de sistemas de
software.
Comentrios:

raramente fabricam um componente a partir do nada. Eles baseiam seus projetos em
componentes exaustivamente testados em outros sistemas. Quando se fala em
Percebam, portanto, que h uma concentrao dos esforos mais na integrao de

partes existentes do que no seu desenvolvimento desde o incio.
Gabarito: C
(UFBA - - UFBA - Analista de Tecnologia da Informao No processo de

software baseado em componentes, cada componente projetado para reuso
71410392104
uma entidade executvel independente, que deve manipular excees.
Comentrios:
Agora voltando um pouco: o que seria exatamente um componente? Pressman

afirma que um componente um bloco de construo modular! Em outras palavras,
uma parte do sistema modular, executvel, implantvel, independente, padronizada
e reutilizvel que encapsula a implementao e expe um conjunto de interfaces do
sistema. Bacana?
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg.57 de 144

Portanto, a primeira parte est correta! A segunda parte afirma que os componentes
devem manipular excees. Concurseiro l um deve e j fica de olho aberto! Na
verdade, de acordo com Sommerville:
Os componentes no devem tratar as excees por si mesmos, pois cada aplicao

ter seus prprios requisitos para tratamento de excees. Antes, o componente deve
definir quais excees podem surgir e public-las como parte da interface.
Gabarito: E
(CESPE MPE/AM Analista Judicirio Analista de Sistemas) A utilizao

de um modelo de desenvolvimento embasado em componentes uma forma
de desenvolvimento em espiral que busca a reutilizao de trechos de software
desenvolvidos e testados em projetos anteriores e armazenados em um
repositrio.
Comentrios:
Os Componentes COTS so 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 e
componentes incorpora muitas das caractersticas do modelo espiral.
De fato, o modelo de desenvolvimento baseado em componentes incorpora

caractersticas do modelo em espiral, preconizando o uso de Componentes
Comerciais Prontos para Uso (COTS).
71410392104
Gabarito: C
(CESPE 2004 SERPRO Analista de Sistemas) O grande objetivo do uso de

engenharia de software por componentes a produo de software de alta
qualidade e baixo custo.
Comentrios:


utilizado o reso como pea principal. Essa abordagem depende de uma grande base
de componentes reusveis e algum framework de integrao.
De fato, cria componentes de alta qualidade e baixo de produo e manuteno.
Gabarito: C
(CESPE 2004 SERPRO Analista de Sistemas) Enquanto o reso em

engenharia de software convencional est geralmente limitado extenso e
manuteno de um sistema especfico, o reso, em engenharia de software por
componentes, um requisito de desenvolvimento, independentemente do
projeto em considerao.
Comentrios:

utilizado o reso como pea principal. Essa abordagem depende de uma grande base
de componentes reusveis e algum framework de integrao.
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 preocupao, no entanto,
no existe se os componentes forem classificados como software livre.
71410392104
Comentrios:
Validao de Sistema: processo de verificao de se um sistema atende s

necessidades e expectativas do cliente. Professor, o que so Sistemas COTS? Esse o
acrnimo de Commercial Off-The-Shelf, que um conjunto de solues pr-
fabricadas e disponveis no mercado, podendo ser compradas ou licenciadas, i.e., uma
grande biblioteca de componentes prontos.

Galera, h regras de licenciamento, sim. No confundam componentes livres com
componentes gratuitos. No porque um software classificado como software
livre que ele grtis ou no possui regras de licenciamento.
Gabarito: E
(CESPE 2008 SERPRO alista de Sistemas) O modelo orientado a reso

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

raramente fabricam um componente a partir do nada. Eles baseiam seus projetos
em componentes exaustivamente testados em outros sistemas. Quando se fala em
Portanto, parte de um software ou componente existente para se criar outro!
Gabarito: C
ACERTEI ERREI
71410392104

MTODOS FORMAIS
Agora vamos falar sobre os modelos especficos! Professor, por que esse nome? Bem,
s para agrupar modelos que no se encaixam diretamente em outros grupos.
Comecemos pelos Mtodos Formais, termo usado para indicar atividades que
contem com representaes matemticas de software, especificao formal, prova
de especificao, desenvolvimento transformacional, etc.
Esse modelo utilizado em ambientes extremamente complexos. So bastante

lentos e dispendiosos, alm de exigirem um treinamento intensivo. Em geral, so
71410392104
utilizados para o desenvolvimento de sistemas que necessitam de grande robustez

e confiabilidade diante da possibilidade de perda de vidas ou srio prejuzo, caso
haja falhas.
Os chamados Mtodos Formais de Desenvolvimento de Software no so

amplamente usados no desenvolvimento de software industrial. A maioria das
empresas de desenvolvimento de software no os considera adequados com
relao aos seus custos para aplic-los em seus processos de desenvolvimento de
software.

Contudo, a especificao formal uma excelente maneira para descobrir erros de
especificao e apresentar a especificao do sistema de modo no ambguo. As
poucas organizaes que tm feito investimentos em mtodos formais tm
constatado menos erros no software entregue aos clientes e tudo isso sem aumento
de custos.
Os mtodos formais podem ser adequados em termos de custo caso seu uso seja
limitado a partes do ncleo do sistema e caso as empresas desejem fazer alto
investimento inicial nessa tecnologia. Professor, pode dar um exemplo de mtodo
formal? Sim, o Mtodo Cleanroom, que trata o desenvolvimento semelhante a uma
sala limpa de cirurgia.
71410392104

(CESPE SERPRO Analista de Sistemas) Para a especificao de software

e verificao de sistemas, uma alternativa que se fundamenta na matemtica
discreta e na lgica o modelo incremental.
Comentrios:
Na verdade, a alternativa a utilizao de mtodos formais!
Gabarito: E
ACERTEI ERREI
71410392104

MODELOS ITERATIVOS E INCREMENTAIS
Como foi dito anteriormente, o Modelo em Cascata acumulava riscos e vrios

projetos comearam a fracassar ao utiliz-lo no mundo inteiro. Ento surgiu o
Modelo Iterativo como uma tentativa de resolver esse problema de acmulo de
riscos. Vejamos a diferena 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-
71410392104
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: possvel 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.

Assim, os resultados so mais rpidos, h maior interao com o usurio e h um

feedback mais intenso possvel reagir mais facilmente a mudanas. Essa
abordagem permite gerenciamento e mitigao de riscos. Professor, mas eu fiquei
com uma dvida: qual a diferena entre Modelo Iterativo e Modelo Incremental? Ou
eles so exatamente a mesma coisa?
Bem, galera... eu nunca vi nenhuma prova cobrar essa diferena 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
diferenas.
IMPORTANTE
71410392104
Galera, j vi essas palavras serem trocadas dezenas de vezes (inclusive no prprio edital).
No entanto, muitas vezes a prpria banca erra e, s vezes, no volta atrs! Infelizmente isso
acontece =(
Iterativo: reiterado ou repetitivo.

Interativo: participao ou ao mtua.
Professor, mas e se cair em prova? Ora, caso caia em prova, a diferena que, no
modelo incremental, h vrias equipes desenvolvendo uma parte do software a

serem integradas no fim e, no modelo iterativo, lana-se a verso 1.0, adicionam-se
funcionalidades, lana uma verso 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-cabeas
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 esboo do

quadro, sendo que ele desenvolve vrias verses do quadro at chegar ao resultado
final. como se fosse uma viso abstrata da imagem, que em seguida vai sendo
melhorada at chegar a uma viso mais concreta. Produz releases, i.e., verses
constantemente melhoradas da imagem.
Uma das vantagens do modelo iterativo e incremental que o cliente pode receber
71410392104
e avaliar as entregas do produto mais cedo, j no incio do desenvolvimento do

software. Alm disso, h maior tolerncia a mudanas com consequncia direta de
reduo do risco de falha do projeto, i.e., ele acomoda melhor mudanas. Ele
aumenta o reso e a qualidade.

(CESPE - 2011 TJ/ES - Analista Judicirio - Anlise de Sistemas - Especficos) 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.
Comentrios:
De fato, no modelo iterativo e incremental, apresenta-se sempre um produto a cada

incremento. J na prototipao, no. Idealmente, ele serve apenas para identificar
requisitos.
Gabarito: C
(CESPE - TJ/DF - Analista Judicirio - Anlise de Sistemas) No modelo de

desenvolvimento incremental, embora haja defasagem entre os perodos de
desenvolvimento de cada incremento, os incrementos so desenvolvidos em
paralelo.
Comentrios:
Questo perfeita. Os incrementos so codificados no exatamente em paralelo h

71410392104
uma pequena defasagem.
Gabarito: C
(CESPE - UNIPAMPA - Anlise de Sistemas) No modelo de

desenvolvimento incremental, a cada iterao so realizadas vrias tarefas. Na
fase de anlise, pode ser feito o refinamento de requisitos e o refinamento do
modelo conceitual.
Comentrios:

Perfeito, a fase seguinte fase de requisitos e busca refin-los.
Gabarito: C
ACERTEI ERREI
71410392104

RAPID APPLICATION DEVELOPMENT (RAD)
O RAD um modelo iterativo e incremental, que enfatiza o ciclo de

desenvolvimento curto (60 a 90 dias). Esse desenvolvimento ocorre to rpido,
porque utilizada o reso de componentes a exausto. Como muitos componentes
j esto testados, pode-se reduzir o tempo total de desenvolvimento. As fases so
mostradas na imagem abaixo:
Modelagem de Negcio: o fluxo de informaes entre as funes de negcio

modelado de modo a responder que informao direciona o processo de
71410392104
negcio; que informao gerada; quem gera essa informao; para onde
vai a informao gerada; e, por fim, quem processa a informao.
Modelagem de Dados: o fluxo de informao definido na fase de modelagem

de negcio refinado em um conjunto de objetos de dados que so
necessrios para suportar o negcio. Os atributos de cada objeto so
identificados e os relacionamentos entre esses objetos so definidos.
Modelagem de Processo: os objetos de dados definidos na modelagem de

dados so transformados para conseguir o fluxo necessrio para implementar

uma funo do negcio. Descries do processamento so criadas para
adicionar, modificar, descartar ou recuperar um objeto de dados.
Gerao da Aplicao: considera o uso de tcnicas de quarta gerao,

trabalha com a reutilizao de componentes de programa existentes quando
possvel, ou cria componentes reusveis. So usadas ferramentas
automatizadas para facilitar a construo do software.
Teste e Modificao: como o processo enfatiza o reso, muitos componentes

j esto testados e isso reduz o tempo total de teste. No entanto, os novos
componentes devem ser testados e todas as interfaces devem ser
exaustivamente exercitadas para colocar o resultado em produo.
71410392104
Neste modelo, h uma interao direta e intensa com o usurio e uso frequente de
programao de banco de dados e ferramentas de apoio ao desenvolvimento,
como geradores de telas e relatrios. Mais abaixo, pode-se ver as vantagens e
desvantagens do modelo. Galera, ele no pode ser utilizado em qualquer situao.
Recomenda-se utiliz-lo quando:

a aplicao no necessita de softwares auxiliares (standalone);

possvel fazer uso de classes pr-existentes;
a performance no o mais importante;
o risco tcnico reduzido;
a distribuio do produto no mercado pequena;
o escopo do projeto restrito;
o sistema pode ser dividido em vrios mdulos;
o risco de mudana tecnolgica baixo.
Permite o desenvolvimento rpido e/ou a Exige recursos humanos caros e experientes.

prototipagem de aplicaes.
Criao e reutilizao de componentes. O envolvimento com o usurio tem que ser
ativo.
Desenvolvimento conduzido em um nvel Comprometimento da equipe do projeto.
mais alto de abstrao.
Grande reduo de codificao manual com Custo alto do conjunto de ferramentas e
wizards. hardware para rodar a aplicao;
Cada funo pode ser direcionada para a uma Mais difcil de acompanhar o projeto.
equipe separada.
Maior flexibilidade (desenvolvedores podem Perda de preciso cientfica (pela falta de
reprojetar vontade). mtodos formais).
Provvel custo reduzido (tempo dinheiro e Pode levar ao retorno das prticas caticas
tambm devido ao reuso). no desenvolvimento.
Tempo de desenvolvimento curto. Pode construir funes desnecessrias.
71410392104
Prottipos permitem uma visualizao mais Requisitos podem no se encaixar (conflitos

cedo. entre desenvolvedores e clientes).
Envolvimento maior do usurio. Padronizao (aparncia diferente entre os
mdulos e componentes)

(CESPE TST - Analista Judicirio - Anlise de Sistemas) O modelo RAD

(Rapid Application Development) consiste em uma forma de prototipao para
esclarecer dvidas da especificao do software.
Comentrios:
RAD um processo de desenvolvimento de software iterativo e incremental que

enfatiza um ciclo de desenvolvimento curto. Ele no uma forma de prototipao,
apesar de poder utiliz-la.
Gabarito: E
(CESPE 2004 BASA Analista de Sistemas) O modelo embasado em

prototipagem um modelo de processo incremental que enfatiza um ciclo de
desenvolvimento extremamente curto. A primeira fase do processo a
modelagem de negcio e a ltima a fase de teste e entrega.
Comentrios:
O RAD um modelo iterativo e incremental, que enfatiza o ciclo de desenvolvimento

curto (60 a 90 dias). Esse desenvolvimento ocorre to rpido, porque utilizada o
reso de componentes a exausto. Como muitos componentes j esto testados,
71410392104
pode-se reduzir o tempo total de desenvolvimento. As fases so mostradas na

imagem abaixo:
Ciclo de desenvolvimento curto? Isso RAD e, no, Prototipagem!
Gabarito: E
(CESPE MPE/AM Analista Judicirio Analista de Sistemas) O modelo

RAD (rapid application development) especfico para projetos de software que
empregam linguagens de programao de terceira gerao.

Comentrios:
No existe qualquer limitao quanto a isso!
Gabarito: E
(CESPE 2011 AL/ES Analista de Sistemas O ciclo de vida RAD (Rapid

Application Development), por privilegiar a rapidez do desenvolvimento, no
possui etapa de modelagem.
Comentrios:
Como no? Existe Modelagem de Negcio, Dados e Processo!
Gabarito: E
(CESPE IGEPREV Analista de Sistemas O modelo Rapid Application

Development (RAD) apropriado para projetos que envolvem grandes riscos
tcnicos.
Comentrios:
Pelo contrrio, apropriado para projetos que envolvem pequenos riscos tcnicos.
Gabarito: E
(CESPE IPEA Analista de Sistemas) O RAD (Rapid Application

Development) um modelo de processo de software incremental que assume
um ciclo de desenvolvimento curto e utiliza uma abordagem de construo com
71410392104
base em componentes.
Comentrios:
Perfeito, exatamente isso!
Gabarito: C
(CESPE TRE/MA Analista de Sistemas O modelo RAD (Rapid

Application Development) uma adaptao de alta velocidade do modelo

sequencial linear, conseguido por meio da construo embasada em
componentes.
Comentrios:
Bem... na minha opinio, seria mais correto afirmar que uma adaptao de alta
velocidade do modelo iterativo incremental. No entanto, o gabarito foi dado como
correto.
Gabarito: C
(CESPE TRE/MA Analista de Sistemas O uso de uma abordagem

de construo embasada em componentes faz que o desenvolvimento no
modelo RAD (Rapid Application Development) seja considerado mais rpido.
Comentrios:
Perfeito, ela se utiliza de uma construo baseada em componentes, fazendo com

que o desenvolvimento seja mais rpido.
Gabarito: C
(CESPE 2013 TRT/17 Analista de Sistemas) O objetivo do RAD separar os

modelos da visualizao e do controle. Ele fornece o controlador e facilita a
escrita de moldes padronizados para a camada de visualizao.
Comentrios:
Galera, esse item no faz qualquer sentido! 71410392104
Gabarito: E
10. (CESPE MPE/AM Analista de Sistemas) O modelo de desenvolvimento

incremental combina caractersticas do modelo de desenvolvimento sequencial
linear com caractersticas do modelo RAD, embora isso resulte em projetos que
sistematicamente apresentam maior durao que aqueles feitos com os dois
modelos de desenvolvimento originais.
Comentrios:

Modelo Incremental no combina caractersticas do Modelo Sequencial Linear com
RAD. Alis, RAD Incremental.
Gabarito: E
11. (CESPE ANS Analista Administrativo Processamento de Dados) O

modelo Rapid Application Development (RAD) uma adaptao do modelo em
espiral para atender a projetos de software fundamentados em componentes.
Comentrios:
Na verdade, ele uma adaptao de alta velocidade do modelo em cascata.
Gabarito: E
ACERTEI ERREI
71410392104

MODELOS EVOLUCIONRIOS
Antes de comearmos, eu acho oportuno dizer que a maioria dos autores

consideram o Modelo Evolucionrio como um tipo de Modelo Iterativo. Um dos
nossos guias, Pressman diz: Os modelos evolucionrios so iterativos, apresentando
caractersticas que possibilitam desenvolver verses cada vez mais completas do
software. Agora hora de ver isso melhor...
Vocs sabem que mudanas so extremamente comuns, i.e., as necessidades de

negcio e de produto mudam frequentemente, tornando inadequado seguir um
71410392104
planejamento em linha reta de um produto final. Hoje em dia, ns vivemos em

funo do tempo! raro um cliente exigir um produto de software com prazos
folgados e tranquilos em geral, o cliente quer o produto para ontem!
Todas essas variveis, prazos apertados, determinados pelo mercado, tornam

impossvel completar um produto de software abrangente, porm uma verso
limitada tem de ser introduzida para aliviar e/ou atender s presses comerciais ou
da concorrncia. E nessa hora que entra o conceito de Modelos Evolucionrios e
suas implementaes.

Dessa forma, podemos afirmar que o Modelo Evolucionrio baseia-se na ideia de
desenvolvimento de uma implementao inicial, expondo o resultado aos
comentrios do usurio e refinando esse resultado por meio de vrias verses at
que seja desenvolvido um sistema adequado ou descartando-o. As implementaes
mais famosas do Modelo Evolucionrio so: Prototipagem e Espiral!
Em geral, a abordagem evolucionria mais eficaz que abordagem em cascata. Por

que? Porque a especificao pode ser desenvolvida de forma incremental. medida
que os usurios compreendem melhor seu problema, isso pode ser refletido no
sistema de software. No entanto, essa abordagem possui dois problemas (inclusive,
j caram no Senado Federal):
O processo no visvel: se os sistemas so desenvolvidos rapidamente, no

vivel economicamente produzir documentos para cada verso do sistema.
Os sistemas so frequentemente mal estruturados: mudanas contnuas tendem

a corromper a estrutura do software e tornar mudanas difceis e caras.
O Pressman recomenda o Desenvolvimento Evolucionrio para sistemas de

pequeno e mdio porte (at 500 mil linhas de cdigo). J para sistemas maiores e
mais complexos, esses problemas supracitados tornam-se mais graves. difcil
estabelecer uma arquitetura estvel, tornando difcil integrar as contribuies das
equipes. Pessoal, isso s uma estimativa!
71410392104
Um esboo simples do processo de desenvolvimento evolucionrio apresentado

acima. As atividades de especificao, desenvolvimento e validao so intercaladas,
em vez de separadas, com feedback rpido que permeia as atividades. Desenvolve-
se rapidamente uma implementao inicial do software a partir de especificaes
bastante abstratas e so feitas modificaes de acordo com sua avaliao.

Cada verso do programa herda as melhores caractersticas das verses anteriores.
Cada verso refinada com base no feedback recebido para produzir um sistema
que satisfaa suas necessidades. Neste ponto, o sistema pode ser entregue ou pode
ser reimplementado utilizando uma abordagem mais estruturada para aumentar a
robustez e a facilidade de manutenes.
As atividades de especificao, desenvolvimento e validao so concorrentes e

apresentam um forte feedback entre si, como mostra a imagem apresentada
anteriormente. Por fim, bom esclarecer a diferena entre Modelo Incremental
Evolucionrio! Pressman afirma que o primeiro tem o objetivo de apresentar um
produto de trabalho ou uma funcionalidade operacional a cada iterao.
J o segundo, durante as primeiras iteraes, pode gerar verses compostas apenas

por modelos em papel ou prottipos. beeeem sutil! Em suma, um Modelo
Evolucionrio no vai necessariamente liberar funcionalidades a cada iterao como
ocorre no Modelo Incremental, logo alguns autores no consideram, por exemplo,
o Modelo Espiral como um Modelo Incremental, mas como Evolucionrio.
71410392104

(FGV 2008 Senado Federal Analista de Sistemas) No modelo evolucionrio,

a mudana constante tende a corromper a estrutura do software.
Comentrios:

sistema de software. Essa abordagem possui dois problemas (inclusive, j caram no
Senado Federal):


Conforme vimos em aula, exatamente isso que acontece!
Gabarito: C
(CESPE TJ/DF Analista de Sistemas) A prototipao evolucionria no

71410392104
gera problemas de manuteno de sistema porque o desenvolvimento rpido

e no sofre grandes mudanas.
Comentrios:

sistema de software. Essa abordagem possui dois problemas (inclusive, j caram no
Senado Federal):


Conforme vimos em aula, gera problemas, sim! Muitas mudanas tendem a

corromper a estrutura do software e isso as tornam difceis e caras. Observao: o
ideal seria que a questo dissesse Modelo ou Abordagem Evolucionria e, no,
Prototipao Evolucionria.
Gabarito: E
ACERTEI ERREI
71410392104

MODELOS EM PROTOTIPAGEM
A Prototipagem utilizada quando no 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 rpido de desenvolvimento e o
prottipo serve como um mecanismo de identificao dos requisitos do software,
que serviro para uma futura especificao.
Um prottipo uma verso inicial de um sistema de software utilizado para

demonstrar conceitos, experimentar opes de projeto e, geralmente, conhecer
71410392104
mais sobre o problema e suas possveis solues. Assim, os custos so controlados

e as partes interessadas do sistema podem experimentar o prottipo mais cedo no
processo de desenvolvimento. A Prototipagem pode ocorrer de duas maneiras:
Desenvolvimento Exploratrio: objetivo do processo trabalhar com o cliente

para explorar os requisitos e entregar um sistema final. O desenvolvimento
comea com as partes do sistema compreendidas. O sistema evolui por meio da
adio de novas caractersticas propostas pelo cliente.
Prototipao Throwaway: o objetivo do processo de desenvolvimento

evolucionrio compreender os requisitos do cliente e, a partir disso,

desenvolver melhor definio de requisitos para o sistema. O prottipo se
concentra na experimentao dos requisitos mal compreendidos do cliente.
IMPORTANTE
Quando uma questo no especifica o tipo de prototipao, geralmente se trata de Prototipao

Throw-away/Descartvel e, no, Evolucionria/Exploratria. Sommerville declara: Uso o termo
prototipao no sentido de processo iterativo de desenvolvimento de um sistema experimental que
no destinado disponibilizao ao cliente.
Um prottipo de software pode ser utilizado em um processo de desenvolvimento

de diversas maneiras! Veremos trs modos possveis de utilizao:
a) No processo de engenharia de requisitos, um prottipo pode ajudar na

descoberta e validao dos requisitos do sistema.
b) Processo de projeto do sistema, um prottipo pode ser usado para explorar

solues especficas de software e apoiar o projeto de interface com o usurio.
c) No processo de teste, um prottipo pode ser usado para realizar testes

completos com o sistema que ser entregue para o cliente.
A metodologia de Prototipagem Evolutiva (ou Evolucionria) uma abordagem que

visualiza o desenvolvimento de concepes do sistema conforme o andamento do
projeto at chegar ao resultado final. Esta metodologia baseia-se na utilizao de
prototipagem visual ou modelos do sistema final. Estes modelos podem ser simples
desenhos ou imagens do sistema.
Prottipos permitem que os usurios introduzam novas ideias para os requisitos e

71410392104
encontrem pontos fortes e fracos no software. Ademais, prottipos podem revelar

erros e omisses nos requisitos propostos, alm de reduzirem o tempo e esforo de
desenvolvimento, treinamento e documentao o sistema. Professor, s h
vantagens? No, h desvantagens tambm! Olha s...
Anlise insuficiente, devido a desenvolvedores que se focam s no prottipo e

esquecem de analisar o problema global; usurios confundem prottipo com o
sistema final, sendo que sero descartados posteriormente; documentao pode ser
prejudicada; falta de visibilidade do progresso quando o sistema evolui, mas nunca
termina; tempo excessivo para desenvolver o prottipo; etc.

Como apresenta a imagem acima, o paradigma de prototipao comea com a

comunicao. Encontra-se com as partes interessadas para definir os objetivos
gerais do software, identificar os requisitos conhecidos e definir reas em que uma
definio mais profunda obrigatria. Uma iterao de prototipao planejada
rapidamente e, ento, ocorre a modelagem dessa iterao.
Um plano rpido se foca na representao daqueles aspectos do software que sero

visveis aos usurios finais e leva construo do prottipo. O prottipo
implantado e avaliado pelas partes interessadas, que fornecem feedbacks que sero
utilizados para refinar os requisitos. A iterao ocorre medida que o prottipo
71410392104
ajustado para satisfazer as necessidades dos diversos stakeholders.
Ao mesmo tempo, ele ajuda a entender melhor o que precisa ser feito! Idealmente,
o prottipo serve como um mecanismo para identificar requisitos de software. Se
um prottipo ser construdo, pode-se utilizar partes existentes de programas ou
aplicar ferramentas que permitem que programas sejam gerados rapidamente. E o
que fazer com o prottipo construdo?
Na maioria dos casos, o prottipo invivel de ser utilizado, por ser muito lento
e/ou muito grande e/ou difcil de utilizar. Em geral, os prottipos so descartados
assim que os objetivos de levantamento de requisitos so alcanados. No entanto,

alguns preferem refin-los iterativamente at evoluir ao sistema final requisitado
pelo usurio. Captaram?
71410392104

(CESPE UNIPAMPA Analista de Sistemas) No modelo de

desenvolvimento prototipagem, um prottipo desenvolvido para ajudar no
entendimento dos requisitos do sistema.
Comentrios:

de entend-los melhor para posteriormente desenvolver o software. Ela se configura
como um processo iterativo, interativo e rpido de desenvolvimento e o prottipo
serve como um mecanismo de identificao dos requisitos do software, que serviro
para uma futura especificao.
Conforme vimos em aula, um prottipo em geral desenvolvido para ajudar no

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

prototipagem evolutiva uma abordagem que visualiza o desenvolvimento de
concepes do sistema conforme o andamento do projeto, por meio de
prottipos visuais.
Comentrios: 71410392104

Gabarito: C

(CESPE 2004 TRE/AL Analista de Sistemas) No modelo de prototipao, o
desenvolvedor cria inicialmente um modelo de software que ser posteriormente
implementado.
Comentrios:

Na maioria dos casos, o prottipo invivel de ser utilizado, por ser muito lento e/ou
muito grande e/ou difcil de utilizar. Em geral, os prottipos so descartados assim
que os objetivos de levantamento de requisitos so alcanados. No entanto, alguns
preferem refin-los iterativamente at evoluir ao sistema final requisitado pelo
usurio. Captaram?
Conforme vimos em aula, cria-se, inicialmente, um modelo do sistema final! Alm

disso, o prottipo pode ser implementado e se tornar esse sistema final. Galera, essa
questo 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 questo? Sua traduo!
Pressman afirma que a Prototipao um processo que permite ao desenvolvedor

a construo de um modelo software que ser construdo. Em outras palavras, a
prototipao um modelo/esboo do software que posteriormente ser construdo.
Pensem em um software qualquer! Antes de construir o software, faremos um
modelo/esboo dele (no importando se iremos descart-lo ou no).
71410392104
Gabarito: C
(CESPE 2007 TSE Analista de Sistemas) Um possvel objetivo da

prototipao criar rapidamente um sistema experimental que possa ser
avaliado por usurios finais. Um prottipo aprovado pelos usurios pode vir a
ser usado como ponto de partida para a construo do sistema.
Comentrios:

Na maioria dos casos, o prottipo invivel de ser utilizado, por ser muito lento e/ou
muito grande e/ou difcil de utilizar. Em geral, os prottipos so descartados assim
que os objetivos de levantamento de requisitos so alcanados. No entanto, alguns
preferem refin-los iterativamente at evoluir ao sistema final requisitado pelo
usurio. Captaram?
Conforme vimos em aula, uma alternativa, i.e., posso us-lo como ponto de
partida para construo do sistema, em vez de descart-lo!
Gabarito: C
(CESPE MPE/AM Analista de Sistemas) No modelo de prototipao,

a especificao de requisitos tem pouca importncia, pois o software
continuamente adaptado em funo dos desejos do usurio.
Comentrios:

Conforme vimos em aula, a prototipao serve no s para o levantamento de

requisitos, mas tambm para sua especificao. Galera, como no tem importncia?
para isso que ele serve!
Gabarito: E
71410392104
(CESPE TJ/DF Analista de Sistemas) Uma vantagem da prototipao

promover a participao e o comprometimento do usurio em relao ao
sistema em desenvolvimento.
Comentrios:

erros e omisses nos requisitos propostos, alm de reduzirem o tempo de

Conforme vimos em aula, percebam que a prototipao promove uma grande

participao dos usurios no processo de desenvolvimento.
Gabarito: C
(CESPE TJ/D Analista de Sistemas) A prototipao de um software

uma tcnica de desenvolvimento no-interativa porque o teste do sistema s
ocorre na verso final.
Comentrios:

Conforme vimos em aula, ela tanto iterativa (repete-se diversas vezes) quanto
interativa (conta com a participao ativa dos usurios).
Gabarito: E
(CESPE TJ/DF Analista de Sistemas) Uma das finalidades da

prototipao reduzir o esforo de desenvolvimento de um software.
Comentrios:

71410392104

erros e omisses nos requisitos propostos, alm de reduzirem o tempo e esforo de
Conforme vimos em aula, a questo est perfeita! Ela realmente ajuda a reduzir o
esforo!
Gabarito: C

(CESPE 2010 INMETRO Analista de Sistemas Um dos benefcios da
prototipao a documentao normalmente gerada, que facilita a manuteno
dos sistemas a longo prazo e a elaborao de casos de teste.
Comentrios:

Conforme vimos em aula, justamente o inverso! A documentao geralmente

prejudicada quando se utiliza a prototipao! Imaginem s: voc precisa entregar
algo rpido para o usurio verificar se satisfaz seus requisitos, no vivel fazer uma
documentao formal.
Gabarito: E
10. (CESPE 2010 INMETRO Analista de Sistemas D) Um dos riscos da

prototipao o usurio confundir o prottipo com o sistema verdadeiro e criar
falsas expectativas com relao a prazos e recursos.
Comentrios:

71410392104
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 prottipo do software produzido e
utilizado para identificar possveis problemas com os requisitos, sendo
descartado logo em seguida, e o desenvolvimento do software propriamente
dito , ento, iniciado.

Comentrios:

Conforme vimos em aula, se o prottipo descartado, ento no se trata de uma

abordagem evolutiva!
Gabarito: E
12. (CESPE 1 Analista de Sistemas) No modelo de prototipao, o

processo de desenvolvimento de software modelado como uma sequncia
linear de fases, enfatizando um ciclo de desenvolvimento de breve durao.
Comentrios:

Conforme vimos em aula, no linear, mas iterativo!
71410392104
Gabarito: E
13. (CESPE 2013 TRT/10 Analista Judicirio Tecnologia da Informao) No

modelo prototipao, a construo de software tem vrias atividades que so
executadas de forma sistemtica e sequencial.
Comentrios:
Na verdade, quem constri software por meio de atividades executadas de forma

sistemtica e sequencial o Modelo em Cascata; a prototipao iterativa.
Gabarito: E

14. (CESPE TCE/RN Assessor Tcnico de Informtica) A prototipao, uma

abordagem para desenvolvimento de software na qual se cria um modelo do
software que ser implementado, composta de quatro etapas: planejamento,
anlise de risco, engenharia e avaliao do cliente.
Comentrios:
Conforme vimos em aula, as etapas so Comunicao, Plano Rpido, Modelagem

de Plano Rpido, Construo do Prottipo, e Implementao, Entrega e Feedback.
As etapas mencionadas na questo so do Modelo em Espiral. Alm disso, no ser
necessariamente implementado.
Gabarito: E
71410392104
15. (CESPE DETRAN/DF Analista de Sistemas) O modelo de processo de

desenvolvimento de software evolucionrio parte do desenvolvimento de uma
implementao inicial cujos resultados so apresentados aos clientes e refinados
por meio de vrias verses at que se alcance o sistema adequado. A
prototipao, como processo, tem por objetivo compreender as especificaes
do software para se chegar aos requisitos para o sistema.
Comentrios:
Desenvolvimento Exploratrio: objetivo do processo trabalhar com o cliente para

explorar os requisitos e entregar um sistema final. O desenvolvimento comea

com as partes do sistema compreendidas. O sistema evolui por meio da adio
de novas caractersticas propostas pelo cliente.
Prototipao Throwaway: o objetivo do processo de desenvolvimento

evolucionrio compreender os requisitos do cliente e, a partir disso, desenvolver
melhor definio de requisitos para o sistema. O prottipo se concentra na
experimentao dos requisitos mal compreendidos do cliente.
Conforme vimos em aula, a Prototipao Throwaway busca, na verdade,

compreender os requisitos para chegar especificao a segunda sentena
inverteu esses conceitos!
Gabarito: E
16. (CESPE TJ/DF Analista de Sistemas) A prototipao evolucionria

permite que a verso inicial do prottipo seja desenvolvida e refinada em
estgios sequenciados, at que se chegue verso final do sistema.
Comentrios:
Um prottipo uma verso inicial de um sistema de software utilizado para

demonstrar conceitos, experimentar opes de projeto e, geralmente, conhecer mais
sobre o problema e suas possveis solues. Assim, os custos so controlados e as
partes interessadas do sistema podem experimentar o prottipo mais cedo no
processo de desenvolvimento. A Prototipagem pode ocorrer de duas maneiras:
Desenvolvimento Exploratrio: objetivo do processo trabalhar com o cliente para

explorar os requisitos e entregar um sistema final. O desenvolvimento comea
com as partes do sistema compreendidas. O sistema evolui por meio da adio
71410392104
de novas caractersticas propostas pelo cliente.
Conforme vimos em aula, a questo est perfeita! Trata da prototipao

evolucionria ou exploratria.
Gabarito: C
17. (CESPE 2011 MEC Anlise de Sistemas) No modelo de prototipao, o


Comentrios:
Na verdade, no linear iterativo.
Gabarito: E
18. (VUNESP - 2009 - CETESB - Analista de Tecnologia da Informao - Banco de

Dados) Considere um sistema cujos requisitos de interface so definidos apenas
quando o cliente realiza um test-drive na aplicao 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) Prototipao.
e) Rapid Application Development.
Comentrios:

A afirmativa diz que o sistema possui requisitos de interface que so definidos

apenas quando o cliente realiza um test-drive, i.e., um teste inicial na aplicao e
aprova essa interface. Em outras palavras, o cliente valida ou no esses requisitos a
71410392104
partir de uma primeira utilizao do sistema. Que metodologia de desenvolvimento

de software pode ser utilizada para levantar e validar/aprovar requisitos? Trata-se da
Prototipao!
Gabarito: D
ACERTEI ERREI

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
71410392104
representar o processo
como uma sequncia
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 Deciso, Anlise de Riscos, etc).

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

com a prototipao. Cada loop representa uma fase do processo de software. Dessa
forma, o loop mais interno pode estar relacionado viabilidade do sistema; o
prximo loop, definio de requisitos; o prximo, ao projeto de sistema e assim
por diante. De acordo com Sommerville, divide-se em quatro setores:
Determinar objetivos, alternativas e restries: definem-se os objetivos da do

projeto (aumentar performance, consertar funcionalidade, melhorar
qualidade), identificam-se alternativas (reso de componentes, comprar
pronto) e identificam-se restries impostas (custo, cronograma, etc).
Avaliar alternativas, identificar e resolver riscos: avaliam-se as alternativas

identificadas em relao aos objetivos e restries. Frequentemente, esse
processo identifica reas de incerteza (custos excessivos, falta de recursos) e
resolve ou reduz os riscos identificados - um prottipo pode ser construdo.
Desenvolv e test : aps a reduo dos riscos, um modelo de

desenvolvimento para o sistema selecionado (Ex: prototipao
evolucionria, modelos formais, modelo em cascata, modelos baseados em
componentes). O software desenvolvido e, posteriormente, testado.
anejar prximas fases: revisa-se o projeto e decide-se sobre o

prosseguimento ao prximo loop da espiral. Se a deciso for pelo
prosseguimento, so elaborados planos para a prxima fase do projeto, e
terminamos um loop.
De acordo com Pressman, cada espiral dividida em cinco setores1:

71410392104
Comunicao: a comunicao em si;

Planejamento: estimativa de custos, cronograma e anlise de riscos;
Modelagem: anlise e design;
Construo: codificao e teste;
Implantao: entrega e feedback;
1
Na verso anterior, eram seis etapas no Modelo em Espiral (Planejamento, Anlise de Riscos, Engenharia,
Construo e Liberao, Avaliao do Cliente e Comunicao com Cliente). Variaes do modelo consideram
entre trs e seis setores da espiral. Infelizmente, cada autor pega a verso original e adapta, criando sua verso.
Portanto, vocs vero muitos nomes diferentes para cada setor.

IMPORTANTE
Cada loop na espiral representa uma fase no processo, entretanto essas fases no so fixas, i.e., escolhem-
se quais fases se deseja realizar. J as atividades so fixas (Comunicao, Planejamento, etc), no entanto
no so obrigatrias. 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 so
fixas (Planejamento, Modelagem, Construo, Implantao, Comunicao), i.e., no posso criar uma nova
atividade. No entanto, no so obrigatrias, i.e., posso eventualmente no realizar todas as atividades.
71410392104
Vocs 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 manuteno. Pode tratar de todo ciclo de vida...
Cada loop uma fase e a fase escolhida de acordo com as necessidades do

negcio! J as atividades do processo so fixas para todos os loops (no
obrigatrias). No entanto, Boehm utiliza uma diviso de atividades diferente do
Pressman. No caso de dvida, considerem a verso original do Modelo de Boehm.
Alm disso, ao final de cada loop, h uma tomada de deciso a respeito do projeto.

Vocs perceberam, pela imagem acima, que existem prottipos que so 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 relao aos outros modelos? Porque ele enfatiza bastante um
aspecto que o diferencia dos demais: Anlise de Riscos.
Este um modelo complexo que precisa ser gerenciado por pessoas que tenham
grande experincia na avaliao de riscos. Geralmente, o modelo utilizado em
sistemas crticos e grandes! Por fim, vamos ver um tema mais polmico: ele
evolucionrio ou incremental? Pressman diz que iterativo, mas, no, incremental
sendo, ento, evolucionrio. Logo, nele em que vamos nos basear2!
O conceito essencial do modelo minimizar os riscos pelo uso repetido de

prottipos e outros meios. Ao contrrio de outros modelos, em cada fase a anlise
de risco realizada. O modelo funciona atravs da construo de verses
progressivamente mais completas do software, iniciando no centro da espiral para
o exterior. A cada volta, o cliente avalia o trabalho e so feitas sugestes.
O modelo, ento, se diferencia por ter uma abordagem cclica, para aumentar
incrementalmente o grau de definio e de implementao de um sistema
enquanto diminui seu grau de risco; e por ter conjunto de marcos de ancoragem,
para garantir o comprometimento dos interessados com solues exequveis e
mutuamente satisfatrias para o sistema.
Suporta mecanismos de reduo de riscos. Exige analistas de risco bastante experientes.
Obtm-se verses do sistema a cada iterao. Exige uma equipe de desenvolvimento extremamente
71410392104
qualificada.
Entregando produtos cada vez mais refinados e de Exige um gerenciamento de processo mais complexo.
melhor qualidade.
Reflete as prticas reais de engenharia atual. No recomendado resolver problemas mais
simples e pequenos.
Apresenta uma abordagem sistemtica.
Apresenta estimativas realsticas.
2
Apesar disso, comum outros autores tratarem o Modelo em Espiral como iterativo e incremental.

ESQUEMA
Somente com esse esquema, responde-se grande parte das questes a seguir...
71410392104

(FCC - 2012 - TST - Analista Judicirio - Anlise de Sistemas) O Ciclo de Vida de

um Sistema especifica todas as fases de desenvolvimento, desde sua concepo
at o processo de manuteno e declnio. No que diz respeito ao
desenvolvimento de software, existem alguns processos conhecidos. Um destes
processos, possui caracterstica iterativa e incremental, inicia cada fase do projeto
realizando um planejamento prvio, realiza a execuo da fase, verifica o
progresso e os resultados da fase (riscos, lies aprendidas) e incrementa novos
objetivos para a fase seguinte, seguindo para a prxima iterao. O processo de
software em questo o:
a) Modelo espiral.
b) Ciclo de vida em cascata.
c) Modelo de desenvolvimento evolucionrio (prototipao).
d) Modelo de desenvolvimento gil.
e) Mtodo de desenvolvimento Cleanroom (Sala Limpa).
Comentrios:
Conforme vimos no esquema, ele citou todos os setores do Modelo Espiral (os
nomes esto um pouco diferentes, mas apenas uma variao). Essa questo tem
um detalhe: ela afirma que o modelo espiral iterativo e incremental, mas j vimos
que o Pressman afirma que ele iterativo e evolucionrio, mas no incremental.
71410392104
Gabarito: A
(FCC - 2010 - TRT - 20 REGIO (SE) - Analista Judicirio - Tecnologia da

Informao) medida que se avana pelo modelo ocorre uma iterao e o
software evolui para estgios superiores, normalmente com aumento da
complexidade. Cada iterao est provida das atividades determinadas pelos
quadrantes planejamento, avaliao de alternativas e riscos, desenvolvimento do
software e avaliao do cliente. No ciclo de vida de desenvolvimento de software,
trata-se da propriedade do modelo:
a) Cascata.

b) Incremental.
c) Espiral.
d) Prototipao.
e) Balbrdia.
Comentrios:
Conforme vimos em aula, a questo fala de iterao, logo no pode ser Modelo em
Cascata! Por outro lado, a questo fala em avaliao de alternativas e riscos,
enfatizada (em verde em nosso esquema). Logo, trata-se claramente do Modelo em
Espiral. Percebam que a questo faz uma confuso com os setores de cada autor,
mas est correta.
Gabarito: C
(FCC - 0 MPE/RN Analista de Sistemas) O modelo em espiral difere

principalmente dos outros modelos de processo de software por:
a) no contemplar o prottipo.
b) reconhecer explicitamente o risco.
c) no ter fases.
d) possuir uma fase nica evolucionria.
e) no contemplar o projeto do produto.
Comentrios:
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
71410392104
destaca em relao aos outros modelos? Porque ele enfatiza bastante um aspecto
que o diferencia dos demais: Anlise de Riscos.
Conforme vimos em aula, reconhecimento explcito no risco.
Gabarito: B
(FCC - 2012 TRE/CE Analista de Sistemas) No desenvolvimento de software

em espiral (Boehm), cada loop est dividido em quatro setores. NO se trata da
denominao de um destes setores:

a) levantamento.
b) definio de objetivos.
c) avaliao e reduo de riscos
d) desenvolvimento e validao.
e) planejamento.
Comentrios:


Desenvolver e testar: aps a reduo dos riscos, um modelo de

desenvolvimento para o sistema selecionado (Ex: prototipao evolucionria,
modelos formais, modelo em cascata, modelos baseados em componentes). O
software desenvolvido e, posteriormente, testado.
Planejar prximas fases: revisa-se o projeto e decide-se sobre o

terminamos um loop.
Conforme vimos em aula, levantamento no um dos setores.

71410392104
Gabarito: E
(FCC 2010 BAHIAGS 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 deciso.
d) uma fase do processo.
e) um ciclo de programa.

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

a prototipao. Cada loop representa uma fase do processo de software. Dessa forma,
o loop mais interno pode estar relacionado viabilidade do sistema; o prximo loop,
definio de requisitos; o prximo, ao projeto de sistema e assim por diante. De
acordo com Sommerville, divide-se em quatro 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.
Comentrios:
Conforme vimos em aula, est perfeito!
Gabarito: C
71410392104
(CESPE TJ/DF Analista Judicirio Tecnologia da Informao) O

modelo em espiral um modelo de processos de software que rene a natureza
iterativa da prototipao com os aspectos sistemticos e controlados do modelo
sequencial linear.
Comentrios:
conhecido como prototipagem- -etapas, por combinar o modelo em cascata com


acordo com Sommerville, divide-se em quatro etapas:
Conforme vimos em aula, Modelo em Espiral tambm conhecido como

Prototipagem-Em-Etapas, por conta disso!
Gabarito: C
(CESPE 2004 COHAB Analista Judicirio Tecnologia da Informao) O

modelo espiral um modelo de processo de software que combina a natureza
iterativa da prototipagem com os aspectos controlados e sistemticos do modelo
sequencial linear.
Comentrios:

Conforme vimos em aula, est perfeito! Galera, eu no errei! Essa questo quase
idntica anterior: o CESPE copiando do CESPE!
Gabarito: C
(CESPE - TJ/DF - Analista Judicirio - Tecnologia da Informao)

Empregando o modelo de desenvolvimento em espiral, o software
desenvolvido em uma srie de verses intermedirias incrementais.
71410392104
Comentrios:
sendo, ento, evolucionrio. Logo, nele em que vamos nos basear!
Conforme vimos em aula, o Pressman discorda! A questo fala que o software

desenvolvido em uma srie de verses intermedirias incrementais. Ora, modelos

iterativos geram uma srie de verses intermedirias; modelos incrementais geram
incrementos. Logo, pode-se assumir que a questo afirma que se trata de um
modelo iterativo e incremental. Pressman discorda, mas no 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 sequncia de atividades relacionadas produo de software realizada
a cada ciclo da espiral.
Comentrios:
IMPORTANTE
Cada loop na espiral representa uma fase no processo, entretanto essas fases no so fixas, i.e., escolhem-se
quais fases se deseja realizar. J as atividades so fixas (Comunicao, Planejamento, etc), no entanto no so
obrigatrias. 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 so fixas (Planejamento,
Modelagem, Construo, Implantao, Comunicao), no posso criar uma atividade entre essas. No entanto,
no so obrigatrias, i.e., posso eventualmente no fazer trs ltimas fases.
Conforme vimos em aula, nem sempre a mesma sequncia de atividades

realizada. Portanto, questo errada!
Gabarito: E

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

Conforme vimos em aula, ele iterativo, portanto permite replanejamento a cada
nova iterao.
Gabarito: C
12. (CESPE - - ANTAQ - Analista Administrativo - Informtica) 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
ausncia de risco nesse modelo o diferencia dos demais modelos de software.
Comentrios:
Na verdade, a presena da Anlise de Riscos que o diferencia.
Gabarito: E
13. (CESPE IPEA Analista de Sistemas) O modelo espiral um modelo

evolucionrio de processo de software que combina a prototipagem com o
modelo em cascata. Contudo, a incerteza em relao ao nmero de ciclos
necessrios para construir o projeto, leva tal abordagem a empregar o modelo
de mtodos formais para viabiliz-lo.
Comentrios: 71410392104

Conforme vimos em aula, a primeira parte est perfeita! No entanto, no faz sentido
empregar o modelo de mtodos formais porque no se sabe estimar o nmero de
ciclos para construir um projeto. Ele tem uma natureza iterativa que permite reduzirs
riscos a cada loop.

Gabarito: E
14. (CESPE UNIPAMPA Analista de Sistemas) O modelo espiral admite

retorno s fases anteriores de desenvolvimento, suportando ainda a execuo
paralela de fases.
Comentrios:
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 sequncia de atividades com
algum retorno entre uma atividade e outra, o processo representado como uma
espiral.
Conforme vimos em aula, ele no admite retorno s fases anteriores e, como espiral
que , no permite a execuo 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.
Comentrios:
71410392104

Gabarito: C
16. (CESPE 2004 BASA Analista de Sistemas) O modelo em espiral evolui

medida que o processo avana, permitindo ao desenvolvedor e ao cliente
entenderem melhor os riscos e reagirem em cada nvel evolucionrio.

Comentrios:
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 dcada de 70 do sculo passado.
Tal modelo considera as seguintes fases: anlise de requisitos, definio, projeto,
implementao, integrao e testes, operao e manuteno.
Comentrios:
Conforme vimos em nosso esquema, as fases so: Comunicao, Planejamento,

Modelagem, Construo e Implantao. As fases mencionadas so do Modelo em
Cascata.
Gabarito: E
18. (CESPE 2004 PBV/RR Analista de Sistemas) O modelo em espiral de

desenvolvimento proposto por Boehm apresenta a anlise de riscos como uma
das suas fases essenciais. 71410392104
Comentrios:
Conforme vimos em aula, est errado! A anlise de riscos no uma fase, mas uma
atividade. No entanto, a banca no entendeu dessa maneira :(

Gabarito: C
19. (CESPE 2004 STJ Analista de Sistemas) O modelo de desenvolvimento em

espiral requer a considerao dos riscos tcnicos em todos os estgios ou
interaes do projeto, o que permite reduzir os riscos antes que se concretizem.
Comentrios:
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
prototipao, acrescentando a anlise de risco, inexistente nestes dois modelos.
Comentrios:
71410392104
Conforme vimos em aula, existe sim Anlise de Riscos no Modelo em Espiral. No

entanto, isso no significa que ela seja inexistente no Modelo em Cascata e no
Modelo de Prototipao, ela apenas no explcita como no Modelo em Espiral.
Gabarito: E

21. (CESPE CENSIPAM Analista de Sistemas) O modelo espiral iterativo
e incremental, assim como so os modelos de processo unificado, de
prototipao, de desenvolvimento rpido de aplicaes e em cascata.
Comentrios:
Conforme vimos em aula, o Modelo Espiral Evolucionrio (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 caractersticas semelhantes: ambos permitem que as
atividades do processo sejam planejadas e avaliadas ao longo do ciclo de vida.
Comentrios:



71410392104


terminamos um loop.
Perfeito, conforme vimos em aula! Lembrando que o Modelo Espiral um tipo de

Modelo Iterativo.

Gabarito: C
(CESPE ANATEL Analista de Sistemas) Entre os modelos de ciclo de

vida de software, o modelo espiral possui maior proximidade com as prticas da
engenharia clssica empregadas, por exemplo, na construo de casas, quando
comparado aos modelos cascata e de componentes reusveis.
Comentrios:

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

Componentes Reusveis, que so processos de desenvolvimento mais sistemticos.
A construo de casas seria um modelo iterativo e incremental, eu acredito!
Gabarito: E
24. (CESPE INMETRO Analista de Sistemas) Uma das caractersticas

marcantes do modelo de desenvolvimento em espiral o fato de ele ser cclico,
e no linear, como o modelo de desenvolvimento em cascata.
Comentrios:
71410392104

Conforme vimos em aula, exatamente isso! Cuidado para no escorregar no

portugus: a questo parece ambgua, mas ela afirma que uma das caractersticas
marcantes do modelo de desenvolvimento em espiral o fato de o modelo espiral
ser cclico, 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
caractersticas do ciclo de vida clssico.
71410392104
Comentrios:

Conforme vimos em aula, esse item no faz qualquer sentido! Ele no uma
implementao do Modelo em Cascata ele um modelo hbrido que combina
caractersticas do Modelo em Cascata com o Modelo de Prototipagem.

Gabarito: E

desenvolvimento em espiral, a anlise de riscos no impacta na elaborao de
um produto ou prottipo.
Comentrios:
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 no so considerados, pois
podem impactar o projeto.
Comentrios:
71410392104

Conforme vimos em aula, riscos so considerados!
Gabarito: E
(CESPE 2010 TRE/MT Analista de Sistemas E) O modelo de

desenvolvimento em espiral, que tem a codificao como segunda etapa, gera
o cdigo do sistema muito mais rapidamente que o modelo de prototipao.

Comentrios:
Conforme vimos em aula, a terceira etapa e no gera o cdigo mais rapidamente

que o modelo de prototipao, que bem mais rpido.
Gabarito: E
(CESPE - 2013 - STF - Tcnico Judicirio - Tecnologia da Informao) O processo

de software fundamentado no modelo em espiral apresenta o processo em
loops compostos basicamente por setores, como, por exemplo, definio de
objetivos, avaliao de riscos, planejamento e desenvolvimento e avaliao.
71410392104
Comentrios:





terminamos um loop.
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.
Comentrios:
Vocs 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 manuteno. Pode tratar de todo ciclo de vida...
71410392104
Conforme vimos em aula, Modelo Espiral de Modelagem de Processos de

Desenvolvimento de Software no existe! A questo viajou agora! Ele finalizado
quando o software implantado? No, necessariamente mas possvel.
Gabarito: E
31. (CESPE - 1 AL/ES - Analista Judicirio - Tecnologia da Informao) No ciclo

de vida em espiral, a de anlise de risco realizada na etapa da modelagem do
produto.
Comentrios:

De acordo com Pressman, cada espiral dividida em cinco etapas:
Comunicao: a comunicao em si;

Planejamento: estimativa de custos, cronograma e anlise de riscos;
Modelagem: anlise e design;
Construo: codificao e teste;
Implantao: entrega e feedback;
Conforme vimos em aula, est de acordo com Pressman (ltima verso); realizada
na etapa de Planejamento e, no, Modelagem.
Gabarito: E
(CESPE 2004 PBV/RR Analista de Sistema) O modelo em cascata linear e

seqencial. Modelos como o espiral e o Rational Unified Process pregam o
desenvolvimento iterativo.
Comentrios:
Gabarito: C
(ESAF 2010 MPOG Analista de Sistemas) As atividades do modelo espiral

de Engenharia de Software so:
a) Planejamento, Anlise dos Componentes, Anlise de Hierarquia e Avaliao

feita pelo cliente. 71410392104
b) Planejamento, Anlise dos Riscos, Engenharia e Avaliao feita pelo cliente.

c) Projeto, Anlise dos Benefcios, Engenharia e Avaliao feita pelo gestor.
d) Planejamento, Eliminao dos Riscos, Anlise de Contingncia e Avaliao
feita pelo cliente.
e) Planejamento, Projeto, Anlise dos Riscos e Engenharia.
Comentrios:
Gabarit B

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

seguir corresponde ao modelo de processo, proposto no final da dcada de 80,
que tem como principais caractersticas ser evolucionrio, iterativo e focado na
reduo dos riscos?
a) Modelo em Espiral.
b) Modelo em Cascata.
c) Modelo em V.
d) Modelo Transformacional.
e) Modelo de Especificao Operacional.
Comentrios:
Ele foi proposto originalmente, em 1988, por Boehm. Vocs perceberam, pela imagem
acima, que existem prottipos que so 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 relao aos outros?
Porque ele enfatiza bastante um aspecto: Anlise de Riscos.
Conforme vimos em aula, a questo est perfeita! Ele disse que o modelo
evolucionrio e iterativo alm 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 so:
71410392104

feita pelo cliente.

feita pelo cliente.

Comentrios:
Conforme vimos em aula, trata-se da ltima variao: Planejamento, Anlise de

Riscos, Engenharia e Avaliao do Cliente. 71410392104
Gabarito: B
ACERTEI ERREI

LISTA DE EXERCCIOS COMENTADOS (DIVERSAS BANCAS)

CONCEITOS BSICOS DE ENGENHARIA DE SOFTWARE
(FCC - 2012 - - 6 Regio (PE) - Tcnico Judicirio - Tecnologia da

Informao - E) Considere: uma disciplina que se ocupa de todos os aspectos
da produo de software, desde os estgios iniciais de especificao do sistema
at a manuteno desse sistema, depois que ele entrou em operao. Seu
principal objetivo fornecer uma estrutura metodolgica para a construo de
software com alta qualidade. A definio refere-se Engenharia de Software.
(CESPE - 2013 - TRT - 10 REGIO (DF e TO) - Analista Judicirio - Tecnologia da

Informao A engenharia de software engloba processos, mtodos e
ferramentas. Um de seus focos a produo de software de alta qualidade a
custos adequados.
(FCC - 2012 - TST - Analista Judicirio - Anlise de Sistemas A Engenharia de

Software:
a) uma rea da computao que visa abordar de modo sistemtico as questes

tcnicas e no tcnicas no projeto, implantao, operao e manuteno no
desenvolvimento de um software.
b) consiste em uma disciplina da computao que aborda assuntos relacionados

a tcnicas para a otimizao de algoritmos e elaborao de ambientes de
desenvolvimento.
c) trata-se de um ramo da TI que discute os aspectos tcnicos e empricos nos

processos de desenvolvimento de sistemas, tal como a definio de artefatos
71410392104
para a modelagem gil.
d) envolve um conjunto de itens que abordam os aspectos de anlise de

mercado, concepo e projeto de software, sendo independente da engenharia
de um sistema.
e) agrupa as melhores prticas para o concepo, projeto, operao e

manuteno de artefatos que suportam a execuo de programas de
computador, tais como as tcnicas de armazenamento e as estruturas em
memria principal.

Informao) Considere: uma disciplina que se ocupa de todos os aspectos da
manuteno desse sistema, depois que ele entrou em operao. Seu principal
objetivo fornecer uma estrutura metodolgica para a construo de software
com alta qualidade. A definio refere-se:
a) ao ciclo de vida do software.

b) programao orientada a objetos.
c) anlise de sistemas.
d) engenharia de requisitos.
e) engenharia de software.
(CESPE - 2011 - MEC - Gerente de Projetos A engenharia de software, disciplina

relacionada aos aspectos da produo de software, abrange somente os
processos tcnicos do desenvolvimento de software.
(FGV - 2010 - BADESC - Analista de Sistemas - Desenvolvimento de Sistemas De

acordo com Pressman, a engenharia de software baseada em camadas, com
foco na qualidade.
Essas camadas so:
a) mtodos, processo e teste.

b) ferramentas, mtodos e processo.
c) mtodos, construo, teste e implantao.
d) planejamento, modelagem, construo, validao e implantao.
e) comunicao, planejamento, modelagem, construo e implantao.
71410392104
(CESPE - 2010 - Banco da Amaznia - Tcnico Cientfico - Tecnologia da

Informao Os princpios de engenharia de software definem a necessidade de
formalidades para reduzir inconsistncias e a decomposio para lidar com a
complexidade.
(FCC - 2010 - TRE- - Analista Judicirio - Tecnologia da Informao - A A

Engenharia de Software:
a) no tem como mtodo a abordagem estruturada para o desenvolvimento de

software, pois baseia-se exclusivamente nos modelos de software, notaes,
regras e tcnicas de desenvolvimento.

b) se confunde com a Cincia da Computao quando ambas tratam do

desenvolvimento de teorias, fundamentaes e prticas de desenvolvimento de
software.
c) tendo como foco apenas o tratamento dos aspectos de construo de

software, subsidia a Engenharia de Sistemas no tratamento dos sistemas
baseados em computadores, incluindo hardware e software.
d) tem como foco principal estabelecer uma abordagem sistemtica de

desenvolvimento, atravs de ferramentas e tcnicas apropriadas, dependendo
do problema a ser abordado, considerando restries e recursos disponveis.
e) segue princpios, tais como, o da Abstrao, que identifica os aspectos

importantes sem ignorar os detalhes e o da Composio, que agrupa as
atividades em um nico processo para distribuio aos especialistas.
(FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI Em relao

Engenharia de Software, INCORRETO afirmar:
a) O design de software, ao descrever os diversos aspectos que estaro presentes

no sistema quando construdo, permite que se faa a avaliao prvia para
garantir que ele alcance os objetivos propostos pelos interessados.
b) A representao de um design de software mais simples para representar

apenas as suas caractersticas essenciais busca atender ao princpio da abstrao.
c) Iniciar a entrevista para obteno dos requisitos de software com perguntas

mais genricas e finalizar com perguntas mais especficas sobre o sistema o
71410392104
que caracteriza a tcnica de entrevista estruturada em funil.
d) No contexto de levantamento de requisitos, funcionalidade um dos aspectos

que deve ser levado em conta na abordagem dos requisitos funcionais.
e) A representao a linguagem do design, cujo nico propsito descrever

um sistema de software que seja possvel construir.
10. (FCC AFR/SP - Analista de Sistemas A engenharia de software est

inserida no contexto:

a) das engenharias de sistemas, de processo e de produto.
b) da engenharia de sistemas, apenas.
c) das engenharias de processo e de produto, apenas.
d) das engenharias de sistemas e de processo, apenas.
e) das engenharias de sistemas e de produto, apenas.
11. (CESPE 2015 STJ Analista de Sistemas) Embora os engenheiros de software

geralmente utilizem uma abordagem sistemtica, a abordagem criativa e menos
formal pode ser eficiente em algumas circunstncias, como, por exemplo, para
o desenvolvimento de sistemas web, que requerem uma mistura de habilidades
de software e de projeto.
12. (CESPE 2015 STJ Analista de Sistemas) O foco da engenharia de software

inclui especificao do sistema, desenvolvimento de hardware, elaborao do
projeto de componentes de hardware e software, definio dos processos e
implantao do sistema.
13. (CESPE 2011 MEC Analista de Sistemas) O processo de desenvolvimento de

software uma caracterizao descritiva ou prescritiva de como um produto de
software deve ser desenvolvido.
14. (CESPE 2013 TRT/10 Analista de Sistemas) As atividades fundamentais

relacionadas ao processo de construo de um software incluem a especificao,
o desenvolvimento, a validao e a evoluo do software.
15. (CESPE 2010 TRE/BA Analista de Sistemas) Um modelo de processo de

software consiste em uma representao complexa de um processo de software,
71410392104
16. (CESPE 1 MEC Analista de Sistemas) Atividades comuns a todos os

processos de software incluem a especificao, o projeto, a implementao e a
validao.
17. (CESPE 2015 STJ Analista de Sistemas) As principais atividades de

engenharia de software so especificao, desenvolvimento, validao e
evoluo.


(CESPE TCE/TO Analista de Sistemas - Quanto maior e mais
complexo o projeto de software, mais simples deve ser o modelo de processo a
ser adotado.
(CESPE TCE/TO Analista de Sistemas - O modelo de ciclo de vida

do software serve para delimitar o alvo do software. Nessa viso, no so
consideradas as atividades necessrias e o relacionamento entre elas.
(CESPE TCE/TO Analista de Sistemas - A escolha do modelo do

ciclo de vida no depende de caractersticas especficas do projeto, pois o melhor
modelo sempre o mais usado pela equipe do projeto.
71410392104
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 122 de

144


MODELO EM CASCATA
(FCC - 2012 - - - Analista Judicirio - Anlise de Sistemas - E) Dos diferentes

modelos para o ciclo de vida de desenvolvimento de um software correto
afirmar que o modelo em cascata o mais recente e complexo.
(FCC - - SEFAZ- - Agente Fiscal de Rendas - Tecnologia da Informao

- Prova 3 - O processo de engenharia de software denominado ciclo de vida
clssico refere-se ao modelo incremental.
(CESPE INMETRO Analista de Sistemas) Em uma empresa que tenha

adotado um processo de desenvolvimento de software em cascata, falhas no
levantamento de requisitos tm maior possibilidade de gerar grandes prejuzos
do que naquelas que tenham adotado desenvolvimento evolucionrio.
(CESPE 2011 MEC Analista de Sistemas) O modelo Waterfall tem a vantagem

de facilitar a realizao de mudanas sem a necessidade de retrabalho em fases
j completadas.
(CESPE 2008 TST Analista de Sistemas) No modelo de desenvolvimento

sequencial linear, a fase de codificao a que gera erros de maior custo de
correo.
(CESPE INMETRO Analista de Sistemas) Em um processo de

desenvolvimento em cascata, os testes de software so realizados todos em um
mesmo estgio, que acontece aps a finalizao das fases de implementao.
(CESPE 2008 SERPRO Analista de Sistemas) O modelo em cascata consiste

71410392104
de fases e atividades que devem ser realizadas em sequncia, de forma que uma
atividade requisito da outra.
(CESPE AL/ES Analista de Sistemas - O modelo de desenvolvimento

em cascata descreve ciclos sequenciais, incrementais e iterativos, possuindo,
entre outras, as fases de requisitos e implementao.
(CESPE 2004 STJ Analista de Sistemas) O modelo de desenvolvimento

seqencial linear, tambm chamado modelo clssico ou modelo em cascata,
caracteriza-se por no acomodar adequadamente as incertezas que existem no

144

incio de um projeto de software, em especial as geradas pela dificuldade do
cliente de explicitar todos os requerimentos que o programa deve contemplar.
10. (CESPE IPEA Analista de Sistema) No modelo em cascata de processo

de desenvolvimento, os clientes devem definir os requisitos apenas durante a
fase de projeto; e os projetistas definem as estratgias de projeto apenas durante
a fase de implementao. As fases do ciclo de vida envolvem definio de
requisitos, projeto, implementao, teste, integrao, operao e manuteno.
Em cada fase do ciclo de vida, podem ser produzidos diversos artefatos.
11. (CESPE 2008 TCE/TO Analista de Sistema No ciclo de vida em cascata,

possvel realizar alternadamente e simultaneamente as atividades de
desenvolvimento de software.
12. (CESPE 2004 TJ/PA Analista de Sistema A abordagem sistemtica

estritamente linear para o desenvolvimento de software denominada modelo
em cascata ou modelo sequencial linear.
13. (CESPE 2006 TSE Analista de Sistema O modelo em cascata organiza

o desenvolvimento em fases. Esse modelo encoraja a definio dos requisitos
antes do restante do desenvolvimento do sistema. Aps a especificao e a
anlise dos requisitos, tm-se o projeto, a implementao e o teste.
14. (CESPE INMTRO Analista de Sistema) No desenvolvimento de

software, o modelo em cascata estruturado de tal maneira que as fases que
compem o desenvolvimento so interligadas. Nessa situao, o final de uma
fase implica o incio de outra.
15. (CESPE 2010 SA Analista de Sistema) No modelo em cascata, o projeto

71410392104
segue uma srie de passos ordenados. Ao final de cada projeto, a equipe de

projeto finaliza uma reviso. O desenvolvimento continua e, ao final, o cliente
avalia a soluo proposta.
16. (CESPE TRE/MT Analista de Sistema - O modelo em cascata

apropriado para software em que os requisitos ainda no foram bem
compreendidos, pois focado na criao de incrementos.
17. (CESPE 2009 UNIPAMPA Analista de Sistema O modelo em cascata

sugere uma abordagem sistemtica e sequencial para o desenvolvimento de
software. Sua natureza linear leva a estados de bloqueio nos quais, para que

144

nova etapa seja iniciada, necessrio que a documentao associada fase
anterior tenha sido aprovada.
18. (CESPE 2004 ABIN Analista de Sistema) O modelo de desenvolvimento

seqencial linear, tambm denominado modelo em cascata, incompatvel com
o emprego de tcnica de anlise orientada a objetos no desenvolvimento de um
sistema de informao.
19. (CESPE TRE/AL Analista de Sistema) O modelo cascata ou ciclo de

vida clssico necessita de uma abordagem sistemtica, que envolve, em primeiro
lugar, o projeto e, em seguida, a anlise, a codificao, os testes e a manuteno.
(CESPE MPE/AM Analista de Sistema) O modelo de desenvolvimento

seqencial linear tem como caracterstica principal a produo de uma verso
bsica, mas funcional, do software desde as primeiras fases.
21. (VUNESP - 2012 - SPTrans - Analista de Informtica) Uma das abordagens do

processo de desenvolvimento da engenharia de software prev a diviso em
etapas, em que o fim de uma a entrada para a prxima. Esse processo
conhecido como modelo:
a) Transformao.
b) Incremental.
c) Evolutivo.
d) Espiral.
e) Cascata.
(CESGRANRIO 2010 PETROBRS Analista de Sistemas Processos de

Negcio) No Ciclo de Vida Clssico, tambm chamado de Modelo Sequencial
71410392104
Linear ou Modelo Cascata, apresentada uma abordagem sistemtica composta

pelas seguintes atividades:
a) Anlise de Requisitos de Software, Projeto, Gerao de Cdigo, Teste e

Manuteno.
b) Modelagem e Engenharia do Sistema/Informao, Anlise de Requisitos de

Software, Projeto, Gerao de Cdigo, Teste e Manuteno.
c) Modelagem e Engenharia do Sistema/Informao, Projeto, Gerao de

Cdigo, Teste e Manuteno.

144

d) Levantamento de Requisitos de Software, Projeto, Gerao de Cdigo e

Manuteno e Anlise de Requisitos de Software.
e) Levantamento de Requisitos de Software, Projeto, Gerao de Cdigo, Teste

Progressivo e Manuteno.
71410392104

144


BASEADO EM COMPONENTES OU ORIENTADO A RESO
(CESPE 2010 TRE/BA Tcnico Judicirio Programao de Sistemas) Na

engenharia de software baseada em componentes, na qual se supe que partes
do sistema j existam, o processo de desenvolvimento concentra-se mais na
integrao dessas partes que no seu desenvolvimento a partir do incio. Essa
abordagem baseada em reso para o desenvolvimento de sistemas de
software.
(UFBA - - UFBA - Analista de Tecnologia da Informao No processo de

software baseado em componentes, cada componente projetado para reuso
uma entidade executvel independente, que deve manipular excees.
(CESPE MPE/AM Analista Judicirio Analista de Sistemas) A utilizao

de um modelo de desenvolvimento embasado em componentes uma forma
de desenvolvimento em espiral que busca a reutilizao de trechos de software
desenvolvidos e testados em projetos anteriores e armazenados em um
repositrio.
(CESPE 2004 SERPRO Analista de Sistemas) O grande objetivo do uso de

engenharia de software por componentes a produo de software de alta
qualidade e baixo custo.
(CESPE 2004 SERPRO Analista de Sistemas) Enquanto o reso em

engenharia de software convencional est geralmente limitado extenso e
manuteno de um sistema especfico, o reso, em engenharia de software por
componentes, um requisito de desenvolvimento, independentemente do
71410392104
projeto em considerao.
(CESPE 2004 SERPRO Analista de Sistemas) O uso de componentes pode

estar condicionado a regras de licenciamento. Essa preocupao, no entanto,
no existe se os componentes forem classificados como software livre.
(CESPE 2008 SERPRO Analista de Sistemas) O modelo orientado a reso

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


MTODOS FORMAIS
(CESPE SERPRO Analista de Sistemas) Para a especificao de software

e verificao de sistemas, uma alternativa que se fundamenta na matemtica
discreta e na lgica o modelo incremental.
71410392104

144


(CESPE - 2011 TJ/ES - Analista Judicirio - Anlise de Sistemas - Especficos) 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 Judicirio - Anlise de Sistemas) No modelo de

desenvolvimento incremental, embora haja defasagem entre os perodos de
desenvolvimento de cada incremento, os incrementos so desenvolvidos em
paralelo.
(CESPE - UNIPAMPA - Anlise de Sistemas) No modelo de

desenvolvimento incremental, a cada iterao so realizadas vrias tarefas. Na
fase de anlise, pode ser feito o refinamento de requisitos e o refinamento do
modelo conceitual.
71410392104

144


RAPID APPLICATON DEVELOPMENT (RAD)
(CESPE TST - Analista Judicirio - Anlise de Sistemas) O modelo RAD

(Rapid Application Development) consiste em uma forma de prototipao para
esclarecer dvidas da especificao do software.
(CESPE 2004 BASA Analista de Sistemas) O modelo embasado em

prototipagem um modelo de processo incremental que enfatiza um ciclo de
desenvolvimento extremamente curto. A primeira fase do processo a
modelagem de negcio e a ltima a fase de teste e entrega.
(CESPE MPE/AM Analista Judicirio Analista de Sistemas) O modelo

RAD (rapid application development) especfico para projetos de software que
empregam linguagens de programao de terceira gerao.
(CESPE 2011 AL/ES Analista de Sistemas O ciclo de vida RAD (Rapid

Application Development), por privilegiar a rapidez do desenvolvimento, no
possui etapa de modelagem.
(CESPE IGEPREV Analista de Sistemas O modelo Rapid Application

Development (RAD) apropriado para projetos que envolvem grandes riscos
tcnicos.
(CESPE IPEA Analista de Sistemas) O RAD (Rapid Application

Development) um modelo de processo de software incremental que assume
um ciclo de desenvolvimento curto e utiliza uma abordagem de construo com
71410392104
base em componentes.
(CESPE TRE/MA Analista de Sistemas O modelo RAD (Rapid

Application Development) uma adaptao de alta velocidade do modelo
sequencial linear, conseguido por meio da construo embasada em
componentes.
(CESPE TRE/MA Analista de Sistemas O uso de uma abordagem

de construo embasada em componentes faz que o desenvolvimento no
modelo RAD (Rapid Application Development) seja considerado mais rpido.

(CESPE 2013 TRT/17 Analista de Sistemas) O objetivo do RAD separar os
modelos da visualizao e do controle. Ele fornece o controlador e facilita a
escrita de moldes padronizados para a camada de visualizao.
10. (CESPE MPE/AM Analista de Sistemas) O modelo de desenvolvimento

incremental combina caractersticas do modelo de desenvolvimento sequencial
linear com caractersticas do modelo RAD, embora isso resulte em projetos que
sistematicamente apresentam maior durao que aqueles feitos com os dois
modelos de desenvolvimento originais.
11. (CESPE ANS Analista Administrativo Processamento de Dados) O

modelo Rapid Application Development (RAD) uma adaptao do modelo em
espiral para atender a projetos de software fundamentados em componentes.
71410392104


(FGV 2008 Senado Federal Analista de Sistemas) No modelo evolucionrio,

a mudana constante tende a corromper a estrutura do software.
(CESPE TJ/DF Analista de Sistemas) A prototipao evolucionria no

gera problemas de manuteno de sistema porque o desenvolvimento rpido
e no sofre grandes mudanas.
71410392104

LISTA DE EXERCCIOS COMENTADOS

MODELO EM PROTOTIPAGEM

desenvolvimento prototipagem, um prottipo desenvolvido para ajudar no
(CESPE 2010 E/MT Analista de Sistemas - C) A metodologia de

prototipagem evolutiva uma abordagem que visualiza o desenvolvimento de
concepes do sistema conforme o andamento do projeto, por meio de
prottipos visuais.
(CESPE 2004 TRE/AL Analista de Sistemas) No modelo de prototipao, o

desenvolvedor cria inicialmente um modelo de software que ser posteriormente
implementado.
(CESPE 2007 TSE Analista de Sistemas) Um possvel objetivo da

prototipao criar rapidamente um sistema experimental que possa ser
avaliado por usurios finais. Um prottipo aprovado pelos usurios pode vir a
ser usado como ponto de partida para a construo do sistema.
(CESPE MPE/AM Analista de Sistemas) No modelo de prototipao,

a especificao de requisitos tem pouca importncia, pois o software
continuamente adaptado em funo dos desejos do usurio.
(CESPE TJ/DF Analista de Sistemas) Uma vantagem da prototipao

promover a participao e o comprometimento do usurio em relao ao
sistema em desenvolvimento. 71410392104
(CESPE TJ/DF Analista de Sistemas) A prototipao de um software

uma tcnica de desenvolvimento no-interativa porque o teste do sistema s
ocorre na verso final.
(CESPE TJ/DF Analista de Sistemas) Uma das finalidades da

prototipao reduzir o esforo de desenvolvimento de um software.
(CESPE 2010 INMETRO Analista de Sistemas A) Um dos benefcios da

prototipao a documentao normalmente gerada, que facilita a manuteno
dos sistemas a longo prazo e a elaborao de casos de teste.

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

prototipao o usurio confundir o prottipo com o sistema verdadeiro e criar
falsas expectativas com relao a prazos e recursos.
11. (CESPE 2010 INMETRO Analista de Sistemas E) Na abordagem evolutiva

para desenvolvimento de software, um prottipo do software produzido e
utilizado para identificar possveis problemas com os requisitos, sendo
descartado logo em seguida, e o desenvolvimento do software propriamente
dito , ento, iniciado.
12. (CESPE 1 Analista de Sistemas) No modelo de prototipao, o

13. (CESPE 2013 TRT/10 Analista Judicirio Tecnologia da Informao) No

modelo prototipao, a construo de software tem vrias atividades que so
executadas de forma sistemtica e sequencial.
14. (VUNESP - 2009 - CETESB - Analista de Tecnologia da Informao - Banco de

Dados) Considere um sistema cujos requisitos de interface so definidos apenas
quando o cliente realiza um test-drive na aplicao 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) Prototipao. 71410392104
e) Rapid Application Development.
15. (CESPE TCE/RN Assessor Tcnico de Informtica) A prototipao, uma

abordagem para desenvolvimento de software na qual se cria um modelo do
software que ser implementado, composta de quatro etapas: planejamento,
anlise de risco, engenharia e avaliao do cliente.
16. (CESPE DETRAN/DF Analista de Sistemas) O modelo de processo de

desenvolvimento de software evolucionrio parte do desenvolvimento de uma
implementao inicial cujos resultados so apresentados aos clientes e refinados
por meio de vrias verses at que se alcance o sistema adequado. A

prototipao, como processo, tem por objetivo compreender as especificaes
do software para se chegar aos requisitos para o sistema.
17. (CESPE TJ/DF Analista de Sistemas) A prototipao evolucionria

permite que a verso inicial do prottipo seja desenvolvida e refinada em
estgios sequenciados, at que se chegue verso final do sistema.
18. (CESPE 2011 MEC Anlise de Sistemas) No modelo de prototipao, o

71410392104


MODELO EM ESPIRAL
(FCC - 2012 - TST - Analista Judicirio - Anlise de Sistemas) O Ciclo de Vida de

um Sistema especifica todas as fases de desenvolvimento, desde sua concepo
at o processo de manuteno e declnio. No que diz respeito ao
desenvolvimento de software, existem alguns processos conhecidos. Um destes
processos, possui caracterstica iterativa e incremental, inicia cada fase do projeto
realizando um planejamento prvio, realiza a execuo da fase, verifica o
progresso e os resultados da fase (riscos, lies aprendidas) e incrementa novos
objetivos para a fase seguinte, seguindo para a prxima iterao. O processo de
software em questo o:
a) Modelo espiral.
b) Ciclo de vida em cascata.
c) Modelo de desenvolvimento evolucionrio (prototipao).
d) Modelo de desenvolvimento gil.
e) Mtodo de desenvolvimento Cleanroom (Sala Limpa).
(FCC - 2010 - TRT - 20 REGIO (SE) - Analista Judicirio - Tecnologia da

Informao - medida que se avana pelo modelo ocorre uma iterao e o
software evolui para estgios superiores, normalmente com aumento da
complexidade. Cada iterao est provida das atividades determinadas pelos
quadrantes planejamento, avaliao de alternativas e riscos, desenvolvimento do
software e avaliao do cliente. No ciclo de vida de desenvolvimento de software,
trata-se da propriedade do modelo:
a) Cascata. 71410392104
b) Incremental.
c) Espiral.
d) Prototipao.
e) Balbrdia.
(FCC - 0 MPE/RN Analista de Sistemas) O modelo em espiral difere

principalmente dos outros modelos de processo de software por:
a) no contemplar o prottipo.
b) reconhecer explicitamente o risco.
c) no ter fases.

d) possuir uma fase nica evolucionria.
e) no 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. NO se trata da
denominao de um destes setores:
a) levantamento.
b) definio de objetivos.
c) avaliao e reduo de riscos
d) desenvolvimento e validao.
e) planejamento.
(FCC 2010 BAHIAGS 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 deciso.
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 Judicirio Tecnologia da Informao) O

modelo em espiral um modelo de processos de software que rene a natureza
iterativa da prototipao com os aspectos sistemticos e controlados do modelo
71410392104
sequencial linear.
(CESPE 2004 COHAB Analista Judicirio Tecnologia da Informao) O

modelo espiral um modelo de processo de software que combina a natureza
iterativa da prototipagem com os aspectos controlados e sistemticos do modelo
sequencial linear.
(CESPE - TJ/DF - Analista Judicirio - Tecnologia da Informao)

Empregando o modelo de desenvolvimento em espiral, o software
desenvolvido em uma srie de verses intermedirias incrementais.

em espiral de ciclo de vida de software iterativo e incremental, uma vez que a
mesma sequncia de atividades relacionadas produo de software realizada
a cada ciclo da espiral.

de desenvolvimento em espiral permite repensar o planejamento diversas vezes
durante o desenrolar do projeto.
12. (CESPE - - ANTAQ - Analista Administrativo - Informtica) 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
ausncia de risco nesse modelo o diferencia dos demais modelos de software.
13. (CESPE IPEA Analista de Sistemas) O modelo espiral um modelo

evolucionrio de processo de software que combina a prototipagem com o
modelo em cascata. Contudo, a incerteza em relao ao nmero de ciclos
necessrios para construir o projeto, leva tal abordagem a empregar o modelo
de mtodos formais para viabiliz-lo.
14. (CESPE UNIPAMPA Analista de Sistemas) O modelo espiral admite

retorno s fases anteriores de desenvolvimento, suportando ainda a execuo
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.
16. (CESPE 2004 BASA Analista de Sistemas) O modelo em espiral evolui

71410392104
medida que o processo avana, permitindo ao desenvolvedor e ao cliente

entenderem melhor os riscos e reagirem em cada nvel evolucionrio.
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 dcada de 70 do sculo passado.
Tal modelo considera as seguintes fases: anlise de requisitos, definio, projeto,
implementao, integrao e testes, operao e manuteno.

18. (CESPE 2004 PBV/RR Analista de Sistemas) O modelo em espiral de
desenvolvimento proposto por Boehm apresenta a anlise de riscos como uma
das suas fases essenciais.
19. (CESPE 2004 STJ Analista de Sistemas) O modelo de desenvolvimento em

espiral requer a considerao dos riscos tcnicos em todos os estgios ou
interaes 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
prototipao, acrescentando a anlise de risco, inexistente nestes dois modelos.
21. (CESPE CENSIPAM Analista de Sistemas) O modelo espiral iterativo

e incremental, assim como so os modelos de processo unificado, de
prototipao, de desenvolvimento rpido de aplicaes e em cascata.
(CESPE SERPRO Analista de Sistemas) O modelo iterativo e o modelo

em espiral possuem caractersticas 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 prticas da
engenharia clssica empregadas, por exemplo, na construo de casas, quando
comparado aos modelos cascata e de componentes reusveis.
24. (CESPE INMETRO Analista de Sistemas) Uma das caractersticas

marcantes do modelo de desenvolvimento em espiral o fato de ele ser cclico,
e no linear, como o modelo de desenvolvimento em cascata.
71410392104
(CESPE UNIPAMPA Analista de Sistemas) O modelo de

desenvolvimento espiral foi desenvolvido somente para abranger as melhores
caractersticas do ciclo de vida clssico.

desenvolvimento em espiral, a anlise de riscos no impacta na elaborao de
um produto ou prottipo.
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 no so considerados, pois
podem impactar o projeto.
(CESPE 2010 TRE/MT Analista de Sistemas E) O modelo de

desenvolvimento em espiral, que tem a codificao como segunda etapa, gera
o cdigo do sistema muito mais rapidamente que o modelo de prototipao.
(CESPE - 2013 - STF - Tcnico Judicirio - Tecnologia da Informao) O processo

de software fundamentado no modelo em espiral apresenta o processo em
loops compostos basicamente por setores, como, por exemplo, definio de
objetivos, avaliao de riscos, planejamento e desenvolvimento e avaliao.
(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 Judicirio - Tecnologia da Informao) No ciclo

de vida em espiral, a de anlise de risco realizada na etapa da modelagem do
produto.
(CESPE 2004 PBV/RR Analista de Sistema) O modelo em cascata linear e

seqencial. 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 so:

feita pelo cliente. 71410392104

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

seguir corresponde ao modelo de processo, proposto no final da dcada de 80,
que tem como principais caractersticas ser evolucionrio, iterativo e focado na
reduo dos riscos?

a) Modelo em Espiral.
b) Modelo em Cascata.
c) Modelo em V.
d) Modelo Transformacional.
e) Modelo de Especificao Operacional.
(ESAF - 2010 MPOG Analista de Sistemas) As atividades do modelo espiral de

Engenharia de Software so:

feita pelo cliente.

feita pelo cliente.
71410392104

Tecnologia da Informao para TCU/ 2017 (Parte II)
GABARITO DOS EXERCCIOS COMENTADOS (DIVERSAS BANCAS)

CONCEITOS BSICOS DE ENGENHARIA DE SOFTWARE
1 2 3 4 5 6 7 8 9 10
C C A E E B C D E A
11 12 13 14 15 16 17 18 19 20
C E C C E C C

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

MODELO EM CASCATA
1 2 3 4 5 6 7 8 9 10
E E C E E E C E C E
11 12 13 14 15 16 17 18 19 20
C C C C E E C E E E
21 22 23 24 25 26 27 28 29 30
E B
71410392104

BASEADO EM COMPONENTES OU ORIENTADO A RESO
1 2 3 4 5 6 7 8 9 10
C E C C C E C


MTODOS FORMAIS
1 2 3 4 5 6 7 8 9 10
E

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

RAPID APPLICATION DEVELOPMENT (RAD)
1 2 3 4 5 6 7 8 9 10
E E E E E C C C E E
11 12 13 14 15 16 17 18 19 20
E

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

MODELO EM PROTOTIPAGEM
1 2 3 4 5 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 - -

MODELO EM ESPIRAL
1 2 3 4 5 6 7 8 9 10
A C B E B C C C C E
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
71410392104

Aula 01 - Engenharia de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula 01 - Engenharia de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Tecnologia da Informao (parte II) p/ Auditor de TI do TCU

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 1 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

DVIDAS DOS ALUNOS

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 2 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

Uma breve apresentao: meu nome Diego Carvalho, bacharel em Cincia da

REA RGOS PARA OS QUAIS J MINISTREI CURSOS

Agncia ANCINE ANTAQ ANATEL

Jurdica TRT/1 TRT/2 TRT/3 TRT/4

Outros CEF DATAPREV DEPEN INMETRO

Galera, l no site, ns professores temos algumas mtricas para medir se o nosso

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 3 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 4 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 5 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 6 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

CONCURSO DO TRIBUNAL DE CONTAS DA UNIO (TCU) - 2017

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 7 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

Antes de comear o curso, vamos alinhar algumas expectativas! O curso que eu

Portanto, vou direcion-los pelo contedo da melhor maneira possvel. O nosso

6 Lugar ISS/Salvador 71410392104

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 8 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

Aula Data Tpicos do Edital

01 25/02 5 Engenharia de software. 5.1 Ciclo de vida do software. 5.2

02 15/03 5.3 Mtricas e estimativas de software: Anlise por pontos de funo.

03 05/04 6 Engenharia de requisitos: conceitos bsicos, tcnicas de elicitao e

04 25/04 7 Metodologias geis: Scrum, XP, Kanban, TDD, BDD e DDD.

05 15/05 8 Testes de software (Unidade, Integrao, Sistema, Aceitao,

06 05/06 1.5 Linguagens de programao Java.

07 25/06 1.7 Frontend Web: HTML5, CSS3,

08 15/07 JavaScript, 1.9 Noes e conceitos de desenvolvimento para

10 25/08 2 Arquitetura de software. Padres de Projeto.

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 9 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

12 30/09 1.6 Ferramentas de desenvolvimento e versionamento de cdigo-fonte

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 10 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 11 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 12 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

ENGENHARIA DE SOFTWARE: CONCEITOS GERAIS

A IEEE define engenharia de software como a aplicao de uma abordagem

Em suma, uma disciplina de engenharia que se ocupa de todos os aspectos da

Sommerville define processo de software como a abordagem sistemtica usada pela

engenharia de software para produo de software. Pode-se identificar as seguintes

De acordo com Pressman: A Engenharia de Software ocorre como consequncia de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 13 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri

A Engenharia de Software tem por objetivos a aplicao de teoria, modelos,

Isto envolve planejamento de custos e prazos, montagem da equipe e garantia de

Alis, nosso outro renomadssimo autor (Sommerville) afirma que: A engenharia de

de software, mas tambm com atividades como o gerenciamento de projeto de

A Engenharia de Software surgiu em meados da dcada de sessenta como uma

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 14 de 144

71410392104 - Paulo Rafael Oliveira Ribeiro Bombardieri