23 métricas de desarrollo de software que monitorear hoy

Métricas de productividad del desarrollador

Existen muchas formas de discutir o evaluar la eficiencia del equipo y el trabajo completado. Las métricas de productividad permiten a los gerentes de desarrollo ejecutar mejor los proyectos. Tabule una combinación de estas métricas de software para medir qué tan avanzado está un proyecto, los niveles de productividad del desarrollador, la cantidad de tiempo de desarrollo adicional necesario y más.

1. Tiempo de entrega (lead time). El tiempo de entrega es el tiempo que tarda algo de principio a fin. En el desarrollo de software, por ejemplo, el tiempo de entrega de un proyecto comienza con la propuesta y termina con la entrega.
2. Cantidad de código. Los equipos de desarrollo pueden mirar esta métrica de software, también llamada miles de líneas de código (KLOC), para determinar el tamaño de una aplicación. Si este KPI es alto, podría indicar que los desarrolladores fueron productivos en sus esfuerzos de programación. Sin embargo, esta métrica no es útil cuando un equipo de desarrollo intenta comparar dos proyectos escritos en diferentes lenguajes de programación. Además, tenga en cuenta que más código no siempre hace que el código sea eficiente o efectivo, lo que puede significar más trabajo de refactorización más adelante.
3. Trabajo en curso (WIP). En un contexto de ingeniería de software, WIP es un trabajo de desarrollo en el que el equipo ha comenzado a trabajar y que ya no está en el backlog. Un equipo puede expresar WIP en un gráfico de quemado. Una herramienta común para los sprints ágiles y Scrum, estos gráficos muestran cuánto trabajo ha terminado el equipo y la cantidad de trabajo que queda por hacer.
4. Velocidad ágil. Para calcular la velocidad, un equipo de desarrollo de software ágil analiza los sprints anteriores y cuenta el número de historias de usuario o puntos de historia completados a lo largo del tiempo. La velocidad ágil es una estimación de qué tan productivo será el equipo en un solo sprint.
5. Tasa de éxito de la meta del sprint. Esta métrica de software calcula el porcentaje de elementos que completó el equipo de desarrollo en el backlog del sprint. Es posible que un equipo no termine el 100 % del trabajo durante un sprint determinado. Sin embargo, el progreso del equipo aún podría cumplir con su definición de terminado: el umbral que debe alcanzar un proyecto para que una organización lo considere terminado. Si la iteración cumple con la definición de hecho, es un éxito.
6. Número de versiones de software. Los equipos ágiles y de DevOps dan prioridad a los lanzamientos de software continuos y frecuentes. Con este KPI, los equipos pueden realizar un seguimiento de la frecuencia con la que lanzan software, ya sea mensual, semanal, diaria, por hora o en cualquier otro período de tiempo, y si esa cadencia finalmente ofrece suficiente valor comercial.

Métricas de rendimiento del software

El rendimiento del software se refiere a medidas cuantitativas del comportamiento de un sistema de software. Las métricas de rendimiento miden los atributos no funcionales, es decir, cómo se desempeña una aplicación, no lo que realiza.

7. Aspectos del desempeño del software. Las pruebas de rendimiento pueden evaluar las siguientes características de una aplicación:

• Escalabilidad
• estabilidad
• capacidad de respuesta
• velocidad
• disponibilidad

Otras expresiones importantes de métricas de rendimiento del software incluyen las siguientes.

8. Rendimiento (throughput). El rendimiento es la cantidad de unidades de datos que procesa un sistema en un cierto período de tiempo.
9. Tiempo de respuesta. El tiempo de respuesta mide cuánto tiempo tarda un sistema en responder a una consulta o demanda.
10. Fiabilidad, disponibilidad y capacidad de servicio (RAS). RAS se refiere a la capacidad del software para cumplir constantemente con sus especificaciones; cuánto tiempo funciona en relación con la cantidad esperada; y con qué facilidad se puede reparar o mantener.

Métricas de defectos

Los equipos de desarrollo deben comprender cómo fallan las aplicaciones para poder construirlas mejor. Estas métricas de desarrollo de software evalúan defectos y vulnerabilidades.

11. Densidad de defectos. A nivel de código, los desarrolladores pueden tabular el número de defectos por KLOC para evaluar la frecuencia de los defectos.
12. Cobertura de código. Esta es la proporción de código fuente que cubren las pruebas automatizadas. La métrica del software permite a los probadores identificar qué áreas del código aún tienen que probar correctamente.
13. Porcentaje de detección de defectos. Esta métrica es una proporción de la cantidad de defectos encontrados antes de los lanzamientos de software en comparación con el número encontrado después del lanzamiento. Para calcular el porcentaje, tome el número de defectos encontrados antes del lanzamiento (x) y la cantidad que encontraron los usuarios después del lanzamiento (y), y luego calcule x/(x + y). Es preferible un alto porcentaje, ya que eso significa que se encontró una mayor proporción de defectos antes de que los clientes usaran el software.
14. Deuda técnica. La deuda técnica es una metáfora que refleja el esfuerzo a largo plazo, así como los costos temporales y financieros, de los desarrolladores que no abordan un problema de desarrollo cuando surge por primera vez.

16. Vulnerabilidades de seguridad. Los análisis de vulnerabilidades identifican las debilidades de seguridad en una aplicación. Cuanto menor sea el número de vulnerabilidades encontradas, más seguro será el software.
17. Incidentes de seguridad reales. Este KPI cuenta la cantidad de veces que un hacker aprovecha una vulnerabilidad en el software. Realice un seguimiento de la frecuencia con la que ocurren estas infracciones, la gravedad del ataque (por ejemplo, qué datos se robaron) y la cantidad de tiempo que duró el incidente.

Las organizaciones de TI utilizan varios promedios para calcular la ocurrencia de fallas o defectos de software.

18. Tiempo medio de detección. El tiempo medio de detección es un promedio que indica cuánto tiempo tarda un equipo en notar un problema o error.
19. Tiempo medio entre fallos. Esta métrica es un cálculo de qué tan común es que un programa falle.
20. Tiempo medio de reparación. El tiempo medio de reparación es el promedio que representa la rapidez con que un equipo aborda las fallas.

Métricas de usabilidad y UX

Los usuarios experimentan e interactúan con el software de diferentes formas. Así como es difícil clasificar las emociones de las personas, también es un desafío evaluar su reacción al software. Si bien ninguna métrica de software puede comunicar la totalidad de la experiencia de usuario, hay algunas que son útiles.

21. Métricas de UX. Las mediciones de UX suelen ser cualitativas y pueden incluir las respuestas emocionales o corporales de los usuarios, como cuánto confían en el software y cómo se mueven sus ojos a través de una interfaz de usuario.
22. Métricas de usabilidad. La usabilidad mide qué tan bien el software permite a los clientes alcanzar sus objetivos. La usabilidad se puede dividir en componentes más pequeños, como los siguientes:

• Facilidad de descubrimiento
• eficiencia
• memorabilidad
• facilidad de aprendizaje
• satisfacción
• accesibilidad, particularmente accesibilidad digital

23. Net Promoter Score (NPS). Esta métrica de software refleja la voluntad de los clientes de recomendar una aplicación a otros. Net Promoter Score se presenta como un rango de números de 0 a 10. Los clientes con una puntuación de 0 a 6 son Detractores; las puntuaciones 7 y 8 son Pasivos; y 9 y 10 son Promotores.