Questões de Qualidade de Software

Questão 43642

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2008
• Provas: CESGRANRIO - 2008 - BR Distribuidora - Analista de Sistemas Júnior - Processos de Negócios
• Disciplina: Engenharia de Software
• Assuntos: Gerência de Configuração; Qualidade de Software

É recomendado que um projeto possua um mecanismo formal e documentado de controle de mudanças. Sobre este mecanismo, são feitas as afirmativas a seguir.

I - O mecanismo deve rastrear e tratar mudanças em quaisquer fatores críticos de sucesso do projeto, incluindo escopo, prazos e custos.

II - Para tornar o processo gerenciável, é recomendado que sejam rastreadas apenas mudanças que possuam impacto significativo no custo ou nos prazos do projeto e que não sejam rejeitadas em primeira análise.

III - A avaliação e a aprovação de quaisquer solicitações de mudanças são atribuições exclusivas do gerente de projeto, pois o mesmo detém a autoridade e a responsabilidade sobre os resultados finais do projeto perante os stakeholders.

IV - Tipicamente, o mecanismo de controle de mudanças prevê algumas categorias de mudanças que são automaticamente aprovadas - tais como as resultantes de emergências - as quais devem ser registradas e rastreadas, da mesma forma que as demais.

Estão corretas APENAS as afirmativas

• A. I e II
• B. I e III
• C. I e IV
• D. II e III
• E. III e IV

Gabarito: C

Comentários

• Ainda continuo com a dúvida... o escopo pode ser modificado durante a fase de controle de mudanças ? considero tal questão um pouco complicada para a resolução, pois ao meu ver o escopo é definido no inicio do projeto e não pode ser modificado... as modificações atuam sobre o planejamento, custos e prazos... em caso de mudança de escopo é necessário um novo projeto.

• Alan

  Um dos processos da gerência de escopo é o controle de mudanças no escopo.

   

• II: ERRADO. As mudanças aprovadas devem ser monitoradas e avaliadas levando em consideração não apenas o custo ou prazos do projeto, mas também o impacto no escopo, orçamento e requisitos de qualidade.

   

  III: ERRADO. Todas as mudanças solicitadas e documentadas devem ser aceitas ou rejeitadas por uma autoridade dentro da equipe de gerenciamento de projetos ou por uma organização externa que represente o patrocinador ou cliente. O sistema de controle de mudanças muitas vezes inclui um comitê de controle de mudanças, responsável pela aprovação ou rejeição das mudanças solicitadas. As funções e responsabilidade desses comitês são definidas claramente nos procedimentos de controle de configuração e de controle de mudanças e são acordadas com o patrocinador, com o cliente e com outras partes interessadas. Ou seja, a avaliação e aprovação das mudanças não dependem exclusivamente do gerente de projetos, mas de um comitê.

Questão 72085

• Banca: CESGRANRIO
• Órgão: IBGE
• Ano: 2010
• Provas: CESGRANRIO - 2010 - IBGE - Analista de Sistemas - Desenvolvimento de Aplicações
• Disciplina: Engenharia de Software
• Assuntos: Metodologia de desenvolvimento de software; Qualidade de Software

Os processos de desenvolvimento de software utilizam, muitas vezes, procedimentos estatísticos para, por exemplo, apoiar a tomada de decisão. Dentro desse contexto, o Diagrama de Pareto é baseado na clássica regra de que

• A. 20% das ocorrências causam 80% dos problemas.
• B. 60% das amostras de um processo normal encontram- se nos limites do desvio padrão.
• C. pontos fora dos limites de um desvio padrão revelam a ocorrência de problemas aleatórios.
• D. três pontos consecutivos abaixo da média indicam um processo em melhoria contínua.
• E. um índice de erro acima dos cinco sigmas indica um processo que alcançou a qualidade.

Gabarito: A

Comentários

• Link que usei para responder a pergunta: http://www.scribd.com/doc/19750932/Diagrama-de-Pareto

• A Lei de Pareto (também conhecido como princípio 80-20), afirma que para muitos fenómenos, 80% das consequências advém de 20% das causas. A lei foi sugerida por Joseph M. Juran, que deu o nome em honra ao economista italiano Vilfredo Pareto.

  O Diagrama de Pareto (ou 80-20 ou 70-30) é um gráfico de barras que ordena os problemas, identificando os mais importantes e medindo-os em diversas escalas, permitindo usar a teoria de Pareto (poucos essenciais, muito triviais), ou seja, há muitos problemas sem importância diante de outros mais importantes. Além disso, o Diagrama de Pareto permite agrupar os dados de diferentes formas, medem o impacto de mudanças no processo e quebra causas genéricas em causas específicas.

  No topo da barra mais alta, traça-se uma linha para poder verificar a medida cumulativa das categorias, podendo assim identificar o peso que os problemas têm em relação ao todo.

   

• a-

  principio de pareto é um modelo que explica ocorrencias de determinados acontcimentos por uma regra de intervalo, cujo padrao é 20% dos motivos causam 80% das consequencias.

Questão 81616

• Banca: FCC
• Órgão: TRE-AM
• Ano: 2010
• Provas: FCC - 2010 - TRE-AM - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Engenharia de Requisitos; Qualidade de Software

Para se garantir a qualidade dos processos, vários passos devem ser tomados, entre eles:

I. Gerenciar os requisitos, identificando quais são as principais necessidades do software, levanto em conta tanto os requisitos funcionais quanto os não funcionais.

II. Acompanhar o projeto de software para que se possa ter uma visão bem realista do progresso do projeto, sendo possível tomar ações eficazes quando o desempenho software se desviar de forma significativa dos planos do projeto.

III. Gerenciar a configuração do software para estabelecer e manter a integridade dos produtos do projeto ao longo do ciclo de vida do software para dar maior segurança ao desenvolvedor e permitir maior controle de desenvolvimento.

IV. Desenvolver um processo padrão para ser gerenciado e revisado, Identificar os pontos fortes e fracos do processo de desenvolvimento e planejar atividades de melhoramento.

É correto o que se afirma em

• A. II e IV, apenas .
• B. I, II e III, apenas.
• C. II, III e IV, apenas.
• D. I e III, apenas.
• E. I, II, III e IV.

Gabarito: E

Comentários

• O enunciado deveria ser:
  
  Para se garantir a qualidade "do software" e não "dos processos".
  
  Com esse enunciado entendo que a resposta correta seria letra A(ítens II e IV).

• 1 – Para se garantir a qualidade dos processos, vários passos devem ser tomados, entre eles: Gerenciar os requisitos, identificando quais são as principais necessidades do software, levanto em conta tanto os requisitos funcionais quanto os não funcionais.

   

  2 - Acompanhar o projeto de software para que se possa ter uma visão bem realista do progresso do projeto, sendo possível tomar ações eficazes quando o desempenho software se desviar de forma significativa dos planos do projeto, é um passo para se garantir a qualidade dos processos.

   

  3 – Gerenciar a configuração do software para estabelecer e manter a integridade dos produtos do projeto ao longo do ciclo de vida do software para dar maior segurança ao desenvolvedor e permitir maior controle de desenvolvimento, é um passo para se garantir a qualidade dos processos.

   

  4 – Desenvolver um processo padrão para ser gerenciado e revisado, Identificar os pontos fortes e fracos do processo de desenvolvimento e planejar atividades de melhoramento, é um passo para se garantir a qualidade dos processos.

• Embora não ache que irá ser tema de questão, uma coisa me chamou a atenção neste comentário: "pela autoridade ou pelo particular". Parece besteira, mas nunca tinha atentado ao fato que um particular também pode provocar ou forjar um flagrante. Apenas um comentário pessoal :)

Questão 106060

• Banca: FCC
• Órgão: PGE-RJ
• Ano: 2009
• Provas: FCC - 2009 - PGE-RJ - Técnico Superior de Análise de Sistemas e Métodos
• Disciplina: Engenharia de Software
• Assuntos: Engenharia de Requisitos; Qualidade de Software

A confiabilidade especificada para um software aplicativo é

• A. um mecanismo de teste de desempenho.
• B. um mecanismo de teste de estresse.
• C. uma restrição de escopo.
• D. um requisito funcional.
• E. um requisito não-funcional.

Gabarito: E

Comentários

• Os requisitos não funcionais são aqueles que expressam como deve ser feito (não confundir requisitos não funcionais com design). Em geral se relacionam com padrões de qualidade como confiabilidade, performance, robustez, etc.
  
  O requisitos funcionais são aqueles que descrevem o comportamento do sistema, suas ações para cada entrada, ou seja, é aquilo que descreve o que tem que ser feito pelo sistema.

• Segundo a INBR ISO/IEC 9126-1:2003, página 6 e 8 respectivamente:

  "a confiabilidade de um produto de software é avaliada pela extração das falhas observadas, somente daqueles defeitos que ocorreram por causa do software (originárias dos requisitos, projeto ou implementação).";

  "6.2 Confiabilidade: Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições
  especificadas".

  Diante das premissas acima, podemos concluir que trata-se de um requisito não funcional, pois não é um mecanismo, restrição ou requisito funcional (não se implementa a confiabilidade em linha de código).
  

  
  

• Confiabilidade segundo Garden:

  - O software fornece todos os recursos e capacidade sem falhas?

  - Esta dispível quando necessário?

  - Fornece funcionalidades sem a ocorrência de erros?

  Confiabilidade segundo McCall:

  Confiabilidade é uma sub-característica do fator de qualidadeOperação do Produto, existem mais dois fatores que são:Revisão doproduto e transição do produto, porém voltando ao assuntoconfiabilidade é definino como: O quanto se pode esperar queum programa realize a função pretendida com a precisão exata.

  Confiabilidade segundo ISO 9126:

  Confiabilidade é a quantidade detempo que o software fica disponível para uso conforme indicadopelos seguintes subatributo:maturidade, tolerância a falhas efacilidade de recuperação.

  
  

  Capítulo 14, 7^a. EdiçãoPressman

  Fazendo um leitura em relação asdefinições acima e observando algumas palavras, como por exempo:

  - “disponível quandonecessário”;

  - “O quanto se pode esperar” ;

  - “a quantidade de tempo que osoftware fica disponível”.

  Trata-sede requisito não-funcional.

  
  

• e-

  Requisitos nao-funcionais sao caracteristicas do sistema, geralmente o comportamento e.g.: portabilidade, desempenho, compatibilidade etc

Questão 106105

• Banca: FCC
• Órgão: PGE-RJ
• Ano: 2009
• Provas: FCC - 2009 - PGE-RJ - Técnico Superior de Análise de Sistemas e Métodos
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

A estratégia de qualidade aplicada à arquitetura tradicional de software deve garantir para as etapas de Engenharia de Sistemas, Requisitos e Projetos, respectivamente, os testes de

• A. sistema, validação e integração.
• B. sistema, integração e unidade.
• C. integração, validação e sistema.
• D. validação, integração e unidade.
• E. sistema, unidade e integração.

Gabarito: A

Comentários

• Teste de Unidade: código
  
  Teste de Integração: projeto
  
  Teste de Validação: requisitos
  
  Teste de Sistema: engenharia de sistemas

• A etapa de requisitos também pode ter testes de unidade, quando é feito sob a ótica do desenvolvedor.
  Questão com duas respostas válidas.
  

• Segundo Pressman:

  Figura 17.1 pag 404 7ed.

   

  teste de Unidade -> Código

  teste de Integração -> Projeto

  teste de Validação -> Requisitos

  teste de Sistema - > Engenharia de Ssitemas

• Segue abaixo a Estratégia de Testes elaborada por Pressman , livro Engenharia de Software:

  https://uploaddeimagens.com.br/imagens/estrategia_de_testes_-_pressman-png

   

  Letra A

Questão 128407

• Banca: FCC
• Órgão: TRT - 15ª Região (SP)
• Ano: 2009
• Provas: FCC - 2009 - TRT - 15ª Região - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

A adequação às normas, leis e procedimentos é um requisito de qualidade denominado

• A. integridade.
• B. autenticidade.
• C. confiabilidade.
• D. confidencialidade.
• E. conformidade.

Gabarito: E

Comentários

• Alternativa E.  Feita por dedução, pois não me recordo ser a conformidade atinente ao assunto de Segurança da informação.
• • CONFIABILIDADE: significa proteger informações contra sua revelação para alguém não autorizado - interna ou externamente. Consiste em proteger a informação contra leitura e/ou cópia por alguém que não tenha sido explicitamente autorizado pelo proprietário daquela informação. A informação deve ser protegida qualquer que seja a mídia que a contenha, como por exemplo, mídia impressa ou mídia digital. Deve-se cuidar não apenas da proteção da informação como um todo, mas também de partes da informação que podem ser utilizadas para interferir sobre o todo. No caso da rede, isto significa que os dados, enquanto em trânsito, não serão vistos, alterados, ou extraídos da rede por pessoas não autorizadas ou capturados por dispositivos ilícitos.

   

  • AUTENTICIDADE: O controle de autenticidade está associado com identificação correta de um usuário ou computador. O serviço de autenticação em um sistema deve assegurar ao receptor que a mensagem é realmente procedente da origem informada em seu conteúdo. Normalmente, isso é implementado a partir de um mecanismo de senhas ou de assinatura digital. A verificação de autenticidade é necessária após todo processo de identificação, seja de um usuário para um sistema, de um sistema para o usuário ou de um sistema para outro sistema. Ela é a medida de proteção de um serviço/informação contra a personificação por intrusos.

   

  • INTEGRIDADE: A integridade consiste em proteger a informação contra modificação sem a permissão explícita do proprietário daquela informação. A modificação inclui ações como escrita, alteração de conteúdo, alteração de status, remoção e criação de informações. Deve-se considerar a proteção da informação nas suas mais variadas formas, como por exemplo, armazenada em discos ou fitas de backup. Integridade significa garantir que se o dado está lá, então não foi corrompido, encontra-se íntegro. Isto significa que aos dados originais nada foi acrescentado, retirado ou modificado. A integridade é assegurada evitando-se alteração não detectada de mensagens (ex. tráfego bancário) e o forjamento não detectado de mensagem (aliado à violação de autenticidade).

   

  • DISPONIBILIDADE: consiste na proteção dos serviços prestados pelo sistema de forma que eles não sejam degradados ou se tornem indisponíveis sem autorização, assegurando ao usuário o acesso aos dados sempre que deles precisar. Isto pode ser chamado também de continuidade dos serviços.
• Confidencialidade: é a garantia de que a informação não será conhecida por quem não deve. O acesso às informações deve ser limitado, ou seja, somente as pessoas explicitamente autorizadas podem acessá-las. Perda da confidencialidade significa perda do segredo. Se uma informação for confidencial, ela será secreta e deverá ser guarda com segurança. e não divulgada para as pessoas não autorizadas.
  
  Confiabilidade: pode ser caracterizada como a condição em que um sistema de informação presta seus serviços de forma eficaz e eficiente, atendendo às especificaçõesde suas funcionalidades, dentro de condições definidas. Ou melhor, um sistema de informação irá "desempenhar o papael que foi proposto ali".

Questão 133999

• Banca: CESPE / CEBRASPE
• Órgão: CEHAP-PB
• Ano: 2009
• Provas: CESPE - 2009 - CEHAP-PB - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Com relação a técnicas e estratégias de validação para desenvolvimento de sistemas, assinale a opção correta.

• A. O teste gama envolve a liberação do sistema a uma série de clientes potenciais que concordam em usar esse sistema.
• B. O teste alfa, conhecido como teste de aceitação, encerra-se quando cliente e projetista concordam que o sistema é uma implementação aceitável dos requisitos do sistema e não se aplica a sistemas desenvolvidos para um único cliente.
• C. Aplicado ao final do processo de teste, o teste caixa-preta ou comportamental é baseado nos requisitos funcionais do software.
• D. A revisão técnica informal é a mais utilizada para verificação de requisitos e examina a especificação para identificar erros de conteúdo ou de interpretação.

Gabarito: C

Comentários

•  A) está falando dos testes Beta

  B) O erro está no final quando ele fala que não se aplica a sistemas de cliente únicos

  C) ok

  D) Revisão Técnica Formal

• Segundo Pressman (6ª edição - página 304), testes alfa e beta somente são utilizados quando o sistema é desenvolvido para ser utilizado por múltiplos clientes. No caso de um único cliente, utiliza-se o teste de aceitação. Portanto, o erro da alternativa "a" está em afirmar que o teste alfa é conhecido como teste de aceitação. O conceitos são diferentes.
• A alternativa B foi retirada do Sommerville (7ª edição), e não do Pressman.
  Vamos ao trecho do livro:
  

  "O teste de aceitação é algumas vezes chamado de teste alfa. Os sistemas sob encomenda são desenvolvidos para um único cliente. O processo de teste alfa continua até que o projetista do sistema e o cliente concordem que o sistema liberado é uma implementação aceitável dos requisitos do sistema.
  Quando um sistema será comercializado como um produto de software, frequentemente é usado um processo de teste denominado teste beta."

  Vamos agora destrinchar a alternativa B:
   - O teste alfa, conhecido como teste de aceitação (correto);
   - encerra-se quando cliente e projetista concordam que o sistema é uma implementação aceitável dos requisitos do sistema (correto);
   - não se aplica a sistemas desenvolvidos para um único cliente (errado). Como podemos ver no trecho do livro, testes alfa se aplicam a sistemas desenvolvidos para um único cliente. Testes beta é que não se aplicam.

• por que a revisão técnica formal é a mais utilizada? não é o contrário? e o teste caixa-preta tem que ser aplicado no final do processo de teste, não pode ser no meio ou no início?

• Teste caixa-preta:

  - também chamado de teste comportamental;

  - focaliza os requisitos funcionais de um sistema, com pouca preocupação em relação à estrutura lógica interna do software.

  - tenta encontrar erros nas seguintes categorias:

  (1) funções incorretas ou faltando;

  (2) erros de interface;

  (3) erros em estruturas de dados ou acesso a bases de dados externas;

  (4) erros de comportamento ou de desempenho;

  (5) erros de inicialização e término.

  (Pressman)

Questão 135409

• Banca: CESPE / CEBRASPE
• Órgão: EMBASA
• Ano: 2010
• Provas: CESPE / CEBRASPE - 2010 - EMBASA - Analista de Saneamento - Analista de Tecnologia da Informação - Desenvolvimento
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Métricas são utilizadas para medir produtividade, estimar qualidade
dos software e identificar e quantificar as funcionalidades
requeridas para um projeto. Com relação a esse assunto, julgue os
itens que se seguem.

Fator de estimativa de qualidade (EQF, estimate quality factor) é definido como a área sob a curva do valor atual pela área entre o valor estimado e o atual. Isso é o inverso da percentagem de erro ou o erro médio relativo.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Neste link tem uma explicação sobre EQF:

  http://www.toddlittleweb.com/Presentations/wwsdc/Metrics.ppt

   

• Copiem o link e colem na opção abrir do power point.

Questão 137134

• Banca: FGV
• Órgão: Senado Federal
• Ano: 2008
• Provas: FGV - 2008 - Senado Federal - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Dos grupos listados a seguir, assinale os que não correspondem a atributos de qualidade do software.

• A. modularidade, eficiência e segurança.
• B. capacidade de recuperação, facilidade de programação e facilidade de gerenciamento.
• C. complexidade, robustez e facilidade de reúso.
• D. testabilidade, proteção e confiabilidade.
• E. facilidade de aprendizado, facilidade de compreensão e facilidade de adaptação.

Gabarito: B

Comentários

•  Facilidade de programação e facilidade de gerenciamento não tem nada a ver com atributos de qualidade do ponto de vista do usuário ou cliente.

• Atributos da norma ISO/IEC 9126-1:2001 (Os atributos de qualidades, ou características de qualidade, são quebrados em sub-características).
  
  1)   Funcionalidade
  a)   adequação
  b)   precisão
  c)   interoperabilidade
  d)   segurança
  e)   estar de acordo com padrões
  2)   Confiabilidade
  a)   maturidade
  b)   tolerância a falhas
  c)   recuperabilidade
  3)   Usabilidade
  a)   compreensibilidade
  b)   facilidade de aprendizado
  c)   operabilidade
  4)   Eficiência
  a)   comportamento no tempo ou desempenho
  b)   uso de recursos
  5)   Manutenibilidade
  a)   analisabilidade
  b)   modificabilidade
  c)   testabilidade
  6)   Portabilidade
  a)   adaptabilidade
  b)   instalabilidade
  c)   co-existência
  
  A norma fala que a lista é exaustiva, portanto o que não está na lista não é atributo de qualidade. Poderíamos considerar, sendo muito pouco rigorosos, "facilidade de programação" como modificabilidade, porém não podemos encontrar nada de facilidade de gerenciamento. Portanto, letra B) está incorreta. 
  
  Um bom detalhamento dos atributos pode ser obtido aqui: http://cnx.org/content/m17527/latest/
• Será que a FGV inventou seus próprios atributos de qualidade?
  Desde quando complexidade é um atributo de qualidade? Onde tem isso?
• De acordo com a 9a edição do sommerville, os atributos de qualidade de software são
  
  Segurança
  Proteção
  Confiabilidade
  Resiliência
  Robustez
  
  Compreensibilidade
  Testabilidade
  Adaptabilidade
  Modularidade
  Complexidade
  
  Portabilidade
  Usabilidade
  Reusabilidade
  Eficiência
  Capacidade de aprendizado

Questão 140860

• Banca: CESPE / CEBRASPE
• Órgão: ANTAQ
• Ano: 2009
• Provas: CESPE - 2009 - ANTAQ - Analista Administrativo - Informática
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Acerca de gestão de processos de negócio e gestão estratégica, julgue os itens subsequentes.

A gestão da qualidade total não deve ser confundida com o gerenciamento de processos, não devendo essas duas atividades sobrepor-se.

• C. Certo
• E. Errado

Gabarito: E

Comentários

•  Segundo a gestão de qualidade total, as necessidades dos clientes devem ser transformadas em requisitos dos processos, através do gerenciamento de processos.

• A gestão da qualidade total não deve ser confundida com o gerenciamento de processos,

  até aqui está correta, são coisas diferentes

   não devendo essas duas atividades sobrepor-se.
  

  está parte está errada porque a gestão da qualidade total envolve também o gerenciamento de processos, aliás, um dos princípios da gestão da qualidade total é a administração por meio de processos.

• ERRADO.

   

  São os 7 elementos constitutivos da Gestão da Qualidade Total:

   
  • Liderança;
  • Planejamento Estratégico;
  • Foco no Cliente;
  • Informação e Análise;
  • Gestão e Desenvolvimento de Pessoas;
  • Gestão de Processos;
  • Resultados Institucionais.

Questão 140908

• Banca: CESPE / CEBRASPE
• Órgão: ANTAQ
• Ano: 2009
• Provas: CESPE - 2009 - ANTAQ - Analista Administrativo - Informática
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

A respeito da engenharia de software, julgue os itens de 101 a 109.

O gerenciamento de qualidade de software pode ser estruturado em três atividades principais: garantia de qualidade, planejamento de qualidade e controle de qualidade. O objetivo da atividade de garantia da qualidade é assegurar que os processos e os produtos de software, no ciclo de vida do projeto, estão em conformidade com os padrões, os procedimentos e as descrições de processos definidos para o projeto submetidos a essa atividade.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Item correto.
  Essa definição está de acordo com o PMBoK 4º versão, Gerência de Qualidade.

• O gerenciamento de qualidade de software pode ser estruturado em três processos e não em três atividades ...

Questão 142825

• Banca: FIP
• Órgão: Câmara Municipal de São José dos Campos - SP
• Ano: 2009
• Provas: FIP - 2009 - Câmara Municipal de São José dos Campos - SP - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

O processo de verificação e validação de um software é realizado através de um conjunto de atividades. É correto afirmar que:

• A. o papel da verificação é assegurar que o programa realiza aquilo que o usuário necessita e atende as suas expectativas.
• B. as atividades de validação examinam se o software atende aos seus requisitos funcionais e não funcionais.
• C. os testes podem mostrar a presença de erros em um programa, mas não servem para demonstrar a sua ausência.
• D. o projeto dos casos de teste não deve envolver a passagem de parâmetros, pois o objetivo é testar cada módulo, individualmente, em busca de erros.
• E. N.D.A.

Gabarito: C

Comentários

• Questão errada mesmo, eu assinei a Letra C, pois era a mais lógica. Mas regressão que eu saiba pode ser feito em qualquer etapa.
• O que está errado na letra b? Patra mim tanto a C quanto a B estão corretas.
• a) o papel da verificação validação é assegurar que o programa realiza aquilo que o usuário necessita e atende as suas expectativas.
  
  b) as atividades de validação verificação examinam se o software atende aos seus requisitos funcionais e não funcionais.

• c-

  testes é para ver ha erros, e nao se nao ha erros.

  usario valida o software

  analista verifica o software

• VERIFICAÇÃO: refere-se ao conjunto de tarefas que garantem que o software implementa corretamente uma função especificação.

   - " Estamos criando o produto corretamente?"

  VALIDAÇÃO: refere-se a um conjunto de tarefas que asseguram que o software foi criado e pode rastreado segundo os requisitos do cliente.

   - "Estamos criando o produto certo?"

Questão 142861

• Banca: FIP
• Órgão: Câmara Municipal de São José dos Campos - SP
• Ano: 2009
• Provas: FIP - 2009 - Câmara Municipal de São José dos Campos - SP - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Normalmente, são descobertos defeitos durante o processo de verificação e validação de um software, e os artefatos onde eles estão localizados devem ser modificados para sua correção. Não é correto afirmar que:

• A. a inspeção de todos os caminhos possíveis de um programa é possível, embora não seja realizada na prática, pois implica aumento nos prazos e custos de desenvolvimento.
• B. a confiabilidade de um software apresenta características semelhantes às do hardware onde ele é executado.
• C. frequentemente, a correção de um defeito acarreta a introdução de novos defeitos.
• D. um teste bem sucedido é aquele que revela um erro ainda desconhecido.
• E. os testes de caixa branca são utilizados para demonstrar que as estruturas de controle interno de um programa apresentam o comportamento esperado.

Gabarito: B

Comentários

• b) ERRADO. Os primeiros trabalhos sobre confiabilidade de software tentaram explorara matemática da teoria da confiabilidade de hardware para a previsão da confiabilidade de software. A maioria dos modelos de confiabilidade relacionada com hardware tem como base falhas devido a desgaste e não as falhas devido a defeitos de projeto. Em hardware, as falhas devido a desgaste físico (por exemplo, os efeitos decorrentes de temperatura, corrosão, choque) são improváveis do que uma falha relacionada ao projeto. Infelizmente, a reciproca é verdadeira para o software. Na realidade, todas as falhas de software podem ser associadas a problemas de projeto ou de implementação, o desgaste não entra em questão.

   

  Fonte: Engenharia de Software - 8ª Edição. Por Roger Pressman, Bruce Maxim

Questão 143746

• Banca: FIP
• Órgão: Câmara Municipal de São José dos Campos - SP
• Ano: 2009
• Provas: FIP - 2009 - Câmara Municipal de São José dos Campos - SP - Programador
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Com relação à qualidade de software, é incorreto afirmar que:

• A. os testes são incapazes de garantir que um software não irá apresentar erros durante a execução.
  
• B. os testes são técnicas dinâmicas de verificação e validação, pois trabalham com uma representação executável do sistema.
  
• C. o processo de validação tem por objetivo realizar testes até que nenhum erro seja encontrado.
  
• D. um teste bem-sucedido é aquele que revela um erro ainda desconhecido.
  
• E. testes de programas podem ser usados para mostrar a presença de erros, mas nunca para mostrar a sua ausência.

Gabarito: C

Comentários

• Em algumas situações os custos dos testes são maiores que o prejuízo do erro. Nestes casos pode-se validar um software contendo erros.
  

• Afirmativa incorreta: Letra C . Os testes não podem garantir que o Software está livre de erros. Logo, não temos que essa garantia que "nenhum erro será encontrado", mesmo com testes exaustivos.

• O objetivo de qualquer teste é justamente expor os possíveis erros do sistema. Se formos pensar que o objetivo é testar até nenhum erro ser encontrado, podemos simplesmente não fazer nenhum teste que nenhum erro será encontrado e damos o software como validado.

  Gabarito C

  Sobre a alternativa A: se não tivermos testado a condição de erro X, se esta ocorrer durante a execução do programa, teremos uma falha. Com isso, podemos dizer que os testes realmente não podem garantir que não ocorrerá erro na execução de um programa, salvo se prevermos todas as infinitas condições em que o SW estará submetido.

Questão 147277

• Banca: FCC
• Órgão: SEFAZ-SP
• Ano: 2009
• Provas: FCC - 2009 - SEFAZ-SP - Agente Fiscal de Rendas - Tecnologia da Informação - Prova 3
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

O processo de confirmação que um software vai ao encontro das especificações de software se trata de um conceito- chave de qualidade denominado

• A. Validação.
• B. Verificação.
• C. Precisão.
• D. Acurácia.
• E. Confiabilidade.

Gabarito: B

Comentários

•  Verificação
  A verificação tem o objetivo de avaliar se o que foi planejado realmente foi realizado. Ou seja, se os requisitos, funcionalidades e performance documentados foram implementados. Verificação também pode ser realizada para especificação de sistemas, para avaliar se os requisitos estão sendo documentados como deveriam e ainda prever falhas ou inconsistências entre requisitos. 
  

  Validação
  A validação tem o objetivo de avaliar se o que foi entregue atende as expectativas. Ou seja, se os requesitos, independente do que foi planejado, estão implementados para atender ao negócio (cliente). 
  Validação final do sistema é realizada pelo cliente ou usuário. 
  
  
  
• A definição dos outros itens de acordo com a norma 9126:
  
  * Validação: A validação refere-se ao processo de examinar um produto para determinar sua conformidade com as necessidades do usuário.
  * Verificação: A verificação refere-se ao processo de examinar o resultado de dada atividade para determinar a sua conformidade com os requisitos estabelecidos para a mesma atividade.
  * Acurácia: Capacidade do produto de software de prover, com o grau de precisão necessário, resultados ou efeitos corretos ou conforme acordados.
  * Confiabilidade: Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas.

• ti_master...
  
  Sommerville, 8a edição, capítulo 22
  
  "Essas definições nos dizem que o papel da verificação envolve verificar se
  o software está de acordo com suas especificações"
  
  "A finalidade da validação é assegurar que o sistema de software atenda às
  expectativas do cliente. Vai além de verificar se o sistema está conforma a
  sua especifiação para mostrar que o software realiza o que o cliente espera
  que ele faça."
  
  
  Ele fala da expressão utilizada por Boehm (Boehm, 1979), idealizador do
  modelo espiral:
  
  "validação: estamos construindo o produto correto?"
  "verificação: estamos construindo o produto corretamente?"
  ....
  
  Abraços.
  Vinícius Martinez

• Verificação: requisitos, funcionalidades, especificações (estamos construindo o produto corretamente?)
  Validação: atender às expectativas do cliente (estamos construindo o produto correto?)

• Truque para lembrar.

  Verificar: Especificação

  Já validação não se encaixaria.

Questão 147283

• Banca: FCC
• Órgão: SEFAZ-SP
• Ano: 2009
• Provas: FCC - 2009 - SEFAZ-SP - Agente Fiscal de Rendas - Tecnologia da Informação - Prova 3
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

O teste de ameaça normalmente deve ser aplicado dentro de um projeto de software nas etapas de

• A. desenvolvimento inicial e desenvolvimento intermediário.
• B. desenvolvimento intermediário e teste de aceitação.
• C. desenvolvimento intermediário e teste de sistema.
• D. teste de integração e teste de aceitação.
• E. teste de integração e teste de sistema.

Gabarito: E

Comentários

• Seria o mesmo que teste de penetração?
  
  A meu ver é um teste semelhante ao teste de segurança porém mais voltado para identificar falhas. Não achei nenhuma referência confiável para este assunto. Quem descobrir o artigo misterioso de onde a FCC copiou/colou esta questão, avise-nos.
  

• Nesse caso, teste de ameaça está inserido no contexto de Teste de Segurança. Sabemos que o Teste de Segurança é realizado em 2 momentos: durante o teste de integração, pois nesse momento estamos verificando se os módulos são capazes de trabalharem junto; e no teste de sistemas, onde temos o teste de desempenho, recuperação, segurança e estresse.

• O máximo que eu encontrei foi uma referência a teste de ameça num TCC ao seguinte livro: "Testes de Software: Produzindo Sistemas Melhores e Mais Confiáveis, Leonardo Molinari, 2003. "
  
  Se alguém tiver ele pode ser que a resposta esteja no mesmo.
• no teste de aceitação não seria, pois lembremos da curva onde o custo de correção aumenta à medida que as fases vão progredindo, o custo de se corrigir algo na fase de aceitação seria altissimo

• Marquei a E, pois levei em consideração a Estratégia de Teste elaborado por pressman

  https://uploaddeimagens.com.br/imagens/estrategia_de_testes_-_pressman-png

Questão 147286

• Banca: FCC
• Órgão: SEFAZ-SP
• Ano: 2009
• Provas: FCC - 2009 - SEFAZ-SP - Agente Fiscal de Rendas - Tecnologia da Informação - Prova 3
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Na prática de garantia de qualidade de software, contrapondo com o controle de qualidade de software, se aplica a atividade:

• A. executar teste de software.
• B. desenvolver casos de testes.
• C. definir métricas e medição.
• D. definir estratégias de testes.
• E. definir planos de desenvolvimento de teste.

Gabarito: C

Comentários

• Garantia da qualidade é orientada a processo.
   Garantia da qualidade é orientada a prevenção.
  
  Controle da qualidade é orientado a produto.
  Controle da qualidade é orientado a detecção.

• QUESTIONÁVEL!!!
  
  

  Capítulo 17 - Garantia de qualidade de software, Pressman, PÁGINA 726

  A garantia de qualidade de software (SQA - Software Quality Assurance) é uma “atividade de guarda-chuva” que é aplicada ao longo de TODO o processo de engenharia de software. A SQA abrange:

  (1) métodos e ferramentas de análise, projeto, codificação e teste;

  (2) revisões técnicas formais que são aplicadas durante cada fase de engenharia de software;

  (3) uma estratégia de teste de múltiplas fases;

  (4) controle da documentação de software e das mudanças feitas nela;

  (5) um procedimento para garantir a adequação aos padrões de desenvolvimento de software;

  (6) mecanismos de medição e divulgação
  
  De acordo com o Pressman, as letras C e D estão corretas!!!
  
   

• Normalmente quando se fala em SQA, se fala em conjunto de Controle e Garantia da qualidade. Logo as atividades citadas pelo comentário anterior faz parte tanto do processo de garantia quanto do controle. E sabe-se bem a diferença entre controle e garantia, como já citado na questão. Controle = produto. Garantia = processo.

• Vamos lá meus amigos... tudo bem com a alternativa C, mas demorei um pouquinho pra "engolir" a alternativa D como errada. Digerindo um pouquinho o Pressman, temos:

  
  

  1) Conceitos:

  1.1) Controle de qualidade:

  "Engloba um conjunto de ações de engenharia de software que ajudam a garantir que cada produto resultante atinja suas metas de qualidade", permitindo "a uma equipe de software ajustar o processo quando qualquer um desses produtos resultantes deixe de atender às metas estabelecidas para a qualidade". (pág. 370)
  

  1.2) Garantia da qualidade:

  "Estabelece a infraestrutura que suporta métodos sólidos de engenharia de software, gerenciamento racional de projeto e ações de controle de qualidade" (...). "Consiste em um conjunto de funções de auditoria e de relatórios que possibilita uma avaliação da efetividade e da completude das ações de controle de qualidade". (pág. 370)
  

  Observe que a Garantia vem antes e depois do Controle: antes, no sentido de suportá-lo e depois, no sentido de avaliá-lo.
  

  
  

  2) Testes:

  "Os testes de software" (...) "são uma função de controle de qualidade com um objetivo principal - descobrir erros. O papel da SQA é garantir que os testes sejam planejados apropriadamente e conduzidos eficientemente de modo que se tenha a maior probabilidade possível de alcançar seu objetivo primário". (pág. 389)

  Conclui-se que, não é papel do SQA "definir estratégias de teste" (afirmativa D), mas sim, garantir que os tais testes sejam planejados apropriadamente e conduzidos eficientemente.
  

  Pressman "subdivide" os testes de software que, conforme dito anteriormente, compõe uma função de controle de qualidade, em:

  a) Estratégias de teste de software (pág. 401)

  b) Testes de aplicativos convencionais (pág. 428)

  c) Testes de aplicações orientadas a objeto (pág. 453)

  d) Testes de aplicações para a web (pág. 468)

  Assim, ocorrendo a palavra teste em uma alternativa de múltipla escolha da FCC, existe uma grande chance de estar relacionado a Controle de qualidade, não a Garantia da qualidade. Observe, por exemplo, o texto das alternativas onde, a alternativa correta, não traz a palavra "teste". Sendo, portanto, relativa a Garantia da qualidade.

  Referência:

  PRESSMAN, Roger S. 2011. Engenharia de Software. 7ª ed.
  

• c-

  Garantia de qualidade engloba atividades para prevenção de defeitos, é uma área que define metodologias e ferramentas de apoio tendo como entrada o plano de qualidade de software e resultados de medições de qualidade.

  
  Controle de qualidade é monitoramento: a detecção de defeitos, por peer reviews, teste e análise de tendências etc.

   

  Garantia: Lida com processos. Meta: prevenção

  Controle: mexe com produtos. Meta: detecção

Questão 147694

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

Considere as informações abaixo em relação ao desenvolvimento de sistemas:

I. executar um software com o objetivo de revelar falhas, mas que não prova a exatidão do software.
II. correta construção do produto.
III. construção do produto certo.

Correspondem corretamente a I, II e III, respectivamente,

• A. validação, verificação e teste.
• B. verificação, teste e validação.
• C. teste, verificação e validação.
• D. validação, teste e verificação.
• E. teste, validação e verificação.

Gabarito: C

Comentários

• Teste -> é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Uma das características do teste é: Um bom teste tem alta probabilidade de encontrar um erro.
  
  Verificação -> refere-se ao conjunto de atividades que garante que o software implementa corretamente uma função específica.
  
  Validação -> refere-se a um conjunto de atividades diferente que garante que o software construído corresponde aos requisitos do cliente.
  
  Fonte: Pressman - 4ª edição.

• Barry Boehm, pioneiro da engenharia de software, expressou sucintamente a diferença entre validação e verificação
  (BOEHM, 1979):

  
  • 'Validação: estamos construindo o produto certo?'
  • 'Verificação: estamos construindo o produto da maneira certa?'

• c-

  Requisitos sao validados, o software é verificado.

• Verificação está mais relacionado ao modo de construir o sistema. tais como: metodologias, linguagens etc.Ou seja, se refere a maneira de desenvolver o sistema.
  Validação está relacionado se os requisitos do sistema estão aderentes ao acordado com os clientes.Pode acontecer de fazer uma verificação eficiente em um sistema, ou seja, o mesmo foi produzido conforme planejado, mas na hora de entregar ao cliente (validação) não era o que este solicitou.

• Esta resposta está errada, de acordo com o simulado estácio de engenharia de software. A correta seria

  verificação, teste e validação. 

Questão 153145

• Banca: CESPE / CEBRASPE
• Órgão: TJ-DFT
• Ano: 2008
• Provas: CESPE - 2008 - TJ-DFT - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Julgue os itens a seguir, acerca da qualidade e da maturidade em
projetos de software.

Técnicas de controle estatístico de processos, que são clássicas em processos de manufatura, permitem determinar se as mudanças e as variações em métricas de conjuntos de projetos de software são indicadoras de aprimoramento ou degradação desses processos.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Por meio do CEP podemos identificar o momento exato em que uma mudança ocorreu no processo. O CEP disponibiliza diversos gráficos para essa finalidade: histogramas, gráficos de dispersão, linhas de tendência, gráfico de controle, etc.
  
  Assim que percebemos uma alteração em algum gráfico aquilo será indicativo de mudanças que poderão apresentar aprimoramento ou degradação dos processos
• No final da frase "aprimoramento ou degradação desses processos.", a palavra degradação tornaria frase errada? Alguem poderia explicar melhor?
• Acho que está errada. Não é variação nas métricas e sim nos indicadores, medidas coletadas, estatísticas, etc... Penso que houve um "abuso de linguagem" com relação às diferenças entre métricas,  medidas, indicadores,etc...Enfim, acho que a questão ficou no mínimo imprecisa.
• Indicar é diferente de determinar. Difícil cravar o item como correto.

Questão 153148

• Banca: CESPE / CEBRASPE
• Órgão: TJ-DFT
• Ano: 2008
• Provas: CESPE - 2008 - TJ-DFT - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Julgue os itens a seguir, acerca da qualidade e da maturidade em
projetos de software.

A eficiência na remoção de defeitos (defect removal efficiency) é uma métrica específica da fase de testes de um projeto de software que permite avaliar tanto a capacidade de testar da equipe quanto os erros deixados no software durante as fases anteriores, inclusive a especificação, a análise e a codificação.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Uma métrica de qualidade é a eficiência na remoção dos defeitos (DRE)
  

  Para o projeto todo a DRE é definida como:

  DRE=E/(E+D)

  E – quantidade de erros encontrados
  D – Quantidade de defeitos

  O valor ideal de DRE é 1, ou seja, nenhum defeito é encontrado no software. As atividade de DRE devem ser realizadas ao longo de cada etapa da Eng. Software

•  Creio que o erro está em afirmar que DRE é uma métrica específica da fase de testes.

  Fonte: Pressman

• O erro da questão não está na descrição da métrica em si, e sim na afirmação "específica da fase de testes de um projeto de software".

  Ora, as fases que compõem um projeto de software são: Levantamento de Requisitos; Análise; Projeto (ou Design); Implementação; e Manutenção pós-entrega.

  Os testes, estão presentes em todas estas fases de um projeto de software com características peculiares para cada fase, inclusive em relação ao tempo gasto com os testes em cada fase (tempo de testes gasto na Análise é menor do que o gasto na Implementação).

  Assim sendo, a afirmação está errada por considerar que os Testes representam uma fase de um projeto de software. Na verdade, os Testes são somente uma disciplina e não uma fase (estão presentes ao longo de todo o projeto de software).

  PS: Não confundir Modelos (Cascata, Iterativo e Incremental, Evolutivo, etc) com as fases de um projeto de software.

• Para mim o erro desta questão está em : "capacidade de testar da equipe".
  
  Se eu já tenho uma equipe de testes, a mesma não é capacitada ? 
  
  Por que essa métrica avaliaria a capacidade da equipe ?

• Segundo Pressman (7ed, pg 595), "Uma métrica de qualidade que traz benefícios tanto para o projeto quanto para o processo é a eficiência na remoção de defeitos (defect removal efficiency - DRE). Essencialmente, a DRE é uma medida da habilidade de filtragem das ações de garantia de qualidade e controle quando elas são aplicadas através de todas as atividades da estrutura de processo. (..) Se for usada como uma métrica que fornece um indicador da habilidade de filtragem das atividades de controle de qualidade e segurança, a DRE estimula a equipe de projeto de software a instituir técnicas para encontrar o maior número possível de erros antes da entrega do software. A DRE também pode ser usada no projeto para avaliar a habilidade de uma equipe para encontrar erros antes que eles passem para a próxima atividade na estrutura do software ou para a próxima ação da engenharia de software."

• A eficiência na remoção de defeitos (defect removal efficiency) é uma métrica específica da fase de testes de um projeto de software (ERRADO - segundo o RUP teste não é uma fase de um projeto de SW, mas sim uma disciplina que está presente em todas as fases do projeto de SW) que permite avaliar tanto a capacidade de testar da equipe quanto os erros deixados no software durante as fases anteriores, inclusive a especificação, a análise e a codificação

  
  

  Bons estudos!
  

Questão 153151

• Banca: CESPE / CEBRASPE
• Órgão: TJ-DFT
• Ano: 2008
• Provas: CESPE - 2008 - TJ-DFT - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Qualidade de Software

Julgue os itens a seguir, acerca da qualidade e da maturidade em
projetos de software.

Um dos objetivos de uma técnica de revista formal é de garantir que o software foi representado em conformidade com padrões predefinidos.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Segundo Pressman:
  "Uma revisão técnica formal é uma atividade de garantia de qualidade de software realizada por engenheiros de software (e outros). Os objetivos são:
  1 - Descobrir erros na função, na lógica ou na implementação, para qualquer representação do software;
  2 - Verificar se o software sob revisão satisfaz os requisitos;
  3 - Garantir que o software tenha sido representado de acordo com padrões pre-definidos;
  4 - Conseguir software que seja desenvolvido de modo uniforme;
  5 - Tornar os projetos mais administráveis".

Questão 153154

• Banca: CESPE / CEBRASPE
• Órgão: TJ-DFT
• Ano: 2008
• Provas: CESPE - 2008 - TJ-DFT - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Julgue os itens a seguir, acerca da qualidade e da maturidade em
projetos de software.

O fator de qualidade flexibilidade de McCall é definido como a capacidade de um software de se adaptar a diferentes sistemas operacionais ou diferentes configurações de hardware.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Fatores da Qualidade de Software (McCall)   

                                                                          * ISO/IEC 9126:1991 NBR 13596

  1.Manutenibilidade*: Posso consertá-lo?
  2. Flexibilidade: Posso mudá-lo
  3. Testabilidade: Posso testá-lo?
  4. Portabilidade*: Poderei usá-lo em outra máquina?
  5. Reusabilidade: Poderei reutilizá-lo em outra máquina?
  6. Interoperabilidade: Poderei compor uma interface com outro sistema?
  7. Corretitude: Ele faz aquilo que eu quero?
  8. Confiabilidade*: Ele se comporta com precisão o tempo todo?
  9. Eficiência*: Ele rodará no meu hardware tão bem quanto possível?
  10. Integridade: Ele é seguro?
  11. Usabilidade*: Ele foi projetado para o usuário?

   

•  "adaptar a diferentes sistemas operacionais..." é portabilidade.

• Flexibilidade se refere à evoluir a solução de software de maneira eficiente e economica. Já Portabilidade se refere à solução de software funcionar em diversas plataformas de hardware e sistemas operacionais.

• Gabarito Errado

  Em 1977, McCall propôs um modelo para a avaliação da qualidade de software. Esse modelo envolve um conjunto de três fatores que avalia o software com relação a três pontos de vista distintos.I - Com relação ao uso do produto (Características Operacionais).
  
  * Corretudide → Medida na qual o software satisfaz as especificações e objetivos visados pelo cliente.
  
  * Confiabilidade → À medida que se pode esperar que um programa execute sua função pretendida com a precisão exigida.
  
  * Eficiência → É a quantidade de recursos computacionais e de código exigida para que um programa execute sua função, com total precisão, visando realizar a operação de forma 100% segura.
  
  * Integridade → Medida na qual, contrala-se o acesso ao software e aos dados, bloqueando assim o acesso de pessoas não autorizadas, para que não ocorra perda de dados ou de código.
  
  * Usuabilidade → Mede a facilidade para a utilização do software.
  
  II - Com relação a alteração do produto (Habilidade para ser alterado).
  
  * Manutenção → O esforço exigido para localizar e reparar erros em um programa.
  
  * Flexibilidade → O esforço utilizado para realizar uma alteração no software, isto é, qual o grau de facilidade que o sw oferece para a sua alteração, de forma rápida e eficaz?
  
  * Testabilidade → São todos os recursos utilizados, no teste do software, isto é, o esforço exigido para testar um programa a fim de garantir que ele execute a função pretendida.
  
  III - Transição do produto (Adaptabilidade a novos ambientes).
  
  * Portabilidade → Mede a facilidade com que um produto pode ser movido para outra plataforma, ou software.
  
  * Reusabilidade → Medida na qual o software, ou parte dele, poder ser reusado em outros softwares, em outras palavras, o código do sw deve ser reaproveitável.
  
  * Interoperabilidade → O software é capaz de ser acoplado ao outro

   

   

  "Retroceder Nunca Render-se Jamais !"
  Força e Fé !
  Fortuna Audaces Sequitur !

• A questão trata de portabilidade.

  Flexibilidade trata do esforço para modificar um software em operação.

Questão 153160

• Banca: CESPE / CEBRASPE
• Órgão: TJ-DFT
• Ano: 2008
• Provas: CESPE - 2008 - TJ-DFT - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Julgue os itens a seguir, acerca da qualidade e da maturidade em
projetos de software.

Uma matriz de grafo de fluxo de um programa é uma ferramenta que permite a concepção de casos de teste considerando a importância relativa dos percursos possíveis na estrutura do software.

• C. Certo
• E. Errado

Gabarito: C

Comentários

•  Matrizes de Grafos é uma matriz quadrada de nós do grafo de fluxo
  
  
  Linhas e Colunas > Nó identificado.
  
  
  Entradas na matriz > Arestas entre nós.
  
  
  Permite a mecanização da determinação de um conjunto de caminhos básicos

• Segundo Pressman, uma matriz de grafo e uma ferramenta muito útil para assistir os testes. Adicionando um peso de ligação a cada entrada da matriz, a matriz matriz de grafo pode tornar-se uma possante ferramenta para avaliar a estrutura de controle do programa durante o teste.

Questão 154681

• Banca: FGV
• Órgão: Senado Federal
• Ano: 2008
• Provas: FGV - 2008 - Senado Federal - Administrador
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

A gestão pela qualidade total é uma tecnologia que se tornou famosa no Brasil no final da década de 80 do século passado. Assinale a alternativa que descreva corretamente uma característica típica dessa tecnologia.

• A. Mudanças imediatas: à semelhança da reengenharia, a gestão pela qualidade total também tinha essa característica, porque seus seguidores insistiam no caráter total da busca pela qualidade.
• B. Delegação plena de autoridade: a delegação de autoridade é proposta antiga de estudiosos, mas é na gestão pela qualidade total que a delegação plena se tornou uma obsessão.
• C. Busca pelo defeito zero: tal busca tem como origem estudos nas indústrias, essencialmente. A busca pelo defeito zero seria aplicável no pátio industrial, embora possa ser aplicada nos escritórios.
• D. Horizontalidade na gestão: contrariamente à verticalização, símbolo da cadeia hierárquica, a horizontalidade é um dos postulados ainda apontados por significativo número de estudiosos como excelente alternativa pois gera o fim da hierarquia.
• E. A empresa como um livro aberto: a empresa tem de abrir a sua situação plena e real, financeira, comercial, funcional, legal a toda estrutura social, não importando o estágio atual, que pode ser de falência, concordata ou de aumento da lucratividade; o objetivo maior é conquistar a confiança de todos e assim partir para a busca da qualidade total de uma forma integrada.

Gabarito: C

Comentários

• Resposta letra "C".

  ==================================================================================================================

  As principais características da Qualidade Total são:

  Foco no cliente;

  Trabalho em equipe permeando toda a organização;

  Decisões baseadas em fatos e dados;

  A busca constante da solução de problemas e da diminuição de erros;

  Valorização do ser humano.

  Já o termo qualidade total tem inserido em seu conceito seis atributos ou dimensões básicas que lhe conferem características de totalidade. Essas seis dimensões são: qualidade intrínseca; custo, atendimento, moral, segurança e ética. Por qualidade intrínseca entende-se a capacidade do produto ou serviço de cumprir o objetivo ao qual se destina.

  A dimensão custo tem, em si, dois focos: custo para a organização do serviço prestado e o seu preço para o cliente. Portanto, não é suficiente ter o produto mais barato, mas sim ter o maior valor pelo preço justo.

  Atendimento é uma dimensão que contém três parâmetros: local, prazo e quantidade, que por si só demonstram a sua importância na produção de bens e na prestação de serviços de excelência. Moral e segurança dos clientes internos de uma organização (funcionários) são fatores decisivos na prestação de serviços de excelência: funcionários desmotivados, mal-treinados, inconscientes da importância de seus papéis na organização não conseguem produzir adequadamente.

  A segurança dos clientes externos de qualquer organização, em um sentido restrito, tem a ver com a segurança física desses clientes e, em um sentido mais amplo, com o impacto do serviço prestado ou da sua provisão no meio ambiente. Hoje em dia, pode-se dizer que o foco no cliente tem primazia absoluta em todas as organizações.

  Finalmente, a sexta dimensão do conceito de qualidade total, a ética, é representada pelos códigos ou regras de conduta e valores que têm que permear todas as pessoas e todos os processos de todas as organizações que pretendem sobreviver no mundo competitivo de hoje.

  Fonte: http://www.programa5s.com.br/qualidade/caracteristicas-da-qualidade-total

• a) ERRADO: enquanto na reengenharia deveriam ocorrer mudanças bruscas, na qualidade total as mudanças são incrementais, decorrendo do processo de melhoria contínua;

   

  b) ERRADO: a qualidade total prescreve a delegação de autoridade, mas não a delegação plena;

   

  d) ERRADO: a horizontalidade apenas destaca a diminuição dos níveis hierárquicos, jamais a sua extinção;

   

  e) ERRADO: este tópico nada tem a ver com a qualidade total.

Questão 156991

• Banca: CESPE / CEBRASPE
• Órgão: TRT - 5ª Região (BA)
• Ano: 2008
• Provas: CESPE - 2008 - TRT - 5ª Região (BA) - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Com relação a engenharia de software, processos de software, análise de requisitos, estratégias de validação e ferramentas CASE, julgue os próximos itens.

A diferença entre verificação e validação reside no fato de que a primeira se refere ao conjunto de atividades que garante que o software realiza corretamente uma função específica, enquanto a segunda refere-se a um conjunto diferente de atividades que garante que o software que foi construído é rastreável às exigências do cliente.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Verificação se refere ao conjunto de atividades que garante que o software implementa corretamente uma função específica.

  Validação se refere a um conjunto de atividades diferente que garante que o software construído corresponde aos requisitos do cliente.

  Pressman, 6ed.

• O objetivo da Verificação é checar se o software atende a seus requisitos funcionais e não funcionais. Validação, no entanto, é um processo mais geral. O objetivo da Validação é garantir que o software atenda às expectativas do cliente. Ele vai além da simples verificação de conformidade com as especificações, pois tenta demonstrar que o software faz o que o cliente espera que ele faça. A Validação é essencial porque as especificações de requisitos nem sempre refletem os desejos ou necessidades dos clientes e usuários do sistema.

   

   

  Fonte: Ian Sommerville, Engenharia de Software, 9ª Edição.

Questão 158986

• Banca: CESPE / CEBRASPE
• Órgão: STJ
• Ano: 2008
• Provas: CESPE - 2008 - STJ - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Acerca de qualidade de software, julgue os itens
subseqüentes.

Os processos no ciclo de vida de um produto de software podem ser classificados como fundamentais, de apoio ou organizacionais. O processo de garantia da qualidade pode ser considerado um processo de apoio que define atividades para garantir a conformidade dos processos e produtos de software com requisitos e planos estabelecidos. Um processo de garantia da qualidade pode abranger a garantia da qualidade do produto, do processo e do sistema de qualidade.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• A Garantia da Qualidade de Software (GQS) é a área-chave de processo do CMM cujo objetivo é fornecer aos vários níveis de gerência a adequada visibilidade dos projetos, dos processos de desenvolvimento e dos produtos gerados. A GQS atua como "guardiã", fornecendo um retrato do uso do Processo e não é responsável por executar testes de software ou inspeção em artefatos.
• ISO 12207
  Classificação de Processos
    Fundamentais: Fornecimento, Operação, Desenvolvimento, Aquisição e Manutenção
    Apoio: Documentação, Verificação, Validação, Auditoria, Revisão, Configuraçao, Qualidade, Resolução de Problema
    Organizacionais: gerência, infra, melhoria, treinamento

• Os processos no ciclo de vida de um produto de software podem ser classificados como fundamentais, de apoio ou organizacionais. O processo de garantia da qualidade pode ser considerado um processo de apoio que define atividades para garantir a conformidade dos processos e produtos de software com requisitos e planos estabelecidos. Um processo de garantia da qualidade pode abranger a garantia da qualidade do produto, do processo e do sistema de qualidade. Garante o do sistema de qualidade?! Pensei que fosse só produto e processo!!!

Questão 158989

• Banca: CESPE / CEBRASPE
• Órgão: STJ
• Ano: 2008
• Provas: CESPE - 2008 - STJ - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Acerca de qualidade de software, julgue os itens
subseqüentes.

Há modelos de qualidade de software nos quais os atributos de qualidade são agrupados em características de qualidade, que, por sua vez, são desdobradas em subcaracterísticas. Por exemplo, confiabilidade é uma possível característica e refere-se à capacidade de o software manter seu nível de desempenho, sob condições estabelecidas, por um período de tempo.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Confiabilidade: "período de tempo em que o software está disponivel para uso, conforme indicado pelos seguintes subatributos: maturidade, tolerância á falha, recuperabilidade" (Pressman)

   

   

• Minha dúvida persiste.

  Confiabilidade tem a ver com DISPONIBILIDADE.

  A questão afirma que Confiabilidade refere-se CAPACIDADE e DESEMPENHO. Como assim?

• Para mim essa definiçao é de disponibilidade, alguém sabe explicar o porquê de ser confiabilidade?
• A questão define CONFIABILIDADE corretamente (A confiabilidade de software é, geralmente, definida como a probabilidade do software operar sem ocorrência de falhas durante um período especificado de tempo em um determinado ambiente. ) Pode ser caracterizada como a condição em que um sistema de informação presta seus serviços de forma eficaz e eficiente. Um sistema de informação irá “desempenhar o papel que foi proposto para si”.
  
  A Disponibilidade de um sistema computacional, indicada por A(t), é a probabilidade de que este sistema esteja funcionando e pronto para uso em um dado instante de tempo t. Informação deve estar disponível sempre que seus usuários (pessoas e empresas autorizadas) necessitarem, não importando o motivo.
  
  São conceitos diferentes. A confiabilidadde fala probabilidade de você poder usar o software sem que ocorra falha. Já a disponibilidade fala que o software tem que estar acessivel quando requisitado.
  
• Essa definição é da ISO 9126-1
• Confiabilidade: Capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas.
  Fonte: NBR ISO/IEC 9126-1:2003

Questão 158992

• Banca: CESPE / CEBRASPE
• Órgão: STJ
• Ano: 2008
• Provas: CESPE - 2008 - STJ - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

No referente a técnicas e estratégias de verificação e
validação, julgue os próximos itens.

Inspeções e walkthroughs podem fazer parte de um processo de verificação e validação, sendo realizadas por equipes cujos membros têm papéis definidos. Quando da inspeção de um código, uma lista de verificação de erros (checklist) é usada. O conteúdo da lista tipicamente independe da linguagem de programação usada.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• bah mas não tem nada a ver com o contexto... walkthrough nada mais é do que um guia para ajudar na execução dos testes. Seria um fluxo de caso de teste, por exemplo: P1. Logar no sistema, P2. Acessar módulo X, P3. Executar operação xpto; P4. Sair do sistema...

•  Acredito que o erro da questão está em afirmar que a inspeção de código usando checklist independe da linguagem de programação. Se vai inspecionar o código é meio nosense dizer que não depende do código.

• o erro esta na ultima parte.
  
  depende sim da linguagem
  
  Vejam: erros de referencia a objetos nao instanciados, por exemplo, nao aparecem em Pascal Estruturado.
• Inspeções e walkthroughs podem fazer parte de um processo de verificação e validação,(...)
  
  Ao meu ver tamém estaria errado afirmar que estes procedimendos estão associados à validação
• Acredito que o erro esteja em dizer que "independe da linguagem de programação usada". 
• Inspeção de software: Verificação Estática
  Verificação: requisitos, diagramas, código fonte
  Restrições: utilidade operacional, desempenho, confiabilidade
  
  Inspeções e walkthroughs podem fazer parte de um processo de verificação e validação
  Quando da inspeção de um código, uma lista de verificação de erros (checklist) é usada. O conteúdo da lista tipicamente independe da linguagem de programação usada.
• .... processo V&V (verificacao e validacao) pode incluir inspecoes e revisoes.
  Ao inspecionar um sistema, voce usa o conhecimento do sistema, seu dominio de aplicacao e a linguagem de programacao ou modelagem para descobrir erro.
  Esses trechos foram tirados do livro de engenharia do Sommerville 9 ed, pag 146.
  
  Diferentes checklists sao usados para diferentes linguaguens de programacao, pois cada linguagem tem seus proprios erros caracteristicos. (Sommerville 9ed pg464.)
  
  A questao esta errada porque o checklist depende da linguagem de programacao.
• Inspeção é verificação estática de código. Validação é dinâmica. Errada questão. 

Questão 162184

• Banca: FCC
• Órgão: TCE-AL
• Ano: 2008
• Provas: FCC - 2008 - TCE-AL - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

A integridade de software é medida

• A. em defeitos por KLOC (milhares de linhas de código).
  
• B. por sua usabilidade.
  
• C. pelo mean-time-to-change ? MTTC.
  
• D. por sua conectividade.
  
• E. pela capacidade do sistema resistir a ataques à sua segurança.

Gabarito: E

Comentários

• KLOC ( 1000 linhas de código )
  
  MTTC (Mean Time To Change -  Tempo médio para mudança) é uma métrica de Manutenabilidade (de Manutenção)
  
  Integridade é a capacidade de um sistema resistir a ataques, intencionais ou não-intencionais.
  
  (Pela norma ISO 17799) Risco é o produto de uma Ameaça pela Vunerabilidade, onde a Ameaça é um agente externo ( como incêndio, terrorismo, funcionários insatisfeitos) e Vunerabilidade faz parte da estrutura interna de um sistema.
  
  Segurança é a probabilidade do ataque ser neutralizado ou repelido.

Questão 163039

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2010
• Provas: CESGRANRIO - 2010 - Petrobrás - Analista de Sistemas Júnior - Processos de Negócios
• Disciplina: Engenharia de Software
• Assuntos: Acoplamento e Coesão; Qualidade de Software

Tanto no paradigma orientado a objetos quanto no paradigma estruturado, existem diversas técnicas úteis para averiguar se um sistema de software foi bem projetado. No primeiro, essas medidas são aplicáveis a classes, e no segundo, são aplicáveis a módulos. Quais, dentre os termos apresentados a seguir, são medidas de qualidade de projeto aplicáveis em ambos os paradigmas?

• A. Fan-in, fan-out e herança.
  
• B. Encapsulamento, herança e coesão.
  
• C. Coesão, acoplamento e polimorfismo.
  
• D. Fan-in, fan-out e acoplamento.
  
• E. Coesão, acoplamento e polimorfismo.

Gabarito: D

Comentários

•  

  • a) Fan-in, fan-out e herança. (Herança só existe no paradigma OO)
  • b) Encapsulamento, herança e coesão. (Herança e encapsulamento só existem no paradigma OO)
  • c) Coesão, acoplamento e polimorfismo. (Polimorfismo só existe no paradigma OO)
  • d) Fan-in, fan-out e acoplamento. Ok
  • e) Coesão, acoplamento e polimorfismo. (Polimorfismo só existe no paradigma OO)
• Fan-in/Fan-out é uma métrica de produto de software.
  
  Segundo Sommerville é isso aí oh:
  
  Fan-in é uma medida do número de funções ou métodos que chamam alguma outra função ou método(digamos X). Fan-out é o número de funções chamadas pela função X. Um  valor alto para Fan-in significa que X está firmemente acoplado com o resto do projeto, e mudanças em X terão grande impacto. Um valor alto para Fan-out sugere que a complexidade geral de X pode ser alta devido à complexidade da lógica de controle necessária para coordenar os componentes chamados.
  Em modelos orientados a objeto é essencialmente a mesma coisa. Contudo, pode ser apropriado fazer uma distinção entre chamadas de outros métodos dentro do objeto e chamadads com base em métodos externos.
• Ainda não tinha ouvido falar em fan-in e fan-out, resolvi a questão por eliminação.
  Herença e polimorfismo só podem ser aplicados a classes, a questão pede o que pode ser aplicado a ambos, só restou a letra D.

• Gente, as alternativas C e E são idênticas! Alguém sabe se caiu assim na prova?

• Questão deveria ser anulada! 02 Alternativas identicas? Wattahell

Questão 163045

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2010
• Provas: CESGRANRIO - 2010 - Petrobrás - Analista de Sistemas Júnior - Processos de Negócios
• Disciplina: Engenharia de Software
• Assuntos: Ferramentas CASE; Qualidade de Software

No contexto da Engenharia de Software, a verificação e a validação são conjuntos de atividades que

• A. envolvem o uso de inspeções técnicas, cujo objetivo é verificar características funcionais de um produto de software, tais como desempenho e usabilidade.
  
• B. asseguram a inexistência de erros de lógica no códigofonte de um produto de software.
  
• C. são de uso exclusivo entre si e correspondem a verificar se o produto de software que está sendo construído atende às expectativas do usuário.
  
• D. são aplicadas após a finalização da etapa de projeto (design) e se limitam às etapas de implementação e de testes.
  
• E. são opcionalmente auxiliadas por ferramentas CASE ou pela construção de protótipos.

Gabarito: E

Comentários

• A especificação do software diz respeito ao processo de verificação do software, a expectativa do cliente diz respeito ao processo de validação do software.

•  A alternativa que poderia gerar confusão é a a) "envolvem o uso de inspeções técnicas, cujo objetivo é verificar características funcionais de um produto de software, tais como desempenho e usabilidade.". No entanto, desempenho e usabilidade são características não-funcionais de um software, por isso errado o item. A V&V não asseguram a inexistência de erros como afirma a letra b). A V&V são de uso comum, uma complementa o trabalho da outra. Por fim, a V&V é aplicada após a finalização da etapa de implementação (tendo como base um arcabouço de desenvolvimento de SW em cascata).

  A alternativa e) é a correta, pois existem ferramentas case como o Eclipse + o JUnit que auxiliam na automatização de testes de unidade por exemplo.

• Na área de qualidade de software validação é a comprovação da aptitude do valor que o software pode derivar de sua aplicação. Deve responder `a questao: o produto correto foi desenvolvido? Já a verificação é um processo paralelo que deve certificar que um sistema ou programa conforma com a especificação para a qual foi produzido. 

Questão 163657

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2010
• Provas: CESGRANRIO - 2010 - Petrobrás - Analista de Sistemas Júnior - Engenharia de Software
• Disciplina: Engenharia de Software
• Assuntos: Métricas de Software; Qualidade de Software

Várias métricas de software são utilizadas para aferir a qualidade de um processo de software, dentre as quais podem-se destacar

• A. Corretude, Manutenbilidade e Integridade.
  
• B. Ponto de Função, Usabilidade e Confiabilidade.
  
• C. Complexidade Ciclomática, Corretude e Manutenbilidade.
  
• D. Usabilidade, Confiabilidade e Nº de Linhas de Código.
  
• E. Usabilidade, Confiabilidade e Integridade.

Gabarito: A

Comentários

• Questão com duas respostas corretas.

   

  Fatores de Qualidade de McCall

  Correção: Quanto um programa satisfaz sua especificação e preenche os objetivos da missão do cliente.

  Confiabilidade: Quanto se pode esperar que um programa realize a função pretendida com a precisão exigida.

  Eficiência: Quantidade de recursos de computação e código necessário para um programa realizar sua função.

  Integridade: Quanto do acesso ao software ou dados por pessoas não-autorizadas pode ser controlado.

  Usabilidade: O esforço necessário para aprender, operar, preparar entradas e interpretar saídas de um programa.

  Manutenibilidade: O esforço necessário para localizar e consertar um erro em um programa.

  Flexibilidade: O esforço necessário para modificar um programa operacional.

  Testabilidade: Esforço necessário para testar um programa, a fim de garantir que ele realize a função esperada.

  Portabilidade: Esforço necessário para transferir o programa de um ambiente de hardware ou software para outro.

  Reutilização: Quanto de um programa (ou partes dele) pode ser reusado em outras aplicações - relativo ao empacotamento e escopo das funções que o programa realiza.

  Interoperabilidade: Esforço necessário para acoplar um sistema a outro.

   

  Fonte: Pressman, Roger S. Engenharia de Software, 6ª Ed. São Paulo: McGrall-Hill, 2006. p. 350.

• A questão trata especificamente da qualidade do PROCESSO DE SOFTWARE, que é um dos componentes para avaliação da qualidade de software.

  Medição pode ser aplicada ao PROCESSO DE SOFTWARE com o objetivo de melhorá-lo de forma contínua.  A eficácia de um processo de software é medida INDIRETAMENTE. Isto é, originamos um conjunto de métricas, baseadas nas saídas que podem ser derivadas do processo. Essas saídas incluem medidas de erros descobertos antes da entrega do software, defeitos entregues aos usuários finais (CORRETUDE), produtos de trabalho entregues (PRODUTIVIDADE) etc. A medição do processo de software é usada com finalidade estratégica.

  Fonte: Engenharia de Software - Roger S. Pressman - Sexta edição -  Capítulo 22.

• O que foi citado acima está na página 509 do Pressman sexta edição.
• Continuo sem entender porque a letra 'E' está errada... Deviam ter anulado esta.
• Colegas,
  
  a meu ver quando a questão pede "qualidades de um processo de software" e não do "software" ela acaba excluindo a possibilidade da Usabilidade como uma das alternativas...
  
  Usabilidade é uma qualidade desejável no "software" (produto) e não no "processo de software" (processo).
  
  Também fiquei na dúvida ao fazer a questão, mas fazendo "engenharia reversa" a partir do gabarito acho que era isso que estava sendo cobrado...
• Página 594 do pressman 7ed:
  
  "Embora existam muitas medidas de qualidade de software, a correção, a manutebilidade, integridade e usabilidade fornecem indicadores úteis para a equipe de projeto. Gilb sugere definições e medidas para cada uma delas."

•  

  "Apesar de existirem várias medidas de qualidade de software, a CORREÇÃO, a MANUTENABILIDADE, INTEGRIDADE  e USABILIDADE fornecem indicadores úteis à equipe de software."

   

  Página 509 do pressman 6ed:

• a-

  As métricas de software permitem desenvolver aplicativos mais complexos com maior velocidade, qualidade e menor custo. As técnicas de medições baseadas em objetos simplificam o projeto mais complexpo.

   

  Existem duas categorias de métricas de software de acordo com Pressman (1995):

  
  Medidas diretas:custo e esforços

  
  Medidas indiretas: aspectos intangíveis, como: funcionalidade, qualidade, complexidade, eficiência, sendo estas mais difíceis de medir.

   

  
  Pressman (1995) classifica as métricas:

  
  1- métricas orientadas ao tamanho: referência- linhas de código, esforço, custo, quantidade de documentação;

  
  2- métricas orientadas à função: funcionalidade ou qualidade. exemplo: técnica de Análise por Pontos de Função;

  
  3- métricas orientadas às pessoas.

   

  obs.: A resposta quer como resposta quais sao exemplos de requisitos nao-funcionais
  e em como elas desenvolvem os aplicativos.

Questão 173326

• Banca: FGV
• Órgão: MEC
• Ano: 2009
• Provas: FGV - 2009 - MEC - Analista de Teste de Qualidade
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

A SQA (Software Quality Assurance) é um padrão sistemático de ações que são exigidas para garantir a qualidade de software. Ela compreende uma variedade de tarefas associadas a grandes atividades.

A seguir são apresentadas as atividades da SQA, à exceção de uma. Assinale-a.

• A. Controle de registro.
• B. Aplicação de métodos técnicos.
• C. Atividades de testes de software.
• D. Realização de revisões técnicas formais.
• E. Aplicação de padrões e procedimentos.

Gabarito: A

Comentários

• O SQA abrange as seguintes tarefas:
   
  1. Aplicação de métodos técnicos;
  2. Realização  de revisões técnicas formais;
  3. Atividades de testes de software;
  4. Aplicação de padrões;
  5. Controle de mudanças;
  6. Medição;
  7. Manutenção de registros e reportagem.

Questão 173329

• Banca: FGV
• Órgão: MEC
• Ano: 2009
• Provas: FGV - 2009 - MEC - Analista de Teste de Qualidade
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Analise a citação a seguir.

"Um conjunto de atributos que têm impacto na capacidade do software de manter o seu nível de desempenho dentro de condições estabelecidas por um dado período de tempo."

A Norma que integra os conceitos de ambiente, estratégias e planejamento de testes, é conhecida por:

• A. ISO 12207
• B. ISO 15504
• C. ISO 9126
• D. IEEE 829
• E. MPS.BR

Gabarito: C

Comentários

• a) ISO 12207: Errada.

  A ISO/IEC 12207 é a norma ISO/IEC que define processo de desenvolvimento de software.

  b) ISO 15504: Errada.
  

  A ISO/IEC 15504, também conhecida como SPICE, é a norma ISO/IEC que define processo de desenvolvimento de software. Ela é uma evolução da ISO/IEC 12207 mas possui níveis de capacidade para cada processo assim como o CMMI.

  c) ISO 9126: Correta!
  

  ISO/IEC 9126 é uma norma ISO para qualidade de produto de software, que se enquadra no modelo de qualidade das normas da família 9000. A norma brasileira correspondente é a NBR ISO/IEC 9126. A norma 9126 se foca na qualidade do produto de software, propondo Atributos de Qualidade.

  d) IEEE 829: Errada.
  

  IEEE 829-1998,[1] também conhecido como o Padrão 829 para Documentação de Teste de Software,[2] é um padrão IEEE que especifica a forma de uso de um conjunto de documentos em oito estágios definidos de teste de software, cada estágio potencialmente produzindo seu próprio tipo de documento.[1][2] O padrão especifica o formato desses documentos mas não estipula se todos eles devem ser produzidos, nem inclui qualquer critério de conteúdo para esses documentos.

   

  e) MPS.BR: Errada.

  
  O MPS.BR ou Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS) voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil.

• Este é o conceito de confiabilidade, segundo a norma 9126.
  Lembrando dos atributos para enriquecer o conhecimento: FUCEMP
  
   
  Funcionalidade: capacidade de executar as funcionalidade requeridas
  Usabilidade: Capacidade de o software ser compreendido, aprendido, usado e apreciado pelo usuário, quando usado nas condições especificadas
  Confiabilidade:   Capacidade de o software manter seu nível de desempenho quando usado nas condições especificadas
  Eficiência:   Capacidade de o software operar no nível de desempenho requerido em relação à quantidade de recursos empregados, quando usado nas condições especificadas
  Manutenibilidade: Capacidade de realizar manutenções no software
  Portabilidade: capacidade de ser utilizado em diferentes ambientes.
• Questão anulada - Conforme alteração Gabarito -
  http://www.questoesdeconcursos.com.br/concurso/justificativa/622/mec-2009-tecnologia-justificativa.pdf

Questão 173338

• Banca: FGV
• Órgão: MEC
• Ano: 2009
• Provas: FGV - 2009 - MEC - Analista de Teste de Qualidade
• Disciplina: Engenharia de Software
• Assuntos: Ferramentas de Desenvolvimento de Software; Qualidade de Software; Teste de Software

Ferramentas de software, frequentemente utilizadas por Analistas de Qualidade e Testes, estão relacionadas a seguir, à exceção de uma. Assinale-a.

• A. Marathon
• B. TestLink
• C. Bugzilla
• D. Filezilla
• E. soapUI

Gabarito: D

Comentários

• Filezilla é de FTP, que opera na porta 21 e 20 utilizando TCP/IP.  Porta 21 para comandos, porta 20 para dados.

   

• Típica questãozinha que não avalia nad ...

Questão 173341

• Banca: FGV
• Órgão: MEC
• Ano: 2009
• Provas: FGV - 2009 - MEC - Analista de Teste de Qualidade
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Entre os critérios de qualidade da norma ISO 9126, não se inclui:

• A. a manutenibilidade.
• B. a funcionalidade.
• C. a confiabilidade.
• D. a utilizabilidade.
• E. a eficicácia.

Gabarito: E

Comentários

• O critério de qualidade é EFICIÊNCIA  e não Eficácia.

• Na verdade eficácia existe sim, no criterio de qualidade em uso. Mas na questão está escrito eficicácia. Isso não existe.
  
• Segundo Sommerville, essa norma idenfitica seis atributos de qualidade:
  
  1. funcionalidade: grau que o software satisfaz as necessidades declaradas;
  2. confiabilidade: período de tempo que o software está disponível para uso;
  3. usabilidade: grau de facilidade em usar o software;
  4. eficiência: grau em que o software faz uso otimizado dos recursos do sistema;
  5. manutenibilidade: facilidade em reparar defeitos no software;
  6. portabilidade: facilidade com a qual o software pode ser transposto para outro ambiente.
  
  Utilizabilidade é dose... mas vai. Acho que a banca ou o próprio QC errou na hora de escrever eficácia.
• Questão anulada - Conforme alteração Gabarito -
  http://www.questoesdeconcursos.com.br/concurso/justificativa/622/mec-2009-tecnologia-justificativa.pdf

Questão 186769

• Banca: FCC
• Órgão: TRE-RS
• Ano: 2010
• Provas: FCC - 2010 - TRE-RS - Analista Judiciário - Analista de Sistemas Suporte
• Disciplina: Engenharia de Software
• Assuntos: Conceitos Básicos em Engenharia de Software; Qualidade de Software

Sobre a engenharia de software, considere:

I. Atualmente todos os problemas na construção de software de alta qualidade no prazo e dentro do orçamento foram solucionados.

II. Ao longo dos últimos 50 anos, o software evoluiu de um produto de indústria para um ferramental especializado em solução de problemas e análise de informações específicas.

III. Todo projeto de software é iniciado por alguma necessidade do negócio.

IV. O intuito da engenharia de software é fornecer uma estrutura para a construção de software com alta qualidade.

Está correto o que consta em

• A. III e IV, somente.
• B. II e III, somente.
• C. I, II e IV, somente.
• D. II, III e IV, somente.
• E. I, II, III e IV.

Gabarito: A

Comentários

• Gabarito: A
  
  Aparentemente, a FFC baseou boa parte da questão no seguinte texto (encontrado na Internet):
  
  O software tornou-se elemento chave na evolução de sistemas e produtos baseados em computador.
  Ao longo dos últimos 50 anos, o SW evoluiu de um ferramental especializado para solução de problemas e análise da informação para uma indústria em si mesmo.
  Mas a antiga cultura e história “de programação” criou um conjunto de problemas que persiste ainda hoje (tornando o SW fator limitante na contínua evolução dos sistemas de computador).
  O software é composto de programas, dados e documentos. Cada um desses itens constitui uma configuração, que é criada como parte do processo de engenharia de software.
  O intuito da engenharia de software é fornecer uma estrutura para a construção de software com alta qualidade.
  
• O intuito da engenharia de software é o desenvolvimento de sistema com bao relação custo-benefício, voltada a especificação, desenvolvimento e manutençao em sistemas de software, aplicnado diversas tecnologias e disciplinas de computação. Objetiva a organização, produtividade e qualidade.
• I - Atualmente todos os problemas na construção de software de alta qualidade no prazo e dentro do orçamento foram solucionados. (Errada)
  II - Ao longo dos últimos 50 anos, o software evoluiu de um produto de indústria para um ferramental especializado em solução de problemas e análise de informações específicas. (Errada,pois o SW evoluiu de um ferramental especializado para solução de problemas e análise da informação para uma indústria em si mesmo. )
  III - Todo projeto de software é iniciado por alguma necessidade do negócio. (Correta)
  Aparentemente, a FFC baseou boa parte da questão no seguinte texto (encontrado na Internet):
  IV - O intuito da engenharia de software é fornecer uma estrutura para a construção de software com alta qualidade.(correto)
  
• Pergunta muito mal elaborada e subjetiva. A redação está péssima e há divergências óbvias.
  
  III. Todo projeto de software é iniciado por alguma necessidade do negócio.
  
  Um projeto de software pode começar por inúmeras outras razões, incluindo:
  - atualização tecnológica;
  - mera curiosidade de um programador.
  só pra citar o que veio a mente agora.
  

• Questão mal elaborada...recurso na certa...as palavras todo e todos são muito forte.

• Estrategia é quando ver uma opção no estilo da II, que não dá nem pra entender, se questionar se está certa pois geralmente esse é o peguinha. 

Questão 195274

• Banca: CESPE / CEBRASPE
• Órgão: TCU
• Ano: 2010
• Provas: CESPE - 2010 - TCU - Auditor Federal de Controle Externo - Tecnologia da Informação - Parte II
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Julgue os itens seguintes, a respeito de engenharia de requisitos.

O checklist de validação é uma forma útil de averiguar se determinado requisito pode ser testado e, em caso afirmativo, se os testes podem ser especificados.

• C. Certo
• E. Errado

Gabarito: C

Comentários

•  É frequentemente útil examinar cada requisito em face de um conjunto de questões do tipo checklist. Eis aqui um pequeno subconjunto de questões que poderiam ser formuladas:
  (…)
  O requisito pode ser testado? Em caso positivo, podemos especificar os testes (algumas vezes chamados critérios de validação) para exercitar o requisito? (…)

   

  comentado por Alessandra Lima
  http://waltercunha.com/blog/index.php/2010/09/22/questoes-de-engenharia-de-requisitos-da-prova-tcu-2010/

• Fonte: Engenharia de Software - Roger s. Pressman (Sexta Edição)
  Página: 120
  
  7.2.6 - Validação
  Checklist de Validação dos Requisitos
  É frequentemente útil examinar cada requisito em face de um conjunto de questões do tipo checklist. Eis aqui um pequeno subconjunto de questões que poderiam ser formuladas: (...) O requisito pode ser testado? Em caso positivo, podemos especificar os testes (algumas vezes chamados critérios de validação) para exercitar o requisito? (…)

• Para sommerville:

  Os artefatos produzidos como consequência da engenharia de requisitos são avaliados quanto à qualidade durante a etapa de validação

  A validação examina a especificação (Em alguns casos, a especificação é um conjunti de cenários de usuários e pouco mais do que isso. Em outros, a especificação pode ser um documento contentando cenários, modelos e descrições por escrito) para garantir que todos os requisitos tenham sido declarados de forma não ambígua, que as inconsistências, omissões e erros tenham sido detectados e corrigidos e que os artefatos estejam de acordo com os padrões estabelecidos para o processo, projeto e produto

  O principal mecanismo de validação de requisitos é a revisão técnica. A equipe de revisão (engenheiros, clientes, usuários e outros interessados) examinam a especificação em busca de erros no conteúdo ou na interpretação, áreas em que talvez sejam necessários esclarecimentos de informações faltantes, de inconsistências, requisitos conflitantes ou requisitos irreais (inatingíveis)

  Para isso, pode ser usada um check list de validação de requisitos: examina cada requisito em relação a um conjunto de perguntas contidas em uma lista de controle

  
  

• Isso não é Verificação não?

  
  

Questão 197506

• Banca: CESPE / CEBRASPE
• Órgão: DETRAN-DF
• Ano: 2009
• Provas: CESPE - 2009 - DETRAN-DF - Analista - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Acerca do desenvolvimento de aplicações e da arquitetura OLAP,
julgue os itens a seguir.

O processo de validação tem por objetivo estabelecer com os clientes confiança quanto ao funcionamento adequado de um software. Enquanto inspeções de software ou revisões por pares são consideradas validação estática, o teste consiste em uma técnica dinâmica de validação de software. Os termos estático ou dinâmico são relativos à necessidade ou não do software ser executado.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Ou seja:
  Validação - de acordo ao uso (ao cliente) (dinamico_
  Verificação - de acordo com os requisitos (estático)
• Não concordei com o gabarito desta questão.
  O trecho: Enquanto inspeções de software ou revisões por pares são consideradas validação estática
   
  Pelo que pude perceber há uma imprecisão quanto ao conceito de validação.  O problema é que a frase inicial ao invés de direcionar qual o contexto usado para o termo validação insere ainda mais confusão.
   
  O processo de validação tem por objetivo estabelecer com os clientes confiança quanto ao funcionamento adequado de um software
   
  A meu ver na questão não foram utilizados os conceitos de Verificação e Validação, já que nesses as inspeções e as revisões por pares estariam no domínio da Verificação.
  
  PS: O comentário anterior não define corretamente os conceitos, pois não há essa classificação de Verificação ser estática e Validação ser dinâmica. Pode haver verificação estática (inspeção) ou dinâmica (teste). O mesmo vale para a Validação.
• De acordo com Sommerville (9 ed., pag. 275), técnicas de analise estática sao técnicas de VERIFICAÇÃO de sistema. Segundo ainda o autor, "talvez a técnica de analise estatica mais usada seja a revisao e inspeção em pares...". Ora, a questão diz em "validação estática", o que está em desacordo com Sommerville. Assim, eu assinalaria Errado.
• Putz...essas questões são para desanimar....
  
  por mais que você saiba a matéria, o Cesp INVENTA conceitos próprios , e pior, não volta atrás mesmo com a literatura mundial monstrando que ele esta errado!

• Houve uma confusão do examinador (estagiário) quanto aos conceitos de Validação e Verificação.

  Ao meu ver... questão ERRADA.
  

• Considero a questão como ERRADA pelo seguinte trecho destacado:

   

  O processo de validação tem por objetivo estabelecer com os clientes confiança quanto ao funcionamento adequado de um software. Enquanto inspeções de software ou revisões por pares são consideradas validação estática, o teste consiste em uma técnica dinâmica de validação de software. Os termos estático ou dinâmico são relativos à necessidade ou não do software ser executado.

   

  O mais correto seria verificação estática, a meu ver.

• vERificação >> Especificação de Requisitos

  validação >> de acordo com o cliente

• Gabarito da questão: Certo.

• Análise estática de softwares, também conhecida como whitebox, trabalha diretamente com o código de uma ferramenta. Nesse caso, os componentes de uma ferramenta são verificados sem que o produto seja executado. Seja por meio de uma ferramenta automatizada ou dos testes manuais, o principal objetivo dessa técnica é identificar erros de programação, tais como: Práticas ruins; Erros de sintaxe; Falhas de segurança.

  Teste dinâmico pode ser empregado de forma complementar a análise estática. Esse tipo de abordagem vê o software como uma “caixa preta” (daí o nome popular “blackbox”) e trabalha, principalmente, com o desempenho e com as informações que são inseridas nas rotinas de entrada e saída de dados. Além disso, são verificados itens como: O tempo de resposta; A performance da aplicação; A capacidade do software se adaptar a diferentes ambientes; O comportamento funcional.

Questão 201322

• Banca: CESPE / CEBRASPE
• Órgão: Banco da Amazônia
• Ano: 2010
• Provas: CESPE - 2010 - Banco da Amazônia - Técnico Científico - Tecnologia da Informação - Arquitetura de Tecnologia
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Para garantir o desenvolvimento de qualidade, é suficiente que a equipe tenha as ferramentas mais atuais de engenharia de software e os melhores computadores.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Ferramentas, processos e pessoal treinado.

  Tudo isso precisa ser dosado de forma igual para se atingir o sucesso.

Questão 205345

• Banca: FEPESE
• Órgão: SEFAZ-SC
• Ano: 2010
• Provas: FEPESE - 2010 - SEFAZ-SC - Auditor Fiscal da Receita Estadual - Parte III - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Relacione cada característica ou subcaracterística de qualidade de software da Coluna 1 com a frase que melhor a representa na Coluna 2.

Coluna 1

1. Analisabilidade
2. Conformidade
3. Estabilidade
4. Funcionalidade
5. Recuperabilidade

Coluna 2

( ) Está de acordo com padrões de portabilidade?
( ) Satisfaz as necessidades?
( ) É capaz de recuperar dados em caso de falha?
( ) Há grande risco quando se faz alterações?
( ) É fácil de encontrar uma falha, quando ocorre?

Assinale a alternativa que indica a sequência correta, de cima para baixo.

• A. 2 - 4 - 3 - 5 - 1
• B. 2 - 4 - 5 - 3 - 1
• C. 3 - 1 - 2 - 4 - 5
• D. 4 - 1 - 2 - 3 - 5
• E. 4 - 2 - 5 - 1 - 3

Gabarito: B

Comentários

• Norma ISO/IEC 9216: É uma norma ISO para qualidade de produto de software, que se enquadra das normas da família 9000. Essa norma, ou conjunto de normas, estabelece um modelo de qualidade com os seguintes componentes: Processo, Produto e Qualidade. Estabelece um modelo de qualidade para o produto, bem como apresenta uma ampla descrição de como aferir, qualitativa e quantitativamente, a “presença” de qualidade.
  Analisibilidade: Subcaracterística da "Manutenibilidade" ("É fácil de modificar?"). Sua pergunta chave é: "É fácil de encontrar uma falha, quando ocorre?"; Conformidade: Subcaracterística da "Portabilidade" ("É fácil de usar em outro ambiente?"). Sua pergunta chave é: "Está de acordo com os padrões de portabilidade?"; Estabilidade: Subcaracterística da "Manutenibilidade" ("É fácil de modificar?"), sua pergunta chave é: "Há grande risco quando se faz alterações?"; Funcionabilidade: É uma característica. Sua pergunta chave é: "Satisfaz as necessidades?"; Recuperabilidade: Subcaracterística da "Confiabilidade" ("É imune a falhas?"), sua pergunta chave é: "É capaz de recuperar dados em caso de falha?". Portanto, a sequência correta é: 2-4-5-3-1 (Alternativa B).
  
  Maiores informações: http://www.bianchi.pro.br/edutec/qualsoft.php
• Prezados,
  
  Quanto a qualidade de software, temos a seguinte relação
  
  Analisabilidade - É fácil de encontrar uma falha, quando ocorre ?
  Conformidade - Está de acordo com padrões de portabilidade ?
  Estabilidade - Há grande risco quando se faz alterações ?
  Funcionalidade - Satisfaz as necessidades ?
  Recuperabilidade - É capaz de recuperar dados em caso de falha ?
  
  Portanto a alternativa correta é a letra B
  
  

Questão 215656

• Banca: CESPE / CEBRASPE
• Órgão: MPU
• Ano: 2010
• Provas: CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Julgue o seguinte item a respeito de qualidade de software.

O nível máximo de qualidade de um software é atingido quando os stakeholders estão satisfeitos com os resultados que ele apresenta; para tanto, é essencial que todos os envolvidos no processo de criação desse software façam parte da revisão de qualidade.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Creio que o erro está na expressão "todos os envolvidos" ,  pois é um exagero que todos os envolvidos façam parte da revisão.

• Pressman, 6ed., define que nas revisões técnicas formais, devem estar de 3 a 5 pessoas no máximo.
• Complementando, as revisões técnicas formais envolvem apenas a equipe técnica, engenheiros de software, gerente de equipe, ... . O cliente está envolvido no processo de criação, porém não fará parte da revisão, como a questão afirma.
• Tudo bem que todo mundo viu erro na assertiva quando ele diz que todos devem estar envolvidos na revisão, mas acho que a questão tem outro problema também, quando ele afirma: "O nível máximo de qualidade de um software é atingido quando os stakeholders estão satisfeitos com os resultados que ele apresenta". A gente pode afirmar isso mesmo? Para mim, um projeto pode atingir a satisfação dos stakeholders sem atingir o nível máximo de qualidade...

• Sommerville p. 463 9ª ed.

  As equipes de revisão devem ter um núcleo de 3 a 4 pessoas. Nem o gerente de projetos, segundo o autor, precisa estar envolvido na revisão. Sommerville apenas cita que um dos membros deve ser um projetista sênior para que as decisões técnicas importantes fiquem sob sua responsabilidade.

• Bom eu marquei errado pela simples afirmação: "O nível máximo de qualidade de um software é atingido quando os stakeholders estão satisfeitos com os resultados que ele apresenta". Gente isso é só uma parte, visto que para se obter uma gestão de qualidade efetiva é necessário também que forneça um valor mensurável não só aos stakeholders mais também para aqueles que o produzem. 

Questão 215671

• Banca: CESPE / CEBRASPE
• Órgão: MPU
• Ano: 2010
• Provas: CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Julgue o seguinte item a respeito de qualidade de software.

O plano de garantia de qualidade de software, os documentos, padrões e guias a serem utilizados, as ferramentas, técnicas e metodologias de apoio e quem deve exercer o controle dessa qualidade estão normatizados pela ISO.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• [ERRADO] As normas ISO não especificam ferramentas a serem utilizadas.

Questão 215674

• Banca: CESPE / CEBRASPE
• Órgão: MPU
• Ano: 2010
• Provas: CESPE - 2010 - MPU - Analista de Informática - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Julgue o seguinte item a respeito de qualidade de software.

A revisão de um projeto de software, tendo em vista a qualidade do processo de codificação, inclui, entre outros aspectos, verificar a ocorrência de erros de ortografia, o uso adequado das convenções da linguagem e se as constantes físicas estão corretas.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• De acordo com Pressman, são objetivos da revisão formal:
   
  * Descobrir erros em funções, lógica ou programação;
  * Verificar se o software satisfaz os requisitos;
  * Verificar os padrões definidos;
  * Software desenvolvido de maneira uniforme;
  * Tornar os projetos mais administráveis.
   
  Portanto, erros de ortografia e os outros citados estão fora dos objetivos da revisão.
• A origem da questão parece ser este material: 
  
  http://www.google.com.br/url?sa=t&source=web&cd=6&ved=0CCoQFjAF&url=http%3A%2F%2Fcelepar7cta.pr.gov.br%2Fportfolio.nsf%2Fb239398b4e7d02ec03256d9c003fdcb8%2F68a2bab0e99b141d03256c2f0073e31e%2F%24FILE%2Fversao5.doc&rct=j&q=A%20revis%C3%A3o%20de%20um%20projeto%20de%20software%2C%20tendo%20em%20vista%20a%20qualidade%20do%20processo%20de%20codifica%C3%A7%C3%A3o%2C%20inclui%2C%20entre%20outros%20aspectos%2C%20verificar%20a%20ocorr%C3%AAncia%20de%20erros%20de%20ortografia%2C%20o%20uso%20adequado%20das%20conven%C3%A7%C3%B5es%20da%20linguagem%20e%20se%20as%20constantes%20f%C3%ADsicas%20est%C3%A3o%20corretas.&ei=SmOSTPHpCcL98AbWxpjuBQ&usg=AFQjCNGUkaRCcNIZmBE3kDCb7QMrmtJpsQ&cad=rja
  
  Segue o que está escrito na referência:
  
  Nesta fase os erros de programação são detectados. A parte de operações
  lógicas deve ser testada. Testes* bottom-up*,* top-down*, *test drivers*, *
  stubs* e outros métodos podem e devem ser utilizados, sendo que se deve
  escolher o mais apropriado ao porte e necessidades dos requisitos de
  acurácia do sistema. Estes métodos serão detalhados a seguir.
  
  Os itens que devem ser avaliados nesta fase, segundo [11], são:
  
  O projeto foi adequadamente traduzido em código?
  Há erros de ortografia ou tipográficos?
  As convenções da linguagem foram adequadamente utilizadas?
  Existe concordância em relação aos padrões de codificação quanto ao estilo da linguagem, comentários e cabeçalho do modular?
  Há comentários incorretos ou ambíguos?
  Os tipos de dados e a declaração de dados são apropriados?
  As constantes físicas estão corretas?
  
  Obs: Encontrei essa referência num e-mail da lista timasters enviado por [e-mail]
  
  

• Constantes Físicas????

Questão 224011

• Banca: UFF
• Órgão: UFF
• Ano: 2009
• Provas: UFF - 2009 - UFF - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Segundo Pressman, na qualidade do software, as inspeções, revisões e testes utilizados ao longo do processo de software, para garantir que cada produto de trabalho satisfaça os requisitos estabelecidos, são conhecidas como:

• A. garantia de qualidade;
• B. custo da qualidade;
• C. controle de qualidade;
• D. reengenharia de processos;
• E. gold plate.

Gabarito: C

Comentários

• Item correto: letra C
  Conforme preconizado no PMBoK 4º versão, essas são algumas das características do controle de qualidade.
• Segundo Pressman, na qualidade do software, as inspeções, revisões e testes utilizados ao longo do processo de software, para garantir que cada produto de trabalho satisfaça os requisitos estabelecidos
  
  De fato, trata da definição do Pressman sobre controle de qualidade. 
  
  Além dessa definição, existe uma outra, que trata sobre Garantia da Qualidade:
  
  "Consiste de um conjunto de funções para auditar e relatar que avalia a efetividade e completeza das atividades de controle de qualidade".
  
  Ou seja, a garantia de qualidade é uma atividade posterior ao controle de qualidade. 

• Controle de Qualidade: Estou produzindo o produto corretamente?

  Garantia de Qualidade: Estou produzindo o produto correto?
  

• c-

  Garantia da Qualidade

  1. Processo definido e apropriado.

  2. Metodologia e padrões são exemplos de garantia da qualidade.

  3. orientada a processo e a prevenção.

  4. Foco em monitoração e melhoria de processo.

   

  controle de qualidade:

  1- descoberta de defeitos específicos.

  2. "Os requisitos são os certos?"

  3. orientado a produto e detecção.

  
  Uma das principais formas de implementação do controle de qualidade é a utilização do PDCA (Plan-Do-Check-Action), que deve ser usado para todas as organizações na definição de controle ou melhoria de qualquer tipo de processo.

   

  Em suma: garantia de qualidade: prevenir. controle de qualidade: detectar. 1° se garante, depois se controla. Tambem note que garantia da qualidade mexe com processo porque ele é a base para aplicar metodlogias orientadas á qualidade como defeito zero, Lean, Demmings' 14 points etc. Ja O controle lida com produto porque ele necessita ser avaliado e melhorado com base em licoes passadas

   

Questão 224014

• Banca: UFF
• Órgão: UFF
• Ano: 2009
• Provas: UFF - 2009 - UFF - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Em relação aos princípios de qualidade, aquele que está diretamente ligado ao tempo de resposta de processamento e aos recursos utilizados no sistema é conhecido como:

• A. praticidade;
• B. suporte;
• C. manutenção;
• D. eficiência;
• E. segurança.

Gabarito: D

Comentários

• De acordo com a norma ISO 9126, as atividades que englobam a eficiência são:
  
  * Comportamento em relação ao tempo
  * Utilização de recursos
  * Conformidade relacionada à eficiência

Questão 224026

• Banca: UFF
• Órgão: UFF
• Ano: 2009
• Provas: UFF - 2009 - UFF - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

No tocante à garantia de qualidade de software, está relacionada com uma de suas funções:

• A. inspeções de requisitos;
• B. testes de comparações;
• C. auditorias;
• D. criação da estrutura analítica do projeto (WBS);
• E. reengenharia de processos.

Gabarito: C

Comentários

• O processo de Garantia da Qualidade utiliza-se de atividades em todas as fazes do desenvolvimento: verificação validação auditoria revisão conjunta

• c-

  Garantia de qualidade - prevenção, processos, inicio das fases do ciclo de vida.

  Contrle de qualidade - detecção, produto, final das fases, garante resultados esperados pelos requisitos

Questão 224029

• Banca: UFF
• Órgão: UFF
• Ano: 2009
• Provas: UFF - 2009 - UFF - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Segundo Pressman, em um sistema baseado em computador, é uma medida simples de confiabilidade:

• A. Violação dos Padrões de Programação (VPS);
• B. Desvio Intencional das Especificações (IDS);
• C. Tempo Médio Entre Falhas (MTBF);
• D. Erro na Lógica do Projeto (EDL);
• E. Teste Incompleto ou Errôneo (IET).

Gabarito: C

Comentários

• Quem faz o uso do conceito de MTBF é o Gerenciamento da Disponibilidade do do Livro de Desenho de servicos do ITIL.
  
  O Tempo Médio entre as Falhas demonstra a confiabilidade do componente. Se um componente tiver um MTBF muito pequeno, significa que ele tem tendência a gerar incidentes com freqüência.

• Em Pressman, 7ed, Pag 396, diz:
  
  "Se considerarmos um sistema computacional, uma medida de confiabilidade simples é o tempo médio entre falhas (MTBF, mean-time-to-failure):
  
  MTBF = MTTF + MTTR "
  
  Os outros sao: Mean time to failure e mean time to repair.

Questão 229897

• Banca: UFF
• Órgão: UFF
• Ano: 2009
• Provas: UFF - 2009 - UFF - Técnico de Laboratório - Informática
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Em relação aos princípios de qualidade em software, no tocante à testabilidade de software, a sentença "quanto menos modificações, menos interrupções no teste" está relacionada com uma característica. Essa característica é identificada como:

• A. operacionalidade;
• B. compreensibilidade;
• C. estabilidade;
• D. controlabilidade;
• E. observalibilidade.

Gabarito: C

Comentários

• * Operacionalidade: é como o produto facilita a sua operação por parte do usuário, incluindo a maneira como ele tolera erros de operação;
  
  * Compreensibilidade: Evidencia o esforço do usuário para reconhecer o conceito lógico e aplicabilidade do software;
  
  * Estabilidade: Avalia a capacidade do software de evitar efeitos colaterais decorrentes de modificações introduzidas;
  
  * Controlabilidade: Controlar o software se trata de poder automatizar e otimizar suas funcionalidades. Durante seu processo, entradas e saídas estruturadas e testes específicos, são considerados essenciais para a sua evolução.
  
  * Observabilidade: Facilidade na localização de problemas

Questão 233026

• Banca: FUNIVERSA
• Órgão: CEB-DISTRIBUIÇÃO S/A
• Ano: 2010
• Provas: FUNIVERSA - 2010 - CEB - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Qualidade de software é uma área da engenharia de software que tem como objetivo garantir a qualidade pela definição e normatização dos processos de desenvolvimento de sistemas. O grupo de normas técnicas "ISO 9000/2000" define qualidade como o grau em que um conjunto de características inerentes a um produto, processo ou sistema cumpre os requisitos inicialmente estipulados para esses. Assinale a alternativa que melhor define "qualidade", dentro da área de engenharia de software.

• A. Conformidade de um sistema com os requisitos levantados no início do processo de desenvolvimento.
• B. Tempo de vida útil de um sistema e sua efetiva utilidade e aplicação.
• C. É medida pelo máximo de tempo de uso entre falhas ocorridas (MTBF) no ciclo de vida do software.
• D. Desempenho medido pelo tempo de resposta no processamento e apresentação das informações.
• E. Equilíbrio entre o prazo de entrega do sistema e o atendimento mínimo dos requisitos levantados.

Gabarito: A

Comentários

• A qualidade deverá ser avaliada por:
  * Expectativas do cliente que foram atendidas;
  * Quantidade baixa de erros encontrados.
• Definições de Qualidade
  
  (JURAN, 1992:9) "Qualidade é ausência de deficiências" ou seja, quanto menos defeitos, melhor a qualidade.
  

  (FEIGENBAUM, 1994:8) "Qualidade é a correção dos problemas e de suas causas ao longo de toda a série de fatores relacionados com marketing, projetos, engenharia, produção e manutenção, que exercem influência sobre a satisfação do usuário."

  (CROSBY, 1986:31) "Qualidade é a conformidade do produto às suas especificações." As necessidades devem ser especificadas, e a qualidade é possível quando essas especificações são obedecidas sem ocorrência de defeito.

  (DEMING, 1993:56) "Qualidade é tudo aquilo que melhora o produto do ponto de vista do cliente".

  (ISHIKAWA, 1993;43) "Qualidade é desenvolver, projetar, produzir e comercializar um produto de qualidade que é mais econômico, mais útil e sempre satisfatório para o consumidor."
• qual é a alternativa correta?
  marquei (a)                        

Questão 234331

• Banca: NC-UFPR
• Órgão: UFPR
• Ano: 2010
• Provas: UFPR - 2010 - UFPR - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Na avaliação da qualidade de software, corretitude é:

• A. a quantidade de recursos de computação e de código exigida para que um programa execute a sua função.
• B. o esforço exigido para modificar um programa operacional.
• C. a medida com que um programa satisfaz sua especificação e cumpre os objetivos visados pelo cliente.
• D. o esforço exigido para localizar e reparar erros num programa.
• E. o esforço para aprender um programa, operá-lo, preparar a entrada e interpretar a saída dos dados.

Gabarito: C

Comentários

•  Baseado no Livro "Engenharia de Software", de Roger Pressman, 6ª Edição (página 350)
  

  A corretitude, ou correção (como apresentado no livro) é um dos fatores de Qualidade de McCall e corresponde a quanto um programa satisfaz sua especificação e preenche os objetivos da missão do cliente.

  Logo, alternativa correta, letra c.

  Espero ter colaborado.

• Corretitude = aderência
• A) Eficiência
  B) Flexibilidade
  C) Correção
  D) Facilidade de Manutenção
  E) Usabilidade
  
  

Questão 276739

• Banca: ESAF
• Órgão: CVM
• Ano: 2010
• Provas: ESAF - 2010 - CVM - Analista de Sistemas - prova 2
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

São informações que compõem o gerenciamento de defeitos

• A. Causa do defeito. Risco calculado. Interfaces. Informações do software. Provas e evidências da existência do controle.
• B. Identificação do defeito. Decomposição. Severidade. Interfaces. Provedores do software. Provas e evidências da existência do defeito.
• C. Disseminação. Severidade. Premissas. Risco de complexidade. Status. Pressupostos da existência do defeito.
• D. Implicações do defeito. Descrição. Risco associado. Springs. Provas e evidências da eliminação do defeito.
• E. Identificação do defeito. Prioridade. Status. Informações do software. Prova e evidências da identificação do defeito.

Gabarito: E

Comentários

• Elementos chave de um processo de gestão de defeitos.
  
  
• As principais informações de um Gerenciamento de Defeitos são:
  
  Identificaçãodo defeito,
  Descrição,
  Severidade,
  Prioridade,
  Risco associado,
  Status,
  Provas e evidências da existência do defeito.

• Acertei, mas qual a fonte disso? É ITIL, ISO?

Questão 280879

• Banca: INSTITUTO CIDADES
• Órgão: AGECOM
• Ano: 2010
• Provas: INSTITUTO CIDADES - 2010 - AGECOM - Analista de Gestão Administrativa - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Desenvolvimento de Software; Qualidade de Software

A Engenharia de Software trata de aspectos relacionados ao estabelecimento de processos, métodos, técnicas, ferramentas e ambientes de suporte ao desenvolvimento de software. Com relação à Engenharia de Software, assinale a alternativa correta.

• A. Atividades de Desenvolvimento são as atividades diretamente relacionadas ao processo de desenvolvimento do software, ou seja, que contribuem diretamente para o desenvolvimento do produto de software a ser entregue ao cliente. São exemplos de atividades de desenvolvimento: especificação e análise de requisitos, projeto e implementação.
• B. Atividades de Gerência são aquelas relacionadas com a garantia da qualidade do produto em desenvolvimento e do processo de software utilizado, tais como revisões e inspeções de produtos (intermediários ou finais) do desenvolvimento.
• C. Atividades de Garantia da Qualidade são aquelas relacionadas ao planejamento e acompanhamento gerencial do projeto, tais como realização de estimativas, elaboração de cronogramas e análise dos riscos do projeto.
• D. No Processo de Software são abordadas as principais atividades da gerência de projetos, a saber: definição do escopo do projeto, estimativas, análise de riscos, elaboração de cronograma, elaboração do plano de projeto e acompanhamento de projetos.
• E. O Planejamento e Gerência de Projetos enfoca os processos de software, os elementos que compõem um processo, a definição de processos para projetos, modelos de processo, normas e modelos de qualidade de processo de software e a automatização do processo de software.

Gabarito: A

Comentários

• b) ERRADO. Atividades de Garantia da Qualidade: são aquelas relacionadas com a garantia da qualidade do produto em desenvolvimento e do processo de software utilizado, tais como revisões e inspeções de produtos (intermediários ou finais) do desenvolvimento.

  c) ERRADO. Atividades de Gerência: são aquelas relacionadas ao planejamento e acompanhamento gerencial do projeto, tais como realização de estimativas, elaboração de cronogramas, análise dos riscos do projeto etc.

  d) ERRADO. Planejamento e Gerência de Projetos – são abordadas as principais atividades da gerência de projetos, a saber: definição do escopo do projeto, estimativas, análise de riscos, elaboração de cronograma, elaboração do plano de projeto e acompanhamento de projetos

  e) ERRADO. Processo de Software – enfoca os processos de software, os elementos que compõem um processo, a definição de processos para projetos, modelos de processo, normas e modelos de qualidade de processo de software e a automatização do processo de software.

• a-

  Atividades diretamente ligadas ao projeto:

  Planejamento (Plano de execução do projeto, levantamento de requisitos, casos de uso), construção (analise, projeto, implementação, testes), implantação (avaiação, manutenção).

Questão 280900

• Banca: INSTITUTO CIDADES
• Órgão: AGECOM
• Ano: 2010
• Provas: INSTITUTO CIDADES - 2010 - AGECOM - Analista de Gestão Administrativa - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

A documentação produzida em um projeto de software é de suma importância para se gerenciar a qualidade, tanto do produto quanto do processo usado para seu desenvolvimento. Com relação à documentação de um projeto de software, marque a alternativa correta:

• A. Uma documentação de qualidade propicia uma maior organização no final do desenvolvimento de um sistema, facilitando modificações e futuras manutenções no mesmo.
• B. Uma documentação reduz o impacto da perda de membros da equipe, porém não reduz o tempo de desenvolvimento de fases posteriores, mas sim reduz o tempo de manutenção e contribui para redução de erros, aumentando a qualidade do processo e do produto gerado.
• C. A criação da documentação não é tão importante quanto a criação do software.
• D. No desenvolvimento de software, são produzidos diversos documentos, dentre eles, documentos descrevendo processos (plano de projeto, plano de qualidade), registrando requisitos e modelos do sistema (documentos de especificação de requisitos, análise e projeto) e apoiando o uso do sistema gerado (manual do usuário, ajuda on-line, tutoriais).
• E. É importante notar que o planejamento da documentação não tem uma estreita relação com o processo de software definido para o projeto.

Gabarito: D

Comentários

• a) ERRADO. Uma documentação de qualidade propicia uma maior organização durante o desenvolvimento de um sistema, facilitando modificações e futuras manutenções no mesmo.

  b) ERRADO. Uma documentação de qualidade propicia uma maior organização durante o desenvolvimento de um sistema, facilitando modificações e futuras manutenções no mesmo. Além disso, reduz o impacto da perda de membros da equipe, reduz o tempo de desenvolvimento de seus posteriores, reduz o tempo de manutenção e contribui para a redução de erros, aumentando assim, a qualidade do processo e do produto gerado.

  c) ERRADO. A criação da documentação é tão importante quanto a criação do software em si

  e) ERRADO. É importante notar que o planejamento da documentação tem uma estreita relação com o processo de software definido para o projeto.

  Fonte:

Questão 308737

• Banca: CESPE / CEBRASPE
• Órgão: TJ-ES
• Ano: 2011
• Provas: CESPE - 2011 - TJ-ES - Técnico de Informática
• Disciplina: Engenharia de Software
• Assuntos: Outros modelos de Processo de Software; Processos de Software; Qualidade de Software

Com referência a engenharia de software e uso de UML para a
modelagem de sistemas, julgue os itens subsecutivos.

Entre as etapas do ciclo de vida de software, as menos importantes incluem a garantia da qualidade, o projeto e o estudo de viabilidade. As demais atividades do ciclo, como a implementação e os testes, requerem maior dedicação da equipe e são essenciais.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Como construir e entregar um software se seu processo não assegurar a qualidade?
  
  A gerência da qualidade de software é um processo dos mais importantes durante o ciclo de vida de software. Isso pelo fato de garantir que o produto funciona de forma adequada e de acordo com o que foi previamente especificado e garante que o software atende às necessidades do cliente.
  
  Acho que é isso.
• Dificil determinar o que é mais ou menos importante dentro do ciclo de vida do software.
• Em geral, as disciplinas iniciais do processo de software são mais importantes se compararmos a ocorrência de erros. Erros na especificação dos requisitos ou no estudo de viabilidade têm impacto em todas as disciplinas subsequentes, com grandes chances de insucesso. O contrário não acontece, caso o erro seja na construção ou testes.
• Oh as ideia: Projetar pra quê, faz nas coxa mesmo... hehehe

Questão 319642

• Banca: CESPE / CEBRASPE
• Órgão: INMETRO
• Ano: 2010
• Provas: CESPE - 2010 - INMETRO - Pesquisador - Análise de Requisitos e Qualidade de Software
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

A literatura de engenharia de software propõe um extenso conjunto de métricas de qualidade, passíveis de aplicação na melhoria da gestão de software, inclusive relacionada a teste de software, como densidade de defeitos, número diário de faltas, índice de defeitos, distribuição de erros, cobertura de testes, suficiência de testes, precisão de testes, tempo médio entre falhas etc. Considere o desafio de implementar, em uma organização produtora de software, práticas efetivas de medição e análise baseadas em um subconjunto dessas métricas, com a finalidade de satisfazer as necessidades de informação da gerência de projeto. Considere, ainda, que a organização, atualmente, não faz uso de métricas. A respeito das práticas de medição e análise mencionadas, e das abordagens para implantação de métricas, assinale a opção correta.

• A. O estabelecimento de uma capacidade básica de medição e análise que atenda às necessidades de informação da gerência de projetos, inclusive relativa à qualidade de produto, é critério que deve ser obrigatoriamente satisfeito a partir do nível de maturidade 3 do modelo CMMI.
• B. O método goal question metric (GQM) foi especialmente criado para que a escolha de métricas de teste de software seja efetuada da forma mais adequada às metas de uma organização produtora de software.
• C. É um erro comum, durante o estabelecimento de uma capacidade de medição e análise relacionada com teste de software, o compartilhamento, com a equipe de desenvolvimento, de sumários e de dados de tendências.
• D. Na terminologia de testes, uma falta ou defeito é a causa de um mau funcionamento de um software; uma falha é o resultado incorreto de uma falta ou defeito; um erro é a diferença entre um resultado computado e um resultado esperado. As falhas são descobertas por meio de testes, mas é a correção da falta ou do defeito que eliminará a falha.
• E. Teste é uma abordagem de controle de qualidade de um software, e o teste pode ser desenvolvido por meio de técnicas de análise estática de código, embora sejam mais comuns as técnicas dinâmicas, incluindo simulação.

Gabarito: D

Questão 319666

• Banca: CESPE / CEBRASPE
• Órgão: INMETRO
• Ano: 2010
• Provas: CESPE - 2010 - INMETRO - Pesquisador - Arquitetura de Soluções de Software
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Assinale a opção correta, acerca de métricas de qualidade de software.

• A. As métricas do processo arquitetural tratam aspectos da arquitetura tanto do software quanto do sistema, de seu projeto em nível de componentes e projeto de interface com o usuário.
• B. As métricas de projeto de interface indicam a qualidade do módulo por meio de medidas indiretas de coesão, acoplamento e complexidade.
• C. As métricas para testes e manutenção focalizam o processo, e não as características técnicas.
• D. O valor de uma métrica é indicação qualitativa de propriedade de algum item do software, inexistindo forma eficiente de se medirem quantitativamente as propriedades de um item de software.
• E. É fundamental que, em uma organização ou um projeto de desenvolvimento de software, se lance mão da maior quantidade de métricas possíveis, até porque, nos modernos ambientes de desenvolvimento de software, se reduz enormemente a complexidade para implementá-las e mantê-las.

Gabarito: C

Comentários

• c-

  as metricas devem:

   

  1- ser facilmente calculadas, entendidas e testadas;
  2- possibilitar estudos estatísticos;
  3- ser expressas em alguma unidade de medida (aí o conceito q devem transformar a medida do software em numeros)
  4- ser definidas tão logo se inicie o processo de desenvolvimento;
  5- ser facilmente aplicadas em qualquer projeto, independente do observador;
  6- ser válidas, confiáveis, práticas e de baixo custo.

• Quase dez anos depois, estou lendo essa explicação e sou só aplausos! Muito bom!

Questão 328630

• Banca: FUNIVERSA
• Órgão: SEPLAG-DF
• Ano: 2010
• Provas: FUNIVERSA - 2010 - SEPLAG-DF - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Com relação ao processo, aos modelos e à medição da qualidade de software, bem como aos testes de software, assinale a alternativa correta.

• A. Os testes sempre revelam erros conhecidos, já que utilizam modelos determinados para sua execução, como casos e roteiros de testes.
• B. Os recursos compatíveis com o nível de desempenho do software são uma parte do atributo de usabilidade para medir a qualidade desse software.
• C. Os testes de software garantem que o sistema não irá apresentar erros durante a execução.
• D. A medida da frequência em que um software apresenta falhas está diretamente ligada à característica de acurácia para avaliação da qualidade do software.
• E. O atributo de qualidade recuperabilidade toma por foco a capacidade de um software recuperar-se após uma falha.

Gabarito: E

Comentários

• a) ERRADO. Os testes nem sempre revelam erros conhecidos, já que utilizam modelos determinados para sua execução, como casos e roteiros de testes.

  b) ERRADO. Os recursos compatíveis com o nível de desempenho do software são uma parte do atributo de eficiência para medir a qualidade desse software.

  c) ERRADO. Os testes de software não garantem que o sistema não irá apresentar erros durante a execução.

  d) ERRADO. A maturidade é a medida da frequência com que um software apresenta falhas. Um software mais maduro é aquele que apresenta menos falhas ao longo de um período fixo de tempo.

Questão 330271

• Banca: FGV
• Órgão: DETRAN-RN
• Ano: 2010
• Provas: FGV - 2010 - DETRAN-RN - Programador de computador
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Assinale a alternativa que NÃO contém somente atributos para características externas e internas do modelo de qualidade de software, definido na ISO/IEC 9126-1:

• A. Funcionalidade, confiabilidade, usabilidade.
• B. Funcionalidade, confiabilidade, eficiência.
• C. Funcionalidade, confiabilidade, alta gerência.
• D. Funcionalidade, usabilidade, portabilidade.
• E. Eficiência, manutenibilidade, portabilidade.

Gabarito: C

Comentários

• Segundo ISO 9126 os atributos que fundamentais para qualidade de software são:
  Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Facilidade de Manutenção e Portabilidade
  
  Detalhamento dos atributos Pressman 7º Edição pg363
  

• Alta gerência lol wut

• a) qualidade interna e externa, que possui 6 características [CEM PUF] (e subcaracterísticas):
  + Confiabilidade (Maturidade, Tolerância a falhas, Recuperabilidade, Conformidade relacionada à funcionalidade)
  + Eficiência (Comportamento em relação ao tempo, Utilização dos recursos, Conformidade em relação à Eficiência)
  + Manutenibilidade ( Analisibilidade, Modificabilidade, Estabilidade, Testabilidade, Conf. relacionada à Manutenibilidade)
  + Portabilidade (Adaptabilidade, Capacidade para ser instalado, Coexistência, Capacidade para substituir, conformidade..)
  + Usabilidade (Intelegibilidade, Apreensibilidade, Operacionalidade, Atratividade, Conformidade rel. Usab.)
  + Funcionalidade (Adequação, Acurácia, Interoperabilidade, Segurança de Acesso, Conformidade rel. Func.)
  
  e b) qualidade em uso, que possui 4 características:
  + Eficácia
  + Produtividade
  + Segurança 
  + Satisfação

• Qualidade interna e externa, que possui 6 características [CEM PUF] (e subcaracterísticas):

   

  + Confiabilidade (Maturidade, Tolerância a falhas, Recuperabilidade, Conformidade relacionada à funcionalidade)
  + Eficiência (Comportamento em relação ao tempo, Utilização dos recursos, Conformidade em relação à Eficiência)
  + Manutenibilidade ( Analisibilidade, Modificabilidade, Estabilidade, Testabilidade, Conf. relacionada à Manutenibilidade)
  + Portabilidade (Adaptabilidade, Capacidade para ser instalado, Coexistência, Capacidade para substituir, conformidade..)
  + Usabilidade (Intelegibilidade, Apreensibilidade, Operacionalidade, Atratividade, Conformidade rel. Usab.)
  + Funcionalidade (Adequação, Acurácia, Interoperabilidade, 

  
  Qualidade em uso, que possui 4 características:

  + Eficácia
  + Produtividade
  + Segurança 
  + Satisfação

• questao estranha da porra

• c-

  ISO 9126 modelo de qualidade para software. 6 categorias

  1- Funcionalidade: atender às necessidades
  2- Confiabilidade: Segurança
  3- Usabilidade: Facilidade
  4- Eficiência: Tempo para a execução ]

  5- Manutenibilidade: manutenção
  6- Portabilidade: adaptação

• CAIXA+MPU

  CEFMPU

  Confiabilidade

  Eficiência

  Funcionalidade

  Manutenibilidade

  Portabilidade

  Usabilidade

Questão 332434

• Banca: FGV
• Órgão: FIOCRUZ
• Ano: 2010
• Provas: FGV - 2010 - FIOCRUZ - Analista de Gestão em Saúde - Gestão de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

As alternativas a seguir apresentam condições para a manutenção da qualidade de serviços e produtos de Tecnologia da Informação, à exceção de uma. Assinale-a.

• A. Promover serviços e o acompanhamento periódico da qualidade de produtos.
• B. Manter um padrão mínimo de segurança e confiabilidade.
• C. Controlar através da coleta de informações sobre o andamento das ações.
• D. Verificar o cumprimento dos planos elaborados.
• E. Assegurar a punição dos culpados.

Gabarito: E

Questão 337774

• Banca: CS-UFG
• Órgão: UFG
• Ano: 2010
• Provas: UFG - 2010 - UFG - Analista de TI - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

O principal objetivo do processo de verificação e validação (V&V) de software é estabelecer confiança de que o sistema de software atende tanto a sua especificação quanto às expectativas de seus usuários finais. Além das atividades de inspeção de software, outras atividades de suma importância no contexto do processo de V&V são aquelas relacionadas

• A. aos testes de software.
• B. à manutenção de software.
• C. à estimativa de custo de software.
• D. ao gerenciamento de configuração de software.

Gabarito: A

Comentários

• O processo de V&V:
  
   É um processo que engloba todo o ciclo de vida - V & V  deve ser aplicado em cada estágio no processo de desenvolvimento.
  Tem dois objetivos principais:  a descoberta de defeitos no sistema Assegurar se o sistema é ou não utilizável  em uma situação operacional Fonte: http://www.dcce.ibilce.unesp.br/~ines/cursos/eng_soft/aula12.PDF

• Gab. a) aos testes de software.

Questão 352525

• Banca: FUNCAB
• Órgão: SES-GO
• Ano: 2010
• Provas: FUNCAB - 2010 - SES-GO - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

No ciclo de vida de um produto, existe uma atividade na fase de desenvolvimento que tem o propósito de demonstrar que o sistema está de acordo com sua especificação e que ele atende às expectativas de clientes e usuários. Essa atividade é conhecida como:

• A. distribuição e entrega.
• B. design da arquitetura do software.
• C. verificação e validação.
• D. implementação.
• E. design conceitual.

Gabarito: C

Comentários

• Verificação e validação destinam-se a mostrar que o sistema está de acordo com a especificação e que ele atende às expectativas de clientes e usuários. A validação visa assegurar se o programa está fazendo aquilo que foi definido na sua especificação (fazendo a coisa certa). A verificação visa verificar se o programa está correto, isto é, não possui erros de execução (fazendo certo a coisa). Existem diferentes formas de verificação e validação. Inspeção analítica e revisão de modelos, documentos e código fonte são formas que podem ser usadas antes mesmo que o programa seja completamente codificado. Os testes de correção, desempenho, confiabilidade, robustez, usabilidade, dentre outros, visam avaliar diversos fatores de qualidade a partir da execução do software. Diferentes técnicas de testes podem ser aplicadas para cada um destes fatores.

Questão 352537

• Banca: FUNCAB
• Órgão: SES-GO
• Ano: 2010
• Provas: FUNCAB - 2010 - SES-GO - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Em relação ao gerenciamento da qualidade, o estabelecimento de uma estrutura de procedimentos e de padrões organizacionais, que conduzam um software de alta qualidade, é conhecido como:

• A. planejamento da qualidade.
• B. garantia da qualidade.
• C. controle da qualidade.
• D. gerenciamento da configuração.
• E. revisões de qualidade.

Gabarito: B

Comentários

• Para Sommerville (2008) o gerenciamento de qualidade de software pode ser dividido em ter atividades principais:

  Garantia de qualidade que consiste em estabelecer procedimentos e padrões que conduzam ao desenvolvimento de software de alta qualidade.

  Planejamento de qualidade selecionar os procedimentos e padrões adequados e adaptá-los a um projeto de software específico o que vai de encontro com recomendações do PMBOK (2008).

  Controle de qualidade definir e aprovar processos que garantam que os procedimentos e padrões de qualidade sejam seguidos.

Questão 360175

• Banca: CESPE / CEBRASPE
• Órgão: SAD-PE
• Ano: 2010
• Provas: CESPE - 2010 - SAD-PE - Analista de Controle Interno – Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Qualidade de software é o grau para o qual um software possui uma combinação desejável de atributos, que, adicionalmente, deve ser claramente definida, caso contrário, uma avaliação da qualidade será realizada de modo intuitivo. Para que tais atributos de qualidade sejam medidos, faz-se necessário identificar um conjunto apropriado de métricas. Acerca dos conceitos gerais de medição de qualidade de software, assinale a opção correta.

• A. No modelo IEEE de qualidade de software, um fator de qualidade é uma entidade mais genérica que um atributo de qualidade.
  
• B. Os modelos de qualidade de software são organizados segundo a perspectiva de que a qualidade do processo de desenvolvimento influencia, diretamente, a qualidade interna, que, por sua vez, influencia a qualidade externa do produto de software, e esta última exerce influência direta sobre a qualidade do produto em uso.
  
• C. De forma geral, os modelos de qualidade da ISO são focados na qualidade de produtos de software, e os modelos CMMI, na qualidade do processo de software.
  
• D. O modelo de referência para medição de qualidade de produto de software da ISO propõe quatro diferentes perspectivas, mediante as quais podem ser desenvolvidas métricas de medição de atributos de qualidade interna, externa, de operação e de uso.
  
• E. Os atributos de qualidade de software, nos modelos de qualidade ISO, são organizados conforme seis características, sendo três delas internas (eficiência, manutenabilidade e portabilidade) e as outras três, externas (funcionalidade, confiabilidade e usabilidade).
  

Gabarito: B

Comentários

• http://en.wikipedia.org/wiki/ISO/IEC_9126
  
  Segundo o wikipédia a letra A está correta, já que ele trata Funcionalidade, p. ex., como:
  funcionalidade - um conjunto de atributos que incidem sobre a existência de um conjunto de funções e as suas propriedades especificadas. as funções são as que satisfazem necessidades explícitas ou implícitas.
  
  Portanto, os fatores seriam mais genéricos e atributos mais específicos sim!
• a) O principal fator de qualidade é o produto atender aos requisitos, já os atributos de qualidade (seis ao todo) são as características que descrevem o que seria um produto de qualidade, portanto, o segundo é mais genérico que o primeiro. Neste caso o "atender aos requisitos" estaria no contexto  "adequação" que é uma espécie do atribudo de qualidade "Funcionalidade".
  b) Correto. A qualidade deve permear todo o ciclo de vida de projeto e continuar pelo ciclo de vida de produto.
  c) De forma geral os modelos ISO são focados na qualidade do PROCESSO. ISO 9001, ISO/IEC15504, ISO/IEC 12207. CMMI correto.
  d) O modelo é o ISO 9126 e ele propões 3 perspectivas: Processo, Produto e Qualidade de uso.
  e) Interna (eficiência, portabilidade, manutenebilidade, confiabilidade) e Externa (funcionalidade e usabilidade)
• ISO 9126: Documento composto basicamente de definições para as características de qualidade:
  Funcionalidade 
  Confiabilidade 
  Usabilidade 
  Eficiência 
  Manutenibilidade 
  Portabilidade
   
  MÉTRICAS EXTERNAS
  • Apóia-se na definição dos atributos externos de qualidade correlacionados com uma determinada característica;
  • Define indicadores e métricas externas para avaliar um produto de software;
  • Referem-se a medições indiretas de um produto de software a partir do comportamento do Sistema Computacional ou do seu efeito no ambiente, quando da execução de seus programas.
  • Usadas para:
  • • Avaliar o comportamento do software quando usado em situações específicas;
    • Para predizer a qualidade real no uso;
    • Para avaliar e indicar se o produto satisfaz as verdadeiras necessidades durante a operação real pelo usuário.

  MÉTRICAS INTERNAS
  • Define indicadores e métricas internas para avaliar um produto de software;
  • Referem-se a medições de um produto de software a partir de suas próprias características internas, sem a necessidade de execução dos programas, como por exemplo, linhas de código, número
    de erros encontrados em revisões, etc.
  • As métricas internas fornecem aos usuários a possibilidade de medir a qualidade dos artefatos intermediários e de prever a qualidade do produto final;
  • Isto permite que o usuário identifique problemas de qualidade e inicie a ação corretiva assim que possível no ciclo de vida do desenvolvimento.

  MÉTRICAS DE QUALIDADE EM USO
  • Valida a qualidade do produto em cenários e tarefas comuns ao usuário;
  • São categorizados pelas características: efetividade, produtividade, segurança e satisfação
   

• Quanto à alternativa E, me parece que a ISO 9126 não faz essa divisão das característiacas em internas e externas, tanto que coloca um modelo único para esses dois tipos (externo e interno) e outro modelo separado para qualidade do produto em uso.

  Algumas características podem ser interpretadas tanto como sendo internas quanto externas, como Confiabilidade, por exemplo.

Questão 362755

• Banca: CESPE / CEBRASPE
• Órgão: TRE-BA
• Ano: 2010
• Provas: CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Em uma visão restritiva, muitas pessoas costumam associar o termo
software aos programas de computador. Software não é apenas o
programa, mas também todos os dados de documentação e
configuração associados, necessários para que o programa opere
corretamente. A respeito de engenharia de software, julgue os itens
de 61 a 65.

Os defeitos do software afetam a confiabilidade dos sistemas, sendo que a maioria dos sistemas de grande porte é composta de diversos subsistemas com diferentes requisitos de confiabilidade. Os defeitos transitórios podem ser corrigidos por ações como reiniciação ou calibração do equipamento.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Defeitos transitórios ou falhas transitórias, são aquelas falhas que eventualmente desaparecem sem qualquer intervenção aparente.

• "Reiniciação" não corrige defeito... ou o Windows 98 seria perfeito!

• Ok, Reiniciação não corrige defeito, mas... corrigem falhas.
  

• Foi difícil de entender rsrs, Mas era a única que encaixava. "agentes exercer legitimamente sua atividade", só tinha competência.

Questão 362758

• Banca: CESPE / CEBRASPE
• Órgão: TRE-BA
• Ano: 2010
• Provas: CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Em uma visão restritiva, muitas pessoas costumam associar o termo
software aos programas de computador. Software não é apenas o
programa, mas também todos os dados de documentação e
configuração associados, necessários para que o programa opere
corretamente. A respeito de engenharia de software, julgue os itens
de 61 a 65.

Os benefícios do reúso estão relacionados ao aproveitamento de código anteriormente desenvolvido e incluem ganhos de produtividade e de qualidade, uma vez que um componente reusado deve ser mais confiável. O modelo COCOMO II considera dois tipos de código reusado: o caixa-preta e o caixa- branca. Considera-se nulo o esforço de desenvolvimento de códigos caixa-branca, pois ele não precisa de adaptação para ser integrado com códigos novos ou outros componentes reusados.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Nem é preciso entender "COCOMO II" para responder a questão, pois o conceito de "caixa-branca" está errado.
• Reuso Caixa Branca
  No reuso caixa branca existe a necessidade que a implementação do componente de software a ser reusado seja exposta de alguma forma. Em linguagens orientadas a objetos como Java e C++, é muito comum o uso de herança para se atingir o reuso, modificando e adaptando o componente. Neste tipo de reuso é preciso conhecer a implementação de algum componente de software que fará parte do reuso.
  
  Reuso Caixa Preta
  O reuso caixa-preta visa eliminar a necessidade do desenvolvedor de um conhecimento da implementação de algum componente de software que fará parte do processo de reuso. Em vez disso, o reuso caixa-preta se dá através da descrição de interfaces ou contratos bem definidos que devem ser respeitados pela implementação a ser elaborada. O esforço sempre é usado na nova implementação e nunca ocorre um desperdício tentando entender implementações de terceiros.
  
  Fonte: TCC de Alexandre Eiki Onishi, orientado por Siang Wun Song da USP.

• e-

  a partir do n° linhas do codigo (entregue ao usuario), o cocomo determina prazos, recursos humanos e tecnicos e custo final. Porem, o tamanho extao do software é uma imitação porque cocomo nao considera interface e outros componentes.

Questão 362791

• Banca: CESPE / CEBRASPE
• Órgão: TRE-BA
• Ano: 2010
• Provas: CESPE - 2010 - TRE-BA - Técnico Judiciário - Programação de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Uma estratégia de teste de software integra métodos de projeto de
casos de teste em uma série planejada de passos, que resultam na
construção bem-sucedida de um software. A esse respeito, julgue
os próximos itens.

Falha é o resultado de um ou mais defeitos em algum aspecto do sistema. No teste de regressão, caso um novo componente ou as suas alterações, quando acrescentados aos componentes restantes do sistema, resultem em novos defeitos em componentes inalterados, então considera-se que o sistema regrediu.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Teste de Regressão. É um dos mais importantes tipos de teste, entretanto é freqüentemente esquecido nos projetos de teste. Consiste na repetição de testes já executados. Sempre que um defeito é resolvido, uma nova funcionalidade adicionada, de alguma forma o código é alterado, podendo influenciar negativamente em outras funcionalidades. O teste de regressão deve ser realizado para certificar que o que estava funcionando permanece com o comportamento adequado após mudanças efetuadas no software.
  
  Fonte: www.ti24x7.com
• Dificl é "saber" (leia-se chutar) a parte que afirma "...considera-se que o sistema regrediu..".
   
  Um erro encontrado em um teste de regressão não que dizer que  o sistema regrediu. Nunca vi uma afirmação dessas na literatura, se alguém souber de algum livro que afirme isso, poste ai...

• "então considera-se que o sistema regrediu"

  Fonte: vozes da cabeça do examinador, brinks, a fonte é a wikipédia, pra variar:

  https://pt.wikipedia.org/wiki/Teste_de_regress%C3%A3o

Questão 392140

• Banca: Aeronáutica
• Órgão: CIAAR
• Ano: 2009
• Provas: Aeronáutica - 2009 - CIAAR - Primeiro Tenente - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Preencha a lacuna abaixo e, em seguida, assinale a alternativa correta.

Em muitos casos, _______________ são feita(o)(s) usando-se a experiência passada como único guia.

• A. testes
• B. estimativas
• C. projetos
• D. análises

Gabarito: B

Comentários

• Geralmente, estimativas são feitas usando-se a experiência passado como único guia. Se um novo projeto for muito semelhante, em termos de tamanho e função, a um projeto passado, provavelmente esse novo projeto exigirá aproximadamente a mesma quantidade de esforço, tomará o mesmo tempo em calendário e custará o mesmo valor em dólares. 
  Se o projeto romper novos horizontes, novas técnicas de estimativas foram disponibilizadas para o desenvolvimento de software com os seguintes atributos: 
  * O escopo do projeto deve ser estabelecido antecipadamente. 
  * Métricas de software são utilizadas e o histórico de aferições passadas é usado como uma base a partir da qual estimativas são feitas. 
  * O projeto é dividido em pequenas partes que são estimadas individualmente.

Questão 392158

• Banca: Aeronáutica
• Órgão: CIAAR
• Ano: 2009
• Provas: Aeronáutica - 2009 - CIAAR - Primeiro Tenente - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

O Modelo COCOMO é associado a

• A. Gerenciamento de Pessoal.
• B. Análise de Riscos.
• C. Projeto de Testes.
• D. Estimativa de Esforço / Custos.

Gabarito: D

Comentários

• o COCOMO é um modelo desenvolvido para estimar esforço, prazo, custo e tamanho da equipe para um projeto de software.

  
  

Questão 442714

• Banca: CESPE / CEBRASPE
• Órgão: TCE-TO
• Ano: 2009
• Provas: CESPE - 2009 - TCE-TO - Analista de Controle Externo - Informática - Processamento de Dados
• Disciplina: Engenharia de Software
• Assuntos: Métricas de Software; Qualidade de Software

A respeito de qualidade de software e suas métricas, assinale a opção correta.

• A. O número de funções ou métodos que constam em um programa pode ser avaliado pela métrica de software fan-in/fan-out.
• B. A métrica de complexidade ciclomática é uma medida que pode estar relacionada ao nível de compreensão do programa.
• C. A medida do número de caracteres em um programa é uma métrica do tipo fog index.
• D. A métrica de comprimento total faz referência ao número de linhas no código que se considera inversamente proporcional ao índice de erro que o código pode apresentar.
• E. A métrica de profundidade de condições aninhadas é a que permite uma melhor compreensão do código.

Gabarito: B

Comentários

• • Complexidade ciclomática
  – Mede a complexidade das estruturas de controle de um
  programa.
  • Fan-in/Fan-out
  – Fan-in mede o número de funções que chama uma
  determinada função.
  – Fan-out mede o número de funções que uma determinada
  função chama.
  • Índice Fog
  – Comprimento médio de palavras e sentenças de um
  documento.
  
  Fonte: Professor Jair C Leite
  
  Complexidade cilomática também pode ser medida como: V(g) = Número de ciclos de excução + 1
• 
  

   a) O número de funções ou métodos que constam em um programa pode ser avaliado pela métrica de software fan-in/fan-out.

  
  ERRADO. Fan-in e fan-ou tem a ver com a quantidade de funções chamadas por um determinado método ou pela quantidade de funções que o chamam.
  
   b) A métrica de complexidade ciclomática é uma medida que pode estar relacionada ao nível de compreensão do programa.

  
  CERTO. Pode estar relacionada com o nível de compreensão.
  
   c) A medida do número de caracteres em um programa é uma métrica do tipo fog index.

  
  ERRADO. Índice tipo fog tem a ver com o comprimento médio de palavras e sentenças de um documento.
  
   d) A métrica de comprimento total faz referência ao número de linhas no código que se considera inversamente proporcional ao índice de erro que o código pode apresentar.

  
  ERRADO. É diretamente proporcional: quanto mais linhas de código, maior a probabilidade de erros ocorrerem.
  
   e) A métrica de profundidade de condições aninhadas é a que permite uma melhor compreensão do código.

  
  ERRADO. Não há tal relação e, adicionalmente, quanto mais condições aninhadas, mais difícil é a compreensão.
   

• b-

  Esta métrica mostra em grafos a sequência de um programa em rotas diferentes, representando o fluxo de controle. A partir de um grafo, sabe-se complexidade ciclomática- número de decisões adicionais em um programa. fórmula: v(G) = E – n + 2, onde, E: é o número de arestas e N: é o número de nós. A complexidade ciclomática leva em conta o número de sub-rotinas dentro de um programa, sugerindo que as mesmas sejam tratadas como componentes não relacionadas dentro do grafo de controle.

Questão 450016

• Banca: FGV
• Órgão: MEC
• Ano: 2009
• Provas: FGV - 2009 - MEC - Analista de Sistemas - Especialista
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Qualidade pode ser entendida como um conjunto de características a serem satisfeitas em um determinado grau, de modo que o produto de software atenda às necessidades explícitas e implícitas de seus usuários. No contexto de desenvolvimento de software, analise as afirmativas a seguir.
I. Características de qualidade do processo podem ser computadas a partir de características de qualidade do produto.
II. Processos possuem características de qualidade próprias e informações sobre a qualidade do produto gerado não influenciam em sua avaliação.
III. Características de qualidade do produto devem seguir padrões durante o desenvolvimento de software, sem serem influenciados por padrões de documentação
Assinale:

• A. se somente a afirmativa I estiver correta.
• B. se somente as afirmativas I e II estiverem corretas.
• C. se somente as afirmativas I e III estiverem corretas.
• D. se somente as afirmativas II e III estiverem corretas.
• E. se todas as afirmativas estiverem corretas.

Gabarito: A

Comentários

• II Produtos ruins foram gerados por processos ruins
  III Processos bons sao definidos e documentados.
• Mapeamento dos erros e comentarios
  
  I. Características de qualidade do processo podem ser computadas a partir de características de qualidade do produto.
  
  R: C. Se um produto é ruim, pode-se afirmar (ou concluir) que o seu processo de desenvolvimento é ruim. OU seja, a qualidade do processo é ruim (basta lembrar que no desenvolvimento de um produto, existe (ou pelo menos deveria existir) a parte de controle da qualidade antes dele ser liberado. Se este controle foi ruim, entregou um produto que tambem é ruim. Logo, o processo inteiro é prejudicado.
  
  II. Processos possuem características de qualidade próprias e informações sobre a qualidade do produto gerado não influenciam em sua avaliação.
  
  R: E. Voltando ao exemplo da resposta anterior, se temos um produto ruim, temos que ver onde houve falha no processo... Tento as informações sobre qual problema ocorre no produto, basta analisar a etapa responsavel por "nao deixar que isso aconteça" dentro do processo.
  
  III. Características de qualidade do produto devem seguir padrões durante o desenvolvimento de software, sem serem influenciados por padrões de documentação
  
  R: E. É ai que entra a lei e as praticas de mercado. Imaginem que um remedio é feito e a sua bula é criada sem os padrao de informacoes definidas pelo INMETRo. O remedio simplismente nao vai atender o seu proposito (se um paciente compra o remedio e nele nao contem as informacoes de contraindicacoes por exemplo, como ele vai saber se o remedio fara bem ou mal a ele?). Basta lembrar do papel do INMETRo, que definie padroes a serem utilizados pela industria em todos os sentidos (inclusive documentação). Isso se aplica inclusive ao desenvolvimento de software (existe padronizacao para documentos de caso de uso por exemplo... campos, papeis, definicoes, enfim).
  

Questão 488656

• Banca: NCE-UFRJ
• Órgão: UFRJ
• Ano: 2008
• Provas: NCE-UFRJ - 2008 - ACAPLAM-PB - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Considere as seguintes afirmativas sobre qualidade de projetos de software:

I- Coesão mede o grau de relacionamento entre as várias responsabilidades de um módulo de software.

II- Acoplamento mede o grau de dependência de módulo com os outros módulos de software.

III- A qualidade de um projeto de software diminui com o aumento da coesão de seus módulos e aumenta com o aumento do acoplamento entre eles.

A(s) afirmativa(s) correta(s) é/são somente:

• A. I
• B. II
• C. III
• D. I e II
• E. I, II e III

Gabarito: D

Comentários

• O desenvolvimento de software de qualidade, dentro do prazo e com o custo estabelecido é essencial para a sobrevivência de qualquer organização desenvolvedora de software. A facilidade com que se dá a manutenção e o potencial de reuso de um software desempenham papel de destaque nesse contexto, e os conceitos de coesão e acoplamento podem auxiliar muito neste sentido.
  
  Os conceitos de coesão e acoplamento, surgidos no contexto da análise e projeto estruturados, embora tenham um grande impacto na qualidade de sistemas, são geralmente desconhecidos ou negligenciados por desenvolvedores iniciantes de sistemas orientados a objetos. O desenvolvimento de softwares com alta coesão e fraco acoplamento facilita, entre outras coisas, a manutenção e o reuso. Assim sendo, o estudo desses conceitos e seus desdobramentos torna-se importante para melhorar a qualidade de sistemas.
  
  O acoplamento refere-se ao quanto uma unidade funcional depende de outra para funcionar. Uma unidade funcional pode ser um método, função ou mesmo uma classe. Quanto maior a dependência entre as unidades funcionais, mais fortemente acopladas elas estão. Uma das formas de se medir o acoplamento de um método, por exemplo, é a quantidade de parâmetros de entrada e suas respectivas complexidades. Quanto mais parâmetros e mais complexos eles forem, maior o acoplamento do método.
  
  A coesão está ligada à responsabilidade única da unidade funcional. Demonstra coerência e unidade conceitual no relacionamento com os outros componentes da unidade funcional. Ou seja, um método coeso realiza uma única função conceitual, servindo a apenas um propósito específico.
  
• I(CERTO) "Coesão está, na verdade, ligado ao princípio da responsabilidade única, que foi introduzido por Robert C. Martin no inicio dos anos 2000 e diz que uma classe deve ter apenas uma única responsabilidade e realizá-la de maneira satisfatória, ou seja, uma classe não deve assumir responsabilidades que não são suas . Uma vez sendo ignorado este princípio, passamos a ter problemas, como dificuldades de manutenção e de reuso"
  
  
  II (CERTO)"o acoplamento significa o quanto uma classe depende da outra para funcionar. E quanto maior for esta dependência entre ambas, dizemos que estas classes elas estão fortemente acopladas".
  
  III (ERRADA) "O forte acoplamento também nos traz muitos problemas, problemas até semelhantes aos que um cenário pouco coeso nos traz."
  
  Leia mais em: Entendendo Coesão e Acoplamento http://www.devmedia.com.br/entendendo-coesao-e-acoplamento/18538#ixzz2lfEasyEf

Questão 488677

• Banca: NCE-UFRJ
• Órgão: UFRJ
• Ano: 2008
• Provas: NCE-UFRJ - 2008 - ACAPLAM-PB - Analista de Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Um sistema de informação possui um Mean Time to Repair (MTTR) de 8 horas. Sabendo-se que a disponibilidade desejada para o sistema seja de 99%, o valor mais próximo da confiabilidade requerida do sistema como medida pelo Mean Time Between Failure (MTBF) deve ser:

• A. 600
• B. 720
• C. 792
• D. 808
• E. 910

Gabarito: C

Comentários

• Utiliza-se a seguinte fórmula:
  
  Disponibilidade = MTBF / (MTBF + MTTR)
  
  Ao substituir  a Disponibilidade por 0,99 e o MTTR como 8, temos o resultado final de 792.

• Disponibilidade = MTBF/(MTBF + MTTR)

  0,99 = MTBF/(MTBF + 8) => 0,99MTBF + 7,92 = MTBF => 0,01MTBF = 7,92 => MTBF = 792horas

  
  

Questão 513589

• Banca: FMP Concursos
• Órgão: TCE-RS
• Ano: 2011
• Provas: FMP Concursos - 2011 - TCE-RS - Auditor Público Externo - Administração
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

A qualidade de uma informação envolve três dimensões: tempo, forma e conteúdo. Qual das afirmações abaixo NÃO corresponde à correta dimensão?

• A. Fornecer informação livre de erros é uma dimensão de forma.
• B. Fornecer informação quando for necessária é uma dimensão de tempo.
• C. Fornecer somente as informações necessárias é uma dimensão de conteúdo.
• D. Informação pode ser fornecida impressa, em vídeo ou outro meio é uma dimensão de forma.
• E. Informação deve estar relacionada com as necessidades de cada destinatário específico, em cada situação é uma dimensão de conteúdo.

Gabarito: A

Comentários

• Livre de erros é conteúdo e não forma.

• Dimensão do Tempo: 

  A informação deve ser fornecida quando for necessária
  A informação deve estar atualizada quando for fornecida
  A informação deve ser fornecida tantas vezes quantas forem necessárias
  A informação pode ser fornecida sobre períodos passados, presentes e futuros.
  
  Dimensão do Conteúdo:
  
  A informação deve estar isenta de erros
  A informação deve estar relacionada às necessidades de informação de um receptor específico para uma situação específica.
  Toda a informação que for necessária deve ser fornecida.
  Apenas a informação que for necessária deve ser fornecida.
  A informação pode ter um alcance amplo ou estreito, ou um foco interno ou externo.
  A informação pode revelar desempenho pela mensuração das atividades concluídas, do progresso realizado ou dos recursos acumulados.
  
  Dimensão da forma:

  A informação deve ser fornecida de uma forma que seja fácil de compreender.
  A informação pode ser fornecida em forma detalhada ou resumida
  A informação pode ser organizada em uma seqüência predeterminada.
  A informação pode ser apresentada em forma narrativa, numérica, gráfica ou outras.
  A informação pode ser fornecida na forma de documentos em papel impresso, monitores de vídeo ou outras mídias

Questão 607120

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2011
• Provas: CESGRANRIO - 2011 - Petrobras - Analista de Sistemas Júnior - Processos de Negócios - 2011
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

A verificação de software é um processo mais abrangente que o processo de validação de software.

PORQUE

O objetivo da validação é assegurar que o sistema atenda às expectativas do cliente, enquanto que a verificação envolve testes de correção do produto.

Analisando-se as afirmações acima, conclui-se que

• A. as duas afirmações são verdadeiras, e a segunda justifica a primeira.
• B. as duas afirmações são verdadeiras, e a segunda não justifica a primeira.
• C. a primeira afirmação é verdadeira, e a segunda é falsa.
• D. a primeira afirmação é falsa, e a segunda é verdadeira.
• E. as duas afirmações são falsas.

Gabarito: E

Comentários

• Validação de software ou, mais genericamente, verificação e validação (V&V), tem a intenção de mostrar que um software se adequa a suas especificações ao mesmo tempo que satisfaz as especificações do cliente do sistema. Teste de programa, em que o sistema é executado com dados de testes simulados, é a principal técnica de validação. A validação também pode envolver processos de verificação, como inspeções e revisões, em cada estágio do processo de software, desde a definição dos requisitos de usuários até o desenvolvimento do programa. Devido à predominância dos testes, a maior parte dos custos de validação incorre durante e após a implementação.

   

  Fonte: Sommerville, 9ª Edição, Capítulo 2.

• Olá pessoal bom dia.

   

  VALIDAÇÃO - ESTAMOS CONSTRUÍNDO O PRODUTO CERTO?

     TÉCNICAS DE VALIDAÇÃO:

       REVISÕES DE REQUISITOS;

       PROTOTIPAÇÃO;

       GERAÇÃO DE CASOS DE TESTE

   

  Por exemplo: a área de negócio solicitou um sistema de gestão de reuniões, portanto a técnica de validação visa checar se é o sistema de gestão de reuniões que está sendo desenvolvido.

   

  VERIFICAÇÃO - ESTAMOS CONSTRUINDO O PRODUTO DE MANEIRA CERTA.

   

  Visa checar se o sistema de gestão de reuniões está isento de erros - maneira certa

   

  Esses conceitos são bem cobrados em diversas provas.

   

  Fonte: sommerville

   

  Go ahead!!!

• Estes termos são frequentemente confundidos, por isso vamos ver agora a diferença entre cada um destes processos:

  1. Verificação: Fizemos o software corretamente? 
  Esta atividade se resume em responder a esta pergunta. A verificação tem o objetivo de avaliar se o que foi planejado realmente foi realizado. Ou seja, se os requisitos e funcionalidades documentados foram implementados, além disso a verificação também pode ser realizada para especificação de sistemas, para avaliar se os requisitos estão sendo documentados como deveriam e ainda prever falhas ou inconsistências entre requisitos.

  2. Validação: Fizemos o software correto?

  A validação tem o objetivo de avaliar se o que foi entregue atende as expectativas do cliente. Ou seja, se os requisitos, independente do que foi planejado, estão sendo implementados para atender a regra de negócio do cliente, se o sistema é realmente aquilo que o cliente quer e está pagando para ter. A validação final do sistema é realizada pelo próprio cliente ou usuário.

• O objetivo da Validação e da Verificação é assegurar que o SW seja adequado e se atende às necessidades, ou seja, a confirmação de que este cumpra suas especificações.

  A Verificação é uma atividade, a qual envolve a análise de um sistema para certificar se este atende aos requisitos funcionais e não funcionais. Já a Validação, é a certificação de que o sistema atende as necessidades e expectativas do cliente. O processo de Validação e Verificação, não são processos separados e independentes

   

  https://www.devmedia.com.br/a-importancia-da-validacao-e-da-verificacao/24559

Questão 607132

• Banca: CESGRANRIO
• Órgão: Petrobras
• Ano: 2011
• Provas: CESGRANRIO - 2011 - Petrobras - Analista de Sistemas Júnior - Processos de Negócios - 2011
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

No contexto de qualidade de software e métricas de software, coesão e acoplamento são medidas

• A. intramodulares, sendo a primeira inversamente proporcional, e a segunda proporcional à qualidade.
• B. intramodulares e diretamente proporcionais à qualidade.
• C. intramodular e intermodular, respectivamente, sendo a primeira proporcional, e a segunda inversamente proporcional à qualidade.
• D. intermodulares e diretamente proporcionais à qualidade.
• E. intermodular e intramodular, respectivamente, sendo a primeira proporcional, e a segunda inversamente proporcional à qualidade.

Gabarito: C

Comentários

• GABARITO: C

  1) Acoplamento é uma medida “inter” componentes

  2) Coesão é uma medida “intra” componentes

  A primeira refere-se ao mundo externo do componente, como ele se inter-relaciona com os outros componentes do sistema.

  A segunda refere-se ao mundo interno do componente, como ele se intra-relaciona consigo mesmo.

  Para um software ter boa manutenibilidade, ter qualidade, é fundamental o modelarmos considerando sempre um sistema com Fraco Acoplamento e Alta Coesão.

• c-

  Muito acomplamento - maior dependencia. Pouco acomplamento - menor dependencia. Verifica-se que quanto mais acoplamento, pior. Unicas opções com essa informação sao 'c' & 'e'. Basta lembrar que "coesão mede associação de elementos em um modulo" p/ chegar à resposta

Questão 641401

• Banca: FCC
• Órgão: TRT - 2ª REGIÃO (SP)
• Ano: 2008
• Provas: FCC - 2008 - TRT - 2ª REGIÃO (SP) - Analista Judiciário - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

O modelo FURPS, para melhoria de qualidade de software, representa as dimensões, que são mais relevantes para os clientes:

• A. Funcionalidade, Usabilidade, Confiabilidade, Desempenho e Suportabilidade.
• B. Funcionalidade, Usabilidade, Reusabilidade, Pontualidade e Suportabilidade.
• C. Flexibilidade, Usabilidade, Conformidade, Desempenho e Atendimento.
• D. Flexibilidade, Usabilidade, Reusabilidade, Performance e Suportabilidade.
• E. Integridade, Usabilidade, Conformidade, Portabilidade e Atendimento.

Gabarito: A

Comentários

• Functionality (Funconalidade) Usability(Usabilidade) Reliability (Confiabilidade) Performance (Desempenho) Supportability (Suportabilidade)
  Resumo: http://qualidadebr.wordpress.com/2008/07/10/furps/

Questão 642316

• Banca: FCC
• Órgão: TCE-PR
• Ano: 2011
• Provas: FCC - 2011 - TCE-PR - Analista de Controle - Informática
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Segundo a ISO/IEC 12119:1994, dentre os requisitos de qualidade de um produto está sua descrição. Um dos objetivos básicos da descrição do produto é o de servir de base para os testes do produto. Dentre os itens que compõe a descrição do produto estão

• A. declarações de usabilidade, declarações de eficiência e declarações de suporte e treinamento.
• B. identificadores, declarações de funcionalidade e declarações de confiabilidade.
• C. declarações de manutenibilidade, declarações de portabilidade e declarações de consistência.
• D. declarações de funcionalidade, declarações de manutenibilidade e declaração de suporte e treinamento.
• E. declarações de usabilidade, declarações de consistência e indicadores.

Gabarito: B

Comentários

• Segundo a ISO/IEC 12119:1994: 
  " 3.1 Descrição de produto

  Cada pacote de  software deve ter uma descrição de produto. A descrição de produto define o produto e é uma parte do conjunto de documentação do produto. Ela fornece informações sobre a documentação de usuário, programas e, se existirem, sobre os dados.

  Os principais objetivos da descrição de produto são: 

  - ajudar o usuário ou o comprador em potencial na

  avaliação da adequação do produto às suas necessidades. Por extensão ela também fornece informações para venda;

  - servir como base para testes (ver seção 4).

  A descrição de produto deve estar disponível para pessoas interessadas no produto.As subseções a seguir, de 3.1.2 a 3.1.8, especificam o que a descrição de produto deve incluir ou convém que inclua, podendo incluir declarações adicionais sobre o produto

  3.1.2 Identificações e indicações
  3.1.3 Declarações sobre funcionalidade
  3.1.4 Declarações sobre confiabilidade
  3.1.5 Declarações sobre usabilidade
  3.1.6 Declarações sobre eficiência
  3.1.7 Declarações sobre manutenibilidade
  3.1.8 Declarações sobre portabilidade "
  
  Bom Estudo!

Questão 644443

• Banca: FCC
• Órgão: TJ-PE
• Ano: 2012
• Provas: FCC - 2012 - TJ-PE - Analista Judiciário - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

No contexto dos atributos de qualidade de software, con- sidere:

I. A resiliência é a capacidade de o sistema voltar ao nível de desempenho anterior a falhas ou comportamento imprevisto de usuários, software ou hardware e recuperar os dados afetados, caso existam.

II. O desempenho e uso de recursos referem-se à capacidade do sistema de alcançar tempos de resposta, latência, tempo de processamento, vazão, etc dentro do período de tempo especificado e ao fato do software exigir mais ou menos recursos de acordo com suas condições de uso.

III. A analisabilidade é o grau de facilidade, com qual seja possível procurar por deficiências no software ou por partes que devem ser modificadas para algum fim.

As subcaracterísticas contidas nos itens I, II e III referem-se, respectivamente, aos atributos de qualidade

• A. funcionabilidade, confiabilidade e usabilidade.
• B. eficiência, manutenibilidade e portabilidade.
• C. funcionabilidade, usabilidade e manutenibilidade.
• D. confiabilidade, eficiência e manutenibilidade
• E. confiabilidade, eficiência e portabilidade.

Gabarito: D

Comentários

• Os atributos que um software deve possuir para que possamos dizer que ele é de qualidade são os seguintes:
   - Funcionalidade: é a capacidade do software de realizar as funções que foram especificadas.
  - Confiabilidade: Quando afirmamos que um sistema é confiável, estamos afirmando que esse sistema é capaz de manter algum nível de desempenho quando funcionando sob circustâncias determinadas. A confiabilidade é normalmente definida sob períodos de tempo.
  - Usabilidade: Usabilidade é a medida da facilidade de o usuário executar alguma funcionalidade do sistema. Essa facilidade está ligada  à compreensibilidade, à facilidade de aprendizado, à operabilidade, a quanto o usuário se sente atraído pelo sistema e à adesão de padrões de usabilidade, que são as subcaracterísticas desse atributo de qualidade.
  - Eficiência: A eficiência ou desempenho é talvez a qualidade mais buscada durante o desenvolvimento de software, uma vez que ela é a mais percebida pelos usuários. Ela é a qualidade relacionada ao uso de recursos do sistema quando esse provê funcionalidade e é também a com que os desenvolvedores mais se preocupam.
  - Manutenibilidade: é uma qualidade, às vezes, negligenciada pelos usuários, mas muito importante aos desenvolvedores. Ela é a capacidade de o software ser modificado em seu processo de evolução.
  - Portabilidade: O último atributo de qualidade presente no padrão ISO/IEC 9126-1:2001 é o de portabilidade. Esse atributo é a medida de necessárias para que o sistema tenha seus requisitos ou ambientes de execução modificados, podendo ser o ambiente de software, de hardware ou organizacional.

• Segundo Pressman, os atributos de qualidade de software são: portabilidade, funcionalidade, eficiência, manutenibilidade, confiabilidade e usabilidade.

• qual é a letra?

  
  

• d-

  relisiencia (resilience) significa retornar ao estado original, geralmente depois de pressionar ou deformar. Um travesseiro tem resiliencia. Argila, não. Confiabilidade é comprovada por testes de stress (ver o quanto o sistema aguenta). Eficiencia é uso racional de recursos, executando o trabalho exigido dentro dos limites contextuais. Manutenção é capacidade do software de ser corrigido quando necessario

Questão 646165

• Banca: FCC
• Órgão: TJ-PE
• Ano: 2012
• Provas: FCC - 2012 - TJ-PE - Técnico Judiciário - Programador de Computador
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Em relação a Qualidade e Teste de Software, quando um produto é previamente testado e enviado para uma nova avaliação, considere:

I. Todas as partes alteradas nos documentos, funcionalidades e informações devem ser testadas como se fosse um produto novo.

II. Todas as partes inalteradas que sejam influenciadas pelas partes alteradas ou por mudanças em um requerido sistema (de acordo com os conhecimentos específicos do testador) devem ser testadas por amostragem.

III. Todas as outras partes que não foram alteradas ou influenciadas pelas alterações, devem ser testadas como sendo um novo produto.

Está correto o que se afirma em

• A. I, apenas.
• B. I, II e III.
• C. II, apenas.
• D. I e III, apenas.
• E. III, apenas.

Gabarito: A

Comentários

• I. Todas as partes alteradas nos documentos, funcionalidades e informações devem ser testadas como se fosse um produto novo.TESTE DE CONFIRMAÇÃO
  
  II. ERRADO Todas as partes inalteradas que sejam influenciadas pelas partes alteradas ou por mudanças em um requerido sistema (de acordo com os conhecimentos específicos do testador) devem ser testadas por amostragem. ESSAS PARTES INFLUENCIADAS DEVERÃO SER TESTADAS NA SUA TOTALIDADE.
  
  III. ERRADO Todas as outras partes que não foram alteradas ou influenciadas pelas alterações, devem ser testadas como sendo um novo produto.NESSE CASO PODERIA SER TESTADO UM PARTE REPRESENTATIVA, TESTE DE REGRESSÃO.
• Complementando, o item II não está errado somente pelo trecho "por amostragem", mas, também pelo parêntese (de acordo com os conhecimentos específicos do testador).
  As partes inalteradas afetadas pela alteração devem ser identificadas com base na solicitação de teste e na documentação do produto de software, não de acordo com os conhecimentos de quem está testando. Seguindo o processo estabelecido, qualquer testador deve ser capaz de realizar os testes.

Questão 646204

• Banca: FCC
• Órgão: TJ-PE
• Ano: 2012
• Provas: FCC - 2012 - TJ-PE - Técnico Judiciário - Programador de Computador
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

São práticas eficientes para revisão de código, EXCETO:

• A. Revisar código por, no máximo, 90 minutos por vez.
• B. Revisar até 500 linhas de código por hora.
• C. Adotar revisões de código com auxílio de ferramentas.
• D. Revisar até 1000 linhas de código por vez.
• E. Decidir antecipadamente os objetivos do processo de revisão de código e como medir sua efetividade.

Gabarito: D

Comentários

• a) Revisar código por, no máximo, 90 minutos por vez. FAZ SENTIDO, PARA NÃO DEIXAR OS REVISORES EXAUSTOS
  b) Revisar até 500 linhas de código por hora. CONFORME ALGUMAS PESQUISAS DE MERCADO NÃO É VIÁVEL REVISAR MAIS QUE 200 A 400 LINHAS DE CÓDIGO POR VEZ.
  c) Adotar revisões de código com auxílio de ferramentas. COM CERTEZA, EXISTEM FERRAMENTAS PARA AVALIAR A COMPLEXIDADE CICLOMÁTICA DO CÓDIGO ASSIM COMO OUTRAS CARACTERÍSTICAS ESTRUTURAIS DO MESMO.
  d) ERRADO Revisar até 1000 linhas de código por vez. CONFORME ALGUMAS PESQUISAS DE MERCADO NÃO É VIÁVEL REVISAR MAIS QUE 200 A 400 LINHAS DE CÓDIGO POR VEZ. http://www.ibm.com/developerworks/br/rational/library/11-proven-practices-for-peer-review/index.html?ca=drs-
  e) Decidir antecipadamente os objetivos do processo de revisão de código e como medir sua efetividade. COM CERTEZA, PLANEJAR É TUDO
  
  Questão difícil, saber o máximo de número de linhas de código a ser adotada para um revisão eficiente...
  Pra mim a letra b deixa um poucos de dúvida...

• Várias práticas comprovadas para revisão de código de peer mais efetiva e eficiente:

  1.Revise menos que 200-400 linhas de código por vez
  2.Tenha como objetivo uma taxa de inspeção de menos de 300-500 LOC por hora
  3.Reserve tempo para uma revisão apropriada e lenta, mas não mais de 60-90 minutos
  4.Faça com que os autores anotem o código de origem antes que a revisão comece
  5.Estabeleça objetivos quantificáveis para a revisão de código, e capture métricas de modo que possa melhorar seus processos
  6.Use listas de verificação, pois elas melhoram substancialmente os resultados para autores e revisores
  7.Verifique se os defeitos foram mesmo corrigidos
  8.Crie uma boa cultura de revisão de código, na qual encontrar defeitos é visto de forma positiva
  9.Revise ao menos parte do código, mesmo que não possa fazer tudo, para se beneficiar do Efeito Ego
  10.Adote revisões de código leves e com auxílio de ferramenta

  RESPOSTA: "D"
  
  Fonte: http://www.ibm.com/developerworks/br/rational/library/11-proven-practices-for-peer-review/index.html?ca=drs-

• really FCC??? really??? um pouco subjetiva essa questão, não?

Questão 662236

• Banca: FCC
• Órgão: INFRAERO
• Ano: 2011
• Provas: FCC - 2011 - INFRAERO - Analista - Engenharia de Software
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Executa um sistema de forma a demandar recursos em volume ou frequência acima do normal. Trata-se de

• A. validação de unidade de implementação.
• B. teste beta.
• C. teste de estresse.
• D. validação de integração.
• E. teste de desempenho.

Gabarito: C

Comentários

• Os testes de desempenho precisam ser projetados para assegurar que o sistema possa processar a carga a que se destina. Isso normalmente envolve a execução de uma série de testes em que você aumenta a carga até que o desempenho do sistema se torne inaceitável.

   

  Uma forma eficaz de descobrir os defeitos é projetar testes para os limites do sistema. Em testes de desempenho, isso significa estressar o sistema, fazendo demandas que estejam fora dos limites de projeto do software. Isso é conhecido como "teste de estresse". Ese tipo de teste tem duas funções: testar o comportamento de falha do sistema e estressar o sistema e trazer à luz defeitos que normalmente não são descobertos.

   

  Os testes de estresse são particularmente relevantes para sistemas distribuídos baseados em uma rede de processadores. Esses sistemas frequentemente apresentam degradação severa quando estão muito carregados. A rede fica inundada com dados de coordenação que os diferentes processos devem trocar. Os processos tornam-se mais lentos à medida que aguardam os dados requisitados a outros processos. Os testes de estresse ajudam-no a descobrir quando a degradação começa, e, assim, você pode adicionar controles ao sistema para rejeitar operações além desse ponto.

   

  Fonte: Sommerville, 9ª Edição, Capítulo 8.

Questão 669598

• Banca: CONSULPLAN
• Órgão: TSE
• Ano: 2012
• Provas: CONSULPLAN - 2012 - TSE - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

Durante o desenvolvimento de um software, é comum a realização de testes, com o objetivo de analisar e concluir se o software está sendo desenvolvido em conformidade com as especificações. Nesse contexto, observe as afirmativas a seguir, estabelecidas por Boehm.

I. Estamos construindo o produto correto?

II. Estamos construindo o produto corretamente?

Essas afirmativas estão relacionadas, respectivamente, aos conceitos de

• A. validação e verificação.
• B. verificação e validação.
• C. avaliação e aceitação.
• D. aceitação e avaliação.

Gabarito: A

Comentários

• I. Estamos construindo o produto correto?
  Está validando
  
  II. Estamos construindo o produto corretamente?
  Está verificando
• Validação
  •“Estamos construindo o produto correto?”
  •O sistema atende às expectativas do cliente/usuário
   
  Verificação
  •“Estamos construindo o produto corretamente?”
  •O software está de acordo com suas especificações
   
  fonte: Pressman, Roger s. Engenharia de Software - 1995
• Verificação: Aspecto interno.Checa se o software atende aos requisitos funcionais.  Refere-se ao conjunto de atividades que garantem que o software implementa corretamente as funções especificadas.
  Visa responder a pergunta:
  Are we build de product right? 
  Estamos construindo o produto de forma correta?
  
  Validação: Aspecto externo. Foco no cliente. Garante que o software está alinhado com as reais necessidades do cliente. Avalia se o sistema é útil e adequado à uma situação operacional.
  Visa responder a pergunta:
  Are we build de right product?
  Estamos construindo o produto certo? 
• O teste de software é um elemento de um tópico mais amplo, muitas vezes conhecido como verificação e validação (V&V). Verificação refere-se ao conjunto de tarefas que garantem que o software implementa corretamente uma função específica. Validação refere-se a um conjunto de tarefas que asseguram que o software foi criado e pode ser rastreado segundo os requisitos do cliente. Boehm define de outra maneira: Verificação: “Estamos criando o produto corretamente?” Validação: “Estamos criando o produto certo?”

• VERIFICAÇÃO - ESTAMOS CONSTRUINDO O PRODUTO CORRETAMENTE? SEM ERROS, BUGS, ETC...

   

  VALIDAÇÃO - ESTAMOS CONSTRUINDO O PRODUTO CORRETO? DE ACORDO COM AS ESPECIFICAÇÕES DO USUÁRIO?

• a-

  Validação é para requisitos. Se os requisitos nao foram validados, havera duvidas se o software é o correto, mesmo se for feito corretamente

  Verificação é para o software para ver se ha bugs etc. Se nao houver verificação, o software ainda pode ser o desejado, mesmo que com requisitos nao-funcionais ausentes

Questão 704281

• Banca: CESPE / CEBRASPE
• Órgão: MPE-PI
• Ano: 2012
• Provas: CESPE - 2012 - MPE-PI - Analista Ministerial - Informática
• Disciplina: Engenharia de Software
• Assuntos: Análise de Pontos de Função; Métricas de Software; Qualidade de Software

A direção de uma empresa designou uma equipe de
analistas para garantir a qualidade dos sistemas de informação em
produção na entidade. Para cumprir suas atribuições, a equipe
recorreu a diversas técnicas e metodologias para a avaliação da
qualidade do desenvolvimento de software.

Com base nessa situação hipotética, julgue os itens que se seguem

Conforme a metodologia definida pelo IFPUG (International Function Point User Group), computam-se como arquivos de interface externa os dados que sejam recebidos de outra aplicação e utilizados para alterar ou remover dados de um arquivo lógico interno

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Errado, isso seria uma entrada externa. Nesse caso os dados recebidos funcionam de forma análoga a comandos inseridos pelo usuário.
• A questão refere-se a Entradas Externas e não Interfaces Externas, portanto esta errada.
  Interface Externa é um agrupamento lógico de dados que reside fora da aplicação, mas fornece informações que podem ser usadas pela aplicação.
  Entradas Externa é originada de um usuário ou transmitida de outra aplicação e fornece dados distintos orientados a a plicação ou informações de controle. Entradas são muitas vezes usadas para atualizar arquivos lógicos internos.
  
  
• Arquivo de interface externa: É um grupo de dados logicamente relacionado ou informações de controle identificados pelo usuário, referenciado na aplicação para fins de recuperação de dados cuja a manutenção é feita por outro aplicativo. Os dados são armazenados fora da fronteira da aplicação.
  Um AIE é obrigatoriamente um ALI de outra aplicação. 

• ALI e AIE tem a intenção de mantar e armazenar, ou dentro da fronteira da aplicação (ALI) ou fora de sua fronteira (AIE) para esses dados serem referenciados, e nunca de alterar / remover os dados de sua aplicação, portanto questão errada!

• Erro da questão está destacada:

  Conforme a metodologia definida pelo IFPUG (International Function Point User Group), computam-se como arquivos de interface externa os dados que sejam recebidos de outra aplicação e utilizados para alterar ou remover dados de um arquivo lógico interno

  Resposta: o termo destacado se trata de um entrada externa (EE) e não uma AIE.

• e-

  FPA considera 2 tipos de dados: estaticos: ALI e AIE; dinâmicos: EE,SE,CE. ALI é dentro e AIE é em outra aplicação. Justamente por serem estáticos, nao modificam dados

Questão 708934

• Banca: FCC
• Órgão: MPE-PE
• Ano: 2012
• Provas: FCC - 2012 - MPE-PE - Analista Ministerial - Informática
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Sobre os itens que devem ser incluidos em uma estrutura preliminar para um plano de qualidade de software, considere:

I. Uma introdução ao produto, contendo uma descrição do produto, seu mercado pretendido e as expectativas de qualidade do produto.

II. Planos do produto, com datas críticas de release e responsabilidades para o produto, junto com os planos para a distribuição e prestação de serviço do produto.

III. Descrições de processo. Os processos de desenvolvimento e serviço são padrões que devem ser usados para o gerenciamento e desenvolvimento de produto.

IV. Os riscos mais importantes que podem afetar a qualidade do produto e as ações que devem ser tomadas ao lidar com eles.

É correto incluir os itens:

• A. II e IV, apenas.
• B. I, II e III, apenas.
• C. I, III e IV, apenas.
• D. I, II, III e IV.
• E. II e III, apenas.

Gabarito: D

Comentários

• A questão é uma cópia da estrutura para o plano de qualidade proposta por Humphrey, descrito no livro "Engenharia de Software" - Ian Sommerville
  

Questão 720454

• Banca: ESAF
• Órgão: CGU
• Ano: 2008
• Provas: ESAF - 2008 - CGU - Tecnologia da Informação - Desenvolvimento de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Um modelo de qualidade define os requisitos que as organizações devem seguir para se capacitarem segundo o mesmo. Entre as opções abaixo, assinale a que se refere exclusivamente a modelos de qualidade de software.

• A. CMMI, MPS.BR, COBIT.
• B. CMMI, COBIT, ISO9001.
• C. CMMI, MPS.BR, ISO9001, COBIT
• D. CMMI, MPS.BR, ISO9000-1.
• E. CMMI, ISO12207, ISO15504, ISO20000, ITIL

Gabarito: D

Comentários

• MPS.BR e ISO 9000-1 não são modelos de qualidade ????
• Complementando o comentário da amiga, 
  O MPS.BR ou Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS)
  A ISO editou a série 9000 com o objetivo de estabelecer critérios para implantação de Sistemas de Garantia da Qualidade. O objetivo da norma é construir um modelo de gerenciamento na organização para que os processos de trabalho sejam padronizados, e, com isso, ajudem a organização na realização de serviços e produção de bens que atendam aos requisitos dos clientes.
• Resposta , Letra B?????   
  NUNCA!!!
  O Propósito do Cobit é ser um guia de boas práticas de gerenciamento... e nada tem a ver com qualidade de software!!!
• Calma, meus camaradas! O gabarito da questão já foi alterado para a correta letra D!
• A ISO 90001 não se refere exclusivamente a qualidade de software, mas também a outras áreas : Software, Hardware, Serviços e processamento de materiais. O examinador tomou umas cachaça ao elaborar essa questão.
  
  http://www.ehow.com/facts_6814066_iso-90001-certification.html

• CMMI, MPS.BR e ISO9000-1, são modelosde qualidade de software.

  COBIT: é um guia de boas praticas e representado como framework, testes dirigidos para a gestão de tecnologia da informação.

  ISO 9000: designa um conjunto de normas técnicas que estabelecem um modelo de gestão da qualidade para organizações em geral, qualquer que seja o seu tipo ou dimensão.

  ISO 12207: Estabele um processo de ciclo de vida do software, contendo processos, atividades e são aplicadas durante a aquisição e configuração dos serviços de sistemas, de forma a melhorá-los.

  ISO 15504: Também conhecida como SPICE, define um processo de desenvolvimento de software. Ela é uma evolução da ISO 12207, mas possui níveis de capacidade para cada processo assim como o CMMI, porém esse não baseou-se naquela, mas são compatíveis.

  ISO 20000: É a primeira norma mundial, especificamente focada para a gerencimaneto de serviços de TI. Ela não formaliza a inclusão das práticas do ITIL, embora esteja descrito na norma um conjunto de processos de gerenciamento que estão alinhados com os processos definidos dentro dos livros do ITIL.

  ITIL: É um conjunto de boas práticas para serem aplicadas na infra-estrutura, operação e manutenção deserviços de TI.

  
  

  
  

• O enuciado poderia terminar assim: que se refere exclusivamente a modelos de qualidade
  

  Ou assim: que se refere, dentre outras coisas, a modelos de qualidade de software
  

  Mas não assim: "que se refere exclusivamente a modelos de qualidade de software"

  A ISO9000-1 (agora obsoleta), pelo que me consta, fazia referência a 4 tipos de produtos:

  • Hardware

  • Software

  • Processed materials

  • Services

  http://www.praxiom.com/iso-9000-1.htm

  Vida de concurseiro fazedor de questão e montador de prova é mole... mas a nossa vida de concursando tá difícil! Tu quoque, ESAF, fili mi!
  

• Sabemos que nem o COBIT (Governança e Gestão de TI), nem a ITIL (Serviços de TI) tratam de qualidade de software.

• d-

  CMMI é um modelo para a melhoria da qualidade e do processo de software em estágios evolutivos de maturidade. Os 5 níveis de maturidade são:

  (1) inicial: Processo imprevisível e sem controle.

  (2) Repetível: processo disciplinado.

  (3) Definido: processo consistente e padronizado.

  (4) Gerenciado: processo previsível e controlado

  (5) Otimização: processo aperfeiçoado para sempre.

Questão 726910

• Banca: INSTITUTO CIDADES
• Órgão: TCM-GO
• Ano: 2012
• Provas: INSTITUTO CIDADES - 2012 - TCM-GO - Auditor de Controle Externo - Informática
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

De acordo com o SWEBOK a qualidade de software é dividida em tópicos. São eles:

I. Fundamentos de qualidade de software;

II. Métricas de desempenho;

III. Gerência do processo de qualidade de software;

IV. Considerações práticas.

• A. II e III, somente;
• B. I, II e III, somente;
• C. I, III e IV, somente;
• D. II, III e IV, somente;
• E. I, II, III e IV.

Gabarito: C

Comentários

• • Promover uma visão consistente da engenharia de software no mundo
  • Clarear e marcar as fronteiras entre a engenharia de software e as outras disciplinas relacionadas
  • Caracterizar o conteúdo da disciplina de engenharia de software
  • Classificar em tópicos a área de conhecimento da engenharia de software
  • Prover uma fundação para o desenvolvimento do currículo, para certificação individual e para licenciamento de material
  • LETRA C

• Para um melhor entendimento e estudo, o SWEBOK divide a qualidade de software em três tópicos, e cada tópico é subdividido em atividades, da seguinte forma:

  • Fundamentos de qualidade de software
    • Cultura e ética de engenharia de software
    • Valores e custos de qualidade
    • Modelos e características de qualidade
    • Melhoria da qualidade
  • Gerência do processo de qualidade de software
    • Garantia de qualidade de software
    • Verificação e validação
    • Revisões e auditorias
  • Considerações práticas
    • Requisitos de qualidade para aplicações
    • Caracterização de defeitos
    • Técnicas de gerência de qualidade de software
    • Medidas de qualidade de software
  
  

  Fonte: http://pt.wikipedia.org/wiki/Qualidade_de_software

• SWEBOK divide a Qualidade de Software em 3 tópicos:

   

  Fundamentos de Qualidade de Software:

  - Cultura e ética de engenharia de software

  - Valores e custos de qualidade

  - Modelos e características de qualidade

  - Melhoria da qualidade

  Gerência do Processo de Qualidade de Software:

  - Garantia de qualidade de software

  - Verificação e validação

  - Revisões e auditorias

  Considerações Práticas:

  - Requisitos de qualidade para aplicações

  - Caracterização de defeitos

  - Técnicas de gerência de qualidade de software

  - Medidas de qualidade de software

Questão 762184

• Banca: FCC
• Órgão: TCE-AM
• Ano: 2012
• Provas: FCC - 2012 - TCE-AM - Analista de Controle Externo - Tecnologia da Informação
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Considere o excerto a seguir:

A engenharia de software pode ser considerada uma tecnologia, com métodos e ferramentas próprios, estruturada em camadas, do ponto de vista sistêmico. A abordagem sistêmica da engenharia de software deve se apoiar num compromisso organizacional com a qualidade que leve à cultura de um processo contínuo de aperfeiçoamento, e é essa cultura que, em última análise, leva ao desenvolvimento de abordagens cada vez mais efetivas. A camada de base em que a engenharia de software se apoia é I e o “adesivo” que mantém unidas as camadas, estruturadas segundo a visão sistêmica, é o I I .

As lacunas I e II devem ser preenchidas, correta e respectivamente, por:

• A. o foco na qualidade - processo
• B. o uso de ferramentas - controle de qualidade
• C. o controle de qualidade - método
• D. o controle de requisitos - projeto
• E. a qualidade de processo - método

Gabarito: A

Comentários

• A engenharia de software é uma disciplina com base em camadas:
  
  • Foco na qualidade = base de apoio, deve ter um compromisso organizacional com a qualidade.
  • Processo  = adesivo que mantém unidas as camadas de tecnologias e permite o desenvolvimento racional e oportuno de softwares de computador.
  • Métodos = define como fazer, análise, modelagem e outras técnicas descritivas.
  • Ferramentas =  fornecem apoio automatizado ou semi-automatizado para o processo e para os métodos. 

Questão 770011

• Banca: CESPE / CEBRASPE
• Órgão: Banco da Amazônia
• Ano: 2012
• Provas: CESPE - 2012 - Banco da Amazônia - Técnico Científico - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software; Teste de Software

A respeito de depuração em lógica de programação, julgue os itens
que se seguem.

Testes top-down são utilizados em conjunto com terminadores, em que uma técnica de rotina de inicialização substitui métodos de mais alto nível por um stub.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• §  Teste de integração top-down
  ·         Começa com os componentes de alto nível de um sistema, e a integração se dá de cima para baixo em uma hierarquia de componentes. Componentes individuais em um nível mais baixo na hierarquia são representados por stubs.

Questão 773485

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Gerente de Projetos
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Com relação a conceitos gerais da engenharia de software, julgue
os itens seguintes.

Para a produção sistemática de software de qualidade, a engenharia de software propõe abordagens que atendam a qualidade sob a perspectiva do produto a ser criado, do processo de criação do produto e de sua adequação ao uso.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• A norma ISO/IEC 9126, estabelece um modelo de qualidade com os seguintes componentes:

  • Processo de desenvolvimento, cuja qualidade afeta a qualidade do produto de software gerado e é influenciado pela natureza do produto desenvolvido;
  • Produto, compreendendo os atributos de qualidade do produto (sistema) de software. Estes atributos de qualidade podem ser divididos entre atributos internos e externos. Estes se diferenciam pela forma como são aferidos (interna ou externamente ao produto de software) e em conjunto compõem a qualidade do produto de software em si;
  • Qualidade em uso que consiste na aferição da qualidade do software em cada contexto específico de usuário. Esta é, também, a qualidade percebida pelo usuário.
  
  

Questão 773512

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Gerente de Projetos
• Disciplina: Engenharia de Software
• Assuntos: Análise de Pontos de Função; Métricas de Software; Qualidade de Software

Com referência à qualidade de software e às métricas utilizadas na
avaliação de processos e projetos de software, julgue os itens a
seguir.

O arquivo de interface externa, que armazena dados referenciados, é um tipo de função de dados lidos e mantidos pela aplicação.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• O arquivo de interface externa, que armazena dados referenciados, é um tipo de função de dados lidos e mantidos pela aplicação.
  
  Os AIE são mantidos dentro da fronteira de outra aplicação!
  
  É sempre bom lembrar que o AIE é, sempre, um ALI (Arquivo Interno Lógico) em outra aplicação!
• Questão Errada.
  
  O arquivo de interface externa, que armazena dados referenciados, é um tipo de função de dados lidos e mantidos pela aplicação. (Dados são mantidos dentro da fronteira de outra aplicação)
  
  
  Um arquivo de interface externa (AIE) é um grupo de dados ou de informações de controle logicamente relacionados, reconhecido pelo usuário, referenciado pela aplicação que está sendo contada, porém, mantido dentro da fronteira de uma outra aplicação. A intenção primária de um AIE é armazenar dados referenciados através de um ou mais processos elementares dentro da fronteira da aplicação que está sendo contada. Um AIE sempre será um ALI em outra aplicação.

Questão 773515

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Gerente de Projetos
• Disciplina: Engenharia de Software
• Assuntos: Análise de Pontos de Função; Métricas de Software; Qualidade de Software

Com referência à qualidade de software e às métricas utilizadas na
avaliação de processos e projetos de software, julgue os itens a
seguir.

Denominam-se consulta externa as funções do tipo transação que não fazem processamento nem alteram o comportamento do sistema.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Processo que envia dados para fora da fronteira da aplicação sem processamento adicional
  Sua intenção primária é apresentar dados ao usuário através da recuperação destes dados 
  Sua lógica de processamento não contém fórmula matemática, nem cálculo, nem cria dados derivados
  
  Pedrosa
• • Consulta externa (CE) – é um par pergunta-resposta, cuja pergunta vem de um usuário ou de outro aplicativo. Os dados são recuperados para atender à solicitação e então são enviados para fora. Uma consulta é definida como uma entrada que resulta na geração de alguma resposta imediata. São consultas externas as consultas simples, realizadas no banco de dados, sem modificá-lo, e mostradas na tela. As telas de ajuda são exemplos.
• Questão com gabarito incorreto. Caberia recurso
  
  Definição de Consulta externa segundo o manual de práticas de contagem: Processo elementar que envia dados ou informações e controle para fora da fronteira da aplicação através da recuperação de dados ou informações de controle de um ou mais ALI ou AIE. A lógica de processamento não deve conter fórmula matemática ou cálculo, não deve criar dados derivados, nem alterar o comportamento do sistema.
  
  Análise da questão:
  1. A questão afirma que "Denominam-se consulta externa as funções do tipo transação que não fazem processamento nem alteram o comportamento do sistema". Vejam que o enunciado diz claramente que Consultas Externas não fazem processamento.
  2. O manual afirma que a lógica de processamento de uma CE "não deve conter fórmula matemática ou cálculo, não deve criar dados derivados, nem alterar o comportamento do sistema"
  3. Logo, há lógica de processamento em uma Consulta Externa (CE), o que torna o enunciado errado. Lógica de processamento é uma característica fundamental das funções transacionais (EE, CE e SE), só que no caso das CEs, a lógica não contém fórmula matemática nem cria dados derivados.

• ALI - 7 - 10 - 15

  AIE - 5 - 7 - 10

  C.E - 3 - 4 -6

  E.E - 3 - 4 -6

  S.E - 4 - 5 - 7

Questão 773521

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Gerente de Projetos
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Com referência à qualidade de software e às métricas utilizadas na
avaliação de processos e projetos de software, julgue os itens a
seguir.

A norma independente SPICE (Software Process Improvement and Capability Determination), embora contribua para a melhoria contínua do processo de software, é pouco utilizada por não estar em conformidade com outras normas, como, por exemplo, a ISO 15504.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• A ISO iniciou em janeiro de 1993 o projeto SPICE (Software Process Improvement and Capability dEtermination) com o objetivo de produzir inicialmente um relatório técnico que fosse, ao mesmo tempo, mais geral e abrangente que os modelos existentes e mais específico que a norma ISO 9001 originando, assim, a série de normas ISO/IEC 15504. 
  
  Fonte: MPS.BR Guia Geral: 2011

• e-

  ISO 15504 tambem é conhecida como SPICE e define processo de desenvolvimento do software. ISO 15504 possui 9 documentos para avaliação do processo, o que lhe confere compaiblidade com o CMMI. As 2 classes avaliadas pelo ISO 15504 sap processo e capacidade.

Questão 773527

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Gerente de Projetos
• Disciplina: Engenharia de Software
• Assuntos: Frameworks; Qualidade de Software

Com referência à qualidade de software e às métricas utilizadas na
avaliação de processos e projetos de software, julgue os itens a
seguir.

A norma ISO 15504 apresenta um framework de avaliação tanto do processo de negócio quanto da engenharia de software e da organização. Nesse framework, os processos são identificados em seis níveis específicos: incompleto, executado, gerenciado, estabelecido, previsível e otimizado.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Capability levels and process attributes

  For each process, ISO/IEC 15504 defines a capability level on the following scale:

  LevelName5Optimizing process4Predictable process3Established process2Managed process1Performed process0Incomplete process

  http://en.wikipedia.org/wiki/ISO/IEC_15504#Capability_levels_and_process_attributes
  

• Gabarito: Certo

   

  Se você está pensando "já vi isso em algum outro lugar" ...

  "O conjunto de produtos COBIT 5 inclui um modelo de capacidade de processo, com base no padrão de Avaliação de Processo – Engenharia de Software ISO/IEC 15504 reconhecido internacionalmente."

  Cobit 5 - página 43 - CAPÍTULO 8 MODELO DE CAPACIDADE DE PROCESSO DO COBIT 5

• c-

  ISO 15504 avalia 2 coisas: processos e capacidade, o qual acompanha o CMMI na escala de 0 a 5

Questão 773530

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Gerente de Projetos
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Com referência à qualidade de software e às métricas utilizadas na
avaliação de processos e projetos de software, julgue os itens a
seguir.

No processo de gerenciamento de software, a qualidade, elemento não mensurável, somente pode ser avaliada qualitativamente, por meio do atendimento das necessidades do cliente em contraste com as possibilidades de desenvolvimento e orçamento disponíveis.

• C. Certo
• E. Errado

Gabarito: E

Comentários

• Pessoal, segundo Pressman:
  Define-se qualidade como uma característica ou atributo de alguma coisa. Como atributo de um item, a qualidade se refere a características mensuráveis. Temos assim, 2 perspectivas envolvendo qualidade em engenharia de software:
  • Qualidade do projeto: refere-se a características que os projetistas especificam para um certo item. Abrange os requisitos, as especificações e o projeto do sistema.
  • Qualidade de conformidade é o grau com que as especificações de projeto são seguidas durante a fabricação. Abrange principalmente a implementação.
  Além do mais, um produto de software pode ser avalidado qualitativamente sob diversos aspectos: Funcionalidade, Usabilidade, Confiabilidade, Desempenho, Manutenibilidade e Portabilidade. E essas avaliações podem (e devem) ser realizadas por equipes de testes especialidadas em uma ou mais dessas abordagens.
  
  Espero ter ajudado!
• Parei de ler no "elemento não mensurável"...
  

Questão 776503

• Banca: CESGRANRIO
• Órgão: Chesf
• Ano: 2012
• Provas: CESGRANRIO - 2012 - Chesf - Profissional de Nível Superior - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Dentre os atributos de um software de qualidade, incluem-se:

• A. controlabilidade, dependabilidade e eficiência
  
• B. controlabilidade, eficiência e manutenibilidade
  
• C. eficiência, imutabilidade e manutenibilidade
  
• D. eficiência, manutenibilidade e usabilidade
  
• E. imutabilidade, manutenibilidade e usabilidade
  

Gabarito: D

Comentários

• Conforme o artigo Software quality attributes and trade-offs, eficiência, manutenibilidade e usabilidade são atributos de qualidade nos modelos propostos pelos autores McCall (1977), Boehm (1978) e pela ISO 9126 (1993).
• D
  
  são atributos:
  confiabilidade - mantém o desempenho.
  usabilidade - simpático.
  eficiência - o nome ja diz tudo.

• Segundo a ISO 9126 sobre qualidade de software os atributos de qualidade são:

   

  Efigênio FU.MA PO.U.CO

   

  Como assim???????

   

  Eficiência

  Funcionalidade

  Manutenibilidade

  Portabilidade

  Usabilidade

  Confiabilidade

• O padrão ISO 9126 foi desenvolvido como uma alternativa de identificar os atributos de qualidade para software. O padrão indica seis atributos de qualidade:

  Usabilidade: é o grau de facilidade de utilização do software. Subatributos: facilidade de compreensão, facilidade de aprendizagem e operabilidade.

  Manutenção: é a facilidade com o qual uma correção pode ser realizada no software. Subatributos: facilidade de analise, facilidade de realização de mudanças, estabilidade e testabilidade.

  Confiabilidade: é a quantidade de tempo que o software fica disponível para uso. Subatributos: maturidade, tolerância a falhas e facilidade de recuperação.

  Eficiência: é o grau de otimização do uso dos recursos do sistema. Subatributos: comportamento em relação ao tempo e comportamento em relação aos recursos. 

  Portabilidade: é a facilidade com a qual o software pode ser transposto de um ambiente a outro. Subatributos: dataptabilidade, facilidade de instalação, conformidade e facilidade de substituição.

  Funcionalidade: é o grau com que o software satisfaz às necessidades declaradas. Subatributos: adequalidade, exatidão, interoperabilidade, conformidade e segurança.

  Alternativa: D

Questão 790972

• Banca: FCC
• Órgão: TST
• Ano: 2012
• Provas: FCC - 2012 - TST - Analista Judiciário - Análise de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Considere:


Riscos que afetam a qualidade ou o desempenho do software que está sendo desenvolvido, como por exemplo, a falha de um componente comprado para o desempenho esperado e que compromete o desempenho geral do sistema são considerados riscos de I . Outro exemplo de riscos dessa categoria é a II .

As lacunas I e II são preenchidas correta e respectivamente por

• A. análise e mudança de tecnologia.
• B. negócios e concorrência de produtos.
• C. projeto e alta rotatividade de pessoal.
• D. produto e mudança frequente de requisitos.
• E. desenvolvimento e indisponibilidade de hardware.

Gabarito: D

Comentários

• Sommerville(2011)

  "22.1 Risk management
  Risk management is one of the most important jobs for a project manager. Risk
  management involves anticipating risks that might affect the project schedule or the
  quality of the software being developed, and then taking action to avoid these risks
  Chapter 22  Project management
  (Hall, 1998; Ould, 1999). You can think of a risk as something that you’d prefer not
  to have happen. Risks may threaten the project, the software that is being developed,
  or the organization. There are, therefore, three related categories of risk:
  1. Project risks Risks that affect the project schedule or resources. An example of
  a project risk is the loss of an experienced designer. Finding a replacement
  designer with appropriate skills and experience may take a long time and, consequently,
  the software design will take longer to complete.
  2. Product risks Risks that affect the quality or performance of the software being
  developed. An example of a product risk is the failure of a purchased component
  to perform as expected. This may affect the overall performance of the system
  so that it is slower than expected.
  3. Business risks Risks that affect the organization developing or procuring the
  software. For example, a competitor introducing a new product is a business
  risk. The introduction of a competitive product may mean that the assumptions
  made about sales of existing software products may be unduly optimistic."
  
   
• Categorias dos riscos: 
  o Riscos relacionados ao projeto – afetam a programação/recursos do projeto; 
  o Riscos relacionados ao produto – afetam a qualidade ou o desempenho do software que está em desenvolvimento;  (a falha de um componente comprado para o desempenho esperado e que compromete o desempenho geral do sistema)
   
  o Riscos para os negócios – afetam a organização que está desenvolvendo ou adquirindo o software. 
  
  • Exemplos de ocorrências:
   
  o Decorrência de requisitos mal-definidos; 
  o Dificuldades de estimar prazos e custos; 
  o Dependência de habilidades individuais; 
  o Mudanças nos requisitos;
  
  Fonte:http://www.garcia.pro.br/EngenhariadeSW/ULBRA-ENGENHARIA-6%20-%20Projeto%20-%20parte%202.pdf
• Tem algo estranho nessa questão. Considerando os comentários do Paulo, trecho tirado do Sommervile, podemos classificar a falha de um componente como risco de produto e a mudança frequente de requisitos como risco de projeto. A alternativa (d) coloca na mesma classificação a falha de um produto e a mudança frequente de requisitos!
  Acho também que a tradução de failure para 'falha' é imprópria nesse caso e deixou a frase em português pouco clara.
• Somerviller 9º ed pag 416
  
  Riscos de Projeto. Riscos que afetam o cronograma ou os recursos de projeto. Um exemplo de um risco de projeto é a perda de um projetista experiente. Encontrar um Projetista Substituto com competência e experiência adequado pode demorar muito tempo e, por conseguinte, o projeto de software vai demorar mais tempo para ser concluído.
  
  Riscos de Produto. Riscos que afetam a qualidade ou o desempenho do software que está sendo desenvolvido. Um exemplo de um risco de produto é a falha de um componente comprado para o desempenho esperado, podendo afetar o desempenho do sistema de forma mais lenta que o esperado.
  
  Riscos de Negocio. Os riscos que afetem a organização que desenvolve ou adquire o software. Por exemplo, um concorrente que introduz um novo produto é um risco empresarial. A introdução de um produto competitivo pode significar que as suposições feitas sobre venda de produtos de software existentes podem ser excessivamente otimistas.

Questão 802969

• Banca: CESPE / CEBRASPE
• Órgão: INMETRO
• Ano: 2010
• Provas: CESPE - 2010 - INMETRO - Pesquisador Tecnologista - Metrologia em Informática
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Conforme o SWEBOK (corpo de conhecimentos da engenharia de software), os processos de garantia de qualidade de software provêem certeza de que o produto de software e seus processos do ciclo de vida do projeto estão conformes aos requisitos especificados, por meio do planejamento, apoio e desempenho de um conjunto de atividades que dão confiança adequada de que a qualidade está sendo construída no software. Com relação a esse assunto, assinale a opção correta acerca dos conceitos de qualidade no desenvolvimento de software, técnicas e estratégias de software.

• A. Em oposição às técnicas analíticas de gestão da qualidade de software, como análise de complexidade e uso de formalismos matemáticos, o teste de software é sempre uma atividade de verificação dinâmica do comportamento de um programa relativamente a um comportamento esperado.
  
• B. Consiste em uma atividade mais bem enquadrada sob o título de validação que sob o título de verificação a realização de uma consulta telefônica ao cliente de um projeto de software, efetuada por equipe de auditoria imediatamente após a implantação desse software, com o objetivo de fazer checagem cruzada do cumprimento de uma etapa formal de avaliação da qualidade na pré-implantação, a qual deveria obrigatoriamente ser feita pela empresa que desenvolveu o software para o cliente.
  
• C. Testes de caixa preta são usualmente fundamentados na análise do código de um programa. Por outro lado, entre as técnicas de teste não relacionadas a testes de caixa preta, estão aquelas embasadas na intuição do testador, em especificações comportamentais e no uso.
  
• D. Entre algumas considerações práticas para a introdução de uma equipe de testadores em uma organização, deve-se incentivar o aumento do ego entre os programadores cujos códigos serão testados.
  
• E. O planejamento, a geração de casos de teste, o relato de problemas e o rastreio de defeitos são algumas das atividades relacionadas ao gerenciamento do processo de testes. Dessas, o rastreio de defeitos é a que mais se aproxima do emprego de abstrações e ferramentas típicas empregadas por programadores.
  

Gabarito: A

Comentários

• b) ERRADO. Consiste em uma atividade mais bem enquadrada sob o título de  verificação validação que sob o título de  verificação...

  A verificação refere-se ao conjunto de atividades que garante que o software implemente corretamente uma função específica. A validação refere-se a um conjunto diferente de atividades que garante que o software que foi construído é rastreável às exigências do cliente.

  c) ERRADO. Testes de caixa preta são usualmente fundamentados na análise do código de um programa. Por outro lado, entre as técnicas de teste relacionadas a testes de caixa preta, estão aquelas embasadas na intuição do testador, em especificações comportamentais e no uso.

  d) ERRADO. Entre algumas considerações práticas para a introdução de uma equipe de testadores em uma organização, deve-se incentivar os programadores cujos códigos serão testados.

  e) ERRADO. O planejamento, a geração de casos de teste, o relato de problemas e o rastreio de defeitos são algumas das atividades relacionadas ao gerenciamento do processo de testes. Dessas, os casos de teste de defeitos é a que mais se aproxima do emprego de abstrações e ferramentas típicas empregadas por programadores.

   

Questão 804352

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

A respeito de engenharia de software, julgue o  item  a seguir.
[
Manutenibilidade, confiabilidade, desempenho e usabilidade estão entre os principais atributos de um produto de software.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• Modelo de Qualidade da Norma ISO 9126

  A norma 9126 se foca na qualidade do produto de software, propondo Atributos de Qualidade, distribuídos em seis características principais, conforme listado abaixo:

  Funcionalidade;

  Confiabilidade;

  Usabilidade;

  Manutenibilidade;

  Eficiência e

  Portabilidade

  https://pt.wikipedia.org/wiki/ISO/IEC_9126

Questão 804541

• Banca: CESPE / CEBRASPE
• Órgão: MEC
• Ano: 2011
• Provas: CESPE - 2011 - MEC - Analista de Sistemas
• Disciplina: Engenharia de Software
• Assuntos: Qualidade de Software

Tendo em vista que as características de qualidade do produto de software permitem identificar uma série de fatores de influenciam na avaliação de um produto de software, julgue o  item. 

A usabilidade representa a facilidade de utilizar o produto. Características como atratividade, compreensibilidade, eficiência de uso, facilidade de memorização e apreensibilidade, permitem orientar uma avaliação nesse contexto.

• C. Certo
• E. Errado

Gabarito: C

Comentários

• CORRETO

  Usabilidade. O grau de facilidade de utilização do software conforme indicado pelos seguintes subatributos: facilidade de compreensão, facilidade de aprendizagem, operabilidade;

  FONTE: PRESSMAN