⚡ TEMA 17 ⚡
Ya estamos en uno de esos temas que, a priori, puede parecer más de «teoría de la informática genérica», pero que en realidad es absolutamente crítico para tu día a día en el SAS. Mira, esto no es simplemente «instalar un IDE y tirar líneas de código». Hablamos de cómo se gestiona el cambio en sistemas que afectan directamente a la salud de millones de andaluces. Cada línea de código que se modifica en Diraya, en el BPS, o en cualquier sistema de gestión clínica, tiene que estar perfectamente trazada, controlada y validada. No hay margen para el «ya lo arreglo sobre la marcha».
Tu rol como futuro Técnico Especialista no será solo programar. Serás garante de que el proceso de desarrollo y despliegue no ponga en riesgo la continuidad asistencial. Y esto, en el examen, se traduce en preguntas muy prácticas sobre ciclo de vida del software, herramientas ALM (Application Lifecycle Management) y, sobre todo, sobre cómo se aplican estos conceptos en la infraestructura real del SAS.
Marco Normativo y Estratégico
Antes de meternos en harina, situémonos. Este tema no se entiende sin:
- Ley 39/2015 (Procedimiento Administrativo Común): que regula la administración electrónica y la obligatoriedad de sistemas robustos.
- ENS (RD 311/2022): especialmente el esquema medio, que exige control estricto de cambios y trazabilidad.
- RGPD-LOPDGDD: cada cambio en sistemas con datos de salud debe estar documentado y justificado.
- Estrategia de Salud Digital 2022-2027 del SSPA: apuesta por la modernización de herramientas de desarrollo y la mejora continua.
- ITIL 4: prácticas de Gestión de Cambios y Gestión de Liberaciones que se materializan en estas herramientas.
Y, sobre todo, la Normativa Interna del SAS: la STIC (Subdirección de Tecnologías de la Información y Comunicaciones) tiene un marco propio que usa JIRA, Confluence y Git como pilares de su gestión.
1. HERRAMIENTAS DE DISEÑO Y DESARROLLO DE SISTEMAS DE INFORMACIÓN: FUNCIONALIDAD Y CONCEPTOS
1.1. Entornos Integrados de Desarrollo (IDE) y Herramientas ALM
Cuando hablamos de herramientas de diseño y desarrollo en el contexto SAS, no nos referimos solo a Eclipse, IntelliJ o Visual Studio. Nos referimos a ecosistemas completos que cubren todo el ciclo de vida: desde que surge la necesidad hasta que el código está en producción.
Suite ALM del SAS
La infraestructura de la STIC está basada en una suite de herramientas que cubren la integración y entrega continua. Los pilares son:
- JIRA: No es solo un gestor de tareas. Es el backbone de la gestión de proyectos TIC. Se usa para líneas de diseño, transición, desarrollo de software, sistemas e infraestructuras, y proyectos provinciales. En JIRA se registran las peticiones de lanzamiento, las incidencias, las planificaciones ágiles (sprints), y se vinculan directamente con el código fuente.
- Confluence: Espacio de documentación colaborativa. Aquí se documentan las decisiones de arquitectura, los manuales de instalación, las estructuras de proyectos. Hay espacios privados para equipos TIC y espacios públicos para documentación de usuario.
- Git: El sistema de control de versiones distribuido. Todo el código fuente, scripts de base de datos y procedimientos de compilación deben residir exclusivamente en los repositorios Git de la STIC. No hay excepciones. No se permite el desarrollo local sin control.
- Jenkins: Orquesta la integración continua. Compila, testea y genera los binarios que luego se almacenan en Nexus.
- Nexus: Repositorio de dependencias y artefactos compilados. Desde aquí se sirven los binarios a los entornos.
1.2. Funcionalidades Clave de las Herramientas ALM
JIRA en el SAS: La funcionalidad va más allá de la gestión de tareas. Se usa para:
- Gestión del ciclo de vida del software: cada aplicación/componente tiene un proyecto JIRA donde se planifican las versiones.
- Control de cambios: cada petición de cambio (PC) se registra, evalúa su impacto, y se vincula a las tareas de desarrollo.
- Trazabilidad: desde una petición de usuario hasta el commit en Git y la entrega final, todo está conectado.
Confluence: Es el «cerebro documental». En él encontrarás normativa interna de la STIC, estructuras de proyectos y acuerdos de arquitectura, y manuales de despliegue y configuración.
Git: La funcionalidad central es el control de versiones distribuido. Cada desarrollador trabaja en su copia local, pero el push debe ir siempre a los servidores de la STIC. Permite ramas (branches) para desarrollo paralelo, fusiones (merges) controladas, e historial completo y recuperable de todo el código.
1.3. El Nuevo Modelo de Gestión: Aplicación-Componente
La STIC está evolucionando hacia un modelo más robusto: APLICACIÓN – COMPONENTES. ¿Qué significa esto? Antes, una aplicación como Diraya tenía múltiples proyectos separados. Ahora, todo lo relacionado con un producto se gestiona en un único proyecto JIRA, y cada partición independiente (módulo, librería, microservicio) es un componente.
Ventajas del modelo Aplicación-Componente
- Visión única del producto: un solo backlog, un solo roadmap.
- Versionado coordinado: la versión de la aplicación depende de las versiones de sus componentes.
- Gestión simplificada: menos proyectos, menos burocracia, más agilidad.
2. GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE: IDENTIFICACIÓN DE LA CONFIGURACIÓN
2.1. ¿Qué es la Gestión de Configuración?
No es simplemente «saber qué versión tenemos». Es identificar, controlar y auditar todo el software que compone un sistema. En el SAS, esto incluye código fuente de aplicaciones, scripts de base de datos, configuraciones de despliegue (Dockerfiles, Helm charts), y dependencias y librerías.
2.2. Identificación de la Configuración en el SAS
La Subdirección de Tecnologías de la Información y Comunicaciones (STIC) establece que todo el código fuente, scripts de base de datos y código compilado deben quedar almacenados en la infraestructura de la STIC. Esto materializa en:
- Catálogo de Aplicaciones (CMS): antes de crear un repositorio Git, la aplicación debe estar registrada en el Catálogo de Aplicaciones. Es el «DNI» de la aplicación en el SAS.
- Código ALM: cada aplicación/componente tiene un código único que se usa en JIRA, Git y Nexus.
- Estructura de repositorios Git: existe una estructura estandarizada.
Por ejemplo, para
Diraya:
- Ruta:
http://git.sas.junta-andalucia.es/asistencial/diraya/<componente> - Ejemplo real:
http://git.sas.junta-andalucia.es/asistencial/diraya/estacion_clinica_cuidados/estacion_clinica_cuidados_cliente_web.
- Ruta:
2.3. Archivos de Configuración y Estructura
Según la normativa interna, cada proyecto debe tener una estructura de carpetas específica que se acuerda al inicio con el Área de Gobernanza y Calidad. Esto incluye:
- Carpeta de migraciones de base de datos: debe contener siempre dos
ficheros:
version_X.X.X.sql: script de actualización.undo_version_X.X.X.sql: script de rollback.
Esta estructura permite automatizar despliegues y garantizar la reversibilidad, clave en sistemas críticos como Diraya.
3. CONTROL DE VERSIONES Y CAMBIOS: GIT
3.1. Fundamentos de Git en el Contexto SAS
Git no es una opción, es obligatorio. El incumplimiento de la directiva de almacenar el código exclusivamente en los repositorios de la STIC conlleva el rechazo automático de la PL (Petición de Lanzamiento).
Principios Clave de Git en el SAS
- Distribuido pero centralizado: cada desarrollador tiene su copia
local, pero el
repositorio de referencia (
origin) está en los servidores SAS. - Trazabilidad absoluta: cada commit debe estar vinculado a una tarea JIRA.
- Versionado semántico: se usa un formato específico que indica el tipo de cambio.
3.2. Política de Versionado del SAS
La normativa interna establece criterios estrictos:
- Primera versión estable: cualquier producto nuevo debe comenzar en 1.0.0.1.
- Versionado de componentes: sigue el formato
X.X.X.Xdonde:- Primer dígito: cambio arquitectónico mayor.
- Segundo dígito: nueva funcionalidad.
- Tercer dígito: corrección de errores.
- Cuarto dígito: hotfix/patch.
Ejemplo real:
estacion_clinica_cuidados_cliente_web.3.6.6.2.zip. Esto indica
que es la versión 3.6.6.2 de ese componente específico de Diraya.
3.3. Workflow de Desarrollo y Ramas
Aunque Git permite flujos flexibles, en el SAS se tiende a un modelo Gitflow adaptado:
- main o master: código en producción. Solo se mergea desde release.
- develop: integración de desarrollos diarios.
- feature/: ramas para cada funcionalidad (ej:
feature/integracion-farmacia). - release/: ramas de preparación de versión.
- hotfix/: parches urgentes en producción.
Norma de oro: nada se mergea a main sin pasar por JIRA, revisión de código y aprobación de calidad.
3.4. Control de Cambios y Peticiones de Lanzamiento
El proceso es rígido y documentado:
- Identificación del cambio: se crea una petición en JIRA.
- Evaluación de impacto: el Área de Gobernanza analiza riesgos.
- Desarrollo: se trabaja en rama feature, con commits vinculados a JIRA.
- Entrega: se solicita la PL (Petición de Lanzamiento) vía CGES, indicando la URL del repositorio Git y la versión.
- Compilación: Jenkins genera el binario y lo almacena en Nexus.
- Despliegue: se ejecuta en entornos de preproducción y, tras validación, en producción.
Documentación obligatoria: cada actualización debe incluir instrucciones especiales si las hubiera, y el formato de los ficheros debe ser estandarizado para futura automatización.
4. INTEGRACIÓN CON SISTEMAS CORPORATIVOS DEL SAS
4.1. Diraya y el Ecosistema de Desarrollo
Diraya no es una monolito estático. Es un conjunto de módulos interconectados que evolucionan constantemente:
- Estación Clínica (EC): módulo médico.
- Estación de Cuidados (ECC): módulo de enfermería.
- Estación de Gestión (EG): gestión administrativa.
- Portal Diraya: acceso web y mapa de ubicaciones hospitalarias.
Cada uno de estos módulos es un componente en el modelo JIRA-Git. Tienen repositorios separados pero versiones coordinadas.
4.2. Ejemplo Práctico: Desarrollo de un Nuevo Componente
Imagina que te encargan desarrollar un módulo de «Alertas de Interacciones Farmacológicas» para Diraya. El flujo sería:
- Registro en CMS: se crea el componente
alertas_farmacologicascon código ALM único. - Proyecto JIRA: se crea el proyecto
DIRAFARMy el backlog de historias de usuario. - Repositorio Git: se solicita vía CGES el repositorio
git.sas.junta-andalucia.es/asistencial/diraya/alertas_farmacologicas. - Desarrollo: el equipo trabaja en ramas
feature/alerta-anticoagulantes,feature/interfaz-farmacia. - Integración: se mergea a
develop, se ejecutan tests automáticos en Jenkins. - Entrega: se solicita PL para versión
1.0.0.1, se genera binario en Nexus. - Despliegue: se despliega en entorno de pruebas, se valida con farmacéuticos, y se promueve a producción.
TODO ESTO, cada paso, queda registrado y auditado. Si en producción surge un problema, puedes rastrear exactamente qué commit introdujo el error.
4.3. Interoperabilidad y Desarrollo de Integraciones
El SAS no es una isla. Integra sistemas externos (Nefrosoft, aplicaciones de laboratorio, etc.) mediante servicios web. El proceso de desarrollo de una integración sigue el mismo rigor: repositorio Git para el código de integración, JIRA para gestionar la petición, y versionado que respete la normativa. Esto garantiza que cuando Nefrosoft se conecta a Diraya para intercambiar datos demográficos de pacientes, el código que hace esa conexión está controlado, versionado y auditado.
5. CASOS PRÁCTICOS ILUSTRATIVOS
Situación: Lunes 8 AM. Los médicos del Hospital Universitario Virgen del Rocío reportan que Diraya muestra errores al validar prescripciones. El servicio de farmacia está paralizado.
Diagnóstico: Se revisa JIRA. Hubo un despliegue el viernes por la noche
(versión 3.6.6.2
del componente validacion_prescripciones). Al comparar el commit con la
versión anterior,
se detecta que falta una condición en la validación de alergias.
Resolución: Se crea un hotfix. Se crea rama
hotfix/validacion-alergias, se
corrige el código, se mergea a main y se genera versión 3.6.6.3. Todo ello en menos de 2
horas, con
trazabilidad completa para auditoría.
Pregunta de examen: ¿Qué normativa asegura la trazabilidad de este cambio? Respuesta: La combinación de ENS (control de cambios), RGPD (impacto en datos) y normativa interna de la STIC que obliga a vincular JIRA-Git-Jenkins.
Situación: El SAS lanza el proyecto «Prescripción Electrónica de Especialidades Controladas». Requiere modificar Diraya, el BPS y el sistema de la ventanilla farmacéutica.
Aproximación: Se crea un proyecto JIRA transversal con
componentes para
cada sistema. Los equipos de desarrollo trabajan en paralelo en sus repositorios Git. Se
usa Gitflow con
una rama release/controladas donde se integran todos los componentes.
Jenkins compila y
genera binarios sincronizados. Se despliega en preproducción y se valida con 3
hospitales piloto.
Resultado: Despliegue coordinado en toda Andalucía sin incidencias, con documentación completa en Confluence y disponible para auditoría del CCN-CERT.
6. CUESTIONARIO DE PREGUNTAS TIPO TEST (≥25 Preguntas)
Instrucciones: Lee cada pregunta y elige la opción correcta. Trata de razonar como si estuvieras en el examen. Al final, las respuestas y explicaciones.
<código ALM de la aplicación en CMS>-testproject.
version_X.X.X.sql
y
undo_version_X.X.X.sql para permitir actualización y marcha atrás.
Mapa Conceptual: Herramientas de Desarrollo SAS
⚙️ HERRAMIENTAS DE DESARROLLO SAS
│
├── 📌 SISTEMAS ALM
│ ├── JIRA (gestión proyectos)
│ ├── Confluence (documentación)
│ ├── Git (control versiones)
│ ├── Jenkins (CI/CD)
│ └── Nexus (binarios)
│
├── 📋 GESTIÓN CONFIGURACIÓN
│ ├── Identificación (CMS, código ALM)
│ ├── Control (ramas Git, versionado)
│ ├── Auditoría (trazabilidad JIRA-Git)
│ └── Entrega (PL, Nexus)
│
├── 🔢 VERSIONADO
│ ├── Formato X.X.X.X (obligatorio)
│ ├── Versión inicial: 1.0.0.1
│ ├── Componentes vs Aplicación
│ └── Ramas: feature, develop, release, hotfix
│
├── 🏥 CONTEXTO SAS
│ ├── Diraya (módulos EC, ECC, EG)
│ ├── BPS, InterSAS, BDU
│ ├── Arquitectura: Citrix, Oracle, Solaris
│ └── Integraciones: HL7, FHIR, servicios web
│
└── 📜 NORMATIVA
├── ENS (control de cambios)
├── RGPD (trazabilidad)
├── Ley 39/2015 (admin. electrónica)
└── Normativa interna STIC
Referencias Normativas y Bibliográficas
Normativa Legal y Reguladora
Normativa Interna del SAS
Estándares y Frameworks
Bibliografía Técnica
Fuentes Web del SAS
Conclusiones y Consejos de Estudio
En resumen, este tema es la columna vertebral de la gestión TIC en el SAS. No es teórico, es 100% operativo. Te voy a dar las claves para que no solo lo apruebes, sino que lo interiorices:
- No memorices, visualiza el flujo: Imagina que eres el responsable de un proyecto real. ¿Qué pasos seguirías desde la idea hasta producción? Ese es el camino: JIRA → Git → Jenkins → Nexus → Producción.
- Los números de versión importan: En el examen te pueden dar un caso con versiones incoherentes. Recuerda: 1.0.0.1 para nuevos productos, formato X.X.X.X, y congruencia entre aplicación y componentes.
- La trazabilidad es sagrada: Cada commit debe ir a JIRA. Cada PL debe tener URL de Git. Cada despliegue debe tener binario en Nexus. Si algo falla en esta cadena, la auditoría del ENS o del CCN-CERT te lo va a reprochar.
- Contexto SAS es todo: No hables de Git genérico. Habla de Git en la
STIC, con sus
normas, sus repositorios (
git.sas.junta-andalucia.es), sus políticas de ramas. No hables de JIRA genérico, habla de JIRA para gestión de proyectos TIC del SAS. - Errores comunes en el examen:
- Confundir roles: el desarrollador no aprueba la PL, lo hace Gobernanza.
- Ignorar la obligatoriedad del almacenamiento en Git STIC.
- No conocer el formato de versionado ni el significado de cada dígito.
- Mezclar binarios con fuente en Git.
Para memorizar: Haz un mapa mental con el flujo completo. Usa tarjetas Anki con preguntas como «¿Qué pasa si…?» (ej: «¿Qué pasa si el código no está en Git STIC? → Rechazo PL»).