A Diretoria de TI dos Serviços de Navegação Aérea iniciou a elaboração do mapa estratégico de riscos tecnológicos para o próximo biênio.
Durante os workshops, os analistas foram orientados a mapear não apenas as ameaças e vulnerabilidades lógicas clássicas de infraestrutura, mas também a estimar matemática e estatisticamente o impacto potencial de cada evento no negócio da instituição.
No âmbito dos frameworks clássicos de Governança de TI e gestão de projetos (PMBOK/COBIT), o risco corporativo é formalmente definido e calculado com base no produto vetorial entre os seguintes componentes básicos:

Durante uma aula de integração para novos desenvolvedores de um órgão público, o arquiteto sênior apresentou o desenho estrutural do sistema de RH.
Ele explicou que o software utiliza uma arquitetura em camadas clássica de três níveis, onde o código associado à exibição das telas não se mistura com as regras de cálculo de férias, e essas, por sua vez, utilizam classes específicas de acesso a dados para ler o banco relacional.
A principal vantagem conceitual de se adotar uma Arquitetura em Camadas tradicional, no desenvolvimento de sistemas corporativos, é permitir a

O Diretor de Tecnologia dos Serviços de Navegação Aérea quer aumentar a transparência do progresso do desenvolvimento de sistemas sem a necessidade de convocar reuniões gerenciais diárias exaustivas. Ele determinou a instalação de telas digitais de grande porte nos corredores centrais da TI, exibindo gráficos de Burndown atualizados em tempo real e o quadro Kanban com o status de todas as demandas ativas.
No âmbito das metodologias ágeis de desenvolvimento de software, as ferramentas físicas ou digitais altamente visíveis instaladas em locais públicos para compartilhar o status do projeto de forma transparente, são classificadas como

Uma agência reguladora federal precisa desenvolver um sistema de monitoramento de satélites de alta complexidade.
Os requisitos de segurança nacional são extremamente rígidos, e qualquer falha lógica pode gerar impactos geopolíticos severos. A gerência técnica determinou a adoção de um modelo de ciclo de vida de desenvolvimento de sistemas tradicional que priorize a gestão e análise formal de riscos em cada fase do projeto, dividindo o ciclo em iterações concêntricas de avaliação, engenharia e planejamento.
O modelo de ciclo de vida de desenvolvimento de software que atende nativamente a essa exigência de controle, caracterizandose por uma abordagem evolucionária orientada e guiada por análises de risco estruturadas, é o

Um Analista de Suporte de uma Central de Serviços recebeu dois chamados em sua fila de atendimento na mesma manhã. O Chamado X foi aberto por um diretor administrativo, relatando que sua impressora corporativa parou de funcionar devido a um atolamento de papel físico, impedindo a impressão de um relatório urgente. O Chamado Y foi aberto por um novo servidor técnico solicitando a instalação de um software de edição de planilhas, cujo uso já é previamente homologado pela política de segurança de TI do órgão.
À luz das definições de práticas de gerenciamento de serviços estabelecidas no framework ITIL v4, os chamados X e Y classificam-se, respectivamente, como

O coordenador de um time Kanban de suporte técnico notou que o tempo total de atendimento das demandas lógicas (Lead Time) estava aumentando significativamente nas últimas semanas.
O quadro visual exibe uma coluna chamada Homologação Técnica congestionada, com mais de 25 tarefas abertas simultaneamente, enquanto a equipe possui apenas dois analistas dedicados a essa validação.
Com base nas propriedades matemáticas que regem o fluxo de sistemas enxutos (Lei de Little), para reduzir o Lead Time e acelerar a vazão de entrega de valor sem alterar o tamanho da equipe, o coordenador deve

Um Analista de Tecnologia está investigando uma degradação de desempenho intermitente em um sistema de prontuário médico distribuído.
Quando um médico ‘clica’ para emitir uma receita, a requisição passa por um API Gateway, dispara o Microsserviço de Autenticação, consome o Microsserviço de Pacientes, consulta o Banco de Dados Relacional e aciona uma função Serverless externa de validação de CRM. O tempo de resposta final na tela do usuário saltou de 1 para 12 segundos, mas os logs isolados de cada servidor indicam que todas as máquinas individuais estão operando com uso de CPU abaixo de 30%.
Para diagnosticar em qual etapa exata do ciclo de chamadas distribuídas a latência está ocorrendo e identificar o gargalo de rede ou processamento, o analista deve implementar o seguinte mecanismo:

Durante o evento de planejamento de um Incremento de Programa (PI Planning) sob o framework SAFe, três times ágeis diferentes constataram um bloqueio mútuo: o Time Alfa depende de uma API de segurança que será desenvolvida pelo Time Beta, que por sua vez depende da modelagem de dados de infraestrutura a ser realizada pelo Time Gama.
O Engenheiro do Trem de Liberação (Release Train Engineer - RTE) interveio para evitar que o Trem de Liberação (Agile Release Train - ART) iniciasse a execução do ciclo de Sprints com riscos críticos não mitigados.
Para visualizar, debater e gerenciar formalmente essas interdependências técnicas e restrições de precedência cronológica entre as equipes durante o PI Planning, o artefato visual obrigatório a ser utilizado é o

O Comitê de Avaliação de Mudanças (CAB) de uma grande empresa pública de tecnologia está analisando uma requisição de mudança de caráter emergencial. A proposta consiste em aplicar um patch de correção em um banco de dados relacional distribuído que suporta o sistema de arrecadação de tributos estaduais.
O proponente da mudança apresentou a matriz de riscos e o plano de testes homologado, mas o CAB barrou a homologação da janela de manutenção sob o argumento de que o Plano de Reversão (Rollback) apresentado dependia da restauração de um backup físico integral (Cold Backup) estimado em 14 horas de processamento.
Considerando as boas práticas de Governança de TI e gerenciamento de mudanças do ITIL v4, a decisão do CAB de barrar a mudança justifica-se tecnicamente porque o plano de reversão

Uma equipe de desenvolvimento de sistemas de uma autarquia federal está modelando o módulo de concessão de licenças ambientais utilizando Domain-Driven Design (DDD).
O domínio possui as classes

ProcessoLicenciamento, ParecerTecnico, Vistoria e DocumentoObrigatorio.

O arquiteto definiu que a classe ProcessoLicenciamento atuará como Aggregate Root. Durante uma revisão de código, constatou-se que um desenvolvedor criou um repositório exclusivo para a classe Vistoria, permitindo que sistemas externos alterem o status de uma vistoria diretamente no banco de dados, sem passar pelas regras de validação contidas em ProcessoLicenciamento.


À luz dos padrões táticos do DDD, a abordagem do desenvolvedor está incorreta porque viola o seguinte princípio: