Questão de Engenharia de Software — Processos de Software - Desenvolvimento Ágil — FCC 2015
Engenharia de Software›Processos de Software - Desenvolvimento Ágil
Código
fc026145
Banca
FCC
Órgão
TRT - 3ª Região (MG)
Ano
2015
Nível
Médio
Cargo
Técnico Judiciário - Área Tecnologia da Informação
Um técnico de TI está trabalhando em um projeto de desenvolvimento de software que utiliza metodologias ágeis e está acompanhando as histórias de usuários, que descrevem as funcionalidades que o software deve ter e
Apodem ser utilizadas para definir os testes unitários, mas não testes de aceitação.
Bdevem ser implementadas, cada uma, em até 8 semanas.
Cprecisam refletir os aspectos técnicos do software, não apenas a visão dos envolvidos.
Ddevem ser escritas segundo o ponto de vista do analista de sistemas.
Eservem ao mesmo propósito de casos de uso, mas não são a mesma coisa.
Revelar gabarito e comentário▾
GabaritoE — servem ao mesmo propósito de casos de uso, mas não são a mesma coisa.
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”.
Histórias de Usuário em Metodologias Ágeis
Gabarito: letra E. Histórias de usuário e casos de uso têm o mesmo propósito de descrever requisitos funcionais, mas são artefatos distintos: histórias de usuário são informais, curtas e focadas no valor de negócio, enquanto casos de uso são detalhados e formais. É justamente essa diferença que a alternativa E captura corretamente.
A banca testa o conhecimento sobre o conceito e a finalidade das histórias de usuário, um pilar das metodologias ágeis. Cada alternativa explora um possível equívoco comum.
Histórias de usuário (Ágil): Propósito (Descrever requisitos funcionais, Foco no valor de negócio); Características (Informais e curtas, Linguagem do negócio, Perspectiva do usuário, Critérios de aceitação); Prazo (Cabe em sprints (1 a 4 semanas), Sem prazo fixo de 8 semanas); Comparação com casos de uso (Mesmo propósito (requisitos), Casos de uso: detalhados e formais)
Alternativa A — ❌ Incorreta
Afirma que histórias de usuário só podem definir testes unitários, e não testes de aceitação. Erro: em métodos ágeis, as histórias de usuário são a base para os testes de aceitação (critérios de aceitação definidos na própria história). Testes unitários são voltados ao código interno e não derivam diretamente das histórias de usuário.
Alternativa B — ❌ Incorreta
Diz que cada história deve ser implementada em até 8 semanas. Erro: não há prazo fixo. Em métodos ágeis, as histórias de usuário são quebradas de modo a caber em iterações curtas (sprints), geralmente de 1 a 4 semanas. O prazo de 8 semanas é muito longo para uma única história e não é uma regra ágil.
Alternativa C — ❌ Incorreta
Sugere que as histórias devem refletir aspectos técnicos. Erro: histórias de usuário são escritas na linguagem do negócio, focando no valor para o usuário, e não em detalhes técnicos. Aspectos técnicos são tratados nas tarefas de implementação durante o desenvolvimento.
Alternativa D — ❌ Incorreta
Indica que as histórias devem ser escritas do ponto de vista do analista de sistemas. Erro: o ponto de vista correto é o do usuário ou cliente. O formato típico é "Como um [papel], quero [funcionalidade] para [benefício]". O analista de sistemas pode ajudar a redigir, mas a perspectiva deve ser do usuário.
Alternativa E — ✅ Correta ⟵ GABARITO
Afirma que histórias de usuário servem ao mesmo propósito de casos de uso (descrever funcionalidades), mas não são a mesma coisa. Correto: ambos capturam requisitos, mas com diferenças: histórias de usuário são mais leves, informais e ágeis; casos de uso são mais estruturados, formais e típicos de processos tradicionais. A afirmação é precisa e alinhada com a literatura de engenharia de software.
NÃO CAIA NESSA!
Na alternativa A, a banca tenta confundir o papel das histórias de usuário na definição de testes. Lembre-se: histórias de usuário guiam testes de aceitação, não unitários. Já na alternativa B, o prazo de 8 semanas é inventado — não há regra fixa; o correto é que as histórias sejam implementadas em iterações curtas.
Gabarito: letra E — histórias de usuário e casos de uso têm propósito similar, mas são artefatos diferentes.