Na fase de planejamento do novo Sistema de Gerenciamento de Informação Aeronáutica (AIS), a equipe de segurança e arquitetura de software implementou as diretrizes de um ciclo de vida de desenvolvimento seguro (Secure SDLC).
Antes de iniciar a digitação de qualquer linha de código de produção, os analistas realizaram workshops para simular a anatomia de potenciais ataques cibernéticos contra o ecossistema, identificando as fronteiras de confiança lógicas do sistema, mapeando os ativos valiosos de dados de navegação e construindo diagramas de fluxo de dados de ameaças estruturados com base no modelo Microsoft STRIDE.
No contexto das práticas obrigatórias de engenharia de segurança de um Secure SDLC, essa atividade técnica preventiva realizada na fase de design inicial do software é chamada

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:

Uma equipe de arquitetura de software precisa integrar o barramento de dados de radar de tráfego aéreo centralizado aos terminais secundários de visualização de doze aeródromos regionais.
O sistema exige o tráfego assíncrono massivo e contínuo de dados lógicos com baixíssima latência e em milissegundos. Os arquitetos rejeitaram o uso de uma arquitetura de Integração de Aplicações Corporativas baseada em Barramento de Serviços Corporativos (ESB) tradicional pesada com transformações XML complexas e decidiram implantar um broker de mensageria moderno altamente escalável baseado em logs imutáveis distribuídos em disco.
A principal justificativa técnica que ampara a escolha de um broker – baseado em logs distribuídos em detrimento de uma arquitetura baseada em ESB tradicional pesada para fluxos de dados de radar massivos em tempo real –, consiste no fato de o primeiro

O gerente de engenharia de software monitora o fluxo de trabalho de correção de defeitos em sistemas de comunicação VHF de emergência aeronáuticos, utilizando o método Kanban.
Através de ferramentas de Business Intelligence, o gerente extraiu os seguintes dados operacionais estabilizados das últimas semanas: a equipe mantém uma média estrita e fixa de 12 itens de tarefas sendo trabalhados simultaneamente em progresso nas colunas de desenvolvimento ativo, e a taxa de entrega média do time está consolidada em 3 itens concluídos por semana de calendário.
Aplicando as propriedades matemáticas fundamentais que regem os sistemas enxutos por meio da Lei de Little, o tempo médio total de ciclo (Cycle Time) que um item gasta para trafegar pelas colunas do fluxo de desenvolvimento ativo monitorado por esse gerente é de

Em conformidade com as diretrizes de governança do COBIT 2019, o Serviço de Navegação Aérea do Brasil está desenhando seu novo sistema de governança de tecnologia corporativo.
O analista de governança deve assegurar que as decisões e estruturas de tecnologia não sejam genéricas, mas sim customizadas em tempo real com base na realidade da instituição, que possui um perfil de tolerância a riscos baixíssimo, devido à natureza crítica do controle do espaço aéreo, adota uma estratégia de inovação constante focada em sistemas distribuídos resilientes e está sujeita a auditorias civis e militares severas.
No arcabouço metodológico do COBIT 2019, os parâmetros específicos que descrevem o cenário contextual da organização – tais como perfil de risco, cenário de ameaças, estratégia corporativa, tamanho da empresa e modelo de adoção de TI –, utilizados para calibrar as prioridades dos objetivos de governança e gestão, são denominados

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 Alocação de Pistas e Coordenação de Slots de Pouso de um aeroporto internacional de alta densidade opera sobre um SGBD relacional transacional ACID. Em momentos de pico de tráfego, múltiplos controladores de voo executam requisições síncronas concorrentes para buscar e reservar os mesmos intervalos de horários disponíveis. A gerência de TI identificou que, durante execuções paralelas, uma transação T1 lê um conjunto de slots livres atendendo a um critério de busca geográfica; simultaneamente, uma transação T2 insere e confirma uma nova linha de slot de pouso que atende perfeitamente ao mesmo critério de T1; ao reexecutar a mesma busca na mesma transação, T1 passa a ver a nova linha inserida por T2, gerando inconsistências nas telas de planejamento dos controladores.

A anomalia de concorrência transacional descrita no estudo de caso e o nível de isolamento ANSI SQL mais baixo capaz de impedir por completo a ocorrência desse fenômeno são, respectivamente,

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: