10 principios de la inspección continua
2 de febrero 2024
¿Qué es la inspección continua?
Hagámos un poco de memoria. La inspección continua es un nuevo paradigma en la gestión de la calidad del código diseñado para hacer que la calidad del software sea algo interno en la empresa, una parte integral del ciclo de vida de desarrollo del software. La inspección continua disfruta de una adopción de base entre los equipos de desarrollo, porque su naturaleza colaborativa conduce a una propiedad del código verdaderamente colectiva y ayuda a los equipos a entregar un mejor software.
Proporciona una gestión continua de la calidad del código y aumenta drásticamente el ROI de un proyecto de desarrollo. El concepto clave en la inspección continua es encontrar los problemas temprano, cuando solucionarlos aún es barato y fácil. Bajo este modelo, las auditorías de código automatizadas analizan el código de un proyecto a lo largo de múltiples ejes de mantenibilidad, lo prueban en busca de bugs y lo comparan con los estándares de codificación del equipo.
Las auditorías se completan con herramientas que detectan esos problemas directamente en el entorno del desarrollador, algo como el corrector ortográfico de Microsoft Word.Los miembros del equipo reciben una alerta tan pronto como se encuentran nuevos problemas para que se puedan abordar lo más rápido posible, mientras el código aún está fresco en la mente del desarrollador. La puntualidad de estas alertas tiene el beneficio adicional de capacitar a los codificadores para que eliminen los malos hábitos y los guíe hacia los buenos.
¿Qué han que tener en cuenta?
A continuación te dejamos 10 principios de la inspección continua para que puedas aplicar desde ya:
-
Todas las partes involucradas en el proceso de desarrollo – no solo los desarrolladores o administradores – deben tener acceso inmediato a datos significativos sobre la calidad del software.
-
La gestión de la calidad del software debe ser una preocupación de todos desde el comienzo del desarrollo, pero es la responsabilidad última del equipo de desarrollo.
-
La calidad del software debe ser parte del proceso de desarrollo, lo que significa que cumplir con los estándares de calidad es uno de los requisitos más estrictos para poder declarar el desarrollo completo.
-
Los requisitos de calidad del software deben ser objetivos y no requerir una decisión subjetiva de aprobado/denegado.
-
En la medida de lo posible, los requisitos de calidad del software deben ser comunes a todos los productos de software, independientemente de sus especificaciones.
-
Los datos de calidad del software deben estar actualizados, es decir, medidos en la última versión del código.
-
Los productos de software deben inspeccionarse continuamente, de modo que los errores se encuentren rápidamente, cuando sean fáciles de corregir. Los desarrolladores deben ser capaces de detectar nuevos defectos de calidad tan pronto como se introduzcan, es decir, dentro del IDE mientras escriben el código, de forma similar a cómo los correctores ortográficos resaltan los errores.
-
Ya sea a través de push o pull, las partes involucradas deben recibir alertas cuando se inyectan nuevos defectos de calidad, ya sea enviando un correo electrónico, rompiendo la compilación o por otros métodos. Se debe realizar un seguimiento de la inyección de nuevos problemas, lo que permite a los equipos tomar decisiones rápidas e informadas sobre la calidad.
-
Los datos de calidad del software deben estar disponibles como valores absolutos (en todos los códigos) y diferenciales (sólo en código nuevo) para que el equipo de desarrollo pueda tener el control total del flujo entrante de issues.
-
A todos los problemas nuevos y los problemas críticos existentes se les debe asignar una ruta clara y un plazo de tiempo para su resolución.
La inspección continua se adapta bien a los entornos de desarrollo ágiles y en cascada, y aborda las deficiencias del enfoque tradicional.La inspección continua ofrece una calidad mejorada con una interrupción mínima del proceso de desarrollo y la línea de tiempo.
Este artículo se ha elaborado a partir de este whitepaper de Sonar
bitegarden team
Helping companies to develop better software