Seguimiento del progreso SCORM

Cómo se reporta el progreso

SecureCodingHub implementa los modelos de reporte de SCORM 1.2 y SCORM 2004 (3.ª y 4.ª edición), por lo que el mismo paquete de contenido se ejecuta en cualquier LMS que cumpla con el estándar. Durante una sesión activa, el player intercambia datos en tiempo de ejecución con el LMS a través del adaptador SCORM API que el LMS inyecta en el lanzamiento, y ese intercambio es el que produce los cuatro datos que tus administradores ven en su cuaderno de calificaciones o en su informe de finalización. Los campos que aparecen abajo son el conjunto canónico que escribimos en cada commit; cada proveedor de LMS los presenta bajo etiquetas de columna distintas, pero los valores subyacentes son idénticos.

Cuando un estudiante completa la formación, el bridge SCORM envía los siguientes datos al LMS:

• Estado de finalización (incomplete → completed)
• Puntuación (0-100)
• Tiempo de sesión
• Marcador para reanudación

Cada uno de estos datos se corresponde con un elemento específico del modelo de datos SCORM. El estado de finalización se escribe en cmi.completion_status en SCORM 2004 y en cmi.core.lesson_status en SCORM 1.2. La puntuación se escribe en cmi.score.raw en ambas versiones, con el equivalente escalado en cmi.score.scaled solo en 2004 (1.2 no tiene campo escalado). El tiempo de sesión se acumula en cmi.session_time con formato de duración ISO 8601, y el marcador de reanudación se serializa en cmi.suspend_data. El bridge vuelve a registrar estos elementos en cada heartbeat durante una sesión activa, de modo que una sesión interrumpida produce un estado parcialmente reportado que el LMS puede mostrar.

Criterios de finalización

Una sesión SCORM se marca como completa cuando el estudiante ha finalizado todas las asignaciones obligatorias de su organización o — si no hay asignaciones obligatorias pendientes — una vez que tiene cualquier progreso registrado. El umbral no se puede configurar hoy por asignación ni por paquete; la misma lógica viaja en cada paquete SCORM que genera la plataforma.

SCORM 2004 distingue entre finalización (¿terminó el estudiante la actividad?) y éxito (¿la aprobó?). El bridge reporta ambos: cmi.completion_status refleja si la actividad está terminada y cmi.success_status refleja si se superó el umbral medio de aprobación. SCORM 1.2 no tiene esa separación entre finalización y éxito — el bridge escribe passed o failed en cmi.core.lesson_status una vez que la finalización es verdadera, y incomplete en caso contrario.

Cálculo de la puntuación

La puntuación que recibe el LMS se calcula en el servidor a partir del progreso de práctica del estudiante. La escala interna de puntuación va de 0 a 160 por desafío (Fase 1 + Fase 2, valiendo cada fase hasta 100 en una finalización a la primera y sin pistas). Para producir un número compatible con SCORM (0-100), el bridge calcula la media de las puntuaciones de práctica en los desafíos completados por el estudiante, la divide entre 1,6 y limita el resultado a un máximo de 100. La transformación es fija; en esta versión no hay ponderación por paquete ni por asignación.

Reanudar / Suspender

Si un estudiante cierra la sesión antes de completarla:

• La posición actual se guarda como marcador
• El siguiente lanzamiento se reanuda desde el marcador
• El heartbeat de la sesión la mantiene activa mientras se está usando

El marcador completo — en qué tema estaba el estudiante, en qué desafío, en qué fase y qué pistas había revelado — vive en el servidor, en el registro de sesión de SecureCodingHub, no dentro del paquete SCORM. Lo que el bridge escribe en cmi.suspend_data es una pequeña envoltura JSON que contiene únicamente el id de sesión de SecureCodingHub (por ejemplo {"sid":"..."}); al reanudar, el bridge lee de nuevo ese id, llama al endpoint de sesión de SecureCodingHub y usa el estado del servidor para rehidratar el player. El LMS, por tanto, nunca almacena contenido de desafíos, historial de respuestas ni estado de pistas.

SCORM impone un límite de 64 KB en cmi.suspend_data en la especificación 1.2, y un límite equivalente de facto en muchas implementaciones de 2004. Como el bridge solo escribe un id de sesión en el LMS, el payload de suspensión se mantiene muy por debajo de un kilobyte, sin importar cuánto dure la asignación ni cuántas veces el estudiante suspenda y reanude.

Heartbeat

Mientras el estudiante tiene abierto el player SCORM, el launcher dispara un heartbeat al backend de SecureCodingHub en POST /api/sch/scorm/heartbeat cada 60 segundos, llevando el id de sesión, el marcador actual y el tiempo de sesión acumulado. Ese mismo tick vuelve a registrar el modelo de datos SCORM en el lado del LMS, de modo que finalización, puntuación, tiempo de sesión y datos de suspensión se mantienen sincronizados sin esperar a eventos de guardado explícitos.

Cómo consultar el progreso

Los administradores pueden consultar las sesiones SCORM desde:

La vista de administración de SecureCodingHub es la fuente de verdad para las analíticas detalladas: intentos por desafío, uso de pistas, tiempo invertido y las remediaciones concretas que eligió el estudiante. El cuaderno de calificaciones del LMS ve el resumen SCORM — finalización, puntuación, tiempo de sesión — y es la superficie adecuada para el reporte de cumplimiento y la emisión de certificados, pero no tiene visibilidad sobre los datos paso a paso subyacentes. La mayoría de administradores usan las dos vistas en paralelo: el LMS para el reporte de «¿el estudiante terminó y aprobó?» y el panel de SecureCodingHub para las decisiones de «¿dónde está teniendo dificultades el grupo y qué deberíamos ajustar?». Para el flujo de analítica más profundo y para configurar los permisos de rol de administración en el panel, consulta nuestra documentación del panel de administración y la guía complementaria de roles y permisos.

La emisión xAPI está en el roadmap y aún no está disponible. Cuando esté disponible, SecureCodingHub podrá enviar los mismos eventos por desafío (revelación de pistas, intentos fallidos, transiciones entre desafíos) a un Learning Record Store junto con los commits SCORM. Hasta entonces, el conjunto de commits SCORM es la única superficie LMS lista para usar y el panel de administración de SecureCodingHub es el único lugar donde ver la granularidad por evento.