Métricas de calidad del software

Las métricas de software se pueden clasificar en tres categorías:

  • Product metrics - Describe las características del producto tales como tamaño, complejidad, características de diseño, desempeño y nivel de calidad.

  • Process metrics - Estas características se pueden utilizar para mejorar las actividades de desarrollo y mantenimiento del software.

  • Project metrics- Esta métrica describe las características y ejecución del proyecto. Los ejemplos incluyen la cantidad de desarrolladores de software, el patrón de personal durante el ciclo de vida del software, el costo, el cronograma y la productividad.

Algunas métricas pertenecen a varias categorías. Por ejemplo, las métricas de calidad en proceso de un proyecto son métricas de proceso y métricas de proyecto.

Software quality metricsson un subconjunto de métricas de software que se centran en los aspectos de calidad del producto, proceso y proyecto. Estos están más estrechamente asociados con las métricas de procesos y productos que con las métricas del proyecto.

Las métricas de calidad del software se pueden dividir en tres categorías:

  • Métricas de calidad del producto
  • Métricas de calidad en proceso
  • Métricas de calidad de mantenimiento

Métricas de calidad del producto

Estas métricas incluyen lo siguiente:

  • Tiempo medio para fallar
  • Densidad de defectos
  • Problemas del cliente
  • La satisfacción del cliente

Tiempo medio para fallar

Es el tiempo entre fallos. Esta métrica se utiliza principalmente con sistemas críticos para la seguridad, como los sistemas de control de tráfico de las aerolíneas, aviónica y armas.

Densidad de defectos

Mide los defectos relativos al tamaño del software expresados ​​como líneas de código o punto de función, etc., es decir, mide la calidad del código por unidad. Esta métrica se utiliza en muchos sistemas de software comerciales.

Problemas del cliente

Mide los problemas que encuentran los clientes al utilizar el producto. Contiene la perspectiva del cliente hacia el espacio de problemas del software, que incluye los problemas no orientados a defectos junto con los problemas de defectos.

La métrica de problemas generalmente se expresa en términos 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

Dónde,

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

El PUM generalmente se calcula para cada mes después de que el software se lanza al mercado, y también para promedios mensuales por año.

La satisfacción del cliente

La satisfacción del cliente a menudo se mide mediante datos de encuestas de clientes a través de una escala de cinco puntos:

  • Muy Satisfecho
  • Satisfied
  • Neutral
  • Dissatisfied
  • Muy insatisfecho

La satisfacción con la calidad general del producto y sus dimensiones específicas generalmente se obtiene a través de varios métodos de encuestas a los clientes. Con base en los datos de la escala de cinco puntos, se pueden construir y utilizar varias métricas con ligeras variaciones, según el propósito del análisis. Por ejemplo

  • Porcentaje de clientes completamente satisfechos
  • Porcentaje de clientes satisfechos
  • Porcentaje de clientes insatisfechos
  • Porcentaje de clientes no satisfechos

Por lo general, se utiliza este porcentaje de satisfacción.

Métricas de calidad en proceso

Las métricas de calidad en proceso se ocupan del seguimiento de la llegada de defectos durante las pruebas formales de la máquina para algunas organizaciones. Esta métrica incluye:

  • Densidad de defectos durante la prueba de la máquina
  • Patrón de llegada de defectos durante la prueba de la máquina
  • Patrón de eliminación de defectos basado en fases
  • Efectividad de eliminación de defectos

Densidad de defectos durante la prueba de la máquina

La tasa de defectos durante la prueba formal de la máquina (prueba después de que el código se integre en la biblioteca del sistema) se correlaciona con la tasa de defectos en el campo. Las tasas de defectos más altas encontradas durante las pruebas son un indicador de que el software ha experimentado una mayor inyección de errores durante su proceso de desarrollo, a menos que la tasa de defectos de prueba más alta se deba a un esfuerzo de prueba extraordinario.

Esta simple métrica de defectos por KLOC o punto de función es un buen indicador de calidad, mientras que el software aún se está probando. Es especialmente útil monitorear lanzamientos posteriores de un producto en la misma organización de desarrollo.

Patrón de llegada de defectos durante la prueba de la máquina

La densidad general de defectos durante la prueba proporcionará solo el resumen de los defectos. El patrón de llegadas de defectos brinda más información sobre los diferentes niveles de calidad en el campo. Incluye lo siguiente:

  • Las llegadas de defectos o los defectos informados durante la fase de prueba por intervalo de tiempo (por ejemplo, semana). Aquí todos los cuales no serán defectos válidos.

  • El patrón de llegadas de defectos válidos cuando se realiza la determinación del problema en los problemas informados. Este es el verdadero patrón de defectos.

  • El patrón de horas extras de retraso acumulado por defectos. Esta métrica es necesaria porque las organizaciones de desarrollo no pueden investigar y solucionar todos los problemas informados de inmediato. Esta es una declaración de carga de trabajo y una declaración de calidad. Si la acumulación de defectos es grande al final del ciclo de desarrollo y aún no se han integrado muchas correcciones en el sistema, la estabilidad del sistema (de ahí su calidad) se verá afectada. Se necesita una nueva prueba (prueba de regresión) para garantizar que se alcancen los niveles de calidad del producto objetivo.

Patrón de eliminación de defectos basado en fases

Esta es una extensión de la métrica de densidad de defectos durante la prueba. Además de las pruebas, realiza un seguimiento de los defectos en todas las fases del ciclo de desarrollo, incluidas las revisiones de diseño, las inspecciones de código y las verificaciones formales antes de las pruebas.

Debido a que un gran porcentaje de los defectos de programación están relacionados con problemas de diseño, la realización de revisiones formales o verificaciones funcionales para mejorar la capacidad de eliminación de defectos del proceso en el front-end reduce los errores en el software. El patrón de eliminación de defectos basado en fases refleja la capacidad general de eliminación de defectos del proceso de desarrollo.

Con respecto a las métricas para las fases de diseño y codificación, además de las tasas de defectos, muchas organizaciones de desarrollo utilizan métricas como la cobertura de inspección y el esfuerzo de inspección para la gestión de la calidad en el proceso.

Efectividad de eliminación de defectos

Se puede definir de la siguiente manera:

$$ DRE = \ frac {Defecto \: eliminado \: durante \: una \: fase \: desarrollo \:} {Defectos \: latentes \: en \: el \: producto} \ veces 100 \% $$

Esta métrica se puede calcular para todo el proceso de desarrollo, para el front-end antes de la integración del código y para cada fase. Se llamaearly defect removal cuando se utiliza para el front-end y phase effectivenesspara fases específicas. Cuanto mayor sea el valor de la métrica, más eficaz será el proceso de desarrollo y menos defectos pasarán a la siguiente fase o al campo. Esta métrica es un concepto clave del modelo de eliminación de defectos para el desarrollo de software.

Métricas de calidad de mantenimiento

Aunque no se puede hacer mucho para alterar la calidad del producto durante esta fase, a continuación se detallan las correcciones que se pueden realizar para eliminar los defectos lo antes posible con una excelente calidad de reparación.

  • Corregir el índice de gestión de trabajos pendientes y atrasos
  • Arregle el tiempo de respuesta y corrija la capacidad de respuesta
  • Porcentaje de correcciones morosas
  • Calidad fija

Corregir el índice de gestión de trabajos pendientes y atrasos

La acumulación de arreglos está relacionada con la tasa de llegadas de defectos y la velocidad a la que están disponibles las correcciones para los problemas notificados. Es un simple recuento de los problemas notificados que quedan al final de cada mes o cada semana. Utilizándolo en el formato de un gráfico de tendencias, esta métrica puede proporcionar información significativa para administrar el proceso de mantenimiento.

El índice de gestión de la acumulación (BMI) se utiliza para gestionar la acumulación de problemas abiertos y no resueltos.

$$ BMI = \ frac {Número \: de \: problemas \: cerrados \: durante \: el \: mes} {Número \: de \: problemas \: llegaron \: durante \: el \: mes} \ veces 100 \% $$

Si el IMC es superior a 100, significa que se reduce la acumulación. Si el IMC es menor a 100, entonces el atraso aumenta.

Arregle el tiempo de respuesta y corrija la capacidad de respuesta

La métrica del tiempo de respuesta fijo se calcula generalmente como el tiempo medio de todos los problemas desde la apertura hasta el cierre. Un tiempo de respuesta corto conduce a la satisfacción del cliente.

Los elementos importantes de la capacidad de respuesta del arreglo son las expectativas del cliente, el tiempo acordado para fijar y la capacidad de cumplir con el compromiso de uno con el cliente.

Porcentaje de correcciones morosas

Se calcula de la siguiente manera:

$ Porcentaje \: En mora \: Correcciones = $

$ \ frac {Número \: de \: arreglos \: que \: excedieron \: el \: criterio \: tiempo \: de \: respuesta \: por \: ceveridad \: nivel} {Número \: de \: arreglos \: entregados \: en \: a \: especificado \: tiempo} \ veces 100 \% $

Calidad fija

La calidad de las reparaciones o el número de reparaciones defectuosas es otra métrica de calidad importante para la fase de mantenimiento. Una solución es defectuosa si no solucionó el problema informado o si solucionó el problema original pero inyectó un nuevo defecto. Para el software de misión crítica, las reparaciones defectuosas son perjudiciales para la satisfacción del cliente. La métrica del porcentaje de arreglos defectuosos es el porcentaje de todos los arreglos en un intervalo de tiempo que es defectuoso.

Una reparación defectuosa se puede registrar de dos formas: regístrela en el mes en que se descubrió o regístrela en el mes en que se entregó la reparación. La primera es una medida del cliente; el segundo es una medida de proceso. La diferencia entre las dos fechas es el período de latencia del arreglo defectuoso.

Por lo general, cuanto mayor sea la latencia, más clientes se verán afectados. Si el número de defectos es grande, entonces el valor pequeño de la métrica de porcentaje mostrará una imagen optimista. El objetivo de calidad para el proceso de mantenimiento, por supuesto, es cero reparaciones defectuosas sin morosidad.