kikobar/reeduorg-docs
1
0
Fork 0
mirror of https://github.com/reeduorg/reeduorg-docs.git synced 2026-03-04 19:36:13 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Compare commits

base: kikobar:d7adc8a7c355b306508504659d2afe256ac827e6
Branches Tags
kikobar:main
..
compare: kikobar:938e0383cefeae1007100e5524d4d9d2c16226fe
Branches Tags
kikobar:main

No commits in common. "d7adc8a7c355b306508504659d2afe256ac827e6" and "938e0383cefeae1007100e5524d4d9d2c16226fe" have entirely different histories.
d7adc8a7c3 ... 938e0383ce

3 changed files with 56 additions and 290 deletions
Show stats Expand all files Collapse all files

132
Data-y-Sistemas/Arquitectura-de-TI-TdR.md
View file

@ -1,132 +0,0 @@
# Arquitectura de Tecnología de Información (TI) – Términos de Referencia (TdR)
## Objetivo del Proyecto
Diseñar y documentar la arquitectura integral de Tecnología de Información que soporte los procesos educativos definidos por Reingeniería Educativa (ReEdu), asegurando que dicha arquitectura sea:
* alineada con los objetivos educativos y sociales del proyecto,
* modular, escalable y evolutiva,
* económicamente sostenible,
* interoperable y basada en estándares abiertos,
* publicable bajo licencias de acceso abierto compatibles con MIT o CC BY 4.0.
La arquitectura servirá como base para la implementación del sistema educativo y de gestión que soporta el modelo educativo de ReEdu en diversos centros educativos en todo el Perú.
## Alcance
El proyecto de Arquitectura de TI incluye, pero no se limita a:
* Diseñar la arquitectura empresarial de TI, alineada a los procesos educativos definidos por ReEdu.
* Definir la arquitectura lógica y física de los sistemas de información.
* Definir la arquitectura de datos, incluyendo modelos conceptuales y principios de gobierno de datos.
* Definir la arquitectura de aplicaciones, identificando:
* sistemas núcleo,
* componentes reutilizables,
* integraciones,
* posibles soluciones existentes (open source / comerciales).
* Definir la arquitectura tecnológica, incluyendo:
* infraestructura,
* cloud vs on-premise,
* conectividad,
* seguridad,
* continuidad y respaldo.
* Establecer principios de interoperabilidad, seguridad, privacidad y protección de datos, alineados a la normativa peruana.
* Definir mecanismos para la evolución continua de la arquitectura.
* Documentar todas las decisiones arquitectónicas y sus racionales.
* Publicar toda la documentación generada bajo licencias abiertas MIT o CC BY 4.0.
* La arquitectura deberá ser aplicable a contextos urbanos y rurales.
### Fuera de Alcance
* Desarrollo de software o adquisición de infraestructura.
* Implementación en instituciones educativas.
* Operación y soporte productivo de sistemas.
* Definición de políticas públicas o regulación.
## Entregables
* Principios de Arquitectura de TI (alineados a la misión de ReEdu).
* Mapa de Capacidades Digitales, vinculado a los procesos educativos.
* Arquitectura Empresarial de TI (nivel 0–1).
* Arquitectura de Aplicaciones:
* catálogo de aplicaciones,
* diagramas de interacción,
* estándares de integración (APIs, eventos, etc.).
* Arquitectura de Datos:
* modelos conceptuales,
* lineamientos de calidad, seguridad y gobierno de datos.
* Arquitectura Tecnológica:
* infraestructura de referencia,
* lineamientos de despliegue,
* seguridad y continuidad.
* Roadmap de implementación tecnológica, por fases.
* Criterios de evaluación tecnológica para futuras adquisiciones o desarrollos.
* Repositorio abierto con toda la documentación, diagramas y artefactos.
## Estándares y Lineamientos Metodológicos
* Marco de referencia: TOGAF (adaptado) o equivalente liviano.
* Modelado:
* ArchiMate (cuando aplique),
* diagramas de arquitectura lógica y física.
* Principios:
* Open by default
* API-first
* Modularidad y desacoplamiento
* Seguridad y privacidad desde el diseño
* Uso preferente de:
* estándares abiertos,
* software open source cuando sea viable.
## Roles y Responsabilidades
* Gerente del Proyecto: coordinación general y ejecución.
* Ejecutivo del Proyecto: aprobación de TdR, entregables y stage gates.
* Gerente de TI: dueño del diseño de la arquitectura.
* Gerente de Procesos e Innovación: asegurar alineamiento con procesos educativos.
* Experto en Educación: validar adecuación pedagógica de las soluciones.
* Gerente de Finanzas y RRHH: control de recursos y transparencia.
* Sounding Board de TI: comité de expertos en arquitectura, seguridad y sistemas educativos, responsable de evaluar calidad, viabilidad y sostenibilidad.
## Plan de Recursos, Calidad, Finanzas y Gobierno
* Trabajo estructurado en co-locations de expertos senior.
* Uso de stage gates para aprobar:
* arquitectura de alto nivel,
* arquitecturas de dominio,
* roadmap.
* Evaluación de calidad basada en:
* alineamiento con procesos,
* simplicidad,
* escalabilidad,
* costo total de propiedad.
* El trabajo podrá ser valorizado, remunerado o donado.
## Decomposición y Programación del Trabajo (referencial)
| Fase | Personas | Duración | Esfuerzo | Costo (US$) | Gastos de co-locacion (US$) |
| -------------------------------------------------- |:---------:|:-----------------:|:------------:|:-----------:|:---------------------------:|
| Alineamiento con procesos educativos | 4–6 | 4 semanas | 120 hh | 8,400 | 2,000 |
| Definición de principios y arquitectura alto nivel | 6–8 | 2–3 semanas | 200 hh | 14,000 | 3,000 |
| Arquitecturas de dominio (apps, datos, tecnología) | 8–12 | 12–20 semanas | 1,200 hh | 84,000 | 20,000 |
| Roadmap y criterios de adopción | 4–6 | 4 semanas | 160 hh | 11,200 | 4,000 |
| Validación por expertos y stage gates | 6–8 | 2 semanas | 120 hh | 8,400 | - |
| **Total** | **15-20** | **30-40 semanas** | **1,800 hh** | **126,000** | **29,000** |
## Principales Incidencias y Riesgos
| Incidencia/Riesgo | Descripción | Calificación | Mitigación |
|:-----------------:| ----------------------------------------------------- |:------------:| -------------------- |
| Riesgo | Arquitectura excesivamente compleja, dificil adopción | Alto | Enfoque MVP |
| Riesgo | Dependencia de proveedores, lock-in tecnológico | Medio | Estándares abiertos |
| Riesgo | Limitaciones de conectividad, brecha digital | Medio | Arquitectura híbrida |
## Supuestos y Limitaciones
* Existirá un modelo de procesos educativos previamente definido.
* Existen elementos de arquitectura opern source satisfactorios para cumplir el diseño
* Se tendrá acceso a SMEs para consultas de temas puntuales sin conocimiento local
* El costo promedio de hh se estima en US$ 70.
## Resultado Esperado
* Un modelo de arquitectura TI de referencia para la educación escolar en el Perú, abierto, replicable y sostenible, que sirva como base para la transformación digital del sistema educativo.

56
Data-y-Sistemas/Data-y-Sistemas-TdR.md Normal file
View file

@ -0,0 +1,56 @@
# Data y Sistemas TdR
## Objetivos del Proyecto
### Alcance
* Diseñar y documentar el modelo de datos, arquitectura de tecnología y aplicaciones requeridos para soportar los procesos involucrados en el planeamiento, desarrollo, ejecución, control y mejora contínua de la educación escolar.
* Publicar todos los diseños, aplicaciones y contenidos arriba descritos, y en general todos los documentos, estudios, análisis, datos, reportes y cuanto material sea generado por el proyecto, bajo licencias de acceso abierto compatibles con MIT o CC BY 4.0.
### Entregables
* Modelo de Datos
* Arquitectura de tecnología
* Paisaje de aplicaciones
* Especificaciones funcionales
## Roles y Responsabilidades del Proyecto
> Describir los principales roles y responsabilidades del proyecto.
* Gerente del Proyecto - (vacante) - Responsable por el desarroyo y ejecución del proyecto.
* Ejecutivo del Proyecto - Presidente del Consejo Directivo de Reingeniería Educativa - Responsable por la aprobación de los TdR, la aceptación de los entregables, la aprobación de los 'Stage Gates' y de la provisión de los fondos y recursos necesarios para el desarrollo y ejecución del proyecto.
* Gerente de TI - (vacante) - Responsable por el diseño y desarrollo de la arquitectura y aplicaciones de TI.
* Gerente de Procesos e Innovación - (vacante) - Dueño y responsable por el diseño de los procesos de negocio (si bien aquí el negocio es el comunal de la educación).
* Experto en Educación - (vacante) - Proveer y conseguir experiencia diversa en materia de educación y pedagogía.
* Gerente de Communicaciones - (vacante) - Responsable por la estrategia y planes de comunicación del proyecto.
* Gerente de Finanzas y Recursos Humanos - (vacante) - Proveer eficiencia y transparencia en la administración de los fondos y recursos del proyecto.
* "Sounding Board" - (vacante) - Comité de expertos en la materia en arquitectura de sistemas de informacion, modelaje de datos, selección y especificación de sistemas de información
## Plan de Recursos, Calidad, Finanzas y Gobierno
> Describir el plan recursos y gobierno del proyecto.
## Decomposición y Programación del Trabajo
> Describir las fases, hitos, tiempos y decomposición del trabajo del proyecto.
* Este proyecto tiene como dependencia el haber completado el diseño de los procesos de educación según [Procesos-y-Funciones-TdR.md](../Procesos-y-Funciones/Procesos-y-Funciones-TdR.md)
## Principales Incidencias y Riesgos
> Describir las principales incidencias y riesgos identificados al momento de la prepareación de estos TdR.
| Incidencia/Riesgo | Descripción | Calificación | Mitigación |
|:-----------------:| -------------------------------------------------------------------------------------------------------------------------------------- |:------------:| -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Riesgo | Invertir gran cantidad de esfuerzo y recursos y al final no obtener interés de la comunidad o de los principales actores involucrados. | Alto | Conectar lo más temprano posible con los stakeholders clave. Desarrollar el proyecto en fases ('stagegated'). |
| Riesgo | No ser capaces de asegurar los recursos y fondos necesarios. | Alto | Mantener el proyecto lo más liviano posible. Conectar lo más temprano posible con potenciales patrocinadores. Desarrollar el proyecto en fases ('stagegated'). |
## Supuestos y Limitaciones
> Describir los supuestos hechos y las limitaciones identificadas al momento de la preparación de estos TdR.
* Los miembros fundadores de ReEdu donarán el tiempo y recursos necesarios para establecer y echar a andar el proyecto.
* Hay suficientes personas, organizaciones e instituciones competentes e interesadas en el mejoramiento de la eduación en el Perú como para poder obtener los recursos necesarios para poder sostener el proyecto y desarrollar los objetivos de ReEdu.
* Es posible diseñar, desarrollar y construir una ifraestructura de TI y paisaje de aplicaciones para soportar los procesos de educación escolar utilizando exclusivamente en tecnología de código abierto.

158
Data-y-Sistemas/Sistema-de-Información-y-Software-Educativo-TdR.md
View file

@ -1,158 +0,0 @@
# Sistema de Información y Software Educativo – Términos de Referencia (TdR)
## Objetivo del Proyecto
Definir el conjunto de sistemas de información y software necesarios para operar el nuevo modelo educativo diseñado por Reingeniería Educativa (ReEdu), asegurando que dichos sistemas:
* soporten integralmente los procesos educativos definidos,
* estén alineados con la arquitectura de TI aprobada,
* sean viables técnica, económica y operativamente,
* prioricen soluciones abiertas, reutilizables y sostenibles,
* puedan implementarse progresivamente en instituciones educativas del Perú.
* El resultado será una definición clara y priorizada de qué software debe:
* desarrollarse,
* adaptarse,
* integrarse,
* o adquirirse.
### Alcance
El proyecto incluye, pero no se limita a:
* Identificar y documentar los sistemas de información requeridos para soportar el modelo educativo ReEdu.
* Definir el alcance funcional de cada sistema.
* Establecer la clasificación de cada componente de software:
* desarrollar,
* adaptar,
* integrar,
* adquirir (preferentemente open source).
* Definir la interacción entre sistemas (integraciones, flujos de datos, APIs).
* Definir los requerimientos no funcionales:
* seguridad,
* privacidad,
* disponibilidad,
* desempeño,
* escalabilidad,
* usabilidad.
* Establecer criterios de priorización y secuenciación de implementación.
* Definir lineamientos para la evolución y mantenimiento del software.
* Documentar y publicar todo el trabajo bajo licencias MIT o CC BY 4.0.
#### Fuera de Alcance
* Desarrollo o implementación del software.
* Contratación de proveedores tecnológicos.
* Operación productiva de los sistemas.
* Soporte técnico continuo.
### Entregables
* Mapa de Sistemas de Información, alineado a los procesos educativos.
* Catálogo de Sistemas y Componentes de Software, incluyendo:
* propósito,
* usuarios,
* alcance funcional.
* Especificación funcional de alto nivel por sistema.
* Matriz de decisión “Build / Adapt / Buy / Integrate”.
* Modelo de interacción entre sistemas (integraciones y flujos).
* Requerimientos no funcionales consolidados.
* Priorización de implementación (MVP, Fase 2, Fase 3).
* Estimación referencial de esfuerzo y costos.
* Repositorio abierto con toda la documentación generada.
## Enfoque Metodológico
* Derivación directa desde:
* procesos educativos,
* arquitectura TI aprobada.
* Diseño usuario-céntrico (docentes, estudiantes, gestores).
* Enfoque MVP + iterativo.
* Preferencia por:
* software open source,
* estándares abiertos,
* arquitectura modular.
* Documentación clara, reutilizable y neutral respecto a proveedores.
## Sistemas de Información a Considerar (referencial)
> La lista final se definirá durante el proyecto.
* Núcleo Educativo
* Sistema de Gestión Académica
* Sistema de Gestión Curricular y Contenidos
* Sistema de Evaluación y Seguimiento del Estudiante
* Plataforma de Aprendizaje (LMS / LXP)
* Gestión y Soporte
* Gestión de Docentes y Talento Educativo
* Gestión de Padres / Tutores
* Gestión Administrativa y Registros
* Gestión de Bienestar y Seguridad
* Analítica y Mejora Continua
* Sistema de Monitoreo de Desempeño Educativo
* Analítica y Reportes
* Gestión de Indicadores (KPIs)
* Transversales
* Gestión de Identidad y Accesos
* Integración y APIs
* Seguridad y Cumplimiento
## Roles y Responsabilidades
* Gerente del Proyecto: coordinación y ejecución.
* Ejecutivo del Proyecto: aprobación de entregables y stage gates.
* Gerente de TI: responsable técnico del diseño.
* Gerente de Procesos e Innovación: alineamiento funcional.
* Experto en Educación: validación pedagógica.
* Sounding Board de Sistemas: evaluación de usabilidad, viabilidad y sostenibilidad.
* Gerente de Finanzas: evaluación de costos y sostenibilidad económica.
## Plan de Recursos, Calidad, Finanzas y Gobierno
* Trabajo estructurado en co-locations de expertos.
* Uso de stage gates para:
* validación del mapa de sistemas,
* aprobación de especificaciones funcionales,
* aprobación de priorización.
* Evaluación de calidad basada en:
* trazabilidad proceso → sistema,
* simplicidad y reutilización,
* costo total de propiedad.
* El esfuerzo podrá ser valorizado, remunerado o donado.
## Decomposición y Programación del Trabajo (referencial)
| Fase | Personas | Duración | Esfuerzo | Costo (US$) | Gastos de co-locación (US$) |
| ------------------------------------------------- |:-----------:|:-----------------:|:------------:|:-----------:|:---------------------------:|
| Alineamiento con procesos y arquitectura | 4 – 6 | 3 semanas | 100 hh | 5,500 | 1,000 |
| Identificación y mapa de sistemas | 6 – 8 | 4 semanas | 200 hh | 11,000 | 3,000 |
| Definición funcional de sistemas | 8 – 12 | 10 – 16 semanas | 1,000 hh | 55,000 | 20,000 |
| Análisis build/buy/adapt | 4 – 6 | 4 semanas | 160 hh | 8,800 | - |
| Priorización y roadmap | 4 – 6 | 3 semanas | 120 hh | 6,600 | - |
| Validación y stage gates | 6 – 8 | 2 semanas | 100 hh | 5,500 | - |
| Input de expertos de procesos durante el proyecto | 2 - 4 | 20 - 30 semanas | 500 hh | 27,500 | - |
| **Total** | **15 - 25** | **30-40 semanas** | **2,180 hh** | **119,900** | **24,000** |
## Principales Incidencias y Riesgos
| Incidencia/Riesgo | Descripción | Calificación | Mitigación |
|:-----------------:| ----------------------------------------------------------------------------------- |:------------:| ------------------------------------ |
| Riesto | Definición excesivamente ambiciosa | Alto | MVP + fases |
| Riesgo | Dependencia tecnológica | Medio | Estándares abiertos |
| Riesgo | Baja adopción por usuarios | Alto | Co-diseño |
| Riesgo | Limitaciones de conectividad | Medio | Diseño offline/híbrido |
| Riesgo | Falta de conocimiento previo de proyecto de esta magnitud en el equipo del proyecto | Alto | Conseguir SMEs en el exterior |
| Riesgo | Estimación inicial de recursos podría estar lejos de la realidad | Alto | Revisión y ajuste en cada stage gate |
## Supuestos y Limitaciones
* La arquitectura de TI está aprobada.
* Los procesos educativos están definidos.
* El costo promedio de hh se estima en US$ 55.
* El diseño deberá ser aplicable a contextos con recursos limitados.
* Existen aplicaciones en el mercado que cubren al menos 80% de las funcionalidades requeridas
* Se cuenta con infraestructura aaS para hacer prototipos que se requieran
* Se tendrá acceso a especialistas de las diferentes aplicaciones a incorporar en el diseño
## Resultado Esperado
* Un modelo claro, priorizado y ejecutable de sistemas y software educativo, que permita a ReEdu y a terceros implementar el nuevo modelo educativo de forma progresiva, abierta y sostenible.