Questão 147736

• Banca: FCC
• Órgão: MPU
• Ano: 2007
• Provas: FCC - 2007 - MPU - Analista de Informática - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Engenharia de Requisitos

Em um artigo sobre uma rede de lojas do varejo, refere-se que um sistema de informações permitiria uma economia de milhões de reais com a geração automática de carnês. Entretanto, a utilização desse sistema provocou um aumento acentuado na inadimplência. O motivo do insucesso foi porque o carnê era grande e não cabia no bolso. Por causa disto os carnês eram guardados em gavetas e esquecidos pelos clientes. Detalhes como esse, que não são capturados durante a análise,

• A. certamente serão observados na fase de testes e homologação de produtos de software.
• B. são objeto do levantamento especificado na fase de modelagem funcional.
• C. constituem defeitos de especificação, cuja ocorrência pode ser reduzida por inspeção formal de software.
• D. são obrigações da engenharia de requisitos praticáveis durante a fase de modelagem de dados.
• E. constituem defeitos de especificação e não há como reduzir sua ocorrência durante o processo de software.

Gabarito: C

Comentários

•  Acho muito difícil que inspeção formal de software detecte problemas tão sutis como esses...  Mas se eles acreditam nisso...

• Concordo, e esta questão é bem subjetiva.

  Por curiosidade: O texto refere-se a rede Casas Bahia

• Realmente questão bem subjetiva.
  
  Nesse caso, acredito que temos que usar o bom senso para resolvê-la.
  As informações propostas no enunciado deixam claro que a questão é sobre os requisitos de software, pois conta uma bela historinha. Pelos outros métodos de desenvolvimento de software não é possível detectar isso (Análise, Projeto, Construção, Testes, Implantação, etc).
  
  Se observarmos as opções c e e que mencionam o defeito de especificação dos requisitos é claro que foi esquecido de incluir na lista de requisitos a opção de tamanho para o carnê. O difícil de engolir na alternativa e é que não é possível reduzir a ocorrência durante o processo de software. É claro que isso não é válido, tendo em vista que existem técnicas de revisão realizada em todas as etapas de construção de um software. Ficando mais fácil matar a questão por elimininação na letra c, pois a banca ao mencionar inspeção formal de software se refere as revisões do processo de desenvolvimento de software.
  
  Mesmo assim, essa questão é muito subjetiva e engloba diversos conceitos na engenharia de software.
• Nem o cliente do software poderá prever que haverá inadimplência por consequência da inserção do software no ambiente de trabalho.
  
  Como o cliente irá prever que haverá caloteiro, quem é honesto não sossega enquanto não tiver pago suas dívidas. 
  
  Se fosse como diz a questão, a empresa não poderá levar ninguém ao SPC/Serasa, pois foi culpa dela mesma, me poupe né.
• Por eliminação:
  
  
  • a) certamente serão observados na fase de testes e homologação de produtos de software.
  • -> Certamente não foram observados, por isso ocorreu o defeito já em produção.
  • b) são objeto do levantamento especificado na fase de modelagem funcional.
  • -> esta opção não tem sentido e não traz nenhum valor para o problema.
  • c) constituem defeitos de especificação, cuja ocorrência pode ser reduzida por inspeção formal de software.
  • -> é um defeito, provacado por falha na especificação. o método formal levaria todos os atributos dos cenários de uso para representações matemáticas, e assim, poderia ter previnido o problema. não é perfeita, pois sabemos que não é assim no mundo real, mas é a melhor alternativa.
  • d) são obrigações da engenharia de requisitos praticáveis durante a fase de modelagem de dados.
  • -> e o que seriam requisitos praticáveis? nada a ver com modelagem de dados.
  • e) constituem defeitos de especificação e não há como reduzir sua ocorrência durante o processo de software.
  • -> constituem defeitos de especificação, certo. mas é claro que a banca não quer aprovar o candidato que diz que é impossível previnir tais tipos de problemas.