Um analista deve escolher uma metodologia de desenvolvimento para elaborar o planejamento do ciclo de vida de um produto de software de larga escala. O sistema é inédito e o reúso de código semelhante não deve ser considerado como base para o novo desenvolvimento. O analista deve considerar, ainda, a necessidade de reduzir os riscos em todas as fases do projeto, pois é provável que os requisitos sejam aprimorados e mudem ao longo do processo. Entre os riscos a serem mitigados, está o de não ter sido contratado pessoal de software suficiente para construir o produto, além de a equipe contratada não ter experiência suficiente no desenvolvimento de produtos em larga escala. Ainda, há o risco de o fornecedor do hardware necessário ao projeto não entregar todas as estações clientes no prazo do contrato. Nessa situação hipotética, para a metodologia do processo de software em questão, é mais apropriado o uso do
- A)modelo codificar-e-corrigir.
Errada, porque o modelo codificar-e-corrigir é improvisado e inadequado para um projeto grande, inédito e com muitos riscos.
- B)modelo espiral.
Certa, porque o modelo espiral é orientado à análise e mitigação de riscos em ciclos, ideal para sistemas novos, complexos e com requisitos mutáveis.
- C)modelo integração e configuração.
Errada, porque integração e configuração é mais ligado a montagem de sistemas por componentes e reaproveitamento, o que o enunciado descarta.
- D)modelo baseado em protótipos.
Errada, porque prototipação ajuda a esclarecer requisitos, mas não é o modelo mais completo para controlar os riscos de um projeto de grande porte.
- E)modelo em cascata.
Errada, porque o cascata é linear e pouco flexível, funcionando mal quando os requisitos podem mudar ao longo do processo.
Gabarito: B
Quando o sistema é grande, novo e cheio de incertezas, a escolha do processo de software não pode ser “no grito”. Se os requisitos podem mudar, se há riscos técnicos e organizacionais importantes e se ainda existe dúvida sobre equipe, prazo e recursos, o melhor caminho é um modelo que trate riscos de forma explícita e contínua. É exatamente aí que o modelo espiral brilha. Ele organiza o desenvolvimento em ciclos, e em cada volta você planeja, analisa riscos, desenvolve e avalia com o cliente. Ou seja: em vez de apostar tudo em uma sequência rígida, você vai reduzindo incertezas aos poucos, o que combina muito com projetos inéditos e de larga escala. No enunciado, aparecem vários riscos clássicos: equipe insuficiente, falta de experiência em produtos grandes, possível atraso na entrega de hardware e requisitos que tendem a evoluir. Isso é praticamente um convite para um processo orientado a riscos. O modelo espiral foi proposto por Barry Boehm justamente com esse foco, sendo muito usado quando o projeto é complexo e os riscos precisam ser atacados desde cedo. As outras opções até existem no mundo real, mas aqui não casam com o cenário. Cascata é rígido demais, prototipação ajuda a entender requisitos, mas não é a melhor resposta quando o coração do problema é gerenciamento de riscos em escala. Por isso, o gabarito B é o mais apropriado.