1. Introducción al Ciclo de Vida de los Sistemas de Información (SDLC)

1.1. ¿Qué es un Sistema de Información?

Definición

Un Sistema de Información (SI) es un conjunto organizado de personas, datos, procesos y tecnología que interactúan para recopilar, procesar, almacenar y distribuir información que soporta la toma de decisiones, coordinación, control, análisis y visualización en una organización.

Componentes SI:

• Hardware: Servidores, PCs, dispositivos red, almacenamiento…
• Software: Aplicaciones (Diraya, PACS…), sistemas operativos, BBDD, middleware…
• Datos: Historias clínicas, pacientes, profesionales, citas, medicamentos… (información digitalizada).
• Personas: Usuarios finales (médicos, enfermeras), administradores TI, desarrolladores…
• Procesos: Procedimientos uso sistema (cómo registrar consulta, cómo pedir analítica…).
• Redes: Comunicaciones (LAN hospitales, WAN Andalucía, Internet, VPN…).

Ejemplo SAS: Diraya NO es solo software (aplicación web Java), es SI completo:

• Hardware: Servidores Azure cloud, almacenamiento BBDD Oracle, balanceadores carga…
• Software: Aplicación Diraya (múltiples módulos), Oracle BBDD, servidores aplicación Tomcat…
• Datos: 8+ millones HCs pacientes andaluces, millones registros clínicos…
• Personas: 15.000+ profesionales sanitarios usuarios, equipos TIC STIC, consultoras mantenimiento (Everis…).
• Procesos: Protocolos clínicos, flujos trabajo administrativos, procedimientos soporte técnico…
• Redes: Red corporativa Junta, conexión hospitales/centros salud, acceso Internet profesionales móviles…

1.2. ¿Qué es el Ciclo de Vida de un Sistema de Información (SDLC)?

Definición SDLC

El Ciclo de Vida del Desarrollo de Sistemas (SDLC – System Development Life Cycle) es el proceso estructurado completo que atraviesa un sistema de información desde su concepción inicial hasta su retiro/reemplazo, pasando por desarrollo, despliegue, operación y mantenimiento.

Metáfora biológica: Como un ser vivo, los SI tienen ciclo vida:

• Nacimiento: Idea inicial, identificación necesidad negocio.
• Gestación: Análisis requisitos, diseño (concebir qué será sistema).
• Nacimiento físico: Implementación (construcción sistema).
• Infancia: Testing, ajustes iniciales.
• Madurez: Operación estable, mantenimiento evolutivo.
• Vejez: Obsolescencia, costes mantenimiento > beneficios.
• Muerte: Retiro, migración a sistema sucesor.

Ejemplo Diraya:

• Nacimiento (años 90): SAS identifica necesidad Historia Clínica Electrónica única Andalucía (sistemas fragmentados, papel…).
• Gestación (finales 90-2000s): Análisis requisitos sanitarios, diseño Diraya inicial, prototipos…
• Nacimiento (2003-2005): Primeras implantaciones Diraya hospitales piloto.
• Infancia (2005-2010): Extensión progresiva, corrección bugs, formación masiva usuarios…
• Madurez (2010-actualidad): Diraya consolidado, mantenimiento evolutivo continuo (nuevos módulos: telemedicina, receta electrónica…), adaptaciones normativas (RGPD…).
• Vejez (¿futuro 2030s?): Posible obsolescencia arquitectura, evaluación migrar plataforma nueva generación…
• Muerte (¿2040s?): Hipotético retiro Diraya, migración sistema sucesor (si tecnologías evolucionan radicalmente).

1.3. Importancia del SDLC

¿Por qué NO «desarrollar directamente» sin metodología SDLC?

Sin SDLC estructurado (enfoque «Code & Fix» – programar y arreglar errores):

• Caos requisitos: «Ya veremos qué quiere usuario mientras programamos» → requisitos ambiguos, malentendidos, retrabajos costosos.
• Arquitectura frágil: Diseño improvisado → código espagueti, difícil mantener/escalar.
• Testing tardío: Probar solo al final → bugs críticos descubiertos tarde, corrección carísima.
• Sobrecostes y retrasos: Proyecto descontrolado, presupuesto/plazo explotados.
• Baja calidad: Producto final NO cumple expectativas, usuarios insatisfechos.
• Mantenimiento pesadilla: Código NO documentado, solo desarrollador original entiende (si se va, catástrofe).

Con SDLC estructurado:

• Requisitos claros: Fase Análisis dedica tiempo entender QUÉ necesita usuario ANTES programar.
• Diseño sólido: Arquitectura pensada (escalable, mantenible, segura).
• Testing integrado: Verificación continua (testing unitario → integración → sistema → UAT).
• Previsibilidad: Fases/hitos definidos → seguimiento avance, control costes/plazos.
• Calidad: Producto cumple requisitos, satisfacción usuario alta.
• Mantenibilidad: Documentación exhaustiva, código limpio, transferencia conocimiento facilitada.

Estadística industria (Standish Group Chaos Report – estudios recurrentes éxito proyectos software):

• Proyectos SIN metodología estructurada: ~70% fallan (cancelados, sobrecostes masivos, NO cumplen requisitos).
• Proyectos CON SDLC adecuado: ~50-60% éxito razonable (nunca 100%, complejidad inherente desarrollo software, pero MUCHO mejor).

1.4. Fases Genéricas del SDLC

Aunque existen múltiples modelos SDLC (Cascada, Espiral, Ágil…), la mayoría comparten fases conceptuales comunes (pueden nombrarse/organizarse diferente, pero actividades esenciales similares):

Nota importante: Orden y forma ejecutar estas fases varía según modelo SDLC elegido:

• Waterfall (Cascada): Fases secuenciales estrictas (Análisis completo → Diseño completo → Implementación completa…).
• Ágil (Scrum): Ciclos cortos (Sprints 2-4 sem) que REPITEN mini-versiones Análisis → Diseño → Implementación → Testing → Despliegue incrementales.
• Espiral: Iteraciones crecientes, enfoque gestión riesgos cada ciclo.

1.5. Diferencia: Desarrollo Software vs Sistema Información Completo

Distinción importante:

Desarrollo Software (enfoque estrecho): Crear código aplicación (programación pura).

Desarrollo Sistema Información (enfoque amplio): Crear SI completo (software + hardware + datos + personas + procesos + redes).

Este tema (SDLC) cubre ambos aspectos, pero énfasis en Sistema Información completo (visión holística), porque:

• Como TFA-STI SAS, NO solo programarás (aunque puede ser parte trabajo), también participarás implantaciones (gestión cambio, formación, soporte…), análisis requisitos sanitarios, diseño integraciones sistemas…
• Proyectos SAS (Diraya, PACS…) son Sistemas Información complejos, NO solo «apps software aisladas».

2. Modelos Clásicos de Ciclo de Vida

Contexto: Existen múltiples «sabores» SDLC, cada uno con filosofía, fases y enfoque propios. Esta sección cubre modelos clásicos (surgidos 1960s-1990s, todavía muy usados especialmente sector público/AAPP). Sección 3 cubrirá modelos modernos (Ágil, Espiral, DevOps).

2.1. Modelo Waterfall (Cascada)

¿Qué es Waterfall?

Waterfall («Cascada») es el modelo SDLC más antiguo y simple, propuesto por Winston Royce en 1970. Estructura proyecto como secuencia lineal fases que «caen como cascada» de una a siguiente (agua NO sube).

Fases Waterfall típico:

1. Requisitos: Recopilar TODOS requisitos → documento Especificación Requisitos (SRS).
2. Diseño: Diseñar TODA arquitectura, componentes, BBDD, interfaces → Documento Diseño.
3. Implementación: Codificar sistema completo según diseño → Código fuente.
4. Testing: Probar sistema completo → Informe Testing.
5. Despliegue: Instalar en producción → Go-live.
6. Mantenimiento: Soporte post-lanzamiento → Parches/versiones futuras.

Características Waterfall:

• Secuencial: Cada fase DEBE completarse antes siguiente (NO se pueden hacer simultáneamente).
• Requisitos estables: Asumir requisitos completos y claros al inicio (NO pueden cambiar después).
• Documentación exhaustiva: Cada fase produce documentos formales (SRS, Diseño, Manuales…).
• Testing al final: Probar solo cuando sistema casi completo (NOT antes).
• Entrega única: Producto final entregado una sola vez (Big Bang → O todo funciona O todo falla).

Visualización Waterfall:

REQUISITOS → DISEÑO → IMPLEMENTACIÓN → TESTING → DESPLIEGUE → MANTENIMIENTO
    ↓          ↓            ↓            ↓         ↓            ↓
 (1-3 mes) (2-4 mes)    (3-8 mes)    (1-2 mes) (1 sem)      (indefinido)

Cada fase es "punto de no retorno":
Si fase Requisitos mala → cascada de errores Diseño → Implementación...
Arreglar requiere volver atrás (costoso, a menudo NO se hace).

Ventajas Waterfall:

• Simplicidad conceptual: Fácil entender, estructura clara.
• Predecibilidad: Si requisitos estables, plazo/coste relativamente predecibles.
• Documentación completa: Abundante documentación (útil auditorías, mantenimiento largo plazo).
• Gestión clara: Hitos bien definidos, seguimiento avance visual (Gantt charts).
• Apropiado para sistemas críticos: Requisitos muy bien entendidos, cambios prohibitivos (ej: software embebido hardware específico).

Desventajas Waterfall (principales):

• Rigidez extrema: Cambios requisitos a mitad proyecto MUY costosos (requieren volver Fase 1, rehacer todo).
• Riesgo entrega tardía de valor: Usuario NO ve nada funcionando hasta final → riesgo descubrir tarde que NO es lo que quería.
• Testing tardío: Bugs encontrados al final, corrección carísima, retrasos seguro.
• Inadecuado para innovación: Si requisitos NO claros (proyecto nuevo, tecnología emergente), Waterfall falla.
• Efecto «Big Bang»: Todo riesgo concentrado go-live único → si falla, catástrofe total.

Cuándo usar Waterfall:

• Requisitos muy estables, BIEN conocidos: Ej. sistema que replica proceso manual bien establecido.
• Cambios prohibitivos: Ej. hardware embebido, donde cambio post-fabricación imposible/carísimo.
• Contrato LCSP cerrado: AAPP con presupuesto fijo, alcance cerrado, NO flexible.
• Equipo distribuido, poca comunicación: Documentación exhaustiva compensa falta interacción (menos crítico con comunicación moderna).
• Sector crítico con regulación estricta: Defensa, aeroespacial, medicina (donde trazabilidad/documentación obligatoria).

Ejemplo Waterfall en contexto SAS (hipotético):

• Proyecto: Renovar sistema gestión inventarios medicamentos (proceso bien definido, requisitos claros desde inicio).
• Mes 1-2: Recopilar requisitos (inventarios, categorías medicamentos, movimientos entrada/salida, alertas stock bajo).
• Mes 3-4: Diseñar BBDD (tablas medicamentos, almacenes, movimientos), interfaz usuario, arquitectura.
• Mes 5-8: Desarrollar sistema completo.
• Mes 9-10: Testing exhaustivo.
• Mes 11: Go-live (cambio de sistema antiguo → nuevo, migración datos históricos).
• Mes 12+: Mantenimiento, corrección bugs menores post-lanzamiento.

2.2. Modelo en V (V-Model)

¿Qué es Modelo en V?

Modelo en V es evolución Waterfall, propuesto por Paul Rook (1990s). Reconoce que testing NO es actividad separada al final, sino relacionada cada fase desarrollo anterior.

Estructura V-Model:

                    REQUISITOS
                        |
                    DISEÑO SISTEMA
                        |
                  DISEÑO DETALLADO
                        |
                   IMPLEMENTACIÓN (bottom V)
                        |
              ↙                    ↖
         TESTING                   TESTING
         UNITARIO             INTEGRACIÓN
            ↓                      ↑
         TESTING              TESTING
         SISTEMA              ACEPTACIÓN
            ↓                      ↑
    DESPLIEGUE/                    |
    MANTENIMIENTO           USUARIOS VALIDAN

Lado izquierdo (descenso): Desarrollo (definición requisitos → detalles)
Fondo (V): Implementación (código)
Lado derecho (ascenso): Verificación (testing alineado cada fase izquierda)

Fases V-Model:

• Requisitos ↔ UAT (Testing Aceptación Usuario): Requisitos definidos → al final usuarios los validan.
• Diseño Sistema ↔ Testing Sistema: Diseño alto nivel → testing end-to-end verifica funcionalidad.
• Diseño Detallado ↔ Testing Integración: Diseño componentes → testing integración verifica componentes trabajan juntos.
• Implementación ↔ Testing Unitario: Codificación → desarrolladores prueban componentes individuales.

Ventajas V-Model sobre Waterfall:

• Testing planificado desde inicio: Para cada actividad desarrollo existe actividad testing correspondiente → casos test diseñados antes codificar (mejora calidad).
• Mejor control defectos: Bugs detectados temprano (en testing unitario/integración), NO esperando sistema completo.
• Trazabilidad requisitos: Cada requisito tiene caso test asociado → garantiza toda funcionalidad verificada.

Desventajas V-Model:

• Sigue siendo secuencial rigidez: Como Waterfall, cambios requisitos a mitad proyecto costosos.
• Testing aún tardío parcialmente: Testing integración/sistema sigue al final (no temprana como Ágil).
• Documentación abundante: Como Waterfall, requiere documentos formales cada fase.

Cuándo usar V-Model:

• Similar Waterfall (requisitos estables, cambios prohibitivos), PERO donde calidad testing CRÍTICA.
• Proyectos críticos seguridad/salud: Ej. software médico (Diraya?), defensa, transporte público → testing riguroso obligatorio.

2.3. Modelo Incremental

¿Qué es Modelo Incremental?

Modelo Incremental divide proyecto en múltiples «incrementos» (versiones pequeñas), cada uno añade funcionalidades nuevas. Cada incremento es mini-proyecto Waterfall completo.

Estructura Incremental:

VERSIÓN 1.0:   Req → Diseño → Impl → Test → Deploy → (en producción, usuarios usan)
                ↓
VERSIÓN 1.1:   Req(nuevas features) → Diseño → Impl → Test → Deploy
                ↓
VERSIÓN 2.0:   Req(más features) → Diseño → Impl → Test → Deploy
                ↓
...continuando versiones ...

Cada versión entregada a producción → usuarios dan feedback → siguiente versión mejora/añade.

Ventajas Incremental:

• Valor temprano: Versión 1.0 entregada tras pocos meses (vs Waterfall meses/años esperar).
• Feedback usuarios: Usuarios usan V1.0, dan feedback → V1.1 incorpora aprendizajes.
• Flexibilidad requisitos: Requisitos V2.0 pueden ajustarse basadas en experiencia V1.0.
• Gestión riesgos: Riesgo distribuido versiones, NO concentrado única entrega.
• Mejor para unknowns: Si requisitos NO totalmente claros, Incremental permite exploración.

Desventajas Incremental:

• Arquitectura puede deteriorarse: Si NO hay diseño macro coherente, versiones sucesivas pueden añadir «parches» → arquitectura frágil.
• Planificación compleja: Decidir QUÉ en V1.0 vs V1.1 vs V2.0… difícil, requiere visión clara roadmap.
• Overhead gestión: Múltiples deployes, versiones, coordinar usuarios… complejo.

Ejemplo Incremental en SAS:

• V1.0 (Mes 6): Módulo Diraya Telemedicida básico (video consulta + grabación).
• V1.1 (Mes 9): Añadir recetas electrónicas telemedicina + compartir pantalla con paciente.
• V2.0 (Mes 12): Integración con PACS (visualizar radiografías telemedicina).
• V2.1 (Mes 15): IA análisis ánimo paciente (detección fatiga, estrés video).

2.4. Modelo Evolutivo (Iterativo)

¿Qué es Modelo Evolutivo?

Modelo Evolutivo (también llamado Iterativo o Spiral simple) es similar Incremental, PERO cada iteración refina TODAS funcionalidades anteriores, NO solo añade nuevas.

Diferencia Incremental vs Evolutivo:

• Incremental: V1.0 (Funciones A+B) → V1.1 (Funciones A+B+C) → V2.0 (Funciones A+B+C+D). Funciones previas NO cambian, solo se añaden.
• Evolutivo: Iter 1 (prototipo A+B básico) → Iter 2 (A+B refinado, mejorado, + C básico) → Iter 3 (A+B+C refinados, mejorados, + D básico). Funciones previas EVOLUCIONAN.

Visualización Evolutivo:

ITERACIÓN 1:  Prototipo básico (30% funcionalidad)
              ↓
ITERACIÓN 2:  Refinamiento prototipo + nuevas features (60% funcionalidad)
              ↓
ITERACIÓN 3:  Refinamiento + más features (85% funcionalidad)
              ↓
ITERACIÓN 4:  Refinamiento final + detalles (100% + calidad pulida)
              ↓
PRODUCTO FINAL

vs INCREMENTAL donde cada versión "termina", Evolutivo cada iteración refina TODO continuamente.

Ventajas Evolutivo:

• Aprendizaje continuo: Cada iteración aprende de anterior, refina.
• Calidad mejora iteración a iteración: NO hay «deuda técnica» acumulada.
• Muy flexible requisitos: Requisitos pueden cambiar cada iteración.
• Ideal prototipado: Primeras iteraciones son prototipos, van madurando.

Desventajas Evolutivo:

• Difícil predecir recursos/plazo final: ¿Cuántas iteraciones hasta «listo»? Impredecible.
• Overhead comunicación: Cambios continuos requieren feedback usuarios constante.
• Riesgo «nunca está listo»: Perfeccionismo continuo, proyecto NO termina.

2.5. Comparativa Modelos Clásicos

Nota importante: Estos modelos «clásicos» surgen era pre-Internet, pre-cloud, cuando cambios requisitos eran caros/lentos. Hoy, en mundo ágil/DevOps/cloud, modelos Waterfall/V bastante menos usados. PERO siguen siendo críticos entender porque:

• Sector público (AAPP, SAS) tiende ser más conservador, contratación LCSP rígida favorece Waterfall/V.
• Sistemas legacy grandes (Diraya, PACS…) frecuentemente usa Incremental/Evolutivo (versiones anuales, mejoras continuas).
• Comprensión modelos clásicos facilita entender modernos (Ágil, DevOps son reacción contra rigidez Waterfall).

3. Modelos Ágiles y Modernos del SDLC

Contexto: A partir años 2000, surgió reacción contra rigidez Waterfall. El Manifiesto Ágil (2001) revolucionó pensamiento desarrollo software. Hoy coexisten modelos ágiles (Scrum, XP), modernos (Espiral, RAD) y ultra-modernos (DevOps).

3.1. Desarrollo Ágil aplicado a SDLC

¿Qué es Agile SDLC?

Agile es filosofía y conjunto prácticas que aplican Manifiesto Ágil (2001) al SDLC completo. Fundamental: ciclos cortos (Sprints 2-4 semanas) que repiten todas fases SDLC (análisis-diseño-implementación-testing) incrementalmente.

Ciclo típico Sprint Ágil (2-4 semanas):

SEMANA 1:
- Lunes: Sprint Planning (qué se hará esta semana)
- Daily Standup (15 min cada mañana, sincronización equipo)
- Martes-Viernes: Desarrollo (análisis + diseño + código + testing incrementales)

SEMANA 2:
- Más desarrollo
- Integración continua (código se integra y testea automáticamente)
- Refinamiento con Product Owner (feedback cambios)

SEMANA 3:
- Finalización tareas

VIERNES SEMANA 3/4:
- Sprint Review: Demo funcionalidades completadas a stakeholders
- Sprint Retrospective: Equipo reflexiona mejoras proceso

LUNES SEMANA 4/5:
- Siguiente Sprint inicia (ciclo repeats)

RESULTADO CADA SPRINT: Incremento potencialmente entregable (código funcionando + tested + documentado mínimo).

Scrum (metodología Ágil más popular):

• Roles: Product Owner (QUÉ hacer), Scrum Master (facilitador), Dev Team (multifuncional, 5-9 personas).
• Artefactos: Product Backlog (lista requisitos priorizada), Sprint Backlog (items seleccionados Sprint), Incremento (software funcionando).
• Eventos: Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective.

Ventajas Ágil SDLC:

• Valor temprano + continuo: Cada Sprint (2-4 sem) entrega software funcionando → usuarios ven avance rápido.
• Flexibilidad requisitos: Cambios entre Sprints bienvenidos, se priorizan Product Backlog.
• Riesgo bajo: Feedback continuo usuarios, correcciones temprano (NO esperar final).
• Calidad integrada: Testing continuo (testing unitario, integración), código cleaned regularmente.
• Motivación equipo: Equipo auto-organizado, entiende propósito trabajo (no solo «seguir órdenes»).

Desventajas Ágil SDLC:

• Requiere compromiso Product Owner: DEBE estar disponible constantemente (vs Waterfall donde define requisitos inicio, listo).
• Documentación reducida: Agile valora «software funcionando» sobre «documentación exhaustiva» (puede ser problema auditorías públicas).
• Escala difícil: Scrum diseñado equipos pequeños (~7 personas). Proyectos 100+ personas requieren frameworks SAFe, LeSS (complejos).
• Predecibilidad baja: Plazo/coste final inciertos (vs Waterfall que planifica todo inicio).
• Contratación pública difícil: LCSP presupuesto/alcance cerrados NO encajan Ágil (alcance flexible).

Aplicación Ágil SDLC en SAS:

• Desarrollo evolutivo Diraya: Versiones anuales (similar Sprints grandes 6-12 meses cada una), feedback usuarios internos integrado.
• Proyectos innovación: IA, Big Data, telemedicina → requisitos inciertos, prototipado importante, Ágil ideal.
• Limitación: Muchos proyectos SAS financiados fondos públicos LCSP → contratación Waterfall (alcance fijo), aunque internamente equipos desarrollan con prácticas Ágil (Scrum-Waterfall híbrido).

3.2. Modelo Espiral (Spiral Model)

¿Qué es Modelo Espiral?

Modelo Espiral, propuesto Barry Boehm (1986), es iterativo + gestión riesgos explícita. Cada iteración (vuelta espiral) expande funcionamiento, reevalúa riesgos.

Estructura Espiral (4 fases cada iteración):

VUELTA 1 (PEQUEÑA):
  1. Planificación: Objetivos, alternativas
  2. Análisis riesgos: QUÉ riesgos? Cómo mitigarlo?
  3. Prototipado/Desarrollo: Construir prototipo pequeño
  4. Evaluación + Planificación siguiente vuelta

VUELTA 2 (MÁS GRANDE):
  1. Planificación: Basada feedback vuelta 1
  2. Análisis riesgos: Riesgos residuales?
  3. Desarrollo: Construir más funcionalidad
  4. Evaluación

VUELTA 3, 4, ... (PROGRESIVAMENTE MÁS COMPLETO)

RESULTADO: Sistema que crece espiral, riesgos disminuyen iteración a iteración.

Ventajas Espiral:

• Gestión riesgos explícita: Cada iteración identifica/mitiga riesgos (vs otros modelos que «esperar a ver»).
• Flexible requisitos: Como Ágil, permite cambios iteración a iteración.
• Prototipado continuo: Primeras vueltas son prototipos, van madurando.

Desventajas Espiral:

• Complejo gestión: Requiere gestión experta riesgos, NO simple equipo junior.
• Coste análisis riesgos: Cada vuelta dedica tiempo/recursos análisis riesgos (overhead).
• Predecibilidad baja: Impredecible cuántas vueltas hasta «listo».

Cuándo usar Espiral: Proyectos grandes riesgos altos (defensa, espacial, sistemas críticos) donde gestión riesgos CRÍTICA.

3.3. RAD (Rapid Application Development)

¿Qué es RAD?

RAD es enfoque desarrollo rápido (popularizado años 90, James Martin). Énfasis prototipado visual, herramientas low-code, desarrollo acelerado.

Características RAD:

• Herramientas visuales: Drag-drop interfaces, generadores código automático (vs codificación manual).
• Prototipos rápidos: Semanas NO meses (vs Waterfall meses).
• Iteraciones rápidas: Feedback usuario → ajuste rápido (días/semanas).
• COTS (Commercial Off-The-Shelf): Usar software existente personalización, NO desarrollar from scratch.

Ejemplo RAD: Desarrollar portal interno SAS (gestión tareas, documentos…) usando plataforma low-code (ej: Mendix, OutSystems, PowerApps) → prototipo en 2 semanas, vs 6 meses development tradicional.

Ventajas RAD:

• Velocidad extrema: Aplicaciones en semanas.
• Coste reducido: Menos desarrolladores, menos tiempo.
• Flexibilidad: Cambios rápidos incorporados.

Desventajas RAD:

• Escalabilidad limitada: Soluciones RAD frecuentemente limitadas complejidad/rendimiento (típicamente aplicaciones internas, NO sistemas críticos masivos).
• Deuda técnica: Prototipado rápido puede generar código NO mantenible largo plazo.
• Dependencia herramientas: Locked-in plataforma específica (vendor lock-in).

3.4. DevOps (Development + Operations Integration)

¿Qué es DevOps?

DevOps es cultura + prácticas integración desarrollo-operaciones (surge ~2009, reacción separación histórica Dev vs Ops). Énfasis: automatización, entrega continua, feedback rápido.

Ciclo DevOps (SDLC extremadamente iterativo, cientos deploys/mes):

CODE (Desarrollador escribe código)
  ↓
COMMIT (Push repositorio Git)
  ↓
CI/CD PIPELINE (Automático):
  - Build automático (compilar código)
  - Testing automático (tests unitarios + integración)
  - Análisis calidad (SonarQube, cobertura código)
  - Despliegue test (entorno staging)
  - Testing adicional (performance, seguridad)
  ↓
DEPLOY PRODUCCIÓN (Automático O manual aprobación)
  - Canary deployment (1% usuarios primero)
  - Blue-Green deployment (ambiente paralelo, switch traffic)
  ↓
MONITOR (Monitorización continua producción)
  - Métricas aplicación (latencia, errores, CPU...)
  - User feedback
  - Logs centralizados (ELK Stack)
  ↓
FEEDBACK → Siguiente iteración (ciclo repeats)

RESULTADO: Deploy múltiples veces DÍA (vs Waterfall once per year).

Prácticas DevOps clave:

• Continuous Integration (CI): Código integra repositorio central múltiples veces día, tests automáticos ejecutan.
• Continuous Delivery (CD): Código PUEDE desplegarse producción cualquier momento (automatizado, listo).
• Continuous Deployment: Código despliega automáticamente producción (más agresivo que Continuous Delivery).
• Infraestructura como Código (IaC): Servidores, BBDD, redes definidos código (vs configuración manual) → reproducible, versionable.
• Containerización (Docker, Kubernetes): Apps empaquetadas containers → deployment consistente múltiples entornos.
• Automatización testing: Tests ejecutan automáticos (NO manuales), cualquier build.

Ventajas DevOps:

• Entrega rápida valor: Deploy múltiples veces día → feedback usuario continuo.
• Calidad alta: Testing automático continuo → bugs detectados instantáneamente.
• Menor riesgo deploys: Cambios pequeños frecuentes (vs grandes deploys raros) → riesgo distribuido.
• Escalabilidad operacional: Automatización permite manejar complejidad infraestructura moderna (cloud, microservicios, cientos servidores).
• Feedback rápido**: Errores producción detectados minutos (vs días/semanas después).

Desventajas DevOps:

• Curva aprendizaje empinada: Requiere skillset amplio (desarrollo + operaciones + cloud + automatización).
• Infraestructura compleja: Pipelines CI/CD, monitorización, IaC… overhead inicial.
• Cambio cultural: Requiere mentalidad colaborativa Dev-Ops (históricamente enfrentados).
• NO apropiado sistemas muy estables**: Si sistema cambia raramente, DevOps overhead NO justificado.

Aplicación DevOps en SAS:

• Potencial: Diraya cloud, ClicSalud+ apps móviles, nuevas plataformas → DevOps muy apropiado (deploy frecuente, feedback usuarios).
• Limitación: Sistemas legacy (BBDD Oracle on-premise, aplicaciones monolíticas) más difíciles containerizar, requiere arquitectura refactoring.
• Adopción actual: STIC probablemente en fase transición (CI/CD pipelines básicos, pero NO completa automatización infraestructura aún).

3.5. Comparativa Modelos Ágiles/Modernos vs Clásicos

4. Prototipado en Desarrollo de Sistemas de Información

Contexto: Prototipado es técnica CRÍTICA desarrollo sistemas modernos. Permite validar requisitos, diseño, tecnología temprano (ANTES inversión masiva desarrollo completo). Aplicable TODOS modelos SDLC (aunque especialmente Ágil, Espiral, RAD).

4.1. Concepto de Prototipo

¿Qué es un Prototipo?

Un prototipo es versión preliminar, simplificada, reducida alcance de sistema que permite explorar, validar, experimentar requisitos/diseño/tecnología ANTES construir sistema completo.

Analogía ingeniería: Construir prototipo coche (versión pequeña, modelos limitados) ANTES fabricación masiva (reduce riesgo, valida diseño, identifica problemas temprano).

Características prototipo típico:

• Reducido alcance: NO todo sistema, solo partes críticas/riesgosas.
• Rápido desarrollo: Días/semanas, NO meses (vs sistema completo).
• Funcionalidad limitada: Puede faltar validaciones, edge cases, rendimiento optimizado…
• Documentación mínima: Enfoque demostración visual, NO documentos exhaustivos.
• Bajo coste: Custa 5-10% coste sistema final, pero ahorra retrabajos grandes.

4.2. Tipos de Prototipos

Clasificación según propósito y madurez:

1. Prototipo Desechable (Throwaway Prototype)

• Objetivo: Validar requisitos, diseño UI/UX, tecnología feasibilidad → DESCARTAR después demostración.
• Construcción: Rápido (código «sucio», NO producción-ready), herramientas low-code (Figma, Adobe XD, PowerApps, Mendix…).
• Ejemplo SAS: Crear prototipo interfaz web módulo Telemedicina Diraya (wireframes + mockups funcionales) → demostrar médicos/enfermeras → recopilar feedback → DESCARTAR prototipo → desarrollar sistema producción versión refinada.
• Ventaja: MUY rápido, bajo coste, feedback temprano crucial.
• Riesgo: Cliente puede esperar prototipo sea sistema final (gestionar expectativas importante).

2. Prototipo Evolutivo (Evolutionary Prototype)

• Objetivo: Prototipo inicial que EVOLUCI ONARÁ hasta convertirse sistema final.
• Construcción: Código relativamente limpio (producción-quality desde inicio), iteraciones progresivas lo refinan.
• Ejemplo SAS: Versión 1.0 Diraya módulo Telemedicida (MVP – Minimum Viable Product) con video consulta + básico, lanzar producción piloto hospitales → V1.1 (recetas, chat), V2.0 (IA emoción), etc.
• Ventaja: Entrega valor temprano, evoluciona usuario feedback real.
• Desventaja: Requiere arquitectura sólida (vs desechable que puede ser «código espagueti»).

3. Prototipo Operacional (Operational Prototype)

• Objetivo: Prototipo funcional parcial, más maduro que desechable, demostrar capacidades core.
• Construcción: Código producción-quality, pero alcance limitado (ej: solo casos uso principales, NO todos edge cases).
• Ejemplo SAS: Prototipo laboratorio IA análisis radiografías → procesa casos 80% comunes bien, casos raros NO soporta aún (pero prueba concepto funciona).

4.3. Proceso Prototipado

FASE 1: DEFINIR PROTOTIPO
  - QUÉ aspectos validar? (UI/UX, tecnología, requisito específico complejo)
  - QUÉ alcance incluir? (MVP mínimo para validar)
  - QUIÉNES stakeholders clave? (usuarios finales, decisores)
  - Cuándo demostrar? (timeline realista)

FASE 2: DESARROLLAR PROTOTIPO
  - Elegir tecnología (favorecida herramientas rápidas: low-code, scripting...)
  - Desarrollo iterativo rápido (días, NO semanas)
  - Focus calidad suficiente, NO perfección

FASE 3: DEMOSTRACIÓN Y FEEDBACK
  - Sesiones demostraciómn usuarios/stakeholders (sesiones 1:1, workshops grupales)
  - Recopilar feedback estructurado (qué funciona?, qué cambiar?, qué falta?)
  - Documentar aprendizajes

FASE 4: ANALIZAR Y DECIDIR
  - Validación exitosa? (requisitos claros ahora, tecnología viable, diseño aprobado)
  - DESCARTAR prototipo (si desechable) + comenzar desarrollo "real" basado lecciones
  - O EVOLUCIONAR prototipo (si evolutivo) + continuar refinamiento iterativo

FASE 5 (SI EVOLUCIONA): SIGUIENTE ITERACIÓN
  - Prototipo → código producción
  - Lanzar usuarios (MVP producción)
  - Feedback → siguiente versión...

4.4. Herramientas Prototipado

4.5. Ventajas y Desventajas Prototipado

VENTAJAS:

• Validar requisitos temprano: Usuarios ven interfaz concreta (vs documentos abstractos) → mejor feedback requisitos reales.
• Reducir riesgo técnico: Probar tecnología compleja ANTES comprometerse → identificar problemas viabilidad.
• Clarificar entendimiento: Descubre ambigüedades requisitos (ej: usuario dice «quiero ver datos» → prototipo muestra qué layout exacto prefiere).
• Mejorar diseño UX: Iteraciones rápidas feedback → UI mejorada ANTES desarrollo coste alto.
• Acelerar desarrollo: Equipo desarrollo tiene visión clara (vs interpretaciones contradictorias requisitos vagos) → desarrollo más eficiente.
• Facilitar comunicación: Prototipo visual comunica mejor que mil palabras documentación.

DESVENTAJAS:

• Gestionar expectativas**: Cliente puede pensar prototipo = sistema final (requiere comunicación clara qué es prototipo).
• Overhead tiempo/coste: Fase prototipado adicional (aunque coste bajo, suma tiempo total proyecto).
• Posible sesgo**: Prototipo puede orientar mal decisiones (si prototipo no representa adecuadamente visión final).
• Scope creep**: Usuarios pueden pedir «una cosita más» durante demostraciones prototipo → scope expansion no controlada.

4.6. Prototipado en Contexto SAS

Aplicaciones reales:

• Nuevas funcionalidades Diraya: Antes desarrollar módulo completo, crear prototipo interfaz (Figma mockups interactivos) → demostraciómn médicos piloto → feedback → refinamiento diseño.
• Aplicaciones móviles: ClicSalud+, apps tablet médicos → prototipos rápido validar UX (gestos, navegación) ANTES inversión desarrollo full.
• Integraciones complejas: Prototipo HL7 integración laboratorio + Diraya → validar formato mensajes, flujos datos ANTES contratación proveedor oficial.
• Innovación IA/Big Data: Prototipo IA análisis radiografías, prototipo dashboards analíticos → MVP rápido validar concepto.

Limitaciones SAS (contexto público):

• Contratación LCSP: Prototipado implica cambios requisitos → puede NO encajar contratos cerrados alcance.
• Presupuesto: Fase prototipado adicional requiere presupuesto específico (vs empresas privadas que absorben costo).
• Cambios normativos**: Requisitos sanitarios pueden cambiar regulación (ej: RGPD nuevas normas) → prototipo puede quedar obsoleto rápido.

5. Fases Detalladas del SDLC

5.1. Fase 1: Planificación e Iniciación

Objetivo: Definir proyecto, justificar inversión, establecer alcance alto nivel.

Actividades:

• Identificar necesidad negocio (problema actual, oportunidad, regulación nueva).
• Análisis viabilidad (técnico, económico, organizacional).
• Análisis coste-beneficio: ROI proyecto (inversión X → ahorros/beneficios Y).
• Identificar stakeholders, patrocinador proyecto, equipo alto nivel.
• Estimación preliminar recursos, plazo, presupuesto.

Entregables: Business Case, Project Charter, Plan Proyecto preliminar.

5.2. Fase 2: Análisis de Requisitos

Objetivo: Entender QUÉ debe hacer sistema (requisitos funcionales + no funcionales).

Actividades:

• Recopilar requisitos (entrevistas stakeholders, workshops, análisis documentos actuales).
• Modelar procesos negocio (AS-IS estado actual, TO-BE estado deseado).
• Definir requisitos funcionales (qué funciona: crear usuario, registrar consulta…).
• Definir requisitos no funcionales (cómo: rendimiento, seguridad, escalabilidad…).
• Casos uso: interacciones usuario-sistema (flujos principales, excepciones).
• Validar requisitos con stakeholders (acuerdo TODOS requisitos).

Entregables: Documento Requisitos (SRS), Casos Uso, Modelos Procesos, Matriz Trazabilidad Requisitos.

5.3. Fase 3: Diseño (Arquitectónico + Detallado)

Objetivo: Definir CÓMO se construirá sistema.

Diseño Arquitectónico:

• Arquitectura alto nivel (componentes, módulos, cómo interactúan).
• Decisiones tecnología (lenguajes, BBDD, frameworks, cloud vs on-premise).
• Diagrama despliegue (servidor app, BBDD, balanceador carga…).
• Estrategia seguridad, backup, disaster recovery.

Diseño Detallado:

• Diseño interfaces usuario (mockups, wireframes, prototipo interactivo).
• Modelo datos (tablas, relaciones, índices BBDD).
• Diseño componentes (clases, métodos, responsabilidades).
• APIs externas, integraciones terceros.
• Procedimientos almacenados, triggers BBDD (si aplica).

Entregables: Documento Diseño Arquitectónico, Diagramas UML (casos uso, secuencia, componentes, despliegue), Modelo Datos, Mockups UI, Documento APIs.

5.4. Fase 4: Implementación (Codificación)

Objetivo: Construir sistema (desarrollar código).

Actividades:

• Codificación componentes según diseño (Java, Python, C#, JavaScript…).
• Versionado código (Git, GitLab, mercurial…).
• Testing unitario (desarrollador prueba componentes individuales).
• Code review (revisión código peers, estándares de calidad).
• Documentación código (comentarios, docstrings, README).
• Integración continua (código integra repositorio central, builds automáticos).

Entregables: Código fuente (repositorio Git), Tests Unitarios, Documentación Código, Builds Ejecutables.

5.5. Fase 5: Testing (Control Calidad)

Objetivo: Verificar sistema funciona, cumple requisitos, calidad acceptable.

Niveles Testing:

• Testing Unitario (desarrolladores): Componentes individuales.
• Testing Integración: Componentes juntos, comunicación correcta.
• Testing Sistema: Sistema completo end-to-end (todos componentes + BBDD).
• Testing Aceptación Usuario (UAT): Usuarios finales validan cumple requisitos.
• Testing Rendimiento: ¿Sistema aguanta carga esperada? Tiempo respuesta?
• Testing Seguridad: Pentesting, análisis vulnerabilidades, compliance ENS.

Entregables: Plan Testing, Casos Test, Informes Bugs/Defectos, Certificación UAT, Reporte Cobertura Testing.

5.6. Fase 6: Despliegue (Go-Live)

Objetivo: Poner sistema producción operativo.

Actividades:

• Preparación entorno producción (servidores, BBDD, configuración).
• Migración datos (cargar históricos sistema anterior → nuevo sistema).
• Testing post-migración (verificar datos migrados correctamente).
• Formación usuarios finales (manuales, webinars, on-site training).
• Comunicación usuarios (notificaciones cambio sistema, go-live date).
• Arranque (cutover) transitión sistema anterior → nuevo (puede ser Big Bang o gradual).
• Soporte post-go-live (N0 disponible 24/7 primeras semanas, resolver incidencias usuarios).

Entregables: Plan Despliegue, Manuales Usuario, Sistema Producción Operativo, Informe Go-Live.

5.7. Fase 7: Mantenimiento

Objetivo: Operar sistema, corregir problemas, evolucionar.

Tipos Mantenimiento:

• Correctivo: Corregir bugs reportados usuarios (incidencias).
• Perfectivo: Mejoras funcionalidad existente (usuarios piden optimizar, UI mejorada).
• Adaptativo: Cambios normativos/regulatorios (nueva ley RGPD, cambios Seguridad Social).
• Preventivo: Mantenimiento evitar problemas (actualizaciones SO, parches seguridad).

Estadística industria: Mantenimiento consume 60-80% esfuerzo ciclo vida sistema (NO solo «desarrollo inicial»).

Entregables: Parches/Hotfixes, Nuevas Versiones, Reportes Incidencias, Documentación Cambios.

5.8. Fase 8: Retiro (Obsolescencia)

Objetivo: Retirar sistema obsoleto, migrar usuario sucesor.

Actividades:

• Identificar obsolescencia (tecnología muy antigua, costes mantenimiento > beneficios, funcionalidad NO soporta requisitos nuevos).
• Evaluar alternativas (update actual sistema, reemplazo completo, sunset gradual).
• Planificar migración (cómo transferir usuarios al nuevo sistema).
• Archivar histórico (datos legales deben guardarse, regularidad retención).
• Desmantelar infraestructura (apagar servidores, liberar licencias, reciclaje hardware).

Ejemplo: Si Diraya en 2050 tecnología completamente obsoleta (ej: reemplazado sistema cuántico IA), plan retiro incluiría: archivar 50 años HC pacientes, migrar usuarios plataforma nueva, desmantelar data centers heredados.

6. Aplicación del SDLC en el Contexto del SAS

6.1. Ciclo Vida Diraya (Ejemplo Real)

Diraya: Evolución Histórica según SDLC:

• Planificación (años 90): SAS identifica necesidad HCE única Andalucía. Análisis viabilidad. Justificación inversión (mejorar acceso información pacientes, reducir duplicación, mejorar calidad asistencia).
• Análisis Requisitos (finales 90-2000): Recopilar requisitos profesionales (médicos, enfermeras, administrativos). Modelar procesos clínicos (consulta, prescripción, alergias…). Casos uso extensos. Versión 1.0 requisitos = HCE básica.
• Diseño (2000-2001): Arquitectura Diraya (módulos: HC, prescripción, PACS viewer, alertas). Decisión tecnología: aplicación web Java (vs escritorio). BBDD: Oracle. Interfaces web intuitiva médicos. Seguridad: autenticación centralizada, cifrado HC.
• Implementación (2001-2003): Desarrollo Diraya versión 1.0 por Everis (proveedor). Codificación módulos core. Integración componentes. Testing unitario.
• Testing (2002-2003): UAT hospitales piloto (ej: Hospital Virgen del Rocío, Complejo Hospitalario Jaén). Usuarios finales prueban HC, prescripción, citas. Bugs identificados + corregidos. Certificación calidad.
• Despliegue (2003-2005): Rollout Diraya progresivo hospitales Andalucía. Migración datos HCs existentes (de sistemas antiguos diferentes). Formación masiva profesionales (centenares horas formación). Go-live gestión por fases (hospital a hospital, servicio a servicio).
• Mantenimiento (2005-actualidad):
  • Correctivo: Bugs usuarios reportan, hotfixes Everis (ej: error filtrado búsqueda HC, problema sincronización farmacia).
  • Perfectivo: Mejoras «Diraya 4.0 → 5.0 → 6.0 → 6.3…» versiones anuales con nuevas funcionalidades.
  • Adaptativo: Cambios regulatorios (RGPD → nuevas tablas consentimiento, normativa receta electrónica → integración SINAUTO).
  • Preventivo: Actualizaciones OS, parches seguridad Oracle, mejora performance BBDD.

6.2. MCMI como Implementación SDLC SAS

Conexión directa:

• MCMI = SDLC especializado SAS para fase Despliegue + Mantenimiento inicial de sistemas.
• Asume: Sistema (ej: Diraya) ya existe, fue desarrollado (cumplió fases Análisis-Diseño-Implementación-Testing de SDLC anterior).
• Propósito MCMI: Estructurar CÓMO implantar sistema existente nuevos hospitales (repliquero Diraya Hospital X → Hospital Y, Hospital Z…).

Mapeo MCMI ↔ Fases SDLC:

6.3. Desafíos SDLC Sistemas Sanitarios SAS

• Complejidad organizacional: Múltiples stakeholders (médicos, enfermeras, administrativos, dirección) con necesidades conflictivas.
• Requisitos cambiantes: Normativa salud evoluciona (nuevas prestaciones, cambios financiación) → impacta requisitos Diraya continuamente.
• Disponibilidad crítica: NO puede parar (vidas en riesgo) → testing exhaustivo, rollback plans críticos.
• Datos sensibles: HC pacientes requieren máxima seguridad, cumplimiento RGPD estricto (impacta diseño, testing, mantenimiento).
• Presupuestos públicos: Limitados, requieren justificación ROI rigurosa, cambios presupuesto afectan plazos/alcance.
• Resistencia cambio: Profesionales sanitarios acostumbrados procesos antiguos, formación NO suficiente (requiere gestión cambio intensiva).
• Legacy systems: Muchos hospitales tienen sistemas antiguos incompatibles → integraciones complejas, migraciones datos problemáticas.

7. Cuestionario de Autoevaluación – 25 Preguntas Tipo Test (TEMA 39)

                        SDLC
                         |
        ┌────────────────┼────────────────┐
        |                |                |
    8 FASES          4 MODELOS        TÉCNICAS
    GENÉRICAS        PRINCIPALES         |
        |                |               |
    1.Planificación  Waterfall       Prototipado
    2.Análisis       (Cascada)       (Desechable
    3.Diseño         ├─ Secuencial    Evolutivo)
    4.Impl.          ├─ Requisitos    |
    5.Testing        │  estables      Testing
    6.Despliegue     │  (fijos)       (5 niveles)
    7.Mant.          ├─ Testing final |
    8.Retiro         └─ Alto riesgo   Integración
                        Big Bang      Continua
                                       (CI/CD)
                    V-Model           DevOps
                    ├─ Secuencial
                    ├─ Testing cada
                    │  fase (aligned)
                    └─ Mejor calidad
                       vs Waterfall

                    Incremental
                    ├─ Múltiples
                    │  versiones
                    ├─ Cada V entrega
                    │  funcionalidad
                    └─ Valor temprano

                    Ágil (Scrum)
                    ├─ Sprints cortos
                    │  2-4 sem
                    ├─ Requisitos
                    │  emergentes
                    ├─ Feedback
                    │  continuo
                    └─ Iterativo

                    Espiral
                    ├─ Gestión riesgos
                    ├─ Iteraciones
                    │  crecientes
                    └─ Prototipado

                    RAD
                    ├─ Desarrollo
                    │  ultra-rápido
                    ├─ Low-code
                    └─ MVP en semanas

                    DevOps
                    ├─ Dev-Ops
                    │  integrado
                    ├─ CI/CD
                    │  automático
                    ├─ Deploy
                    │  varias veces día
                    └─ Infraestructura
                       como Código

    APLICACIÓN SAS:
    ├─ Diraya: Ciclo vida real 1990→2024+ (8 fases SDLC)
    ├─ MCMI: Modelo SAS especializado fase Despliegue
    └─ Modelos: Waterfall (infraestructura), Ágil (Diraya versiones)