Questão de Engenharia de Software — Desenvolvimento de Software — FGV 2024
Engenharia de Software›Desenvolvimento de Software
Código
fg100838
Banca
FGV
Órgão
TRF - 1ª REGIÃO
Ano
2024
Nível
Superior
Cargo
Analista Judiciário - Área Apoio Especializado - Especialidade: Análise de Sistemas de Informação
Os analistas do Time de Desenvolvimento de Software (TDS) estão utilizando User Story (História de Usuário) do Extreme Programming (XP) para todos os novos projetos, em substituição aos Casos de Uso em UML.Na escrita das User Stories, os analistas devem:
Aconsiderar que histórias podem ser construídas em mais de uma iteração;
Bordenar a escrita das histórias, visto que há uma dependência entre elas;
Cdetalhar os critérios de testes a serem executados com base na história;
Dconsiderar que uma história pode ser um ou mais cenários em um caso de uso;
Efocar nos objetivos do usuário e em como a interação com o sistema satisfaz esses objetivos.
Revelar gabarito e comentário▾
GabaritoD — considerar que uma história pode ser um ou mais cenários em um caso de uso;
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”.
User Stories no Extreme Programming (XP)
Gabarito: letra D. A alternativa D está correta porque, no contexto do XP, uma User Story pode representar um ou mais cenários de um Caso de Uso tradicional, funcionando como uma descrição simplificada e orientada ao valor do negócio. As demais alternativas distorcem as características das User Stories, confundindo-as com práticas de Casos de Uso ou impondo restrições que não se aplicam no XP.
A questão exige conhecimento das diferenças fundamentais entre User Stories (típicas de métodos ágeis como XP) e Casos de Uso (UML). Enquanto os Casos de Uso são narrativas detalhadas que descrevem interações entre atores e o sistema, as User Stories são mais enxutas, escritas na perspectiva do usuário e focam no valor de negócio, priorizando a comunicação e a simplicidade.
User Story (XP): Características (Enxuta (2-3 frases), Foco no valor de negócio, Perspectiva do usuário, Prioriza comunicação); Diferenças dos Casos de Uso (UML) (User Story: descrição simplificada, Caso de Uso: narrativa detalhada); Regras (Implementada em 1 iteração, Escrita independente, Priorização pelo cliente (Planning Game), Critérios de aceitação separados); Relação com Caso de Uso (Uma User Story = um ou mais cenários)
Alternativa A — ❌ Incorreta
Afirma que histórias podem ser construídas em mais de uma iteração. No XP, cada User Story deve ser implementada dentro de uma única iteração (normalmente 1-3 semanas). Histórias grandes devem ser quebradas em menores para caber em uma iteração. Construir em mais de uma iteração contraria o princípio de entregas contínuas e incrementais.
Alternativa B — ❌ Incorreta
Diz que é necessário ordenar a escrita das histórias, visto que há uma dependência entre elas. No XP, as histórias são escritas de forma independente, e sua priorização é feita pelo cliente no Planning Game com base no valor de negócio, não em dependências técnicas. Embora dependências possam existir, a escrita não é rigidamente ordenada por elas; a flexibilidade é essencial.
Alternativa C — ❌ Incorreta
Sugere detalhar os critérios de testes a serem executados com base na história. As User Stories no XP são curtas (geralmente 2-3 frases) e não incluem detalhes de teste. Os critérios de aceitação podem ser definidos, mas os testes são escritos separadamente pelos desenvolvedores (TDD). A alternativa confunde User Stories com especificações detalhadas de Casos de Uso.
Alternativa D — ✅ Correta ⟵ GABARITO
considerar que uma história pode ser um ou mais cenários em um caso de uso — Exato. No XP, as User Stories substituem os Casos de Uso tradicionais. Uma User Story representa um cenário (fluxo principal ou alternativo) do que seria descrito em um Caso de Uso. Essa é a visão aceita na literatura ágil.
Alternativa E — ❌ Incorreta
focar nos objetivos do usuário e em como a interação com o sistema satisfaz esses objetivos — Essa descrição é típica de Casos de Uso, que detalham a interação passo a passo. As User Stories focam no valor de negócio e são escritas na voz do usuário, mas não descrevem a interação em si; elas são um lembrete para uma conversa futura. A redação da alternativa se aproxima mais de um Caso de Uso do que de uma User Story.
NÃO CAIA NESSA!
A alternativa E parece correta porque User Stories também se preocupam com o usuário, mas o detalhamento da interação é próprio de Casos de Uso. A banca explora essa fronteira sutil. Lembre-se: User Stories são curtas e focam no porquê (valor), não no como (interação detalhada).