Questões de Engenharia de Software - RUP (Rational Unified Process) - Processo Unificado Rational para Concurso
Foram encontradas 503 questões
I. Identificar os maiores riscos do projeto e, no final da fase, apresentar um modelo de requisitos para o sistema, que pode ser um conjunto de casos de uso da UML, uma descrição da arquitetura ou um plano de desenvolvimento do software.
II. Elaborar o projeto do sistema e o desenvolvimento, em paralelo, das partes do sistema e sua integração.
III. Com base em informações originadas de business cases estabelecidos para o sistema, identificar todas as entidades externas (pessoas e sistemas) que vão interagir com o sistema e definir as interações. Essas informações são usadas para avaliar a contribuição do sistema para o negócio.
Essas atividades são, correta e respectivamente, abordadas nas fases do Rational Unified Process (RUP):
I. A fase de transição se concentra nas atividades necessárias para colocar o software nas mãos dos usuários. Tipicamente, essa fase inclui várias iterações, incluindo versões beta, versões de disponibilidade geral, além de correções de erros e lançamentos de aprimoramento. Um esforço considerável é gasto em atividades ligadas ao usuário: documentação de sistema, treinamento e suporte no uso inicial do produto. Neste ponto, no entanto, o feedback do usuário deve limitar-se principalmente a problemas de ajuste, configuração, instalação e usabilidade do produto.
II. Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. A transparência requer que estes aspectos tenham uma definição padrão comum para que os observadores compartilhem um mesmo entendimento do que está sendo visto. Por exemplo: uma linguagem comum referindo-se ao processo deve ser compartilhada por todos os participantes; e aqueles que realizam o trabalho e aqueles que inspecionam o incremento resultado do trabalho devem compartilhar uma definição comum de Pronto.
III. A implementação inicial do software apoia duas atividades do processo de engenharia de requisitos: a) levantamento de requisitos, pois os usuários podem realizar experiências para ver como o sistema apoia seu trabalho, podendo ter novas ideias para os requisitos, identificar pontos positivos e negativos do software e até propor novos requisitos de sistema; b) validação de requisitos, pois a implementação pode revelar erros e omissões nos requisitos propostos, levando os usuários a crerem que sua visão inicial era incorreta e incompleta e dando a eles oportunidade de fazerem ajustes na especificação de sistema para refletir sua compreensão alterada dos requisitos.
IV. O cliente está sempre participando do desenvolvimento do sistema; testes de unidade e de aceitação fornecem feedback sobre o sistema; oportunidades e problemas são identificados o mais rápido possível; os códigos são integrados e testados constantemente, para o caso de algum problema ser detectado, poder ser corrigido imediatamente.
As características I, II, III e IV são, respectivamente,
( ) Estática – essa perspectiva mostra as atividades realizadas no processo. ( ) Prática – essa perspectiva mostra as fases do modelo ao longo do tempo. ( ) Dinâmica – essa perspectiva sugere as boas práticas a serem usadas durante o processo.
As afirmativas são, respectivamente,