Juliana Jenny Kolb
Home > Simulados on-line > Questões de Concursos > Tecnologia da Informação (TI) > Questões de Engenharia de Software > Engenharia de Software-Todas as Matérias
Teste 1: Engenharia de Software – Todas as matérias da disciplina
Questões extraídas de concursos públicos e/ou provas de certificação. Cada teste apresenta no máximo 30 questões, selecionadas randomicamente.
Os testes estão embutidos na fase de Construção e são realizados antes da fase de Transição. </br> </br> Para ler mais sobre o assunto, acesse: Fases do Processo Unificado ( ) I- A Implantação da Função de Qualidade (IFQ), em inglês Quality Function Deployment (QFD), é uma técnica que traduz as necessidades do cliente para requisitos técnicos do software. A IFQ concentra-se em maximizar a satisfação do cliente a partir do processo de engenharia de software (ZUL92). Para conseguir isso, a IFQ enfatiza o entendimento do que tem valor para o cliente e depois implanta esses valores por meio do processo de engenharia. A IFQ identifica três tipos de requisitos: </br> Para ler mais sobre o assunto, acesse: Implantação da Função de Qualidade ( ) </br> </br> II- A gestão de requisitos começa com a identificação. A cada requisito é atribuído um modo identificador. Uma vez identificados os requisitos, tabelas de rastreamento são desenvolvidas. </br> </br> Para ler mais sobre o assunto, acesse: Gestão de Requisitos – Rastreamento de Requisitos ( ) </br> </br> III- À medida que os requisitos são coletados, uma visão geral das funções e características do sistema começam a se materializar. No entanto, é difícil avançar para atividades mais técnicas de engenharia de software até que a equipe de software entenda como essas funções e características serão usadas por diferentes classes de usuários finais. Para tanto, desenvolvedores e usuários podem criar um conjunto de cenários que identifiquem uma linha de uso para o sistema a ser construído. Os cenários, frequentemente chamados de Casos de Uso ( ), fornecem uma descrição de como o sistema será usado. </br> </br> Para ler mais sobre o assunto, acesse: Cenários de Usuários ( ) O Dono do Produto (PO) é responsável por maximizar o valor do produto e do trabalho da equipe de desenvolvimento. O Dono do Produto é a única pessoa responsável por gerenciar o backlog do produto. O Scrum Master serve a Equipe de Desenvolvimento de várias formas, incluindo: • orientar a Equipe de Desenvolvimento na sua auto organização e multidisciplinaridade; • ensinar ou liderar a Equipe de Desenvolvimento para criar um produto de alto valor; • Remover impedimentos para o progresso da equipe de desenvolvimento; • Facilitar os eventos do Scrum quando solicitado ou necessário; • Orientar a Equipe de Desenvolvimento no ambiente organizacional no qual o Scrum ainda não é amplamente adotado e compreendido. </br> </br> Para ler mais sobre o assunto, acesse: SCRUM ( )Results
#1. (CESPE – 2013 – TCE-RO) A rastreabilidade bidirecional deve ocorrer tanto de forma horizontal quanto vertical. A horizontal estabelece a dependência de um requisito-fonte até o nível de decomposição mais baixo do produto, enquanto a rastreabilidade vertical estabelece a dependência dos requisitos entre si
#2. (CESPE – 2008 – STJ) Se uma classe abstrata declara uma interface, essa classe tipicamente contém declarações de métodos, mas não corpos de métodos; a interface não pode ser implementada por classes que herdem da classe abstrata. Em diagramas UML, a classe abstrata pode ser identificada colocando-se seu nome em itálico, e relacionamentos de dependência podem ser representados por setas tracejadas entre clientes da interface e a classe abstrata.
#3. (FCC – 2012 – TCE-AP) Considere o seguinte diagrama UML:
O número 1 e símbolo 1..* que aparecem ao lado das classes Nota Fiscal e Itens se referem à restrição de #4. (CESPE – 2008 – STJ) As características a seguir estão corretas para um modelo construído com a UML: pacotes contêm colaborações; as colaborações estão documentadas via diagramas de interação e diagramas de classe; as colaborações descrevem realizações de casos de uso; os padrões de projeto (design patterns) empregados no modelo estão representados via colaborações parametrizadas.
#5. (CESPE – 2008 – STJ) Em um modelo construído com a UML, estão corretas as seguintes características de diagramas de atividades: separações (forks) e junções (joins) são empregadas quando há atividades em paralelo; cada junção tem uma transição de entrada e várias de saída; cada separação tem várias transições de entrada e uma de saída; atividades estão agrupadas em raias separadas por linhas.
#6. (CESPE – 2008 – STJ) As seguintes características estão corretas para um modelo construído com a UML: nos diagramas de componentes, há módulos de código representados por componentes; há diagramas de componentes onde dependências de compilação estão representadas por setas tracejadas entre componentes; nos diagramas de utilização (deployment), alguns nós representam unidades computacionais, outros representam dispositivos periféricos.
#7. (CESPE – 2013 – INPI) O diagrama de casos de uso é utilizado para mostrar o fluxo de trabalho, detalhando as decisões do caminho tomado durante a execução das tarefas.
#8. (FCC – 2010 – DPE-SP) A partir da perspectiva de gerenciamento, NÃO faz parte do ciclo de vida de software do RUP (Rational Unified Process):
?
A correção aparecerá no rodapé da questão, caso você erre ou não selecione uma opção de resposta.
#9. (CESPE – 2013 – TCE-RO) A abordagem iterativa e a incremental compõem o desenvolvimento em fases. Na primeira, o sistema é dividido em subsistemas por funcionalidades, adicionando-se mais funcionalidades a cada versão; na segunda, o sistema é entregue completo e muda a funcionalidade a cada nova versão
?
Quando um Modelo Incremental é usado, o primeiro incremento frequentemente é chamado de núcleo do produto. Isto é, os requisitos básicos são satisfeitos, mas muitas características suplementares deixam de ser elaboradas. O núcleo do produto é usado pelo cliente e um plano é desenvolvido para o próximo incremento como resultado do uso e/ou avaliação. O Modelo de Processo Incremental, como a prototipagem e outras abordagens evolucionárias, é iterativo por natureza. O Modelo Incremental tem o objetivo de apresentar um produto operacional a cada incremento.
#10. (FCC – 2011 – INFRAERO) A principal metodologia tradicional utilizada no desenvolvimento de software é o modelo clássico também conhecido como cascata ou sequencial. Nesse modelo,
?
O Modelo em Cascata sugere uma abordagem sistemática e sequencial para o desenvolvimento de softwares. Cada etapa tem associada ao seu término uma documentação que deve ser aprovada para que a etapa posterior possa ter início.
#11. (FCC – INFRAERO/2011) Uma disciplina do RUP que tem como uma de suas finalidades “assegurar que os clientes, usuários e desenvolvedores tenham um entendimento comum da organização-alvo”, a qual se relaciona com a disciplina Ambiente. Trata-se de
#12. (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. Alguns clientes da Express não apreciam os modelos de desenvolvimento mais modernos, preferindo métodos mais tradicionais, como o Modelo Espiral. Considere as seguintes afirmações sobre o Modelo Espiral de desenvolvimento de software: I. As diversas versões desenvolvidas no Modelo Espiral, principalmente as resultantes das primeiras iterações, podem se constituir em protótipos do sistema final. II. Suporta um máximo de 4 iterações. III. Cada iteração tem duração máxima de duas semanas. Está correto o que se afirma em
?
Usando o Modelo Espiral, o software é desenvolvido em uma série de versões evolucionárias. Durante as primeiras iterações, as versões podem ser um modelo de papel ou protótipo. Durante as últimas iterações, são produzidas versões cada vez mais completas do sistema submetido à engenharia. *O modelo não limita duração nem quantidade de iterações.
#13. (CESPE – 2013 – TCE-RO) Engenharia de software não está relacionada somente aos processos técnicos de desenvolvimento de softwares, mas também a atividades como gerenciamento de projeto e desenvolvimento de ferramentas, métodos e teorias que apoiem a produção de softwares.
#14. (CESPE – 2013 – TCE-RO) Sistemas que incluem software são classificados em duas categorias: sistemas técnicos embasados em computadores e sistemas sociotécnicos. Os primeiros incluem componentes de hardware, software, pessoas, procedimentos e processos; os segundos são regidos pelas políticas e regras organizacionais.
#15. (CESPE – 2013 – TCE-RO) Em projeto de software, a independência funcional pode ser medida pela coesão, isto é, pela interdependência relativa entre os módulos, e pelo acoplamento, ou seja, pela força funcional relativa de um módulo
?
Coesão = força funcional relativa de um módulo, acoplamento = interdependência relativa entre os módulos. Em um projeto de software sugere-se: ALTA coesão e BAIXO acoplamento
#16. (FCC – 2014 – TRF – 3ª REGIÃO) Considere as seguintes atividades: 1. Compreensão do domínio: os analistas devem desenvolver sua compreensão do domínio da aplicação. 2. Coleta de requisitos: processo de interagir com os stakeholders do sistema para descobrir seus requisitos. 3. Classificação: atividade que considera o conjunto não estruturado dos requisitos e os organiza em grupos coerentes. 4. Resolução de conflitos: Solucionar conflitos decorrentes do envolvimento de múltiplos stakeholders. 5. Definição das prioridades: envolve a interação com os stakeholders para a definição dos requisitos mais importantes. 6. Descarte de requisitos: atividade de descartar requisitos menos importantes, baseando-se nas indicações dos stakeholders. 7. Verificação de requisitos: os requisitos são verificados para descobrir se estão completos e consistentes e se estão em concordância com o que os stakeholders desejam do sistema. 8. Modelagem de requisitos: os requisitos são modelados utilizando-se o diagrama de casos de uso e de sequência da UML. Faz parte do processo de levantamento e análise de requisitos o que consta em APENAS 1, 2,
#17. (FCC – 2012 – TCE-AP) Em relação a requisitos de sistemas, considere: I. O modo como um sistema deve reagir a certas entradas e o comportamento em que o sistema deve ter em certas situações e, em alguns casos, especificar o que o sistema não deve fazer, são chamados de requisitos não-funcionais. II. As restrições aos serviços ou funções de um sistema, como, por exemplo, processos de desenvolvimento ou utilização de padrões, são requisitos de funcionamento do sistema ou requisitos funcionais. III. Requisitos que vem do domínio da aplicação do sistema e refletem características ou restrições para aquele domínio são chamados de requisitos de domínio e podem ser requisitos funcionais e/ou não-funcionais. Está correto o que se afirma em
#18. (CESGRANRIO – 2010 – IBGE) Com o objetivo de minimizar os problemas enfrentados e melhorar o processo de engenharia de requisitos, um engenheiro de requisitos decidiu elencar uma série de medidas que poderá empregar em seus futuros projetos, tais como: I – aplicar a técnica de IFQ (Implantação da Função de Qualidade) que permite coletar os requisitos excitantes, os quais refletem características que vão além das expectativas do cliente e mostram ser muito satisfatórios quando presentes; II – utilizar tabelas de rastreamento que relacionam os requisitos identificados a um ou mais aspectos do sistema; III – utilizar casos de uso para fazer uma coleta iterativa de requisitos, uma vez que o processo de levantamento de requisitos é uma atividade evolutiva. Está(ão) correta(s) a(s) medida(s)
?
A correção aparecerá no rodapé da questão, caso você erre ou não selecione uma opção de resposta.
#19. (FCC – 2011 – INFRAERO) Os produtos de trabalho resultantes da engenharia de requisitos são avaliados quanto à qualidade durante a etapa de validação de requisitos. Analise os itens a seguir referentes a essa etapa: I. Um dos principais mecanismos de validação de requisitos é a avaliação técnica formal. II. O modelo de análise pode garantir que os requisitos foram consistentemente declarados. III. É frequentemente útil examinar cada requisito em face de um conjunto de questões do tipo checklist. IV. A equipe de revisão que avalia os requisitos inclui apenas pessoas com conhecimento técnico na área de TI, como engenheiros de softwares, desenvolvedores etc. Está correto o que consta em
#20. (FCC – 2011 – INFRAERO) A engenharia de requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vão trabalhar para resolver. Ela inclui um conjunto de tarefas que levam a um entendimento de qual será o impacto do software sobre o negócio, do que o cliente quer e de como os usuários finais vão interagir com o software. A função de negociação no processo de engenharia de requisitos
#21. (CESPE – 2013 – TCE-RO) A fase de análise define os requisitos do cliente, conforme as necessidades de negócio, e as considerações técnicas envolvidas, que se agrupam em uma solução tecnológica, compõem a fase de projeto de software.
#22. (FCC – 2014 – TRF – 3ª REGIÃO) Sabendo que a Análise de Pontos de Função (APF) permite medir o tamanho funcional do software, considere que no desenvolvimento de um software foram fornecidos os seguintes dados:
Ao se completar a tabela 4, o total de pontos de função das transações é #23. (FCC – 2012 – TCE-AP) Um dos primeiros passos para efetuar a contagem por pontos de função de um sistema, é definir o tipo de contagem que será efetuado. Esses tipos se dividem em
#24. (FCC – 2014 – TRF – 3ª REGIÃO) Os modelos ágeis de desenvolvimento de software têm menos ênfase nas definições de atividades e mais ênfase na pragmática e nos fatores humanos do desenvolvimento. Um destes modelos enfatiza o uso de orientação a objetos e possui apenas duas grandes fases: 1 − Concepção e Planejamento e 2 − Construção. A fase de Concepção e Planejamento possui três disciplinas (chamadas de processos): Desenvolver Modelo Abrangente, Construir Lista de Funcionalidades e Planejar por funcionalidade. Já a fase de Construção incorpora duas disciplinas (processos): Detalhar por Funcionalidade e Construir por Funcionalidade. Já a fase de Construção incorpora duas disciplinas (processos): Detalhar por Funcionalidade e Construir por Funcionalidade. O texto acima apresenta a metodologia ágil conhecida como
?
O Feature-Driven Development (FDD) ou Desenvolvimento Orientado a Funcionalidades é uma metodologia ágil que consiste em: - desenhar um protótipo do produto; - montar uma lista de funcionalidades desse produto; - planejar e desenvolver por funcionalidade.
#25. (FCC – 2014 – TRF – 3ª REGIÃO) Scrum é um modelo utilizado no desenvolvimento ágil de software. No Scrum um dos conceitos mais importantes é o sprint, que consiste em um ciclo de desenvolvimento que, em geral, vai de duas semanas a um mês. No início de cada sprint é feito um …… I , no qual a equipe prioriza os elementos do ……II a serem implementados e transfere esses elementos para o ……III , ou seja, a lista de funcionalidades a serem implementadas no ciclo que se inicia. A equipe se compromete a desenvolver as funcionalidades e o ……IV se compromete a não trazer novas funcionalidades durante o mesmo sprint. As lacunas I, II, III e IV são preenchidas, correta e respectivamente, por
#26. (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. Considerando um software de grande porte desenvolvido pela Express, torna-se necessário, inicialmente, elaborar os testes de unidade de software. É necessário, ao se testar uma unidade, que se projetem e implementem programas que acionem os módulos sob teste, eventualmente passando alguns parâmetros necessários. Tais programas denominam-se
#27. (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. Um dos clientes da Express solicitou que fosse utilizada uma técnica de teste de software denominada caminhos independentes. A filosofia básica dessa técnica de teste é
?
O TESTE DE CAMINHO (caixa-branca) é o que define como a aplicação deve trabalhar com todos os parâmetros sendo utilizados para que o teste seja perfeito. Deve-se realizar estes testes para saber se a aplicação está realmente realizando o que foi planejado/codificado. O Teste de Caminho pode ser aplicado a um projeto procedimental ou ao código-fonte. CAMINHOS INDEPENDENTES: Um caminho independente é qualquer caminho através do programa que introduz pelo menos um novo conjunto de comandos de processamento ou uma nova condição.
#28. (FUNCAB – SESACRE/2014) No gerenciamento de transações, se ocorrerem falhas que interrompam o processo de atualização de valores de estoque, o sistema deve manter os valores anteriores. Esse princípio é conhecido como:
#29. (CESPE – SERPRO/2013) Indicadores são utilizados para a avaliação da qualidade de produtos, processos e clientes. A respeito desse assunto, julgue os itens que se seguem. Além de ser empregado para medição e avaliação da qualidade de produtos e processos, um sistema de indicadores deve ser utilizado para controle de desempenho futuro.
#30. (CESPE – 2013 – INPI) No Scrum, o Product Owner (PO) é responsável por definir a visão do produto e remover os impedimentos, enquanto o Scrum Master (SM) é responsável por elaborar e manter o Product Backlog, bem como por ajudar o PO a executar suas atividades diárias.
?
A correção aparecerá no rodapé da questão, caso você erre ou não selecione uma opção de resposta.