CALIDAD E INTEGRACIÓNDatos revisados

FUENTES Y REVISIÓN

Calidad de los datos

Consulta cómo se revisaron y unieron los datos de Admisiones, SIS, Pagos, Moodle y Bienestar.

Descargar datos de la cohorte

1.200estudiantes únicosUna fila por estudiante · Periodo 2025-1

Fuentes integradas5Admisiones, SIS, Pagos, Moodle y Bienestar

Reglas documentadas22Limpieza, integración y cálculo

Controles finales11 / 11Comprobaciones de la cohorte integrada

RESULTADOS GENERALES

La cohorte en cifras

Resultados de la cohorte completa: matrícula, continuidad, notas y alertas.

Descargar indicadores · CSV

Indicador	Valor	Unidad
Cargando indicadores…

El promedio se calcula con 1.175 notas; 25 estudiantes no tienen una nota registrada. Hay cuatro estudiantes cuya alerta no se pudo determinar. Para consultar un grupo, abre el Tablero de indicadores.

PROCESO

Cómo se prepararon los datos

Python + pandas

Extraer

Leer los cinco archivos y conservar una copia de los datos recibidos.

Transformar

Unificar nombres y formatos, retirar duplicados y relacionar los registros de cada estudiante.

Cargar

Guardar la cohorte revisada y el registro de los cambios realizados.

La revisión de los archivos originales se repitió y confirmó los mismos 1.200 estudiantes. Después de esta preparación, los datos se cargan al almacén que alimenta el Tablero de indicadores.

TRAZABILIDAD

Cambios realizados en los datos

Consulta los problemas encontrados y cómo se resolvieron.

Registro completo

Etapa

Regla / fuente	Problema	Tratamiento aplicado	Etapa
Cargando las reglas…

22 reglas33 entradas en el registro, agrupadas por regla.

Cada cambio conserva su registro. Por ejemplo, se detectaron 13 promedios fuera de la escala de 0 a 5 y se corrigieron en la siguiente etapa.

CALIDAD

Controles de calidad

Revisión del número de estudiantes, los cruces entre fuentes y los valores registrados.

Descargar controles

CASOS CONSERVADOS

Datos pendientes de completar

Estos casos siguen en la cohorte y se tienen en cuenta al calcular los indicadores.

25estudiantes sin promedio

El promedio se calcula con las 1.175 notas registradas. Las notas faltantes no se reemplazan por cero.

4alertas no determinadas

Cuatro estudiantes comparten dos correos. No se pudo asignar su actividad de Moodle con seguridad.

ARCHIVOS PÚBLICOS

Descargas

Descarga los datos de la cohorte, el registro de cambios y los indicadores generales. Los archivos de consulta no incluyen nombres, documentos ni correos.

CSV

Datos de la cohorte

Datos académicos y resultados de los 1.200 estudiantes, sin información personal.

Descargar CSV

Registro de cambios

Detalle de las 22 reglas usadas para revisar y preparar los datos.

Descargar

CSV

Indicadores generales

Resultados de toda la cohorte. Para consultar un grupo, abre el Tablero de indicadores.

Descargar CSV

MODELO DE DATOSModelo dimensional validado

MODELO SEMÁNTICO · POWER BI

Modelo de datos

Los registros de estudiantes y admitidos se organizan para consultar los resultados por programa, facultad, estrato y periodo.

NIVEL DE DETALLE

Qué representa cada fila

Cada fila representa a un estudiante en un periodo de cohorte. La cohorte 2025-1 tiene 1.200 estudiantes y registra si cada uno continuó sus estudios en 2025-2.

La tabla de admisiones tiene 1.450 filas, una por persona admitida en el proceso de ingreso a 2025-1. Algunas admisiones se registraron antes de ese año. La continuidad en 2025-2 se guarda en el registro de la cohorte, sin añadir otra fila del estudiante.

ESTRUCTURA

Hechos, dimensiones y relaciones

Las flechas del modelo van de cada dimensión (1) hacia sus hechos (*).

hecho_permanencia

Registra las notas, créditos, actividad, pagos, continuidad y alertas de los 1.200 estudiantes de la cohorte.

hecho_admisiones

Registra a los 1.450 admitidos y permite calcular qué proporción se matriculó, también al elegir un grupo en los filtros.

Dimensión	Información / filtro	Relación con hechos
dim_estudiante	Código e identidad de la cohorte	codigo → permanencia
dim_programa	Programa y facultad	programa → permanencia y admisiones
dim_estrato	Estratos 1 a 6	estrato → permanencia y admisiones
dim_periodo	Periodo de cohorte 2025-1	periodo → permanencia y admisiones

Los programas se agrupan en tres facultades: Ingeniería (Industrial e Informática), Ciencias Económicas y Administrativas (Administración y Contaduría) y Ciencias Sociales y Humanas (Psicología y Trabajo Social). Esta agrupación se definió para el Observatorio; los archivos de origen solo indicaban el programa.

Vista del modelo de Power BI con cuatro dimensiones, dos tablas de hechos y siete relaciones activas de uno a varios. — Vista de modelo de Power BI. Selecciona la imagen para verla en tamaño completo.

MEDIDAS

Qué suma y qué se recalcula

Medida	Cálculo en el contexto filtrado	Comportamiento
Estudiantes cohorte / retenidos / desertores	Conteos de filas y condiciones de continuidad	Aditivos entre programas y estratos de esta cohorte
Admitidos únicos	Conteo de hecho_admisiones	Aditivo entre programas y estratos de este proceso
Estudiantes alertados / alertados que desertaron	Conteos con las condiciones de alerta y deserción	Aditivos entre programas y estratos de esta cohorte
Retención / deserción / absorción	Retenidos ÷ cohorte; desertores ÷ cohorte; cohorte ÷ admitidos	No aditivos: se recalcula numerador ÷ denominador
Precisión / cobertura de alerta	Alertados que desertaron ÷ alertados; ÷ desertores	No aditivos: se recalcula el cociente
Promedio de la cohorte	Media de las 1.175 notas disponibles	No aditivo: se calcula sobre las notas disponibles

Los conteos se pueden sumar cuando cada estudiante aparece una sola vez. Al consultar varios periodos, una persona puede aparecer en más de uno. Los cuatro casos sin alerta definida no se cuentan entre los estudiantes alertados.

Ejemplos de consulta

Con Psicología y estrato 1: 41 estudiantes, 6 desertores, 47 admitidos; deserción 14,63 % y absorción 87,23 %. Con Ingeniería y estrato 1: 79 estudiantes, 15 desertores y 93 admitidos; deserción 18,99 % y absorción 84,95 %.

Puedes consultar estos resultados y elegir otros grupos en el Tablero de indicadores.

ARQUITECTURAArquitectura objetivo diseñada

PROCESAMIENTO Y ACCESO

Cómo funciona el Observatorio

Los archivos revisados se cargan a un almacén de datos con DuckDB. Lambda calcula los resultados y los guarda en S3 para que puedan consultarse en el Tablero de indicadores. El diagrama también muestra servicios previstos para recibir actividad de Moodle y enviar avisos al personal autorizado.

DIAGRAMA

Recorrido de los datos

Las flechas siguen el recorrido de cada dato desde su origen hasta el tablero o el orientador.

Descargar SVG ↓Editar en draw.io ↓

Fuentes SIS, Admisiones, Pagos, Bienestar y Moodle histórico ingresan por lotes a S3 raw. SPADIES es una referencia externa opcional con revisión mensual. El ETL cruza y protege Bienestar antes de clean y curated. Las vistas SQL en DuckDB y S3 con CloudFront llevan agregados al tablero; Power BI es el modelo de referencia. Los eventos de Moodle pasan por API Gateway, SQS, Lambda y SNS hasta orientadores autorizados. — El diagrama incluye el procesamiento actual y los servicios previstos. La recepción continua de eventos de Moodle y los avisos privados todavía no están habilitados.

FRECUENCIA

Cuándo se actualizarían los datos

Hoy la actualización se inicia al ejecutar el proceso de carga. Estas frecuencias describen la automatización prevista.

Flujo	Frecuencia prevista	Destino / uso
SIS, Admisiones, Pagos y Bienestar → S3 raw/	Un lote diario durante el periodo académico; el manifiesto dispara la ejecución al completarse.	ETL y controles de calidad.
SPADIES → S3 raw/	Revisar una vez al mes si hay nuevos datos públicos; su publicación no es necesariamente mensual.	Comparación contextual; no alimenta las cifras actuales de la cohorte.
Moodle → API Gateway y SQS	Por evento de actividad; evaluación objetivo en menos de 5 minutos.	Alerta temprana operativa.
Eventos Moodle → S3 raw/	Micro lotes de histórico cada 5 minutos.	Reconstrucción y análisis posterior.
ETL → clean/ → curated/ → capa semántica → tablero	Después del lote diario validado; tablero agregado actualizado a diario.	Indicadores por programa, facultad, estrato y periodo.
Alerta → SNS → orientador	Al cambiar el estado de un caso; objetivo menor de 5 minutos desde el evento.	Atención individual en un canal privado.

PROTECCIÓN DE DATOS

Acceso a los datos de Bienestar

Protección prevista antes de guardar los datos preparados.

El diseño prevé relacionar los registros de Bienestar por nombre y programa en un entorno restringido. Para el análisis se usará una clave técnica y la relación con cada persona se guardará aparte, con acceso limitado. Este tratamiento se llama seudonimización. La consulta pública mostrará resultados por grupos, sin detalles personales de atención.

Los avisos previstos solo incluirán el número del caso. El detalle estará reservado al personal autorizado. Este acceso privado todavía no está habilitado.

DECISIONES TÉCNICAS

Servicios y funciones

Para qué se usa cada servicio y qué aporta al procesamiento.

Tecnología	Función	Justificación
Amazon S3	Lake raw/, clean/ y curated/; web privada.	Conserva archivos originales e históricos por lote y sirve los datos publicados con permisos separados.
S3 Event Notifications + AWS Lambda	Ingesta por lotes y ETL Python.	El manifiesto activa una ejecución cuando el lote está completo; evita mantener un servidor encendido.
API Gateway + Amazon SQS	Recepción de eventos Moodle.	La API valida el evento y la cola amortigua picos y permite reintentos.
AWS Lambda + DynamoDB	Evaluación y estado de alertas.	Procesa cada evento y guarda el estado para evitar notificaciones duplicadas.
DuckDB	Data Warehouse dimensional en curated/.	Construye tablas de hechos, dimensiones y agregados en un archivo consultable, sin servidor de base de datos permanente.
SQL en DuckDB + Power BI	Capa semántica y modelo de referencia.	Las vistas y cocientes definen las cifras web; se contrastan con las medidas y relaciones del modelo Power BI.
S3 web + CloudFront	Publicación HTTPS del tablero.	Entrega el tablero agregado y la cohorte sin identificadores por HTTPS, con caché y sin credenciales de AWS.
Amazon SNS + IAM	Canal de alertas y permisos por rol.	SNS notifica cambios sin información sensible; IAM limita quién puede consultar los datos privados.

SPADIES se considera una referencia futura y sus datos no se usan en los indicadores actuales. La recepción automática de actividad de Moodle también está pendiente. Más información sobre los servicios previstos: eventos de S3, SQS con Lambda y estadísticas SPADIES.

TABLERO DE INDICADORESIndicadores y filtros

RESULTADOS DE LA COHORTE

Indicadores de permanencia

Consulta la continuidad académica, las notas y las alertas. Elige una facultad, un programa o un estrato para ver sus resultados.

Cohorte 2025-1 · Continuidad observada en 2025-2

Datos de demostración. Esta consulta es pública y usa datos simulados. En un entorno institucional, el acceso requeriría una cuenta y permisos según la función de cada usuario.

Facultad Programa Estrato

Cargando indicadores…

CONTINUIDAD POR PROGRAMA

Continuidad por programa

Porcentaje de estudiantes que continuaron sus estudios y de quienes no registraron matrícula en el periodo siguiente.

RetenciónDeserción

DETALLE

Resultados por programa

Consulta los resultados de cada programa y el total del grupo seleccionado.

Programa	Cohorte	Admitidos	Absorción	Retención	Deserción	Promedio	Alertados	Precisión	Cobertura

Metas, fórmulas y lectura del semáforoConsulta las metas de seguimiento y cómo se calcula cada indicador.

Indicador	Cálculo	Verde	Amarillo	Rojo

El semáforo compara los resultados con las metas de seguimiento. La capacidad de atención es de 120 estudiantes para toda la cohorte; un filtro muestra solo una parte de esa demanda. Estos indicadores conservan la regla actual. La selección priorizada y su evaluación están en Alerta temprana.

El promedio general usa las 1.175 notas disponibles. Hay 25 estudiantes sin nota y cuatro cuya alerta no pudo determinarse. Cada filtro vuelve a calcular los resultados del grupo elegido. “Sin datos” indica que no hay información suficiente para calcular un indicador.

ALERTA TEMPRANASelección para seguimiento

ACTIVIDAD EN MOODLE

Alerta temprana

La selección priorizada identifica estudiantes con poca actividad reciente y permite organizar el seguimiento dentro de la capacidad de atención.

Cohorte 2025-1 · Información disponible hasta la semana 8

Datos de demostración. Esta comparación usa la cohorte completa, sin filtros. En un entorno institucional, el seguimiento de cada caso estaría reservado al personal autorizado.

Cargando la evaluación de alertas…

REGLA DE SELECCIÓN

Poca actividad en las últimas dos semanas

La regla usa los accesos registrados en las semanas 7 y 8. Las matrículas posteriores solo se consultan para evaluar sus resultados.

COMPARACIÓN

Qué cambia frente a la regla actual

Ambas reglas se evalúan sobre los mismos estudiantes y el mismo resultado de continuidad.

Regla	Alertados	Detectados	Precisión	Cobertura	Capacidad de atención

La regla actual asigna alerta cuando el promedio de notas de las semanas 4 y 8 es menor que 3, o cuando los accesos de las semanas 7 y 8 suman cero. Sus indicadores generales siguen disponibles en el Tablero de indicadores.

EVALUACIÓN DE LA SELECCIÓN

Matriz de confusión

Relaciona la alerta asignada con la continuidad observada en el periodo siguiente.

Selección priorizada

Regla actual

Detectados — verdaderos positivos: Recibieron alerta y después desertaron.
Falsos positivos: Recibieron alerta y continuaron sus estudios.
Falsos negativos: Desertaron y no recibieron una alerta.
Verdaderos negativos: No recibieron alerta y continuaron sus estudios.

DISTRIBUCIÓN

Selección priorizada por programa

La capacidad máxima y la cobertura mínima se evalúan sobre la cohorte completa.

Programa	Alertados	Detectados	Continuaron con alerta	Desertaron sin alerta	Precisión	Cobertura

Cómo se eligió el límite de accesosComparación de límites de actividad y condiciones de atención.

Accesos máximos	Alertados	Detectados	Cobertura	Capacidad	Cobertura mínima

El límite se eligió comparando resultados en esta misma cohorte. Antes de aplicarlo a nuevos periodos, se debe volver a comprobar cuántos casos selecciona y cuántos logra detectar.

Esta evaluación muestra a quién habría señalado la regla con la información disponible hasta la semana 8. No demuestra que la atención posterior hubiera evitado la deserción.

SIGUIENTE FASE

Prospectiva tecnológica

Tres propuestas para recibir información más reciente, mejorar la selección de alertas y acompañar a los estudiantes a tiempo.

Estas tecnologías son propuestas. Aún no están implementadas y no cambian las cifras del tablero actual.

PUNTO DE PARTIDA

Qué necesitamos mejorar

La selección actual prioriza 112 estudiantes y detecta 68 de los 175 casos de deserción: su cobertura es del 38,86 %. Quedan 107 casos sin alerta. Además, cuatro estudiantes no tienen actividad de Moodle asignada de forma suficiente y todavía no existe un flujo de seguimiento de las intervenciones.

Estas cifras corresponden a la evaluación publicada de la cohorte 2025-1. Si se carga otra cohorte, se deberá revisar este diagnóstico. Consulta los resultados en Alerta temprana.

01 · INFORMACIÓN OPORTUNA

Amazon SQS para recibir eventos de Moodle

Una cola guarda los eventos de actividad mientras el proceso de integración los recibe y transforma. Moodle enviaría los eventos mediante una API y Lambda los procesaría sin depender de una exportación manual.

Problema del caso: Los archivos históricos muestran la actividad después de su exportación. Esto retrasa la detección de una caída de participación.
Indicador que se busca mejorar: Cobertura de la alerta. Con información reciente se podrían identificar más casos antes del cierre de la selección. Recibir antes los eventos no garantiza aumentar la cobertura.
Riesgo: Un evento repetido podría inflar los accesos. Un correo compartido podría asignar actividad a la persona equivocada.
Mitigación: Usar un identificador único por evento para evitar duplicados, registrar su fecha y enlazar el usuario de Moodle con el código del SIS mediante una correspondencia validada. Los casos ambiguos irían a revisión; los fallos, a una cola de errores.
Cómo comprobar la mejora: Comparar la cobertura al mismo corte de la semana 8, con un máximo de 120 alertados. Medir también el retraso de llegada y los eventos sin identidad resuelta.

Amplía la recepción continua prevista en la Arquitectura. Base técnica: Amazon Web Services (s. f.-a).

02 · SELECCIÓN DE CASOS

Amazon SageMaker AI con XGBoost

Un modelo de aprendizaje automático buscaría patrones combinando actividad y notas. Produciría una puntuación de riesgo para apoyar la selección, con revisión humana.

Problema del caso: La regla de tres accesos o menos deja 107 desertores sin alerta. La baja actividad por sí sola no identifica todas las situaciones de riesgo.
Indicador que se busca mejorar: Cobertura y precisión de la alerta. Se intentaría detectar más desertores sin superar 120 alertados ni empeorar la precisión del 60,71 % de referencia.
Riesgo: El modelo podría memorizar esta pequeña cohorte, favorecer a ciertos grupos o usar por error información posterior a la semana 8.
Mitigación: Reunir varias cohortes, entrenar con periodos anteriores y evaluar con uno posterior reservado. Usar solo datos disponibles hasta el corte, revisar resultados por programa y estrato y mantener revisión humana. Excluir detalle sensible de Bienestar.
Cómo comprobar la mejora: Comparar su matriz de confusión con la regla simple sobre la misma cohorte de prueba. Adoptarlo solo si mejora el resultado acordado dentro de la capacidad; si no, conservar la regla actual.

Es una prueba futura, no una mejora demostrada ni una decisión automática sobre el estudiante. Base técnica: Amazon Web Services (s. f.-c).

03 · ACOMPAÑAMIENTO

AWS Step Functions para organizar el seguimiento

Un flujo coordinaría la asignación de cada caso, el aviso al orientador, el plazo de contacto y el registro del resultado. El orientador decidiría la atención necesaria.

Problema del caso: La página identifica casos, pero todavía no registra si un orientador los contactó, qué apoyo recibieron o si hubo seguimiento.
Indicador que se busca mejorar: Retención de primer periodo y, como resultado complementario, deserción. El objetivo es que la alerta produzca una atención oportuna, no solo un conteo.
Riesgo: Podrían enviarse avisos duplicados, quedar casos sin responsable o divulgarse información personal en mensajes.
Mitigación: Una clave única por estudiante y periodo, responsable y plazo explícitos, reintentos controlados y registro privado de estados. Los avisos llevarían un enlace al caso, sin notas ni información de Bienestar; el acceso requeriría credenciales y permisos por rol.
Cómo comprobar la mejora: Medir contacto y atención como indicadores operativos adicionales; evaluar retención al siguiente periodo con un grupo comparable o un piloto escalonado. Un cambio en retención, por sí solo, no prueba que el flujo lo causó.

Complementa el canal privado previsto en la Arquitectura. Base técnica: Amazon Web Services (s. f.-b).

Orden propuesto

Primero, asegurar la identidad y la llegada de actividad. Resolver los cruces ambiguos y probar la recepción continua en un grupo pequeño.
Después, habilitar el seguimiento privado. Definir responsables, capacidad de atención y permisos antes de enviar avisos.
Por último, probar el modelo de riesgo. Reunir nuevas cohortes y demostrar una mejora frente a la regla simple.

La integración y el modelo dimensional siguen los conceptos del material de modelos y arquitecturas; el uso de información para apoyar decisiones se fundamenta en el material de introducción a la inteligencia de negocios. SPADIES permanece como referencia conceptual externa, sin integración prevista para esta demostración.