Aula 00: Engenharia de Software para Concursos - Curso Regular

Aula 00
Engenharia de Software para Concursos - Curso Regular

Professor: Diego Carvalho
Curso Regular de Engenharia de Software
Curso de Teoria e Exercícios - 2016
Prof. Diego Carvalho – Aula 00
AULA 00
SUMÁRIO PÁGINA
Apresentação 01
- Engenharia de Software: Conceitos Gerais 12
- Ciclo de Vida de Software 31
- Processos de Desenvolvimento de Software 33
- Modelo em Cascata 37
Lista de Exercícios Comentados 56
Gabarito 68
16712855225
Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 1 de 68

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

Metodologias ou Processos de Desenvolvimento de Software: Modelo em Cascata. Modelo Orientado
a Reuso. Modelo em Prototipagem, Modelo Evolucionário, Modelo Espiral, Modelo Formal, RAD, Modelo
Iterativo e Incremental. Processo Unificado: Conceitos Básicos, Dimensões Dinâmica, Estática e
Prática, Gráfico das Baleias, Fases (Iniciação, Elaboração, Construção e Transição), Disciplinas ou
Fluxo de Processos (Modelagem de Negócio, Requisitos, Análise e Projeto, Implementação, Teste,
Implantação, Gestão de Configuração e Mudança, Gestão de Projetos, Ambiente), Artefatos,
Atividades, Melhores Práticas, Principais Marcos, Princípios Chaves. Metodologias Ágeis de
Desenvolvimento de Software: Scrum, eXtreme Programming (XP), Feature-driven Development
(FDD), Test-driven Development (TDD), Acceptance Test-driven Development (ATDD), Kanban.
Definição de Requisito, Classificação de Requisitos (Funcional, Não- Funcional, Domínio; Produto,
Organizacional, Externo; Confiabilidade, Proteção, Desempenho, etc); Engenharia de Requisitos:
Estudo de Viabilidade, Elicitação e Análise de Requisitos, Especificação de Requisitos, Validação de
Requisitos, Gestão de Requisitos. Técnicas de Elicitação e Técnicas de Validação. Linguagem de
Modelagem: Unified Modeling Language (UML) 2.x – Contexto Histórico, Conceitos Básicos, Tipos de
Diagramas (Estruturais, Comportamentais, Interação). Diagramas de Classes, Componentes,
Implantação, Perfil, Objetos, Estrutura Composta, Pacotes, Máquina de Estados, Casos de Uso,
Atividades, Sequência, Comunicação, Interação Geral e Tempo. Conceitos Básicos do Paradigma
Estruturado. Conceitos Básicos de Orientação a Objetos: Classes, Objetos, Atributos, Métodos,
Mensagens, Abstração, Encapsulamento, Polimorfismo, Herança, Relacionamentos). Análise e
Projeto: Conceitos Básicos, Diferenças, Modelos, Classes de Fronteira, Controle e Entidade. Análise
de Pontos de Função: IFPUG – Definição e Contexto, Benefícios e Vantagens, Componentes de Dados
(AIE, ALI) e Transação (EE, SE, CE), Etapas do Procedimento de Contagem: Determinar Tipo de
Contagem, Determinar Escopo e Fronteira, Cálculo dos Pontos de Função Não-Ajustados, Cálculo do
Fator de Ajuste, Cálculo dos Pontos de Função Ajustados. NESMA - Tipos de Contagem e Deflatores.
Qualidade de Software: Garantia e Controle, Principais Características, Verificação & Validação,
Erro, Falha, Falta e Defeito. Testes de Software: Conceitos Básicos, Processo de Testes, Técnicas de
16712855225
Testes (Teste Caixa Banca, Cinza e Preta), Níveis de Testes (Teste de Unidade, Módulo, Componente;
Teste de Integração; Teste de Aceitação, Validação, Release; Teste de Sistema/Funcional). Tipos de
Testes: Carga, Estresse, Volume, Desempenho, Usabilidade, Cenários, Regressão, Back-to-Back,
Comparação, Recuperação, Alfa, Beta, Compatibilidade, Estático, Dinâmico). Arquitetura de
Software. Arquitetura em Camadas (Cliente/Servidor). Arquitetura MVC. Arquitetura Distribuída.
Arquitetura Hub. Arquitetura Microsserviços. Arquitetura Mainframe. Arquitetura Orientada a
Serviços (SOA): Conceitos Básicos, SOAP, WSDL, UDDI. REST. WS-Security. Interoperabilidade de
Sistemas. e- PING: Conceitos Básicos, Interoperabilidade, Escopo, Políticas Gerais, Segmentação,
Gestão. Acessibilidade de Sistemas. e-MAG 3.1: Conceitos Básicos, Acessibilidade, Acesso, Passos
para um Sítio Acessível, Segmentos, Recomendações. Engenharia de Usabilidade. Gerenciamento
Eletrônico de Documentos (GED). Portais Corporativos e Colaborativos.

APRESENTAÇÃO
Olá, pessoal. Sejam bem-vindos ao Curso Regular de Engenharia de Software!

Galera, depois de receber dezenas de pedidos requisitando um curso que ajudasse
alunos a se prepararem com certa antecedência para concursos, resolvemos lançar
cursos regulares! Esse curso está redondo, muito maduro e com um bocado de
exercícios. Aqui você encontrará o conteúdo mais comum em qualquer edital de
engenharia de software.
O cenário político/fiscal atual não está muito favorável para os concursos, porém,
sa é a hora de começar a estudar e ter uma vantagem sobre os concorrentes.
Precisa falar que Engenharia de Software é importante? Precisa falar que você tem
que saber tudo sobre Métodos Ágeis, RUP, Requisitos, Testes, UML, Análise, Projeto,
etc? Precisa falar que é tema certo de prova discursiva?
DÚVIDAS DOS ALUNOS
TOP 5
1. Peço encarecidamente que leiam as instruções dessa primeira aula. Eu sei que é chato, mas assim
nós alinhamos nossas expectativas a respeito do curso.
16712855225
2. Essa é a Aula Demonstrativa (está disponível para todos na internet) – o restante do conteúdo estará
disponível na Aula 01 (apenas para aqueles que adquirirem o curso).
3. Esse curso não possui vídeo-aulas! Estamos trabalhando para disponibilizá-las em breve, nesse
primeiro semestre – talvez ainda não seja possível disponibilizá-las para esse curso.
4. Esse curso contempla somente aquilo que está em seu cronograma. Ele não contempla todo edital de
tecnologia da informação, nem outras disciplinas, nem discursivas, estudos de caso, etc.
5. Existem questões de Múltipla Escolha (A, B, C, D, E) e existem questões de Certo/Errado (C, E). Quando
não há itens para escolha na questão, é porque a questão é da Modalidade Certo/Errado.

O PROFESSOR
Uma breve apresentação: meu nome é Diego Carvalho, bacharel em Ciência da

Computação pela Universidade de Brasília, pós-graduado em Gestão de Tecnologia
da Informação na Administração Pública e Analista de Finanças e Controle da
Secretaria do Tesouro Nacional. Já passei por esses perrengues de concurseiro e sei
de duas coisas: a estrada é difícil, mas o prêmio compensa! E muito!
www.facebook.com/professordiegocarvalho
ÁREA ÓRGÃOS PARA OS QUAIS JÁ MINISTREI CURSOS
Agência ANCINE ANTAQ ANATEL
Jurídica TRT/1 TRT/2 TRT/3 TRT/4

TJ/BA CNMP MP/PB TRT/15
Legislativa CÂMARA DOS
DEPUTADOS
Auditoria TCE/RS TCE/SP TCE/CE TCM/GO
TCU TCM/SP
Fiscal ISS/SP ISS/BA
Outros CEF DATAPREV DEPEN INMETRO
Galera, lá no site, nós – professores – temos algumas métricas para medir se o nosso
16712855225
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... vocês vão aprender muito com esse curso!

16712855225

16712855225

16712855225

O CURSO...
Antes de começar o curso, vamos alinhar algumas expectativas! O curso que eu

proponho abrangerá todo o conteúdo do meu cronograma, entretanto é impossível
e inviável esgotar cada ponto do edital em uma aula escrita. Como se ministra Java
em uma aula? Teríamos uma aula de 800 páginas e não chegaríamos nem perto de
matar todo conteúdo! Imaginem agora cada ponto do Edital.
Portanto, vou direcioná-los pelo conteúdo da melhor maneira possível. O nosso

foco é ter uma visão geral, mas objetiva do que de fato cai em prova e, não,
elucubrações sobre cada tema. Meu foco aqui é te fazer passar! Eu sei como é
complicado ler muita coisa (ainda mais de TI) e vocês têm outras disciplinas para
estudar. Logo, vou ser simples e objetivo! Tranquilo? ;)
Além disso, o cronograma será seguido com a maior fidelidade possível, mas ele
não é estático e poderá haver alterações no decorrer do curso. Eventualmente,
posso tirar o conteúdo de uma aula e colocar em outra de forma que o estudo de
vocês fique mais lógico, coeso e fácil de acompanhar; posso também inverter a
ordem das aulas (adiantar uma aula e atrasar outra) – sem prejudicá-los.
Além disso, vamos usar questões de diversas bancas. Enfim, confiem em mim: o
curso vai ajudar bastante! Qualquer dúvida, é só me chamar! Caso haja alguma
reclamação, problema, sugestão, comentários, erros de digitação, etc, podem enviar
para o nosso fórum que eu tento responder da maneira mais tempestiva possível.
Ainda duvidam que PDF não dá certo com Concursos de TI? Veja abaixo:
6º Lugar – ISS/Salvador 16712855225
https://www.youtube.com/watch?v=b1w4H3l6mC4#t=1678
1º Lugar – TRT/RJ
https://www.facebook.com/video.php?v=790616534367672
2º Lugar – ISS/Salvador
https://www.youtube.com/watch?v=vmU1n1J-aqQ
1º Lugar – Dataprev
http://www.estrategiaconcursos.com.br/blog/entrevista-andre-furtado-aprovado-em-1o-lugar-
no-concurso-dataprev-para-o-cargo-de-analistaarea-de-tecnologia-da-informacao/

CRONOGRAM
Aula Data Tópicos do Edital

00 25/03 Aula Demonstrativa. Engenharia de Software. Conceitos Básicos ou
Gerais. Ciclo de vida do software. Modelos, Metodologias ou Processos
de Desenvolvimento de Software: Modelo em Cascata.
01 01/04 Modelo Orientado a Reuso. Modelo em Prototipagem, Modelo

Evolucionário, Modelo Espiral, Modelo Formal, RAD, Modelo Iterativo e
Incremental.
02 15/04 Processo Unificado: Conceitos Básicos, Dimensões Dinâmica, Estática e

Prática, Gráfico das Baleias, Fases (Iniciação, Elaboração, Construção
e Transição), Disciplinas ou Fluxo de Processos (Modelagem de Negócio,
Requisitos, Análise e Projeto, Implementação, Teste, Implantação,
Gestão de Configuração e Mudança, Gestão de Projetos, Ambiente),
Artefatos, Atividades, Melhores Práticas, Principais Marcos, Princípios
Chaves.
03 01/05 Metodologias Ágeis de Desenvolvimento de Software: Scrum, eXtreme
Programming (XP), Feature-driven Development (FDD), Test-driven
Development (TDD), Acceptance Test-driven Development (ATDD),
Kanban.
04 15/05 Definição de Requisito, Classificação de Requisitos (Funcional, Não-

Funcional, Domínio; Produto, Organizacional, Externo; Confiabilidade,
Proteção, Desempenho, etc); Engenharia de Requisitos: Estudo de
16712855225
Viabilidade, Elicitação e Análise de Requisitos, Especificação de

Requisitos, Validação de Requisitos, Gestão de Requisitos. Técnicas de
Elicitação e Técnicas de Validação.
05 01/06 Linguagem de Modelagem: Unified Modeling Language (UML) 2.x –

Contexto Histórico, Conceitos Básicos, Tipos de Diagramas
(Estruturais, Comportamentais, Interação). Diagramas de Classes,
Componentes, Implantação, Perfil, Objetos, Estrutura Composta,
Pacotes, Máquina de Estados, Casos de Uso, Atividades, Sequência,
Comunicação, Interação Geral e Tempo.

06 15/06 Conceitos Básicos do Paradigma Estruturado. Conceitos Básicos de

Orientação a Objetos: Classes, Objetos, Atributos, Métodos, Mensagens,
Abstração, Encapsulamento, Polimorfismo, Herança, Relacionamentos).
Análise e Projeto: Conceitos Básicos, Diferenças, Modelos, Classes de
Fronteira, Controle e Entidade.
07 01/07 Análise de Pontos de Função: IFPUG – Definição e Contexto, Benefícios

e Vantagens, Componentes de Dados (AIE, ALI) e Transação (EE, SE, CE),
Etapas do Procedimento de Contagem: Determinar Tipo de Contagem,
Determinar Escopo e Fronteira, Cálculo dos Pontos de Função Não-
Ajustados, Cálculo do Fator de Ajuste, Cálculo dos Pontos de Função
Ajustados. NESMA - Tipos de Contagem e Deflatores.
08 15/07 Qualidade de Software: Garantia e Controle, Principais Características,

Verificação & Validação, Erro, Falha, Falta e Defeito. Testes de Software:
Conceitos Básicos, Processo de Testes, Técnicas de Testes (Teste Caixa
Banca, Cinza e Preta), Níveis de Testes (Teste de Unidade, Módulo,
Componente; Teste de Integração; Teste de Aceitação, Validação,
Release; Teste de Sistema/Funcional). Tipos de Testes: Carga, Estresse,
Volume, Desempenho, Usabilidade, Cenários, Regressão, Back-to-Back,
Comparação, Recuperação, Alfa, Beta, Compatibilidade, Estático,
Dinâmico).
09 01/08 Arquitetura de Software. Arquitetura em Camadas (Cliente/Servidor).

Arquitetura MVC. Arquitetura Distribuída. Arquitetura Hub. Arquitetura
Microsserviços. Arquitetura Mainframe.
10 15/08 Arquitetura Orientada a Serviços (SOA): Conceitos Básicos, SOAP,

16712855225
WSDL, UDDI. REST. WS-Security.
11 01/09 Interoperabilidade de Sistemas. e- PING: Conceitos Básicos,

Interoperabilidade, Escopo, Políticas Gerais, Segmentação, Gestão.
Acessibilidade de Sistemas. e-MAG 3.1: Conceitos Básicos,
Acessibilidade, Acesso, Passos para um Sítio Acessível, Segmentos,
Recomendações.
12 15/09 Engenharia de Usabilidade. Gerenciamento Eletrônico de Documentos

(GED). Portais Corporativos e Colaborativos.

AS AULAS E AS DICAS
1 – Parágrafos pequenos: observem que os parágrafos 2 – Visão Geral: não se atenham a detalhes antes de
têm, no máximo, cinco linhas. Isso serve para que a entender o básico. Por que? Ora, não há nada mais
leitura não fique cansativa e para que vocês não irritante do que ir para uma prova que vai cair, por
desanimem no meio do material! Para tal, eu tento dividir exemplo, RUP, saber vários detalhes, mas não saber as
as disciplinas de maneira que as aulas fiquem objetivas e fases e disciplinas. Portanto, caso estejam iniciando os
pequenas (em termos de teoria), mas extensa (em estudos sobre uma matéria, foquem em saber o básico
termos de exercícios). para depois se especializarem.
3 – Destaques em vermelho: quase todos os 4 – Façam muitos exercícios: ler várias bibliografias é
parágrafos possuem alguma palavra ou frase destacada muito trabalhoso e, geralmente, não vale o custo-
em negrito e em vermelho. Isso ocorre por suas razões: benefício. Acredito que o que funciona mesmo é entender
primeiro, para enfatizar alguma informação importante; o básico, depois fazer muitos exercícios e,
segundo, para facilitar a leitura vertical, i.e., após uma eventualmente, caso encontrarem algo que não
primeira leitura, a segunda pode ser passando apenas souberem, pesquisem-no separadamente. Além disso,
pelos pontos em destaque. você vai pegando as “manhas” da banca.
5 – Linguagem natural: essa é uma aula para ser lida, o 6 – Façam resumos: essa dica somente serve caso
que por si só já pode ser cansativo. Tentarei colocar a vocês tenham disponibilidade. Caso haja pouco tempo
linguagem mais coloquial possível, simulando uma para estudar ou pouco tempo até a prova, não compensa!
conversa. Portanto, caso virem frases ou palavras em Se não, façam resumos organizados, pois eles
itálico, ou é uma palavra estrangeira ou é a simulação de economizarão um bom tempo de estudo em suas
uma conversa com vocês. Pode dar um exemplo, próximas provas e sempre que descobrirem novas
professor? Acabei de dar! :-) informações, insiram-nas no resumo.
7 – Diversas figuras: essas aulas estarão em constante 8 – Revisem antes da prova: não adianta querer
evolução, sempre à procura de explicar as matérias de estudar coisas novas até o último minuto antes da prova
maneira mais compreensível e com novas e não revisar o que estudou há um mês. Vocês irão
informações/questões. Para tal, na minha opinião, é esquecer e irão se irritar na hora da prova por não
fundamental a utilização de figuras, gráficos, painéis, etc. lembrarem de conceitos simples. Tirem uma semana
Em minha experiência, é bem mais fácil memorizar a para revisar seus resumos, decorarem algumas coisas
partir de imagens. e, certamente, irão mais confiantes para a prova.
9 – Fazer Exercícios: muitos exercícios é o meio pelo 10 – Simulado Final: ora, fazer um bloco de questões
qual vocês se situarão. Como assim, professor? É na hora 16712855225
depois de estudar a teoria é tranquilo. No entanto,
de fazer os exercícios que vocês descobrirão se estão lembrem-se que a memória de vocês não é infinita e
bem ou mal e avaliarão se precisam estudar mais ou vocês têm um milhão de outras coisas para estudar e
menos. Para tal, há um quadrinho ao final de cada bloco decorar. Portanto, se possível, ao fim do curso faremos
de exercícios para vocês anotarem a quantidade de um simulado com questões escolhidas que foram
questões respondidas corretamente ou incorretamente. comentadas dentro das aulas.
Bem, pessoal! É isso... sejam bem-vindos! Espero que vocês curtam e tenham uma
leitura leve e despojada da aula, mas com muito foco, atenção e dedicação.
Qualquer dúvida, podem entrar em contato comigo – ficarei feliz em ajudá-los. Bons
estudos, estou torcendo por vocês!

ENGENHARIA DE SOFTWARE: CONCEITOS GERAIS
Vamos lá, galera! Apesar de hoje em dia haver milhões de profissionais que mexem
com software no mundo inteiro, faz pouco tempo que a Engenharia de Software
alcançou o status de profissão reconhecida e de disciplina legítima de engenharia.
Pois é, ela ganhou tanta importância que é cobrada até em concursos públicos! Ok,
professor... mas o que é a Engenharia de Software?
A IEEE define engenharia de software como a aplicação de uma abordagem

sistemática, disciplinada e quantificável de desenvolvimento, operação e
manutenção de software. Já Friedrich Bauer conceitua como a criação e a utilização
de sólidos princípios de engenharia a fim de obter software de maneira econômica,
que seja confiável e que trabalhe em máquinas reais.
Em suma, é uma disciplina de engenharia que se ocupa de todos os aspectos da

produção de software, desde os estágios iniciais de especificação do sistema até a
manutenção desse sistema, após sua entrada em produção A meta incipal da
Engenharia de Software é desenvolver sistemas de software com boa relação custo-
benefício. Bacana?
Aliás, vamos voltar um pouquinho: o que seria um software? Bem, em uma visão
restritiva, muitas pessoas costumam associar o termo software aos programas de
computador. Software não é apenas o programa, mas também todos os dados de
documentação e configuração associados, necessários para que o programa opere
corretamente. Vamos prosseguir...
Sommerville define processo de software como a abordagem sistemática usada pela

16712855225
engenharia de software para produção de software. Pode-se identificar as seguintes

atividades: Especificação; Desenvolvimento; Validação; e Evolução. O Processo de
Software é uma caracterização descritiva ou prescritiva de como um produto de
software deve ser desenvolvido. E o que diz Pressman?
De acordo com Pressman: “A Engenharia de Software ocorre como consequência 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 serviço
ou uma tecnologia para transformação da informação ou controle”.

Ademais, nosso renomadíssimo autor afirma que a engenharia de sistemas está

preocupada com todos os aspectos do desenvolvimento de sistemas
computacionais, incluindo engenharia de hardware, engenharia de software e
engenharia de processos. Percebam, então, que a Engenharia de Sistemas está em
um contexto maior. Entenderam direitinho?
A Engenharia de Software tem por objetivos a aplicação de teoria, modelos,

formalismos, técnicas e ferramentas da ciência da computação e áreas afins para a
desenvolvimento sistemático de software. Associado ao desenvolvimento, é preciso
também aplicar processos, métodos 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
produção da documentação formal do produto, do processo, dos critérios de
qualidade e dos manuais de usuários finais. Todos esses aspectos devem ser levados
em consideração.
Aliás, nosso outro renomadíssimo autor (Sommerville) afirma que: “A engenharia de

software não está relacionada apenas com os processos técnicos de desenvolvimento
16712855225
de software, mas também com atividades como o gerenciamento de projeto de

software e o desenvolvimento de ferramentas, métodos e teorias que apoiem a
produção de software”.
A Engenharia de Software surgiu em meados da década de sessenta como uma

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

Já na década de oitenta, surgiu a Análise Estruturada e algumas Ferramentas CASE

que permitiam automatizar algumas tarefas. Na década de noventa, surgiu a
orientação a objetos, linguagens visuais, processo unificado, entre outros. E na
última década, surgiram as metodologias ágeis e diversos paradigmas de
desenvolvimento.
A Engenharia de Software possui alguns princípios, tais como: Formalidade, em que

o software deve ser desenvolvido de acordo com passos definidos com precisão e
seguidos de maneira efetiva; Abstração, preocupa-se com a identificação de um
determinado fenômeno da realidade, sem se preocupar com detalhes,
considerando apenas os aspectos mais relevantes.
Há a Decomposição, em que se divide o problema em partes, de maneira que cada

uma possa ser resolvida de uma forma mais específica; Generalização, maneira
usada para resolver um problema, de forma genérica, com o intuito de reaproveitar
essa solução em outras situações; Flexibilização é o processo que permite que o
software possa ser alterado, sem causar problemas para sua execução.
Certa vez, um aluno me perguntou: professor, como a formalidade pode reduzir

inconsistências? Cenário 1: Estamos na fase de testes de software. O testador afirma
que fez todos os testes, você - líder de projeto - acredita, e passa o software ao
cliente. Esse tenta utilizar o software e verifica que ele não está funcionando
corretamente. Bacana?
Cenário 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ê - líder de projeto - lê o documento de testes e verifica que não
foram feitos testes de carga e testes de segurança. Retorna para o testador e pede
para ele refazer os testes. 16712855225
Feito isso, ele passa o software ao cliente, que fica feliz e satisfeito com tudo
funcionando corretamente. Vocês percebem que essas formalidades evitam aquele
"telefone-sem-fio"? Quanto mais eu seguir o processo, o passo-a-passo, o que foi
definido por várias pessoas a partir de suas experiências com vários projetos, mais
eu tenho chance de obter êxito na construção do meu software. Bacana?
Bem, galera... a Engenharia de Software se divide em algumas disciplinas genéricas

como: Requisitos de Negócio, Requisitos de Software, Análise de Software, Projeto
de Software, Construção de Software, Testes de Software, Implantação de Software

e Manutenção de Software. Pessoal, essas disciplinas e seus nomes são bem

genéricos e variam de acordo com os autores.
A disciplina de Requisitos de Negócio busca entender como o negócio funciona. Já

a disciplina de Requisitos de Software busca entender e levantar os requisitos. Na
Análise de Software, desenha-se o problema e no Projeto de Software, desenha-se
a solução do problema. A Construção de Software é a implementação ou
codificação em si.
Na disciplina de Testes de Software, realizam-se verificações para garantir sua

consistência e funcionamento. Na disciplina de Implantação de Software, coloca-se
o software em produção na organização. Por fim, a disciplina de Manutenção de
Software busca manter o software funcionando. Bem, é isso... nós nos
aprofundaremos mais adiante.
ESQUEMA
16712855225

(CESPE - 2013 - TRT - 10ª REGIÃO (DF e TO) - Analista Judiciário - Tecnologia da
Informação) A engenharia de software engloba processos, métodos e
ferramentas. Um de seus focos é a produção de software de alta qualidade a
custos adequados.
Comentários:

Basta visualizar a imagem para responder à questão!

16712855225
Gabarito: C
(FCC - 2012 - TST - Analista Judiciário - Análise de Sistemas) A Engenharia de

Software:
a) é uma área da computação que visa abordar de modo sistemático as questões

técnicas e não técnicas no projeto, implantação, operação e manutenção no
desenvolvimento de um software.

b) consiste em uma disciplina da computação que aborda assuntos relacionados

a técnicas para a otimização de algoritmos e elaboração de ambientes de
desenvolvimento.
c) trata-se de um ramo da TI que discute os aspectos técnicos e empíricos nos

processos de desenvolvimento de sistemas, tal como a definição de artefatos
para a modelagem ágil.
d) envolve um conjunto de itens que abordam os aspectos de análise de

mercado, concepção e projeto de software, sendo independente da engenharia
de um sistema.
e) agrupa as melhores práticas para o concepção, projeto, operação e

manutenção de artefatos que suportam a execução de programas de
computador, tais como as técnicas de armazenamento e as estruturas em
memória principal.
Comentários:

(a) Perfeito, observem as palavras-chave: modo sistemático; questões técnicas e não

técnicas; projeto, implantação, operação e manutenção de desenvolvimento de
software. (b) Técnicas para otimização de algoritmos e elaboração de ambientes de
16712855225
desenvolvimento? Não, isso não é Engenharia de Software. (c) Pessoal, discordo do

gabarito! Certa vez, um aluno me disse que talvez fosse porque aspectos empíricos
são mais voltados para metodologias ágeis. Sim, é verdade! No entanto, a
engenharia de software trata também de metodologias ágeis. Se alguém encontrar
o erro, avise :-] (d) A Análise de Mercado serve mais como uma técnica para Análise
de Interfaces, mas pode ser vista como um dos aspectos que envolvem a Engenharia
de Software. Pressman afirma que: “A Análise de Mercado pode ser inestimável na
definição de segmentos de mercado e no entendimento de como cada segmento
poderia usar o software de modos sutilmente diferentes”. De todo modo, a questão
está errada porque a Engenharia de Software depende da Engenharia de Sistema

(como é mostrado acima). (e) Suportam a execução? Não, suportam o

desenvolvimento de programas de computador.
Gabarito: A
(FCC - 2012 - TRT - 6ª Região (PE) - Técnico Judiciário - Tecnologia da

Informação) Considere: é uma disciplina que se ocupa de todos os aspectos da
manutenção desse sistema, depois que ele entrou em operação. Seu principal
objetivo é fornecer uma estrutura metodológica para a construção de software
com alta qualidade. A definição refere-se:
a) ao ciclo de vida do software.

b) à programação orientada a objetos.
c) à análise de sistemas.
d) à engenharia de requisitos.
e) à engenharia de software.
Comentários:
Em suma, é uma disciplina de engenharia que se ocupa de todos os aspectos da

manutenção desse sistema, após sua entrada em produção. A meta principal da
Engenharia de Software é desenvolver sistemas de software com boa relação custo-
benefício. Bacana?
Conforme vimos em aula, essa é a pura definição de Engenharia de Software!
16712855225
Gabarito: E
(CESPE - 2011 - MEC - Gerente de Projetos A engenharia de software, disciplina

relacionada aos aspectos da produção de software, abrange somente os
processos técnicos do desenvolvimento de software.
Comentários:



Conforme vimos em aula, não são apenas processos técnicos!
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 são:
a) métodos, processo e teste.

b) ferramentas, métodos e processo.
c) métodos, construção, teste e implantação.
d) planejamento, modelagem, construção, validação e implantação.
e) comunicação, planejamento, modelagem, construção e implantação.
Comentários:
16712855225
Conforme vimos em aula, bastava visualizar a imagem para responder à questão!
Gabarito: B
(CESPE - 2010 - Banco da Amazônia - Técnico Científico - Tecnologia da

Informação Os princípios de engenharia de software definem a necessidade de
formalidades para reduzir inconsistências e a decomposição para lidar com a
complexidade.
Comentários:


seguidos de maneira efetiva; Há a Decomposição, em que se divide o problema em
partes, de maneira que cada uma possa ser resolvida de uma forma mais específica;
Conforme vimos em aula, são princípios: Formalidade e Decomposição.
Gabarito: C
(FCC - 2010 - TRE- - Analista Judiciário - Tecnologia da Informação A

Engenharia de Software:
a) não tem como método a abordagem estruturada para o desenvolvimento de

software, pois baseia-se exclusivamente nos modelos de software, notações,
regras e técnicas de desenvolvimento.
b) se confunde com a Ciência da Computação quando ambas tratam do

desenvolvimento de teorias, fundamentações e práticas de desenvolvimento de
software.
c) tendo como foco apenas o tratamento dos aspectos de construção 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 sistemática de

desenvolvimento, através de ferramentas e técnicas apropriadas, dependendo
do problema a ser abordado, considerando restrições e recursos disponíveis.
16712855225
e) segue princípios, tais como, o da Abstração, que identifica os aspectos

importantes sem ignorar os detalhes e o da Composição, que agrupa as
atividades em um único processo para distribuição aos especialistas.
Comentários:
A IEEE define engenharia de software como a aplicação de uma abordagem

sistemática, disciplinada e quantificável de desenvolvimento, operação e manutenção
de software. Já Friedrich Bauer conceitua como a criação e a utilização de sólidos
princípios de engenharia a fim de obter software de maneira econômica, que seja
confiável e que trabalhe em máquinas reais.

(a) Pelo contrário, ela se baseia em uma abordagem estruturada e sistemática!

(b) Na verdade, Engenharia de Software é uma disciplina da Ciência da Computação.
(c) Apenas o tratamento dos aspectos de construção de software? Só construção?

Não!
(d) Perfeito, é exatamente isso!


determinado fenômeno da realidade, sem se preocupar com detalhes, considerando
apenas os aspectos mais relevantes.
(e) Composição? Não, Decomposição! Divide-se o problema em partes para que

16712855225
cada uma possa ser resolvida de uma forma mais específica. Além disso, a abstração
ignora detalhes!
Gabarito: D
(FCC - 2011 - INFRAERO - Analista de Sistemas - Gestão de TI Em relação à

Engenharia de Software, é INCORRETO afirmar:
a) O design de software, ao descrever os diversos aspectos que estarão presentes

no sistema quando construído, permite que se faça a avaliação prévia para
garantir que ele alcance os objetivos propostos pelos interessados.

b) A representação de um design de software mais simples para representar

apenas as suas características essenciais busca atender ao princípio da abstração.
c) Iniciar a entrevista para obtenção dos requisitos de software com perguntas

mais genéricas e finalizar com perguntas mais específicas sobre o sistema é o
que caracteriza a técnica de entrevista estruturada em funil.
d) No contexto de levantamento de requisitos, funcionalidade é um dos aspectos

que deve ser levado em conta na abordagem dos requisitos funcionais.
e) A representação é a linguagem do design, cujo único propósito é descrever

um sistema de software que seja possível construir.
Comentários:
Galera, descrever um sistema de software que seja possível construir não é o único,
mas um dos objetivos da representação. Ela auxilia a comunicação entre as partes
interessadas e serve também como documentação.
Gabarito: E
(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.
16712855225
e) das engenharias de sistemas e de produto, apenas.
Comentário


Ademais, nosso renomadíssimo autor afirma que a engenharia de sistemas está

preocupada com todos os aspectos do desenvolvimento de sistemas computacionais,
incluindo engenharia de hardware, engenharia de software e engenharia de
processos. Percebam, então, que a Engenharia de Sistemas está em um contexto
maior. Entenderam direitinho?
Conforme vimos em aula, está inserida no contexto das Engenharias de Sistemas,

de Processo e de Produto.
Gabarito: A
10. (CESPE – 2015 – STJ – Analista de Sistemas Embora os engenheiros de software

geralmente utilizem uma abordagem sistemática, a abordagem criativa e menos
formal pode ser eficiente em algumas circunstâncias, como, por exemplo, para
o desenvolvimento de sistemas web, que requerem uma mistura de habilidades
de software e de projeto.
Comentários:
Apesar de soar um pouco estranho, isso está no Sommerville:
“No entanto, engenharia tem tudo a ver com selecionar o método mais adequado
para um conjunto de circunstâncias, então uma abordagem mais criativa e menos
formal pode ser eficiente em algumas circunstâncias. Desenvolvimento menos formal
particularmente adequado para o desenvolvimento de sistemas Web, que requerem
uma mistura de habilidades de software e de projeto”.
Gabarito: C
16712855225
11. (CESPE – 2015 – STJ – Analista de Sistemas) O foco da engenharia de software

inclui especificação do sistema, desenvolvimento de hardware, elaboração do
projeto de componentes de hardware e software, definição dos processos e
implantação do sistema.
Comentários:
Conforme vimos em aula, até trata de alguns aspectos de hardware; mas

desenvolvimento de hardware, não.
Gabarito: E

12. (CESPE – 1– – Analista de Sistemas) O processo de desenvolvimento de

software é uma caracterização descritiva ou prescritiva de como um produto de
software deve ser desenvolvido.
Comentários:

Conforme vimos em aula, a questão está perfeita!
Gabarito: C
13. (CESPE – 3 – TRT/10ª – Analista de Sistemas) As atividades fundamentais

relacionadas ao processo de construção de um software incluem a especificação,
o desenvolvimento, a validação e a evolução do software.
Comentários:

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

software consiste em uma representação complexa de um processo de software,
apresentada a partir de uma perspectiva genérica.
Comentários:

Não, trata-se de uma representação simplificada de um processo de software,

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

processos de software incluem a especificação, o projeto, a implementação e a
validação.
mentários:

Vejam que ele dividiu a atividade de Desenvolvimento em Projeto e Implementação,

mas não invalida a questão. Professor, ele não falou sobre a evolução! Sim, mas a
questão apenas afirma que essas são atividades comuns e, não, que são as únicas.
Gabarito: C
16. (CESPE – 5 – STJ – Analista de Sistemas) As principais atividades de

engenharia de software são especificação, desenvolvimento, validação e
evolução.
Comentários:
16712855225

Gabarito: C

17. (FUNIVERSA – – IPHAN – Analista de Sistemas) A Engenharia de Software

resume-se em um conjunto de técnicas utilizadas para o desenvolvimento e
manutenção de sistemas computadorizados, visando produzir e manter
softwares de forma padronizada e com qualidade. Ela obedece a alguns
princípios como (1) Formalidade, (2) Abstração, (3) Decomposição, (4)
Generalização e (5) Flexibilização. Assinale a alternativa que apresenta conceito
correto sobre os princípios da Engenharia de Software.
a) A flexibilização é o processo que permite que o software possa ser alterado,

sem causar problemas para sua execução.
b) A formalidade é a maneira usada para resolver um problema, de forma

genérica, com o intuito de poder reaproveitar essa solução em outras situações
semelhantes.
c) A generalização preocupa-se com a identificação de um determinado

fenômeno da realidade, sem se preocupar com detalhes, considerando apenas
os aspectos mais relevantes.
d) Pelo princípio da decomposição, o software deve ser desenvolvido de acordo

com passos definidos com precisão e seguidos de maneira efetiva.
e) A abstração é a técnica de se dividir o problema em partes, de maneira que

cada uma possa ser resolvida de uma forma mais específica.
Comentários:

16712855225

determinado fenômeno da realidade, sem se preocupar com detalhes, considerando
apenas os aspectos mais relevantes.


Conforme vimos em aula, a flexibilização é o processo que permite que o software

possa ser alterado, sem causar problemas para sua execução.
Gabarito: A
18. (CESPE – 3 – TCE/RO – Analista de Sistemas) Engenharia de software não está

relacionada somente aos processos técnicos de desenvolvimento de softwares,
mas também a atividades como gerenciamento de projeto e desenvolvimento
de ferramentas, métodos e teorias que apoiem a produção de softwares.
Comentários:

Gabarito: C
19. (CESPE – 0 – DETRAN/ES – Analista de Sistemas) Segundo princípio da

engenharia de software, os vários artefatos produzidos ao longo do seu ciclo de
vida apresentam, de forma geral, nível de abstração cada vez menor.
Comentários:
Galera, vamos pensar um pouco! A abstração é a subtração de detalhes – focar-se

16712855225
no que é mais relevante e ignorar detalhes menos relevantes. No início do ciclo de

vida, os artefatos são bastante abstratos. Temos, por exemplo, uma modelagem do
negócio, um documento de requisitos funcionais, a abstração vai diminuindo e
temos a modelagem visual de análise, depois a modelagem do projeto, até chegar
ao código-fonte e ao executável do software. Nesse ponto, temos o menor nível de
abstração (com muitos detalhes!). Compreenderam?
Gabarito: C
(CESPE – 2010 – TRE/BA – Analista de Sistemas) Entre os desafios enfrentados

pela engenharia de software estão lidar com sistemas legados, atender à

crescente diversidade e atender às exigências quanto a prazos de entrega

reduzidos.
Comentários:
Bem, essa questão é bastante intuitiva. De fato, a engenharia de software tem que
lidar com sistemas legados, atender à crescente diversidade e atender às exigências
quanto aos (curtos) prazos de entrega.
Gabarito: C
21. (FCC – 0 – DPE/SP – Analista de Sistemas) A Engenharia de Software
I. não visa o desenvolvimento de teorias e fundamentações, preocupando-se

unicamente com as práticas de desenvolvimento de software.
II. tem como foco o tratamento dos aspectos de desenvolvimento de software,

abstraindo-se dos sistemas baseados em computadores, incluindo hardware e
software.
III. tem como métodos as abordagens estruturadas para o desenvolvimento de

software que incluem os modelos de software, notações, regras e maneiras de
desenvolvimento.
IV. segue princípios, tais como, o da Abstração, que identifica os aspectos

É correto o que se afirma em: 16712855225
a) III e IV, apenas.

b) I, II, III e IV.
c) I e II, apenas.
d) I, II e III, apenas.
e) II, III e IV, apenas.
Comentários:
(I) Errado, Sommerville diz: “Computer science focuses on theory and fundamentals;
software engineering is concerned with the practicalities of developing and delivering

useful software”. No entanto, ele não diz que a engenharia de software se preocupa
(II) Errado, Pressman diz: “System engineering is concerned with all aspects of
computer-based systems development including hardware, software, and process
engineering” – a questão trata da Engenharia de Sistemas.
(III) Correto, de fato ela tem como métodos as abordagens estruturadas para o
desenvolvimento de software que incluem os modelos de software, notações, regras
e maneiras de desenvolvimento.
(IV) Errado, o princípio da abstração ignora os detalhes; e o princípio da composição

não existe – o que existe é o princípio da decomposição. E ele divide o problema
em partes menores.
Em suma, nenhuma das opções nos atende! Vocês sabem qual opção a banca
marcou como correta? A Letra D!!! E ela voltou atrás com os recursos? Não!!! Pois é,
galera! Acostumem-se com isso :(
Gabarito: D
(CESPE – 3 – TCE/RO – Analista de Sistemas) Assim como a Engenharia de

Software, existe também na área de informática a chamada Ciência da
Computação. Assinale a alternativa que melhor apresenta a diferença entre
Engenharia de Software e Ciência da Computação.
a) A Ciência da Computação tem como objetivo o desenvolvimento de teorias e

fundamentações. Já a Engenharia de Software se preocupa com as práticas de
desenvolvimento de software. 16712855225
b) A Engenharia de Software trata da criação dos sistemas de computação

(softwares) enquanto a Ciência da Computação está ligada ao desenvolvimento
e criação de componentes de hardware.
c) A Engenharia de Software trata dos sistemas com base em computadores, que

inclui hardware e software, e a Ciência da Computação trata apenas dos aspectos
de desenvolvimento de sistemas.

d) A Ciência da Computação trata dos sistemas com base em computadores,

que inclui hardware e software, e a Engenharia de Software trata apenas dos
aspectos de desenvolvimento de sistemas.
e) A Ciência da Computação destina-se ao estudo e solução para problemas

genéricos das áreas de rede e banco de dados e a Engenharia de Software
restringe- se ao desenvolvimento de sistemas.
Comentários:

que sustenta a engenharia de software é a qualida
Essa questão parece contradizer o que diz Sommerville, mas observem que não! A
Engenharia de Software coloca em prática a teoria e fundamentação trazida pela
Ciência da Computação.
Gabarito: A
(CESPE – – ANAC – Analista de Sistemas) O termo engenharia pretende

indicar que o desenvolvimento de software submete-se a leis similares às que
governam a manufatura de produtos industriais em engenharias tradicionais,
pois ambos são metodológicos.
Comentários:
16712855225
Perfeito! A Engenharia busca os princípios mais consolidados de outras engenharias

mais tradicionais – engenharia mecânica, civil, elétrica, etc.
Gabarito: C
ACERTEI ERREI

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

atravessa desde sua concepção até sua retirada de produção. Galera, não
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 diferença geralmente não é 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 próprio ciclo
de vida, mas sugere fases genéricas: Início do Projeto, Organização e Preparação,
Execução do Trabalho e Encerramento do Projeto.
16712855225
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
Definição, Desenvolvimento, Operação e Retirada como um projeto.
O Ciclo de Vida é apenas a ordem global das atividades desempenhadas não só no

desenvolvimento de software, mas também em sua evolução, manutenção e

retirada. Infelizmente não há um consenso entre os autores a respeito dos estágios,

mas é comum as seguintes fases: Definição ou Concepção, Desenvolvimento ou
Construção, Operação ou Utilização e Retirada ou Aposentadoria.
Na Definição, busca-se entender o problema a ser resolvido pelo software. No

Desenvolvimento, busca-se construir o software de acordo com uma série de
requisitos. Na Operação, ocorre a entrega, distribuição, instalação, configuração,
16712855225
utilização e manutenção do software. Por fim, na Retirada, aposenta-se o software

de vez! É isso... simples, não?! ;)

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

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

atividades, relacionamentos, artefatos, ferramentas, papéis, etc necessários para
construir, entregar, manter e evoluir um produto de software. Já o ciclo de vida de
desenvolvimento de software apresenta uma representação mais alto nível do
processo de software executado.
Galera, vocês não precisam se preocupar com isso! Nunca vi essa diferença ser
cobrada em prova. Aliás, é comum que as bancas as tratem como sinônimos.
Pessoal, coloquei na imagem abaixo os principais grupos de modelos de
desenvolvimento de software. Essa classificação não é um consenso entre os autores
e nem são mutuamente exclusivas, podendo haver combinação entre elas.
16712855225

A tabela abaixo apresenta um comparativo entre os principais modelos de processos

de desenvolvimento de software, com as principais características a serem
observadas antes de escolher o ciclo de vida adequado. Pessoal, isso é uma
orientação genérica, não é exato para todos os conceitos, mas ajuda bastante a
entendê-los. Vejamos a tabela:
GERENCIAM
MODELO FOCO REQUISITOS 1ª VERSÃO P/ CLIENTE
ENTO
Documentos e Bem conhecidos e estáticos Fim do ciclo 1

CASCATA
artefatos
INCREMENTAL
Incrementos Mais abstratos; tratados em Protótipos operacionais 3
operacionais módulos
EVOLUTIVO
Evolução dos Pouco conhecidos Protótipos operacionais 4
requisitos
Rapidez de Escopo restrito; mais Protótipos operacionais 5
RAD
desenvolvimento abstratos; tratado em módulos
PROTOTIPAGEM
Dúvidas nos Mais abstratos Protótipos não 5
requisitos operacionais
ESPIRAL
Análise Mais abstratos; evoluídos com o Protótipos operacionais 5
de Risco tempo ou não operacionais
RUP
Frameworks e Mais abstratos; evoluídos com o Protótipos operacionais 5
boas práticas tempo ou não operacionais
A última coluna, referente ao gerenciamento, revela em uma escala de 1 a 5 a

dificuldade de gerenciamento de cada processo (sendo 1 mais simples e 5 mais
complexo). O que diferencia um processo de software de outro é a ordem em que
as fases vão 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

16712855225
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 prejuízos no andamento do projeto.

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

complexo o projeto de software, mais simples deve ser o modelo de processo a
ser adotado.
Comentários:
Galera, não existe essa relação! Em geral, quanto mais complexo o projeto mais
complexo o modelo. No entanto, isso também não é 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 visão, não são
consideradas as atividades necessárias e o relacionamento entre elas.
Comentários:
Pelo contrário, o alvo do software serve para delimitar o modelo de ciclo de vida a
ser escolhido. Ademais, são consideradas as atividades necessárias e o
relacionamento entre elas.
16712855225
Gabarito: E
(CESPE – – TCE/TO – Analista de Sistemas - A escolha do modelo do

ciclo de vida não depende de características específicas do projeto, pois o melhor
modelo é sempre o mais usado pela equipe do projeto.
Comentários:
Não faz o menor sentido! A escolha depende das características do projeto.
Gabarito: E

(ESAF - 2012 – CGU – Analista de Sistemas) A escolha de um modelo é

fortemente dependente das características do projeto. Os principais modelos de
ciclo de vida podem ser agrupados em três categorias principais:
a) sequenciais, cascata e evolutivos.

b) sequenciais, incrementais e ágeis.
c) sequenciais, incrementais e evolutivos.
d) sequenciais, ágeis e cascata.
e) cascata, ágeis e evolutivos.
Comentários:
16712855225
Conforme vimos em aula, basta ver imagem: Sequencial, Incremental e Evolutivo.

Galera, ágil é metodologia e, não, ciclo de vida.
Gabarito: C
ACERTEI ERREI

MODELO EM CASCATA
Citado inicialmente em 1970 por W. Royce, também designado Cascata ou Clássico

ou Sequencial ou Linear ou Tradicional ou Waterfall ou Rígido ou Monolítico (todos
esses nomes já caíram em prova!). Esse nome é devido ao encadeamento simples
de uma fase com a outra. Os estágios do modelo demonstram as principais
atividades de desenvolvimento. Observem a imagem mais abaixo!
No Modelo em Cascata, uma fase só se inicia após o término e aprovação da fase

anterior, isto é, há uma sequência de desenvolvimento do projeto. Por exemplo, a
16712855225
Fase 4 só é iniciada após o término e aprovação da Fase 3. A Fase 5 só é iniciada

após o término e aprovação da Fase 4. Mas que fases são essas? Bem, agora que
complica, porque cada autor resolve criar suas fases!
De acordo com Vasconcelos (2006), no Modelo em Cascata, o projeto segue uma

série passos ordenados, ao final de cada fase, a equipe de projeto finaliza uma
revisão. Além disso, o desenvolvimento não continua até que o cliente esteja
satisfeito com os resultados alcançados. Vocês conseguem perceber como essas
restrições engessam o desenvolvimento?

Por Por Por Pressman Por Pressman Por

Sommerville Yourdon (4ª Ed.) (6ª Ed.) Royce
Definição de Requisitos Requisitos de Modelagem e Engenharia Comunicação Elicitação de
Sistema do Sistema/Informação Requisitos
Projeto de Sistema e Requisitos de Análise de Requisitos de Planejamento Projeto
Software Software Software
Implementação e Teste Análise Projeto Modelagem Construção
de Unidade
Integração e Teste de Projeto Geração de Código
16712855225
Construção Integração
Sistema
Operação e Manutenção Codificação Teste e Manutenção Implantação Teste de
Depuração
Teste Instalação
Operação Manutenção de
Software
Percebam que há diferenças gritantes entre os autores! Inclusive, há divergências

até entre autor e ele mesmo, dependendo da versão do livro (Exemplo: Pressman
mudou as fases na última edição de seu livro). Professor, você já viu isso cair em

prova? Sim, já vi! E o que aconteceu? Bem, polêmica, recursos, etc! Não há o que
fazer... minha classificação preferida é a do Yourdon.
Na prática, esses estágios não são completamente sequenciais, i.e., eles se

sobrepõem e trocam informações entre si. Na teoria, são fases sequenciais com o
resultado de cada fase consistindo em um ou mais documentos aprovados ou não,
dependendo dos problemas. Por exemplo: durante o projeto, são identificados
problemas com requisitos.
De modo geral, grande parte dos modelos possuem as seguintes fases:
Planejamento: faz-se o esboço do escopo e dos requisitos, além de estimativas

razoáveis sobre recursos, custos e prazos.
Análise e Especificação de Requisitos: durante essa fase, refina-se os requisitos e

o escopo e desenha-se o problema em questão.
Projeto: durante essa fase, incorpora-se requisitos tecnológicos aos requisitos

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

programas executáveis pela máquina.
Teste: o programa é testado como um sistema completo para garantir que os

requisitos de software foram atendidos.
Implantação, Operação e Manutenção: o sistema de software é liberado para o

cliente, treina-se usuários, gerencia serviços e realiza manutenções.
16712855225

Professor, o que você quer dizer com atrasar a redução de riscos? Bem, essa é uma
desvantagem recorrente em provas. Como uma fase só se inicia após o término da
fase anterior, só é possível em geral verificar se houve erros nas últimas fases – como
pode ser visto na imagem abaixo. Em outros modelos, os riscos são reduzidos desde
as primeiras fases do processo de desenvolvimento.
Percebam que os riscos deveriam ser descobertos logo no início do processo de

desenvolvimento, porém eles são descobertos somente após o início dos testes e
integração. Vocês podem notar que, nesse instante (parte vermelha), o progresso
do projeto avança e retrai diversas vezes, porque o sistema está sendo corrigido
devido a requisitos modificados.
Vejam, também, que o projeto não terminou em seu deadline original. Como a
redução dos riscos atrasou, todo andamento do projeto também atrasou. Dessa
forma, não se cumpriu nem o prazo do projeto e, provavelmente, nem o orçamento
e talvez seu escopo – tendo em vista que, quanto mais ao fim do projeto um erro é
identificado, mais caras se tornam as modificações.
Entenderam essa parte direitinho? Um erro na fase de requisitos, por exemplo, que
não foi corrigido e foi descoberto no final do processo de desenvolvimento, terá um
custo de correção altíssimo, visto que provavelmente terá que se refazer tudo
novamente. Ora, se eu peço a construção de um carro e você constrói uma moto,
o custo para corrigir esse erro será altíssimo.
16712855225

Portanto não confundam essas duas coisas: o erro ocorreu no início e foi
identificado no início, terá baixo custo de correçã se o erro ocorreu no início e foi
identificado no final, terá alto custo de correção. O custo de correção 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 gráfico Risco x Tempo,

comparando o modelo em cascata com o Modelo Iterativo e Incremental. Observem
que o Modelo Iterativo e Incremental já começa a reduzir os riscos desde o início
do processo, em contraste com o Modelo em Cascata que acumula os riscos até a
fase de testes, integração e implantação do sistema.
Galera, a grande vantagem do Modelo em Cascata é que o desenvolvimento é

dividido em fases distintas, padronizadas, etc (antigamente, os softwares eram
construídos artesanalmente). É possível colocar pessoas com perfis específicos para
cada fase, i.e., quem tem facilidade de se comunicar vai ser analista de requisitos,
programadores vão fazer a codificação, etc.
A grande desvantagem é que - em projetos complexos – demora-se muito para

chegar até a fase de testes, sendo que o cliente não vê nada rodando até a
implantação. Então, pode acontecer de, nas fases finais, os requisitos da organização
não serem mais os mesmos daqueles do início e o software não ter mais utilidade
para organização.
Professor, então o Modelo em Cascata não deve ser usado em nenhuma hipótese?
Calma lá, ele pode ser usado! No entanto, sua utilização deve ocorrer
preferencialmente quando os requisitos forem bem compreendidos e houver pouca
probabilidade de mudanças radicais durante o desenvolvimento do sistema. Vocês
16712855225
entenderam?
VANTAGENS DESVANTAGENS
É simples de entender e fácil de aplicar, Divisão inflexível do projeto em estágios

facilitando o planejamento. distintos.
Fixa pontos específicos para a entrega de Dificuldade em incorporar mudanças de
artefatos. requisitos.

Funciona bem para equipes tecnicamente Clientes só visualizam resultados próximos

fracas. ao final do projeto.
É fácil de gerenciar, devido a sua rigidez. Atrasa a redução de riscos.
Realiza documentação extensa por cada Apenas a fase final produz um artefato de
fase ou estágio. software entregável.
Possibilita boa aderência a outros modelos Cliente deve saber todos os requisitos no
de processo. início do projeto.
Funciona bem com projetos pequenos e Modelo inicial (Royce) não permitia
com requisitos bem conhecidos. feedback entre as fases do projeto.
Pressupõe que os requisitos ficarão
estáveis ao longo do tempo.
Não funciona bem com projetos complexos
e OO, apesar de compatível.
Podemos afirmar, então, que o Modelo em Cascata é considerado um método

tradicional e fortemente prescritivo, i.e., ele busca sempre dizer o que fazer, em
geral, por meio de planos definidos no início do projeto. Que planos, professor?
Escopo, custo, cronograma... tudo isso bem detalhado em uma extensa
documentação. Mudanças são bem-vindas? Claro que não!
ESQUEMA
16712855225

(FCC - 2012 - - - Analista Judiciário - Análise 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.
Comentários:

esses nomes já caíram em prova!). Esse nome é devido ao encadeamento simples de
uma fase com a outra. Os estágios do modelo demonstram as principais atividades
de desenvolvimento. Observem a imagem mais abaixo!
Mais recente? Não, muito antigo! Complexo? Não, possui um encadeamento simples
de fases.
Gabarito: E
(FCC - - SEFAZ- - Agente Fiscal de Rendas - Tecnologia da Informação

- Prova 3 - O processo de engenharia de software denominado ciclo de vida
clássico refere-se ao modelo incremental.
Comentários:
16712855225

Não, modelo clássico se refere a modelo em cascata, sequencial, linear, tradicional,

waterfall, rígido ou monolítico.
Gabarito: E

(CESPE – – INMETRO – Analista de Sistemas) Em uma empresa que tenha

adotado um processo de desenvolvimento de software em cascata, falhas no
levantamento de requisitos têm maior possibilidade de gerar grandes prejuízos
do que naquelas que tenham adotado desenvolvimento evolucionário.
Comentários:

Funciona bem com projetos pequenos e Não fornece feedback entre as fases.
com requisitos bem conhecidos.
16712855225

O Modelo em Cascata, de fato, não reage bem a mudanças. Já Modelo

evolucionário é mais adaptável a mudanças por se utilizar de iterações.
Gabarito: C
(CESPE – 2011 – MEC – Analista de Sistemas) O modelo Waterfall tem a vantagem

de facilitar a realização de mudanças sem a necessidade de retrabalho em fases
já completadas.

Comentários:

Pelo contrário, há dificuldade de lidar com requisitos voláteis, tendo em vista que
dependendo do erro, é necessário refazê-lo desde seu início.
16712855225
Gabarito: E
(CESPE – 2008 – TST – Analista de Sistemas) No modelo de desenvolvimento

sequencial linear, a fase de codificação é a que gera erros de maior custo de
correção.
Comentários:

Entenderam essa parte direitinho? Um erro na fase de requisitos, por exemplo, que
não foi corrigido e foi descoberto no final do processo de desenvolvimento, terá um
custo de correção altíssimo, visto que provavelmente terá que se refazer tudo
novamente. Ora, se eu peço a construção de um carro e você constrói uma moto, o
custo para corrigir esse erro será altíssimo.
Portanto não confundam essas duas coisas! Percebam o que eu disse: quanto mais
tarde se descobre um erro, mais caro se torna sua correção. Dizendo isso de outra
forma: erros nas fases iniciais possuem custo de correção altíssimo. 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 correção mais altos. Logo,
o maior custo está na fase de codificação? Não, 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 são realizados todos em um
mesmo estágio, que acontece após a finalização das fases de implementação.
Comentários:

Definição de Requisitos Requisitos de Modelagem e Engenharia do Comunicação Elicitação de
Sistema Sistema/Informação Requisitos
16712855225
Implementação e Teste de Análise Projeto Modelagem Construção

Unidade
Integração e Teste de Projeto Geração de Código Construção Integração
Sistema
Depuração
Teste Instalação
Software
Todos em um mesmo estágio, não. A grande maioria dos testes ocorrem, de fato,
após a finalização das fases de implementação. No entanto, podem ocorrer testes
unitários durante a própria implementação, como mostra o quadro acima.

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

de fases e atividades que devem ser realizadas em sequência, de forma que uma
atividade é requisito da outra.
Comentários:

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

término e aprovação 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 implementação.
Comentários:
Não! Ele não descreve ciclos, muito menos ciclos iterativos. Na verdade, essa é a
definição de Modelo Iterativo e Incremental.
16712855225
Gabarito: E
(CESPE – 2004 – STJ – Analista de Sistemas) O modelo de desenvolvimento

seqüencial linear, também chamado modelo clássico ou modelo em cascata,
caracteriza-se por não acomodar adequadamente as incertezas que existem no
início de um projeto de software, em especial as geradas pela dificuldade do
cliente de explicitar todos os requerimentos que o programa deve contemplar.
Comentários:

Professor, o que você quer dizer com atrasar a redução de riscos? Bem, essa é uma
desvantagem recorrente em provas. Como uma fase só se inicia após o término da
fase anterior, só é possível em geral verificar se houve erros nas últimas fases – como
pode ser visto na imagem abaixo. Em outros modelos, os riscos são reduzidos desde
as primeiras fases do processo de desenvolvimento.
Perfeito, lembrem-se que ele acumula riscos e não lida bem com requisitos voláteis.
Gabarito: C
10. (CESPE – – IPEA – Analista de Sistema) No modelo em cascata de processo

de desenvolvimento, os clientes devem definir os requisitos apenas durante a
fase de projeto; e os projetistas definem as estratégias de projeto apenas durante
a fase de implementação. As fases do ciclo de vida envolvem definição de
requisitos, projeto, implementação, teste, integração, operação e manutenção.
Em cada fase do ciclo de vida, podem ser produzidos diversos artefatos.
Comentários:
Essa questão não faz sentido! Os clientes definem os requisitos durante a fase de
Definição de Requisitos. Já os projetistas definem as estratégias de projeto apenas
durante a fase Projeto.
Gabarito: E
11. (CESPE – 2008 – TCE/TO – Analista de Sistema – No ciclo de vida em cascata,

é possível realizar alternadamente e simultaneamente as atividades de
desenvolvimento de software.
16712855225
Comentários:

Não, é sequencial e linear. Não pode ser alternado e simultâneo!
Gabarito: E

12. (CESPE – 2004 – TJ/PA – Analista de Sistema – A abordagem sistemática

estritamente linear para o desenvolvimento de software é denominada modelo
em cascata ou modelo sequencial linear.
Comentários:

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 definição dos requisitos
antes do restante do desenvolvimento do sistema. Após a especificação e a
análise dos requisitos, têm-se o projeto, a implementação e o teste.
Comentários:

16712855225

Unidade
Sistema
Depuração
Teste Instalação
Software
Perfeito! De fato, segue essa ordem!

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

software, o modelo em cascata é estruturado de tal maneira que as fases que
compõem o desenvolvimento são interligadas. Nessa situação, o final de uma
fase implica o início de outra.
Comentários:

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

segue uma série de passos ordenados. Ao final de cada projeto, a equipe de
projeto finaliza uma revisão. O desenvolvimento continua e, ao final, o cliente
avalia a solução proposta.
Comentários:
De acordo com Vasconcelos (2006), no Modelo em Cascata, o projeto segue uma

série passos ordenados, ao final de cada fase, a equipe de projeto finaliza uma
revisão. Além disso, o desenvolvimento não continua até que o cliente esteja satisfeito
16712855225
com os resultados alcançados. Vocês conseguem perceber como essas restrições

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

apropriado para software em que os requisitos ainda não foram bem
compreendidos, pois é focado na criação de incrementos.

Comentários:
Professor, então o Modelo em Cascata não deve ser usado em nenhuma hipótese?
Calma lá, ele pode ser usado! No entanto, sua utilização deve ocorrer
preferencialmente quando os requisitos forem bem compreendidos e houver pouca
probabilidade de mudanças radicais durante o desenvolvimento do sistema. Vocês
entenderam?
Pelo contrário, totalmente errado!
Gabarito: E
17. (CESPE – 2009 – UNIPAMPA – Analista de Sistema – O modelo em cascata

sugere uma abordagem sistemática e sequencial para o desenvolvimento de
software. Sua natureza linear leva a estados de bloqueio nos quais, para que
nova etapa seja iniciada, é necessário que a documentação associada à fase
anterior tenha sido aprovada.
Comentários:

Perfeito! Não basta terminar uma fase, é necessário que a sua documentação tenha
sido aprovada.
16712855225
Gabarito: C
18. (CESPE – 2004 – ABIN – Analista de Sistema) O modelo de desenvolvimento

seqüencial linear, também denominado modelo em cascata, é incompatível com
o emprego de técnica de análise orientada a objetos no desenvolvimento de um
sistema de informação.
Comentários:


Não funciona bem com projetos
complexos e OO, apesar de compatível.
Ele é compatível, mas não é recomendado! Por que, não? Imagina um projeto super
complexo que utiliza uma análise orientada a objetos (que é um modelo mais
sofisticado que a análise estruturada). Lembre-se que, no Modelo em Cascata, você
não pode errar, porque se você errar, os riscos de o projeto falhar são enormes! Por
essa razão, ele não é recomendável, apesar de compatível!
16712855225
Gabarito: E
19. (CESPE – 2004 – TRE/AL – Analista de Sistema) O modelo cascata ou ciclo de

vida clássico necessita de uma abordagem sistemática, que envolve, em primeiro
lugar, o projeto e, em seguida, a análise, a codificação, os testes e a manutenção.
Comentários:


Unidade
Sistema
Depuração
Teste Instalação
Software
Primeiro Projeto e depois Análise? Não, Análise vem antes do Projeto!
Gabarito: E
(CESPE – – MPE/AM – Analista de Sistema) O modelo de desenvolvimento

seqüencial linear tem como característica principal a produção de uma versão
básica, mas funcional, do software desde as primeiras fases.
Comentários:

Fixa pontos específicos para a entrega de 16712855225
Dificuldade em incorporar mudanças de
Funciona bem para equipes tecnicamente Clientes só visualizam resultados
fracas. próximos ao final do projeto.
Realiza documentação extensa por cada Apenas a fase final produz um artefato
fase ou estágio. de software entregável.

Pelo contrário, somente nas fases finais que se tem uma versão! Essa definição está
mais com cara de modelo de desenvolvimento em prototipagem.
Gabarito: E
21. (VUNESP - 2012 - SPTrans - Analista de Informática) Uma das abordagens do

processo de desenvolvimento da engenharia de software prevê a divisão em
etapas, em que o fim de uma é a entrada para a próxima. Esse processo é
conhecido como modelo:
a) Transformação.
b) Incremental.
c) Evolutivo.
d) Espiral.
e) Cascata.
Comentários:

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

Negócio) No Ciclo de Vida Clássico, também chamado de Modelo Sequencial
Linear ou Modelo Cascata, é apresentada uma abordagem sistemática composta
pelas seguintes atividades:

a) Análise de Requisitos de Software, Projeto, Geração de Código, Teste e

Manutenção.
b) Modelagem e Engenharia do Sistema/Informação, Análise de Requisitos de

Software, Projeto, Geração de Código, Teste e Manutenção.
c) Modelagem e Engenharia do Sistema/Informação, Projeto, Geração de

Código, Teste e Manutenção.
d) Levantamento de Requisitos de Software, Projeto, Geração de Código e

Manutenção e Análise de Requisitos de Software.
e) Levantamento de Requisitos de Software, Projeto, Geração de Código, Teste

Progressivo e Manutenção.
Comentários:

Unidade
Sistema
Depuração
Teste Instalação
16712855225
Software
A Letra B está correta de acordo com o Pressman 4ª Edição, mas está errada de
acordo com o Pressman 6ª Edição. Ademais, na questão ele sequer disse que era
de acordo com o Pressman. Portanto, percebam que é um assunto polêmico e que
as bancas deveriam ignorar, mas eventualmente elas cobram mesmo assim.
Gabarito: B
ACERTEI ERREI

LISTA DE EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

CONCEITOS BÁSICOS DE ENGENHARIA DE SOFTWARE
(CESPE - 2013 - TRT - 10ª REGIÃO (DF e TO) - Analista Judiciário - Tecnologia da
Informação A engenharia de software engloba processos, métodos e
ferramentas. Um de seus focos é a produção de software de alta qualidade a
custos adequados.
(FCC - 2012 - TST - Analista Judiciário - Análise de Sistemas A Engenharia de

Software:
a) é uma área da computação que visa abordar de modo sistemático as questões

técnicas e não técnicas no projeto, implantação, operação e manutenção no
desenvolvimento de um software.
b) consiste em uma disciplina da computação que aborda assuntos relacionados

a técnicas para a otimização de algoritmos e elaboração de ambientes de
desenvolvimento.
c) trata-se de um ramo da TI que discute os aspectos técnicos e empíricos nos

processos de desenvolvimento de sistemas, tal como a definição de artefatos
para a modelagem ágil.
d) envolve um conjunto de itens que abordam os aspectos de análise de

mercado, concepção e projeto de software, sendo independente da engenharia
de um sistema.
16712855225
e) agrupa as melhores práticas para o concepção, projeto, operação e

manutenção de artefatos que suportam a execução de programas de
computador, tais como as técnicas de armazenamento e as estruturas em
memória principal.
(FCC - 2012 - TRT - 6ª Região (PE) - Técnico Judiciário - Tecnologia da

Informação) Considere: é uma disciplina que se ocupa de todos os aspectos da
manutenção desse sistema, depois que ele entrou em operação. Seu principal
objetivo é fornecer uma estrutura metodológica para a construção de software
com alta qualidade. A definição refere-se:

a) ao ciclo de vida do software.

b) à programação orientada a objetos.
c) à análise 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 produção de software, abrange somente os
processos técnicos 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 são:
a) métodos, processo e teste.

b) ferramentas, métodos e processo.
c) métodos, construção, teste e implantação.
d) planejamento, modelagem, construção, validação e implantação.
e) comunicação, planejamento, modelagem, construção e implantação.
(CESPE - 2010 - Banco da Amazônia - Técnico Científico - Tecnologia da

Informação Os princípios de engenharia de software definem a necessidade de
formalidades para reduzir inconsistências e a decomposição para lidar com a
complexidade.
(FCC - 2010 - TRE- - Analista Judiciário - Tecnologia da Informação - A A

16712855225
Engenharia de Software:
a) não tem como método a abordagem estruturada para o desenvolvimento de

software, pois baseia-se exclusivamente nos modelos de software, notações,
regras e técnicas de desenvolvimento.
b) se confunde com a Ciência da Computação quando ambas tratam do

desenvolvimento de teorias, fundamentações e práticas de desenvolvimento de
software.

c) tendo como foco apenas o tratamento dos aspectos de construção 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 sistemática de

desenvolvimento, através de ferramentas e técnicas apropriadas, dependendo
do problema a ser abordado, considerando restrições e recursos disponíveis.
e) segue princípios, tais como, o da Abstração, que identifica os aspectos

(FCC - 2011 - INFRAERO - Analista de Sistemas - Gestão de TI Em relação à

Engenharia de Software, é INCORRETO afirmar:
a) O design de software, ao descrever os diversos aspectos que estarão presentes

no sistema quando construído, permite que se faça a avaliação prévia para
garantir que ele alcance os objetivos propostos pelos interessados.
b) A representação de um design de software mais simples para representar

apenas as suas características essenciais busca atender ao princípio da abstração.
c) Iniciar a entrevista para obtenção dos requisitos de software com perguntas

mais genéricas e finalizar com perguntas mais específicas sobre o sistema é o
que caracteriza a técnica 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.
16712855225
e) A representação é a linguagem do design, cujo único propósito é descrever

um sistema de software que seja possível construir.
(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.

10. (CESPE – 2015 – STJ – Analista de Sistemas) Embora os engenheiros de software

geralmente utilizem uma abordagem sistemática, a abordagem criativa e menos
formal pode ser eficiente em algumas circunstâncias, como, por exemplo, para
o desenvolvimento de sistemas web, que requerem uma mistura de habilidades
de software e de projeto.
11. (CESPE – 2015 – STJ – Analista de Sistemas) O foco da engenharia de software

inclui especificação do sistema, desenvolvimento de hardware, elaboração do
projeto de componentes de hardware e software, definição dos processos e
implantação do sistema.
12. (CESPE – 2011 – MEC – Analista de Sistemas) O processo de desenvolvimento de

software é uma caracterização descritiva ou prescritiva de como um produto de
software deve ser desenvolvido.
13. (CESPE – 2013 – TRT/10ª – Analista de Sistemas) As atividades fundamentais

relacionadas ao processo de construção de um software incluem a especificação,
o desenvolvimento, a validação e a evolução do software.
14. (CESPE – 2010 – TRE/BA – Analista de Sistemas) Um modelo de processo de

software consiste em uma representação complexa de um processo de software,
15. (CESPE – 1 – MEC – Analista de Sistemas) Atividades comuns a todos os

processos de software incluem a especificação, o projeto, a implementação e a
validação.
16. (CESPE – 2015 – STJ – Analista de Sistemas) As principais atividades de

16712855225
engenharia de software são especificação, desenvolvimento, validação e

evolução.
17. (FUNIVERSA – – IPHAN – Analista de Sistemas) A Engenharia de Software

resume-se em um conjunto de técnicas utilizadas para o desenvolvimento e
manutenção de sistemas computadorizados, visando produzir e manter
softwares de forma padronizada e com qualidade. Ela obedece a alguns
princípios como (1) Formalidade, (2) Abstração, (3) Decomposição, (4)
Generalização e (5) Flexibilização. Assinale a alternativa que apresenta conceito
correto sobre os princípios da Engenharia de Software.

a) A flexibilização é o processo que permite que o software possa ser alterado,

sem causar problemas para sua execução.
b) A formalidade é a maneira usada para resolver um problema, de forma

genérica, com o intuito de poder reaproveitar essa solução em outras situações
semelhantes.
c) A generalização preocupa-se com a identificação de um determinado

fenômeno da realidade, sem se preocupar com detalhes, considerando apenas
os aspectos mais relevantes.
d) Pelo princípio da decomposição, o software deve ser desenvolvido de acordo

com passos definidos com precisão e seguidos de maneira efetiva.
e) A abstração é a técnica de se dividir o problema em partes, de maneira que

cada uma possa ser resolvida de uma forma mais específica.
18. (CESPE – 2013 – TCE/RO – Analista de Sistemas) Engenharia de software não está
relacionada somente aos processos técnicos de desenvolvimento de softwares,
mas também a atividades como gerenciamento de projeto e desenvolvimento
de ferramentas, métodos e teorias que apoiem a produção de softwares.
19. (CESPE – 0 – DETRAN/ES – Analista de Sistemas) Segundo princípio da

engenharia de software, os vários artefatos produzidos ao longo do seu ciclo de
vida apresentam, de forma geral, nível de abstração cada vez menor.
(CESPE – 2010 – TRE/BA – Analista de Sistemas) Entre os desafios enfrentados

pela engenharia de software estão lidar com sistemas legados, atender à
crescente diversidade e atender às exigências quanto a prazos de entrega
16712855225
reduzidos.
21. (FCC – 0 – DPE/SP – Analista de Sistemas) A Engenharia de Software
I. não visa o desenvolvimento de teorias e fundamentações, preocupando-se

II. tem como foco o tratamento dos aspectos de desenvolvimento de software,

abstraindo-se dos sistemas baseados em computadores, incluindo hardware e
software.

III. tem como métodos as abordagens estruturadas para o desenvolvimento de

software que incluem os modelos de software, notações, regras e maneiras de
desenvolvimento.
IV. segue princípios, tais como, o da Abstração, que identifica os aspectos

É correto o que se afirma em:
a) III e IV, apenas.

b) I, II, III e IV.
c) I e II, apenas.
d) I, II e III, apenas.
e) II, III e IV, apenas.
(CESPE – 3 – TCE/RO – Analista de Sistemas Assim como a Engenharia de

Software, existe também na área de informática a chamada Ciência da
Computação. Assinale a alternativa que melhor apresenta a diferença entre
Engenharia de Software e Ciência da Computação.
a) A Ciência da Computação tem como objetivo o desenvolvimento de teorias e

fundamentações. Já a Engenharia de Software se preocupa com as práticas de
b) A Engenharia de Software trata da criação dos sistemas de computação

(softwares) enquanto a Ciência da Computação está ligada ao desenvolvimento
e criação de componentes de hardware.
16712855225
c) A Engenharia de Software trata dos sistemas com base em computadores, que

inclui hardware e software, e a Ciência da Computação trata apenas dos aspectos
de desenvolvimento de sistemas.
d) A Ciência da Computação trata dos sistemas com base em computadores,

que inclui hardware e software, e a Engenharia de Software trata apenas dos
aspectos de desenvolvimento de sistemas.
e) A Ciência da Computação destina-se ao estudo e solução para problemas

genéricos das áreas de rede e banco de dados e a Engenharia de Software
restringe- se ao desenvolvimento de sistemas.

(CESPE – – ANAC – Analista de Sistemas) O termo engenharia pretende

indicar que o desenvolvimento de software submete-se a leis similares às que
governam a manufatura de produtos industriais em engenharias tradicionais,
pois ambos são metodológicos.
16712855225


(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 visão, não são
consideradas as atividades necessárias e o relacionamento entre elas.
(CESPE – – TCE/TO – Analista de Sistemas - A escolha do modelo do

ciclo de vida não depende de características específicas do projeto, pois o melhor
modelo é sempre o mais usado pela equipe do projeto.
(ESAF - 2012 – CGU – Analista de Sistemas) A escolha de um modelo é

fortemente dependente das características do projeto. Os principais modelos de
ciclo de vida podem ser agrupados em três categorias principais:
a) sequenciais, cascata e evolutivos.

b) sequenciais, incrementais e ágeis.
c) sequenciais, incrementais e evolutivos.
d) sequenciais, ágeis e cascata.
e) cascata, ágeis e evolutivos.
16712855225


MODELO EM CASCATA
(FCC - 2012 - - - Analista Judiciário - Análise 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 Informação

- Prova 3 - O processo de engenharia de software denominado ciclo de vida
clássico 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 têm maior possibilidade de gerar grandes prejuízos
do que naquelas que tenham adotado desenvolvimento evolucionário.
ESPE – 2011 – MEC – Analista de Sistemas) O modelo Waterfall tem a vantagem

de facilitar a realização de mudanças sem a necessidade de retrabalho em fases
já completadas.
(CESPE – 2008 – TST – Analista de Sistemas) No modelo de desenvolvimento

sequencial linear, a fase de codificação é a que gera erros de maior custo de
correção.
(CESPE – – INMETRO – Analista de Sistemas) Em um processo de

desenvolvimento em cascata, os testes de software são realizados todos em um
mesmo estágio, que acontece após a finalização das fases de implementação.
16712855225
(CESPE – 2008 – SERPRO – Analista de Sistemas) O modelo em cascata consiste

de fases e atividades que devem ser realizadas em sequência, 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 implementação.
(CESPE – 2004 – STJ – Analista de Sistemas) O modelo de desenvolvimento

seqüencial linear, também chamado modelo clássico ou modelo em cascata,

caracteriza-se por não acomodar adequadamente as incertezas que existem no

início 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 estratégias de projeto apenas durante
a fase de implementação. As fases do ciclo de vida envolvem definição de
requisitos, projeto, implementação, teste, integração, operação e manutenção.
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,

é possível realizar alternadamente e simultaneamente as atividades de
12. (CESPE – 2004 – TJ/PA – Analista de Sistema – A abordagem sistemática

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 definição dos requisitos
antes do restante do desenvolvimento do sistema. Após a especificação e a
análise dos requisitos, têm-se o projeto, a implementação e o teste.
14. (CESPE – – INMTRO – Analista de Sistema) No desenvolvimento de

software, o modelo em cascata é estruturado de tal maneira que as fases que
compõem o desenvolvimento são interligadas. Nessa situação, o final de uma
fase implica o início de outra.
16712855225
15. (CESPE – 2010 – BASA – Analista de Sistema) No modelo em cascata, o projeto

segue uma série de passos ordenados. Ao final de cada projeto, a equipe de
projeto finaliza uma revisão. O desenvolvimento continua e, ao final, o cliente
avalia a solução proposta.
16. (CESPE – – TRE/MT – Analista de Sistema - O modelo em cascata é

apropriado para software em que os requisitos ainda não foram bem
compreendidos, pois é focado na criação de incrementos.
17. (CESPE – 2009 – UNIPAMPA – Analista de Sistema – O modelo em cascata

sugere uma abordagem sistemática e sequencial para o desenvolvimento de

software. Sua natureza linear leva a estados de bloqueio nos quais, para que
nova etapa seja iniciada, é necessário que a documentação associada à fase
anterior tenha sido aprovada.
18. (CESPE – 2004 – ABIN – Analista de Sistema) O modelo de desenvolvimento

seqüencial linear, também denominado modelo em cascata, é incompatível com
o emprego de técnica de análise orientada a objetos no desenvolvimento de um
sistema de informação.
19. (CESPE – 2004 – TRE/AL – Analista de Sistema) O modelo cascata ou ciclo de

vida clássico necessita de uma abordagem sistemática, que envolve, em primeiro
lugar, o projeto e, em seguida, a análise, a codificação, os testes e a manutenção.
(CESPE – – MPE/AM – Analista de Sistema) O modelo de desenvolvimento

seqüencial linear tem como característica principal a produção de uma versão
básica, mas funcional, do software desde as primeiras fases.
21. (VUNESP - 2012 - SPTrans - Analista de Informática) Uma das abordagens do

processo de desenvolvimento da engenharia de software prevê a divisão em
etapas, em que o fim de uma é a entrada para a próxima. Esse processo é
conhecido como modelo:
a) Transformação.
b) Incremental.
c) Evolutivo.
d) Espiral.
e) Cascata.
(CESGRANRIO – 2010 – PETROBRÁS – Analista de Sistemas – Processos de

16712855225
Negócio) No Ciclo de Vida Clássico, também chamado de Modelo Sequencial

Linear ou Modelo Cascata, é apresentada uma abordagem sistemática composta
pelas seguintes atividades:
a) Análise de Requisitos de Software, Projeto, Geração de Código, Teste e

Manutenção.
b) Modelagem e Engenharia do Sistema/Informação, Análise de Requisitos de

Software, Projeto, Geração de Código, Teste e Manutenção.

c) Modelagem e Engenharia do Sistema/Informação, Projeto, Geração de

Código, Teste e Manutenção.
d) Levantamento de Requisitos de Software, Projeto, Geração de Código e

Manutenção e Análise de Requisitos de Software.
e) Levantamento de Requisitos de Software, Projeto, Geração de Código, Teste

Progressivo e Manutenção.
16712855225

GABARITO DOS EXERCÍCIOS COMENTADOS (DIVERSAS BANCAS)

CONCEITOS BÁSICOS DE ENGENHARIA DE SOFTWARE
1 2 3 4 5 6 7 8 9 10
C A E E B C D E A C
11 12 13 14 15 16 17 18 19 20
E C C E C C A C C C
21 22 23 24 25 26 27 28 29 30
D A C

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

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

Aula 00: Engenharia de Software para Concursos - Curso Regular

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 00: Engenharia de Software para Concursos - Curso Regular

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Aula 00: Engenharia de Software para Concursos - Curso Regular

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 00

Engenharia de Software para Concursos - Curso Regular

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 1 de 68

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

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 2 de 68

Olá, pessoal. Sejam bem-vindos ao Curso Regular de Engenharia de Software!

DÚVIDAS DOS ALUNOS

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 3 de 68

Uma breve apresentação: meu nome é Diego Carvalho, bacharel em Ciência da

ÁREA ÓRGÃOS PARA OS QUAIS JÁ MINISTREI CURSOS

Agência ANCINE ANTAQ ANATEL

Jurídica TRT/1 TRT/2 TRT/3 TRT/4

Outros CEF DATAPREV DEPEN INMETRO

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 4 de 68

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 5 de 68

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 6 de 68

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 7 de 68

Antes de começar o curso, vamos alinhar algumas expectativas! O curso que eu

Portanto, vou direcioná-los pelo conteúdo da melhor maneira possível. O nosso

6º Lugar – ISS/Salvador 16712855225

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 8 de 68

Aula Data Tópicos do Edital

01 01/04 Modelo Orientado a Reuso. Modelo em Prototipagem, Modelo

02 15/04 Processo Unificado: Conceitos Básicos, Dimensões Dinâmica, Estática e

04 15/05 Definição de Requisito, Classificação de Requisitos (Funcional, Não-

Viabilidade, Elicitação e Análise de Requisitos, Especificação de

05 01/06 Linguagem de Modelagem: Unified Modeling Language (UML) 2.x –

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 9 de 68

06 15/06 Conceitos Básicos do Paradigma Estruturado. Conceitos Básicos de

07 01/07 Análise de Pontos de Função: IFPUG – Definição e Contexto, Benefícios

08 15/07 Qualidade de Software: Garantia e Controle, Principais Características,

09 01/08 Arquitetura de Software. Arquitetura em Camadas (Cliente/Servidor).

10 15/08 Arquitetura Orientada a Serviços (SOA): Conceitos Básicos, SOAP,

WSDL, UDDI. REST. WS-Security.

11 01/09 Interoperabilidade de Sistemas. e- PING: Conceitos Básicos,

12 15/09 Engenharia de Usabilidade. Gerenciamento Eletrônico de Documentos

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 10 de 68

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 11 de 68

ENGENHARIA DE SOFTWARE: CONCEITOS GERAIS

A IEEE define engenharia de software como a aplicação de uma abordagem

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

Sommerville define processo de software como a abordagem sistemática usada pela

engenharia de software para produção de software. Pode-se identificar as seguintes

De acordo com Pressman: “A Engenharia de Software ocorre como consequência de

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 12 de 68

Ademais, nosso renomadíssimo autor afirma que a engenharia de sistemas está

A Engenharia de Software tem por objetivos a aplicação de teoria, modelos,

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

Aliás, nosso outro renomadíssimo autor (Sommerville) afirma que: “A engenharia de

de software, mas também com atividades como o gerenciamento de projeto de

A Engenharia de Software surgiu em meados da década de sessenta como uma

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 13 de 68

Já na década de oitenta, surgiu a Análise Estruturada e algumas Ferramentas CASE

A Engenharia de Software possui alguns princípios, tais como: Formalidade, em que

Há a Decomposição, em que se divide o problema em partes, de maneira que cada

Certa vez, um aluno me perguntou: professor, como a formalidade pode reduzir

Bem, galera... a Engenharia de Software se divide em algumas disciplinas genéricas

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 14 de 68

e Manutenção de Software. Pessoal, essas disciplinas e seus nomes são bem