Questão de Engenharia de Software — Geral — FCC 2026

Gerência de Configuração: trilha de auditoria e controle de versão

Gabarito: letra C. A conclusão tecnicamente fundamentada é que a inexistência de controle de versionamento compromete a rastreabilidade e a integridade das informações, exigindo recomendações técnicas para adequação do sistema. Isso decorre dos princípios da Gerência de Configuração de Software (GCS), que estabelecem o controle de mudanças e a auditoria de configuração como atividades essenciais para garantir que o software evolua de forma controlada e que seu estado seja sempre conhecido e reproduzível.

A Gerência de Configuração de Software é a disciplina da Engenharia de Software responsável por identificar, organizar e controlar as modificações feitas no software durante todo o seu ciclo de vida. Seu objetivo é manter a integridade e a rastreabilidade dos artefatos, permitindo que se saiba, a qualquer momento, o que foi alterado, por quem, quando e por quê. No contexto de um sistema de gestão de denúncias de uma Ouvidoria, essas garantias são ainda mais críticas, pois envolvem informações sensíveis que podem ter implicações legais e institucionais.

A trilha de auditoria (ou log de auditoria) é o registro detalhado e cronológico das operações realizadas no sistema, incluindo quem acessou, o que alterou e quando. O controle de versionamento, por sua vez, é o mecanismo que gerencia as diferentes versões de um artefato (código, documentos, configurações), permitindo recuperar estados anteriores e entender a evolução do produto. Ambos são pilares da rastreabilidade: sem eles, é impossível reconstituir o histórico de alterações, identificar responsabilidades ou verificar se o sistema está em conformidade com os requisitos institucionais.

Na prática, imagine que um usuário interno altere indevidamente o teor de uma denúncia. Sem trilha de auditoria, não há como provar quem fez a alteração nem quando. Sem controle de versão, não há como restaurar o conteúdo original. A integridade da informação fica comprometida, e a confiança no sistema como fonte oficial de registro é abalada. Por isso, o parecer técnico não pode se limitar a descrever funcionalidades ou a tratar as lacunas informalmente: ele deve registrar formalmente as não conformidades e recomendar as correções necessárias, pois é essa a função do setor técnico no assessoramento à administração superior.

A banca explora aqui a tentação de minimizar o problema ou de tratá-lo como questão secundária. As alternativas incorretas propõem exatamente isso: desviar o foco do parecer, priorizar a correção informal, aceitar o sistema como adequado ou compensar a falta de auditoria com backups. O critério decisivo é reconhecer que rastreabilidade e integridade são requisitos não funcionais essenciais — e que sua ausência é uma não conformidade que deve ser formalmente apontada e corrigida.

Alternativa A — ❌ Incorreta

Afirma que o parecer deve se concentrar na descrição funcional e que o posicionamento conclusivo sobre conformidade seria de outra área. Isso contraria a própria natureza do parecer técnico, que tem por finalidade avaliar a conformidade do sistema com os requisitos institucionais. O setor de TI, ao elaborar o parecer, deve emitir conclusão fundamentada sobre as lacunas encontradas, inclusive as de natureza não funcional, como auditoria e versionamento. Transferir essa responsabilidade a outra área seria uma omissão técnica.

Alternativa B — ❌ Incorreta

Sugere que as lacunas técnicas sejam tratadas pela equipe de desenvolvimento e priorizadas frente ao registro formal no parecer. Inverte a ordem correta: o parecer é justamente o instrumento formal para registrar as não conformidades e subsidiar a decisão da administração superior. Tratar as lacunas informalmente, sem registro, compromete a transparência e a rastreabilidade do próprio processo de correção. A prioridade deve ser documentar o problema e, a partir daí, planejar a correção.

Alternativa C — ✅ Correta ⟵ GABARITO

A alternativa está correta porque identifica com precisão o impacto da ausência de controle de versionamento: compromete a rastreabilidade e a integridade das informações. A rastreabilidade é a capacidade de reconstituir o histórico de alterações; a integridade é a garantia de que os dados não foram corrompidos ou alterados indevidamente. Sem versionamento, não há como saber qual versão do registro está vigente, quem a alterou ou como recuperar uma versão anterior. O parecer deve, portanto, recomendar tecnicamente a adequação do sistema, implementando mecanismos de auditoria e controle de versão.

Alternativa D — ❌ Incorreta

Afirma que o sistema atende aos requisitos institucionais por implementar autenticação e registro de logs. A autenticação (verificação de identidade do usuário) e os logs (registros de eventos) são medidas importantes, mas não substituem a trilha de auditoria detalhada nem o controle de versionamento. A trilha de auditoria vai além do log simples: registra o antes e o depois de cada alteração, permitindo reconstituir o estado anterior. O versionamento, por sua vez, gerencia as versões dos artefatos. A presença de autenticação e logs não supre a ausência desses mecanismos, portanto o sistema não pode ser considerado plenamente conforme.

Alternativa E — ❌ Incorreta

Propõe que a ausência de trilha de auditoria seja compensada por backups periódicos, priorizando o ajuste estrutural em segundo plano. Backups são essenciais para recuperação de desastres, mas não cumprem a função da trilha de auditoria: eles restauram dados, mas não registram quem alterou o quê e quando. A trilha de auditoria é um requisito de rastreabilidade e controle, não de disponibilidade. Compensar uma lacuna com outra medida de natureza diferente é tecnicamente incorreto e não resolve o problema de integridade e responsabilização.

Gabarito: letra C