Questões de Concurso Comentadas por alunos sobre rup (rational unified process) - processo unificado rational em engenharia de software
Foram encontradas 493 questões
Resolva questões gratuitamente!
Junte-se a mais de 4 milhões de concurseiros!
Julgue o próximo item, relativos ao RUP (Rational Unified Process).
O RUP não é um processo apropriado para todos os tipos
de desenvolvimento de software.
Julgue o próximo item, relativos ao RUP (Rational Unified Process).
O RUP é um exemplo de modelo de processo que apoia
a prototipação e a entrega incremental de softwares. No
entanto, ele não consegue combinar as perspectivas
estática e dinâmica em um único diagrama.
Considere as características abaixo.
I. Colaboração e desenvolvimento de empatia entre integrantes das equipes com foco no projeto e não em interesses pessoais.
II . Reuniões com a participação de profissionais de várias áreas necessárias para o projeto (desenvolvimento, operações, apoio).
III . Utilização de metodologias ágeis como RUP, XP e/ou Scrum para permitir entregas rápidas e contínuas.
IV. Implementação do gerenciamento de configuração para que mudanças realizadas manualmente nos servidores, sem conhecimento da gerência de configurações, sejam desfeitas.
V. Estratégias para gestão de incidentes bem definidas, políticas de rollback, backup e ferramentas de monitoração proativas.
VI. Ambientes necessários para o trabalho da equipe de desenvolvimento providos de forma dinâmica e automatizada, sem necessidade de intervenção da equipe de operações.
São características corretas e alinhadas às práticas DevOps APENAS os itens
Considere que um Analista de Sistemas sugeriu a implementação de um novo projeto com base em um processo de software que organiza suas iterações em quatro fases principais:
[1] Concepção: levantar, de forma genérica e pouco precisa, o escopo do projeto. O objetivo é ter uma visão inicial do problema, estimar esforço e prazos e determinar se o projeto é viável e merece uma análise mais profunda.
[2] Elaboração: levantar todos, ou a maior parte dos requisitos. Em uma primeira iteração alguns requisitos, de maior risco e valor arquitetural, são especificados em detalhes, implementados e servem como base de avaliação junto ao usuário e desenvolvedores para o planejamento da próxima iteração. Ao fim da fase, 90% dos requisitos devem ter sido levantados em detalhes, o núcleo do sistema deve ter sido implementado com alta qualidade, os principais riscos devem ter sido tratados, podendo-se fazer estimativas mais realistas.
[3] Construção: implementar, de forma iterativa, os elementos restantes de menor risco e mais fáceis e preparação para a implantação.
[4] Transição: realizar testes finais e implantação.
O processo de software indicado pelo Analista é o