Este servicio se ejecuta siguiendo el proceso publicado en el catálogo de servicios estándar según el modelo de calidad de la Agencia.
Se puede consultar en el siguiente enlace: S06 - Evaluación estática de código fuente
A continuación, se especifican las distintas tecnologías a las que actualmente esta Oficina de Calidad aplica este Servicio, así como las verificaciones específicas en cada caso.
En caso de se usen lenguajes/tecnologías diferentes, contactar con la Oficina de Calidad.
Tecnología Java
Las pautas para cumplir en este servicio se implementan sobre las herramientas de integración continua de las que se dispone. A la espera de definir su funcionamiento y proceso de administración, se han definido Umbrales de aceptación permitidos por SonarQube Quality Gates de calidad del código en base a indicadores.
Se aconseja que, salvo excepciones, este servicio sea solicitado únicamente cuando el sistema haya superado el servicio de Evaluación de la integración y el despliegue continuo corporativo, ya que este garantiza que se gestionará el código de forma adecuada, realizándose la compilación del mismo de forma idónea y, automáticamente se validará el código con las herramientas corporativas, teniendo el equipo de desarrollo acceso a las herramientas y garantizando que sea autónomo para analizar los resultados ya que los informes se generan de forma automática. Además, se habrá establecido para el sistema la línea base (o valores de referencia) exigidos para dicho sistema en cuanto a calidad de código se refiere, si necesita que no se apliquen los valores de referencia inicialmente establecidos para todos los sistemas.
Contactar con el soporte de la Oficina de Calidad cuando:
•se requiera de un soporte para mejorar los parámetros de calidad del sistema.
•sea necesario crear una regla específica para ese sistema que tenga particular interés en el mismo.
Herramientas para la Ejecución del Servicio
Tecnología Java
Para aquellos Sistemas de Información que trabajan en integración continua con la infraestructura de este Organismo, son dos las fuentes para analizar el código por parte del equipo de desarrollo de forma autónoma: los resultados expuestos en la herramienta SonarQube y el informe relacionado con el análisis de dependencias que se realiza con plugins de OWASP.
Tecnología Developer
Se ha realizado un desarolllo ad-hoc en este Organismo para la Verificación Estática de Código denominada HawkEye.
Esta herramienta está a disposición de los equipos de desarrollo, de forma que autónomamente pueden revisar la calidad del código del código desarrollado.
En caso de requerirla, solicitar a la Oficina de Calidad.
Tecnología SAP
Para la ejecución de este servicio sobre tecnología SAP, la Oficina de Calidad hace uso de la herramienta para desarrolladores que incluye esta tecnología: SAP Code Inspector. Esta herramienta, incluida en el pack de desarrollo de SAP, es un inspector de código que permite analizar cualquier objeto del Repositorio de Objetos en términos de sintaxis, seguridad y rendimiento. En dicha herramienta, se pueden definir inspecciones que, con la ayuda de variantes de verificación, examinen ciertos conjuntos de objetos. Como resultado de una inspección, se reciben mensajes de información, de advertencia o de error en diferentes propiedades de los objetos examinados.
Umbrales quality gates
Los distintos umbrales Quality Gates se implementan en las herramientas asociadas a la evaluación estática de código fuente y, con ello, se establece un criterio para la generación de nuevos umbrales y sus niveles asociados, a aplicar a los proyectos.
Los proyectos que soliciten la evaluación estática de código fuente mediante petición expresa se someterán a una aplicación gradual de los niveles, comenzando por el nivel "inicial" y aumentando el grado de exigencia a medida que se vaya superando cada nivel anterior.
Existen varios niveles Quality Gates, donde cada uno de ellos va asociado a una fase de madurez del ciclo. De esta forma, a medida que un Sistema de información dado avance de fase, se le requerirá el cumplimiento de unos umbrales de calidad estática de código superiores, por suponerse una mayor madurez general del mismo, y sobre todo, con respecto a la alineación y seguimiento de determinadas prácticas de desarrollo.
Así, pueden definirse:
Nivel 0 - Bajo: este nivel se asignará por defecto a todos los sistemas que soliciten este servicio. Es el nivel más básico, con unos umbrales de métricas más laxos, y el mínimo a cumplir por parte de un Sistema en cuanto a requerimiento de umbrales de calidad estática de código. Se centra en no empeorar la calidad del proyecto.
Nivel 1 - Medio: Este nivel será el primero en exigir un estándar mínimo de calidad para todo el proyecto, requiriendo la corrección de defectos previos para cumplir con los criterios de calidad del código. Sin embargo, se establecerán umbrales bajos para facilitar que el proyecto los supere sin dificultad significativa.
Nivel 2 - Alto: una vez superado el nivel anterior por parte de un Sistema, se le asignará este nivel, el cual este deberá cumplir la próxima ocasión que se solicite el Servicio o se realice por cualquier motivo la verificación estática de código. Aquí se dará un paso más allá en el cumplimiento de los umbrales de las métricas asociadas a la calidad estática de código; de esta forma, será más restrictivo en cuanto a algunas de las métricas incluidas, como pueden ser porcentaje de comentarios, duplicidad de líneas, o cantidad de defectos o vulnerabilidades.
Nivel 3 - Exigente: este nivel, que será el máximo para alcanzar, solo se asignará a un Sistema cuando este haya superado los precedentes, y se requerirá el cumplimiento de unos umbrales más exigentes que en niveles anteriores. Por ejemplo, se exigirán valores bajos para métricas que miden la cantidad de defectos o vulnerabilidades, y elevados para otras métricas, como el porcentaje de comentarios o la cobertura de código.
En la siguiente tabla se representan las diferentes fases:
MÉTRICAS | Nivel 0 - Bajo | Nivel 1 - Medio(para superar la Validación) | Nivel 2 - Alto | Nivel 3 - Exigente | |
Ranking de Fiabilidad | = A | = A | = A | = A | |
Ranking de Seguridad | = A | = A | = A | = A | |
Ranking de Mantenibilidad | = A | = A | = A | = A | |
New Code | Porcentaje de Lineas Duplicadas | <= 30 % | <= 25% | <= 20% | <= 15% |
Cobertura de Pruebas | N/A | >= 50% | >= 70% | >= 90% | |
Vulnerabilidades | = 0 | = 0 | = 0 | = 0 | |
Incumplimientos Bloqueantes | = 0 | = 0 | = 0 | = 0 | |
Revisión de hotspot | = 100% | = 100% | = 100% | = 100% | |
Ranking de Fiabilidad | N/A | >= C | >= B | = A | |
Ranking de Seguridad | >= C | >= B | = A | = A | |
Ranking de Mantenibilidad | >= C | >= B | = A | = A | |
Porcentaje de Comentarios | >= 5% | >= 10% | >= 15% | >= 20% | |
Overall | Porcentaje de Líneas Duplicadas | <= 50% | <= 40% | <= 20% | <= 15% |
Porcentaje de Test Exitosos | N/A | >= 60% | >= 75% | = 100% | |
Cobertura de Pruebas | N/A | >= 20% | >= 50% | >= 80% | |
Vulnerabilidades | < = 100 | < = 50 | < = 20 | = 0 | |
Incumplimientos Bloqueantes | < = 200 | < = 100 | < = 50 | = 0 |
Estándar de asignación y superación de niveles SONAR
A continuación, se explica un planteamiento con el objetivo de mejorar la calidad del código de las aplicaciones y garantizar su sostenibilidad a lo largo del tiempo. Para ello se ha definido el anterior esquema de Quality Gates basado en cuatro niveles de restricción progresiva como hemos visto. Este planteamiento establece los criterios para la asignación de Quality Gates a las aplicaciones nuevas y existentes, así como la evolución de los requisitos a lo largo del tiempo.
Criterios de Asignación Inicial
Actualmente, las aplicaciones serán evaluadas en Sonar según los siguientes criterios:
- Aplicaciones Nuevas (Desarrollo Nuevo): Cualquier aplicación que no tenga una versión en producción deberá cumplir con el Nivel 2 - Alto desde su primer análisis en Sonar.
- Aplicaciones Existentes: Aquellas aplicaciones que ya estén en producción iniciarán con el Nivel 0 - Bajo.
Progresión de Quality Gates
Con el fin de garantizar una mejora continua en la calidad del código, se establece una evolución anual en los niveles de Quality Gates, quedando de la siguiente forma:
- Actualmente y durante el 2025:
- Aplicaciones Nuevas: Nivel 2.
- Aplicaciones Existentes: Nivel 0.
- Se informa a los equipos de desarrollo que a partir de 2026 el nivel mínimo exigido será el Nivel 1.
- Año 2026:
- Aplicaciones Nuevas: Nivel 2.
- Aplicaciones Existentes: Nivel 1 (mejorando desde el Nivel 0 del año anterior).
- Se informa a los equipos de desarrollo que en 2027 el nivel mínimo exigido será el Nivel 2.
- Año 2027:
- Aplicaciones Nuevas: Nivel 2.
- Aplicaciones Existentes: Nivel 2 (mejorando desde el Nivel 1 del año anterior).
- Se informa a los equipos de desarrollo que este será el último año de transición y que en 2028 todas las aplicaciones deberán cumplir con el Nivel 3.
- Año 2028 en adelante:
- Todas las aplicaciones (nuevas y existentes) deberán cumplir con el Nivel 3 - Exigente.
- Actualmente y durante el 2025:
Seguimiento y Comunicación
Para garantizar la transición efectiva entre niveles, se realizarán reportes a los equipos de desarrollo que lo soliciten a través de NAOS, informando su situación actual y las mejoras necesarias para alcanzar el nivel requerido en el próximo año. Además, se brindarán capacitaciones sobre buenas prácticas de desarrollo para facilitar la adaptación a los nuevos estándares.
Este plan establece una estrategia progresiva de mejora de la calidad del código en las aplicaciones, permitiendo una adaptación gradual sin afectar la operatividad de los proyectos existentes. La meta final es que, para el año 2028, todas las aplicaciones cumplan con el Nivel 3 de calidad.
Información necesaria para una solicitud del servicio de evaluación
Para complementar la solicitud del servicio a la Oficina de Calidad de determinados sistemas (horizontales y otros), es necesario adjuntar a la petición el archivo de hoja de cálculo que se puede encontrar adjunto en esta página, denominado "PLT_S06-Estática de código fuente_Datos previos evaluación_v01r00".
Documentación
Documentos para Usuarios
Fecha | Título |
---|---|
16/04/2025 | PLT_S06-Estática de código fuente_Datos previos evaluación_v01r00 |