Subdirección de las Tecnologías de la Información y Comunicaciones

Área de Gobernanza y Calidad

Cumplimiento normativo

Histórico de cambios

Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.

Introducción

Todos los proyectos desarrollados para la STIC deben construirse y desarrollarse en base a los requisitos técnicos y tecnológicos que la infraestructura del SAS soporta. En caso contrario deberá especificarse de forma clara y concisa durante la reunión de lanzamiento del proyecto. A continuación se detalla el conjunto de requisitos a contemplar por parte de los proveedores.

Integración continua

Desde la Oficina de Calidad se propone un entorno tecnológico de integración continua que se adapte a las particularidades del proceso de desarrollo software de la STIC, basado en herramientas de software libre y que proporcionará los siguientes beneficios:

• Reducción del tiempo de desarrollo de los proyectos.
• Detección de errores inmediatamente durante el proceso de desarrollo.
• Disminución considerablemente del tiempo de ejecución de las pruebas de calidad del software.
• Mantener tanto al equipo de desarrollo como a la propia STIC informados del estado del sistema en desarrollo y tener disponibilidad de la última versión del código para realizar pruebas de despliegue.

El proceso de Integración Continua permite poner de manifiesto la mayor parte de los errores de un sistema de información en el mismo día en el que se integran los módulos intervinientes, reduciendo drásticamente los tiempos para determinar el problema y resolverlo. Cada vez que se realiza la integración, los desarrolladores deben asegurarse que todas las pruebas se ejecutan correctamente, para que el nuevo código sea incorporado definitivamente.

Un proceso de integración continua incluye las siguientes acciones:

• Compilación de fuentes: detectar lo antes posibles si los cambios comprometidos producen errores de compilación.
• Ejecución de test unitarios: otro de los puntos clave para aumentar la calidad de un proceso de desarrollo es la implementación de test unitarios. Estos tests nos proporcionan la primera información funcional del aplicativo.
• Empaquetado de binarios: ensamblar el código fuente y publicar los binarios generados en un repositorio de artefactos facilita la reutilización de software y aportan la última versión de software disponible en cualquier momento del desarrollo.
• Análisis estáticos de Calidad: es importante el uso de herramientas que proporcionen análisis estáticos de código fuente mediante un catálogo de reglas de calidad predefinidas.
• Despliegue de aplicativos: periódicamente, si se han producido cambios en el código fuente, es imprescindible saber si la aplicación no tiene problemas en el despliegue, implantación e integración de la misma.
• Tests funcionales: una vez que tenemos el proceso anterior completo, disponemos de una aplicación instalada. Éste es el momento de saber si funcionalmente la aplicación tiene buena salud. Existen multitud de herramientas para implementar este tipo de test, desde simulación de navegaciones en aplicaciones web o de escritorio, pruebas de servicios web, pruebas de carga y concurrencia,...

Desde este marco propuesto el entorno tecnológico por la OCA consta de las siguientes herramientas:

Repositorio de código

• GIT: Consultar la documentación relativa a GIT en el siguiente enlace
• Nexus: Las librerías utilizadas para el desarrollo de las aplicaciones deberán proceder del repositorio de librerías del SAS:  https://dml-si.sas.junta-andalucia.es/. En caso de que fuese necesaria la implementación de una librería propia del proyecto, o el uso de librerías pertenecientes a un repositorio no incluido, deberá notificarse (mediante petición CGES) con antelación a la entrega, para proceder a su incorporación al repositorio del SAS.

Construcción de código

• MAVEN: De forma general, el ciclo de vida de desarrollo para aplicaciones Java EE cuyo código fuente sea incorporado al repositorio de la STIC, deberá ser gestionado con la herramienta Maven, según las pautas generales definidas por el estándar y adaptadas al entorno específico del SAS (ver norma desarrollo Java EE 6. El uso de Maven se restringirá a versiones superiores a 3.X.X.

Servidor de integración continua

• JENKINS: Herramienta para la integración continua, que permite a través de su integración con Maven la compilación, verificación y registro del software: http://ci.alm.sas.junta-andalucia.es/

Herramientas para la realización de pruebas

• JUNIT: Framework Open Source para la automatización de las pruebas en los proyectos Software. Este framework provee al usuario de herramientas, clases y métodos que le facilitan la tarea de realizar pruebas en su sistema y así asegurar su consistencia y funcionalidad.
• Sonarqube: Herramienta que permite analizar y valorar la calidad del código desarrollado: http://qa.alm.sas.junta-andalucia.es/about

Preparación de la entrega. Catálogo de peticiones CGES

Antes de realizar la entrega es necesario cumplir una serie de condiciones: Tener la aplicación dada de alta en el repositorio de código, o las librerías a utilizar en Nexus son algunas de ellas. Mediante esta sección se enumera el catálogo de peticiones CGES disponibles para realizar solicitudes de este tipo a la Oficina de Calidad.

Más información...

Gestión de Entregas

Esta sección recoge la normativa aplicable para la gestión de entregas del software desarrollado por y para la STIC así como el procedimiento relativo a la entrega de Software de los desarrollados realizados.

Con la aplicación de esta norma y recomendaciones, la STIC pretende:

• Definir las herramientas para la Gestión de Entregas.
• Definir la estructura del código fuente, los acuerdos de marcado de versiones y la política de numeración de versiones.
• Implantar y normalizar el procedimiento de entrega de código fuente.

La gestión de las entregas del software desarrollado por y para la Subdirección de Tecnologías de la Información y Comunicaciones del Servicio Andaluz de Salud se realizará usando las herramientas, los procedimientos y normas definidos en los enlaces relacionados a continuación.

Verificación de calidad de código fuente

Una vez realizada la entrega, la Oficina de Calidad realizará una serie de validaciones con el fin de aceptarla. Una de ellas será la verificación de la calidad del código entregado. 

En esta sección se recoge la normativa aplicable para la comprobación de la calidad del código fuente de las aplicaciones desarrolladas para la STIC en base al conjunto de prácticas de desarrollo definidas. 

• Métricas verificables: conjunto de métricas verificables por la Oficina de Calidad.
• Umbrales de calidad: umbrales de calidad exigidos por la OCA (umbrales mínimos y de confianza).
• Calidad de los tests unitarios y cobertura de los mismos.

La realización de pruebas se realizará en base a la herramienta Sonarqube que permite automatizar la mayor parte de las comprobaciones

Más información... 

Normativa CNO de BBDD

Otra de las tareas a realizar tras la entrega será la revisión de los scripts necesarios para la implantación de la versión a liberar. En esta sección se dispone de la normativa establecida para las bases de datos Oracle del Servicio Andaluz de Salud, así como del acceso a la herramienta de evaluación para el cumplimiento de dicha normativa. La aplicación devuelve un informe HTML con el número de normas cumplidas e incumplidas respecto a la normativa de BBDD Oracle publicada por la STIC y que son de obligado cumplimiento.

Más información...