📘 Guia Mestre: Engenharia de Software
(Prof. Jadir)
Foco: A1 - UNICID | ADS
1. O "Jeito" de Fazer Software (Ciclo de Vida)
Pense nisso como estratégia para construir uma casa. Existem dois jeitos
principais que o Jadir adora comparar:
A. Modelo Cascata (Waterfall) 🌊
● O Jeito Antigo: Imagine uma cachoeira. A água só cai, nunca sobe de
volta.
● Como funciona: Você faz tudo sequencialmente. Primeiro planeja
TUDO, depois desenha TUDO, depois coda TUDO, e só no final o
cliente vê.
● A Pegadinha: Se o cliente disser "não gostei" no final, você tem que
destruir a casa e começar do zero.
● Palavras-Chave para a Prova: Rígido, Sequencial, Documentação
pesada, Difícil de mudar.
● Quando usar? Só quando você tem 100% de certeza do que vai fazer
(ex: software de uma máquina hospitalar).
B. Métodos Ágeis (SCRUM) 🏃
● O Jeito Moderno: Imagine cozinhar experimentando o molho a cada 5
minutos.
● Como funciona: Você divide o projeto em pedacinhos (Sprints). A
cada 2 ou 3 semanas, você entrega uma parte funcionando para o
cliente ver.
● A Vantagem: Se o cliente mudar de ideia, você ajusta rápido.
● Palavras-Chave para a Prova: Iterativo (repete), Incremental (cresce
aos poucos), Aceita mudanças, Cliente participa.
2. Requisitos: O que o cliente quer?
Aqui é onde você define o jogo. Lembre-se da regra: Funcional é VERBO,
Não-Funcional é ADJETIVO.
Tipo A Exemplo (Analogia Na Prova
Pergunta do Carro) (Software)
Mágica
Funcional O que ele O carro deve andar. O sistema deve
(RF) faz? O carro deve frear. cadastrar
clientes.
O sistema deve
emitir nota.
Não-Funcio Como ele O carro deve ser O sistema deve
nal (RNF) é? rápido. O carro deve rodar em
ser vermelho. Android.
O sistema deve
ser seguro.
O sistema deve
responder em
1s.
Dica de Ouro: Se a frase falar de "Desempenho", "Segurança",
"Plataforma" ou "Confiabilidade", é Requisito Não-Funcional.
3. UML: Desenhando o Sistema 🎨
O Jadir não quer que você code na prova, ele quer que você desenhe
(modele).
A. Diagrama de Caso de Uso (Os Bonequinhos)
É a visão do Cliente. Mostra quem usa e o que faz.
● Visual: Bonequinho (Ator) ligado a uma bolinha (Elipse).
● Exemplo: Um bonequinho "Aluno" ligado a uma bolinha "Visualizar
Notas".
● Para que serve: Definir o escopo (o que entra e o que não entra no
sistema).
B. Diagrama de Classes (A Planta Baixa)
É a visão do Programador. Mostra como o código vai ser organizado.
● Visual: Um retângulo dividido em 3 andares.
1. Nome: (Ex: ContaBancaria)
2. Atributos: Características (Ex: saldo, numero) -> São as
variáveis.
3. Métodos: Ações (Ex: sacar(), depositar()) -> São as funções.
4. Qualidade: A Pegadinha "V vs V" ⚠️
Essa cai em 90% das provas de Engenharia de Software. Não confunda!
1. Verificação: Estamos fazendo o produto corretamente?
○ Foco: Processo, Normas, Sem Bugs.
○ Analogia: "O texto está sem erros de português?" (Não importa
se o texto é chato, importa que a gramática está certa).
2. Validação: Estamos fazendo o produto certo?
○ Foco: Cliente, Desejo, Utilidade.
○ Analogia: "O texto é sobre o assunto que o leitor queria ler?"
(Não adianta a gramática estar linda se o tema está errado).
Resumo:
Verificação = Engenharia (Está quebrado?)
Validação = Cliente (É isso que você queria?)
5. Scrum: O Rito Ágil
Como você já é estagiário, associe com o seu trabalho, mas use os nomes
técnicos:
● Product Owner (PO): O "Dono do Produto". Ele representa o cliente.
Ele diz O QUE fazer.
● Scrum Master: O "Técnico do Time". Ele remove impedimentos e
garante que as regras do Scrum sejam seguidas. Ele não é chefe, é
líder servidor.
● Daily Scrum: A reunião rápida (15 min) em pé. Três perguntas: O que
fiz ontem? O que farei hoje? Tenho algum problema?
● Sprint: O tempo de trabalho (Time-box), geralmente de 2 a 4 semanas.
⚡ Resumo da Salvação (Para ler 5 min
antes da prova)
● Cascata = Velho, Rígido, Sequencial.
● Ágil = Novo, Flexível, Iterativo.
● Requisito Funcional = Ação / Verbo (Calcular, Salvar).
● Requisito Não-Funcional = Qualidade / Restrição (Rápido, Seguro).
● Caso de Uso = Bonequinhos (O que o sistema faz).
● Diagrama de Classe = Retângulos (Como o sistema é estruturado).
● Verificação = Sem bugs.
● Validação = Cliente feliz.
Baseado na "engenharia reversa" das provas da UNICID/Cruzeiro do Sul e no
perfil do Professor Jadir (que mistura teoria clássica com prática de mercado),
montei esta Prova Regimental Simulada (A1).
Se você conseguir acertar pelo menos 70% desta lista, você está pronto.
🎓 SIMULADO A1: ENGENHARIA DE
SOFTWARE
Professor: Jadir Custódio | Curso: ADS - UNICID
Tempo Sugerido: 40 minutos
PARTE 1: Questões Objetivas (Múltipla Escolha)
1. (Sobre Ciclo de Vida)
Uma empresa de software foi contratada para desenvolver um sistema crítico
de controle de tráfego aéreo. Os requisitos são extremamente detalhados,
rígidos e não podem sofrer alterações após o início do desenvolvimento, pois
um erro poderia ser fatal. Qual modelo de processo é o mais adequado para
este cenário?
A) Scrum (Ágil)
B) Modelo em Espiral
C) Modelo Cascata (Waterfall)
D) Prototipação Evolutiva
E) XP (Extreme Programming)
2. (Sobre Requisitos)
Durante a reunião de levantamento de requisitos para um aplicativo de
delivery, o cliente afirmou: "O sistema deve calcular a taxa de entrega
automaticamente baseada na distância" e "O sistema deve ser capaz de
suportar 10.000 usuários simultâneos sem travar".
Esses requisitos são, respectivamente:
A) Não-Funcional e Funcional.
B) Funcional e Funcional.
C) Não-Funcional e Não-Funcional.
D) Funcional e Não-Funcional.
E) Regra de Negócio e Requisito de Interface.
3. (Sobre UML - Casos de Uso)
No Diagrama de Caso de Uso, às vezes uma funcionalidade sempre precisa
de outra para funcionar (obrigatório), e às vezes ela pode usar outra
(opcional). Essas relações são chamadas, respectivamente, de:
A) Generalização e Especialização.
B) Include (Inclusão) e Extend (Extensão).
C) Extend (Extensão) e Include (Inclusão).
D) Agregação e Composição.
E) Herança e Polimorfismo.
4. (Sobre UML - Diagrama de Classes)
Analise a afirmação: "Este diagrama representa a estrutura estática do
sistema, mostrando seus atributos e métodos. É considerado a 'planta baixa'
para os programadores construírem o banco de dados e as classes de
código."
De qual diagrama estamos falando?
A) Diagrama de Sequência.
B) Diagrama de Atividades.
C) Diagrama de Classes.
D) Diagrama de Casos de Uso.
E) Diagrama de Implantação.
5. (Conceitos de Qualidade - Pegadinha do Jadir)
Você entregou um software que não possui nenhum bug, o código está limpo
e segue todas as normas técnicas. Porém, o cliente reclamou que o software
não resolve o problema de negócio dele e que "não era isso que ele
precisava".
Tecnicamente, podemos dizer que:
A) O software falhou na Verificação, mas passou na Validação.
B) O software passou na Verificação, mas falhou na Validação.
C) O software falhou em ambos (Verificação e Validação).
D) O erro foi de hardware, não de software.
6. (Metodologias Ágeis / Scrum)
No Scrum, existe um artefato que é uma lista priorizada de tudo o que pode
ser necessário no produto (todos os requisitos e desejos do cliente). Quem
cuida dessa lista é o Product Owner. Qual o nome dessa lista?
A) Sprint Backlog
B) Product Backlog
C) Daily Report
D) Burndown Chart
E) Diagrama de Gantt
7. (Engenharia de Requisitos)
Qual das alternativas abaixo descreve MELHOR o que é um "Stakeholder"
em um projeto de software?
A) Apenas quem paga pelo projeto (o dono da empresa).
B) Apenas os programadores que escrevem o código.
C) Qualquer pessoa ou grupo que possa afetar ou ser afetado pelo sistema
(usuários, gerentes, desenvolvedores, clientes).
D) O servidor onde o sistema será hospedado.
PARTE 2: Questão Discursiva (Pode cair 1 ou 2 assim)
8. (Estudo de Caso)
"O modelo Cascata é frequentemente criticado por ser 'engessado'. Explique
por que a mudança de requisitos é um problema grave no modelo Cascata e
como as Metodologias Ágeis (como o Scrum) resolvem esse problema."
🛑 PARE AQUI! Tente responder antes de olhar as respostas.
.
✅ GABARITO COMENTADO (Sua ferramenta de estudo)
1. Resposta C (Cascata)
● Por que? O enunciado falou em "requisitos rígidos", "não podem sofrer
alterações" e "sistema crítico". O Cascata é ruim para mudanças, mas
é ótimo para controle e segurança absoluta. Ágil (Scrum) é para
quando se espera mudanças.
2. Resposta D (Funcional e Não-Funcional)
● Por que?
○ "Calcular taxa" é uma ação (VERBO) -> Funcional.
○ "Suportar 10.000 usuários" é desempenho/capacidade
(ADJETIVO/RESTRIÇÃO) -> Não-Funcional.
3. Resposta B (Include e Extend)
● Por que? Essa é clássica de prova técnica.
○ Include: "Eu incluo isso obrigatoriamente" (ex: Para sacar, tem
que digitar senha).
○ Extend: "Eu estendo isso opcionalmente" (ex: Ao sacar, posso
imprimir comprovante ou não).
4. Resposta C (Diagrama de Classes)
● Por que? Falou em "Estrutura Estática", "Atributos e Métodos", é
Classe. O de Caso de Uso é comportamento (funcional), não estrutura.
5. Resposta B (Passou na Verificação, Falhou na Validação)
● Por que?
○ Verificação = Construir o produto corretamente (sem bugs).
Você fez isso.
○ Validação = Construir o produto certo (o que o cliente queria).
Você falhou nisso.
6. Resposta B (Product Backlog)
● Por que? O Product Backlog é a lista total do projeto. O Sprint
Backlog é só a listinha pequena do que vai ser feito nesta semana. Não
confunda os dois!
7. Resposta C (Qualquer afetado)
● Por que? Stakeholder não é só quem paga (Sponsor). O usuário final
que vai clicar no botão, a equipe de suporte e até o governo (leis)
podem ser stakeholders.
8. Resposta Sugerida (Discursiva):
"No modelo Cascata, as fases são sequenciais. Para mudar um
requisito, é preciso 'voltar' fases inteiras (re-projetar,
re-documentar), o que custa muito caro e atrasa o projeto. Já nas
Metodologias Ágeis (Scrum), o projeto é fatiado em ciclos curtos
(Sprints). Se o requisito mudar, a alteração é incorporada na
próxima Sprint, sem grandes prejuízos, pois o software é
construído de forma incremental e adaptativa."
Dica final: O Jadir gosta de ver se você sabe diferenciar as coisas. Se cair
uma questão comparativa, use palavras como "Rígido vs Flexível" ou
"Documentação vs Código Funcionando".
Boa prova! Você tem o conhecimento, agora é só ter calma na leitura. 👊