La integracion SYS-07 - Acceso Unico Institucional debe tratarse como contrato operativo entre sistemas. Este articulo describe el estado actual, la forma esperada de integracion, las dependencias necesarias y las tareas que deben cerrar evidencia antes de avanzar a certificacion o produccion.
Introduccion
Esta integracion debe entenderse como un contrato operativo entre sistemas. Su implementacion debe avanzar por etapas: definicion funcional, contrato tecnico, mock, adaptador, prueba de permisos, conexion real, certificacion, despliegue y monitoreo.
Detalle
- Sistema: SYS-07 - Acceso Unico Institucional
- Owner funcional: DTI/PFPNNA | Owner tecnico: Seguridad/DTI
- Autenticacion: OAuth2/JWT/MFA/RBAC
- VPN: No | Allowlist: No | Certificados: No
- Estado: mock Proveedor simulado permitido para desarrollo, adaptador Integracion de identidad pendiente de especificacion final, conexion real Ambiente de autenticacion pendiente, certificacion Pruebas de seguridad y roles pendientes, produccion Produccion condicionada a pentesting.
Como se espera integrar
Integracion de identidad con OAuth2/JWT, RBAC, MFA, auditoria, expiracion de sesiones y segregacion de funciones.
Dependencias necesarias
- DEP-DTI-001: Repositorios Git - condicion operacional para DTI. - Habilita construccion, control de versiones, revisiones tecnicas, trazabilidad de cambios y despliegues. Sin esta dependencia, las tareas pueden avanzar en diseno, pero no deben cerrarse como implementadas.
- DEP-DTI-002: Arquitectura institucional - condicion operacional para DTI. - Habilita diseno, contratos, criterios de aceptacion y validacion funcional. Sin esta dependencia, se pueden documentar supuestos, pero no cerrar definiciones finales.
- DEP-DTI-004: Documentación de autenticación - condicion operacional para DTI. - Habilita pruebas, despliegue, validacion de seguridad y evidencia operativa. Sin esta dependencia, el avance debe mantenerse condicionado o con mock.
- DEP-DTI-007: Acceso a datos historicos - condicion operacional para DTI y migracion. - Habilita el avance contractual del componente relacionado. Su ausencia puede condicionar analisis, construccion, pruebas, certificacion o liberacion segun la tarea afectada.
- DEP-INM-001: Enlace tecnico y funcional INM - condicion de gobierno para interoperabilidad externa. - Habilita interoperabilidad real, certificacion y paso a produccion. Sin esta dependencia, solo se puede operar con mock o adaptador condicionado.
Tareas vinculadas
PYD-001 - Sesión de lanzamiento
Responsable: Coordinadora técnica | Disciplina: Coordinacion | Sistema/componente: Gobierno del Proyecto | Fechas: 2026-06-16 a 2026-06-17.
Descripcion detallada
PYD-001 - Sesión de lanzamiento
Objetivo PM: abrir formalmente el proyecto con acuerdos de gobierno, canales, calendario inmediato y ruta de decision para los frentes RMH, RMI, interoperabilidad, datos, QA y seguridad.
Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta Gobierno del Proyecto, queda a cargo de Coordinadora técnica y esta planeada del 2026-06-16 al 2026-06-17. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: la sesion debe cerrar acuerdos utilizables desde el dia siguiente: responsables, cadencia, tablero, riesgos iniciales y dependencias que requieren escalamiento. Actividades principales del checklist: Preparar agenda de arranque con objetivos, alcance de la reunion, decisiones esperadas y tiempo asignado por tema; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Confirmar asistentes clave: direccion funcional, DTI, coordinacion tecnica, QA, seguridad, datos e integraciones; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Presentar alcance contractual, entregables, hitos, fechas criticas y mecanismo de aceptacion; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Acordar canales de comunicacion, cadencia de comites, formato de seguimiento y responsables de decision; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Registrar acuerdos, riesgos iniciales, dependencias abiertas y dudas que requieren respuesta institucional; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-001 (Sesión de lanzamiento): minuta validada, lista de asistentes, acuerdos, decisiones abiertas, dependencias iniciales y acciones inmediatas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-001 solo si "Sesión de lanzamiento" produce minuta de arranque con acuerdos, asistentes, decisiones abiertas y calendario inmediato; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con minuta aceptada, acuerdos fechados, responsables asignados y actualizacion del tablero PtD. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.
Riesgos y controles: Riesgo de cerrar Sesión de lanzamiento sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-001 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Coordinadora técnica puede coordinar la revision de Gobierno del Proyecto, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-001 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-001 (Sesión de lanzamiento): minuta validada, lista de asistentes, acuerdos, decisiones abiertas, dependencias iniciales y acciones inmediatas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-001 solo si "Sesión de lanzamiento" produce minuta de arranque con acuerdos, asistentes, decisiones abiertas y calendario inmediato; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con minuta aceptada, acuerdos fechados, responsables asignados y actualizacion del tablero PtD. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Sesión de lanzamiento sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-001 | Alcance | Preparar agenda de arranque con objetivos, alcance de la reunion, decisiones esperadas y tiempo asignado por tema; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-001 | Analisis | Confirmar asistentes clave: direccion funcional, DTI, coordinacion tecnica, QA, seguridad, datos e integraciones; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-001 | Construccion | Presentar alcance contractual, entregables, hitos, fechas criticas y mecanismo de aceptacion; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-001 | Evidencia | Acordar canales de comunicacion, cadencia de comites, formato de seguimiento y responsables de decision; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-001 | Validacion | Registrar acuerdos, riesgos iniciales, dependencias abiertas y dudas que requieren respuesta institucional; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-001 | Dependencias | Definir acciones inmediatas con responsable, fecha compromiso y relacion con las siguientes tareas del hito; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-001 | Seguridad | Adjuntar minuta validada por participantes o responsable funcional/tecnico; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-001 | Cierre | Actualizar Perfex/PtD con acuerdos, proximos pasos y semaforo inicial del proyecto; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-002 - Confirmación formal del alcance del RMH
Responsable: Analista funcional | Disciplina: Funcional/Backend | Sistema/componente: RMH - Registro de Movilidad Humana | Fechas: 2026-06-16 a 2026-06-18.
Descripcion detallada
PYD-002 - Confirmación formal del alcance del RMH
Objetivo PM: cerrar que cubre y que no cubre el Registro de Movilidad Humana: alta de caso, situacion migratoria, seguimiento, canalizaciones, entradas/salidas, repatriaciones e interoperabilidad INM/COMAR.
Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta RMH - Registro de Movilidad Humana, queda a cargo de Analista funcional y esta planeada del 2026-06-16 al 2026-06-18. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el alcance debe separar funciones obligatorias, integraciones condicionadas, datos afectados, reglas de negocio, reportes y criterios de aceptacion. Actividades principales del checklist: Revisar objetivo del componente Registro de Movilidad Humana y su relacion con Expediente Unico NNA e interoperabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Definir que procesos, datos, reportes e integraciones quedan incluidos en el alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Documentar exclusiones, supuestos, restricciones institucionales y criterios para cambios futuros; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Identificar dependencias externas, responsables de aprobacion y riesgos que condicionan el cierre; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Aterrizar criterios de aceptacion verificables para analisis, construccion, pruebas y entrega; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-002 (Confirmación formal del alcance del RMH): documento de alcance, lista de incluidos/excluidos, supuestos, criterios de aceptacion y aprobacion funcional/tecnica. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-002 solo si "Confirmación formal del alcance del RMH" produce documento de alcance con incluidos, excluidos, supuestos, dependencias, criterios de aceptacion y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando RMH queda aprobado como alcance operativo y las excepciones quedan registradas como condicion o cambio futuro. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional
Riesgos y controles: Alcance ambiguo que provoque retrabajo, expectativas no aprobadas o cierre condicionado del entregable. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-002 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Analista funcional puede coordinar la revision de Registro de Movilidad Humana, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-002 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-002 (Confirmación formal del alcance del RMH): documento de alcance, lista de incluidos/excluidos, supuestos, criterios de aceptacion y aprobacion funcional/tecnica. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-002 solo si "Confirmación formal del alcance del RMH" produce documento de alcance con incluidos, excluidos, supuestos, dependencias, criterios de aceptacion y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando RMH queda aprobado como alcance operativo y las excepciones quedan registradas como condicion o cambio futuro. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Alcance ambiguo que provoque retrabajo, expectativas no aprobadas o cierre condicionado del entregable. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-002 | Alcance | Revisar objetivo del componente Registro de Movilidad Humana y su relacion con Expediente Unico NNA e interoperabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-002 | Analisis | Definir que procesos, datos, reportes e integraciones quedan incluidos en el alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-002 | Construccion | Documentar exclusiones, supuestos, restricciones institucionales y criterios para cambios futuros; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-002 | Evidencia | Identificar dependencias externas, responsables de aprobacion y riesgos que condicionan el cierre; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-002 | Validacion | Aterrizar criterios de aceptacion verificables para analisis, construccion, pruebas y entrega; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-002 | Dependencias | Validar que el alcance no prometa conexion real cuando solo exista mock o documentacion pendiente; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-002 | Seguridad | Obtener revision funcional y tecnica sobre el alcance acordado; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-002 | Cierre | Actualizar Perfex/PtD con decisiones, condiciones y pendientes del alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-003 - Confirmar alcance de Movilidad Interna
Responsable: Coordinadora técnica | Disciplina: Funcional/Backend | Sistema/componente: RMI - Registro de Movilidad Interna | Fechas: 2026-06-16 a 2026-06-18.
Descripcion detallada
PYD-003 - Confirmar alcance de Movilidad Interna
Objetivo PM: cerrar el alcance del Registro de Movilidad Interna: traslados, origen/destino, causas, responsables, seguimiento, relacion con medidas y centros.
Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta RMI - Registro de Movilidad Interna, queda a cargo de Coordinadora técnica y esta planeada del 2026-06-16 al 2026-06-18. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el alcance debe precisar datos, estados, validaciones, permisos, evidencias y cruces con Expediente Unico y RMH. Actividades principales del checklist: Revisar objetivo del componente Registro de Movilidad Interna y su relacion con Expediente Unico NNA e interoperabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Definir que procesos, datos, reportes e integraciones quedan incluidos en el alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Documentar exclusiones, supuestos, restricciones institucionales y criterios para cambios futuros; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Identificar dependencias externas, responsables de aprobacion y riesgos que condicionan el cierre; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Aterrizar criterios de aceptacion verificables para analisis, construccion, pruebas y entrega; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-003 (Confirmar alcance de Movilidad Interna): documento de alcance, lista de incluidos/excluidos, supuestos, criterios de aceptacion y aprobacion funcional/tecnica. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-003 solo si "Confirmar alcance de Movilidad Interna" produce documento de alcance con incluidos, excluidos, supuestos, dependencias, criterios de aceptacion y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando RMI queda delimitado y no se confunde con canalizaciones migratorias o movimientos externos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional
Riesgos y controles: Alcance ambiguo que provoque retrabajo, expectativas no aprobadas o cierre condicionado del entregable. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-003 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Coordinadora técnica puede coordinar la revision de Registro de Movilidad Interna, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-003 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-003 (Confirmar alcance de Movilidad Interna): documento de alcance, lista de incluidos/excluidos, supuestos, criterios de aceptacion y aprobacion funcional/tecnica. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-003 solo si "Confirmar alcance de Movilidad Interna" produce documento de alcance con incluidos, excluidos, supuestos, dependencias, criterios de aceptacion y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando RMI queda delimitado y no se confunde con canalizaciones migratorias o movimientos externos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Alcance ambiguo que provoque retrabajo, expectativas no aprobadas o cierre condicionado del entregable. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-INM-001 - Enlace técnico y funcional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-003 | Alcance | Revisar objetivo del componente Registro de Movilidad Interna y su relacion con Expediente Unico NNA e interoperabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-003 | Analisis | Definir que procesos, datos, reportes e integraciones quedan incluidos en el alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-003 | Construccion | Documentar exclusiones, supuestos, restricciones institucionales y criterios para cambios futuros; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-003 | Evidencia | Identificar dependencias externas, responsables de aprobacion y riesgos que condicionan el cierre; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-003 | Validacion | Aterrizar criterios de aceptacion verificables para analisis, construccion, pruebas y entrega; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-003 | Dependencias | Validar que el alcance no prometa conexion real cuando solo exista mock o documentacion pendiente; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-003 | Seguridad | Obtener revision funcional y tecnica sobre el alcance acordado; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-003 | Cierre | Actualizar Perfex/PtD con decisiones, condiciones y pendientes del alcance; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-004 - Identificar responsables institucionales
Responsable: Coordinadora técnica | Disciplina: Coordinacion | Sistema/componente: Gobierno del Proyecto | Fechas: 2026-06-16 a 2026-06-18.
Descripcion detallada
PYD-004 - Identificar responsables institucionales
Objetivo PM: identificar quien decide, quien opera, quien valida, quien autoriza accesos y quien escala bloqueos durante el proyecto.
Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta Gobierno del Proyecto, queda a cargo de Coordinadora técnica y esta planeada del 2026-06-16 al 2026-06-18. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: la matriz debe distinguir responsables funcionales, tecnicos, suplentes y aprobadores, con relacion directa a entregables e integraciones. Actividades principales del checklist: Listar instituciones, areas y responsables que participan en decisiones, validaciones o entregas; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Separar responsable funcional, responsable tecnico, suplente, aprobador y ruta de escalamiento; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Registrar datos de contacto operativos sin incluir secretos ni credenciales; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Identificar quien autoriza cambios de alcance, accesos, datos, integraciones y evidencia contractual; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Relacionar cada responsable con hitos, entregables o dependencias concretas; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-004 (Identificar responsables institucionales): matriz de responsables institucionales con contacto funcional, tecnico, suplente y ruta de escalamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-004 solo si "Identificar responsables institucionales" produce matriz de responsables institucionales con contacto funcional, tecnico, suplente y ruta de escalamiento; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando no quedan actividades criticas sin responsable unico de cierre. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-RDVF-001 - Responsable tecnico; DEP-RMP-001 - Responsable tecnico; DEP-RNCAS-001 - Responsable tecnico
Riesgos y controles: Riesgo de cerrar Identificar responsables institucionales sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-RDVF-001 - Responsable tecnico; DEP-RMP-001 - Responsable tecnico; DEP-RNCAS-001 - Responsable tecnico. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-004 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-RDVF-001 - Responsable tecnico; DEP-RMP-001 - Responsable tecnico; DEP-RNCAS-001 - Responsable tecnico. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Coordinadora técnica puede coordinar la revision de Gobierno del Proyecto, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-004 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-004 (Identificar responsables institucionales): matriz de responsables institucionales con contacto funcional, tecnico, suplente y ruta de escalamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-004 solo si "Identificar responsables institucionales" produce matriz de responsables institucionales con contacto funcional, tecnico, suplente y ruta de escalamiento; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando no quedan actividades criticas sin responsable unico de cierre. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Identificar responsables institucionales sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-RDVF-001 - Responsable tecnico; DEP-RMP-001 - Responsable tecnico; DEP-RNCAS-001 - Responsable tecnico. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-004 | Alcance | Listar instituciones, areas y responsables que participan en decisiones, validaciones o entregas; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-004 | Analisis | Separar responsable funcional, responsable tecnico, suplente, aprobador y ruta de escalamiento; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-004 | Construccion | Registrar datos de contacto operativos sin incluir secretos ni credenciales; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-004 | Evidencia | Identificar quien autoriza cambios de alcance, accesos, datos, integraciones y evidencia contractual; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-004 | Validacion | Relacionar cada responsable con hitos, entregables o dependencias concretas; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-004 | Dependencias | Validar la matriz con coordinacion y corregir vacios de responsabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-004 | Seguridad | Publicar la version controlada en Perfex/PtD o repositorio documental autorizado; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-004 | Cierre | Registrar fecha de revision y siguiente actualizacion programada; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-005 - Solicitar repositorio e infraestructura
Responsable: DevOps | Disciplina: DevOps | Sistema/componente: Infraestructura DTI | Fechas: 2026-06-16 a 2026-06-18.
Descripcion detallada
PYD-005 - Solicitar repositorio e infraestructura
Objetivo PM: habilitar repositorios, ambientes y accesos minimos para construir con trazabilidad y sin depender de archivos sueltos o credenciales compartidas.
Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta Infraestructura DTI, queda a cargo de DevOps y esta planeada del 2026-06-16 al 2026-06-18. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: la solicitud debe cubrir ramas, permisos, variables, politicas de PR, ambientes y prueba basica de despliegue o ejecucion. Actividades principales del checklist: Formalizar solicitud de repositorio backend/frontend, ambientes y accesos requeridos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Especificar ramas, politicas de PR, revisores, proteccion de rama y nomenclatura de versiones; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Solicitar infraestructura minima para desarrollo, QA y pruebas de integracion; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Confirmar mecanismos seguros para variables de entorno y secretos fuera del repositorio; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Registrar usuarios autorizados, permisos y vigencia de accesos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-005 (Solicitar repositorio e infraestructura): solicitud formal de repositorios, ambientes, accesos, ramas, permisos y evidencias de habilitacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-005 solo si "Solicitar repositorio e infraestructura" produce solicitud formal de repositorios, ambientes, accesos, ramas, permisos y evidencias de habilitacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia de acceso y ejecucion de un artefacto minimo en el ambiente acordado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva
Riesgos y controles: Riesgo de cerrar Solicitar repositorio e infraestructura sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-005 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que DevOps puede coordinar la revision de Infraestructura DTI, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-005 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-005 (Solicitar repositorio e infraestructura): solicitud formal de repositorios, ambientes, accesos, ramas, permisos y evidencias de habilitacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-005 solo si "Solicitar repositorio e infraestructura" produce solicitud formal de repositorios, ambientes, accesos, ramas, permisos y evidencias de habilitacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia de acceso y ejecucion de un artefacto minimo en el ambiente acordado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Solicitar repositorio e infraestructura sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-005 | Alcance | Formalizar solicitud de repositorio backend/frontend, ambientes y accesos requeridos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-005 | Analisis | Especificar ramas, politicas de PR, revisores, proteccion de rama y nomenclatura de versiones; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-005 | Construccion | Solicitar infraestructura minima para desarrollo, QA y pruebas de integracion; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-005 | Evidencia | Confirmar mecanismos seguros para variables de entorno y secretos fuera del repositorio; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-005 | Validacion | Registrar usuarios autorizados, permisos y vigencia de accesos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-005 | Dependencias | Adjuntar acuse o evidencia de habilitacion de repositorio/ambiente; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-005 | Seguridad | Validar que el equipo puede clonar, ejecutar y desplegar un artefacto minimo; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-005 | Cierre | Actualizar dependencia DTI y semaforo del hito segun disponibilidad real; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-006 - Crear matriz RACI
Responsable: Coordinadora técnica | Disciplina: Coordinacion | Sistema/componente: Gobierno del Proyecto | Fechas: 2026-06-17 a 2026-06-19.
Descripcion detallada
PYD-006 - Crear matriz RACI
Objetivo PM: definir responsabilidad real por actividad y aprobacion, evitando que los cierres queden repartidos entre varias areas sin accountable.
Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta Gobierno del Proyecto, queda a cargo de Coordinadora técnica y esta planeada del 2026-06-17 al 2026-06-19. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: la matriz debe cubrir entregables, hitos, integraciones, QA, seguridad, datos, aprobaciones y escalamiento. Actividades principales del checklist: Listar actividades principales por entregable, hito, integracion, QA, seguridad y datos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Asignar Responsible, Accountable, Consulted e Informed sin duplicar aprobadores finales; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Resolver vacios donde no exista responsable unico de decision; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Validar segregacion de funciones en aprobaciones tecnicas, funcionales y de seguridad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Alinear RACI con responsables registrados en Perfex/PtD; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-006 (Crear matriz RACI): matriz RACI aprobada para entregables, hitos, integraciones, QA, seguridad y aprobaciones. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-006 solo si "Crear matriz RACI" produce matriz RACI aprobada para entregables, hitos, integraciones, QA, seguridad y aprobaciones; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando coordinacion acepta la RACI y se resuelven vacios de responsabilidad. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.
Riesgos y controles: Riesgo de cerrar Crear matriz RACI sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-006 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Coordinadora técnica puede coordinar la revision de Gobierno del Proyecto, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-006 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-006 (Crear matriz RACI): matriz RACI aprobada para entregables, hitos, integraciones, QA, seguridad y aprobaciones. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-006 solo si "Crear matriz RACI" produce matriz RACI aprobada para entregables, hitos, integraciones, QA, seguridad y aprobaciones; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando coordinacion acepta la RACI y se resuelven vacios de responsabilidad. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Crear matriz RACI sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-006 | Alcance | Listar actividades principales por entregable, hito, integracion, QA, seguridad y datos; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-006 | Analisis | Asignar Responsible, Accountable, Consulted e Informed sin duplicar aprobadores finales; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-006 | Construccion | Resolver vacios donde no exista responsable unico de decision; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-006 | Evidencia | Validar segregacion de funciones en aprobaciones tecnicas, funcionales y de seguridad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-006 | Validacion | Alinear RACI con responsables registrados en Perfex/PtD; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-006 | Dependencias | Documentar excepciones y acuerdos de escalamiento; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-006 | Seguridad | Obtener revision de coordinacion tecnica y aprobador funcional; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-006 | Cierre | Publicar matriz versionada y vincularla al Entregable 1; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-010 - Elaborar estrategia de interoperabilidad con mocks
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: Interoperabilidad Interna/Externa | Fechas: 2026-06-18 a 2026-06-22.
Descripcion detallada
PYD-010 - Elaborar estrategia de interoperabilidad con mocks
Objetivo PM: ordenar la interoperabilidad por estados verificables: contrato, mock, adaptador, conexion real, certificacion y produccion.
Alcance operativo: esta tarea pertenece a H01 - H01 - Arranque, gobierno y plan de trabajo, se vincula con PYD-E1 - Plan de trabajo, estrategia y gobierno del proyecto, impacta Interoperabilidad Interna/Externa, queda a cargo de Integraciones y esta planeada del 2026-06-18 al 2026-06-22. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: la estrategia debe indicar versionado OpenAPI/JSON, errores, reintentos, idempotencia, seguridad, auditoria y responsables externos. Actividades principales del checklist: Listar sistemas internos y externos: INM, COMAR, RDVF, RMP, RNCAS, RMH, RMI y Expediente Unico; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Definir que integraciones avanzan con mock, cuales requieren contrato y cuales requieren conexion real; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Establecer versionado de contratos OpenAPI/JSON, errores, reintentos y trazabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Definir seguridad: OAuth2/JWT, VPN, allowlist, certificados o condicion pendiente; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.; Crear criterio para no marcar certificacion si solo existe mock; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-010 (Elaborar estrategia de interoperabilidad con mocks): estrategia de interoperabilidad con mocks, contratos, adaptadores, seguridad, estados y certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-010 solo si "Elaborar estrategia de interoperabilidad con mocks" produce estrategia de interoperabilidad con mocks, contratos, adaptadores, seguridad, estados y certificacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando cada sistema tiene camino de avance y condicion formal si la contraparte no entrega accesos o contratos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado
Riesgos y controles: Riesgo de cerrar Elaborar estrategia de interoperabilidad con mocks sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-010 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de Interoperabilidad Interna/Externa, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-010 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-010 (Elaborar estrategia de interoperabilidad con mocks): estrategia de interoperabilidad con mocks, contratos, adaptadores, seguridad, estados y certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-010 solo si "Elaborar estrategia de interoperabilidad con mocks" produce estrategia de interoperabilidad con mocks, contratos, adaptadores, seguridad, estados y certificacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando cada sistema tiene camino de avance y condicion formal si la contraparte no entrega accesos o contratos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Elaborar estrategia de interoperabilidad con mocks sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-010 | Alcance | Listar sistemas internos y externos: INM, COMAR, RDVF, RMP, RNCAS, RMH, RMI y Expediente Unico; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-010 | Analisis | Definir que integraciones avanzan con mock, cuales requieren contrato y cuales requieren conexion real; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-010 | Construccion | Establecer versionado de contratos OpenAPI/JSON, errores, reintentos y trazabilidad; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-010 | Evidencia | Definir seguridad: OAuth2/JWT, VPN, allowlist, certificados o condicion pendiente; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-010 | Validacion | Crear criterio para no marcar certificacion si solo existe mock; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-010 | Dependencias | Definir bitacora de intercambio, correlation ID y evidencia de prueba; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-010 | Seguridad | Relacionar dependencias externas con tareas y fechas del plan; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
- PYD-010 | Cierre | Publicar estrategia y actualizar estados de integracion en PtD; debe dejar evidencia trazable al hito H01, responsable asignado y fecha de cierre.
PYD-020 - Taller de captura inicial del NNA
Responsable: Analista funcional | Disciplina: Coordinacion | Sistema/componente: PortusDerechos 2.0 | Fechas: 2026-06-30 a 2026-07-01.
Descripcion detallada
PYD-020 - Taller de captura inicial del NNA
Objetivo PM: levantar como se registra por primera vez un NNA: identidad, datos generales, documentos, fuente institucional, validaciones, duplicados y permisos de captura.
Alcance operativo: esta tarea pertenece a H02 - H02 - Levantamiento funcional y normativo, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta PortusDerechos 2.0, queda a cargo de Analista funcional y esta planeada del 2026-06-30 al 2026-07-01. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el taller debe producir flujo de captura, campos obligatorios/opcionales, excepciones, evidencias y preguntas que impactan modelo de datos o UX. Actividades principales del checklist: Preparar guion del taller y preguntas especificas para Expediente Unico NNA y captura inicial de identidad/datos generales; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Confirmar usuarios expertos, responsables funcionales y perfiles que operan el flujo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Levantar flujo actual paso a paso, incluyendo excepciones, documentos usados y decisiones manuales; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Identificar datos capturados, validaciones reales, puntos de dolor y riesgos operativos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Separar reglas obligatorias de preferencias de interfaz o reporteo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-020 (Taller de captura inicial del NNA): minuta de taller, flujo levantado, reglas operativas, preguntas abiertas, evidencias funcionales y acuerdos. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-020 solo si "Taller de captura inicial del NNA" produce minuta de taller con flujo actual, reglas operativas, pain points, decisiones y dudas por resolver; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el flujo puede transformarse en formulario, API, validaciones y casos de prueba. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.
Riesgos y controles: Riesgo de cerrar Taller de captura inicial del NNA sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-020 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Analista funcional puede coordinar la revision de Expediente Unico NNA y captura inicial de identidad/datos generales, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-020 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-020 (Taller de captura inicial del NNA): minuta de taller, flujo levantado, reglas operativas, preguntas abiertas, evidencias funcionales y acuerdos. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-020 solo si "Taller de captura inicial del NNA" produce minuta de taller con flujo actual, reglas operativas, pain points, decisiones y dudas por resolver; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el flujo puede transformarse en formulario, API, validaciones y casos de prueba. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Taller de captura inicial del NNA sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-020 | Alcance | Preparar guion del taller y preguntas especificas para Expediente Unico NNA y captura inicial de identidad/datos generales; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-020 | Analisis | Confirmar usuarios expertos, responsables funcionales y perfiles que operan el flujo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-020 | Construccion | Levantar flujo actual paso a paso, incluyendo excepciones, documentos usados y decisiones manuales; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-020 | Evidencia | Identificar datos capturados, validaciones reales, puntos de dolor y riesgos operativos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-020 | Validacion | Separar reglas obligatorias de preferencias de interfaz o reporteo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-020 | Dependencias | Registrar acuerdos, dudas abiertas, supuestos y evidencias entregadas durante el taller; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-020 | Seguridad | Traducir hallazgos a historias, reglas, catalogos o tareas tecnicas trazables; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-020 | Cierre | Validar minuta del taller con el responsable funcional antes de cerrar la tarea; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-024 - Definir roles y jerarquías
Responsable: Analista funcional | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-07-06 a 2026-07-08.
Descripcion detallada
PYD-024 - Definir roles y jerarquías
Objetivo PM: asegurar que cada perfil acceda solo a funciones, rutas, datos y acciones autorizadas.
Alcance operativo: esta tarea pertenece a H02 - H02 - Levantamiento funcional y normativo, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Acceso Unico Institucional, queda a cargo de Analista funcional y esta planeada del 2026-07-06 al 2026-07-08. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe mapear roles, permisos, rutas protegidas, acciones criticas, denegaciones y evidencia de auditoria. Actividades principales del checklist: Identificar perfiles de usuario reales y acciones que ejecutan en cada modulo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Definir jerarquia, permisos de consulta, captura, modificacion, autorizacion, exportacion y administracion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Marcar acciones criticas que requieren MFA, aprobacion adicional o auditoria reforzada; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Validar segregacion de funciones y conflictos de permisos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Alinear roles con RBAC tecnico y pantallas React; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-024 (Definir roles y jerarquías): matriz de roles, jerarquias, permisos, segregacion de funciones y acciones criticas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-024 solo si "Definir roles y jerarquías" produce matriz de roles, jerarquias, permisos, segregacion de funciones y acciones criticas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-003 - Roles y jerarquías
Riesgos y controles: Riesgo de cerrar Definir roles y jerarquías sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-003 - Roles y jerarquías. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-024 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-003 - Roles y jerarquías. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Analista funcional puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-024 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-024 (Definir roles y jerarquías): matriz de roles, jerarquias, permisos, segregacion de funciones y acciones criticas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-024 solo si "Definir roles y jerarquías" produce matriz de roles, jerarquias, permisos, segregacion de funciones y acciones criticas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Definir roles y jerarquías sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-003 - Roles y jerarquías. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-024 | Alcance | Identificar perfiles de usuario reales y acciones que ejecutan en cada modulo; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-024 | Analisis | Definir jerarquia, permisos de consulta, captura, modificacion, autorizacion, exportacion y administracion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-024 | Construccion | Marcar acciones criticas que requieren MFA, aprobacion adicional o auditoria reforzada; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-024 | Evidencia | Validar segregacion de funciones y conflictos de permisos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-024 | Validacion | Alinear roles con RBAC tecnico y pantallas React; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-024 | Dependencias | Definir datos sensibles que no deben mostrarse por perfil; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-024 | Seguridad | Revisar matriz con seguridad, DTI y responsable funcional; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-024 | Cierre | Registrar matriz aprobada y pendientes de implementacion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-026 - Solicitar documentación técnica de INM
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: INM | Fechas: 2026-06-18 a 2026-06-30.
Descripcion detallada
PYD-026 - Solicitar documentación técnica de INM
Objetivo PM: obtener documentacion, contratos, credenciales controladas, ambientes y responsables necesarios para integrar interoperabilidad con INM.
Alcance operativo: esta tarea pertenece a H02 - H02 - Levantamiento funcional y normativo, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta INM, queda a cargo de Integraciones y esta planeada del 2026-06-18 al 2026-06-30. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: la solicitud debe distinguir informacion tecnica, datos de prueba, ventanas de prueba, seguridad, certificacion y vigencia. Actividades principales del checklist: Preparar solicitud formal de documentacion tecnica para interoperabilidad con INM; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Especificar contratos API, modelos de datos, catalogos, errores, autenticacion y ambientes requeridos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Solicitar datos de prueba anonimizados, responsables tecnicos y ventana de soporte; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Registrar fecha de solicitud, fecha requerida y ruta de escalamiento; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Revisar documentacion recibida contra necesidades de diseño e integracion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-026 (Solicitar documentación técnica de INM): solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-026 solo si "Solicitar documentación técnica de INM" produce solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acuse, fecha compromiso o condicion formal registrada como dependencia. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios
Riesgos y controles: Riesgo de cerrar Solicitar documentación técnica de INM sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Si la institucion externa no entrega documentacion o accesos, el avance queda limitado a analisis, mock o condicion formal. Dependencias a vigilar: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de interoperabilidad con INM, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-026 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-026 (Solicitar documentación técnica de INM): solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-026 solo si "Solicitar documentación técnica de INM" produce solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acuse, fecha compromiso o condicion formal registrada como dependencia. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Solicitar documentación técnica de INM sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-026 | Alcance | Preparar solicitud formal de documentacion tecnica para interoperabilidad con INM; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-026 | Analisis | Especificar contratos API, modelos de datos, catalogos, errores, autenticacion y ambientes requeridos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-026 | Construccion | Solicitar datos de prueba anonimizados, responsables tecnicos y ventana de soporte; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-026 | Evidencia | Registrar fecha de solicitud, fecha requerida y ruta de escalamiento; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-026 | Validacion | Revisar documentacion recibida contra necesidades de diseño e integracion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-026 | Dependencias | Registrar brechas, dudas, riesgos y tareas que quedan condicionadas; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-026 | Seguridad | Actualizar dependencia externa y estado de integracion en PtD; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-026 | Cierre | Adjuntar acuse, minuta o evidencia documental autorizada; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-027 - Solicitar documentación técnica de COMAR
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: COMAR | Fechas: 2026-06-18 a 2026-06-30.
Descripcion detallada
PYD-027 - Solicitar documentación técnica de COMAR
Objetivo PM: obtener documentacion, contratos, credenciales controladas, ambientes y responsables necesarios para integrar interoperabilidad con COMAR.
Alcance operativo: esta tarea pertenece a H02 - H02 - Levantamiento funcional y normativo, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta COMAR, queda a cargo de Integraciones y esta planeada del 2026-06-18 al 2026-06-30. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: la solicitud debe distinguir informacion tecnica, datos de prueba, ventanas de prueba, seguridad, certificacion y vigencia. Actividades principales del checklist: Preparar solicitud formal de documentacion tecnica para interoperabilidad con COMAR; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Especificar contratos API, modelos de datos, catalogos, errores, autenticacion y ambientes requeridos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Solicitar datos de prueba anonimizados, responsables tecnicos y ventana de soporte; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Registrar fecha de solicitud, fecha requerida y ruta de escalamiento; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Revisar documentacion recibida contra necesidades de diseño e integracion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-027 (Solicitar documentación técnica de COMAR): solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-027 solo si "Solicitar documentación técnica de COMAR" produce solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acuse, fecha compromiso o condicion formal registrada como dependencia. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios
Riesgos y controles: Riesgo de cerrar Solicitar documentación técnica de COMAR sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Si la institucion externa no entrega documentacion o accesos, el avance queda limitado a analisis, mock o condicion formal. Dependencias a vigilar: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de interoperabilidad con COMAR, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-027 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-027 (Solicitar documentación técnica de COMAR): solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-027 solo si "Solicitar documentación técnica de COMAR" produce solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acuse, fecha compromiso o condicion formal registrada como dependencia. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Solicitar documentación técnica de COMAR sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-027 | Alcance | Preparar solicitud formal de documentacion tecnica para interoperabilidad con COMAR; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-027 | Analisis | Especificar contratos API, modelos de datos, catalogos, errores, autenticacion y ambientes requeridos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-027 | Construccion | Solicitar datos de prueba anonimizados, responsables tecnicos y ventana de soporte; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-027 | Evidencia | Registrar fecha de solicitud, fecha requerida y ruta de escalamiento; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-027 | Validacion | Revisar documentacion recibida contra necesidades de diseño e integracion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-027 | Dependencias | Registrar brechas, dudas, riesgos y tareas que quedan condicionadas; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-027 | Seguridad | Actualizar dependencia externa y estado de integracion en PtD; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-027 | Cierre | Adjuntar acuse, minuta o evidencia documental autorizada; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-028 - Solicitar modelos y contratos de RDVF, RMP y RNCAS
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: RDVF | Fechas: 2026-06-18 a 2026-06-30.
Descripcion detallada
PYD-028 - Solicitar modelos y contratos de RDVF, RMP y RNCAS
Objetivo PM: obtener documentacion, contratos, credenciales controladas, ambientes y responsables necesarios para integrar Registro del Derecho a Vivir en Familia.
Alcance operativo: esta tarea pertenece a H02 - H02 - Levantamiento funcional y normativo, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta RDVF, queda a cargo de Integraciones y esta planeada del 2026-06-18 al 2026-06-30. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: la solicitud debe distinguir informacion tecnica, datos de prueba, ventanas de prueba, seguridad, certificacion y vigencia. Actividades principales del checklist: Preparar solicitud formal de documentacion tecnica para Registro del Derecho a Vivir en Familia; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Especificar contratos API, modelos de datos, catalogos, errores, autenticacion y ambientes requeridos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Solicitar datos de prueba anonimizados, responsables tecnicos y ventana de soporte; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Registrar fecha de solicitud, fecha requerida y ruta de escalamiento; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.; Revisar documentacion recibida contra necesidades de diseño e integracion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-028 (Solicitar modelos y contratos de RDVF, RMP y RNCAS): solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-028 solo si "Solicitar modelos y contratos de RDVF, RMP y RNCAS" produce solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acuse, fecha compromiso o condicion formal registrada como dependencia. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-INM-003 - Contrato preliminar; DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad
Riesgos y controles: Riesgo de cerrar Solicitar modelos y contratos de RDVF, RMP y RNCAS sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-INM-003 - Contrato preliminar; DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Si la institucion externa no entrega documentacion o accesos, el avance queda limitado a analisis, mock o condicion formal. Dependencias a vigilar: DEP-INM-003 - Contrato preliminar; DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de Registro del Derecho a Vivir en Familia, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-028 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-028 (Solicitar modelos y contratos de RDVF, RMP y RNCAS): solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-028 solo si "Solicitar modelos y contratos de RDVF, RMP y RNCAS" produce solicitud y acuse de documentacion tecnica, contratos, credenciales, ambientes, datos de prueba y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acuse, fecha compromiso o condicion formal registrada como dependencia. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Solicitar modelos y contratos de RDVF, RMP y RNCAS sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-INM-003 - Contrato preliminar; DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-028 | Alcance | Preparar solicitud formal de documentacion tecnica para Registro del Derecho a Vivir en Familia; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-028 | Analisis | Especificar contratos API, modelos de datos, catalogos, errores, autenticacion y ambientes requeridos; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-028 | Construccion | Solicitar datos de prueba anonimizados, responsables tecnicos y ventana de soporte; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-028 | Evidencia | Registrar fecha de solicitud, fecha requerida y ruta de escalamiento; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-028 | Validacion | Revisar documentacion recibida contra necesidades de diseño e integracion; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-028 | Dependencias | Registrar brechas, dudas, riesgos y tareas que quedan condicionadas; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-028 | Seguridad | Actualizar dependencia externa y estado de integracion en PtD; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
- PYD-028 | Cierre | Adjuntar acuse, minuta o evidencia documental autorizada; debe dejar evidencia trazable al hito H02, responsable asignado y fecha de cierre.
PYD-030 - Definir requisitos de seguridad
Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-07-06 a 2026-07-10.
Descripcion detallada
PYD-030 - Definir requisitos de seguridad
Objetivo PM: definir requisitos medibles para Acceso Unico Institucional, con umbrales, metodo de verificacion y responsable de aceptacion.
Alcance operativo: esta tarea pertenece a H03 - H03 - Requerimientos no funcionales, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2026-07-06 al 2026-07-10. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: cada requisito debe poder probarse; se deben evitar frases aspiracionales sin metrica, ambiente o evidencia. Actividades principales del checklist: Definir requisito medible y ambito exacto para Definir requisitos de seguridad; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Establecer metrica, umbral, metodo de medicion y ambiente de prueba; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Identificar impacto en arquitectura, infraestructura, datos, seguridad y experiencia de usuario; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Definir casos de prueba y evidencia requerida para aceptar el requisito; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Registrar supuestos, restricciones y dependencias tecnicas; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-030 (Definir requisitos de seguridad): documento de requisitos no funcionales medibles, umbrales, metodos de prueba y responsables. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-030 solo si "Definir requisitos de seguridad" produce documento de requisitos no funcionales medibles, umbrales, metodos de prueba y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando QA y arquitectura pueden convertir los requisitos en pruebas o controles. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos
Riesgos y controles: Riesgo de cerrar Definir requisitos de seguridad sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-030 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-030 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-030 (Definir requisitos de seguridad): documento de requisitos no funcionales medibles, umbrales, metodos de prueba y responsables. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-030 solo si "Definir requisitos de seguridad" produce documento de requisitos no funcionales medibles, umbrales, metodos de prueba y responsables; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando QA y arquitectura pueden convertir los requisitos en pruebas o controles. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Definir requisitos de seguridad sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-030 | Alcance | Definir requisito medible y ambito exacto para Definir requisitos de seguridad; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-030 | Analisis | Establecer metrica, umbral, metodo de medicion y ambiente de prueba; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-030 | Construccion | Identificar impacto en arquitectura, infraestructura, datos, seguridad y experiencia de usuario; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-030 | Evidencia | Definir casos de prueba y evidencia requerida para aceptar el requisito; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-030 | Validacion | Registrar supuestos, restricciones y dependencias tecnicas; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-030 | Dependencias | Validar viabilidad con desarrollo, QA, seguridad y DTI; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-030 | Seguridad | Aprobar requisito con responsable tecnico y funcional; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-030 | Cierre | Actualizar trazabilidad con hitos y entregables del proyecto; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-031 - Definir auditoría y trazabilidad
Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-07-08 a 2026-07-13.
Descripcion detallada
PYD-031 - Definir auditoría y trazabilidad
Objetivo PM: evaluar seguridad con alcance autorizado, evidencia controlada y plan de remediacion accionable.
Alcance operativo: esta tarea pertenece a H03 - H03 - Requerimientos no funcionales, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2026-07-08 al 2026-07-13. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: la prueba debe cubrir roles, sesion, APIs, configuracion, datos sensibles y hallazgos clasificados por severidad. Actividades principales del checklist: Definir alcance exacto de seguridad para Definir auditoría y trazabilidad: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-031 (Definir auditoría y trazabilidad): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-031 solo si "Definir auditoría y trazabilidad" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte, plan de remediacion, retest o excepcion formal aprobada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos
Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-031 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-031 (Definir auditoría y trazabilidad): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-031 solo si "Definir auditoría y trazabilidad" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte, plan de remediacion, retest o excepcion formal aprobada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-031 | Alcance | Definir alcance exacto de seguridad para Definir auditoría y trazabilidad: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-031 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-031 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-031 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-031 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-031 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-031 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
- PYD-031 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H03, responsable asignado y fecha de cierre.
PYD-032 - Diseñar C4 Contexto
Responsable: Integraciones | Disciplina: Arquitectura | Sistema/componente: Arquitectura Institucional | Fechas: 2026-07-08 a 2026-07-10.
Descripcion detallada
PYD-032 - Diseñar C4 Contexto
Objetivo PM: representar el ecosistema institucional de PortusDerechos 2.0: usuarios, registros, servicios transversales, INM, COMAR y limites del sistema.
Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Arquitectura Institucional, queda a cargo de Integraciones y esta planeada del 2026-07-08 al 2026-07-10. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el diagrama debe mostrar actores, sistemas externos, fronteras, responsabilidades de datos y relaciones de confianza. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar C4 Contexto; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-032 (Diseñar C4 Contexto): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-032 solo si "Diseñar C4 Contexto" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el contexto explica quien usa, quien provee datos y que queda fuera del sistema. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional
Riesgos y controles: Riesgo de cerrar Diseñar C4 Contexto sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-032 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de arquitectura C4 de contexto institucional, actores, registros y sistemas externos, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-032 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-032 (Diseñar C4 Contexto): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-032 solo si "Diseñar C4 Contexto" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el contexto explica quien usa, quien provee datos y que queda fuera del sistema. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Diseñar C4 Contexto sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-032 | Alcance | Definir alcance del artefacto de diseno para Diseñar C4 Contexto; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-032 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-032 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-032 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-032 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-032 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-032 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-032 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-033 - Diseñar C4 Contenedores
Responsable: Integraciones | Disciplina: Arquitectura | Sistema/componente: Arquitectura Tecnica | Fechas: 2026-07-10 a 2026-07-14.
Descripcion detallada
PYD-033 - Diseñar C4 Contenedores
Objetivo PM: definir contenedores logicos y tecnologicos: frontend React, API Gateway/FastAPI, servicios, PostgreSQL, mensajeria, documentos, seguridad y observabilidad.
Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Arquitectura Tecnica, queda a cargo de Integraciones y esta planeada del 2026-07-10 al 2026-07-14. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el diseno debe aterrizar responsabilidades, protocolos, despliegue, dependencias y puntos de fallo por contenedor. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar C4 Contenedores; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-033 (Diseñar C4 Contenedores): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-033 solo si "Diseñar C4 Contenedores" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando cada contenedor tiene proposito, contrato y relacion clara con el modelo operativo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional
Riesgos y controles: Riesgo de cerrar Diseñar C4 Contenedores sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-033 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de contenedores backend, frontend, datos, integraciones y servicios transversales, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-033 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-033 (Diseñar C4 Contenedores): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-033 solo si "Diseñar C4 Contenedores" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando cada contenedor tiene proposito, contrato y relacion clara con el modelo operativo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Diseñar C4 Contenedores sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-033 | Alcance | Definir alcance del artefacto de diseno para Diseñar C4 Contenedores; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-033 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-033 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-033 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-033 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-033 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-033 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-033 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-034 - Diseñar componentes FastAPI
Responsable: Backend 1 | Disciplina: Backend/Arquitectura | Sistema/componente: FastAPI / API Gateway | Fechas: 2026-07-10 a 2026-07-15.
Descripcion detallada
PYD-034 - Diseñar componentes FastAPI
Objetivo PM: definir o preparar la base FastAPI para servicios de Expediente, RMH, RMI, interoperabilidad, seguridad y observabilidad.
Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta FastAPI / API Gateway, queda a cargo de Backend 1 y esta planeada del 2026-07-10 al 2026-07-15. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe quedar estructura de routers, dependencias, validaciones Pydantic, errores, OpenAPI, configuracion y pruebas base. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar componentes FastAPI; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-034 (Diseñar componentes FastAPI): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-034 solo si "Diseñar componentes FastAPI" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el servicio arranca, publica contrato y soporta pruebas automatizadas iniciales. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional
Riesgos y controles: Riesgo de cerrar Diseñar componentes FastAPI sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-034 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de FastAPI / API Gateway, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-034 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-034 (Diseñar componentes FastAPI): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-034 solo si "Diseñar componentes FastAPI" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el servicio arranca, publica contrato y soporta pruebas automatizadas iniciales. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Diseñar componentes FastAPI sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-034 | Alcance | Definir alcance del artefacto de diseno para Diseñar componentes FastAPI; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-034 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-034 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-034 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-034 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-034 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-034 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-034 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-035 - Diseñar arquitectura React
Responsable: Frontend 1 | Disciplina: Frontend | Sistema/componente: Frontend React / UI Operativa | Fechas: 2026-07-10 a 2026-07-15.
Descripcion detallada
PYD-035 - Diseñar arquitectura React
Objetivo PM: definir o preparar la base React 19 para una operacion institucional: rutas, layout, formularios, bandejas, permisos y componentes reutilizables.
Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Frontend React / UI Operativa, queda a cargo de Frontend 1 y esta planeada del 2026-07-10 al 2026-07-15. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe quedar estructura Vite/PNPM, convenciones de componentes, manejo de estado, servicios API, errores y pruebas frontend. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar arquitectura React; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-035 (Diseñar arquitectura React): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-035 solo si "Diseñar arquitectura React" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el frontend corre, consume configuracion y permite extender flujos sin rehacer arquitectura. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional
Riesgos y controles: Riesgo de cerrar Diseñar arquitectura React sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-035 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Frontend 1 puede coordinar la revision de Frontend React 19, rutas, estado, componentes y UX operativa, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-035 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-035 (Diseñar arquitectura React): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-035 solo si "Diseñar arquitectura React" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el frontend corre, consume configuracion y permite extender flujos sin rehacer arquitectura. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Diseñar arquitectura React sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-035 | Alcance | Definir alcance del artefacto de diseno para Diseñar arquitectura React; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-035 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-035 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-035 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-035 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-035 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-035 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-035 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-036 - Diseñar ERD PostgreSQL
Responsable: Datos | Disciplina: Datos | Sistema/componente: PostgreSQL / Gobierno de Datos | Fechas: 2026-07-08 a 2026-07-15.
Descripcion detallada
PYD-036 - Diseñar ERD PostgreSQL
Objetivo PM: aterrizar entidades, relaciones, catalogos, constraints y linaje de datos para Expediente, RMH, RMI e interoperabilidad.
Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta PostgreSQL / Gobierno de Datos, queda a cargo de Datos y esta planeada del 2026-07-08 al 2026-07-15. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el artefacto debe cubrir llaves, cardinalidades, historiales, auditoria, campos sensibles, indices y reglas de calidad. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar ERD PostgreSQL; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-036 (Diseñar ERD PostgreSQL): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-036 solo si "Diseñar ERD PostgreSQL" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando desarrollo, migracion y reportes pueden usar el modelo sin reinterpretar campos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos
Riesgos y controles: Riesgo de cerrar Diseñar ERD PostgreSQL sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-036 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Datos puede coordinar la revision de modelo relacional PostgreSQL para Expediente, RMH, RMI e interoperabilidad, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-036 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-036 (Diseñar ERD PostgreSQL): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-036 solo si "Diseñar ERD PostgreSQL" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando desarrollo, migracion y reportes pueden usar el modelo sin reinterpretar campos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Diseñar ERD PostgreSQL sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-036 | Alcance | Definir alcance del artefacto de diseno para Diseñar ERD PostgreSQL; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-036 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-036 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-036 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-036 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-036 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-036 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-036 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-037 - Elaborar diccionario de datos
Responsable: Datos | Disciplina: Datos | Sistema/componente: Gobierno de Datos | Fechas: 2026-07-10 a 2026-07-17.
Descripcion detallada
PYD-037 - Elaborar diccionario de datos
Objetivo PM: aterrizar entidades, relaciones, catalogos, constraints y linaje de datos para Expediente, RMH, RMI e interoperabilidad.
Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Gobierno de Datos, queda a cargo de Datos y esta planeada del 2026-07-10 al 2026-07-17. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el artefacto debe cubrir llaves, cardinalidades, historiales, auditoria, campos sensibles, indices y reglas de calidad. Actividades principales del checklist: Definir alcance del artefacto de diseno para Elaborar diccionario de datos; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-037 (Elaborar diccionario de datos): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-037 solo si "Elaborar diccionario de datos" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando desarrollo, migracion y reportes pueden usar el modelo sin reinterpretar campos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos
Riesgos y controles: Riesgo de cerrar Elaborar diccionario de datos sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-037 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Datos puede coordinar la revision de Gobierno de Datos, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-037 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-037 (Elaborar diccionario de datos): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-037 solo si "Elaborar diccionario de datos" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando desarrollo, migracion y reportes pueden usar el modelo sin reinterpretar campos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Elaborar diccionario de datos sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-037 | Alcance | Definir alcance del artefacto de diseno para Elaborar diccionario de datos; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-037 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-037 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-037 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-037 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-037 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-037 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-037 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-038 - Diseñar modelo canónico de interoperabilidad
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: Interoperabilidad Interna/Externa | Fechas: 2026-07-10 a 2026-07-17.
Descripcion detallada
PYD-038 - Diseñar modelo canónico de interoperabilidad
Objetivo PM: definir el formato comun de intercambio entre Expediente, RMH, RMI, RDVF, RMP, RNCAS, INM y COMAR.
Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Interoperabilidad Interna/Externa, queda a cargo de Integraciones y esta planeada del 2026-07-10 al 2026-07-17. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe precisar identificadores, eventos, catalogos, payloads, versiones, errores, idempotencia y trazabilidad. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar modelo canónico de interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-038 (Diseñar modelo canónico de interoperabilidad): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-038 solo si "Diseñar modelo canónico de interoperabilidad" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los mocks/adaptadores pueden mapear sus datos al contrato comun. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos
Riesgos y controles: Riesgo de cerrar Diseñar modelo canónico de interoperabilidad sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-038 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de Interoperabilidad Interna/Externa, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-038 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-038 (Diseñar modelo canónico de interoperabilidad): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-038 solo si "Diseñar modelo canónico de interoperabilidad" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los mocks/adaptadores pueden mapear sus datos al contrato comun. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Diseñar modelo canónico de interoperabilidad sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-038 | Alcance | Definir alcance del artefacto de diseno para Diseñar modelo canónico de interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-038 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-038 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-038 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-038 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-038 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-038 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-038 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-039 - Diseñar estrategia de migración
Responsable: Datos | Disciplina: Datos | Sistema/componente: Gobierno de Datos | Fechas: 2026-07-13 a 2026-07-17.
Descripcion detallada
PYD-039 - Diseñar estrategia de migración
Objetivo PM: preparar migracion con reglas de extraccion, limpieza, transformacion, conciliacion, rechazo y rollback.
Alcance operativo: esta tarea pertenece a H04 - H04 - Arquitectura C4 y modelo de datos preliminar, se vincula con PYD-E2 - Analisis, arquitectura y diseno funcional/API First, impacta Gobierno de Datos, queda a cargo de Datos y esta planeada del 2026-07-13 al 2026-07-17. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el trabajo debe producir totales, reglas de calidad, bitacora, muestras, diferencias explicadas y dependencias de datos fuente. Actividades principales del checklist: Definir alcance del artefacto de diseno para Diseñar estrategia de migración; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-039 (Diseñar estrategia de migración): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-039 solo si "Diseñar estrategia de migración" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los datos pueden ensayarse y conciliase sin poner en riesgo informacion real. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos
Riesgos y controles: Riesgo de cerrar Diseñar estrategia de migración sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-039 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Datos puede coordinar la revision de Gobierno de Datos, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-039 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-039 (Diseñar estrategia de migración): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-039 solo si "Diseñar estrategia de migración" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los datos pueden ensayarse y conciliase sin poner en riesgo informacion real. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Diseñar estrategia de migración sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-039 | Alcance | Definir alcance del artefacto de diseno para Diseñar estrategia de migración; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-039 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-039 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-039 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-039 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-039 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-039 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
- PYD-039 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H04, responsable asignado y fecha de cierre.
PYD-060 - Implementar búsqueda de NNA
Responsable: Backend 1 | Disciplina: Backend | Sistema/componente: Expediente Unico NNA | Fechas: 2026-08-10 a 2026-08-14.
Descripcion detallada
PYD-060 - Implementar búsqueda de NNA
Objetivo PM: implementar busqueda de expedientes NNA con criterios permitidos, filtros, permisos, auditoria y prevencion de duplicados.
Alcance operativo: esta tarea pertenece a H06 - H06 - Expediente unico, autenticacion y seguridad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Expediente Unico NNA, queda a cargo de Backend 1 y esta planeada del 2026-08-10 al 2026-08-14. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe considerar nombre, CURP o identificadores permitidos, paginacion, resultados parciales, seguridad y bitacora de consulta. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar búsqueda de NNA en Expediente Unico NNA, busqueda, filtros, permisos y auditoria; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-060 (Implementar búsqueda de NNA): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-060 solo si "Implementar búsqueda de NNA" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con casos de busqueda exacta, parcial, sin resultados, permisos insuficientes y auditoria registrada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo
Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de Expediente Unico NNA, busqueda, filtros, permisos y auditoria, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-060 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-060 (Implementar búsqueda de NNA): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-060 solo si "Implementar búsqueda de NNA" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con casos de busqueda exacta, parcial, sin resultados, permisos insuficientes y auditoria registrada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-060 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar búsqueda de NNA en Expediente Unico NNA, busqueda, filtros, permisos y auditoria; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-060 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-060 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-060 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-060 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-060 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-060 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-060 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-061 - Implementar alta de expediente
Responsable: Backend 2 | Disciplina: Backend | Sistema/componente: Expediente Unico NNA | Fechas: 2026-08-10 a 2026-08-17.
Descripcion detallada
PYD-061 - Implementar alta de expediente
Objetivo PM: implementar Implementar alta de expediente dentro de Expediente Unico NNA con comportamiento claro, validaciones, permisos, auditoria y pruebas.
Alcance operativo: esta tarea pertenece a H06 - H06 - Expediente unico, autenticacion y seguridad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Expediente Unico NNA, queda a cargo de Backend 2 y esta planeada del 2026-08-10 al 2026-08-17. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el desarrollo debe cubrir backend, frontend, modelo, contrato o servicio impactado, con manejo de errores y datos limite. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar alta de expediente en Expediente Unico NNA; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-061 (Implementar alta de expediente): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-061 solo si "Implementar alta de expediente" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia funcional, pruebas, trazabilidad de cambio y actualizacion de contrato o documentacion si aplica. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo
Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 2 puede coordinar la revision de Expediente Unico NNA, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-061 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-061 (Implementar alta de expediente): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-061 solo si "Implementar alta de expediente" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia funcional, pruebas, trazabilidad de cambio y actualizacion de contrato o documentacion si aplica. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-061 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar alta de expediente en Expediente Unico NNA; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-061 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-061 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-061 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-061 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-061 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-061 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-061 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-063 - Implementar JWT/OAuth2 simulado o real
Responsable: Backend 1 | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-08-10 a 2026-08-18.
Descripcion detallada
PYD-063 - Implementar JWT/OAuth2 simulado o real
Objetivo PM: habilitar autenticacion institucional mediante OAuth2/JWT real o simulado de forma controlada para desarrollo y QA.
Alcance operativo: esta tarea pertenece a H06 - H06 - Expediente unico, autenticacion y seguridad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Acceso Unico Institucional, queda a cargo de Backend 1 y esta planeada del 2026-08-10 al 2026-08-18. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe cubrir emision/validacion de token, expiracion, refresh si aplica, claims, errores y configuracion segura. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar JWT/OAuth2 simulado o real en Acceso Unico Institucional con OAuth2/JWT, sesiones y tokens; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-063 (Implementar JWT/OAuth2 simulado o real): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-063 solo si "Implementar JWT/OAuth2 simulado o real" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acceso permitido, token invalido, expirado, rol insuficiente y auditoria de sesion. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-DTI-007 - Acceso a datos históricos; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RMP-004 - Fecha real de disponibilidad
Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-DTI-007 - Acceso a datos históricos; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RMP-004 - Fecha real de disponibilidad. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-DTI-007 - Acceso a datos históricos; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RMP-004 - Fecha real de disponibilidad. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de Acceso Unico Institucional con OAuth2/JWT, sesiones y tokens, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-063 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-063 (Implementar JWT/OAuth2 simulado o real): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-063 solo si "Implementar JWT/OAuth2 simulado o real" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acceso permitido, token invalido, expirado, rol insuficiente y auditoria de sesion. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-DTI-007 - Acceso a datos históricos; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RMP-004 - Fecha real de disponibilidad. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-063 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar JWT/OAuth2 simulado o real en Acceso Unico Institucional con OAuth2/JWT, sesiones y tokens; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-063 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-063 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-063 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-063 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-063 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-063 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-063 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-064 - Implementar RBAC base
Responsable: Backend 1 | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-08-14 a 2026-08-20.
Descripcion detallada
PYD-064 - Implementar RBAC base
Objetivo PM: asegurar que cada perfil acceda solo a funciones, rutas, datos y acciones autorizadas.
Alcance operativo: esta tarea pertenece a H06 - H06 - Expediente unico, autenticacion y seguridad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Acceso Unico Institucional, queda a cargo de Backend 1 y esta planeada del 2026-08-14 al 2026-08-20. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe mapear roles, permisos, rutas protegidas, acciones criticas, denegaciones y evidencia de auditoria. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar RBAC base en Acceso Unico Institucional; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-064 (Implementar RBAC base): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-064 solo si "Implementar RBAC base" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos
Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-064 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-064 (Implementar RBAC base): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-064 solo si "Implementar RBAC base" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-064 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar RBAC base en Acceso Unico Institucional; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-064 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-064 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-064 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-064 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-064 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-064 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-064 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-065 - Implementar protección de rutas React
Responsable: Frontend 1 | Disciplina: Frontend/Seguridad | Sistema/componente: Frontend React / UI Operativa | Fechas: 2026-08-17 a 2026-08-20.
Descripcion detallada
PYD-065 - Implementar protección de rutas React
Objetivo PM: asegurar que cada perfil acceda solo a funciones, rutas, datos y acciones autorizadas.
Alcance operativo: esta tarea pertenece a H06 - H06 - Expediente unico, autenticacion y seguridad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Frontend React / UI Operativa, queda a cargo de Frontend 1 y esta planeada del 2026-08-17 al 2026-08-20. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe mapear roles, permisos, rutas protegidas, acciones criticas, denegaciones y evidencia de auditoria. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar protección de rutas React en proteccion de rutas React integrada con RBAC y sesion institucional; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-065 (Implementar protección de rutas React): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-065 solo si "Implementar protección de rutas React" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.
Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Frontend 1 puede coordinar la revision de proteccion de rutas React integrada con RBAC y sesion institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-065 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-065 (Implementar protección de rutas React): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-065 solo si "Implementar protección de rutas React" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-065 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar protección de rutas React en proteccion de rutas React integrada con RBAC y sesion institucional; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-065 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-065 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-065 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-065 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-065 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-065 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-065 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-066 - Implementar auditoría inicial
Responsable: Backend 2 | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-08-17 a 2026-08-21.
Descripcion detallada
PYD-066 - Implementar auditoría inicial
Objetivo PM: implementar Implementar auditoría inicial dentro de Acceso Unico Institucional con comportamiento claro, validaciones, permisos, auditoria y pruebas.
Alcance operativo: esta tarea pertenece a H06 - H06 - Expediente unico, autenticacion y seguridad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Acceso Unico Institucional, queda a cargo de Backend 2 y esta planeada del 2026-08-17 al 2026-08-21. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el desarrollo debe cubrir backend, frontend, modelo, contrato o servicio impactado, con manejo de errores y datos limite. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Implementar auditoría inicial en Acceso Unico Institucional; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-066 (Implementar auditoría inicial): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-066 solo si "Implementar auditoría inicial" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia funcional, pruebas, trazabilidad de cambio y actualizacion de contrato o documentacion si aplica. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos
Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 2 puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-066 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-066 (Implementar auditoría inicial): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-066 solo si "Implementar auditoría inicial" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con evidencia funcional, pruebas, trazabilidad de cambio y actualizacion de contrato o documentacion si aplica. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-066 | Alcance | Confirmar historia o flujo operativo que resuelve Implementar auditoría inicial en Acceso Unico Institucional; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-066 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-066 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-066 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-066 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-066 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-066 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
- PYD-066 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H06, responsable asignado y fecha de cierre.
PYD-082 - Implementar modelo canónico
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: Interoperabilidad Interna/Externa | Fechas: 2026-09-07 a 2026-09-14.
Descripcion detallada
PYD-082 - Implementar modelo canónico
Objetivo PM: definir el formato comun de intercambio entre Expediente, RMH, RMI, RDVF, RMP, RNCAS, INM y COMAR.
Alcance operativo: esta tarea pertenece a H08 - H08 - Traslados e interoperabilidad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Interoperabilidad Interna/Externa, queda a cargo de Integraciones y esta planeada del 2026-09-07 al 2026-09-14. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe precisar identificadores, eventos, catalogos, payloads, versiones, errores, idempotencia y trazabilidad. Actividades principales del checklist: Definir alcance del artefacto de diseno para Implementar modelo canónico; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-082 (Implementar modelo canónico): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-082 solo si "Implementar modelo canónico" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los mocks/adaptadores pueden mapear sus datos al contrato comun. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos
Riesgos y controles: Riesgo de cerrar Implementar modelo canónico sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-082 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de modelo canonico de interoperabilidad para registros internos y externos, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-082 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-082 (Implementar modelo canónico): artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-082 solo si "Implementar modelo canónico" produce artefacto de diseno revisado: diagrama, modelo, contrato, decisiones ADR y trazabilidad con tareas; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los mocks/adaptadores pueden mapear sus datos al contrato comun. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Implementar modelo canónico sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-RDVF-002 - Modelo de datos; DEP-RMP-002 - Modelo de datos; DEP-RNCAS-002 - Modelo de datos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-082 | Alcance | Definir alcance del artefacto de diseno para Implementar modelo canónico; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-082 | Analisis | Levantar decisiones arquitectonicas, restricciones, dependencias y alternativas descartadas; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-082 | Construccion | Representar componentes, datos, contratos, flujos o relaciones segun corresponda; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-082 | Evidencia | Validar consistencia con RMH, RMI, Expediente Unico, seguridad e interoperabilidad; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-082 | Validacion | Identificar cambios requeridos en APIs, modelo de datos, frontend, infraestructura o QA; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-082 | Dependencias | Registrar riesgos tecnicos y decisiones ADR cuando aplique; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-082 | Seguridad | Revisar el artefacto con arquitectura, desarrollo y QA; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-082 | Cierre | Publicar version aprobada y vincularla al entregable correspondiente; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
PYD-083 - Construir mock INM
Responsable: Backend 2 | Disciplina: Integraciones | Sistema/componente: INM | Fechas: 2026-09-09 a 2026-09-16.
Descripcion detallada
PYD-083 - Construir mock INM
Objetivo PM: construir mock contractual para interoperabilidad con INM, permitiendo probar flujos sin depender de disponibilidad institucional real.
Alcance operativo: esta tarea pertenece a H08 - H08 - Traslados e interoperabilidad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta INM, queda a cargo de Backend 2 y esta planeada del 2026-09-09 al 2026-09-16. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el mock debe exponer payloads representativos, errores, latencia controlada, versionado y datos de prueba documentados. Actividades principales del checklist: Confirmar alcance de integracion para interoperabilidad con INM: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-083 (Construir mock INM): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-083 solo si "Construir mock INM" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador consume el mock y reproduce casos exitosos y fallidos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de interoperabilidad con INM no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Dependencias a vigilar: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 2 puede coordinar la revision de interoperabilidad con INM, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-083 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-083 (Construir mock INM): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-083 solo si "Construir mock INM" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador consume el mock y reproduce casos exitosos y fallidos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-083 | Alcance | Confirmar alcance de integracion para interoperabilidad con INM: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-083 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-083 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-083 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-083 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-083 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-083 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-083 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
PYD-084 - Construir mock COMAR
Responsable: Backend 2 | Disciplina: Integraciones | Sistema/componente: COMAR | Fechas: 2026-09-09 a 2026-09-16.
Descripcion detallada
PYD-084 - Construir mock COMAR
Objetivo PM: construir mock contractual para interoperabilidad con COMAR, permitiendo probar flujos sin depender de disponibilidad institucional real.
Alcance operativo: esta tarea pertenece a H08 - H08 - Traslados e interoperabilidad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta COMAR, queda a cargo de Backend 2 y esta planeada del 2026-09-09 al 2026-09-16. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el mock debe exponer payloads representativos, errores, latencia controlada, versionado y datos de prueba documentados. Actividades principales del checklist: Confirmar alcance de integracion para interoperabilidad con COMAR: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-084 (Construir mock COMAR): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-084 solo si "Construir mock COMAR" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador consume el mock y reproduce casos exitosos y fallidos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de interoperabilidad con COMAR no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Dependencias a vigilar: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 2 puede coordinar la revision de interoperabilidad con COMAR, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-084 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-084 (Construir mock COMAR): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-084 solo si "Construir mock COMAR" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador consume el mock y reproduce casos exitosos y fallidos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-RDVF-005 - Mock validado; DEP-RMP-005 - Mock validado; DEP-RNCAS-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-084 | Alcance | Confirmar alcance de integracion para interoperabilidad con COMAR: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-084 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-084 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-084 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-084 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-084 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-084 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-084 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
PYD-085 - Construir mocks RDVF, RMP y RNCAS
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: RDVF | Fechas: 2026-09-09 a 2026-09-17.
Descripcion detallada
PYD-085 - Construir mocks RDVF, RMP y RNCAS
Objetivo PM: construir mock contractual para Registro del Derecho a Vivir en Familia, permitiendo probar flujos sin depender de disponibilidad institucional real.
Alcance operativo: esta tarea pertenece a H08 - H08 - Traslados e interoperabilidad base, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta RDVF, queda a cargo de Integraciones y esta planeada del 2026-09-09 al 2026-09-17. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el mock debe exponer payloads representativos, errores, latencia controlada, versionado y datos de prueba documentados. Actividades principales del checklist: Confirmar alcance de integracion para Registro del Derecho a Vivir en Familia: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-085 (Construir mocks RDVF, RMP y RNCAS): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-085 solo si "Construir mocks RDVF, RMP y RNCAS" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador consume el mock y reproduce casos exitosos y fallidos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RDVF-005 - Mock validado
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RDVF-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de Registro del Derecho a Vivir en Familia no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Dependencias a vigilar: DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RDVF-005 - Mock validado. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de Registro del Derecho a Vivir en Familia, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-085 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-085 (Construir mocks RDVF, RMP y RNCAS): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-085 solo si "Construir mocks RDVF, RMP y RNCAS" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador consume el mock y reproduce casos exitosos y fallidos. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RDVF-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-085 | Alcance | Confirmar alcance de integracion para Registro del Derecho a Vivir en Familia: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-085 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-085 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-085 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-085 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-085 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-085 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
- PYD-085 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H08, responsable asignado y fecha de cierre.
PYD-090 - Bandeja principal de casos
Responsable: Frontend 1 | Disciplina: Backend | Sistema/componente: Expediente Unico NNA | Fechas: 2026-09-21 a 2026-09-28.
Descripcion detallada
PYD-090 - Bandeja principal de casos
Objetivo PM: habilitar bandejas operativas para localizar, priorizar y abrir casos con filtros utiles y rendimiento aceptable.
Alcance operativo: esta tarea pertenece a H09 - H09 - Bandejas, documentos y antiduplicados, se vincula con PYD-E3 - Construccion base del Registro de Movilidad Humana e interoperabilidad mock, impacta Expediente Unico NNA, queda a cargo de Frontend 1 y esta planeada del 2026-09-21 al 2026-09-28. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe cubrir columnas, filtros, paginacion, ordenamiento, permisos, estados vacios y tiempos de respuesta. Actividades principales del checklist: Confirmar historia o flujo operativo que resuelve Bandeja principal de casos en Expediente Unico NNA; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.; Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-090 (Bandeja principal de casos): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-090 solo si "Bandeja principal de casos" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con datos de prueba suficientes, filtros combinados, permisos y evidencia UX. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo; DEP-PF-005 - Casos de aceptación
Riesgos y controles: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-PF-005 - Casos de aceptación. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La funcionalidad no debe cerrarse como completa si faltan contrato, permisos, pruebas, auditoria o evidencia de error controlado. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo; DEP-PF-005 - Casos de aceptación. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Frontend 1 puede coordinar la revision de Expediente Unico NNA, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-090 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-090 (Bandeja principal de casos): capturas, pruebas, commit/PR, contrato actualizado si aplica y evidencia de funcionamiento. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-090 solo si "Bandeja principal de casos" produce funcionalidad implementada con pruebas, evidencia, trazabilidad, manejo de errores y criterios de aceptacion; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con datos de prueba suficientes, filtros combinados, permisos y evidencia UX. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Implementacion que resuelve el caso feliz pero omite permisos, auditoria, errores, datos limite o integracion. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-PF-005 - Casos de aceptación. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-090 | Alcance | Confirmar historia o flujo operativo que resuelve Bandeja principal de casos en Expediente Unico NNA; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
- PYD-090 | Analisis | Definir comportamiento esperado, validaciones, estados, mensajes y errores controlados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
- PYD-090 | Construccion | Implementar backend, frontend o servicio requerido con trazabilidad y auditoria cuando aplique; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
- PYD-090 | Evidencia | Actualizar contrato API, modelo de datos, permisos o componentes UI impactados; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
- PYD-090 | Validacion | Probar caso exitoso, caso negativo, permisos y datos limite; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
- PYD-090 | Dependencias | Verificar que no se registren secretos ni datos personales reales en logs o evidencias; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
- PYD-090 | Seguridad | Adjuntar evidencia funcional: captura, reporte de prueba, commit, PR o demo; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
- PYD-090 | Cierre | Actualizar estado, riesgos e integraciones relacionadas en PtD; debe dejar evidencia trazable al hito H09, responsable asignado y fecha de cierre.
PYD-120 - Conectar RDVF
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: RDVF | Fechas: 2026-11-02 a 2026-11-10.
Descripcion detallada
PYD-120 - Conectar RDVF
Objetivo PM: construir o habilitar la integracion de Registro del Derecho a Vivir en Familia con contrato, adaptador, seguridad, manejo de errores y trazabilidad.
Alcance operativo: esta tarea pertenece a H12 - H12 - Interoperabilidad interna real, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta RDVF, queda a cargo de Integraciones y esta planeada del 2026-11-02 al 2026-11-10. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe probar caso exitoso, errores controlados, timeout, reintento, equivalencias de catalogo y registro de auditoria. Actividades principales del checklist: Confirmar alcance de integracion para Registro del Derecho a Vivir en Familia: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-120 (Conectar RDVF): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-120 solo si "Conectar RDVF" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el estado queda claro: mock, adaptador, conexion real, certificacion o condicion formal. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RDVF-005 - Mock validado
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RDVF-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de Registro del Derecho a Vivir en Familia no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Dependencias a vigilar: DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RDVF-005 - Mock validado. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de Registro del Derecho a Vivir en Familia, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-120 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-120 (Conectar RDVF): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-120 solo si "Conectar RDVF" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el estado queda claro: mock, adaptador, conexion real, certificacion o condicion formal. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-RDVF-001 - Responsable tecnico; DEP-RDVF-002 - Modelo de datos; DEP-RDVF-003 - Contrato API; DEP-RDVF-004 - Fecha real de disponibilidad; DEP-RDVF-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-120 | Alcance | Confirmar alcance de integracion para Registro del Derecho a Vivir en Familia: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-120 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-120 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-120 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-120 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-120 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-120 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-120 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
PYD-121 - Conectar RMP
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: RMP | Fechas: 2026-11-02 a 2026-11-10.
Descripcion detallada
PYD-121 - Conectar RMP
Objetivo PM: construir o habilitar la integracion de Registro de Medidas de Proteccion con contrato, adaptador, seguridad, manejo de errores y trazabilidad.
Alcance operativo: esta tarea pertenece a H12 - H12 - Interoperabilidad interna real, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta RMP, queda a cargo de Integraciones y esta planeada del 2026-11-02 al 2026-11-10. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe probar caso exitoso, errores controlados, timeout, reintento, equivalencias de catalogo y registro de auditoria. Actividades principales del checklist: Confirmar alcance de integracion para Registro de Medidas de Proteccion: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-121 (Conectar RMP): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-121 solo si "Conectar RMP" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el estado queda claro: mock, adaptador, conexion real, certificacion o condicion formal. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de Registro de Medidas de Proteccion no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de Registro de Medidas de Proteccion, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-121 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-121 (Conectar RMP): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-121 solo si "Conectar RMP" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el estado queda claro: mock, adaptador, conexion real, certificacion o condicion formal. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-121 | Alcance | Confirmar alcance de integracion para Registro de Medidas de Proteccion: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-121 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-121 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-121 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-121 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-121 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-121 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-121 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
PYD-122 - Conectar RNCAS
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: RNCAS | Fechas: 2026-11-04 a 2026-11-13.
Descripcion detallada
PYD-122 - Conectar RNCAS
Objetivo PM: construir o habilitar la integracion de Registro Nacional de Centros de Asistencia Social con contrato, adaptador, seguridad, manejo de errores y trazabilidad.
Alcance operativo: esta tarea pertenece a H12 - H12 - Interoperabilidad interna real, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta RNCAS, queda a cargo de Integraciones y esta planeada del 2026-11-04 al 2026-11-13. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe probar caso exitoso, errores controlados, timeout, reintento, equivalencias de catalogo y registro de auditoria. Actividades principales del checklist: Confirmar alcance de integracion para Registro Nacional de Centros de Asistencia Social: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-122 (Conectar RNCAS): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-122 solo si "Conectar RNCAS" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el estado queda claro: mock, adaptador, conexion real, certificacion o condicion formal. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-RNCAS-001 - Responsable tecnico; DEP-RNCAS-002 - Modelo de datos; DEP-RNCAS-003 - Contrato API; DEP-RNCAS-004 - Fecha real de disponibilidad; DEP-RNCAS-005 - Mock validado
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-RNCAS-001 - Responsable tecnico; DEP-RNCAS-002 - Modelo de datos; DEP-RNCAS-003 - Contrato API; DEP-RNCAS-004 - Fecha real de disponibilidad; DEP-RNCAS-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de Registro Nacional de Centros de Asistencia Social no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Dependencias a vigilar: DEP-RNCAS-001 - Responsable tecnico; DEP-RNCAS-002 - Modelo de datos; DEP-RNCAS-003 - Contrato API; DEP-RNCAS-004 - Fecha real de disponibilidad; DEP-RNCAS-005 - Mock validado. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de Registro Nacional de Centros de Asistencia Social, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-122 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-122 (Conectar RNCAS): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-122 solo si "Conectar RNCAS" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el estado queda claro: mock, adaptador, conexion real, certificacion o condicion formal. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-RNCAS-001 - Responsable tecnico; DEP-RNCAS-002 - Modelo de datos; DEP-RNCAS-003 - Contrato API; DEP-RNCAS-004 - Fecha real de disponibilidad; DEP-RNCAS-005 - Mock validado. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-122 | Alcance | Confirmar alcance de integracion para Registro Nacional de Centros de Asistencia Social: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-122 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-122 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-122 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-122 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-122 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-122 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-122 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
PYD-123 - Certificar contratos internos o registrar condición
Responsable: QA | Disciplina: Integraciones | Sistema/componente: Interoperabilidad Interna/Externa | Fechas: 2026-11-10 a 2026-11-13.
Descripcion detallada
PYD-123 - Certificar contratos internos o registrar condición
Objetivo PM: construir o habilitar la integracion de contratos internos RDVF, RMP y RNCAS con certificacion o condicion formal con contrato, adaptador, seguridad, manejo de errores y trazabilidad.
Alcance operativo: esta tarea pertenece a H12 - H12 - Interoperabilidad interna real, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta Interoperabilidad Interna/Externa, queda a cargo de QA y esta planeada del 2026-11-10 al 2026-11-13. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe probar caso exitoso, errores controlados, timeout, reintento, equivalencias de catalogo y registro de auditoria. Actividades principales del checklist: Confirmar alcance de integracion para contratos internos RDVF, RMP y RNCAS con certificacion o condicion formal: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-123 (Certificar contratos internos o registrar condición): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-123 solo si "Certificar contratos internos o registrar condición" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el estado queda claro: mock, adaptador, conexion real, certificacion o condicion formal. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-INM-003 - Contrato preliminar; DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-003 - Contrato API; DEP-RDVF-007 - Certificacion
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-INM-003 - Contrato preliminar; DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-003 - Contrato API; DEP-RDVF-007 - Certificacion. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de contratos internos RDVF, RMP y RNCAS con certificacion o condicion formal no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Dependencias a vigilar: DEP-INM-003 - Contrato preliminar; DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-003 - Contrato API; DEP-RDVF-007 - Certificacion. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que QA puede coordinar la revision de contratos internos RDVF, RMP y RNCAS con certificacion o condicion formal, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-123 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-123 (Certificar contratos internos o registrar condición): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-123 solo si "Certificar contratos internos o registrar condición" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el estado queda claro: mock, adaptador, conexion real, certificacion o condicion formal. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-INM-003 - Contrato preliminar; DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-003 - Contrato API; DEP-RDVF-007 - Certificacion. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-123 | Alcance | Confirmar alcance de integracion para contratos internos RDVF, RMP y RNCAS con certificacion o condicion formal: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-123 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-123 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-123 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-123 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-123 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-123 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
- PYD-123 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H12, responsable asignado y fecha de cierre.
PYD-130 - Configurar conectividad INM
Responsable: DevOps | Disciplina: Integraciones | Sistema/componente: INM | Fechas: 2026-11-16 a 2026-11-20.
Descripcion detallada
PYD-130 - Configurar conectividad INM
Objetivo PM: habilitar interoperabilidad externa con INM, cuidando red, autenticacion, contrato, errores, evidencias y condicion institucional.
Alcance operativo: esta tarea pertenece a H13 - H13 - Integracion real INM y COMAR, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta INM, queda a cargo de DevOps y esta planeada del 2026-11-16 al 2026-11-20. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe probar conectividad, payload, autenticacion, timeout, reintento, catalogos, datos de prueba y bitacora de solicitud/respuesta. Actividades principales del checklist: Confirmar alcance de integracion para interoperabilidad con INM: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-130 (Configurar conectividad INM): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-130 solo si "Configurar conectividad INM" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador demuestra caso exitoso, error controlado y estado formal de certificacion o bloqueo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de interoperabilidad con INM no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que DevOps puede coordinar la revision de interoperabilidad con INM, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-130 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-130 (Configurar conectividad INM): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-130 solo si "Configurar conectividad INM" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador demuestra caso exitoso, error controlado y estado formal de certificacion o bloqueo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-130 | Alcance | Confirmar alcance de integracion para interoperabilidad con INM: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-130 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-130 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-130 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-130 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-130 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-130 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-130 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
PYD-131 - Probar adaptador INM
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: INM | Fechas: 2026-11-18 a 2026-11-25.
Descripcion detallada
PYD-131 - Probar adaptador INM
Objetivo PM: habilitar interoperabilidad externa con INM, cuidando red, autenticacion, contrato, errores, evidencias y condicion institucional.
Alcance operativo: esta tarea pertenece a H13 - H13 - Integracion real INM y COMAR, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta INM, queda a cargo de Integraciones y esta planeada del 2026-11-18 al 2026-11-25. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe probar conectividad, payload, autenticacion, timeout, reintento, catalogos, datos de prueba y bitacora de solicitud/respuesta. Actividades principales del checklist: Confirmar alcance de integracion para interoperabilidad con INM: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-131 (Probar adaptador INM): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-131 solo si "Probar adaptador INM" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador demuestra caso exitoso, error controlado y estado formal de certificacion o bloqueo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de interoperabilidad con INM no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de interoperabilidad con INM, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-131 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-131 (Probar adaptador INM): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-131 solo si "Probar adaptador INM" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador demuestra caso exitoso, error controlado y estado formal de certificacion o bloqueo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-131 | Alcance | Confirmar alcance de integracion para interoperabilidad con INM: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-131 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-131 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-131 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-131 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-131 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-131 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-131 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
PYD-132 - Configurar conectividad COMAR
Responsable: DevOps | Disciplina: Integraciones | Sistema/componente: COMAR | Fechas: 2026-11-16 a 2026-11-20.
Descripcion detallada
PYD-132 - Configurar conectividad COMAR
Objetivo PM: habilitar interoperabilidad externa con COMAR, cuidando red, autenticacion, contrato, errores, evidencias y condicion institucional.
Alcance operativo: esta tarea pertenece a H13 - H13 - Integracion real INM y COMAR, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta COMAR, queda a cargo de DevOps y esta planeada del 2026-11-16 al 2026-11-20. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe probar conectividad, payload, autenticacion, timeout, reintento, catalogos, datos de prueba y bitacora de solicitud/respuesta. Actividades principales del checklist: Confirmar alcance de integracion para interoperabilidad con COMAR: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-132 (Configurar conectividad COMAR): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-132 solo si "Configurar conectividad COMAR" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador demuestra caso exitoso, error controlado y estado formal de certificacion o bloqueo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de interoperabilidad con COMAR no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que DevOps puede coordinar la revision de interoperabilidad con COMAR, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-132 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-132 (Configurar conectividad COMAR): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-132 solo si "Configurar conectividad COMAR" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador demuestra caso exitoso, error controlado y estado formal de certificacion o bloqueo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-132 | Alcance | Confirmar alcance de integracion para interoperabilidad con COMAR: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-132 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-132 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-132 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-132 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-132 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-132 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-132 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
PYD-133 - Probar adaptador COMAR
Responsable: Integraciones | Disciplina: Integraciones | Sistema/componente: COMAR | Fechas: 2026-11-18 a 2026-11-25.
Descripcion detallada
PYD-133 - Probar adaptador COMAR
Objetivo PM: habilitar interoperabilidad externa con COMAR, cuidando red, autenticacion, contrato, errores, evidencias y condicion institucional.
Alcance operativo: esta tarea pertenece a H13 - H13 - Integracion real INM y COMAR, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta COMAR, queda a cargo de Integraciones y esta planeada del 2026-11-18 al 2026-11-25. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe probar conectividad, payload, autenticacion, timeout, reintento, catalogos, datos de prueba y bitacora de solicitud/respuesta. Actividades principales del checklist: Confirmar alcance de integracion para interoperabilidad con COMAR: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-133 (Probar adaptador COMAR): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-133 solo si "Probar adaptador COMAR" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador demuestra caso exitoso, error controlado y estado formal de certificacion o bloqueo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de interoperabilidad con COMAR no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Integraciones puede coordinar la revision de interoperabilidad con COMAR, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-133 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-133 (Probar adaptador COMAR): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-133 solo si "Probar adaptador COMAR" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el adaptador demuestra caso exitoso, error controlado y estado formal de certificacion o bloqueo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-133 | Alcance | Confirmar alcance de integracion para interoperabilidad con COMAR: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-133 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-133 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-133 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-133 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-133 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-133 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-133 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
PYD-134 - Certificación externa o registro condicionado
Responsable: Coordinadora técnica | Disciplina: Integraciones | Sistema/componente: Interoperabilidad Interna/Externa | Fechas: 2026-11-25 a 2026-11-27.
Descripcion detallada
PYD-134 - Certificación externa o registro condicionado
Objetivo PM: construir o habilitar la integracion de Interoperabilidad Interna/Externa con contrato, adaptador, seguridad, manejo de errores y trazabilidad.
Alcance operativo: esta tarea pertenece a H13 - H13 - Integracion real INM y COMAR, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta Interoperabilidad Interna/Externa, queda a cargo de Coordinadora técnica y esta planeada del 2026-11-25 al 2026-11-27. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe probar caso exitoso, errores controlados, timeout, reintento, equivalencias de catalogo y registro de auditoria. Actividades principales del checklist: Confirmar alcance de integracion para Interoperabilidad Interna/Externa: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.; Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-134 (Certificación externa o registro condicionado): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-134 solo si "Certificación externa o registro condicionado" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el estado queda claro: mock, adaptador, conexion real, certificacion o condicion formal. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-007 - Certificacion; DEP-RMP-007 - Certificacion; DEP-RNCAS-007 - Certificacion
Riesgos y controles: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-007 - Certificacion; DEP-RMP-007 - Certificacion; DEP-RNCAS-007 - Certificacion. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La integracion de Interoperabilidad Interna/Externa no debe considerarse real hasta contar con contrato, ambiente, credenciales controladas, datos de prueba y evidencia de solicitud/respuesta. Dependencias a vigilar: DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-007 - Certificacion; DEP-RMP-007 - Certificacion; DEP-RNCAS-007 - Certificacion. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Coordinadora técnica puede coordinar la revision de Interoperabilidad Interna/Externa, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-134 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-134 (Certificación externa o registro condicionado): contrato, mock/adaptador, evidencia de solicitud/respuesta, pruebas de error/reintento y estado de certificacion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-134 solo si "Certificación externa o registro condicionado" produce integracion documentada con contrato, mock/adaptador, manejo de errores, seguridad, pruebas y evidencia; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando el estado queda claro: mock, adaptador, conexion real, certificacion o condicion formal. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Contrato incompleto, indisponibilidad de contraparte, diferencias de catalogo, errores no controlados o imposibilidad de certificar a tiempo. Puede agravarse si no se atiende: DEP-INM-006 - Ventana de certificación; DEP-INM-007 - Certificación QA; DEP-RDVF-007 - Certificacion; DEP-RMP-007 - Certificacion; DEP-RNCAS-007 - Certificacion. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-134 | Alcance | Confirmar alcance de integracion para Interoperabilidad Interna/Externa: mock, adaptador, conexion real o certificacion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-134 | Analisis | Revisar contrato, endpoints, payloads, errores, autenticacion y datos de prueba disponibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-134 | Construccion | Implementar o configurar adaptador/mapeo sin almacenar credenciales en codigo; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-134 | Evidencia | Probar caso exitoso, error controlado, timeout, reintento y registro de auditoria; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-134 | Validacion | Validar equivalencias de catalogos y campos obligatorios; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-134 | Dependencias | Registrar evidencia de solicitud/respuesta, correlation ID y resultado sin exponer datos sensibles; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-134 | Seguridad | Actualizar estado de integracion: mock, adaptador, conexion real, certificacion o condicion; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
- PYD-134 | Cierre | Documentar brechas, dependencia externa y criterio para avanzar o bloquear; debe dejar evidencia trazable al hito H13, responsable asignado y fecha de cierre.
PYD-143 - Validar rollback
Responsable: DevOps | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-12-04 a 2026-12-04.
Descripcion detallada
PYD-143 - Validar rollback
Objetivo PM: mover o preparar datos con calidad verificable, conciliacion y capacidad de rollback.
Alcance operativo: esta tarea pertenece a H14 - H14 - Migracion preliminar, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta Acceso Unico Institucional, queda a cargo de DevOps y esta planeada del 2026-12-04 al 2026-12-04. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el paquete debe cubrir fuente, reglas de limpieza, rechazados, bitacora, muestras, conciliacion y rollback. Actividades principales del checklist: Confirmar fuentes, estructura, volumen, periodo y responsable de datos para Validar rollback; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.; Definir reglas de limpieza, transformacion, catalogos, deduplicacion y rechazo; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.; Ejecutar proceso en ambiente controlado con datos anonimizados o autorizados; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.; Registrar bitacora de registros leidos, aceptados, rechazados y corregidos; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.; Conciliar totales, muestras y campos criticos con responsable funcional; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-143 (Validar rollback): scripts, bitacora de carga, reporte de rechazados, conciliacion, muestras y rollback. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-143 solo si "Validar rollback" produce paquete de migracion con fuente, reglas, validaciones, bitacora, conciliacion y rollback; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte de totales, diferencias explicadas y evidencia de recuperacion. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos
Riesgos y controles: Datos fuente incompletos, duplicados, reglas de limpieza no aprobadas o conciliacion insuficiente. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La migracion queda limitada por calidad de fuente, reglas de limpieza, disponibilidad de respaldos y autorizacion de datos. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que DevOps puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-143 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-143 (Validar rollback): scripts, bitacora de carga, reporte de rechazados, conciliacion, muestras y rollback. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-143 solo si "Validar rollback" produce paquete de migracion con fuente, reglas, validaciones, bitacora, conciliacion y rollback; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte de totales, diferencias explicadas y evidencia de recuperacion. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Datos fuente incompletos, duplicados, reglas de limpieza no aprobadas o conciliacion insuficiente. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-143 | Alcance | Confirmar fuentes, estructura, volumen, periodo y responsable de datos para Validar rollback; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
- PYD-143 | Analisis | Definir reglas de limpieza, transformacion, catalogos, deduplicacion y rechazo; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
- PYD-143 | Construccion | Ejecutar proceso en ambiente controlado con datos anonimizados o autorizados; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
- PYD-143 | Evidencia | Registrar bitacora de registros leidos, aceptados, rechazados y corregidos; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
- PYD-143 | Validacion | Conciliar totales, muestras y campos criticos con responsable funcional; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
- PYD-143 | Dependencias | Documentar errores, excepciones, ajustes y plan de rollback; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
- PYD-143 | Seguridad | Adjuntar scripts, reporte de ejecucion y evidencia de conciliacion; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
- PYD-143 | Cierre | Actualizar semaforo de migracion y tareas afectadas; debe dejar evidencia trazable al hito H14, responsable asignado y fecha de cierre.
PYD-153 - Ejecutar pruebas de seguridad
Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-12-09 a 2026-12-11.
Descripcion detallada
PYD-153 - Ejecutar pruebas de seguridad
Objetivo PM: comprobar que Acceso Unico Institucional funciona en escenarios reales, negativos, permisos, integraciones y regresion.
Alcance operativo: esta tarea pertenece a H15 - H15 - Pruebas integrales de QA, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2026-12-09 al 2026-12-11. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: la ejecucion debe registrar casos, datos usados, evidencia, defectos, severidad y decision de avance. Actividades principales del checklist: Confirmar alcance de prueba para Ejecutar pruebas de seguridad y version del artefacto a validar; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Preparar casos, datos anonimizados, usuarios y ambiente; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Ejecutar casos positivos, negativos, permisos, datos limite y regresion aplicable; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Registrar defectos con pasos de reproduccion, evidencia, severidad y modulo afectado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Separar defectos bloqueantes de observaciones no bloqueantes; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-153 (Ejecutar pruebas de seguridad): reporte QA, casos ejecutados, defectos, evidencia, decision QA y matriz de regresion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-153 solo si "Ejecutar pruebas de seguridad" produce reporte de pruebas con casos ejecutados, defectos, evidencias, severidad y decision de avance; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando no quedan defectos bloqueantes sin plan ni aceptacion condicionada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-007 - Usuarios para pruebas
Riesgos y controles: Defectos bloqueantes sin responsable, datos de prueba insuficientes o regresion incompleta. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-153 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-007 - Usuarios para pruebas. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-153 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-153 (Ejecutar pruebas de seguridad): reporte QA, casos ejecutados, defectos, evidencia, decision QA y matriz de regresion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-153 solo si "Ejecutar pruebas de seguridad" produce reporte de pruebas con casos ejecutados, defectos, evidencias, severidad y decision de avance; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando no quedan defectos bloqueantes sin plan ni aceptacion condicionada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Defectos bloqueantes sin responsable, datos de prueba insuficientes o regresion incompleta. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-153 | Alcance | Confirmar alcance de prueba para Ejecutar pruebas de seguridad y version del artefacto a validar; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-153 | Analisis | Preparar casos, datos anonimizados, usuarios y ambiente; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-153 | Construccion | Ejecutar casos positivos, negativos, permisos, datos limite y regresion aplicable; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-153 | Evidencia | Registrar defectos con pasos de reproduccion, evidencia, severidad y modulo afectado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-153 | Validacion | Separar defectos bloqueantes de observaciones no bloqueantes; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-153 | Dependencias | Reejecutar casos corregidos y documentar resultado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-153 | Seguridad | Emitir decision QA: aprobado, aprobado condicionado o rechazado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-153 | Cierre | Actualizar Perfex/PtD con reporte, evidencias y riesgos; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-154 - Ejecutar pruebas de roles y auditoría
Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2026-12-09 a 2026-12-11.
Descripcion detallada
PYD-154 - Ejecutar pruebas de roles y auditoría
Objetivo PM: asegurar que cada perfil acceda solo a funciones, rutas, datos y acciones autorizadas.
Alcance operativo: esta tarea pertenece a H15 - H15 - Pruebas integrales de QA, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2026-12-09 al 2026-12-11. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe mapear roles, permisos, rutas protegidas, acciones criticas, denegaciones y evidencia de auditoria. Actividades principales del checklist: Confirmar alcance de prueba para Ejecutar pruebas de roles y auditoría y version del artefacto a validar; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Preparar casos, datos anonimizados, usuarios y ambiente; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Ejecutar casos positivos, negativos, permisos, datos limite y regresion aplicable; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Registrar defectos con pasos de reproduccion, evidencia, severidad y modulo afectado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.; Separar defectos bloqueantes de observaciones no bloqueantes; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-154 (Ejecutar pruebas de roles y auditoría): reporte QA, casos ejecutados, defectos, evidencia, decision QA y matriz de regresion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-154 solo si "Ejecutar pruebas de roles y auditoría" produce reporte de pruebas con casos ejecutados, defectos, evidencias, severidad y decision de avance; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-003 - Roles y jerarquías; DEP-PF-007 - Usuarios para pruebas
Riesgos y controles: Defectos bloqueantes sin responsable, datos de prueba insuficientes o regresion incompleta. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-003 - Roles y jerarquías; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-154 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-003 - Roles y jerarquías; DEP-PF-007 - Usuarios para pruebas. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-154 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-154 (Ejecutar pruebas de roles y auditoría): reporte QA, casos ejecutados, defectos, evidencia, decision QA y matriz de regresion. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-154 solo si "Ejecutar pruebas de roles y auditoría" produce reporte de pruebas con casos ejecutados, defectos, evidencias, severidad y decision de avance; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de permisos y pruebas de acceso permitido/denegado. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Defectos bloqueantes sin responsable, datos de prueba insuficientes o regresion incompleta. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-INM-005 - Ambiente, VPN, credenciales y datos de prueba; DEP-PF-003 - Roles y jerarquías; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-154 | Alcance | Confirmar alcance de prueba para Ejecutar pruebas de roles y auditoría y version del artefacto a validar; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-154 | Analisis | Preparar casos, datos anonimizados, usuarios y ambiente; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-154 | Construccion | Ejecutar casos positivos, negativos, permisos, datos limite y regresion aplicable; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-154 | Evidencia | Registrar defectos con pasos de reproduccion, evidencia, severidad y modulo afectado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-154 | Validacion | Separar defectos bloqueantes de observaciones no bloqueantes; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-154 | Dependencias | Reejecutar casos corregidos y documentar resultado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-154 | Seguridad | Emitir decision QA: aprobado, aprobado condicionado o rechazado; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
- PYD-154 | Cierre | Actualizar Perfex/PtD con reporte, evidencias y riesgos; debe dejar evidencia trazable al hito H15, responsable asignado y fecha de cierre.
PYD-165 - Atender observaciones institucionales
Responsable: Coordinadora técnica | Disciplina: Documentacion | Sistema/componente: Gestion Documental | Fechas: 2027-01-06 a 2027-01-08.
Descripcion detallada
PYD-165 - Atender observaciones institucionales
Objetivo PM: resolver observaciones formales sobre Gestion Documental, distinguiendo correccion aceptada, aclaracion, cambio fuera de alcance y condicion pendiente.
Alcance operativo: esta tarea pertenece a H16 - H16 - Correcciones y cierre tecnico de QA, se vincula con PYD-E4 - Integracion, QA, seguridad y migracion preliminar, impacta Gestion Documental, queda a cargo de Coordinadora técnica y esta planeada del 2027-01-06 al 2027-01-08. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: cada observacion debe quedar trazada con respuesta, responsable, evidencia, impacto en entregable y decision de cierre. Actividades principales del checklist: Definir alcance del documento o paquete para Atender observaciones institucionales; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.; Integrar contenido actualizado, evidencias, anexos, decisiones y control de cambios; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.; Revisar consistencia con tareas, hitos, dependencias, integraciones y criterios de aceptacion; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.; Atender observaciones recibidas y registrar respuesta por punto; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.; Validar que no incluya secretos, credenciales ni datos personales reales; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-165 (Atender observaciones institucionales): documento o paquete formal actualizado con control de cambios, anexos, observaciones atendidas y version entregable. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-165 solo si "Atender observaciones institucionales" produce documento o paquete formal actualizado con control de cambios, anexos, observaciones atendidas y version entregable; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de observaciones actualizada y conformidad o condicion formal del revisor. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios
Riesgos y controles: Riesgo de cerrar Atender observaciones institucionales sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: El cierre de PYD-165 queda limitado por disponibilidad de responsables, evidencia y dependencias del hito. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Coordinadora técnica puede coordinar la revision de Gestion Documental, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-165 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-165 (Atender observaciones institucionales): documento o paquete formal actualizado con control de cambios, anexos, observaciones atendidas y version entregable. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-165 solo si "Atender observaciones institucionales" produce documento o paquete formal actualizado con control de cambios, anexos, observaciones atendidas y version entregable; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con matriz de observaciones actualizada y conformidad o condicion formal del revisor. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Riesgo de cerrar Atender observaciones institucionales sin evidencia suficiente, responsable claro o impacto revisado sobre hitos dependientes. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-004 - Documentación de autenticación; DEP-INM-002 - Documentación de servicios. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-165 | Alcance | Definir alcance del documento o paquete para Atender observaciones institucionales; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.
- PYD-165 | Analisis | Integrar contenido actualizado, evidencias, anexos, decisiones y control de cambios; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.
- PYD-165 | Construccion | Revisar consistencia con tareas, hitos, dependencias, integraciones y criterios de aceptacion; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.
- PYD-165 | Evidencia | Atender observaciones recibidas y registrar respuesta por punto; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.
- PYD-165 | Validacion | Validar que no incluya secretos, credenciales ni datos personales reales; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.
- PYD-165 | Dependencias | Preparar version formal con fecha, responsable y estado; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.
- PYD-165 | Seguridad | Obtener revision tecnica/funcional o registrar condicion pendiente; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.
- PYD-165 | Cierre | Publicar evidencia documental y actualizar el entregable en PtD; debe dejar evidencia trazable al hito H16, responsable asignado y fecha de cierre.
PYD-180 - Preparar alcance de pentesting
Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2027-02-01 a 2027-02-03.
Descripcion detallada
PYD-180 - Preparar alcance de pentesting
Objetivo PM: gestionar seguridad desde alcance autorizado hasta remediacion comprobada, sin exponer evidencia sensible.
Alcance operativo: esta tarea pertenece a H18 - H18 - Pentesting y evaluacion de seguridad, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2027-02-01 al 2027-02-03. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe cubrir hallazgos, severidad, impacto, responsable, fix, retest, excepcion y decision de liberacion. Actividades principales del checklist: Definir alcance exacto de seguridad para Preparar alcance de pentesting: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-180 (Preparar alcance de pentesting): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-180 solo si "Preparar alcance de pentesting" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-007 - Usuarios para pruebas
Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-007 - Usuarios para pruebas. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-180 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-180 (Preparar alcance de pentesting): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-180 solo si "Preparar alcance de pentesting" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-180 | Alcance | Definir alcance exacto de seguridad para Preparar alcance de pentesting: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-180 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-180 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-180 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-180 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-180 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-180 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-180 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-181 - Ejecutar pentesting
Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2027-02-03 a 2027-02-10.
Descripcion detallada
PYD-181 - Ejecutar pentesting
Objetivo PM: gestionar seguridad desde alcance autorizado hasta remediacion comprobada, sin exponer evidencia sensible.
Alcance operativo: esta tarea pertenece a H18 - H18 - Pentesting y evaluacion de seguridad, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2027-02-03 al 2027-02-10. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe cubrir hallazgos, severidad, impacto, responsable, fix, retest, excepcion y decision de liberacion. Actividades principales del checklist: Definir alcance exacto de seguridad para Ejecutar pentesting: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-181 (Ejecutar pentesting): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-181 solo si "Ejecutar pentesting" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos
Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-181 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-181 (Ejecutar pentesting): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-181 solo si "Ejecutar pentesting" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-181 | Alcance | Definir alcance exacto de seguridad para Ejecutar pentesting: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-181 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-181 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-181 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-181 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-181 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-181 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-181 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-182 - Clasificar hallazgos
Responsable: Seguridad | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2027-02-10 a 2027-02-12.
Descripcion detallada
PYD-182 - Clasificar hallazgos
Objetivo PM: evaluar seguridad con alcance autorizado, evidencia controlada y plan de remediacion accionable.
Alcance operativo: esta tarea pertenece a H18 - H18 - Pentesting y evaluacion de seguridad, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Acceso Unico Institucional, queda a cargo de Seguridad y esta planeada del 2027-02-10 al 2027-02-12. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: la prueba debe cubrir roles, sesion, APIs, configuracion, datos sensibles y hallazgos clasificados por severidad. Actividades principales del checklist: Definir alcance exacto de seguridad para Clasificar hallazgos: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-182 (Clasificar hallazgos): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-182 solo si "Clasificar hallazgos" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte, plan de remediacion, retest o excepcion formal aprobada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos
Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Seguridad puede coordinar la revision de gestion de hallazgos de seguridad, severidad, remediacion y retest, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-182 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-182 (Clasificar hallazgos): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-182 solo si "Clasificar hallazgos" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con reporte, plan de remediacion, retest o excepcion formal aprobada. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-182 | Alcance | Definir alcance exacto de seguridad para Clasificar hallazgos: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-182 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-182 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-182 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-182 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-182 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-182 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
- PYD-182 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H18, responsable asignado y fecha de cierre.
PYD-190 - Remediar vulnerabilidades críticas
Responsable: Backend 1 | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2027-02-15 a 2027-02-19.
Descripcion detallada
PYD-190 - Remediar vulnerabilidades críticas
Objetivo PM: gestionar seguridad desde alcance autorizado hasta remediacion comprobada, sin exponer evidencia sensible.
Alcance operativo: esta tarea pertenece a H19 - H19 - Remediacion y repruebas, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Acceso Unico Institucional, queda a cargo de Backend 1 y esta planeada del 2027-02-15 al 2027-02-19. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe cubrir hallazgos, severidad, impacto, responsable, fix, retest, excepcion y decision de liberacion. Actividades principales del checklist: Definir alcance exacto de seguridad para Remediar vulnerabilidades críticas: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-190 (Remediar vulnerabilidades críticas): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-190 solo si "Remediar vulnerabilidades críticas" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos
Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-190 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-190 (Remediar vulnerabilidades críticas): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-190 solo si "Remediar vulnerabilidades críticas" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-190 | Alcance | Definir alcance exacto de seguridad para Remediar vulnerabilidades críticas: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-190 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-190 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-190 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-190 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-190 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-190 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-190 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-191 - Remediar vulnerabilidades altas
Responsable: Backend 1 | Disciplina: Seguridad | Sistema/componente: Acceso Unico Institucional | Fechas: 2027-02-18 a 2027-02-24.
Descripcion detallada
PYD-191 - Remediar vulnerabilidades altas
Objetivo PM: gestionar seguridad desde alcance autorizado hasta remediacion comprobada, sin exponer evidencia sensible.
Alcance operativo: esta tarea pertenece a H19 - H19 - Remediacion y repruebas, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Acceso Unico Institucional, queda a cargo de Backend 1 y esta planeada del 2027-02-18 al 2027-02-24. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe cubrir hallazgos, severidad, impacto, responsable, fix, retest, excepcion y decision de liberacion. Actividades principales del checklist: Definir alcance exacto de seguridad para Remediar vulnerabilidades altas: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.; Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-191 (Remediar vulnerabilidades altas): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-191 solo si "Remediar vulnerabilidades altas" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos
Riesgos y controles: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: Las pruebas de seguridad solo pueden ejecutarse sobre alcance autorizado, ambientes permitidos y usuarios de prueba. Dependencias a vigilar: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Backend 1 puede coordinar la revision de Acceso Unico Institucional, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-191 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-191 (Remediar vulnerabilidades altas): reporte de seguridad, hallazgos, severidad, evidencia controlada, remediacion y retest. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-191 solo si "Remediar vulnerabilidades altas" produce reporte de seguridad con alcance, evidencia, hallazgos, severidad, plan de remediacion y retest; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando los hallazgos criticos/altos quedan cerrados o formalmente exceptuados. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Hallazgos criticos sin ventana de remediacion, evidencia sensible mal resguardada o retest incompleto. Puede agravarse si no se atiende: DEP-DTI-002 - Arquitectura institucional; DEP-DTI-007 - Acceso a datos históricos. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-191 | Alcance | Definir alcance exacto de seguridad para Remediar vulnerabilidades altas: modulos, endpoints, roles y datos sensibles; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-191 | Analisis | Preparar ambiente, usuarios de prueba, ventanas de ejecucion y autorizacion formal; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-191 | Construccion | Ejecutar pruebas o revision segun alcance: permisos, sesion, API, datos, configuracion o pentest; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-191 | Evidencia | Clasificar hallazgos por severidad, impacto, explotabilidad y evidencia; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-191 | Validacion | Registrar plan de remediacion con responsable y fecha objetivo; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-191 | Dependencias | Validar que evidencias no incluyan secretos ni datos personales reales; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-191 | Seguridad | Ejecutar retest o definir condicion formal cuando aplique; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
- PYD-191 | Cierre | Actualizar riesgos, RAID y criterio de liberacion; debe dejar evidencia trazable al hito H19, responsable asignado y fecha de cierre.
PYD-201 - Preparar infraestructura productiva
Responsable: DevOps | Disciplina: DevOps | Sistema/componente: Infraestructura DTI | Fechas: 2027-03-01 a 2027-03-08.
Descripcion detallada
PYD-201 - Preparar infraestructura productiva
Objetivo PM: preparar o ejecutar liberacion productiva con ventana, respaldo, monitoreo, rollback y responsables.
Alcance operativo: esta tarea pertenece a H20 - H20 - Migracion definitiva y preparacion productiva, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Infraestructura DTI, queda a cargo de DevOps y esta planeada del 2027-03-01 al 2027-03-08. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: el paquete debe cubrir Go/No-Go, humo productivo, comunicacion, evidencia y criterio para abortar. Actividades principales del checklist: Confirmar prerrequisitos de produccion para Preparar infraestructura productiva: aprobaciones, version, respaldo y ventana; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.; Revisar checklist Go/No-Go, dependencias abiertas y plan de rollback; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.; Validar configuracion de ambiente, monitoreo, alertas, logs y responsables de guardia; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.; Ejecutar liberacion o prueba productiva segun procedimiento autorizado; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.; Verificar humo funcional, autenticacion, integraciones criticas y reportes basicos; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-201 (Preparar infraestructura productiva): checklist Go/No-Go, respaldo, ventana, monitoreo, humo productivo y comunicacion de resultado. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-201 solo si "Preparar infraestructura productiva" produce paquete de liberacion con checklist Go/No-Go, monitoreo, rollback, responsables y evidencia productiva; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con resultado productivo documentado y monitoreo activo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva; DEP-INM-008 - Preparación productiva; DEP-PF-007 - Usuarios para pruebas
Riesgos y controles: Liberacion sin rollback probado, monitoreo incompleto o decision Go/No-Go sin responsables presentes. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva; DEP-INM-008 - Preparación productiva; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La liberacion queda condicionada por ventana aprobada, respaldo, rollback, monitoreo y decision Go/No-Go. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva; DEP-INM-008 - Preparación productiva; DEP-PF-007 - Usuarios para pruebas. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que DevOps puede coordinar la revision de Infraestructura DTI, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-201 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-201 (Preparar infraestructura productiva): checklist Go/No-Go, respaldo, ventana, monitoreo, humo productivo y comunicacion de resultado. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-201 solo si "Preparar infraestructura productiva" produce paquete de liberacion con checklist Go/No-Go, monitoreo, rollback, responsables y evidencia productiva; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con resultado productivo documentado y monitoreo activo. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Liberacion sin rollback probado, monitoreo incompleto o decision Go/No-Go sin responsables presentes. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva; DEP-INM-008 - Preparación productiva; DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-201 | Alcance | Confirmar prerrequisitos de produccion para Preparar infraestructura productiva: aprobaciones, version, respaldo y ventana; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-201 | Analisis | Revisar checklist Go/No-Go, dependencias abiertas y plan de rollback; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-201 | Construccion | Validar configuracion de ambiente, monitoreo, alertas, logs y responsables de guardia; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-201 | Evidencia | Ejecutar liberacion o prueba productiva segun procedimiento autorizado; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-201 | Validacion | Verificar humo funcional, autenticacion, integraciones criticas y reportes basicos; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-201 | Dependencias | Registrar evidencia productiva sin datos sensibles; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-201 | Seguridad | Documentar incidentes, decisiones y pendientes post-liberacion; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-201 | Cierre | Actualizar estado de produccion y comunicar resultado a interesados; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
PYD-202 - Configurar monitoreo y alertas
Responsable: DevOps | Disciplina: DevOps | Sistema/componente: Infraestructura DTI | Fechas: 2027-03-05 a 2027-03-10.
Descripcion detallada
PYD-202 - Configurar monitoreo y alertas
Objetivo PM: habilitar observabilidad operativa para saber si servicios, integraciones y jobs estan vivos, sanos y auditables.
Alcance operativo: esta tarea pertenece a H20 - H20 - Migracion definitiva y preparacion productiva, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Infraestructura DTI, queda a cargo de DevOps y esta planeada del 2027-03-05 al 2027-03-10. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe incluir health checks, logs estructurados, correlation IDs, metricas, alertas y criterios de severidad. Actividades principales del checklist: Confirmar prerrequisitos de produccion para Configurar monitoreo y alertas: aprobaciones, version, respaldo y ventana; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.; Revisar checklist Go/No-Go, dependencias abiertas y plan de rollback; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.; Validar configuracion de ambiente, monitoreo, alertas, logs y responsables de guardia; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.; Ejecutar liberacion o prueba productiva segun procedimiento autorizado; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.; Verificar humo funcional, autenticacion, integraciones criticas y reportes basicos; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-202 (Configurar monitoreo y alertas): checklist Go/No-Go, respaldo, ventana, monitoreo, humo productivo y comunicacion de resultado. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-202 solo si "Configurar monitoreo y alertas" produce paquete de liberacion con checklist Go/No-Go, monitoreo, rollback, responsables y evidencia productiva; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando una falla simulada genera evidencia localizable y accion de soporte. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva
Riesgos y controles: Liberacion sin rollback probado, monitoreo incompleto o decision Go/No-Go sin responsables presentes. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La liberacion queda condicionada por ventana aprobada, respaldo, rollback, monitoreo y decision Go/No-Go. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que DevOps puede coordinar la revision de Infraestructura DTI, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-202 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-202 (Configurar monitoreo y alertas): checklist Go/No-Go, respaldo, ventana, monitoreo, humo productivo y comunicacion de resultado. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-202 solo si "Configurar monitoreo y alertas" produce paquete de liberacion con checklist Go/No-Go, monitoreo, rollback, responsables y evidencia productiva; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida cuando una falla simulada genera evidencia localizable y accion de soporte. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Liberacion sin rollback probado, monitoreo incompleto o decision Go/No-Go sin responsables presentes. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-202 | Alcance | Confirmar prerrequisitos de produccion para Configurar monitoreo y alertas: aprobaciones, version, respaldo y ventana; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-202 | Analisis | Revisar checklist Go/No-Go, dependencias abiertas y plan de rollback; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-202 | Construccion | Validar configuracion de ambiente, monitoreo, alertas, logs y responsables de guardia; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-202 | Evidencia | Ejecutar liberacion o prueba productiva segun procedimiento autorizado; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-202 | Validacion | Verificar humo funcional, autenticacion, integraciones criticas y reportes basicos; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-202 | Dependencias | Registrar evidencia productiva sin datos sensibles; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-202 | Seguridad | Documentar incidentes, decisiones y pendientes post-liberacion; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
- PYD-202 | Cierre | Actualizar estado de produccion y comunicar resultado a interesados; debe dejar evidencia trazable al hito H20, responsable asignado y fecha de cierre.
PYD-210 - Preparar checklist Go/No-Go
Responsable: Coordinadora técnica | Disciplina: Coordinacion | Sistema/componente: Gobierno del Proyecto | Fechas: 2027-03-15 a 2027-03-17.
Descripcion detallada
PYD-210 - Preparar checklist Go/No-Go
Objetivo PM: tomar y ejecutar decision de liberacion productiva con checklist, responsables, rollback, monitoreo y comunicacion.
Alcance operativo: esta tarea pertenece a H21 - H21 - Comite Go/No-Go y liberacion, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Gobierno del Proyecto, queda a cargo de Coordinadora técnica y esta planeada del 2027-03-15 al 2027-03-17. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe cubrir criterios de avance, bloqueos, ventana, respaldo, despliegue, humo productivo y plan de reversa. Actividades principales del checklist: Confirmar prerrequisitos de produccion para Preparar checklist Go/No-Go: aprobaciones, version, respaldo y ventana; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Revisar checklist Go/No-Go, dependencias abiertas y plan de rollback; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Validar configuracion de ambiente, monitoreo, alertas, logs y responsables de guardia; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Ejecutar liberacion o prueba productiva segun procedimiento autorizado; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Verificar humo funcional, autenticacion, integraciones criticas y reportes basicos; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-210 (Preparar checklist Go/No-Go): checklist Go/No-Go, respaldo, ventana, monitoreo, humo productivo y comunicacion de resultado. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-210 solo si "Preparar checklist Go/No-Go" produce paquete de liberacion con checklist Go/No-Go, monitoreo, rollback, responsables y evidencia productiva; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acta Go/No-Go, evidencia de despliegue/humo y monitoreo inicial. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-PF-007 - Usuarios para pruebas
Riesgos y controles: Liberacion sin rollback probado, monitoreo incompleto o decision Go/No-Go sin responsables presentes. Puede agravarse si no se atiende: DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La liberacion queda condicionada por ventana aprobada, respaldo, rollback, monitoreo y decision Go/No-Go. Dependencias a vigilar: DEP-PF-007 - Usuarios para pruebas. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Coordinadora técnica puede coordinar la revision de Gobierno del Proyecto, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-210 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-210 (Preparar checklist Go/No-Go): checklist Go/No-Go, respaldo, ventana, monitoreo, humo productivo y comunicacion de resultado. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-210 solo si "Preparar checklist Go/No-Go" produce paquete de liberacion con checklist Go/No-Go, monitoreo, rollback, responsables y evidencia productiva; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acta Go/No-Go, evidencia de despliegue/humo y monitoreo inicial. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Liberacion sin rollback probado, monitoreo incompleto o decision Go/No-Go sin responsables presentes. Puede agravarse si no se atiende: DEP-PF-007 - Usuarios para pruebas. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-210 | Alcance | Confirmar prerrequisitos de produccion para Preparar checklist Go/No-Go: aprobaciones, version, respaldo y ventana; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-210 | Analisis | Revisar checklist Go/No-Go, dependencias abiertas y plan de rollback; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-210 | Construccion | Validar configuracion de ambiente, monitoreo, alertas, logs y responsables de guardia; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-210 | Evidencia | Ejecutar liberacion o prueba productiva segun procedimiento autorizado; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-210 | Validacion | Verificar humo funcional, autenticacion, integraciones criticas y reportes basicos; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-210 | Dependencias | Registrar evidencia productiva sin datos sensibles; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-210 | Seguridad | Documentar incidentes, decisiones y pendientes post-liberacion; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-210 | Cierre | Actualizar estado de produccion y comunicar resultado a interesados; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
PYD-211 - Ejecutar comité Go/No-Go
Responsable: Coordinadora técnica | Disciplina: Coordinacion | Sistema/componente: Gobierno del Proyecto | Fechas: 2027-03-18 a 2027-03-18.
Descripcion detallada
PYD-211 - Ejecutar comité Go/No-Go
Objetivo PM: tomar y ejecutar decision de liberacion productiva con checklist, responsables, rollback, monitoreo y comunicacion.
Alcance operativo: esta tarea pertenece a H21 - H21 - Comite Go/No-Go y liberacion, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Gobierno del Proyecto, queda a cargo de Coordinadora técnica y esta planeada del 2027-03-18 al 2027-03-18. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe cubrir criterios de avance, bloqueos, ventana, respaldo, despliegue, humo productivo y plan de reversa. Actividades principales del checklist: Confirmar prerrequisitos de produccion para Ejecutar comité Go/No-Go: aprobaciones, version, respaldo y ventana; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Revisar checklist Go/No-Go, dependencias abiertas y plan de rollback; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Validar configuracion de ambiente, monitoreo, alertas, logs y responsables de guardia; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Ejecutar liberacion o prueba productiva segun procedimiento autorizado; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Verificar humo funcional, autenticacion, integraciones criticas y reportes basicos; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-211 (Ejecutar comité Go/No-Go): checklist Go/No-Go, respaldo, ventana, monitoreo, humo productivo y comunicacion de resultado. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-211 solo si "Ejecutar comité Go/No-Go" produce paquete de liberacion con checklist Go/No-Go, monitoreo, rollback, responsables y evidencia productiva; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acta Go/No-Go, evidencia de despliegue/humo y monitoreo inicial. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: No hay una dependencia directa enlazada por texto; aun asi debe verificarse que ambientes, accesos, datos de prueba y responsables esten disponibles antes del cierre.
Riesgos y controles: Liberacion sin rollback probado, monitoreo incompleto o decision Go/No-Go sin responsables presentes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La liberacion queda condicionada por ventana aprobada, respaldo, rollback, monitoreo y decision Go/No-Go. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que Coordinadora técnica puede coordinar la revision de Gobierno del Proyecto, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-211 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-211 (Ejecutar comité Go/No-Go): checklist Go/No-Go, respaldo, ventana, monitoreo, humo productivo y comunicacion de resultado. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-211 solo si "Ejecutar comité Go/No-Go" produce paquete de liberacion con checklist Go/No-Go, monitoreo, rollback, responsables y evidencia productiva; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acta Go/No-Go, evidencia de despliegue/humo y monitoreo inicial. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Liberacion sin rollback probado, monitoreo incompleto o decision Go/No-Go sin responsables presentes. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-211 | Alcance | Confirmar prerrequisitos de produccion para Ejecutar comité Go/No-Go: aprobaciones, version, respaldo y ventana; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-211 | Analisis | Revisar checklist Go/No-Go, dependencias abiertas y plan de rollback; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-211 | Construccion | Validar configuracion de ambiente, monitoreo, alertas, logs y responsables de guardia; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-211 | Evidencia | Ejecutar liberacion o prueba productiva segun procedimiento autorizado; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-211 | Validacion | Verificar humo funcional, autenticacion, integraciones criticas y reportes basicos; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-211 | Dependencias | Registrar evidencia productiva sin datos sensibles; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-211 | Seguridad | Documentar incidentes, decisiones y pendientes post-liberacion; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-211 | Cierre | Actualizar estado de produccion y comunicar resultado a interesados; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
PYD-212 - Liberar a producción
Responsable: DevOps | Disciplina: DevOps | Sistema/componente: Infraestructura DTI | Fechas: 2027-03-19 a 2027-03-19.
Descripcion detallada
PYD-212 - Liberar a producción
Objetivo PM: tomar y ejecutar decision de liberacion productiva con checklist, responsables, rollback, monitoreo y comunicacion.
Alcance operativo: esta tarea pertenece a H21 - H21 - Comite Go/No-Go y liberacion, se vincula con PYD-E5 - Remediacion, despliegue productivo, capacitacion y cierre, impacta Infraestructura DTI, queda a cargo de DevOps y esta planeada del 2027-03-19 al 2027-03-19. Debe gestionarse como unidad de trabajo cerrable: alcance claro, actividad ejecutada, evidencia adjunta, dependencia revisada y criterio de aceptacion aplicado.
Actividades de ejecucion: debe cubrir criterios de avance, bloqueos, ventana, respaldo, despliegue, humo productivo y plan de reversa. Actividades principales del checklist: Confirmar prerrequisitos de produccion para Liberar a producción: aprobaciones, version, respaldo y ventana; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Revisar checklist Go/No-Go, dependencias abiertas y plan de rollback; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Validar configuracion de ambiente, monitoreo, alertas, logs y responsables de guardia; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Ejecutar liberacion o prueba productiva segun procedimiento autorizado; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.; Verificar humo funcional, autenticacion, integraciones criticas y reportes basicos; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre..
Entregable verificable: Evidencia requerida para PYD-212 (Liberar a producción): checklist Go/No-Go, respaldo, ventana, monitoreo, humo productivo y comunicacion de resultado. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-212 solo si "Liberar a producción" produce paquete de liberacion con checklist Go/No-Go, monitoreo, rollback, responsables y evidencia productiva; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acta Go/No-Go, evidencia de despliegue/humo y monitoreo inicial. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Dependencias y coordinacion: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva
Riesgos y controles: Liberacion sin rollback probado, monitoreo incompleto o decision Go/No-Go sin responsables presentes. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente. Limitaciones de cierre: La liberacion queda condicionada por ventana aprobada, respaldo, rollback, monitoreo y decision Go/No-Go. Dependencias a vigilar: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. Si falta aprobacion, ambiente, dato de prueba, contrato o responsable, el cierre debe marcarse como condicionado. Supuestos operativos: Se asume que DevOps puede coordinar la revision de Infraestructura DTI, que los ambientes y datos usados son de prueba o estan autorizados, y que cualquier cambio de alcance se registra antes de cerrar la tarea. Se asume disponibilidad razonable de responsables institucionales y uso exclusivo de datos de prueba autorizados.
Regla de cierre: PYD-212 solo puede cerrarse cuando los 8 entregables del checklist esten completos o formalmente exceptuados, la evidencia este disponible en Perfex/PtD, el responsable de cierre haya revisado el resultado y cualquier bloqueo quede registrado como dependencia, RAID o condicion de aceptacion.
Seguridad y datos: no se deben adjuntar credenciales, tokens, secretos, datos personales reales no autorizados ni capturas con informacion sensible. Las evidencias deben usar datos sinteticos, anonimizados o autorizados, y los logs deben ser aptos para auditoria.
Evidencia esperada: Evidencia requerida para PYD-212 (Liberar a producción): checklist Go/No-Go, respaldo, ventana, monitoreo, humo productivo y comunicacion de resultado. Debe incluir responsable, fecha, version o identificador de evidencia, relacion con hito/entregable y aprobacion o condicion de cierre.
Criterio de aceptacion: Aceptar PYD-212 solo si "Liberar a producción" produce paquete de liberacion con checklist Go/No-Go, monitoreo, rollback, responsables y evidencia productiva; cumple el checklist completo; cuenta con evidencia verificable; refleja dependencias, riesgos o condiciones abiertas; y se valida con acta Go/No-Go, evidencia de despliegue/humo y monitoreo inicial. La aceptacion PM exige checklist completo, evidencia verificable, dependencia revisada y ausencia de bloqueo no condicionado.
Riesgos operativos: Liberacion sin rollback probado, monitoreo incompleto o decision Go/No-Go sin responsables presentes. Puede agravarse si no se atiende: DEP-DTI-003 - Infraestructura de desarrollo; DEP-DTI-008 - Infraestructura productiva. El riesgo PM principal es cerrar avance nominal sin evidencia suficiente, dependencia resuelta o aceptacion del responsable correspondiente.
Dependencias relacionadas: DEP-DTI-001 - Repositorios Git - condicion operacional para DTI., DEP-DTI-002 - Arquitectura institucional - condicion operacional para DTI., DEP-DTI-003 - Infraestructura de desarrollo - condicion operacional para DTI., DEP-DTI-004 - Documentación de autenticación - condicion operacional para DTI., DEP-DTI-005 - Ambiente QA - condicion operacional para DTI., DEP-DTI-006 - Certificados y DNS QA - condicion operacional para DTI., DEP-DTI-007 - Acceso a datos historicos - condicion operacional para DTI y migracion., DEP-DTI-008 - Infraestructura productiva - condicion operacional para liberacion y estabilizacion.
Integraciones relacionadas: SYS-07 - Acceso Unico Institucional
Checklist de entregables
- PYD-212 | Alcance | Confirmar prerrequisitos de produccion para Liberar a producción: aprobaciones, version, respaldo y ventana; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-212 | Analisis | Revisar checklist Go/No-Go, dependencias abiertas y plan de rollback; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-212 | Construccion | Validar configuracion de ambiente, monitoreo, alertas, logs y responsables de guardia; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-212 | Evidencia | Ejecutar liberacion o prueba productiva segun procedimiento autorizado; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-212 | Validacion | Verificar humo funcional, autenticacion, integraciones criticas y reportes basicos; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-212 | Dependencias | Registrar evidencia productiva sin datos sensibles; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-212 | Seguridad | Documentar incidentes, decisiones y pendientes post-liberacion; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.
- PYD-212 | Cierre | Actualizar estado de produccion y comunicar resultado a interesados; debe dejar evidencia trazable al hito H21, responsable asignado y fecha de cierre.