Questões de Engenharia de Software FGV: comentadas e grátis

Resposta correta: D

A frase descreve uma metodologia ágil que organiza o trabalho em ciclos curtos e repetidos, chamados de sprints. Em cada sprint, a equipe planeja, desenvolve, testa e entrega uma parte funcional do produto, o que dá ritmo ao projeto e facilita ajustes rápidos. É como trabalhar em “rodadas” curtas: em vez de esperar meses para ver resultado, você entrega pedaços menores com frequência. Isso é a cara do Scrum. Ele se apoia justamente em sprints, que são intervalos de tempo fixos para executar um conjunto de tarefas e gerar valor ao final de cada ciclo. A lógica é inspeção e adaptação contínuas, com reuniões, papéis definidos e acompanhamento constante do progresso. Por isso o gabarito é a letra D. As outras metodologias ágeis até são relacionadas ao desenvolvimento iterativo e incremental, mas não se caracterizam, de forma tão específica, pelo uso do termo sprint como elemento central da organização do trabalho. Em prova, se aparecer a palavra sprint, pense primeiro em Scrum. É um daqueles indícios clássicos que a banca gosta de usar para separar quem reconhece o conceito de quem só passou correndo pelo conteúdo.

Resposta correta: D

Quando a banca fala em métricas de produto, ela quer medir características do software em si. Se a métrica for dinâmica, a ideia é coletar dados enquanto o programa está executando, como consumo de memória, tempo de resposta e desempenho em uso real. Ou seja: sai o olhar para o código parado e entra a observação do software trabalhando de verdade. Já as métricas estáticas são aquelas obtidas sem executar o programa, normalmente olhando código-fonte, estrutura e documentação. É aqui que aparecem medidas como tamanho de código, complexidade estrutural e outras que você consegue calcular só lendo ou analisando o sistema no papel ou no repositório. Na questão, o item que melhor se encaixa na lógica de métrica dinâmica é o número de relatórios de bugs, porque ele está ligado ao comportamento do software em uso e aos defeitos percebidos durante a operação. Em provas, a banca costuma usar esse tipo de indicador para associar a qualidade percebida do produto ao que acontece quando o sistema está funcionando no mundo real. Então, a resposta correta é a D. O raciocínio é: se a métrica depende da execução e da experiência de uso, ela é dinâmica; se depende só da análise do código ou da estrutura, ela é estática. A prova quer exatamente essa separação, sem mistério e sem pegadinha de laboratório.

Resposta correta: D

No UML, o Diagrama de Transição de Estados mostra como um objeto ou sistema muda de um estado para outro ao longo do tempo, geralmente em resposta a eventos. Pense nele como o "mapa das mudanças": ele destaca estados, eventos, transições e ações associadas. É um diagrama bem útil quando o comportamento depende de condições e reações, como uma porta que sai de "fechada" para "aberta" quando alguém aciona um comando. Por isso, o gabarito é a letra D. A questão fala em "estado de mudança de um sistema orientado por eventos", que é exatamente a ideia central desse diagrama: acompanhar o ciclo de vida do objeto e suas alterações conforme os eventos acontecem. Em outras palavras, ele não foca em ordem de mensagens, nem em fluxo de atividades, nem em organização estrutural. Na doutrina de UML, esse diagrama também é conhecido como diagrama de estados ou máquina de estados, e é típico em análise de comportamento reativo. Se o sistema "responde" a estímulos com mudanças bem definidas, o diagrama de transição de estados entra em cena sem fazer drama, mas com muita utilidade. Então, se a questão falar de evento, estado, transição e mudança de comportamento, acenda a luz do diagrama de estados. Se falar de mensagens, atividades ou estrutura, aí é outro diagrama na festa.

Resposta correta: D

Quando o Web Service recebe uma mensagem de NF-e, ele faz uma espécie de triagem automática antes de aceitar o arquivo. Primeiro, verifica se o XML está bem formado, depois se ele segue o Schema esperado, se não ultrapassa limites de tamanho e se respeita regras básicas de consistência da estrutura. É o famoso "passa no pente-fino antes de entrar". Essas validações são de natureza técnica e estrutural. Então entram coisas como XML malformado, tags fora do Schema e até limite de tamanho da mensagem. Em regras de transmissão e submissão de NF-e, o sistema precisa garantir que o documento chegue íntegro e padronizado, porque um pequeno erro de estrutura já basta para rejeitar a mensagem. A alternativa D sai da lógica dessas validações de recepção. Repetição de valor na tag cEAN entre itens do mesmo documento fiscal não é uma verificação típica de recebimento da mensagem pelo Web Service, mas uma regra ligada ao conteúdo fiscal do documento, não à validação técnica do XML na entrada. Por isso ela é a exceção pedida na questão. Em resumo: o Web Service olha primeiro para a "saúde" do XML, não para todas as regras de negócio do documento. A FGV gosta bastante de misturar validação sintática, estrutural e regra de negócio para ver se você separa uma coisa da outra.

Resposta correta: B

Em engenharia de requisitos, requisito funcional é aquilo que o sistema deve fazer, ou seja, os serviços, tarefas e comportamentos esperados. Aqui, o sistema de uso interno do banco permite que Marta confira os documentos enviados digitalmente pelos novos clientes. Repare que não estamos falando de qualidade, segurança, desempenho ou restrição técnica, mas sim de uma funcionalidade concreta do sistema: analisar/conferir documentos dentro do fluxo de abertura de conta. A pegadinha da questão está em misturar o processo de negócio com a tecnologia usada para executá-lo. O fato de Marta usar um sistema informatizado interno não transforma a demanda em requisito de proteção, de confiança ou qualquer outro tipo mais abstrato. O que interessa é a função entregue pelo software para apoiar a triagem. Em termos práticos: se você consegue descrever a necessidade começando por um verbo de ação do sistema, como conferir, validar, cadastrar, enviar, aprovar ou consultar, a chance de ser requisito funcional é altíssima. Já requisitos de produto, proteção ou confiança costumam tratar de atributos de qualidade, restrições e propriedades não funcionais. Por isso, o gabarito é a letra B. A conferência de documentos realizada por Marta por meio do sistema é uma funcionalidade que o sistema deve oferecer ao usuário interno do banco.

Resposta correta: A

Em Web Services, a ideia central é permitir que sistemas diferentes conversem pela rede de forma padronizada. O SOAP entra justamente aí: ele é um protocolo para troca de mensagens estruturadas, normalmente usando XML como base. Por isso, a afirmativa I está correta. A segunda afirmativa erra feio no nome e no conceito: o padrão usado para descrever Web Services é o WSDL (Web Services Description Language), não "SDL", e ele não é baseado em HTML. O WSDL usa XML para definir operações, mensagens, tipos e endpoints do serviço. A terceira também está errada, porque XML não serve para formatar e exibir páginas Web. XML é uma linguagem de marcação voltada a estruturar e transportar dados. Quem faz o papel de apresentação visual é mais o HTML, geralmente com CSS e JavaScript no front-end. Então, o gabarito A faz sentido: só a I está correta. Em prova, a banca gosta de trocar WSDL por SDL e confundir XML com HTML, então vale ficar atento a esses detalhes de nomenclatura e função.

Resposta correta: A

Em REST, a ideia central é simples: cada requisição deve trazer tudo o que o servidor precisa para entendê-la e processá-la, sem depender de estado salvo de chamadas anteriores. Isso é o famoso princípio de statelessness, ou seja, o servidor não guarda o contexto da sessão do cliente entre uma chamada e outra. Em prova, quando aparecer REST, pense logo em independência entre requisições, uso de HTTP e foco em recursos, não em sessões longas ou protocolos como WSDL. Por isso, a alternativa correta é a A. Se o endpoint recebe uma requisição com todas as informações necessárias, ele segue bem o estilo REST, porque a comunicação fica desacoplada e escalável. Cada chamada já “se vira sozinha”, o que facilita distribuição, balanceamento e manutenção. As outras alternativas misturam REST com características de outras abordagens. WSDL é típico de serviços SOAP, não de REST. Manter dados de sessão no servidor também foge da lógica REST. E otimização por cache pode existir em REST, mas não é a essência cobrada aqui, além de a redação da alternativa D ficar inadequada ao tratar busca de dados como algo que o servidor deve fazer “primeiro no cache” como regra arquitetural. Em concursos, a FGV gosta bastante de testar essa diferença entre REST e SOAP. Se você lembrar que REST trabalha com recursos via HTTP e com requisições sem estado, já mata boa parte das pegadinhas.

Resposta correta: C

A análise de ponto de função é uma técnica de mensuração de software voltada a estimar o tamanho funcional de um sistema, isto é, quanto ele entrega de funcionalidade para o usuário, independentemente da linguagem, da tecnologia ou do número de linhas de código. Ela é muito usada em estimativas, orçamento, contratos e comparação entre projetos, porque transforma funcionalidades em uma medida padronizada e relativamente estável. Na prática, ela ajuda a responder: "esse sistema é maior ou menor?" e não "quem programou melhor?". Por isso, o gabarito é a letra C. A análise de ponto de função serve para medir o tamanho de projetos de desenvolvimento de software, especialmente do ponto de vista funcional. Ela não mede diretamente produtividade, nem desempenho de hardware, nem tempo de resposta. É uma métrica de tamanho, e não uma métrica operacional de execução. Vale lembrar a diferença clássica: ponto de função mede o que o sistema faz para o usuário; já produtividade, em geral, relaciona esforço com entrega, como pontos por hora ou por pessoa. Então, se a banca pergunta sobre análise de ponto de função, pense logo em dimensionamento do software, estimativa e contagem funcional. É aquela conta que ajuda a colocar o projeto no mapa, sem pedir que o sistema corra a maratona.

Resposta correta: C

A UML organiza a visualização do sistema por meio de diagramas, e cada um serve para uma fotografia diferente do projeto. Quando a questão fala em modelar as interações entre atores e objetos, e também entre os próprios objetos, ela está pedindo um diagrama que mostre a troca de mensagens ao longo do tempo. Esse é exatamente o papel do diagrama de sequência: ele representa a ordem temporal das interações, mostrando quem envia mensagem para quem e em que momento isso acontece. Em concurso, pense assim: se a pergunta enfatiza "interação" e "ordem das mensagens", acenda a luz do diagrama de sequência. Já os atores costumam aparecer no contexto de uso do sistema, mas a interação detalhada entre eles e os objetos internos não fica bem representada no diagrama de casos de uso. O diagrama de sequência entra como a visão mais operacional dessa conversa entre elementos do sistema. Por isso o gabarito é a letra C. A UML, na doutrina clássica de Booch, Rumbaugh e Jacobson, trata o diagrama de sequência como um dos diagramas de interação, junto com o de comunicação, justamente para descrever o fluxo de mensagens entre objetos e participantes.

Resposta correta: C

Em Kubernetes, quando dois grupos de containers precisam se encontrar na rede sem depender do IP que cada um recebeu, você precisa de uma camada de abstração de rede. É aí que entra o Service: ele funciona como um endereço estável, com nome e porta fixos, enquanto os pods por trás podem nascer, morrer e trocar de IP sem bagunçar a comunicação. No enunciado, o Grupo A precisa acessar o Grupo B e o orquestrador deve garantir essa conexão mesmo com IPs dinâmicos. Isso é exatamente o papel do Service: expor um conjunto de pods e fazer o balanceamento e o encaminhamento interno para eles. Na prática, o Service vira o ponto de contato estável entre os componentes. Já pod, ReplicaSet, Ingress e StatefulSet resolvem outras dores. Pod é a menor unidade executável, ReplicaSet cuida de quantidade de réplicas, Ingress trata entrada HTTP/HTTPS para fora do cluster, e StatefulSet é voltado a aplicações com identidade e ordem estáveis. Nenhum deles substitui a função básica de endereço estável na comunicação interna entre grupos de containers. Então o gabarito C está correto porque o Service é o recurso do Kubernetes usado para dar descoberta e acesso estáveis aos workloads, independentemente dos IPs efêmeros dos pods. É o clássico "não memorize o IP, memorize o nome" do mundo Kubernetes.