

Seu próximo nível começa aqui
Seu desenvolvimento não pode ter limites. Garanta sua Assinatura Ilimitada e libere uma preparação completa com os melhores professores do Brasil.
Leia o fragmento de texto a para responder as QUESTÕES 28 e 29.
Na década de 1980 e início de 1990, havia uma visão generalizada de que a melhor maneira para conseguir o melhor software era por meio de um planejamento cuidadoso do projeto, qualidade da segurança formalizada, do uso de métodos de análise e projeto apoiado por ferramentas CASE (Computer aided software engineering) e do processo de desenvolvimento de software rigoroso e controlado. Essa percepção veio da unidade de engenharia de software, responsável pelo desenvolvimento de sistemas de software grandes e duradouros, como sistemas aeroespaciais e de governo.
Esse software foi desenvolvido por grandes equipes que trabalham para diferentes empresas. Geralmente, as equipes eram dispersas geograficamente e trabalhavam com o software por longos períodos. Um exemplo desse tipo de software é o sistema de controle de uma aeronave moderna, que pode demorar até dez anos, desde a especificação inicial até a implantação.
Tais abordagens dirigidas a planos envolvem um overhead significativo no planejamento, projeto e documentação do sistema. Esse overhead se justifica quando o trabalho de várias equipes de desenvolvimento pode ser coordenado, quando o sistema é um sistema crítico e quando muitas pessoas diferentes estão envolvidas na manutenção do software durante a sua vida. (adaptado).
Em relação aos princípios dos modelos ágeis de desenvolvimento de software, assinale a alternativa INCORRETA.
Envolvimento do cliente: Os clientes devem estar intimamente envolvidos no processo de desenvolvimento. Seu papel é fornecer e priorizar novos requisitos do sistema e avaliar suas iterações.
Entrega incremental: O software é desenvolvido em incrementos com o cliente, especificando os requisitos para serem incluídos em cada um.
Pessoas, não processos: As habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas. Membros da equipe devem desenvolver suas próprias maneiras de trabalhar, sem processos prescritivos.
Não aceitar mudanças: Deve-se considerar que os requisitos do sistema não vão mudar. Por isso, projete o sistema de maneira que não seja necessário efetuar mudanças.
Manter a simplicidade: Deve-se focalizar a simplicidade, tanto do software a ser desenvolvido quanto do processo de desenvolvimento. Sempre que possível, indica-se trabalhar ativamente para eliminar a complexidade do sistema.