Educación
SIDER: una escuela digital sin internet para aulas rurales
Una plataforma gamificada de STEM e inglés hecha como PWA. Funciona sin internet, se actualiza por USB y resiste cortes de luz y datos dañados.
Concepto ✓ feb 2026Prototipo ✓ mar 2026Piloto ✓ 2026
Siguiente: Extenderlo a más colegios de Urubamba
- PWA
- Offline-first
- Data-mule sync
- Gamification
El problema
Los colegios rurales de Cusco tienen computadores de gama baja, cortes de luz y ninguna conexión fiable.
Las actualizaciones y el contenido tenían que llegar a colegios sin conexión, y el sistema tenía que aguantar las condiciones en las que iba a funcionar.
Qué construí
Lideré el diseño y la construcción: concepto, PRD y TDD, la PWA, el despliegue por USB y los planes de piloto y logística.
- Una aplicación web progresiva para computadores de gama baja que funciona sin conexión a internet.
- Un sistema de actualización por "data mule": el contenido nuevo viaja en memoria USB o por transferencia local.
- Manejo de cortes de luz, datos dañados y fallos de conectividad en campo.
- Un currículo gamificado de STEM e inglés con misiones y puntos de experiencia.
- Un panel docente para registrar estudiantes, seguir su progreso y exportar los datos por USB.
De la idea al piloto
Concepto ✓ feb 2026
El concepto offline-first, las fases CONCEIVE y PLAN, y cuatro documentos de concepto técnico (V1 a V4).
Prototipo ✓ mar 2026
PRD v1.0, TDD v1.0 y un plan de pruebas del MVP; después, el MVP: una app para estudiantes y un panel docente.
Piloto ✓ 2026
Un plan de ejecución del piloto (V5) y una arquitectura de automatización logística (V6); después, el piloto: 6 colegios de la región de Cusco, más de 300 estudiantes.
Resultado. El piloto llegó a más de 300 estudiantes en 6 colegios. El siguiente paso es extenderse a más colegios de Urubamba.
Siguiente: Extenderlo a más colegios de Urubamba
Por dentro
Plan de negocio y de escala en siete partes
El plan tal como se escribió en marzo de 2026, antes del piloto. El estado dice cuánto vale cada parte: una cifra con fuente, un plan, una meta por validar o un riesgo que seguía abierto.
| Parte | Qué dice el plan | Estado |
|---|---|---|
| 1. Problema | La Urubamba rural rompe cualquier diseño de software convencional: solo el 23,6 % de los hogares rurales tiene internet (INEI, 2023), los cortes de luz son frecuentes y las donaciones de hardware anteriores fracasaron por falta de mantenimiento y datos perdidos. De ahí la regla: ninguna parte del sistema puede depender de internet para funcionar. | Dato citado |
| 2. Cliente y mercado | El patrocinador es FutureSense Foundation junto con Challenges Abroad. El piloto empieza en un colegio; la meta es llegar a 40 a 50 colegios multigrado de Urubamba, unos 3.500 estudiantes, en 24 meses. | Plan |
| 3. Producto | Tres capas: un núcleo digital de misiones gamificadas que funciona 24/7 sin internet, un panel docente sin línea de comandos y talleres físicos de STEM dirigidos por voluntarios y anclados en las misiones digitales. | Construido, pilotado |
| 4. Economía unitaria | El servidor del colegio se validó en S/ 405, un 25,6 % por debajo de la referencia, y el ahorro se invirtió en un SSD (unos S/ 95) porque las tarjetas de memoria fallan con los apagones. Las tablets cuestan unos S/ 460 cada una. La meta es un costo de adquisición de S/ 3.000 o menos por colegio equipado, por comprobar con facturas. | Meta, por validar |
| 5. Plan de entrega | Un equipo de cuatro personas durante seis meses son 24 personas-mes. 21 están planificadas y 3 (12,5 %) quedan como colchón para el sistema de actualización y el soporte en campo. Siete iniciativas se ordenan con RICE y MoSCoW en tres horizontes. | Plan |
| 6. Criterios de éxito | Ocho criterios, sostenidos durante cuatro semanas seguidas, habilitan la expansión: disponibilidad mayor al 99 % en horario lectivo, ningún incidente de corrupción, una exportación por USB exitosa, más del 80 % de los estudiantes completando una misión, más de 4 horas semanales por perfil activo, 30 sesiones por debajo de 200 ms, costo de adquisición dentro de la meta y ninguna visita técnica presencial. Los resultados frente a ellos no se publican. | Definidos, resultados no publicados |
| 7. Riesgos | Nueve riesgos técnicos y de campo, cada uno con responsable. Dos estaban abiertos al escribir el PRD: la alineación con el plan nacional de educación, que exigía un convenio con la autoridad local de educación antes del mes 2, y el suministro de Raspberry Pi en Perú, con minicomputadores donados como alternativa. | Abiertos en su momento |
Del PRD de SIDER v1.0 (20 de marzo de 2026). Cifras en soles peruanos. El piloto terminó y SIDER no está funcionando hoy en los colegios; extenderlo por Urubamba es el siguiente paso, aún sin empezar.
Requisitos: un extracto del PRD
Escribí los documentos de requisitos y de diseño del piloto (PRD y TDD, versión 1.0, 20 de marzo de 2026). Estos son los requisitos que más moldearon el sistema. Cada uno termina en algo que se puede comprobar.
| ID | Requisito | Prioridad | Criterio de aceptación |
|---|---|---|---|
| FR-03 | Exportación de telemetría por USB | Should, meses 2 a 3 | Un USB con la etiqueta SIDER_SYNC escribe el archivo de registro en menos de 30 segundos y muestra una señal de éxito. Ninguna sesión se exporta dos veces. Cualquier otro USB se ignora. |
| FR-04 | Actualización sin conexión con particiones A/B | Could, meses 4 a 6 | Si una actualización falla (checksum inválido, corrupción o fallo de arranque), el sistema vuelve a la partición anterior sin acción del docente, sin pérdida de datos y con menos de 3 minutos de caída. |
| NFR-01 | Concurrencia | Must | Más de 30 escrituras simultáneas con una latencia menor de 200 ms en una Raspberry Pi 4 de 4 GB. |
| NFR-02 | Memoria | Must | Node.js, Express y SQLite no usan más de 500 MB con una carga de 30 sesiones. |
| NFR-03 | Disponibilidad | Must | El servidor funciona más del 99 % del tiempo que hay electricidad, y resiste los apagones porque el sistema operativo es de solo lectura. |
| NFR-05 | Seguridad del USB | Must | Solo se procesan USB con la etiqueta SIDER_SYNC y actualizaciones firmadas. Cero programas sin firmar se ejecutan. |
| NFR-06 | Controles táctiles | Must | Todos los controles miden al menos 48 por 48 px para tablets de 7 a 8 pulgadas. |
| NFR-09 | Privacidad | Must | Ningún nombre completo ni número de documento se guarda en texto plano en los registros exportados. Los estudiantes se identifican con un hash SHA-256. |
| NFR-10 | Cortes de energía | Must | 1.000 cortes de energía simulados seguidos sin corromper la base de datos SQLite. |
Extracto del PRD de SIDER v1.0, 20 de marzo de 2026, escrito para el patrocinador del piloto, FutureSense Foundation. Se quitaron los nombres de colegios y personas. Son requisitos y criterios de aceptación, no resultados de pruebas.
Decisiones de diseño: un extracto del TDD
El TDD responde tres preguntas por cada subsistema: qué patrón, por qué venció a las alternativas y cómo encaja con el resto.
| Principio | Qué significa | Descartado |
|---|---|---|
| Sin conexión primero | No tener red es el estado normal, no un error que atrapar. | Código que intenta una petición y recurre a una alternativa si falla |
| Un monolito deliberado | Un solo proceso de Node.js lo ejecuta todo. Sin contenedores ni malla de servicios. | Microservicios, Docker Compose |
| Escrituras defensivas | Toda escritura en disco asume que la luz puede irse. SQLite en modo WAL con transacciones inmediatas es la única forma de guardar datos. | Escribir archivos JSON directamente |
| Sin dependencias en ejecución | El paquete de producción no necesita red, ni siquiera para tipografías o iconos. | Enlaces a CDN, tipografías remotas |
| La menor superficie de ataque | Sin puertos externos abiertos, sin acceso remoto y sin programas sin firmar. La red del colegio es el perímetro. | SSH expuesto, una API pública |
| Mantenible antes que elegante | Un stack estándar y comentarios en español, para que un desarrollador junior pueda arreglar un problema en campo. | Frameworks de vanguardia |
Extracto del TDD de SIDER v1.0, 20 de marzo de 2026. El hardware es una Raspberry Pi 4 con un SSD, una partición raíz de solo lectura, dos particiones idénticas del sistema para las actualizaciones (A y B) y una partición de datos.
Habilidades de gestión de producto y desarrollo que muestra esta página
Cada habilidad señala el lugar de los documentos donde se puede comprobar.
| Habilidad | Dónde se ve |
|---|---|
| Priorizar con RICE, MoSCoW y horizontes de entrega | Siete iniciativas puntuadas por alcance, impacto, confianza y esfuerzo en personas-mes. La exportación por USB es un Should para los meses 2 y 3 y el sistema de actualización un Could para los meses 4 a 6, así que la primera versión no espera a lo más difícil. |
| Caso de negocio y costo unitario | Un servidor validado un 25,6 % por debajo del precio de referencia, con el ahorro llevado a la pieza que más falla, y una meta de costo por colegio equipado. |
| Definir métricas de éxito | Ocho criterios con una meta y una forma de medir cada uno, escritos antes de que empezara el piloto. |
| Escribir criterios de aceptación comprobables | Cada requisito de arriba termina en un número o algo observable: 30 segundos, 200 ms, 500 MB, 1.000 cortes de energía. |
| Definir el alcance | El PRD lista lo que queda fuera del piloto: internet satelital, equipos para las casas, una app nativa, IA adaptativa e inicio de sesión de terceros. |
| Diseñar para un operador no técnico | Una regla de cero línea de comandos para el docente, colores de semáforo para el estado y una memoria USB como única interfaz de exportación y actualización. |
| Planificar un piloto en campo | Un plan de ejecución del piloto (V5) y una arquitectura de automatización logística (V6) siguieron al PRD. |
| Arquitectura que funciona sin conexión | Una caché con service worker y una cola en el navegador de cada tablet, y una base SQLite en modo WAL en el servidor del colegio. |
| Actualizaciones que resisten fallos | Actualizaciones firmadas escritas en la partición inactiva, una verificación de salud de 30 segundos tras el arranque y una reversión automática. |
| Modelo de datos y una API local | Cuatro tablas (estudiantes, sesiones, módulos y registro de sincronización) y una API que corre en la red del colegio y no llama a nada fuera de ella. |
| Privacidad desde el diseño | Los ID de estudiante son hashes y los registros exportados no contienen nombres. |
“In the Peru Hub, Andres has contributed to the development of SIDER and supported Monitoring & Evaluation processes. … He has demonstrated a good ability to translate operational needs into practical solutions and collaborate across different teams.”
Gonzalo Davila NovoaRegional Manager, Latinoamérica, FutureSense Foundation