Questões de Concurso Comentadas para emgepron

No desenvolvimento de software, o início para toda a atividade parte do levantamento de requisitos, sendo repetida em todas as demais etapas da engenharia de requisitos. Sommerville propõe um processo genérico de levantamento e análise que contém diversas atividades, sendo três delas detalhadas a seguir.
I. É o processo de interagir com os stakeholders do sistema para descobrir seus requisitos, e a compreensão do domínio se desenvolve mais durante essa atividade. II. É um estágio que envolve interação com os stakeholders para a definição dos requisitos mais importantes, considerando que, em qualquer conjunto de requisitos, alguns serão mais importantes do que outros. III. É o processo que realiza uma análise dos requisitos para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema.
As atividades detalhas em I, II e III são conhecidas, respectivamente, como:

Um processo de desenvolvimento de software pode ser visto como um conjunto de fases organizadas, usadas para definir, desenvolver, testar e manter um software. Existem diversos processos, cabendo destacar que há algumas fases básicas comuns à grande parte dos existentes. Em uma dessas fases, o sistema é codificado a partir da descrição computacional da fase de projeto em uma outra linguagem, onde se torna possível a compilação e geração do código - executável para o desenvolvimento software. Em um processo de desenvolvimento orientado a objetos, essa etapa ocorre definindo as classes de objetos do sistema em questão, fazendo uso das linguagens de programação. Pode-se também utilizar ferramentas de software e bibliotecas de classes preexistentes para agilizar a atividade, como também o uso de ferramentas CASE, que dinamizam o processo de desenvolvimento, nas várias atividades, onde inclui-se geração de código-fonte e documentação.
Essa fase é denominada:

Na implementação de bancos de dados relacionais, busca-se solucionar ou minimizar dois problemas, descritos a seguir.
I. Está associado à ocorrência de informações armazenadas em arquivos separados, com conteúdos diferentes. II. Está associado à existência das mesmas informações em aplicações diferentes, como por exemplo, em arquivos de material e de registros de projetos.
As descrições em I e em II referem- se, respectivamente, aos seguintes termos:

No contexto da Análise e Projeto de Sistemas e do processo de desenvolvimento de software, a UML reconhece três tipos mais importantes de relações, conceituadas a seguir.
I. São relacionamentos estruturais entre instâncias e especificam que objetos de uma classe estão ligados a objetos de outras classes, podendo existir entre classes ou entre objetos. II. São relacionamentos de utilização no qual uma mudança na especificação de um elemento pode alterar a especificação do elemento dependente. Este tipo de relação entre classes indica que os objetos de uma classe usam serviços dos objetos de outra classe. III. São relacionamentos entre um elemento mais geral e um mais específico. O elemento mais específico herda as propriedades e métodos do elemento mais geral. Este tipo de relação é também conhecida como herança no modelo a objetos, existindo só entre as classes.
Os tipos descritos em l, ll e lll são, respectivamente:

Diversas técnicas ou ferramentas foram criadas ou buscadas pela gestão com foco na Qualidade no sentido de apoiar a realização dos seus projetos ou atividades que executa. O Diagrama de causa e efeito, também conhecido por “Diagrama Espinha de Peixe”, significa: