Métricas de qualidade de software

As métricas de software podem ser classificadas em três categorias -

  • Product metrics - Descreve as características do produto, como tamanho, complexidade, recursos de design, desempenho e nível de qualidade.

  • Process metrics - Essas características podem ser utilizadas para melhorar as atividades de desenvolvimento e manutenção do software.

  • Project metrics- Esta métrica descreve as características e execução do projeto. Os exemplos incluem o número de desenvolvedores de software, o padrão de pessoal ao longo do ciclo de vida do software, custo, cronograma e produtividade.

Algumas métricas pertencem a várias categorias. Por exemplo, as métricas de qualidade em processo de um projeto são métricas de processo e métricas de projeto.

Software quality metricssão um subconjunto de métricas de software que se concentram nos aspectos de qualidade do produto, processo e projeto. Eles estão mais intimamente associados às métricas de processo e produto do que às métricas de projeto.

As métricas de qualidade de software podem ser divididas em três categorias -

  • Métricas de qualidade do produto
  • Métricas de qualidade em processo
  • Métricas de qualidade de manutenção

Métricas de qualidade do produto

Essas métricas incluem o seguinte -

  • Tempo Médio para Falha
  • Densidade de Defeito
  • Problemas do cliente
  • Satisfação do cliente

Tempo Médio para Falha

É o tempo entre as falhas. Essa métrica é usada principalmente com sistemas críticos de segurança, como sistemas de controle de tráfego de companhias aéreas, aviônicos e armas.

Densidade de Defeito

Ele mede os defeitos relativos ao tamanho do software expresso como linhas de código ou ponto de função, etc., ou seja, ele mede a qualidade do código por unidade. Essa métrica é usada em muitos sistemas de software comerciais.

Problemas do cliente

Ele mede os problemas que os clientes encontram ao usar o produto. Ele contém a perspectiva do cliente em relação ao espaço do problema do software, que inclui os problemas não orientados a defeitos juntamente com os problemas de defeito.

A métrica de problemas é geralmente expressa em termos de Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Onde,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

O PUM é geralmente calculado para cada mês após o lançamento do software no mercado e também para médias mensais por ano.

Satisfação do cliente

A satisfação do cliente é frequentemente medida por dados de pesquisa do cliente por meio da escala de cinco pontos -

  • Muito satisfeito
  • Satisfied
  • Neutral
  • Dissatisfied
  • Muito Insatisfeito

A satisfação com a qualidade geral do produto e suas dimensões específicas é geralmente obtida por meio de vários métodos de pesquisas com clientes. Com base nos dados da escala de cinco pontos, várias métricas com pequenas variações podem ser construídas e usadas, dependendo do propósito da análise. Por exemplo -

  • Porcentagem de clientes totalmente satisfeitos
  • Porcentagem de clientes satisfeitos
  • Porcentagem de clientes insatisfeitos
  • Porcentagem de clientes insatisfeitos

Normalmente, esse percentual de satisfação é usado.

Métricas de qualidade em processo

As métricas de qualidade em processo tratam do rastreamento da chegada de defeitos durante o teste formal da máquina para algumas organizações. Esta métrica inclui -

  • Densidade de defeito durante o teste da máquina
  • Padrão de chegada de defeito durante o teste da máquina
  • Padrão de remoção de defeito baseado em fase
  • Eficácia de remoção de defeitos

Densidade de defeito durante o teste da máquina

A taxa de defeitos durante o teste formal da máquina (teste após o código ser integrado à biblioteca do sistema) é correlacionada com a taxa de defeitos no campo. Taxas de defeitos mais altas encontradas durante o teste são um indicador de que o software experimentou uma injeção de erro maior durante seu processo de desenvolvimento, a menos que a taxa de defeitos de teste mais alta seja devido a um esforço de teste extraordinário.

Essa métrica simples de defeitos por KLOC ou ponto de função é um bom indicador de qualidade, enquanto o software ainda está sendo testado. É especialmente útil monitorar versões subsequentes de um produto na mesma organização de desenvolvimento.

Padrão de chegada de defeito durante o teste da máquina

A densidade geral do defeito durante o teste fornecerá apenas o resumo dos defeitos. O padrão de recebimento de defeitos fornece mais informações sobre os diferentes níveis de qualidade no campo. Inclui o seguinte -

  • As chegadas de defeitos ou defeitos relatados durante a fase de teste por intervalo de tempo (por exemplo, semana). Aqui, todos os quais não serão defeitos válidos.

  • O padrão de chegadas de defeitos válidos quando a determinação do problema é feita nos problemas relatados. Este é o verdadeiro padrão de defeito.

  • O padrão de atraso de defeitos ao longo do tempo. Essa métrica é necessária porque as organizações de desenvolvimento não podem investigar e corrigir todos os problemas relatados imediatamente. Esta é uma declaração de carga de trabalho, bem como uma declaração de qualidade. Se o backlog de defeitos for grande no final do ciclo de desenvolvimento e muitas correções ainda tiverem que ser integradas ao sistema, a estabilidade do sistema (daí sua qualidade) será afetada. Um novo teste (teste de regressão) é necessário para garantir que os níveis de qualidade do produto pretendidos sejam alcançados.

Padrão de remoção de defeito baseado em fase

Esta é uma extensão da métrica de densidade de defeito durante o teste. Além de testar, ele rastreia os defeitos em todas as fases do ciclo de desenvolvimento, incluindo as revisões de design, inspeções de código e verificações formais antes do teste.

Como uma grande porcentagem dos defeitos de programação está relacionada a problemas de design, a realização de revisões formais ou verificações funcionais para aprimorar a capacidade de remoção de defeitos do processo no front-end reduz os erros no software. O padrão de remoção de defeitos com base em fases reflete a capacidade geral de remoção de defeitos do processo de desenvolvimento.

Com relação às métricas para as fases de design e codificação, além das taxas de defeitos, muitas organizações de desenvolvimento usam métricas como cobertura de inspeção e esforço de inspeção para gerenciamento de qualidade em processo.

Eficácia de remoção de defeitos

Pode ser definido da seguinte forma -

$$ DRE = \ frac {Defeito \: removido \: durante \: a \: desenvolvimento \: fase} {Defeitos \: latente \: em \: o \: produto} \ vezes 100 \% $$

Essa métrica pode ser calculada para todo o processo de desenvolvimento, para o front-end antes da integração do código e para cada fase. É chamadoearly defect removal quando usado para o front-end e phase effectivenesspara fases específicas. Quanto maior o valor da métrica, mais eficaz é o processo de desenvolvimento e menos defeitos passam para a próxima fase ou para o campo. Essa métrica é um conceito-chave do modelo de remoção de defeitos para desenvolvimento de software.

Métricas de qualidade de manutenção

Embora muito não possa ser feito para alterar a qualidade do produto durante esta fase, a seguir estão as correções que podem ser realizadas para eliminar os defeitos o mais rápido possível com excelente qualidade de correção.

  • Corrigir backlog e índice de gerenciamento de backlog
  • Corrija o tempo de resposta e a capacidade de resposta
  • Porcentagem de correções inadimplentes
  • Qualidade fixa

Corrigir backlog e índice de gerenciamento de backlog

O backlog de correção está relacionado à taxa de recebimento de defeitos e à taxa em que as correções para problemas relatados se tornam disponíveis. É uma simples contagem de problemas relatados que permanecem no final de cada mês ou a cada semana. Utilizando-o no formato de um gráfico de tendência, essa métrica pode fornecer informações significativas para o gerenciamento do processo de manutenção.

O Backlog Management Index (BMI) é usado para gerenciar o backlog de problemas abertos e não resolvidos.

$$ BMI = \ frac {Número \: de \: problemas \: fechado \: durante \: o \: mês} {Número \: de \: problemas \: chegou \: durante \: o \: mês} \ vezes 100 \% $$

Se o IMC for maior que 100, significa que o acúmulo é reduzido. Se o IMC for inferior a 100, o acúmulo aumentou.

Corrija o tempo de resposta e a capacidade de resposta

A métrica do tempo de resposta do conserto é geralmente calculada como o tempo médio de todos os problemas da abertura ao fechamento. O curto tempo de resposta da correção leva à satisfação do cliente.

Os elementos importantes da capacidade de resposta do conserto são as expectativas do cliente, o tempo combinado para conserto e a capacidade de cumprir o compromisso com o cliente.

Porcentagem de correções inadimplentes

É calculado da seguinte forma -

$ Percent \: Delinquent \: Fixes = $

$ \ frac {Número \: de \: correções \: que \: excedeu \: a \: resposta \: tempo \: critérios \: por \: ceveridade \: nível} {Número \: de \: correções \: entregues \: em \: a \: especificado \: hora} \ vezes 100 \% $

Qualidade fixa

A qualidade do conserto ou o número de consertos defeituosos é outra métrica de qualidade importante para a fase de manutenção. Uma correção está com defeito se não corrigiu o problema relatado ou se corrigiu o problema original, mas injetou um novo defeito. Para software de missão crítica, as correções defeituosas são prejudiciais à satisfação do cliente. A métrica da porcentagem de correções com defeito é a porcentagem de todas as correções com defeito em um intervalo de tempo.

Uma correção defeituosa pode ser registrada de duas maneiras: Registre-a no mês em que foi descoberta ou registre-a no mês em que a correção foi entregue. O primeiro é uma medida do cliente; a segunda é uma medida de processo. A diferença entre as duas datas é o período latente da correção defeituosa.

Normalmente, quanto maior a latência, mais clientes serão afetados. Se o número de defeitos for grande, o pequeno valor da métrica percentual mostrará uma imagem otimista. A meta de qualidade para o processo de manutenção, é claro, é zero consertos defeituosos sem inadimplência.