Tipos de Métricas de Software

Métricas para qualidade de especificação

De acordo com Pressman e Maxim (2016, p. 663), há uma lista de características que podem ser usadas para avaliar a qualidade do modelo de requisitos e as especificações de requisitos correspondentes, como: não ambiguidade, totalidade, exatidão, compreensibilidade, consistência interna e externa, disponibilidade, rastreabilidade, modificabilidade, entre outras. Cada uma delas pode ser representada usando uma ou mais métricas.

Suponha que há Nr requisitos em uma especificação, entre os quais há Nf requisitos funcionais e Nnf requisitos não funcionais, tal que:

Nr = Nf + Nnf

Para se determinar a não ambiguidade dos requisitos, pode ser utilizada uma métrica com base na interpretação de cada requisito pelos revisores. Se Nii representa o número de requisitos para os quais todos os revisores tiveram a mesma interpretação (ii = interpretação idêntica), temos:

Q1 = Nii / Nr

Quanto mais próximo de 1 for Q1, menos ambiguidades haverá na especificação dos requisitos.

Considerando que Nfu representa o número de requisitos funcionais únicos, Ne representa o número de entradas definidas pela especificação e Ns o número de estados especificados, a métrica da totalidade dos requisitos funcionais Q2 pode ser obtida por:

Q2 = Nfu / (Ne x Ns)

Métrica Eficiência na Remoção de Defeitos ou Defect Removal Efficiency (DRE)

A métrica Eficiência na Remoção de Defeitos ou Defect Removal Efficiency (DRE), de acordo com Pressman e Maxim (2016, p. 718), “é uma medida da capacidade de filtragem das ações de garantia de qualidade e controle quando são aplicadas em todas as atividades da estruturas de processo”.

Sendo Ea= número de erros encontrados antes que o software seja entregue ao usuário final e Dd= número de defeitos encontrados depois que o software foi entregue ao usuário final, o DRE pode ser assim definido:

O valor ideal para DRE é 1, ou seja, nenhum defeito é encontrado no software. Mas de forma mais realista, Dd será maior que 0. À medida que Ea aumenta é provável que o valor final de Dd diminua (erros são removidos antes de se tornarem defeitos) e o valor global de DRE comece a se aproximar de 1.

Um dos objetivos desta métrica é incentivar a equipe de desenvolvedores a incorporar técnicas para que seja encontrado o maior número de erros possível antes da entrega do software.

Métricas orientadas a Casos de Uso ou Use Cases (UCs)

Os casos de uso ou Use Cases (UCs) são amplamente utilizados como método para descrever requisitos no nível dos clientes ou no domínio do negócio. De acordo com Pressman e Maxim (2016, p. 714), os UCs são definidos no início do processo de software, permitindo que sejam usados para estimativas antes de iniciar atividades de modelagem e construção.

O UC é independente da linguagem de programação e sua quantidade é diretamente proporcional ao tamanho do software em LOC e à quantidade de casos de teste que terão de ser projetados para exercitar o software.