Questão de Engenharia de Software — Qualidade de Software — FCC 2026
Engenharia de Software›Qualidade de Software
Código
gp044410
Banca
FCC
Órgão
AL-RR
Ano
2026
Cargo
Analista Legislativo - Analista de Segurança da Informação
A Assembleia Legislativa planeja migrar seus sistemas legados para um ambiente de nuvem e contratar o desenvolvimentoum novo portal de transparência. Para garantir a segurança e a conformidade técnica no modelo contratual, a solução deveprever que
Aa migração ocorra para um modelo Public Cloud com criptografia de ponta a ponta gerida pelo provedor, os requisitostécnicos de sustentabilidade foquem no descarte de hardware e o desenvolvimento seja entregue via SaaS para reduzir asuperfície de ataque local.
Bo contrato de infraestrutura priorize o modelo On-premises para manter a soberania dos dados, a segurança da informaçãoseja tratada como um requisito funcional específico de cada entrega e a acessibilidade seja orientada por meio do uso deferramentas de tradução automática.
Co desenvolvimento seja medido por story points em regime Agile, a infraestrutura utilize o modelo Community Cloud paraisolamento lógico total e os requisitos de acessibilidade sigam a norma ISO 27001 para garantir a inclusão digital dos cidadãos.
Do edital exija certificações SOC 2 Type II (Service Organization Control 2) do provedor de nuvem, o desenvolvimento utilizemétricas de Ponto de Função com análise estática de código (SAST) integrada e o contrato preveja sanções pordescumprimento de níveis de serviço de segurança.
Ea arquitetura seja baseada em Multicloud para evitar o vendor lock-in,a sustentação seja contratada por postos de trabalhopresenciais para controle físico e os requisitos não funcionais de segurança sejam validados após a homologação final dosoftware.
Revelar gabarito e comentário▾
GabaritoD — o edital exija certificações SOC 2 Type II (Service Organization Control 2) do provedor de nuvem, o desenvolvimento utilize
métricas de Ponto de Função com análise estática de código (SAST) integrada e o contrato preveja sanções por
descumprimento de níveis de serviço de segurança.
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Qualidade de Software em Contratação de Serviços de TI
Gabarito: letra D. A alternativa D apresenta um conjunto coerente de exigências contratuais para garantir segurança e conformidade: certificação SOC 2 Type II do provedor de nuvem (auditoria independente de controles de segurança), uso de métricas de Ponto de Função combinadas com análise estática de código (SAST) para qualidade de desenvolvimento, e previsão de sanções pelo descumprimento de níveis de serviço de segurança. As demais alternativas contêm inadequações técnicas ou conceituais.
A banca testa o conhecimento sobre práticas recomendadas em contratação de soluções de TI no setor público, especialmente no que tange à segurança da informação, métricas de software e modelos de implantação.
Alternativa
Modelo de Infraestrutura
Métrica/Método de Desenvolvimento
Requisito de Segurança/Conformidade
Requisito de Acessibilidade/Sustentabilidade
Coerência Técnica
A
Public Cloud
SaaS (Software as a Service)
Criptografia ponta a ponta gerida pelo provedor
Sustentabilidade focada apenas no descarte de hardware
❌ Inadequada (conflito com soberania de dados; falta de customização)
B
On‑premises
Não especificado
Segurança tratada como requisito funcional
Acessibilidade por tradução automática
❌ Inadequada (contradiz migração para nuvem; erro conceitual sobre segurança)
C
Community Cloud
Story points (Agile)
ISO 27001 (aplicada incorretamente à acessibilidade)
Isolamento lógico total (não garantido)
❌ Inadequada (ISO 27001 não trata de acessibilidade; isolamento não é total)
D
Nuvem (provedor com SOC 2 Type II)
Ponto de Função + SAST (análise estática)
SOC 2 Type II; sanções por descumprimento de SLAs de segurança
Não especificado (foco em segurança e conformidade)
✅ Correta (práticas recomendadas e coerentes)
E
Multicloud
Postos de trabalho presenciais (sustentação)
Requisitos não funcionais validados após homologação
Vendor lock-in evitado
❌ Inadequada (sustentação presencial contradiz nuvem; validação tardia de segurança)
Alternativa A — ❌ Incorreta
Embora a criptografia ponta a ponta seja desejável, a escolha de Public Cloud pode conflitar com exigências de soberania de dados de um órgão legislativo. Além disso, focar sustentabilidade apenas no descarte de hardware é insuficiente, e entregar o desenvolvimento via SaaS elimina a possibilidade de customização necessária para um portal de transparência.
Alternativa B — ❌ Incorreta
Priorizar On‑premises contradiz a premissa de migração para nuvem. Tratar segurança como requisito funcional é incorreto: segurança é um requisito não funcional (transversal). A acessibilidade por tradução automática não atende aos padrões exigidos (e.g., WCAG).
Alternativa C — ❌ Incorreta
Medir desenvolvimento unicamente por story points é válido em Agile, mas não suficiente. Community Cloud não garante isolamento lógico total – ele é compartilhado entre organizações. A norma ISO 27001 trata de gestão de segurança da informação, não de acessibilidade (que é regida por ISO 9241, WCAG, etc.).
Alternativa D — ✅ Correta ⟵ GABARITO
Reúne as melhores práticas:
SOC 2 Type II é uma certificação reconhecida internacionalmente que atesta a eficácia dos controles de segurança, confidencialidade e privacidade do provedor de nuvem.
Ponto de Função é uma métrica de tamanho funcional amplamente usada em contratos públicos, e SAST (Static Application Security Testing) integrado permite detectar vulnerabilidades precocemente.
Sanções contratuais por descumprimento de SLAs de segurança garantem responsabilização e alinhamento com a proteção de dados.
Alternativa E — ❌ Incorreta
Multicloud evita vendor lock‑in, mas a sustentação por postos presenciais é contraditória com a agilidade e o modelo de nuvem. Validar requisitos não funcionais de segurança apenas após a homologação final é tardio; devem ser verificados continuamente durante o desenvolvimento.
NÃO CAIA NESSA!
A banca explora a confusão entre normas e requisitos: na alternativa C, associa acessibilidade à ISO 27001 (que é de segurança); na B, trata segurança como requisito funcional. Fique atento a essas trocas!