10 Métricas de Calidad del Software para Mejorar la Eficiencia

Se espera que para el 2027, el mercado del software sea de 800 mil millones de dólares (Statista, 2023¹). Pero, aunque la industria sigue creciendo de manera constante año tras año, no todos los actores del mercado prosperarán.

Hay varias razones, pero en este artículo nos centraremos en la calidad del software y cómo medirla de forma objetiva y con propósito.

⏱ Tiempo de lectura: 12 minutos.

¿Qué encontrarás en este artículo?

• La importancia de medir la calidad el software
• ¿Qué son las métricas de calidad del software?
• Diez métricas de calidad del software que debes conocer
• La principal estrategia para mejorar las métricas de calidad del software
• Logra la certificación CMMI Development en tu empresa

La importancia de medir la calidad del software

Como ocurre con otros productos del mercado, el software puede ser “excelente”, “bueno”, “no tan bueno” o inclusive “pésimo”.

Son tus clientes los que tendrán la última palabra, pero tú eres responsable de lo que vendes. Por esa razón, para directores y gerentes de desarrollo es vital monitorear la calidad en el desarrollo de software que tu empresa produce.

¿El objetivo? Reducir las probabilidades de entregar productos de baja calidad a tus clientes.

Las métricas de calidad del software te ayudarán a determinar si tu equipo de desarrollo está encaminado o no a crear software de mejor manera en cada sprint y proyecto.

Bien diseñadas y aplicadas, te darán mucha información útil para tomar decisiones más informadas con relación a cómo mejorar el desempeño de tu equipo, de los proyectos e incluso del negocio.

Las métricas que aquí te presento, son claves para lograr niveles óptimos de calidad del software acorde al modelo CMMI Development. Revisaremos juntos los datos que conforman cada métrica y te recomendaré soluciones para ayudarte a comprender y mejorar esas cifras.

A lo largo de este artículo te mostraré también cómo es que el seguimiento del tiempo te va a llevar a mejores niveles de calidad de software.

¿Qué son las métricas de calidad del software?

Las métricas de calidad del software son criterios y medidas utilizadas para evaluar qué tan bien se desarrolla una solución de software por un grupo. Son una brújula que te ayuda a entender la eficiencia, confiabilidad y rendimiento del software, asegurando que cumpla con los estándares y requisitos establecidos.

Lo más importante de las métricas es que cuantifican aspectos de la calidad del software que muchas veces pueden parecer difíciles de evaluar por ser hasta cierto punto abstractos.

Quizás puedes pensar en evaluar la calidad del código fuente de tu equipo solicitando a un revisor de código que te de su opinión sobre la legibilidad, la consistencia… ¿o deberías de tomar en cuenta si tiene comentarios útiles para comprender el código? En todo esto siempre habrá un elemento de subjetividad, más aún si la revisión de código es realizada por un miembro del equipo, incluso siendo desarrolladores senior o arquitectos de software muy experimentados.

Afortunadamente, hay aspectos observables y medibles con los que evaluar la calidad con métricas objetivas, eliminando las conclusiones sesgadas y la incertidumbre de la evaluación de la calidad del software.

Además, existen diferentes tipos de métricas de calidad del software, y cada tipo aborda distintas dimensiones de esta calidad. Por ejemplo, algunas métricas te permiten sacar conclusiones sobre qué tan bueno es el código fuente y qué tan bien diseñada está la interfaz de usuario, mientras que otras miden la efectividad del proceso de prueba de software.

Después de todo, el ciclo de vida del desarrollo de software incluye diferentes etapas, roles y actividades, cada una con sus preocupaciones. Pero en conjunto, las etapas, roles, actividades y métricas impulsan el software de alta calidad.

Diez métricas de calidad del software que debes conocer

1. Rotación total de códigos
2. Tasa de fallas
3. Disponibilidad del sistema
4. Densidad de defectos
5. Tiempo medio de detección (MTTD)
6. Tiempo medio entre fallas (MTBF)
7. Tiempo medio de resolución (MTTR)
8. Satisfacción del cliente (CSAT)
9. Tiempo medio para remediar una vulnerabilidad
10. Cobertura de código

1. Rotación total de códigos

Es la cantidad de líneas de código agregadas, modificadas o eliminadas de una base de código durante un período de tiempo.

Aunque desarrollar y mantener software consiste en cambiar una base de código varias veces, hacerlo con demasiada frecuencia puede indicar problemas de calidad. Esto se debe a que, como regla general, cuantos más cambios, mayor será la probabilidad de introducir errores en los productos.

No mide la calidad per se, pero la alta rotación podría correlacionarse con otros problemas de métricas de calidad.

Los arquitectos y programadores de software estructuran los sistemas modernos en módulos, y cada módulo depende de otros para funcionar. Pero luego, al codificar, un error en un módulo podría terminar en la falla de otro módulo.

Además, demasiadas líneas de código nuevas pueden indicar que se encuentra en las primeras etapas de codificación. Pero también podrían indicar que no estás reutilizando código, lo que afecta el rendimiento del software. Por ejemplo, no reutilizar el código puede llevar más tiempo a los productos cargar los recursos que necesitan para funcionar correctamente.

Por último, pero no menos importante, una vez que lanzas el software, una alta rotación de código podría indicar una arquitectura propensa a errores que necesita refactorización. Por ejemplo, la arquitectura puede resultar difícil de probar o escalar.

Esta métrica está formada por los siguientes datos:

• Líneas de código agregadas = lc_a
• Líneas de código modificadas = lc_m
• Líneas de código eliminadas = lc_e
• Periodo de tiempo de la medición (por lo general por Sprint) = t

Ejemplo: 10,000 líneas de código en tres sprints.

2. Tasa de fallas

La tasa de fallas es la frecuencia con la que falla un producto de software.

Y cuando eso sucede, los usuarios finales simplemente no pueden operar el producto en absoluto.

Los fallos son errores inesperados, como un defecto que los testers no detectaron o una sobrecarga repentina del sistema. Ocurren mientras el software se está ejecutando y finalizan su ejecución abruptamente. A veces, los datos se pierden en el proceso.

Las empresas de sistemas críticos, como las que desarrollan sistemas de control de tráfico aéreo o sistemas de bolsa, se centran mucho en esta métrica.

Una tasa de fallos alta es una señal de alerta de errores en el producto (normalmente graves). Y los problemas de calidad subyacentes pueden variar desde una garantía de calidad insuficiente hasta una validación deficiente del usuario.

En otras palabras, la tasa de fallas no indica exactamente qué debe hacer para reducir el número. En su lugar, debe investigar la causa raíz exacta de los bloqueos.

Pero, si se introduce un código que provoca fallas en la producción, eso significa que está pasando por alto cualquier proceso de control de calidad o prueba unitaria que tenga implementado. Eso es un problema.

La mayoría de los problemas con el control de calidad se deben las siguientes debilidades:

1. Lanzamientos apresurados: no hay tiempo suficiente para realizar un control de calidad adecuado antes de la fase de despliegue.
2. Recursos limitados: no hay suficientes horas/ojos para realizar un control de calidad adecuado.
3. Proceso de control de calidad inadecuado: avería en el proceso real y aprobación del código por parte de pruebas.

Si tienes esta última debilidad, deberás profundizar en el flujo de trabajo general de control de calidad. Puede haber problemas de comunicación o las pautas de control de calidad pueden estar desactualizadas y no reflejar el estado actual del software.

Si se trata de recursos o planificación, es posible que desees revisar cómo tu equipo analiza y se compromete a trabajar.

• ¿Cómo está actualmente analizando y planificando sus historias de usuario, casos de uso o requisitos de producto?
• ¿Cómo se calculan los plazos y el esfuerzo de trabajo?

No lo improvises.

Cuando sea posible, asegúrate de integrar datos históricos como registros de seguimiento del tiempo de proyectos similares, historias de usuarios o elementos de trabajo, puede ayudar a tu equipo a comprender mejor lo que están “mordiendo” y que pueden “masticarlo” adecuadamente.

De esta manera puedes prevenir que tu proyecto no se vea afectado por un proceso de control de calidad inadecuado.

Retrocediendo un paso más, es posible que desees considerar cuál equipo (o quién) es responsable de introducir el código que está causando la tasa de fallas. ¿Es un problema repetido?

Aunque el problema debe identificarse en el control de calidad, también se puede solucionar entendiendo cómo y por qué se introdujo el problema durante el proceso de desarrollo.

Esta métrica está formada por los siguientes datos:

• Número de fallas = N_f
• Periodo de tiempo de la medición (por lo general es por días) = t

Ejemplo: una caída del sistema por cada 30 días.

3. Disponibilidad del sistema

Evalúa la cantidad de tiempo que un sistema está en funcionamiento. Compara el tiempo de actividad del sistema con su tiempo de inactividad durante un período de tiempo. Y considera que un sistema que está disponible es tan rápido como se espera y no falla a menos que ocurran condiciones imprevistas.

Otra forma de decirlo: la disponibilidad del sistema es la probabilidad de que un producto de software no deje de estar disponible cuando los usuarios lo necesiten.

Una alta disponibilidad significa más tiempo de actividad que de inactividad, lo que significa que los usuarios rara vez pierden el acceso al sistema. En ese caso, el producto lanzado no contiene errores o solo algunos de ellos, lo que requiere pocas correcciones en su código base.

La disponibilidad del sistema es una métrica de calidad esencial para las empresas de desarrollo de software que crean productos que deben funcionar las 24 horas del día.

Esta métrica está formada por los siguientes datos:

• Tiempo de actividad (medido en horas) = T_a
• Tiempo de inactividad (medido en horas) = T_i

Ejemplo: un producto de software que está activo nueve horas de cada diez tiene una disponibilidad del sistema del 90 %.

4. Densidad de defectos

Es la cantidad de defectos en un producto de software en comparación con su tamaño. Esto significa que es un número relativo.

Los defectos son errores encontrados por los evaluadores antes del lanzamiento del producto. Representan necesidades de usuario insatisfechas. Y si los evaluadores no los detectan a tiempo, los defectos originan fallas en manos de los usuarios finales.

Esta métrica mide la calidad del código y le brinda información para estimación de los esfuerzos de corrección del software. Un código de alta calidad requiere pocas correcciones y es más fácil de mantener, escalar y evolucionar.

¿Quieres sacarle provecho a esta métrica? Entonces no olvides ofrecer a los miembros de tu equipo la oportunidad de aprender de los defectos que codificaron o no detectaron durante las pruebas. Así es como mejorarán continuamente su código y sus prácticas de prueba, y terminarán mejorando sus resultados.

Esta métrica a menudo se expresa como la cantidad de defectos por cada 1000 líneas de código y está formada por los siguientes datos:

• Número de defectos = N_d
• Número total de líneas de código = N_c

Ejemplo: Diez defectos en un total de 20,000 líneas de código equivalen a una densidad de defectos de 0,5 por 1,000 líneas de código.

5. Tiempo medio de detección (MTTD)

Es el tiempo promedio que le toma a tu equipo detectar errores en un producto de software.

Un MTTD bajo indica que, normalmente, su equipo encuentra errores rápidamente. Y cuanto más rápido los encuentren, más rápido corregirán esos errores. Como resultado, el sistema no está inactivo por mantenimiento durante demasiado tiempo, lo que minimiza el impacto de los defectos o fallas en los usuarios finales.

Por otro lado, un MTTD alto significa que tu equipo debe dedicar más tiempo a actividades de control de calidad. También significa que es necesario asignar más recursos a la etapa de mantenimiento del producto.

Aunque los procesos de descubrimiento de defectos y gestión de tickets influyen en el MTTD de un producto, la calidad del código tiene el mismo impacto. He aquí por qué: un código bien estructurado es más fácil de navegar y depurar, que es el paso número uno para corregir un error.

Pide a los miembros de tu equipo que recopilen datos sobre todos los errores, como el día y la hora en que ocurrieron y cuándo alguien los informó. Además, si puedes implementar un sistema de seguimiento del tiempo para que los miembros de tu equipo registren lo que tardaron en corregir los errores, te va a ayudar muchísimo, tanto que lograrás niveles de Six Sigma de calidad en tus productos.

Este indicador está formado por los siguientes datos:

• Tiempo total para detectar todos los errores durante un período de tiempo = T_d
• Número total de errores = N_e
• Tiempo para detectar un error = T_d1
• Día y hora en que se detectó = D_d
• Día y hora en que ocurrió = D_o

Ejemplo: en agosto de 2023, una aplicación produjo 20 errores con un tiempo total de detección de 1000 minutos, lo que equivale a un MTTD de 50 minutos.

6. Tiempo medio entre fallas (MTBF)

Es el tiempo promedio entre dos fallas del sistema. Se trata de errores que se encuentran tras el lanzamiento del producto y que se deben, por ejemplo, a un defecto no detectado.

Las fallas pueden ser tan graves como un bloqueo, pero también pueden deberse a que el software no hace lo que los usuarios finales esperan que haga.

Por supuesto, cuanto mayor sea el MTBF, mejor. Significa que el producto es más fiable, lo cual es esencial en industrias como la sanitaria y la aeronáutica.

Abordar una tasa MTBF problemática puede ser un poco más complejo.

La primera pregunta que debes hacerte es si has visto un aumento (en realidad, una disminución del tiempo) en el MTBF, debes analizar dos aspectos:

Es posible que se haya introducido un único punto de falla en una versión reciente, lo que provocó un aumento en la frecuencia de fallas y una disminución en el MTBF. O tal vez no se introdujo nada nuevo, pero un cambio en el comportamiento del usuario expuso un problema anterior que ahora está creando más casos de falla.

Si se trata de cualquiera de estos dos problemas, es de esperar que sea un escenario contenido que pueda abordarse mediante un flujo de trabajo normal de prueba y corrección de errores.

Quizás el escenario más siniestro es que tu MTBF esté empeorando porque el equipo de desarrollo está introduciendo una mayor cantidad de problemas que luego causan una mayor cantidad de fallas.

Esto significa que quizás haya un problema más sistémico que abordar.

Como te comenté al analizar los problemas con la tasa de fallas, si hay un aumento en la cantidad de problemas o errores que se introducen en el código en vivo, generalmente se debe a una falla en el flujo de trabajo del equipo.

En muchos casos, es producto de una mala planificación (historias de usuario sin alcance adecuado, el trabajo se apresura, el control de calidad sólo tiene 2 horas para realizar la prueba).

Este es el momento de abordar el proceso en sí. Analiza cómo tu equipo está creando estimaciones de trabajo y qué salvaguardas puede implementar para evitar un alcance excesivo que genere problemas en cascada con el control de calidad y la calidad del software.

Este indicador está formado por los siguientes datos:

• Tiempo total de ejecución medido en horas= T_e
• Número total de fallas = N_f

Ejemplo: un software que se ha estado ejecutando durante 3000 horas y ha fallado 15 veces tiene un MTBF de 200 horas, lo que significa que falla en promedio una vez cada 200 horas.

7. Tiempo medio de resolución (MTTR)

Es el tiempo promedio que le toma a tu equipo resolver un error en un producto de software después de que alguien lo descubre.

Esto se calcula como la cantidad de horas o minutos que transcurren entre que se detecta el problema y se resuelve. Generalmente, sólo se cuentan los minutos u horas que caen dentro del horario laboral normal (es decir, no contaría el tiempo transcurrido en las noches o los fines de semana).

Regularmente, un MTTR bajo significa que tu equipo repara los errores rápidamente.

Pero, por supuesto, depende de la gravedad del error y de la experiencia de tus desarrolladores.

Los errores menores tienden a tardar mucho menos en resolverse que los críticos. Y los programadores senior, así como los arquitectos de software, tienden a tardar menos tiempo en resolver un error.

Para abordar los problemas con MTTR, asegúrate de que tu equipo dedica suficiente tiempo a estructurar su código base de acuerdo con las mejores prácticas de la industria. Continúa perfeccionando tus pautas y documentación de codificación interna.

Considera también implementar nuevos procesos o sistemas para diagnosticar más rápidamente los problemas y poder resolverlos más rápidamente.

Este indicador está formado por los siguientes datos:

• Tiempo total desde el descubrimiento hasta la resolución en minutos = T_d
• Número total de reparaciones = N_r

Ejemplo: si transcurrieron 2,880 minutos en total entre el descubrimiento y la resolución de 96 errores en un producto durante los últimos tres meses, entonces el MTTR de ese producto es de 30 minutos para el trimestre.

8. Satisfacción del cliente (CSAT)

Es un número que representa la forma en que los clientes experimentan tu producto de software. Y se llega a ello recopilando y analizando los datos de las encuestas de satisfacción de tus clientes sobre el funcionamiento del software. No se incluyen datos sobre la calidad del servicio como por ejemplo el soporte en tu mesa de ayuda.

Por lo general, una pregunta en esas encuestas es sobre la satisfacción general de los clientes con tu producto. Te recomiendo que den una respuesta en una escala de cinco puntos, desde “extremadamente satisfecho” hasta “extremadamente insatisfecho”.

Esta métrica de calidad te brindará la percepción de los usuarios sobre la calidad general de tu producto. Cuanto mayor sea el CSAT, mejor será esa percepción de calidad.

Este indicador está formado por los siguientes datos:

• Número total de clientes satisfechos = C_s  , siendo los clientes satisfechos aquellos que calificaron su satisfacción como “extremadamente satisfecho” y “satisfecho”.
• Número total de respuestas a la encuesta de clientes = N_r

Ejemplo: si 53 de 100 clientes calificaron su satisfacción como "extremadamente satisfecho" y "satisfecho", entonces el CSAT de su producto es 53% o solo 53.

9. Tiempo medio para remediar una vulnerabilidad

Es el tiempo promedio que le toma a tu equipo reparar las vulnerabilidades de ciberseguridad en tu producto de software.

La causa principal de esas vulnerabilidades suele ser el código de baja calidad. Y un número bajo significa que los usuarios finales están menos expuestos a posibles violaciones de datos, pérdidas financieras e interrupciones repentinas del servicio.

De manera similar al MTTR, el tiempo medio para remediar una vulnerabilidad depende de qué tan bien tu equipo implemente las mejores prácticas de codificación. Pero en este caso, las mejores prácticas que siempre deben monitorear, incluso después del lanzamiento del producto, son las de ciberseguridad.

Este indicador está formado por los siguientes datos:

• Tiempo total entre el descubrimiento y la corrección de vulnerabilidades = T_t
• Número total de vulnerabilidades = N_v
• Periodo de tiempo = t  , generalmente en días.

Ejemplo: si un equipo de desarrollo pasó 20 horas reparando dos vulnerabilidades en un producto el último trimestre, entonces el tiempo medio del producto para remediar una vulnerabilidad es de 10 horas por trimestre.

10. Cobertura del código

Evalúa la cantidad de código fuente de tu producto para el cual existe una prueba unitaria.

Se trata de pruebas realizadas por programadores en el entorno de desarrollo que utilizaron para crear el producto. Y el objetivo es encontrar errores en el código base lo antes posible y evitar fallas del sistema en el futuro.

Para ello, los programadores deben cubrir cada línea de código con una prueba unitaria. Por ejemplo, las pruebas unitarias deben cubrir todas las condiciones de los casos de uso del producto.

Y si la cobertura del código de tu producto es alta y todas las pruebas unitarias pasaron, la calidad del código se considera alta. Eso se traduce en software de alta calidad.

Este indicador está formado por los siguientes datos:

• Número de líneas de código probadas = L_p
• Número total de líneas de código en el código base = L_t

Ejemplo: si una base de código tiene 10 000 líneas de código y las pruebas unitarias cubren 9500 de esas líneas, entonces su producto tiene una cobertura de código del 95%.

La principal estrategia para mejorar las métricas de calidad del desarrollo de software

Nadie dijo que priorizar la calidad del software y cumplir con los plazos sea fácil. Pero a menudo la mala planificación del tiempo es la razón detrás de los problemas de calidad, lo que obliga a los equipos de desarrollo a acelerar los lanzamientos de productos y acortar el control de calidad.

Como puedes haber notado, el seguimiento del tiempo puede conducir a cada vez mejores métricas de calidad. ¿Por qué? Llevar un control del tiempo invertido en el desarrollo, las correcciones, pruebas y demás actividades mejora las estimaciones de tiempo y presupuesto, permitiéndote planificar próximos proyectos con mayor precisión.

Recuerda que este tipo de datos y estrategias de calidad en software son derivadas del modelo CMMI Development. Si el tema te interesa te invito a que consultes también estas entradas de nuestro blog:

• 20 Mejores Prácticas de Desarrollo de Software
• CMMI y Agile: Dos Enfoques Complementarios
• Cómo Realizar una Buena Especificación de Requisitos de Software

Para cerrar, parafraseo aquí a Larry Ellison, fundador y CEO de Oracle: “el mejor momento para comenzar a monitorear y mejorar las métricas de calidad del desarrollo de software fue hace años. El segundo mejor momento es ahora”.

 Fuentes

¹ Statista: Revenue of the software market worldwide from 2016 to 2027, by segment