Curso 11143 Aula 00 v1

Aula 00
Tecnologia da Informao (parte II) p/ ABIN OTI - Cargo 9 - Desenvolvimento e

Manuteno de Sistemas
Professor: Diego Carvalho
00000000000 - DEMO
Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

Curso de Teoria e Exerccios ABIN/2016
Prof. Diego Carvalho Aula 00
AULA 00
SUMRIO
PGINA
01
14
29
31
34
53
61
65
68
73
78
92
Apresentao
- Engenharia de Software: Conceitos Gerais
- Ciclo de Vida de Software
- Processos de Desenvolvimento de Software
- Modelo em Cascata
- Modelo Baseado em Componentes
- Modelo Orientado a Aspectos
- Mtodos Formais
- Modelos Iterativos e Incrementais
- Modelos Evolucionrios
Lista de Exerccios Comentados
Gabarito
E a, querem mais teoria? Mais exerccios? Tem muito mais! Essa apenas a aula demonstrativa para
que vocs conheam o mtodo e a escrita! Espero que vocs venham comigo... grande abrao ;)
00000000000
Prof. Diego Carvalho
www.estrategiaconcursos.com.br
00000000000 - DEMO
Pg. 1 de 93

VIII QUALIDADE DE SOFTWARE: Metodologias de desenvolvimento de software; processo

unificado: conceitos, diretrizes, disciplinas; metodologias geis; prticas geis: Integrao
contnua, Test-driven Development (TDD), Refactoring; Framework. mtricas e estimativas de
software; anlise por pontos de funo. IX ANLISE E PROJETO ORIENTADOS A OBJETOS:
Conceitos bsicos, padres de projetos; UML: Viso geral, modelos e diagramas. VI
ENGENHARIA DE REQUISITOS: Conceitos bsicos; tcnicas de elicitao de requisitos;
gerenciamento de requisitos; especificao de requisitos; tcnicas de validao de
requisitos; prototipao. VII ENGENHARIA DE USABILIDADE: Conceitos bsicos e aplicaes;
critrios, recomendaes e guias de estilo; anlise de requisitos de usabilidade; mtodos
para avaliao de usabilidade. II LGICA DE PROGRAMAO: Construo de algoritmos; tipos
de dados simples e estruturados; variveis e constantes; comandos de atribuio, entrada e
sada; avaliao de expresses; funes pr-definidas; conceito de bloco de comandos;
estruturas de controle, seleo, repetio e desvio; operadores e expresses; passagem de
parmetros; recursividade; conceitos bsicos de programao estruturada e orientada a
objetos; mtodos de ordenao, pesquisa e hashing. X PROGRAMAO ORIENTADA A
OBJETOS: Conceitos bsicos: classes, objetos, mtodos, mensagens, sobrecarga, herana,
polimorfismo, interfaces e pacotes; tratamento de exceo. XI LINGUAGENS E TECNOLOGIAS
DE PROGRAMAO: Linguagens de programao, HTML; CSS; PHP; Javascript; AJAX; DHTML;
XML, XSD e XSLT. Arquitetura: Service Oriented Architecture (SOA); SOAP; Design Patterns;
padro Model-View- Controller (MVC); TESTES: Teste funcional, de performance e de
integrao; plano de testes; ferramentas e automatizao de testes.
00000000000
00000000000 - DEMO
Pg. 2 de 93

APRESENTAO
Ol, pessoal. Sejam bem-vindos! Vocs j devem ter visto que ser um ano muito
difcil para os concurseiros. Ento, cada concurso atualmente tem que ser levado
muito a srio. O ltimo concurso foi h cinco anos e o salrio excepcional. Quem
quiser se tornar um Oficial de Inteligncia, este o momento! Recomendo
fortemente estudar com antecedncia, porque esse um concurso bem difcil.
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).
00000000000
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.
00000000000 - DEMO
Pg. 3 de 93

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/2
CNMP
TRT/3
MP/PB
TRT/4
TRT/15
TCE/SP
TCM/SP
ISS/BA
TCE/CE
TCM/GO
Fiscal
TRT/1
TJ/BA
CMARA DOS
DEPUTADOS
TCE/RS
TCU
ISS/SP
Outros
CEF
DATAPREV
DEPEN
INMETRO
Legislativa
Auditoria
Galera, l no site, ns professores temos algumas mtricas para medir se o nosso

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!
00000000000
00000000000 - DEMO
Pg. 4 de 93

00000000000
00000000000 - DEMO
Pg. 5 de 93

00000000000
00000000000 - DEMO
Pg. 6 de 93

00000000000
00000000000 - DEMO
Pg. 7 de 93

O CONCURSO
ABIN OFICIAL TCNICO DE INTELIGNCIA

ESPECIALIDADE: DESENVOLVIMENTO E MANUTENO DE SISTEMAS
00000000000
REMUNERAO
VAGAS
CERCA DE R$15.376,00
EDITAL/AUTORIZAO:
NO DISPONVEL
00000000000 - DEMO
Pg. 8 de 93

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 vis 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
https://www.youtube.com/watch?v=b1w4H3l6mC4#t=1678
00000000000
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-lugarno-concurso-dataprev-para-o-cargo-de-analistaarea-de-tecnologia-da-informacao/
00000000000 - DEMO
Pg. 9 de 93

CRONOGRAM
Aula
00
Data
05/02
Tpicos do Edital
01
12/01
VIII QUALIDADE DE SOFTWARE: Metodologias de desenvolvimento de

software;
02
19/02
processo unificado: conceitos, diretrizes, disciplinas;
03
26/02
metodologias geis; prticas geis: Integrao contnua, Test-driven

Development (TDD), Refactoring; Framework.
04
01/03
mtricas e estimativas de software; anlise por pontos de funo.
05
08/03
IX ANLISE E PROJETO ORIENTADOS A OBJETOS: Conceitos bsicos,

padres de projetos;
06
15/03
UML: Viso geral, modelos e diagramas.
07
22/03
VI ENGENHARIA DE REQUISITOS: Conceitos bsicos; tcnicas de

elicitao de requisitos; gerenciamento de requisitos; especificao
de requisitos; tcnicas de validao de requisitos; prototipao.
Aula Demonstrativa
00000000000
08
01/04
VII ENGENHARIA DE USABILIDADE: Conceitos bsicos e aplicaes;

critrios, recomendaes e guias de estilo; anlise de requisitos de
usabilidade; mtodos para avaliao de usabilidade.
09
08/04
II LGICA DE PROGRAMAO: Construo de algoritmos; tipos de dados

simples e estruturados; variveis e constantes; comandos de
atribuio, entrada e sada; avaliao de expresses; funes prdefinidas; conceito de bloco de comandos; estruturas de controle,
seleo, repetio e desvio; operadores e expresses; passagem de
00000000000 - DEMO
Pg. 10 de 93

parmetros; recursividade; conceitos bsicos de programao

estruturada e orientada a objetos; mtodos de ordenao, pesquisa e
hashing.
10
15/04
X PROGRAMAO ORIENTADA A OBJETOS: Conceitos bsicos: classes,

objetos, mtodos, mensagens, sobrecarga, herana, polimorfismo,
interfaces e pacotes; tratamento de exceo.
11
22/04
XI LINGUAGENS E TECNOLOGIAS DE PROGRAMAO: Linguagens de

programao, HTML; CSS;
12
01/05
PHP; Javascript; AJAX; DHTML; XML, XSD e XSLT.
13
08/05
Arquitetura: Service Oriented Architecture (SOA); SOAP; Design

Patterns; padro Model-View- Controller (MVC);
14
15/05
TESTES: Teste funcional, de performance e de integrao; plano de

testes; ferramentas e automatizao de testes.
00000000000
00000000000 - DEMO
Pg. 11 de 93

AS AULAS E AS DICAS
1 Pargrafos pequenos: observem que os pargrafos
tm, no mximo, cinco linhas. Isso serve para que a
leitura no fique cansativa e para que vocs no
desanimem no meio do material! Para tal, eu tento dividir
as disciplinas de maneira que as aulas fiquem objetivas e
pequenas (em termos de teoria), mas extensa (em
termos de exerccios).
3 Destaques em vermelho: quase todos os
pargrafos possuem alguma palavra ou frase destacada
em negrito e em vermelho. Isso ocorre por suas razes:
primeiro, para enfatizar alguma informao importante;
segundo, para facilitar a leitura vertical, i.e., aps uma
primeira leitura, a segunda pode ser passando apenas
pelos pontos em destaque.
5 Linguagem natural: essa uma aula para ser lida, o
que por si s j pode ser cansativo. Tentarei colocar a
linguagem mais coloquial possvel, simulando uma
conversa. Portanto, caso virem frases ou palavras em
itlico, ou uma palavra estrangeira ou a simulao de
uma conversa com vocs. Pode dar um exemplo,
professor? Acabei de dar! :-)
7 Diversas figuras: essas aulas estaro em constante
evoluo, sempre procura de explicar as matrias de
maneira mais compreensvel e com novas
informaes/questes. Para tal, na minha opinio,
fundamental a utilizao de figuras, grficos, painis, etc.
Em minha experincia, bem mais fcil memorizar a
partir de imagens.
9 Fazer Exerccios: muitos exerccios o meio pelo
qual vocs se situaro. Como assim, professor? na hora
de fazer os exerccios que vocs descobriro se esto
bem ou mal e avaliaro se precisam estudar mais ou
menos. Para tal, h um quadrinho ao final de cada bloco
de exerccios para vocs anotarem a quantidade de
questes respondidas corretamente ou incorretamente.
00000000000
2 Viso Geral: no se atenham a detalhes antes de

entender o bsico. Por que? Ora, no h nada mais
irritante do que ir para uma prova que vai cair, por
exemplo, RUP, saber vrios detalhes, mas no saber as
fases e disciplinas. Portanto, caso estejam iniciando os
estudos sobre uma matria, foquem em saber o bsico
para depois se especializarem.
4 Faam muitos exerccios: ler vrias bibliografias
muito trabalhoso e, geralmente, no vale o custobenefcio. Acredito que o que funciona mesmo entender
o bsico, depois fazer muitos exerccios e,
eventualmente, caso encontrarem algo que no
souberem, pesquisem-no separadamente. Alm disso,
voc vai pegando as manhas da banca.
6 Faam resumos: essa dica somente serve caso
vocs tenham disponibilidade. Caso haja pouco tempo
para estudar ou pouco tempo at a prova, no compensa!
Se no, faam resumos organizados, pois eles
economizaro um bom tempo de estudo em suas
prximas provas e sempre que descobrirem novas
informaes, insiram-nas no resumo.
8 Revisem antes da prova: no adianta querer
estudar coisas novas at o ltimo minuto antes da prova
e no revisar o que estudou h um ms. Vocs iro
esquecer e iro se irritar na hora da prova por no
lembrarem de conceitos simples. Tirem uma semana
para revisar seus resumos, decorarem algumas coisas
e, certamente, iro mais confiantes para a prova.
10 Simulado Final: ora, fazer um bloco de questes
depois de estudar a teoria tranquilo. No entanto,
lembrem-se que a memria de vocs no infinita e
vocs tm um milho de outras coisas para estudar e
decorar. Portanto, se possvel, ao fim do curso faremos
um simulado com questes escolhidas que foram
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 ;-)
00000000000 - DEMO
Pg. 12 de 93

R$15.376,00
R$15.376,00
R$15.376,00
R$15.376,00
R$15.376,00
00000000000
00000000000 - DEMO
Pg. 13 de 93

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 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.
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
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?
00000000000
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.
00000000000 - DEMO
Pg. 14 de 93

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
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.
00000000000
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.
00000000000 - DEMO
Pg. 15 de 93

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 Decomposi , 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.
00000000000
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
00000000000 - DEMO
Pg. 16 de 93

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
00000000000
00000000000 - DEMO
Pg. 17 de 93

(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
custos adequados.
00000000000
Comentrios:
00000000000 - DEMO
Pg. 18 de 93

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.
00000000000
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:
00000000000 - DEMO
Pg. 19 de 93


(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
objetivo fornecer uma estrutura metodolgica para a construo de software
com alta qualidade. A definio refere-se:
00000000000
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:
00000000000 - DEMO
Pg. 20 de 93

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.
e) comunicao, planejamento, modelagem, construo e implantao.
00000000000
Comentrios:
00000000000 - DEMO
Pg. 21 de 93

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 Decomposio, 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
00000000000
(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.
00000000000 - DEMO
Pg. 22 de 93

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!
(b) Na verdade, Engenharia de Software uma disciplina da Cincia da Computao.
00000000000
(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.
00000000000 - DEMO
Pg. 23 de 93


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.
00000000000
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
00000000000 - DEMO
Pg. 24 de 93

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
00000000000
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:
00000000000 - DEMO
Pg. 25 de 93

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.
barito: 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 aspect
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.
00000000000
Comentrios:
Conforme vimos em aula, a questo est perfeita!
00000000000 - DEMO
Pg. 26 de 93

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
00000000000
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:
00000000000 - DEMO
Pg. 27 de 93

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
00000000000
00000000000 - DEMO
Pg. 28 de 93

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.
00000000000
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
00000000000 - DEMO
Pg. 29 de 93

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,
utilizao e manuteno do software. Por fim, na Retirada, aposenta-se o software
de vez! isso... simples, no?! ;)
00000000000
00000000000 - DEMO
Pg. 30 de 93

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

De acordo com Sommerville, o termo Ciclo de Vida de Desenvolvimento de
Softwa 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.
00000000000
00000000000 - DEMO
Pg. 31 de 93

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:
MODELO
CASCATA
INCREMENTAL
EVOLUTIVO
RAD
PROTOTIPAGEM
ESPIRAL
RUP
FOCO
REQUISITOS
Documentos e
Bem conhecidos e estticos
artefatos
Incrementos
Mais abstratos; tratados em
operacionais
mdulos
Evoluo dos
Pouco conhecidos
requisitos
Rapidez de
Escopo restrito; mais
desenvolvimento abstratos; tratado em mdulos
Dvidas nos
Mais abstratos
requisitos
Anlise
Mais abstratos; evoludos com o
de Risco
tempo
Frameworks e Mais abstratos; evoludos com o
boas prticas
tempo
1 VERSO P/ CLIENTE
GERENCIAM
ENTO
Fim do ciclo
Prottipos operacionais
Prottipos no
operacionais
ou no operacionais
ou no operacionais
5
5
5
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
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.
00000000000
00000000000 - DEMO
Pg. 32 de 93

(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.
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.
00000000000
Comentrios:
No faz o menor sentido! A escolha depende das caractersticas do projeto.
Gabarito: E
ACERTEI
ERREI
00000000000 - DEMO
Pg. 33 de 93

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
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!
00000000000
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?
00000000000 - DEMO
Pg. 34 de 93

Por
Sommerville
Definio de Requisitos
Projeto de Sistema e
Software
Implementao e Teste
de Unidade
Integrao e Teste de
Sistema
Operao e Manuteno
Por
Yourdon
Requisitos de
Sistema
Requisitos de
Software
Anlise
Por Pressman
(4 Ed.)
Modelagem e Engenharia
do Sistema/Informao
Anlise de Requisitos de
Software
Projeto
Por Pressman
(6 Ed.)
Comunicao
Planejamento
Por
Royce
Elicitao de
Requisitos
Projeto
Modelagem
Construo
Projeto
Gerao de Cdigo
Construo
Integrao
Codificao
Teste e Manuteno
Implantao
Teste de
Depurao
Instalao
00000000000
Teste
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
00000000000 - DEMO
Pg. 35 de 93

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.
Implementao: 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.
00000000000
00000000000 - DEMO
Pg. 36 de 93

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.
00000000000
00000000000 - DEMO
Pg. 37 de 93

o erro ocorreu no incio e foi

Portanto no confundam essas duas coisas:
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
entenderam?
00000000000
VANTAGENS
DESVANTAGENS
simples de entender e fcil de aplicar,

facilitando o planejamento.
Fixa pontos especficos para a entrega de
artefatos.
Diviso inflexvel do projeto em estgios

distintos.
Dificuldade em incorporar mudanas de
requisitos.
00000000000 - DEMO
Pg. 38 de 93

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
fase ou estgio.
Possibilita boa aderncia a outros modelos
de processo.
Funciona bem com projetos pequenos e
com requisitos bem conhecidos.
Apenas a fase final produz um artefato de

software entregvel.
Cliente deve saber todos os requisitos no
incio do projeto.
Modelo inicial (Royce) no permitia
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
00000000000
00000000000 - DEMO
Pg. 39 de 93

(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
(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.
Comentrios:
00000000000

No, modelo clssico se refere a modelo em cascata, sequencial, linear, tradicional,
waterfall, rgido ou monoltico.
Gabarito: E
00000000000 - DEMO
Pg. 40 de 93

(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:
VANTAGENS
DESVANTAGENS

artefatos.
Funciona bem para equipes tecnicamente
fracas.
fcil de gerenciar, devido a sua rigidez.

distintos.
requisitos.
Clientes s visualizam resultados prximos
Atrasa a reduo de riscos.

fase ou estgio.
de processo.

software entregvel.
incio do projeto.
No fornece feedback entre as fases.
00000000000

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.
00000000000 - DEMO
Pg. 41 de 93

Comentrios:
VANTAGENS
DESVANTAGENS

artefatos.
fracas.

distintos.
requisitos.

fase ou estgio.
de processo.

software entregvel.
incio do projeto.
Pelo contrrio, h dificuldade de lidar com requisitos volteis, tendo em vista que
dependendo do erro, necessrio refaz-lo desde seu incio.
00000000000
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:
00000000000 - DEMO
Pg. 42 de 93

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:
Por
Sommerville
Por
Yourdon
Por Pressman
(4 Ed.)
Por Pressman
(6 Ed.)
Por
Royce
Requisitos de
Sistema
Requisitos de
Software
Anlise
Modelagem e Engenharia do
Sistema/Informao
Software
Projeto
Comunicao
Planejamento
Elicitao de
Requisitos
Projeto
Modelagem
Construo
Projeto
Gerao de Cdigo
Construo
Integrao
Codificao
Teste e Manuteno
Implantao
Teste de
Depurao
Instalao
Software
Implementao e Teste de
Unidade
Integrao e Teste de
Sistema
Operao e Manuteno
00000000000
Teste
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.
00000000000 - DEMO
Pg. 43 de 93

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.
00000000000
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:
00000000000 - DEMO
Pg. 44 de 93

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
IPEA Analista de Sistema) No modelo em cascata de processo
10. (CESPE
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.
00000000000
Comentrios:
No, sequencial e linear. No pode ser alternado e simultneo!
Gabarito: E
00000000000 - DEMO
Pg. 45 de 93

A abordagem sistemtica
12. (CESPE 2004 TJ/PA Analista de Sistema
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:
Por
Sommerville
Por
Yourdon
Por Pressman
(4 Ed.)
Por Pressman
(6 Ed.)
Por
Royce
Requisitos de
Sistema
Requisitos de
Software
Anlise
Sistema/Informao
Software
Projeto
Comunicao
Planejamento
Elicitao de
Requisitos
Projeto
Modelagem
Construo
Projeto
Gerao de Cdigo
Construo
Integrao
Codificao
Teste e Manuteno
Implantao
Teste de
Depurao
Instalao
Software
Unidade
Integrao e Teste de
Sistema
Operao e Manuteno
00000000000
Teste
Operao
Manuteno de
Software
Perfeito! De fato, segue essa ordem!
00000000000 - DEMO
Pg. 46 de 93

Gabarito: C
INMTRO Analista de Sistema) No desenvolvimento de
14. (CESPE
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
com os resultados alcanados. Vocs conseguem perceber como essas restries
engessam o desenvolvimento?
00000000000
Ao final de cada projeto? No! Ao final de cada fase.

Gabarito: E
TRE/MT Analista de Sistema O modelo em cascata
16. (CESPE
apropriado para software em que os requisitos ainda no foram bem
compreendidos, pois focado na criao de incrementos.
00000000000 - DEMO
Pg. 47 de 93

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
obabilidade 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.
00000000000
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:
00000000000 - DEMO
Pg. 48 de 93

VANTAGENS
DESVANTAGENS

artefatos.
fracas.

distintos.
requisitos.

fase ou estgio.
de processo.

software entregvel.
incio do projeto.
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!
00000000000
Gabarito: E
19.
ESPE 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:
Por
Sommerville
Por
Yourdon
Por Pressman
(4 Ed.)
Por Pressman
(6 Ed.)
00000000000 - DEMO
Por
Royce
Pg. 49 de 93

Software
Unidade
Integrao e Teste de
Sistema
Operao e Manuteno
Requisitos de
Sistema
Requisitos de
Software
Anlise
Sistema/Informao
Software
Projeto
Comunicao
Planejamento
Elicitao de
Requisitos
Projeto
Modelagem
Construo
Projeto
Gerao de Cdigo
Construo
Integrao
Codificao
Teste e Manuteno
Implantao
Teste de
Depurao
Instalao
Teste
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:
VANTAGENS
DESVANTAGENS

artefatos.
fracas.

distintos.
requisitos.
Clientes s visualizam resultados
prximos ao final do projeto.

fase ou estgio.
de processo.
Apenas a fase final produz um artefato

de software entregvel.
incio do projeto.
00000000000
00000000000 - DEMO
Pg. 50 de 93

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

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:
complica, porque cada autor resolve criar suas fases!
00000000000
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:
00000000000 - DEMO
Pg. 51 de 93

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:
Por
Sommerville
Por
Yourdon
Por Pressman
(4 Ed.)
Por Pressman
(6 Ed.)
Por
Royce
Requisitos de
Sistema
Requisitos de
Software
Anlise
Sistema/Informao
Software
Projeto
Comunicao
Planejamento
Elicitao de
Requisitos
Projeto
Modelagem
Construo
Projeto
Gerao de Cdigo
Construo
Integrao
Codificao
Teste e Manuteno
Implantao
Teste de
Depurao
Instalao
Software
Unidade
Integrao e Teste de
Sistema
Operao e Manuteno
Teste
00000000000
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
00000000000 - DEMO
Pg. 52 de 93

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
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.
00000000000
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?
00000000000 - DEMO
Pg. 53 de 93

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.
00000000000
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?
00000000000 - DEMO
Pg. 54 de 93

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
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.
00000000000
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.
00000000000 - DEMO
Pg. 55 de 93

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.
00000000000
00000000000 - DEMO
Pg. 56 de 93

(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
uma entidade executvel independente, que deve manipular excees.
00000000000
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?
00000000000 - DEMO
Pg. 57 de 93

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 em
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).
00000000000
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:
00000000000 - DEMO
Pg. 58 de 93

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.
00000000000
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 prfabricadas e disponveis no mercado, podendo ser compradas ou licenciadas, i.e., uma
grande biblioteca de componentes prontos.
00000000000 - DEMO
Pg. 59 de 93

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 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.
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
00000000000
00000000000 - DEMO
Pg. 60 de 93

MODELO ORIENTADO A ASPECTOS

A maioria dos processos de desenvolvimento de software vem considerando
sistemas com unidades cada vez menores de desenvolvimento, i.e., vem
modularizando cada vez mais os sistemas. A Engenharia de Software prov as bases
para o desenvolvimento de software, j as linguagens de programao permitem a
abstrao de unidades e composio destas de inmeras formas possveis.
Sabe-se que no desenvolvimento de software existem propriedades que no se
enquadram em componentes da decomposio funcional, tais como: tratamento
de excees, restries de tempo real, distribuio e controle de concorrncia. Vocs
entendem isso? A grande maioria das unidades de programao podem ser
decompostas em uma funo, porm existem unidades que no podem!
Qual o problema, professor? Bem, essas unidades normalmente ficam espalhadas
em diversos componentes do sistema afetando a performance e a semntica da
aplicao. Vamos traduzir? Quando ns modularizamos um sistema, torna-se mais
fcil e intuitivo entender o funcionamento de uma aplicao; essas unidades que
no podem ser decompostas em funes atrapalham esse entendimento.
Imaginem que temos um mtodo que recebe um valor, realiza um processamento
e devolve outro valor. Uma funo dentro desse mtodo possui um tratamento de
exceo! Galera, tratamento de exceo no faz parte da funcionalidade principal,
no entanto mesmo assim ela fica presente no cdigo (atrapalhando a
modularizao e o acoplamento).
Embora essas unidades possam ser visualizadas e analisadas relativamente em
separado, sua implementao utilizando linguagens orientadas a objeto ou
estruturadas torna-se confusa e seu cdigo encontra-se espalhado atravs do
cdigo da aplicao, dificultando a separao da funcionalidade bsica do sistema
dessas propriedades.
00000000000
A Programao Orientada a Aspectos uma abordagem que permite a separao

dessas propriedades ortogonais1 dos componentes funcionais de uma forma natural
e concisa, utilizando-se de mecanismos de abstrao e de composio para a
Quando duas propriedades sendo programadas devem ser compostas de maneira diferente e ainda
coordenarem-se dito que elas so ortogonais entre si.
00000000000 - DEMO
Pg. 61 de 93

produo de cdigo executvel. Vocs podem me perguntar: Professor, por que no

podemos utilizar programao orientada a objetos ou programao estruturada?
Atualmente, conhecem-se vrios problemas de programao em que as tcnicas de
orientao a objetos ou de programao estruturada no so suficientes para
separar claramente todas as decises de projeto que o programa deve implementar.
Isto se deve ao fato de que as abordagens mais utilizadas concentram-se em
encontrar e compor unidades funcionais da decomposio do sistema.
J outras questes importantes no so bem localizadas no projeto funcional.
Exemplos disto podem ser propriedades que envolvem vrias unidades funcionais,
tais como: sincronizao, restries de tempo, concorrncia, distribuio de objetos,
persistncia, etc. Galera, vocs j conseguiram chegar a uma definio de
Programao Orientada a Aspectos? E se cair na discursiva?
Vocs podem dizer algo assim: Programao Orientada a Aspectos um paradigma
de desenvolvimento de software que separa responsabilidades, requisitos e
interesses de um sistema. A modularizao dos aspectos produz uma arquitetura
fcil de projetar, implementar e manter. Muitos acham que esse paradigma veio
para substituir a Programao Orientada a Objetos (POO). Est certo isso?
Claro que no! POA veio para complementar a POO (visto que utiliz-la
isoladamente no traz benefcios para o projeto). Para tal, ela mantm o foco na
separao de interesses (Separation of Concerns), que so requisitos especficos que
devem ser atendidos para satisfazer o objetivo de um sistema, mas que no
pertencem ao domnio do negcio. H dois tipos:
Interesses Principais (Core Concerns): capturam as funcionalidades centrais
de um mdulo.
Interesses Ortogonais (Crosscutting Concerns): capturam funcionalidades
perifricas.
00000000000
Por que separar interesses? Porque, dessa forma, geracdigo de melhor

qualidade; gera-se maior modularidade; facilita-se atribuio de responsabilidade
entre mdulos distintos; promove-se a reusabilidade de cdigo; facilita-se a
evoluo de software; viabiliza-se a anlise do problema dentro de domnios
especficos; entre outras tantas vantagens.
Ok, mas o que so Aspectos? Aspectos so propriedades de um sistema envolvendo
diversos componentes funcionais que no podem ser expressas utilizando as
00000000000 - DEMO
Pg. 62 de 93

notaes e linguagens atuais de uma maneira precisa (Ex: sincronizao,

persistncia, distribuio, interao entre componentes). Os interesses so
carregados em um mdulo chamado Aspecto.
Professor, um Aspecto um Componente? No, Componentes podem ser
encapsulados em um procedimento generalizado (objeto, mtodo, procedimento,
etc). Aspectos em geral no so unidades de decomposio funcional do sistema,
mas propriedades que envolvem diversas unidades de um sistema, afetando a
semntica dos componentes funcionais sistematicamente.
Rapaziada, possvel citar diversos exemplos de aspectos, como por exemplo:
controle de concorrncia em operaes em uma mesma conta bancria, registro
das transaes de uma determinada conta, poltica de segurana de acesso aos
usurios de um sistema, restries de tempo real associadas entrega de
mensagens.
Dada a definio de componentes e aspectos, possvel colocar o objetivo da
programao orientada a aspectos: oferecer suporte para o programador na tarefa
de separar claramente os componentes dos aspectos, os componentes entre si e os
aspectos entre si, utilizando-se de mecanismos que permitam a abstrao e
composio destas, produzindo o sistema desejado 2.
00000000000
Galera, qual a linguagem de Programao Orientada a Aspectos mais famosa? AspectJ.
00000000000 - DEMO
Pg. 63 de 93

(CESPE - 2013 ANTT - Analista de Sistemas) O paradigma de programao

orientada a aspectos traz solues para alguns dos problemas existentes no
paradigma orientado a objetos, como herana mltipla e sobrecarga de
operadores.
Comentrios:
J outras questes importantes no so bem localizadas no projeto funcional.
Exemplos disto podem ser propriedades que envolvem vrias unidades funcionais,
tais como: sincronizao, restries de tempo, concorrncia, distribuio de objetos,
persistncia, etc. Galera, vocs j conseguiram chegar a uma definio de
Programao Orientada a Aspectos? E se cair na discursiva?
Galera, no so esses os problemas resolvidos pela POA! Ela resolve problemas que
envolvem vrias unidades funcionais, ajudando a separar responsabilidades no
h qualquer relao com herana mltipla ou sobrecarga de operadores. Ademais,
vejam a pegadinha: herana mltipla e sobrecarga de operadores um problema do
paradigma orientado a objetos? No, galera um problema do Java! Lembrem-se
que Java no uma linguagem completamente orientada a objetos!
Gabarito: E
(CESPE - 2013 - SERPRO - Analista - Desenvolvimento de Sistemas) A POA, uma
evoluo da programao orientada a objetos, implementada nas linguagens
Java, C++, Smalltalk e Prolog.
00000000000
Comentrios:
Prolog? Galera, Prolog uma linguagem lgica; POA no pode ser implementada
nesta linguagem!
Gabarito: E
ACERTEI
ERREI
00000000000 - DEMO
Pg. 64 de 93

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
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.
00000000000
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.
00000000000 - DEMO
Pg. 65 de 93

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.
00000000000
00000000000 - DEMO
Pg. 66 de 93

(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
00000000000
00000000000 - DEMO
Pg. 67 de 93

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, testase os cem requisitos, e assim, por diante, sequencialmente.
00000000000
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.
00000000000 - DEMO
Pg. 68 de 93

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, presumese que iterativo. Eles frequentemente andam lado a lado, mas h pequenas
diferenas.
IMPORTANTE
00000000000
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
00000000000 - DEMO
Pg. 69 de 93

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
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.
00000000000
00000000000 - DEMO
Pg. 70 de 93

(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
uma pequena defasagem.
00000000000
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:
00000000000 - DEMO
Pg. 71 de 93

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

Gabarito: C
ACERTEI
ERREI
00000000000
00000000000 - DEMO
Pg. 72 de 93

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
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!
00000000000
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.
00000000000 - DEMO
Pg. 73 de 93

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!
00000000000
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. Desenvolvese rapidamente uma implementao inicial do software a partir de especificaes
bastante abstratas e so feitas modificaes de acordo com sua avaliao.
00000000000 - DEMO
Pg. 74 de 93

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.
00000000000
00000000000 - DEMO
Pg. 75 de 93

(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
gera problemas de manuteno de sistema porque o desenvolvimento rpido
e no sofre grandes mudanas.
00000000000
Comentrios:
sistema de software. Essa abordagem possui dois problemas (inclusive, j caram no
Senado Federal):
00000000000 - DEMO
Pg. 76 de 93


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
00000000000
00000000000 - DEMO
Pg. 77 de 93

LISTA DE EXERCCIOS COMENTADOS (DIVERSAS BANCAS)

CONCEITOS BSICOS DE ENGENHARIA DE SOFTWARE
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
para a modelagem gil.
00000000000
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.
00000000000 - DEMO
Pg. 78 de 93


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.
00000000000
(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.
00000000000 - DEMO
Pg. 79 de 93

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
que caracteriza a tcnica de entrevista estruturada em funil.
00000000000
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:
00000000000 - DEMO
Pg. 80 de 93

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,
00000000000
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.
00000000000 - DEMO
Pg. 81 de 93


(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.
00000000000
00000000000 - DEMO
Pg. 82 de 93


MODELO EM CASCATA
(FCC - 2012 - TJ- - 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.
00000000000
(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.
(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,
00000000000 - DEMO
Pg. 83 de 93

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.
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.
INMTRO Analista de Sistema) No desenvolvimento de
14. (CESPE
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.
00000000000
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.
TRE/MT Analista de Sistema O modelo em cascata
16. (CESPE
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
00000000000 - DEMO
Pg. 84 de 93

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.
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 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.
(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
Linear ou Modelo Cascata, apresentada uma abordagem sistemtica composta
pelas seguintes atividades:
00000000000
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.
00000000000 - DEMO
Pg. 85 de 93

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.
00000000000
00000000000 - DEMO
Pg. 86 de 93


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
projeto em considerao.
00000000000
(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.
00000000000 - DEMO
Pg. 87 de 93


MODELOS ORIENTADOS A ASPECTOS
(CESPE - 2013 ANTT - Analista de Sistemas) O paradigma de programao
orientada a aspectos traz solues para alguns dos problemas existentes no
paradigma orientado a objetos, como herana mltipla e sobrecarga de
operadores.
(CESPE - 2013 - SERPRO - Analista - Desenvolvimento de Sistemas) A POA, uma
evoluo da programao orientada a objetos, implementada nas linguagens
Java, C++, Smalltalk e Prolog.
00000000000
00000000000 - DEMO
Pg. 88 de 93


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.
00000000000
00000000000 - DEMO
Pg. 89 de 93


(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.
00000000000
00000000000 - DEMO
Pg. 90 de 93


(FG 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.
00000000000
00000000000 - DEMO
Pg. 91 de 93

GABARITO DOS EXERCCIOS COMENTADOS (DIVERSAS BANCAS)

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

1
E
2
E
3
E
10

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

BASEADO EM COMPONENTES OU ORIENTADO A RESO
1
C
2
E
3
C
4
C
5
C
6
E
7
C
00000000000 - DEMO
Pg. 92 de 93
10


MODELOS ORIENTADOS A ASPECTOS
1
E
2
E
10

MTODOS FORMAIS
1
E
10

1
C
2
C
3
C
10

1
C
2
E
00000000000
00000000000 - DEMO
Pg. 93 de 93
10

Curso 11143 Aula 00 v1

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Curso 11143 Aula 00 v1

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 00

Tecnologia da Informao (parte II) p/ ABIN OTI - Cargo 9 - Desenvolvimento e

Professor: Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

VIII QUALIDADE DE SOFTWARE: Metodologias de desenvolvimento de software; processo

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

DVIDAS DOS ALUNOS

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

RGOS PARA OS QUAIS J MINISTREI CURSOS

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

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

ABIN OFICIAL TCNICO DE INTELIGNCIA

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

VIII QUALIDADE DE SOFTWARE: Metodologias de desenvolvimento de

processo unificado: conceitos, diretrizes, disciplinas;

metodologias geis; prticas geis: Integrao contnua, Test-driven

mtricas e estimativas de software; anlise por pontos de funo.

IX ANLISE E PROJETO ORIENTADOS A OBJETOS: Conceitos bsicos,

UML: Viso geral, modelos e diagramas.

VI ENGENHARIA DE REQUISITOS: Conceitos bsicos; tcnicas de

VII ENGENHARIA DE USABILIDADE: Conceitos bsicos e aplicaes;

II LGICA DE PROGRAMAO: Construo de algoritmos; tipos de dados

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

parmetros; recursividade; conceitos bsicos de programao

X PROGRAMAO ORIENTADA A OBJETOS: Conceitos bsicos: classes,

XI LINGUAGENS E TECNOLOGIAS DE PROGRAMAO: Linguagens de

PHP; Javascript; AJAX; DHTML; XML, XSD e XSLT.

Arquitetura: Service Oriented Architecture (SOA); SOAP; Design

TESTES: Teste funcional, de performance e de integrao; plano de

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

2 Viso Geral: no se atenham a detalhes antes de

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

ENGENHARIA DE SOFTWARE: CONCEITOS GERAIS

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

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

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

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

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

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)

J na dcada de oitenta, surgiu a Anlise Estruturada e algumas Ferramentas CASE

Prof. Diego Carvalho

Tecnologia da Informao para Oficial de Inteligncia (Desenvolvimento)