Tome un camino más rápido e inteligente hacia la automatización de pruebas C/C++ impulsada por IA. Descubra cómo >>
Cómo abordar su acumulación de advertencias de análisis estático y deuda técnica
Si ha tenido problemas para manejar su acumulación de advertencias de análisis estático y deuda técnica, consulte esta publicación para aprender cómo abordar esto.
Si ha tenido problemas para manejar su acumulación de advertencias de análisis estático y deuda técnica, consulte esta publicación para aprender cómo abordar esto.
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.
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:
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:
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.
Cuando se trata de deuda técnica, hay dos grandes categorías.
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.
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:
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 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.
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.
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.
Un ejemplo de panel de un portal web. En este caso, un resumen del cumplimiento del 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.
El explorador de violaciones de Parasoft
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.
Aprendizaje automático sobre cómo priorizar los resultados del análisis estático.
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.
Un ejemplo de un informe de desviación de Parasoft MISRA C
Es importante para los equipos que están adopción de análisis estático Comprender que no es necesario corregir ni analizar todas las advertencias. No todas son iguales, por lo que el nivel de gravedad es el mejor indicador del esfuerzo necesario para investigar y corregir una advertencia. Al analizar a fondo la acumulación de advertencias, los equipos, en efecto, amplían la línea 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.
Ajustes de configuración de prueba personalizados dentro del IDE
Esta configuración se puede utilizar para filtrar las advertencias en el IDE.
Las configuraciones se pueden seleccionar en la vista DTP Findings en el IDE.
Mover gradualmente la línea para abordar la siguiente prioridad y categoría más alta es la mejor estrategia para gestionar una gran acumulación de advertencias. Eventualmente, los equipos de software llegan a un punto límite debido al tiempo y el presupuesto. Sin embargo, deben sentirse seguros de haber logrado mejoras significativas en calidad y seguridad a pesar de la acumulación de advertencias.
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.
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.
En un proyecto grande, al principio habrá muchas advertencias. Gestionarlas con rapidez y eficiencia es fundamental. Es importante que los equipos que adoptan el análisis estático comprendan que no es necesario corregir ni analizar todas las advertencias. En su lugar, asegúrese de seleccionar una herramienta que le permita navegar, evaluar, priorizar y asignar los errores reportados para su corrección. Mover gradualmente el límite para abordar la siguiente prioridad y categoría más alta es la mejor estrategia para gestionar una gran acumulación de advertencias.
«MISRA», «MISRA C» y el logotipo triangular son marcas registradas de The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. Todos los derechos reservados.
