Engenharia de Software para a Marinha: O que estudar?

Na disciplina de Engenharia de Software, a preparação para concursos da Marinha exige muito mais do que familiaridade com termos conhecidos do mercado. A prova normalmente cobra conceitos clássicos, distinções conceituais e aplicação correta da terminologia. Por isso, o estudo precisa ser organizado, estratégico e baseado em compreensão real dos fundamentos.

Um erro frequente entre candidatos é tratar Engenharia de Software como uma matéria excessivamente abstrata. Na verdade, ela é uma disciplina extremamente lógica. A banca costuma selecionar temas centrais, como requisitos, qualidade, projeto, métodos ágeis e testes, e transformá-los em alternativas objetivas que exigem precisão técnica do candidato.

O primeiro grande eixo de cobrança costuma ser requisitos de software. Aqui, a distinção entre requisitos funcionais e não funcionais é indispensável. Os requisitos funcionais descrevem o que o sistema deve fazer. Já os não funcionais tratam de restrições, atributos de qualidade e condições sob as quais o sistema deve operar, como desempenho, segurança, disponibilidade e confiabilidade.

Esse tema merece muita atenção porque as bancas adoram induzir o candidato ao erro por meio de enunciados aparentemente intuitivos. Muita gente acha que requisito não funcional é algo secundário ou meramente acessório. Isso está errado. Em muitos sistemas, especialmente os corporativos e críticos, os requisitos não funcionais impactam diretamente a arquitetura da solução.

Se um sistema precisa responder em tempo reduzido, atender milhares de usuários simultâneos, operar com alta disponibilidade e proteger dados sensíveis, essas exigências moldam profundamente a forma como o software será construído. Portanto, em prova, é fundamental reconhecer que requisitos não funcionais não são “detalhes”; eles podem influenciar escolhas arquiteturais centrais.

Outro bloco muito importante é o de projeto de software, especialmente os conceitos de coesão e acoplamento. Esse é um conteúdo clássico da Engenharia de Software e aparece porque permite à banca construir alternativas bastante sedutoras. O princípio geral é conhecido: desejamos alta coesão e baixo acoplamento.

Alta coesão significa que um módulo possui responsabilidades bem relacionadas entre si. Baixo acoplamento significa que a dependência entre módulos é reduzida. Na prática, isso facilita manutenção, compreensão, teste, reaproveitamento e evolução do sistema. Em termos de concurso, esse assunto é perigoso porque o examinador costuma inverter os benefícios nas alternativas.

Por exemplo, pode aparecer a ideia errada de que alto acoplamento facilita integração ou de que baixa coesão melhora a centralização das funcionalidades. Essas formulações confundem candidatos que conhecem superficialmente os termos, mas não entendem as consequências práticas do projeto ruim. Por isso, sempre associe coesão à unidade lógica interna e acoplamento ao grau de dependência externa.

A disciplina também costuma cobrar métodos ágeis, com destaque para Scrum. Esse assunto é extremamente recorrente porque combina terminologia específica, papéis, eventos e artefatos. A prova pode perguntar o objetivo da Sprint Review, da Sprint Retrospective, do Sprint Planning ou do Daily Scrum, explorando diferenças muito sutis entre eles.

Na Sprint Review, por exemplo, o foco está na inspeção do incremento e na interação com stakeholders para avaliar o que foi produzido e ajustar o Product Backlog, se necessário. Já na Retrospective, a atenção se volta ao processo de trabalho da equipe, com reflexão sobre melhorias para a próxima Sprint. Essa distinção é clássica em prova.

O problema é que muitos candidatos compreendem o espírito do Scrum, mas confundem formalmente as cerimônias. Em concurso, isso custa ponto. O examinador não quer apenas saber se você “entendeu mais ou menos” a ideia geral do ágil. Ele quer ver se você domina a nomenclatura correta e sabe associar cada evento à sua finalidade específica.

Outro tema que merece estudo sério é teste de software. Em Engenharia de Software para concursos, a cobrança costuma recair sobre níveis e objetivos dos testes. Não basta conhecer os nomes. É necessário saber exatamente o que cada tipo de teste busca verificar e em que contexto ele é mais adequado.

O teste unitário verifica partes isoladas do sistema. O teste de integração avalia a interação entre componentes. O teste de sistema observa o comportamento do software como um todo. O teste de aceitação busca verificar aderência às necessidades do usuário ou do cliente. Já o teste de regressão procura identificar se mudanças introduziram defeitos em funcionalidades que antes operavam corretamente.

Esse último é bastante cobrado porque muitas vezes o aluno o confunde com reteste ou com teste de integração. O raciocínio correto é simples: sempre que uma modificação ocorre no software, é necessário verificar se essa mudança afetou negativamente elementos que já estavam estabilizados. Esse é o espírito do teste de regressão.

Há ainda a distinção entre técnicas como caixa-preta e caixa-branca. A caixa-preta se concentra nas entradas e saídas, sem examinar a estrutura interna do código. A caixa-branca considera a lógica interna, caminhos e estruturas do programa. Esse contraste também é muito útil para a banca construir questões objetivas de boa qualidade.

Do ponto de vista de preparação, minha orientação é organizar a disciplina por pares conceituais. Estude funcional versus não funcional. Alta coesão versus baixo acoplamento. Review versus Retrospective. Teste unitário versus integração versus aceitação versus regressão. Essa estratégia ajuda muito porque a prova geralmente trabalha exatamente com conceitos vizinhos.

Outra recomendação é utilizar autores clássicos como Pressman e Sommerville como base de revisão. Isso fortalece a compreensão conceitual e ajuda a consolidar definições mais estáveis, algo muito útil em provas. Quando o candidato estuda por boas referências, ele fica menos vulnerável a alternativas redigidas de forma ambígua ou capciosa.

Também é importante lembrar que Engenharia de Software não deve ser estudada como uma lista de jargões. O conteúdo faz sentido como visão estruturada da construção de software. Requisitos definem necessidades. Projeto organiza a solução. Métodos orientam o processo. Testes verificam qualidade. Quando o aluno entende essa cadeia, o conteúdo deixa de parecer disperso.

Por fim, a grande chave para ir bem em Engenharia de Software na Marinha é combinar teoria sólida com leitura analítica de questões. A banca tende a cobrar conceitos tradicionais, mas inseridos em alternativas que exigem atenção, comparação e domínio terminológico. Quem estuda com método, resolve questões e revisa os pontos clássicos chega à prova com muita vantagem.