-
Segundo Pressman, os modelo não podem ser rígidos, mas ágeis e adaptáveis. Segue o trecho de seu livro:
"Anteriormente, declarei que o processo de engenharia de software não é rígido nem deve ser seguido à risca. Mais que isso, ele deve ser ágil e adaptável (ao problema, ao projeto, à equipe e à cultura organizacional). Portanto, o processo adotado para um determinado projeto pode ser muito diferente daquele adotado para outro.". Pressmam, 7ª Ed, Pag: 42.
-
A questão diz que, quando há necessidade do levantamento completo dos requisitos antes da implementação, o modelo é rígido.
Não está certo isso?
-
A questão está certa, quando é rígido tem que ser feito todo o levantamento completo dos requisitos; quando é flexível os requisitos são feitos a medida que o projeto progride. Não vi nada de errado na assertiva.
-
A "necessidade de os requisitos serem completamente levantados antes de se iniciar a implementação das funcionalidades" não torna o modelo (como um todo) rígido.
-
Acredito que o erro da alternativa é afirmar que os modelos são considerados rígidos se houver a obrigatoriedade do levantamento prévio e completo de requisitos.
O modelo em cascata, considerado rígido, apresenta o processo de desenvolvimento como uma SÉRIE DE ESTÁGIOS obrigatoriamente sequenciais. "A fase seguinte não deve começar até que a fase anterior tenha terminado." (Sommerville)
Estágios do modelo em cascata:
Definição dos requisitos > Projeto do sistema e do software > Implementação e teste de unidade > Integeração e teste de sistema > operação e manutenção (Sommerville)
Fone: Engenharia de Software, Ian Sommerville, décima edição, Pearson Education do Brasil
-
Gabarito: Errado.
A questão traz que a necessidade de os requisitos serem completamente levantados antes de se iniciar a implementação das funcionalidades é a causa de um modelo ser rígido. O que está errado. É uma consequência.
A causa de um modelo ser considerado rígido é quando ele não aceita bem mudanças em suas fases, o que o torna rígido e, por consequência, teremos de levantar todos os requisitos antes de começar a implementar, pois ele não aceita bem mudanças.