Compartilhando | Teste 3: Engenharia de Software – Todas as Matérias da Disciplina

#1. (FCC – SEFAZ/SP/2013) Os mecanismos de controle de versão, integrados com o processo de controle de modificações, implementam dois elementos importantes do controle de modificação. São eles:
I. Determina quais engenheiros de software podem acessar e modificar um determinado objeto de configuração.
II. Ajuda a garantir que modificações paralelas, realizadas por duas pessoas diferentes, não se sobreponham.
Os elementos I e II são, respectivamente:

Controle de configuração e Controle de modificação.

Controle de segurança e Controle de atualização.

Controle de versão e Controle de modificação.

Gerência de acessibilidade e Gerência de modificabilidade.

Controle de acesso e Controle de sincronização.

#2. (FUNCAB – SESACRE/2014) No diagrama de casos de uso, as pessoas ou entidades externas que integram, interagem ou desempenham algum papel no sistema, são conhecidas como:

casos de uso.

objetos.

atores.

mensagens.

classes.

#3. (IESES – TRE-MA/2015) Na programação orientada a objetos, o relacionamento do tipo herança entre classes traz alguns benefícios dos quais se destacam:

A superclasse melhora seu desempenho na execução de operações.

A subclasse recebe todos os objetos da classe pai.

Reuso de programa ou partes do modelo, definição consistente de definição de interfaces e traz suporte ao desenvolvimento incremental.

A superclasse recebe da subclasse um conjunto de operações já implementadas.

#4. (ESAF – 2004 – CGU) No desenvolvimento Orientado a Objetos usando UML, um prefixo é incorporado a um nome de atributo ou nome de operação para indicar a visibilidade da propriedade. Com relação ao prefixo utilizado com esta finalidade, é correto afirmar que os atributos ou operações

privadas são prefixados com o sinal de subtração (-).

privadas são prefixados com o símbolo de número (#).

protegidas são prefixados com o sinal de subtração (-).

públicas são prefixados com o sinal de subtração (-).

públicas são prefixados com o sinal de adição (+).

#5. (FCC – 2010 – DPE-SP) Sobre análise de requisitos da engenharia de software, considere:
I. Os requisitos de usuário podem descrever tanto requisitos funcionais quanto requisitos não-funcionais.
II. Os requisitos de sistema podem descrever apenas requisitos não funcionais.
III. Os requisitos não-funcionais podem ser divididos em requisitos de produto, organizacionais e externos.
Está correto o que se afirma em

II e III, apenas.

I, II e III.

I e III, apenas.

III, apenas.

I e II, apenas.

#6. (FCC – 2010 – DPE-SP) Na Engenharia de Software, a frase “identificar os aspectos importantes, ignorando os detalhes” define o princípio

Formalidade.

Generalização.

Flexibilização.

Abstração.

Decomposição.

#7. (CESPE – 2008 – STJ) Os requisitos de um sistema podem ser descrições dos serviços fornecidos ou restrições operacionais. Requisitos podem ainda ser classificados como funcionais, não funcionais, ou de domínio. A engenharia de requisitos visa compreender e definir os requisitos. Um processo de engenharia de requisitos pode envolver o estudo de viabilidade, a análise, a especificação e a validação de requisitos.

Falso

Verdadeiro

#8. (CESPE – 2008 – STJ) Entre as atividades em um processo de projeto de software, pode-se ter: a identificação e a documentação dos subsistemas existentes e os seus relacionamentos; a especificação dos serviços providos por cada subsistema e das restrições de operação dos mesmos; a documentação da interface entre subsistemas; a especificação de estruturas de dados e algoritmos usados.

Falso

Verdadeiro

#9. (CESPE – 2013 – INPI) A engenharia de requisitos demonstrada na forma de espiral compõe-se de três fases: elicitação de requisitos (compreensão de requisitos funcionais e de usuário), especificação de requisitos (requisitos de usuário e de sistema) e validação de requisitos (estudo de viabilidade, prototipação e revisão).

Falso

Verdadeiro

#10. (CESPE – 2013 – TCE-RO) Na análise estruturada, o modelo criado representa o fluxo e o conteúdo da informação, dividido em partições funcionais e comportamentais. Na análise orientada a objetos, o objetivo é modelar os objetos do domínio do produto, seus relacionamentos e comportamentos

Verdadeiro

Falso

#11. (ESAF – 2004 – CGU) Analise as seguintes afirmações relativas à Engenharia de Software:
I. A análise de requisitos é responsável pela especificação dos requisitos de software e hardware que serão utilizados durante o processo de desenvolvimento de um sistema.
II. A análise de requisitos define a metodologia de programação a ser utilizada no desenvolvimento do sistema.
III. A especificação de requisitos fornece ao desenvolvedor e ao cliente os parâmetros para avaliar a qualidade logo que o sistema for construído.
IV. A análise de requisitos possibilita que o engenheiro de software especifique a função e o desempenho do sistema e estabeleça quais são as restrições de projeto que o sistema deve atender.
Estão corretos os itens:

III e IV

I e II

II e III

I e III

II e IV

#12. (CESPE – 2013 – INPI) De acordo com os princípios da engenharia de software relacionados à independência funcional, os algoritmos devem ser construídos por módulos visando unicamente ao alto acoplamento e à baixa coesão, caso a interface entre os módulos dê-se pela passagem de dados.

Falso

Verdadeiro

#13. (CESPE – 2013 – TCE-RO) De acordo com a evolução dos requisitos, estes podem ser classificados em permanentes, que são gerados nas fases iniciais do desenvolvimento, e voláteis, que surgem ao longo do processo de construção do software.

Verdadeiro

Falso

#14. (FCC – INFRAERO/2011) Em relação às regras do Scrum, é INCORRETO afirmar:

O Sprint deve ser realizado num período máximo de 40 dias e ter uma equipe de trabalho não superior a 10 pessoas.

As reuniões durante um Sprint devem ser diárias, sempre à mesma hora e no mesmo local e não devem durar mais que 30 minutos.

Se o Sprint tomar um rumo não desejado, é possível dissolvê-lo e começar um novo Sprint, baseando num novo Sprint Backlog.

Toda conversação restringe as respostas dos participantes às três perguntas do Scrum Master: O que desenvolveu desde a última reunião? Que dificuldades encontrou durante o seu trabalho? O que planeja desenvolver até a próxima reunião?

Com base nas respostas às três perguntas, o Scrum Master deve imediatamente tomar decisões, quando necessárias, para remover todas as situações que impeçam a agilidade do trabalho.

#15. (ESAF – 2004 – CGU) Na modelagem com UML, o Diagrama de Casos de Uso fornece

o comportamento estático do ator que participa deste diagrama, apenas com o objetivo de receber a informação final de execução do processo.

um gráfico de atores montado sem a especificação de domínio, comunicações ou associações entre atores

o contexto completo de uma interação, inclusive os objetos e seus relacionamentos pertinentes a uma interação particular.

um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível da funcionalidade do sistema mediante uma requisição do usuário.

o comportamento dinâmico do sistema, tornando-se ideal para especificar as exigências de tempo real ou restrições do desenho.

#16. (ESAF – 2004 – CGU) Analise as seguintes afirmações relativas à UML:
I. A identidade de objeto é a propriedade pela qual cada objeto, dependendo apenas de sua classe ou estado, pode ser identificado e tratado como uma entidade distinta de software. Este princípio de dependência entre a identidade de um objeto e seu estado viabiliza a herança nas linguagens orientadas a objetos.
II. Na UML, a construção da generalização é representada como uma seta com uma ponta “aberta” e permite ao desenho indicar tanto a herança simples quanto a herança múltipla.
III. Um atributo será considerado de estado quando puder assumir valores infinitos com transições ilimitadas entre eles.
IV. Uma associação na UML representa um conjunto de vínculos de relacionamento entre instâncias de classe.
Estão corretos os itens:

II e III

II e IV

I e II

III e IV

I e III

#17. (ESAF – 2004 – CGU) Na modelagem com UML, um Diagrama de Seqüência mostra interações de objetos organizados em uma seqüência de tempo

mas quando utilizado para representar a autodelegação ou mensagem de autochamada assíncrona, não trata o tempo como uma dimensão separada.

mas não trata associações entre os objetos.

definindo todos os possíveis estados de um sistema.

mas não trata a autodelegação ou mensagem de autochamada.

sendo largamente utilizado de forma individualizada para cada classe, com o objetivo de tornar o estudo simples o bastante para se ter um diagrama compreensível.

#18. (IESES – TRE-MA/2015) Uma classe associativa é usada em um diagrama de classe em UML quando:

Se deseja implementar um relacionamento do tipo composição abstrata.

Se deseja vincular atributos ou operações para um relacionamento entre uma ou mais classes ao invés de incorporá-los em uma das classes participantes do relacionamento.

Quando for uma situação particular de herança múltipla inversa.

Como forma alternativa para resolver o polimorfismo restritivo na subclasse.

#19. (IESES – TRE-MA/2015) Na UML, o relacionamento do tipo agregação compartilhada usado no diagrama de classes serve na situação de: ? A correção aparecerá no rodapé da questão, caso você erre ou não selecione uma opção de resposta.

Necessidade de modificar a operação construtora nas duas classes sendo relacionadas.

Encontrar objetos das classes e seus atributos usando o método.

Definir em OCL uma restrição entre essas classes.

Necessidade de expressar um relacionamento fraco do tipo todo-parte, pois referem-se a parte poder existe sem o todo.

Agregação é um tipo especial de associação onde tenta-se demonstrar que as informações de um objeto (chamado objeto-todo) precisam se complementadas pelas informações contidas em um ou mais objetos de outra classe (chamados objeto-parte).

Este tipo de associação tenta demonstrar uma relação Todo-Parte entre os objetos associados.

Para ler mais sobre o assunto, acesse: Agregação ( )

#20. (FCC – 2011 – INFRAERO) A métrica análise por pontos de função foi desenvolvida na década de 1970, como uma forma de medir software. Analise os itens a seguir relacionados a essa métrica:
I. Considera mais importante o número de linhas de código do que as funcionalidades criadas.
II. Pode ser aplicada antes do código ser escrito, baseando-se na descrição arquitetural do projeto.
III. É dependente da tecnologia utilizada no desenvolvimento.
IV. Dois programas muito diferentes podem possuir a mesma contagem de pontos de função.
Está correto o que consta em

I e III, apenas.

I, II, III e IV.

I, II e IV, apenas.

I, II e III, apenas.

II e IV, apenas.

#21. (FCC – SEFAZ/SP/2013) No cálculo do valor dos pontos de função, utiliza-se a seguinte expressão: O valor correto utilizado para X é ? Necessário decorar a fórmula.

0,65.

0,50.

1,25.

2,00.

1,00.

Para ler mais sobre o assunto, acesse: Estimativa por Ponto de Função ( )

#22. (FCC – SEFAZ/SP/2013) A análise por pontos de função utiliza alguns domínios de informação para quantificar o produto software. Dentre tais domínios, incluem-se ? A correção aparecerá no rodapé da questão, caso você erre ou não selecione uma opção de resposta.

a velocidade de processamento e o número de consultas externas.

o número de comandos do tipo case e a quantidade de memória utilizada.

o número de entradas e saídas externas e o número de consultas externas.

a quantidade de memória e o número de tabelas utilizadas no sistema.

o número de tabelas utilizadas no sistema e o número de comandos do tipo case.

Valores do domínio de informação são definidos da seguinte maneira:

1) Número de arquivos lógicos internos (ALI ou Internal Logical Files – ILFs);

2) Número de Interfaces externas (AIE);

3) Número de entradas externas (EE ou External Inputs – Eis);

4) Número de consultas externas (CE ou External Inquiries – EQs);

5) Número de saídas externas (SE ou External Output – Eos).

Para ler mais sobre o assunto, acesse: Estimativa por Ponto de Função ( )

#23. (FCC – INFRAERO/2011) No RUP, definir quais são os atores, os casos de uso existentes e como eles interagem entre si é função típica do

Designer de Negócios.

Revisor do Modelo de Negócios.

Revisor de Requisitos.

Analista do Processo de Negócios.

Analista de Sistemas.

#24. (FCC – INFRAERO/2011) Em projetos pequenos, o RUP pode reduzir os requisitos de artefato para se comparar ao equivalente de artefatos em projeto de XP. Nesse sentido, considere o quadro de equivalência entre os artefatos do XP e RUP: Está correto o que consta APENAS em

III, IV e V.

I, II e III.

II, III e V.

II, IV e V.

I, II e IV.

#25. (FCC – SEFAZ/SP/2013) A empresa Express conta com diversas equipes de desenvolvimento, nas áreas de software em geral, incluindo técnicas estruturadas e de orientação a objetos. Essas equipes estão em constante aperfeiçoamento, visando mantê-las sempre atualizadas com as técnicas mais recentes da engenharia de software, incluindo-se aí a área de bancos de dados.
A Express atende clientes de diversos perfis, abrangendo pequenas, médias e grandes empresas. Dessa forma, os sistemas de computação solicitados também atendem a esse perfil, compreendendo sistemas de pequeno, médio e grande porte.
A Express conta com equipes especializadas, de grande experiência nas áreas acima destacadas, estando, portanto, apta a atender desde um simples produto até um grande sistema de software. Dessa forma, os produtos desenvolvidos pela Express possuem, normalmente, uma qualidade bastante apurada, o que pode ser verificado pelas diversas técnicas existentes.
Uma das normas da Express é a de produzir documentação de excelente qualidade, cuja finalidade é, não apenas para entrega aos clientes, mas também para possibilitar a manutenção adequada dos produtos desenvolvidos.
A Express utiliza diversos ciclos de vida de desenvolvimento de software, conforme o acordo feito com cada cliente. Em se tratando dos ciclos de vida de desenvolvimento de software, a maioria dos processos considera, na etapa de especificação do software, as seguintes atividades a serem realizadas:
A − Especificação de Requisitos
B − Levantamento e Análise de Requisitos
C − Estudo de Viabilidade
D − Validação de Requisitos
A ordem indicada para a realização dessas atividades é

B – A – D – C.

A – D – B – C.

A – B – C – D.

D – A – B – C.

C – B – A – D.

#26. (FUNCAB – SESACRE/2014) No desenvolvimento de software, são fases do modelo em cascata: ? O Modelo em Cascata apresenta as seguintes etapas: • ANÁLISE: análise de engenharia de sistemas: quanto mais dados forem coletados em nível de sistema, menor a probabilidade de haver defeitos; análise de requisitos de software: levantamento das necessidades do cliente, em relação aos recursos e funcionalidades. • PROJETO: concentra-se em quatro atributos: estrutura de dados, arquitetura de software, detalhes de procedimentos e caracterização de interface; • CODIFICAÇÃO: tradução do projeto em linguagem de máquina; • TESTES: procura de defeitos; • IMPLEMENTAÇÃO/manutenção: entrega, manutenção e feedback.

análise de viabilidade, projeto, validação, testes e manutenção.

planejamento, análise de risco, validação e testes.

análise de requisitos, projeto, codificação, testes e manutenção.

análise de requisitos, desenvolvimento, testes e validação.

concepção, desenvolvimento, testes e manutenção.

#27. (CESPE – 2013 – TCE-RO) A gerência de requisitos deve manter a matriz de rastreabilidade atualizada para, caso o cliente solicite uma mudança, o item de configuração correspondente seja implementado.

Verdadeiro

Falso

#28. (FCC – 2014 – TRF – 3ª REGIÃO) A figura abaixo mostra um diagrama com as atividades relativas ao levantamento de requisitos. O diagrama e a lacuna da caixa em branco referem-se, respectivamente, aos diagramas UML de

Componentes e Atividade.

Fluxo de Dados e Atividade.

Atividade e Casos de Uso.

Sequência e Casos de Uso.

Requisitos e Classes.

#29. (UFMT – UFSBA/2017) O modelo de desenvolvimento de software Processo Unificado (PU) é constituído de fases e disciplinas. Cada disciplina possui seu próprio fluxo de trabalho (workflow). Analise a figura a seguir.

Qual o nome da disciplina do PU representada pelo workflow ilustrado na figura? ? A correção aparecerá no rodapé da questão, caso você erre ou não selecione uma opção de resposta.

Requisitos

Análise e design

Implementação

Implantação

Correto: Análise e design

A Análise e Projeto busca mostrar como o sistema será realizado. O objetivo é construir um sistema que:

Execute, em um ambiente de execução determinado, as tarefas e funções especificadas nas descrições de casos de uso;
Cumpra todas as suas necessidades;
Seja fácil de manter quando ocorrerem mudanças nos requisitos funcionais;

Resultados de projeto em um modelo de análise e projeto têm, opcionalmente, um modelo de análise. O modelo de design serve como uma abstração do código-fonte, isto é, o projeto atua como uma espécie de “gabarito” de como o código-fonte será estruturado e escrito. O modelo de projeto consiste em classes de design estruturado em pacotes e subsistemas com interfaces bem definidas, representando o que irá se tornar componentes da aplicação. Ele também contém descrições de como os objetos dessas classes colaboram para desempenhar casos de uso do projeto.

Para ler mais sobre o assunto, acesse: Disciplinas do Processo Unificado ( )

#30. (UFMT – UFSBA/2017) Os métodos de análise e projeto de software permitem construir modelos e avaliar a completeza e a consistência do processo e do projeto. A adoção de uma metodologia para o processo de desenvolvimento de software impõe uma disciplina que possibilita a previsibilidade e eficiência necessárias à Engenharia de Software. As metodologias tradicionais de desenvolvimento de software, baseadas na elicitação e documentação completa de requisitos para a posterior construção do software, estão sendo confrontadas pelas metodologias ágeis que dão ênfase às pessoas, interações, colaboração dos usuários para a entrega rápida de artefatos. Muitos autores descrevem os modelos de desenvolvimento de software, pois tratam apenas do processo; nessa questão, a abordagem para metodologia é abrangente. A coluna da esquerda apresenta metodologias de desenvolvimento de software e a da direita, características de cada uma. Numere a coluna da direita de acordo com a da esquerda.
1 – Modelo em cascata
2 – Extreme Programming (XP)
3 – Scrum
4 – Modelo Espiral
( ) Ciclo de desenvolvimento curto, feedback constante, incremental.
( ) Backlog de produto, Sprint, Sprint backlog.
( ) Combina elementos de projeto e estágios de prototipação.
( ) Fases progressivas, processo estruturado.

3, 2, 4, 1

2, 3, 4, 1

4, 1, 2, 3

1, 2, 3, 4

Teste 3: Engenharia de Software – Todas as Matérias da Disciplina

Teste 3: Engenharia de Software – Todas as matérias da disciplina

Results

#2. (FUNCAB – SESACRE/2014) No diagrama de casos de uso, as pessoas ou entidades externas que integram, interagem ou desempenham algum papel no sistema, são conhecidas como:

#3. (IESES – TRE-MA/2015) Na programação orientada a objetos, o relacionamento do tipo herança entre classes traz alguns benefícios dos quais se destacam:

#4. (ESAF – 2004 – CGU) No desenvolvimento Orientado a Objetos usando UML, um prefixo é incorporado a um nome de atributo ou nome de operação para indicar a visibilidade da propriedade. Com relação ao prefixo utilizado com esta finalidade, é correto afirmar que os atributos ou operações

#6. (FCC – 2010 – DPE-SP) Na Engenharia de Software, a frase “identificar os aspectos importantes, ignorando os detalhes” define o princípio

#13. (CESPE – 2013 – TCE-RO) De acordo com a evolução dos requisitos, estes podem ser classificados em permanentes, que são gerados nas fases iniciais do desenvolvimento, e voláteis, que surgem ao longo do processo de construção do software.

#14. (FCC – INFRAERO/2011) Em relação às regras do Scrum, é INCORRETO afirmar:

#15. (ESAF – 2004 – CGU) Na modelagem com UML, o Diagrama de Casos de Uso fornece

#17. (ESAF – 2004 – CGU) Na modelagem com UML, um Diagrama de Seqüência mostra interações de objetos organizados em uma seqüência de tempo

#18. (IESES – TRE-MA/2015) Uma classe associativa é usada em um diagrama de classe em UML quando:

#19. (IESES – TRE-MA/2015) Na UML, o relacionamento do tipo agregação compartilhada usado no diagrama de classes serve na situação de: ? A correção aparecerá no rodapé da questão, caso você erre ou não selecione uma opção de resposta.

#21. (FCC – SEFAZ/SP/2013) No cálculo do valor dos pontos de função, utiliza-se a seguinte expressão: O valor correto utilizado para X é ? Necessário decorar a fórmula.

#22. (FCC – SEFAZ/SP/2013) A análise por pontos de função utiliza alguns domínios de informação para quantificar o produto software. Dentre tais domínios, incluem-se ? A correção aparecerá no rodapé da questão, caso você erre ou não selecione uma opção de resposta.

#23. (FCC – INFRAERO/2011) No RUP, definir quais são os atores, os casos de uso existentes e como eles interagem entre si é função típica do

#24. (FCC – INFRAERO/2011) Em projetos pequenos, o RUP pode reduzir os requisitos de artefato para se comparar ao equivalente de artefatos em projeto de XP. Nesse sentido, considere o quadro de equivalência entre os artefatos do XP e RUP: Está correto o que consta APENAS em

#27. (CESPE – 2013 – TCE-RO) A gerência de requisitos deve manter a matriz de rastreabilidade atualizada para, caso o cliente solicite uma mudança, o item de configuração correspondente seja implementado.

#28. (FCC – 2014 – TRF – 3ª REGIÃO) A figura abaixo mostra um diagrama com as atividades relativas ao levantamento de requisitos. O diagrama e a lacuna da caixa em branco referem-se, respectivamente, aos diagramas UML de

Deixe uma resposta Cancelar resposta