Riesgo y deuda de calidad: lo que no sabe puede perjudicarlo

Cuando se trata de evaluar el riesgo de una base de código, no es un número mágico de bala única, y no es un simple semáforo "pasa / no pasa". El riesgo es multidimensional y multivariante, y se mide de manera diferente para diferentes organizaciones.

Probablemente ya sepa dónde están las partes de alto riesgo o "malas" del código: son las partes del código que siempre está cambiando, pequeños ajustes aquí y allá para solucionar pequeños problemas que parecen inocuos en sí mismos pero que generalmente representan capas de características además de un diseño deficiente. Esta es la razón por la que realizar cambios en el código existente es la principal causa de introducción de defectos en una aplicación.

Pero también sabemos que el cambio es constante. Nunca implementa todo por completo o corrige la primera vez, pero al mismo tiempo, a medida que se superpone al código existente, se pierde el conocimiento de cada caso de uso y escenario, aumenta la complejidad y el código se vuelve cada vez más riesgoso. Son estos cambios los que proporcionan la clave para aplicar el contexto al riesgo.

Tan importante como la visibilidad del riesgo en sí es comprender cómo lidiar con él, cómo priorizar las acciones de remediación para lograr un 'nivel aceptable de riesgo' mientras se minimiza el impacto en la velocidad del equipo. Esta publicación analiza solo eso: cómo evaluar el riesgo de cambios en el código y cómo priorizar y mitigar el riesgo de manera eficiente.

Determinación del riesgo multivariante

El riesgo no es un solo número o un 'semáforo' a nivel de proyecto (aunque usamos los colores de semáforo fácilmente asociados en nuestra interfaz de usuario), es una categorización de la base del código y una guía sobre dónde hay problemas reales y potenciales. existe. Vea abajo:

Un ejemplo de un gráfico circular del Process Intelligence Engine de Parasoft que muestra la proporción de código de alto, medio y bajo riesgo.

La categorización del riesgo es multidimensional y multivariante: debe reunir métricas de calidad de técnicas como análisis estático, métricas, cobertura de código y pruebas para comprenderlo realmente. Ninguna de estas técnicas le da el valor para una dimensión específica, sino que le da un valor para una fórmula. Por ejemplo, la cobertura de código no es un buen número para usar por sí solo porque podría tener una cobertura del 100%, pero solo una pequeña cantidad de pruebas que hacen algo significativo; debe pensar en lo que está usando la cobertura de código para decirle (es decir, "¿Qué tan bien se ha probado mi código?") Y aumentarlo con más datos para obtener un análisis más significativo.

Un ejemplo de un gráfico de burbujas de cambio de código riesgoso que ilustra dónde se encuentran los riesgos más altos. (Las burbujas se pueden expandir para ver las métricas que impulsan las categorizaciones).

El gráfico de burbujas anterior ilustra la categorización del riesgo en función de dos dimensiones (también se muestra en el gráfico a continuación):

• Carga de mantenimiento, usando una combinación de Volumen Halstead, Complejidad Ciclomática Estricta, número de líneas de código y proporción de código a comentarios para cuantificar qué tan fácil de mantener y comprensible es el código, y
• Déficit de prueba, utilizando el número de pruebas, el número de métodos y la cobertura del código para cuantificar qué tan bien se ha probado el código.

El código que se ha probado de manera deficiente (es decir, un déficit de prueba más alto) se clasifica como de alto riesgo (rojo), mientras que el código que está bien probado y bien construido (es decir, menor carga de mantenimiento) se clasifica como de bajo riesgo (verde).

Bases de código volátiles, donde cada cambio es un riesgo

Durante el calor del desarrollo, su base de código está en un estado de flujo constante y cada línea de código cambiada presenta un riesgo desconocido. ¿Romperá una característica fundamental? ¿Introduce una falla de seguridad? Cuanta menos información, mayor es el riesgo. En publicaciones anteriores, discutimos el impacto del cambio en las pruebas y cómo la cobertura de código debe usarse de manera inteligente para predecir dónde deben enfocarse los recursos de prueba. Sin embargo, incluso con una mayor cobertura y pruebas, todavía existe un riesgo adicional que se acumula con el tiempo.

El cambio en la base de código nos da la tercera y más importante dimensión de riesgo: equipo. No el tiempo en el sentido tradicional, sino el tiempo en lo que respecta a las construcciones y los cambios entre ellas. Centrarse en las partes de la base de código que han cambiado entre las compilaciones nos da la capacidad de concentrarnos en abordar el código que es tanto de mayor riesgo como más relevante, ya que el equipo está trabajando actualmente en esta parte de la base de código.

¿La carga de la deuda de calidad lo está frenando?

El código heredado y reutilizado ya tiene su propia carga, especialmente en lo que respecta a la seguridad. Cada línea de código enviada o modificada se suma a esta deuda si no hay controles adecuados para mantener o mejorar la línea de base de calidad. Salir de esta deuda, como cualquier deuda, requiere concentración y compromiso de reducción. Además, como con cualquier deuda, ¿cómo se sabe ahorrar a menos que se sepa dónde se está gastando el dinero?

Una vez que haya identificado el código con el mayor riesgo y la más alta prioridad, también debe considerar la cantidad de trabajo necesario para mitigar el riesgo. Esta es la cuarta y última dimensión: Deuda de calidad. En el gráfico de burbujas anterior, la deuda de calidad está representada por el tamaño de la burbuja: cuanto más grande es la burbuja, más problemas conocidos deben abordarse. En nuestro ejemplo, la deuda de calidad es una combinación de violaciones de análisis estático de alta gravedad (incluidas violaciones de umbrales establecidos para métricas de código) y fallas de prueba, normalizadas por el número de líneas lógicas de código (consulte la Figura 3).

Esta agregación de tareas de calidad sobresalientes brinda orientación sobre la cantidad relativa de trabajo requerido para reducir el riesgo del código.

¡Pero no es así como mido los riesgos!

No todas las organizaciones seguirán las mismas prácticas de calidad o acordarán qué factores tomar en consideración al calcular las dimensiones. Debe poder configurar y crear su propia definición de riesgo.

El ejemplo de este blog está disponible para los usuarios de Parasoft Marketplace, lo que le permite usarlo de inmediato, ampliarlo y modificarlo para satisfacer sus necesidades específicas. A partir del ejemplo, puede personalizar el análisis estático, los umbrales de métricas y las categorizaciones de riesgo para que se adapten a su organización.

Conclusión

Equilibrar los presupuestos, los horarios y los objetivos de calidad con las medidas de seguridad adecuadas mientras se satisface a los clientes es una tarea difícil con riesgos en todo momento. Sin embargo, la automatización de las prácticas de calidad y la inteligencia de procesos ayuda a guiarlo hacia dónde se gastan mejor los recursos. Comprender dónde reside el riesgo y cómo cada cambio de código afecta la calidad y seguridad de su línea de base reduce muchas incógnitas en la ecuación de desarrollo. La deuda de calidad y seguridad puede superarse con el enfoque adecuado.

por Mark Lambert

Mark, vicepresidente de productos de Parasoft, es responsable de garantizar que las soluciones de Parasoft brinden un valor real a las organizaciones que las adoptan. Mark ha estado con Parasoft desde 2004, trabajando con una amplia variedad de clientes de Global 2000, desde implementaciones de tecnología específicas hasta iniciativas de mejora de procesos SDLC más amplias.