From 79a60d4ca8dba28ccc64ff8b13e686231a24e58f Mon Sep 17 00:00:00 2001 From: Fiorella Barcelli Date: Sun, 8 Feb 2026 17:23:34 +0800 Subject: [PATCH] =?UTF-8?q?Separar=20el=20IT=20TdR=20en=20dos=20partes,=20?= =?UTF-8?q?una=20para=20el=20dise=C3=B1o=20del=20sistema=20y=20aplicacione?= =?UTF-8?q?s,=20y=20otra=20para=20el=20dise=C3=B1o=20de=20la=20arquitectur?= =?UTF-8?q?a=20de=20TI?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Data-y-Sistemas/Arquitectura-de-TI-TdR.md | 143 ++++++++++++++++ ...e-Información-y-Software-Educativo-TdR.md | 158 ++++++++++++++++++ 2 files changed, 301 insertions(+) create mode 100644 Data-y-Sistemas/Arquitectura-de-TI-TdR.md create mode 100644 Data-y-Sistemas/Sistema-de-Información-y-Software-Educativo-TdR.md diff --git a/Data-y-Sistemas/Arquitectura-de-TI-TdR.md b/Data-y-Sistemas/Arquitectura-de-TI-TdR.md new file mode 100644 index 0000000..657e27a --- /dev/null +++ b/Data-y-Sistemas/Arquitectura-de-TI-TdR.md @@ -0,0 +1,143 @@ +DISEÑO DE LA ARQUITECTURA de TI +Arquitectura de Tecnología de Información (TI) – Términos de Referencia (TdR) +1. 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ú. + +2. 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. + +3. 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. + +4. 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. + +5. 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. + +6. 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. + +7. Decomposición y Programación del Trabajo (referencial) +Fase +Personas +Duración +Esfuerzo +Alineamiento con procesos educativos +4–6 +4 semanas +120 hh +Definición de principios y arquitectura alto nivel +6–8 +2–3 semanas +200 hh +Arquitecturas de dominio (apps, datos, tecnología) +8–12 +12–20 semanas +1,200 hh +Roadmap y criterios de adopción +4–6 +4 semanas +160 hh +Validación por expertos y stage gates +6–8 +2 semanas +120 hh + +8. Principales Riesgos +Riesgo +Descripción +Mitigación +Arquitectura excesivamente compleja +Difícil adopción +Enfoque MVP +Dependencia de proveedores +Lock-in tecnológico +Estándares abiertos +Limitaciones de conectividad +Brecha digital +Arquitectura híbrida + +9. 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. + +10. 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. + + diff --git a/Data-y-Sistemas/Sistema-de-Información-y-Software-Educativo-TdR.md b/Data-y-Sistemas/Sistema-de-Información-y-Software-Educativo-TdR.md new file mode 100644 index 0000000..2234dbb --- /dev/null +++ b/Data-y-Sistemas/Sistema-de-Información-y-Software-Educativo-TdR.md @@ -0,0 +1,158 @@ +# 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.