mirror of
https://github.com/reeduorg/reeduorg-docs.git
synced 2026-02-11 17:16:57 +00:00
Reformateo del TdR de Arquitectura y cálculo de recursos
This commit is contained in:
Fiorella Barcelli
parent
79a60d4ca8
commit
044ecc5f32
GPG key ID:
006C13A68E25D3B7
|
|
@ -1,143 +1,132 @@
|
||||||
DISEÑO DE LA ARQUITECTURA de TI
|
# Arquitectura de Tecnología de Información (TI) – Términos de Referencia (TdR)
|
||||||
Arquitectura de Tecnología de Información (TI) – Términos de Referencia (TdR)
|
|
||||||
1. Objetivo del Proyecto
|
## 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:
|
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
|
* 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:
|
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
|
* Diseñar la arquitectura empresarial de TI, alineada a los procesos educativos definidos por ReEdu.
|
||||||
• Principios de Arquitectura de TI (alineados a la misión de ReEdu).
|
* Definir la arquitectura lógica y física de los sistemas de información.
|
||||||
• Mapa de Capacidades Digitales, vinculado a los procesos educativos.
|
* Definir la arquitectura de datos, incluyendo modelos conceptuales y principios de gobierno de datos.
|
||||||
• Arquitectura Empresarial de TI (nivel 0–1).
|
* Definir la arquitectura de aplicaciones, identificando:
|
||||||
• Arquitectura de Aplicaciones:
|
* sistemas núcleo,
|
||||||
◦ catálogo de aplicaciones,
|
* componentes reutilizables,
|
||||||
◦ diagramas de interacción,
|
* integraciones,
|
||||||
◦ estándares de integración (APIs, eventos, etc.).
|
* posibles soluciones existentes (open source / comerciales).
|
||||||
• Arquitectura de Datos:
|
* Definir la arquitectura tecnológica, incluyendo:
|
||||||
◦ modelos conceptuales,
|
* infraestructura,
|
||||||
◦ lineamientos de calidad, seguridad y gobierno de datos.
|
* cloud vs on-premise,
|
||||||
• Arquitectura Tecnológica:
|
* conectividad,
|
||||||
◦ infraestructura de referencia,
|
* seguridad,
|
||||||
◦ lineamientos de despliegue,
|
* continuidad y respaldo.
|
||||||
◦ seguridad y continuidad.
|
* Establecer principios de interoperabilidad, seguridad, privacidad y protección de datos, alineados a la normativa peruana.
|
||||||
• Roadmap de implementación tecnológica, por fases.
|
* Definir mecanismos para la evolución continua de la arquitectura.
|
||||||
• Criterios de evaluación tecnológica para futuras adquisiciones o desarrollos.
|
* Documentar todas las decisiones arquitectónicas y sus racionales.
|
||||||
• Repositorio abierto con toda la documentación, diagramas y artefactos.
|
* 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.
|
||||||
|
|
||||||
4. Estándares y Lineamientos Metodológicos
|
### Fuera de Alcance
|
||||||
• 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
|
* Desarrollo de software o adquisición de infraestructura.
|
||||||
• Gerente del Proyecto: coordinación general y ejecución.
|
* Implementación en instituciones educativas.
|
||||||
• Ejecutivo del Proyecto: aprobación de TdR, entregables y stage gates.
|
* Operación y soporte productivo de sistemas.
|
||||||
• Gerente de TI: dueño del diseño de la arquitectura.
|
* Definición de políticas públicas o regulación.
|
||||||
• 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
|
## Entregables
|
||||||
• 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)
|
* Principios de Arquitectura de TI (alineados a la misión de ReEdu).
|
||||||
Fase
|
* Mapa de Capacidades Digitales, vinculado a los procesos educativos.
|
||||||
Personas
|
* Arquitectura Empresarial de TI (nivel 0–1).
|
||||||
Duración
|
* Arquitectura de Aplicaciones:
|
||||||
Esfuerzo
|
* catálogo de aplicaciones,
|
||||||
Alineamiento con procesos educativos
|
* diagramas de interacción,
|
||||||
4–6
|
* estándares de integración (APIs, eventos, etc.).
|
||||||
4 semanas
|
* Arquitectura de Datos:
|
||||||
120 hh
|
* modelos conceptuales,
|
||||||
Definición de principios y arquitectura alto nivel
|
* lineamientos de calidad, seguridad y gobierno de datos.
|
||||||
6–8
|
* Arquitectura Tecnológica:
|
||||||
2–3 semanas
|
* infraestructura de referencia,
|
||||||
200 hh
|
* lineamientos de despliegue,
|
||||||
Arquitecturas de dominio (apps, datos, tecnología)
|
* seguridad y continuidad.
|
||||||
8–12
|
* Roadmap de implementación tecnológica, por fases.
|
||||||
12–20 semanas
|
* Criterios de evaluación tecnológica para futuras adquisiciones o desarrollos.
|
||||||
1,200 hh
|
* Repositorio abierto con toda la documentación, diagramas y artefactos.
|
||||||
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
|
## Estándares y Lineamientos Metodológicos
|
||||||
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
|
* Marco de referencia: TOGAF (adaptado) o equivalente liviano.
|
||||||
• Existirá un modelo de procesos educativos previamente definido.
|
* Modelado:
|
||||||
• Existen elementos de arquitectura opern source satisfactorios para cumplir el diseño
|
* ArchiMate (cuando aplique),
|
||||||
• Se tendrá acceso a SMEs para consultas de temas puntuales sin conocimiento local
|
* diagramas de arquitectura lógica y física.
|
||||||
• El costo promedio de hh se estima en US$ 70.
|
* 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.
|
||||||
|
|
||||||
10. Resultado Esperado
|
## Roles y Responsabilidades
|
||||||
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.
|
|
||||||
|
|
||||||
|
* 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.
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue