Questões de Engenharia de Software - Processos de Software - Desenvolvimento Ágil para Concurso
Foram encontradas 1.284 questões
Em relação ao desenvolvimento e à sustentação de software e ao gerenciamento de produtos de software, julgue o item a seguir.
Enquanto o scrum master é responsável por garantir que a
equipe siga a metodologia Scrum, o product owner em uma
equipe Scrum pode ser um cliente externo que define as
necessidades e prioridades do produto.
Leia o fragmento de texto a seguir para responder a questão.
Ao término de cada Sprint, o método ágil Scrum promove uma análise profunda do processo de trabalho, das pessoas envolvidas e da dinâmica entre elas, bem como das ferramentas utilizadas, por meio de perguntas reflexivas como “Outras metodologias podem ser úteis?”, “Quais pontos positivos e negativos podemos identificar?” e “Em quais aspectos podemos evoluir?”. (adaptado).
Ainda sobre a etapa de Sprint do método ágil Scrum, assinale a
alternativa CORRETA.
Leia o fragmento de texto a para responder a questão.
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).