División del Cliente en Microfrontends PT2

[milo19980525]

Se requiere continuar la planeación para dividir el sistema SISGPLAN en microclientes, de tal forma que cada uno sea independiente, autosuficiente, escalable, resiliente y tolerante a fallos. El objetivo es lograr desacoplar los componentes del cliente y descentralizar el frontend de un solo cliente para que sea mas sencillo realizar mantenimiento en los mismos y facilitar tareas de intervención por parte del equipo de desarrollo.

Especificaciones técnicas

1. Cada microcliente debe estar conformado por el conjunto de componentes y vistas que se relacionen funcionalmente.
2. Se debe tener en cuenta el cliente base (orquestador de microclientes) se desarrollo en SGA en el repositorio: SGA_cliente_root.
3. Un ejemplo de microcliente es: https://github.com/udistrital/sga_cliente_calendario_academico_mf o https://github.com/udistrital/sga_cliente_proyecto_curricular_mf.
4. El microcliente Core_mf es uno que tienes los componentes globales como: Header, footer, sidebar, estilos, funciones globales (Parecido al web component).
5. Cada Microcliente debe ser descentralizado, lo cual implica que debe poder ser desarrollado, implementado y escalado de forma independiente de otros.
6. Issues a tener en cuenta:
   Prueba de concepto para la creación de microcliente e implementación de Editor de texto enriquecido para la creación de template para correos personalizados  sga_cliente#1454
   Apropiación y documentación de tecnología de micro clientes para la migración del cliente actual a la nueva tecnología  sga_documentacion#4
   Creación de micro cliente para el componente dinámico dinamicforms con arquitectura de micro frontend primera parte sga_cliente#1517
   Creación de capacitación general equipo SGA para la creación e implementación de Clientes con Arquitectura Micro cliente  sga_cliente#1531
   Migración de modulo calendario academico a arquitectura de micro cliente  sga_documentacion#10

Sub Tareas

• Análisis del sistema a nivel de código para comprender su funcionamiento y grado de acoplamiento y unión entre componentes y funcionalidades.
• Refinamiento del diagrama de componentes de la arquitectura propuesta para el sistema de SISGPLAN.
• Creación de listado de Microclientes a detalle, señalando os componentes que lo conforman, así como su relación con otros microclientes y componentes de la OATI.

Criterios de aceptación

• El diagrama de componentes refinado, muestra la división clara del sistema en múltiples microclientes y su relación con los diferentes componentes de la OATI para su funcionamiento como sistema de información.
• El detalle de los microclientes, muestra el listado de funcionalidades que componen cada microcliente y que relación existe entre cada uno de los microclientes entre si y con otros componentes de la OATI.

Requerimientos

• Link del sistema en ambiente de pruebas.
• Material de apoyo.
• Credenciales de acceso al sistema.

Dependencias

• No presenta.

Definition of Ready - DoR

• Está refinada y estimada en puntos de historia por el equipo.
• Incluye la descripción y criterios de aceptación, con el detalle funcional y especificaciones técnicas, de forma entendible por cualquier miembro del equipo.
• No tiene bloqueos que impidan su ejecución.
• Las dependencias entán identificadas y resueltas.
• Puede ser probada dentro del Sprint.

Definition of Done - DoD - Desarrollo

• Criterios de aceptación cumplidos.
• Documentación de issue realizada.
• Aprobada por SM/Líder técnico.

[Mechaz123]

Se adjunta el link del diagrama desarrollador como PROPUESTA, cabe aclarar que la propuesta se encuentra en la pestaña de ORDENAMIENTO:

https://udistritaleduco-my.sharepoint.com/:u:/g/personal/daarojasg_udistrital_edu_co/EYokYcdfRD9FomBr8J2MlUkBiTfYdiKwOSaTsdbAiKqbbA?e=wBfwC0

[Mechaz123]

Se adjunta también la imagen del diagrama desarrollado:

[Mechaz123]

Después de la revisión por parte del equipo de SISGPLAN, se deben realizar los siguientes cambios:

• Observar de qué manera se puede desacoplar el PUI del MF de seguimiento.
• Crear un MF llamado Utilidades para incluir información básica y evaluación.
• Observar de qué manera se puede desacoplar "Formulación Plan", en un MF nuevo, actualmente todo está unido en el componente llamado PLAN.

Se queda al pendiente de si falta alguna otra indicación a listar, para realizar el respectivo cambio.

[milo19980525]

Se debe revisar el apartado pendientes asociado al usuario "pruebascps".

[Mechaz123]

Se realizan las modificaciones mencionadas al diagrama.

[milo19980525]

Por favor realizar los siguientes ajustes:

• Creación de MF de evaluación (sacar de utilidades-mf).
• Ajuste de MF "PLAN DE ACCION - MF", para que contenga el componente de plan en "PLANES-MF". La idea es que "PLAN DE ACCION - MF" contenga la construcción, consulta y habilitación de reporte. Cambiar nombre a "planeacion_construccion_mf"