Considerando os conceitos fundamentais da Engenharia de Software, o Ciclo de Vida do Desenvolvimento de Software (CVDS) e os critérios de Qualidade de Software, sobre a implementação de práticas de qualidade ao longo do CVDS, analise as afirmativas a seguir. I. A análise de requisitos, uma fase inicial do CVDS possui menor impacto na qualidade do software final que os testes finais do software. II. Testes de software, realizados apenas na fase final do desenvolvimento, são suficientes para garantir a qualidade do software. III. A revisão de código e a refatoração são práticas que podem ser aplicadas em várias fases do CVDS para melhorar a manutenibilidade e a qualidade do software, mas são mais eficazes na fase de elaboração e construção. Está correto o que se afirma em
- A)I, apenas.
Esta alternativa sustenta que apenas a afirmativa I estaria correta, isto é, que a análise de requisitos teria menor impacto na qualidade final do que os testes feitos no fim. No mérito, isso inverte a lógica da Engenharia de Software: defeitos de requisitos costumam contaminar arquitetura, implementação e testes, sendo muito mais caros de corrigir depois, enquanto testes finais apenas revelam problemas já introduzidos. Por isso, a assertiva I não se sustenta.
- B)III, apenas.
Esta alternativa afirma que somente a afirmativa III está correta, e o conteúdo dela é tecnicamente consistente. Revisão de código e refatoração são práticas de qualidade que podem ocorrer ao longo de várias etapas do ciclo de vida, mas ganham muito em eficácia quando aplicadas durante a elaboração e a construção, pois o software ainda está em evolução e a correção de problemas estruturais é mais barata. Elas melhoram principalmente a manutenibilidade, a clareza e a qualidade interna do código.
- C)I e II, apenas.
Aqui se diz que I e II estariam corretas, ou seja, que requisitos teriam menos impacto que testes finais e que testar só no fim bastaria para garantir qualidade. As duas ideias são contrariadas pelos fundamentos da Engenharia de Software: a qualidade deve ser incorporada desde o início e não pode ser assegurada apenas por testes tardios, que detectam falhas, mas não substituem boas práticas de levantamento, projeto e construção. Assim, a alternativa combina duas premissas incorretas.
- D)I e III, apenas.
Esta opção reúne I e III, então aceita a tese de que a análise de requisitos teria menor impacto que os testes finais e também a de que revisão de código e refatoração são úteis em várias fases, sobretudo na elaboração e construção. O problema está na primeira parte: requisitos mal definidos têm forte efeito sobre o produto final e sobre o custo de correção, de modo que testes ao final não superam a importância da fase inicial. A presença de III, que está correta, não salva a alternativa.
- E)II e III, apenas.
Nesta alternativa, sustenta-se que II e III seriam verdadeiras, isto é, que testes realizados apenas ao final seriam suficientes para garantir qualidade e que revisão de código e refatoração teriam papel relevante ao longo do ciclo. A segunda parte está correta, mas a primeira é incompatível com o conceito de qualidade de software, que depende de prevenção, verificação contínua e práticas distribuídas pelo CVDS, e não só de testes finais. Assim, o erro específico está em superestimar o poder dos testes no encerramento do desenvolvimento.
Gabarito: B
No CVDS, qualidade nao e algo que voce deixa para o “testezinho final”. Ela precisa ser construida desde o comeco, porque corrigir erro cedo costuma ser muito mais barato do que descobrir tudo na reta final. Por isso, fases como levantamento e analise de requisitos sao decisivas: se o requisito vem torto, o sistema inteiro pode nascer torto tambem. A afirmativa I esta errada porque a analise de requisitos costuma ter enorme impacto na qualidade do software final. Um requisito mal entendido gera retrabalho, defeitos de projeto e insatisfacao do usuario. Em Engenharia de Software, a velha regra vale forte: quanto mais cedo voce encontra o problema, menor o estrago. A afirmativa II tambem esta errada. Testes sao essenciais, mas nao fazem milagre sozinhos. Qualidade envolve preventivamente boas praticas ao longo de todo o ciclo: boa especificacao, projeto limpo, codigo bem feito, revisao, integracao e testes em varios niveis. Testar no fim ajuda a encontrar defeitos, mas nao compensa falhas de processo anteriores. Ja a afirmativa III esta correta. Revisao de codigo e refatoracao realmente podem aparecer em varias fases, mas fazem mais sentido e rendem mais durante elaboracao e construcao, quando o codigo ainda esta sendo moldado. Isso melhora manutenibilidade, reduz complexidade e aumenta a qualidade geral do produto. Em resumo: qualidade nao eh “apertar o botao testar”; eh um trabalho continuo ao longo do ciclo inteiro.