Questões sobre Engenharia de Software

Baseando-se nas Características Gerais do Sistema (CGS), um dos passos para o cálculo do fator de ajuste é:

• A.

  avaliar o impacto de cada uma das 14 CGS no aplicativo que está sendo contado, atribuindo peso de 0 a 5 para cada característica.

• B.

  calcular o nível de influência por meio da multiplicação dos pesos de cada uma das 14 CGS.

• C.

  avaliar as entradas de cada uma das 14 CGS no aplicativo que está sendo contado, atribuindo peso de 0 a 10 para cada característica.

• D.

  avaliar o impacto de cada uma das 14 CGS no aplicativo que está sendo contado, atribuindo peso de 0 a 10 para cada característica.

• E.

  calcular o nível de influência por meio da soma dos pesos da primeira metade das 14 CGS.

Algumas das Características Gerais do Sistema (CGS) são:

• A.

  Comunicação de Dados. Funções intrínsecas. Performance. Especifi cação de equipamento. Saída de dados on-line. Processamento complexo. Reusabilidade. Facilidade de Implementação.

• B.

  Transmissão de Dados. Funções distribuídas. Modularidade. Fornecedores de equipamentos. Entrada de dados on-line. Processamento complexo. Reengenharia. Múltiplos subprogramas.

• C.

  Comunicação de Dados. Servidores distribuídos. Performance. Configuração de equipamento. Entrada de dados on-line. Processamento cognitivo. Facilidade de Manutenção. Múltiplos locais.

• D.

  Comunicação de Dados. Funções distribuídas. Performance. Configuração de equipamento. Entrada de dados on-line. Processamento complexo. Reusabilidade. Facilidade de Implantação.

• E.

  Transmissão de Dados. Ações distribuídas. Performance. Configuração de equipamento. Entrada de dados on-line e off-line. Direcionamento complexo. Reusabilidade. Facilidade de Implantação.

O cálculo dos pontos de função de um projeto de desenvolvimento consiste dos componentes de funcionalidade:

• A.

  reusabilidade de aplicação; reusabilidade de conversão; fator de ajuste da aplicação.

• B.

  funcionalidade de aplicação; funcionalidade de compressão; fator de ponderação da aplicação.

• C.

  reusabilidade de aplicação; funcionalidade de programação; fator de ajuste da aplicação.

• D.

  funcionalidade de aplicação; funcionalidade de conversão; fator de ajuste da aplicação.

• E.

  funcionalidade de programação; funcionalidade de conversão; funcionalidade de manutenção.

Ferramentas CASE podem ser usadas pelo engenheiro de sistemas

• A.

  para criar um modelo de sistema reativo que seja usado como base para simulação de desempenho e de comportamento.

• B.

  para criar um modelo de mudança organizacional que seja usado como base para interface e interpretação.

• C.

  para criar um modelo de hardware que seja usado como base para simulação virtual de desempenho e de comportamento.

• D.

  para criar um modelo de requisitos ativos que seja usado como base para auditoria de comportamento.

• E.

  para projeto de hardware de apoio que seja usado para simulação de obsolescência controlada.

Segundo os princípios da boa especificação,

• A.

  uma linguagem de especificação de sistema orientada ao usuário é exigida.

• B.

  junte funcionalidade e implementação.

• C.

  separe funcionalidade de usabilidade.

• D.

  uma linguagem de programação orientada ao processo contém componentes interagentes.

• E.

  separe funcionalidade de implementação.

São princípios de Modelagem de Processos:

• A.

  Modelo simples, pensamento complicado. Seja minucioso, comece pequeno e vá atualizando. Divida e descreva, evite mini-modelos. Use métodos, dados e metadados. Não se apaixone por dados.

• B.

  Aderência. Usabilidade ou essência. Custo/ benefício. Segurança. Comparabilidade. Imparcialidade.

• C.

  Modelo complicado, pensamento simples. Seja parcimonioso, comece pelo todo e vá dividindo. Divida e conquiste, evite metáforas. Use analogias de comprometimento. Não se apaixone por dados.

• D.

  Aderência. Relevância ou suficiência. Custo / benefício. Clareza. Comparabilidade. Estruturação sistêmica.

• E.

  Sistema simples, configuração complicada. Seja interativo, comece grande e vá simplificando. Divida e conquiste, evite megamodelos. Use metáforas, analogias e similares. Não se apaixone por paradigmas.

No ciclo da Engenharia da Usabilidade, as atividades da fase de análise são:

• A.

  Análise da instituição do usuário. Análise do contexto da tarefa. Análise das possibilidades e restrições do treinamento. Análise de princípios setoriais para o projeto.

• B.

  Análise do perfi l do usuário. Análise do contexto da plataforma. Análise de compatibilidade gerencial. Análise de princípios gerais para o projeto.

• C.

  Análise do perfi l do usuário. Análise do contexto da tarefa. Análise das possibilidades e restrições da plataforma. Análise de princípios gerais para o projeto.

• D.

  Análise do perfi l do desenvolvedor. Análise de requisitos. Análise das possibilidades e sistemas da plataforma. Análise de princípios gerais para as transações.

• E.

  Análise da instituição do usuário. Análise de compromissos. Análise das possibilidades e restrições da estrutura. Análise de ameaças à segurança do projeto.

São heurísticas de usabilidade

• A.

  Coerência e padrões. Prevenção de erros. Relembrar em vez de Reconhecer. Flexibilidade e eficiência de mapeamento. Ajuda e documentação.

• B.

  Visibilidade do estado do sistema. Mapeamento entre o sistema e o mundo real. Liberdade e Controle ao Usuário. Prevenção de erros. Reconhecer em vez de relembrar.

• C.

  Versatilidade do estado do sistema. Previsão de acertos. Reconhecer em vez de relembrar. Design estético e maximalista. Suporte para o usuário reconhecer, diagnosticar e recuperar erros.

• D.

  Mapeamento entre o sistema e os programas. Liberdade e Controle ao Desenvolvedor. Consistência e padrões. Flexibilidade e eficiência de uso. Ajuda e informação.

• E.

  Visibilidade da estrutura do sistema. Compromisso entre o sistema e a configuração. Liberdade e Controle ao Usuário. Suporte para o usuário reconhecer, diagnosticar e aplicar erros. Ajuda à implementação.

A métrica de software Complexidade ciclomática

• A.

  para um fluxo de grafo, é definida como

  E – N – 2, onde

  E é o número de entidades do grafo

  N é o número de nós do grafo de fluxo.

• B.

  proporciona uma medida quantitativa da complexidade lógica de um programa.

• C.

  para um fluxo de grafo é definida como

  E + N – 2, onde

  E é o número de ramos do grafo de fluxo

  N é o número de novos elos do grafo de fluxo.

• D.

  é uma medida cumulativa da complexidade física de um programa.

• E.

  é uma propriedade dos ciclos de maior complexidade de um programa.

São axiomas em risco

• A.

  É impossível testar um programa completamente. Teste de software é um exercício baseado em certezas. Quanto menos bugs forem encontrados, mais bugs existirão.

• B.

  É possível testar um programa completamente. Teste de software não pode ter riscos. Quanto mais breaks forem encontrados, mais breaks existirão.

• C.

  É impossível testar um programa completamente. Teste de software é um exercício baseado em risco. Quanto mais bugs forem encontrados, mais bugs existirão.

• D.

  É impossível testar um programa que tenha riscos. Teste de software deve ser feito pelos seus desenvolvedores. Todos os bugs encontrados serão consertados.

• E.

  É impossível testar um programa parcialmente. Teste de software aplica-se unicamente a ambientes sem risco. Quanto mais bugs forem encontrados, menos bugs existirão.