O Serviço de Navegação Aérea está modernizando o Subsistema de Processamento de Mensagens ATS (Air Traffic Services). Devido a requisitos internacionais estritos de segurança e à necessidade de homologação por órgãos reguladores, os requisitos de comunicação e os protocolos de rede com centros de controle adjacentes são completamente conhecidos, estáveis e rígidos, não permitindo ambiguidades ou mudanças durante a execução.
Diante de um cenário no qual os requisitos são estáveis, completamente definidos no início do projeto e a previsibilidade e conformidade regulatória são os fatores críticos de sucesso, o modelo de ciclo de vida tradicional linear se mostra o mais adequado.
Assinale a opção que apresenta uma característica ou desvantagem típica do Modelo em Cascata, nesse contexto.

Ao desenvolver o algoritmo de cálculo de distância de segurança anticolisão (TCAS) entre duas aeronaves em uma nova biblioteca de software, o desenvolvedor decide aplicar de forma estrita o ciclo de passos determinado pela metodologia Test-Driven Development (TDD). Ele iniciou criando um caso de teste unitário exaustivo contendo as coordenadas geográficas tridimensionais e as velocidades vetoriais de dois alvos simulados em rota de interceptação iminente.
Seguindo rigorosamente a ordem cronológica obrigatória das fases que compõem o ciclo padrão do TDD (conhecido na literatura técnica como o ciclo Red-Green-Refactor), o desenvolvedor deve, logo após ter escrito o código desse teste unitário inicial, executar os seguintes passos sequenciais:

O pipeline de Integração Contínua (CI) do sistema de radar secundário de um aeroporto federal foi configurado com ferramentas automatizadas de testes de segurança de aplicações.
Na fase de compilação, o analisador emitiu um relatório estancando a esteira ao detectar o uso de funções inseguras de manipulação de strings em C++ que poderiam abrir brechas para corrupção de memória. O analista DevOps alegou que a esteira de build deveria ignorar o alerta, pois uma varredura dinâmica executada na aplicação rodando em ambiente de homologação simulado não conseguiu explorar a falha através de requisições de rede externas.
Com base nos conceitos que diferenciam as abordagens de segurança SAST (Análise Estática) e DAST (Análise Dinâmica), a decisão correta do engenheiro de software deve consistir em manter a esteira travada porque a técnica SAST

Durante o ciclo de auditoria de segurança de um Sistema de Processamento de Planos de Voo (FPL), identificou-se uma inconsistência lógica na validação de mensagens de atualização compulsórias enviadas pelas companhias aéreas.
O Gerente de Engenharia de Software determinou que a equipe demonstrasse matematicamente quais linhas específicas do código-fonte do módulo de parsing foram geradas a partir de qual requisito técnico de segurança original, e quais casos de testes homologados cobrem esse escopo para subsidiar a homologação regulatória civil.
A atividade de Engenharia de Requisitos voltada a estabelecer links lógicos bidirecionais contínuos entre os requisitos de origem, os artefatos de arquitetura, os componentes de código-fonte e as suítes de testes de validação finais é classificada como rastreabilidade do tipo

O sistema de radar de um Centro de Controle de Área (ACC) processa fluxos de dados de vigilância aérea formatados no padrão internacional EUROCONTROL ASTERIX (Category 062 - SDPS Track Messages).
A equipe técnica precisa integrar um novo módulo de monitoramento ambiental terceirizado que exige o recebimento desses mesmos dados de alvos (altitude, velocidade e proa), mas formatados estritamente na sintaxe XML do padrão meteorológico WXXM (WXXM Weather Information Exchange Model).
O código do sistema de radar existente não pode sofrer modificações estruturais para evitar riscos de regressão no processamento de segurança do tráfego aéreo.
Para viabilizar a comunicação síncrona entre o sistema de radar emissor de objetos ASTERIX e o módulo consumidor estruturado em XML WXXM, ocultando a incompatibilidade de interfaces sem alterar as classes originais, o engenheiro de software deve implementar o padrão de projeto

Um engenheiro de software do Serviço de Navegação Aérea do Brasil recebeu a tarefa de projetar o novo microsserviço de processamento de mensagens meteorológicas aeronáuticas (METAR).
O sistema precisa ler boletins climáticos de múltiplos canais (redes de rádio HF, brokers AMQP locais e APIs de satélite externas), e persistir os dados validados, tanto em um banco NoSQL local quanto em um Data Lake central da aeronáutica. Buscando isolar o núcleo das regras de negócio (cálculo de teto de nuvens e visibilidade de pista) de variações tecnológicas em bancos de dados e protocolos de rede de terceiros, o engenheiro decidiu aplicar os padrões da Arquitetura Hexagonal.
No contexto da Arquitetura Hexagonal, para permitir que o núcleo da aplicação invoque operações de persistência no banco NoSQL sem criar um acoplamento direto com o driver específico do banco, o engenheiro de software deve posicionar o contrato da interface de persistência e a sua respectiva implementação em código nas seguintes estruturas:

Um engenheiro implementou uma lógica em Python para acionar um alarme com histerese: o alarme deve ser ligado quando a temperatura atingir ou ultrapassar 72 °C e deve permanecer ligado até que a temperatura atinja ou fique abaixo de 66 °C.

A variável ACIONAMENTOS registra quantas vezes o alarme passa do estado desligado para o estado ligado. 

TEMPERATURAS = [68, 71, 74, 73, 69, 65]

ALARME = False
ACIONAMENTOS = 0

for temp in TEMPERATURAS:
    if temp >= 72 and not ALARME:
        ALARME = True
        ACIONAMENTOS += 1
    elif temp <= 66 and ALARME:
        ALARME = False

print(ALARME, ACIONAMENTOS)

O sistema de supervisão de temperatura realiza medições ao longo de um intervalo de tempo que são armazenadas na variável TEMPERATURAS do tipo lista.

Após a execução do código, será impresso

Um controlador executa uma rotina lógica para definir o acionamento de uma ventoinha de emergência instalada em um rack de equipamentos.

O controlador recebe sinais digitais de supervisão e uma leitura de temperatura, conforme o pseudocódigo a seguir. 

energia_ok = VERDADEIRO
comunicacao_ok = VERDADEIRO
porta_fechada = FALSO
alarme_incendio = FALSO
temperatura = 38
ventilacao_manual = FALSO

modo_seguro    =   energia_ok   E   comunicacao_ok   E
porta_fechada E NAO alarme_incendio

SE modo_seguro E temperatura >= 35 ENTAO
    ventoinha = VERDADEIRO
SENAO SE ventilacao_manual E NAO alarme_incendio
ENTAO
    ventoinha = VERDADEIRO
SENAO
    ventoinha = FALSO
FIM SE

Após a execução da rotina, o valor da variável ventoinha será

Atílio é um analista de segurança dedicado e atualizado com as ferramentas de mercados disponíveis para facilitar seu trabalho. Durante uma de suas rotinas de testes, estava testando uma API com o Postman e observou que requisições com credenciais inválidas retornavam código HTTP 200.

Nesse caso, o Postman

No ciclo de vida de desenvolvimento de software, a garantia de qualidade depende diretamente da conexão entre os requisitos funcionais e as validações finais.

Nesse cenário, os critérios de aceitação são descritos como uma forma de documentar os anseios e as necessidades do cliente, especificando como o sistema deve operar para ser aceito. Eles servem como o elo fundamental de rastreabilidade, transformando regras de negócio em cenários de teste verificáveis.

Sobre os critérios de aceitação, analise as afirmativas a seguir.

I. Servem para verificar se o sistema como um todo adere aos critérios contratuais acordados com o usuário final.
II. Ajudam a confirmar que o software cumpre todos os seus requisitos funcionais e não funcionais.
III. Auxiliam na tomada de decisão dos stakeholders sobre o "go-live" (entrada em produção).

Está correto o que se afirma em