Cómo abordar su acumulación de advertencias de análisis estático y deuda técnica

Después de que las herramientas de análisis estático se hayan integrado en el flujo de trabajo diario del equipo de desarrollo, la siguiente fase es trabajar para reducir la acumulación de advertencias y la deuda técnica en un proyecto.

En el caso de un producto en mantenimiento o en desarrollo, es probable que haya una acumulación considerable que tratar. En el caso de un proyecto greenfield, hay menos retrasos. Sin embargo, las recomendaciones siguen siendo las mismas para cada etapa de madurez.

El mejor punto de partida para lidiar con una acumulación de advertencias es priorizar y filtrar los resultados según el resultado deseado. Usando la seguridad como ejemplo, tiene sentido priorizar la acumulación en términos de advertencias de seguridad, clasificadas por criticidad.

Esta es una continuación del enfoque utilizado cuando se Introducción al análisis estático en un proyecto, pero ahora la atención se centra en el siguiente conjunto digerible de advertencias para que el equipo las analice. Parasoft C/C++test maneja esto de varias maneras, como veremos a continuación.

¿Qué es la deuda técnica y por qué es importante?

La deuda técnica es el costo incurrido por retrasar el trabajo esencial o tomar atajos durante el desarrollo del software. Esta forma de deuda, como la deuda financiera, acumula intereses con el tiempo y puede volverse costosa de arreglar si no se resuelve.

Ejemplos de deuda técnica incluyen:

• Código que es difícil de mantener o ampliar
• Dependencias obsoletas
• Vulnerabilidades de seguridad

Desafortunadamente, la deuda técnica es un problema común, ya que los equipos de desarrollo de software a menudo priorizan la entrega rápida de funciones en lugar de crear una base de código sólida.

Abordar la deuda técnica es crucial por varias razones. Puede:

• Impedir la capacidad de los equipos de software para entregar productos de alta calidad.
• Disminuir la productividad.
• Aumentar el tiempo de desarrollo.
• Menor satisfacción del cliente.
• Plantean riesgos de seguridad.

Resolver la deuda técnica es esencial para crear productos de software sostenibles y mantenibles que puedan adaptarse a las cambiantes necesidades comerciales y de los clientes.

Tipos de Deuda Técnica

Cuando se trata de deuda técnica, hay dos grandes categorías.

1. Intencional
2. Involuntario

Se incurre en una deuda técnica intencional cuando un equipo conscientemente toma atajos para cumplir con un plazo o lograr un objetivo específico. Este tipo de deuda técnica a menudo se acumula como resultado de consideraciones comerciales, como las presiones del mercado, y se considera un mal necesario. La desventaja es que puede generar trabajo adicional en el futuro, como la refactorización, que puede ser costoso.

Por otro lado, se incurre en una deuda técnica no intencional cuando un equipo no es consciente del impacto de las decisiones que toma durante el desarrollo. Esto puede ocurrir como resultado de la falta de comprensión o experiencia en un área específica, la falta de recursos o tiempo, o simplemente debido a la falta de disciplina o rigor.

Este tipo de deuda técnica suele ser más insidiosa, ya que puede ser difícil de detectar y diagnosticar, y puede tener consecuencias imprevistas en el futuro. Independientemente del tipo de deuda técnica, es importante estar al tanto de su existencia y tomar medidas para administrarla de manera efectiva a fin de garantizar la salud y el éxito a largo plazo de un proyecto de software.

Ejemplos de deuda técnica

La deuda técnica no intencional puede acumularse con el tiempo si no se aborda, lo que finalmente dificulta el mantenimiento y la evolución del software. Algunos ejemplos de deuda técnica no intencional incluyen:

• Deuda de diseño surge cuando se toman decisiones de diseño para cumplir objetivos a corto plazo o metas de entrega, sin considerar las implicaciones a largo plazo de esas decisiones.
• código de deuda surge de malas prácticas de codificación y atajos para cumplir con los plazos, lo que genera problemas como códigos duplicados o demasiado complejos que son difíciles de mantener o probar.
• Deuda de prueba ocurre cuando las pruebas adecuadas no se llevan a cabo o son insuficientes, lo que genera desafíos en la detección y el tratamiento de defectos y la posibilidad de que se publiquen errores en la producción.

La deuda técnica intencional se asume con el entendimiento de que deberá devolverse en algún momento en el futuro. Algunos ejemplos de deuda técnica intencional incluyen:

• La deuda técnica planificada es deliberada. Implica tomar atajos con el conocimiento de que se abordarán en el futuro, como usar una biblioteca de terceros que se reemplazará con una solución personalizada.
• El equipo de desarrollo incurre intencionalmente en deuda comercial para satisfacer una necesidad comercial, como lanzar un producto con menos funciones de las planificadas para satisfacer la demanda del mercado, con el entendimiento de que deberá mejorarse más adelante.
• La deuda estratégica ocurre cuando un equipo pospone intencionalmente el trabajo en nuevas funciones o sistemas para priorizar otras áreas, a pesar de saber que será más costoso en el futuro.

La mejor práctica para la deuda técnica es adoptar un enfoque proactivo para administrar la calidad del código para que los desarrolladores de software puedan reducir el riesgo de acumular demasiada deuda técnica y garantizar que su software se mantenga saludable y sostenible a largo plazo al priorizar prácticas de código y diseño de alta calidad y pagar regularmente la deuda técnica. Esto significa invertir en la calidad del código, las pruebas y la documentación, y garantizar que el software siga siendo mantenible, escalable y seguro a lo largo del tiempo.

Importancia del análisis estático para la gestión de la deuda técnica

El análisis estático es un método automatizado para revisar el código fuente en busca de problemas de calidad y cumplimiento. Puede ser útil para identificar problemas de seguridad, vulnerabilidades de seguridad y problemas de confiabilidad, o áreas donde el código puede ser más difícil de mantener o ampliar en el futuro.

Al detectar la deuda técnica temprano, los equipos pueden tomar medidas para abordarla antes de que se convierta en un problema mayor. Esto puede ayudar a mejorar la calidad del código, reducir el tiempo de desarrollo, reducir los costos de mano de obra y mejorar el valor general de los productos de software.

Cuadros de mando para análisis de alto nivel

centralizado de parasoft paneles de informes y análisis Brinde a los desarrolladores y gerentes la capacidad de ver el estado actual de un proyecto desde varios puntos de vista y navegue más en detalle donde sea necesario para establecer un conjunto de advertencias para una mayor investigación. Considere el siguiente tablero que muestra el cumplimiento actual de un proyecto con el estándar de codificación de seguridad CERT C.

Con este portal web, los usuarios pueden profundizar en el análisis, hasta el nivel de archivo y código si es necesario, e investigar las advertencias completamente dentro del portal web o en un IDE. Las advertencias se pueden priorizar, asignar a los desarrolladores, suprimir o marcar como falso positivo en esta etapa. Vea el siguiente ejemplo del explorador de Parasoft.

Manejo de violaciones de estándares de codificación

En la mayoría de los casos, cuando se analiza el código fuente para el cumplimiento del estándar de codificación, las infracciones se notifican como advertencias de análisis estático. En un proyecto grande, inicialmente habrá muchas advertencias. Gestionarlos de forma rápida y eficiente es fundamental. El explorador de violaciones de Parasoft es la herramienta clave para navegar, evaluar, priorizar y asignar errores informados para su corrección.

Si una violación de la regla de análisis estático resulta ser válida pero justificable, considerada inofensiva o no aplicable, un desarrollador puede suprimir el error y se puede documentar una desviación. Estas desviaciones se informan a través de cada nivel del proyecto al tablero y la documentación de cumplimiento.

Para que el cumplimiento del estándar de codificación sea factible para los proyectos existentes, es fundamental que los equipos se centren primero en las reglas que se consideran obligatorias. El cumplimiento a menudo se basa en el cumplimiento de los requisitos obligatorios con violaciones de las reglas recomendadas si se documentan adecuadamente. Los estándares permiten recategorizar las reglas, si no son obligatorias, permitiendo violaciones, si son justificables y documentadas. Sin esto, tratar de corregir cada violación se vuelve inviable.

Aprovechando la inteligencia artificial (AI) y el aprendizaje automático (ML), Parasoft's informes y análisis aprenda tanto de las interacciones históricas con la base de código como de los hallazgos de análisis estáticos anteriores para predecir la relevancia y priorizar los nuevos hallazgos.

Los gerentes y líderes de desarrollo también ahorran horas extra de trabajo con una interfaz navegable para explorar violaciones y generar automáticamente informes para evidencia de certificación, si es necesario. A continuación se muestra un ejemplo de un informe de desviación de MISRA C.

Gestión de la acumulación de errores y advertencias de seguridad

Es importante para los equipos que están adopción de análisis estático entender que no es necesario corregir o analizar todas las advertencias. No todas las advertencias se crean por igual, por lo que el nivel de gravedad es el mejor indicador de cuánto esfuerzo se debe realizar para investigar y corregir una advertencia. Al profundizar en la acumulación de advertencias, los equipos efectivamente mueven "la línea en la arena" un poco más cada vez.

Parasoft's jprueba y Prueba C / C ++ permitir a los usuarios priorizar y filtrar advertencias dentro del IDE usando configuraciones. Por ejemplo, pueden usar un nivel de gravedad y una categoría para crear un conjunto de advertencias adecuadas para el análisis. A continuación se muestra un ejemplo de una nueva configuración de usuario.

Esta configuración se puede utilizar para filtrar las advertencias en el IDE.

Mover gradualmente la "línea en la arena" para abordar la siguiente prioridad y categoría más alta es el mejor enfoque para lidiar con una gran acumulación de advertencias. Eventualmente, los equipos de software llegan a un punto límite debido al tiempo y al presupuesto. Pero deben sentirse cómodos de haber realizado mejoras significativas en la calidad y la seguridad a pesar de la acumulación de advertencias.

Mejores prácticas para prevenir la deuda técnica

La prevención de la deuda técnica requiere una enfoque proactivo que involucra a todo el equipo de desarrollo de software. Estas son algunas de las mejores prácticas que pueden ayudar a prevenir la deuda técnica.

• Priorizar y planificar. Desarrolle un plan claro y priorice las tareas según el valor comercial y el riesgo. Esto puede ayudar a evitar tomar atajos para cumplir con plazos poco realistas.
• Revisiones de código. Realice revisiones de código para garantizar la calidad del código e identificar posibles problemas al principio del proceso de desarrollo.
• Automatice las pruebas. Use pruebas automatizadas para detectar problemas temprano y reducir el riesgo de introducir nuevos problemas.
• Integración y entrega continuas. Implemente la integración y la entrega continuas para garantizar que los cambios de código se integren y prueben con regularidad, lo que reduce el riesgo de problemas de integración.
• Seguimiento de la deuda técnica. Realice un seguimiento de la deuda técnica y priorice su pago como parte de los ciclos de desarrollo regulares.
• Compartir conocimientos. Fomente una cultura de intercambio de conocimientos para garantizar que el equipo esté al tanto de las últimas actualizaciones y mejores prácticas.

Al seguir estas mejores prácticas, los equipos de desarrollo de software pueden ayudar a prevenir deudas técnicas y garantizar que están creando productos de software seguros, confiables y fáciles de mantener.

Resumen

En un proyecto grande, inicialmente habrá muchas advertencias. Gestionarlos de forma rápida y eficiente es fundamental. Es importante que los equipos que adopten el análisis estático entiendan que corregir o analizar todas las advertencias no es necesario. En su lugar, asegúrese de seleccionar una herramienta que le permita navegar, evaluar, priorizar y asignar errores informados para su corrección. Mover gradualmente la "línea en la arena" para abordar la siguiente prioridad y categoría más alta es el mejor enfoque para lidiar con una gran acumulación de advertencias.

“MISRA”, “MISRA C” y el logotipo del triángulo son marcas comerciales registradas de The MISRA Consortium Limited. © The MISRA Consortium Limited, 2021. Todos los derechos reservados.