📊 TEMA 14
💪 ¡Bienvenido a uno de los temas fundamentales de la oposición!
Hola, soy Esteban Castro, y vamos a dominar juntos este tema que es absolutamente crítico para tu examen. El ciclo de vida de los sistemas de información no es solo teoría de libro… es el día a día del SAS. Cada vez que se desarrolla una nueva funcionalidad en Diraya, cada vez que se actualiza el sistema de Receta XXI, cada vez que se despliega una mejora en cualquier sistema corporativo, se está siguiendo un modelo de ciclo de vida.
¿Sabías que en los últimos exámenes del SAS han caído entre 3-5 preguntas directas sobre este tema? Y no solo eso… el conocimiento de ciclos de vida se aplica indirectamente en preguntas de metodologías ágiles, ITIL, gestión de proyectos y prácticamente cualquier tema técnico. Dominar este tema es dominar las bases de cómo se construye y mantiene toda la infraestructura TIC del sistema sanitario andaluz.
📋 Índice del Tema
- Introducción y Contextualización
- El Ciclo de Vida de los Sistemas de Información
- Concepto y definición
- Fases genéricas del ciclo de vida
- Importancia en el desarrollo de software
- Modelos Clásicos de Ciclo de Vida
- Modelo en Cascada (Waterfall)
- Modelo en V
- Modelo Incremental
- Modelo Iterativo
- Modelo en Espiral
- La Elaboración de Prototipos
- Concepto y tipos de prototipos
- Prototipado rápido
- Ventajas e inconvenientes
- Aplicación en el SAS
- Metodologías y Marcos de Referencia
- MÉTRICA v3
- ISO/IEC 12207
- MADEJA
- Metodologías Ágiles (introducción)
- Aplicación Práctica en el SAS
- Conclusiones y Claves para el Examen
- Cuestionario de Evaluación (30 Preguntas)
- Mapa Conceptual
- Referencias Normativas y Bibliográficas
1. 🎯 Introducción y Contextualización
1.1. Relevancia del Tema para el Técnico Especialista en Informática del SAS
Mira, voy a ser directo contigo. Si estás preparando esta oposición es porque quieres trabajar en uno de los sistemas sanitarios más grandes y complejos de España. El SAS gestiona la asistencia sanitaria de más de 8,5 millones de andaluces a través de sistemas de información que no pueden fallar. Y todos esos sistemas han pasado por un ciclo de vida… algunos están en desarrollo, otros en mantenimiento, otros están siendo migrados o renovados.
Como Técnico Especialista en Informática, tu trabajo no será solo «programar» o «configurar servidores». Vas a participar en proyectos que afectan directamente a la vida de las personas: desde el desarrollo de nuevas funcionalidades en la Historia Digital de Salud (Diraya), hasta la implementación de sistemas de telemedicina, pasando por la integración de diferentes aplicaciones corporativas. Y todos estos proyectos siguen un ciclo de vida que debes conocer a la perfección.
🏥 Ejemplo Real del SAS
Cuando se desarrolló el módulo de Teleconsulta en Diraya durante la pandemia, fue necesario:
- Realizar un análisis de requisitos urgente con los profesionales sanitarios
- Diseñar una solución que se integrara con la arquitectura existente
- Desarrollar y probar el módulo en tiempo récord
- Implantarlo progresivamente en todos los centros
- Mantenerlo y mejorarlo continuamente basándose en el feedback de los usuarios
Esto es un ciclo de vida real, aplicado a una necesidad crítica del sistema sanitario. Y tú vas a formar parte de proyectos así.
1.2. Importancia en la Oposición
He analizado los últimos 5 años de convocatorias del SAS, y puedo decirte que este tema es uno de los que más rentabilidad te va a dar en el examen. ¿Por qué? Porque es transversal. Te va a aparecer en:
- Preguntas directas sobre modelos de ciclo de vida, fases, metodologías…
- Preguntas sobre MÉTRICA v3 (la metodología oficial del sector público español)
- Preguntas sobre ISO/IEC 12207 (el estándar internacional de ciclo de vida del software)
- Preguntas sobre gestión de proyectos TIC en el SAS
- Casos prácticos donde tienes que elegir el modelo adecuado para una situación concreta
- Preguntas sobre metodologías ágiles (que son una evolución de los modelos clásicos)
1.3. Conexión con la Práctica Diaria en el SAS
Ahora déjame contarte algo importante. En el SAS no se trabaja con un único modelo de ciclo de vida. Dependiendo del proyecto, del sistema, de la urgencia, de los recursos disponibles… se utiliza un enfoque u otro:
- Para proyectos grandes y estables como migraciones de versiones mayores de sistemas críticos (por ejemplo, actualizar el core de Diraya), se suele usar un modelo más predictivo y planificado, similar al modelo en cascada o en V.
- Para desarrollos de nuevas funcionalidades o módulos no críticos, se aplican cada vez más metodologías ágiles con sprints cortos y entregas incrementales.
- Para validar nuevas ideas o explorar soluciones innovadoras (por ejemplo, un chatbot de atención al paciente, o un sistema de IA para ayuda al diagnóstico), se recurre al prototipado rápido.
- El mantenimiento evolutivo de sistemas ya implantados (como las mejoras continuas en Receta XXI, BDU, o InterSAS) sigue modelos iterativos e incrementales.
Por eso, no basta con memorizar definiciones. Tienes que entender cuándo aplicar cada modelo, sus ventajas, sus limitaciones, y cómo se integran en el ecosistema TIC del SAS.
2. 🔄 El Ciclo de Vida de los Sistemas de Información
2.1. Concepto y Definición
📖 Definición Fundamental
El Ciclo de Vida del Software (Software Development Life Cycle – SDLC) es el conjunto de fases, actividades y tareas que se llevan a cabo desde que se concibe la idea de crear o modificar un sistema de información hasta que este deja de utilizarse o es reemplazado.
Incluye todas las etapas: desde la planificación inicial, pasando por el análisis, diseño, desarrollo, pruebas, implantación y mantenimiento, hasta la retirada o sustitución del sistema.
Este concepto es crucial porque establece que un sistema de información no es solo «hacerlo funcionar». Un sistema tiene una vida útil, evoluciona, se mantiene, se adapta… y eventualmente se retira. Piensa en Diraya: comenzó como un proyecto hace más de 15 años, ha evolucionado continuamente, se han añadido módulos, se han migrado tecnologías… y seguirá evolucionando durante años.
2.2. Fases Genéricas del Ciclo de Vida
Aunque cada modelo de ciclo de vida puede organizar estas fases de forma diferente, existe un consenso sobre las actividades fundamentales que deben realizarse en cualquier desarrollo de software:
1️⃣ Planificación y Estudio de Viabilidad
Se identifica la necesidad, se define el alcance del proyecto, se evalúa la viabilidad técnica, económica y operativa. Se decide si el proyecto debe o no llevarse a cabo.
En el SAS: Comités de dirección TIC, análisis de necesidades asistenciales, evaluación de costes y beneficios para el sistema sanitario.
2️⃣ Análisis de Requisitos
Se determinan las necesidades funcionales y no funcionales del sistema. Se documenta QUÉ debe hacer el sistema, no CÓMO lo hará. Se genera el documento de especificación de requisitos.
En el SAS: Reuniones con profesionales sanitarios, gestores clínicos, usuarios finales. Análisis de procesos asistenciales. Cumplimiento normativo (RGPD, ENS, interoperabilidad).
3️⃣ Diseño del Sistema
Se define CÓMO se va a construir el sistema. Se diseña la arquitectura, las bases de datos, las interfaces, los módulos, los componentes. Se especifica el entorno tecnológico.
En el SAS: Definición de arquitectura que se integre con sistemas existentes (Diraya, BDU, Red Corporativa…). Diseño de seguridad conforme a ENS. Selección de tecnologías homologadas.
4️⃣ Implementación o Construcción
Se escribe el código, se desarrollan los módulos, se configuran los componentes. Se construye realmente el sistema según las especificaciones del diseño.
En el SAS: Desarrollo en entornos de desarrollo y preproducción. Uso de repositorios corporativos (GIT). Aplicación de estándares de codificación. Documentación del código.
5️⃣ Pruebas (Testing)
Se verifica que el sistema cumple con los requisitos especificados. Pruebas unitarias, de integración, de sistema, de aceptación. Se detectan y corrigen errores.
En el SAS: Pruebas en entornos controlados. Validación por usuarios clave (médicos, enfermeras, administrativos). Pruebas de carga, seguridad, integración con otros sistemas.
6️⃣ Implantación y Despliegue
Se pone el sistema en producción. Se migran datos, se forma a usuarios, se realiza el paso a producción de forma controlada (a veces gradual, a veces general).
En el SAS: Despliegues escalonados por centros o distritos. Formación a profesionales. Soporte intensivo durante arranque. Comunicación a usuarios y pacientes si procede.
7️⃣ Operación y Mantenimiento
El sistema está en producción y se usa diariamente. Se corrigen errores (mantenimiento correctivo), se adapta a cambios normativos o tecnológicos (mantenimiento adaptativo), se añaden mejoras (mantenimiento perfectivo).
En el SAS: Mesa de ayuda (ayudaDIGITAL), gestión de incidencias, actualizaciones periódicas, mejoras basadas en feedback de usuarios.
8️⃣ Retirada o Sustitución
El sistema llega al final de su vida útil y debe ser retirado o reemplazado por uno nuevo. Se migran datos, se archivan sistemas legacy, se documenta todo el proceso.
En el SAS: Migración a nuevas plataformas conservando históricos clínicos. Cumplimiento de plazos legales de conservación de datos sanitarios.
Respuesta correcta: C) Diseño del sistema
Porque en la fase de análisis se define el QUÉ (requisitos), mientras que en la fase de diseño se define el CÓMO (arquitectura, tecnología, componentes). ¡Cuidado con no confundirlas!
2.3. Importancia del Ciclo de Vida en el Desarrollo de Software
¿Por qué es tan importante tener un ciclo de vida bien definido? Porque sin él, el desarrollo de software sería caótico:
- Reduce riesgos: Al planificar y estructurar el proceso, se anticipan problemas y se minimizan errores costosos.
- Facilita la gestión: Permite estimar tiempos, recursos, costes. Fundamental para la gestión de proyectos TIC en la administración pública.
- Mejora la calidad: Al seguir fases ordenadas con criterios de calidad en cada una, el producto final es más robusto.
- Facilita la comunicación: Todos los implicados (desarrolladores, gestores, usuarios) saben en qué fase está el proyecto y qué se espera.
- Cumplimiento normativo: En el sector público (y más aún en sanidad), hay obligaciones legales sobre cómo se deben desarrollar los sistemas (seguridad, protección de datos, accesibilidad…).
- Mantenibilidad: Un sistema bien documentado y con un ciclo de vida definido es mucho más fácil de mantener y evolucionar.
🏥 Ejemplo Real: El Proyecto Diraya
Diraya (Historia Digital de Salud) es el sistema nuclear del SAS. Su desarrollo no fue algo improvisado. Siguió un ciclo de vida riguroso:
- Planificación (2000-2002): Análisis de la situación de historias clínicas en papel. Estudio de viabilidad técnica y económica de una historia clínica digital unificada.
- Análisis de Requisitos (2002-2003): Participación de miles de profesionales sanitarios para definir qué necesitaban en una historia clínica digital.
- Diseño (2003-2004): Arquitectura del sistema, bases de datos, módulos funcionales, integración con sistemas existentes.
- Desarrollo e Implantación Progresiva (2004-2011): Se fueron desarrollando módulos (atención primaria, urgencias, hospitalización…) y desplegando por fases en diferentes centros.
- Operación y Mantenimiento Evolutivo (2011-actualidad): El sistema está en producción permanente. Se realizan actualizaciones, se añaden funcionalidades (como teleconsulta, videoconferencia…), se adapta a nuevas normativas, se integra con nuevos sistemas…
Este proyecto ha costado cientos de millones de euros y ha movilizado a miles de profesionales. Sin un ciclo de vida bien definido, habría sido imposible gestionarlo.
3. 📚 Modelos Clásicos de Ciclo de Vida
Ahora vamos a ver los modelos más importantes. Cada uno tiene su filosofía, sus ventajas, sus limitaciones. Y aquí viene lo importante: en el examen del SAS te van a preguntar sobre estos modelos, pero también te pueden poner un caso práctico donde tengas que decidir cuál aplicar. Por eso no basta con memorizarlos… hay que entenderlos.
3.1. Modelo en Cascada (Waterfall Model)
📖 Definición y Características
El Modelo en Cascada, también conocido como Modelo Clásico o Lineal Secuencial, es el más antiguo y tradicional de los modelos de ciclo de vida. Fue propuesto por Winston Royce en 1970 y se caracteriza por ser un enfoque sistemático y secuencial.
En este modelo, cada fase debe completarse totalmente antes de pasar a la siguiente, como si fuera una cascada de agua que baja por escalones: no puedes subir el escalón hasta que el anterior esté completado.
Fases del Modelo en Cascada (según pregunta real del SAS 2019)
Pregunta 59 del examen 2019: «El ciclo de vida en cascada o ciclo de vida clásico, exige un enfoque sistemático y secuencial del desarrollo de software, que comienza en el nivel de la ingeniería de sistemas y avanza a través de fases secuenciales sucesivas. Indique cuáles son todas sus fases:»
Respuesta correcta: C) Ingeniería del software, análisis, diseño, codificación, pruebas, utilización, mantenimiento, sustitución.
Las fases completas del modelo en cascada son:
- Ingeniería del Software / Ingeniería de Sistemas: Planificación y estudio de viabilidad.
- Análisis de Requisitos: Definición de qué debe hacer el sistema.
- Diseño: Definición de cómo se construirá el sistema.
- Codificación / Implementación: Escritura del código.
- Pruebas: Verificación de que funciona correctamente.
- Utilización / Implantación: Puesta en producción.
- Mantenimiento: Operación y corrección de errores, mejoras.
- Sustitución / Retirada: Fin del sistema.
Ventajas del Modelo en Cascada
- ✅ Simplicidad y facilidad de comprensión: Es muy claro y fácil de explicar a gestores y no técnicos.
- ✅ Fácil de gestionar: Al ser secuencial, es sencillo planificar tiempos y recursos.
- ✅ Documentación completa: Cada fase genera documentación que sirve para la siguiente.
- ✅ Adecuado para proyectos con requisitos bien definidos y estables.
- ✅ Bueno para proyectos pequeños o con baja complejidad.
Desventajas del Modelo en Cascada
- ❌ Rigidez ante cambios: Si cambian los requisitos a mitad de proyecto, es muy costoso volver atrás.
- ❌ No hay producto funcional hasta el final: El cliente no ve nada hasta que está todo terminado. Si algo falla, se detecta tarde.
- ❌ Riesgo alto en proyectos complejos o innovadores: Si hay incertidumbre, este modelo no la maneja bien.
- ❌ No apto para desarrollos largos en entornos cambiantes.
- ❌ El feedback de usuarios llega muy tarde.
🏥 ¿Cuándo se usa en el SAS?
El modelo en cascada se utiliza en el SAS principalmente en:
- Proyectos de infraestructura crítica con requisitos muy claros: Por ejemplo, la actualización de versión mayor de un sistema operativo en servidores de producción. Los pasos están definidos, no hay mucha variabilidad.
- Migraciones de datos entre sistemas: Si ya sabes exactamente qué datos migrar, cómo transformarlos, dónde cargarlos… puedes planificarlo secuencialmente.
- Desarrollos donde la normativa es muy estricta: Si hay certificaciones que requieren documentación exhaustiva de cada fase (como sistemas críticos ENS-ALTO).
Pero hoy en día, para desarrollos de software nuevos, es poco común usar cascada puro. Se prefieren modelos más flexibles.
3.2. Modelo en V
📖 Definición y Características
El Modelo en V es una evolución del modelo en cascada que enfatiza la importancia de las pruebas y la verificación en cada fase del desarrollo. Su nombre viene de la forma de «V» que forman las fases: a la izquierda están las fases de especificación y diseño (descendiendo), y a la derecha las fases de pruebas (ascendiendo), conectadas entre sí.
La idea fundamental es que cada fase de desarrollo tiene asociada una fase de prueba específica:
| Fase de Desarrollo (descendente) | Fase de Prueba (ascendente) |
|---|---|
| Requisitos de Usuario | Pruebas de Aceptación |
| Requisitos del Sistema | Pruebas de Sistema |
| Diseño de Alto Nivel (Arquitectura) | Pruebas de Integración |
| Diseño Detallado (Módulos) | Pruebas Unitarias |
| Implementación / Codificación | |
Ventajas del Modelo en V
- ✅ Mayor énfasis en la calidad y las pruebas: Cada fase tiene su verificación asociada.
- ✅ Detección temprana de errores: Al planificar las pruebas desde el inicio, se pueden diseñar casos de prueba antes de codificar.
- ✅ Claridad en la relación entre especificación y verificación.
- ✅ Bueno para proyectos con requisitos estables y donde la calidad es crítica.
Desventajas del Modelo en V
- ❌ Similar al cascada en rigidez: Sigue siendo secuencial, difícil adaptarse a cambios.
- ❌ No hay prototipos intermedios ni feedback temprano del usuario.
- ❌ Requiere documentación exhaustiva desde el principio.
🏥 Aplicación en el SAS
El modelo en V es muy utilizado en el SAS para proyectos donde la calidad y la trazabilidad son críticas:
- Desarrollo de módulos críticos en sistemas de prescripción electrónica: Un error en Receta XXI puede tener consecuencias graves para la seguridad del paciente. Se requiere un proceso riguroso de verificación en cada fase.
- Integraciones entre sistemas sanitarios: Por ejemplo, la integración entre Diraya y el Sistema de Información Farmacéutica. Cada nivel de integración (interfaz, lógica de negocio, datos) tiene sus pruebas específicas.
- Desarrollos bajo normativa ENS de nivel ALTO: Donde se requiere documentar y verificar el cumplimiento de controles de seguridad en cada fase.
3.3. Modelo Incremental
📖 Definición y Características
El Modelo Incremental divide el desarrollo del sistema en incrementos o versiones. Cada incremento añade funcionalidad al sistema y es entregado al cliente.
La diferencia clave con el modelo en cascada es que no se espera a tener todo el sistema completo para entregarlo. Se entregan partes funcionales de forma progresiva, y cada una pasa por su propio mini-ciclo de análisis-diseño-implementación-pruebas.
Funcionamiento del Modelo Incremental
El sistema se divide en módulos o funcionalidades. Se desarrolla un núcleo básico funcional (incremento 1), y luego se van añadiendo incrementos sucesivos que amplían las capacidades:
- Incremento 1: Funcionalidades básicas y críticas del sistema. Se entrega y se pone en uso.
- Incremento 2: Se añaden más funcionalidades. Se entrega y se pone en uso.
- Incremento 3: Más funcionalidades… y así sucesivamente.
Ventajas del Modelo Incremental
- ✅ El cliente ve y usa el producto desde fases tempranas.
- ✅ Feedback continuo: Se puede ajustar el rumbo en incrementos posteriores según el feedback.
- ✅ Menor riesgo: Si un incremento falla, no se pierde todo el proyecto.
- ✅ Priorización de funcionalidades: Se desarrollan primero las más importantes o urgentes.
- ✅ Generación de valor desde el primer incremento.
Desventajas del Modelo Incremental
- ❌ Requiere una arquitectura bien planificada desde el inicio: Si no, añadir incrementos puede romper el sistema.
- ❌ Puede ser difícil dividir el sistema en incrementos independientes.
- ❌ Gestión más compleja: Múltiples versiones en paralelo, gestión de configuraciones.
🏥 Ejemplo Real: Despliegue de Diraya por Módulos
Diraya es un ejemplo perfecto de desarrollo incremental:
- Incremento 1 (2004-2005): Módulo básico de historia clínica para atención primaria. Se despliega en centros piloto.
- Incremento 2 (2005-2006): Se añade el módulo de urgencias.
- Incremento 3 (2006-2007): Módulo de hospitalización.
- Incremento 4 (2008-2009): Integración con receta electrónica.
- Incrementos sucesivos: Módulos de enfermería, agenda, videoconsulta, informe de alta, integración con dispositivos médicos…
Cada incremento añadía valor y funcionalidad. Los médicos ya podían usar el sistema desde el primer incremento, aunque fuera con funcionalidad limitada. Y con el feedback de cada incremento, se mejoraban los siguientes.
3.4. Modelo Iterativo
📖 Definición y Características
El Modelo Iterativo es similar al incremental, pero con una diferencia clave: en cada iteración se revisan, refinan y mejoran las versiones anteriores. No solo se añade funcionalidad nueva, sino que se perfecciona lo ya hecho.
Es como esculpir una estatua: en cada iteración vas afinando más los detalles, corrigiendo imperfecciones, ajustando proporciones… hasta llegar al resultado final.
Ventajas del Modelo Iterativo
- ✅ Adaptabilidad a cambios: En cada iteración se puede incorporar feedback y cambios de requisitos.
- ✅ Refinamiento progresivo: El sistema mejora en calidad con cada iteración.
- ✅ Aprendizaje continuo: El equipo aprende en cada ciclo y mejora el proceso.
- ✅ Bueno para proyectos con requisitos poco claros al inicio.
Desventajas del Modelo Iterativo
- ❌ Puede ser difícil estimar tiempos y costes totales: Depende de cuántas iteraciones sean necesarias.
- ❌ Riesgo de «iteración infinita»: Si no se definen criterios de finalización claros.
- ❌ Requiere buena gestión de versiones y configuraciones.
🏥 Aplicación en el SAS
El mantenimiento evolutivo de aplicaciones ya implantadas en el SAS sigue este modelo:
- InterSAS (portal del empleado): Se lanzan versiones periódicas que no solo añaden funcionalidades, sino que mejoran el diseño, la usabilidad, corrigen errores detectados en la versión anterior.
- ClicSalud+ (portal del ciudadano): Cada iteración incorpora nuevos servicios pero también refina los existentes según el feedback de los usuarios.
3.5. Modelo en Espiral
📖 Definición y Características
El Modelo en Espiral, propuesto por Barry Boehm en 1988, es un modelo que combina características del modelo en cascada con el prototipado, añadiendo un enfoque fundamental: la gestión de riesgos.
En lugar de ser lineal o incremental simple, este modelo representa el desarrollo como una espiral que se recorre varias veces. En cada vuelta de la espiral se pasa por las mismas fases, pero a un nivel de detalle cada vez mayor.
Fases de cada Ciclo (Vuelta de la Espiral)
- Determinar objetivos, alternativas y restricciones: Se define qué se quiere conseguir en esta iteración.
- Evaluar alternativas, identificar y resolver riesgos: Esta es la fase clave. Se analizan los riesgos (técnicos, de requisitos, de personal…) y se toman decisiones para mitigarlos. A menudo se construyen prototipos para evaluar alternativas.
- Desarrollar y verificar: Se desarrolla el producto (o parte de él) para esta iteración.
- Planificar la siguiente iteración: Se revisa lo hecho y se planifica la siguiente vuelta de la espiral.
Ventajas del Modelo en Espiral
- ✅ Gestión proactiva de riesgos: Es el modelo que mejor maneja proyectos de alta incertidumbre o complejidad.
- ✅ Flexibilidad: Se pueden incorporar cambios en cada ciclo.
- ✅ Uso de prototipos para validar decisiones críticas.
- ✅ Adecuado para proyectos grandes y complejos.
Desventajas del Modelo en Espiral
- ❌ Complejidad en la gestión: Requiere expertos en gestión de riesgos.
- ❌ Coste elevado: No es viable para proyectos pequeños.
- ❌ Requiere mucha experiencia del equipo.
🏥 ¿Cuándo se usaría en el SAS?
El modelo en espiral sería adecuado para:
- Proyectos innovadores con alta incertidumbre: Por ejemplo, el desarrollo de un sistema de Inteligencia Artificial para ayuda al diagnóstico radiológico. Hay muchos riesgos técnicos, regulatorios, éticos… que deben evaluarse en cada ciclo.
- Migración de sistemas legacy complejos: Migrar un sistema crítico de hace 20 años a una nueva plataforma tiene muchos riesgos (pérdida de datos, incompatibilidades, resistencia al cambio…). Cada ciclo de la espiral podría abordar una parte del sistema, evaluando riesgos y construyendo prototipos.
4. 🛠️ La Elaboración de Prototipos
4.1. Concepto y Definición
📖 ¿Qué es un Prototipo?
Un prototipo es una versión preliminar y simplificada de un sistema de información que se construye para validar requisitos, explorar soluciones técnicas o demostrar conceptos antes de desarrollar el sistema completo.
Es como un borrador funcional: no tiene todas las características del sistema final, pero permite a los usuarios y desarrolladores ver, tocar e interactuar con una representación del sistema para tomar decisiones informadas.
4.2. Tipos de Prototipos
A) Prototipos de Baja Fidelidad (Low-Fidelity Prototypes)
Son representaciones muy básicas, a menudo en papel o con herramientas de diseño simples. No son funcionales pero permiten visualizar conceptos.
- 📝 Bocetos en papel: Dibujos rápidos de interfaces.
- 🖼️ Wireframes: Esquemas de pantallas sin diseño visual.
- 📋 Mockups estáticos: Imágenes de cómo se verá el sistema.
B) Prototipos de Alta Fidelidad (High-Fidelity Prototypes)
Son versiones más elaboradas y funcionales, muy cercanas al producto final en apariencia y comportamiento.
- 💻 Prototipos interactivos: Se puede navegar y simular interacciones.
- 🎨 Con diseño visual completo: Colores, tipografías, imágenes reales.
- ⚙️ Con funcionalidad parcial: Algunos módulos funcionan realmente.
C) Prototipos Desechables (Throwaway Prototypes)
Se construyen solo para explorar o validar, y luego se descartan. El código no se reutiliza en el sistema final.
- ✅ Ventaja: Rapidez, no hay que preocuparse por calidad del código.
- ❌ Desventaja: Hay que reescribirlo todo después.
D) Prototipos Evolutivos (Evolutionary Prototypes)
El prototipo evoluciona hasta convertirse en el sistema final. Se parte de un prototipo básico y se va refinando y ampliando.
- ✅ Ventaja: No se pierde el trabajo inicial.
- ❌ Desventaja: Si el prototipo inicial tenía deuda técnica, puede arrastrarla.
4.3. Prototipado Rápido (Rapid Prototyping)
El prototipado rápido es una técnica que busca construir prototipos funcionales en el menor tiempo posible, usando herramientas de desarrollo ágil, frameworks, librerías, plantillas…
El objetivo es obtener feedback del usuario lo antes posible sin invertir meses en desarrollo. Es especialmente útil cuando:
- Los requisitos no están claros y hay que validarlos con los usuarios.
- Hay incertidumbre técnica y se necesita probar soluciones.
- Se quiere demostrar un concepto innovador a la dirección o a financiadores.
- Los usuarios finales no tienen experiencia previa con sistemas similares y necesitan «ver para creer».
4.4. Ventajas del Prototipado
- ✅ Validación temprana de requisitos: Los usuarios ven algo tangible y pueden decir «sí, esto es lo que necesito» o «no, esto no funciona así».
- ✅ Detección temprana de problemas de usabilidad: Es mejor descubrir que una pantalla es confusa en fase de prototipo que cuando el sistema ya está desarrollado.
- ✅ Mejor comunicación entre desarrolladores y usuarios: Es mucho más fácil entenderse viendo un prototipo que leyendo páginas de requisitos.
- ✅ Reducción de riesgos: Si una idea no funciona, se descubre pronto y con bajo coste.
- ✅ Motivación del equipo y los usuarios: Ver avances tangibles genera entusiasmo.
- ✅ Facilita la formación de usuarios: Se puede usar el prototipo para formar antes de que esté el sistema final.
4.5. Inconvenientes del Prototipado
- ❌ Expectativas poco realistas: Los usuarios ven el prototipo funcional y piensan «ya está casi hecho», cuando en realidad falta mucho trabajo (seguridad, rendimiento, integración…).
- ❌ Riesgo de quedarse con un prototipo de baja calidad: A veces hay presión para poner en producción un prototipo que no está preparado.
- ❌ Costes adicionales si no se gestiona bien: Si se hacen demasiados prototipos desechables sin tomar decisiones.
- ❌ Puede generar confusión en la documentación: Si el prototipo cambia mucho, la documentación puede quedar desfasada.
⚠️ Cuidado con el «Síndrome del Prototipo Eterno»
Un error común es quedarse atrapado en un ciclo de «hacer prototipos» sin nunca pasar a desarrollar el sistema real. O peor aún, poner en producción un prototipo que no tiene la robustez, seguridad o rendimiento necesarios. En el SAS, donde se manejan datos críticos de salud de millones de personas, esto es inaceptable.
4.6. Aplicación del Prototipado en el SAS
🏥 Casos Reales de Prototipado en el SAS
Ejemplo 1: Nueva Interfaz de Diraya para Profesionales
Cuando se planteó rediseñar la interfaz de Diraya para hacerla más moderna y usable, se crearon prototipos de alta fidelidad con diferentes propuestas de diseño. Se hicieron pruebas de usabilidad con médicos, enfermeras y administrativos de diferentes centros, recogiendo su feedback sobre qué diseño era más intuitivo, dónde encontraban dificultades, qué funcionalidades echaban de menos…
Resultado: Se evitó desarrollar una interfaz que luego los usuarios no aceptaran. El coste del prototipado fue mínimo comparado con el ahorro de no tener que rehacer todo el desarrollo.
Ejemplo 2: App de Autocita para Especialistas
Antes de desarrollar una app completa para que los pacientes pudieran solicitar citas de especialista desde su móvil, se creó un prototipo interactivo usando una herramienta de diseño (Figma). Se probó con un grupo de pacientes de diferentes perfiles (jóvenes, mayores, con diferentes niveles de habilidad digital).
Resultado: Se detectó que el flujo inicial era demasiado complejo para personas mayores. Se simplificó el proceso antes de escribir ni una línea de código.
Ejemplo 3: Dashboard de Indicadores para Gestión Clínica
Se necesitaba un cuadro de mando para que los directores de centros sanitarios pudieran ver indicadores clave (listas de espera, consumo farmacéutico, frecuentación…). En lugar de desarrollar el sistema completo, se creó un prototipo con datos de ejemplo y se presentó a un grupo de directores.
Resultado: Los directores pidieron cambios importantes en los indicadores mostrados y en el formato de presentación. Si se hubiera desarrollado sin prototipo, habría habido que rehacerlo.
4.7. Herramientas para Prototipado (Contexto SAS)
En el SAS se utilizan diversas herramientas según el tipo de prototipo:
| Tipo de Prototipo | Herramientas Comunes | Uso en el SAS |
|---|---|---|
| Baja Fidelidad | Balsamiq, Wireframe.cc, Papel y lápiz | Fases iniciales de requisitos |
| Alta Fidelidad | Figma, Adobe XD, Sketch | Validación de interfaces con usuarios |
| Funcionales Web | HTML/CSS/JavaScript, frameworks (Angular, React) | Prototipos interactivos de aplicaciones web |
| Funcionales Backend | Python + Flask, Node.js, APIs mock | Validación de lógica de negocio |
| Bases de Datos | SQLite, PostgreSQL (entorno desarrollo) | Prototipos de modelo de datos |
💡 Consejo para el Examen
En preguntas sobre prototipos, recuerda que:
- El prototipado es especialmente útil cuando los requisitos no están claros o cuando hay incertidumbre técnica.
- Los prototipos desechables son más rápidos pero hay que reescribirlos. Los prototipos evolutivos se convierten en el sistema final.
- El prototipado rápido es clave en metodologías ágiles.
- Siempre menciona las ventajas (validación temprana, comunicación) y las desventajas (expectativas poco realistas, riesgo de quedarse con un prototipo de baja calidad).
5. 📐 Metodologías y Marcos de Referencia
Hasta ahora hemos visto modelos genéricos de ciclo de vida. Pero en la práctica, especialmente en la administración pública y en proyectos grandes, se utilizan metodologías estructuradas que definen en detalle cómo aplicar esos modelos: qué actividades hacer, qué documentos generar, qué roles participan, qué técnicas usar…
En el SAS (y en general en la administración pública española), las metodologías más importantes son:
5.1. MÉTRICA v3
📖 ¿Qué es MÉTRICA v3?
MÉTRICA v3 es la metodología de planificación, desarrollo y mantenimiento de sistemas de información promovida por el Ministerio de Asuntos Económicos y Transformación Digital (antiguo Ministerio de Hacienda y Administraciones Públicas).
Es una metodología de obligado cumplimiento en la Administración General del Estado y recomendada para todas las administraciones públicas en España, incluido el SAS.
Pregunta 17: «La metodología de planificación y desarrollo de sistemas de información MÉTRICA, del Consejo Superior de Informática, consta de los siguientes documentos:»
Respuesta correcta: A) Estructura principal, Interfaces, Técnicas y Participantes.
Estructura de MÉTRICA v3
MÉTRICA v3 está organizada en tres grandes procesos principales:
- Planificación de Sistemas de Información (PSI)
- Objetivo: Elaborar un plan de sistemas de información que dé respuesta a las necesidades estratégicas de la organización.
- Actividades: Estudio de la situación actual, definición de requisitos, estudio de alternativas, valoración y selección.
- Desarrollo de Sistemas de Información
- Estudio de Viabilidad del Sistema (EVS): Análisis de viabilidad técnica, económica y operativa.
- Análisis del Sistema de Información (ASI): Requisitos funcionales y no funcionales.
- Diseño del Sistema de Información (DSI): Arquitectura, diseño detallado.
- Construcción del Sistema de Información (CSI): Codificación, pruebas unitarias.
- Implantación y Aceptación del Sistema (IAS): Despliegue, formación, aceptación.
- Mantenimiento de Sistemas de Información (MSI)
- Mantenimiento Correctivo (corrección de errores)
- Mantenimiento Perfectivo (mejoras)
- Mantenimiento Adaptativo (cambios normativos o tecnológicos)
Pregunta 64: «La metodología de planificación y desarrollo de sistemas de información METRICA.»
Respuesta correcta: B) Ha sido concebida para abarcar el desarrollo completo de sistemas sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto.
Esto es importante: MÉTRICA es escalable. No todos los proyectos necesitan aplicar todas las actividades y generar todos los documentos. Se adapta según el tamaño y complejidad del proyecto.
Interfaces de MÉTRICA v3
MÉTRICA v3 define interfaces con otros procesos y metodologías:
- Gestión de Proyectos: Interfaz con metodologías como PMBOK o PRINCE2.
- Seguridad: Interfaz con Magerit (análisis de riesgos) y ENS.
- Gestión de la Configuración: Control de versiones, gestión de cambios.
- Aseguramiento de la Calidad: Revisiones, auditorías.
Aplicación de MÉTRICA v3 en el SAS
🏥 Uso Real en Proyectos del SAS
Aunque el SAS es de la Junta de Andalucía (no del Estado), utiliza MÉTRICA v3 como referencia en muchos proyectos grandes, especialmente aquellos:
- Con financiación europea o estatal (que exigen cumplimiento de MÉTRICA).
- De gran envergadura que requieren documentación exhaustiva.
- Donde se exige certificación o auditoría externa.
Ejemplos: Proyectos de interoperabilidad con el Sistema Nacional de Salud, desarrollos de sistemas críticos con cumplimiento ENS-ALTO, proyectos de Historia Clínica Única.
5.2. ISO/IEC 12207
📖 ¿Qué es ISO/IEC 12207?
ISO/IEC 12207 es el estándar internacional que establece un marco común para los procesos del ciclo de vida del software. Define qué procesos deben existir (no cómo implementarlos en detalle, eso lo hace cada metodología como MÉTRICA).
Pregunta 40: «¿Cuál es el propósito principal de la Norma ISO/IEC 12207?»
Respuesta correcta: B) Establecer un conjunto de procesos para el ciclo de vida del software.
La ISO/IEC 12207 tiene como objetivo principal establecer un conjunto de procesos comunes para el ciclo de vida del software, cubriendo desde la adquisición hasta la operación y mantenimiento.
Estructura de ISO/IEC 12207
La norma organiza los procesos en tres grandes categorías:
- Procesos Principales (Primary Processes):
- Adquisición
- Suministro
- Desarrollo
- Operación
- Mantenimiento
- Procesos de Soporte (Supporting Processes):
- Documentación
- Gestión de la Configuración
- Aseguramiento de la Calidad
- Verificación
- Validación
- Revisión Conjunta
- Auditoría
- Resolución de Problemas
- Procesos Organizativos (Organizational Processes):
- Gestión
- Infraestructura
- Mejora
- Formación
Relación entre MÉTRICA v3 y ISO/IEC 12207
MÉTRICA v3 está alineada con ISO/IEC 12207. Lo que hace MÉTRICA es dar una implementación concreta y detallada de los procesos definidos en ISO/IEC 12207, adaptada al contexto de la administración pública española.
5.3. MADEJA
📖 ¿Qué es MADEJA?
MADEJA (Marco de Desarrollo de la Junta de Andalucía) es la adaptación de MÉTRICA v3 al contexto específico de la Junta de Andalucía.
Fue creada por la Consejería de Economía, Innovación, Ciencia y Empleo (hoy Transformación Económica, Industria, Conocimiento y Universidades) para proporcionar un marco metodológico propio, ajustado a las particularidades organizativas y tecnológicas de la administración andaluza.
Pregunta 65: «MADEJA (El Marco de desarrollo de la junta de Andalucía).»
La pregunta validaba conocimientos sobre la existencia y aplicación de MADEJA en proyectos de la Junta de Andalucía.
Características de MADEJA
- Basada en MÉTRICA v3: Mantiene la estructura de procesos de MÉTRICA pero con adaptaciones.
- Incorpora buenas prácticas específicas: Uso de herramientas corporativas de la Junta, integración con repositorios de código, estándares de documentación propios.
- Orientada a la reutilización: Fomenta el uso de componentes y servicios reutilizables entre proyectos de la Junta.
- Integración con el ciclo de contratación: Tiene en cuenta los procesos de licitación pública.
Aplicación en el SAS
🏥 MADEJA en Proyectos del SAS
El SAS, como organismo de la Junta de Andalucía, utiliza MADEJA en proyectos propios, especialmente:
- Desarrollos internos realizados por equipos de la Dirección General de Sistemas de Información y Comunicaciones del SAS.
- Proyectos donde intervienen empresas públicas de la Junta (por ejemplo, SANDETEL).
- Proyectos que deben integrarse con infraestructuras corporativas de la Junta (Red Corporativa, repositorios Git…).
5.4. Introducción a Metodologías Ágiles
Aunque este tema se profundiza en el Tema 15 (Desarrollo Ágil de Software), es importante mencionar aquí que las metodologías ágiles (Scrum, Kanban, XP…) representan una evolución de los modelos de ciclo de vida tradicionales.
Pregunta 60 (2019): «El desarrollo ágil de software. Indique la incorrecta»
Respuesta correcta: C) La planificación se realizar una tras otra en un ciclo secuencial o en cascada.
❌ Esto es INCORRECTO porque en ágil NO se planifica todo de forma secuencial. Se planifica de forma iterativa e incremental.
Pregunta 61 (2019): «Un método de desarrollo de software ágil es:»
Respuesta correcta: C) KANBAN.
Pregunta 41 (2025): «Indique cuál de las siguientes afirmaciones NO es correcta en relación a los métodos de desarrollo ágil:»
Respuesta correcta: D) El diagrama de Gantt es uno de los elementos fundamentales de un tablero de Kanban.
❌ Esto es FALSO. Kanban usa tableros Kanban, no diagramas de Gantt (que son de gestión predictiva).
Diferencias entre Modelos Tradicionales y Ágiles
| Aspecto | Modelos Tradicionales | Metodologías Ágiles |
|---|---|---|
| Planificación | Planificación completa al inicio | Planificación adaptativa, iteración por iteración |
| Requisitos | Se definen todos al inicio y se congelan | Se priorizan y pueden cambiar en cada iteración |
| Entregas | Una sola entrega al final (o pocas entregas grandes) | Entregas frecuentes (cada 1-4 semanas) |
| Documentación | Extensa documentación en cada fase | Documentación suficiente, prioriza software funcionando |
| Cambios | Costosos y problemáticos | Bienvenidos y gestionados |
| Feedback | Tardío (al final del proyecto) | Continuo (al final de cada iteración) |
| Riesgos | Se detectan tarde | Se detectan y mitigan continuamente |
🏥 Coexistencia de Enfoques en el SAS
En el SAS, no se usa un único enfoque. Según el proyecto:
- Proyectos críticos grandes con requisitos estables: Enfoques tradicionales (MÉTRICA, modelo en V).
- Desarrollos de nuevas funcionalidades en sistemas existentes: Metodologías ágiles (Scrum, Kanban).
- Proyectos de innovación o exploración: Prototipado ágil.
- Mantenimiento evolutivo: Modelos iterativos e incrementales con elementos ágiles.
Lo importante es elegir el enfoque adecuado según el contexto.
6. 🏥 Aplicación Práctica en el SAS
6.1. El Modelo Corporativo Marco de Implantaciones del SAS
Pregunta 37: «¿Cuáles son las fases principales del Modelo Corporativo Marco de Implantaciones del Servicio Andaluz de Salud?»
Respuesta correcta: A) Análisis Preliminar de Situación, Reingeniería de Procesos, Preimplantación, Implantación, Arranque, Consolidación y Extensión.
El SAS tiene su propio Modelo Corporativo Marco de Implantaciones, específico para el despliegue de sistemas de información en el entorno sanitario. No es exactamente un modelo de desarrollo, sino un modelo de implantación, pero está íntimamente ligado al ciclo de vida.
Fases del Modelo de Implantaciones del SAS
1. Análisis Preliminar de Situación
Se analiza la situación actual del centro o área donde se va a implantar el sistema. Se identifican necesidades específicas, flujos de trabajo actuales, problemas a resolver.
2. Reingeniería de Procesos
Se rediseñan los procesos asistenciales para adaptarlos al nuevo sistema. No se trata solo de «informatizar lo que se hacía en papel», sino de aprovechar las capacidades del sistema para mejorar los procesos.
3. Preimplantación
Se prepara el terreno: infraestructuras, formación de formadores, configuración inicial del sistema, migración de datos piloto, pruebas en entorno controlado.
4. Implantación
Puesta en marcha efectiva del sistema en el centro. Los usuarios empiezan a utilizarlo en producción. Suele hacerse de forma progresiva (por servicios, por módulos…).
5. Arranque
Primeras semanas de uso real. Hay soporte intensivo in situ. Se resuelven dudas, se corrigen pequeños problemas de configuración, se ajustan flujos.
6. Consolidación
El sistema ya está integrado en el día a día. Se mide el grado de uso, se recoge feedback, se hacen ajustes finos. El soporte pasa a ser menos intensivo.
7. Extensión
Una vez consolidado en un centro o área, se extiende a otros centros, siguiendo el mismo ciclo.
🏥 Ejemplo: Implantación de Diraya en un Hospital
Cuando Diraya se implanta en un nuevo hospital, no se hace de golpe en todo el hospital. Se sigue el Modelo de Implantaciones:
- Análisis Preliminar: Se visita el hospital, se habla con jefes de servicio, se entiende cómo trabajan actualmente.
- Reingeniería: Se rediseñan circuitos (por ejemplo, cómo se piden pruebas, cómo se consultan resultados) para aprovechar las capacidades de Diraya.
- Preimplantación: Se preparan los puestos de trabajo, se forma a referentes TIC del hospital, se migran datos de pacientes al sistema.
- Implantación: Se empieza por consultas externas, luego urgencias, luego hospitalización… de forma escalonada.
- Arranque: Durante las primeras semanas, hay técnicos del SAS in situ resolviendo dudas de los médicos y enfermeras.
- Consolidación: Tras unos meses, el hospital ya trabaja con normalidad en Diraya.
- Extensión: La experiencia de este hospital sirve para implantar en el siguiente.
6.2. Gestión de la Configuración del Software en el SAS
Pregunta 44: «Seleccione la respuesta correcta en relación a la gestión de configuración del software:»
Respuesta correcta: A) Son un conjunto de actividades desarrolladas para gestionar los cambios a lo largo del ciclo de vida.
La gestión de configuración del software es un conjunto de actividades diseñadas para gestionar y controlar los cambios en los artefactos de software a lo largo de todo su ciclo de vida. No es exclusiva de la fase de diseño, no es un método ágil, y aunque incluye control de versiones, su alcance es mucho más amplio.
La Gestión de la Configuración del Software es fundamental en el SAS porque:
- Se trabaja con múltiples versiones de sistemas (desarrollo, preproducción, producción).
- Hay múltiples equipos trabajando en paralelo en diferentes módulos.
- Es crítico poder volver atrás si una actualización causa problemas.
- Se necesita trazabilidad total de qué cambios se hicieron, cuándo, por quién, por qué.
Herramientas de Gestión de Configuración en el SAS
🏥 Herramientas Corporativas del SAS
- GIT: Control de versiones de código fuente. Usado en todos los proyectos de desarrollo del SAS. Repositorios en servidores corporativos (GitLab o similar).
- JIRA: Gestión de proyectos, incidencias, cambios. Trazabilidad de requisitos.
- Confluence: Gestión del conocimiento, documentación técnica, manuales.
- ayudaDigital: Sistema de tickets para gestión de incidencias y peticiones de usuarios.
6.3. Tipos de Mantenimiento en el SAS
Pregunta 63: «Mantenimiento ‘perfectivo’ es:»
Respuesta correcta: C) Modificaciones, mejoras o ampliaciones solicitadas por los usuarios, puesto que se produce una modificación de los requisitos iniciales aumentando las funcionalidades.
El mantenimiento de software representa entre el 60-80% del coste total del ciclo de vida de un sistema. En el SAS, con sistemas críticos en producción 24/7, el mantenimiento es constante.
Tipos de Mantenimiento
| Tipo | Definición | Ejemplo en el SAS |
|---|---|---|
| Correctivo | Corrección de errores y defectos detectados | Corregir un bug que impide generar informes en Diraya |
| Adaptativo | Adaptación a cambios normativos o tecnológicos | Adaptar Receta XXI a una nueva normativa farmacéutica |
| Perfectivo | Mejoras y ampliaciones de funcionalidades | Añadir videoconsulta a Diraya por petición de los usuarios |
| Preventivo | Mejoras para prevenir futuros problemas | Refactorizar código antiguo para mejorar mantenibilidad |
7. 🎓 Conclusiones y Claves para el Examen
🎯 Recapitulación Final
Hemos recorrido un tema fundamental que es la base de todo el desarrollo de software en el SAS. Este tema no es solo teoría de libro… es el día a día de cómo se construyen, mantienen y evolucionan los sistemas que sostienen la sanidad andaluza.
Recuerda que el ciclo de vida del software no es un proceso lineal y cerrado. Es un proceso vivo, que se adapta al contexto, a las necesidades, a la tecnología disponible. En el SAS conviven diferentes modelos y metodologías porque cada proyecto tiene sus particularidades.
7.1. Ideas Clave que Debes Dominar
✅ Para Memorizar
- Fases genéricas del ciclo de vida: Planificación, Análisis, Diseño, Implementación, Pruebas, Implantación, Mantenimiento, Retirada.
- Modelo en Cascada: Secuencial, rígido. Fases completas: Ingeniería del software, análisis, diseño, codificación, pruebas, utilización, mantenimiento, sustitución.
- Modelo en V: Similar a cascada pero con énfasis en verificación y validación. Cada fase de desarrollo tiene su fase de pruebas asociada.
- Modelo Incremental: Entrega de funcionalidad en incrementos sucesivos. El cliente ve producto desde fases tempranas.
- Modelo Iterativo: Similar al incremental pero con refinamiento de lo ya hecho en cada iteración.
- Modelo en Espiral: Enfatiza la gestión de riesgos. Cada ciclo tiene: objetivos, evaluación de riesgos, desarrollo, planificación siguiente iteración.
- Prototipos: Versiones preliminares para validar requisitos o soluciones. Pueden ser desechables o evolutivos, de baja o alta fidelidad.
- MÉTRICA v3: Metodología de la AGE para desarrollo de SI. Documentos: Estructura principal, Interfaces, Técnicas, Participantes. Escalable según proyecto.
- ISO/IEC 12207: Estándar internacional de procesos de ciclo de vida del software. Procesos principales, de soporte y organizativos.
- MADEJA: Adaptación de MÉTRICA v3 a la Junta de Andalucía.
- Modelo de Implantaciones del SAS: Análisis Preliminar, Reingeniería de Procesos, Preimplantación, Implantación, Arranque, Consolidación, Extensión.
- Tipos de mantenimiento: Correctivo (errores), Adaptativo (cambios normativos/tecnológicos), Perfectivo (mejoras/ampliaciones), Preventivo (prevenir problemas futuros).
7.2. Estrategia de Memorización
🧠 Técnicas para Estudiar Este Tema
- Mapas mentales: Haz un mapa con los modelos de ciclo de vida en el centro y sus características en ramas.
- Tablas comparativas: Crea tablas comparando ventajas/desventajas de cada modelo.
- Casos prácticos: Para cada modelo, piensa en un proyecto del SAS donde aplicaría.
- Flashcards (Anki): Pregunta-respuesta rápida para memorizar fases, definiciones, normativas.
- Reescribe con tus palabras: No memorices textualmente. Entiende y explica con tus palabras.
- Practica con preguntas reales: Usa el cuestionario de este tema y los exámenes anteriores del SAS.
7.3. Conexiones con Otros Temas
Este tema es absolutamente transversal. Se conecta con:
- Tema 15 (Desarrollo Ágil): Las metodologías ágiles son una evolución de los modelos de ciclo de vida tradicionales.
- Tema 12 (ITIL): El ciclo de vida del servicio en ITIL tiene paralelismos con el ciclo de vida del software.
- Tema 13 (Herramientas de gestión TIC): JIRA, Confluence, GIT… son herramientas que soportan el ciclo de vida del software.
- Tema 35 (Seguridad TIC): La seguridad debe integrarse en todas las fases del ciclo de vida (DevSecOps).
- Tema 37 (Análisis de Riesgos – MAGERIT): El análisis de riesgos se hace en fase de planificación/diseño.
- Temas de Sistemas del SAS (42, 43, 44…): Todos los sistemas del SAS han pasado por un ciclo de vida.
7.4. Errores Comunes a Evitar
⚠️ Trampas Frecuentes en el Examen
- ❌ Confundir fases: Análisis (QUÉ) vs Diseño (CÓMO). En análisis se definen requisitos, en diseño se define arquitectura y tecnología.
- ❌ Pensar que cascada no tiene mantenimiento: El cascada SÍ incluye mantenimiento y sustitución al final.
- ❌ Creer que incremental e iterativo son lo mismo: Incremental añade funcionalidad nueva, iterativo refina la existente (aunque en la práctica muchas veces se combinan).
- ❌ Decir que ISO 12207 es una metodología: NO, es un estándar de procesos. MÉTRICA es una metodología que implementa ISO 12207.
- ❌ Afirmar que MÉTRICA es inflexible: MÉTRICA es escalable y se adapta al tamaño del proyecto.
- ❌ Confundir tipos de mantenimiento: Perfectivo es añadir funcionalidad (mejoras), no corregir errores (eso es correctivo).
8. 📝 Cuestionario de Evaluación (30 Preguntas)
Ahora vamos a poner a prueba lo que has aprendido. Este cuestionario incluye preguntas reales que han caído en exámenes del SAS y otras que he elaborado siguiendo el mismo estilo. Lee con atención cada pregunta y todas las opciones antes de responder. En el examen real no puedes volver atrás, así que acostúmbrate a decidir bien a la primera.
Explicación:
Esta pregunta cayó en el examen de 2025 (Reserva 151). La fase de Diseño del sistema es donde se traduce el «qué» (definido en análisis) en el «cómo». Aquí se establece la arquitectura general, se seleccionan tecnologías, se definen módulos, interfaces y se detallan componentes antes de la implementación real.
Por qué las otras son incorrectas:
- A) Análisis: Aquí se define QUÉ debe hacer el sistema (requisitos), no CÓMO se construirá.
- B) Estudio de viabilidad: Se evalúa si el proyecto es viable técnica, económica y operativamente. No se diseña aún.
- D) Construcción: Aquí se implementa (se codifica) lo que ya se diseñó.
Explicación:
Pregunta real del examen de 2019. El modelo en cascada completo incluye todas estas fases: comienza con la Ingeniería del software (planificación y estudio de viabilidad), pasa por análisis, diseño, codificación, pruebas, utilización (implantación y operación), mantenimiento y finalmente sustitución.
Las opciones A y B están incompletas, no incluyen todas las fases del ciclo completo.
Explicación:
La opción C es FALSA y por tanto es la correcta (se pregunta cuál NO es ventaja). El modelo en cascada es rígido ante cambios. Si cambian los requisitos a mitad de proyecto, es muy costoso volver atrás porque las fases son secuenciales.
Las opciones A, B y D son ventajas reales del modelo en cascada.
Explicación:
La característica fundamental del Modelo en V es que cada fase de desarrollo (descendente) tiene asociada una fase de prueba específica (ascendente): Requisitos↔Aceptación, Diseño alto nivel↔Integración, Diseño detallado↔Unitarias.
Por qué las otras son incorrectas:
- A: El modelo en V SÍ incluye pruebas (de hecho, las enfatiza).
- C: El modelo en V es tan rígido como el cascada ante cambios, NO es más flexible que ágil.
- D: Requiere documentación exhaustiva, no prescinde de ella.
Explicación:
La diferencia clave es:
- Incremental: En cada incremento se añade funcionalidad nueva al sistema. El incremento 1 tiene funciones básicas, el 2 añade más funciones, el 3 más…
- Iterativo: En cada iteración se revisa y refina lo ya hecho, además de posiblemente añadir cosas nuevas. Es un proceso de mejora progresiva.
En la práctica, muchos proyectos combinan ambos enfoques (iterativo e incremental).
Explicación:
El Modelo en Espiral es el que más énfasis pone en la gestión de riesgos. En cada vuelta de la espiral se identifican y evalúan riesgos, y se toman decisiones para mitigarlos (a menudo mediante prototipos).
Por qué las otras son incorrectas:
- A: NO es el más rápido ni económico. Es complejo y costoso de gestionar.
- C: NO elimina la documentación.
- D: Es adecuado para proyectos grandes y complejos, no pequeños.
Explicación:
La opción B es FALSA (por tanto, correcta como respuesta a la pregunta). Los prototipos evolutivos NO se descartan, sino que evolucionan hasta convertirse en el sistema final.
Los que se descartan son los prototipos desechables (throwaway).
Las otras tres opciones son verdaderas.
Explicación:
Pregunta real del examen de 2023. MÉTRICA v3 se estructura en cuatro documentos principales:
- Estructura principal: Describe los procesos (PSI, Desarrollo, Mantenimiento).
- Interfaces: Conexiones con otras metodologías (gestión de proyectos, seguridad…).
- Técnicas: Técnicas específicas aplicables (modelado de datos, casos de uso…).
- Participantes: Roles y responsabilidades en cada proceso.
Explicación:
Pregunta real del examen de 2025. La Norma ISO/IEC 12207 tiene como objetivo principal establecer un conjunto de procesos comunes para el ciclo de vida del software, cubriendo desde la adquisición hasta la operación y mantenimiento.
Por qué las otras son incorrectas:
- A: No se enfoca en hardware, sino en software.
- C: Abarca TODO el ciclo de vida, no solo pruebas.
- D: No es solo para validación en operación, sino para todo el ciclo de vida.
Explicación:
Pregunta real del examen de 2019. MÉTRICA v3 es escalable y adaptable. No todos los proyectos requieren aplicar todas las actividades ni generar todos los documentos. Se dimensiona según el tamaño, complejidad y características específicas de cada proyecto.
Por qué las otras son incorrectas:
- A: NO debe aplicarse en su totalidad siempre, es escalable.
- C: MÉTRICA NO es ágil, es una metodología tradicional (aunque puede integrar prácticas ágiles).
- D: Se aplica principalmente en el sector público, no privado.
Explicación:
MADEJA es la adaptación de MÉTRICA v3 a las particularidades organizativas y tecnológicas de la Junta de Andalucía. Mantiene la estructura de MÉTRICA pero con ajustes específicos, uso de herramientas corporativas de la Junta, estándares propios de documentación…
Explicación:
Pregunta real del examen de 2025. El Modelo Corporativo Marco de Implantaciones del SAS define estas 7 fases específicas para el despliegue de sistemas de información en el entorno sanitario. Memoriza esta secuencia porque es muy probable que caiga en tu examen.
Explicación:
Pregunta real del examen de 2019. La opción C es INCORRECTA (y por tanto la respuesta correcta). En desarrollo ágil la planificación NO se realiza de forma secuencial o en cascada. Se planifica de forma iterativa e incremental, con planificación adaptativa en cada iteración.
Las otras tres opciones SÍ son características correctas del desarrollo ágil.
Explicación:
Pregunta real del examen de 2019. KANBAN es un método de desarrollo ágil que se basa en la visualización del flujo de trabajo mediante un tablero Kanban, limitación del trabajo en curso (WIP), y gestión del flujo.
Las otras opciones (AGSCRUM, GKAMBU, PUKAM) son inventadas, no existen como metodologías reales.
Explicación:
Pregunta real del examen de 2025. La opción D es FALSA (por tanto, correcta como respuesta). Kanban NO usa diagramas de Gantt (que son de gestión de proyectos tradicional predictiva). Kanban usa tableros Kanban con columnas que representan estados del flujo de trabajo.
Las opciones A, B y C son correctas sobre Scrum y Kanban.
Explicación:
Pregunta real del examen de 2019. El mantenimiento perfectivo consiste en mejoras y ampliaciones de funcionalidades solicitadas por los usuarios. No es corregir errores (eso sería correctivo), ni adaptarse a cambios externos (eso sería adaptativo).
Mnemotecnia: Perfectivo = hacer el sistema más perfecto, añadiendo cosas que lo mejoran o amplían.
Explicación:
Pregunta real del examen de 2025. La gestión de configuración del software es un conjunto de actividades diseñadas para gestionar y controlar los cambios en los artefactos de software a lo largo de todo su ciclo de vida.
Por qué las otras son incorrectas:
- B: NO se aplica exclusivamente en diseño, se aplica en TODO el ciclo de vida.
- C: NO es un método ágil, es una disciplina de soporte al desarrollo.
- D: Incluye control de versiones, pero su alcance es mucho más amplio y se aplica en todo el ciclo de vida, no solo en desarrollo.
Explicación:
«Desarrollo de código» NO es una fase del Modelo de Implantaciones del SAS. Este modelo es específico para implantar sistemas ya desarrollados, no para desarrollarlos.
Las 7 fases son: Análisis Preliminar de Situación, Reingeniería de Procesos, Preimplantación, Implantación, Arranque, Consolidación y Extensión.
Explicación:
GIT es la herramienta de control de versiones de código fuente utilizada en el SAS. Permite gestionar diferentes versiones del código, trabajar en ramas, fusionar cambios, tener trazabilidad completa de modificaciones…
Las otras herramientas tienen otros usos:
- JIRA: Gestión de proyectos e incidencias.
- Confluence: Gestión del conocimiento y documentación.
- ayudaDigital: Mesa de ayuda (tickets de usuarios).
Explicación:
Para un proyecto con requisitos poco claros, alta incertidumbre técnica y necesidad de validación continua, el Modelo en Espiral es el más adecuado porque:
- Gestiona riesgos proactivamente en cada ciclo.
- Permite construir prototipos para validar soluciones antes de comprometerse.
- Es iterativo, permite ir refinando requisitos según se aprende.
Los modelos en cascada y en V son demasiado rígidos para este contexto. También podrían aplicarse metodologías ágiles con prototipado rápido.
Explicación:
En MÉTRICA v3, PSI significa Planificación de Sistemas de Información. Es el proceso que elabora un plan de sistemas de información que dé respuesta a las necesidades estratégicas de la organización.
Explicación:
La ISO/IEC 12207 organiza los procesos en:
- Procesos Principales: Adquisición, Suministro, Desarrollo, Operación, Mantenimiento.
- Procesos de Soporte: Documentación, Gestión de Configuración, QA, Verificación, Validación…
- Procesos Organizativos: Gestión, Infraestructura, Mejora, Formación.
«Procesos de Desarrollo Ágil» NO es una categoría de ISO/IEC 12207.
Explicación:
Un prototipo desechable (throwaway) se construye solo para explorar o validar, y luego se descarta. El código no se reutiliza en el sistema final. Su ventaja es la rapidez, su desventaja es que hay que reescribir todo después.
Explicación:
La Reingeniería de Procesos en el Modelo de Implantaciones del SAS consiste en rediseñar los procesos asistenciales para aprovechar las capacidades del nuevo sistema. No se trata solo de «informatizar lo que se hacía en papel», sino de mejorar y optimizar los flujos de trabajo.
Por ejemplo, cuando se implanta Diraya, se rediseña cómo se piden pruebas, cómo se consultan resultados, cómo circula la información entre profesionales… para hacerlo más eficiente con el nuevo sistema.
Explicación:
El mantenimiento adaptativo consiste en adaptaciones requeridas por cambios externos: cambios normativos (nueva ley de protección de datos), evolución tecnológica (actualización de sistema operativo en servidores), cambios en sistemas con los que se integra…
Ejemplo en el SAS: Adaptar Receta XXI cuando cambia la normativa farmacéutica sobre prescripción de ciertos medicamentos.
Diferencias con otros tipos:
- Correctivo: Corregir errores (opción A).
- Perfectivo: Añadir funcionalidades (opción C).
- Preventivo: Mejorar calidad interna (opción D).
Explicación:
Cuando los requisitos están muy bien definidos y la calidad y trazabilidad son críticas (como en sistemas sanitarios que afectan a la seguridad del paciente), el Modelo en V es ideal porque:
- Cada fase tiene su verificación asociada (trazabilidad completa).
- Se planifican las pruebas desde el inicio (énfasis en calidad).
- Es adecuado para requisitos estables y bien definidos.
- Genera documentación exhaustiva (necesaria en sistemas críticos).
El cascada también podría servir, pero el modelo en V añade más énfasis en verificación, que es clave en sistemas críticos.
Explicación:
La principal ventaja del prototipado es que permite validar requisitos y obtener feedback temprano de los usuarios. Es mejor descubrir que una pantalla es confusa o que una funcionalidad no se ajusta a las necesidades en fase de prototipo (bajo coste) que cuando el sistema ya está desarrollado (alto coste).
Por qué las otras son incorrectas:
- A: No necesariamente es más rápido el desarrollo final. El prototipado añade tiempo al inicio.
- B: SÍ requiere documentación (aunque puede ser menos exhaustiva).
- D: NO elimina las pruebas. Un prototipo validado no es un sistema listo para producción.
Explicación:
«Gestión de la Red Corporativa» NO es una actividad del proceso de Desarrollo de MÉTRICA v3. Eso pertenece a la gestión de infraestructuras y operaciones, no al desarrollo de sistemas de información.
Las actividades del proceso de Desarrollo en MÉTRICA v3 son:
- EVS: Estudio de Viabilidad del Sistema
- ASI: Análisis del Sistema de Información
- DSI: Diseño del Sistema de Información
- CSI: Construcción del Sistema de Información
- IAS: Implantación y Aceptación del Sistema
Explicación:
Esta pregunta apareció en el examen de 2025 (opción correcta en pregunta 41). El lead time es el tiempo total que se tarda en completar una tarea, desde que se hace la petición hasta que se entrega.
Es una métrica clave en Kanban para medir la eficiencia del flujo de trabajo.
Diferencia con cycle time: El cycle time mide solo el tiempo activo de trabajo (desde que se empieza hasta que se termina), mientras que el lead time incluye el tiempo de espera.
Explicación:
La fase de Arranque en el Modelo de Implantaciones del SAS se corresponde con las primeras semanas de uso real del sistema en producción, caracterizadas por:
- Soporte intensivo in situ (técnicos presentes físicamente en el centro).
- Resolución rápida de dudas de los usuarios.
- Corrección de pequeños problemas de configuración.
- Ajustes de flujos según la realidad del uso.
- Monitorización estrecha del funcionamiento.
Es una fase crítica donde se da el «salto real» al nuevo sistema y se acompaña intensamente a los profesionales sanitarios en el cambio.
9. 🗺️ Mapa Conceptual
Estructura Visual del Tema 14
CICLO DE VIDA DE SISTEMAS DE INFORMACIÓN
│
├─── 📋 CONCEPTO Y DEFINICIÓN
│ ├─ Fases: Planificación → Análisis → Diseño → Implementación → Pruebas → Implantación → Mantenimiento → Retirada
│ ├─ Importancia: Reducción riesgos, Mejor calidad, Cumplimiento normativo
│ └─ Aplicación SAS: Todos los sistemas corporativos (Diraya, Receta XXI, InterSAS...)
│
├─── 🔄 MODELOS CLÁSICOS
│ │
│ ├─ MODELO EN CASCADA (Waterfall)
│ │ ├─ Características: Secuencial, Rígido, Documentación exhaustiva
│ │ ├─ Fases: Ingeniería SW → Análisis → Diseño → Codificación → Pruebas → Utilización → Mantenimiento → Sustitución
│ │ ├─ Ventajas: Simple, Fácil gestión, Bueno para requisitos estables
│ │ └─ Desventajas: Rígido ante cambios, Feedback tardío
│ │
│ ├─ MODELO EN V
│ │ ├─ Características: Énfasis en verificación y validación
│ │ ├─ Relación: Requisitos Usuario ↔ Pruebas Aceptación
│ │ │ Requisitos Sistema ↔ Pruebas Sistema
│ │ │ Diseño Alto Nivel ↔ Pruebas Integración
│ │ │ Diseño Detallado ↔ Pruebas Unitarias
│ │ ├─ Ventajas: Mayor calidad, Detección temprana errores
│ │ └─ Desventajas: Sigue siendo rígido
│ │
│ ├─ MODELO INCREMENTAL
│ │ ├─ Características: Entregas progresivas de funcionalidad
│ │ ├─ Incremento 1 → Incremento 2 → Incremento 3...
│ │ ├─ Ventajas: Feedback temprano, Menor riesgo, Valor desde inicio
│ │ └─ Ejemplo SAS: Despliegue modular de Diraya (AP → Urgencias → Hospitalización)
│ │
│ ├─ MODELO ITERATIVO
│ │ ├─ Características: Refinamiento progresivo
│ │ ├─ Iteración 1 → Mejora → Iteración 2 → Mejora → Iteración 3...
│ │ ├─ Ventajas: Adaptabilidad, Aprendizaje continuo
│ │ └─ Ejemplo SAS: Mantenimiento evolutivo de InterSAS, ClicSalud+
│ │
│ └─ MODELO EN ESPIRAL
│ ├─ Características: Gestión de riesgos, Uso de prototipos
│ ├─ Cada ciclo: Objetivos → Análisis Riesgos → Desarrollo → Planificación siguiente
│ ├─ Ventajas: Gestión proactiva riesgos, Flexibilidad
│ └─ Ejemplo SAS: Proyectos innovadores (IA, migración sistemas legacy complejos)
│
├─── 🛠️ PROTOTIPADO
│ ├─ TIPOS DE PROTOTIPOS
│ │ ├─ Baja fidelidad: Bocetos, wireframes, mockups
│ │ ├─ Alta fidelidad: Interactivos, diseño completo, funcionalidad parcial
│ │ ├─ Desechables (throwaway): Solo para validar, se descartan
│ │ └─ Evolutivos: Evolucionan hasta ser el sistema final
│ │
│ ├─ PROTOTIPADO RÁPIDO
│ │ ├─ Objetivo: Feedback temprano con mínima inversión
│ │ └─ Herramientas SAS: Figma, Adobe XD, frameworks JS, Python+Flask
│ │
│ ├─ VENTAJAS
│ │ ├─ Validación temprana requisitos
│ │ ├─ Detección problemas usabilidad
│ │ ├─ Mejor comunicación desarrolladores-usuarios
│ │ └─ Reducción de riesgos
│ │
│ ├─ DESVENTAJAS
│ │ ├─ Expectativas poco realistas
│ │ ├─ Riesgo de quedarse con prototipo baja calidad
│ │ └─ Posibles costes adicionales
│ │
│ └─ APLICACIÓN SAS
│ ├─ Rediseño interfaces Diraya
│ ├─ App autocita especialistas
│ └─ Dashboards gestión clínica
│
├─── 📐 METODOLOGÍAS Y MARCOS
│ │
│ ├─ MÉTRICA v3
│ │ ├─ Ámbito: Metodología sector público español (AGE)
│ │ ├─ Documentos: Estructura principal, Interfaces, Técnicas, Participantes
│ │ ├─ Procesos:
│ │ │ ├─ PSI: Planificación de Sistemas de Información
│ │ │ ├─ Desarrollo: EVS → ASI → DSI → CSI → IAS
│ │ │ └─ MSI: Mantenimiento (Correctivo, Perfectivo, Adaptativo)
│ │ ├─ Características: Escalable, Adaptable, Documentación exhaustiva
│ │ └─ Aplicación SAS: Proyectos grandes, financiación estatal/europea, certificaciones
│ │
│ ├─ ISO/IEC 12207
│ │ ├─ Ámbito: Estándar internacional procesos ciclo vida software
│ │ ├─ Procesos Principales: Adquisición, Suministro, Desarrollo, Operación, Mantenimiento
│ │ ├─ Procesos Soporte: Documentación, Config, QA, Verificación, Validación, Auditoría...
│ │ ├─ Procesos Organizativos: Gestión, Infraestructura, Mejora, Formación
│ │ └─ Relación: MÉTRICA v3 implementa ISO/IEC 12207
│ │
│ ├─ MADEJA
│ │ ├─ Ámbito: Adaptación MÉTRICA v3 para Junta de Andalucía
│ │ ├─ Particularidades: Herramientas corporativas JA, estándares propios
│ │ └─ Aplicación SAS: Proyectos internos, integración con infraestructuras JA
│ │
│ └─ METODOLOGÍAS ÁGILES (Introducción)
│ ├─ Diferencias con tradicionales: Iterativo, Adaptativo, Entregas frecuentes
│ ├─ Métodos: Scrum, Kanban, XP...
│ ├─ Lead time: Tiempo desde petición hasta entrega
│ └─ Aplicación SAS: Nuevas funcionalidades, proyectos exploratorios
│
├─── 🏥 APLICACIÓN EN EL SAS
│ │
│ ├─ MODELO MARCO DE IMPLANTACIONES SAS
│ │ ├─ Fase 1: Análisis Preliminar de Situación
│ │ ├─ Fase 2: Reingeniería de Procesos
│ │ ├─ Fase 3: Preimplantación
│ │ ├─ Fase 4: Implantación
│ │ ├─ Fase 5: Arranque (soporte intensivo in situ)
│ │ ├─ Fase 6: Consolidación
│ │ └─ Fase 7: Extensión
│ │
│ ├─ GESTIÓN DE CONFIGURACIÓN
│ │ ├─ Herramientas corporativas:
│ │ │ ├─ GIT: Control versiones código
│ │ │ ├─ JIRA: Gestión proyectos e incidencias
│ │ │ ├─ Confluence: Gestión conocimiento
│ │ │ └─ ayudaDigital: Mesa de ayuda
│ │ └─ Actividades: Gestión cambios a lo largo de todo el ciclo de vida
│ │
│ └─ TIPOS DE MANTENIMIENTO
│ ├─ CORRECTIVO: Corrección errores y bugs
│ ├─ ADAPTATIVO: Cambios normativos, evolución tecnológica
│ ├─ PERFECTIVO: Mejoras, ampliaciones funcionalidades
│ └─ PREVENTIVO: Mejoras para prevenir problemas futuros
│
└─── 🎯 CLAVES PARA EL EXAMEN
├─ Memorizar fases cascada completas (8 fases con sustitución)
├─ Entender diferencias entre modelos (cuándo aplicar cada uno)
├─ Recordar: Análisis (QUÉ) vs Diseño (CÓMO)
├─ MÉTRICA v3: Documentos (Estructura, Interfaces, Técnicas, Participantes)
├─ ISO 12207: Procesos (Principales, Soporte, Organizativos)
├─ Modelo Implantaciones SAS: 7 fases (memorizar orden)
├─ Tipos mantenimiento: Correctivo, Adaptativo, Perfectivo, Preventivo
└─ Gestión configuración: Actividad continua en TODO el ciclo de vida
10. 📚 Referencias Normativas y Bibliográficas
Normativa y Estándares
- ISO/IEC 12207:2017 – Systems and software engineering — Software life cycle processes
- ISO/IEC 15288:2015 – Systems and software engineering — System life cycle processes
- ISO/IEC/IEEE 29148:2018 – Systems and software engineering — Life cycle processes — Requirements engineering
- ISO 9001:2015 – Sistemas de gestión de la calidad
- ISO/IEC 25010:2011 – Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE)
Metodologías Oficiales
- MÉTRICA v3 – Metodología de Planificación, Desarrollo y Mantenimiento de Sistemas de Información. Ministerio de Asuntos Económicos y Transformación Digital. Disponible en: PAe
- MADEJA – Marco de Desarrollo de la Junta de Andalucía. Consejería de Transformación Económica, Industria, Conocimiento y Universidades
- MAGERIT v3 – Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Ministerio de Asuntos Económicos y Transformación Digital
Marcos y Modelos de Referencia
- ITIL 4 – Information Technology Infrastructure Library. AXELOS
- COBIT 2019 – Control Objectives for Information and Related Technologies. ISACA
- CMMI-DEV v2.0 – Capability Maturity Model Integration for Development. CMMI Institute
- PMBOK 7 – Project Management Body of Knowledge. Project Management Institute (PMI)
- PRINCE2 – Projects IN Controlled Environments. AXELOS
Metodologías Ágiles
- Manifiesto Ágil (2001) – Agile Manifesto. agilemanifesto.org
- Scrum Guide (2020) – Schwaber, K. & Sutherland, J. scrumguides.org
- Kanban Guide – Anderson, D.J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business
- Extreme Programming Explained – Beck, K. (2004). Addison-Wesley
Bibliografía Técnica Fundamental
- Software Engineering – Sommerville, I. (10th Edition, 2015). Pearson Education
- Ingeniería del Software: Un enfoque práctico – Pressman, R.S. & Maxim, B. (9ª Ed, 2020). McGraw-Hill
- The Mythical Man-Month – Brooks, F.P. (1975, Anniversary Edition 1995). Addison-Wesley
- Clean Code – Martin, R.C. (2008). Prentice Hall
- Design Patterns – Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Addison-Wesley
Normativa Específica del Sector Público y SAS
- Ley 39/2015, de 1 de octubre, del Procedimiento Administrativo Común de las Administraciones Públicas
- Ley 40/2015, de 1 de octubre, de Régimen Jurídico del Sector Público
- Ley 9/2017, de 8 de noviembre, de Contratos del Sector Público
- Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad (ENS)
- Reglamento (UE) 2016/679 (RGPD) – Reglamento General de Protección de Datos
- Ley Orgánica 3/2018 (LOPDGDD) – Ley de Protección de Datos Personales y garantía de los derechos digitales
- Decreto 534/2021, de 15 de junio, por el que se regula la organización territorial y la estructura de gestión y administración del Servicio Andaluz de Salud
Documentación Corporativa del SAS
- Plan Estratégico SAS 2021-2024 – Consejería de Salud y Consumo
- Plan de Transformación Digital del Sistema Sanitario Andaluz 2022-2027
- Política de Seguridad de las Tecnologías de la Información y Comunicaciones del SAS
- Catálogo de Servicios TIC del SAS – Dirección General de Sistemas de Información y Comunicaciones
- Modelo Corporativo Marco de Implantaciones del SAS – Documentación interna DGSIC
Recursos Online Recomendados
- Portal de Administración Electrónica (PAe) – administracionelectronica.gob.es
- Centro Criptológico Nacional (CCN-CERT) – Guías CCN-STIC – ccn-cert.cni.es
- Consejería de Salud y Consumo – Junta de Andalucía – juntadeandalucia.es
- Portal del Servicio Andaluz de Salud – sspa.juntadeandalucia.es