Tema 40
Análisis Funcional de Sistemas de Información
Casos de Uso, UML, Modelado de Dominio, Análisis Dinámico (BPMN/CMMN), Aspectos No-Funcionales
Oposición Técnico/a de Función Administrativa – Opción Sistemas y Tecnología de la Información (TFA-STI) del SAS
🎯 Por qué Análisis Funcional es CRÍTICO para tu futuro TFA-STI
Conexión temas anteriores:
- Tema 39 (Ciclo Vida): «En fase ANÁLISIS del SDLC, recopilar requisitos»
- Tema 40 (AHORA): «CÓMO hacer ese análisis profesionalmente» ← estás aquí
Realidad trabajo SAS: Cuando participas proyecto implantación Diraya nueva hospital (o cualquier sistema), equipo hace:
- Casos de Uso: «¿Qué flujos usuario necesitas?» (médico registra consulta, enfermera solicita analítica…)
- UML Diagramas: Visualizar arquitectura sistema (qué clases, cómo interactúan)
- Modelado Dominio: «¿Qué son entidades clave?» (Paciente, HC, Consulta, Medicamento…)
- BPMN: Mapear procesos sanitarios complejos (flujo paciente Urgencias → triaje → médico → farmacia…)
- Seguridad/Rendimiento: «¿Sistema soporta 15.000 usuarios simultáneos sin caída?» «¿HC cifradas correctamente?»
En examen: Preguntas sobre diagramas UML (tipos, cuándo usar), casos uso, modelado ER, BPMN, requisitos no-funcionales (típico 10-15 preguntas directas).
Ventaja competitiva: Si dominas UML + casos uso, comunicas análisis con arquitectos + producto owners como profesional (NO junior). Rapidez carrera = dominar estas técnicas.
1. Introducción al Análisis Funcional de Sistemas de Información
1.1. ¿Qué es Análisis Funcional?
Definición
El Análisis Funcional es el proceso detallado de identificar, documentar, validar REQUISITOS FUNCIONALES (QUÉ debe hacer el sistema) y NO FUNCIONALES (CÓMO debe hacerlo: rendimiento, seguridad…).
Diferencia Análisis Funcional vs Técnico:
- Análisis Funcional: QUÉ requisitos negocio/usuario (perspectiva usuario, médico, administrativo).
- Análisis Técnico: CÓMO implementar requisitos (arquitectura, tecnología, componentes internos) ← viene después.
Ejemplo SAS:
- Requisito Funcional (Análisis): «Médico debe ver histórico consultas paciente últimos 5 años con filtros por especialidad.»
- Requisito Técnico (posterior): «Implementar índices BBDD optimizar query <2 segundos, cache Redis para consultas frecuentes, paginación 50 registros..."
1.2. Objetivo Análisis Funcional
Producir documento Especificación Requisitos (SRS) que:
- Completo: Cubra TODOS requisitos funcionales (NO falten funcionalidades).
- Consistente: Requisitos NO contradictorios entre sí.
- Claro: Entendible stakeholders técnicos + NO técnicos (médicos, directores…).
- Verificable: Cada requisito testeable (medible, validable).
- Trazable: Nexo requisito ↔ casos uso ↔ tests ↔ entregables.
1.3. Técnicas Análisis Funcional (Este Tema 40)
Este tema cubre técnicas documentar requisitos:
| Técnica | Propósito | Representa |
|---|---|---|
| Casos de Uso | Documentar interacciones usuario-sistema flujos principales | QUÉ usuario puede hacer (perspectiva usuario exterior) |
| Historias de Usuario | Formato ágil requisitos (vs casos uso formales) | Narrativa simple «Como médico, quiero…» |
| UML Diagramas | Visualizar estructura, comportamiento sistema | Entidades, relaciones, flujos, secuencias, componentes |
| Modelado Dominio | Identificar conceptos clave negocio (entidades) | Qué son datos principales (Paciente, HC, Medicamento…) |
| Modelo Entidad-Relación (ER) | Visualizar entidades + relaciones BBDD | Estructura datos (tablas, atributos, claves foráneas) |
| BPMN/CMMN | Mapear procesos negocio complejos | Flujos operativos detallados (quién hace qué, cuándo, decisiones) |
| Requisitos No-Funcionales | Documentar atributos de calidad | Rendimiento, seguridad, disponibilidad, escalabilidad… |
1.4. Rol Analista Funcional en Proyectos SAS
Responsabilidades:
- Recopilar requisitos: Entrevistas médicos, enfermeras, administrativos, directivos.
- Modelar procesos: Entender flujos actuales (AS-IS), visualizar deseados (TO-BE).
- Documentar especificaciones: Escribir SRS, casos uso, diagramas UML.
- Validar con stakeholders: Asegurar interpretación correcta requisitos (sesiones validación).
- Facilitar comunicación: Traducir entre «lenguaje médico» (usuario) y «lenguaje técnico» (arquitecto/desarrollador).
- Gestionar cambios requisitos: Cuando usuario pide nuevos requisitos mid-proyecto (change control).
- Testing acceptance: Colaborar UAT (preparar test cases, validar funcionalidades).
Ejemplo real SAS: Implantación módulo Telemedicina Diraya novo hospital
- Analista funcional entrevista médicos: «¿Qué funcionalidades necesitáis telemedicina?»
- Recopila requisitos (video consulta, grabación, compartir pantalla, recetas electrónicas…
- Crea casos uso: «Caso: Médico atiende paciente telemedicina»
- Dibuja diagramas UML (qué classes HC, Consulta Telemedicida, Grabación…)
- Mapea flujo BPMN (paciente cita online → entra video → médico atiende → receta → farmacia)
- Define requisitos no-funcionales (video max 2 segundos latencia, 99.5% uptime, RGPD compliance…).
- Documento final SRS → equipo desarrollo implementa → testing ✓
✅ Reflexión TFA-STI: Como técnico SAS, podrías NO ser analista funcional puro (ese rol especializado). PERO:
- Necesitarás ENTENDER UML, casos uso (leer especificaciones desarrollador = «hazme esto de SRS»).
- En meetings equipo técnico/producto, hablarán UML, BPMN, requisitos ← debes entender.
- Si asciendes (arquitecto, líder técnico), DEBES dominar estas técnicas.
- Muchas oposiciones (TFA-STI) incluyen preguntas análisis → este conocimiento impacta nota.
2. Casos de Uso e Historias de Usuario
Contexto: Casos de Uso e Historias de Usuario son dos técnicas para documentar QUÉ usuario puede hacer con el sistema. Similares en objetivo, diferente formato (formal vs ágil).
2.1. Casos de Uso (Use Cases)
¿Qué es un Caso de Uso?
Un Caso de Uso es una descripción detallada, estructurada de una interacción usuario-sistema que describe QUÉ hace usuario y CÓMO sistema responde para lograr objetivo específico.
Componentes Caso de Uso:
- Nombre: Verbo + sustantivo (ej: «Registrar Consulta», «Ver Histórico Paciente»).
- Actor primario: Usuario que inicia caso uso (ej: Médico, Enfermera, Administrativo).
- Precondición: Estado sistema ANTES caso uso (ej: «Usuario autenticado en Diraya»).
- Flujo principal (happy path): Pasos 1-N usuario + sistema para completar objetivo (éxito).
- Flujos alternativos: Variaciones flujo principal (ej: usuario cancela, datos inválidos…).
- Postcondición: Estado sistema DESPUÉS caso uso completado (ej: «Consulta registrada BBDD, notificación enviada»).
📋 Caso de Uso UC-001: Registrar Consulta Médica
ID: UC-001
Nombre: Registrar Consulta Médica
Actor Primario: Médico
Nombre: Registrar Consulta Médica
Actor Primario: Médico
PRECONDICIÓN:
– Médico autenticado en Diraya
– Paciente seleccionado (histórico abierto)
FLUJO PRINCIPAL:
1. Médico hace clic en «Nueva Consulta»
2. Sistema muestra formulario consulta en blanco
3. Médico ingresa motivo consulta (síntomas)
4. Médico ingresa hallazgos exploración física
5. Médico busca y selecciona diagnóstico (CIE-10)
6. Médico prescribe medicamentos (opcional)
7. Médico guarda consulta
8. Sistema valida datos completitud
9. Sistema guarda consulta en BBDD
10. Sistema muestra confirmación «Consulta guardada»
FLUJOS ALTERNATIVOS:
3a. Paciente urgencia grave:
3a1. Sistema marca consulta prioridad alta automática
3a2. Notifica enfermería preparar sala procedimientos
3a1. Sistema marca consulta prioridad alta automática
3a2. Notifica enfermería preparar sala procedimientos
8a. Validación falla (campos obligatorios vacíos):
8a1. Sistema muestra error campos requeridos
8a2. Médico completa campos faltantes
8a3. Vuelve paso 7
8a1. Sistema muestra error campos requeridos
8a2. Médico completa campos faltantes
8a3. Vuelve paso 7
POSTCONDICIÓN:
– Consulta registrada en HC paciente
– Notificación enviada farmacia (si hay medicamentos)
2.2. Historias de Usuario (User Stories)
¿Qué es Historia Usuario?
Formato ágil documentar requisitos. Narrativa simple desde perspectiva usuario que expresa NECESIDAD + RAZÓN.
Formato estándar: «Como [TIPO USUARIO], quiero [ACCIÓN], para [BENEFICIO]»
Ejemplos Historias Usuario – Sistema Diraya
HU-001: Como médico, quiero buscar paciente por DNI/nombre, para acceder rápidamente a su HC sin navegar listas.
HU-002: Como enfermera, quiero ver alergias paciente destacadas en rojo, para evitar administrar medicamentos peligrosos.
HU-003: Como administrativo, quiero exportar estadísticas consultas mensuales, para reportar actividad a dirección.
2.3. Diferencias Casos Uso vs Historias Usuario
| Aspecto | Casos de Uso | Historias de Usuario |
|---|---|---|
| Formato | Estructurado, formal, detallado | Narrativa simple, 1-2 frases |
| Nivel detalle | Alto (flujos completos, alternativas) | Bajo (conversación starting point) |
| Metodología | Waterfall, RUP, tradicional | Ágil, Scrum, XP |
| Tiempo crear | Horas-días por caso uso | Minutos por historia |
| Uso típico | Contratos formales, documentación completa | Sprint planning, backlog ágil |
3. UML (Lenguaje Unificado de Modelado) – Diagramas Principales
¿Qué es UML?
UML (Unified Modeling Language) es estándar notación gráfica para visualizar, especificar, documentar sistemas software. Permite comunicar diseño de forma visual (diagramas) vs puramente texto.
3.1. Diagrama de Clases (Class Diagram)
Propósito: Mostrar estructura estática (clases, atributos, métodos, relaciones).
Ejemplo: Diagrama Clases Diraya (Sistema Consultas)
┌──────────────────────┐
│ Paciente │
├──────────────────────┤
│- id: String │
│- nombre: String │
│- DNI: String │
│- fechaNacimiento: Date│
│- alergias: String[] │
├──────────────────────┤
│+ getId() │
│+ addAlergias(alergia)│
│+ getHistórico() │
└──────────────────────┘
│
│ 1..* (asociación: paciente tiene muchas)
│
┌──────────────────────┐
│ Consulta │
├──────────────────────┤
│- id: String │
│- fecha: Date │
│- síntomas: String │
│- diagnóstico: String │
│- medicamentos: Med[] │
├──────────────────────┤
│+ getId() │
│+ guardar() │
│+ addMedicamento(med) │
└──────────────────────┘
│
│ 0..* (una consulta puede tener)
▼
┌──────────────────────┐
│ Medicamento │
├──────────────────────┤
│- id: String │
│- nombre: String │
│- dosis: Float │
│- duracion: Integer │
├──────────────────────┤
│+ getDosis() │
│+ getContraindicación()
└──────────────────────┘
Herencia:
┌──────────────────────┐
│ Profesional (Abstract)
├──────────────────────┤
│- id: String │
│- nombre: String │
│- especialidad: String│
└──────────────────────┘
▲
│ (herencia)
┌────┴────┐
│ │
┌────────┐ ┌────────┐
│Médico │ │Enfermera│
└────────┘ └────────┘
3.2. Diagrama de Secuencia (Sequence Diagram)
Propósito: Mostrar interacciones entre objetos en tiempo (secuencia mensajes).
Ejemplo: Diagrama Secuencia «Médico Registra Consulta» (Diraya)
Médico Diraya UI Diraya Backend BBDD
│ │ │ │
│─ clic «Guardar» ──→ │ │ │
│ │─ validar datos ────→ │ │
│ │ ← OK/ERROR ─────────│ │
│ │ │─ INSERT Consulta─→
│ │ │ ← ID generado ─│
│ │ ← guardarOK() ─────│ │
│ ← «Consulta guardada» ← │ │
│ │ │─ notificar Farmacia─→
│ │ │ (integración SINAUTO) │
alt [tiene medicamentos]
│ │ │ │
│ │ │─ INSERT Prescrip ─→
│ │ │ ← OK ─────────│
end
3.3. Diagrama de Actividad (Activity Diagram)
Propósito: Mostrar flujo lógico proceso (similar BPMN pero más técnico).
Ejemplo: Flujo «Registrar Consulta» (Activity Diagram)
[Inicio]
│
▼
[Abrir Formulario Consulta]
│
▼
[Seleccionar Tipo Consulta]
│
▼
[Ingresar Síntomas]
│
▼
◇ ¿Datos válidos?
╱ ╲
No Sí
│ │
└─────┤ [Mostrar Error]
│ (vuelta anterior)
▼
[Seleccionar Diagnóstico (CIE-10)]
│
▼
[Prescribir Medicamentos]
│
▼
◇ ¿Contraindicación?
╱ ╲
Sí No
│ │
[Alerta + Confirmar]
│ │
└────┬┘
▼
[Guardar Consulta BBDD]
│
▼
◇ ¿Éxito?
╱ ╲
Sí No
│ │ [Error Transacción]
│ └─┐ [Reintento]
│ │ (max 3 veces)
▼ │
[Enviar Notificación Farmacia]
│ │
└──────┤
▼
[Mostrar Confirmación Usuario]
│
▼
[Fin]
3.4. Diagrama de Componentes (Component Diagram)
Propósito: Mostrar componentes software y dependencias (módulos, librerías, servicios).
Ejemplo: Arquitectura Diraya (Component Diagram simplificado)
┌─────────────────────────┐
│ Cliente Web (React) │
└────────────┬────────────┘
│ HTTP/REST
▼
┌─────────────────────────────────────────┐
│ API Gateway (Spring Boot) │
└────────┬────────────┬────────────┬──────┘
│ │ │
┌────▼───┐ ┌────▼───┐ ┌──▼──────┐
│ Consulta│ │ Paciente│ │Recetas │
│Service │ │Service │ │Service │
└────┬────┘ └────┬────┘ └──┬──────┘
│ │ │
└─────────────┼────────────┘
│ JDBC
▼
┌──────────────────────────┐
│ Oracle BBDD Diraya │
└──────────────────────────┘
│
┌───┴────┐
│ Legacy │
│ Systems│
└────────┘
(PACS, Laboratorio, Farmacia)
3.5. Cuándo Usar Cada Diagrama UML
| Diagrama | Propósito | Fase SDLC | Examen SAS Probabilidad |
|---|---|---|---|
| Clases | Estructura estática (entidades, relaciones) | Diseño | ⭐⭐⭐⭐⭐ ALTA |
| Secuencia | Interacciones objetos (flujos temporales) | Diseño/Implementación | ⭐⭐⭐ MEDIA |
| Actividad | Flujos lógicos procesos | Análisis/Diseño | ⭐⭐ BAJA |
| Casos Uso | Qué sistema hace (requisitos usuario) | Análisis | ⭐⭐⭐⭐ ALTA |
| Componentes | Arquitectura software (módulos) | Diseño Arquitectónico | ⭐⭐⭐ MEDIA |
4. Análisis de Dominio: Modelado de Dominio, ER, y No-Funcionales
4.1. Modelado de Dominio
¿Qué es?: Identificación conceptos clave negocio (entidades principales, atributos, relaciones). Precede diseño BBDD formal.
Ejemplo Diraya: Entidades clave = Paciente, Consulta, Medicamento, Diagnóstico (CIE-10), Profesional, Prueba Diagnóstica, HC.
🗄️ Sección 4.2: Modelo Entidad-Relación (ER)
Diseño estructura BBDD Diraya – Ejemplo simplificado
📌 Propósito:
Diseñar estructura BBDD (tablas, atributos, claves, relaciones 1:1, 1:N, N:N)
Ejemplo simplificado Diraya (ER Diagrama)
TABLAS Y ATRIBUTOS:
═══════════════════════════════════════════════════
PACIENTE (1 : N) CONSULTA
├─ id_paciente (PK – Primary Key)
├─ nombre (VARCHAR 100)
├─ DNI (UNIQUE – identificador único)
├─ fecha_nacimiento (DATE)
├─ alergias (TEXT – lista medicamentos alergia)
├─ fecha_alta (DATE)
└─ historial_clínico (CLOB – datos históricos)
CONSULTA (N : N) MEDICAMENTO
├─ id_consulta (PK)
├─ id_paciente (FK – Foreign Key → PACIENTE)
├─ id_profesional (FK → PROFESIONAL)
├─ fecha_consulta (DATE)
├─ síntomas (TEXT 0-5000 caracteres)
├─ hallazgos (TEXT – exploración física)
├─ diagnóstico (VARCHAR – descripción CIE-10)
└─ observaciones (TEXT – notas clínicas)
CONSULTA (1 : N) DIAGNÓSTICO_CIE10
├─ id_diagnostico (PK)
├─ id_consulta (FK)
└─ codigo_cie10 (FK → CIE10 tabla catálogo)
MEDICAMENTO (catálogo)
├─ id_medicamento (PK)
├─ nombre (VARCHAR)
├─ principio_activo (VARCHAR)
└─ dosis_max (DECIMAL)
PROFESIONAL (1 : N) CONSULTA
├─ id_profesional (PK)
├─ nombre (VARCHAR)
├─ especialidad (VARCHAR)
├─ numero_colegiado (UNIQUE)
└─ centro_trabajo (VARCHAR)
RELACIONES:
═══════════════════════════════════════════════════
• Relaciones 1:N (línea con 1 lado y N lado)
• Relaciones N:N (línea con N ambos lados, requiere tabla intermedia)
• PK = Primary Key (identifica única fila tabla)
• FK = Foreign Key (vincula a otra tabla)
📖 Leyenda Modelo ER
1:N (Uno a Muchos):
1 Paciente tiene MUCHAS Consultas. Implementado: FK id_paciente en tabla CONSULTA
N:N (Muchos a Muchos):
1 Consulta usa MUCHOS Medicamentos, 1 Medicamento en MUCHAS Consultas. Requiere tabla intermedia CONSULTA_MEDICAMENTO
PK (Primary Key):
Clave primaria identifica única cada fila. Ej: id_paciente, id_consulta
FK (Foreign Key):
Clave foránea vincula tablas. Ej: id_paciente en CONSULTA referencia PACIENTE.id_paciente
4.3. BPMN y CMMN (Modelado Procesos)
BPMN (Business Process Model and Notation): Estándar notación procesos negocio (similar Activity Diagram UML pero más orientado procesos). Elementos: Eventos (círculos), Actividades (rectángulos), Compuertas Lógicas (diamantes), Carriles (swimlanes por rol).
CMMN (Case Management Model and Notation): Para procesos NO lineales (casos ad-hoc, decisiones complejas). Menos usado en examen TFA-STI.
Ejemplo BPMN: Proceso «Paciente Llega Urgencias» (SAS simplificado)
Paciente Recepción Triaje Médico Farmacia
│ │ │ │ │
│─ Llega ────────→ │ │ │ │
│ (Evento Inicio) │ │ │ │
│ │─ Registro ──→ │ │ │
│ │ (Actividad) │ │ │
│ │ │─ Evaluar ─────→ │ │
│ │ │ (Actividad) │ │
│ │ │ │─ Prescribir ──│
│ │ │ ◇ ¿Urgencia? │ (Actividad) │
│ │ ╱ ╲ │ │
│ │ Alto Bajo │ │
│ │ │ │ │ │
│ │ [Atender [Esperar] │ │
│ │ prioritario] │ │
│ │ │ │ │ │
│ │ └──────┤────────────│ │
│ │ │ │ │
│ │ └─ Derivar ──│ │
│ │ (Actividad) │ │
│ │ │─ Dispensar ──→ │
│ │ │ (Actividad) │
│◄───────────────────────────────────────────────── │ (Evento Fin) │
│ (Alta)
Carriles por roles (Paciente, Recepción, Triaje, Médico, Farmacia)
Compuertas ◇ = decisiones lógicas (alto/bajo riesgo)
Actividades = tareas (Registro, Evaluar, Prescribir…)
Eventos = inicio/fin proceso
4.4. Requisitos No-Funcionales (Aspectos Clave)
Requisitos No-Funcionales: Atributos CALIDAD sistema (cómo debe hacerlo, NO qué). Críticos definir temprano (impactan arquitectura).
Principales categorías:
| Categoría | Descripción | Ejemplo Diraya |
|---|---|---|
| Rendimiento | Velocidad, throughput, latencia | Búsqueda HC paciente <2 seg, 99.5% uptime, soportar 15.000 usuarios simultáneos |
| Seguridad | Autenticación, encriptación, acceso controlado | RBAC (médico solo ve pacientes asignados), TLS cifrado tránsito, 2FA opcional |
| Privacidad | RGPD, protección datos sensibles | Cifrado datos reposo (AES-256), derecho olvido, auditoría 10 años, consentimiento explícito |
| Disponibilidad | Uptime, recovery, backup | Backup diarios, recovery <4h, RTO 2h, RPO 1h |
| Escalabilidad | Crecer sin degradación | Arquitectura cloud auto-scaling, BBDD replicada, caching distribuido (Redis) |
| Usabilidad | Interfaz intuitiva, accesibilidad | WCAG 2.1 AA compliance, interfaz médico <5 minutos aprender, responsive mobile |
| Mantenibilidad | Código limpio, documentación, logs | Code style enforcement, cobertura tests >80%, logs DEBUG nivel, JavaDocs |
| Interoperabilidad | Integración sistemas externos | APIs REST+JSON, HL7v2/FHIR para clínicas, integración farmacia SINAUTO, PACS DICOM |
📝 Documento Requisitos No-Funcionales típico:
- RNF-001: Performance – Búsqueda HC <2 segundos, percentil p95
- RNF-002: Security – Encriptación AES-256 en reposo, TLS 1.3 en tránsito
- RNF-003: Availability – 99.5% uptime mensual (máx 3.6 horas downtime)
- RNF-004: Scalability – Soportar 100% crecimiento usuarios sin cambios arquitectura
- RNF-005: Privacy – RGPD compliance (derecho olvido, portabilidad, auditoría)
5. Cuestionario Tema 40 – 25 Preguntas (Estilo Examen OEP 2025 SAS)
📝 Instrucciones
25 preguntas análisis funcional, UML, modelado, BPMN, requisitos no-funcionales. Formato: múltiple choice (A, B, C, D). Tiempo: 50 minutos. Objetivo: >20 correctas (80%).
Pregunta 1
¿Cuál es diferencia principal entre requisito funcional y no-funcional?
Respuesta correcta: A
Funcional: requisitos negocio usuario (QUÉ). No-funcional: atributos calidad (CÓMO, rendimiento, seguridad, disponibilidad…).
Funcional: requisitos negocio usuario (QUÉ). No-funcional: atributos calidad (CÓMO, rendimiento, seguridad, disponibilidad…).
Pregunta 2
Caso de Uso típicamente incluye (seleccione INCORRECTO):
Respuesta correcta: D
Casos uso: requisitos NIVEL USUARIO (QUÉ hace), NO código implementación (eso viene después, fase Desarrollo).
Casos uso: requisitos NIVEL USUARIO (QUÉ hace), NO código implementación (eso viene después, fase Desarrollo).
Pregunta 3
Historia de Usuario formato estándar es:
Respuesta correcta: A
Historias Usuario = formato Ágil narrativa simple (perspectiva usuario, motivo). Casos Uso = forma estructurada formal.
Historias Usuario = formato Ágil narrativa simple (perspectiva usuario, motivo). Casos Uso = forma estructurada formal.
Pregunta 4
¿Cuál es propósito PRINCIPAL Diagrama de Clases UML?
Respuesta correcta: A
Diagrama Clases: arquitectura estática (qué clases existen, atributos, métodos, herencia, asociaciones).
Diagrama Clases: arquitectura estática (qué clases existen, atributos, métodos, herencia, asociaciones).
Pregunta 5
En UML, símbolo flecha «▲» (triángulo vacío) representa:
Respuesta correcta: A
Flecha triángulo vacío = herencia (Médico hereda Profesional). Línea simple = asociación. Rombo = agregación/composición.
Flecha triángulo vacío = herencia (Médico hereda Profesional). Línea simple = asociación. Rombo = agregación/composición.
Pregunta 6
Diagrama de Secuencia muestra:
Respuesta correcta: A
Secuencia: actores/objetos eje horizontal, línea vida vertical, mensajes flechas diagonales (eje tiempo).
Secuencia: actores/objetos eje horizontal, línea vida vertical, mensajes flechas diagonales (eje tiempo).
Pregunta 7
Modelo Entidad-Relación (ER) es:
Respuesta correcta: A
ER: diseño BBDD (entidades = tablas, atributos = columnas, relaciones = claves foráneas 1:N, N:N).
ER: diseño BBDD (entidades = tablas, atributos = columnas, relaciones = claves foráneas 1:N, N:N).
Pregunta 8
BPMN (Business Process Model and Notation) usa simbología:
Respuesta correcta: B
BPMN estándar: elementos característicos eventos/actividades/compuertas/carriles para procesos negocio (similar Activity UML pero más rico).
BPMN estándar: elementos característicos eventos/actividades/compuertas/carriles para procesos negocio (similar Activity UML pero más rico).
Pregunta 9
Relación 1:N en ER significa:
Respuesta correcta: A
1:N = entidad padre una instancia conecta múltiples hijo. Ej: Paciente(1) : Consulta(N). Implementado FK lado N.
1:N = entidad padre una instancia conecta múltiples hijo. Ej: Paciente(1) : Consulta(N). Implementado FK lado N.
Pregunta 10
Requisito No-Funcional CRÍTICO sector sanitario es:
Respuesta correcta: B
SAS sanitario: seguridad (HC pacientes sensibles), privacidad (RGPD), disponibilidad (sistemas NO fallan), rendimiento (usuario profesional impaciente). Vidas en riesgo = criticidad máxima.
SAS sanitario: seguridad (HC pacientes sensibles), privacidad (RGPD), disponibilidad (sistemas NO fallan), rendimiento (usuario profesional impaciente). Vidas en riesgo = criticidad máxima.
Pregunta 11
¿En qué fase SDLC típicamente se realizan Casos de Uso?
Respuesta correcta: A
Casos Uso = fase Análisis SDLC (antes Diseño). Documentan QUÉ usuario necesita (requisitos funcionales).
Casos Uso = fase Análisis SDLC (antes Diseño). Documentan QUÉ usuario necesita (requisitos funcionales).
Pregunta 12
Historias Usuario son típicamente usadas en:
Respuesta correcta: B
Historias Usuario = enfoque Ágil (XP, Scrum). Narrativas breves, tamaño Sprint (1-5 días), facilitan planning iterativo.
Historias Usuario = enfoque Ágil (XP, Scrum). Narrativas breves, tamaño Sprint (1-5 días), facilitan planning iterativo.
Pregunta 13
En un Diagrama de Clases UML, atributo «+nombre: String» significa:
Respuesta correcta: B
Visibilidad UML: + público, – privado, # protegido, ~ paquete. El «+» indica acceso público.
Visibilidad UML: + público, – privado, # protegido, ~ paquete. El «+» indica acceso público.
Pregunta 14
¿Qué relación ER requiere tabla intermedia?
Respuesta correcta: C
N:N necesita tabla intermedia (ej: CONSULTA_MEDICAMENTO vincula consultas con medicamentos). 1:N solo FK.
N:N necesita tabla intermedia (ej: CONSULTA_MEDICAMENTO vincula consultas con medicamentos). 1:N solo FK.
Pregunta 15
En BPMN, símbolo ◇ (diamante) representa:
Respuesta correcta: C
Diamante = compuerta decisión (if/else). Círculo = evento. Rectángulo = actividad. Líneas = flujos.
Diamante = compuerta decisión (if/else). Círculo = evento. Rectángulo = actividad. Líneas = flujos.
Pregunta 16
BPMN vs UML Activity Diagram diferencia principal:
Respuesta correcta: B
BPMN: procesos negocio (médicos, administrativos entienden). Activity UML: flujos técnicos/algoritmos (developers).
BPMN: procesos negocio (médicos, administrativos entienden). Activity UML: flujos técnicos/algoritmos (developers).
Pregunta 17
Requisito «Sistema disponible 99.5% tiempo» es:
Respuesta correcta: B
99.5% uptime = requisito NO funcional disponibilidad. Funcional sería «sistema permite registrar consulta».
99.5% uptime = requisito NO funcional disponibilidad. Funcional sería «sistema permite registrar consulta».
Pregunta 18
¿Cuál NO es diagrama UML estándar?
Respuesta correcta: D
Gantt = gestión proyectos (cronograma), NO diagrama UML. UML tiene 14 diagramas oficiales (clases, secuencia, actividad…).
Gantt = gestión proyectos (cronograma), NO diagrama UML. UML tiene 14 diagramas oficiales (clases, secuencia, actividad…).
Pregunta 19
Seguridad aplicación sanitaria debe incluir (seleccione MÁS importante):
Respuesta correcta: B
Seguridad: cifrado datos (AES-256), TLS conexiones, control acceso (RBAC), auditoría. Protegen HC pacientes (sensibles RGPD).
Seguridad: cifrado datos (AES-256), TLS conexiones, control acceso (RBAC), auditoría. Protegen HC pacientes (sensibles RGPD).
Pregunta 20
¿Cuál es atributo calidad más crítico sector sanitario?
Respuesta correcta: B
SAS: prioritarios Seguridad (HC sensibles), Privacidad (RGPD), Disponibilidad (vidas), Rendimiento (médico impaciente). Otros secundarios.
SAS: prioritarios Seguridad (HC sensibles), Privacidad (RGPD), Disponibilidad (vidas), Rendimiento (médico impaciente). Otros secundarios.
Pregunta 21
¿En qué tipo de proyecto típicamente se usan MÁS Casos de Uso?
Respuesta correcta: B
Casos Uso: énfasis Waterfall/formal. SAS contratos públicos (LCSP) requieren documentación completa especificaciones (casos uso se adecúan).
Casos Uso: énfasis Waterfall/formal. SAS contratos públicos (LCSP) requieren documentación completa especificaciones (casos uso se adecúan).
Pregunta 22
¿Qué herramienta es MÁS apropiada crear Diagramas UML?
Respuesta correcta: B
Herramientas UML: Lucidchart (online), Draw.io (gratuito), Enterprise Architect (profesional), VS (integrado). NO Word plano.
Herramientas UML: Lucidchart (online), Draw.io (gratuito), Enterprise Architect (profesional), VS (integrado). NO Word plano.
Pregunta 23
En especificación Caso de Uso, «Postcondición» es:
Respuesta correcta: B
Postcondición: qué debe ser verdad DESPUÉS caso uso completo (ej: «Consulta guardada BBDD, notificación enviada»). Verifica éxito.
Postcondición: qué debe ser verdad DESPUÉS caso uso completo (ej: «Consulta guardada BBDD, notificación enviada»). Verifica éxito.
Pregunta 24
Requisito No-Funcional «Escalabilidad» en Diraya significa:
Respuesta correcta: B
Escalabilidad: cuando crecimiento usuarios/datos, rendimiento se mantiene. Ejemplo: cloud auto-scaling (agregar servidores automático).
Escalabilidad: cuando crecimiento usuarios/datos, rendimiento se mantiene. Ejemplo: cloud auto-scaling (agregar servidores automático).
Pregunta 25
¿Cuál es ventaja principal UML sobre documentación texto?
Respuesta correcta: B
UML: visualización clara (clases, relaciones, flujos), lenguaje común técnicos + NO técnicos, evita ambigüedades prosa. Complementa documentación texto.
UML: visualización clara (clases, relaciones, flujos), lenguaje común técnicos + NO técnicos, evita ambigüedades prosa. Complementa documentación texto.
✅ CUESTIONARIO COMPLETO (Preguntas 1-25)
- Preguntas 1-5: Conceptos fundamentales (Req Funcionales vs No-Funcionales, Casos Uso, Historias Usuario, Diagramas UML)
- Preguntas 6-10: UML Diagramas principales (Secuencia, ER, BPMN, Requisitos SAS)
- Preguntas 11-15: Fases SDLC, ER relaciones, BPMN elementos
- Preguntas 16-20: BPMN vs Activity, Disponibilidad, Seguridad, Criticidad SAS
- Preguntas 21-25: Contexto proyectos, herramientas, estructura Casos Uso, Escalabilidad, ventajas UML
Evaluación Final:
- 23-25 correctas: ⭐⭐⭐⭐⭐ Excelente – Dominas análisis funcional completo
- 20-22 correctas: ⭐⭐⭐⭐ Muy Bien – Repasa UML + Requisitos No-Funcionales
- 17-19 correctas: ⭐⭐⭐ Bien – Estudia Casos Uso + ER + BPMN
- 14-16 correctas: ⭐⭐ Aprobado – Focus tema completo + ejemplos SAS
- <14 correctas: ⭐ Repasa – Cubrimiento medio, necesita refuerzo conceptos clave
6. Mapa Conceptual Tema 40
📊 Análisis Funcional Sistemas Información
ANÁLISIS FUNCIONAL
│
┌─────────────────┼─────────────────┐
│ │ │
TÉCNICAS DOCUMENTOS REQUISITOS
ANÁLISIS ENTREGABLES │
│ │ ├─ Funcionales (QUÉ)
│ │ │ ├─ Casos Uso
├─ Casos Uso ├─ SRS │ └─ Historias Usuario
├─ Historias ├─ Diagramas │
│ Usuario │ UML └─ No-Funcionales (CÓMO)
├─ UML ├─ ER ├─ Seguridad/Privacidad
│ ├─ Clases ├─ BPMN ├─ Rendimiento
│ ├─ Secuencia └─ Documento ├─ Disponibilidad
│ ├─ Actividad Requisitos ├─ Escalabilidad
│ └─ Componentes No-Funct. ├─ Usabilidad
│ └─ Mantenibilidad
├─ Modelado
│ Dominio APLICACIÓN SAS:
├─ ER - Casos Uso: especificaciones formales
└─ BPMN - UML Clases: estructura HC+Consulta+Medicamento
- ER: BBDD Diraya (Paciente-Consulta-Medicamento)
- BPMN: Procesos (paciente urgencias, médico consulta)
- No-func: 99.5% uptime, RGPD, <2seg búsqueda
7. Referencias Normativas y Bibliográficas
- OMG UML 2.5: Unified Modeling Language 2.5 - omg.org
- OMG BPMN 2.0: Business Process Model and Notation - omg.org
- OMG CMMN 1.1: Case Management Model and Notation
- ISO/IEC 25010:2011: Calidad Software - Requisitos No-Funcionales
- IEEE 830-1998: Especificación Requisitos Software (SRS)
- Cockburn, A.: "Writing Effective Use Cases" (2001)
- Fowler, M.: "UML Distilled" (2003)
- RGPD: Reglamento UE 2016/679 Protección Datos
- ENS: RD 311/2022 Esquema Nacional Seguridad
- MCMI SAS: Marco Común Metodológico Implantación SAS
🏥 Sección 8: Mapeo Proyecto Real SAS
Ejemplo: Implantación Módulo Diraya Telemedicina - Cómo 4 temas trabajan juntos
📅 Timeline Completo AÑO 1: Proyecto Telemedicina Diraya
MESES 1: PLANIFICACIÓN (Tema 37)
Director TIC define: "Queremos módulo Telemedicina Diraya"
• Gestor Proyectos usa PMBOK/MCMI (Tema 37)
• Define alcance, plazo (12 meses), presupuesto (500K€)
• Identifica stakeholders (médicos, enfermeras, IT, farmacia)
• Planifica riesgos (tecnología nueva = incertidumbre)
• Usa JIRA crear Epic (Tema 38)
MESES 2-3: ANÁLISIS (Tema 40 + 39)
Analista Funcional realiza Análisis Requisitos (Tema 40)
• Entrevista médicos: "¿Qué necesitáis telemedicina?"
• Crea Casos Uso (registrar telemedicina, grabar, compartir pantalla)
• Dibuja UML Clases (ConsultaTelemedicida, Grabación, Paciente)
• Mapea BPMN procesos (paciente cita online → video → prescripción)
• Define Requisitos No-Funcionales (video <2seg latencia, 99.5% uptime)
• Usa Confluence documentar especificaciones (Tema 38)
• Fase Análisis SDLC se completa (Tema 39)
MESES 4-6: DISEÑO (Tema 39 + 38)
Arquitecto expande análisis → diseño
• Dibuja Diagrama Componentes (frontend React, API REST Spring, BBDD Oracle)
• Define integración video (WebRTC, Jitsi)
• Diseña ER BBDD (tablas ConsultaTelemedicida, Grabación, links PACS)
• Usa Confluence guardar diseño (Tema 38)
• Proyecta en JIRA (Tema 38)
• Fase Diseño SDLC completa
MESES 7-9: IMPLEMENTACIÓN (Tema 39 + 38)
Dev Team codifica (Tema 39 implementación)
• Usa JIRA Scrum (Tema 38): Sprints 2 semanas
• Cada sprint: análisis → diseño → código → test incrementales
• Integración continua/deploy (DevOps Tema 39)
• Usa Confluence documenta código (Tema 38)
• Daily Standup 15min coordinación (Tema 38)
MESES 10-11: TESTING (Tema 39)
Testing niveles (Tema 40 requisitos verifican tests)
• Testing unitario (developers)
• Testing integración (video+BBDD+PACS)
• Testing sistema (end-to-end)
• UAT médicos (usuarios finales validan requisitos)
• CSU (Tema 38) prepara soporte post-lanzamiento
• Documenta bugs en JIRA (Tema 38)
MES 12: DESPLIEGUE (Tema 39)
Go-live Telemedicina (Tema 39 despliegue)
• CSU (Tema 38) atiende incidencias N1 (Service Desk)
• Técnicos N2 escalado problemas (Tema 38)
• Monitorización Nagios (Tema 38): ¿99.5% uptime se cumple?
AÑOS 2+: MANTENIMIENTO (Tema 39 + 38)
Correctivo: bugs usuarios reportan ayudaDIGITAL (Tema 38)
• Perfectivo: nuevas funciones (v1.1 chat de voz, v2.0 IA emoción)
• Adaptativo: cambios normativos (RGPD nuevas, SINAUTO receta)
• Preventivo: actualizaciones seguridad, BBDD optimización
Tips Examen OEP 2025 SAS TFA-STI
⭐ Preguntas PROBABLES (basadas estructura examen)
Tema 37 (Gestión):
- "¿Cuáles son 10 áreas conocimiento PMBOK?" → Respuesta: Integración, Alcance, Cronograma, Costes, Calidad, Recursos, Comunicación, Riesgos, Adquisiciones, Stakeholders
- "¿Diferencia MCMI SAS vs PMBOK genérico?" → Respuesta: MCMI especializado SAS (8 fases específicas implantaciones)
- "¿Waterfall vs Ágil en sector público?" → Respuesta: Waterfall (contratos LCSP fijos), Ágil (proyectos evolución internos)
Tema 38 (Herramientas):
- "¿Diferencia JIRA Software vs JIRA Service Management?" → Respuesta: Software = gestión proyectos, Service Management = Service Desk ITSM
- "¿Qué es ayudaDIGITAL SAS?" → Respuesta: Service Desk corporativo N1 (portal soporte usuarios, ticketing)
- "¿Herramienta wiki corporativa SAS?" → Respuesta: Confluence (documentación técnica Diraya)
- "¿Monitorización sistemas SAS?" → Respuesta: Nagios (alertas servidores, métricas disponibilidad)
Tema 39 (Ciclo Vida):
- "¿8 fases SDLC en orden?" → Respuesta: Planificación → Análisis → Diseño → Implementación → Testing → Despliegue → Mantenimiento → Retiro
- "¿Cuándo usar Waterfall vs Ágil?" → Respuesta: Waterfall (requisitos claros, fijos), Ágil (requisitos inciertos, flexibles)
- "¿Prototipo desechable vs evolutivo?" → Respuesta: Desechable (validar, tirar), Evolutivo (MVP producción, iterar)
- "¿DevOps qué es?" → Respuesta: Integración Dev-Ops, CI/CD automático, deploy múltiple veces día
Tema 40 (Análisis):
- "¿Diferencia Casos Uso vs Historias Usuario?" → Respuesta: Casos Uso (formal estructurado Waterfall), Historias Usuario (narrativa ágil Scrum)
- "¿Qué es UML?" → Respuesta: Lenguaje modelado estándar OMG (diagramas visualizar sistemas)
- "¿5 diagramas UML principales?" → Respuesta: Clases, Secuencia, Actividad, Casos Uso, Componentes
- "¿Modelo ER para qué?" → Respuesta: Diseñar BBDD (tablas, atributos, relaciones, claves)
- "¿BPMN para qué?" → Respuesta: Mapear procesos negocio (eventos, actividades, compuertas, carriles)
- "¿Requisitos No-Funcionales críticos SAS?" → Respuesta: Seguridad, Privacidad (RGPD), Disponibilidad (99.5%), Rendimiento (<2seg)
✅ Estrategia Examen: Conectar 4 Temas
Si pregunta aislada sobre Tema X, amplía respuesta conectando:
- Pregunta: "¿Qué es Caso de Uso?" (Tema 40)
Respuesta COMPLETA: "Caso Uso = documentación requisitos fase Análisis (Tema 40) de SDLC (Tema 39). Se crean antes Diseño. Se gestiona proyecto mediante PMBOK/MCMI (Tema 37). Se documenta Confluence (Tema 38). Luego se vincula JIRA (Tema 38) tests verifican cumplimiento." - Pregunta: "¿Cuándo usar Ágil?" (Tema 39)
Respuesta COMPLETA: "Ágil (Tema 39) para requisitos inciertos. Se gestiona Scrum (Tema 37 metodología). Se ejecuta JIRA (Tema 38). Historias Usuario (Tema 40) como requisitos. Sprints iterativos = Análisis-Diseño-Desarrollo-Testing incremental cada 2 semanas. Diraya evoluciona así (versiones anuales)."
Demuestras COMPRENSIÓN HOLÍSTICA (NO solo memorización desconectada) → jueces valoran.