S001-2019 Cuc Sunat Tech4 VF PDF

Formulario TECH-4: Descripción del enfoque, metodología y plan
de trabajo para responder a los Términos de Referencia
ÍNDICE GENERAL
ÍNDICE GENERAL ............................................................................................................................... 1
LISTADO DE ILUSTRACIONES ......................................................................................................... 9
LISTADO DE TABLAS ...................................................................................................................... 12
1 ENFOQUE TÉCNICO Y METODOLOGÍA ................................................................................. 14
1.1 DEFINICIONES ....................................................................................................................... 14

1.2 INTRODUCCIÓN ..................................................................................................................... 15
1.2.1 Objetivos estratégicos del Proyecto ........................................................................... 15
1.2.2 La experiencia del CONSORCIO ............................................................................... 18
1.2.2.1 Visión de las Administraciones Tributarias y Aduaneras ................................ 18
1.2.2.2 CEDEX Tributos ..................................................................................................... 20
1.3 VISIÓN DEL PROYECTO.......................................................................................................... 22
1.3.1 Modularidad de un Sistema Tributario ....................................................................... 22
1.3.2 Registro Único de Contribuyentes .............................................................................. 22
1.3.3 Sistema de Cuenta Única del Contribuyente ............................................................. 23
1.3.4 Resumen del alcance del Proyecto ............................................................................ 24
1.4 ENFOQUE TÉCNICO ............................................................................................................... 30
1.4.1 Mapa de Procesos ...................................................................................................... 30
1.4.1.1 Descripción de los procesos relacionados con la cuenta única del
contribuyente ........................................................................................................................ 31
1.4.1.1.1 Compensaciones ............................................................................................. 33
1.4.1.1.2 Suspensión ....................................................................................................... 36
1.4.1.1.3 Ajuste de diferencias ....................................................................................... 38
1.4.1.1.4 Comunicación de diferencias ......................................................................... 40
1.4.1.1.5 Reconocimiento de pagos con error ............................................................. 41
1.4.1.1.6 Modificación de datos ..................................................................................... 45
1.4.1.1.7 Veredicto rectificatorias .................................................................................. 48
1.4.1.1.8 Devoluciones .................................................................................................... 50
1.4.1.1.9 Aplicar documento en cuenta única .............................................................. 52
1.4.1.1.9.1 Agente Extractor de Datos ....................................................................... 52
1.4.1.1.10 Motor ............................................................................................................... 53
Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

“Unidad Ejecutora Mejoramiento del Sistema de Información de la SUNAT - MSI”
SPI N° 001-2019-SUNAT/BID
“CONTRATACIÓN DEL SERVICIO DE DESARROLLO, PRUEBAS Y PUESTA EN PRODUCCIÓN DEL SISTEMA DE CUENTA ÚNICA DE
CONTRIBUYENTE – MVP1 Y MVP2”
1
1.4.1.1.11 Configuración ................................................................................................. 54
1.4.1.1.12 Componente de Validación ........................................................................... 55
1.4.1.1.13 Componente Motor de DN ............................................................................. 56
1.4.1.1.14 Componente Motor de Lanzamiento ............................................................ 60
1.4.1.1.15 Correcciones en cuenta única ...................................................................... 68
1.4.1.1.16 Detracciones ................................................................................................... 71
1.4.1.1.17 Formularios y documentos de cuenta única............................................... 73
1.4.1.1.18 Presentar declaración jurada ........................................................................ 74
1.4.1.1.19 Registrar órdenes de pago ........................................................................... 75
1.4.1.1.20 Comprobantes electrónicos ......................................................................... 75
1.4.1.1.21 Recepción de pagos ...................................................................................... 76
1.4.1.1.22 Infracciones .................................................................................................... 77
1.4.1.1.23 Registro manual de valores .......................................................................... 78
1.4.1.1.24 Créditos con posible prescripción ............................................................... 78
1.4.1.1.25 Fraccionamiento (Parte 1) ............................................................................. 79
1.4.1.1.26 Funcionalidades compartidas ...................................................................... 80
1.4.2 Arquitectura de Negocio ............................................................................................. 80
1.4.2.1 Front ....................................................................................................................... 80
1.4.2.2 Back ....................................................................................................................... 81
1.4.2.3 Interoperabilidad................................................................................................... 81
1.4.3 Arquitectura de Aplicaciones ...................................................................................... 87
1.4.3.1 Principios de la Arquitectura ............................................................................... 87
1.4.3.2 Frontend ................................................................................................................ 92
1.4.3.3 Backend ................................................................................................................. 93
1.4.3.4 Procesos ................................................................................................................ 95
1.4.4 Arquitectura Tecnológica ............................................................................................ 98
1.4.4.1 Diagrama de la Arquitectura Tecnológica. ........................................................ 98
1.4.4.2 Frontend .............................................................................................................. 100
1.4.4.2.1 Framework Frontend ..................................................................................... 100
1.4.4.2.2 Librerías de mejora de productividad .......................................................... 101
1.4.4.2.3 Herramientas .................................................................................................. 101
1.4.4.2.4 Componentes tecnológicos que soportan el frontend. ............................. 102
1.4.4.3 Backend ............................................................................................................... 103
1.4.4.3.1 API Gateway Kong ......................................................................................... 103
1.4.4.3.2 Bases de datos ............................................................................................... 104
1.4.4.3.2.1 MongoDB ................................................................................................. 105
1.4.4.3.2.2 Redis ......................................................................................................... 105

2
1.4.4.3.2.3 Kafka y Zookeeper .................................................................................. 106
1.4.4.3.2.4 Agente Extractor de Datos (AED) .......................................................... 107
1.4.4.3.2.5 Microservicios ......................................................................................... 108
1.4.4.4 Procesos .............................................................................................................. 109
1.4.4.4.1 Zeebe ............................................................................................................... 109
1.4.4.4.1.1 Ventajas de Zeebe: .................................................................................. 109
1.4.4.4.2 Motor de reglas de negocio Drools .............................................................. 110
1.4.4.4.2.1 Arquitectura de Drools ........................................................................... 111
1.4.4.5 Logs, Monitoreo y Alertas ................................................................................. 112
1.4.4.5.1 Prometheus .................................................................................................... 112
1.4.4.5.2 Grafana............................................................................................................ 113
1.4.4.5.3 ElasticStack .................................................................................................... 114
1.4.4.6 CI/CD .................................................................................................................... 115
1.4.4.6.1 Jenkins ............................................................................................................ 115
1.4.4.6.2 SonarQube ...................................................................................................... 116
1.4.4.6.3 GitLab .............................................................................................................. 117
1.4.4.6.4 Artifactory ....................................................................................................... 117
1.4.4.6.5 Arquitectura .................................................................................................... 118
1.5 MARCO METODOLÓGICO ..................................................................................................... 119
1.5.1 SAFe - Scaled Agile Framework Enterprise (Escalado Ágil) ................................... 119
1.5.1.1 Nivel Portafolio ................................................................................................... 123
1.5.1.1.1 Características del Nivel de Portafolio ........................................................ 124
1.5.1.1.2 Roles dentro del Nivel de Portafolio ............................................................ 124
1.5.1.2 Nivel Programa ................................................................................................... 124
1.5.1.2.1 Características del Nivel de Programa ........................................................ 125
1.5.1.2.2 Roles dentro del Nivel de Programa ............................................................ 125
1.5.1.2.2.1 Release Train Engineer .......................................................................... 125
1.5.1.2.2.2 Product Manager ..................................................................................... 126
1.5.1.2.2.3 System Team ........................................................................................... 127
1.5.1.3 Nivel Equipo SCRUM. ......................................................................................... 128
1.5.1.3.1 Características del Nivel de Equipo. ............................................................ 128
1.5.1.3.2 Roles dentro del Nivel de Equipos ............................................................... 128
1.5.1.4 Nivel programa - CUC ........................................................................................ 131
1.5.1.4.1 Releases.......................................................................................................... 133
1.5.1.4.2 Tren de entrega ágil ....................................................................................... 134
1.5.1.4.3 Iteración (Sprint) ............................................................................................ 135
1.5.1.4.4 Métricas........................................................................................................... 138

3
1.5.1.4.4.1 Diagrama de Flujo Acumulado .............................................................. 138
1.5.1.4.4.2 Informe de progreso de las Épicas ............................................................. 139
1.5.1.4.5 Mantenimiento Correctivo y Soporte. .......................................................... 140
1.5.1.4.5.1 KANBAN ................................................................................................... 140
1.5.1.5 Nivel Equipo Scrum – CUC ................................................................................ 148
1.5.1.5.1 Definición de eventos. ................................................................................... 151
1.5.2 DevOps ..................................................................................................................... 153
1.5.2.1 Proceso de adopción DevOps........................................................................... 154
1.5.2.2 Ciclo de adopción DevOps con el marco de trabajo Three Ways de The
Phoenix Project .................................................................................................................. 156
1.5.2.3 Prácticas asociadas a la adopción de la filosofía DevOps ............................ 159
1.5.2.3.1 Calidad y documentación Ágil ..................................................................... 159
1.5.2.3.1.1 Aseguramiento de la Calidad ................................................................. 160
1.5.2.3.1.2 Documentación técnica ágil................................................................... 161
1.5.2.3.2 Registro de incidentes .................................................................................. 164
1.5.2.3.3 Revisiones de código .................................................................................... 165
1.5.2.3.4 Automatización de pruebas .......................................................................... 166
1.5.2.3.4.1 Buenas prácticas .................................................................................... 168
1.5.2.3.4.2 Herramientas ........................................................................................... 169
1.5.2.3.5 Integración, entrega y despliegue continuo ............................................... 170
1.5.2.3.6 Estrategia de ramas ....................................................................................... 172
1.5.2.3.7 Construcción de servicios ............................................................................ 173
1.5.2.3.8 Observabilidad ............................................................................................... 173
1.5.2.3.9 Infraestructura como código. ....................................................................... 175
1.5.2.3.10 Rotación de asunción tareas de despliegue y entrega ............................ 175
1.5.2.4 Retrospectivas, post-morten y dailies standup .............................................. 176
1.5.3 Carga Inicial de Datos .............................................................................................. 176
1.5.3.1 Definición general............................................................................................... 177
1.5.3.1.1 Interoperabilidad y migración ...................................................................... 177
1.5.3.1.2 La carga inicial de datos como transacción inicial de la CUC .................. 177
1.5.3.1.3 Carga Inicial de Datos, MVP1 y MVP2 .......................................................... 178
1.5.3.2 Metodología Propuesta ...................................................................................... 178
1.5.4 Capacitación ............................................................................................................. 179
1.5.4.1 Modelo de Capacitación y Transferencia de Conocimiento .......................... 179
1.5.4.1.1 Modelo de Transferencia del Conocimiento ............................................... 180
1.5.4.1.2 Modelo de Capacitación ................................................................................ 184
1.5.4.1.3 Esquema de Competencias y Conocimientos ............................................ 186

4
1.5.4.1.4 Roles y Funciones de una Oficina de TTC .................................................. 187
1.5.4.2 Procesos y Organización de la Capacitación .................................................. 188
1.5.4.2.1 Procesos de Capacitación ............................................................................ 189
1.5.4.2.2 Organización del Equipo de Capacitación .................................................. 189
2 PLAN DE TRABAJO ............................................................................................................... 191
2.1 INTRODUCCIÓN ................................................................................................................... 191

2.1.1 Objetivo ..................................................................................................................... 191
2.1.2 Definiciones y siglas ................................................................................................. 191
2.1.3 Identificación del Proyecto ........................................................................................ 193
2.1.3.1 Objetivo General del Proyecto .......................................................................... 193
2.1.3.2 Objeto de las Especificaciones Técnicas ........................................................ 194
2.2 FASES DEL PROYECTO ........................................................................................................ 195
2.2.1 Fase de Gestión ....................................................................................................... 196
2.2.1.1 Plan General de Trabajo .................................................................................... 196
2.2.1.1.1 Etapa: Planificación ....................................................................................... 196
2.2.1.1.1.1 Cronograma ............................................................................................. 197
2.2.1.1.1.2 Principales Hitos ..................................................................................... 197
2.2.1.1.2 Etapa: Seguimiento y Control del Proyecto ................................................ 197
2.2.1.1.2.1 Gestión del avance del proyecto ........................................................... 197
2.2.1.1.2.2 Modelo de Relación ................................................................................ 198
2.2.1.1.2.3 Procedimiento de Gestión de Cambios ................................................ 203
2.2.1.1.2.4 Procedimiento de Gestión de Incidencias ............................................ 204
2.2.1.1.2.5 Procedimiento de Entregas y Aceptaciones ........................................ 204
2.2.1.1.2.6 Gestión de la Configuración. ................................................................. 205
2.2.1.1.2.7 Documentación de Gestión.................................................................... 206
2.2.1.1.2.8 Cronograma ............................................................................................. 208
2.2.1.1.3 Etapa: Finalización ........................................................................................ 208
2.2.1.1.3.1 Cronograma ............................................................................................. 208
2.2.2 Fase de Carga Inicial de Datos ................................................................................ 208
2.2.2.1.1 Etapa Carga Inicial de Datos ........................................................................ 208
2.2.2.1.1.1 Inclusión de las tareas de análisis y estudio de migración dentro de
los equipos de análisis y desarrollo de los diferentes MVP .................................. 208
2.2.2.1.1.2 Designación de un “Responsable de Carga Inicial de Datos” ........... 210

5
2.2.2.1.1.3 Validación expresa de las diferentes estructuras de carga y extracción
de datos 211
2.2.2.1.1.4 Ejecución de la carga de datos en la CUC a través de los programas
transaccionales........................................................................................................... 212
2.2.2.1.1.5 Reconstrucción del “Saldo del Contribuyente” ................................... 216
2.2.2.1.1.6 Cronograma ............................................................................................. 217
2.2.2.1.1.7 Principales hitos ..................................................................................... 217
2.2.3 Fase de Desarrollo, Pruebas y Puesta en producción del Sistema de Cuenta Única
de Contribuyente: ..................................................................................................................... 220
2.2.3.1.1 Etapa: Inicial ................................................................................................... 220
2.2.3.1.1.1 Conformación del Centro de Excelencia .............................................. 220
2.2.3.1.1.2 Definición sistema de gobierno junto equipo agile ............................. 222
2.2.3.1.1.3 Generación de arquetipos y pipelines genéricos en colaboración con
el equipo de arquitectura ........................................................................................... 223
2.2.3.1.1.4 Definición del Modelo de Colaboración (MVP1, MVP2) ...................... 223
2.2.3.1.2 Etapa: Preparación de Ambientes ............................................................... 224
2.2.3.1.2.1 Ambientes de Desarrollo y Pruebas ..................................................... 224
2.2.3.1.2.2 Instalación y Configuración de Ambientes de Preproducción y
Producción .................................................................................................................. 226
2.2.3.1.3 Etapa: Desarrollo y Pruebas de los MPVs................................................... 228
2.2.3.1.3.1 Sprint 0 ..................................................................................................... 228
2.2.3.1.3.2 Sprints 1 en adelante .............................................................................. 230
2.2.3.1.3.3 Cronograma ............................................................................................. 233
2.2.4 Migración de los ambientes de desarrollo y pruebas ............................................... 233
2.2.4.1 Plan General de Trabajo ...................................................................................... 233
2.2.4.1.1 Instalación y Configuración .............................................................................. 234
2.2.4.1.1.1 Cronograma .............................................................................................. 234
2.2.4.1.1.2 Principales Hitos ....................................................................................... 234
2.2.4.1.2 Migración de los Ambientes de Desarrollo y Prueba ....................................... 234
2.2.4.1.2.1 Cronograma ............................................................................................. 234
2.2.5 Fase de Capacitación y Transferencia de Conocimientos ....................................... 234
2.2.5.1.1 Capacitación a Técnicos y Funcionarios de LA SUNAT ............................ 235
2.2.5.1.1.1 Principales Procesos de la Capacitación ............................................. 235

6
2.2.5.1.1.2 Organización del Equipo de Capacitación ........................................... 236
2.2.5.1.1.3 Listado de Cursos Técnicos Presenciales y a Distancia .................... 237
2.2.5.1.1.4 Listado de Cursos Funcionales Presenciales y a Distancia .............. 238
2.2.5.1.1.5 Aprendizaje a Distancia .......................................................................... 240
2.2.5.1.1.6 Cronograma ............................................................................................. 241
2.2.6 Fase de Mantenimiento Correctivo y Soporte .......................................................... 242
2.2.6.1.1 Mantenimiento Correctivo............................................................................. 244
2.2.6.1.2 Soporte y Operación ...................................................................................... 245
2.2.6.1.3 Cronograma ..................................................................................................... 246
2.2.6.1.4 Principales Hitos .............................................................................................. 246
2.2.7 Prestación Accesoria: Mantenimiento Evolutivo ...................................................... 246
2.2.7.1 Plan General de Trabajo ...................................................................................... 246
2.2.7.1.1 Servicio de Fábrica de Integración .............................................................. 247
2.2.7.1.2 Cronograma .................................................................................................... 250
2.2.7.1.3 Principales Hitos ............................................................................................ 250
2.2.8 Entregables y Criterios de Aceptación ..................................................................... 251
2.2.8.1 Entregables ......................................................................................................... 251
2.2.8.2 Criterios de Aceptación ..................................................................................... 252
2.3 PLAN DE GESTIÓN DE RIESGOS ........................................................................................... 264
2.3.1 Introducción .............................................................................................................. 264
2.3.2 Metodología .............................................................................................................. 265
2.3.3 Roles y Responsabilidades ...................................................................................... 281
2.3.4 Calendario ................................................................................................................ 282
2.3.5 Categorías de Riesgo ............................................................................................... 283
2.3.6 Estructura de Desglose de Riesgos ......................................................................... 285
2.3.7 Definición de Probabilidad e Impacto de Riesgos .................................................... 287
2.3.8 Matriz de Probabilidad e Impacto ............................................................................. 287
2.3.9 Valoración de los Principales Riesgos ..................................................................... 289
2.3.10 Plan de Mitigación de Riesgos ................................................................................. 294
2.4 PLAN DE GESTIÓN DE INTERESADOS .................................................................................... 302
2.4.1 Introducción .............................................................................................................. 302
2.4.2 Objetivos y Alcance .................................................................................................. 302
2.4.3 Términos y Definiciones ........................................................................................... 304
2.4.4 Definición de la Gestión de Grupos De Interés ........................................................ 304
2.4.4.1 Identificación de los grupos de interés ............................................................ 305

7
2.4.4.2 Planificación de la comunicación / participación ........................................... 306
2.4.4.3 Distribución de la información .......................................................................... 307
2.4.4.4 Gestionar las expectativas ................................................................................ 307
2.4.5 Registro de interesados ............................................................................................ 308
2.4.6 Áreas que deberán dar opinión favorable ................................................................ 310
2.5 PLAN DE GESTIÓN DE COMUNICACIONES ............................................................................. 313
2.5.1 Introducción .............................................................................................................. 315
2.5.2 Definiciones y Siglas ................................................................................................ 316
2.5.3 Roles y Responsabilidades ...................................................................................... 317
2.5.4 Tabla de Comunicaciones ........................................................................................ 318
3 ORGANIZACIÓN Y DOTACIÓN DE PERSONAL ................................................................... 319
3.1 ORGANIGRAMA ................................................................................................................... 319

3.2 MATRIZ DE RESPONSABILIDADES ......................................................................................... 321
3.3 DEFINICIÓN DE ROLES Y CANTIDAD DE RECURSOS POR ROL ................................................. 327
3.3.1 Organización del Equipo .......................................................................................... 327
3.3.2 Definición de Rol y Cantidad del Personal Clave ..................................................... 328
3.3.3 Definición de Rol y Cantidad del Personal No Clave ............................................... 330
4 ANEXOS................................................................................................................................... 335
4.1 ANEXO 1: CRONOGRAMA DE LOS TRABAJOS Y PLANIFICACIÓN DE ENTREGABLES (TECH-5) .... 336
4.1 ANEXO 2: RUTA CRÍTICA. .................................................................................................... 350
4.2 ANEXO 3: CRONOGRAMA DE HITOS...................................................................................... 351

8
Listado de Ilustraciones
Ilustración 1: Ámbitos de transformación de la Administraciones tributarias ..................................... 17

Ilustración 2: Áreas claves de las Administraciones Tributarias ........................................................ 19
Ilustración 3: Centro CEDEX y Ámbitos funcionales .......................................................................... 20
Ilustración 4: Clientes de CEDEX ....................................................................................................... 21
Ilustración 5: CEDEX - Transformación Digital .................................................................................. 21
Ilustración 6: Modularidad del Sistema Tributario .............................................................................. 22
Ilustración 7: Resumen del alcance del proyecto ............................................................................... 26
Ilustración 8: Visión General del Proyecto ......................................................................................... 29
Ilustración 9: Procesos y Módulos del Sistema .................................................................................. 30
Ilustración 10: Mapa de Procesos ...................................................................................................... 32
Ilustración 11: Componentes del Motor .............................................................................................. 54
Ilustración 12: Relación de los componentes del Motor ..................................................................... 54
Ilustración 13: Componente de Configuración ................................................................................... 55
Ilustración 14: Componente de Validación ......................................................................................... 56
Ilustración 15: Componente Motor de Documentos Normalizados: ................................................... 59
Ilustración 16: Motor de Lanzamiento ................................................................................................ 60
Ilustración 17: Tipología de cuentas ................................................................................................... 61
Ilustración 18: Consultas .................................................................................................................... 67
Ilustración 19: Mapa de integraciones MVP1 ..................................................................................... 84
Ilustración 20: Mapa de integraciones MVP2 ..................................................................................... 86
Ilustración 21: Arquitectura de aplicaciones ....................................................................................... 87
Ilustración 22: Elementos principales de una arquitectura orientada a microservicios...................... 90
Ilustración 23: Workflow ..................................................................................................................... 96
Ilustración 24: Regla de negocio ........................................................................................................ 97
Ilustración 25: Diagrama de la Arquitectura Tecnológica ................................................................... 99
Ilustración 26: Herramientas de desarrollo....................................................................................... 102
Ilustración 27: Componentes tecnológicos ....................................................................................... 102
Ilustración 28: Kong .......................................................................................................................... 104
Ilustración 29: Arquitectura de la base de datos MongoDB NoSQL ................................................ 105
Ilustración 30: Kafka y Zookeeper .................................................................................................... 106
Ilustración 31: Agente Extractor de Datos (AED) ............................................................................. 107
Ilustración 32: Arquitectura de Drools .............................................................................................. 111
Ilustración 33: Logs, Monitoreo y Alertas ......................................................................................... 112
Ilustración 34: Grafana ..................................................................................................................... 113
9
Ilustración 35: Beats ......................................................................................................................... 115
Ilustración 36: CI/CD ........................................................................................................................ 115
Ilustración 37: Jenkins ...................................................................................................................... 116
Ilustración 38: Artifactory .................................................................................................................. 118
Ilustración 39: Arquitectura ............................................................................................................... 118
Ilustración 40: SAFe ......................................................................................................................... 120
Ilustración 41: Marco de Gestión ...................................................................................................... 121
Ilustración 42: SCALED AGILE FRAMEWORK – VISTA GENERAL DEL FRAMEWORK ............. 122
Ilustración 43: GESTIÓN DE BACKLOGS EN DISTINTOS NIVELES – SAFe ............................... 123
Ilustración 44: SCALED AGILE FRAMEWORK: NIVEL PORTAFOLIO .......................................... 124
Ilustración 45: SCALED AGILE FRAMEWORK: NIVEL PROGRAMA ............................................ 125
Ilustración 46: SCALED AGILE FRAMEWORK: NIVEL SRUM TEAMS ......................................... 128
Ilustración 47: Estructura del Programa CUC y SAFe ..................................................................... 132
Ilustración 48: NIVELES DE GESTIÓN DE SAFe............................................................................ 133
Ilustración 49: RELEASE.................................................................................................................. 134
Ilustración 50: DESARROLLO EN CADENCIA. ENTREGA EN DEMANDA. .................................. 135
Ilustración 51: ANATOMÍA DE UNA ITERACIÓN ............................................................................ 135
Ilustración 52: CADENCIA A NIVEL DE EQUIPOS ......................................................................... 136
Ilustración 53: CADENCIA A NIVEL DE PROGRAMA .................................................................... 137
Ilustración 54: Cadencia Integrada Y Actividades Generales .......................................................... 137
Ilustración 55: Diagrama de Flujo Acumulado.................................................................................. 139
Ilustración 56: Informe de Progreso de las Épicas ........................................................................... 140
Ilustración 57: Kanban ...................................................................................................................... 141
Ilustración 58: Métricas de Kanban .................................................................................................. 142
Ilustración 59: Diagrama de Control de Variabilidad ........................................................................ 143
Ilustración 60: Diagrama de Lead Time y Cycle Time ..................................................................... 144
Ilustración 61: Diagrama de Flujo Acumulado.................................................................................. 144
Ilustración 62: Diagrama de Envejecimiento .................................................................................... 145
Ilustración 63: Clases de Servicio .................................................................................................... 146
Ilustración 64: Manejo De Clases De Servicio En Un Tablero Kanban ........................................... 147
Ilustración 65: Modelo de Capacitación y Transferencia del Conocimiento .................................... 180
Ilustración 66: Técnicas de Transferencia del Conocimiento ........................................................... 181
Ilustración 67: Transferencia del Conocimiento ............................................................................... 182
Ilustración 68: Proceso Difundir el Conocimiento ............................................................................ 183
Ilustración 69: Proceso Compartir el Conocimiento ......................................................................... 184
Ilustración 70: Modelo de la Capacitación, ISO 10015:2003 ........................................................... 185
Ilustración 71: Modelo de Echevarría, 2001; 2002 ........................................................................... 187

10
Ilustración 72: Organigrama de la Oficina de TTC ........................................................................... 188
Ilustración 73: Procesos para la Capacitación ................................................................................. 189
Ilustración 74: Organigrama del Equipo Responsable del Plan de Capacitación ............................ 190
Ilustración 75: MVP1 y MVP2 ........................................................................................................... 195
Ilustración 76: Modelo de Relación .................................................................................................. 199
Ilustración 77: Modelo de Relación .................................................................................................. 203
Ilustración 78: Procedimiento de Gestión de Incidencias ................................................................ 204
Ilustración 79: Procedimiento de Entregas y Aceptaciones ............................................................. 205
Ilustración 80: Documentación de Gestión ....................................................................................... 206
Ilustración 81: Extracción de datos .................................................................................................. 211
Ilustración 82: Ejecución de la carga de datos en la CUC ............................................................... 213
Ilustración 83: Definición del Modelo de Colaboración (MVP1, MVP2) ........................................... 224
Ilustración 84: Implementación del sprint ........................................................................................ 231
Ilustración 85: Implementación del sprint ........................................................................................ 235
Ilustración 86: Organización del Equipo de Capacitación ................................................................ 236
Ilustración 87: Estructura de la Plataforma de Enseñanza a Distancia ........................................... 241
Ilustración 88: Diagrama de Flujo ..................................................................................................... 243
Ilustración 89: Prestación ................................................................................................................. 247
Ilustración 90: Servicio de Fábrica de Integración ........................................................................... 248
Ilustración 91: Metodología .............................................................................................................. 266
Ilustración 92: Roles y Responsabilidades ....................................................................................... 281
Ilustración 93: Calendario ................................................................................................................. 283
Ilustración 94: Estructura de Desglose de Riesgos ......................................................................... 285
Ilustración 95: Estructura de Desglose de Riesgos ......................................................................... 286
Ilustración 96: Matriz de Probabilidades e impacto .......................................................................... 288
Ilustración 97: Pirámide de satisfacción ........................................................................................... 314
Ilustración 98: Organigrama ............................................................................................................. 319
Ilustración 99: Modelo de Relación y Niveles de Supervisión y Control .......................................... 320

11
Listado de Tablas
Tabla 1: Compensaciones .................................................................................................................. 35

Tabla 2: Suspensión ........................................................................................................................... 38
Tabla 3: Ajuste de diferencias ............................................................................................................ 39
Tabla 4: Comunicación de diferencias ............................................................................................... 41
Tabla 5: Reconocimiento de pagos con error .................................................................................... 44
Tabla 6: Modificación de datos ........................................................................................................... 47
Tabla 7: Veredicto rectificatorias ........................................................................................................ 50
Tabla 8: Devoluciones ........................................................................................................................ 52
Tabla 9: Documento Normalizado (DN) asignado por el Sistema ..................................................... 57
Tabla 10: Documento Sustento (Proceso de Negocio) - Documento "Origen o Solicitud" ................ 57
Tabla 11: Otros datos específicos de los Procesos de Negocio ........................................................ 58
Tabla 12: Conceptos a Normalizar ..................................................................................................... 59
Tabla 13: Subcuentas ......................................................................................................................... 66
Tabla 14: Correcciones en cuenta única ............................................................................................ 70
Tabla 15: Detracciones ....................................................................................................................... 73
Tabla 16: Formularios y documentos de cuenta única ...................................................................... 74
Tabla 17: Presentar declaración jurada ............................................................................................. 74
Tabla 18: Registrar órdenes de pago ................................................................................................. 75
Tabla 19: Comprobantes electrónicos ................................................................................................ 76
Tabla 20: Recepción de pagos ........................................................................................................... 77
Tabla 21: Infracciones ........................................................................................................................ 78
Tabla 22: Registro manual de valores ................................................................................................ 78
Tabla 23: Créditos con posible prescripción ...................................................................................... 79
Tabla 24: Fraccionamiento (Parte 1) .................................................................................................. 79
Tabla 25: Funcionalidades compartidas ............................................................................................. 80
Tabla 26: Difusión del Conocimiento ................................................................................................ 183
Tabla 27: Compartir el Conocimiento ............................................................................................... 184
Tabla 28: Fases del Modelo de Capacitación .................................................................................. 186
Tabla 29: MVP1 y MVP2 .................................................................................................................. 196
Tabla 30: Gestión del avance del proyecto ...................................................................................... 198
Tabla 31: Planificación de Sprint 0 ................................................................................................... 230
Tabla 32: Equipo Responsable del Plan de Capacitación ............................................................... 237
Tabla 33: Listado de Cursos Técnicos Presenciales y a Distancia ................................................. 238
Tabla 34: Listado de Cursos Funcionales Presenciales y a Distancia ............................................ 239
Tabla 35: Atención de Incidentes ..................................................................................................... 243

12
Tabla 36: Plan de acción para resolver un incidente ....................................................................... 245
Tabla 37: Entregables ...................................................................................................................... 252
Tabla 38: Probabilidad...................................................................................................................... 287
Tabla 39: Impacto ............................................................................................................................. 287
Tabla 40: Riesgos ............................................................................................................................. 294
Tabla 41: Mitigación de Riesgos ...................................................................................................... 301
Tabla 42: Interesados ....................................................................................................................... 310
Tabla 43: Entregables ...................................................................................................................... 312
Tabla 44: Tabla: Matriz de Comunicaciones .................................................................................... 318
Tabla 45: Matriz RACI ...................................................................................................................... 325
Tabla 46: Roles - Matriz RACI .......................................................................................................... 326
Tabla 47: Responsabilidades - Matriz RACI .................................................................................... 326
Tabla 48: Rol y Cantidad del Personal Clave................................................................................... 329
Tabla 49: Rol y Cantidad del Personal del Equipo de Trabajo ........................................................ 330
Tabla 50: Otros Especialistas ........................................................................................................... 333
Tabla 51: TECH-5: Cronograma de los trabajos y planificación de entregables ............................. 349
Tabla 52: Ruta Crítica....................................................................................................................... 350
Tabla 53: Cronograma de Hitos ....................................................................................................... 351

13
1 Enfoque Técnico y Metodología
1.1 Definiciones
 ART: Agile Release Train o Tren de Lanzamiento Ágil es una organización conformada por
un conjunto de equipos Agiles de larga duración que, junto con otras partes interesadas,
desarrollan y entregan soluciones de forma incremental, utilizando una serie de iteraciones
de longitud fija dentro del periodo de un Incremento de Programa (PI).
 Backlog del producto: es una lista ordenada de todo lo que es necesario para desarrollar el
producto, y es la única fuente de requisitos para cualquier cambio a realizarse.
 DevOps: Contempla el modelo de Integración Continua y pruebas (“build”, “test”), Entrega y
Despliegue Continuo (“reléase”, “deploy”) y Operación Continua (monitoreo y operación)
 Firma Consultora: Postor a quien se ha adjudicado la Buena Pro del presente proceso y
suscribe el contrato.
 IaaS: acrónimo de las siglas en inglés “Infraestructure as a Service”, es una categoría de
servicios en “Nube”. Los recursos informáticos ofrecidos consisten en “hardware” virtualizado
(Infraestructura de procesamiento). Abarca aspectos como servidores virtuales, conexiones
de red, ancho de banda, direcciones IP y balanceadores de carga. El Usuario de la
Infraestructura es quien se encarga de la escalabilidad según sus necesidades. Pueden
entregarse servicios como aplicaciones de productividad, o recursos de Infraestructura.
 INSI: Intendencia Nacional de Sistemas de Información.
 INGP: Intendencia Nacional de Gestión de Procesos.
 MVP: Productos Mínimos Viables que conforman los entregables del proyecto y deberán ser
puestos en producción en forma secuencial.
 MVP1: Primer producto mínimo viable del Sistema de Cuenta Única de Contribuyente.
 MVP2: Segundo producto mínimo viable del Sistema de Cuenta Única de Contribuyente.
 PI: Program Increment o Incremento de Programa es el periodo de tiempo (timebox) en la
que el ART genera un valor incremental.
 Plataforma SUNAT: Se refiere a la Infraestructura de Nube que contratará SUNAT para
soportar los diferentes ambientes requeridos para el presente proyecto.
 PMI: “Project Management Institute” es una organización sin fines de lucro que asocia a
profesionales relacionados con la Gestión de Proyectos.
 Prueba de Concepto: identificada también por las siglas en inglés “PoC”, es una
implementación resumida o incompleta, de un método o de una idea, realizada con el
propósito de verificar que el concepto o teoría en cuestión es susceptible de ser explotada de
una manera útil.

14
 RTE: Release Train Engineer o Ingeniero del Release, es un líder servicial y entrenador del
Agile Release Train (ART). Las principales responsabilidades de RTE es facilitar los eventos
y procesos de ART y ayudar a los equipos a entregar valor. Los RTE se comunican con los
stakeholders, escalan los impedimentos, ayudan a gestionar el riesgo y generan una mejora
continua.
 SCRUM: Metodología ágil de desarrollo de sistemas de información.
 SAFe: Marco de trabajo ágil de escalamiento Scrum.
 SCUC: Sistema de Cuenta Única del Contribuyente.
 Sistemas legados: Hace referencia a software u componente pre-existente, que podría estar
desarrollado con tecnologías nuevas o antiguas, y que son considerados críticos para los
procesos actuales de SUNAT.
 SLA: Acuerdo de Nivel de Servicio.
 SUNAT: Superintendencia Nacional de Aduanas y de Administración Tributaria, contratante
en todos los casos.
 POs: Product Owners
 QA: Quality assurance ó Aseguramiento de la calidad
1.2 Introducción
1.2.1 Objetivos estratégicos del Proyecto
El objetivo del proyecto persigue el fortalecimiento institucional de la SUNAT en sus funciones

aduanera y tributaria, a través de la implementación de una nueva arquitectura tecnológica que
optimice e integre los procesos aduaneros, tributarios y administrativos. Se pretenden lograr los
siguientes objetivos estratégicos:
 Mejorar la efectividad del control del cumplimiento Aduanero y Tributario, a través de

un mejor control de la Administración de las obligaciones tributarias y aduaneras al tener los
incumplimientos en forma oportuna, además de brindarle información integral y actualizada
de la situación fiscal del contribuyente y permitirle automatizar procesos. De modo que se
mejore la efectividad del control del cumplimiento aduanero y tributario.
 Brindar servicios de calidad para facilitar y fomentar el cumplimiento voluntario,

simplificando y facilitando al contribuyente información, de deuda y créditos en forma
inmediata e integrada. Así, se reducirá el tiempo que el contribuyente requiere para cumplir
con sus obligaciones.

15
 Reducir costos para la Administración Tributaria y Aduanera, haciendo más eficientes
los procesos de control, recaudación y de servicios. Evitando la carga operativa de las
dependencias.
 Profundizar el desarrollo de la conciencia aduanera y fiscal en la ciudadanía
 Fortalecer el desarrollo institucional de la SUNAT y sus recursos humanos
A través del cumplimiento de estos objetivos se contribuirá a:
 Lograr una mayor justicia tributaria, mediante el control de los contribuyentes que no dan
cabal cumplimiento a las obligaciones establecidas por las leyes, lo que además permitiría
incrementar la recaudación.
 Apoyar la mejora de la elaboración de estudios y estadísticas tributarias, que permitirán

evaluar y centrar las correspondientes mejoras en la administración aduanera y tributaria.
 Eliminar la problemática originada por la existencia de diversos sistemas y fuentes

para el control de la deuda
 Permitir al contribuyente y al usuario de comercio exterior una consulta unificada de

sus obligaciones.
Este planteamiento comporta una estrategia de transformación digital y cultural, alineada con las
iniciativas en las que están inmersas actualmente las Administraciones Tributarias. Estas estrategias
se apoyan fundamentalmente en tres Áreas:
 Relación con el Contribuyente

 Lucha contra el Fraude
 Eficiencia Operativa

16
Ámbitos de transformación de las Administraciones Tributarias
Información
Interacción ágil, clara y
Asistencia transparente
personalizada
Implicación social
Trámites
Relación con el Lucha contra
contribuyente el fraude
Accesibilidad y proximidad Prevención del fraude
(nuevos canales, omnicanalidad,...)
Ámbitos de
Rediseño de la cartera de servicios transformación Control, detección y
corrección del fraude
(innovación, procesamiento telemático,...)
Cálculo de la brecha fiscal

(brecha fiscal)
Eficiencia
Gobierno del dato operativa Eficiencia en la gestión,
inspección y recaudación
Ilustración 1: Ámbitos de transformación de la Administraciones tributarias
Es en este contexto, es donde la implementación del Sistema de Cuenta Única de Contribuyente

(SCUC) cobra todo el sentido, ya que va a permitir a la SUNAT:
 Optimizar las tareas de control sobre la deuda y acreencias de las obligaciones de los
contribuyentes y usuarios de comercio exterior, para la mejora del cumplimiento, al
disponer de:
o Información unificada, integrada y actualizada del estado de cumplimento de

sus obligaciones, independiente y complementaria a los sistemas “Legados” (y
nuevos módulos) que la originan.
o Una herramienta que siente las bases para la automatización de las tareas, su
tramitación y, en consecuencia, la reducción de los costes de gestión.
 Ofrecer al contribuyente información consolidada de su situación de forma inmediata e

integrada tributaria frente a la Administración:
o Favoreciendo e incentivando el cumplimiento voluntario de sus obligaciones.

o Proporcionando transparencia en la actividad recaudatoria.
o Reduciendo el tiempo que el contribuyente requiere para cumplir con sus
obligaciones.

17
 Optimizar las tareas de cobranza, mejorando la eficacia y eficiencia de los procesos,
priorizando y adecuando las estrategias de cobro según el análisis de la información
integrada:
o Facilitando la adecuación organizativa y el diseño de políticas de cobro

adaptadas a las características de la ciudadanía.
o Sentando las bases para, en posteriores proyectos, implementar herramientas
analíticas avanzadas que identifiquen patrones de comportamiento,
segmentación de contribuyentes o tipologías de deuda.
 Asegurar la correcta imputación contable y desglose de las partidas aplicadas, así como la
trazabilidad de todos los movimientos manteniendo un histórico de los mismos.
 Establecer métricas de gestión que permitan implementar procesos de mejora continua.
Contribuyendo todo lo anterior a: minorar los costos de la Administración y a aumentar la

eficiencia tanto de los procesos de control como de servicios.
La Transformación cultural es imprescindible para el cambio de mentalidad y

comportamiento necesario hacia un nuevo Modelo de Administración Digital.
1.2.2 La experiencia del CONSORCIO
1.2.2.1 Visión de las Administraciones Tributarias y Aduaneras
En un entorno de transformación digital y evolución tecnológica constante, los grandes objetivos de

las Administraciones Tributarias, en general su VISIÓN son, entre otros:
 Ofrecer al ciudadano herramientas que faciliten el cumplimiento de sus obligaciones

tributarias y agilicen su relación con la Administración: Presentación telemática, borradores,
omnicanalidad, sede electrónica, etc.
 Mejorar la eficiencia interna y los procesos de mejora continua de la Administración

Tributaria: visión 360º del contribuyente, procesos homogéneos, administración
electrónica, calidad de los datos, etc.
 Impulsar las capacidades en la lucha contra el fraude, tanto a nivel de detección como de
control de riesgos, incluyendo para ello, el análisis masivo de la información a través de
algoritmos avanzados e Inteligencia Artificial.

18
 Facilitar instrumentos colaborativos que agilicen la interacción entre Administraciones,
entre Organismos colaboradores y entre Ciudadanos.
 Proporcionar mecanismos para garantizar la trazabilidad y la transparencia en la gestión.
 Agilizar y reducir el coste del mantenimiento de los sistemas y su rápida adecuación a

cambios normativos y organizativos.
El CONSORCIO cubre las necesidades de transformación de las TRES ÁREAS CLAVE de

las Administraciones Tributarias desde sus diferentes Ejes: Personas, Procesos, Datos y
Tecnología.
Asegurar que los recursos de la organización tengan las

Relación con el
Personas
competencias necesarias, habilidades e información
contribuyente actualizada para abordar el proceso de transformación
digital con garantías.
Definir la estrategia de transformación digital de los

Procesos procesos de negocio de la organización, basada en su
optimización y su aportación de valor
Lucha contra
el fraude
Considerar los datos como un activo estratégico de gran
Datos
valor para la organización, a través de la implantación de
un modelo de gobernanza de los datos, la mejora continua
y el control de la calidad de la información
Eficiencia
Tecnología
Promover iniciativas digitales para mejorar la
operativa competitividad mediante la eliminación de las brechas
tecnológicas y aumentar la eficiencia de la Organización
Ilustración 2: Áreas claves de las Administraciones Tributarias
El CONSORCIO colabora en el cumplimiento de la misión de las Administraciones Tributarias y

Aduaneras, en la facilitación del cumplimiento voluntario y en el control del cumplimiento de
las obligaciones, para lo que desarrolla nuevas fórmulas que permiten:
 Incrementar la eficacia del control Tributario y Aduanero.
 Brindar servicios a los obligados que les permitan un mejor cumplimiento de sus
obligaciones tributarias y aduaneras.
 Facilitar las operaciones de comercio exterior

19
1.2.2.2 CEDEX Tributos
Ilustración 3: Centro CEDEX y Ámbitos funcionales
El CONSORCIO cuenta con un Centro de Excelencia (CEDEX) de Tributos, que dará el soporte
necesario durante todas las fases del proyecto – Sistema de Cuenta Única de Contribuyente
(SCUC).
El CEDEX Tributos coordina todos los proyectos de ámbito Tributario a nivel Internacional, cuenta
con más de 200 consultores especializados en el ámbito de la Gestión Tributaria y de la Gestión
Económico-Financiera y acumula más de 20 años de experiencia con proyectos de carácter
internacional, entre los que destacan, además de las colaboraciones con la SUNAT y entre otras:
ESPAÑA Implantación y mantenimiento del sistema para cubrir de forma integral la renovación tecnológica de la gestión
tributaria de la Agencia Tributaria de Catalunya
Implantación, adaptación y mantenimiento del Sistema de Gestión de Tributos para Agencia Tributaria
ESPAÑA del Gobierno de Canarias
ESPAÑA Sistemas de Gestión Tributaria de la Diputación Foral de Guipuzcoa: Plataforma Presentación

Tributaria, Plataforma de Recaudación Tributaria y Sistema Integral de Inspección
ESPAÑA Implantación de aplicación para la gestión tributaria de impuestos locales de la Agencia Tributaria de
Madrid
Colaboración en los Desarrollos y en el Mantenimiento de Aplicaciones de la Agencia Estatal de

ESPAÑA Administración Tributaria (AEAT)
ESPAÑA Implantación de aplicación para la gestión tributaria de impuestos locales de la Agencia Tributaria de
Sevilla
ESPAÑA Mantenimiento y evolución de los sistemas de Expedientes Tributarios y de Gestión Tributaria.

20
Evolución de la Oficina Virtual Tributaria para la adaptación a la ley 39/2015 e integración con el
ESPAÑA sistema documental de ATRIGA. Implantación de un sistema de digitalización certificada de
documentos para el expediente tributario electrónico.
BRASIL Implantación del Sistema de Administración Tributaria y Financiera – para la Secretaria de Fazenda del
Estado de Paraiba
Implantación del Sistema de Administración Tributaria y Financiera – para la Secretaria de Fazenda del
BRASIL Estado de Amapa
ARGELIA Análisis de requisitos, diseño, desarrollo y lanzamiento del nuevo sistema informático de gestión
tributaria, basado en SAP-TRM
MEXICO Colaboración en los Desarrollos y en el Mantenimiento de Aplicaciones del Servicio de

Administración Tributaria (SAT)
PERU Colaboración en los Desarrollos y en el Mantenimiento de Aplicaciones de la Superintendencia

Nacional de Aduanas y de Administración Tributaria¡
COLOMBIA Plan de Modernización y de Inspección de la Dirección de Impuestos y Aduanas de Colombia
Ilustración 4: Clientes de CEDEX
Estas experiencias permiten poner a disposición de la SUNAT un equipo multidisciplinario con

capacidad para afrontar un proyecto de la complejidad y criticidad como el Sistema de Cuenta Única
de Contribuyente (SCUC).
El CEDEX lidera el desarrollo y mantenimiento del portfolio de soluciones específicas para el ámbito
Tributario, integradas en la suit global de soluciones de la compañía.
En este contexto de Transformación Digital mencionado, merece especial relevancia nuestra

solución Taxes Fraud, que apoyada sobre tecnología BigData y herramientas analíticas, proporciona
capacidades de soporte para los procesos de Calidad del Dato (Datacleansing), Modelos Predictivos
de Analítica Avanzada o herramientas de Robotización, entre otras.
G e s tió n An alític a
económic o-finan c iera Av an zad a
G e s tió n
R e c u rs os R o b ó tic a
Hu man o s
Ta x es Tax es Ta x es In te lig en c ia d e
erp rev enu e frau d c o n te n ido s
d o c u me n tales
Data
C le a n s in g
G e s tió n
Tr ib u tar ia
G e s tió n
R e c a u d a tor ia
Ilustración 5: CEDEX - Transformación Digital

21
1.3 Visión del Proyecto
1.3.1 Modularidad de un Sistema Tributario
En base al Conocimiento Sectorial y la experiencia en diversas implantaciones en el ámbito de

Tributos, toda transformación y mejoramiento de los Sistemas Tributarios se debería acometer en
diferentes fases, conforme el siguiente gráfico.
Portal Sede
Contribuyente Electrónica
3
7
Intelligence
Plataforma
Business
Cobranza Coactiva Presentación

(Ejecutiva) Normalizada
2
SCU
Integraciones
1
6 Censo
Case Único 4
Management Recaudación
(Fiscalización) Sistema de
avanzada
Analítica
Cuenta Única
5
Determinación
Herramientas
soporte
Ilustración 6: Modularidad del Sistema Tributario
Desde nuestro conocimiento y experiencia, la SUNAT está acometiendo un proceso de

transformación de la forma más rigurosa y consecuente, configurando a partir del Registro Unificado
de Contribuyentes y del Sistema de Cuenta Única, las bases de la Transformación Digital de sus
Sistemas de Información.
1.3.2 Registro Único de Contribuyentes
El elemento fundamental sobre el que se asientan los Sistemas de Información Tributaria, es la

disponibilidad de una identificación única de las personas y de las empresas. Aunque no forma parte
del alcance del proyecto Sistema de Cuenta Única de Contribuyente (SCUC), este objetivo
normalmente tiene una enorme complejidad.
El nivel de calidad del Registro Único de los contribuyentes PRICO y MEPECO, determinarán el nivel
de eficacia de la Cuenta Única del Contribuyente.

22
En este ámbito, una de las tareas más importantes, es la limpieza y reparación de datos
(Datacleansing). Este proceso incluye la identificación de datos duplicados, incompletos, incorrectos,
inexactos, no pertinentes, etc. Para luego substituir, modificar o eliminar estos datos y cargarlos ya
depurados en las BD.DD. existentes.
Aunque no forma parte del presente proyecto, esta situación inicial es de vital importancia, ya que
es la base sobre la que se construirá la identificación del contribuyente en el Sistema de
Cuenta Única de Contribuyente (SCUC), y que determinará los posteriores procesos de
mejoramiento del nuevo Sistema Tributario de la SUNAT.
1.3.3 Sistema de Cuenta Única del Contribuyente
Mediante una visión 360º del Contribuyente, el organismo fiscalizador y recaudador podrá revisar de
un solo vistazo toda la actividad económica de un contribuyente.
Estas iniciativas forman parte de las estrategias de mejoramiento a nivel mundial, y en países como
España, Chile, Estados Unidos o Australia ya se han incorporado en las organizaciones fiscalizadoras
y recaudadoras, con resultados exitosos para la Administración.
Los paradigmas de gestión de las administraciones tributarias y aduaneras coinciden en convertir al

contribuyente y al usuario de comercio exterior en el eje central de su gestión, donde se ha
pasado de una información tributaria departamental y estanca por materia, a un sistema de
información integrado en el cual el contribuyente y el usuario de comercio exterior adquieren especial
relevancia, girando todo entorno a su persona.
El Sistema de Cuenta Única de Contribuyente (SCUC) mostrará toda la información relativa a la

deuda y crédito de un contribuyente o de un usuario de comercio exterior y de forma actualizada,
pudiéndose ofrecer la misma no sólo a los usuarios de las Administraciones sino también a los propios
contribuyentes y a los usuarios de comercio exterior.
La información que se brinda a estos usuarios “externos a la Administración” presenta dos

dimensiones:
 Consulta del estado de la cuenta única
 Aplicación de los créditos al pago de deudas
Una de las grandes ventajas que tiene el Sistema de Cuenta Única de Contribuyente (SCUC) es
que no afecta a los sistemas Legados, permitiendo disponer de un visor que muestra de un solo
vistazo la situación económica del contribuyente y del usuario de comercio exterior.

23
Desde esta orientación, el Sistema de Cuenta Única Contribuyente se plantea como el epicentro
del mapa de sistemas de gestión, y desde el punto de vista del CONSORCIO es la manera más
coherente de abordar la transformación y mejoramiento de los sistemas de información de una
Administración Tributaria y Aduanera.
1.3.4 Resumen del alcance del Proyecto
La Cuenta Única es una herramienta que ofrecerá un registro centralizado e integrado de las deudas
y acreencias de las obligaciones aduaneras, tributarias y previsionales del contribuyente y/o usuario
de comercio exterior (Estado de Cuenta Tributaria), a partir de su identificación, fundamentalmente,
con el RUC (aunque podrán usarse otros mecanismos de identificación).
Existirá una única cuenta para cada contribuyente, que reflejará los movimientos de los procesos que
afectan al saldo del contribuyente y del usuario de comercio exterior, pudiendo ser estos, de dos tipos:
 Iniciados por el contribuyente, como resultado del cumplimiento de sus obligaciones

tributarias
 Iniciados por la Administración, como consecuencia del control y gestión de la deuda y

créditos
Todos los sistemas que soportan los procesos de negocio de Tributos Internos y Aduaneros
publicarán movimientos y recibirán información del sistema de Cuenta Única.
Estos movimientos se capturarán a través de “extractores” en los sistemas “legados” y, en los casos
en los que se trate de una aplicación de créditos, se utilizará también como información para la
creación del documento normalizado, la procedente del Sistema de Cuenta Única de Contribuyente.
Lo mismo sucederá con otras funcionalidades que sirven para realizar ajustes o correcciones de la
propia cuenta única. Deberán desarrollarse módulos nuevos para aquellos procesos que no cubran
todos los estados previstos. En estos dos últimos casos, la generación de los documentos
normalizados no precisará del uso de los extractores de información, sino que serán el resto de los
componentes del sistema de cuenta única los responsables de generar los documentos normalizados
y de registrar los movimientos en la cuenta única.
La información se almacenará (a alto nivel), en los siguientes tipos de cuenta:
 Cuentas de Deudas: Que determinan saldos deudores.

 Cuentas de Créditos: Que determinan saldos a favor del contribuyente.
 Cuentas Transitorias: Que están en proceso de revisión por la Administración (contencioso
o de fiscalización).
 Cuentas de Control:

24
o Informativas: Que almacenan información derivada no estrictamente de
recaudación, como pueden ser procesos de declaración y que se utilizarán para
control (por ejemplo, retenciones IGV) .
o Contrapartida: Para registrar los asientos en partida doble para aquellas
transacciones que lo requieran.
El elemento clave de información del Sistema de Cuenta Única de Contribuyente (SCUC) es el

documento normalizado. Este documento se generará con la información residente en cada
“sistema” origen (Sistema legado y SCUC (incluye los nuevos módulos)), a partir de todos los
procesos (declaraciones, solicitudes, resoluciones, procesos, otros) que afecten a los saldos que se
controlarán en la cuenta.
El documento normalizado se ha definido bajo dos premisas:
 Desacopla la lógica de negocio, del proceso de la recogida de información

 Busca ser mínimamente intrusivo en los sistemas origen para no verse afectado por
sus cambios
Los proveedores de la información para la generación de la información de los documentos

normalizados serán los procesos ejecutados en los sistemas legados, los procesos ejecutados a
través de los nuevos módulos y aquellos procesos ejecutados por el propio Sistema de Cuenta Única
del Contribuyente.
Sobre la información obtenida se aplicarán las Reglas de Validación y de Normalización,

obteniéndose de esta manera los documentos normalizados.
Estos documentos normalizados quedarán relacionados con la información (transacción, proceso,

documento) que le ha servido como base para su generación.
Los documentos normalizados darán lugar al registro de movimientos en la cuenta única del
contribuyente según lo que se haya establecido en las Reglas de Registro de Movimientos.

25
Ilustración 7: Resumen del alcance del proyecto
Se establecerán reglas de parametrización que permitan un mantenimiento ágil de las condiciones

de tratamiento de los documentos normalizados. Esta parametrización deberá cubrir dos aspectos:
 La parametrización de las reglas de validación y normalización de los documentos.

 La parametrización de las reglas de aplicación y registro de los movimientos.
El uso del documento normalizado traerá consigo las siguientes ventajas:
 Desacopla los movimientos contables de:
o Los cambios en los formularios de presentación.

o Los modelos de datos y la lógica de negocio de cada sistema origen.
 Facilita el establecimiento de un “lenguaje común” en la Organización. Esto va a permitir,

entre otros:
o Homogeneizar y simplificar las tareas de control y de fiscalización.

o Mejorar la trazabilidad de las operaciones.
o Establece una relación inequívoca entre documento y movimiento.

26
 Estandariza las consultas y procesos que se realicen sobre el nuevo sistema
Para favorecer una implantación incremental, el proceso de desarrollo del Sistema de

Cuenta Única de Contribuyente (SCUC), se establece en cinco fases (MVPs):
 Fases contempladas en el presente proyecto:
o MVP1: Donde se incorporan el mayor volumen de transacciones que cubren las

operaciones de recaudación. Fundamentalmente Declaraciones Juradas, Pagos
y Comprobantes electrónicos.
o MVP2: En el que se incluyen los procesos y trámites relacionados con la
recaudación, así como la determinación y control de las infracciones.
 Fases que se acometerán en futuras implantaciones:
o MVP3: con el objetivo de migrar los saldos gestionados por el RSIRAT hacia la
Cuenta Única complementándose con los procesos relativos a fraccionamiento,
refinanciamiento y recursos impugnatorios.
o MVP4: en el que se implementarán otros procesos de valores de reorganización
de sociedades y funcionalidades con poca demanda que se encuentran
implementados en RSIRAT.
o MVP5: en el que se incluirán aduanas y elementos de liquidación de
determinación.
Todas las fases y su descomposición en hitos y sprints intermedios, van a disponer de un sistema
de testeo que garantice:
 Que el avance en el Backlog del proyecto cumple las expectativas de los usuarios clave.
 La calidad de los desarrollos realizados.
 El contraste con los requisitos iniciales y la decisión de planificar cambios si fuese necesario.
El alto nivel de detalle expresado en los TDRs, en cuanto al alcance, análisis y planteamiento de
proyecto, reduce sin duda los riesgos asociados a este tipo de implantaciones.
Con todo y desde una perspectiva funcional, el CONSORCIO estima que los puntos críticos, entre
otros, para el éxito del proyecto son:
 Identificación única e inequívoca de los Contribuyentes.

27
 Correcta identificación de los datos a migrar en la carga inicial (Saldos, Movimientos, etc.) y
establecimiento de mecanismos de validación y cuadre de la carga inicial de datos.
 Coordinación con el ciclo de vida y versiones de los sistemas “Legados”, cuando sean
necesarias modificaciones.
 Disponibilidad de los responsables de la SUNAT, en los distintos ámbitos, para los procesos
de validación y pruebas de los hitos SCRUM identificados.
 Gestión de los cambios de alcance que puedan aparecer en el ciclo de vida del proyecto.
 Coordinación de las tareas de mantenimiento con el desarrollo.
 Impacto Normativo no previsto.
 Impacto Organizacional.
 Acciones de capacitación y de gestión del cambio.
Durante todas las fases del proyecto, el CONSORCIO tratará de anticipar proactivamente los riesgos
potenciales. Para ello y a partir de su equipo de consultores y de la experiencia en gestión de
proyectos de ámbito tributario, el CONSORCIO propondrá a la SUNAT las acciones de mitigación
necesarias, que permitan alcanzar los objetivos previstos.
Una visión general de alcance del proyecto se muestra en la ilustración Visión General del Proyecto.
En esta imagen se muestra el alcance desde 2 Ejes diferentes:
 Eje (parte derecha):

o
Interoperabilidad
Back End
Front End
 Eje (parte izquierda):

o Procesos Operativos
o Procesos Core SCUC
o Componentes
o Principales Productos
o Consultas e interacción y relaciones existentes entre ellos

28
Ilustración 8: Visión General del Proyecto

29
1.4 Enfoque Técnico
1.4.1 Mapa de Procesos
En la ilustración Procesos y Módulos del sistema se muestran una imagen de alto nivel con los
procesos involucrados, de los componentes que serán utilizados para la ejecución de los procesos
core del sistema de cuenta única y los principales productos.
Ilustración 9: Procesos y Módulos del Sistema

30
1.4.1.1 Descripción de los procesos relacionados con la cuenta única del contribuyente
En este apartado del documento se describirán los procesos dentro del ámbito de la cuenta única del
contribuyente. Se establecen dos tipos de descripciones en función de si se trata de un sistema
legado un nuevo módulo o, bien se trata, de los procesos core del sistema de cuenta única.
Para la primera categoría de procesos se presenta una ficha con los siguientes apartados:
 Objetivos y principales características

 Diagrama (no se utilizará para los procesos ejecutados en el sistema legado)
 Trámites del proceso (no se utilizará para los procesos ejecutados en sistema legado)
 Relación de Trámites e Historias de Usuario.
 Tablas maestras (no se utilizará para los procesos ejecutados en sistema legado)
 Consultas (no se utilizará para los procesos ejecutados en el sistema legado)
El orden que se seguirá en la descripción será el mismo que el previsto en las épicas.
Para los procesos core del sistema de cuenta única (Procesos core del sistema de cuenta única
(SCUC)), y, para facilitar la trazabilidad con la arquitectura de aplicaciones se utilizará una
descripción de los procesos que toma como punto de partida el componente que lo ejecuta.
(Ver apartado Procesos correspondientes a nuevos desarrollos o ejecutados en sistemas
legados)
Para mostrar el entendimiento de la funcionalidad que se debe abordar, se presenta en primer

lugar, el mapa de procesos en el que se traslada una visión a alto nivel tanto de los procesos
involucrados como de las propias interacciones existentes entre ellos.

31
Ilustración 10: Mapa de Procesos

“CONTRATACIÓN DEL SERVICIO DE DESARROLLO, PRUEBAS Y PUESTA EN PRODUCCIÓN DEL SISTEMA DE CUENTA ÚNICA DE CONTRIBUYENTE – MVP1 Y MVP2”
32
A) Procesos correspondientes a nuevos desarrollos o ejecutados en el sistema legado
1.4.1.1.1 Compensaciones
OBJETIVO Y CARACTERÍSTICAS PRINCIPALES
 El proceso de compensaciones tiene como objetivo permitir aplicar los montos registrados
en la cuenta única a las deudas de un mismo contribuyente.
 Esta aplicación se efectuará de acuerdo con la parametrización que se haya realizado en el
sistema sobre la correspondencia que deba existir entre el origen del crédito y su posible
aplicación (ver TABLAS MAESTRAS).
 El proceso se podrá ejecutar de forma automática y manual.
DIAGRAMA
TRÁMITES  INICIAR PROCESO, permitirá iniciar el proceso mediante:

DEL o El registro de la solicitud de compensación de crédito
PROCESO o Una acción de oficio o bien
o Un proceso automático del propio sistema.
SUPERINTENDENCIA NACIONAL DE ADUANAS Y DE ADMINISTRACIÓN TRIBUTARIA – SUNAT

“Proyectos para la Consolidación de la Gestión Tributaria y Aduanera”
SPIN° 002-2018-SUNAT/BID-“SERVICIO DE DESARROLLO, PRUEBAS Y PUESTA EN PRODUCCIÓN DEL SISTEMA

DE CUENTA ÚNICA DE CONTRIBUYENTE”
Av. Jorge Basadre N° 233, Of. 901. San Isidro – Teléfono: 488-8888
33
En todos los casos, quedará seleccionado el contribuyente afectado, la
deuda y el crédito a compensar y se procederá a reservar el crédito
seleccionado.
 La reserva del crédito implicará GENERAR MOVIMIENTOS EN LA
CUENTA ÚNICA.
 EVALUAR PROCEDENCIA, permitirá realizar la evaluación de la
procedencia o no de la compensación.
o En el caso de que se trate de la modalidad automática, finalizado este
trámite el sistema iniciará el trámite EMITIR RESOLUCIÓN.
o En el caso de que no se pueda evaluar la procedencia de forma
automática, se deberá iniciar el trámite ASIGNAR CASO.
 ASIGNAR CASO, permitirá que se realice la asignación manual o
automática de casos a evaluar a un usuario con perfil GESTOR. En el caso
de que la asignación sea manual será un usuario con perfil SUPERVISOR
quien realice la asignación de los casos.
 REGISTRAR RESULTADO PRELIMINAR, deberá ejecutarse en los casos
en los que la evaluación del caso no se realizado de forma automática. El
registro del resultado preliminar implicará que el resultado deba ser
confirmado por un usuario con rol suficiente a tal efecto. Este usuario
contará con dos opciones:
o Confirmar el resultado preliminar.
o Devolverlo.
 CONFIRMAR RESULTADO, supondrá corroborar el resultado preliminar
registrado para emitir resolución.
 DEVOLVER, implicará asignar el caso de nuevo al gestor que emitió el
resultado preliminar, quien deberá realizar de nuevo la evaluación del mismo
y volver a registrar un nuevo resultado preliminar.
 EMITIR RESOLUCIÓN, permitirá que se genere la resolución sobre la
procedencia total o parcial o la improcedencia. En cualquiera de los casos,
se deberán generar movimientos en la cuenta única.
o En todos los casos, se levantará la reserva del crédito.
o Si es procedente o procedente parcial, en este último caso, por el
importe que proceda, se generarán movimientos de compensación en
la cuenta única.
o Si es improcedente, únicamente se levantará la reserva del crédito.
 REVERTIR, permitirá que una vez se haya emitido resolución, se reviertan
los resultados de la misma, pasándose a generar los “contra-movimientos”


34
necesarios en la cuenta única para reflejar la situación provocada por la
reversión.
 El sistema también permitirá registrar el DESISTIMIENTO del contribuyente
que podrá tenerse en cuenta antes de emitirse resolución.
TABLAS  Mantener tributos compensables
MAESTRAS  Mantener criterios de uso de créditos
CONSULTAS  Listar solicitudes de compensación
 Consultar detalles de solicitudes de compensación
 Consultar saldos de créditos de Cuenta Única para Uso o Reconocimiento
de Pagos con Error
 Listar tributos compensables
RELACIÓN
DE TRÁMITES HISTORIA DE USUARIO
TRÁMITES E Registrar Solicitud de Compensación de
Iniciar proceso
HISTORIAS créditos
DE USUARIO Iniciar proceso Seleccionar contribuyente
Iniciar proceso Seleccionar crédito de compensación
Generar solicitudes de compensación de
Iniciar proceso
oficio automáticas
Asignar solicitudes de compensación de
Asignar caso
créditos
Resolver Solicitudes de Compensación
Emitir Resolución
de créditos
Generar movimientos en la cuenta
Aplicar compensación en cuenta
única
- ¿Revertir?
- Generar movimientos en la Realizar reversión de compensación
cuenta única
Tabla 1: Compensaciones


35
1.4.1.1.2 Suspensión
OBJETIVOS Y CARACTERÍSTICAS PRINCIPALES
 La suspensión tiene como objetivo que no se tengan en cuenta los saldos sobre los que
se ha ejecutado el proceso hasta que se levante la suspensión de los mismos.
 La evaluación de la procedencia de la suspensión se podrá ejecutar de forma manual o
automática por el sistema.
 Se aplicará la suspensión en los saldos deudores causados por eventos que:
o El sistema no puede resolver automáticamente
o Requieren mayor revisión por parte del usuario
o Requieren respuesta de otros procesos antes de proceder a la emisión de las órdenes
de pago o emisión de resoluciones de multa.
DIAGRAMA
TRÁMITES  INICIAR PROCESO, se producirá a través del:

DEL o Registro manual preliminar de la suspensión
PROCESO o Registro automático de la suspensión
El registro de la suspensión supondrá indicar:
o La fecha de inicio de la suspensión
o El motivo de la suspensión


36
o La fecha de fin de fin de la suspensión (opcional)
procedencia o no de la suspensión.
trámite el sistema iniciará el trámite SUSPENDER.
 SUSPENDER, supondrá GENERAR MOVIMIENTOS EN LA CUENTA
ÚNICA de modo que se producirá la suspensión
 REGISTRAR O MODIFICAR FECHA DE FIN DE SUSPENSIÓN, permitirá
asignar o modificar la fecha de suspensión
 ACTIVAR supondrá GENERAR MOVIMIENTOS EN LA CUENTA ÚNICA,
de modo que se levante la suspensión existente.
TABLAS  Mantener motivos de suspensión manual
MAESTRAS  Mantener criterios de uso de créditos
CONSULTAS  Listar suspensiones
 Consultar detalle suspensión
 Listar motivos de suspensión manual
RELACIÓN TRÁMITES HISTORIA DE USUARIO
DE Iniciar proceso:
TRÁMITES E - Generar documento
Registrar documento de suspensión
HISTORIAS - Generar movimientos en la
DE USUARIO cuenta única
Evaluar procedencia Evaluar documentos de suspensión
Asignar caso Asignar caso de suspensión
Modificar documento de suspensión
Devolver
preliminar
Registrar o Modificar fecha de fin Registrar o Modificar fecha de fin de
de suspensión suspensión


37
Activar Activar o suspender cuenta según plazo
Suspender de suspensión
Generar movimientos en la cuenta Generar documentos de suspensión

única automáticamente
Tabla 2: Suspensión
1.4.1.1.3 Ajuste de diferencias

 Modificar los saldos de las cuentas de deuda y crédito a partir del registro de documentos
de ajuste.
 El proceso se podrá iniciar con el registro de documentos de forma:
o Individual
o Masiva
o Automáticamente por el sistema
DIAGRAMA
TRÁMITES  INICIAR PROCESO, permitirá realizar el registro:

DEL o Manual individual de documentos de ajuste
PROCESO o Manual masivo de documentos de ajuste
o Automático de documentos de ajuste. Generados éstos, se iniciará el
proceso GENERAR MOVIMIENTOS EN LA CUENTA ÚNICA.
En el resto de los casos, el supervisor optará por confirmar el resultado
preliminar iniciándose el proceso GENERAR MOVIMIENTOS EN LA


38
CUENTA ÚNICA o bien podrá devolver al usuario que registro el documento
preliminar el caso para que vuelva a evaluarlo a través del trámite
DEVOLVER.
 GENERAR MOVIMIENTOS EN CUENTA ÚNICA permite realizar el registro
de los movimientos en la cuenta única del contribuyente.
 REVERTIR, en este caso implicará la generación de un nuevo documento
de ajuste que permita invertir / anular el resultado del inicialmente registrado.
TABLAS  Mantener motivos de ajustes
MAESTRAS
CONSULTAS  Listar ajustes
 Consultar detalle de documentos de ajuste
 Listar motivos de ajuste en cuenta
DE Iniciar proceso:
TRÁMITES E - Generar documento
Registro de documento de ajuste
HISTORIAS - Generar movimientos en la
Iniciar proceso:
- Generar documento
Registro masivo de documentos de ajuste
- Generar movimientos en la
cuenta única
Iniciar proceso:
- Generar documento Generar documentos de ajuste
- Generar movimientos en la automáticamente
cuenta única
Aplicar ajustes en cuenta
única
Devolver Modificar ajuste preliminar
- ¿Revertir?
- Generar movimientos en la Realizar reversión de ajuste aplicado
cuenta única
Tabla 3: Ajuste de diferencias


39
1.4.1.1.4 Comunicación de diferencias
 Permitir que el contribuyente solicite la revisión de sus saldos en la cuenta única. Los motivos
de esta solicitud se encontrarán tasados (ver Tablas Maestras)
 Las correcciones se realizarán utilizando las herramientas previstas para Ajustes, Re-
Procesamiento y otras.
DIAGRAMA
 INICIAR PROCESO, permitirá que el contribuyente presente una solicitud

de revisión de saldos o coeficientes electrónica en la que indique las
TRÁMITES
diferencias detectadas y el sustento de las mismas.
DEL
 El sistema de forma automática o el supervisor ejecutarán el trámite
PROCESO
ASIGNAR CASO de modo que el caso quedará asignado a un gestor que
procederá a EVALUAR LA PROCEDENCIA.


40
 REGISTRAR RESULTADO PRELIMINAR permitirá que el gestor indique
su parecer sobre la solicitud que quedará pendiente de confirmar por su
supervisor.
 El supervisor podrá confirmar o no el resultado preliminar.
 EMITIR RESOLUCIÓN, se ejecutará cuando el supervisor confirme el
resultado preliminar del gestor iniciándose el proceso GENERAR
MOVIMIENTOS EN LA CUENTA ÚNICA y comunicándose el resultado al
contribuyente.
TABLAS  Mantener motivos de comunicación de diferencias
MAESTRAS  Mantener lista de conceptos (cuentas y coeficientes)
 Listar comunicaciones de diferencias
 Consultar detalle de comunicaciones de diferencias en cuenta
CONSULTAS
 Listar motivos de comunicación de diferencias
 Listar conceptos (cuentas y coeficientes)
DE Registrar comunicación de diferencias de
Iniciar proceso
TRÁMITES E saldos
HISTORIAS Asignar casos de comunicación de
Asignar caso
DE USUARIO diferencias pendientes
Resolver solicitud de comunicación de
Emitir Resolución
diferencias con cuenta
Generar movimientos en la cuenta Aplicar documento de diferencias en
única cuenta
- ¿Revertir?
Realizar reversión de Comunicación de
diferencias
cuenta única
Tabla 4: Comunicación de diferencias
1.4.1.1.5 Reconocimiento de pagos con error

 Permitirá corregir el código de tributo asignado a una boleta de pago. Así permitirá el uso de
pagos registrados (pagos indebidos o en exceso, pagos anticipados o pagos imputados con
error) para que sean dirigidos a deudas del mismo contribuyente, siempre que se cumpla lo


41
parametrizado (ver Tablas Maestras) como correspondencia entre orígenes del crédito y su
aplicación.
DIAGRAMA

DEL o El registro de la solicitud del contribuyente
PROCESO o Una acción de oficio
En todos los casos, se procederá a reservar el crédito seleccionado.
 La reserva del pago implicará GENERAR MOVIMIENTOS EN LA CUENTA
ÚNICA.
procedencia o no del caso.


42
o Devolverlo.
procedencia o no de la solicitud. En cualquiera de los casos, se deberán
generar movimientos en la cuenta única.
o Si es procedente se generarán movimientos de aplicación de pago en
la cuenta única.
o Si es improcedente, únicamente se levantará la reserva del pago.
reversión.
TABLAS  N/A
MAESTRAS
CONSULTAS  Listar solicitudes de reconocimiento de pago con error
 Consulta de solicitudes de reconocimiento de pago con error
 Listar motivos de comunicación de diferencias
DE


43
TRÁMITES E Generar solicitudes de reconocimiento de
Iniciar proceso
HISTORIAS pago con error de oficio automáticas
DE USUARIO Registrar solicitud de reconocimiento de
Iniciar proceso
pago con error
Seleccionar crédito para reconocimiento
Iniciar proceso
de pago con error
Asignar solicitudes de reconocimiento de
Asignar caso
pago con error
Resolver caso de solicitud de
Emitir Resolución
reconocimiento de pago con error
- ¿Revertir?
Realizar reversión de reconocimiento de
pago con error
cuenta única
Generar movimientos en la cuenta Aplicar reconocimiento de pagos con error
única en cuenta
Tabla 5: Reconocimiento de pagos con error


44
1.4.1.1.6 Modificación de datos
 Permitirá la corrección de datos de declaraciones y pagos que no pueden ser modificados
vía rectificatoria.
DIAGRAMA

DEL o El registro de la solicitud de modificación de datos del contribuyente
PROCESO o Una acción de oficio
 La deuda quedará pendiente de resolución implicará GENERAR
MOVIMIENTOS EN LA CUENTA ÚNICA.


45
o Devolverlo.
procedencia o no de la solicitud. En cualquiera de los casos, se deberán
generar movimientos en la cuenta única.
o En todos los casos, se levantará la marca de la deuda como pendiente
de resolución.
o Si es procedente se procederá a la modificación del formulario y,
cuando sea necesario, al recálculo de las cuentas afectadas.
o Si es improcedente, únicamente se levantará la marca de deuda
pendiente de resolución.
reversión.
TABLAS  Mantener campos modificación de campos
MAESTRAS
CONSULTAS  Listar solicitudes de modificación de datos
 Consultar detalles solicitudes de modificación de datos


46
 Listar campos modificación de datos
DE Registrar de solicitud de modificación de
TRÁMITES E Iniciar proceso datos
HISTORIAS Iniciar proceso Generar solicitudes de modificación de
DE USUARIO datos de oficio automáticas
Asignar caso Asignar casos de modificación de datos
Emitir Resolución Resolver casos de modificación de Datos
- ¿Revertir?
Realizar reversión de modificación de
datos
cuenta única
Aplicar solicitud de modificación de datos
única
Tabla 6: Modificación de datos


47
1.4.1.1.7 Veredicto rectificatorias
 Emitir un veredicto para aplicar en la cuenta única los incrementos de saldo a favor del
contribuyente como consecuencia de la presentación de una declaración jurada
rectificatoria.
 El proceso de emisión del veredicto sobre rectificatorias se encuentra sujeto a plazo. En el
caso de que se supere el plazo, sin haberse emitido veredicto, se considerará aceptada la
rectificatoria.
DIAGRAMA
TRÁMITES  INICIAR PROCESO, se producirá a través del:

DEL o Declaración Jurada Rectificatoria
PROCESO  EVALUAR PROCEDENCIA, permitirá realizar la evaluación de la


48
o Devolverlo.
procedencia o no de la solicitud. Si es procedente se procederá a
incrementar el saldo a favor del contribuyente.
reversión.
TABLAS  N/A
MAESTRAS
CONSULTAS  Listar declaraciones juradas rectificatorias pendientes de veredicto
 Listar veredictos de rectificatoria
 Consultar veredictos de rectificatoria
 Consultar Resoluciones de Intendencia por Veredictos de Rectificatoria
DE Registro de documento de veredicto de
Iniciar proceso
TRÁMITES E rectificatoria
HISTORIAS Devolver Editar o eliminar veredicto borrador
DE USUARIO


49
Aplicar veredicto de rectificatoria
única
Selección automática de rectificatorias
Asignar caso
para veredicto manual
Veredicto automático por silencio
Emitir Resolución
administrativo
Asignar caso Asignar Veredictos pendientes
- ¿Revertir?
Realizar reversión de veredicto de
rectificatoria
cuenta única
Tabla 7: Veredicto rectificatorias
1.4.1.1.8 Devoluciones
 Permitir registrar en la cuenta única un débito por devolución
DESCRIPCIÓN


50
DEL o El registro de la solicitud de devolución
o Un proceso automático del propio sistema.
CUENTA ÚNICA.
procedencia o no de la devolución.
o Devolverlo.
importe que proceda se generarán débitos de devolución en la cuenta
única.


51
reversión.
TABLAS  N/A
MAESTRAS
CONSULTAS  Consultar detalles de solicitud de devolución
 Listar solicitudes de devolución
DE Generar movimientos en la cuenta
Aplicar devolución en cuenta
TRÁMITES E única
HISTORIAS Iniciar proceso Registrar solicitud de devolución
DE USUARIO
Asignar caso Asignar solicitudes de devolución
Emitir Resolución Resolver casos de devolución
- ¿Revertir?
- Generar movimientos en la Realizar reversión de devolución
cuenta única
Generar solicitudes de devolución de
Iniciar proceso
oficio automáticas
Tabla 8: Devoluciones
B) Procesos core del sistema de cuenta única (SCUC)
1.4.1.1.9 Aplicar documento en cuenta única

En este apartado del documento se explicará el core de la cuenta única a través de cada uno de sus
componentes.
1.4.1.1.9.1 Agente Extractor de Datos

Es el componente responsable de:
 Capturar los datos en los sistemas legados y someterlos a procesamiento, garantizando

que no se perderá información alguna.
 Reprocesar la información.


52
El agente extractor de datos extraerá los datos de los sistemas legados con la finalidad de obtener
un “documento origen o solicitud”. Se registrará la ejecución del proceso de extracción de datos
efectuado y un estado a cada uno de los datos extraídos
En el caso de que se haya ejecutado el proceso con error, de acuerdo con los parámetros previstos
se procederá al reproceso de la información recibida.
Pendi ente
Envía do nube
Proces a do con éxi to
Proces a do con error ERROR
Si el proceso se ha ejecutado con éxito, con los datos extraídos se genera el “documento origen
o solicitud” que estará formado por:
 Cabecera de documento o Encabezado

 Detalle del documento
 Casillas
Existirán diferentes tipos de documentos de origen que podrán ser mantenidos a través de las
opciones de configuración del sistema. Cada uno de estos tipos de documento origen contarán con
unas casillas de información de concretas que serán tratadas a nivel de tablas maestras.
PROCESO ASOCIADO Extraer datos
1.4.1.1.10 Motor
Es el conjunto de componentes responsables de procesar la información. Estos componentes son
los siguientes:
 Configuración
 Validación
 Motor de documentos normalizados (DN)
 Cálculo de DN
 Motor de Lanzamiento


53
Ilustración 11: Componentes del Motor
Ilustración 12: Relación de los componentes del Motor
1.4.1.1.11 Configuración
El componente de Configuración es el responsable de administrar la configuración de los
componentes: Validación, Motor de DN y Motor de Lanzamiento.


54
Ilustración 13: Componente de Configuración
A través del componente de configuración se permitirá realizar la administración de las:
 Reglas de validación
 Reglas de normalización
 Reglas de registro de movimientos
Las reglas de validación son utilizadas por el componente de Validación en el proceso de

validación de datos.
Las reglas de normalización son utilizadas por el componente de Motor de Documentos

Normalizados en los procesos Registrar Documentos Normalizados y Calcular Documento
Normalizados.
1.4.1.1.12 Componente de Validación

Es el componente responsable de asegurar que los “documentos origen o solicitudes”
cumplen las reglas de validación.


55
Ilustración 14: Componente de Validación
El proceso Validar Datos toma el documento origen o solicitud y aplica las reglas de validación,
obteniéndose como producto del mismo el Documento Origen o Solicitud Completado.
PROCESO ASOCIADO Validar Datos
1.4.1.1.13 Componente Motor de DN

El componente Motor de DN será el responsable de:
 Generar los documentos normalizados que, después, serán objeto de tratamiento a través
del Motor de Lanzamiento. (determina la fórmula).
Estos documentos serán generados tomando como punto de partida el “documento origen
o solicitud” completado.
 Enriquecer los documentos normalizados generados mediante la aplicación de fórmulas
de cálculo sobre sus casillas. (aplica la fórmula)
 Los documentos normalizados dispondrán de los siguientes datos:
Documento Normalizado (DN) asignados por el Sistema
1 Tipo proceso de Identifica el tipo de proceso de negocio o documento que

negocio origina el DN
2 N° de Orden del DN Número de orden correlativo asignado al DN
3 Fecha y hora de Fecha y hora del proceso de generación del DN

generación del DN


56
Documento Normalizado (DN) asignados por el Sistema
4 Indicador de estado Indica el estado del DN(1 =generado2 = revertido)
5 Indicador de proceso Indica si el DN se encuentra procesado en Cuenta Única

(1 = procesado2 = no procesado)
6 Indicador de Indica si el DN se ha originado por un reproceso y de ser

Reproceso el caso si es automático o a pedido
Tabla 9: Documento Normalizado (DN) asignado por el Sistema
Documento Sustento (Proceso de Negocio)
1 RUC Número de RUC del contribuyente que origina el proceso

de negocio
2 Documento de Código de formulario sustento (DJ, boleta, solicitud,
sustento Comunicación, resolución, número de ajuste, número de
re imputación, etc.)
3 Número de orden del Número de orden de formulario sustento
documento de
sustento
4 Tributo Código de tributo del documento sustento
5 Fecha y hora del Fecha y hora de ingreso del documento sustento en el

documento de sistema de origen
sustento
6 Origen de DJ Indica si la DJ fue realizada por el contribuyente o por LA
SUNAT.
7 Tipo de DJ 0 = Original1= sustitutoria 2 = rectificatoria pendiente3 =
rectificatoria aceptada y 4 = rectificatoria rechazada
8 Fecha de Fecha por último dígito de RUC, vencimiento especial o
vencimiento nueva fecha en caso de modificación de fecha de
vencimiento
9 Moneda 1 = Soles2 = dólares …(otras monedas según parámetro)
10 Tipo de resultado Indica si el resultado es aceptado o denegado o si la

resolución, de ser el caso, es procedente, procedente en
parte, improcedente o inadmisible
Tabla 10: Documento Sustento (Proceso de Negocio) - Documento "Origen o Solicitud"


57
Otros datos específicos (Proceso de Negocio)
1 Cantidad de Cuotas Número de cuotas que conforma la deuda Aplica para los
casos de fraccionamiento y de DJ de ITAN.
2 RUC responsable Número de RUC del contribuyente que se le atribuyó la

deuda o del crédito (para casos de reorganización de
empresas, por ejemplo)
3 Documento de Documento que da origen al proceso o trámite y por el

origen que se tiene el tipo de resultado
4 Número de orden de Número de orden del documento que da origen al

documento de origen proceso o trámite y por el que se tiene el tipo de resultado
5 Indicador de Casillas El campo “Indicador de Casillas Diferentes” 2 tiene los

con Diferencias siguientes valores:
0 = Sin casillas diferentes
1 = Con casillas diferentes

Tabla 11: Otros datos específicos de los Procesos de Negocio
Conceptos a Normalizar
Concepto Casilla o Concepto a normalizar
Indicador de regla Indica la funcionalidad del concepto normalizado(1 = Crea2

= Usa3 = Anula)
RUC Número de RUC del contribuyente (por ejemplo, para
modificación de datos)
Período tributario Período tributario del documento sustento o documento

origen
Código de tributo Código de tributo del documento sustento o documento

origen
Código de Código de tributo asociado del documento sustento o

tributo documento origen
asociado
Número de Código del documento sustento o documento origen (DJ,
documento de valor, RI, etc.)
sustento del insumo


58
Conceptos a Normalizar
Número de orden del Número de orden del documento sustento

documento de
sustento del insumo
Fecha y hora de Fecha y hora de generación del débito o crédito o de
generación aplicación o uso del crédito (coexistencia), de ser el caso.
aplicación o uso
Importe del tributo Monto de tributo del documento de crédito o de deuda.
Interés capitalizado Monto de interés capitalizado del documento.
Interés moratorio Monto de interés moratorio del documento.
Saldo disponible del Saldo disponible del crédito en la cuenta antes de su

crédito en la cuenta aplicación a la deuda mediante este documento.
Tabla 12: Conceptos a Normalizar
 Utilizará las reglas de normalización del componente Configuración.
Ilustración 15: Componente Motor de Documentos Normalizados:
PROCESO  Registrar Documentos Normalizados

ASOCIADO  Calcular Documento Normalizado


59
 El proceso Registrar Documentos Normalizados a través del Motor de Documentos
Normalizados generará el “Documento Normalizado”.
 El proceso Calcular Documento Normalizado a través del componente Cálculo de
Documentos Normalizados completará el documento normalizado obteniéndose el
“Documento Normalizado Enriquecido”.
1.4.1.1.14 Componente Motor de Lanzamiento

 El componente Motor de Lanzamiento se responsabilizará de generar los movimientos de
la cuenta única aplicando sobre los documentos normalizados enriquecidos las reglas
de Registro de Movimientos.
 Estos movimientos se registrarán en la cuenta única del contribuyente.
Ilustración 16: Motor de Lanzamiento
 Los movimientos generados por el Motor de Lanzamiento siempre dispondrán del

atributo: “Tipo” y podrán contar con la asignación de un impuesto y de su vencimiento,
o no, según los casos.
 Será la combinación de estas tres variables la que permita que se inserten
en una de las siguientes cuatro tipologías de cuentas:


60
Ilustración 17: Tipología de cuentas
 Las cuentas de deuda reflejarán la posición deudora del contribuyente y acreedora de la

Administración.
 Las cuentas de crédito reflejarán la posición acreedora del contribuyente y deudora de
la Administración.
 Las cuentas de control se utilizarán para controlar y asegurar la coherencia de los
formularios y solicitudes presentados por el contribuyente.
 Las cuentas transitorias tendrán como objeto la reserva de deudas, créditos o saldos
mientras los mismos no son firmes.
 Estas cuentas dispondrán de “subcuentas” según el siguiente cuadro:
Cuenta Subcuenta Tributo Descripción Tributo

Cuenta de Saldos deudores Todos los tributos que generan
Deuda Varios
TI deuda
Tributos relacionados a
Deuda Cuenta de Sanciones TI Varios
infracciones
Cuenta de Valores (OP, RM, Todos los tributos que generan
Deuda Varios
RD, RI) deuda
Todos los tributos que generan
Deuda Cuenta de Fraccionamiento Varios
deuda
Todos los tributos que por normas
Saldos a Favor vigentes permiten generar saldo a
Crédito Varios
Declaraciones Mensuales favor por declaraciones juradas
mensuales
RTA.-REGULARIZ.-
30702
RTA.1RA.CATEG. RTA.-
Saldos a Favor 30703
Crédito REGULARIZ.-RTA. DE TRABAJO
Declaraciones Anuales 30704
RTA.-REGULARIZ.-
30801
RTA.2DA.CATEG.


61
RENTA - REGULAR. - 3RA.
CATEG. RENTA -
Impuesto Temporal a los Activos

Crédito Pagos del ITAN contra renta 30308
Netos (ITAN)
Saldo a favor materia de
Crédito 10101 IGV - OPER. INT. - CTA. PROPIA
beneficio
Todos los tributos por los que se
Crédito Pagos Todos
pueden hacer pagos
Crédito Pagos anticipados Todos
pueden hacer pagos
Crédito Pagos en exceso Todos
pueden hacer pagos
Crédito Pagos indebidos Todos
pueden hacer pagos
Crédito Cuenta Tributo Descripción Tributo
Todos los tributos que las normas
Pagos con documentos
Crédito Varios vigentes permiten realizar con
valorados
documentos valorados
Documentos valorados Corresponden a todos los tipos de
Crédito Varios
electrónicos documentos valorados
Pagos por ingreso como
Crédito 80703 Traslado de montos de cuentas
recaudación
RENTA - REGULAR. - 3RA.
Crédito Pérdidas tributarias 30801
CATEG.
Pagos a cuenta en exceso de RENTA-3RA. CATEGOR.-
Crédito 30301
renta CTA.PROPIA
Retenciones del IGV – sujeto IGV-REG.PROVEEDOR.-
Crédito 10302
retenido RETENCIONES
IGV - GRAL. PERCEPCION
Percepciones del IGV ADUANAS
10503
(internas, hidrocarburos, IGV - PERCEPCION VENTA
Crédito 10504
importación) – sujeto INTERNA
10502
percibido IGV-REG.PERCEPCION
HIDRICARBUROS


62
Pagos a cuenta de renta de RENTA-1RA. CATEGOR.-
Crédito 30101
1ra. Categoría CTA.PROPIA
Pagos a cuenta de renta de RENTA-2DA. CATEGOR.-
Crédito 30201
2da. Categoría CTA.PROPIA
Pagos a cuenta de renta de
Crédito 30301 RENTA – 3RA. CATEGOR.
3ra. Categoría
Retenciones de renta de RENTA-2DA. CATEG.-
Crédito 30202
2da.Categoría RETENCIONES
Pagos a cuenta de renta de RENTA-4TA. CATEGOR.-
Crédito 30401
4ta. Categoría CTA.PROPIA
Retenciones de renta de 4ta. RENTA-4TA. CATEGOR.-
Crédito 30402
Categoría RETENCIONES
Crédito 30501 RENTA-5TA.- CTA. PROPIA
5ta. Categoría
Retenciones renta de 5ta. RENTA 5TA. CATEG.
Crédito 30502
Retenciones de Renta de 3ra RETENC. RTA. 3RA CAT.
Crédito 30302
Categoría FIDEICOM
IGV – No domiciliados
Pago de tributos no 10401
Crédito Los demás conceptos cuyo saldo
declarativos Varios
deudor no se controlará en cuenta
Pagos por Regalía
Crédito Contractual contra 71403 REGALÍAS MINERAS LEY 29788
Gravamen Minero
Pagos por Regalía Ley
REGALÍAS MINERAS – LEY
Crédito 28258 contra Gravamen 71401
28258
Minero
Retenciones IGV – para el IGV-REG.PROVEEDOR.-
Control 10302
Sujeto retenido RETENCIONES
Retenciones IGV – para el IGV-REG.PROVEEDOR.-
Control 10302
agente RETENCIONES
10503
Percepciones IGV -– para el ADUANAS
Control 10504
Sujeto retenido IGV - PERCEPCION VENTA
10502
INTERNA


63
IGV - REG. PERCEPCIÓN
HIDROCARBUROS

ADUANAS
10503
Percepciones IGV– para el IGV - PERCEPCION VENTA
Control 10504
agente INTERNA
10502
IGV - REG. PERCEPCIÓN
HIDROCARBUROS
Control Exportación de servicios 10101 IGV mensual
Pagos a cuenta de renta de RENTA-1RA. CATEGOR.-
Control 30101
1ra. Categoría Pagos CTA.PROPIA
Pagos a cuenta de renta de RENTA-2DA. CATEGOR.-
Control 30201
2da. Categoría Pagos CTA.PROPIA
Control 30301 RENTA – 3RA. CATEGOR.
3ra. Categoría Pagos
Retenciones de renta de 2da. RENTA-2DA. CATEG.-
Control 30202
Categoría Pagos RETENCIONES
IMP.TRANS.FINANC.-
Control Retenciones ITF 81302
RETENCION
Pagos a cuenta de renta de RENTA-4TA. CATEGOR.-
Control 30401
4ta. Categoría Pagos CTA.PROPIA
RENTA-4TA. CATEGOR.-
Control Retenciones 4ta. Categoría 30402
RETENCIONES
Control 30501 RENTA-5TA.- CTA. PROPIA
5ta. Categoría Pagos
IMP.TRANS.FINANC.-
Control ITF 81301
CTA.PROPIA
Retenciones renta de 5ta. RENTA 5TA. CATEG.
Control 30502
Retenciones de Renta de 3ra RETENC. RTA. 3RA CAT.
Control 30302
Categoría FIDEICOM
RENTA-1RA. CATEGOR.-
Control Rentas de 1ra Categoría 30101
CTA.PROPIA
30401 RENTA-4TA. CATEGOR.-
Control Rentas de 4ta Categoría
30402 CTA.PROPIA


64
RETENCIONES
30501 CTA.PROPIA
Control Rentas de 5ta Categoría
30502 RENTA-5TA.CATEGOR.-
RETENCIONEScorregido
Provenientes de información de
comprobantes de pago e
Control Gastos deducibles Varios información de pagos de
impuestos, contra rentas de trabajo
y/o de fuente extranjera anual.
Pagos de tributos no Para cuando son invocados en un
Control Varios
declarativos proceso no contencioso.
Cuentas que permiten la partida
Control Cuentas de Contrapartida Varios doble para el registro de las
transacciones
Cuenta Transitoria de Todos los tributos que generan
Transitorias Varios
Deudas en Revisión deuda
Cuenta Transitoria de Todos los tributos que generan
Transitorias Varios
Créditos en Revisión créditos y saldos a favor
Saldos deudores Todos los tributos que generan
Transitorias Varios
preliminares deuda
Transitorias Saldos a favor preliminares Varios
créditos y saldos a favor
Saldos de infracciones
Transitorias Varios Todas las infracciones
preliminares
Cuenta de Saldos deudores
Deuda DAM, DS, LC (Tributos Varios
deuda
Aduaneros)
Cuenta de Valores TA (LC) Todos los tributos que generan
Deuda Varios
(Tributos Aduaneros) deuda
Cuenta de Peco (Tributos Pago que corresponde al beneficio
Crédito Varios
Aduaneros) otorgado
Cuenta de Amazonía Pago que corresponde al beneficio
Crédito Varios
(Tributos Aduaneros) otorgado


65
Cuenta de Drawback Pago que corresponde al beneficio
Crédito Varios
(Tributos Aduaneros) otorgado
Pagos en exceso o indebidos Todos los tributos de Aduanas por
Crédito Varios
(Tributos Aduaneros) los que se puede hacer pagos
Tabla 13: Subcuentas
PROCESO ASOCIADO  Registrar Movimientos en Cuenta Única
La Cuenta Única será “única” por contribuyente o usuario de comercio exterior. Para lograr esa
unicidad se atenderá a la presencia del mismo documento de identificación pudiéndose contemplar
los siguientes:
 RUC – Registro Único de Contribuyente
 Pasaporte
 DNI – Documento Nacional de Identidad
 Carné de Extranjería
La cuenta única contendrá los movimientos generados y se le asignará un estado.
Se dispondrá de las siguientes consultas sobre la cuenta única:
 Documentos normalizados
 Cuenta de deuda, de crédito y transitorias
 Cuentas de control
 Consulta de situación general de la cuenta del contribuyente
 Saldos deudores
 Consulta de la liquidación de la declaración
 Consulta de seguimiento de documentos y eventos
 Consulta de liquidación de declaraciones con arrastre de créditos por varios periodos
 Información personalizada para las DDJJ
 Consulta por movimientos
 Consulta de consistencia
 Consulta general de valores


66
Ilustración 18: Consultas


67
1.4.1.1.15 Correcciones en cuenta única
Agrupa un conjunto de funcionalidades que permiten realizar correcciones en la cuenta única
cuando se han producido errores en la especificación o aplicación de las reglas de normalización,
reglas de registro de movimientos.
Estas funcionalidades se ejecutarán en:
 La re-normalización de documentos
 La aplicación de los movimientos a la cuenta única (procesamiento de documentos
normalizados).
DIAGRAMA

DEL o El registro de un documento de modificación de prorrata de cálculo de
PROCESO IGV
o La generación de un documento de modificación de coeficiente de
Renta automática o masiva


68
o La generación de un documento de modificación de prorrata IGV
automática o masiva.
procedencia o no de la corrección.
o Devolverlo.
procedencia total o parcial o la improcedencia:
o Re-proceso individual de cuentas
o Re-proceso masivo de cuentas
o Re-normalización de documentos
o Re-proceso de documento normalizado,
Generándose movimientos en la cuenta única.
reversión.
TABLAS  N/A
MAESTRAS
CONSULTAS  Listar documentos de modificación de prorrata para el cálculo de IGV
 Consultar detalle de doc. de modificación de prorrata para el cálculo de IGV
 Listar documentos de modificación de coeficiente de Renta


69
 Consultar documento de modificación de coeficiente de Renta
DE Registrar documento de modificación de
TRÁMITES E prorrata cálculo de IGV
HISTORIAS Generar documento de modificación de
Iniciar proceso
DE USUARIO prorrata IGV automática o masiva
Generar documento de modificación de
coeficiente de Renta autom. o masiva
Registrar documento de modificación de
Emitir Resolución
coeficiente de Renta
Generar movimientos en la cuenta Aplicar documento de modificación de
única prorrata para el cálculo de IGV
Generar movimientos en la cuenta Aplicar documento de modificación de
única coeficiente de Renta
Re-proceso individual de cuentas Re-proceso individual de cuentas
Re-proceso masivo de cuentas Re-proceso masivo de cuentas
Re-normalización de documentos Re-normalización de documentos
Re-proceso de documento
Re-proceso de documento normalizado
normalizado
- ¿Revertir?
Realizar reversión de documento de mod.
de prorrata para cálculo de IGV
cuenta única
- ¿Revertir?
Realizar reversión de documento de
modificación de coeficiente de Renta
cuenta única
Modificar documento preliminar de
Devolver
modificación de coeficiente de Renta
Modificar doc. preliminar de modificación
Devolver
de prorrata para el cálculo de IGV
Tabla 14: Correcciones en cuenta única


70
1.4.1.1.16 Detracciones
 Permitir el uso de montos de los ingresos como recaudación registrados en la cuenta única
para que sean aplicados a deudas del mismo contribuyente.
 Deberá existir una correspondencia entre el origen y el destino (ver Tablas maestras).
DIAGRAMA

DEL o El registro de la solicitud del contribuyente
CUENTA ÚNICA.
procedencia o no de la reimputación.


71
o Devolverlo.
importe que proceda se generarán movimientos de reimputación en la
cuenta única.
reversión.
TABLAS  Origen / Destino del Crédito
MAESTRAS
CONSULTAS  Listar solicitudes reimputación de cuentas de ingreso (Detracciones)
 Consultar solicitudes de reimputación de cuentas de ingreso Detracciones


72
DE - ¿Revertir?
Realizar reversión de reimputación de
TRÁMITES E - Generar movimientos en la
cuentas de ingreso
HISTORIAS cuenta única
DE USUARIO Seleccionar créditos de Cuenta de
Iniciar proceso
Ingreso como Recaudación SUNAT
Solicitud reimputación de cuenta de
Iniciar proceso
ingreso (Detracciones)
Asignar caso Asignar solicitudes de reimputacion
Resolver casos de reimputación de

Emitir Resolución
cuentas de ingreso (Detracciones)
Generar movimientos en la cuenta Aplicar casos de reimputación de cuentas
única de ingreso (Detracciones)
Generar solicitud de reimputación de
Iniciar proceso
montos en cuenta de ingreso
Tabla 15: Detracciones
1.4.1.1.17 Formularios y documentos de cuenta única

 Los formularios y los documentos que se utilicen en todos los procesos deberán ser
objeto de parametrización a través del sistema.
 Los documentos generados y registrados deben ser consultables tanto por el
contribuyente como por los usuarios del sistema, debiéndose ofrecer también el estado
en el que se encuentra el proceso.
DIAGRAMA
N/A.
TRÁMITES  N/A
DEL PROCESO
TABLAS  Configurar formularios
MAESTRAS  Configurar versiones
 Configurar casillas
 Configurar plantillas
 TABLAS MAESTRAS numeración correlativa de valores y resoluciones
CONSULTAS  Listar documentos de cuenta única
 Visualizar documentos de cuenta única
 Listar solicitudes del contribuyente


73
 Listar formularios
 Listar versiones
 Listar casillas
 Listar plantillas
RELACIÓN DE
TRÁMITES E
 N/A
HISTORIAS DE
USUARIO
Tabla 16: Formularios y documentos de cuenta única
1.4.1.1.18 Presentar declaración jurada

 Se realiza desde los sistemas: Plataforma Única de Declaraciones y Pagos y Red Bancaria
(Pago Fácil).
 Estos sistemas deben integrarse con la cuenta única para recibir datos que forman parte de
la declaración y de los procesos de liquidación.
 De otra parte, una vez presentada la declaración jurada, los datos de estos sistemas se
someterán a los procesos de cuenta única para que formen parte de la cuenta única del
contribuyente.
DIAGRAMA
N/A. Existirá integración con los Sistemas legados.
TRÁMITES  N/A
DEL
PROCESO
TABLAS  N/A
MAESTRAS
CONSULTAS  N/A
TRÁMITES HISTORIA DE USUARIO
RELACIÓN Liquidar Liquidar declaración jurada
DE Generar cuenta de control de Renta y
Generar cuenta de control
TRÁMITES E Retenciones de Renta
HISTORIAS Generación de créditos al vencimiento de
Generación de crédito
DE USUARIO renta anual
Validar DJ Rectificatoria Validaciones DJ Rectificatoria
Tabla 17: Presentar declaración jurada


74
1.4.1.1.19 Registrar órdenes de pago
 Permitir generar las órdenes de pago desde la cuenta única del contribuyente en aquellos
casos en los que se ha superado el plazo de pago de las declaraciones juradas sin haberse
realizado el mismo.
 Permitir integrar estos datos con los sistemas legados.
DIAGRAMA
N/A
TABLAS  N/A
MAESTRAS
TRÁMITES  N/A
DEL
PROCESO
CONSULTAS  N/A
DE Emitir Orden de Pago Emitir Órdenes de Pago
TRÁMITES E - ¿Revertir?
HISTORIAS - Generar movimientos en la Realizar reversión de Orden de Pago
Tabla 18: Registrar órdenes de pago
1.4.1.1.20 Comprobantes electrónicos

 Los comprobantes electrónicos de pago se registrarán en la cuenta de control del Sistema
de Comprobantes Electrónicos.
 A partir de esta información se permitirá que se puedan formar bases imponibles, casillas de
deducciones y de créditos a utilizar por los contribuyentes en las declaraciones juradas.
 En el caso de la declaración de IGV se generarán cuentas de control de retenciones y de
percepciones del agente y del sujeto retenido y de exportaciones de servicios.
 En el caso de la declaración de Renta se generarán cuentas de control de retenciones por
rentas de cuenta propia, por retenciones de rentas y por gastos deducibles correspondientes
a honorarios profesionales, así como por comprobantes de pago emitidos por alojamientos
en hoteles o consumos en restaurantes y bares.
DESCRIPCIÓN
N/A


75
TRÁMITES  N/A
DEL
PROCESO
TABLAS  N/A
MAESTRAS
CONSULTAS  N/A
RELACIÓN
TRÁMITES E Generación automática de
Generación automática de créditos
HISTORIAS créditos
DE USUARIO
Tabla 19: Comprobantes electrónicos
1.4.1.1.21 Recepción de pagos

 Permitir determinar la naturaleza y el destino del pago, pudiendo aplicar el movimiento a una
deuda existente o determinar si éste tiene características de pago indebido o en exceso.
 También permitirá de modo asíncrono ejecutar un proceso de ajuste automático por
tolerancia.
 Determinados pagos generan cuentas de créditos que se aplican al impuesto resultante de
declaraciones juradas, pero, también generan cuentas de control a través de la información
que brinda el formulario de pago, como la base imponible o los ingresos sobre los que se
calculó el impuesto pagado. Estas cuentas de control corresponden a determinados gastos
que la ley permite deducir para determinar la renta imponible.
DIAGRAMA
N/A
TRÁMITES  N/A
DEL
PROCESO
TABLAS  N/A
MAESTRAS
CONSULTAS  N/A

DE Generar cuenta de control de Generar cuenta de control de pago a
TRÁMITES E pago a Renta Renta


76
HISTORIAS Imputar pago Imputar pago
DE USUARIO Extorno de pagos Extorno de pagos
- ¿Revertir?
- Generar movimientos en la Reversión de pago
cuenta única
- ¿Revertir?
- Generar movimientos en la Reversión de extorno de pago
cuenta única
Tabla 20: Recepción de pagos
1.4.1.1.22 Infracciones
 Permitir registrar los movimientos correspondientes a las sanciones.
 Permitir registrar los movimientos de rebaja de la sanción por subsanación de la infracción.
 Permitir registrar los movimientos correspondientes a las Resoluciones de Multa.
DIAGRAMA
N/A
TRÁMITES  N/A
DEL
PROCESO
TABLAS  N/A
MAESTRAS
CONSULTAS  Consulta de documentos de infracciones
Dar de Baja Infracción Realizar baja de Infracción
Emitir Infracción por omisión a la Emitir infracción por omisión a la
presentación presentación
Generar Infracción por
RELACIÓN Generar infracción por rectificación
rectificación (Declarar datos
DE (Declarar datos falsos)
falsos)
TRÁMITES E
Generar infracción por
HISTORIAS Generar infracción por retenciones y
retenciones y percepciones no
DE USUARIO percepciones no pagadas
pagadas
Calcular gradualidad infracción Calcular gradualidad infracción
- ¿Revertir?
- Generar movimientos en la Realizar reversión de RM
cuenta única


77
Emitir RM automática Emitir RM automática
Reproceso de detección de
Reproceso de detección de infracciones
infracciones
Registro de infracciones de Registro de infracciones de procesos
procesos independientes independientes
Tabla 21: Infracciones
1.4.1.1.23 Registro manual de valores

 Permitir registrar en la cuenta única los movimientos que deben ajustar las cuentas de saldos
deudores o de infracciones como consecuencia de la emisión de valores manual, prevista
para casos de contingencia en los que no se puede efectuar el ajuste a través de los
procesos automáticos existentes.
DIAGRAMA
N/A
TRÁMITES  N/A
DEL
PROCESO
TABLAS  N/A
MAESTRAS
CONSULTAS  N/A
RELACIÓN
DE
TRÁMITES E
Ajuste por emisión de OP y RM Ajuste por emisión de OP y RM
HISTORIAS
DE USUARIO
Tabla 22: Registro manual de valores
1.4.1.1.24 Créditos con posible prescripción

 Ejecución de un proceso que permita identificar los créditos en los que se haya incurrido en
posible prescripción.
 El proceso podrá encontrarse planificado o bien ser ejecutado a petición de usuario.
 El sistema permitirá obtener un reporte con la identificación de los créditos que cumplan con
los requisitos para considerarlos prescritos.


78
 La observación de la prescripción podrá iniciarse de oficio o bien a petición del interesado
debiéndose tener en cuenta no sólo la antigüedad del crédito sino también todos aquellos
eventos que hayan podido interrumpido o suspendido el plazo de prescripción.
DIAGRAMA
N/A
TRÁMITES  N/A
DEL
PROCESO
TABLAS  N/A
MAESTRAS
CONSULTAS  N/A
RELACIÓN
TRÁMITES E Generar reporte preliminar de créditos
Reporte
HISTORIAS prescritos
DE USUARIO
Tabla 23: Créditos con posible prescripción
1.4.1.1.25 Fraccionamiento (Parte 1)

 Permitir realizar el ajuste a los saldos deudores y de los saldos de infracciones por
fraccionamiento.
DIAGRAMA
N/A
TRÁMITES  N/A
DEL
PROCESO
TABLAS  N/A
MAESTRAS
CONSULTAS  N/A
RELACIÓN
TRÁMITES E Generar movimientos en la cuenta Registrar RI de Fraccionamiento
HISTORIAS única (RSIRAT)
DE USUARIO
Tabla 24: Fraccionamiento (Parte 1)


79
1.4.1.1.26 Funcionalidades compartidas
 Este grupo tiene como objetivo poner de manifiesto la existencia de funcionalidades que han
de ser compartidas por el sistema.
Descripción
N/A
TRÁMITES  N/A
DEL
PROCESO
TABLAS  Parametrizar asignación automática de solicitudes
MAESTRAS  Mantener supervisores para aplicación de solicitudes
 Mantener gestores para evaluación de solicitudes
CONSULTAS  Listar solicitudes - Especificación Genérica
 Consulta Cuenta Única - Especificación Genérica
 Listar parametría - Especificación Genérica
RELACIÓN
TRÁMITES E Seleccionar usuario de Cuenta
Seleccionar usuario de Cuenta Única
HISTORIAS Única
DE USUARIO
Tabla 25: Funcionalidades compartidas
1.4.2 Arquitectura de Negocio
1.4.2.1 Front
El término front hace referencia a aquellas funcionalidades cuyo actor principal es un usuario; bien
sea: un usuario externo como puede serlo: un contribuyente, un banco o cualquier otro tercero que
interactúe con la administración haciendo uso de un sistema de información, o bien, un usuario
interno; entendiendo por usuario interno a aquel que se encuentra o se ocupa en la propia
Administración.
En esta categoría las principales aplicaciones identificadas según los términos de referencia a utilizar
por usuarios externos son las siguientes:
 Plataforma de declaraciones y pagos.

 Pago fácil
 CPE
 CIBELLE


80
 SINE
 SIRAT y RSIRAT en lo que no se oponga a la definición indicada para el concepto: “front”.
 SCUC excepto en lo referido a la extracción, normalización y registro de movimientos en la
cuenta única.
Si bien son estas las aplicaciones que darán soporte a los procesos de la cuenta única, no se
contempla en la presente propuesta los desarrollos que deban efectuarse en los sistemas legados.
1.4.2.2 Back
El término back se reserva para aquellas funcionalidades cuya ejecución no precisa la interacción
con el usuario, aunque sí dan soporte a los procesos de negocio. Así, en esta categoría pueden
identificarse las siguientes aplicaciones:
 SCUC, en lo que afecta a la extracción, normalización y registro de movimientos

 SIRAT y RSIRAT, en lo que afecta a procesos que se ejecutan de manera desatendida o con
características análogas a las indicadas en la descripción del término: “back”.
Si bien son estas las aplicaciones que darán soporte a los procesos de la cuenta única, no se
contempla en la presente propuesta los desarrollos que deban efectuarse en los sistemas legados.
1.4.2.3 Interoperabilidad
Por interoperabilidad debe entenderse la capacidad de los sistemas de información y de los

procedimientos a los que éstos dan soporte, de compartir datos y posibilitar el intercambio de
información y conocimiento entre ellos.
Este concepto tiene una dimensión semántica que va más allá del simple hecho de asegurar que un
conjunto de sistemas sean capaces de intercambiar técnicamente datos. En este sentido, el aspecto
clave de la interoperabilidad respecto al negocio es asegurar que:
 Se identifiquen todas y cada una de las interacciones entre sistemas necesarias para soportar
todos los procesos del negocio.
 Las interacciones transmitan toda la información necesaria para finalizar con éxito tanto el
proceso de negocio que se está siendo ejecutando como todos aquellos que se puedan
derivar de él con posterioridad.
 Exista una completa trazabilidad de las transacciones a lo largo de todos y cada uno de los
sistemas que intervengan en su ciclo de vida y ejecución.


81
 Los usuarios tengan acceso en todo momento a cualquiera de los datos relativos a un
proceso de negocio, independientemente del sistema en el que se almacene la información.
Tomando como premisa esta definición cabe destacar que es de vital importancia para esta operación
la correcta identificación de los sistemas que intervendrán suministrando y consumiendo datos en
cada una de las funcionalidades/épicas de los MVP1 y MVP2 y el correcto tratamiento de las
integraciones que se hayan de hacerse entre los sistemas involucrados.
Dado que los sistemas de información sirven como soporte para la ejecución de los procesos de
negocio y de los procedimientos que identifican cómo deben ser ejecutados estos, se utilizará el mapa
de procesos presentado antes para mostrar el “mapa de integraciones” visto desde un punto de vista
funcional para cada uno de los MVPs afectados por esta operación.
Hay que mencionar que este “mapa de integraciones” se ha efectuado por parte del CONSORCIO a
partir del análisis del detalle de las historias de usuario incluidas en los términos de referencia
publicados por la SUNAT.
Una de las primeras tareas a realizar al inicio del proyecto sería efectuar una revisión exhaustiva del
detalle de dichas historias de usuario para asegurar que:
 Las informaciones de cada proceso contenidas en los términos de referencia están completas
o si, por el contrario, cabe la posibilidad de tener que revisar la definición de alguno de ellos.
 La comprensión de cada proceso ha sido correcta, tanto a nivel de enrutamiento como de
dependencias con otros procesos.
 Todos los sistemas necesarios han sido identificados en el enrutamiento de cada proceso.
 Los flujos de información trazados y su secuencia son correctos.
Fruto de la revisión de los procesos, se confeccionará una versión definitiva del “mapa de
integraciones” resultante para cada uno de los MVP1 y MVP2. Versión que debería ser validada por
los responsables de SUNAT para asegurar que está en concordancia con su estrategia institucional
de sistemas informáticos, ya que, recordemos que la puesta en marcha del sistema de cuenta única
podría dar lugar a la discontinuación de uno o varios de los actuales sistemas legados de la SUNAT.
Cabe destacar, que la existencia de dos puestas en producción del sistema de cuenta única, obliga
a diferenciar entre dos tipos de integraciones:
 Integraciones transitorias.
 Integraciones definitivas.


82
Por integraciones transitorias debe entenderse aquellas que sólo pervivirán hasta la puesta en
producción de los desarrollos correspondientes al MVP2 y por integraciones definitivas aquellas que
subsistirán una vez puesto en producción el MVP2.
En la siguiente ilustración se identifican, a alto nivel, los sistemas involucrados y los flujos en la
integración transitoria, marcados en gris en la ilustración Mapa de integraciones MVP1, para explicar
a continuación sus peculiaridades y cómo se vinculan con la finalización de procedimientos,
terminando con las integraciones definitivas, sus tipos y especificidades, y cómo quedaría el mapa
de integraciones tras la puesta en producción de los desarrollos correspondientes al MVP2
(ilustración Mapa de integraciones MVP2).


83
Ilustración 19: Mapa de integraciones MVP1

SPIN° 002-2018-SUNAT/BID-“SERVICIO DE DESARROLLO, PRUEBAS Y PUESTA EN PRODUCCIÓN DEL SISTEMA DE CUENTA ÚNICA DE CONTRIBUYENTE”
84
Las integraciones transitorias o temporales tienen lugar, como se ha indicado en párrafos anteriores,
por la existencia de dos puestas en producción del sistema de cuenta única, y ocurren durante el
periodo en el que las funcionalidades de MVP2 no sean puestas en producción. En ese periodo, y
para completar la ejecución de los procesos de negocio, será necesario integrarse con los sistemas
legados existentes en la actualidad en la institución.
Cabe destacar que estas integraciones, además presentan otra característica común referida a su
vinculación con la finalización de procedimientos. Así, cuando se produzca la finalización de los
procesos de compensación, devolución, modificación de datos, reconocimiento de pagos con
error, determinación de infracción, reimputación de montos, fraccionamiento, registro manual
de valores o reconocimiento de prescripción, el sistema de cuenta única deberá actualizar su
información consecuencia de la conclusión de estos procedimientos.
Las integraciones definitivas para el alcance de esta operación pueden ser divididas en dos grupos,
teniendo en consideración quiénes son los principales actores de los procesos involucrados. Así, de
una parte, al primer grupo se le podría denominar: “Integraciones Usuario Externo” por ser el actor
principal el contribuyente y al segundo grupo: “Integraciones Usuario Interno” por ser el principal actor
el usuario interno de la institución.
Dentro de las “integraciones usuario externo” quedarían aquellas referidas a los procesos de
presentación de declaraciones juradas, pagos y envío de comprobantes electrónicos y dentro de las
“integraciones usuario interno” el registro manual de valores, el registro de las resoluciones de
fraccionamiento y el registro de las resoluciones sobre prescripción.
Cabe señalar que las integraciones a practicar en los procesos de liquidación de declaraciones
juradas y de reconocimiento de prescripción, han de practicarse en dos sentidos:
 Para practicar las liquidaciones de declaraciones juradas será el sistema de plataforma única
de declaraciones y pagos quien consuma datos existentes en el sistema de cuenta única para
ofrecer a los contribuyentes casillas ya informadas – calculadas en sus formularios de
liquidación y será el sistema de cuenta única quien consuma datos de las declaraciones
juradas presentadas para actualizar datos del sistema de cuenta única.
 En el caso del reconocimiento de la prescripción serán el sistema de cuenta única quien
ofrezca los datos sobre esa posible prescripción de créditos a favor de la administración y
quien los consuma será el sistema RSIRAT hasta que se dicte la resolución en la que se
reconozca la prescripción. Concluido el reconocimiento, SCUC será quien use los datos
sobre la prescripción para actualizar las cuentas.
Así, el mapa de integraciones presente tras la puesta en producción del MVP2, quedaría trazado
según lo que se muestra en la siguiente imagen.


85
Ilustración 20: Mapa de integraciones MVP2

SPIN° 002-2018-SUNAT/BID-“SERVICIO DE DESARROLLO, PRUEBAS Y PUESTA EN PRODUCCIÓN DEL SISTEMA DE CUENTA ÚNICA DE CONTRIBUYENTE”
86
1.4.3 Arquitectura de Aplicaciones
Una vez explicado el enfoque arquitectónico del negocio y presentados los procesos, sistemas e
integraciones involucrados en la construcción funcional del SCUC, procedemos a plantear, a alto
nivel, cómo se plasmaría el sistema dentro del marco tecnológico recogido en los TDRs, de forma
que se detallen las capas y módulos que lo conforman, los principios que lo rigen, los estándares en
los que se apoya y el enfoque arquitectónico para dar solución a cómo se plasmarían las
funcionalidades front y back detalladas en el epígrafe anterior.
Ilustración 21: Arquitectura de aplicaciones
En el diagrama anterior, se presentan diferentes capas que se han identificado para dar respuesta a
los requerimientos funcionales y no funcionales, apoyando además a la arquitectura propuesta en los
TdR del pliego. Esta arquitectura no pretende ser un diseño cerrado y estático, sino que, en base a
las funcionalidades a implementar y teniendo en cuenta la flexibilidad que proporciona la metodología
agile utilizada, puede ser necesario actualizar los módulos de la arquitectura, siempre con la
aprobación de la SUNAT.
La solución general, el diseño, la estrategia, los módulos, han sido definidos para garantizar los más
altos requerimientos de calidad, flexibilidad, rendimiento, escalabilidad, estandarización,
mantenibilidad y seguridad.
1.4.3.1 Principios de la Arquitectura
A la hora de seleccionar los módulos de la arquitectura, se han tenido en cuenta las siguientes
premisas generales:

87
 Escalabilidad. Posibilidad de incrementar el tamaño del sistema para satisfacer nuevas
necesidades.
 Portabilidad. Posibilidad de funcionar en plataformas distintas a la utilizada para su
construcción.
 Rendimiento. Respuesta adecuada a ciertos parámetros como velocidad de respuesta a
peticiones externas, capacidad de servicio, precisión de la respuesta dada ante una petición,
etc.
 Disponibilidad. Capacidad de dar servicio de forma continuada, incluso ante la ocurrencia
de incidentes.
 Fiabilidad. Capacidad de ofrecer una respuesta funcionalmente correcta según se describe
en el análisis de requisitos.
 Integración. Posibilidad de mantener diálogo con sistemas externos.
 Seguridad. Capacidad de operar garantizando el acceso a la información de forma
organizada, la inaccesibilidad a tal información por medios no permitidos, etc.
La adecuación a estándares ha sido un pilar fundamental en la toma de decisiones para la elección

de los componentes de arquitectura para el sistema CUC. El sistema deberá ser implementado e
implantado siguiendo prácticas formales y empleando estándares, frente a la utilización de desarrollos
ad-hoc que han demostrado ser claramente más inadecuados.
Usando tecnologías basadas en estándares del mercado se obtienen los siguientes beneficios:
 Reutilización. Aprovechando trabajos previos de investigación y definición en lugar de

rehacer en cada proyecto. Los estándares parten de estar completamente probados y
validados, y se obtienen de la experiencia previa del CONSORCIO en proyectos entregados
y actualmente en operación.
 Evolución sencilla. La adecuación a estándares facilita la evolución del sistema, dotándolo
de una serie de directrices a seguir para su evolución.
 Gestión del conocimiento. Los conocimientos en estándares se caracterizan por ser más
sencillo encontrar recursos, asegurando la evolución del sistema a lo largo de su vida útil sin
tener que depender de un único proveedor, reduciendo así el conocido vendorlock-in.
 Abaratamiento de costes. El número de proveedores conocedores de los estándares es
muy amplio, lo que promueve la competencia, minimizando el coste de mantenimiento de los
sistemas de cara al futuro.
El pilar fundamental de la arquitectura son los microservicios, La definición de una arquitectura de

microservicios, según Martin Fowler, es la siguiente:

88
“In short, the microservice architectural style is an approach to developing a single application as a
suite of small services, each running in its own process and communicating with lightweight
mechanisms, often an HTTP resource API. These services are built around business capabilities and
independently deployable by fully automated deployment machinery. There is a bare minimum of
centralized management of these services, which may be written in different programming languages
and use different data storage technologies.”
“En resumen, el estilo arquitectónico de servicios múltiples es un enfoque para desarrollar una sola
aplicación como un conjunto de pequeños servicios, cada uno de los cuales se ejecuta en su propio
proceso y se comunica con mecanismos ligeros, a menudo una API de recursos HTTP. Estos
servicios están integrados en las capacidades comerciales y se pueden implementar de forma
independiente mediante una máquina de despliegue automatizada. Hay un mínimo de gestión
centralizada de los servicios, que pueden escribirse en diferentes idiomas de programación y utilizar
diferentes tecnologías de almacenamiento de datos”
En este sentido, las características clave de los microservicios son las siguientes:
 Autonomía. La principal idea de una arquitectura de microservicios es que cada servicio sea
autónomo y pueda ser modificado, desplegado y escalado de forma independiente, sin
necesidad de cambiar otras partes del sistema. Asimismo, los microservicios han de tener
una dependencia mínima de otros servicios (bajo acoplamiento / alta cohesión).
 API's. Los microservicios exponen su funcionalidad mediante la definición de interfaces
(API’s): Un servicio productor publica una interfaz que es utilizada por un servicio consumidor.
La exposición final de las API’s hacia los consumidores externos se realizará utilizando Kong.
 Única función de negocio. Una característica de los microservicios es que están enfocados
a la realización correcta de una única función y tienen bien definidas las interfaces (API’s)
que exponen.
Y, a partir de las características anteriormente mencionadas, se obtienen los siguientes beneficios:
 Escalado independiente. Cada microservicio puede escalarse de forma independiente vía

escalado vertical (dotándole de más CPU o memoria) o escalado horizontal (sharding), en
función de sus necesidades. A diferencia de las aplicaciones monolíticas, en las cuales es
posible tener distintos requisitos, pero han de ser desplegados conjuntamente. Este escalado
estará gestionado por el orquestador de contenedores.
 Actualización independiente. Cada servicio puede ser desplegado de forma independiente
a otro. Cualquier cambio local a un servicio puede ser realizado por un desarrollador sin
requerir la coordinación con otros equipos. Por ejemplo, el rendimiento de un servicio puede
mejorarse cambiando la implementación subyacente. Como resultado, esto mantiene la
agilidad del microservicio. También es un gran facilitador de CI/CD.

89
 Fácil mantenimiento. El código de un microservicio está restringido a una única función, por
lo que es más sencillo de entender y modificar. Se simplifica el entorno de Desarrollo, con
unos proyectos más fácilmente gestionables al ser éstos de menor tamaño. La facilidad de
lectura y asimilación puede permitir a los desarrolladores ser más productivos.
 Potencial heterogeneidad y poliglotismo. Los desarrolladores son libres de escoger el
lenguaje y stack tecnológico que mejor se adapta al servicio. Esto permite recodificar el
servicio utilizando los mejores lenguajes y tecnologías, de forma opuesta a ser penalizado
por decisiones pasadas, y da la libertad de elección a la hora de seleccionar una tecnología,
herramienta o framework. Si bien existe esta libertad, en el caso del proyecto de CUC, en los
siguientes apartados se detallarán una la tecnología homogénea a emplear, pero
considerando desarrollar los servicios siguiendo el paradigma reactivo.
 Aislamiento ante fallos y recursos. Un mal comportamiento en un servicio, como un
memoryleak o una conexión no cerrada a una base de datos, puede afectar solo a ese
servicio, al contrario de una aplicación monolítica. Esto mejora el aislamiento ante fallos y
limita en cuánto puede afectar un fallo a una aplicación. Para ello, se aplicará el patrón Circuit
Breaker.
 Mejora en la comunicación entre equipos. Un microservicio es desarrollado típicamente
por un equipo full-stack. Todos los miembros relacionados con ese dominio trabajan
conjuntamente en un único equipo, lo cual mejora significativamente la comunicación entre
los miembros del equipo, puesto que comparten el mismo objetivo final.
Considerando lo anteriormente indicado, los elementos principales de una arquitectura orientada a

microservicios son los siguientes:
Ilustración 22: Elementos principales de una arquitectura orientada a microservicios
 Contenedores. Los contenedores de software han creado un marco estandarizado para

todos los servicios al abstraer el código central del sistema operativo del hardware
subyacente.
 Microservicios &API’s. La adopción e incremento de las capacidades ofrecidas por las API’s
han creado un formato robusto y estandarizado para las comunicaciones entre aplicaciones,
servicios y servidores.
 Infraestructura Cloud Escalable. Las infraestructuras cloud públicas, privadas e híbridas
son capaces de facilitar recursos bajo demanda y pueden escalar los recursos de manera

90
efectiva, independientemente de la carga o tráfico asociados. Esto proporciona elasticidad a
los microservicios y, a su vez, los hace más adaptables y eficientes.
 DevOps. La Integración Continua y Despliegue Continuo (Continuous Integration &
Continuous Deployment (CI/CD)) son muy importantes para el éxito de las aplicaciones
basadas en microservicios. Estas prácticas son requeridas para que los errores sean
identificados de forma temprana, así como se requiere poca o ninguna coordinación entre los
distintos equipos que desarrollan microservicios. Para nuestra arquitectura,
implementaremos los siguiente:
o Repositorio de código. Permite gestionar el código fuente y el control de versiones
distribuido para el equipo de desarrollo.
o Analizador de código. Se plantea realizar revisión de código para detectar” bugs” y
vulnerabilidades donde involucre el desarrollo de un módulo.
o Service Discovery. Permite el registro de servicios además de un API externo para
interactuar. Registrar los servicios dinámicamente mediante la configuración de
eventos de creación y eliminación de servicios. Además, brindará un API para
monitorear los estados de salud, permitiendo implementar el patrón de Circuit
Breaker.
Complementará el funcionamiento de balanceadores de carga mediante el Server
Discovery, es decir, una aplicación invocará a los balanceadores y estos accediendo
al registro de servicios invocarán a la instancia correspondiente.
o Configuración de app. Gestiona las configuraciones complementarias de las
aplicaciones para acceder a recursos, como por ejemplo accesos a base de datos,
montaje de la unidad de persistencia (disco duro) en caso del módulo de documentos
y otros parámetros que varían según el ambiente.
o Integrador y compilador. Permite realizar la integración continua, teniendo en
consideración que realiza la ejecución de pruebas unitarias y las compilaciones de
librerías e imágenes necesarias para el despliegue.
o Repositorio de artefactos. Permite gestionar las librerías, imágenes de los
contenedores con su respectiva versión.
o Despliegue. Capa que permite realizar el despliegue continuo de los servicios.
 Monitoreo. Cabe destacar que aplicar una arquitectura de microservicios, donde cada
servicio puede escalar de forma independiente, implica una mayor complejidad a la hora de
monitorizar y trazar cada una de las peticiones. Para ello, se plantea una solución que
permita:
o Trazabilidad y trazabilidad distribuida. Agregación de las trazas generadas por
cada una de las instancias de microservicios en un único punto centralizado, así
como registro de cada petición con un identificador que permite el seguimiento
completo de una invocación. Para ello se generará un identificador único que se

91
propaga entre invocaciones y se realizará la recolección, almacenamiento y
visualización de las trazas, respectivamente.
o Métricas. Gestión de las métricas de los elementos implantados, permitiendo el
envío de alertas a distintos canales de destino. Para ello, se debe realizar una
recolección de información para poder identificar la salubridad, métricas de los
microservicios, así como información del uso de recursos de los contenedores
(utilización de memoria, CPU y file system, entre otras).
1.4.3.2 Frontend
Para el desarrollo se plantea como arquitectura un desarrollo de una SPA (Single Page web
Application), es decir, una aplicación web de una sola página, donde el contenido se va refrescando
con peticiones asíncronas al módulo del API Gateway, sin necesidad de refrescar toda la aplicación.
Una aplicación SPA, con capas totalmente desacopladas, que a través de servicios de negocio
consume los datos y servicios expuestos en backend.
Los principales ejes directores del desarrollo en su vertiente front, y que servirán de guía para la
elección de tecnologías, así como para los equipos de proyecto serán:
 La construcción de servicios y componentes reutilizables.

 Solución basada en estándares.
 Arquitecturas atractivas y efectivas.
 Tecnologías con un time tomarket reducido.
 Desarrollos flexibles, escalables y sostenibles.
 Selección de tecnologías que permitan disminución de costes de mantenimiento.
 Separación de las capas de presentación y negocio.
Adicional al SPA, se plantea el uso de Micro Frontends cuya idea es pensar en un sitio web o
aplicación web como una composición de características que son propiedad de equipos
independientes. Cada equipo tiene un área de negocio definida o misión de la que se preocupa y se
especializa. Un equipo es cross functional y desarrolla sus características end-to-end, desde la base
de datos hasta la interfaz de usuario.
Sin embargo, esta idea no es nueva, en el pasado se llamaba Integración de Frontend para Sistemas
Verticales o Sistemas autocontenidos. Pero Micro Frontends es claramente un término más amigable
y menos voluminoso.

92
Ventajas de los Micro Frontends:
 Es Agnóstico a la Tecnología. Cada equipo debe poder elegir y actualizar su stack sin tener
que coordinar con otros equipos. Los Custom Elements son una excelente manera de ocultar
los detalles de la implementación mientras se proporciona una interfaz neutral a otros.
 Aislar el código del equipo. No compartir tiempo de ejecución, incluso si todos los equipos
usan el mismo framework. Crea aplicaciones independientes que sean autónomas. No hay
que confiar en estado compartido o variables globales.
 Establecer prefijos de equipo. Acordar los espacios de nombres no aislados. Espacio de
nombres CSS, eventos, almacenamiento local y cookies para evitar colisiones y dejar clara
la propiedad.
 Favorece las funciones nativas del navegador sobre las API personalizadas. Utilizar
Eventos de navegador para la comunicación en lugar de crear un sistema global PubSub. Si
realmente tiene que crear una API de varios equipos, intente que sea lo más simple posible.
 Construir un sitio resiliente. Su función debería ser útil, incluso si JavaScript falla o no se
ha ejecutado todavía. Utilizar Universal Rendering y Progressive Enhancement para mejorar
el rendimiento percibido.
Para su implementación se usará un framework que permita una integración óptima y eficiente con
Sass (Syntactically Awesome Style Sheets), uno de los preprocesadores de hojas de estilo sintácticas
más potentes. Con ello disminuimos riesgos inherentes a la organización de hojas de estilos para un
proyecto de cierta envergadura.
El framework de desarrollo se debe realizar usando un lenguaje que se compile a JavaScript para
mejorar la productividad y disminución de riesgos por la alta complejidad del proyecto. Dota de mayor
control de código para equipos de desarrollo grandes.
El módulo debe ser responsivo, mediante el uso de un framework para cumplir con el requerimiento
no funcional de usabilidad.
1.4.3.3 Backend
Se han identificado los siguientes módulos:
 API Gateway. Permite exponer las API’s de CUC brindando facilidades para la aplicación.
Se integrará a mecanismos alineados al estándar de Open Authentication. Para la
autenticación se debe integrar a servicios existentes de SUNAT para la generación de tokens.
Para la autorización se implementará un módulo que permita definir el control de accesos a
los perfiles definidos en las bases.

93
Se implementará la validación de tokens, el cual requieren mecanismos de firma criptográfica
mediante el uso de llaves y/o certificados de SUNAT y que deben estar protegidos en un
HSM (Hardware Security Module) al igual que cualquier otra credencial a un recurso.
 Sistemas Legados. Módulo que representa los sistemas de SUNAT que están desplegados
on-premise. Para la integración con dichos sistemas se usará API’s implementadas por
SUNAT así como el módulo extractores para poder integrarse a los módulos desplegados en
la nube que forman parte del Sistema CUC.
 Extractores. Módulo que implementa el patrón “mediation module”. Permite la integración
entre los sistemas legados y las cuentas gestionadas por el Sistema CUC. Las transacciones
que afectan a las cuentas pertenecen los siguientes sistemas legados:
o Plataforma Única de Declaraciones y Pagos.
o Carrito de Pagos.
o Declaraciones y Pagos (Bancos).
o SIRAT.
o CPE y CIBELLE (Comprobantes de Pagos y Libros electrónicos).
o RSIRAT.
Este módulo tiene las siguientes características:
o Uso de adaptadores o conectores para acceder a los recursos de Data Streaming y
Base de datos.
o Se ejecutará en on-premise, pero con conexión a la nube para transferir la
información.
o Uso de mecanismos de “polling”, para que mediante un periodo determinado se
pueda obtener un conjunto de registros a transferir.
o Uso de una base de datos de control, para que se registre un identificador de control
para dar inicio al envío de información al Data Streaming.
o Por cada registro, el módulo transformará la información a una estructura estándar.
o Registrará el éxito del registro procesado exitosamente.
 CUC Core. Capa que está compuesta por los siguientes módulos.
o Servicios Core. Conformada por un conjunto de microservicios para poder realizar
el procesamiento de la información (normalización de documentos) y brindar accesos
a las cuentas y movimientos. Usa el módulo streaming para la ingesta de información.
o Caché. Es una gestor de caché para poder almacenar información temporal, que no
requiera persistencia.
o Repositorio de datos. Es una base de datos orientada a documentos, el cual
permite almacenar las cuentas y movimientos.
 Plataforma de streaming. Permite procesar de forma secuencial y gradual registro por
registro la información que provienen de los sistemas legados así como de los procesos de

94
CUC. Da soporte para el stream de datos así como para la comunicación de asíncrona de
los microservicios (productor/consumidor).
Permite la ingesta de información para poder ser explotada por ejemplo para reportes.
 Servicios de soporte. Capa que reúne a los módulos transversales para dar soporte al
funcionamiento de CUC.
o Autenticación. Módulo que representa a los servicios existentes de SUNAT, es
decir, en el sistema de CUC no se crearán nuevos usuarios ni el mecanismo de
autenticación (generación de tokens). Dicho módulo es requerido por el API Gateway
para las políticas de seguridad.
o Autorización. Módulo que permite gestionar la autorización granular de las
operaciones expuestas en el API Gateway y los perfiles.
o Auditoria. Módulo que permite implementar el requerimiento no funcional para que
el sistema sea auditable.
o Usuarios. Identificado debido a la necesidad de complementar información de los
usuarios y perfiles como es el mantenimiento de la estructura jerárquica de gestores,
supervisores, así como equipos de atención que se requieren para los procesos.
o Repositorio de documentos. Identificado debido que algunos procesos requieren
que se pueda adjuntar documentos o archivos. El microservicio es agnóstico al
proceso, por lo tanto, permite realizar operaciones de guardar un documento, obtener
un documento, eliminar un documento. El propio módulo o microservicio que requiera
su uso, será el encargado de asociar a su proceso o solicitud.
o Parámetros. Debido que se requiere que los parámetros sean centralizados, se crea
un microservicio para poder brindar una API escalable para acceder a información
centralizada.
1.4.3.4 Procesos
Capa que implementa los procesos y está compuesto por los siguientes módulos:
 Servicios de procesos. Microservicios que serán orquestados para dar soporte a los
procesos.
 Caché. Es un gestor de caché para poder almacenar información temporal, que no requiera
persistencia.
 Workflow.

95
Ilustración 23: Workflow
Módulo ligero que permite orquestar microservicios, para ello se hará uso de un framework altamente
escalable. Creemos que los procesos como una de las capas fundamentales del sistema CUC, y
debido a ello, es necesario darle un enfoque de workflow para el planteamiento de la arquitectura.
Entendiéndose que un workflow es una secuencia o flujo de las actividades en una organización con
el objetivo de llevar a cabo un trabajo. Tal como describimos en la arquitectura funcional, los procesos
se representan como un gráfico de elementos, que son un conjunto de actividades, eventos, puertas
de enlace, y flujos de secuencia que definen una ejecución semántica finita. Implementando los
procesos desde la perspectiva de workflows, permitirá apoyar las iniciativas de la mejora de la calidad
del servicio o producto, expansión a nuevos proceso, aumentar la satisfacción de los contribuyentes.
Los workflows requieren un enfoque sistemático, de gestión integral, para la mejora continua,
alineándolos con el cumplimiento de las estrategias de SUNAT. Basaremos una arquitectura
enfocada en genera visibilidad del proceso, lo que permite controlar los procesos de SUNAT. La
visibilidad permite poder ver a cualquier hora, que es lo que está ocurriendo con un proceso, por
ejemplo, ver qué actividades faltan completar o cuales de ellas están generando retraso.
Proponemos una arquitectura que apoyen directamente los objetivos estratégicos de SUNAT ya que,
para el sistema CUC, requiere una estrecha colaboración entre los procesos, el área de TI y la
arquitectura que permite llevar la agilidad a una nueva escala.
Los workflows a implementar no deben ser ajenos a la arquitectura de microservicios, para ello
definimos el uso de dos patrones para su implementación:
o El primer patrón es realizar una coreografía de microservicios, es decir, cada
microservicio será el encargado de coordinar la secuencia de invocación a otro
mediante un evento (mensajes asíncronos), además de controlar la persistencia de
estados y asignación de solicitudes (tares).
o El segundo patrón, es el de orquestación de microservicios, mediante el cual existe
un workflow o microservicio que es el coordinador de todos los microservicios que
componen el proceso.
En la arquitectura planteada, debido que debe ser altamente escalable y ser capaz de soportar
workflows complejos, se plantea la arquitectura que soporte ambos patrones. Que en la fase de
desarrollo se debe decidir a potestad de la mesa de trabajo y según los criterios siguientes:

96
o Complejidad.
o Tipo larga duración o corta duración.
o Eventos que se desencadenan mediante vencimiento de duraciones o fechas.
o Escalamientos o notificaciones.
o Reasignaciones de las solicitudes.
o Integración con sistemas legados.
 Reglas de negocio.
Ilustración 24: Regla de negocio
Microservicios que implementan las reglas de negocio, para ello se usa un framework altamente
escalable. Las reglas de negocios definen y controlan la estructura, el funcionamiento y la estrategia
de una organización. Las reglas de negocios pueden estar formalmente definidas en manuales de
procedimiento, contratos, acuerdos, o bien pueden formar parte como conocimiento o experiencia de
los empleados. Las reglas de negocios son dinámicas, están sujetas a cambios en el tiempo y pueden
encontrarse en todo tipo de aplicaciones, independiente de la arquitectura. Por lo general una regla
de negocio consta de una serie de condiciones que se evalúan generando una serie de acciones.
Una regla de negocio se utiliza para ayudar a abstraer de la aplicación la lógica de negocio. Un
microservicio o cualquier sistema puede envía datos y espera un resultado permitiendo su
reutilización.
Las reglas de negocio en las organizaciones reúnen un grupo de normas empresariales y se puede
implementar por lo general de dos maneras, mediante un conjunto de reglas y por tablas de
decisiones.
Ejemplos de reglas de negocio son:
o Se podrá de cambiar las tasas asociados a cuentas ya que podrían variar de acuerdo
a periodos o temporadas: anual, mes de cierre, etc.
o Se podrá tener la capacidad de revisar el detalle de un reclamo que ocurrió en el
pasado. La política actual de la empresa puede no ser la que se aplicó en su
momento y esto se podría realizar mediante la revisión de la auditoría.

97
Implementar las reglas mediante código o mediante una tabla de parámetros no es deseable. Esto
conllevaría a efectuar la intervención de una persona de TI, o en el peor escenario un control de
cambios, y un redespliegue del microservicio. A pesar que estamos en un entorno DevOps y la
agilidad es un punto clave en la arquitectura, nuestra propuesta implica ir un paso más allá y los
microservicios de reglas de negocios proporcionan una solución mucho más elegante.
Cuando estos valores son necesarios, los microservicios que lo requieran solicitan estos valores de
forma dinámica mediante la invocación a los microservicio de reglas de negocio. En principio, estos
valores pueden ser modificados por personal adecuado sin que ellos tengan que saber nada acerca
de las características técnicas de la solución.
Repositorio de procesos. Almacena información relacionada a gestionar las actividades y estados

de workflows de larga duración, implementado en base de datos distribuida.
1.4.4 Arquitectura Tecnológica
La Arquitectura tecnológica a utilizar es una arquitectura hibrida (Onpremises y Cloud) con

componentes de código abierto. En esta sección del documento se describirán los componentes
tecnológicos que componen la solución de Sistema de Cuenta Única de Contribuyente.
Se presentan por lo tanto diferentes tipos de componentes arquitectónicos y tecnologías que se han
considerado adecuadas para dar respuesta a las necesidades funcionales detectadas, apoyando
además la arquitectura propuesta en los TdR del pliego.
1.4.4.1 Diagrama de la Arquitectura Tecnológica.

98
Ilustración 25: Diagrama de la Arquitectura Tecnológica

99
La arquitectura tecnológica planteada contiene la mayor cantidad de componentes desplegados en
la nube como bases de datos, capacidades de software, aplicaciones, etc. diseñados para aprovechar
el poder de los recursos de la nube para resolver problemas. La arquitectura en la nube define los
componentes, así como las relaciones entre ellos.
Los componentes encontrados en la arquitectura lógica son los siguientes:
 Recursos locales
 Recursos en la nube
 Componentes de software y servicios
 Middleware
Toda la arquitectura de la nube está destinada a proporcionar a los usuarios un gran ancho de banda,
lo que les permite tener acceso ininterrumpido a datos y aplicaciones, una red ágil a pedido con la
posibilidad de moverse de manera rápida y eficiente entre servidores o incluso entre nubes y, lo más
importante, la seguridad de la red.
La arquitectura implementada en la nube para la instalación de todos los componentes es:

Infraestructura como servicio (IaaS) la cual proporciona servidores, redes, dispositivos de
almacenamiento, etc., que se ejecutan en la nube, disponibles para los usuarios con un pago por uso.
1.4.4.2 Frontend
1.4.4.2.1 Framework Frontend

Para la construcción del SPA utilizaremos el framework Angular en su versión 8.
 Este framework cumple además cualquier necesidad multilenguaje sin modificar el core del
mismo, ya está integrado.
 Nos permite una integración óptima y eficiente con Sass (Syntactically Awesome Style
Sheets), uno de los preprocesadores de hojas de estilo sintácticas más potentes. Con ello
disminuimos riesgos inherentes a la organización de hojas de estilos para un proyecto de
cierta envergadura.
 Dada la elección del framework Angular, el desarrollo se realizará con TypeScript, cuya
ventaja principal para este proyecto es una mejora en productividad y disminución de riesgos
por la alta complejidad del proyecto. Dota de mayor control de código para equipos de
desarrollo grandes.
 Las ventajas que aporta este tipo de solución son la mejora de la experiencia de uso, de la
percepción del rendimiento de las aplicaciones y una mayor reutilización y homogeneidad
para futuras aplicaciones, así como mantenimientos y/o evolutivos.

100
1.4.4.2.2 Librerías de mejora de productividad
Para un desarrollo más rápido y controlado, utilizaremos la librería de controles y componentes
PrimeNG:
 Perfecta integración con las últimas versiones de Angular.

 Multitud de componentes disponibles, ya testados e integrables de forma rápida en el
proyecto.
 Disponibilidad de controles para graficar estadísticas, tendencias, análisis cuantitativos y
cualitativos.
 Soporte de temas o themes para ajustes más personalizados en la visualización de los
controles.
 Fuentes de iconos adaptadas a las principales necesidades del mercado, siguiendo
estándares y guías de estilo generalmente aceptadas por la comunidad de desarrolladores.
Para el ajuste responsive utilizaremos PrimeNGGrids:
 La solución será responsive, gracias al sistema de grids que tenemos construido con la
librería.
 Además, nos permitirá utilizar las últimas técnicas de ajuste en pantalla, como flexlayouts.
1.4.4.2.3 Herramientas
Partiendo de que todo entorno de desarrollo creado tiene sus personalizaciones especiales, se
propone optar por este conjunto de herramientas para el desarrollo del stack de referencia:
 Atom / Procesador de texto: Procesador de texto opensource, muy visual y con una alta
capacidad de personalización en cuanto a lenguajes, gráficos, temas o interfaces.
 Jasmine / Pruebas: Framework de prueba de código abierto para JavaScript. Su objetivo es
ejecutarse en cualquier plataforma habilitada para JavaScript como Angular, no interferir en
la aplicación ni en el IDE.
 WebPack / Build Tools: Herramienta de gestión de assets que destaca por su robustez, su
velocidad y el control milimétricos de los assets que se generan.
 JSCS / Calidad de código: Permite verificar la calidad del código. Producto OpenSource, de
fácil configuración y que permite una alta automatización de procesos.
 NPM / Gestor de paquetes: Gestor de paquetes de referencia para Node.js. La gran mayoría
de librerías que se utilizan disponen de un paquete de npm.
 SASS / Preprocesadores de texto: Preprocesador que permite hacer un css más modular,
reutilizable y de fácil mantenimiento.
 GIT / Control de versiones: Sobresale la velocidad, ramificación, convergencia, seguridad
y un flujo de trabajo adaptable.

101
 Google Web Optimizer / Rendimiento: Permite obtener información del rendimiento a
tiempo real directamente desde el navegador.
Ilustración 26: Herramientas de desarrollo
1.4.4.2.4 Componentes tecnológicos que soportan el frontend.
Ilustración 27: Componentes tecnológicos
El SPA funcionara con una imagen Docker basada en Nginx que es un servidor web/proxy inverso
ligero de alto rendimiento.
Docker es una tecnología de código abierto que nos permite crear pequeñas virtualizaciones de
sistemas, llamados contenedores, donde podemos meter o empaquetar todo lo necesario para que
funcione nuestra aplicación. Estás pequeñas virtualizaciones se ejecutan como procesos y no llegan
a ser tan pesadas como las máquinas virtuales convencionales. De esta forma, logramos que en ellas
tengamos todo lo esencial y necesario para que nuestra app o servicio funcione correctamente.
Las ventajas principales con respecto a las máquinas virtuales son:
 Ocupan menos espacio que las máquinas virtuales convencionales.

102
Al ser más ligeras que las máquinas virtuales, podemos estar ejecutando varias a la vez en el mismo
servidor.
 Son más fáciles de actualizar y desplegar.
Nos permiten crearlas lo más parecidas al entorno real de ejecución, por lo que las pruebas serán
más efectivas.
Los contenedores se encuentran desplegados en:
Kubernetes que es un sistema de orquestación de contenedores, lo que significa que el software no

se encarga de crearlos, sino de administrarlos. Para ello, Kubernetes aplica la automatización de
procesos, lo que vuelve más fácil para los desarrolladores comprobar, mantener o publicar
aplicaciones. La arquitectura de Kubernetes consta de una clara jerarquía, compuesta por los
siguientes elementos:
Contenedor: incluye las aplicaciones y entornos de software.
Pod: este elemento de la arquitectura de Kubernetes se encarga de agrupar aquellos contenedores

que necesitan trabajar juntos para el funcionamiento de una aplicación.
Nodo: uno o varios pods se ejecutan en un nodo, que puede ser tanto una máquina virtual como
física.
Clúster: en Kubernetes, los nodos se agrupan en clústeres.
Por otra parte, la arquitectura de Kubernetes se basa en el principio de maestro y esclavo. Los nodos
descritos se utilizan como esclavos, es decir, que son las partes controladas del sistema y están bajo
la administración y el control de los maestros de Kubernetes.
Una de las tareas de un maestro, por ejemplo, es distribuir los pods en los nodos. Mediante la
supervisión constante, el maestro puede intervenir tan pronto como falla un nodo y clonarlo para
compensar el error. El estado real siempre se compara con el estado deseado y se ajusta si es
necesario. Tales procesos suceden automáticamente. El maestro es también el punto de acceso para
los administradores y les sirve para orquestar los contenedores.
1.4.4.3 Backend
1.4.4.3.1 API Gateway Kong

Dentro de las arquitectura de microservicios, Kong desempeñaría las funciones de API Gateway, ese
módulo inicial donde se integran cada uno de nuestros servicios

103
Kong es una herramienta Open Source creada sobre NGINX para ayudarnos en un gran número de
cosas. Kong nos permite:
1. Homogeneizar las diferentes APIs de nuestro negocio.

2. Securizar nuestra API para que no tengan que encargarse los microservicios.
3. Obtener métricas de uso de las diferentes partes de la API.
4. Obtener logs en un repositorio común.
5. Transformar peticiones y respuestas.
6. Almacenar variables de entorno.
Kong se caracteriza por escalar muy bien ya que si necesitamos crear dos o más instancias por el
contexto en el que nos encontremos, esto será posible. La información importante de Kong es
persistida en base de datos. Kong da soporte para Apache Cassandra y PostgreSQL pudiendo
seleccionar la opción que más nos convenga por medio de configuración.
Ilustración 28: Kong
Uno de los puntos fuertes de Kong radica en la posibilidad de extender la herramienta por medio de
plugins. Kong es una herramienta muy modulable que permite ir agregando funcionalidades según la
necesitemos. Los plugins son desarrollados con lenguaje de programación LUA y permite acceso
completo a los recursos de la base de datos.
1.4.4.3.2 Bases de datos

Debido a la naturaleza de la información que es manejada en los procesos de negocio es necesaria
una base de datos NoSql, la mejor opción en este tipo de bases de datos es MongoDB.

104
1.4.4.3.2.1 MongoDB
Es una herramienta de gestión de bases de datos basada en documentos de código abierto que
almacena datos en formatos similares a JSON. Es una base de datos NoSQL altamente escalable,
flexible y distribuida.
Ser una herramienta NoSQL significa que no utiliza las filas y columnas habituales que tanto asocia
con la gestión de bases de datos relacionales. Es una arquitectura que se basa en colecciones y
documentos. La unidad básica de datos en esta base de datos consiste en un conjunto de pares
clave-valor. Permite que los documentos tengan diferentes campos y estructuras. Esta base de datos
utiliza un formato de almacenamiento de documentos llamado BSON, que es un estilo binario de
documentos JSON.
Arquitectura de la base de datos MongoDB NoSQL
Ilustración 29: Arquitectura de la base de datos MongoDB NoSQL
1.4.4.3.2.2 Redis
Es muy común que durante la implementación de un proceso de negocio o micro servicio surja la
necesidad de almacenar datos en cache para obtener resultados más rápido que los
almacenamientos tradicionales es por ello que una fuente de datos como Redis nos permitirá
solventar estas situaciones.
Redis es un almacén de datos de clave valor en memoria. Es un sistema de almacenamiento donde

los datos se almacenan en forma de pares de clave y valor, esto significa que los pares clave-valor
se almacenan en la memoria primaria (RAM).
En Redis, la clave debe ser una cadena, pero el valor puede ser una cadena, lista, conjunto, conjunto
ordenado o hash.

105
Ventaja de Redis
Los sistemas de gestión de bases de datos almacenan todo en un segundo almacenamiento, lo que
hace que las operaciones de lectura y escritura sean muy lentas. Pero Redis almacena todo en la
memoria primaria, que es muy rápida en lectura y escritura de datos.
1.4.4.3.2.3 Kafka y Zookeeper
Ilustración 30: Kafka y Zookeeper
Kafka es una plataforma de transmisión distribuida que permite:
 Publicar y suscribirse a secuencias de registros, similar a una cola de mensajes o sistema de

mensajería empresarial.
 Almacena flujos de registros de una manera duradera y tolerante a fallas.
 Procesa flujos de registros a medida que ocurren.
Kafka será usado para transmitir los mensajes de los procesos de negocio del CUC creando canales
de transmisión de datos en tiempo real.
Kafka se ejecuta como un clúster en uno o más servidores que pueden abarcar múltiples centros de
datos. El clúster de Kafka almacena flujos de registros en categorías llamadas tópicos. Cada registro
consta de una clave, un valor y una marca de tiempo.
Los datos escritos en Kafka se escriben en el disco y se replican para tolerancia a fallas. Kafka permite
a los productores esperar el acuse de recibo para que una escritura no se considere completa hasta
que esté completamente replicada y garantice su persistencia incluso si el servidor al que se escribe
falla.

106
Kafka usa ZooKeeper para administrar el clúster. ZooKeeper se utiliza para coordinar los Brokers
/cluster, es un sistema de archivos consistente para la información de configuración, también es
usado para hacer la elección de liderazgo del Broker de Kafka y los pares de partición de tópicos.
Kafka usa ZooKeeper para gestionar el descubrimiento de servicios para los brokers de Kafka que
forman el clúster. ZooKeeper envía cambios de la topología a Kafka, por lo que cada nodo en el
clúster sabe cuándo se une un nuevo agente, un agente muere, se elimina un tópico o se agrega un
tópico, etc. ZooKeeper proporciona una vista sincronizada de la configuración del grupo Kafka.
1.4.4.3.2.4 Agente Extractor de Datos (AED)
Ilustración 31: Agente Extractor de Datos (AED)
Para implementar los AED se usará el patrón “Mediation”, el cual permitirá obtener la información de
la base de datos de SUNAT teniendo las siguientes características:
 Usa el framework SpringIntegration 5.
 Usa el patrón de “Mediation”, que permitirá integrar dos sistemas.
 Se crearán tantos componentes de mediación como sistemas tenga SUNAT para

extraer. Dichos sistemas están descritos en las historias de usuario.
 Usa de un adaptador JDBC InboundChannelAdapter para acceder a las base de datos

de los sistemas legados.
 Uso de un adaptador Kafka OutboundChannelAdapter para acceder a los recursos de

Kafka y poder registrar la información en una estructura estándar para que sea
procesada.
 Los componentes se ejecutará en on-premise, pero con conexión a la nube para

transferir la información.

107
Se ejecuta el siguiente proceso:
 Una vez completada una transacción se debe registrar un identificador de control para
dar inicio al envío de información a Kafka. Las transacciones deben pertenecer a uno de
los siguientes sistemas legados:
 Plataforma Única de Declaraciones y Pagos
 Carrito de Pagos
 Declaraciones y Pagos (Bancos)
 SIRAT
 CPE y CIBELLE (Comprobantes de Pagos y Libros electrónicos)
 RSIRAT
 SIGAD
 El AED, estará configurado para hacer “polling” a la tabla de control y si encuentra

registros pendientes, iniciará el proceso de envío al Data Streaming.
 Por cada registro, el AED transformará la información a una estructura estándar.
 Finalmente y por cada registro enviará al Data Streaming la información y esperará la

confirmación que se ha procesado exitosamente.
 Registrará el éxito del registro procesado exitosamente
1.4.4.3.2.5 Microservicios
Para poder realizar los procesos de negocios en la CUC es necesario implementar lógica para la
manipulación de datos, transformación y orquestación de los mismos. Esta lógica será implementada
utilizando una arquitectura de microservicios.
Framework usado
Spring boot es un módulo de Spring Framework que se utiliza para crear aplicaciones
independientes basadas en Spring orientado a que el desarrollador utilice un mínimo esfuerzo en su
implementación. El concepto principal detrás de Spring Boot es evitar una gran cantidad de código
repetitivo y configuración para mejorar el desarrollo, las pruebas unitarias, etc.

108
Con Spring boot implementaremos microservicios basados en REST, el cual proporciona los medios
para construir APIs flexibles que pueden:
 API evolucionables
 Servicios escalables
 Servicios asegurables
Spring Cloud Consul proporciona ServiceDiscovery que es uno de los principios clave de una
arquitectura basada en microservicios. Intentar configurar manualmente cada cliente o alguna forma
de convención puede ser muy difícil de hacer y puede ser muy frágil. Consul proporciona servicios de
descubrimiento de servicios a través de una API HTTP y DNS. Spring Cloud Consul aprovecha la API
HTTP para el registro y descubrimiento de servicios. Esto no evita que las aplicaciones que no sean
Spring Cloud aprovechen la interfaz DNS. Los servidores de Consul Agents se ejecutan en un clúster
que se comunica a través de un protocolo de Gossip y utiliza el protocolo de consenso Rafa.
Spring Metrics proporciona instalaciones para configurar aplicaciones con recopilación de métricas
e interactuar con sistemas populares de monitoreo de aplicaciones de terceros como Prometheus,
que es un kit de herramientas de monitoreo y alerta de sistemas de código abierto
1.4.4.4 Procesos
Para poder implementar los procesos de negocio será necesario orquestar diferentes microservicios
y esto aumentará la complejidad en el desarrollo, es por ello que se propone el uso de las siguientes
herramientas:
1.4.4.4.1 Zeebe
Es un motor de flujo de trabajo para la orquestación de microservicios. Zeebe asegura que, una vez
que se inician, los flujos siempre se llevan a cabo completamente, reintentando los pasos en caso de
fallas. En el camino, Zeebe mantiene un registro de auditoría completo para poder monitorear el
progreso de los flujos. Zeebe es tolerante a fallas y escala sin problemas para manejar los crecientes
volúmenes de transacciones.
1.4.4.4.1.1 Ventajas de Zeebe:

1. Visibilidad del estado de los flujos de trabajo de extremo a extremo de una empresa, incluida
la cantidad de flujos de trabajo en vuelo, la duración promedio del flujo de trabajo, los errores
actuales dentro de un flujo de trabajo y más.
2. Orquestación de flujo de trabajo basada en el estado actual de un flujo de trabajo; Zeebe
publica "comandos" como eventos que pueden ser consumidos por uno o más microservicios,
asegurando que los flujos de trabajo progresen de acuerdo con su definición.

109
3. Monitoreo de tiempos de espera u otros errores de flujo de trabajo con la capacidad de
configurar rutas de manejo de errores, como reintentos con estado o escalada a equipos que
pueden resolver un problema manualmente.
Zeebe fue diseñado para operar a gran escala, y para lograr esto, proporciona:
 Escalabilidad horizontal y sin dependencia de una base de datos externa; Zeebe escribe
datos directamente en el sistema de archivos en los mismos servidores donde se implementa.
Zeebe simplifica la distribución del procesamiento en un grupo de máquinas para ofrecer un
alto rendimiento.
 Tolerancia a fallas a través de un mecanismo de replicación fácil de configurar, asegurando
que Zeebe pueda recuperarse de la falla de la máquina o el software sin pérdida de datos y
tiempo de inactividad mínimo. Esto asegura que el sistema como un todo permanezca
disponible sin requerir una acción manual.
 Una arquitectura basada en mensajes donde todos los eventos relevantes para el flujo de
trabajo se escriben en un registro de solo agregado, que proporciona una pista de auditoría
y un historial del estado de un flujo de trabajo.
 Un modelo de interacción de publicación-suscripción, que permite que los microservicios
que se conectan a Zeebe mantengan un alto grado de control y autonomía, incluido el control
sobre las velocidades de procesamiento. Estas propiedades hacen que Zeebe sea resistente,
escalable y reactivo.
 Flujos de trabajo visuales modelados en el estándar ISO BPMN 2.0 para que las partes
interesadas técnicas y no técnicas puedan colaborar en el diseño del flujo de trabajo en un
lenguaje de modelado ampliamente utilizado.
 Un modelo de cliente independiente del lenguaje, que permite construir un cliente Zeebe
en casi cualquier lenguaje de programación que una organización utiliza para construir
microservicios.
 Facilidad de uso operativa como sistema autónomo y autosuficiente. Zeebe no requiere
un coordinador de clúster como ZooKeeper. Debido a que todos los nodos en un clúster de
Zeebe son iguales, es relativamente fácil de escalar y funciona muy bien con los
administradores de recursos modernos y los orquestadores de contenedores como Docker,
Kubernetes y DC / OS. La CLI (interfaz de línea de comandos) de Zeebe le permite realizar
scripts y automatizar tareas de administración y operaciones.
1.4.4.4.2 Motor de reglas de negocio Drools

Es una plataforma de integración de lógica de negocios (BLiP). Es un proyecto de código abierto
escrito en Java que utiliza un sistema de implementación avanzado del algoritmo de coincidencia de
patrones Rete.

110
Drools ayudan a separar y razonar sobre la lógica y los datos que se encuentran en los procesos
comerciales. Es compatible con el encadenamiento hacia adelante y hacia atrás del motor de reglas
de drools basado en inferencia.
Drools se dividen en dos partes: autoría y tiempo de ejecución.
Autoría: implica el desarrollo de archivos de reglas.
Tiempo de ejecución: implica la creación de memoria de trabajo y el manejo de la activación.
Estas son las características importantes de Drool:
 Le ayuda a separar la aplicación de la lógica dinámica.

 Programación declarativa.
 Centralización del conocimiento.
 Velocidad y escalabilidad.
 Lógica separada de la aplicación.
 Reglas comprensibles.
1.4.4.4.2.1 Arquitectura de Drools
Ilustración 32: Arquitectura de Drools
1. Las reglas se cargan en Rule Base, que está disponible todo el tiempo.
2. Los hechos se afirman en la memoria de trabajo donde luego se pueden modificar o retraer.
3. El proceso de comparación de los hechos nuevos o existentes con las reglas de producción
se denomina coincidencia de patrones, que se realiza mediante el motor de reglas.
4. La agenda le permite administrar el orden de ejecución de las reglas en conflicto con la ayuda
de una estrategia de resolución de conflictos.

111
1.4.4.5 Logs, Monitoreo y Alertas
Ilustración 33: Logs, Monitoreo y Alertas
Los logs, monitoreo y alertas en la solución planteada pueden provenir de los sistemas instalados o
de las implementaciones realizadas en estos sistemas. Se ha contemplado la captura de logs para
estos dos escenarios utilizando las siguientes herramientas.
1.4.4.5.1 Prometheus
Prometheus, que es un kit de herramientas de monitoreo y alerta de sistemas de código abierto.
Las características principales de Prometheus son:

112
 Un modelo de datos multidimensionales con datos de series temporales identificados por
nombre de métrica y pares clave / valor.
 PromQL, un lenguaje de consulta flexible.
 No depender del almacenamiento distribuido; los nodos de servidor único y autónomos
 La recopilación de series temporales se realiza a través de un modelo de extracción a través
de HTTP.
 Pushing time series es compatible a través de una puerta de enlace intermedia.
 Los objetivos se descubren mediante el descubrimiento de servicios o la configuración
estática.
 Múltiples modos de gráficos y soporte de tablero.
Prometheus funciona bien para grabar cualquier serie temporal puramente numérica. Se adapta tanto
al monitoreo centrado en la máquina como al monitoreo de arquitecturas orientadas a servicios
altamente dinámicas. En un mundo de microservicios, su soporte para la recolección y consulta de
datos multidimensionales es una fortaleza particular.
1.4.4.5.2 Grafana
Es una herramienta de visualización de métricas, que puede mostrar gráficamente los datos
recolectados por Prometheus utilizando PromQL.
Ilustración 34: Grafana
Grafana es la plataforma de análisis para métricas, que le permite consultar, visualizar, alertar y
comprender los datos, sin importar dónde estén almacenadas. Le permite crear, explorar y compartir
tableros con su equipo. Para la visualización y personalización del tablero de instrumentos, Grafana
es la mejor de todas las opciones.

113
1.4.4.5.3 ElasticStack
Es un conjunto de herramientas de gran potencial de código abierto que se combinan para crear una
herramienta de administración de registros permitiendo la monitorización, consolidación y análisis de
logs generados en múltiples servidores, estas herramientas son: ElasticSearch, Logstash, Kibana y
Beats.
También pueden ser utilizadas como herramientas independientes, pero la unión de todas ellas hace
una combinación perfecta para la gestión de registros.
Elasticsearch
Es un motor de búsqueda y analítica distribuido con base en JSON, posee una base de datos
distribuida. Distribuye toda la información en todos los nodos, por tanto es tolerante a fallos y tiene
alta disponibilidad. Al igual que distribuye la información, distribuye el procesamiento. Cuando se
realiza una consulta o búsqueda y esa información se encuentra distribuida, será cada nodo el que
procese dicha información y devuelva los resultados. Por tanto, podemos obtener mejores
rendimientos.
Logstach
Logstash es un pipeline de recopilación de datos dinámico con un ecosistema de plugin extensible.

Es la parte de pre procesamiento antes de guardar la información en Elasticsearch que hemos
comentado, donde recogemos un input, una entrada, trabajamos los eventos y los sacamos por una
salida, antes de almacenarlos en las bases de datos.
Kibana
Permite visualizar tus datos de Elasticsearch y navegar por el ElasticStack para que puedas hacer
cualquier cosa, desde rastrear la carga de búsqueda hasta comprender cómo fluyen las solicitudes a
través de tus aplicaciones.
Es el más visual, dónde vamos a generar las visualizaciones sobre la información y dónde vamos a
generar los dashboards.
Beats
Es la plataforma para los agentes de datos con un solo propósito. Envían datos de cientos o miles de
máquinas y sistemas a Logstash o Elasticsearch. Compuesta de recolectores de información.
Recogen información, ya sea de un fichero, log de datos, eventos, métricas del sistema (CPU, RAM),
hacen comprobaciones de qué servicios se encuentran activos, analizan a nivel de red los paquetes,
el tiempo de respuesta entre ellos.

114
Ilustración 35: Beats
1.4.4.6 CI/CD
Ilustración 36: CI/CD
1.4.4.6.1 Jenkins
Es un servidor de automatización de código abierto. Con Jenkins, se puede acelerar el proceso de

desarrollo de software al automatizarlo. Jenkins gestiona y controla los procesos de entrega de
software a lo largo de todo el ciclo de vida, incluyendo compilación, documento, prueba, paquete,
etapa, implementación, análisis de código estático y mucho más.
Jenkins es parte fundamental del proceso de CI/CD (Integración continua y Entrega continua) pero
por si solo no puede cumplir con todo el ciclo de DevOps.
Para optimizar y organizar de mejor forma el trabajo de Jenkins es necesario contar con el plugin
Pipeline.

115
Un Pipeline (tubería) es un concepto separado que se refiere a los grupos de eventos o trabajos que
están conectados en una secuencia.
Jenkins nos proporciona varias interfaces y herramientas para automatizar todo el proceso.
Necesitamos un repositorio de Git donde el equipo de desarrollo subirá el código. Luego, Jenkins se
hace cargo de allí, mediante una herramienta de frontend donde puede definir el Pipeline.
Desde Git, Jenkins extrae el código y luego Jenkins lo mueve a la fase de commit, donde el código
se confirma desde cada branch. La fase de compilación es donde compilamos el código. Utilizando
herramientas como gradlew en Jenkins y luego se compila el código. Jenkins supervisa los casos de
prueba y las validaciones de código con Sonarqube.
Luego, pasa al servidor de pruebas para implementarlo con Docker. Después de una serie de pruebas
unitarias o pruebas de cordura, es promovido a un nuevo ambiente.
Ilustración 37: Jenkins
1.4.4.6.2 SonarQube
Es una plataforma de código abierto para el análisis de la calidad de código usando diversas
herramientas de análisis estático de código fuente como Checkstyle, PMD o FindBugs para obtener
métricas que pueden ayudar a mejorar la calidad del código de un programa. También pertenece al
conjunto de herramientas de análisis de código estático, junto con Understand, semmle y otras.
Es una herramienta esencial para nuestra fase de integración continua y auditoria de código dentro
de nuestro ciclo de desarrollo de nuestra aplicación. Existen muchos problemas que se pueden
encontrar en un código. Las reglas difieren y pueden clasificarse en 5 grupos según su severidad:
Bloqueador, crítico, grave, menor e informativo. Así que, si hay un bug o un bug potencial, va a ser
clasificado como problema bloqueador o crítico, y algunos problemas como “los números mágicos no
se deben utilizar” van a ser clasificados con severidad menor o informativa. Y deberá volver a la fase
de desarrollo para corregir esas partes de código.

116
1.4.4.6.3 GitLab
Gitlab es un servicio web de control de versiones y desarrollo de software colaborativo basado en Git.
Además de gestor de repositorios, el servicio ofrece también alojamiento de wikis y un sistema de
seguimiento de errores, todo ello publicado bajo una Licencia de código abierto.
1.4.4.6.4 Artifactory
Es un repositorio de artefactos universal que nos permite administrar cualquier pieza de software,
binarios o dependencias, en cualquier lenguaje.
La principal ventaja de Artifactory es evitar que los equipos de trabajo usen diversos repositorios, con
distintas versiones o distintas fuentes, centralizando en un único sitio y en un único espacio de
almacenamiento todas las dependencias de un proyecto y su gestión durante los ciclos de desarrollo,
incluso en ambientes de desarrollo distribuidos.
Al ser universal, se puede integrar con cualquier herramienta de desarrollo, como IDEs, utilidades
para DevOps, herramientas de control de versiones, sistemas operativos, etc.
Contar con este servidor en la Nube nos asegura disponer de la infraestructura necesaria para ofrecer
esta herramienta a equipos de trabajo distribuidos, donde podamos asegurar la capacidad de trabajo
a todo el equipo, desde la misma o distintas oficinas, remotamente desde cualquier otro lugar o
facilitar las operaciones en servidores locales o remotos en cualquier red.
Al centralizar el trabajo, una de sus funciones consiste en cachear y almacenar los recursos
necesarios para desarrollo y operaciones. Algunos de estos recursos serán probablemente pesados
como imágenes de entornos de desarrollo o Docker registry, por lo que será ideal contar con un
servidor que nos asegure la escalabilidad de la plataforma. En este sentido, es especialmente idóneo
un Servidor Cloud, en el que podamos ampliar el espacio necesario, o cualquier otro tipo de recurso,
bajo demanda y sin necesidad de incómodas migraciones.

117
Ilustración 38: Artifactory
1.4.4.6.5 Arquitectura
Ilustración 39: Arquitectura
1. El primer paso en el proceso de CI/CD es subir el código al repositorio GIT.

2. Jenkins detecta los cambios realizados en el repositorio y se encarga de compilar con gradlew
el código fuente.
3. Gradlew obtendrá las librerías necesarias desde el repositorio local Artifactory.
4. Jenkins someterá a pruebas unitarias y al análisis del código utilizando Sonar Qube.

118
5. Si todos los pasos son cumplidos satisfactoriamente Jenkins procederá a generar la imagen
Docker para su despliegue en Kubernetes.
1.5 Marco Metodológico
El proyecto se desarrollará en un marco de proyecto híbrido, es decir, en marco general se

utilizarán los planes de gestión, lineamientos y buenas practicas PMBOK 6, pero el desarrollo
será llevado a cabo con mesas ágiles.
Se propone aplicar un marco de trabajo para el escalado de las prácticas ágiles (Scrum) en
el desarrollo de software y sistemas.
Scrum aporta importantes ventajas en cuanto a la transparencia en los avances realizados,

cohesión, participación y autogestión de los equipos, comunicación y reducción del
riesgo, y cumplimiento de la calidad esperada, entre otras. El Consorcio entiende que
Scrum se adapta a las necesidades del proyecto, al promover un incremento de
productividad y visibilidad desde fases tempranas del mismo, empleando un enfoque
iterativo e incremental para optimizar la previsibilidad y gestión del riesgo.
1.5.1 SAFe - Scaled Agile Framework Enterprise (Escalado Ágil)
Antes de describir el framework SAFe, es importante circunscribir que la aplicación de

metodologías ágiles (en especial SCRUM), de aplicación a nivel de programa para gestionar los
requisitos y dividirlos en sprints más pequeños que luego serán gestionados como un proyecto, están
especialmente recomendados en aquellos proyectos que tengan un alto nivel de incertidumbre en
los requisitos o definición de alcance.

119
Cuánto menos claro están nuestros
No todos los proyectos son requisitos, más necesidad hay de
predictivos. planificar para adaptarlos.
La propia incertidumbre del El coste asociado al cambio es muy

mercado conduce al cambio. alto en los entornos de gestión
tradicionales.
Dynamic link between

Business and IT
Ilustración 40: SAFe
Es de vital importancia entender esta incertidumbre en los requisitos, los mismos que siempre serán
consensuados con los Product Owners de la SUNAT, ya que lo más probable es que el producto final
difiera del originalmente planificado; pues en la metodología SCRUM estos requisitos (que van
definiendo el alcance real del proyecto), pueden formar parte de un sprint o no en función de la
decisión consensuada y validada formalmente que determinen los Product Owners de la SUNAT y el
CONSORCIO. A este proceso se le conoce como Planificación Adaptativa.
A nivel de programa, los Product Owners de programa (o Product Managers) junto con los Product
Owners de la SUNAT determinarán el Product Backlog de lo que se denominará el Backlog del
Programa. Como consecuencia de esta “re-priorización” es posible que haya requisitos originales que
por diferentes motivos no sean relevantes para la SUNAT (como propietarios del producto, la SUNAT
tendrá la última palabra acerca de las funcionalidades a incluir en cada una de las iteraciones), y
salgan del alcance de la iteración.
A nivel de proyecto, para cada sprint, los POs de la SUNAT y el CONSORCIO determinarán el Product
Backlog de ese sprint de manera formal que está alineado al backlog de programa.
El resultado al cierre de un sprint de proyecto será validado por los Product Owners del CONSORCIO
y por el Product Owner de la SUNAT para verificar que las funcionalidades acordadas en el Product

120
Backlog para ese sprint han sido satisfechas, de modo que quede certificada la entrega del producto
específico de ese sprint.
Una vez finalizados los sprints de proyecto pertenecientes a un Incremento de Programa (o “Sprint
de Sprints”), se validará con los Product Owners del Programa (Product Managers) de la SUNAT y el
CONSORCIO el incremento de producto definido y acordado por las partes en el Product Backlog de
programa.
La consecución de iteraciones de Programa o “Sprint de Sprints” compondrán el producto final y,

dada la flexibilidad presentada por SCRUM a la hora de gestionar los requisitos, hará que el producto
final seguramente difiera en algunos aspectos del planificado en el punto inicial del proyecto,
suponiendo un cambio de alcance que con toda seguridad estará más alineado con las necesidades
reales de la SUNAT, que las inicialmente planteadas, con lo que esto nunca debería suponer un
problema.
El CONSORCIO dispone de amplia experiencia y un marco de metodológico de acuerdo a las

metodologías ágiles de Gestión de proyectos. Este marco de gestión incluye las mejores prácticas
definidas el Lean Management, Scrum y prácticas XP como se puede ver el siguiente gráfico:
Comunicación
Coraje Daily meetings Sprint Planning
Collective sw ownership
Integración continua
Refactoring
Sprint
Review
TDD
Respeto Feedback
Test automatizados
Iteraciones Retrospective
Simplicidad
Ilustración 41: Marco de Gestión
A continuación, se explica en mayor detalle el framework metodológico SAFe que soportará la Gestión
del Programa a través del Backlog de Programa y los diferentes de Incrementos de Programa o
“Sprint de Sprints” mencionados anteriormente:
Scaled Agile Framework o SAFe es un marco de trabajo que permite escalar los beneficios y
prácticas de Agile y Lean hacia todos los niveles de una organización -equipos, programas y
portafolio- a través de prácticas, roles y herramientas aplicadas a obtener entregas frecuentes de
software de valor y calidad, maximizando el beneficio al negocio y permitiendo mayor agilidad
organizacional. El propósito de SAFe es mejorar la competitividad, productividad y la entrega de
software de valor y calidad de la industria del desarrollo de software, brindar los beneficios del

121
desarrollo de software ágil hacia todos los equipos de desarrollo e incrementar la motivación y
empoderamiento de los equipos.
A nivel de equipo ofrece un modelo de proceso para los equipos ágiles basados en Scrum y
prácticas XP. A nivel de programa, los esfuerzos de múltiples equipos ágiles se integran para ofrecer
versiones de valor más grandes para la empresa. A nivel de portafolio los programas son alineados
con la estrategia de negocio y la intención de inversión.
Con la finalidad de buscar mejores formas de desarrollar software, Scaled Agile Framework se utiliza
para escalar con éxito el desarrollo más flexible y ágil, optimizando el flujo de valor a través de la
organización y desarrollo de sistemas.
Scaled Agile Framework es también una base de conocimiento para la implementación de prácticas
ágiles a escala empresarial, diferenciando y asignando roles individuales, actividades y artefactos
utilizados.
Ilustración 42: SCALED AGILE FRAMEWORK – VISTA GENERAL DEL FRAMEWORK
SAFe integra prácticas ágiles (especialmente Kanban, Scrum y XP) para de esta manera obtener un
framework integrado que se aplica a nivel Organizacional.

122
Backlogs
El backlog es la cola de requerimientos de negocio debidamente priorizados en función del Valor del
Negocio. En todo el modelo se manejarán 3 Backlogs diferentes:
 Portafolio Backlog: Contiene las épicas priorizadas y que van a ser ejecutadas, estas
épicas se priorizan en el Comité de Portafolio y son defendidas y seguidas por los
Epic Owner o Propietarios de la épica.
 Program Backlog: Contiene las descripciones genéricas de todos los requisitos,
funcionalidades deseables, que se encontrarán priorizadas y que van a ser
construidas en un roadmap. A nivel de programa la priorización es manejada por el
Product Manager.
 Team Backlog: En este nivel se encuentran las historias de usuario que se elaboran
y son debidamente priorizadas. La Priorización en este nivel es responsabilidad del
Product Owner.
A continuación gráfica en la cual se visualiza como se encuentran distribuidos los Backlogs para
cada nivel:
Ilustración 43: GESTIÓN DE BACKLOGS EN DISTINTOS NIVELES – SAFe
1.5.1.1 Nivel Portafolio
En el portafolio se definen las actividades macro que forman parte del Negocio y de la Arquitectura
Empresarial, estas épicas forman el backlog del portafolio que se administra en tableros kanban,

123
organizando de esta manera los temas de inversión de la empresa que en conjunto formarán la
propuesta de valor de la organización.
Ilustración 44: SCALED AGILE FRAMEWORK: NIVEL PORTAFOLIO
1.5.1.1.1 Características del Nivel de Portafolio

 Estrategia centralizada, ejecución descentralizada.
 Presupuesto Lean a nivel de Programa.
 Los sistemas Kanban proveen visibilidad del portafolio y limita el WIP.
 Métricas objetivas soportan el gobierno y la mejora continua.
 Descripción del Valor a través de Épicas de Negocio y arquitectura.
1.5.1.1.2 Roles dentro del Nivel de Portafolio

Los roles que intervienen a nivel de portafolio se describen a continuación:
 Equipo de Gestión de Portafolio (Portfolio Management Team): Dueños del negocio,

representantes de la PMO y Arquitectos Empresariales y otros interesados, que trabajan
conjuntamente para garantizar que las épicas aprobadas sean ejecutadas, la PMO facilita y
coordina las actividades a Nivel de Portafolio.
 Epic Owners: Trabajan con los stakeholders en la definición de épicas, generan el caso de
negocio, presentan, buscan la aprobación y velan por el cumplimiento de la épica.
 Enterprise Architect: Define la visión tecnológica del producto para soportar la estrategia de
negocio de la empresa.
1.5.1.2 Nivel Programa
Para el presente proyecto de la CUC, se manejará desde el nivel de programa. Una vez definido el
backlog de Portafolio con las épicas, se genera la visión y roadmap del producto (Release Plan),
descomponiendo la épica en Features que conforman el backlog de programa, que es compuesto
también por requerimientos no funcionales (NFRs).

124
Ilustración 45: SCALED AGILE FRAMEWORK: NIVEL PROGRAMA
A este nivel se genera un trabajo de integración de funcionalidades y requerimientos de arquitectura

organizados en un tren ágil para la liberación de soluciones (o Agile Release Train), todo el trabajo
se soporta sobre la construcción de una arquitectura.
1.5.1.2.1 Características del Nivel de Programa

 Auto-organización y autogestión de equipos ágiles.
 Software funcionando a nivel de Sistema al menos cada trimestre (definido en el reléase
plan).
 Alineamiento con una misión común a través un único backlog.
 Tamaño de sprint y estimación común.
 Cadencia de planificación Cara-a-Cara para la colaboración alineamiento, sincronización y
evaluación (Release Planning).
 Entrega de Valor a través de Features.
1.5.1.2.2 Roles dentro del Nivel de Programa

Los roles que forman parte de este nivel son los siguientes:
1.5.1.2.2.1 Release Train Engineer

El Ingeniero del Tren de Entrega o Gerente del Release (o RTE por sus siglas en inglés: Release
Train Engineer) asiste en la planificación, gestión y gobierno de los releases en uno o más trenes
ágiles. Es parte del equipo denominado Release Management Team que es el ente coordinador del
Release a través de todos los programas y equipos. Inicialmente se proponen incrementos de
producto cada 3 meses. El equipo de Gestión del Release canaliza y dirige todas las gestiones que
se ameriten para lograr una entrega satisfactoria incluyendo remover bloqueantes a nivel de
programa. De igual manera, el equipo tiene la autoridad para reunir a los roles de diferentes áreas
(Product Managers, System Team, Development Managers, Arquitectura, Operaciones y otros) para
coordinar asuntos relacionados al Release, identificar problemas y tomar decisiones para
desbloquear la entrega.
Entre las responsabilidades de este rol se encuentran:

125
 Coordinar y facilitar las reuniones Scrum de Scrums, Release Planning y otras requeridas a
nivel de programa.
 Consolidar, informar y asignar a las áreas impedimentos y hallazgos escalados en Scrum de
Scrums y Retrospectivas.
 Consolidar e informar sobre la salud del Release después de cada Release Planning.
 Consolidar las métricas para generar las métricas a nivel de programa (ver apartado
específico de métricas a seguir).
 Coordinar las reuniones planificadas del Sprint e invitar a los interesados.
 Coordinar reuniones en demanda con las áreas involucradas para resolver temas urgentes
que afecten al Release.
 Consolidar y compartir las métricas a nivel de Programa después de cada System Demo e
Inspect & Adapt.
 Coordinar y participar en reuniones de definición de procesos para la operación de los
equipos (Bugs, Soportes, otros).
 Coordinar, liderar y apoyar al equipo de Scrum Masters.
1.5.1.2.2.2 Product Manager

El Gerente de Producto o Product Manager es el responsable de definir y priorizar el backlog de cada
Programa al que está asignado, desarrolla la visión y el roadmap de las features en el tiempo y trabaja
con su equipo de Product Owners para optimizar la entrega de valor a través varios Releases.
Entre sus responsabilidades se encuentran:
 Comprender altamente el alcance funcional del producto y sus reglas de negocio.

 Definir las Features del Producto con la documentación y criterio de aceptación
necesarios.
 Trabajar colaborativamente con su equipo de POs para refinar y estimar las Features.
 Ordenar los elementos en el backlog de Programa para alcanzar los objetivos del
release de la mejor manera posible (maximizando el ROI).
 Expresar claramente los objetivos del Release hacia el equipo de POs.
 Explicar claramente las Features al equipo de PO desde un punto de vista de negocio.
 Asegurar que el Equipo de POs entiende los elementos del backlog de Programa al
nivel necesario.
 Aceptar o rechazar las Features en el ambiente de Integración o UATs.
 Revisar el progreso de las Features en cada tren en base a la aceptación de las
historias.
 Estar disponible siempre para el equipo para resolver inquietudes sobre las Features.

126
 Presentar el progreso de las Features en cada Release Planning a los interesados.
 Replanificar las Features en el tiempo en caso de cambio de prioridades.
 Trabajar colaborativamente con los Release Managers para resolver problemas e
impedimentos a nivel de programa.
 Trabajar colaborativamente con otras áreas relacionadas a Producto: Dueños del
Negocio, Gerentes de Proyecto, Representantes del Cliente, Miembros del Portafolio
y demás interesados.
 Coordinar presentaciones con Clientes para demostrar funcionalidad.
1.5.1.2.2.3 System Team

El System Team es un equipo especial a nivel de programa que provee asistencia en la
construcción y uso infraestructura de ambientes de desarrollo -incluyendo integración
continua, ambientes de compilación, plataformas de pruebas y herramientas para la
automatización de pruebas-, así como también la integración del código de los equipos ágiles,
ejecución de pruebas de sistemas end-to-end y de demostrar soluciones funcionando en la
System Demo al final de cada iteración. Provee feedback sobre la eficacia, integridad y
calidad de la solución.
 Infraestructura de Desarrollo
 Crear y mantener la infraestructura, incluyendo la integración continua, compilación
automatizada, plataformas de pruebas y herramientas para la automatización de
pruebas
 Crear plataformas y ambientes de demostración del sistema, QA, pruebas de usuario
(UATs), etc.
 Crear programas, utilidades y scripts para automatizar el despliegue
 Facilitar los aspectos técnicos de la colaboración con terceros, tales como los datos
o proveedores de servicios, las instalaciones de alojamiento, etc.
 Integración
 Determinar y ayudar a mantener las decisiones y políticas para el manejo de
branches y gestión del código fuente
 Ejecutar scripts de integración a nivel de sistema o integrar manualmente donde la
automatización no es posible o aún no se ha aplicado
 Ayudar a los equipos de componentes en la definición de las interfaces entre
componentes
 Asistir a los equipos en las actividades diarias

127
 Pruebas de Producto End-To-End
 Participar en el Release Planning para definir la integración y pruebas de historias de
usuario;
 Crear nuevos escenarios de pruebas automatizadas;
 Ampliar los escenarios de prueba para conjuntos de datos más grandes;
 Organizar casos de prueba diseñados por equipos individuales en suites ordenadas;
 Realizar las pruebas manuales y ejecutar pruebas automatizadas para las nuevas
características e historias;
 Probar el rendimiento del sistema de prueba frente a los requisitos no funcionales y
ayudar a los arquitectos de sistemas en la identificación de las deficiencias del
sistema y los cuellos de botella.
1.5.1.3 Nivel Equipo SCRUM.
Toda la planificación y ejecución del portafolio y del programa recae en actividades puntuales a ser
atendidas por los equipos Scrum, para esto cada equipo ágil posee su backlog que a su vez es
dividido en backlogs de los sprints.
Ilustración 46: SCALED AGILE FRAMEWORK: NIVEL SRUM TEAMS
En este nivel se utilizan prácticas de Scrum y XP para el desarrollo de software en iteraciones de

cuatro semanas.
1.5.1.3.1 Características del Nivel de Equipo.

 Incrementos cada cuatro semanas de software de valor y completamente probado.
 Equipos empoderados, auto-organizados, autogestionados y crosfuncionales.
 Los equipos operan bajo una visión de programa y arquitectura y una guía de UX.
 Desarrollo del producto usando técnicas basadas en XP.
 Entrega de valor a través de Historias de Usuario.
1.5.1.3.2 Roles dentro del Nivel de Equipos

128
El consorcio dispondrá de un equipo de profesionales multifuncionales que conformar las
mesas agiles para el análisis, desarrollo, prueba e integración de los requerimientos del
SCUC. Estos equipós estarán conformados por los roles descritos a continuación:
a. Product Owner
El Dueño de Producto es el miembro del equipo ágil responsable de maximizar el valor del
producto y del trabajo del Equipo de Desarrollo. El Dueño de Producto es la única persona
responsable de gestionar la Lista del Producto (Product Backlog) que debe expresar los
objetivos del negocio y del programa.
 Expresar claramente los objetivos del Sprint hacia el equipo de desarrollo

 Definir las historias de usuario asociadas a los objetivos del sprint y los criterios de
aceptación respectivos
 Ordenar los elementos en la Lista del Producto para alcanzar los objetivos del sprint y
del programa de la mejor manera posible (maximizar el ROI)
 Explicar claramente las historias de usuario al equipo de desarrollo desde un punto de
vista de negocio
 Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto
al nivel necesario
 Aceptar o rechazar las historias de usuario en la Sprint Demo
 Detectar o recibir bugs, analizarlos y priorizarlos en el backlog
 Probar y aceptar los bugs que se han corregidos en el sprint antes de pasar a
ambientes de Integración o UATs
 Hacer el “refinamiento” del Product Backlog; es decir, trabajar refinando las historias
del siguiente sprint mientras el equipo desarrolla las historias actuales
 Estar disponible siempre para el equipo para resolver inquietudes sobre las historias
del sprint
b. Scrum Master
El Scrum Master es el miembro del equipo cuya responsabilidad primaria es ayudar a los
equipos de desarrollado en cumplir los objetivos del Sprint. Es el responsable de asegurar
que los procesos organizacionales de Scrum y SAFe son comprendidos y adoptados. El
Scrum Master es un líder que está al servicio del equipo de desarrollo. El Scrum Master ayuda
al equipo de desarrollo a mejorar su interacción entre los miembros del equipo, entre el equipo
y otros equipos ágiles y entre el equipo y la organización. Ayuda a identificar, notificar y
remover impedimentos para que el equipo desarrolle a su plena capacidad.

129
 Coordinar y facilitar las reuniones de SAFe según se requiera o necesite

 Ayudar al PO a mostrar de forma efectiva su lista de producto hacia el equipo
 Ayudar al Equipo Ágil a entender el objetivo del sprint
 Eliminar impedimentos para el progreso del Equipo de Desarrollo
 Asegurar que el estado de las tareas se actualice diariamente en la Reunión Diaria
 Colocar el trabajo del equipo visualmente y asegurarse que se encuentre actualizado
 Llenar y publicar las métricas de desempeño del equipo al final de cada sprint (ver
apartado específico de métricas a seguir)
 Registrar los impedimentos en el Impediment Backlog y escalarlos en Scrum de Scrum
 Reportar y escalar en demanda hacia los Release Train Engineers novedades que
merezcan atención en función de la urgencia e impacto
 Apoyar a la organización en la adopción de SAFe y Scrum
 Ayudar a los empleados e interesados a entender y llevar a cabo SAFe y Scrum
 Trabajar con los Development Managers en motivar cambios que incrementen la
productividad del Equipo Ágil
 Lograr que el equipo respete los acuerdos organizacionales y del equipo
 Trabajar con otros Scrum Masters, Release Train Engineers y Development Managers
para incrementar la efectividad de la aplicación de SAFe en el programa y la
organización
c. Equipo Ágil
El Equipo de Desarrollo es un grupo de profesionales que tienen la habilidad y

responsabilidad de construir y probar un incremento de un producto en un lapso corto y
definido (timebox), que proponemos sea de 4 semanas para el CUC. Consiste en los
profesionales que desempeñan el trabajo de entregar un Incremento de producto
“Terminado”, que potencialmente se pueda poner en producción, al final de cada Sprint. Solo
los miembros del Equipo de Desarrollo participan en la creación del Incremento de Producto.
Los Equipos de Desarrollo son estructurados y empoderados por la organización para

organizar y gestionar su propio trabajo. La sinergia resultante optimiza la eficiencia y
efectividad del Equipo de Desarrollo.
 Comprender el contexto de negocio y los objetivos del sprint;

130
 Comprender el propósito y el alcance de cada historia de usuario;
 Descomponer el trabajo en tareas de cada historia de usuario presentada por el PO
que logren cumplir a cabalidad con los criterios de aceptación de la historia y que
aseguren la calidad técnica y cumplan con la Definición de Done;
 Estimar las tareas e historia en base a su complejidad en función de su conocimiento,
experiencia y habilidades;
 Asegurar la calidad técnica y estructural de cada historia desarrollada en el sprint;
 Conocer la Definición de Done organizacional y de cada equipo;
 Actualizar su trabajo diariamente en el tablero físico y digital;
 Agregar criterios de aceptación para nuevos escenarios de pruebas que se descubran
durante el sprint;
 Notificar clara y oportunamente los problemas o impedimentos que se tenga durante
el sprint;
 Asistir y participar eficazmente en las ceremonias de Scrum;
 Respetar los acuerdos organizacionales y del equipo;
 Apoyar a otros miembros del equipo en revisión de tareas, capacitación o problemas
que puedan presentarse;
 Asegurar que el estado de las tareas se actualice diariamente en el Daily StandUp;
 Actualizar los campos de Remaining Work diariamente sobre las tareas que se están
trabajando;
 Participar de forma honesta en la Retrospectiva y levantar los aspectos de mejora que
sean necesario;
 Apoyar al Scrum Master en la remoción de impedimentos;
 Apoyar al Scrum Master en las ceremonias de Scrum.
1.5.1.4 Nivel programa - CUC
La estructura del programa de la SUNAT tiene varios niveles de división. Estos niveles pueden
abstraerse en las siguientes gestiones: Gestión del Portafolio, Gestión de Programa y Gestión de
Proyectos, tal como se muestra a continuación:

131
GESTIÓN DE PORTAFOLIO
(Estrategia)
GESTIÓN DE PROGRAMA
(Coodinación)
GESTIÓN DE PROYECTOS
(Ejecución)
Ilustración 47: Estructura del Programa CUC y SAFe
El marco metodológico SAFe está diseñado para soportar naturalmente los niveles mencionados,
proporcionando prácticas, roles y mecanismos exitosamente probados para la gestión de muchos
equipos ágiles a través de varios programas en iniciativas de tecnología que aportan valor a la
organización. De esta forma, es posible hacer una coincidencia de los niveles de gestión del
Programa con los niveles de SAFe:

132
Ilustración 48: Niveles de Gestión de SAFe
1.5.1.4.1 Releases
Un Release o entregable es un conjunto de características validadas y completas que han probado
su eficiencia y eficacia para uso final, acompañado de la documentación y recursos necesarios para
asegurar una instalación y despliegue exitoso. En SAFe, el desarrollo de se realiza en cadencia,
mientras que la decisión de enviar un entregable a producción se realiza en demanda en función a la
decisión del equipo del Programa y el Cliente. Significa que la definición de la fecha de una entrega
es una decisión de negocio, a partir del número de features completas y su estabilidad que
representan un valor en un tiempo determinado. En consecuencia, un Release es una acumulación
features de varios equipos ágiles. Inicialmente se proponen Releases cada 3 meses.

133
Ilustración 49: Release
Al aplicar SAFe se crea un esquema de mejoras respecto a la calidad, esto se debe a la

retroalimentación continua que permite obtener los siguientes beneficios:
 Entregas en periodos cortos (a ser acordados con el Cliente contractualmente);

 Retroalimentación más rápida y continua nos permite identificar oportunamente errores, así
como también determinar mejoras, las mismas que al ser identificadas a tiempo permiten
realizar los cambios necesarios de manera oportuna y ajustar la planificación;
 Todos los Releases se encontrarán definidos contemplando el Conjunto de Características
planeada y la fecha en la cual se realizará la liberación, todo esto contemplando que el producto
entregado sea de calidad;
 Mientras existe un alcance que se maneja de forma variable, la fecha de entrega del release y
la calidad son fijas.
1.5.1.4.2 Tren de entrega ágil

Agile Release Train o ART es un grupo de equipos trabajando en la entrega de valor en una
cadencia definida y constante. El término surge de la analogía de las salidas de los trenes de
una estación, las mismas que se definen en rangos uniformes de tiempo y de constante
consecución. Cada ART produce un incremento de sistema; donde se integran todas las
características o Features de todos los equipos ágiles y programas que se terminaron y
aceptaron por los Product Managers. La integración del incremento de sistema sugerida es
trimestral. Sin embargo, es el negocio quien define la salida al mercado de un número
acumulado de features que corresponde a un tren específico.

134
Ilustración 50: Desarrollo en Cadencia. Entrega en Demanda.
1.5.1.4.3 Iteración (Sprint)

Una Iteración o Sprint es un periodo de tiempo fijo estrictamente definido (timebox) en el cual un
equipo de desarrollo ágil se compromete a entregar valor de forma de un incremento de software
probado y funcionando. La duración es de cuatro semanas formando así una cadencia de desarrollo
constante.
En el consorcio, todos los equipos ágiles trabajarán con la misma cadencia de desarrollo para facilitar
el control del trabajo, reuniones, pruebas, demos del sprint y de sistema, liberaciones, entre otros.
Ilustración 51: Anatomía de una Iteración

135
Para cada iteración, los equipos ágiles trabajan bajo el marco de desarrollo ágil denominado Scrum
y usan las prácticas de Programación Extrema (eXtreme Programming) para asegurar el
cumplimiento de las necesidades de negocio, la calidad y la excelencia técnica.
CADENCIA A NIVEL DE PROGRAMA Y DE EQUIPOS
Bajo la dinámica de Scrum, un equipo ágil cumplirá con las siguientes ceremonias y entregables:
SPRINT 1 SPRINT 2 SPRINT 3 SPRINT N
Semana 1 Semana 4 Semana 5 Semana 8 Semana 9 Semana 12 Semana N Semana N+4
Sprint Planning
Sprint Demo
Retrospectiva
Incremento de Incremento de Incremento de Incremento de

Producto Producto Producto Producto
Ilustración 52: Cadencia a Nivel de Equipos
En un enfoque de escalamiento, para la coordinación y alineamiento de varios equipos trabajando en

una gran solución de software, SAFe propone una cadencia a nivel de programa donde se escalan
las ceremonias y prácticas ágiles, generando entregables de valor más grandes a través de la
integración y aprobación del incremento de cada equipo, lo que se denomina: Incremento de
Programa. La cadencia a nivel de Programa propuesta es la siguiente:

136
PROGRAM INCREMENT 1 PROGRAM INCREMENT 2
Sprint 1 Sprint 2 Sprint 3 Sprint N-2 Sprint N-1 Sprint N
Release Planning
System Demo
Inspect & Adapt
Scrum de Scrums
Seguimiento
Integración ST
Incremento de Incremento de Incremento de Incremento de

Release 1 Release 2
Sistema Sistema Sistema Sistema
Ilustración 53: Cadencia a nivel de programa
En una línea del tiempo, el ritmo de entrega de valor y actividades principales para la integración y
aprobación de los incrementos de Programa y Equipos es el siguiente:
Ilustración 54: Cadencia Integrada Y Actividades Generales
Puntos de Validación Intermedia de las Entregas Parciales
Se prevén los siguientes puntos de validación del alcance entregado:

137
 Sprint Demo: Durante la presentación de los resultados de cada mesa ágil en cada sprint, y
previo a la retrospectiva, se establecerá un punto de validación del alcance de los desarrollos
en curso
 Release Demo: Al igual que en cada sprint, cada reléase Demo será un punto de control de
la aplicación desplegada.
Estos puntos de control permitirán comprobar la calidad de los desarrollos entregados, así como
validar el grado de cumplimiento con las épicas iniciales, y detectar en su caso:
 Defectos en cada sprint, que formarán parte del backlog del siguiente sprint
 Cambios de alcance sobre la funcionalidad marcada en las diferentes épicas, que deberán
seguir el procedimiento establecido para estos casos.
1.5.1.4.4 Métricas
Según el manifiesto Ágil solo hay una métrica principal, siendo el resto son secundarias.
Una vez controles esa métrica prueba a utilizar alguna más. Esta métrica no es otra que:
“El software funcionando es la principal medida de progreso”
Firmantes de manifiesto ágil
Sin embargo y como si de cualquier otro sistema de gestión se tratara, una vez activado,
es necesario llevar a cabo una serie de acciones de seguimiento (para comparar el avance
respecto las líneas de base (objetivos establecidos)) y control (para implementar medidas
correctivas si fuera necesario). Nada de lo anterior sería posible sin un sistema de
indicadores o métricas. Es por ello, que proponemos las siguientes métricas de
seguimiento a nivel de Programa:
1.5.1.4.4.1 Diagrama de Flujo Acumulado

Se trata de uno de los instrumentos más potentes de Kanban; permite hacer una lectura
rápida sobre “el fluir” del flujo que se representa, y tomar decisiones para favorecer el
flujo. El objetivo de trabajar con metodologías “Agile” es optimizar el flujo, reduciendo los
tiempos de ciclo y acortando los tiempos de entrega.
A partir de una buena comprensión y diseño del flujo de valor, podría definirse el
Diagrama de Flujo Acumulativo (Cumulative Flow Diagramme, CFD).

138
Ilustración 55: Diagrama de Flujo Acumulado
1.5.1.4.4.2 Informe de progreso de las Épicas

El Informe de Progreso de las Épicas sirve, como su propio nombre indica para llevar a
cabo el seguimiento de las mismas. Es una métrica bastante similar a la de proyectos
más tradicionales.
En la Figura puede observar un Informe de Progreso de las Épicas. Observa la primera

estimación del tamaño del trabajo (línea roja) en comparación con la estimación actual.
Además, pude comprobarse cuanto trabajo se ha completado en comparación con la
estimación original.

139
Ilustración 56: Informe de Progreso de las Épicas
1.5.1.4.5 Mantenimiento Correctivo y Soporte.

En base a su experiencia en la aplicación exitosa de métodos ágiles en proyectos a gran escala, el
CONSORCIO propone usar el método ágil KANBAN para los equipos asignados al Mantenimiento
Correctivo y de Soporte. Kanban ofrece el nivel de adaptabilidad, flexibilidad y atención al tipo de
trabajo que se genera en estas etapas; permitiendo mejor gestión de la carga de trabajo a demanda
y mejor respuesta al trabajo emergente.
1.5.1.4.5.1 KANBAN
Kanban es un método que facilita y mejora el flujo de valor a través de la visualización del
flujo de trabajo, el establecimiento de límites al trabajo en progreso, la medición del
desempeño a través del flujo y la mejora continua del proceso. Kanban es un método de
“arrastre” donde el equipo de trabajo toma el trabajo que conoce que puede atender en base
a su capacidad y a las prioridades en demanda del negocio.
Kanban es una palabra japonesa que significa “tarjetas visuales”, donde Kan es “visual”, y
Ban corresponde a “tarjeta”.El origen de la metodología Kanban debemos buscarlo en los
procesos de producción “just-in-time” (JIT) ideados por Toyota, en los que se utilizaban
tarjetas para identificar necesidades de material en la cadena de producción.

140
Kanban usa un mecanismo de control visual para hacer seguimiento del trabajo conforme
este viaja a través del flujo de valor. Típicamente, se usa un panel o pizarra con notas
adhesivas o un panel electrónico de tarjetas. Las mejores prácticas apuntan probablemente
al uso de ambos. La transparencia que esto genera contribuye también al cambio cultural.
Las metodologías Ágiles han obtenido buenos resultados proporcionando transparencia
respecto al trabajo en curso y completado, así como en el reporte de métricas como la
velocidad (cantidad de trabajo realizada en una iteración). Kanban sin embargo va un paso
más allá y proporciona transparencia al proceso y su flujo. Kanban expone los cuellos de
botella, colas, variabilidad y desperdicios. Todas las cosas que impactan al rendimiento de la
organización en términos de la cantidad de trabajo entregado y el ciclo de tiempo requerido
para entregarlo.
Ilustración 57: Kanban
EJEMPLO DE UN TABLERO KANBAN
Kanban proporciona a los miembros del equipo y a las partes interesadas visibilidad sobre
los efectos de sus acciones (o falta de acción). De esta forma, los casos de estudios
preliminares están demostrando que Kanban cambia el comportamiento y motiva a una
mayor colaboración en el trabajo. La visibilidad de los cuellos de botella, desperdicios y
variabilidades y su impacto también promueve la discusión sobre las posibles mejoras, y los
equipos comienzan rápidamente a implementar mejoras en su proceso.
1.5.1.4.5.1.1 Principios Del Método Kanban

La esencia del método Kanban puede describirse en los siguientes puntos:
 Visualizar el Flujo de Trabajo

141
 Definir límites al trabajo en progreso (WIP Limits)
 Gestionar el flujo
 Definir políticas explicitas
 Implementar ciclos de retroalimentación y mejora
1.5.1.4.5.1.2 Métricas de Kanban

Kanban es posiblemente el método ágil que más métricas proporciona. A continuación, se destacan
las principales, proponiéndose solamente las tres primeras:
 Cycle Time o Tiempo de Ciclo: Es la métrica que registra el tiempo que sucede entre el
inicio y el final del proceso, para un ítem de trabajo dado. En software sería desde que se
inicia a trabajar sobre una funcionalidad hasta que se termina la misma. Normalmente se
mide en días de trabajo.
 Lead Time o Tiempo de Espera: Es la métrica que registra el tiempo que sucede entre el
momento en el cual se está pidiendo un ítem de trabajo y el momento de su entrega (el final
del proceso). En software es el tiempo que transcurre desde que se identifica una
funcionalidad y se solicita hasta que se entrega dicha funcionalidad. Normalmente se mide
en días de trabajo.
Ilustración 58: Métricas de Kanban
 Diagrama de Control de Variabilidad: Muestra el comportamiento histórico de una métrica

particular, normalmente el Tiempo de Ciclo, para identificar el nivel de variabilidad del dato y
los límites superiores e inferiores. A mayor variabilidad menor predictibilidad, por lo tanto, es
muy útil para proyecciones del trabajo e estimaciones de proyecto a alto nivel.

142
Ilustración 59: Diagrama de Control de Variabilidad
DIAGRAMA DE VARIABILIDAD
Las métricas que se muestran a continuación, aun siendo de uso común, no las recomendamos para
el seguimiento del mantenimiento y garantía.
 Touch Time o Tiempo de Tocado: Es la métrica que registra el tiempo en el cual un ítem
de trabajo fue realmente trabajado (o "tocado") por el equipo. Dicho de otra forma: cuantos
días hábiles pasó este ítem en columnas de "trabajo en curso", en oposición con columnas
de cola / buffer y estado bloqueado o sin trabajo del equipo sobre el mismo. Con lo cual, para
un mismo ítem: Touch Time ≤ Cycle Time ≥ Lead Time.
 Throughput: La cantidad de ítems entregados en un período de tiempo.
 Diagrama de Lead Time y Cycle Time: Muestra la evolución en el tiempo de las métricas
Cycle Time y Lead Time. Este diagrama es útil para evidenciar el comportamiento del flujo
de entrega de valor y los tiempos promedios de entrega.

143
Ilustración 60: Diagrama de Lead Time y Cycle Time (Diagrama de tiempos de espera y de ciclo)
 Diagrama de Flujo Acumulado: Muestra la cantidad relativa de trabajo para cada etapa del
flujo de trabajo en el tiempo. El diagrama debería funcionar sin problemas. Los grandes
bloques y líneas horizontales planas indican impedimentos para fluir o falta de flujo. Las
variaciones en las bandas representan situaciones de cuello de botella.
Ilustración 61: Diagrama de Flujo Acumulado

144
 Diagrama de Envejecimiento: Muestra el tiempo de permanencia de los ítems de trabajo
en el backlog. Esta información es importante para evaluar el Costo de la Demora que posee
un impacto económico sobre el flujo y el sistema. Entre más permanece o “envejece” una
solicitud en un backlog, mayor es su Costo de Demora, por lo que debe ser atendido,
repriorizado o eliminado. Este enfoque responde a una mentalidad de mantener el mínimo
inventario.
Ilustración 62: Diagrama de Envejecimiento
1.5.1.4.5.1.3 Kanban para Equipos de Mantenimiento Correctivo y de Soporte

La naturaleza de trabajo que se genera en las etapas de Mantenimiento y Garantía no respeta
necesariamente una cadencia constante de entrega de valor de forma síncrona. Es decir,
existe trabajo emergente o “no planificable” que pueda ser previsto dentro de la planificación
de un Sprint. Por ejemplo: atención a errores urgentes, gestión de incidentes y soportes. Al
presentarse una problemática diferente, el enfoque metodológico debe ser diferente enfocado
a este contexto.
A través de Kanban se puede manejar, atender y medir el trabajo planificable

(mantenimientos evolutivos con fechas acordadas, controles de cambio, mantenimiento
evolutivo) y el emergente (errores urgentes, soportes correctivos, etc.). A través del manejo
de Clases de Servicio, un equipo Kanban puede clasificar el tipo de trabajo y atenderlo según
la naturaleza del mismo; en base a prioridad que se decide en demanda y a SLAs que se
acuerdan con los Clientes.

145
1.5.1.4.5.1.4 Clases de Servicio
Kanban maneja normalmente las siguientes clases de servicio:
o Estándar: Actividad de negocio con visibilidad al Cliente, pero que no tiene una fija
determinada de finalización. La mayoría de los elementos del backlog se consideran
un “caso normal que no es específicamente dependiente de la fecha. El costo de la
demora es lineal para elementos estándar, el valor no se logra hasta que se produce
la entrega, pero no hay ningún requisito fecha fija.
o Fecha Fija: Actividad de negocio con visibilidad al Cliente con fecha fija de entrega.
Ítems de trabajo con fechas fijas que representan hitos y poseen dependencia a una
fecha predeterminada. Estos artículos son introducidos en desarrollo cuando sea
necesario, a fin de ser terminado en el tiempo; algunos pueden requerir un análisis
adicional para refinar el tiempo de espera que se esperaba.
o Expedito: Trabajo urgente que debe ser atendido. Un ítem de trabajo "Expedito"
requiere atención inmediata; se puede incluso ignorar de las restricciones actuales
WIP. Por lo general sólo puede haber un elemento "Expedito" en el flujo a la vez, y
los equipos podrán establecer una política de "enjambre" (todos trabajando sobre el
ítem) para asegurarse de que se mueve a través del sistema de manera expedita o
fluida.
Ilustración 63: Clases de Servicio
Manejo de clases de servicio en un tablero KANBAN
La tabla a continuación explica las diferencias principales entre Scrum y Kanban:

146
SCRUM KANBAN
Sprints de duración fija

Cadencia Flujo continuo
(normalmente 2-4 semanas)
Entrega continua o en función
Al final del Sprint si lo aprueba
Entregas de la discreción del equipo y
el Product Owner
stakeholders
No hay roles. Normalmente
Product Owner, Scrum
Roles existe un Agile Coach o un
Master, Equipo de Desarrollo
Líder de Equipo
No hay ceremonias pre-
escritas. Normalmente los
Planificación del Sprint,
equipos Kanban usan la
Ceremonias Reunión Diaria, Sprint Demo,
reunión Diaria y realizan
Retrospectiva
Retrospectivas en cualquier
momento.
Métricas Clave Velocidad Tiempo de Ciclo
El equipo no debe ser
El cambio pasa en cualquier
interrumpido y no se debe
momento. Se puede tomar el
hacer cambios en el alcance
trabajo y asignarlo al flujo en
Enfoque frente al Cambio del Sprint. Se hace
base a políticas. No hay foco
estimaciones y compromisos
en la estimación. Se lleva las
en función del aprendizaje del
métricas del esfuerzo real.
equipo
Ilustración 64: Manejo De Clases De Servicio En Un Tablero Kanban
Diferencias entre SCRUM y KANBAN
El marco de trabajo SAFe habilita el uso de equipos con diferente enfoque metodológico trabajando
juntos en tren. De esta forma, es perfectamente posible alinear y trabajar con equipos Scrum y
Kanban en cualquier momento de la vida del proyecto.

147
Equipos SCRUM y KANBAN en SAFe
1.5.1.5 Nivel Equipo Scrum – CUC
A continuación se detalla la personalización del marco de trabajo Scrum a las necesidades

de LA SUNAT.
Asignar Product Owner
En esta actividad se deberá seleccionar el Product Owner como responsable de maximizar

el valor del producto entregado y controlar el backlog del producto.
Sprint cero
El Sprint cero permite identificar los objetivos del proyecto y reducir la incertidumbre
respecto al alcance y respecto al enfoque tecnológico. El Sprint cero produce todo lo
necesario para poder empezar a trabajar con un enfoque ágil.
Tomando como punto de partida la definición de requisitos funcionales y no funcionales, en

forma de historias de usuario especificadas en el pliego, el objetivo último de este Sprint
cero es obtener una visión clara de:
 Qué se va a implementar, en forma de backlog del producto y prototipos.
 Cómo se va a implementar, en forma de Arquitectura técnica.
 Cuáles son los componentes, en forma de Documento de Dependencias.
 Y Cuánto tiempo se va a tardar en alcanzar los objetivos en de los MVPs definidos por
LA SUNAT.

148
Como salida de este Sprint cero se generarán tres productos principales: El Plan de
Releases, Documento de Dependencias y un backlog del producto inicial revisada con LA
SUNAT.
Sprints de cuatro semanas de duración
El desarrollo de las historias de usuario de backlog del producto se realizará en Sprints o

iteraciones de cuatro semanas de duración.
Los estados por los que puede pasar una historia de usuario, propuestos por LA SUNAT en
el Pliego, permitirán medir el avance de la Release y del MVP en curso. No obstante, será
posible visualizar el avance real de cada Sprint por medio de los gráficos de Burndown.
Para integrarse de manera efectiva con el marco de Scrum, el diseño de la experiencia

de usuario (UX) no se define exclusivamente a priori o se evalúa a posteriori. El diseño
de la Experiencia de usuario (UX) tendrá aportaciones muy importantes para ayudar al
proceso de refinamiento que se hace durante un Sprint (n) para anticipar lo que será
el trabajo para el siguiente Sprint (n+1). Este enfoque se denomina Dual Track.
Herramientas de UX para investigar a usuarios y sus reacciones, para validar prototipos de
partes del producto o para hacer análisis competitivo, entre otras, son y pueden ser
utilizadas durante el Sprint. Se utilizan para ayudar a mitigar el riesgo de no saber cómo un
usuario reacciona ante uno de los elementos del Product Backlog que se están
contemplando para el siguiente Sprint. Estos esfuerzos se hacen en colaboración con los
desarrolladores y claramente con el dueño del producto (product owner) y otros
stakeholders.
Planificación de Sprints
Al comienzo de cada Sprint se le confirmará a LA SUNAT el conjunto de historias de

usuario que serán incluidas en el Sprint, en función de la planificación tentativa, el
avance del proyecto, la estimación actualizada de las historias de usuario, y el conjunto de
las mismas que puedan haber sido parte de sprints anteriores, pero no lograron su
aprobación.
En cada semana de trabajo del Sprint se podrá realizar una reunión de refinamiento junto
con el Product Owner de la SUNAT, para aclarar cualquier duda sobre las historias de
usuario del backlog del producto. Esto mejorará el entendimiento del equipo Scrum sobre
el alcance a planificar en la siguiente actividad de Planificación de Sprint. Debido a que el
backlog de producto es un artefacto vivo en Scrum, es posible que la priorización de

149
nuevas historias de usuario por parte del Product Owner de la SUNAT condicionen
las fechas comprometidas de los MVPs.
Las entradas para esta actividad de planificación serán:
 Backlog del producto actualizado y priorizada.
 Plan de Gestión del proyecto.
 Producto desarrollado hasta la fecha, si no se trata del primer Sprint.
 Velocidad estimada del equipo en función de las velocidades obtenidas en los últimos
sprints, que se utilizará como uno de los criterios a tener en cuenta para seleccionar la
cantidad de trabajo del Sprint.
En la reunión de planificación de Sprint estará presente el Product Owner de LA SUNAT, y

el Plan de Sprint deberá ser aprobado en Mesa Ágil por los siguientes representantes de
LA SUNAT: Jefe de Proyecto, Product Owner, Desarrollo y Calidad.
La actualización constante y periódica del backlog del Producto permitirá a LA SUNAT

conocer en todo momento el alcance pendiente de completar, y, por tanto, candidato a
incluir como parte de la Planificación de Sprint.
Revisión de Sprints
Al final de cada Sprint se mostrará el trabajo realizado a LA SUNAT en una reunión de

revisión del incremento alcanzado. El objetivo principal de esta reunión es obtener
feedback por parte de los usuarios.
Entre los asistentes a esta reunión de revisión de Sprint, estarán, por parte de LA SUNAT,
el Jefe de proyecto, Product Owner, y los responsables de desarrollo, calidad, operación,
arquitectura, y seguridad de la información.
La revisión de Sprint generará un informe con el resultado de la ejecución del Sprint y

la consiguiente actualización del backlog del producto. Una vez finalizada la revisión de
Sprint, el incremento de producto alcanzado en el mismo se desplegará en el ambiente
de Pruebas.
Scrum de scrums.
Cuando el número de recursos llegue a su pico más alto de proyecto, será importante
garantizar una adecuada coordinación entre los diferentes equipos Scrum involucrados. Es
en ese momento cuando será necesario realizar reuniones de escalado Scrum de Scrums.
Es decir, una reunión en donde varios Scrum Masters se reúnen, tras haber realizado las

150
respectivas sincronizaciones diarias de trabajo de sus equipos. En estas reuniones el Jefe
de proyecto del Consorcio podría adoptar el rol de Chief Scrum Master, de manera que en
una única ceremonia se puedan coordinar las posibles dependencias entre los equipos,
escalar los impedimentos no resueltos que estén afectando al trabajo diario de cualquier
equipo, así como actualizar el avance de trabajo real con respecto al planificado.
Herramientas de apoyo
Es importante tener un feedback del progreso de cada uno de los Sprints. Esto es
responsabilidad del equipo de desarrollo y debe hacerse al menos una vez al día durante
la sincronización diaria de equipo o Daily.
Esta información es muy relevante para calcular la probabilidad de alcanzar el objetivo del
Sprint y completar todos los elementos comprometidos en la sesión de Planificación.
La información del progreso del Sprint puede representarse en un gráfico de avance visible
para todo el mundo.
Esta medición se basa en las tareas en las que han sido granuladas cada historia de usuario
del Sprint, y cómo van siendo completadas a medida que va avanzando el Sprint. Es lo que
se conoce como Sprint Burndown chart. Este gráfico de avance será actualizado por
los equipos de desarrollo en cada Daily.
Además del gráfico de avance de Sprint, los equipos utilizarán tableros Kanban que
permitan mostrar el avance de las tareas de la iteración en curso y establecer acciones
correctoras cuando se identifique algún riesgo o impedimento.
1.5.1.5.1 Definición de eventos.

a) Eventos o reuniones a realizar.
En Scrum existen diversas reuniones o eventos, también llamadas ceremonias, que

tratan de crear regularidad y reducir al mínimo la necesidad de reuniones fuera de las
definidas en este marco de trabajo.
A continuación, se detallan las ceremonias o reuniones que tienen lugar cada Sprint.

151
Periodicidad y
Reunión Asistentes Objetivos Salidas
duración
Reunión de Cada cuatro Product Owner Primera parte: Sprint backlog.
planificación semanas, al inicio Responsable de Identificar elementos Objetivo del
del sprint del sprint desarrollo, del backlog de sprint.
Duración: 8 horas calidad de producto a abordar en Duración del
SUNAT y Jefe de el sprint. sprint y fecha de
proyecto Identificar línea base la reunión de
Scrum Master de recursos para el revisión.
Equipo de sprint.
Desarrollo Depuración de las
Otros historias de usuario.
stakeholders Segunda parte:
Moderador: Descomposición y
Scrum Master estimación de esfuerzo
de las historias.
Auto asignación de las
tareas en el equipo.
Reunión daily Diaria. Equipo de Lo que ha logrado Actualización
meeting Duración: no más Desarrollo. desde el anterior Kanban.
de 15 minutos. Scrum Master scrum diario. Actualización
(opcional) Lo que va a hacer gráfico de
Otros hasta el próximo scrum avance del
stakeholders y/o diario. sprint.
Product Owner Si están teniendo
en casos algún problema, o si
específicos prevé que puede
Moderador: encontrar algún
Equipo de impedimento.
Desarrollo
Reunión de Cada tres Product Owner. Enseñar el incremento Feedback para
revisión del semanas, al final Responsables realizado. el Product
sprint del sprint. aplicaciones Verificación de Owner.
Duración: no más involucrados cumplimientos del Scrum Master
de 4 horas. Scrum Master sprint. fija fecha de la
Equipo de Atención al feedback reunión de
Desarrollo obtenido en la sesión.

152
Periodicidad y
Reunión Asistentes Objetivos Salidas
duración
Otros planificación del
stakeholders siguiente sprint.
Reunión de El equipo Scrum Product Owner Mantener actualizado Product backlog
refinamiento podrá realizar una Scrum Master el Product Backlog. refinado.
sesión de Scrum Master Incorporar nuevas
refinamiento por Equipo de historias de usuario,
semana de trabajo Desarrollo división de historias,
en el Sprint. replanteamiento de
Duración: en total historias ya definidas y
no más del 10% estimación.
del tiempo del Garantizar la definición
sprint. de Layout o UX, para
que el Equipo de
Desarrollo pueda
empezar a trabajar en
el siguiente Sprint.
Reunión de Cada cuatro Scrum Master Analizar el “Cómo”. Plan de acción
retrospectiva semanas, tras la Equipo de Analizar problemas y con las
reunión de Desarrollo aspectos mejorables propuestas de
revisión. Product Owner del proceso. mejora.
Duración: no más DoD actualizada.
de 4 horas.
1.5.2 DevOps
DevOps es una cultura de trabajo que se apoya en un conjunto de prácticas y en una colección
de herramientas que conforman un proceso de mejora continua de la capacidad de los equipos que
colaboran en la entrega de software, dando como resultado mayor calidad, fiabilidad y frecuencia de
las entregas.
La cultura DevOps impregna todos los perfiles, fases y procesos involucrados en la entrega de valor
a través del software, y especialmente el diseño, desarrollo, calidad, testing, integración continua,
aprovisionamiento, monitorización, etc. Estas responsabilidades históricamente han recaído en
equipos diferentes, que en este nuevo enfoque deben colaborar conjuntamente y
corresponsabilizándose de todo lo concerniente a la entrega de software.

153
DevOps, como cultura de trabajo, fomenta:
 La desaparición de silos y de grupos de trabajo estancos

 la comunicación, colaboración e integración en equipos de los diferentes perfiles que
participan en la entrega de software
 la asunción de responsabilidad de cada perfil en todas las facetas involucradas en la entrega
de software: calidad, test, seguridad, despliegue, entrega, monitorización, documentación
DevOps se apoya en un conjunto de prácticas inspiradas en:
 las metodologías ágiles, con el foco en obtener feedback temprano y continuo, para
adaptarse a los cambios
 la metodología Lean, con el objetivo de eliminar desperdicios en el proceso de entrega,
 en Extreme Programming y el movimiento software craftmanship, que ponen el foco en
prácticas de ingeniería del software para la entrega de valor con calidad y fiabilidad
DevOps se ayuda de una colección de tecnologías y herramientas que facilitan:
 la gestión y evolución de aplicaciones de forma ágil y fiable

 la automatización de tareas repetitivas que consumen mucho tiempo
 la dotación de infraestructura y el aprovisionamiento
 la mejora de la monitorización de las operaciones IT
Los principios que deben regir toda adopción DevOps se condensan en el acrónimo CALMS: Cultura,
Automatización, Lean, Medición o monitorización y Colaboración (Sharing), y en esa línea se
detallará el proceso de adopción
1.5.2.1 Proceso de adopción DevOps

154
La adopción de la filosofía DevOps para el SCUC se apoya en tres pilares fundamentales: las
personas, la tecnología y un marco de trabajo especialmente diseñado para este proyecto
 Personas – El factor determinante de toda adopción DevOps es el equipo y las personas

que lo conforman. Gracias a la experiencia, las habilidades y la cultura DevOps de Indra,
nuestros profesionales son especialistas en:
o Aplicar en todo momento un pensamiento alineado con los valores y principios del
agilismo, de forma que, a lo largo del proyecto, y apoyándose en el feedback
continuo, se inspeccionen y adapten las prácticas recogidas en esta oferta para
evolucionarlas
o Enfatizar la colaboración entre perfiles multifuncionales orientándose a la entrega de
valor
o Fomentar la autonomía y responsabilidad en los equipos, gracias a entornos en los
que se promueva y produzca el aprendizaje y la mejora continua
o Romper silos, compartiendo la responsabilidad de todos los procesos del ciclo de
entrega de software entre distintos perfiles
 Tecnología – Uno de los facilitadores de esta adopción es la tecnología y las herramientas
en las que se apoyan las prácticas que propondremos seguir. Dentro del equipo de Indra
contamos con profesionales cualificados con las habilidades necesarias para colaborar en
torno a la tecnología para hacer viable la adopción DevOps
 Marco de trabajo –Todo proceso de adopción necesita de un marco de trabajo para poder
ser llevado a cabo, e Indra, para el proyecto del SCUC, propone seguir el recogido en el libro
“The Phoenix Project” que sentó las bases de la filosofía DevOps, en el que se describen los
tres caminos (Three Ways) que permiten de forma efectiva enmarcar los procesos y prácticas
para la adopción DevOps:

155
o Flujo (First Way): Inspección y adaptación continua del flujo de trabajo empleado en
la entrega de software
o Feedback (Second Way): Adopción de prácticas que fomenten el feedback temprano
o Experimentación y aprendizaje (Third Way) – Mejora del flujo de entrega en base al
aprendizaje derivado del feedback temprano y a la experimentación
1.5.2.2 Ciclo de adopción DevOps con el marco de trabajo Three Ways de The Phoenix
Project
Este marco de trabajo se concreta en una iteración continua con tres etapas, tal y como se muestra
en la siguiente imagen:
En primer lugar, es necesario definir el flujo de entrega inicial, que habitualmente tiene las siguientes
etapas:

156
El mejor mecanismo para identificar este primer flujo es usar una de las herramientas nucleares al
flujo de entrega, como es Jenkins, y definir un pipeline inicial para un futurible microservicio, aunque
por ahora sólo sea el clásico hola mundo.
Esto introduce la necesidad de elegir en este momento algunas de las herramientas en las que se
apoyará el proceso de entrega. En la siguiente imagen se muestran un posible conjunto de
herramientas a utilizar en base a la experiencia de Indra y a lo recogido en los TDR.

157
La aportación de estas herramientas se irá concretando a lo largo de la oferta, siendo esta una
propuesta inicial que deberá ser concretada en el arranque del proyecto junto con el equipo de la
SUNAT.
A continuación, se comenzará la adopción de prácticas que fomenten el feedback temprano.

Muchas de estas prácticas están alineadas con la metodología ágil Extreme Programming, base junto
a Scrum en la propuesta metodológica SAFe de la presente oferta.
 Pruebas automatizadas
 Revisiones de código
 Integración y despliegues continuos
 Observabilidad o monitoreo de logs, eventos, procesos e infraestructura
 Uso de dashboards para la visualización de información
 Retrospectivas y post-mortems
 Gestión de información de decisiones, cambios, incidentes y problemas
 Rotación en la asunción de trabajos de despliegue y entrega
 Reuniones diarias (dailies standup)
Para facilitar la adopción de estas prácticas, se contará con las herramientas mencionadas antes más
otras adicionales que se irán concretando a lo largo de la oferta.
En la siguiente imagen se observa cómo estas prácticas aplican al flujo de entrega:

158
Como última etapa de esta iteración continua, y en base al feedback aportado por las prácticas
mencionadas en el paso anterior, y apoyado por la experimentación continua, se irán eliminando
posibles desperdicios, promoviendo la automatización de tareas e incorporando mejoras.
Terminado el primer ciclo, y una vez se hayan iniciado los desarrollos y la adopción de las prácticas
propuestas, para futuros análisis del flujo de entrega se propone usar Value Stream Mapping (VSM),
una técnica concebida dentro del movimiento lean manufacturing cuyo objetivo es analizar, diseñar y
administrar el flujo de materiales e información requeridos para entregar un producto a un cliente.
VSM utiliza un sistema de símbolos estándar para representar flujos de trabajo y flujos de información,
los cuales son marcados como agregadores o no de valor, desde el punto de vista del cliente, y su
objetivo final es eliminar aquellos elementos que no aporten valor.
Esta técnica es útil para mejorar procesos en los que haya pasos repetibles, y especialmente cuando
hay transferencias múltiples, habituales en manufactura. En el desarrollo de software, puede revelar
ineficiencias en el ciclo de vida de la entrega de software, como posibles pasos a eliminar, pasos a
automatizar, etc.
La entrega y el despliegue continuo no necesitan obligatoriamente de VSM y es perfectamente

posible diseñar e implementar pipelines eficientes sin necesidad de usar esta técnica, pero su uso
fomenta una cultura de mejora continua que ha demostrado ser efectiva en ingeniería y en
operaciones de software.
1.5.2.3 Prácticas asociadas a la adopción de la filosofía DevOps
1.5.2.3.1 Calidad y documentación Ágil

La adopción de este marco de trabajo debe llevar en paralelo la incorporación de dos aspectos vitales
en la filosofía DevOps:
 El aseguramiento de la calidad en todo el proceso

 La definición de mecanismos de documentación técnica ágil que de soporte al conocimiento
que debe intercambiarse en el equipo

159
Dicho esto, el modelo de adopción DevOps se detalla en la siguiente imagen:
A continuación, se detallan las prácticas mencionadas en el marco de adopción explicado, y se

proponen herramientas a utilizar para facilitar dicha adopción.
1.5.2.3.1.1 Aseguramiento de la Calidad

Según Kent Beck, creador de XP y TDD, para asegurar la calidad de un sistema se deben cumplir 4
puntos:
 Se deben pasar las pruebas

 El código debe revelar claramente la intención
 No debe haber duplicidades en el código
 El sistema debe tener el menor número de elementos posible
Por ello, el enfoque para garantizar la calidad de las entregas desde el inicio para el proyecto SCUC
se basará en la calidad del código, la calidad de los diseños técnicos y una buena estrategia de
testing.
Para buscar calidad en código, diseños y pruebas se propone la siguiente estrategia:
 Promover la homogeneidad en el código, consensuando unas convenciones de estilo, de

nomenclatura de paquetes y clases y de estructura de los repositorios, basadas en los
estándares y buenas prácticas que la SUNAT pudiera tener establecidos y en los de la
comunidad de desarrollo. Para lograr esta homogeneidad se acometerán las siguientes
tareas:
o Crear unas preferencias de codificación a aplicar automáticamente en los IDE

160
o Implantar herramientas de validación de convenciones como ArchUnit
o Realizar análisis de calidad estática de código, en momentos clave:
 Durante el desarrollo se creará tareas en gradle para que se conecte a

SonarQube y que permitirá a los desarrolladores, en tiempo real, identificar
y corregir las incidencias de calidad.
 Si no cumple los criterios de calidad de código, no será posible subir nuestras

fuentes al repositorio.
 Como se explicará en la integración continua, también se ejecutar en análisis

de código mediante la herramienta SonarQube para revisar las reglas que
verifican que se respetan los estándares de codificación y diseño
comentados.
o Adoptar la práctica de las revisiones de código
 Promover la calidad en los diseños, para lo cual se respetarán las recomendaciones de

ingeniería del software para generar diseños simples y se respetarán los principios SOLID.
Para garantizar el uso de esas buenas prácticas se acometerán las siguientes tareas
o Realizar análisis de calidad estática de código
o Adoptar la práctica de las revisiones de código, detallada en el epígrafe de prácticas.
 Consensuar todos los criterios a validar antes de la entrega de incrementos de software.

Estos criterios se denominan en inglés el Definition of Done (DoD) y se recogerán en un
documento, siempre vivo, a disposición de los equipos de desarrollo
 Automatizar en la medida de lo posible todas las tareas de análisis y revisión de buenas

prácticas
1.5.2.3.1.2 Documentación técnica ágil

Uno de los 4 valores del manifiesto ágil indica:
” Software funcionando sobre documentación extensiva
La propuesta de Indra para la documentación técnica del SCUC se basará en las siguientes premisas
alineadas con ese valor:
 El esfuerzo de documentar debe estar totalmente alineado con el ciclo de desarrollo software
(SDLC) y se genera durante el desarrollo
 Todo el equipo contribuye al esfuerzo documentador, en cada sprint, evitando silos y
compartiendo la responsabilidad sobre la misma

161
 La documentación técnica debe ser generada por ingenieros de software
 Limitar la documentación a aquello que no se pueda consultar en el código o en los tests
 Orientar la documentación a sus consumidores
 Promover las buenas prácticas de la comunidad en cada tipo de documentación
 Identificar una persona clave en cada equipo que promueve y gestiona el esfuerzo
documentador
Se propone seguir la filosofía Docs As Code, que promueve usar las mismas herramientas y
prácticas que se usan para codificar, usando texto plano, almacenando los documentos en sistemas
de control de versiones para conocer las fechas, cambios y autores de dichos cambios, haciendo
revisiones por pares y testeando que se está generando correctamente.
La documentación técnica será de alguno de los siguientes tipos en función de su propósito:
 Documentación de arquitectura y de marco de trabajo

 Documentación de servicios
 Registro de decisiones relevantes
 Registro de incidentes
1.5.2.3.1.2.1 Documentación de arquitectura y de marco de trabajo

El propósito de esta documentación será recoger las líneas arquitectónicas a seguir, documentar los
componentes comunes usados por todos los microservicios y el marco de trabajo, en el que
destacarán las buenas prácticas, las estrategias de testing, los procesos de integración y despliegue
continuos, etc.
Esta documentación es vital pues facilitará la rotación en la asunción de ciertas labores, como las de
despliegue y entrega, lo que permitirá obtener feedback de los procesos utilizados de forma que se
promueva la mejora continua.
La herramienta propuesta para registrar esta información es GitLab (docs as code) y para el
renderizado de la documentación se recomienda usar Jekyll (ver Mejoras).
1.5.2.3.1.2.2 Documentación de los servicios

Cada componente de la arquitectura estará documentado con herramientas lo más cercanas al
código posible, de forma que el desarrollador pueda describir lo que hacen de forma temprana,
mejorando la calidad de lo documentado y facilitando la trazabilidad y mantenibilidad de la
documentación.
En los servicios hay varias piezas fundamentales para generar documentación técnica:

162
 README: un fichero de texto que introduce y explica el servicio. Contendrá información
relevante para facilitar la comprensión de lo que hace dicho servicio. Se recomienda seguir
las indicaciones recogidas en makeareadme.com.
 Changelog: un fichero de texto cuyo propósito es mantener una buena trazabilidad del
trabajo que se desarrolla y que contiene una lista cronológicamente ordenada de los cambios
más destacables para cada versión de un proyecto, incluyendo información de la versión,
estructurada en nuevas funcionalidades, errores corregidos, modificaciones en la API. Se
recomienda seguir lo indicado en keepachangelog.com
 Código backend: Javadoc es una utilidad para la generación de documentación en formato
HTML a partir de código fuente Java. Es el estándar de la industria para documentar clases
de Java y se puede automatizar su generación en el proceso de integración continua
 Tracing: Spring Cloud Sleuth, por ejemplo, para tracing de peticiones
 Código frontend: Compodoc y JSDoc permitirá documentar nuestros componentes Angular
así como los métodos en typescript mediante anotaciones.
Adicionalmente a esta documentación se debe tener en cuenta que la mejor documentación para un
servicio son sus tests, por lo que siguiendo las buenas prácticas de desarrollo de pruebas se podrá
saber exactamente qué es lo que hace el servicio.
1.5.2.3.1.2.3 Registro de decisiones relevantes (RDR, basado en LADR)

Con el objetivo de mantener un enfoque ágil para la necesaria documentación de un sistema como
el PROYECTO-SUNAT-CUC, se recomienda el uso de una técnica llamada LADR, Lightweight
Architectural Decision Record, recomendada en recientes radares tecnológicos de ThoughtWorks, y
consistente en registrar las decisiones arquitectónicas que se toman en desarrollos ágiles, que para
esta oferta denominaremos RDR para ampliar el registro a todas las decisiones relevantes para el
sistema.
Para aplicar esta técnica, se propone usar el patrón Alexandrain en los documentos que recojan las
decisiones relevantes, el cual se plasma en el uso de estas secciones::
 Título y fecha
 Contexto en el que se toma la decisión
 Decisión tomada
 Estado actual
 Consecuencias, tanto positivas como negativas
Indra tiene experiencia usando esta práctica y en base a ella aporta las siguientes recomendaciones
para lograr que sea eficiente:
 Documentar en el momento más cercano a la toma de la decisión que lo origina

163
 Fechar los documentos
 Hacerlos inmutables, es decir, no se modifican y sólo cambia su estado, enlazando a nuevos
documentos que recojan la decisión que provocó que otros quedaran obsoletos o sin
aplicación
Las herramientas propuestas para registrar esta información son GitLab, en la que se apoyará la
práctica Docs as code, y Jekyll, que será la responsable de generar un sitio web totalmente funcional
a partir de los contenidos registrados en GitLab.
1.5.2.3.2 Registro de incidentes

Se propone mantener un registro, a modo post-morten, de las incidencias importantes ocurridas en
el sistema, con el objetivo de generar aprendizaje e introducir mejoras que eviten que se repitan en
el futuro.
Se propone generar reportes de incidencias con esta estructura:
 Resumen de la incidencia en la que se recoja una descripción breve de lo ocurrido

 Cronología, no solo inicio, fin y duración, sino de todos los momentos relevantes: cuándo
ocurrió, cuando se notificó al equipo, acciones y eventos, y cuando se restauró el servicio,
siempre indicando la zona horaria
 Causa raíz, con una explicación detallada de lo ocurrido, evitando suavizar las conclusiones
a las que se llegue
 Resolución y recuperación del sistema, indicando las acciones tomadas y el número de
veces que se han debido tomar
 Correcciones y acciones preventivas, listando lo que se debe hacer para evitar que ocurra
de nuevo y cómo actuar para hacerlo mejor la próxima vez
Para que el registro sea eficiente se recomienda documentarlo durante la gestión de la incidencia o
en el momento más cercano posible.
La herramienta propuesta para registrar esta información es GitLab (docs as code) y para el
renderizado de la documentación se recomienda usar Jekyll (ver Mejoras).

164
1.5.2.3.3 Revisiones de código
Las revisiones de código no sólo fomentan la calidad, sino que permiten detectar incidencias y
mejoras de forma temprana y, en general, favorecen la colaboración y la excelencia dentro del equipo,
ya que:
 Crean una cultura que valora la calidad

 Fomentan la propiedad compartida del código
 Promueve un ambiente positivo y sin críticas destructivas
 Define unos estándares de codificación consensuados
Las revisiones de código se apoyarán en la utilidad de merge request de GitLab y necesitan que
previamente se haya:
 Consensuado un Definition of Done inicial
 Consensuado qué se quiere revisar y creado una checklist con ello. Esa lista podrá variar con el
tiempo y no se recomienda ser exigentes de inicio. Se propone de entrada poner el foco en:
o convenciones de código,
o tamaño de los métodos y las clases,
o legibilidad del código
o principios de diseño SOLID
o cumplimiento de las buenas prácticas del testing
 Creado una plantilla de merge requests de GitLab con la checklist anterior

 Documentado las buenas prácticas para la adopción de revisiones de código, entra las que
destacamos en base a nuestra experiencia:
o Tracing: Spring Cloud Sleuth, por ejemplo, para tracing de peticiones
o
o No revisar más de 400 líneas de código o dedicar más de una hora revisando
código, pues decae la productividad
o
o Revisar el código por el autor antes de lanzar la merge request
o Documentar bien la merge request, buscando que su lectura secuencial sea fluida y
expresiva
o Cuidar los mensajes intercambiados durante la revisión y categorizar cada
comentario con una palabra que indique la importancia del mismo. Se propone usar:
Opcional, Importante y Bloqueante
o Preguntar en persona al autor todo lo que no se entienda

165
o Hacer un seguimiento inmediato de las revisiones en las que se ha participado, si es
en el mismo día, mejor, para ser ágil en la respuesta y para respetar el feedback
temprano, tan importante en la adopción de toda práctica DevOps
El flujo recomendado para hacer revisiones de código y los roles implicados serán el siguiente:
1. El autor de los cambios a entregar:

o valida que se cumple con el DoD
o hace autorevisión de su código, siguiendo lo indicado en la checklist de la plantilla de
revisiones de código
o crea una merge request en GitLab, bien documentada, sobre los cambios a merge
2. El revisor:
o valida la checklist acordada para el código en revisión, y:
 si la merge request cumple con los criterios validados, la acepta
 pero si encuentra aspectos a mejorar,
 inicia debates con el autor, asociados al código que considere que
debe mejorar
3. El autor revisa los debates e incorpora las sugerencias o responde a ellos
4. el revisor acepta los cambios y continúa el proceso hasta que considere que todo está
validado
5. Cuando se cumplan los criterios acordados y si no hay conflictos, se hará el merge de la
rama, bien en GitLab o con el cliente git que se desee
1.5.2.3.4 Automatización de pruebas

El objetivo de la presente estrategia es combinar una importante batería de pruebas automáticas con
un menor porcentaje de pruebas manuales que aporten confianza en que:
 el código entregado está libre de errores y

 los cambios introducidos no afectan a funcionalidades previamente desarrolladas (errores
de regresión).
Para ello, y como punto de partida, se propone una estrategia inicial de pruebas que se irá
concretando conforme avance el conocimiento de los equipos de desarrollo de las necesidades del
sistema, lo que permitirá concretar qué tipos de pruebas son más eficientes para generar esa
confianza.
La estrategia propuesta para el SCUC se basa en tres criterios:
 el coste de creación y de mantenimiento de las pruebas
 la velocidad de ejecución de las pruebas

166
 la confianza que la prueba otorga, directamente relacionada con la cantidad de código que la
prueba cubre
Para la presente estrategia distinguiremos los siguientes tipos de pruebas:
 Pruebas unitarias, que son aquellas que testean una pieza de código de forma individual y
aislada, sin acceso a base de datos o sistemas de archivos.
 Pruebas de integración (o de servicio o sistema), que necesitan acceder a servicios o

sistemas externos (archivos, base de datos, gestor documental, etc.) para poder ejecutarse
 Pruebas de aceptación, orientadas a validar los criterios de aceptación de las historias de

usuario
 Pruebas funcionales o end-to-end (E2E) son aquellas que se realizan de "extremo a

extremo" de la aplicación, englobando desde los canales de entrada hasta los repositorios de
datos.
La estrategia de pruebas suele representarse con un esquema estratificado en el que cada una de
las capas se corresponde con una tipología de tests, y cuya anchura y altura representan la
proporción recomendable de pruebas de ese tipo respecto al resto de tipos de pruebas.
En base al equilibrio entre el coste de hacer y mantener cada tipo de prueba y la confianza que otorga,
se obtendrá lo que se conoce como el retorno de la inversión (ROI) de la prueba, proponiendo un
mayor porcentaje de pruebas de aquellas que mayor retorno ofrezcan.
Dicho eso, la confianza que aportan las pruebas end-to-end es mayor que el de las pruebas de
aceptación, de integración o de las unitarias, por ese orden, pero en el coste de creación y de
mantenimiento, al igual que en la velocidad de ejecución, las unitarias salen mejor paradas, seguidas
de las de integración, aceptación y end-to-end, que son las más costosas de crear, mantener y
ejecutar. En base a nuestra experiencia, las pruebas de integración se erigen como las que mejor
retorno de inversión aportan, y por ello la estrategia recomendada ofrece un reparto porcentual mayor
de este tipo de pruebas, seguidas de las pruebas unitarias. Las de aceptación y las pruebas
funcionales son las que menor retorno de la inversión aportan.
Al representar esos porcentajes para cada tipo de prueba, se obtiene el denominado testing trophy,
por su aspecto de trofeo, en la que se otorga mayor peso a las pruebas de integración frente a las
unitarias, de las que también conviene tener una base muy sólida, o las de aceptación y las end-to-
end.

167
En la imagen, se representan con un color diferente las pruebas manuales y exploratorias, junto con
parte de las end-to-end (E2E), para diferenciar las automatizables de las que no lo son. Todas ellas
son necesarias y de suma importancia, ya que permiten lograr una elevada confianza en que no se
entregan errores en código nuevo o de regresión, aunque su coste sea el más elevado de todos.
La base del éxito de esta estrategia está en la calidad del código y de los diseños, y por ello se
representan un segmento en la base del trofeo, ya que, para poder disponer de una buena estrategia
de pruebas, la calidad del código en que estas pruebas se basan es esencial.
1.5.2.3.4.1 Buenas prácticas

En base a nuestra experiencia haciendo pruebas y siguiendo las recomendaciones de las
comunidades de desarrollo y QA, proponemos seguir estas indicaciones:
 Los tests deben probar el comportamiento, no la implementación, y las pruebas sobre el

estado de tus objetos siempre son preferibles a las pruebas sobre la interacción entre ellos
 Hacer los tests antes que el código hará que este último esté mejor diseñado, pero en
ocasiones, cuando se tiene una idea clara de cómo será el diseño tu código, puede estar
justificado codificar primero. Hay que tener en cuenta que hacer las pruebas después del
código, suele generar pruebas más débiles
 Hacer que los test fallen al menos una vez. Si se crean tests después de tener implementado
el código, se corre el riesgo de que siempre “estén verdes”, lo cual es una mala práctica ("A
test that never fails is worse than having no test at all")

168
 Generar tests claros, completos y concisos; fieles (cubrir todos los caminos y condiciones);
resilentes ante las refactorizaciones y precisos (que informen cuando fallen (importante el
nombre del test)
 Crear tests que respeten el acrónimo FIRST (Fast, Isolated, Repeteable, Self validating,
Timely)
 Cada test debe expresar claramente en su nombre si probará temas de infraestructura, de
funcionalidad o de estructura de los objetos y recoger lo que prueban (Subject Under Test,
SUT) y se propone seguir alguno de estos patrones de nombrado:
o Should-Return
o Given-When-Then
 El código del test debe seguir el patrón AAA: Arrange (preparar), Act (actuar) y Assert (validar)
1.5.2.3.4.2 Herramientas
Para cada tipo de pruebas se utilizarán las herramientas que mejor se adapten a la casuística del
test y que mejor se integren en el ciclo de integración continua. Se realizará la ejecución por
separado de ciertos tipos de pruebas para adecuarla al pipeline. El conjunto de herramientas
propuestas deberá ser consensuado con la SUNAT aunque se propone partir de las siguientes:
· Pruebas unitarias y de integración
o JUnit para la ejecución de pruebas unitarias y de integración y como marco de

ejecución de otras herramientas de pruebas
o Mockito para crear objetos similares a los que habrá en producción, pero ocultando la
complejidad que algunos de ellos conllevan y que dificultará la ejecución de la prueba.
o Hamcrest, para facilitar la codificación de las aserciones
o Flapdoodle como base de datos en memoria para pruebas de integración mockeadas
· Pruebas de rendimiento
o JMeter, herramienta específica para realizar peticiones y medir el rendimiento
· Pruebas funcionales
o Cucumber, framework de testing orientado a realizar pruebas de comportamiento del

sistema
o Gherkin, un lenguaje soportado por Cucumber que permite expresar las pruebas en
lenguaje natural y cercano al negocio

169
o Selenium, framework de pruebas funcionales
o Selenium Jupiter, extensión de JUnit que facilita la ejecución de pruebas Selenium

con utilidades para usar navegadores y contenedores locales o remotos
1.5.2.3.5 Integración, entrega y despliegue continuo

El ciclo de integración continua será el que se indica en el siguiente esquema:
Explicación:
1. El desarrollador sube código (hace push a developer tras un merge) se inicia el proceso de
integración.
2. Mediante webhooks de GitLab se detecta el evento anterior y ejecuta un pipeline de Jenkins
que orquestará los trabajos de integración e inicia el proceso de inicio de build.
3. Se obtiene el código del repositorio.
4. A continuación, y en base a los descriptores del servicio, se obtienen las dependencias
necesarias para construir el servicio, accediendo al repositorio de artefactos, y se inicia la
compilación del código y el build.
5. Si todo ha ido bien, se lanzan los tests unitarios y de integración.
6. Ejecuta el análisis de código estático con SonarQube.
El ciclo de entrega y despliegue continuo será lo que se indica en el siguiente esquema:

170
Explicación:
1. El usuario sube código (hace push a master tras un merge) se inicia el proceso de entrega y
despliegue continuo.
2. Mediante webhooks de GitLab se detecta el evento anterior y ejecuta un pipeline de Jenkins
que orquestará los trabajos de despliegue.
3. En primer lugar, se hace checkout del código.
4. A continuación, y en base a los descriptores del servicio, se obtienen las dependencias
necesarias para construir el servicio, accediendo al repositorio de artefactos, y se inicia la
compilación del código y el build.
5. Si todo ha ido bien, se lanzan los tests unitarios y de integración.
6. Se ejecuta el análisis de código (opcionalmente).
7. Si se pasan las pruebas, la nueva versión del artefacto se sube al repositorio.
8. A continuación, y con la nueva versión del artefacto se actualiza la imagen de Docker que
permite desplegar el servicio y se sube al repositorio de imágenes.
9. Despliega la imagen en el contenedor.
10. En caso que sea ambiente de pruebas, se procederá a realizar la validación de calidad.
A continuación, podemos ver un esquema de cómo sería un pipeline de Jenkins con las herramientas
involucradas en cada paso del mismo.

171
Relacionado con el flujo CI/CD, conviene repasar las siguientes recomendaciones en base a nuestra
experiencia en proyectos similares al SCUC:
 Estrategia de ramas git

 Construcción de los artefactos de los microservicios
1.5.2.3.6 Estrategia de ramas

Se propone seguir una estrategia de ramas basada en el modelo git-flow, que facilita la creación y
reintegro de desarrollos de funcionalidades, la liberación de hot fixes en respuesta a incidencias y la
entrega de releases.
Las principales ramas utilizadas en GitLab son las siguientes:
 master: Contiene código listo para pasar a producción. A esta rama se subirá el código
habitualmente desde la rama develop, y eventualmente desde hotfixes, cuando haya que
generar un parche
 develop: Contiene el código de desarrollo con los últimos commits efectuados por el equipo
y será la base para la integración y las pruebas. Cada vez que una funcionalidad esté lista
para ser entregada, se llevará a la rama master
 features: en esta rama cada desarrollador será libre de crear ramas propias para sus
desarrollos, siempre que el código termine reintegrándose en la rama develop
 hotfixes: se creará una rama de este tipo cuando haya que realizar una corrección sobre una
versión en producción, de manera que la rama nacerá de la versión etiquetada en la que se
ha detectado la incidencia.
En el siguiente esquema se puede ver un ejemplo de uso de las ramas antes comentadas en el
modelo git-flow, reflejando las tres situaciones habituales del código:
 desarrollo de reléase: secuencia de trabajo marcada con ,

 corrección de incidencias: secuencia marcada con  y
 trabajo diario en ramas de desarrollo: secuencia marcada con 
172
1.5.2.3.7 Construcción de servicios
Una de las claves para garantizar una construcción de servicios homogénea a lo largo del desarrollo
y de la vida útil del sistema es mantener una estructura similar en todos ellos, y para ello se seguirán
las recomendaciones de la SUNAT o las buenas prácticas de la comunidad de desarrollo.
La herramienta a utilizar para la construcción de proyectos será Gradle que permite establecer unas
fases uniformes a seguir en dicha construcción y facilita la gestión de dependencias.
Otro aspecto importante en este punto será la nomenclatura de artefactos y política de versionado de
los artefactos generados, que respetarán las normas indicadas en los TDR, basados en el versionado
semántico.
1.5.2.3.8 Observabilidad
La complejidad actual de los sistemas distribuidos hace que el número de problemas relacionados
con el mismo sean mayores en número y en dificultad que cuando se trabajaba con monolitos.
Para dar respuesta a esta necesidad nace la observabilidad, que es el conjunto de actividades
destinadas a medir, recopilar y analizar las señales de un sistema, entre las que se incluyen métricas,
tracing, logs, eventos, etc., y tiene como objetivo mejorar el conocimiento de los sistemas y anticipar
situaciones no deseadas.

173
La principal diferencia con el monitoreo clásico es que éste se hacía observando el sistema desde
fuera, como si fuera una caja negra (black box monitoring) y ahora se propone recopilar información
desde dentro (white box monitoring).
Un sistema observable es aquel que expone suficiente información a la par que permite un fácil
acceso a esos datos y a encontrar respuestas basadas en ellos.
Trabajar para predecir fallos es muy costoso, tanto como tratar de hacer software sin fallos, y la clave
está en encontrar el equilibrio entre el coste asociado a las incidencias y el coste de reaccionar ante
ellos, por lo que la observabilidad suele combinarse con mecanismos que permiten al software ser
resilente a los fallos: reintentos, timeouts, circuit breaking, etc.
Los pilares de los equipos que practican observabilidad son cinco y se apoyarán en las siguientes
herramientas:
 Monitorización: Prometheus
 Tracing: Spring Cloud Sleuth, por ejemplo, para tracing de peticiones
 Agregación y análisis de logs: Beats, Logtash y ElasticSearch
 Visualización: Grafana y Kibana
 Alertas: Prometheus, Kibana y las herramientas habituales de comunicación: correo
electrónico, Slack, etc.
Un ejemplo de cómo se haría tracing y agregación de logs con el stack tecnológico propuesto para
implementar observabilidad en el PROYECTO-SUNAT-CUC:

174
1.5.2.3.9 Infraestructura como código.
La infraestructura como son los servidores y redes, se debe gestionar como cualquier otro artefacto
de software, dando como resultado lo que se conoce como "Infraestructura como código".
Para la instalación y configuración de la infraestructura se usará Ansible, que tiene las siguientes
características:
 No requiere niveles habilidades de programación.
 Las instrucciones escritas para Ansible son legibles por humanos.
 Trabaja con un nodo de control y nodos gestionados.
 Se ejecuta sobre SSH, pero existen otras formas de comunicación.
Para nuestro caso, al usar Ansible tendremos las siguientes ventajas:
 Trabajos repetitivos para configuraciones en los diferentes ambientes.
 Al tener los scripts Ansible, podemos determinar que la instalación y configuración está
autodocumentada.
 La capacidad de idempotencia.
 Podemos hacer seguimiento de versiones en las configuraciones ya que se podrá hacer uso
de repositorios para la gestión de los scripts Ansible.
En nuestra infraestructura, se configurará lo siguiente:
 Configuración de las subredes.
 Configuración de los Servidores como son firewall, iptables y cualquier trabajo antes de
instala los productos.
 Instalación y configuración de los productos como son base de datos, contenedores, data
streaming, herramientas de monitoreo.
1.5.2.3.10 Rotación de asunción tareas de despliegue y entrega

Una de las prácticas que se propone adoptar para promover la filosofía DevOps es la de rotar en la
asunción de tareas de despliegue y entrega, la mayoría de las cuales suelen estar automatizadas.
Alternar estas responsabilidades entre diferentes miembros del equipo tiene dos objetivos:
 reducir el temido bus factor, por el cual dependemos de ciertas personas para hacer ciertas
tareas

175
 revisar y mejorar documentación de apoyo para este tipo de tareas, facilitando con ello futuras
rotaciones
 participar en la inspección y adaptación de los procesos de despliegue y entrega
1.5.2.4 Retrospectivas, post-morten y dailies standup
La mayoría de las prácticas propuestas en la adopción DevOps de la presente oferta se apoyan en

la experiencia de Indra en desarrollos ágiles y, al igual que muchas prácticas ágiles, no son
prescriptivas, ni existen recetas que garanticen el éxito, si no que se basan en un conjunto de
recomendaciones en base a en desarrollos pasados y en la búsqueda continua de mejora de las
mismas.
Las mejoras a adoptar dependen de cada equipo de desarrollo, de cada proyecto, y el contexto en
el que desarrollan su trabajo varía con el tiempo, y por ello es necesaria una labor continua de
inspección y adaptación de las prácticas a ese contexto específico y cambiante.
Ese trabajo de recopilación de información, métricas, lecciones aprendidas, etc., se plasma en la

celebración de retrospectivas y las reuniones diarias (dailies standup) propuestas en el epígrafe
sobre metodología SAFe, y los análisis post-morten para incidencias y problemas descritos en el
epígrafe de documentación técnica, siendo todos ellos de vital importancia para el modelo de
adopción DevOps propuesto para el PROYECTO-SUNAT-CUC.
1.5.3 Carga Inicial de Datos
La correcta definición de los procesos de carga inicial de datos es clave para garantizar el éxito de
cualquier puesta en marcha y, aún más, en un proyecto con un esquema de interoperabilidad tan
complejo como es el de la CUC.
Tal y como ya se ha mencionado, la misión principal de la CUC será:
 Asegurar la correcta imputación contable y desglose de las partidas aplicadas.
 Asegurar la trazabilidad de todos los movimientos.
 Mantener un histórico de todos los movimientos.
En este sentido, es indispensable que toda la información que concurra hacia ella esté
homogeneizada, independientemente del origen de la misma. Será precisamente esta
homogenización o normalización la que le otorgará a la CUC su complementariedad respecto a los
sistemas “legados” y todos aquellos nuevos desarrollos que, en un próximo futuro, pueda abordar la
SUNAT.

176
Así pues, el aspecto clave a abordar en el proceso de carga incial de datos es conseguir una correcta
homogenización de la información que fluya hacia la CUC y que, posteriormente, dicha información
pueda ser extraída y utilizada con normalidad por todas y cada una de las funcionalidades/épicas de
los diferentes MVP.
1.5.3.1 Definición general
1.5.3.1.1 Interoperabilidad y migración
Esquemáticamente, podríamos definir la CUC como un módulo de confluencia y de extracción

información para múltiples procesos; procesos que pueden tener su origen en diferentes sistemas
desarrollados, a su vez, en diversas plataformas tecnológicas.
La solución para definir el esquema de interoperabilidad entre las diferentes transacciones y sistemas
consiste en lograr el diseño de un esquema único de intercambio de información, que pueda ser
generado y utilizado por cualquiera de los sistemas que operen alrededor de la CUC.
Siguiendo este enfoque, la carga inicial de datos debe ser entendida como una interacción más
entre cualquiera de los sistemas y la CUC; no como un evento aislado y al margen. De otro modo,
se corre el riesgo de que la solución propuesta para la migración no esté alineada con el resto de
interacciones y resulte incompatible con el esquema de interoperabilidad y con los desarrollos
efectuados para cada una de las diferentes funcionalidades/épicas de los MVP1 y MVP2.
1.5.3.1.2 La carga inicial de datos como transacción inicial de la CUC
La visión del CONSORCIO es que, simplificando conceptos, la carga incial de datos no es sino la
transacción inicial que permitirá todo el posterior funcionamiento del módulo CUC. Una
transacción que se ejecutará desde todos aquellos sistemas que originen movimientos que deban ser
reflejados en la Cuenta Única.
La consolidación dentro de la base de datos de la CUC de todos los documentos enviados dará lugar
a la creación del saldo inicial de la posición abierta a fecha del arranque de cada uno de los
contribuyentes.
Siguiendo esta visión, y apoyándonos en nuestra experiencia, el proceso de carga inicial de datos
considerará, únicamente, aquellos documentos que conformen el saldo vivo de la cuenta del
contribuyente relativo a las funcionalidades/épicas a poner en marcha en cada uno de los MVP1 y
MVP2, quedando los documentos históricos almacenados en las respectivas bases de datos de los
sistemas legados.

177
1.5.3.1.3 Carga Inicial de Datos, MVP1 y MVP2
Aunque la planificación del desarrollo y la puesta en marcha de las funcionalidades del proyecto se
agrupan en dos MVP bien diferenciados y ubicados en diferentes momentos en el tiempo, la
metodología a aplicar para el diseño y ejecución de la carga incial de datos debe ser, lógicamente, la
misma para ambos MVP.
Como ya hemos dicho, las labores de definición del esquema de interoperabilidad deben lograr el
diseño de un esquema/estructura de intercambio de información normalizada que sea común a todo
el parque aplicativo de la SUNAT.
Dada la dispersión de aplicaciones y la complejidad inherente a las operaciones y funcionalidades a

poner en marcha, las tareas de carga inicial de datos –en lo que a mapeo de datos y definición de
reglas y validaciones se refiere- no pueden plantearse de forma aislada, sino que se han de
sincronizar junto con las tareas de análisis y desarrollo de cada una de las funcionalidades/épicas
pertenecientes a los MVP1 y MVP2.
Plantear la carga inicial de datos de forma aislada a los análisis y desarrollos propios de cada MVP
supondría incurrir en un grave riesgo de cara a la planificación y el éxito del proyecto, implicando
entre otros los siguientes elementos:
 Errores de mapeo, omisión de reglas de validación u olvido de datos imprescindibles, tanto

para el funcionamiento de la CUC, como para asegurar la correcta la interoperabilidad entre
los sistemas.
 Retrabajo, debido al hecho de tener que reconfigurar los programas de extracción de datos
de los sistemas Legados ya creados y todo tipo de parametrizaciones diseñadas para
soportar el proceso.
En definitiva, hechos que provocarían una ejecución no válida de la carga incial de datos y que,
por tanto, la invalidarían, generando importantes retrasos en el calendario de puesta en marcha de
los respectivos MVP.
1.5.3.2 Metodología Propuesta
El hecho de que el módulo de CUC pueda ser llamado desde multitud de sistemas legados exigirá un
estudio muy cuidadoso y detallado de la estructura y contenido de las diferentes bases de datos de
los sistemas a integrar.
Se deberá asegurar que la carga inicial de datos recoge todos los datos necesarios para soportar, no
únicamente los procesos a realizar en un primer momento sobre el módulo CUC, sino para soportar

178
también los procesos de negocio que se mantengan –ya sea temporal, o definitivamente- en los
diferentes sistemas legados.
Por todos los motivos expuestos anteriormente, desdel CONSORCIO, proponemos una metodología
de carga inicial de datos basada en los siguientes puntos:
 Incluir el estudio de las necesidades de carga inicial de datos como parte de las tareas propias
de cada uno de los equipos de análisis y desarrollo de las funcionalidades/épicas de los
diferentes MVP.
 Designación de un “Responsable de carga inicial de datos” que se encargará de definir, desde

un primer momento, las necesidades del proceso de carga inicial de datos y coordinará los
avances de todas las tareas relativas a la migración que se ejecuten a nivel de los equipos
de análisis y desarrollo de cada una de las funcionalidades/épicas de cada MVP.
 Validación expresa de las diferentes estructuras de datos obtenidas tras el análisis, por parte
de los responsables SUNAT a cargo de:
o el desarrollo de las funcionalidades/épicas CUC.

o cada uno de los sistemas legados de origen involucrados.
 Ejecución de la carga inicial de datos en el sistema CUC a través de los programas

transaccionales de cada una de las funcionalidades/épicas de los MVP1 y MVP2 que
permitan conformar el saldo de la cuenta de cada uno de los contribuyentes.
La tendencia del mercado a la hora de plantear una metodología para un proceso de carga inicial de
datos es incluir, cada vez más, la utilización herramientas de limpieza y reparación de datos
(Datacleansing) que permitan mejorar la calidad de los datos a incorporar a los nuevos sistemas.
Aunque no forma parte del alcance del presente proyecto, CONSORCIO propondrá como mejora
dentro de su propuesta– detallando las condiciones en el correspondiente apartado (TECH3)- la
utilización de su propia herramienta de Data Cleasing.
1.5.4 Capacitación
En esta sección se presenta la metodología para identificar las necesidades de capacitación,

fortalecimiento, entrenamiento y desarrollo que tenemos que tener en cuenta para realizar una
capacitación efectiva y de calidad.
1.5.4.1 Modelo de Capacitación y Transferencia de Conocimiento

179
En esta sección se describe el modelo de capacitación y transferencia del conocimiento sobre el cual
se elaborará el Plan de Capacitación.
Ilustración 65: Modelo de Capacitación1 y Transferencia del Conocimiento2
1.5.4.1.1 Modelo de Transferencia del Conocimiento

A continuación, se describen las actividades en el Modelo de Transferencia de Conocimiento, que
son necesarias para comunicar, compartir, distribuir y monitorear el conocimiento creado y/o
adquirido. El cual es necesario transferir a los colaboradores de la organización para la asimilación
del conocimiento. En ese sentido es fundamental definir las técnicas de transferencia que se empleará
para alcanzar los objetivos de la transferencia del conocimiento.
1
Norma Internacional ISO-10015:2003. Gestión de la Calidad. Directrices para la Formación
2
Fase V de la Metodología de la Valoración del Conocimiento

180
Capacitación
Formación
Comunidades de
formadores
Transferencia
del
Conocimiento
Grupos de Mentoring
Trabajo
Coaching
Ilustración 66: Técnicas de Transferencia del Conocimiento
 Capacitación: Esta técnica establece la formación y desarrollo de capacidades mediante el

dictado de cursos o talleres en modalidad presencial o virtual.
 Formación de formadores: Esta técnica permite incrementar el número de personas cuyo
conocimiento de los procesos del servicio les permite dar soporte al resto de los
colaboradores de la organización.
 Mentoring: Es una práctica que consiste en asignar mentor o mentores a colaboradores que
tienen más experiencia en la organización.
 Coaching: Es un proceso interactivo que busca incrementar la productividad mediante el cual
jefe y supervisores buscan resolver solucionar problemas de desempeño o desarrollar
capacidades de los colaboradores.
 Grupos de Trabajo: Esta técnica permite a los usuarios hacer uso de un grupo de
herramientas cuando se precise el trabajo en equipo.
 Comunidades: Esta técnica permite a los usuarios disponer de las herramientas necesarias
para que puedan aprender, participar y compartir información de forma masiva y abierta.
A continuación, se representa gráficamente los procesos que componen la Transferencia del

Conocimiento.

181
Ilustración 67: Transferencia del Conocimiento
a) Difundir el Conocimiento
Propósito: Actividades:
Recepcionar el Informe de Resultados, el Especialista de la

GC debe canalizar el Informe de Resultados del proceso.
Valorar el Conocimiento
Evaluar el contenido del Informe de Resultados, el

Especialista de la GC, evalúa el Informe de Resultados y
determina la técnica de difusión del conocimiento más
apropiada. Esta actividad se efectúa siempre y cuando la
Difundir el
técnica de transferencia del conocimiento seleccionada
conocimiento que
implique difusión masiva a los colaboradores de la
ha sido creado o
organización
adquirido haciendo
uso de los canales
Elaborar el Plan de Difusión del Conocimiento, el Supervisor
de comunicación de
de la GC y el Especialista de la GC centralizan todas las
la organización
necesidades de difusión del conocimiento para establecer el
Plan de Difusión del Conocimiento
Aprobar el Plan de Difusión del Conocimiento. El Plan de

Difusión del conocimiento debe ser aprobado por el
Supervisor de la GC. El Especialista GC evalúa y determina
el medio, mediante el cual se procederá a difundir el
conocimiento

182
Realizar las actividades de difusión del conocimiento a través

de los canales de comunicación (Portal, boletín informativo,
correo electrónico, comunicación interpersonal, etc.) de la
organización, el Operador de la GC ejecuta las actividades
correspondientes para difundir el conocimiento según el Plan
de Difusión del Conocimiento
Tabla 26: Difusión del Conocimiento
Entradas Técnicas y Herramientas Salidas

1. Juicio de Expertos.
1.Informe de 1. Plan de
2. Canales de Difusión del
Resultados comunicación Conocimiento
3. Técnicas de
transferencia del
conocimiento
Ilustración 68: Proceso Difundir el Conocimiento
b) Compartir el Conocimiento
Determinar el público objetivo al cual se compartirá el

conocimiento, el Supervisor de la GC y el Especialista de la
GC deben revisar el Informe de Resultados para determinar
Compartir el
el público objetivo al cual se compartirá el conocimiento, los
conocimiento
contenidos del conocimiento que se deberá compartir hacia
creado o adquirido a
los colaboradores de la organización.
los colaboradores
de la organización,
Seleccionar la técnica de transferencia del conocimiento, el
mediante el uso de Especialista de la GC, deberá evaluar y seleccionar la
técnicas apropiadas
técnica de transferencia con el cual se compartirá el
de transferencia del
conocimiento.
conocimiento
Realizar actividades de aseguramiento de la transferencia
del conocimiento. El Operador de la GC debe realizar
actividades preliminares para aseguramiento de la

183
transferencia del conocimiento según la técnica

seleccionada.
Compartir el conocimiento, el Especialista de la GC y el

Operador de la GC debe realizar las acciones
correspondientes para compartir el conocimiento según la
técnica de transferencia seleccionada. De ser necesario El
Especialista de la GC debe apoyarse en la tecnología de la
organización para las técnicas de transferencia del
conocimiento.
Medir el conocimiento compartido, el Especialista de la GC

deber medir el conocimiento compartido haciendo uso de
los criterios de valoración del conocimiento
Elaborar el Informe de Ejecución del conocimiento

compartido, el Especialista de la GC debe elaborar un
Informe de Ejecución que debe contener la medición del
conocimiento compartido a los colaboradores de la
organización.
Tabla 27: Compartir el Conocimiento
Entradas Técnicas y Herramientas Salidas
1. Plan de 1. Plan de
1. Juicio de Expertos.
Difusión del Transferencia
Conocimiento 2. Herramientas del Conocimiento
Colaborativas
2. Informe de 2. Informe de
Resultados 3. Técnicas de Ejecución
transferencia del
conocimiento
Ilustración 69: Proceso Compartir el Conocimiento
1.5.4.1.2 Modelo de Capacitación

A continuación, se describe las fases identificadas en modelo de capacitación:
 Identificar las necesidades de la Capacitación

 Planeación de la Capacitación

184
 Ejecución de la Capacitación
 Evaluación de la Capacitación
Identificar las
necesidades de
la Capacitación
Evaluación de la Planeación de la
Capacitación Capacitación
Ejecución de la
Capacitación
Ilustración 70: Modelo de la Capacitación, ISO 10015:20033
FASE DESCRIPCIÓN ACTIVIDADES

- Identificar el alcance de los
Esta fase permite la objetivos de la capacitación.
Fase 1: detección de las - Determinación de los requisitos
Identificar las necesidades de básicos de personal.
necesidades de capacitación - Análisis de problemas de
Capacitación (diagnóstico) personal.
- Análisis de informes y otros
datos
- Definir el objetivo de la
En esta fase se
capacitación
elabora el Plan de
- Definir los cursos y/o talleres a
Fase 2: capacitación para
desarrollar.
Planeación de la atender las
- Determinar el contenido de la
Capacitación necesidades
capacitación.
diagnosticadas en la
- Selección de modalidad de
fase anterior.
capacitación.
3 Norma Internacional ISO-10015:2003. Gestión de la Calidad. Directrices para la Formación.

185
FASE DESCRIPCIÓN ACTIVIDADES
- Definición de los recursos
necesarios para implementar la
capacitación (instructor, equipos o
herramientas, materiales, etc.).
- Definición de las personas a
capacitar.
- Lugar y horario de la
capacitación.
- Definir el control y evaluación de
los resultados.
Esta fase permite la
Fase 3: - Realizar la capacitación a cargo
Implementación y
Ejecución de la de la Oficina de Transferencia de
realización del plan de
Capacitación Tecnología y Conocimiento.
capacitación
- Evaluar los resultados de la
Esta fase permite la capacitación
Fase 4:
Evaluación y control - Seguimiento
Evaluación de la
de los resultados - Comprobación o medición
Capacitación
obtenidos. - Comparación de la situación
actual con la anterior.
Tabla 28: Fases del Modelo de Capacitación
1.5.4.1.3 Esquema de Competencias y Conocimientos
Las competencias constituyen un conjunto de conocimientos, prácticas, comportamientos y tipos de

razonamientos adquiridos en función de lo aprendido y de lo vivido; esto es, el conjunto de
conocimientos, habilidades, actitudes e intereses que distinguen a las personas y a las
organizaciones. De manera que las competencias son observables en situaciones cotidianas de
trabajo y en situaciones de prueba.

186
Ilustración 71: Modelo de Echevarría, 2001; 2002
La Competencia Profesional, según Echeverría, es la puesta en práctica del conjunto de

conocimientos, procedimientos, actitudes y capacidades que una persona posee y que son
necesarios para hacer frente de forma efectiva, con el nivel y la calidad de realización requeridos, a
las funciones que demanda una profesión en un determinado puesto de trabajo y resolver los
problemas que emergen de forma autónoma y creativa y colaborar en la organización del trabajo y
en su entorno socio-laboral.
En este sentido, aplicando el modelo de Echevarría, la capacitación es una técnica de Transferencia

de Conocimiento por medio del cual, de manera sistemática y organizada, las personas desarrollan
habilidades y competencias técnicas-metodológicas en función de objetivos definidos.
La capacitación entraña la transmisión de conocimientos especializados relativos al trabajo

(competencia técnica), que busca que los participantes puedan aplicar estos conocimientos a
situaciones laborales concretas (competencia metodológica), mediante el dictado de cursos o talleres
en modalidad presencial y virtual.
Estas capacitaciones de las soluciones técnicas y herramientas ofertadas que permitirán el desarrollo
de las capacidades y competencias técnicas de los colaboradores de LA SUNAT, generando
oportunidades de formación que promuevan condiciones favorecedoras del cambio institucional.
1.5.4.1.4 Roles y Funciones de una Oficina de TTC

La Oficina de Transferencia de Tecnología y Conocimiento (OTTC) tendría la siguiente forma:

187
Ilustración 72: Organigrama de la Oficina de TTC
A continuación, se describen los roles y funciones del equipo de la Oficina de TTC:
Rol Funciones relacionadas
Responsable de asegurar la transferencia de

conocimiento de las herramientas y soluciones técnicas
desarrolladas en el marco de ejecución del proyecto las
cuales se encuentran enmarcadas en bases y oferta
Responsable de la técnica del contrato.
Oficina de
Responsable de la Identificación de necesidades,
Transferencia de
Planeación, Ejecución, y Evaluación de los cursos
Tecnología y correspondientes al Plan de Capacitación que permita los
Conocimiento colaboradores de LA SUNAT, la capacitación en las
herramientas y soluciones técnicas que se generen en el
marco de ejecución del proyecto.
Responsable de la elaboración y/o entrega de la
Metodología para la Valoración de Conocimiento.
Realizar actividades relacionadas a la transferencia de
Analista de conocimiento del proyecto.
Transferencia de Realizar las actividades relacionadas a la identificación de
Tecnología y necesidades, planificación, ejecución y evaluación de los
Conocimiento cursos correspondientes al Plan de Capacitación.

Realizar actividades relacionadas a la elaboración de una
Metodología para la Valoración de Conocimiento.
1.5.4.2 Procesos y Organización de la Capacitación

188
A continuación, se describe los procesos y la organización para la ejecución de las capacitaciones,
que nos permitirán asegurar la correcta realización de las actividades del Plan de Capacitación.
1.5.4.2.1 Procesos de Capacitación

 Requerir a LA SUNAT, el listado de participantes de acuerdo al perfil de requisitos del
participante definido.
 Proveer los recursos y materiales a los participantes del curso del Plan de Capacitación.
 Asegurar que la sala de capacitación se encuentre disponible, operativo y esté conforme a
los requisitos técnicos del curso programado.
 Realizar el dictado de los cursos del Plan de Capacitación.
 Realizar la evaluación de resultados de las evaluaciones teórica y práctica y elaborar el
informe de capacitación del curso.
 Realizar seguimiento y control al Plan de Capacitación.
Ilustración 73: Procesos para la Capacitación
1.5.4.2.2 Organización del Equipo de Capacitación

A continuación, se describe el organigrama del Equipo de Capacitación, quienes en conjunto serán
responsables de la elaboración, ejecución, evaluación, seguimiento y cierre de las actividades
correspondientes al Plan de Capacitación.

189
Ilustración 74: Organigrama del Equipo Responsable del Plan de Capacitación
A continuación, se describe los roles del personal del equipo de Capacitación:
Responsable de la Identificación de necesidades,

Planeación, Ejecución, y Evaluación de los cursos
Responsable de la Oficina
correspondientes al Plan de Capacitación que permita los
de TTC colaboradores de LA SUNAT, la capacitación en las
herramientas y soluciones técnicas que se generen en el
marco de ejecución del proyecto.
Realizar las actividades relacionadas a la identificación de

Analista de TTC necesidades, planificación, ejecución y evaluación de los
cursos del Plan de Capacitación.
Equipo de facilitadores internos y externos responsables del

Instructores
dictado de los cursos del Plan de Capacitación.

190
2 Plan de Trabajo
2.1 Introducción
Tal y como se solicita en el documento de licitación, el proyecto “PROYECTOS PARA LA

CONSOLIDACIÓN DE LA GESTIÓN TRIBUTARIA Y ADUANERA” se divide en seis
renglones, siendo estas las siguientes:
1. Gestión
2. Carga inicial de datos
3. Fase de Desarrollo, Pruebas y Puesta en producción del Sistema de Cuenta Única de
Contribuyente
4. Migración de los ambientes de desarrollo y pruebas
5. Fase de Capacitación y Transferencia de Conocimientos
6. Fase de Mantenimiento Correctivo y Soporte
El presente Plan General del Proyecto describe las características más relevantes de cada
una de las líneas anteriormente citadas.
El Plan General del Proyecto incluye todos los subproyectos; así como también, describe
todos los supuestos y restricciones consideradas para su elaboración. También se incluyen
las fases planteadas en la estrategia de implementación y los planes específicos solicitados
para el servicio de implementación e implantación.
Además, este Plan General del Proyecto, preparará, integrará y coordinará todos los planes
subsidiarios.
2.1.1 Objetivo
El presente documento recoge todos los aspectos relativos al alcance del proyecto, modelo
de trabajo a aplicar (tareas, hitos, etc.), modelo organizativo del mismo y metodología de
gestión, con el fin de que sirva de marco de referencia a todas las personas involucradas en
el proyecto.
2.1.2 Definiciones y siglas
Alcance del proyecto – Se denomina así al conjunto de trabajos y actividades que deben
completarse para entregar el producto, servicio o resultado del proyecto con las
características y funciones requeridas. El alcance del proyecto es la frontera del proyecto:
define y controla qué debe y qué no debe hacerse.

191
EDT, Estructura de Desglose de Trabajo – La EDT organiza y define el alcance total del
proyecto (el trabajo que está fuera de la EDT está fuera del alcance del proyecto). Puede
definirse como una descomposición jerárquica, orientada a entregables o a actividades, del
trabajo que debe ser ejecutado por el equipo de proyecto para conseguir materializar los
objetivos del mismo y crear sus entregables.
EVM, EarnedValue Management – EVM es una técnica de control de proyectos que se

utiliza para determinar el desempeño de un proyecto comparando entre sí tres variables
independientes medidas sobre una actividad o paquete de la EDT en un momento de tiempo
determinado. El EVM permite determinar las desviaciones respecto a los objetivos de
calendario y coste del proyecto, y hacer predicciones de las condiciones del futuro del
proyecto basadas en la información y datos disponibles en el momento de la predicción. Para
la gestión de proyectos se incorporarán las buenas prácticas definidas por el estándar del
EVM durante el seguimiento y control del proyecto.
Hito, Milestone– Hito es todo evento relevante del calendario del proyecto. Normalmente los
hitos se asocian a la finalización de entregables o a la finalización de fases asociadas al ciclo
de vida definido para el proyecto.
Interesados en el proyecto, Stakeholders– Personas u organizaciones involucradas

activamente en el proyecto, o cuyos intereses puedan ser afectados por la ejecución del
proyecto o por su resultado. Ejemplos de interesados en el proyecto: Patrocinador del
proyecto, equipo de dirección, equipo de proyecto, usuarios, cliente, oficinas de gestión de
proyectos, etc.
Línea base, Baseline–Se denomina así al último Plan para la Dirección del Proyecto
formalmente aprobado, que incorpora el alcance total del proyecto, los compromisos de
calendario y fechas de entrega y su presupuesto asignado. Las diferentes líneas base se
utilizan para el seguimiento y control del proyecto usando la técnica del EVM. El Plan para la
Dirección del Proyecto aprobado incorpora:
Plan para la Dirección del Proyecto – También llamado plan integrado de alcance,
calendario y costes. El Plan para la Dirección del Proyecto aprobado es el elemento sobre el
que mediremos periódicamente la situación de nuestro proyecto. Es el producto principal de
la fase de planificación, y relaciona, en un plan de trabajo integrado las tres líneas base:
Paquete de Trabajo – Elemento resultante de la división o descomposición del alcance del

proyecto (EDT) en sus diferentes componentes. Los paquetes de trabajo deben poderse
estimar de manera realista en esfuerzo y duración, y con cierto nivel de confianza. Los
paquetes de trabajo siempre generan un producto o un entregable como resultado y pueden

192
ser controlados mediante la técnica de EVM. Un paquete de trabajo debe poder completarse
sin interrupciones, es decir, sin necesidad de más información y si se desea puede
subcontratarse o externalizarse.
RP, Responsable del Proyecto – Directos de Proyectos, PM. El RP es la persona

designada por la organización para gestionar un proyecto. Gestionar un proyecto implica,
entre otras responsabilidades, identificar los requisitos, establecer objetivos claros y
alcanzables, equilibrar las demandas del proyecto de calidad, alcance, coste y calendario,
adaptar las especificaciones, planteamientos y planes a las expectativas de los diferentes
interesados en el proyecto.
Solicitud de Cambio –Es el mecanismo formal donde se recoge toda la información

referente a un cambio, dentro de un Proyecto.
Tipos de Cambio –Muchos son los tipos de cambio que pueden surgir en un desarrollo, y
cada uno puede requerir un tratamiento específico. En la Gestión de Cambios se incluyen
únicamente los cambios de Tipo “nuevo requisito” y “mejora”.
Ciclo de Vida –El ciclo de vida es un aspecto fundamental asociado a toda solicitud de
cambio y el cual permite conocer el flujo o secuencia que seguirá cada una de las solicitudes
a lo largo de los diferentes estados en los que se puede encontrar hasta ser implementado.
EAP –Enunciado Detallado Del Alcance Del Proyecto
TI – Tecnologías de la Información.
TIC – Tecnologías de la Información y las Comunicaciones.
SUNAT: La Superintendencia Nacional de Aduanas y Administración Tributaria (SUNAT) es

un organismo técnico especializado del Perú adscrito al Ministerio de Economía y Finanzas.
2.1.3 Identificación del Proyecto
2.1.3.1 Objetivo General del Proyecto
El objetivo de este proceso es contratar el Servicio de desarrollo, pruebas y puesta en

producción del Sistema de Cuenta Única de Contribuyente para los dos primeros MVP de los
cinco que constituyen el alcance completo del sistema.

193
2.1.3.2 Objeto de las Especificaciones Técnicas
 Desarrollar el sistema de cuenta única de contribuyente y usuario de comercio exterior

cumpliendo con los requerimientos funcionales y no funcionales y la especificación de la
Arquitectura especificada en estos términos de referencia.
 Desarrollar los Agentes Extractores de Datos con el objetivo de obtener datos desde los
sistemas legados sobre la infraestructura on-premise de LA SUNAT, así como resolver toda
la interoperabilidad entre los sistemas legados y el sistema de cuenta única bajo la
arquitectura descrita en este documento.
 Brindar los ambientes de desarrollo y prueba a lo largo del proyecto.
 Brindar a LA SUNAT, lo requerido en el presente TDR, con el fin habilitar sus ambientes de
desarrollo y pruebas al finalizar el desarrollo del MVP2.
 Realizar la carga inicial de datos al sistema de Cuenta Única de Contribuyente.
 Utilizar las herramientas especificadas en estos términos de referencia para el desarrollo,

prueba y puesta en producción del sistema.
 Implementar el Modelo de DevOps del Sistema de Cuenta Única definido en estos términos
de referencia.
 Llevar a cabo todas las pruebas necesarias al sistema para asegurar el cumplimiento de los
requerimientos funcionales y no funcionales, teniendo en cuenta todos los aspectos técnicos,
así como la integración a los demás sistemas de LA SUNAT. Documentar la metodología
para llevar a cabo las pruebas, los detalles técnicos de las pruebas y sus resultados.
 Proporcionar a LA SUNAT lo requerido en el presente TDR con el fin de poner en producción

el sistema de cuenta única de contribuyente, según la estrategia de implantación que se
definirá en la fase de planificación, asegurando el correcto funcionamiento, la seguridad de
la información, la disponibilidad del servicio y todo lo que sea necesario para su correcta
operación.
 Elaborar la documentación técnica y capacitar a los técnicos de LA SUNAT realizando la

transferencia de conocimiento de los aspectos técnicos del sistema: entorno de desarrollo,
estructuración del sistema, arquitectura del sistema, código fuente y todos los elementos
necesarios para su correcta operación y evolución.
 Elaborar la documentación de usuario del sistema y capacitar a los usuarios de éste.
 Brindar el servicio de mantenimiento correctivo y soporte del sistema desde su puesta en

producción.

194
 Brindar el servicio de mantenimiento evolutivo mediante la modalidad de pedidos a demanda
por parte de LA SUNAT.
2.2 Fases del Proyecto
La siguiente imagen presenta un cronograma macro-global del proyecto.
MVP1 y MVP2:
Ilustración 75: MVP1 y MVP2
Fase Nombre Descripción

Se divide en tres etapas:
1. Planificación: elaboración del Plan de Gestión del Proyecto
01 Gestión
2. Seguimiento y Control del Proyecto
3. Finalización: cierre del proyecto
Se deberá cargar todos los datos que sean necesarios para el

correcto funcionamiento del sistema en pre-producción y
producción. Una vez puesto en producción el MVP1, la carga,
02 Carga inicial de datos
ajustes o migración de datos que se consideren necesarios para
los siguientes MVPs será parte de las etapas de desarrollo,
pruebas y puesta en producción de cada MVP.
a. Preparación: Se preparará todo lo necesario para el
Fase de Desarrollo,
desarrollo del sistema: ambientes de desarrollo y pruebas,
Pruebas y Puesta en
03 infraestructura, equipos, herramientas para la gestión y
producción del Sistema
seguimiento de las tareas de desarrollo y pruebas bajo la
CUC
metodología ágil y la capacitación del uso de ellas, etc.

195
Fase Nombre Descripción
b. Desarrollo de cada MVP: Esta es la fase donde se
construirá, probará y pondrá en producción el sistema CUC.
Migración de los
Se deberá proporcionar a LA SUNAT lo requerido para habilitar
04 ambientes de desarrollo
sus ambientes de desarrollo y pruebas.
y pruebas
Fase de Capacitación y Si bien habrá capacitación antes de la puesta en producción de

05 Transferencia de cada MVP, se prevé una fase de capacitación y transferencia de
Conocimientos conocimientos hacia los usuarios y técnicos de LA SUNAT.
Fase de Mantenimiento Se refiere a corregir los incidentes o errores presentados

06
Correctivo y Soporte durante el uso en producción del sistema.
Tabla 29: MVP1 y MVP2
2.2.1 Fase de Gestión
Esta Fase se divide en tres etapas:
2.2.1.1 Plan General de Trabajo
2.2.1.1.1 Etapa: Planificación

Esta etapa tiene como objetivo principal elaborar el Plan de Gestión del Proyecto, el cual
deberá basarse en los procedimientos, buenas prácticas y recomendaciones del Project
Management Body of Knowledge (PMBOK) sexta edición del Project Management Institute.
El Plan de Gestión deberá abarcar las 10 áreas de conocimiento y todos los procesos de
gestión, así como el modelo de Gobernanza de éste en sus diferentes niveles (técnico,
táctico y estratégico) e incluir el Plan de Gestión de Cambios que se aplicará en el proyecto.
En forma adicional deberá incluir la planificación (cronograma) de las siguientes actividades:
 Implementación del ambiente físico en donde se realizará el servicio.

 Implementación de la infraestructura tecnológica del servicio (HW y SW) para el
personal que desarrollará el servicio, así como las comunicaciones y la seguridad del
ambiente físico donde se realizará el servicio.

196
 Revisión y aprobación de metodologías, Gobernanza, formatos de los entregables y
estándares aplicables al proyecto
 Transferencia de conocimiento de LA SUNAT hacia LA FIRMA CONSULTORA, según
acuerdo entre las partes.
2.2.1.1.1.1 Cronograma
Ver Cronograma de Hitos en el Anexo 3
2.2.1.1.1.2 Principales Hitos

a) Presentación del Plan general del Proyecto
b) Aprobación del Plan general del Proyecto
2.2.1.1.2 Etapa: Seguimiento y Control del Proyecto
Esta etapa se ejecutará en paralelo a todas las demás fases del proyecto con el objetivo de efectuar
el seguimiento y tomar las acciones que correspondan de acuerdo con lo señalado en el Plan de
Gestión.
A lo largo del proyecto se mantendrá actualizado el sistema informático de gestión, el cual debe
permitir hacer un monitoreo general pero también a nivel de cada historia de usuario y por diferentes
dimensiones (riesgos, presupuesto, comunicaciones, alcance, cronograma, etc.), monitorear el
avance en el Backlog del producto, esto significa que se podrá ver cuántas historias de usuario,
comparando lo real con lo planificado en el Plan de Gestión consolidando la información por MVP,
Release y Sprints.
La gestión de proyectos es un conjunto de acciones estimadas para alcanzar un objetivo determinado.

Para ello, deben desarrollarse bajo el paraguas de una estrategia alineada con la de la empresa. Es
un conjunto de actividades realizadas durante todo el tiempo del proyecto, bajo unos requerimientos
dados y por un determinado equipo de trabajo.
Tener en cuenta plazos, riesgos, actividades, equipo, costes, etc. Todo debe estar bien coordinado
para que el trabajo que se ejecute siga la dirección que necesitamos, siempre y cuando
aprovechemos y optimicemos los recursos.
A continuación, se especifican las principales gestiones asociadas a la labor de dirección y gestión
del proyecto desde el inicio hasta su finalización.
2.2.1.1.2.1 Gestión del avance del proyecto
Un factor de éxito fundamental en cualquier proyecto es la capacidad de su director o jefe de proyecto

para tomar decisiones correctas en el momento oportuno. Lo cual sólo se puede hacer si se cuenta

197
con información clara, confiable y actualizada acerca del progreso del proyecto. De la misma manera
es igualmente importante proporcionar información concisa a los interesados en el proyecto. La
gestión del valor ganado del PMI proporciona un enfoque para medir el desempeño del proyecto a
partir de la comparación de su avance real frente al planeado, permitiendo evaluar tendencias para
formular pronósticos
Según vaya avanzando el proyecto, el Consorcio aplicará el estándar del valor ganado del PMI como
mecanismo de control de avance.
Además, se proponen los dos siguientes indicadores para tener información sobre el avance del
proyecto:
Indicador Contenido
SPI Es una medida de eficiencia del cronograma que

(Schedule permitirá saber si el trabajo realizado hasta la
Performance fecha se encuentra dentro de la planificación
Indicator) prevista.
 Si es menor que 1, indica que la planificación lleva

retraso.
 Igual a 1 indica que estamos dentro del plan

previsto.
 Mayor que 1 indica que vamos con adelanto sobre

la planificación prevista.
ETC Se trata del valor que cada miembro del equipo de

(Estimated to trabajo estima como necesario para finalizar una
Complete) tarea.
Tabla 30: Gestión del avance del proyecto
Además de estos indicadores, y a partir del valor ganado, el Jefe de proyecto mantendrá internamente
otros, como son el CPI (Cost Performance Indicator) o el EAC (Estimate At Completion) que permitirán
informar de manera objetiva sobre el avance real del proyecto, y poner en marcha acciones
correctivas cuando la desviación sea significativa.
2.2.1.1.2.2 Modelo de Relación
En base a la experiencia en la gestión de proyectos, se propone para una efectiva gestión del proyecto
SCUC, el siguiente modelo de relación para el seguimiento y control del proyecto. Los criterios
empleados en la definición del modelo, así como la información de seguimiento y control a utilizar,

198
están orientados a facilitar una comunicación eficaz entre ambas partes, que garantice la fluidez y
agilidad necesaria para la gestión y toma de decisiones.
El seguimiento y control del proyecto se articulará a través de los siguientes mecanismos:
Ilustración 76: Modelo de Relación
2.2.1.1.2.2.1 Comité de Dirección o Comité Directivo

Es el máximo órgano de control del proyecto, con capacidad para representar tanto a la SUNAT
como a Indra en el marco de colaboración de este proyecto. Mantiene una visión global del conjunto
del proyecto, de sus hitos y sus interdependencias, así como de los riesgos potenciales e
incidencias.
Se establece como órgano máximo de interpretación de las distintas vicisitudes que pudieran surgir
en la prestación de los servicios requeridos en este contrato, tanto en la relación con el
adjudicatario del servicio como en los imprevistos que en la relación con los usuarios pudieran
producirse.
Se constituirá al inicio del proyecto y se mantendrá hasta su finalización. Se reunirá bajo petición de
algunas de las partes o como mínimo una vez al trimestre.
 Composición:
o Por parte de la SUNAT:
 Dirección de la SUNAT
 Jefe del proyecto por parte de la SUNAT
 Responsables de área de la SUNAT que en cada momento se considere
oportuno convocar en función del orden del día de la reunión.
o Por parte de Indra:
 Director del Mercado AA.PP. en Perú
 Jefe de proyecto
 Responsables del equipo de trabajo (equipo clave) que en cada momento se
considere oportuno convocar en función del orden del día de la reunión
 Funciones y responsabilidades:
o Marcar las estrategias y líneas generales de actuación del proyecto.

199
o Realizar el seguimiento de la consecución de hitos, análisis de desviaciones, impacto
sobre los hitos pendientes y asesoramiento de riesgos.
o Dirigir, coordinar y apoyar la labor de los participantes en el proyecto.
o Validar los entregables o resultados parciales o totales del proyecto.
o Controlar el cumplimiento de los compromisos establecidos en el contrato.
o Efectuar el control económico, de plazos, de calidad, de requerimientos y de
especificaciones del proyecto.
o Garantizar la comunicación y la movilización de las personas.
o Realizar el análisis, control y resolución de las peticiones de cambio en las
especificaciones acordadas.
o Decidir sobre las posibles incidencias que se produzcan a lo largo del proyecto.
o Priorizar los objetivos del proyecto tomando las decisiones necesarias para su
correcta marcha.
2.2.1.1.2.2.2 Comité de Seguimiento

Es el órgano normal de gestión del proyecto a nivel operativo, y responsable directo de la
consecución de sus objetivos. Supervisa la ejecución del contrato.
Sus funciones: establecer las prioridades, valorar y aprobar las estimaciones de tiempo previsto
para la realización de las tareas objeto del contrato, dar el visto bueno a su finalización y resolver
los eventuales conflictos que pudieran surgir
Depende del Comité de Dirección, a quien informa y reporta.
Se constituirá al inicio del proyecto, con el mismo ciclo de vida que el Comité de Dirección. Se
reunirá con una periodicidad mensual.
 Composición:
o Por parte de la SUNAT:
 Jefe del proyecto
 Responsables de área de la SUNAT
 De forma puntual, algún miembro del equipo funcional o técnico que se estime
necesario.
 Jefe del proyecto
 Responsables del equipo de trabajo (equipo clave)
 De forma puntual algún miembro del equipo: Especialista funcional, consultores
tecnológicos, etc. que se estime necesario
o Planificación, Coordinación, Control y Seguimiento.

200
o Seguimiento y control de los riesgos del proyecto
o Funciones de soporte
 Garantía de Calidad.
 Gestión de Configuración.
 Organización y Metodología.
 Soporte de Herramientas / Utilidades.
 Interlocución con los Responsables de las distintas actuaciones.
o Funciones de comunicación y difusión en coordinación con la PMO y Oficina de
Gestión del Cambio.
2.2.1.1.2.2.3 PMO – Oficina de Proyecto
Las funciones de la PMO, será la encargada de realizar las tareas de coordinación y difusión del
proyecto a nivel operativo, y responsable directa de la elaboración de la información necesaria para
los Comités de Dirección y Seguimiento.
Depende del Comité de Dirección y de los Comités de Seguimiento, para quien trabaja.
Se constituirá al inicio del proyecto, con el mismo ciclo de vida que el proyecto.
 Composición:
 Jefe de Proyecto
 Líder PMO
 Personal de la PMO
 Especialistas en Capacitación
 Abogado Gestor del Contrato o Contract Manager
o Aportar la información necesaria al Comité de seguimiento y a la Oficina de Gestión
del Proyecto para poder realizar las funciones de seguimiento y control. Facilita y
recopila la información y elabora los informes para los distintos Comités.
o Realización de las funciones correspondientes a las distintas fases del proyecto.
o Funciones de comunicación y difusión, tanto a nivel interno como a nivel externo con
el Apoyo de la Oficina de Gestión del Cambio. El papel de la Oficina de Proyecto será
de colaboración con la SUNAT, proporcionando información sobre la marcha del
proyecto en su conjunto y a nivel individual sobre cada una de las actuaciones.
o Uno de los objetivos que debe cubrir la Oficina de Proyecto es la de difusión de
resultados.

201
Para Indra es prioritario facilitar la gestión por parte de la SUNAT de los aspectos clave del servicio.
Por esto, establece mecanismos que aportan la información que estos necesitan para realizar esta
gestión:
Procedimientos de control y seguimiento: Dentro de los procedimientos de control y gestión

destacamos los siguientes elementos:
o Reuniones (Comités de Dirección y de Seguimiento)

o Procedimiento de gestión de cambios
o Procedimiento de gestión de incidencias
o Procedimiento de entregas y aceptaciones
o Gestión de riesgos
Documentación de gestión: Indra definirá el modelo de documentación de acuerdo a lo establecido

por la SUNAT, y los procedimientos de entrega y aceptación de esa documentación.
2.2.1.1.2.2.3.1 Reuniones del Comité de Dirección

El Comité se reunirá al inicio del proyecto (reunión de arranque).
El Comité se reunirá de manera ordinaria, pudiendo hacerlo con carácter extraordinario siempre que
se considere necesario.
En las reuniones del Comité de Dirección podrán participar, además de sus miembros, todas
aquellas personas que el Comité considere oportuno, con objeto de cubrir los objetivos.
En las reuniones de este Comité, Indra facilitará a sus miembros un Informe de Dirección
correspondiente al período transcurrido desde la reunión anterior.
El Jefe del Proyecto por parte de Indra, o persona delegada, será el secretario del Comité, siendo
responsable de:
o Realizar la convocatoria de la reunión.

o Levantar acta de la reunión con los acuerdos alcanzados y presentarla a los demás
miembros del Comité para su firma.
2.2.1.1.2.2.3.2 Reuniones del Comité de Seguimiento

Como complemento a las reuniones de seguimiento y control a celebrar por parte del Comité de
Dirección, se celebrarán otro tipo de reuniones de seguimiento de carácter específico / sectorial,
convocadas por la Oficina de Gestión del Proyecto, representando uno de los mecanismos de
gestión interactiva del proyecto, siendo sus funciones principales:

202
o Informar a todos los miembros del equipo de aspectos de interés general de las
distintas actuaciones del proyecto.
o Grado de avance en la ejecución de proyecto, en las áreas respectivas
o Contenido y análisis de la información y documentación.
o Aumentar la coordinación entre los distintos grupos de trabajo.
o Conocer y contrastar las opiniones de las personas del equipo.
o Detectar posibles problemas que pudieran incidir en la marcha de las actuaciones.
o Favorecer, en general, la comunicación e integración de los miembros del equipo del
proyecto.
2.2.1.1.2.3 Procedimiento de Gestión de Cambios

Cambio
Definiremos como Cambio a todo tipo de modificación o extensión que afecte a los trabajos en el
proyecto, definidos en el presente documento. También, denominaremos cambio a cualquier
modificación de un entregable ya aceptado.
Un cambio afecta al presupuesto de ingresos y costes del contrato. Puede ser una actualización,
una mejora, una extensión o una corrección y pueden estar originados por:
o Cambios en el acuerdo y/o identificación de nuevos componentes.

o Variaciones en el equipo de trabajo y/o en la dedicación de sus miembros
Objetivos
Incorporar al proyecto todas aquellas necesidades surgidas o identificadas con posterioridad a su

inicio. La finalidad del control de cambios es identificar, documentar, seguir y consensuar el cambio
que se realice para dejar clara su repercusión y estimar su impacto en la planificación y en los
costes, ya que se trata de una modificación del acuerdo de Prestación de Servicios inicial.
Área Origen del Petición de cambios de

Cambio alcance
Registro del cambio y Elaborar un informe ejecutivo Actualizar el documento de
Oficina de evaluación inicial de la planteando los posibles escenarios, alcance, Plan de proyecto, y
Proyecto petición. su impacto y valoración. comunicar a las área afectadas
Solicitar a los equipos ¿Aprobar

¿Se ha de Sí ¿impacto Sí la petición
afectados un análisis del
realizar? impacto y valoración de la pequeño? de
Comité de
petición de cambios cambio?
Seguimiento No No No
Fin Fin
¿Aprobar
Comité de No Sí
Dirección Fin la petición de
cambio?
Ilustración 77: Modelo de Relación

203
2.2.1.1.2.4 Procedimiento de Gestión de Incidencias
Incidencia
Definiremos como Incidencia a todo tipo de circunstancia que afecta al desarrollo normal del
proyecto.
Un conjunto de incidencias de la misma naturaleza, de origen ajeno a Indra, puede originar un

cambio.
En las incidencias imputables a Indra, la responsabilidad de su registro y resolución es asumida por

ésta.
En caso contrario, el control consiste en consensuar con la SUNAT el origen de la incidencia para
poder evitarla en un futuro y acordar conjuntamente como se resolverá. En este caso será
considerada como un cambio.
Objetivos
Identificar y controlar aquellos factores que puedan afectar al desarrollo del proyecto. La finalidad
del control de incidencias es su rápida resolución.
Área Origen del Si

Detección de la Incidencia
Cambio
Elaborar un informe ejecutivo Actualizar el documento de

Oficina de Registro de la incidencia ¿Imp.
planteando los posibles escenarios, alcance, Plan de proyecto, y
y evaluación inicial Indra? comunicar a las área afectadas
Proyecto su impacto y valoración.
No
Solicitar a los Sí Sí
equipos afectados ¿impacto ¿Aprobar la
Sí pequeño? resolución?
No ¿Se ha de un análisis del
Comité de Fin gestionar? impacto y valoración
Seguimiento No
de la petición de No
cambios Fin
Comité de No ¿Aprobar Sí
Dirección Fin la resolución?
Ilustración 78: Procedimiento de Gestión de Incidencias
2.2.1.1.2.5 Procedimiento de Entregas y Aceptaciones

Objetivos
Formalizar el proceso de entrega y aceptación de los entregables del proyecto.
El período de aprobación que se propone de los entregables del proyecto es de dos (2) días
laborables para actas del proyecto y de diez (10) días laborables para el resto de entregables. No
obstante, y si fuera necesario establecer otros periodos de aceptación para cualesquiera otros
entregables, se deberá especificar en el “Plan de Proyecto” y “Plan de Calidad”.
La ausencia de respuesta por escrito en el período indicado se asume como una aprobación tácita.

204
Si el desarrollo del trabajo así lo exigiera, este período podría verse modificado en el Comité de
Seguimiento, con la finalidad de evitar retrasos en el desarrollo del servicio.
Las detecciones de regresión posteriores a una aceptación/validación serán tratadas por el

procedimiento de Gestión de Incidencias descrito.
La aprobación de todos los resultados parciales supone la aceptación de la globalidad del proyecto.
Ilustración 79: Procedimiento de Entregas y Aceptaciones
2.2.1.1.2.6 Gestión de la Configuración.

El propósito del proceso de gestión de la configuración es establecer los mecanismos
para garantizar la integridad entre la documentación, así como para garantizar la
calidad de todo producto obtenido durante cualquiera de las etapas del desarrollo, a
través del estricto control de los cambios realizados y de la disponibilidad constante
de una versión estable de cada elemento. La gestión de la configuración se realizará
durante todas las fases del proyecto, incluyendo el mantenimiento, una vez realizada
la puesta en Producción.
Consorcio se ajustará a la metodología de la SUNAT, respecto al repositorio de

código y, tal y como viene indicado en el pliego, el formato y nomenclatura de los
artefactos.
Consorcio considerará proporcionar un espacio documental para almacenamiento de

los entregables y documentación de proyecto, y capacitará a la SUNAT sobre el
correcto uso de dicho sistema informático.

205
2.2.1.1.2.7 Documentación de Gestión
 Reporting. Aspectos clave
1 Objetivo 3 Factores de riesgo
 Comunicar las informaciones adecuadas, suficientes y  Demasiados inf ormes que nadie lee
necesarias para revisar, evaluar, analizar y decidir en los  Demasiados inf ormes a nivel no adecuado
niveles apropiados de la organización del
2 Factores de éxito 4 Lecciones Aprendidas
 Tener un plan de reporting de informes claramente  Normalizar y racionalizar la inf ormación que se transmite a
definido en términos de: todos los niveles de la organización para que sea:
 Qué información contiene  Comprensible, f ácil de interpretar (mejora la
 Cómo se presenta la información productividad), clara, útil, etc...
 Cuándo se presenta el informe  “la sobre inf ormación es una f uente de no
 A quién está dirigido inf ormación” o “el exceso de luz es como el exceso de
oscuridad, ambos impiden ver”
Ilustración 80: Documentación de Gestión
Los instrumentos básicos para el seguimiento y control del proyecto serán los siguientes:
2.2.1.1.2.7.1 Reuniones Operativas

Como complemento a las reuniones de seguimiento y control a celebrar por parte del Comité de
Dirección y del Comité de Seguimiento, se celebrarán otro tipo de reuniones operativas de carácter
específico / sectorial, convocadas por la Oficina de Gestión del Proyecto, representando uno de los
mecanismos de gestión interactiva del proyecto, siendo sus funciones principales:
o Informar a todos los miembros del equipo de aspectos de interés general de las
distintas actuaciones del proyecto.
o Grado de avance en la ejecución de proyecto en las áreas respectivas
2.2.1.1.2.7.2 Plan de Proyecto

Se preparará en la fase de arranque del proyecto y contendrá la información de partida para el
comienzo del proyecto, la planificación detallada, la organización y componentes de los grupos de
trabajo y del Comité de Dirección y de Seguimiento y los distintos hitos a cubrir y productos a
obtener.
Este documento podrá ser modificado en el transcurso del proyecto, siempre que se acuerden, por
un órgano de control variaciones, a los objetivos marcados.
2.2.1.1.2.7.3 Informes de Dirección

El objetivo de este informe es que el Comité de Dirección tenga conocimiento del estado del
proyecto a una fecha determinada. Información que debe recoger:

206
Básicamente, la información que deberá recoger será la siguiente:
o Revisión de decisiones de acta de reunión de Comité de Dirección anterior.

o Visión general del plan de proyecto, con un mayor nivel de detalle en la fase actual.
o Hitos y avance realizados en el último período.
o Incidencias que han aparecido. Causas de las desviaciones (si existiesen). Acciones
correctoras.
o Revisión de actividades críticas y riesgos importantes.
o Propuestas de cambios de los objetivos del proyecto
2.2.1.1.2.7.4 Informes de Seguimiento

Este informe tiene como objetivo que el Comité de Seguimiento pueda tener conocimiento del
estado real del proyecto en su conjunto y tomar decisiones que pudieran afectar a los objetivos del
proyecto. El informe será elaborado por Indra con anterioridad a las reuniones y deberá reflejar su
situación a una fecha determinada.
Básicamente, la información que deberá recoger será la siguiente:
o Revisión de decisiones de acta de reunión de Comité de Seguimiento anterior

o Situación del proyecto. Visión general del plan de proyecto, con un mayor nivel de
detalle en la fase actual.
o Principales resultados obtenidos en el período.
o Productos entregados
o Problemas surgidos.
o Cambios sobre la planificación inicial.
o Resultados que se prevea obtener en el período comprendido hasta el siguiente
Comité.
o Acciones / decisiones a tomar por el Comité de Seguimiento.
o Resúmenes del progreso del proyecto.
o Riesgos del Proyecto
2.2.1.1.2.7.5 Actas de reuniones

Seguirán el formato estándar establecido para el proyecto y de manera habitual contendrán la
información siguiente:
o Personas convocadas a la reunión.

o Personas asistentes, indicando si representan a otra.
o Fecha de la reunión.
o Temas tratados.
o Acuerdos alcanzados.

207
o Compromisos adquiridos y personas y fechas responsables de los compromisos.
o Firmas de aceptación de los asistentes
2.2.1.1.2.7.6 Informes de calidad

Los informes de calidad se basarán en el seguimiento de un conjunto de indicadores definidos al
inicio del proyecto.
Los valores obtenidos periódicamente para dichos parámetros, y el análisis de su evolución

permitirán conocer la situación de calidad del proyecto e identificar la necesidad de poner en
marcha acciones correctoras o de mejora, así como valorar, en su caso, la bondad de las acciones
de mejora puestas en marcha.
Ver Cronograma Detallado en el Anexo 1

a) Entregables verificados
2.2.1.1.3 Etapa: Finalización
Objetivo principal garantizar el cierre del contrato una vez se hayan cumplido todos los
requisitos de este.

Ver tabla de Hitos en el Anexo 3
2.2.2 Fase de Carga Inicial de Datos
2.2.2.1.1 Etapa Carga Inicial de Datos
2.2.2.1.1.1 Inclusión de las tareas de análisis y estudio de migración dentro de los equipos
de análisis y desarrollo de los diferentes MVP
A pesar de que en el pliego publicado por la SUNAT ya se muestran tanto un primer modelo de
lo que se ha dado en llamar “Documento Normalizado” como diferentes diagramas de clases
a desarrollar dentro del sistema CUC, la propia SUNAT reconoce que todas estas estructuras
pueden estar sujetas a modificaciones.

208
Por lo tanto, una de las tareas prioritarias a realizar desde el inicio del proyecto es un análisis,
revisión y validación expresa de cada una de dichas estructuras. Todo ello, con el fin de
poder identificar si se satisfacen las necesidades de interoperabilidad del sistema o si, por el
contrario, es necesario realizar cambios adicionales.
Estas tareas de análisis y revisión deberán llevarse a cabo pilotadas por parte de los diferentes
“product owners” de cada funcionalidad/épica y por parte de los responsables de las aplicaciones
legados que vayan a utilizar cada una de las funcionalidades/épicas. El objetivo de estas tareas
será:
 Identificar cuáles son los sistemas legados que contienen información necesaria para la
correcta reconstrucción del saldo de cada uno de los contribuyentes.
 Definir e identificar los datos a extraer de cada uno de los sistemas legados para poder
construir un saldo de cada uno de los contribuyentes. Estos datos deberán asegurar la
consistencia de la información entre la CUC y las aplicaciones legados en cuestión.
 Definir la estructura definitiva del “documento normalizado” de entrada a la CUC, así como la
estructura de los diferentes extractores, teniendo en cuenta las particularidades y
necesidades de cada una de las épicas/funcionalidades de los MVP1 y MVP2.
En definitiva, el objetivo de estas tareas será la definición de una estructura definitiva de

intercambio y normalización de datos que permita y asegure el correcto funcionamiento del
esquema de interoperabilidad entre la CUC y las diferentes aplicaciones legadas y/o satélites.
Siendo la carga inicial de datos una transacción más de este esquema, podrá aprovecharse todo
este trabajo realizado para minimizar el esfuerzo global necesario para su desarrollo.
Dado que las tareas de análisis de datos y definición de las estructuras de “documento
normalizado” y “extractor” se llevarán a cabo por parte de los diferentes equipos de desarrollo
asignados a cada una de las funcionalidades/épicas de los MVP1 y MVP2, CONSORCIO propone
que sean dichos equipos quienes incluyan el estudio de las necesidades de carga inicial de
datos en sus planes de trabajo, haciendo especial hincapié en:
 El conocimiento de la estructura de la información en los sistemas de origen.
 El mapeo entre la estructura de los registros en los sistemas legados de origen y la estructura
del documento normalizado aplicable a cada una de las funcionalidades/épicas.

209
 La definición de las reglas de calidad y validaciones a aplicar a los datos a incorporar al
sistema CUC, tanto para las transacciones estándar como para la migración inicial de datos.
Detrás de esta idea subyace el hecho de que implicar a los equipos de desarrollo en la migración
permite optimizar el trabajo, ya que son ellos quienes, por su posición, pueden:
 Conocer e identificar a cada uno de los actores implicados en cada una de las
funcionalidades/épicas.
 Conocer, de primera mano, el esquema de interoperabilidad definido para cada una de las
 Comprender el funcionamiento de cada una de las funcionalidades/épicas y los

requerimientos que exigen en términos de datos en cada momento.
 Participar y asegurar la definición correcta y definitiva de las estructuras de intercambio entre

los sistemas implicados.
Siendo estos los principales aspectos clave que permitirán asegurar un correcto diseño y una
ejecución exitosa de las cargas de datos iniciales.
2.2.2.1.1.2 Designación de un “Responsable de Carga Inicial de Datos”
La reorganización de equipos y tareas propuesta por el CONSORCIO, exige la creación de la

figura –dentro del equipo de consultoría- de un “Responsable de Carga Inicial de Datos”, cuya
misión principal será velar por el correcto desarrollo, sincronización y ejecución de todas las
labores relacionadas con la carga inicial de datos.
Idealmente, por parte de la SUNAT, debería designarse un puesto análogo que permita reforzar
y asegurar por su lado el correcto desarrollo de las tareas asociadas a la carga inicial de datos
que dependan de personal de la SUNAT.
Serán tareas propias de este “Responsable de Carga Inicial de Datos”:
 Definir y mantener el “Plan de Carga Inicial de Datos”.
 La generación y entrega de toda la documentación asociada a la carga inicial de datos.
 Participar en todas las mesas ágiles y demás foros de toma de decisiones.

210
2.2.2.1.1.3 Validación expresa de las diferentes estructuras de carga y extracción de datos
La naturaleza del módulo CUC le sitúa como la pieza central de todo el esquema de
interoperabilidad de los diferentes sistemas de la SUNAT.
La creación de un nuevo epicentro dentro del parque aplicativo de la SUNAT, obligará a que
todos los responsables de los sistemas legados deban estar implicados -de un modo u otro- en
las tareas detalladas de definición de las estructuras aplicables para la normalización de los
documentos, ya sea porque sus sistemas sean sustituidos por la CUC o porque sus sistemas
perduren, aunque consumiendo y/o suministrando datos a la CUC.
Desarrollar el módulo CUC de forma aislada, sin considerar todos y cada uno de los sistemas
legados con los que debe interoperar sería un gravísimo error, ya que podría generar importantes
inconsistencias, no siendo capaz la CUC de recoger todas las operaciones para conformar
realmente un saldo único y correcto para el contribuyente.
La interoperabilidad exige, por otro lado, que la comunicación entre la CUC y los sistemas
legados sea bidireccional. Esta comunicación se canalizará a través de dos módulos:
 El “motor de normalización”, para la entrada de datos en la CUC.
 La “API de Cuenta Única” para el suministro de datos hacia los sistemas Legados.
Ilustración 81: Extracción de datos
La optimización del esquema de interoperabilidad es el factor que exige la creación de un

“documento normalizado” que, definido de forma simple no es más que el esquema único y
común a todos los sistemas legados y satélites de comunicación con la CUC.
En este sentido:

211
 El equipo de desarrollo –tanto a nivel de SUNAT como del CONSORCIO- será el responsable
de identificar y diseñar el esquema definitivo del “documento normalizado” aplicable a cada
funcionalidad/épica que permita asegurar el flujo de información hacia la CUC, a partir de las
informaciones suministradas por los equipos Legados.
 El “Responsable de Carga Inicial de Datos” deberá seguir de cerca el detalle de estos

esquemas para poder tener una visión de conjunto de los flujos de interoperabilidad con el
fin de certificar que los datos a cargar cumplen con todos los requerimientos necesarios para
asegurar el correcto funcionamiento de las operaciones. Para ello, deberá contar con la
ayuda de los diferentes equipos de desarrollo.
Los trabajos de análisis y diseño de las estructuras de datos no se darán por finalizados sin que
los responsables por parte de la SUNAT de las diferentes funcionalidades/épicas validen los
resultados obtenidos.
2.2.2.1.1.4 Ejecución de la carga de datos en la CUC a través de los programas

transaccionales
Otra de las premisas que propone el CONSORCIO, previa aprobación de SUNAT, es la
ejecución de la carga de datos a través es usar ETL, para cargar directamente a la base de datos
de la nube desde las bases de datos de los legados.
Se propone como una alternativa a las descritas, debido que existe pueden existir casos como
se muestran a continuación:
 Factibilidad de cargar ciertos saldos y movimientos sin la necesidad de usar el data

streaming. Como parte de la consolidación de saldos, antes de la puesta a producción.
 Información complementaria para el funcionamiento de cuenta única y que se
encuentran en los sistemas legados como por ejemplo: Información que residen en las
tablas maestras de los legados, información adicional de los contribuyentes, entre otros.
Para ello es necesario un mecanismo de sincronización de información.
 Para procesamientos de archivos planos como información inicial para la carga al CUC.
Para ello se debe ejecutar el siguiente proceso:

212
Ilustración 82: Ejecución de la carga de datos en la CUC
1. Realizar entrevistas con especialistas SUNAT
Herramienta Excel
Entradas Programación de Reuniones
Salidas Actas de Reunión
Descripción Se realizan reuniones con los líderes o especialistas de procesos,
de negocio y técnico para tener todos los puntos de vista
necesarios para poder armar los modelos de datos implicados.
2. Inventariar fuentes
Herramienta Excel
Entradas Actas de Reunión, Documentación de Sistemas / Fuentes
Salidas Inventario de Fuentes
Descripción Luego de realizadas las entrevistas y recopilada toda la
documentación de los sistemas / fuentes, se realiza un inventario
detallado de las fuentes a migrar, se debe describir el sistema /
fuente ya sean estructuradas (columnas, tablas) o no estructuradas
(archivos planos).

213
3. Revisar procesos MVP
Herramienta Excel
Entradas Diagramas de Procesos MVP
Salidas Análisis de Procesos MVP
Descripción Se hace una revisión de los procesos del respectivo MVP para
determinar que datos necesita para su correcto funcionamiento.
4. Realizar Modelos de Datos
Herramienta Robo 3T, Modelador UML

Participantes Arquitecto de Datos
Salidas Modelos de Datos Conceptual, Lógico y Físico
Descripción Se elaboran los modelos de datos Conceptual, Lógico y Físico, en
base al conocimiento adquirido de los procesos MVP combinados
con las fuentes inventariadas.
5. Realizar Fichas Mapeo de Procesos vs Entidades de Datos
Herramienta Excel
Entradas Análisis de Procesos MVP, Modelos de Datos
Salidas Fichas Técnicas de Mapeo
Descripción Se elaboran Fichas Técnicas donde se hace el mapeo entre los
procesos de los MVP y las estructuras modeladas.

214
6. Elaborar fichas Mapeo Fuentes vs Tablas
Herramienta Excel
Entradas Inventario de Fuentes, Modelos de Datos
Salidas Fichas Técnicas de Mapeo
Descripción Se elaboran Fichas Técnicas donde se detallan las fuentes, sus
columnas inventariadas y como finalmente alimentan las estructuras
modeladas. Aquí se especifican las reglas de migración o
transformación.
7. Elaborar Mallas de Jobs
Herramienta Apache NIFI

Entradas Fichas Técnicas de Mapeo, Modelos de Datos
Salidas Mallas de Carga
Descripción Se debe elaborar un orden de carga de las entidades modeladas,
para ello se elaboran mallas de Jobs, cada malla tiene un job
controlador que ordena la ejecución de cada job.
8. Implementar Jobs ETL

Entradas Fichas Técnicas de Mapeo, Modelos de Datos, Mallas de Carga
Salidas Jobs ETL
Descripción Se construyen los Jobs de Extraccion, Transformación y Carga
desde las fuentes inventariadas hacia los modelos de datos
construidos.
9. Realizar Pruebas de Carga de Mallas

Entradas Fichas Técnicas de Mapeo, Modelos de Datos, Mallas de Carga,
Jobs ETL
Salidas Pruebas de Carga
Descripción Se ejecutan pruebas de Jobs individuales, luego de mallas
individuales y luego la malla completa. Se revisan y corrigen
errores que se presenten.
10. Ejecutar Mallas de Jobs

Jobs ETL
Salidas Malla Ejecutada
Descripción Se ejecuta toda la malla de los Jobs para realizar la migración.

215
11. Elaborar Informe de Migración
Herramienta Apache NIFI, Word, Excel

Jobs ETL
Salidas Informe de Migración
Descripción Se elabora informe de migración con los datos originales,
luego los datos finales migrados.
2.2.2.1.1.5 Reconstrucción del “Saldo del Contribuyente”

La puesta en marcha de un nuevo sistema suscita siempre la pregunta de: “¿qué datos se van
a cargar?
El CONSORCIO propone que la carga inicial de datos de la CUC recoja únicamente aquellos
documentos o partidas que compongan el “Saldo Vivo” del contribuyente para los
tributos existentes a fecha del arranque de cada uno de los MVP. De este modo, los
históricos quedarán almacenados y disponibles para ser consultados en los sistemas legados
de origen.
La carga inicial de datos es, de per se, un proceso delicado y complejo al que no se debe añadir
dificultades superfluas. La práctica, a lo largo de muchos y variados proyectos, ha demostrado
que cargar los datos históricos no aporta ningún valor añadido –ya que, como hemos indicado,
siguen disponibles a fines de consulta en los sistemas de origen- y únicamente sirve para
dificultar innecesariamente las tareas de arranque del nuevo sistema.
La cuestión clave para poder realizar una carga inicial de datos útil y correcta es identificar todos
los posibles orígenes/aplicaciones que vayan a intervenir en el proceso de conformación del
“saldo vivo” a migrar para cada una de las funcionalidades/épicas.
Cada uno de estos orígenes deberá enviar al CU la información detallada que compone el saldo
de dicho contribuyente.
Se deberán cargar todos los documentos correspondientes a posiciones “abiertas” (deudas y

créditos) y también todos aquellos que puedan estar “bloqueados temporalmente” por tener
dependencias con contenciosos o procesos similares en curso que requieran del bloqueo del
documento en, por ejemplo, acciones de compensación.
En este sentido, será responsabilidad de la SUNAT:
 Identificar dentro de sus sistemas legados cuáles son las partidas a migrar a la CUC en cada
uno de los MVP.

216
 Validar del saldo obtenido y los documentos incorporados en la CUC como resultado del
proceso de migración de datos para cada uno de los contribuyentes.
2.2.2.1.1.7 Principales hitos

Ver tabla Hitos en el Anexo 3
Ya hemos mencionado las dependencias directas que presenta el proceso de migración de datos
respecto de las labores de desarrollo e integración de funcionalidades/épicas.
En este sentido es importante identificar cuáles son los principales hitos de este proceso para
identificar correctamente esas dependencias de modo que permitan trazar correctamente el
cronograma de la migración.
Es un requisito imprescindible que todos los hitos de la migración se acompasen de forma

adecuada con los nuevos desarrollos e integraciones, ya que, de otro modo, podrían generarse
inconsistencias en la información que impidiesen reconstruir el saldo/posición correcta,
documento a documento, de cada contribuyente.
La enumeración secuencial de hitos ligados al proceso de carga inicial de datos desde el inicio
del proyecto es la siguiente:
 Inicio de las labores de análisis y mapeo de datos entre sistemas implicados en cada una de
las funcionalidades/épicas.
 Obtención del modelo definitivo/transitorio (*) de normalización para cada una de las
funcionalidades/épicas de los MVP1 y MVP2.
(*) teniendo en cuenta la definición de integración definitiva e integración transitoria

establecido en el capítulo de interoperabilidad.
 Confección del inventario de las reglas de calidad, transformaciones y validaciones a aplicar

a los datos de sistemas legados a integrar en el sistema de Cuenta Única.
 Diseño detallado de los componentes y estructuras específicas a utilizar –teniendo en cuenta

las reglas de calidad, transformaciones y validaciones a aplicar a los datos- tanto para la
extracción de datos como para invocar al motor de normalización con el fin de efectuar la
carga inicial de datos del sistema de cuenta única.

217
 Confección de un Plan detallado de ejecución, especificando las diferentes ejecuciones de
carga que se realizarán de forma progresiva en los diferentes entornos de la plataforma hasta
llegar a la carga final a realizar en el entorno productivo.
 Inicio y fin de la construcción de dichos componentes y estructuras.
 Inicio de las pruebas –unitarias y de integración- de los componentes y estructuras.
 Aceptación por parte del usuario SUNAT responsable de la migración de los componentes y
estructuras.
 Proceso de depuración de datos iniciales a cargar (Data Cleansing) en el sistema de Cuenta

Unica. Este proceso no contempla, en ningún caso, la actualización y/o corrección de los
datos en los sistemas de origen por parte del equipo del Consorcio.
 Ejecución de test de cargas de datos y validación de los resultados obtenidos en cada uno
de los entornos del sistema (desarrollo, integración, test, etc.), resultados que quedarán
plasmados, para cada una de las ejecuciones en el correspondiente informe de ejecución.
 Preparación, validación y entrega por parte de la SUNAT de los ficheros conteniendo los
datos y documentos definitivos que conformen el saldo de cada contribuyente a integrar en
el entorno productivo del sistema de Cuenta Única para cada una de las
funcionalidades/épicas de los respectivos MVP1 y MVP2.
 Ejecución –para cada uno de los MVP1 y MVP2- de la carga de los datos suministrados por
SUNAT en el entorno productivo de la cuenta única.
 Validación de los datos cargados en el entorno productivo de la cuenta única.
Identificadas las dependencias y valorados los esfuerzos necesarios para la realización de los
nuevos desarrollos e integraciones transitorias para cada MVP1 y MVP2 se integrará el Plan de
Carga Inicial de Datos como una parte más del Plan de Gestión del Proyecto.
Este plan de carga incial de datos incluirá todos los hitos anteriormente enumerados, así como
un plan detallado de ejecuciones de carga datos que considerará tanto la carga definitiva de
datos en el entorno productivo, como todas las cargas previas en entornos de integración y

218
pruebas que sean necesarias para asegurar el éxito de la puesta en marcha de cada una de las
Es importante identificar, junto con los hitos del proceso, cuáles serán aquellos otros documentos
entregables ligados a las labores de carga inicial de datos.
A continuación, se enumeran estos documentos:
 Plan detallado de ejecución de carga inicial de datos, especificando las diferentes

ejecuciones de carga que se realizarán, de forma progresiva, en cada uno de los diferentes
entornos de la plataforma hasta llegar a la ejecución carga final en el entorno productivo para
los MVP1 y MVP2.
 Inventario completo de las reglas, validaciones y transformaciones a aplicar sobre los

datos a cargar hacia el sistema de Cuenta Única para cada una de las funcionalidades/épicas
de los MVP1 y MVP2.
 Diseño detallado de todos y cada uno de los componentes y estructuras a utilizar en el

proceso de carga inicial de datos para cada una de las funcionalidades/épicas de los MVP1
y MVP2.
 Informe de ejecución de la carga de datos. Este informe se generará no sólo para la carga
definitiva en el entorno productivo, sino para cada una de las cargas realizadas –a modo de
prueba- en entornos previos (desarrollo, test, etc…).
Su contenido incluirá el detalle de todas las actividades y pruebas realizadas en cada una de
las ejecuciones, así como una exposición y valoración de los resultados obtenidos.
Este informe recogerá también el detalle de las acciones y/o medidas correctivas necesarias
para corregir y subsanar los potenciales errores o problemas detectados en cada una de las
ejecuciones.
Todos y cada uno de estos entregables serán generados, secuenciados y versionados

adecuadamente para los MVP1 y MVP2.

219
2.2.3 Fase de Desarrollo, Pruebas y Puesta en producción del Sistema de Cuenta Única de
Contribuyente:
Teniendo en cuenta la magnitud del proyecto y el número de equipos de desarrollo en paralelo, se

requiere una planificación previa al inicio del desarrollo de las herramientas de orquestación de la
infraestructura e instalación de los servicios/productos necesarios para garantizar una buena gestión
de los costes además de un sistema robusto de CI/CD garantizando la calidad del código, las pruebas
de los desarrollos para garantizar la no regresión y pruebas de integración para validar la
comunicación correcta entre los microservicios desarrollados e integraciones con terceros. Para ello
se debe disponer de las herramientas de desarrollo necesarias para antes de llegar al CI/CD
garantizar los puntos anteriores. Además, se deberá disponer de las herramientas necesarias para
garantizar una correcta definición de los contratos de los servicios y su catalogación. Por otra parte,
teniendo en cuenta que el desarrollo está basado en microservicos será necesario disponer de un
sistemapara concentración, monitorizamiento y visualización de logs y métricas para garantizar la
trazabilidad correcta de la aplicación.
Como inicio del proyecto, LA SUNAT deberá proporcionar los siguientes elementos:
 Toda la información relativa a la arquitectura del sistema, historias de usuario y demás materiales
producidos por la consultoría “Servicio de Elaboración de la Arquitectura del Sistema de Cuenta
Única”.
 Configuraciones de red, en caso de que sean necesarios;
 Material y documentación de la infraestructura actual de LA SUNAT en caso de que sea necesario
y estén disponibles
 Capacitación a LA FIRMA CONSULTORA en conceptos generales de Cuenta Única de
Contribuyente y conceptos particulares de la cuenta única en LA SUNAT, así como en
conocimiento general de LA SUNAT, áreas involucradas y procesos que tienen puntos de
contacto con la cuenta única
 Información sobre los lineamientos técnicos, estándares, metodologías y buenas prácticas
promovidas por LA SUNAT en los temas que aplicarán para el proyecto.
2.2.3.1.1 Etapa: Inicial
2.2.3.1.1.1 Conformación del Centro de Excelencia

“Centro de Excelencia es un equipo interdisciplinario que se encarga de guiar las decisiones sobre
diseño e implementación para lograr soluciones planteadas según la estrategia de la Organización”

220
El centro de excelencia contará con la participación de personas expertas en cada uno de los
siguientes roles:
Product Owner: el cual estará conformado por especialistas funcionales, con fuertes
conocimientos en el negocio y las historias de usuarios planteadas.
Experto metodológico: será integrado por un especialista en la metodología ágil que se empleara
durante la ejecución del proyecto.
Arquitecto Cloud: este rol será ejercido por un experto en la nube utilizada para el proyecto CUC,
este experto conocerá la infraestructura y los servicios prestados por dicha nube.
Arquitecto de datos: será responsable de especificar como realizar de forma correcta el

modelamiento de datos, especificará el estándar a utilizar y certificará que se esté aplicando
correctamente.
Arquitecto tecnológico: especificará los lineamientos y estándares de desarrollo también definirá

las herramientas a utilizar durante la implementación de las tareas de desarrollo. Este experto
garantizará que los estándares se cumplan como fueron especificados.
Especialista QA: este rol contará con un experto que ayudará al equipo de pruebas a definir
técnicas, lineamientos y estándares más apropiados para elaborar las pruebas. Propondrá informes
que expongan de mejor forma los resultados de las pruebas.
Especialista UX: este rol tendrá un experto en experiencia de usuario y definirá los lineamientos
principales que se deberán cumplir durante el diseño de las interfaces del proyecto.
Especialista DevOps: será integrado por un experto que se encargará de transmitir la cultura
DevOps, concientizar y velar por que se ejecuten las técnicas de DevOps correctamente.
Una de las funciones del centro de excelencia es potenciar las metodologías de trabajo, el gobierno
de TI, la gestión de conocimiento y la gestión de tecnologías.
El centro de gobierno nos ayudara a:
Ahorrar tiempo:
El CdE puede lograr la potenciación del proceso de diseño y ejecución de proyectos; así como una
gestión más inteligente de los talentos que forman parte de la organización. Como resultado, los flujos
de trabajo se agilizan y se disminuye el tiempo de ejecución de tareas y alcance de objetivos. Además
de esto, el resultado final suele ser mayor que el de un proyecto que no ha sido Gestionado por un
CdE; lo que se traduce no solo en una mejora de los tiempos sino también en calidad.

221
Mejorar la comunicación:
Parte del trabajo del CdE es lograr una comunicación más fluida en la que se le dé impulso al trabajo
en equipo, la creatividad y la innovación. Gracias a que la información está centralizada, todos los
participantes de un proyecto pueden acceder fácilmente a cualquier dato que necesiten; y aportar
nuevas ideas independientemente del departamento al que pertenezcan o de su ubicación
geográfica.
La prevención:
El CdE canaliza las capacidades del equipo de trabajo y las experiencias profesionales y crea una
combinación sinérgica capaz de mejorar exponencialmente la forma en cómo se resuelven
problemas dentro de la organización. Como resultado, se crean mejores estrategias de prevención
y resiliencia ante incidentes; gracias a que los procesos y procedimientos se modifican de acuerdo
con el descubrimiento de nuevos conocimientos.
La automatización inteligente:
El uso de herramientas inteligentes juega un rol vital en el desempeño de cualquier organización. Es

por ello que elegir las soluciones que mejor se adapten a las necesidades del negocio; debe ser
siempre una prioridad. Sin embargo, elegir las aplicaciones que puedan ofrecer los mejores
resultados en cuanto al desempeño; puede convertirse muchas veces en un gran desafío. Por suerte,
el CdE puede enfocar sus conocimientos en medir el rendimiento de distintas herramientas para
determinar cuáles son las más adecuadas, según sus características; para ser implementadas en la
organización. Como consecuencia, el proceso de automatización se vuelve más inteligente; lo que
beneficia de forma general al negocio, pues se facilitan los procesos de trabajo.
2.2.3.1.1.2 Definición sistema de gobierno junto equipo agile

Se realizará un análisis del cliente y de las necesidades del proyecto para garantizar
un marco operativo de mínimos que irá evolucionando para cubrir todas las
necesidades del proyecto según se detectan en un proceso de refinamiento constante
durante toda la vida del proyecto.
Durante el periodo de implantación del departamento cross de DevOps se aplicarán
metodologías más cercanas al Kanban que irán evolucionando hacia un Scrum para
poder garantizar soporte a los equipos de desarrollo a la vez que realizan las tareas
propias del equipo de DevOps con los equipos de arquitectura y poder realizar mejoras
sobre la deuda técnica.
Los equipos de desarrollo tendrán reuniones periódicas con el DevOps de ese
microservicio para poder asesorar y peticiones sobre temas de automatización de
procesos (pipelines de CI/CD) además de reunirse con el equipo de arquitectura para

222
revisar los elementos arquitecturales, gestión de la configuración, automatización de
procesos.
Por ello el equipo de DevOps tendrá que priorizar las tareas y evitar bloqueos tanto a
los equipos de desarrollo como a las necesidades a nivel de arquitectura.
2.2.3.1.1.3 Generación de arquetipos y pipelines genéricos en colaboración con el equipo de

arquitectura
Para garantizar unas verificaciones y automatizaciones básicas para el inicio de los
proyectos garantizando un mínimo en la calidad y pruebas sobre los proyectos se
realizará una tarea inicial que sufrirá un mantenimiento durante todo el proyecto en el
que se definirán los arquetipos mínimos para el inicio del proyecto con las
dependencias decididas por el equipo de Arquitectura y unos pipelines jenkins con los
procesos mínimos de CI para disponer de ellos desde el inicio del primer proyecto y
poder detectar deficiencias lo antes posible en el proceso de desarrollo.
Una vez definidos estos pipelines de jenkins mínimos de CI se abordarán los del
proceso de CD.
Para completar esta tarea se decidirán las librerías iniciales disponibles para los
desarrollos y en caso de ser necesarias más durante este se indicará al equipo de
arquitectura verificando si es estable y segura y en caso positivo será añadida al
repositorio de artefactos para que pueda usarla el equipo de desarrollo.
2.2.3.1.1.4 Definición del Modelo de Colaboración (MVP1, MVP2)

En esta fase se establece los modelos de trabajo y colaboración entre los equipos
además de las estrategias de implantación y aprovisionamiento de los microservicios
del proyecto para garantizar su correcto desempeño.
Se implanta la estrategia de la orquestación de implantación de microservicios con

dentro de kubernetes la estrategia del Rolling Update para garantizar el balanceo del
tráfico de los pods antiguos a los nuevos creando pods de la nueva versión y
eliminando pods de la versión antigua hasta desplegar el número de pods nuevos
necesarios y quitando todos los antiguos como se muestra en la imagen inferior.

223
Ilustración 83: Definición del Modelo de Colaboración (MVP1, MVP2)
2.2.3.1.2 Etapa: Preparación de Ambientes

Se preparar todo lo que sea necesario para comenzar el desarrollo del sistema, ambientes de
desarrollo y pruebas, infraestructura, equipos de trabajo, herramientas para la gestión y seguimiento
de las tareas de desarrollo y pruebas bajo la metodología ágil y la capacitación del uso de ellas por
parte de todo el equipo de trabajo.
2.2.3.1.2.1 Ambientes de Desarrollo y Pruebas

2.2.3.1.2.1.1 Generación infraestructura como código del ecosistema de trabajo
Como se indica en el pliego, se selecciona la herramienta de orquestación de
infraestructuras Ansible. Con ella se procederá a la automatización del
aprovisionamiento de máquinas y servicios en el cloud indicado para el ecosistema del
CI/CD y componentes transversales. Antes del inicio del MVP1 se ejecutarán para
tener los ecosistemas creados para el equipo de desarrollo.
Las herramientas a instalar al inicio del proyecto serán las siguientes:
 Repositorio de Código y Control de Versión: Git y GitLab

 Análisis de Código: SonarQube
 Integración Continua: Jenkins se añadirán workers de jenkins para optimizar el
rendimiento que se aprovisionaran para las ejecuciones.
 Repositorios de artefactos y Docker Registry: Artifactory

224
 Test de seguridad: OWASP ZAP
2.2.3.1.2.1.2 Generación de infraestructura como código
Utilizando Ansible, se procederá a la automatización del aprovisionamiento de
máquinas y servicios en el cloud indicados y las maquinas necesarias para cada
entorno, en este punto se realizarán los scripts y se crearan únicamente los de los
entornos de desarrollo, pero se dejarán preparados para los entornos posteriores y así
poder ejecutarlos cuando sea necesario. Por otro lado, se automatiza la orquestación
de las máquinas para el aprovisionamiento de software que requiere una instalación
específica de algunas herramientas.
Se priorizarán los más necesarios para el equipo de desarrollo:
 Orquestación de Microservicios: Kubernetes (En caso de que el cloud

seleccionado lo aprovisione como servicio se propondrá usar dicho servicio al
SUNAT)
 Bases de Datos: MongoDB (Install with MongoDB Atlas)
 API Gateway: Kong
 Data Streamming: Kafka
 Monitoreo de Microservicios: Grafana y Prometheus
 Monitorización: Elasticsearch, Logstash, Beats y Kibana
Estas tareas se priorizarán para no bloquear a los equipos de desarrollo y podrán

aparecer más softwares necesarios u adaptaciones de los ya instalados para cuando
se instalan en entornos superiores según avance el desarrollo. Los desarrollos de
ansible serán idenpotentes para garantizar la ejecución completa de los playbooks sin
tener que hacer adaptaciones manuales en cada ejecución.
Implantación Desarrollo y pruebas

Se implantarán todos los entornos y servicios necesarios para los entornos de Desarrollo y
pruebas en los entornos del CONSORCIO para cubrir las necesidades iniciales de los
equipos de desarrollo. Estas necesidades evolucionarán según vaya avanzando el
desarrollo, se producirán cambios y por ellos ejecuciones de los playbooks de
aprovisionamiento.
2.2.3.1.2.1.3 Cronograma
2.2.3.1.2.1.4 Principales Hitos

Ver tabla de hitos en el Anexo 3

225
2.2.3.1.2.2 Instalación y Configuración de Ambientes de Preproducción y Producción
Esta etapa iniciará cuando LA SUNAT comunique la disponibilidad de los ambientes de pre-
Producción y producción.
Contempla la especificación de la configuración de los ambientes, dentro de los límites contratados

por LA SUNAT, específicamente:
- La configuración Inicial de servidores virtuales (procesador, memoria,

almacenamiento)
- Componentes tecnológicos (manejador de contenedores, bases de datos,
herramientas de data streaming, y todo lo que requiera la arquitectura).
- Configuración de los componentes, de seguridad y de red, subredes, firewalls, load
balancers, etc.
2.2.3.1.2.2.1 Adecuación de Playbooks para los entornos.

Se deberá actualizar los playbooks Ansible creados para los ambientes de desarrollo
y pruebas, se procederá a la automatización del aprovisionamiento de máquinas y
servicios en el cloud indicados y las maquinas necesarias para cada entorno.
Para ello se aprovisionará las siguientes plataformas:
 Orquestación de Microservicios: Kubernetes (En caso de que el cloud

seleccionado lo aprovisione como servicio se propondrá usar dicho servicio al
SUNAT)
 Bases de Datos: MongoDB (Install with MongoDB Atlas)
 API Gateway: Kong
 Data Streamming: Kafka
 Monitoreo de Microservicios: Grafana y Prometheus
 Monitorización: Elasticsearch, Logstash, Beats y Kibana
Los desarrollos de ansible serán idenpotentes para garantizar la ejecución completa

de los playbooks sin tener que hacer adaptaciones manuales en cada ejecución.
2.2.3.1.2.2.2 Instalación de componentes desarrollados.

También contempla el pase a producción de los componentes a los ambientes. Para ello se debe
ejecutar los siguientes planes:
2.2.3.1.2.2.2.1 Plan de RollBack

Para el roolback se realizará un flujo de contingencia en el que se indicara la versión
al a que se quiere volver sobre un pipeline de Jenkins en el que nos indicara las
versiones que tiene el Artifactory del contenedor a desplegar para el roolback. Antes

226
del despliegue de la versión en producción se realizarán pruebas sobre esa versión en
producción para garantizar la no regresión.
 Pruebas unitarias automáticas

 Validación código estático
 Generación de artefacto
 Pruebas integración sobre JUnit
 Arranque aplicación sobre contenedor
 Pruebas de integración/E2E (Selenium)
 Pruebas seguridad
 Cobertura de pruebas
 Despliegue en PreProduccion
Después de estas pruebas se realizará el despliegue en producción bajo la estrategia

Green/Blue que se indicó anteriormente para garantizar la no perdida de servicio y la
realización de pruebas de humo sobre el nuevo servicio para comprobar su correcto
despliegue.
2.2.3.1.2.2.2.2 Plan de puesta en Producción

Para el plan de la puesta en producción se indicará si es un despliegue inicial en el que
se desplegaran n micro servicios además de los servicios necesarios o despliegue de
microservicios por separado. Antes del despliegue de la versión en producción se
realizarán pruebas sobre esa versión en producción para garantizar la no regresión.
 Pruebas unitarias automáticas

 Validación código estático
 Generación de artefacto
 Pruebas integración sobre JUnit
 Arranque aplicación sobre contenedor
 Pruebas seguridad
 Cobertura de pruebas
Tendremos un pipeline de generación de infraestructuras, aprovisionamiento de

servicios necesarios e instalación de servicios. Este pipeline se realizará con ansible
con las configuraciones indicadas y reutilizando los playbooks usados en los entornos
anteriores pero adaptados al entorno de producción indicados en los inventories.

227
Además, configuración inicial del orquestador de contenedores kubernetes. Se
agregarán las configuraciones necesarias dentro del cónsul para los servicios
especificados. Al ser playbooksidenpotentes solo se realizarán los cambios
necesarios
Tendremos pipeline en el que se indicaran los microservicios y componentes front a

desplegar y se realizara el despliegue de cada uno de las imágenes dentro de
Artifactory con las configuraciones indicadas en los k8s files del entorno de
producción. Se añadirá un apartado donde se podrán indicar configuraciones
necesarias para cada microservicio y se instalarán dentro del cónsul. Si se despliega
un servicio ya desplegado con una versión diferente se seguirá la estrategia
Green/blue para garantizar la no pérdida de servicio y la realización de pruebas de
humo para comprobar un despliegue correcto.
2.2.3.1.2.2.3 Cronograma
2.2.3.1.2.2.4 Principales Hitos

2.2.3.1.3 Etapa: Desarrollo y Pruebas de los MPVs

El objetivo de esta etapa es la implementación del sistema de Cuenta Única de Contribuyente
cumpliendo los requerimientos funcionales y no funcionales exigidos, según el marco de
desarrollo Scrum. A continuación desarrollaremos las siguientes fases para el desarrollo del
MVP1 y MVP2.
2.2.3.1.3.1 Sprint 0
El Sprint 0 produce todo lo necesario para poder comenzar a trabajar con un enfoque ágil, comprende
6 semanas del proyecto, tendrá como objetivo la revisión y análisis de las historias de usuario del
MVP. Para ello se recabará información que permita entender el contexto global de proyecto, los
objetivos de negocio y las necesidades del usuario.
El Sprint 0 es una fase inicial del Proyecto, similar a la de un levantamiento inicial de requerimientos.
Durante el Sprint 0 se realiza el levantamiento de un backlog inicial el cual se define como un
conjunto de especificaciones que son extraídas de las historias de usuarios y la información obtenida
de Workshops. Supone un levantamiento de información, que permita conocer la problemática que
habrá de resolver la Solución.
Los workshop se realizaran con los especialistas funcionales de la SUNAT para lograr obtener el
mayor detalle y entendimiento posible de las historias de usuarios.

228
Con el levantamiento de información contenido en este backlog inicial, se realiza un diagrama de
dependencias.
El Diagrama de Dependencias define en que tecnología se desarrollará la solución, con que

artefactos y en que capas. En efecto dependiendo de la solución el Diagrama de Dependencias ha
de definir las capas correspondientes a dicha solución.
Una vez determinadas las capas del Diagrama de Dependencias y a medida que vaya progresando
el proyecto se incluirán en cada una de ellas los artefactos que se vayan diseñando, y la relación
entre ellos.
El diagrama de dependencia nos permitirá obtener de forma gráfica cuales son los componentes
tecnológicos que se desarrollaran posteriormente.
Los componentes que serán identificados en el diagrama de dependencia son los siguientes:
 Interfaces de usuarios.
 Reglas de negocio.
 Micro servicios.
 Tópicos Kafka.
 Apis.
 Colecciones de datos.
 Entre otros.
Las ventajas del Sprint 0 son las siguientes:
 Tener definidas algunas historias de usuario antes de comenzar el primer Sprint

 Implicar al Product Owner desde el principio para ir adaptando el roadmap a sus expectativas
 Cada Sprint se basará en este modelo previo, y por lo tanto no necesitará una planificación
previa muy extensa
 La estructura de nuestro proyecto nos dará las guías para trabajar
 Podremos adaptar en cualquier momento esta estructura ajustándonos a nuevos entornos
de trabajo

229
Planificación de Sprint 0
Para realizar esta tarea se dividirán equipos de trabajo por Historias de usuarios Épicas, y se seguirá
el siguiente cronograma:
Actividades S1 S2 S3 S4 S5 S6
Realización de Workshop
Diseño de diagrama de dependencia por Historias
Épicas
Unificación de diagramas de dependencia
revisión y validación final
Tabla 31: Planificación de Sprint 0
El objetivo último es obtener una visión clara de:
 Qué queremos implementar, en forma de Product Backlog y prototipos.

 Cómo lo queremos implementar, en forma de Arquitectura técnica.
 Y cuánto (tiempo) aproximadamente nos va a costar llegar a cada una de las posibles fases
principales de la implementación de la solución.
En este punto, tanto los responsables del negocio, como el equipo del proyecto han tenido tiempo de
trabajar juntos en un objetivo común, construir un lenguaje y unas herramientas de colaboración que
facilitan la comunicación y sirven para cimentar una relación de confianza entre quién ha de decidir
finalmente qué y con qué prioridad se debe implementar (el Product Owner) y quién está capacitado
para decidir cómo se implementa (el equipo Scrum) el producto.
Es sólo en este momento cuando estamos preparados para arrancar el proyecto desde una base
sólida.
2.2.3.1.3.2 Sprints 1 en adelante

Aplicable para el Sprint 1 en adelante y hasta la finalización del proyecto, se trabaja con las
bases obtenidas en el sprint 0 y todos los artefactos que gestiona el Centro de Excelencia.
Cada sprint se ejecutará una iteración de cuatro semanas, para el cual el Scrum Master
facilitará al Equipo Scrum a superar impedimentos durante su proceso de creación de
entregables. Durante este tiempo, el equipo trabaja para convertir las necesidades del backlog
de las historias de usuario al backlog del sprint. Para obtener los máximos beneficios de un
proyecto Scrum se debe mantener las cuatro semanas.
El equipo tendrá una reunión de 15 minutos para practicar el principio de transaparencia, el

cual responderán las tres preguntas:

230
 ¿Qué hice desde la última reunión?
 ¿Qué realizaré el día de hoy?
 ¿Qué impedimentos tengo en la actualidad?
2.2.3.1.3.2.1 Reunión de planificación del sprint

Esta reunión tendrá una duración de 8 horas para cada Sprint y se ejecutará realizará lo
siguiente:
El Product Owner asignará las historias de usuario según el diagrama de depencias a su

respectivo Equipo Scrum.
El Product Owner explica las historias de usuario asignadas al Equipo Scrum.
Equipo Scrum se compromete con las historias de usuario.
Debido que cada historia ya se encuentra identificada a nivel de dependencia, el Equipo Scrum
se encargará de descomponerlo en tareas para crear el Sprint Backlog.
El Equipo Scrum debe estimar las tareas identificadas para cumplir con el alcance de Sprint.
2.2.3.1.3.2.2 Implementación del sprint
Ilustración 84: Implementación del sprint
El proceso de implementación se lo ejecutarán los Equipos Scrum(equipos de desarrollo) para

lo cual seguirán el siguiente proceso:

231
 El Scrum Master facilitará la creación de los repositorios de versionamiento Gitlab para
el componente.
 El Scrum Master facilitará la creación de los pipelines para la integración continua para
el componente.
 El desarrollador, que ya tiene su tarea asignada, realizará un proceso de análisis y
diseño del componente. Realizará un refinamiento para retroalimentar el diagrama de
dependencias.
 El desarrollador iniciará la implementación teniendo en consideración que dentro del
equipo existirá un especialista funcional, que se encargue de resolver dudas asociadas
a la historia de usuario.
 Como insumo, el desarrollador tendrá disponible los prototipos o pantallas, en caso que
implique desarrollar la parte frontend.
 El desarrollador podrá ejecutar sus tareas asignadas, que están el el Backlog del Sprint
ayudándose de las historias de usuario a la que pertenece y al diagrama de
dependencias.
 Si el equipo de desarrollo no puede resolver algunas interrogantes funcionales, podrá
apoyarse del Product Owner para la aclaración.
 El desarrollador debe implementar las pruebas unitarias de los componentes.
 Se ejecutará la integración continua para validar que el código compila y que las
funcionalidades implementadas cumplen mediante la compilación y ejecución de
pruebas automáticas.
 Se ejecutará el despliegue continuo de los componentes a los ambientes de desarrollo.
 En el equipo existirá un especialista QA, que se encargará de realizar la validación de
los criterios de aceptación una vez que las tareas asociadas a una historia de usuario es
completada.
Consideraciones para pruebas:
Después que el desarrollador haya ejecutado las pruebas en su ambiente local (PC),
posteriormente se realizará el ambiente de desarrollo.
Tal como indicamos, tendremos un pipeline en el que se indicaran los microservicios
y componentes front a desplegar y se realizara el despliegue de cada uno de las
imágenes dentro de Artifactory con las configuraciones indicadas en los k8s files del
entorno de desarrollo. Se añadirá un apartado donde se podrán indicar configuraciones
necesarias para cada microservicio y se instalarán dentro del cónsul.
Las actividades implicadas en el despliegue son las siguientes:

232
- Pruebas unitarias automáticas
- Validación código estático
- Generación de artefacto
- Pruebas integración sobre JUnit
- Arranque aplicación sobre contenedor
- Pruebas de integración/E2E (Selenium)
- Pruebas seguridad
- Cobertura de pruebas
- Despliegue en desarrollo.
2.2.3.1.3.2.3 Revisión del sprint

La reunión de del sprint tendrá una duración de cuatro horas, el cual el Equipo Scrum
demostrará la implementación al Produc Owner para que apruebe los criterios de aceptación
descritos en las historias de usuario.
2.2.3.1.3.2.4 Retrospectiva del sprint

Reunión de retrospectiva tendrá una duración de cuatro horas. Durante esta reunión, el Equipo
Scrum se reúne para revisar y reflexionar sobre el sprint anterior en relación a los procesos
que se siguieron, las herramientas empleadas, la colaboración y los mecanismos de
comunicación, así como otros aspectos de interés para el proyecto.
Ver Cronograma detallado en el Anexo 1
a) Informe de Puesta en producción del MVP1
b) Informe de Puesta en producción del MVP2
c) Todas las documentaciones requeridas para los Releases
2.2.4 Migración de los ambientes de desarrollo y pruebas
El objetivo de esta etapa es preparar los ambientes de desarrollo y pruebas para LA SUNAT, con el
fin de que esta pueda continuar con el desarrollo evolutivo del sistema en sus propios ambientes.

233
2.2.4.1.1 Instalación y Configuración
En esta etapa se entregarán la especificación de la arquitectura y lineamientos de infraestructura
base a LA SUNAT para los ambientes de desarrollo y pruebas de LA SUNAT. Esto implica
especificar la configuración de los ambientes necesarios, dentro de los límites contratados por
LA SUNAT, indicando:
- Configuración Inicial de servidores virtuales (procesador, memoria, almacenamiento);

- Componentes tecnológicos (manejador de contenedores, bases de datos, herramientas
de data streaming, y todo lo que requiera la arquitectura);
- Configuración de los componentes, de seguridad y de red, subredes, firewalls, load
balancers, etc.;

Ver tabla de hitos en el anexo 3
2.2.4.1.2 Migración de los Ambientes de Desarrollo y Prueba
Se realizarán las tareas de mantenimiento sobre las infraestructuras y servicios sobre los
playbooks que se ejecutaran en los entornos previos para testearlos y cuando se requiera
progresaran por los entornos hasta producción. Se realizará la migración de los entornos
de desarrollo y pruebas a él cloud de la Sunat para disponer de ellos al finalizar del periodo
de desarrollo y con ello se eliminará la infraestructura de cloud del CONSORCIO.

Ver tabla de hitos en el anexo 3
2.2.5 Fase de Capacitación y Transferencia de Conocimientos
El objetivo principal de esta Fase es realizar las capacitaciones sobre el uso, administración y
operación de cada MVP desarrollado. La capacitación debe realizarse por cada épica entregada
previa a la puesta en producción de cada MVP.

234
2.2.5.1.1 Capacitación a Técnicos y Funcionarios de LA SUNAT
Conforme a la revisión de los documentos de referencia (Convocatoria), se han establecido las
siguientes consideraciones necesarias para la capacitación y Transferencia, existirán 03 tipos
de capacitaciones:
 Capacitar a los técnicos de LA SUNAT en los aspectos técnicos del sistema con
todos los elementos necesarios para su correcta operación y evolución.
 Capacitación funcional a funcionarios de LA SUNAT.
 Capacitación y Transferencia de Conocimiento.
2.2.5.1.1.1 Principales Procesos de la Capacitación

 Requerir a LA SUNAT, el listado de participantes de acuerdo al perfil de requisitos
del participante definido.
 Proveer los recursos y materiales a los participantes del curso del Plan de
Capacitación.
 Asegurar que la sala de capacitación se encuentre disponible, operativo y esté
conforme a los requisitos técnicos del curso programado.
 Realizar el dictado de los cursos del Plan de Capacitación.
 Realizar la evaluación de resultados de las evaluaciones teórica y práctica y
elaborar el informe de capacitación del curso.
 Realizar seguimiento y control al Plan de Capacitación.
Ilustración 85: Implementación del sprint

235
Procesos para la Capacitación
2.2.5.1.1.2 Organización del Equipo de Capacitación

A continuación se describe el organigrama del Equipo de Capacitación, quienes en conjunto
serán responsables de la elaboración, ejecución, evaluación, seguimiento y cierre de las
actividades correspondientes al Plan de Capacitación.
OFICINA DE TTC
RESPONSABLE DE
LA OFICINA DE
TTC
INSTRUCTORES ANALISTA TTC
Ilustración 86: Organización del Equipo de Capacitación
Organigrama del Equipo Responsable del Plan de Capacitación
A continuación se describe los roles del personal del equipo de Capacitación:
Responsable de la Identificación de
necesidades, Planeación, Ejecución, y
Evaluación de los cursos correspondientes al
Responsable de la Oficina
Plan de Capacitación que permita los
de TTC colaboradores de LA SUNAT, la capacitación
en las herramientas y soluciones técnicas que
se generen en el marco de ejecución del
proyecto.
Realizar las actividades relacionadas a la

identificación de necesidades, planificación,
Analista de TTC
ejecución y evaluación de los cursos del Plan
de Capacitación.

236
Equipo de facilitadores internos y externos

Instructores responsables del dictado de los cursos del Plan
de Capacitación.
Tabla 32: Equipo Responsable del Plan de Capacitación
2.2.5.1.1.3 Listado de Cursos Técnicos Presenciales y a Distancia

A continuación, se detalla los cursos que han sido definidos como necesarios de brindar a los
colaboradores de LA SUNAT.
Capacitar a los técnicos de LA SUNAT en los aspectos técnicos del sistema con todos
los elementos necesarios para su correcta operación y evolución.
Se realizará una capacitación sobre el uso, administración y operación de cada MVP

desarrollado. La capacitación debe realizarse por cada épica entregada previo a la puesta en
producción de cada MVP.
N° TEMAS *
1 API Gateway Kong
2 Orquestación de Microservicios Kubernetes
3 Data Streamming Kafka
4 Monitoreo de Microservicios Prometheus y Grafana
5 Framework de Desarrollo SpringBoot + ReactiveX
6 Lenguaje de Programación Java8
7 Repositorio de Código y Control de Versión Git + GitLab
8 Análisis de Código SonarQube
9 Plataforma de Container Docker
10 Integración Continua Jenkins

237
N° TEMAS *
11 Configuraciones de Aplicación Consul
12 Bases de Datos NoSQL propietario del CSP
13 Arquitectura Propuesta de Datos Datos/Aplicación
14 Dimensionamiento de Componentes Hardware/Software
15 Gestión de Seguridad de Usuarios y Roles
16 Modelo Ágil
17 Modelo DevOps
Tabla 33: Listado de Cursos Técnicos Presenciales y a Distancia
Las capacitaciones serán ejecutadas después de finalizar cada MVP y varios temas
podrán ser dictados en un solo curso.
2.2.5.1.1.4 Listado de Cursos Funcionales Presenciales y a Distancia

Se realizará capacitaciones orientadas al usuario final. Estas capacitaciones se brindarán a un
grupo de hasta 100 funcionarios. Este grupo debe ser previamente designado por LA SUNAT
y comunicado por el CONSORCIO. La capacitación debe realizarse por cada épica que
corresponda en la cantidad total de participantes designados previo a la puesta en producción
de cada MVP.
MVP Descripción Cursos
MVP1 Provee el soporte EP002 - Suspensión

para las operaciones
EP003 - Ajustes
de Recaudación de
la SUNAT, que EP004 - Comunicación de diferencias
comprenden el
mayor flujo EP007 - Veredicto de rectificatoria
transaccional de la
EP009 - Aplicar documento en cuenta única
Cuenta Única a partir
de los formularios de EP012 - Correcciones de cuenta única
Declaración

238
MVP Descripción Cursos
Jurada, Pagos y EP013 - Consultas de Cuenta Única

Comprobantes
EP015 - Formularios y Documentos de CU
Electrónicos.
EP021 - Presentar declaración jurada
EP026 - Registrar órdenes de pago – parte 1
EP027 - Registrar comprobantes electrónicos
EP028 - Recepción de pagos
EP040 – Registro manual de valores
EP045 – Fraccionamiento – parte 1
EP098 – Funcionalidades compartidas
EP053 – Efectos de legados en Cuenta Única (*)
MVP2 Incorpora los EP001 – Compensaciones

procesos y trámites
EP005 - Reconocimiento de pago con error
relacionados con la
recaudación, así EP006 - Modificación de datos
como la
determinación y EP008 - Devoluciones (Pagos Indebidos, Exceso)
control de las
EP012 - Correcciones de cuenta única
infracciones.
EP014 - Reimputación de ingreso como recaudación
(Detracciones)
EP037 – Infracciones
EP041 - Créditos con posible prescripción
Tabla 34: Listado de Cursos Funcionales Presenciales y a Distancia

239
2.2.5.1.1.5 Aprendizaje a Distancia
Esta técnica implica hacer el uso de una plataforma de e-Learning o educación a distancia.
Promoviendo el auto capacitación para el desarrollo profesional cualquiera sea su ámbito
laboral.
Para lo cual se utilizará una plataforma e-learning, plataforma educativa web que integra un
conjunto de herramientas para la enseñanza-aprendizaje en línea, permitiendo una enseñanza
no presencial e-learning, donde se combina la enseñanza en Internet con experiencias en la
clase presencial.
El objetivo primordial de una plataforma e-learning es permitir la creación y gestión de los

espacios de enseñanza y aprendizaje en Internet, donde los profesores y los alumnos puedan
interaccionar durante su proceso de formación. Un espacio de enseñanza y aprendizaje (EA).
Funcionalidad.- El conjunto de herramientas permitirá realizar cinco funciones principales: (i)

la administración de la plataforma; (ii) la comunicación de los participantes; (iii) la gestión de
contenidos; (iv) la gestión del trabajo en grupos, y (v) las evaluaciones.
(i) Administración. Permitirá la gestión de los usuarios: como altas, modificaciones, borrado,
gestión de la lista de clase, la definición de roles y el control y seguimiento del acceso de los
usuarios.
(ii) Comunicación. Las herramientas de comunicación permiten la interacción entre

profesores y alumnos. Puede ser asíncrona20 con el correo electrónico, los foros, el calendario
y los avisos; o síncrona, con las charlas (chats) o la pizarra electrónica. Estas herramientas
permiten todos los sentidos de interacción: del profesor hacia alumnos, de los alumnos hacia
profesor, de alumno con alumnos, alumnos entre sí, o todos con todos.
(iii) Gestión de contenidos. Para la gestión de contenidos dispondremos de un sistema de

almacenamiento y gestión de archivos que permitirá realizar operaciones básicas sobre ellos,
como visualizarlos, organizarlos en carpetas (directorios) y subcarpetas, copiar, pegar,
eliminar, comprimir, descargar o cargar archivos a la plataforma.
(iv) Gestión de grupos. Estas herramientas permitirán realizar las operaciones de alta,
modificación o borrado de grupos de alumnos y la creación de “escenarios virtuales” para el
trabajo cooperativo de los miembros de un grupo.
(v) Evaluación y Emisión de Certificados. Las herramientas para la evaluación permiten la

creación, edición y realización de ciertos tipos de tests, luego de ser calificado y obtener una
nota aprobatoria, el sistema emitirá automáticamente una certificado.

240
Estructura de la Plataforma de Enseñanza a Distancia:
A continuación mostramos un ejemplo que como se estructuraría la plataforma para los

alumnos, siendo esta muy intuitiva y fácil de usar.
Ilustración 87: Estructura de la Plataforma de Enseñanza a Distancia
Material para la plataforma de Aprendizaje a Distancia:
La información que necesitamos para la plataforma e-learning será:
- Material: El la creación de los silabus y ppt de la clase a dictar.

- Videos: La creación de videos multimedia utilizando la herramienta Camtasia o similar;
este software permite capturar, editar y generar videos en formatos de calidad y
comprimidos.
- Test de Evaluación: De desarrollada la lista de preguntas las cuales serán ingresadas
a la plataforma para evaluar a los estudiantes.


241
2.2.6 Fase de Mantenimiento Correctivo y Soporte
Esta fase comenzará a partir del día siguiente de la conformidad de LA SUNAT a la instalación en
producción del MVP1 y finalizará 90 días calendario a partir del día siguiente de la conformidad de
LA SUNAT a la instalación en producción del MVP2.
Se entregarán informes mensuales detallados que incluyen los siguientes elementos:
● Lista de incidentes atendidos durante el mes detallando en casa caso: un análisis del
incidente, tiempos empleados en su solución, el detalle de la solución y acciones que se
tomaron para evitar un nuevo incidente de esta naturaleza.
● Disponibilidad: tiempo de disponibilidad del sistema en línea. En casos de no disponibilidad
se detallará los tiempos y motivos de la ocurrencia. Así como las acciones tomadas para que
la situación no se repita cuando las causas involucren a los entregables del proyecto o a las
acciones propuestas, si las tuviera, cuando las causas no lo involucren.
Como se ha explicado previamente, es necesario establecer un plan de incorporación de recursos al

equipo de mantenimiento correctivo. Es esencial que el plan de incorporación de recursos tenga en
cuenta las particularidades del Servicio de desarrollo, pruebas y puesta en producción del Sistema
de Cuenta Única de Contribuyente.
En base a la información proporcionada por la SUNAT y nuestra experiencia en servicios similares,
hemos diseñado un plan de trabajo a alto nivel que gira alrededor de dos máximas:
El equipo de mantenimiento
Óptimo correctivo irá creciendo a medida
dimensionamiento que se pongan en producción los
de los equipos distintos MVP
Parte de los recursos que se
Transferencia de hayan dedicado al desarrollo,
conocimiento pruebas y puesta en producción
entre equipos de cada MVP se incorporarán al

equipo de mantenimiento
Como se puede ver en el siguiente esquema, el equipo de mantenimiento correctivo se irá

incorporando al servicio a medida que se vayan poniendo en producción los diferentes MVPs.
Adicionalmente y para dotar al equipo de mantenimiento correctivo del mayor conocimiento sobre el
Sistema de Cuenta Única, parte del equipo de desarrollo se incorporará posteriormente al equipo de
mantenimiento.

242
Mejoras o cambios por modificaciones normativas
En casos de que surjan cambios normativos que impliquen realizar cambios y/o mejoras en el sistema
durante la etapa de garantía, Indra se compromete a resolverlo. Para ello, se analizará junto a la
SUNAT las historias de usuario impactadas, y se cambiarán de común acuerdo para cumplir con el
cambio normativo. A continuación se muestra el diagrama de flujo según el que se tratarán estas
peticiones:
Crear petición
Identificar Historia(s)
de Usuario a modificar
¿Ha sido puesta

en producción?
Registrar petición Si Añadir a Backlog
en JIRA de evolutivo
No Si
Estimar esfuerzo Actualizar Backlog Cerrar incidencia
requerido en desarrollo en JIRA
No
Ilustración 88: Diagrama de Flujo
Indicador de Atención de Incidentes
La tabla siguiente define los tiempos máximos esperados para las actividades de atención de
incidentes, los valores están expresados en horas y días calendario.
Tipo de
Nivel Descripción Tiempo máximo de resolución
Severidad
Hasta 4 (cuatro) horas, contadas a

Fallas del sistema que perjudiquen el
partir del momento en el que se
1 Grave procesamiento o impidan la prestación
comunica el incidente, en horario
normal del servicio.
7x24
Problemas en funcionalidades y / o Hasta 3 (tres) días, contadas a

procesos que no afecten la prestación partir del momento en el que se
2 Medio
normal del servicio, pero que afecten el comunica el incidente, en horario
estándar de calidad de este. 7x24
Hasta 7 (siete) días, contadas a

Fallas de menor importancia que no
partir del momento en el que se
3 Leve afecten el procesamiento, ni la
comunica el incidente, en horario
prestación del servicio.
7x24
Tabla 35: Atención de Incidentes

243
2.2.6.1.1 Mantenimiento Correctivo

Se refiere a corregir los incidentes o errores presentados durante el uso en producción del
sistema. Los incidentes detectados deben ser tratados a través de los medios y canales
establecidos.
Plan de acción para resolver un incidente
N° Actividad Tarea Comentario Tiempo

Si el caso se recibe por
Service Desk se
Recibir los casos de los a través direcciona a la actividad 2.
Recibir de los siguientes medios: Si es por atención
1 2 Minutos
Caso - Atención telefónica telefónica se registra en la
- Service Desk herramienta, se le informa
al usuario y pasa a la
actividad 2.
Realizar la evaluación y la
Asegurar que la categoría
Categorizar asignación de una categoría de
2 del incidente corresponde 10 Minutos
el Incidente acuerdo a la gravedad. (Grave,
con la realidad del mismo.
Medio y Leve)
Tarea 1: Acordar y asignar una
prioridad adecuada, que
permitirá determinar cómo se
Si no puede ser
manejará el incidente y el
solucionado por la Mesa
personal de soporte.
de ayuda se escala a los
Profesionales con
Priorizar el Tarea 2: La prioridad
3 Funciones en Sistemas, 10 Minutos
incidente normalmente se puede
pasar a la actividad 4.
determinar teniendo en cuenta
Si puede solucionar, se
tanto la urgencia del incidente
inicia el proceso de
(la rapidez con la que el negocio
solución.
necesita una resolución), y el
nivel de impacto que está
causando.

244
N° Actividad Tarea Comentario Tiempo
Definir si la solución es
definitiva o temporal.
Identificar y analizar la causa Si la solución es temporal
raíz del incidente con el fin de la solución definitiva se
Entre 10
dar la solución, en caso de que implementará en el plazo
Resolver minutos y las
4 el incidente no se pueda establecido en el
incidente horas según
resolver, se buscara una documento de Niveles de
SLA
solución temporal que permita, escalamiento de atención
la recuperación parcial o total. de incidentes.
Si es total pasar a la
actividad 5
Nivel 1:
Tiempo de
Nivel 1: Realizar un informe entrega hasta
detallado de la emergencia, las un (01) día
medidas correctivas tomadas y después del
las acciones preventivas Restablecimien
recomendadas. Asegurar la to del servicio.
5 Documentar documentación de la
Nivel 2 y 3: Busca que las solución. Nivel 2 y
acciones tomadas durante la 3:Tiempo de
incidencia sean reportadas entrega hasta
formalmente luego de aplicada un (01) día
la solución. después de
terminada la
atención.
Tabla 36: Plan de acción para resolver un incidente
2.2.6.1.2 Soporte y Operación

El acceso al servicio de soporte ocurrirá través de los siguientes canales de comunicación:
● Service Desk: Herramienta web, disponible en tiempo 24x7, en español, que permitirá la
creación, acompañamiento y actualización de los “tickets de soporte”.
● Atención Telefónica: Disponible en tiempo 24x7, a través de profesional(es) calificado(s)
para la atención oportuna y en idioma español. El objetivo de este canal es soportar la

245
apertura de tickets de soporte que pueden ser acompañados/actualizados a través del canal
de Service Desk.
● Correo Electrónico: Empleado para intercambio de información entre los profesionales
involucrados en los procesos de atención, realizando el registro del contenido en Service
Desk, cuando corresponda.
● Reuniones: Presenciales o virtuales, pueden ser convocadas por LA SUNAT o LA FIRMA
CONSULTORA, deben ser coordinadas oportunamente para contar con la participación del
personal requerido.
Mensualmente, se elaborarán informes con las actividades de soporte, identificando la cronología

de actividades y el estatus de los tickets de soporte.
2.2.6.1.3 Cronograma
2.2.6.1.4 Principales Hitos

2.2.7 Prestación Accesoria: Mantenimiento Evolutivo
Al día siguiente de obtenida la conformidad del Plan de Gestión del Proyecto, se podrá activar el
Mantenimiento Evolutivo que se extenderá hasta 1 mes antes de terminar la fase de Mantenimiento
Correctivo y Soporte.
A pesar de no disponer de una línea base de carga de trabajo asegurada para el mantenimiento
evolutivo, se podrá preveer hasta cierto punto el esfuerzo necesario para esta tarea. En esta línea,
se estima a priori que el volumen de carga de trabajo irá aumentando a medida que se vayan
poniendo en producción los MVP. Por ello, se ha diseñado un plan de trabajo a alto nivel orientado a
gestionar el volumen del equipo dedicado al mantenimiento evolutivo del Sistema de Cuenta Única,
basado en el aumento progresivo de carga de trabajo.
La propuesta de implantación es una combinación de formación, y transferencia de conocimiento

que se articulará a través de la Oficina de Gestión del Servicio de Indra, siendo responsable de este
proceso. La implantación se estructura en las siguientes fases:
 Análisis y planificación: Se elaborará un plan de implantación detallado, identificando

actividades, equipos y responsables.
 Formación: Se realizará formación sobre los procedimientos ágiles, a los implicados por la
creación de un nuevo equipo. La formación se orientará a los responsables del Sistema de
Cuenta Única de la SUNAT (Product Owner), a los usuarios clave de la SUNAT y también al

246
propio equipo de desarrollo. La formación se particularizará en función de las necesidades de
las áreas implicadas, que habrán sido identificadas en la fase de análisis y planificación.
 Creación de nuevos equipos: se forman nuevos equipos con integrantes experimentados de

los equipos ya exixtentes y se abordan nuevos proyectos, expandiendo así el conocimiento de
la metodología. La correcta implantación de la metodología tiene que seguir siendo un objetivo
de estos proyectos y, por lo tanto, se tiene que monitorizar y cuantificar a través de métricas
de los procesos ágiles.
 Prestación: una vez incorporado un nuevo equipo, los equipos trabajarán normalmente con la
metodología ya implantada y se realizará el seguimiento mediante los ANS establecidos.
Gestión
Equipo 2 Equipo 3
Equipo 1
Equipo actual Incorporación de

nuevos equipos
Ilustración 89: Prestación
A lo largo de todo el servicio se utilizará el conocimiento generado durante la fase de desarrollo,

pruebas y puesta en producción de los MVP. De esta forma se agilizará la formación de los nuevos
equipos y se mejorará tanto la eficiencia como la calidad de los trabajos entregados
Para poder cumplir con el mantenimiento evolutivo se utilizará el modelo de fábrica para poder
abordar y atender todos los requerimientos ajustándose a el.
Si en la epata de prestación accesoria no se haya consumido las bosa de horas, se inforará a la

entidad que no existieron evolutivos.
A continuación, se presenta el modelo de Fábrica ofertado.
2.2.7.1.1 Servicio de Fábrica de Integración

Como parte del servicio, el servicio de Fábrica de SW incluye el poder trabajar modelos iterativos,
basado en metodologías ágiles con el objetivo de poder cumplir con los diferentes proyectos o
iniciativas de tecnología para poder cumplir con los objetivos del negocio. Es con este fin, que el
modelo comprende las siguientes partes:

247
Planificación
Levantamiento Diseño
SWF
Producción Implementación
Pruebas
Ilustración 90: Servicio de Fábrica de Integración
Levantamiento: El levantamiento de requerimientos se refiere a la identificación de las

necesidades de negocio enfocadas en un sistema, proyecto o iniciativa, ya sea a partir de los
usuarios, clientes o interesados. Para esto se aplican diferentes técnicas que están asociadas al
levantamiento y descubrimiento, tanto de necesidades como de los componentes tecnológicos
asociados. Dichas técnicas pueden ser las siguientes, según corresponda:
 Análisis de Documentación
 Análisis de Código fuente
 Entrevistas con el usuario
 Mesas de trabajo
 Historias de Usuario
Dentro del método de trabajo utilizado, el método estandarizado son las historias de usuario.
Además, se identificará y definirá en conjunto con LA SUNAT las actividades necesarias para
poder incluir los componentes necesarios a construir dentro de las herramientas de DevOps, con
el fin de apoyar incrementalmente a poder tener una automatización asociada al despliegue y
desarrollo continuo. (CI/CD)
Planificación: En esta etapa, dependiendo de diferentes factores asociados al proyecto y/o

iniciativa, se planificarán los esfuerzos, mesas de trabajo necesarios para poder cumplir con la

248
necesidad. También se determinará el equipo que estará dedicado para cada una de las
siguientes etapas del método evolutivo propuesto, hasta ver el proyecto funcionando en
Producción y se preparará los insumos necesarios para poder hacer el kickoff del proyecto, tanto
para TI como para el negocio. Esta misma etapa es la que lleva el control del backlog de
actividades y el plan de iteraciones asociadas al proyecto y su cumplimiento por parte del equipo
de trabajo asignado.
Diseño: En esta etapa se hace la definición técnica de los diferentes artefactos y componentes
identificados en la etapa de Levantamiento, para lo cual se estará utilizando diferentes artefactos
para poder apoyar la definición y presentación de la solución técnica. Dentro de estos artefactos
estarán los siguientes, según corresponda:
 Arquitectura Tecnológica
 Especificaciones técnicas de cada componente
 Contrato detallado de los componentes
Además, se incluirá el diseño de los diferentes pipelines necesarios para poder integrar estos
componentes definidos a la herramienta de DevOps que sea definida por La Secretaría de
Gobierno Digital, para así ir subiendo incrementalmente las diferentes soluciones a dicha
plataforma.
Implementación: En esta etapa se encuentra la construcción del código fuente en las diferentes
tecnologías necesarias con el fin de poder dar soporte a las necesidades técnicas y/o de negocio
que desea implementar LA SUNAT. También estará la configuración del pipeline para DevOps
en la herramienta definida por LA SUNAT, en el caso que no exista, con el fin de ir subiendo
incrementalmente las diferentes soluciones a dicha plataforma.
También se utilizarán herramientas de ofuscación de código con el fin de poder proteger el código
fuente de cualquier mal uso y poder reducir el tamaño de los despliegues. Las herramientas para
utilizar estarán alineadas con OWASP.
Pruebas: En esta etapa, dependiendo de la definición que se realizará en conjunto con La

Secretaría de Gobierno Digital para cada uno de los proyectos se efectuará lossiguientes:
 Estrategia DevOps para el proyecto en ejecución: Si la estrategia de DevOps está incluida

dentro del alcance del proyecto que se esté ejecutando, pueden existir 2 posibilidades,
ya existen los pipelines de aprobación hasta su despliegue en Producción o no existen.
En el caso que no existan, se definirán los sets de datos y los scripts necesarios para la
ejecución de pruebas automatizadas de dicho componente y se apoyará la configuración

249
de dicho pipeline, con el fin de que pueda ser utilizado mas adelante en futuras
modificaciones al componente. En el caso en que el pipeline ya exista, se alimentará de
los datos actualizados para poder ejecutarlas pruebas y supervisar los resultados, con el
fin de asegurar un desarrollo de calidad y ágil. Esto puede aplicar para el proyecto o para
algún componente del proyecto.
 Sin estrategia DevOps para el proyecto en ejecución: Si se define en conjunto con LA
SUNAT que para este proyecto o para algún componente de este no se va a aplicar la
estrategia de DevOps, se ejecutarán las pruebas unitarias (UT), las pruebas de
integración (SIT), y se dará soporte a las pruebas de aseguramiento de calidad (QA) y de
aceptación de Usuario. Para las pruebas UT y SIT se entregarán evidencias por cada
uno de los componentes, según corresponda.
Por último, se elaborarán los documentos que sean necesarios para la ejecución de los pases
entre ambientes, según corresponda, ya sea para cada uno de los componentes o si se ha
definido el uso de la estrategia de DevOps. Además, se utilizan herramientas para poder
determinar los siguientes puntos:
 Vulnerabilidades en código fuente basadas en OWASP: SonarQube

 Pruebas de Carga: SOAPUI, LOADUI
 Automatización de pruebas de interfaz: Selenium WebDriver
Producción: Indistintamente si el proyecto se ejecuta con una estrategia de DevOps o no, en

esta etapa se realizará el acompañamiento del despliegue de la solución a Producción. Además,
se apoyará en la resolución de ciertos casos de uso que se puedan determinar solamente en
producción, con el fin de poder asegurar que la solución cumpla con todos los requisitos y con el
aseguramiento de estos por la cual fue concebida. Además, se incluirá un acompañamiento post
producción para su etapa de marcha blanca, la cual se definirá en conjunto con LA SUNAT,
dependiendo de la envergadura, complejidad y criticidad del proyecto.
Intrínsecamente, estará la atención de defectos asociados a Garantía como parte de nuestro

servicio de Calidad.
2.2.7.1.2 Cronograma
2.2.7.1.3 Principales Hitos


250
2.2.8 Entregables y Criterios de Aceptación
2.2.8.1 Entregables
Id Fase Entregable Plazo máximo (en días calendario)

Plan de Gestión del 30 días calendario a partir del día siguiente al
E1 Gestión
Proyecto inicio del servicio
Informe de preparación de
Desarrollo, Pruebas y 60 días calendario a partir del día siguiente al
E2 ambientes de Desarrollo y
Puesta en Producción inicio del servicio
Pruebas
Dentro de los 270 días calendario, a partir del
Informe de implementación día siguiente de la conformidad del E1, las
Desarrollo, Pruebas y
E3 del Release 1 y creación de fechas se determinarán de común acuerdo
Puesta en Producción
ambiente de pre-producción entre las partes. Deberá estar definido en el
Plan de Gestión del Proyecto.
Informe de Puesta en
día siguiente de la conformidad del E1, las
Desarrollo, Pruebas y producción del MVP1 y
E4 fechas se determinarán de común acuerdo
Puesta en Producción creación de ambiente de
entre las partes. Deberá estar definido en el
producción
Informe de carga inicial de
E5 Carga Inicial de Datos fechas se determinarán de común acuerdo
datos del MVP1
Desarrollo, Pruebas y Informe de implementación
E6 fechas se determinarán de común acuerdo
Puesta en Producción del Release 4
450 días calendario a partir del día siguiente
a la conformidad del E1, las fechas se
Desarrollo, Pruebas y Informe de Puesta en
E7 determinarán de común acuerdo entre las
Puesta en Producción producción del MVP2
partes. Deberá estar definido en el Plan de
Gestión del Proyecto.
Informe de carga inicial de
E8 Carga Inicial de Datos día siguiente de la conformidad del E1, las
datos del MVP2
fechas se determinarán de común acuerdo

251
Id Fase Entregable Plazo máximo (en días calendario)
Migración de Informe de Migración de los día siguiente de la conformidad del E7, las
E9 ambientes de ambientes de Desarrollo y fechas se determinarán de común acuerdo
Desarrollo y Pruebas Pruebas entre las partes. Deberá estar definido en el
día siguiente de la conformidad del
Capacitación y Informe de Capacitación y
entregable E4. Las fechas se determinarán
E10 Transferencia de Transferencia de
de común acuerdo entre las partes. Deberá
Conocimientos Conocimientos
estar definido en el Plan de Gestión del
Proyecto.
Informe mensual de Cada 30 días calendario a partir del día
Mantenimiento Mantenimiento Correctivo siguiente de la conformidad del E4, por un
E11
correctivo y Soporte Informe mensual de Soporte plazo máximo de 90 días calendario después
y Operación de la conformidad de E7.
A los 30 días calendario a partir del día
siguiente de la presentación del último
E12 Cierre del proyecto Informe final del Proyecto
informe mensual de Mantenimiento
Correctivo y Soporte (E11).
Tabla 37: Entregables
2.2.8.2 Criterios de Aceptación
A continuación se detallan los criterios de aceptación en cada uno de los entregables:
 E1 – Plan de Gestión del Proyecto
Entregable: Plan de Gestión del proyecto:
 Versión digital en Word.

 Versión impresa con dos copias digitales.
Criterios de Aceptación: Revisión del cumplimiento de los aspectos señalados en el punto

7.2.1 “Fase de Gestión”

252
 E2 – Informe de preparación de ambientes de Desarrollo y Pruebas
Entregable: Informe de preparación de ambientes de Desarrollo y Pruebas.
Criterios de Aceptación: Revisión del cumplimiento de los aspectos señalados en el punto

7.2.3.1.1 Ambientes de Desarrollo y Pruebas
 E3 - Informe de implementación del Release 1 y creación del ambiente de pre-

producción
Entregables:
 Implementación del Release 1:

o Actas de conformidad de cada demostración del sistema que forme parte del
release.
o Documento con prototipos de pantallas, adjuntando el informe de aplicación
de user experience (UX). El informe debe contener:
 Los resultados de las evaluaciones de los Tests de usuario
 Recomendaciones de cambios que se implementaron para mejorar
la experiencia de usuario.
o Documentación de negocio, como mínimo: Épicas, Historias de usuario y
Reglas de Negocio actualizadas.
o Documentos técnicos de sistemas utilizados para el desarrollo
o Datos requeridos para la utilización y que no tienen pantallas para registro
pre-cargados en las bases de datos
o Requerimientos funcionales y no funcionales atendidos. Se debe remitir la
evidencia de su cumplimiento
o Funcionalidades implementadas y disponibles
o Documentación de Arquitectura (anexos técnicos de este TDR) actualizados,
de ser el caso
o Documentos de Pruebas: Plan y casos de pruebas
o Informe de pruebas funcionales, no funcionales y sus resultados llevadas a
cabo.
o Acta de Aceptación de usuario
o Informe histórico de Sprints ejecutados, así como todas las historias de
usuario incluidas y sus correspondientes aceptaciones.
o Código fuente en el repositorio SUNAT
o Reporte de trazabilidad de historia de usuario versus código fuente.
o Evidencias de seguridad en aplicaciones.
o Carga inicial de datos:

253
 Plan de ejecución de la carga inicial de datos, incluyendo
documentación detallada de todas las estructuras a cargar
 Reporte de ejecución de la carga de datos, incluyendo el detalle de
actividades y pruebas realizadas sobre el software y los datos para
garantizar el correcto funcionamiento del sistema luego de la carga
de inicial de datos.
 Creación del ambiente de pre-producción (en la Plataforma de LA SUNAT):

o Ambientes de preproducción funcionando correctamente sobre la Plataforma
de LA SUNAT;
o Versión actualizada del sistema configurada en el ambiente, de acuerdo con
el modelo de DevOps definido;
o Configuraciones del sistema debidamente actualizadas de manera a soportar
la utilización de la versión más actual del sistema en el ambiente configurado.
o Documentación de todas las pruebas realizadas en el ambiente para
asegurar su correcto funcionamiento y compatibilidad;
o Manuales, documentación y diagramas técnicos actualizados;
o Documentación de las configuraciones de seguridad, Backups y todo lo que
sea necesario para asegurar la disponibilidad del sistema, la seguridad de la
información, así como los aspectos técnicos y normativos vigentes
solicitadas en estos términos de referencia.
o Informe de capacitación a técnicos de LA SUNAT.
El detalle de la información que deben contener estos documentos será definido en la fase
de Planificación.
Criterios de Aceptación:
 Implementación del Release 1:

o Implementación completa de las historias de usuario que forman parte del
Release 1, en el Release Plan propuesto en el Anexo 14;
o Pruebas del sistema sin incidentes pendientes de corrección;
o Sistema actualizado y disponible en ambiente de pre-producción;
deben estar precargados en las bases de datos;
o Toda la información requerida para el funcionamiento del Release 1 está
correctamente cargada;
o Requerimientos funcionales y no funcionales atendidos y evidenciados;
o Todos los informes solicitados elaborados y entregados

254
 Creación del ambiente de pre-producción (en la Plataforma de LA SUNAT):
o El sistema fue desplegado y configurado en el ambiente previsto;
o El ambiente, la infraestructura y las herramientas de DevOps fueron
configurados de acuerdo con el modelo de DevOps definido;
o Archivos de configuración están debidamente actualizados en las
herramientas de DevOps de control de versiones;
o Los pipelines de integración y entrega continua fueron configurados en los
respectivos ambientes permitiendo el despliegue automatizado de acuerdo
con el modelo de DevOps definido;
o Las bases de datos, todas sus configuraciones y accesos de las aplicaciones
fueron realizados;
o Las pruebas del sistema fueron realizadas y no tienen inconformidades;
 E4 – Informe de Puesta en Producción del MVP 1 y creación del ambiente de

producción
Entregables:
 Puesta en Producción del MVP1:

o Actas de conformidad de cada demostración del sistema que forme parte del
MVP.
o Documento con prototipos de pantallas, adjuntando el informe de aplicación
de user experience (UX). El informe debe contener:
 Los resultados de las evaluaciones de los Tests de usuario
 Recomendaciones de cambios que se implementaron para mejorar
la experiencia de usuario.
o Documentación de negocio, como mínimo: Épicas, Historias de usuario y
o Documentos técnicos de sistemas utilizados para el desarrollo
pre-cargados en las bases de datos;
o Requerimientos funcionales y no funcionales atendidos. Se debe remitir la
evidencia de su cumplimiento
o Funcionalidades del MVP implementadas y disponibles
o Informe de capacitación técnica y funcional
o Manuales de usuario virtuales del sistema
o Documentación de Arquitectura (anexos técnicos de este TDR) actualizados,
de ser el caso

255
o Documentos de Pruebas: Plan y casos de pruebas
o Informe de pruebas funcionales, no funcionales y sus resultados llevadas a
cabo para la puesta en producción.
o Informe histórico de Sprints ejecutados en el MVP, así como todas las
historias de usuario incluidas y sus correspondientes aceptaciones.
o Código fuente en el repositorio SUNAT
o Reporte de trazabilidad de historia de usuario versus código fuente.
o Evidencias de seguridad en aplicaciones.
o Tutorial auto administrado para el usuario del sistema, el cual permitirá guiar
al usuario paso a paso en la forma de utilizar correctamente cada opción del
sistema, indicando en forma oral y visual la información que se debe registrar,
mostrando los valores que el sistema presentará y explicando los pasos a
seguir hasta finalizar cada transacción u operación en el sistema.
o Videos de clase virtual funcional del sistema. Deben estar en formato mp4 y
codificados en H264. Con una proporción de 960 X 540 y una duración
máxima es de 10 minutos cada video. En caso sea una clase de mayor
tiempo al señalado dividir por temas guardando una correlación lógica
o Carga inicial de datos:
 Plan de ejecución de la carga inicial de datos, incluyendo
documentación detallada de todas las estructuras a cargar
 Reporte de ejecución de la carga de datos, incluyendo el detalle de
actividades y pruebas realizadas sobre el software y los datos para
garantizar el correcto funcionamiento del sistema luego de la carga
de inicial de datos.
 Creación del ambiente de producción (en la Plataforma de LA SUNAT):
o Ambiente de producción funcionando correctamente sobre la Plataforma de
LA SUNAT;
o Versión actualizada del sistema configurada en los respectivos ambientes,
de acuerdo con el modelo de DevOps definido;
la utilización de la versión más actual del sistema en el ambiente configurado.
o Documentación de todas las pruebas realizadas en el ambiente para
asegurar su correcto funcionamiento y compatibilidad;
o Manuales de operación de los ambientes de producción funcionando
correctamente sobre la Plataforma de LA SUNAT, lo que incluye los
procedimientos de Backups, control de acceso y monitoreo de infraestructura
y aplicaciones;

256
o Documentación de las configuraciones de seguridad, Backups y todo lo que
de Planificación.
 Puesta en Producción del MVP1

o Implementación completa de las historias de usuario del MVP;
o Pruebas del sistema sin incidentes pendientes de corrección;
o Usuarios capacitados para la utilización de las épicas desarrolladas o
actualizadas;
o Técnicos de LA SUNAT capacitados;
o Manuales actualizados de manera adherente a la versión más actual del
sistema;
deben estar precargados en las bases de datos;
o Toda la información requerida para el funcionamiento del MVP está
o Requerimientos funcionales y no funcionales atendidos y evidenciados;
o Todos los informes solicitados elaborados y entregados.
 Creación del ambiente de producción (en la Plataforma de LA SUNAT):

o El sistema fue desplegado y configurado en todos los ambientes previstos;
configurados de acuerdo con el modelo de DevOps definido;
o Archivos de configuración, manuales técnicos y operacionales están
debidamente actualizados en las herramientas de DevOps de control de
versiones;

257
fueron realizados;
Para dar por finalizada esta fase se debe tener el Sistema actualizado y disponible en
ambiente de producción y Acta de Aceptación de usuario.
 E5 – Informe de la Carga Inicial de Datos del MVP1
Entregables:
 Plan de ejecución de la carga inicial de datos, incluyendo documentación detallada

de todas las estructuras a cargar
 Reporte de ejecución de la carga de datos, incluyendo el detalle de actividades y
pruebas realizadas sobre el software y los datos para garantizar el correcto
funcionamiento del sistema luego de la carga de inicial de datos.
 Fue realizado el mapeo de los procesos de transformación y carga de los datos a

partir de la información proporcionada por LA SUNAT.
 La carga de datos fue realizada según el plan definido para la Carga Inicial de datos
en el Plan de Gestión aprobado con LA SUNAT.
 Los datos cargados son suficientes para poner el sistema en operación, es decir que,
ninguna información que sea registrada directamente en las bases de datos esté
incompleta y sin una funcionalidad que permita su registro por los usuarios del
sistema.
 Los saldos de los contribuyentes para cada uno de los tributos que los afectan, así
como, los respectivos movimientos están actualizados en las cuentas del sistema.
 Los documentos de procesos de la administración tributaria que tienen su
seguimiento en la Cuenta Única fueron cargados en las respectivas bases de datos
del Sistema de Cuenta Única.
 La carga de datos realizada no generó errores en la versión vigente del sistema en
ninguno de los ambientes de la Plataforma de LA SUNAT.

258
 E6 - Informe de implementación del Release 4
Entregables:
 Actas de conformidad de cada demostración del sistema que forme parte del release.
 Documento con prototipos de pantallas, adjuntando el informe de aplicación de
userexperience. (UX). El informe debe contener:
o Los resultados de las evaluaciones de los Tests de usuario
o Recomendaciones de cambios que se implementaron para mejorar la
experiencia de usuario.
 Documentación de negocio, como mínimo: Épicas, Historias de usuario y Reglas de
Negocio actualizadas.
 Documentos técnicos de sistemas utilizados para el desarrollo
 Datos requeridos para la utilización y que no tienen pantallas para registro pre-
cargados en las bases de datos
 Requerimientos funcionales y no funcionales atendidos. Se debe remitir la evidencia
de su cumplimiento
 Funcionalidades implementadas y disponibles
 Documentación de Arquitectura (anexos técnicos de este TDR) actualizados, de ser
el caso
 Documentos de Pruebas: Plan y casos de pruebas
 Informe de pruebas funcionales, no funcionales y sus resultados llevadas a cabo.
 Acta de Aceptación de usuario
 Informe histórico de Sprints ejecutados, así como todas las historias de usuario
incluidas y sus correspondientes aceptaciones.
 Código fuente en el repositorio SUNAT
 Reporte de trazabilidad de historia de usuario versus código fuente.
 Evidencias de seguridad en aplicaciones.
 Carga inicial de datos (de corresponder):
o Plan de ejecución de la carga inicial de datos, incluyendo documentación
detallada de todas las estructuras a cargar
o Reporte de ejecución de la carga de datos, incluyendo el detalle de
actividades y pruebas realizadas sobre el software y los datos para garantizar
el correcto funcionamiento del sistema luego de la carga de inicial de datos.
de Planificación.

259
 Implementación completa de las historias de usuario que forman parte del Release
4, en el Release Plan propuesto en el Anexo 14 de la base.
 Pruebas del sistema sin incidentes pendientes de corrección;
 Sistema actualizado y disponible en ambiente de pre-producción;
 Datos requeridos para la utilización y que no tienen pantallas para registro deben
estar precargados en las bases de datos;
 Toda la información requerida para el funcionamiento del Release 1 está
 Requerimientos funcionales y no funcionales atendidos y evidenciados;
 Todos los informes solicitados elaborados y entregados
 E7 – Informe de Puesta en Producción del MVP2
Entregables:
 Actas de conformidad de cada demostración del sistema que forme parte del MVP.
 Documento con prototipos de pantallas, adjuntando el informe de aplicación de user
experience. (UX). El informe debe contener:
o Los resultados de las evaluaciones de las pruebas de usuario
o Recomendaciones de cambios que se implementaron para mejorar la
experiencia de usuario.
 Documentación de negocio, como mínimo: Épicas, Historias de usuario y Reglas de
Negocio actualizadas.
 Documentos técnicos de sistemas utilizados para el desarrollo
 Datos requeridos para la utilización y que no tienen pantallas para registro pre-
cargados en las bases de datos;
 Requerimientos funcionales y no funcionales atendidos. Se debe remitir la evidencia
de su cumplimiento
 Funcionalidades del MVP implementadas y disponibles
 Informe de capacitación técnica y funcional
 Manuales de usuario virtuales del sistema
 Documentación de Arquitectura (anexos técnicos de este TDR) actualizados, de ser
el caso
 Documentos de Pruebas: Plan y casos de pruebas
 Informe de pruebas funcionales, no funcionales y sus resultados llevadas a cabo para
la puesta en producción.

260
 Informe histórico de Sprints ejecutados en el MVP, así como todas las historias de
 Código fuente en el repositorio SUNAT
 Reporte de trazabilidad de historia de usuario versus código fuente.
 Evidencias de seguridad en aplicaciones.
 Tutorial auto administrado para el usuario del sistema, el cual permitirá guiar al
usuario paso a paso en la forma de utilizar correctamente cada opción del sistema,
indicando en forma oral y visual la información que se debe registrar, mostrando los
valores que el sistema presentará y explicando los pasos a seguir hasta finalizar cada
transacción u operación en el sistema.
 Videos de clase virtual funcional del sistema. Deben estar en formato mp4 y
codificados en H264. Con una proporción de 960 X 540 y una duración máxima es
de 10 minutos cada video. En caso sea una clase de mayor tiempo al señalado dividir
por temas guardando una correlación lógica
 Carga inicial de datos:
o Plan de ejecución de la carga inicial de datos, incluyendo documentación
detallada de todas las estructuras a cargar
o Reporte de ejecución de la carga de datos, incluyendo el detalle de
actividades y pruebas realizadas sobre el software y los datos para garantizar
el correcto funcionamiento del sistema luego de la carga de inicial de datos.
de Planificación.
 Implementación completa de las historias de usuario del MVP;

 Pruebas del sistema sin incidentes pendientes de corrección;
 Usuarios capacitados para la utilización de las épicas desarrolladas o actualizadas;
 Técnicos de LA SUNAT capacitados;
 Manuales actualizados de manera adherente a la versión más actual del sistema;
 Datos requeridos para la utilización y que no tienen pantallas para registro deben
estar precargados en las bases de datos;
 Toda la información requerida para el funcionamiento del MVP está correctamente
cargada;
 Requerimientos funcionales y no funcionales atendidos y evidenciados;
 Todos los informes solicitados elaborados y entregados.

261
Para dar por finalizada esta fase se debe tener el Sistema actualizado y disponible en
ambiente de producción y Acta de Aceptación de usuario.
 E8 – Informe de la Carga Inicial de Datos del MVP2
Entregables:
 Plan de ejecución de la carga inicial de datos, incluyendo documentación detallada

de todas las estructuras a cargar
 Reporte de ejecución de la carga de datos, incluyendo el detalle de actividades y
pruebas realizadas sobre el software y los datos para garantizar el correcto
funcionamiento del sistema luego de la carga de inicial de datos.
 Fue realizado el mapeo de los procesos de transformación y carga de los datos a

partir de la información proporcionada por LA SUNAT;
 La carga de datos fue realizada según el plan definido para la Carga Inicial de datos
en el Plan de Gestión aprobado con LA SUNAT;
 Los datos cargados son suficientes para poner el sistema en operación, es decir que,
ninguna información que sea registrada directamente en las bases de datos esté
incompleta y sin una funcionalidad que permita su registro por los usuarios del
sistema;
 Los saldos de los contribuyentes para cada uno de los tributos que los afectan, así
como, los respectivos movimientos están actualizados en las cuentas del sistema;
 Los documentos de procesos de la administración tributaria que tienen su
seguimiento en la Cuenta Única fueron cargados en las respectivas bases de datos
del Sistema de Cuenta Única;
 La carga de datos realizada no generó errores en la versión vigente del sistema en
ninguno de los ambientes de la Plataformade LA SUNAT.
 E9– Informe de Migración de los ambientes de Desarrollo y Pruebas
Entregables:
 Migración hacia la Plataforma de LA SUNAT:

o Ambientes de desarrollo y pruebas funcionando correctamente sobre la
Plataforma de LA SUNAT;

262
o Versión actualizada del sistema configurada en los respectivos ambientes,
de acuerdo con el modelo de DevOps definido;
la utilización de la versión más actual del sistema en cada uno de los
ambientes configurados.
o Código fuente del sistema actualizado en las herramientas del modelo de
DevOps en la Plataforma de LA SUNAT;
o Documentación de todas las pruebas realizadas en los ambientes para
asegurar su correcto funcionamiento;
o Manuales de operación de los ambientes de desarrollo y pruebas
funcionando correctamente sobre la Plataforma de LA SUNAT, lo que
incluyen los procedimientos de backup, control de acceso y monitoreo de
infraestructura y aplicaciones;
o Documentación de las configuraciones de seguridad, backups y todo lo que
 Migración hacia la Plataforma de LA SUNAT:

o El sistema fue desplegado y configurado en todos los ambientes previstos;
configurados de acuerdo al modelo de DevOps definido;
o El código fuente de la solución, así como los archivos de configuración,
infraestructura como código, manuales técnicos y operacionales están
debidamente actualizados en las herramientas de DevOps de control de
versiones;
fueron realizados;

263
 E10– Informe de Capacitación y Transferencia de Conocimientos
Entrega: Informe de capacitación y Transferencia de Conocimientos
Criterios de Aceptación: Conformidad de la capacitación en función de los requerimientos

detallados en estos términos de referencia, frecuencia (nombres y firmas), fechas de las
capacitaciones técnicas y de usuarios.
 E11- Informe de Mantenimiento Correctivo y Soporte
Entrega: LA FIRMA CONSULTORA deberá entregar informes mensuales detallados que

incluyan como mínimo los siguientes elementos:
 Mantenimiento Correctivo: Informe de Atención de Incidencias atendidos durante el

mes detallando en casa caso: un análisis del incidente, tiempos empleados en su
solución, el detalle de la solución y acciones que se tomaron para evitar un nuevo
incidente de esta naturaleza.
 Soporte: informes con las actividades de soporte, identificando la cronología de
actividades y el estatus de tickets de soporte.
Criterios de Aceptación: Conformidad de los informes en función de los requerimientos

detallados en estos términos de referencia.
 E12– Informe Final del Proyecto
El informe final debe contener información acerca de las actividades ejecutadas del proyecto
en las diversas áreas del conocimiento según el plan de gestión, actualizaciones necesarias
generadas en el plan, copias de las solicitudes de cambio presentadas al proyecto, copias
históricas de las líneas de base de tiempo y alcance. Además de conclusiones y
recomendaciones acerca del sistema Cuenta Única y de la ejecución del proyecto.
Criterios de aceptación: Conformidad del informe en función de los requerimientos detallados

en estos términos de referencia.
2.3 Plan de Gestión de Riesgos
2.3.1 Introducción

264
Se define a continuación el contenido del Plan de Gestión de Riesgos. Este plan describe la
forma en que se realizará la gestión de los riesgos en el proyecto, cómo se determinan los
riesgos y factores críticos asociados al desarrollo y puesta en marcha del proyecto así como
de los diferentes sub-proyectos, evaluando su grado de impacto y estableciendo las medidas
de mitigación, para minimizar posibles incidencias, o las medidas de contingencia a aplicar
en caso de que se materialicen estos riesgos, con el fin de minimizar tiempos de recuperación
y retrasos en los trabajos a realizar.
El objetivo principal de la Gestión de Riesgos del proyecto es aumentar la probabilidad y el

impacto de los eventos positivos y disminuir la probabilidad y el impacto de los eventos
adversos para el proyecto. La gestión de riesgos es un proceso sistemático e iterativo
orientado a identificar, evaluar el impacto y preparar las estrategias de respuesta a los
posibles riesgos que puedan interponerse en la consecución de los objetivos del proyecto.
2.3.2 Metodología
A continuación, se definen los métodos, herramientas y fuentes de información que se van a

utilizar para realizar la gestión de riesgos durante el desarrollo del proyecto, así como las
fuentes de información de datos que se emplearán para este proceso.
La metodología que se utilizará para la gestión de riesgos del proyecto es la establecida en

la Metodología de Gestión de Proyectos del Consorcio, basada en estándares internacionales
como el PMBOK (Project Management Body of Knowledge).
La gestión de Riesgos en los proyectos que el Consorcio acomete, comienza con la

planificación cuidadosa y explicita de las actividades a realizar en la gestión de los riesgos
del proyecto, lo que mejora la posibilidad de éxito de todos los procesos que la soportan,
entendiéndose por planificación de la gestión de riesgos el proceso de decidir cómo se van a
abordar y llevar a cabo dichas actividades.
La identificación de los procesos de gestión de riesgos del proyecto queda reflejada en el

Plan de Gestión de Riesgos del mismo, donde se describe cómo se estructura y realiza esta
gestión.
Una vez definido el plan, se realiza una evaluación inicial de los riesgos del proyecto,
reflejando la precepción de los mismos en la etapa precontractual del proyecto.
La Gestión de Riesgos continúa durante toda la vida del proyecto. Durante la fase de
Planificación se sentarán las bases más significativas de la gestión de riesgos, dado su
previsible impacto sobre la planificación de aspectos fundamentales que afectan al desarrollo
del proyecto. El Plan de Riesgos se gestionará y mantendrá actualizado durante la fase de
ejecución y la fase de seguimiento y control del proyecto.

265
Ilustración 91: Metodología
Etapa Contractual
Evaluación Inicial de Riesgos
Se realiza la evaluación inicial de Riesgos en la etapa precontractual con el objetivo

fundamental de identificar aquellas áreas de riesgo que requieren una atención especial, de
manera que se pueda realizar la gestión con la mayor seguridad y garantía posibles, y
tomarlas medidas oportunas en el momento de preparar la planificación de detalle para la
ejecución del proyecto.
Si bien pueden existir riesgos específicos de una etapa comercial o de gestión de la oferta
en sí, y que deben tener por tanto un tratamiento específico, la mayor parte de los riesgos
a tener en cuenta en esta etapa se refieren a los relativos al éxito en la ejecución del
proyecto.
Planificación
Planificación de la Gestión de Riesgos
La Planificación de la Gestión de Riesgos es el proceso por el cual se define cómo realizar

las actividades de gestión de riesgos para el proyecto. La planificación de los procesos de
gestión de riesgos es importante para garantizar que el nivel, el tipo y la visibilidad de la
gestión sean acordes con el riesgo y la importancia del proyecto, con el fin de proporcionar
recursos y tiempo suficiente para las actividades de gestión de riesgos y para establecer
una base acordada para evaluar los riesgos. El proceso de Planificación de la Gestión de
Riesgos se realiza en las fases tempranas de planificación del proyecto, dado que es crucial
para realizar con éxito el resto de los procesos de la Gestión de Riesgos.

266
El equipo del proyecto mantendrá reuniones para desarrollar el plan de gestión de riesgos.
Los participantes de estas reuniones pueden ser, entre otros, el jefe del proyecto, miembros
del equipo del proyecto e interesados seleccionados, cualquier persona de PIDE con la
responsabilidad de gestionar la planificación y ejecución de actividades relacionadas con
los riesgos, así como otros implicados, según sea necesario.
En estas reuniones, se definen los planes a alto nivel para efectuar las actividades de
gestión de riesgos. Se evalúa el coste de la gestión de riesgos y se estima la duración de
las actividades, para incluirlos en el presupuesto y el cronograma del proyecto,
respectivamente. Se establecen o se revisan las metodologías para la aplicación de los
planes de contingencia en materia de riesgos. Se asignan las responsabilidades de gestión
de riesgos. Se adaptan para su uso en el proyecto las plantillas generales para las
categorías de riesgo y las definiciones de términos, tales como los niveles de riesgo, la
probabilidad por tipo de riesgo, el impacto por tipo de objetivo y la matriz de probabilidad e
impacto.
Identificación de Riesgos
La Identificación de Riesgos es el proceso por el cual se determinan los riesgos que pueden
afectar al proyecto y se documentan sus características. Entre las personas que participan
en la identificación de riesgos se pueden incluir: el Jefe de Proyecto, los diferentes Soportes
al Jefe de Proyecto, incluido el Gestor de Riesgos, los miembros del equipo del proyecto,
cualquier persona de PIDE con la responsabilidad de gestionar de actividades relacionadas
con los riesgos y/o relacionados con las actividades del proyecto.
Identificar los Riesgos es un proceso iterativo debido a que se pueden descubrir nuevos
riesgos o pueden evolucionar conforme el proyecto avanza a lo largo de su ciclo de vida.
La frecuencia de iteración y quiénes participan en cada ciclo varía de una situación a otra.
El proceso debe involucrar al equipo del proyecto de modo que pueda desarrollar y
mantener un sentido de propiedad y responsabilidad por los riesgos y las acciones de
respuesta asociadas. Los interesados externos al equipo del proyecto pueden proporcionar
información objetiva adicional.
Para identificar los riesgos en el proyecto, se parte o se analizan determinados documentos

o activos del proyecto, tales como:
 Plan de Gestión de Riesgos

El primer documento a tener en cuenta en el proceso de identificación de riesgos es el
plan de gestión de riesgos, en el que se revisarán las asignaciones de roles y
responsabilidades, la provisión para las actividades de gestión de riesgos en el
presupuesto y en el cronograma, y las categorías de riesgo.

267
 Estimación del Coste de las Actividades
Las revisiones de la estimación del coste de las actividades son útiles para identificar los
riesgos, ya que proporcionan una evaluación cuantitativa del coste probable para
completar las actividades del cronograma, e idealmente están expresadas como un rango
cuya amplitud indica los grados de riesgo. La revisión puede dar como resultado
proyecciones que indiquen si la estimación es suficiente para completar la actividad, o es
insuficiente (en cuyo caso podría representar un riesgo para el proyecto)
 Estimación de la Duración de la Actividad

Las revisiones de la estimación de la duración de las actividades son útiles para identificar
los riesgos relacionados con los tiempos asignados para la realización de las actividades
o de todo el proyecto; la amplitud de rango de dichas estimaciones también indica en este
caso logrados relativos de riesgo.
 Línea Base del Alcance del Proyecto

Los supuestos del proyecto se encuentran en el enunciado del alcance del proyecto. La
incertidumbre a nivel de los supuestos del proyecto debe evaluarse como causas
potenciales de riesgo.
La EDT (Estructura de Descomposición del Trabajo) es una entrada crítica para la

identificación de riesgos ya que facilita la comprensión de los riesgos potenciales. Los
riesgos pueden identificarse y luego realizar el seguimiento a nivel de resumen, de
módulo, o de paquete de trabajo.
 Registro de Interesados
La información acerca de los interesados será útil para solicitar entradas para la
identificación de riesgos, ya que esto asegurará que los interesados clave, especialmente
PIDE, sean entrevistados o participen de otra manera durante el proceso Identificar los
Riesgos.
 Presupuesto del Proyecto

El proceso de Identificación de Riesgos requiere la comprensión del presupuesto del
proyecto que forma parte del plan del proyecto. Por su naturaleza o estructura, el enfoque
específico de la gestión de costes o del presupuesto del proyecto puede generar riesgos
o moderarlos.
 Gestión del Cronograma del Proyecto

El proceso de Identificación de Riesgos también requiere la comprensión del cronograma
que forma parte del plan del proyecto. Por su naturaleza o estructura, el enfoque
específico del cronograma del proyecto puede generar riesgos o moderarlos.

268
 Documentos /informes del Proyecto
Los documentos del proyecto incluyen, entre otros los informes de desempeño del
trabajo, informes de seguimiento del proyecto, líneas base, así como otra información
generada durante el desarrollo del proyecto que resulte valiosa para la identificación de
riesgos
 Factores Ambientales
Los factores ambientales tanto de PIDE, como del Consorcio y de otros proveedores
implicados en el desarrollo del proyecto pueden influir en el proceso de identificación de
riesgos, mencionando entre otros: información publicada, incluidas las bases de datos
comerciales, investigaciones académicas, estudios comparativos, benchmarking,
estudios del sector, experiencias publicadas.
 Activos de los Procesos de la Organización

Los activos de los procesos de la organización que pueden influir en el proceso Identificar
los Riesgos incluyen, entre otros:
o los archivos del proyecto, incluidos los datos reales

o los controles de los procesos de la organización y del proyecto
o las plantillas de registros de riesgos
o las lecciones aprendidas
Los métodos y técnicas que se pueden utilizar en el proceso de identificación de riesgos

pasan por efectuar una revisión estructurada de la documentación del proyecto, incluyendo
los planes, los supuestos, los archivos de proyectos anteriores, los contratos y otra
información. La calidad de los planes, así como la consistencia entre dichos planes y los
requisitos y supuestos del proyecto, pueden ser indicadores de riesgo en el proyecto.
Asimismo se pueden utilizar técnicas de recopilación de información tales como: Tormenta
de ideas, entrevistas de grupo, análisis causa efecto, listas de control basándose en la
información histórica y el conocimiento acumulado a partir de proyectos similares anteriores
y otras fuentes de información, análisis de supuestos, identificando los riesgos del proyecto
debidos al carácter inexacto, inestable, incoherente o incompleto de los supuestos, análisis
DAFO (debilidades, amenazas, fortalezas y oportunidades), juicio de expertos, con
experiencia apropiada, adquirida en proyectos o áreas de negocio similares.
Análisis Cualitativo de Riesgos
Realizar el Análisis Cualitativo de Riesgos consiste en priorizar los riesgos para realizar otros
análisis o acciones posteriores, evaluando y combinando la probabilidad de ocurrencia y el

269
impacto de dichos riesgos. Generalmente se mejora el desempeño del proyecto
concentrándose en los riesgos de alta prioridad. El proceso Realizar el Análisis Cualitativo de
Riesgos evalúa la prioridad de los riesgos identificados usando la probabilidad relativa de
ocurrencia, el impacto correspondiente sobre los objetivos del proyecto si los riesgos se
presentan, así como otros factores, tales como el plazo de respuesta y la tolerancia al riesgo
por parte de la organización, asociados con las restricciones del proyecto en cuanto a costes,
cronograma y alcance. Estas evaluaciones reflejan la actitud frente a los riesgos, tanto del
equipo del proyecto como de otros interesados. Por lo tanto, una evaluación eficaz requiere
la identificación explícita y la gestión de las actitudes frente al riesgo por parte de los
participantes clave en el proyecto.
Realizar el Análisis Cualitativo de Riesgos es por lo general un medio rápido y económico de

establecer prioridades para la planificación de la respuesta a los riesgos y sienta las bases
para realizar el análisis cuantitativo de riesgos, si se requiere. El proceso de Análisis
Cualitativo de Riesgos debe ser revisado durante el ciclo de vida del proyecto para
mantenerlo actualizado con respecto a los cambios en los riesgos del proyecto.
Este proceso puede conducir al proceso Realizar el Análisis Cuantitativo de Riesgos o

directamente al proceso Planificar la Respuesta a los Riesgos.
Como punto de partida de este proceso, generalmente se tendrán en cuenta y considerarán

como entradas al mismo:
 Registros de Riesgos identificados en el proceso anterior

En concreto, la definición de los roles y responsabilidades para la gestión de riesgos, los
presupuestos, las actividades del cronograma relativas a la gestión de riesgos, así como
las categorías de riesgo, las definiciones de probabilidad e impacto, la matriz de
probabilidad e impacto y la revisión de la tolerancia al riesgo por parte de los interesados.
 Alcance del Proyecto

Los proyectos de tipo común o recurrente tienden a que sus riesgos sean mejor
comprendidos. Los proyectos innovadores y que utilizan tecnología punta, como puede
ser este proyecto, así como los proyectos altamente complejos, tienden a tener más
incertidumbre.
 Información de otros procesos de la Organización

270
Los activos de los procesos de la organización que pueden influir en el proceso de Análisis
Cualitativo de Riesgos incluyen, entre otros:
o Información procedente de proyectos similares anteriores completados

o Estudios de proyectos similares realizados por especialistas en riesgos
o Bases de datos de riesgos que pueden estar disponibles, procedentes de fuentes
industriales o propietarias
Entre los métodos y técnicas que se pueden utilizar en el proceso de Análisis Cualitativo de
Riesgos cabe mencionar:
 Evaluación de Probabilidad e Impacto de los Riesgos

La evaluación de la probabilidad de los riesgos estudia la probabilidad de ocurrencia de
cada riesgo específico. La evaluación del impacto de los riesgos investiga el efecto
potencial de los mismos sobre un objetivo del proyecto, en concreto sobre el cronograma
o plazo, el coste, o el alcance.
Para cada riesgo identificado, se evalúan la probabilidad y el impacto. Los riesgos pueden
evaluarse en entrevistas o reuniones con participantes seleccionados por su familiaridad
con las categorías de riesgo utilizados. Entre ellos, se incluyen los miembros del equipo
del proyecto y, quizás, expertos que no pertenecen al proyecto.
Durante estas entrevistas o reuniones, se evalúa el nivel de probabilidad de cada riesgo y

su impacto sobre cada objetivo del proyecto. Las probabilidades e impactos de los riesgos
se califican de acuerdo con las definiciones proporcionadas en el plan de gestión de
riesgos. Los riesgos con una baja calificación en cuanto a probabilidad e impacto se suelen
incluir en una lista de supervisión para su seguimiento futuro.
 Matriz de Probabilidad e Impacto

Los riesgos deben priorizarse para realizar un análisis cuantitativo posterior y elaborar
respuestas basadas en su calificación. Estas reglas de calificación de los riesgos se
definen por la organización antes del inicio del proyecto y se incluyen en los activos de los
procesos de la organización. Las reglas de calificación de los riesgos pueden adaptarse
al proyecto específico durante el proceso Planificar la Gestión de Riesgos. Habitualmente,
la evaluación de la importancia de cada riesgo y, por consiguiente, de su prioridad de
atención, se efectúa utilizando una matriz de probabilidad e impacto. Dicha matriz
especifica las combinaciones de probabilidad e impacto que llevan a calificar los riesgos
con una prioridad baja, moderada o alta. En esta matriz las áreas con las cifras más altas
representa un riesgo alto, y aquellas con cifras intermedias o bajas presentan un riesgo
más moderado (ver Matriz de Riesgo e Impacto definida para este proyecto).

271
La calificación de los riesgos ayuda a guiar las respuestas a los riesgos. Por ejemplo, los
riesgos que, si se concretan (amenazas), tienen un impacto negativo sobre los objetivos,
y queso encuentran en la zona de riesgo alto de la matriz, pueden necesitar prioridad de
acción y estrategias de respuesta agresivas. Las amenazas en la zona de riesgo bajo
pueden no necesitar una acción de gestión proactiva, más allá de ser incluidas en una
lista de supervisión o de ser agregadas a una reserva para contingencias.
 Evaluación de la Calidad de los Datos sobre Riesgos

Para ser creíble, un análisis cualitativo de riesgos requiere datos exactos y sin
parcialidades. El análisis de la calidad de los datos sobre riesgos es una técnica para
evaluar el grado de utilidad de los datos sobre riesgos para su gestión. Implica examinar
el grado de entendimiento del riesgo y la exactitud, calidad, fiabilidad e integridad de los
datos relacionados con el riesgo. Si la calidad de los datos es inaceptable, puede ser
necesario recopilar datos de mayor calidad.
 Categorización de Riesgos
Los riesgos del proyecto pueden categorizarse por fuentes de riesgo, por área del
proyecto afectada, u otra categoría útil (p.ej., fase del proyecto) para determinar qué
áreas del proyecto están más expuestas a los efectos de la incertidumbre. La
agrupación de los riesgos en función de sus causas comunes puede llevar al
desarrollo de respuestas efectivas a los riesgos.
 Evaluación de la Urgencia de los Riesgos

Los riesgos que requieren respuestas a corto plazo pueden ser considerados de
atención más urgente. Los indicadores de prioridad pueden incluir el tiempo para dar
una respuesta a los riesgos, los síntomas y las señales de advertencia, y la
calificación del riesgo. En algunos análisis cualitativos, la evaluación de la urgencia
de un riesgo puede estar asociada con la calificación del riesgo, la cual se determina
a partir de la matriz de probabilidad e impacto para obtener una calificación final de
la severidad del riesgo.
 Juicio de Expertos
El juicio de expertos es necesario para evaluar la probabilidad y el impacto de cada
riesgo, para determinar su ubicación dentro de la matriz de impacto y probabilidad.
Por lo general, los expertos son aquellas personas que ya han tenido experiencia en
proyectos similares relativamente recientes. Además, quienes planifican y dirigen el
proyecto específico son expertos, particularmente en lo relativo a los aspectos
específicos de dicho proyecto. La obtención del juicio de expertos en materia de
riesgos se logra a menudo mediante talleres de facilitación o entrevistas.

272
Después del proceso de Análisis Cualitativo de Riesgos se deberán actualizar los
Registros de Riesgos identificados en el proceso anterior. Se incluirá en éstos:
 Clasificación relativa o lista de prioridades de los riesgos del proyecto. La matriz de

probabilidad e impacto puede utilizarse para clasificar los riesgos según su
importancia individual. La utilización de combinaciones de probabilidad de ocurrencia
de cada riesgo y su impacto sobre los objetivos en caso de que suceda otorgará a
los riesgos un orden de prioridad y los clasificará en grupos según sean de “riesgo
alto”, de “riesgo moderado” o de “riesgo bajo”. Los riesgos pueden enumerarse por
prioridades en forma separada para el plazo, el coste y el alcance, puesto que las
organizaciones pueden acordar mayor importancia a un objetivo o a otro.
 Riesgos agrupados por categorías. La categorización de riesgos puede revelar

causas comunes de riesgos o áreas del proyecto que requieren atención especial.
Descubrir las concentraciones de riesgos puede mejorar la efectividad de las
respuestas a los riesgos.
 Causas de riesgo o áreas del proyecto que requieren particular atención. Descubrir
las concentraciones de riesgos puede mejorar la efectividad de las respuestas a los
riesgos.
 Lista de riesgos que requieren respuesta a corto plazo. Los riesgos que requieren
una respuesta urgente y aquéllos que pueden ser tratados posteriormente pueden
incluirse en grupos diferentes.
 Lista de riesgos que requieren análisis y respuesta adicionales. Algunos riesgos

pueden justificar un mayor análisis, incluido el análisis cuantitativo de riesgos, así
como una acción de respuesta.
 Listas de supervisión para riesgos de baja prioridad. Los riesgos que no se han
evaluado como importantes en el proceso del Análisis Cualitativo de Riesgos pueden
incluirse en una lista de supervisión para un seguimiento posterior.
 Tendencias en los resultados del análisis cualitativo de riesgos. Conforme se repite
el análisis, puede hacerse evidente una tendencia para determinados riesgos, que
puede hacer más o menos urgente o importante la respuesta a los riesgos o un
análisis más profundo.
Análisis Cuantitativo de Riesgos
Realizar el Análisis Cuantitativo de Riesgos es el proceso que consiste en analizar

numéricamente el efecto de los riesgos identificados sobre los objetivos generales del proyecto.
El proceso de Análisis Cuantitativo de Riesgos se aplica a los riesgos priorizados mediante el

273
proceso anterior por tener un posible impacto significativo sobre las demandas concurrentes del
proyecto. Puede utilizarse para asignar a esos riesgos una calificación numérica individual o para
evaluar el efecto acumulativo de todos los riesgos que afectan el proyecto. También presenta un
enfoque cuantitativo para tomar decisiones en caso de incertidumbre.
Por lo general, el proceso del Análisis Cuantitativo de Riesgos se realiza después del proceso
de Análisis Cualitativo de Riesgos. En algunos casos, es posible que el proceso de Análisis
Cuantitativo de Riesgos no sea necesario para desarrollar una respuesta efectiva a los riesgos.
La disponibilidad de tiempo y presupuesto, así como la necesidad de declaraciones cualitativas
o cuantitativas acerca de los riesgos y sus impactos, determinarán qué métodos emplear para
un proyecto en particular. El proceso de Análisis Cuantitativo de Riesgos debe repetirse después
del proceso de Planificar la Respuesta a los Riesgos, así como durante el proceso Seguimiento
y Control de los Riesgos, para determinar si se ha reducido satisfactoriamente el riesgo global
del proyecto.
Como punto de partida de este proceso, generalmente se tendrán en cuenta y considerarán

como entradas al mismo:
 Registro de Riesgos

 Presupuesto del Proyecto
 Cronograma del Proyecto
 Activos de los Procesos de la Organización
 Los activos de los procesos de la organización que pueden influir en el proceso Realizar
el Análisis Cuantitativo de Riesgos incluyen, entre otros:
o información procedente de proyectos similares anteriores completados
o estudios de proyectos similares realizados por especialistas en riesgos
o bases de datos de riesgos que pueden estar disponibles, procedentes de fuentes
industriales o propietarias
Para realizar el análisis cuantitativo de riesgos se podrán utilizar entre otros, los siguientes
métodos y técnicas:
 Técnicas de Recopilación y Representación de Datos

o Entrevistas. Las técnicas de entrevistas se basan en la experiencia y en datos
históricos para cuantificar la probabilidad y el impacto de los riesgos sobre los
objetivos del proyecto.
o Distribuciones de probabilidad. Las distribuciones continuas de probabilidad,
utilizadas ampliamente en el modelado y la simulación, representan la incertidumbre

274
de los valores tales como las duraciones de las actividades del cronograma y los
costes de los componentes del proyecto.
 Técnicas de Análisis Cuantitativo de Riesgos y de Modelado

Las técnicas comúnmente usadas abarcan tanto los análisis orientados a eventos como
a los orientados a proyectos, e incluyen Análisis de sensibilidad, de ayuda a determinar
qué riesgos tienen un mayor impacto potencial en el proyecto, Análisis del valor
monetario esperado.
 Juicio de Expertos
El juicio de expertos (que idealmente recurre a expertos con experiencia relevante y
reciente) se requiere para identificar los impactos potenciales sobre el coste y el
cronograma, para evaluarla probabilidad y definir las entradas (tales como las
distribuciones de probabilidad) a las herramientas, y también para la interpretación de
los datos.
El resultado del análisis cuantitativo de los riesgos se documenta en los Registros de Riesgos,
incluyendo: estimaciones de los resultados potenciales de la planificación y estimación del
proyecto, enumerando las fechas de conclusión y los costes posibles con sus niveles de
confianza asociados; estimación de la probabilidad de alcanzar los objetivos del proyecto de
acuerdo con el plan actual utilizando los resultados del análisis cuantitativo de riesgos. También
se obtendrá una lista priorizada de riesgos cuantificados. Esta lista de riesgos incluye los
riesgos que representan la mayor amenaza o presentan la mayor oportunidad para el proyecto.
Se incluyen los riesgos que pueden tener el mayor efecto en las contingencias descotes y
aquéllos que tienen más probabilidad de influir en la ruta crítica.
Planificación de la Respuesta a los Riesgos
Planificar la Respuesta a los Riesgos es el proceso por el cual se desarrollan opciones y

acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto.
Se realiza después de los procesos de Análisis Cualitativo y Cuantitativo de Riesgos. Incluye
la identificación y asignación de una persona (el “propietario de la respuesta a los riesgos”)
para que asuma la responsabilidad de cada respuesta a los riesgos acordada y financiada. El
proceso Planificar la Respuesta a los Riesgos aborda los riesgos en función de superioridad,
introduciendo recursos y actividades en el presupuesto, el cronograma y el plan de gestión del
proyecto, según se requiera.
Las respuestas a los riesgos planificadas deben adaptarse a la importancia del riesgo, ser
rentables con relación al desafío a cumplir, realistas dentro del contexto del proyecto,

275
acordadas por todas las partes involucradas y deben estar a cargo de una persona
responsable.
También deben ser oportunas. A menudo, se requiere seleccionar la mejor respuesta a los
riesgos entre varias opciones. Los riesgos incluyen las amenazas y/o las oportunidades que
pueden afectar el éxito del proyecto, y se debaten las respuestas para cada una de ellas.
Como punto de partida del proceso de Planificación de la Respuesta a los Riesgos se revisarán:
 El registro de riesgos en los que se han incluido los riesgos identificados, las causas de los
mismos, la lista de respuestas potenciales, los propietarios de los riesgos, la calificación
relativa o lista de prioridades de los riesgos del proyecto, una lista de riesgos que requieren
respuesta a corto plazo, una lista de riesgos que requieren un análisis adicional y una
respuesta, las tendencias de los resultados del análisis cualitativo y una lista de supervisión
para los riesgos de baja prioridad.
 El plan de gestión de riesgos en el que se han incluido los roles y las responsabilidades, las
definiciones del análisis de riesgos, la periodicidad de las revisiones (y de la eliminación de
riesgos de la revisión), así como los umbrales de riesgo para los riesgos bajos, moderados o
altos. Los umbrales de riesgo ayudan a identificar los riesgos que requieren respuestas
específicas.
Estrategias de respuesta a los riesgos
Para cada riesgo, se debe seleccionar la estrategia o la combinación de estrategias con mayor
probabilidad de eficacia. Las herramientas de análisis de riesgos, tales como el análisis mediante
árbol de decisiones), pueden utilizarse para seleccionar las respuestas más apropiadas. Se
desarrollan acciones específicas para implementar esa estrategia, incluyendo estrategias
principales y de refuerzo, según sea necesario. Puede desarrollarse un plan de reserva, que se
implementará si la estrategia seleccionada no resulta totalmente efectiva o si se produce un
riesgo aceptado.
También deben revisarse los riesgos secundarios (riesgos provocados por las estrategias). A
menudo, se asigna una reserva para contingencias de tiempo o coste.
Las estrategias siguientes abordan las amenazas o los riesgos que pueden tener impactos
negativos sobre los objetivos del proyecto en caso de ocurrir:
 Evitar. Evitar el riesgo implica cambiar el plan de gestión del proyecto, a fin de eliminar por
completo la amenaza y la causa de la misma. Ejemplos de lo anterior son la ampliación del
plazo del proyecto, el cambio de estrategia o la reducción del alcance. Algunos riesgos que
surgen en etapas tempranas del proyecto pueden ser evitados aclarando los requisitos,
obteniendo información, mejorando la comunicación o aportando experiencia.

276
 Transferir. Transferir el riesgo requiere trasladar a un tercero todo o parte del impacto
negativo de una amenaza, junto con la propiedad de la respuesta. La transferencia de un
riesgo simplemente confiere a una tercera persona la responsabilidad de su gestión; no lo
elimina. Transferir el riesgo casi siempre implica el pago de una prima de riesgo a la parte
que asume el riesgo. Las herramientas de transferencia pueden ser bastante diversas e
incluyen, entre otras, el uso de seguros, garantías de cumplimiento, fianzas, certificados de
garantía, etc. Pueden emplearse contratos para transferir a un tercero la responsabilidad de
riesgos específicos. Por ejemplo, cuando un comprador dispone de capacidades que el
vendedor no posee, puede ser prudente transferir contractualmente al comprador parte del
trabajo junto con sus riesgos correspondientes. En muchos casos, el uso de un contrato de
margen sobre el coste puede transferir el coste del riesgo al comprador, mientras que un
contrato de precio fijo puede transferir el riesgo al vendedor.
 Mitigar. Mitigar el riesgo implica reducir a un umbral aceptable la probabilidad y/o el impacto
de un evento adverso. Adoptar acciones tempranas para reducir la probabilidad de ocurrencia
de un riesgo y/o su impacto sobre el proyecto, a menudo es más efectivo que tratar de reparar
el daño después de ocurrido el riesgo. Ejemplos de acciones tendientes a mitigar un riesgo
son adoptar procesos menos complejos, efectuar más pruebas o seleccionar un proveedor
más estable. Por ejemplo, la mitigación puede requerir la creación de un prototipo para reducir
el riesgo de pasar de un modelo a escala de un proceso o producto a uno de tamaño real.
Cuando no es posible reducir la probabilidad, una respuesta de mitigación puede abordar el
impacto del riesgo, dirigiéndose a los vínculos que determinan su severidad.
 Aceptar. Esta estrategia se adopta en los casos en los que no es posible eliminar todas las
amenazas de un proyecto. Esta estrategia indica que el equipo del proyecto ha decidido no
cambiar el plan de gestión del proyecto para hacer frente a un riesgo, o no ha podido
identificar ninguna otra estrategia de respuesta adecuada. Esta estrategia puede ser pasiva
o activa. La aceptación pasiva no requiere ninguna acción, excepto documentar la estrategia,
dejando que el equipo del proyecto aborde los riesgos conforme se presentan. La estrategia
de aceptación activa más común consiste en establecer un plan de contingencia, que incluya
la cantidad de tiempo, medios financieros o recursos necesarios para abordar los riesgos.
Preparación del presupuesto
Como actividad previa antes del arranque del proyecto, se asignarán los recursos y se
estimarán los costes necesarios para la gestión de riesgos a fin de incluirlos en la línea base
de coste del proyecto.

277
Ejecución
Implementación de las respuestas a los Riesgos
En este proceso se implementarán las acciones de respuestas a los riesgos identificadas y

planificadas en el proceso anterior. El beneficio clave de este proceso es asegurar que las
respuestas a riesgos acordadas se ejecutan tal como se han planificado, con el fin de
controlar la exposición a riesgos del proyecto, minimizar las amenazas individuales del
proyecto, y maximizar las oportunidades individuales del proyecto. Este proceso se lleva a
cabo durante todo el ciclo de vida del proyecto.
Para el establecimiento de las estrategias de respuesta el responsable del proyecto designa

un “Propietario del Riesgo” que normalmente es el miembro del equipo de proyecto mejor
conocedor del riesgo o que es responsable del área donde este se produciría y ha ayudado
en su evaluación cualitativa. Él será el encargado de aplicar las estrategias de respuesta
cuando se hayan planificado, así como de monitorizar constantemente el estado del riesgo.
El Propietario del Riesgo debe proponer las Estrategias de Respuesta, estimar su coste y la
fecha en que debe comenzar su implementación, en aquellos casos en que pueda
establecerse de antemano, e identificar el acontecimiento (Detonante) que anunciará que el
riesgo se va a materializar y que obligará, por tanto, a aplicar las estrategias de respuesta.
Las estrategias implican, en principio, tomar alguna acción. Incluso si la decisión es “no hacer
nada”, debe documentarse esta decisión y justificarse. Además, dependiendo de la
estrategia adoptada y de la severidad del riesgo puede ser necesario definir un plan de
mitigación, encaminado a reducir las probabilidades de que el riesgo se transforme en un
problema real; un plan de contingencia, encaminado a reducir el impacto del riesgo una vez
materializado; o ambos planes:
 Para desarrollar adecuadamente un Plan de Mitigación, es necesario analizar lo más

detalladamente posible las causas del riesgo a mitigar, definir el objetivo concreto del plan,
ver qué paquetes de trabajo están afectados y determinar cuáles son las opciones de
actuación, sus costes e impacto. Una vez seleccionada una opción, es posible que ésta a su
vez sea generadora de nuevos riesgos (denominados riesgos secundarios) y que será
necesario tener en cuenta e incluir, igualmente, en el proceso de gestión de riesgos.
 Los Planes de Contingencia se preparan para el caso de que las acciones preventivas fallen,
e independientemente de cuál sea la estrategia de respuesta asignada al riesgo. Estos
planes deben incluir la definición de un suceso o evento que actúe como avisador
(Detonante) y deben incluir los pasos o acciones concretas a realizar su calendario y
secuencia

278
Una vez que se han definido e implantado las estrategias de respuesta a un riesgo debe
evaluarse el riesgo residual que quedará después de su aplicación. Esta evaluación del riesgo
residual se hace de la misma forma que en la evaluación cualitativa de Riesgos y establece
el nuevo perfil de riesgo del proyecto, dando por supuesto que se aplicarán las estrategias
definidas. Cuando una estrategia reduzca la probabilidad y el impacto de un riesgo tanto que
pueda considerarse eliminado a efectos de la gestión de riesgos, el procedimiento es una
evaluación del riesgo residual indicando bajo en la probabilidad de ocurrencia y en los tres
campos de impacto del riesgo.
Seguimiento y Control
Monitorizar los Riesgos
La Monitorización de los Riesgos del proyecto se realiza durante la ejecución del mismo.
A medida que se avanza en la ejecución del proyecto se sabe más sobre los riesgos del
mismo. A su vez, cada uno de éstos puede evolucionar variando su probabilidad de acontecer
y su impacto en el proyecto y adicionalmente pueden presentarse nuevos riesgos o
identificarse riesgos que no fueron identificados durante la planificación.
El objetivo principal de la Gestión de los Riesgos es anticiparse a los mismos, en todo

momento, para poder minimizar su probabilidad de ocurrencia y/o sus efectos negativos si se
presentan.
Por ello la Monitorización de los Riesgos no puede limitarse a supervisar y controlar el

cumplimiento del plan inicial de riesgos, sino que en cada revisión del proyecto tiene que
considerar el mayor conocimiento que se tenga de los riesgos anteriormente identificados, la
aparición de nuevos riesgos y los riesgos que no habían sido identificados con anterioridad a
la revisión.
La Monitorización de los Riesgos del proyecto debe realizarse en una reunión del equipo del
proyecto liderada por el responsable del mismo con la participación de los expertos y de los
responsables de las áreas organizativas participantes en el proyecto que el responsable del
proyecto considere oportuno. Estas reuniones pueden coincidir con las reuniones periódicas
de seguimiento del proyecto.
Durante el proceso de Monitorización de los Riesgos del proyecto se realizan las actividades
siguientes, preferiblemente, en la secuencia indicada:
1. Se analizan los riesgos para los que se han establecido estrategias de respuesta
 Se revisa la ejecución de las estrategias de respuesta y su efectividad.
 Se define la conveniencia iniciar la aplicación de las acciones de contingencia

279
 Se reconsidera la evaluación de los riesgos residuales
2. Se revisan los riesgos identificados para los que no se han establecido estrategias de
respuesta.
 Se reconsidera la evaluación del riesgo
3. Se identifican si han aparecido riesgos nuevos, que en ese caso deben ser evaluados
e incorporados a lista de riesgos identificados y evaluados
4. Se actualiza la lista priorizada de riesgos con la información de los pasos anteriores
5. Se establecen estrategias de respuesta a los riesgos que proceda en la situación

actualizada y se comunican a los responsables de aplicarlas.

280
2.3.3 Roles y Responsabilidades
A continuación, se definen los miembros del equipo necesarios para la gestión de riesgos del
proyecto, detallando los roles y responsabilidades de los participantes:
Comité de
Riesgos
Gerente de Arquitecto de
Proyecto Solución
Ilustración 92: Roles y Responsabilidades
Detector del Riesgo
El detector del riesgo inicialmente identifica el riesgo y formalmente lo comunica al Gestor del
Riesgo.
El detector del riesgo es formalmente responsable por:
 La temprana identificación del riesgo dentro del proyecto

 La documentación formal del riesgo, completando el formulario de Registro de Riesgo
 La publicación del Registro de Riesgo para la revisión del Jefe del Proyecto.
Gestor del Riesgo
El Gestor del Riesgo recibe, registra, y monitorea el progreso de todos los riesgos del
proyecto. El Gestor del Riesgo es formalmente responsable de:
 Recibir los Registros de Riesgos e identificación de riesgos apropiados para el

proyecto
 Grabar todos los riesgos en el Registro de Riesgos
 Presentar todos los riesgos al Comité de Riesgos
 Reportar y comunicar todas las decisiones tomadas por el Comité de Riesgos

281
 Seguir el progreso y las acciones de mitigación asignadas
Comité de Riesgos
El Comité de Riesgos confirma el riesgo, es decir su probabilidad e impacto, y asigna las

acciones según la estrategia seleccionada para cada riesgo.
El Comité es formalmente responsable de:
 Un regular repaso de los riesgos registrados en el Registro de Riesgos

 La identificación de solicitudes de cambio necesarias para mitigar los riesgos
identificados
 Asignación de acciones para mitigar el riesgo
 El cierre de riesgos que no presentan acciones pendientes y no presentan

probablemente más impacto al proyecto
El Comité de Riesgos estará formado en principio por el Jefe de Proyecto, el Gestor del
Riesgo, y los Responsables de Soporte al Jefe de Proyecto para los distintos equipos de
soporte al Jefe de Proyecto.
Equipo del Proyecto
El Equipo del proyecto está comprometido con las acciones de mitigar el riesgo, delegados
por el Comité de Riesgos.
2.3.4 Calendario
A continuación, se incluye el calendario de las actividades de gestión de los riesgos que se

realizarán durante el ciclo de vida del proyecto, y que se han descrito en los apartados
anteriores.
Al inicio del proyecto, este calendario de actividades de gestión de riesgos se adecuará a las
fechas y calendario específico del proyecto.

282
Inicio Fin
Proyecto Proyecto
Fase Actividad Periodo 0 Periodo 1 Periodo 2 Periodo 3 … … Periodo n

Etapa Precontractual
Evaluación Inicial de Riesgos
Planificación
Planificación de la Gestión de Riesgos
Identificación de Riesgos
Análisis Cualitativo de Riesgos
Análisis Cuantitativo de Riesgos
Planificación de la Respuesta a los Riesgos
Ejecución
Implementar las respuesta a los Riesgos
Seguimiento y Control
Monitorizar los Riesgos
Plan de Plan de Gestión

Gestión de de Riesgos Registros Riesgos
Riesgos Revisado Revisados
Ilustración 93: Calendario
2.3.5 Categorías de Riesgo
Se incluyen a continuación todas las categorías de riesgos identificadas en la taxonomía

utilizada, así como la descripción de las mismas.
Aunque para la ejecución concreta de este proyecto, y dada la fase precontractual en la que
se ha elaborado el Plan de Riesgos, no se han identificado riesgos de todas las subcategorías
descritas, se mantiene el conjunto de todas las categorías, en previsión de que durante la
ejecución del proyecto puedan detectarse riesgos a tipificar dentro de estas categorías.
Asimismo, si alguno de los riesgos identificados no es posible categorizarlo en alguna de las
existentes, se actualizará la taxonomía de riesgos como parte del proceso de mejora
continua:
1. Riesgos País/Comunidad
Riesgos potenciales derivados del país/comunidad de la Compañía y/o donde se
ejecuta y/o entrega el proyecto.
2. Riesgos Cliente
En el Cliente deben considerarse siempre, para la identificación de los riesgos del
proyecto, tres grupos de interés que están afectados por éste, influirán sobre él y
pueden ser causantes de riesgos:
 El/los Patrocinadores del Proyecto (han decidido la ejecución del proyecto y

establecido sus metas y objetivos estratégicos o los beneficios que debe
aportar a la organización, normalmente será la Alta Dirección o un Alto
Directivo)
 Los Usuarios del producto del Proyecto (utilizarán el producto del proyecto
para su trabajo en la Organización)

283
 Los Receptores del producto del Proyecto (reciben el producto del proyecto
y aunque no lo utilizan para su trabajo, deben mantenerlo, actualizarlo, dar
asistencia técnica a los usuarios, integrarlo con otros sistemas
relacionados,…)
3. Riesgos Contractuales
Riesgos derivados del contrato firmado para la ejecución del proyecto. En su
identificación y/o en la definición de las estrategias más adecuadas para su mitigación
debe intervenir conjuntamente los responsables del proyecto y la Asesoría Jurídica
de la Compañía.
4. Riesgos Asociados en el Proyecto

Riesgos derivados de los Asociados en el Proyecto, como por ejemplo otros
miembros de una UTE, partners, consorcios, etc.
5. Riesgos Proveedor / Subcontratista

Riesgos provenientes de los Proveedores y Subcontratistas clave
6. Riesgos asociados a los Requisitos del Producto y/o Entregables del Proyecto
Riesgos potenciales derivados de la naturaleza, novedad, dimensión, complejidad del
productos o productos del proyecto así como de la estabilidad, viabilidad, claridad,
de los requisitos del mismo
7. Riesgos asociados al Proceso y Métodos de Dirección/Gestión del Proyecto y

al Entorno del mismo
Riesgos potenciales al Proceso y Métodos de Dirección / Gestión del Proyecto en el
Entorno en el que se realiza el Proyecto: Consorcio, UTE, ...
8. Riesgos asociados al trabajo específico a realizar

Riesgos potenciales derivados la dificultad del trabajo específico a realizar para
asegurar el cumplimiento de los requisitos definidos para el producto del proyecto y
su integración con el entorno en que debe operar
9. Riesgos asociados a los Procesos y Sistemas de Diseño, Ingeniería, Desarrollo,

Fabricación, Integración y Pruebas a aplicar al Proyecto
Riesgos potenciales derivados del Proceso, la secuencia definida de pasos y tareas
a realizar desde el inicio hasta el final del proyecto; y de los Sistemas, las
herramientas de hardware, software y otros equipos de diseño, ingeniería, desarrollo,
fabricación, integración y pruebas utilizados para realizar los productos del proyecto
10. Riesgos relacionados con los recursos necesarios para la realización del
proyecto

284
Riesgos potenciales asociados a la criticidad, carencia o escasez de los recursos
necesarios para la realización del proyecto
2.3.6 Estructura de Desglose de Riesgos
Ilustración 94: Estructura de Desglose de Riesgos

285
Ilustración 95: Estructura de Desglose de Riesgos

286
2.3.7 Definición de Probabilidad e Impacto de Riesgos
Probabilidad: es la posibilidad de que suceda el riesgo. Los niveles establecidos para

cuantificar la probabilidad son:
Alta Media Baja
Probabilidad de Muy probable que ocurra Puede ocurrir Poco probable que
Ocurrencia ocurra
Del 51% al 100% Del 21% al 50%
Del 0% al 20%
Tabla 38: Probabilidad
Impacto: es el efecto (cuantitativo o cualitativo) que podría tener ese riesgo si se materializa.
Los niveles establecidos para cuantificar el mismo, sobre cada factor objetivo del proyecto,
son:
Factor objetivo
Alto Medio Bajo
Escala
Calendario Retraso de más de un Retraso entre un 5% y Retraso de menos de un

20% sobre la un 20% sobre la 5% sobre la planificación
planificación planificación
Coste Incremento de más de Incremento entre un 5% Incremento de menos de

un 20% sobre el y un 20% sobre el un 5% sobre el
presupuesto presupuesto presupuesto
Alcance No se cumple un No se cumple algún Algunos fallos e

requisito clave o el requisito o entregable incumplimientos sin
producto es inaceptable secundario importancia para el
cliente
Tabla 39: Impacto
2.3.8 Matriz de Probabilidad e Impacto
Matriz de Análisis de Severidad: representa la evaluación cualitativa del riesgo en función

de la probabilidad de que acontezca y su impacto. Servirá para representar los criterios de
tolerancia del proyecto en relación a la prevención de riesgos.
Para cada factor objetivo (calendario, alcance y coste) se cumplimentará la siguiente matriz:

287
Matriz de Probabilidad e impacto (análisis de severidad)
Probabilidad de ocurrir
Alta
Media
Baja
Bajo Medio Alto
Impacto en un factor objetivo
Riesgo crítico Riesgo apreciable Riesgo asumible
Ilustración 96: Matriz de Probabilidades e impacto
Una vez realizada la Evaluación Cualitativa de todos los riesgos identificados para el proyecto se
establece el orden de prioridad de los mismos en función de su severidad, esto es, la posición de
la combinación probabilidad - impacto en la matriz de análisis de severidad de cada uno de los
tres factores objetivo del proyecto: el cumplimiento del calendario establecido, del coste
presupuestado y del alcance acordado, ponderados según los pesos asignados a cada tipo de
impacto:
 Un riesgo sobre el factor objetivo Calendario supone mayor severidad que sobre el factor
objetivo Alcance
 Un riesgo sobre el factor objetivo Alcance supone mayor severidad que sobre el factor
objetivo Coste
Se han asignado los siguientes pesos a cada tipo de impacto (Calendario, coste y alcance):
 Calendario: 50%
 Alcance: 30%
 Coste: 20%
Criterio de priorización de riesgos, para priorizar los riesgos se sigue el criterio:
 Un riesgo crítico supone mayor severidad que cualquier riesgo apreciable (una de las tres
posiciones en la zona roja de la matriz supone una mayor severidad del riesgo que cualquier
número de posiciones en zona amarilla).

288
 Un riesgo apreciable supone mayor severidad que cualquier riesgo asumible (una de las
posiciones en la zona amarilla de la matriz supone una mayor severidad del riesgo que
cualquier número de posiciones en zona verde).
Para calcular la priorización se han asignado los pesos siguientes a la posición de cada tipo de
impacto (Calendario, coste y alcance) en la matriz de análisis de la severidad:
 Cada posición en Rojo: 6 Puntos
 Cada posición en Amarillo: 3 Punto

 Cada posición en Verde: 1 Puntos
Para obtener la evaluación global de la severidad de cada riesgo se suman los puntos obtenidos
por los tres tipos de impacto del riesgo ponderados por el peso del tipo del impacto (Coste,
Calendario y Alcance). Se ordenan los riesgos identificados por orden decreciente de la suma así
obtenida (De 1 a 18).
2.3.9 Valoración de los Principales Riesgos
El análisis (cualitativo y cuantitativo) y clasificación de riesgos capacita al equipo para

cuantificar las prioridades de los distintos riesgos. Los equipos pueden decidir en qué riesgos
se ha de emplear tiempo y esfuerzo.
 Calcular el factor de riesgo, como nivel de exposición global a cada uno de los riesgos
individuales, mediante la valoración entre 0 y 1 de la probabilidad, impacto y
capacidad de controlar del riesgo.
 Asociar a cada riesgo identificado el plazo previsto para reducir la probabilidad de

riesgo.
A continuación se exponen una valoración de los principales riesgos potenciales existentes

(incluyendo los generales).
Leyenda
 Probabilidad de Riesgo. Probabilidad de que aparezca el problema. Los valores estarán

comprendidos entre 1 y 5 (5-Frecuente, 4-.Probable, 3-Ocasional, 2- Remoto, 1-Improbable)
 Impacto del Riesgo. Daño sufrido si aparece el problema que anuncia el riesgo. Los valores
estarán clasificados en 5 niveles (5-Catastrófico, 4-Crítico, 3-Severo, 2-Menor, 1-
Despreciable).
Grado de riesgo al riesgo. En función de la probabilidad y el impacto, se debe asignar un

grado de riesgo al riesgo, que podrá ser: tolerable, bajo, medio, alto o intolerable

289
Impacto Grado
Grupo de Probable causa del Probabilidad de
Código Riesgo Consecuencia del del
Riesgo Riesgo Riesgo
Riesgo Riesgo
Debido a una Podría haber un impacto Lo que podría provocar
3-
R001 General inadecuada Gestión del negativo en la retraso en los tiempos de 2- Remoto Medio
Severo
Cambio organización entrega
Lo que provocaría que la
Debido a una
Podría afectar la Calidad calidad de los servicios que se 3-
R002 General inadecuada Gestión del 2- Remoto Bajo
del Trabajo Final presten pueda no ser el Severo
Cambio
adecuado
Lo que provocaría que el
Debido a una sistema no responda con el
Podría afectar a la
R003 General inadecuada selección rendimiento adecuado o no 2- Remoto 4- Crítico Alto
Infraestructura global
de las herramientas esté disponible cuando se
requiere

Debido a problemas de Podrían existir 3-
sistema no responda 2- Remoto
R004 General integración con problemas con la Severo o Medio
adecuadamente, al no poder
sistemas solución planteada
conectarse a éstas.
Disponibilidad de datos Dificultad para la priorización

Inadecuada calidad de 3-
R005 Migración no del todo adecuados de tareas de pruebas y 3- Ocasional Medio
los datos disponibles Severo
para las pruebas certificación
No disponer del
personal de SUNAT en
Retardo en el proceso 3-
R006 Migración el tiempo necesario Incumplimiento de plazos 3- Ocasional Medio
de certificación Severo
para la realización de
las pruebas.
Desconocimiento de Podría afectar al objetivo Lo que provocaría 3-

Gestión 2- Remoto
R007 las funciones del rol de cubrir un rol del incumplimiento de plazos o Severo Medio
documental
asignado proyecto deficiencias en la solución
Definición general de Poca profundidad del Lo que provocaría un

Gestión
R008 los objetivos análisis de los incumplimiento de plazos y 3- Ocasional 3-Severo Alto
documental
específicos requerimientos mayores costes asociados
Debido a la definición Podría darse una falta Lo que provocaría una
R009 General de alto nivel del alcance de entendimiento de los desviación en plazos, costes y 2- Remoto 4- Crítico Alto
en la propuesta detalles del alcance alcance
Podría existir un
Debido a la falta de desconocimiento del
Lo que provocaría un
R010 Migración precisión del volumen volumen de migración a 3- Ocasional 4-Crítico Medio
incumplimiento de plazos
de datos ejecutar, y sus
condiciones

290
Impacto Grado
Riesgo Riesgo
Debido a la falta de
Podría darse un bajo
costumbre en la Lo que provocaría el rechazo
R011 General nivel de 3- Ocasional 4-Crítico Medio
utilización de sistemas de ser usado por los usuarios
adopción/utilización
de esta naturaleza
Podría darse una
Mala definición de Lo que provocaría una
R012 General indefinición de 3- Ocasional 4- Crítico Alto
indicadores desviación en plazos.
indicadores
Debido a la indecisión
Podría darse una
por parte de los Lo que provocaría una
R013 General indefinición de los 3- Ocasional 3-Severo Medio
responsable en la desviación en plazos.
informes
definición de informes
Podría darse una Lo que provocaría una
Debido a un fallo en la
dependencia en la indisponibilidad de datos,
carga de datos por
R014 Migración provisión de datos de retrasando la generación y 4-Probable 3-Severo Medio
indisponibilidad desde
proyectos migrados e validación de indicadores e
los fuentes
integrados informes
Debido a que el
dimensionamiento de la Podrían darse
Lo que provocaría un
R015 Migración plataforma no ha sido problemas de 3- Ocasional 4-Crítico Medio
incumplimiento de plazos.
correcta en base a la rendimiento
información obtenida
Debido a que el
dimensionamiento de la Podrían darse
Arquitectur Lo que provocaría un
R016 plataforma no ha sido problemas de 3- Ocasional 4-Crítico Medio
a incumplimiento de plazos.
correcta en base a la rendimiento
información obtenida.
Podría darse el caso de
Automatiza que un especialista en
Debido de hechos Lo que provocaría un 3-
R017 ción de las herramientas 3- Ocasional Medio
fortuitos incumplimiento de plazos. Severo
procesos seleccionadas deje de
laborar en el Consorcio.
Debido a que la
Automatiza Podrían darse
definición de los Lo que provocaría un
R018 ción de problemas de 3- Ocasional 4-Crítico Medio
procesos de negocio no incumplimiento de plazos.
procesos rendimiento
han sido detalladas
Debido a la
Podría existir una
documentación
indisponibilidad de Lo que provocaría una
desactualizada o falta
Base Datos información funcional de dificultad para realizar el
R019 de documentación de 4-Probable 4- Crítico Alto
Integrada los sistema a migrar o inventario y mapeo de los
los sistemas que
información datos.
forman parte de la
desactualizada
migración

291
Impacto Grado
Riesgo Riesgo
Podría producirse un
Debido a que el Lo que provocaría un
fallo en la comunicación
mensaje de incumplimiento de plazos y
con los distintos
Base Datos colaboración a los mayores costes asociados al
R020 integradores que 4-Probable 4- Crítico Alto
Integrada integradores no ha sido incremento en el esfuerzo de
actualmente soportan la
lo suficientemente comunicación entre los
operación de los
explicito integradores
diferentes aplicativos
equipo técnico vea reducida
su actividad al no contar con
Podría darse una
Base Datos No hay una causa los servicios necesarios para
R021 dependencia con 5-Frecuente 3-Severo Medio
Integrada inicial seguir con su trabajo, lo que
proyectos de integración
generaría incumplimiento de
plazos y mayores costes
asociados
Lo que generaría retraso en la
Debido a la falta de ejecución de las siguientes
disponibilidad de
Podría generar demora actividades:
tiempo del personal de
en la aprobación de los - Gestionar proyectos
R022 General la Institución para 2-Remoto 3-Severo Medio
documentos entregables - Gestionar el cambio
realizar las tareas de
por la Institución - Transferir conocimiento
aprobación de
documentos en plazo

Debido a la falta de ejecución de las siguientes
disponibilidad de Podría generar demora actividades:
tiempo del personal de en la entrega de
R023 General - Gestionar el cambio 3-Ocasional 3-Severo Medio
la Institución para documentos por la
- Transferir conocimiento
realizar las tareas de Institución
entrega de documentos
Lo que genearía retraso en la

Debido a la falta de Podría generar demora ejecución de las siguientes
R024 General disponibilidad del en la designación y actividades: 3-Ocasional 3-Severo Medio
personal a entrevistar agenda para entrevistas - Gestionar el cambio
- Transferir conocimiento

Podría generar cambio ejecución de las siguientes
Debido a cambios
del personal de actividades:
R025 General organizativos del 2-Remoto 2-Menor Bajo
supervisión para el - Gestionar proyectos
proyecto
proyecto. - Gestionar el cambio
-Transferir conocimiento

292
Impacto Grado
Riesgo Riesgo
Podría generar cambio Retraso en la ejecución de las
Debido a cambios en el de los instrumentos siguientes actividades:
R026 General 2-Remoto 2-Menor Bajo
proyecto aprobados para la
- Gestionar proyectos
gestión del proyecto.
Atraso general del proyecto e
La resistencia al
incremento del costo y
cambio es un riesgo Resistencia al Cambio
esfuerzos en actividades de
R027 General que puede darse por parte del personal de 3-Ocasional 3-Severo Medio
capacitación e información.
siempre en proyectos la Institución
de esta complejidad
Podría generar cambios

de fechas programadas Retraso en la ejecución de las
Debido a imprevistos o
R028 General para la capacitación al siguientes actividades: 3-Ocasional 4-Crítico Medio
hechos fortuitos
Consorcio por parte de - Transferir el conocimiento
SUNAT
Retraso en la ejecución de las
No liberación de otras
No asistencia del siguientes actividades:
funciones para poder
R029 General personal de Institución a - Transferir el conocimiento. 3-Ocasional 3-Severo Medio
acudir a las sesiones
las capacitaciones. - Atraso general del
de capacitación
proyecto.
Falta de disponibilidad
Demora en la
de tiempo del personal
designación de personal
de la Institución para Retraso en la ejecución de
de la Institución para la
R030 General realizar las tareas de las siguientes actividades: 3-Ocasional 4-Crítico Alto
transferencia de
transferencia de - Transferir el conocimiento
conocimiento y
conocimiento y
tecnología
tecnología
Problemas de Problemas de acceso a

Infraestruct Retraso en las actividades del
R031 comunicaciones, fallas la plataforma en la Nube 2-Remoto 3-Severo Medio
ura cronograma.
eléctricas y otros. desde la Organización.
Perdida de datos y/o
Infraestruct Hacker, Malware u Mayor exposición a indisponibilidad de sistemas y
R032 3-Ocasional 4-Crítico Alto
ura otras formas de ataque. ataques de seguridad retardos en la ejecución del
plan.
Falta de coordinación
Épicas no desarrolladas
entre los equipos,
R033 Desarrollo dentro de las fechas Retraso en el cronograma. 3-Ocasional 3-Severo Medio
recursos no
establecidas
disponibles.
Actividades no
identificadas o producto Retrasos de cronograma,
Actividades no
R034 General de la consecuencia de replanificación de tareas y/o 3-Ocasional 2-Menor Bajo
programadas
ciertas acciones dentro retrabajo.
del proyecto.

293
Impacto Grado
Riesgo Riesgo
Falta de coordinación, Entregables
Retraso en la ejecución de
recursos indisponibles, contractuales
R035 General actividades dependientes de 2-Remoto 2-Menor Bajo
incertidumbre en las presentados fuera de
estas.
especificaciones. plazo.
Duplicidad en la fuente
Mala calidad de datos de
Base Datos de datos o mala
R036 la Carga inicial Información inconsistente. 2-Remoto 3-Severo Medio
Integrada especificación de los
datos a extraer.
Indisponibilidad de No se completan los

Falta de coordinación o
R037 usuarios claves entregables en los tiempos 2-Remoto 2-Menor Bajo
hechos fortuitos.
establecidos.
Tabla 40: Riesgos
2.3.10 Plan de Mitigación de Riesgos
El evitar que un riesgo identificado pueda activarse y las acciones encaminadas a ello, es lo
que se denomina prevención o mitigación. Una correcta gestión de riesgos será aquella que
permita disponer de correctos planes o acciones de prevención que eviten la activación del
riesgo, disminuyendo su probabilidad de ocurrencia.
Un riesgo deja de ser riesgo y se convierte en incidencia, cuando las medidas de prevención
han fracasado. Aunque una vez que el riesgo se ha producido y se ha tratado como una
incidencia, es factible planificar y ejecutar, de forma previa a su conversión en problema,
medidas encaminadas a absorber los efectos negativos sobre los costes y la planificación,
de manera que sean lo menos agresivos posibles. A estas acciones se les denomina acciones
de contingencia.
Dado los riesgos identificados, se indica las acciones de Prevención/Mitigación en aquellos

riesgos que se consideran pueden evitarse, y las acciones de Contingencia en aquellos
riesgos que se consideran no pueden evitarse y pueden ocurrir:
Descripción Acción de
Cód. Acción de mitigación Inicio Fin
Riesgo Descripción del riesgo contingencia
Lo que provocaría que los
Podría haber un Ejecutar reuniones con los involucrados a
usuarios que deben utilizar Inicio Fin de
R001 impacto negativo fin de obtener una planificación acorde al
el sistema son reticentes al Proyecto Proyecto
en la organización proyecto.
mismo

294
Promover que la alta dirección esté
involucrada en el seguimiento del proyecto
Lo que provocaría que la a través de la asistencia a reuniones de
Podría afectar la calidad de los trabajos seguimiento.
Inicio Fin de
R002 Calidad del realizados y el servicio que Realizar una correcta elección del equipo
Proyecto Proyecto
Trabajo Final se preste puede no ser el de trabajo y usuarios para la
adecuado determinación de requisitos.
Formación completa y adaptada a cada
perfil
Realizar pruebas de concepto sobre cada
una de las herramientas propuestas, para
el presente proyecto
Plantear redundancia de elementos en el
diseño de la Plataforma, para evitar la
caída del sistema.

Podría afectarse Diseñar Plan de Contingencia a utilizar en
sistema no responde con el
a la los primeros días de la puesta en Inicio Fin de
R003 rendimiento adecuado o no
Infraestructura explotación, con el detalle de acciones Proyecto Proyecto
está disponible cuando se
Global encaminadas para poder suplir a las
requiere
aplicaciones y tratar de que la actividad
siga. Para evitar que una caída de la
infraestructura provoque no poder
acceder a datos almacenados en el
sistema, que son necesarios para la
actividad diaria.
Podrían existir Lo que provocaría que el Planificar y realizar las pruebas de

problemas con la sistema no responda integración con distintos casos de uso Inicio Fin de
R004
solución adecuadamente, al no para garantizar el correcto funcionamiento Proyecto Proyecto
planteada poder conectarse a éstas. cuando el sistema entre en producción.
Substituir
aquella
información que
Disponibilidad de
Dificultad a la hora de Substituir aquella información que no se no se pueda
datos no del todo Inicio Fin de
R005 realizar la priorización en el pueda obtener de los datos por obtener de los
adecuados para Proyecto Proyecto
análisis estimaciones de usuarios expertos datos por
las pruebas
estimaciones
de usuarios
expertos
Retardo en el Adelantar lo antes posible al personal de
Inicio Fin de
R006 proceso de Incumplimiento de plazos certificación los resultados a medida que ----------------
Proyecto Proyecto
certificación estén disponibles

295
Dificultad en encontrar
Podría afectar al
perfiles preparados para Gestionar la contratación y en caso Se recurriría a
objetivo de cubrir Inicio Fin de
R007 ejecutar la gestión necesario requerir soporte técnico de un personal
un rol del Proyecto Proyecto
documental que necesita la equipo desde España. español experto
proyecto
Institución
Establecer un nivel de alcance durante el

Se propondrá
proceso de análisis y toma de requisitos.
Poca profundidad Requisitos insuficientes, un alcance
Inicio Fin de
R008 del análisis de los mal capturados o basado en el
Establecer un marco de objetivos Proyecto Proyecto
requerimientos transmitidos criterio de
concretos para la gestión documental
expertos.
durante el proceso de análisis y definición
Lanzar, a la mayor brevedad, la fase de

Podría darse una No se cuenta con un nivel diseño funcional; este diseño debería Se propondrá
falta de de detalle del alcance, que cubrir de forma inmediata los siguientes un alcance
Inicio
R009 entendimiento de permita gestionar tanto la objetivos: Identificar al público objetivo y la basado en el
Proyecto
los detalles del expectativa del cliente como funcionalidad que va a tener cada uno de criterio de
alcance el trabajo a ejecutar ellos disponible (Portal Público, Intranet, expertos.
Extranet).
Podría existir un No esperar al final de la construcción para Replanificar y

No se tiene información del
desconocimiento elaborar el plan de migración de redimensionar
volumen de información a
del volumen de contenidos, todo lo contrario, planificarlo el equipo una Inicio
R010 migrar, sus peculiaridades,
migración a para que se elabore inmediatamente vez conocido el Proyecto
el número de excepciones
ejecutar, y sus después de tener la aprobación de la volumen a
ni la tecnología subyacente
condiciones Arquitectura de datos. migrar
Realizar actividades de campo con los

usuarios finales para incorporar al gestor
de conocimiento el lenguaje y las
necesidades de sus futuros usuarios.
Incluir planes
Conducir una actividad intensa de
de
Podría darse un dinamización posterior a la implantación
dinamización
bajo nivel de La gestión del conocimiento del sistema Inicio Fin de
R011 activa por parte
adopción/utilizaci puede ser infrautilizada Proyecto Proyecto
del equipo de
ón La Institución puede conducir actividades
proyecto y
que refuercen la utilización de este
Institución
sistema. El Consorcio suele recomendar
el revisar el Plan de RRHH para incorporar
la aportación de conocimiento como parte
de la retribución/ascenso en la
organización.

296
Durante la toma de requerimientos, el
personal de que formará parte de esta Se utilizaría el
fase del proyecto deberá tener una idea criterio de los
Escasa información
Indefinición de clara de los indicadores estratégicos, expertos en BI Inicio Fin de
R012 respecto de los indicadores
indicadores tácticos y operativos que formará parte del para la Proyecto Proyecto
necesarios a implantar
modelo, con la finalidad de construir el definición de los
modelo de datos teniendo como base indicadores.
estos indicadores.
Durante la toma de requerimientos, el
Se propondrá
personal que formará parte de esta fase
Reducido nivel de detalle un modelo de
Indefinición de del proyecto deberá tener una idea clara Inicio Fin de
R013 respecto a los informes a informe basado
informes de los informes estratégicos, tácticos y Proyecto Proyecto
implantar en el criterio de
operativos que serán creados dentro del
los expertos.
alcance del BI.
Las dependencias estarán establecidas Re planificación
Dependencia en dentro de la planificación global del y revisión de
El componente tiene un alto
la provisión de proyecto. actividades.
grado de dependencia con
datos de Inicio Fin de
R014 entidades externas
proyectos Los responsables deberán coordinar y Establecimiento Proyecto Proyecto
(integración) o con
migrados e alertar cualquier retraso que pueda de seguimiento
información a migrar
integrados impactar en el proyecto o proceso extraordinario
impactado.
Dado el volumen de Revisión del volumen de datos y
información que se va a paralelismo de ejecución de procesos
consolidar, es posible previo al inicio de la construcción. Replanificar
Problemas de prever que se tengan dimensionamie Inicio Fin de
R015
rendimiento problemas de rendimiento Realización de pruebas de rendimiento sin nto de Proyecto Proyecto
en las diferentes piezas que esperar a la finalización del ciclo completo plataforma.
componen el componente de desarrollo, para poder valorar la
de BD evolución del entorno.
Análisis de
posibles cuellos
Al ser una arquitectura Anális inicial del dimensionamiento previo de botella y
donde intervienen muchas al inicio de la construcción. tomar las
Problemas de Inicio Fin de
R016 plataformas, algunas de Validación del dimensionamiento antes de decisiones
rendimiento Proyecto Proyecto
ellas podrían ocasionar la preparación de playbooks para los oportunas con
problemas de rendimiento. ambientes de producción. respecto a
software y
hardware.
Es caso personal El personal con Gestionar con el responsable del proyecto
Se recurriría al Inicio Fin de
R017 de las conocimientos en estas y el proveedor la realización de cursos de
apoyo de Proyecto Proyecto
herramientas herramientas no está capacitación sobre la herramienta.

297
seleccionadas en fácilmente disponible en el Gestionar con el responsable del global personal
el mercado local. mercado laboral local. del Centro de Competencia de español experto
Arquitectura del Consorcio la
incorporación el poyo para la capacitación
necesaria
Análisis de
- Revisión del alcance previo al inicio
posibles cuellos
de la construcción
Se prevén problemas de de botella y
rendimiento al ser un tomar las
Problemas de - Realización de pruebas de Inicio Fin de
R018 sistema con una alta decisiones
rendimiento rendimiento sin esperar a la Proyecto Proyecto
concurrencia de personas y oportunas con
finalización del ciclo completo de
procesos respecto a
desarrollo, para poder valorar la
software y
evolución del entorno
hardware.
- Reuniones con los responsables de
Indisponibilidad los sistemas a migrar.
de información
Falta información de los
funcional de los - Solicitar y analizar la documentación Inicio Fin de
R019 modelos de datos de las
sistema a migrar funcional, mapa de procesos, Proyecto Proyecto
fuentes de información
o información modelos de datos, etc.
desactualizada proporcionadas por los
responsables.
Fallo en la
comunicación con
Comunicación no fluida con
los distintos Imprescindible identificar a los
los responsables de las
integradores que colaboradores claves de los distintos
fuentes de datos; dificultad Inicio Fin de
R020 actualmente integradores y mantener el compromiso
en identificar interlocutores Proyecto Proyecto
soportan la de colaboración bajo el soporte de los
válidos entre los distintos
operación de los directores de la Institución.
integradores
distintos
aplicativos
Las dependencias estarán establecidas
dentro de la planificación global del
proyecto.
Dependencia con
Inicio Fin de
R021 proyectos de
Los responsables de cada proyecto Proyecto Proyecto
integración
deberán coordinar y alertar cualquier
retraso que pueda impactar en el proyecto
o proceso impactado.

298
Demora en la aprobación de
los documentos entregables
por Institución que puede
Demora en la
producir retraso en las
aprobación de los
siguientes actividades: Formalizar un mecanismo de aprobación Inicio Fin de
R022 documentos
- Gestionar proyectos con tiempos y criterios estándar. Proyecto Proyecto
entregables por
- Gestionar el cambio
Institución
organizacional
- Transferir el
conocimiento
Demora en la entrega de
documentos por Institución
que puede producir retraso
Demora en la en las siguientes
entrega de actividades: Formular los requerimientos por parte del Inicio Fin de
R023
documentos por - Gestionar proyectos Consorcio con tiempo. Proyecto Proyecto
Institución - Gestionar el cambio
organizacional
- Transferir el
conocimiento
Demora en la designación y
agenda para entrevistas
Institución que puede
Demora en la
designación y Formular los requerimientos de entrevista Inicio Fin de
R024 siguientes actividades:
agenda para por parte del Consorcio con tiempo. Proyecto Proyecto
entrevistas
organizacional
- Transferir el
conocimiento
Cambio del personal de
supervisión del proyecto por
Institución que puede
Cambio del
producir retraso en las Asegurar que la información de la
personal de
siguientes actividades: supervisión de los componentes del Inicio Fin de
R025 supervisión del
- Gestionar proyectos proyecto se encuentre debidamente Proyecto Proyecto
proyecto por
- Gestionar el cambio documentada.
Institución
organizacional
- Transferir el
conocimiento
Cambio de Cambio de instrumentos
instrumentos aprobados para la gestión
Inicio Fin de
R026 aprobados para la del proyecto que puede Evitar bajo cualquier circunstancia.
Proyecto Proyecto
gestión del producir retraso en las
proyecto siguientes actividades:

299
- Gestionar proyectos
Resistencia al cambio por

parte del personal de
Resistencia al
Institución que puede Identificar personal clave de Institución
cambio por parte Inicio Fin de
R027 producir retraso en las con quien iniciar la evangelización del
del personal de Proyecto Proyecto
siguientes actividades: cambio.
Institución
organizacional
Cambio de fechas
programadas para la
capacitación por Institución
Cambio de fechas
que puede producir retraso
programadas
en las siguientes Formular los requerimientos por parte del Inicio Fin de
R028 para la
actividades: Consorcio con tiempo. Proyecto Proyecto
capacitación por
Institución
organizacional
- Transferir el
conocimiento
No asistencia del personal
de Institución a las
capacitaciones que puede
No asistencia del
personal de Formular los requerimientos por parte del Inicio Fin de
R029 siguientes actividades:
Institución a las Consorcio con tiempo. Proyecto Proyecto
capacitaciones
organizacional
- Transferir el
conocimiento
Demora en la designación
Demora en la de personal de Institución
designación de para la transferencia de
personal de conocimiento y tecnología Identificar personal clave de Institución
Inicio Fin de
R030 Institución para la que puede producir retraso con quien iniciar las coordinaciones para
Proyecto Proyecto
transferencia de en las siguientes la transferencia de conocimiento.
conocimiento y actividades:
tecnología. - Transferir el
conocimiento
Problemas de Planificar y realizar las pruebas de
Demora, bloqueos, falta de
acceso a la integración con distintos casos de uso Inicio Fin de
R031 conectividad u otros
plataforma en la para garantizar el correcto funcionamiento Proyecto Proyecto
problemas de acceso a la
Nube cuando el sistema entre en producción

300
plataforma en la Nube
desde la Organización
Al ser una plataforma en la Nube, este
Exposición de ataques que
estará expuesto al ataque de agentes con
Mayor exposición pueden vulnerar la
intenciones maliciosas, con lo que debe Inicio Fin de
R032 a ataques de seguridad y afectar o alterar
llevarse a cabo acciones especiales para Proyecto Proyecto
seguridad la continuación del
proteger la información. Ejecución de
proyecto.
auditorías de seguridad.
Épicas no Épicas no desarrolladas
desarrolladas dentro de las fechas
Se deberá coordinar un plan de atención Inicio Fin de
R033 dentro de las establecidas lo que puede
del stock. Proyecto Proyecto
fechas producir retraso en el
establecidas cronograma.
En caso SUNAT solicite realizar
Las actividades no
actividades no programadas Indra
programadas pueden
estimará el costo esfuerzo de las mismas.
Actividades no generar sobrecostos Inicio Fin de
R034 En caso que el CONSORCIO incurra en
programadas pudiendo afectar a una de Proyecto Proyecto
actividades no programadas debido al no
las partes según sea el
cumplimiento de sus actividades, Indra
caso.
asumirá el sobresfuerzo.
Entregables contractuales
El CONSORCIO optimizará e
Entregables presentados fuera de plazo
incrementará los recursos, esto para
contractuales lo que puede incurrir al Inicio Fin de
R035 velará el cumplimiento de las
presentados retraso de cronograma, si Proyecto Proyecto
presentaciones de los entregables en
fuera de plazo. otro entregable depende de
fechas establecidas.
este.
Velar por la Calidad de
Mala calidad de datos de la Carga inicial Establecimiento temprano de
Inicio Fin de
R036 datos de la Carga para no poner en riesgo la mecanismos de validación. Muestreo y
Proyecto Proyecto
inicial puesta en producción del Pruebas con cuadres de información
MVP1.
Asegurar la disponibilidad
del usuario clave con el fin Publicación de calendarios con
Disponibilidad de Inicio Fin de
R037 de no generar ningún tipo anticipación. Agendas concretas.
usuarios claves Proyecto Proyecto
de retraso en los Previsión de acciones de escalado.
entregables del proyecto.
Tabla 41: Mitigación de Riesgos

301
2.4 Plan de Gestión de Interesados
2.4.1 Introducción
Con el fin de asegurar el cumplimiento de la Gestión de Interesados o Grupos de Interés del

proyecto, se ha elaborado el presente Plan de Gestión de Interesados.
Hay que destacar que el Plan de Gestión de Interesados es un documento vivo sujeto a
revisiones, por lo que se han de considerar estas bajo los siguientes condicionantes:
 Comienzo / finalización de las fases del proyecto.
 Consecuencia de acciones de mejora.
2.4.2 Objetivos y Alcance
La Gestión de los Grupos de Interés o Interesados es clave para el éxito del proyecto, ya que
se considerará que el proyecto culmina con éxito si consigue los beneficios esperados por el
cliente y por los participantes e interesados en el proyecto.
Los interesados en el proyecto son personas u organizaciones que participan activamente en

el proyecto, o cuyos intereses pueden verse afectados positiva o negativamente por la
ejecución o terminación del proyecto. Los interesados también pueden ejercer influencia
sobre el proyecto, los entregables y los miembros del equipo. Por ello, la identificación
adecuada de los interesados es crucial para su correcta gestión posterior, y lograr así cubrir
adecuadamente las expectativas de todos ellos.
El equipo de dirección del proyecto identificará tanto a los interesados internos como
externos, con objeto de determinar los requisitos del proyecto y las expectativas de todas las
partes involucradas. Más aún, el director del proyecto gestionará la influencia de los diversos
interesados con relación a los requisitos del proyecto, para asegurar un resultado exitoso.
Para ello, este Plan de Gestión de Grupos de Interés o Interesados define las distintas
actividades para lograr esa gestión adecuada, desde la identificación de los Interesados, el
modo de involucrarles en la definición de requisitos y su grado de influencia sobre los mismos,
así como el modo de mantenerles involucrados como parte de la Organización del proyecto
y garantizar así la adecuada gestión de expectativas de todos ellos al término del proyecto.
Los procesos en la gestión de Interesados del proyecto son:

302
 Identificar a los interesados que consiste en identificar los distintos Grupos de
Interés y el grado de impacto que pueden ejercer sobre el proyecto.
 Planificar las comunicaciones que consiste en planificar tanto en contenido como

en tiempo los distintos tipos de comunicación que se hará llegar a los Grupos de
Interés identificados para su continua y fluida comunicación que evite conflictos.
 Distribuir la información que consiste en la ejecución del plan de comunicación

definido, tanto en contenido como en tiempo.
 Gestionar las expectativas que consiste en la comunicación activa con los Grupos
de Interés para recoger con la máxima antelación sus necesidades y el grado de
urgencia, e importancia, y poder así ante cualquier incidencia gestionarla con toda la
información de cada Grupo de interés, para su posterior análisis como un cambio o
desviación al Alcance definido.
Los distintos interesados tienen diferentes niveles de responsabilidad y autoridad cuando

participan en un proyecto y éstos pueden cambiar durante el ciclo de vida de este. Su
responsabilidad y autoridad pueden variar desde una participación ocasional en
encuestas y grupos de opinión, hasta el patrocinio total del proyecto, lo cual incluye
proporcionar apoyo financiero y político. Los interesados pueden tener un impacto
adverso en los objetivos del proyecto.
La identificación de los interesados es un proceso continuo y puede resultar difícil. Si

bien, es crucial identificar a los interesados y comprender su grado relativo de influencia
en un proyecto, su impacto para la posterior gestión de expectativas y acciones para
resolver los posibles conflictos y evitar impactos en la duración, alcance, calidad o costes
del proyecto.
La Gestión de las expectativas también se tratará siguiendo este Plan ya que, para los
interesados, un proyecto puede tener resultados tanto positivos como negativos. Algunos
interesados se benefician con el éxito de un proyecto, mientras que otros perciben
resultados negativos como consecuencia del éxito del proyecto.
La Gestión de las expectativas se torna en un aspecto clave en la gestión ya que a

menudo los objetivos de los interesados son muy diferentes o contradictorios. Parte de
las responsabilidades del director del proyecto es balancear estos intereses y asegurarse
de que el equipo del proyecto interactué con los interesados de una manera profesional
y cooperativa.

303
El objetivo del Plan de Gestión de Interesados es proporcionar una guía acerca de cómo
se identificarán, analizará su impacto, y se gestionarán las expectativas de los diferentes
Grupos de Interés dentro del alcance del proyecto.
Los componentes del Plan de Gestión de Interesados son, por tanto:
 Proceso para una Identificación adecuada y continuada de los Grupos de Interés

 Proceso para una correcta Planificación de las Comunicaciones que haga llegar a
todos los Grupos de Interés la información adecuada
 Proceso para la Gestión de las Expectativas de cada grupo de Interés que garantice
la adecuada cobertura de las mismas repercutiendo positivamente en los resultados
del proyecto y evitando conflictos que afecten a la operativa del mismo.
Que se describirán en los apartados siguientes.
2.4.3 Términos y Definiciones
Interesados / Grupos de Interés: Los interesados en el proyecto serán aquellas personas y

organizaciones que estén activamente involucrados en el proyecto, o cuyos intereses pueden
verse afectados de manera positiva o negativa por la ejecución o terminación del proyecto.
Expectativas: Aquellas necesidades o requisitos esperados por parte de un grupo de Interés,

analizado su importancia y urgencia, para evaluar el impacto en el Alcance de proyecto y las
posibles acciones de resolución.
Impacto: Es un factor relacionado directamente con cualquier cambio a realizar en el Sistema. Su

correcto análisis permitirá minimizar y gestionar correctamente los aspectos negativos que la
introducción de dicho cambio puede ocasionar al resto de componentes de la aplicación. El
impacto se contemplará a todos los niveles en que un cambio puede afectar al desarrollo software
como, por ejemplo:
 Impacto en Planificación
 Impacto en Costes
 Impacto en Esfuerzo
 Impacto en Implantación, etc.
2.4.4 Definición de la Gestión de Grupos De Interés
Definir la Gestión de los Grupos de Interés es el proceso que consiste en desarrollar una
identificación y gestión adecuada de cada uno de los grupos de Interés, clasificándolos por

304
su nivel de interés, influencia e impacto, y una posterior definición de la Gestión de sus
expectativas, de modo que se logre alcanzar lo esperado, identificado, evaluado y acordado
como posible dentro del alcance del proyecto, lo considerado como requisitos del proyecto,
al término del proyecto con el menor impacto en el mismo.
Para ello es necesaria la definición y planificación adecuada de las actividades identificadas

como parte de la Gestión de los Grupos de Interés, que se elaborará partiendo de la Bases y
la oferta presentada.
Esta Gestión definida en este plan, la identificación de los interesados hecha, como la
planificación de la comunicación y participación de estos y la gestión de expectativas, se
revisará de modo periódico durante la ejecución del proyecto para ser ajustado a los cambios
que se puedan ir dando a lo largo del mismo.
A continuación, describimos las actividades a realizar para la Gestión de los Grupos de

Interés.
2.4.4.1 Identificación de los grupos de interés
Objetivo: Identificación adecuada de todos los Grupos de Interés que impactan en el proyecto
y sus resultados finales. Esta identificación se realizará partiendo de:
 Las bases de la Licitación Pública.
 La oferta presentada.
 El plan de alcance del proyecto
Para la identificación de los Interesados se recogerán todas las personas u organizaciones

impactadas por el proyecto, y se documentará la información relevante relativa a sus
intereses, participación e impacto en el éxito del proyecto en el Registro de Interesados.
Este documento recogerá las características de cada grupo de interés como, por ejemplo:
 La información de identificación: nombre, puesto en la organización, ubicación, rol en

el proyecto, información de contacto.
 La información de evaluación: principales requisitos, principales expectativas,

influencia potencial en el proyecto, fase en el ciclo de vida donde el interés es mayor.
 La clasificación de los interesados: interno/externo, partidario/neutral/opositor, etc.

305
Por cada grupo de interés se recogerá su posición en la organización, si es el caso, y el nivel
de autoridad. Esta identificación se realizará en el comienzo del proyecto para poder así
planificar las distintas acciones de comunicación y de participación en el proyecto, y poder
así maximizar las influencias positivas y mitigar los impactos negativos potenciales
gestionando adecuadamente sus expectativas.
Tras el registro de los interesados se realizará el análisis de estos, para su clasificación

adecuada. Este análisis identificará los intereses, las expectativas y la influencia de los
interesados, y los relaciona con la finalidad del proyecto, y si fuese el caso, permitirá a
identificar las relaciones con interesados que pueden aprovecharse para crear alianzas y
acuerdos potenciales, a fin de mejorar las probabilidades de éxito del proyecto.
Cada grupo de interés se clasificará en función de dos variables que permitirán establecer
las distintas estrategias a seguir para su gestión:
 Importancia; que indica la capacidad de efectuar cambios en el alcance del proyecto

o ejecución, es decir, su capacidad de Impacto en el proyecto.
 Influencia; que indica su participación o interés activo en el proyecto
Se clasificarán los distintos Grupos de Interés identificados en una gráfica que permita
situarlos según esas dos variables, y en función de ellos se establecerán acciones.
2.4.4.2 Planificación de la comunicación / participación
El objetivo es establecer las necesidades de información de cada grupo de interés

para garantizar su participación en el proyecto en el momento adecuado.
Se planificarán las acciones de información requeridas por las necesidades de cada

grupo de interés y el modo de abordar dichas necesidades, estableciendo por cada
una de ellas; quién necesita (grupo de interés), qué necesita (información), cuándo
la necesita (periodo), cómo le será proporcionada (canal) y por quién (remitente).
Estas acciones resultantes del plan de comunicación serán parte del Plan de proyecto
de modo que se ejecuten en tiempo y modo acorde a las acciones de gestión y
seguimiento definidas.
Cada acción se establecerá en función de cada grupo de interés y las características

identificadas en la anterior fase.
Se establecerán, siempre que se posible, los canales fijados para la comunicación

dentro del proyecto en el plan de proyecto, “Portal del proyecto” y correo electrónico,

306
así como en las mismas reuniones de seguimiento establecidas en el Plan de
proyecto.
2.4.4.3 Distribución de la información
El objetivo es ejecutar en tiempo y forma las acciones de comunicaciones

establecidas en el Plan de comunicación para asegurar que la comunicación
requerida a cada Grupo de interés se ejecuta siguiendo el plan definido para
garantizar la cobertura adecuada de las expectativas de cada grupo participante.
A cada grupo de interés en función de su clasificación (Importancia / Influencia) se le

distribuirá un tipo de información, en un momento del proyecto dado y con el canal
establecido para ello.
La información a remitir estará relacionada con el comportamiento del proyecto, el

rango de consecución de los resultados y alcance definido, por lo tanto, con la
cobertura del plan definido. Asimismo, a cada grupo se le informara de futuras
acciones planificadas en el Plan de proyecto que pudiera afectarle, ya sean por la
necesidad de su participación según planificación o ante cambios o hechos
acontecidos.
Entre los distintos tipos de información a remitir se encuentran:
 Notificaciones a los interesados. Información para suministrar a los interesados

sobre incidentes resueltos, cambios aprobados y estado general del proyecto.
 Informes del proyecto. Los informes del proyecto que se elaboren según el Plan de
proyecto, con el contenido y periodicidad en este fijado.
 Entregables del proyecto. Aquellos entregables de información definidos en el Plan

de proyecto que se consideren de valor para los Grupos de Interés.
2.4.4.4 Gestionar las expectativas
El objetivo es lograr que los Grupos de Interés apoyen la ejecución definida y

acordada del proyecto al conocer los beneficios y riesgos de este.
La gestión de expectativas permitirá comunicarse y trabajar en colaboración con los

Grupos de Interés para satisfacer sus necesidades y abordar los problemas a medida
que se presentan, manteniendo una comunicación fluida con los Grupos de Interés

307
bidireccional, de modo que se puedan abordar de modo ágil e inmediato sus
inquietudes o problemas y resolverlos de modo eficiente, para que no impacten en el
resultado final del proyecto.
De este modo se pretende garantizar la ejecución del proyecto según el alcance

definido de tiempo, calidad y coste, y disminuir los riesgos de este, ya que los Grupos
de interés que pudieran impactar de modo negativo en el mismo, conocen de
antemano los beneficios y riesgos del mismo y se logra así que lo apoyen de forma
activa y ayudar en la evaluación de los riesgos asociados con las elecciones del
proyecto.
El responsable de proyecto gestionará las expectativas de los interesados de modo

activo, mediante las reuniones de seguimiento, la comunicación bidireccional con los
Grupos de Interés y otras acciones según se haya establecido en el plan de
comunicación, con el objetivo de disminuir el riesgo de que el proyecto no alcance
sus objetivos y metas por causa de incidentes no resueltos a nivel de los interesados
y limitar así las interrupciones durante el proyecto.
En función de las necesidades y expectativas recogidas en el Plan de proyecto por

parte de cada grupo y conocidas las acciones de comunicación planificadas, se
llevará a cabo la gestión de expectativas en las mismas reuniones de seguimiento
establecidas en el Plan de proyecto, de modo que se recogerán en las actas de
reunión las incidencias que surjan, identificando el Grupo de Interés origen, la
resolución a la incidencia, su prioridad y la persona responsable de su seguimiento y
resolución, ya que se tratará como un cambio o desviación tal y como se define en el
Plan de Gestión del Alcance.
El estado de las incidencias recopiladas y su gestión hasta la resolución se hará

siguiendo el proceso de seguimiento definido en el Plan de proyecto.
2.4.5 Registro de interesados
A continuación, tabla preliminar del análisis de interesados recolectados de las bases.

308
Interesado Descripción Sector
Este comité se constituye en la instancia máxima para la
Comité Directivo. Sunat
toma de decisiones, se reunirá a solicitud de LA SUNAT
Se constituye en una instancia de coordinación y
supervisión y tiene como finalidad velar por la correcta
Comité Técnico. marcha del servicio en todos los aspectos considerados en Sunat
el contrato y documentos complementarios que formen
parte del mismo se reunirá a solicitud de LA SUNAT
Profesionales a dedicación exclusiva y completa para la
Personal clave Consorcio
presentación del servicio.
Gerente de
Responsable por las actividades de gerencia del equipo,
Proyecto (a ser
haciendo el control de estatus y actuando como facilitador Sunat
designado por LA
para los demás equipos.
SUNAT).
Funcionarios SUNAT, con el rol de lider usuario en el
Lider Usuario Sunat
proyecto.
Funcionario SUNAT, con el rol de lider técnico en el
Lider Tecnico Sunat
proyecto
Funcionario SUNAT, con el rol de lider Normativo en el
Lider Normativo Sunat
proyecto
Unidad Ejecutora
Mejoramiento del Responsables de la supervisión y administración del
Sistema de contrato, previa opinión técnica favorable de las áreas que Sunat
Información de la se detallan por entregable.
SUNAT
Funcionarios SUNAT, que utilizarán los módulos que se
Usuarios Internos Sunat
implementan en el proyecto.
Alta Dirección Directivos con toma de decisiones en SUNAT. Sunat
También conocidos como usuarios externos, son usuarios
Contribuyentes con acceso a consultas y opciones que se implementen en Externo
el sistema.
Gerente General
Profesional designado por el consorco con poder para su
(Representante Consorcio
representación legal
Legal Consorcio)
Jefe de Proyeto Profesional responsable de la gestion y seguimiento del
Consorcio
Consorcio proyecto

309
Director de
Maximo responsable del proyecto por parte del consorcio Consorcio
Proyecto
Tabla 42: Interesados
2.4.6 Áreas que deberán dar opinión favorable
Id Entregable Áreas que deberán dar opinión favorable
 Gerencia de Procesos y Proyectos de

Plan de Gestión del
E1 Sistemas.
Proyecto
 Gerencia Normativa de Procesos
 Gerencia de Arquitectura.
 Gerencia de Calidad de Sistemas.
Informe de
 Gerencia de Desarrollo de Sistemas.
preparación de
E2  Gerencia de Operaciones y Soporte a
ambientes de
Usuarios.
Desarrollo y Pruebas
 Oficina de Seguridad Informática.
Informe de  Gerencia de Calidad de Sistemas.
implementación del  Gerencia de Desarrollo de Sistemas.
E3 Release 1 y creación  Gerencia de Operaciones y Soporte a
de ambiente de pre- Usuarios.
producción  Oficina de Seguridad Informática.
Gerencia Normativa de Procesos
 Gerencia de Operaciones y Soporte a

Informe de Puesta en Usuarios
producción del MVP1  Gerencia de Arquitectura.
E4 y creación de  Gerencia de Calidad de Sistemas.
ambiente de  Gerencia de Desarrollo de Sistemas.
producción  Oficina de Seguridad Informática.

310
Informe de carga  Gerencia de Desarrollo de Sistemas.
E5 inicial de datos del  Gerencia de Operaciones y Soporte a
MVP1 Usuarios.
Informe de  Gerencia de Desarrollo de Sistemas.
E6 implementación del  Gerencia de Operaciones y Soporte a
Release 4 Usuarios.

Usuarios
Informe de Puesta en
E7  Gerencia de Calidad de Sistemas.
producción del MVP2

Usuarios
Informe de carga  Gerencia de Arquitectura.
E8 inicial de datos del  Gerencia de Calidad de Sistemas.
MVP2  Gerencia de Desarrollo de Sistemas.
Informe de Migración  Gerencia de Arquitectura.

E9 de los ambientes de

311

Usuarios.
Informe de  Gerencia de Calidad de Sistemas.

Capacitación y  Gerencia de Procesos y Proyectos de
E10
Transferencia de Sistemas.
Conocimientos  Gerencia Normativa de Procesos.

Informe de
 Gerencia de Calidad
E11 Mantenimiento
Correctivo y Soporte
Usuarios.
 Gerencia de Procesos y Proyectos de

Informe final del Sistemas.
E12
Proyecto
Tabla 43: Entregables

312
2.5 Plan de Gestión de Comunicaciones
Basándose en la pirámide de satisfacción de Nieder y Zimmerman donde se determina

que la resistencia al cambio es una sucesión de los siguientes niveles:
 No Quiere,
 No Puede,
 No Sabe,
Para superar el primer nivel de resistencia, “No Sabe”, se tendría que satisfacer la
necesidad de conocimiento de las personas que forman parte de la organización. El
objetivo pasa por dar respuesta a las preguntas que la gente se formula, tales como:
 ¿qué está ocurriendo?
 ¿por qué estamos haciendo esto?
 ¿cómo se va a hacer?
 ¿cuándo se va a hacer?
 ¿a quién le va a afectar?
Para enfrentarse a este nivel es necesario definir un plan de comunicación que

contenga el conjunto de medidas que se va a aplicar.
Una vez que se satisfaga la necesidad de saber, los implicados estarán más abiertos al
aprendizaje de nuevas habilidades y destrezas relacionadas con el cambio. Por lo tanto,
ya se estaría en condiciones de liquidar el siguiente nivel, “No Puede”. Para esto se
tendrá que elaborar un plan de formación en el que se ofrecerá a los participantes,
nuevas capacidades y conocimientos en relación al cambio con el que se están
enfrentando o que directamente aumentará su disposición para realizar nuevas
actividades.
Una vez adquiridas estas nuevas habilidades, los implicados tendrán la confianza
necesaria para superar la falta de voluntad de cambio. El deseo de cambio se sitúa en
el nivel más alto de la pirámide y sobre él tienen repercusión las medidas que se tomaron
en los niveles anteriores. Pero, además, habrá que adoptar otras medidas específicas
relacionadas con el propio “ego” de los implicados de manera que éstos den un paso
definitivo para superar la resistencia. Entre las medidas que se pueden adoptar se
encuentran:

313
 El establecimiento de objetivos de desempeño individuales y de equipo que estén
en línea con los cambios que se quieren conseguir.
 La medida de las personas respecto de estos objetivos.
 El establecimiento de mecanismos eficaces de coaching y feedback.
 El reconocimiento y la recompensa de las personas por conseguir los objetivos e

implantar los cambios.
En otras palabras, se debe llevar a cabo una evaluación y seguimiento de los afectados
por el cambio para vencer definitivamente el último paso de la pirámide de satisfacción.
Ilustración 97: Pirámide de satisfacción
Tras esta reflexión, las etapas serían:
 Plan de comunicación: en función de los implicados y roles asignados, y en base

al análisis realizado, se diseñará un plan de comunicación con el que difundir la
estrategia y objetivos que se persiguen con el cambio, para así involucrar a toda la
organización. Particularizado por perfil y rol en el sistema.
 Plan de formación: todo cambio va a necesitar que las personas implicadas

reciban la formación necesaria para adquirir las capacidades que precise la nueva
situación.
Por ejemplo, si se instala una nueva aplicación se tendrán que impartir cursos para
que las personas que tienen que usarla cuenten con los conocimientos adecuados;
si no se conocen los fundamentos básicos tecnológicos, se deberá impartir
formación en aspectos tales como el uso de Internet, ofimática, firma digital, etc.
 Evaluación y seguimiento: Se tienen que llevar a cabo actividades destinadas a

evaluar la gestión del cambio y, en consecuencia, actuar si fuese preciso,
redimensionar o llevar a cabo acciones que corrijan comportamientos inadecuados
frente al perseguido. Para eso tendremos que contar con dos fuentes de

314
información: el propio proyecto de gestión del cambio y el proyecto tecnológico
puesto en marcha.
No hay que olvidar que el proyecto de gestión del cambio está íntimamente
asociado con el proyecto tecnológico y hay que conseguir que la comunicación y la
información entre ambos fluyan adecuadamente para que las decisiones que se
tomen en cualquier sentido se determinen en base a una información correcta y
completa de la situación de la entidad.
Para desarrollar todas las medidas que requiere esta metodología, se tiene que
contar con el respaldo de los equipos que más conozcan cada entidad y las
personas que la forman. Los que respalden las medidas a desarrollar serán los que
instrumentalizarán el proyecto de gestión del cambio.
Por otra parte, se tiene que contar con la información relativa al proyecto tecnológico
que se inicie y, por lo tanto, con la colaboración de los responsables técnicos
de éste.
Con esto es posible contar con una información completa y exhaustiva que permita
que la toma de decisiones sea consecuente con la situación real.
2.5.1 Introducción
En este plan se describen las actividades necesarias para asegurar que las comunicaciones
relevantes del Proyecto se recogen, se distribuyen a los interesados oportunos y se
almacenan para su posterior uso.
Este Plan tiene como objetivos principales:
 Mantener a los interesados informados sobre las necesidades, planificación, alcance, y

seguimiento del proyecto.
 Proveer información clara para la toma de decisiones y seguimiento del proyecto.
 Dar la oportunidad a los interesados de facilitar feedback sobre la información del
proyecto.
Consideraciones importantes que es necesario tener en cuenta son:
 Identificar quiénes necesitan la información y quién está autorizado para trasmitirla.

 Cuando necesitarán esta información (en los diferentes momentos del proyecto).
 Dónde debe alojarse la información y comunicaciones.
 Qué formato/s debe adoptar.

315
 Cómo puede accederse a esa información, así como, otros aspectos de tipo cultural,
barreras de lenguaje, etc. relacionado.
2.5.2 Definiciones y Siglas
Stakeholders: Interesados o partes interesadas. Cualquier persona, grupo u organización

que se ve afectada por el desarrollo del proyecto.
Interesados: Los interesados en el proyecto serán aquellas personas y organizaciones que

estén activamente involucrados en el proyecto, o cuyos intereses pueden verse afectados de
manera positiva o negativa por la ejecución o terminación del proyecto.

316
2.5.3 Roles y Responsabilidades
Gerente del Proyecto
Es el responsable del proyecto y lidera activamente el proceso de Gestión de la

Comunicación estableciendo:
 Identificar las partes interesadas del proyecto.

 Establecer qué información se ha de distribuir a estas partes interesadas, cuándo y a
través de qué medio.
 Facilitar una comunicación abierta y honesta tanto con el equipo de proyecto como con
Dirección y las partes interesadas.
 Controlar la efectividad de la comunicación.
 Gestionar las peticiones de información ad-hoc que surjan, diseñando previamente el
procedimiento de recepción y tratamiento de las mismas, que se comunicará a las partes
interesadas del proyecto, con el fin de gestionar las expectativas de estos grupos.
 Gestionar la aprobación y la aplicación de las medidas correctivas que se consideren
necesarias para la mejora o adecuación de las comunicaciones.
Partes interesadas
Reciben la información del proyecto, según se ha establecido en el Plan de Comunicaciones.

Así mismo, generan peticiones de datos ad-hoc, que tendrán que ser tratadas por el equipo
de proyecto.
Equipo de Proyecto
Los miembros del equipo de proyecto:
 Participan en la planificación de la comunicación.

 Han de asegurar que esta comunicación se distribuye, es entendida y fluye a las
personas que han de estar informadas.
 Colaboran en la realización de los controles necesarios para detectar posibles acciones
correctivas, colaborando también en implantar dichas acciones correctivas.

317
2.5.4 Tabla de Comunicaciones
Tipo de Responsable de
Medio Tipo de Entrega Frecuencia Contenido Destinatario por SUNAT
Comunicación Comunicar
Director de
Comunicación Escrita
Reunión Actas de reunión Proyecto / Jefe de Cuando se requiera Se distribuyen luego de cada reunión. Comité Directivo.
y/o Verbal
Proyeto Consorcio
Comunicación Escrita Jefe de Proyeto
Reunión Actas de reunión Cuando se requiera Se distribuyen luego de cada reunión. Comité Técnico.
y/o Verbal Consorcio
Comunicación Escrita Avance del Jefe de Proyeto Retro-alimentación del estado del proyecto, riesgos Gerente de Proyecto (a ser
Reunión Mensual
y/o Verbal Proyecto Consorcio / problemas identificados. designado por LA SUNAT).
Comunicaciones frecuentes entre los integrantes del
Comunicación Escrita proyecto, entre equipos y a la gerencia para:
Correo y/o Reunión Mensaje de correo Personal clave Cuando se requiera Lider Tecnico
y/o Verbal solución de problemas, revisión de estados, retrasos
y recolección de información.
En caso se aprueben cambios, los usuarios clave
Director de enviarán información al Equipo de Proyecto para las
Entrega física por Mesa Según lo planificado Gerente de Proyecto (a ser
Comunicación Escrita Entregables Proyecto / Jefe de estimaciones e informarán al Gerente de Proyecto
de Partes en el cronograma designado por LA SUNAT).
Proyeto Consorcio los cambios para proceder con la actualización del
cronograma.
Informes con las Informes con las actividades de soporte,

Jefe de Proyeto Según lo indicado en
Comunicación Escrita Correo electrónico. actividades de identificando la cronología de actividades y el Lider Usuario
Consorcio Bases
soporte estatus de los tickets de soporte.
Un informe detallado de la emergencia, las medidas

correctivas tomadas y las acciones preventivas
Informe Técnicos de Director de
Según lo indicado en recomendadas. Gerente de Proyecto (a ser
Comunicación Escrita Correo electrónico. Atención de Proyecto / Jefe de
Bases Acciones tomadas durante la incidencia sean designado por LA SUNAT).
Incidencias Proyeto Consorcio
reportadas formalmente luego de aplicada la
solución.
Reunión para solución de problemas y recolección
Comunicación Escrita Correo electrónico. Acta de reunión Personal clave A demanda Lider Normativo/Usuarios Internos
de información.
Director de Unidad Ejecutora Mejoramiento
Informe ejecutivo del estado del proyecto, riesgos /
Comunicación Escrita Correo electrónico. Informe ejecutivo Proyecto / Jefe de A demanda del Sistema de Información de la
problemas identificados.
Proyeto Consorcio SUNAT
Director de Informe ejecutivo del estado del proyecto, riesgos /
Comunicación Escrita Correo y/o Reunión Informe ejecutivo A demanda Alta Dirección
Proyecto / Jefe de problemas identificados.
Registro de
Comunicación Escrita Recolección de información (perspectivas y/o
Reunión perspectivas / Personal clave A demanda Contribuyentes
y/o Verbal. Requerimientos)
Requerimientos
Gerente General
Comunicación Escrita Reunión para solución de problemas, revisión de
Reunión Acta de Acuerdos (Representante A demanda Comité Directivo.
y/o Verbal estados y retrasos.
Legal Consorcio)
Tabla 44: Tabla: Matriz de Comunicaciones

318
3 Organización y Dotación de Personal
3.1 Organigrama
A continuación, se muestra el Organigrama del proyecto:
Ilustración 98: Organigrama

Leyenda:
Equipo Clave
Equipo No Clave

319
El organigrama está muy relacionado con el modelo de relación establecido, y los diferentes niveles de supervisión y control explicados, como puede verse
en el siguiente gráfico:
Ilustración 99: Modelo de Relación y Niveles de Supervisión y Control

320
Los equipos Scrum (de desarrollo y mantenimiento) estarán formados por un Proxy Product Owner,
un Scrum Master (uno para cada dos equipos), un diseñador UX, tres desarrolladores de Back-End,
dos de Front-End, un tester y un experto en BBDD. El número de equipos variará según los productos
(MVPn).
De forma transversal se constituirá un equipo de apoyo en España, conformado por:
o Expertos tributarios
o Ágil coach
o Especialistas DevOps
o Especialistas Cloud
o Especialistas UX
3.2 Matriz de Responsabilidades
La siguiente matriz muestra las actividades de alto nivel que desempeñará cada miembro del equipo
propuesto.

321
RESPONSABILIDADES DEL EQUIPO POR
SUNAT CONSORCIO
ACTIVIDADES
No Entregables - Fases DPS JPS POS LTS LUS ETS JPI EF EMA AN AD LD ESI RT UX EDO EGC DES
D-1 Fase de Gestión
Planificación
E-1 Plan de Gestión del Proyecto
Plan de gestión de los interesados
Entrega del Plan a SUNAT I A I I I I R I I I I I I I I I I I
Aprobación de SUNAT A R R R R C C I I I I I I I I I I I
Plan para la gestión del alcance A R R R R C C I I I I I I I I I I I
Plan de gestión de los requisitos A R R R R C C I I I I I I I I I I I
Línea base del alcance A R R R R C C I I I I I I I I I I I
Entrega de Línea base del alcance I A I I I I R I I I I I I I I I I I
Plan de gestión del cronograma A R R R R C C I I I I I I I I I I I
Plan de gestión de los riesgos A R R R R C C I I I I I I I I I I I
Plan de gestión de los recursos A R R R R C C I I I I I I I I I I I
Plan de gestión de los costos A R R R R C C I I I I I I I I I I I
Línea base del cronograma A R R R R C C I I I I I I I I I I I
Entrega de Línea base del I A I I I I R I I I I I I I I I I I
Cronograma del proyecto A R R R R C C I I I I I I I I I I I
Entrega del Cronograma a SUNAT I A I I I I R I I I I I I I I I I I
Plan de gestión de la calidad A R R R R C C I I I I I I I I I I I
Plan de gestión de las comunicaciones A R R R R C C I I I I I I I I I I I
Entrega del Plan a SUNAT I A I
Superintendencia I
Nacional I
de Aduanas yI de Administración
R I Tributaria
I - SUNAT
I I I I I I I I I
Aprobación de SUNAT A “Unidad
R Ejecutora
R Mejoramiento
R R del Sistema
C de Información
C I de la SUNAT
I I
- MSI” I I I I I I I I
Plan de gestión de las adquisiciones A R R R R C C I I I I I I I I I I I
Entrega del Plan a SUNAT I A I I SPI N°I001-2019-SUNAT/BID
I R I I I I I I I I I I I
Aprobación“CONTRATACIÓN
de SUNAT DEL SERVICIO DEADESARROLLO,
R PRUEBAS
R Y PUESTA
R EN
R PRODUCCIÓN
C DEL
C SISTEMA I DE CUENTA
I ÚNICA
I DE CONTRIBUYENTE
I I – MVP1
I Y MVP2”
I I I I I
Plan de gestión del cambio A R R R R C C I I I I I I I I I I322 I
Plan de Gestión Aprobado A R R R R C C I I I I I I I I I I I
Línea base del cronograma A R R R R C C I I I I I I I I I I I
Entrega de Línea base del I A I I I I R I I I I I I I I I I I
Cronograma del proyecto A R R R R C C I I I I I I I I I I I
Entrega del Cronograma a SUNAT I A I I I I R I I I I I I I I I I I
Plan de gestión de la calidad A R R R R C C I I I I I I I I I I I
Plan de gestión de las comunicaciones A R R R R C C I I I I I I I I I I I
Plan de gestión de las adquisiciones A R R R R C C I I I I I I I I I I I
Plan de gestión del cambio A R R R R C C I I I I I I I I I I I
Plan de Gestión Aprobado A R R R R C C I I I I I I I I I I I
Seguimiento y Control del Proyecto I A C C C C R C C C C C C C C C C C
D-2 Finalización
E-12 Informe final del Proyecto I A I I I I R I I I I I I I I I I I
Informe Final de Proyecto Aprobado A R R R R C I I I I I I I I I I I I
Fase Carga Inicial de Datos
Etapa de Preparación de Ambientes
Planificación de la Carga Inicial de I A I I I I R R I I R I I I I I
Estrategía
Realizar Estrategia I A C C C C R R C C R C R C
Entrega del informe Final de I A I I I I R R I I R I I I I I
Etapa de Implementación de la Carga
Inventariar Fuentes
Recibir Capacitacion de Legados A R R R R C I I I I I I I I I I I I
Realizar Inventario y Mapeo de las 6 I A C C C R C R C C C R C
Realizar Modelo de Datos - MVP1 y I A C C C C R C C C R R C R R
Realizar Migración I A C C C R C R C C C R C
Efectuar pruebas de Migración I A C C C C R R C C C R C R R
E-5 Informe de carga inicial de
Entrega del Informe a SUNAT I A I I I I R I I I I I I I I I I I
Fase de Desarrollo, Pruebas y Puesta en
Etapa Preparación de Ambientes
Ambientes de Desarrollo y Pruebas I A C C C R C R R C R R C
Preparación lineamientos de
infraestructura y ambientes, I A C C C R C R R C R R C
Recepción de la Información Necesaria I A C C C C R C C R R C R C C
Instalación Configuraciones Base I A C C C R C R R C R R C
Creación y configuración VPN I A C C C R C R R C R R C
Tunning y Pruebas de Componentes de I Superintendencia
A C Nacional
C de Aduanas
C R
y de Administración C - SUNAT
Tributaria R R C R R C
E-2 Informe de preparación de “Unidad Ejecutora Mejoramiento del Sistema de Información de la SUNAT - MSI”
Aprobación de SUNAT A R R R SPI N° R C I
001-2019-SUNAT/BID I I I I I I I I I I I
Apoyo en“CONTRATACIÓN
Instalación y Configuración de
DEL SERVICIO DE DESARROLLO,
I A PRUEBASC Y PUESTA
C ENCPRODUCCIÓN DEL R SISTEMA DE CUENTA
C ÚNICA
R DE
R CONTRIBUYENTE
C R – MVP1
R Y MVP2” C
Ambientes de Preproducción y Producción
Etapa Desarrollo, Pruebas y Puesta en
323
Realizar MVP 1
Entrega del informe final MVP 1 a I A I I I I R I I I I I I I I I I I
Aprobación de SUNAT A R R R R C I I I I I I I I I I I I
Fase de Desarrollo, Pruebas y Puesta en
Etapa Preparación de Ambientes
Ambientes de Desarrollo y Pruebas I A C C C R C R R C R R C
Preparación lineamientos de
infraestructura y ambientes, I A C C C R C R R C R R C
Recepción de la Información Necesaria I A C C C C R C C R R C R C C
Instalación Configuraciones Base I A C C C R C R R C R R C
Creación y configuración VPN I A C C C R C R R C R R C
Tunning y Pruebas de Componentes de I A C C C R C R R C R R C
E-2 Informe de preparación de
Apoyo en Instalación y Configuración de
I A C C C R C R R C R R C
Ambientes de Preproducción y Producción
Realizar MVP 1
Entrega del informe final MVP 1 a I A I I I I R I I I I I I I I I I I
Incremento de Producto 1 I A C C C C R C C C R R C R R
SPRINT 0 I A C C C C R C C C R R C R R
RELEASE 1
E-3 Informe de implementación del
Release 1 y creación de ambiente de
Incremento de Producto 2
RELEASE 2 I A C C C C R C C C R R C R R
RELEASE 3
E4 – Informe de Puesta en
Validación y Correccion
RELEASE 4
E6 - Informe de implementación del
RELEASE 5
SPRINT 12 I Superintendencia
A C Nacional
C de Aduanas
C yCde Administración
R C Tributaria
C - SUNAT
C R R C R R
SPRINT 13 I “UnidadAEjecutora
C Mejoramiento
C Cdel Sistema
C de Información
R C de la C
SUNAT - C
MSI” R R C R R
RELEASE 6 SPI N° 001-2019-SUNAT/BID
SPRINT“CONTRATACIÓN
14 I
DEL SERVICIO DE DESARROLLO, A PRUEBAS
C Y PUESTA
C ENCPRODUCCIÓN
C R SISTEMA
DEL C DE CUENTA
C C
ÚNICA DERCONTRIBUYENTE
R C – MVP1
R Y MVP2” R
324
SPRINT 7
RELEASE 4
E6 - Informe de implementación del
RELEASE 5
RELEASE 6
Fase de Migración Desarrollo y Pruebas
Etapa Instalación, Configuración y
Migración de Ambientes de Desarrollo y
E9 – Informe de Migración de los
Entrega del Informe de conformidad I A I I I I R I I I I I I I I I I I
Fase de Capacitación y Transferenica de
Capacitación Técnica al personal de la I A C C C R R R R C R R C
E10 - Informe de Capacitación y
Entrega del Informe de conformidad I A I I I I R I I I I I I I I I I I
Fase de Mantenimiento Correctivo y
Mantenimiento Correctivo
Soporte y Operación
E11 - Informe de Mantenimiento
Prestación Accesoria: Mantenimiento
E11-1 - Informe de Actividades de
E11-2 - Informe de Actividades de
E11-3- Informe de Actividades de
Tabla 45: Matriz RACI

325
DPS Director de Proyecto de la SUNAT.
JPS Jefe de proyecto por parte del CONSORCIO
POS Líder Normativo (Product Owner) y Equipo Normativo.
SUNAT
LTS Líder Técnico y Equipo Técnico.
LUS Líder Usuario y Equipo Usuario.
ETS Equipo de trabajo del Proyecto
JPI Jefe de proyecto por parte del CONSORCIO
EF Especialista Funcional
EMA Especialista en Metodología Ágil
AN Arquitecto de TI en Nube
AD Arquitecto de Datos
LD Líder de Desarrollo
CONSORCIO
ESI Especialista en Seguridad Informática
RT Responsable de Testing
UX Responsable UX
EDO Especialista DevOps
EGC Especialista en Gestión del Calidad
DES Desarrollador
Tabla 46: Roles - Matriz RACI
R Responsable de ejecutar la tarea

Asegura que la tarea se cumpla aunque no sea directamente
A
Responsabilidades responsable
C Debe ser consultado
I Debe ser informado
Tabla 47: Responsabilidades - Matriz RACI

326
3.3 Definición de Roles y Cantidad de Recursos por Rol
A continuación, se enumeran las responsabilidades específicas de cada uno de los miembros
del equipo.
3.3.1 Organización del Equipo
 Equipos clave.
En el proyecto participarán dos equipos, denominados “clave”, si bien el equipo clave que
estraá en el día a día del proyecto y cuyos CV son presentados en la oferta serán
todos perfiles locales, siendo el equipo clave de España y equipo de apoyo.
Los equipos clave darán servicio y alimentarán a los equipos Agile que desarrollarán las
distintas entregas que se realizarán a lo largo de la vida del proyecto.
 Equipo Especialista DevOps.
 Equipo Especialista Cloud.
 Equipo Multidisciplinar. Este equipo ágil multidisciplinar dispondrá de los perfiles

necesarios para poder completar cada historia de usuario de la pila de producto, de
tal manera que dispongan de las habilidades necesarias para poder planificar con
garantías el alcance de un Sprint.
Identificación de Roles Transversales
 Identificación del rol de Jefe de Proyecto por parte de LA SUNAT.
 Identificación del rol de Product Owner por parte de LA SUNAT.
 Identificación de los responsables de cada área por parte de LA SUNAT

correspondientes a desarrollo, calidad, operación, arquitectura, y seguridad de la
información.
 Identificación del rol de Jefe de proyecto del CONSORCIO.
 Identificación del rol de Especialista Funcional del CONSORCIO.
 Identificación de los roles de arquitecto TI en la nube, de Datos y de Seguridad del

CONSORCIO.
 Identificación del rol de Especialista en Metodología Ágil del CONSORCIO.
 Identificación del rol de Líder de Desarrollo del CONSORCIO.
 Identificación del rol de Especialista DevOps del CONSORCIO.
 Identificación del rol de Especialista Cloud del CONSORCIO.
 Identificación del rol de Especialista UX del CONSORCIO.
 Identificación del rol de Agile Coach del CONSORCIO.

327
3.3.2 Definición de Rol y Cantidad del Personal Clave
Grupo Perfil Funciones y responsabilidades Cantidad

Será el máximo responsable de la gestión, dirección y
seguimiento del proyecto.
Sus funciones serán, entre otras, las siguientes:
 Dirigir, supervisar y coordinar la realización de
los trabajos.
 Ser parte del comité directivo y técnico.
 Asegurar el cumplimiento del cronograma
aprobado.
 Control de los elementos esenciales del proyecto
(alcance, tiempo, coste, recursos, riesgos)
realizando siempre una medición del avance real
en relación a lo planificado.
 Dirección y coordinación de los equipos de
Jefe de
Gestión trabajo. 1
proyecto
 Supervisión de la calidad final de todos los
productos entregados en el proyecto.
 Seguimiento, revisión y aprobación de las tareas
y MVPs realizados.
 Participación en las reuniones de trabajo que
sean necesarias con los responsables de las
áreas de la SUNAT, con el fin de obtener toda la
información requerida para la correcta ejecución
de los trabajos realizados.
 Realización de informes periódicos y todos
aquellos informes que, a petición de la SUNAT,
puedan servir para la consecución de los
objetivos previstos.
Será responsable de garantizar el cumplimiento del
Especialista
Framework SAFe propuesta en el proyecto, alineando a
Especialistas en
las prácticas de SUNAT. Una de las responsabilidades 1
Ágil Metodologías
será ayudar en la coordinación entre los distintos
ágiles
equipos de desarrollo en el proyecto.
Perfil con gran expertise en Cloud Computing, sus
funciones se basarán principalmente en:
 Colaborar en la Carga inicial de datos en los
entornos de Producción y Preproducción.
 Responsable de la migración de los ambientes
de Desarrollo y Pruebas al proveedor de
servicios de nube de La SUNAT.
Especialistas Arquitecto de
 Responsable de Asegurar la correcta 3
Cloud TI en Nube
preparación de ambientes siguiendo los
requerimientos de Infraestructura,
dimensionamiento y seguridad definidos por la
SUNAT.
 Colaborar en la capacitación y transferencia de
conocimiento hacia la SUNAT en los aspectos
técnicos del sistema.

328
Grupo Perfil Funciones y responsabilidades Cantidad
Será responsable de modelar y diseñar la Arquitectura
de datos de la Plataforma, cubriendo, entre otras, las
siguientes actividades:
 Responsable de la carga inicial de datos en los
entornos de Producción y Preproducción.
 Colaborar en la migración de los ambientes de
Desarrollo y Pruebas al proveedor de servicios
en la nube de SUNAT.
Especialistas Arquitecto de
 Asegurar la correcta preparación de ambientes 2
Datos datos
en materia de datos según los requerimientos de
seguridad establecidos por la SUNAT.
 Responsable en el diseño de los Agentes
Extractores de datos durante el Sprint 0.
 Colaborar en la capacitación y Transferencia de
conocimientos hacia la SUNAT en temas
relacionados con el uso y operación de la
herramienta.
 Apoyar en la definición del diseño técnico,
coordinación de los desarrollos, pruebas y
soporte a la puesta en producción.
 Verificación de la correcta aplicación y
cumplimiento de las metodologías establecidas.
 Definir junto con el equipo o equipos de
desarrollo las prácticas de implementación a
seguir.
Especialistas Líder de  Colaboración y asesoramiento en la realización
2
Desarrollo Desarrollo del diseño técnico de los desarrollos.
 Verificación del adecuado funcionamiento de los
elementos construidos, de la integración entre
los mismos y los diferentes desarrollos.
 Asegurar la ejecución de Pruebas unitarias que
garanticen la calidad de cualquier componente
desarrollado.
 Asegurar que los equipos de desarrollo siguen el
proceso de Integración y entrega continúa
definido por la SUNAT.
Tabla 48: Rol y Cantidad del Personal Clave

329
3.3.3 Definición de Rol y Cantidad del Personal No Clave
Grupo Perfil Funciones y responsabilidades Cant.

Gran conocedor de la metodología DevOps. Tendrá las
siguiente actividades:
 Responsabilidad de hacer cumplir la metodología
que se indica en la propuesta.
Especialistas Especialista
 Ayudar en las definiciones de los mecanismos de 1
Cloud DevOps
las pruebas unitarias e integrales.
 Responsabilidad de informar los criterios de calidad
que reportan las herramientas.
 Responsable de los Ingenieros Devops
Persona multifuncional, con años de experiencia en el
desarrollo de software. Son desarrolladores Full Stack y
Especialistas Desarrolladores
serviran de mentoring para los demás equipos de 1
Desarrollo Senior
desarrollo. Conocedores de las tecnilogías API Gateway,
Microservicios, Angular JS/Bootstrap/Jquery/html5, REST.
Ofrecerá un alto grado de expertise en experiencia de
usuario, ya que será responsable de garantizar un
adecuado nivel de usabilidad, accesibilidad, etc del
Especialistas
UX Designer sistema. 1
UX
 Diseño de la Interface del Sistema.
 Codificación de todos los elementos del frontal.
Su función principal será asegurar que los 4 ambientes
Especialista en
Especialistas correspondientes a Desarrollo, Pruebas, Preproducción y
Seguridad 1
SGSI Producción, cumplen con los Requerimientos de Seguridad
Informática
informática definidos por la SUNAT en el Anexo 13.
Será el responsable de analizar los requisitos definidos,
para asegurar el desarrollo de todas las funcionalidades
solicitadas por la SUNAT y que forman parte del alcance
del proyecto.
Analistas Especialista
 Participará en la elaboración inicial de la backlog 1
Funcionales Funcional
del producto con el Product Owner de la SUNAT.
 Colaborará en la elaboración de los planes de
pruebas que se ejecutarán para evaluar el correcto
funcionamiento de las historias de usuario del
backlog del sprint.
Debido que la fase de construcción y pruebas de la
Plataforma se hará bajo metodología ágil, deberá existir un
perfil responsable de Testing que asegure la calidad de las
historias de usuario.
Sus funciones principales serán:
Especialistas Responsable  Colaborar con el equipo o equipos Scrum durante
1
Calidad de Testing cada Sprint para asegurar la correcta definición de
los criterios de aceptación de las historias de
usuario.
 Colaborar en la elaboración del informe de cierre
de Sprint para detallar el estado de las historias de
usuario incluidas en la iteración.
Tabla 49: Rol y Cantidad del Personal del Equipo de Trabajo
Otros Especialistas.

330
Cantidad
Grupo ROL Funciones y responsabilidades Cant.
Total
Conocedor a profundidad de las tecnologías que
se aplicarán en el proyecto, principalmente a
nivel de administración y/o configuración. Debe
conocer a nivel de tecnología (plataforma)
relacionado a API Gateway, Contenedores, Data
Streaming, Caché. Tendrá las siguiente
Especialista actividades:
2
Cloud  Serán los responsables del
mantenimiento, configuración y control
de las plataformas.
 Encargados de validar la performance y
buen funcionamiento de la plataforma.
 Son los que participarán en las
capacitaciones a SUNAT.
Conocedor de patrones y buenas prácticas
aplicado a la arquitectura de microservicios. Gran
conocedor de los contenedores Kubernetes, API
Gateway, Zeebe y drools. Tendrá las siguiente
actividades:
 Participará en las reuniones donde
Especialistas implique decisiones de arquitectura de
7 Especialista
Cloud aplicaciones y/o de tecnología aplicada a 2
Microservicios
los microservicios.
 Apoyo al Arquitecto de TI nube para las
decisiones de arquitectura.
 Responsable del cumplimiento de las
directivas en la arquitectura orientada a
microservicios.

Conocedor de la metodología DevOps, pero con
gran experiencia en las herramientas de Gitlab,
Jenkins, Ansible y demás tecnologías indicadas
en la propuesta. Tendrá las siguiente
actividades:
 Gobierno de los repositorios de
Ingeniero
versionamiento Gitlab. 3
Devops
 Apoyo en la creación de los playbooks
Ansible.
 Ayudar en la creación de los pipelines
para la integración y despliegue
continuo.

Conocedor de las tecnologías MongoDB, Data
caché y Apache Kafka:
Especialistas Especialista  Administrador de las plataformas.
6 6
Datos Datos  Apoyo en el diseño de componentes.
 Provisionar recursos para los
microservicios.
 Responsable de ayudar a los equipos de
desarrollo en la implementación de sus
Especialistas
29 Líder Técnico componentes. Gran conocedor de 6
Desarrollo
workflows, microservicios, drools y
buenas prácticas en el desarrollo de

331
Cantidad
Total
software, con conocimientos en SAFe y
SCRUM.
 Forman parte del equipo de desarrollo.
Persona multifuncional y especialista en
Especialista diseño y construcción de microservicios
14
Dev Backend para la parte backend, implementando
las buenas prácticas y construcción de
pruebas unitarias.
 Forman parte del equipo de desarrollo.
Persona multifuncional y especialistas
Especialista
en Angular, HTML5. Se encargarán de 9
Fontend
desarrollar los microservicios para la
parte Frontend.
 Es el responsable de realizar tareas de
análisis y entendimiento de las historias
de usuario.
 Facilitar el entendimiento al equipo de
Analista
7 desarrollo acerca de las historias de 6
Funcional
Analistas usuarios.
Funcionales  Colaborar en la realización de las
pruebas para evaluar los criterios de
aceptación
 Amplio conocedor en tributos. Facilitador
Especialista
para el entendimiento del equipo de 1
Tributos
desarrollo en los procesos tributarios.
 Elaborar documentos de gestión de
acuerdo a la Metodología de la
organización
 Actualización de indicadores.
 Elaborar informes ejecutivos para la
gerencia.
Líder PMO  Mantener actualizado el tablero de 1
control para monitorear y reportar el
cumplimiento de los cronogramas de
proyectos.
 Proponer y velar por el adecuado uso de
metodologías (SCRUM, PMI,
Analistas emergentes, entre otras) en el desarrollo
11
PMO de proyectos y mejoras.
 Responsable de revisar contratos y
Contract
requerimientos contractuales del 1
Manager
proyecto.
 Seguimiento específico a actividades
involucradas entre los Proyecto.
 Facilitar la definición de misiones,
objetivos, tareas y requisitos de recursos
Analista PMO del proyecto. 5
 Proponer y velar por el uso correcto de
la metodología (SCRUM, PMI,
emergentes, entre otras) en el desarrollo
de proyectos y mejoras.

332
Cantidad
Total

Tener control de las lecciones
aprendidas y que estas se tomen en
cuenta como fuente de información para
aplicar en los siguientes proyectos.
 Documentar a nivel técnico
requerimientos contractuales.
 Garantizar el cumplimiento de los
requerimientos metodológicos para la
documentación del proyecto.
 Responsable en la capacitación
funcional y técnica del CUC.
 Responsable que se ejecuten las tareas
Analista
asociadas a las capacitaciones al 4
Capacitación
personal SUNAT.
 Garantizar los recursos necesarios para
la realización de las capacitaciones.
 Conocedor del framework SAFe y
SCRUM. Responsable de ser el
facilitador en los equipos de desarrollo,
Especialistas Especialista encargándose de solucionar los
3 3
Ágil Ágil impedimentos. También es un
conocedor de prácticas ágiles
involucradas en el desarrollo de
software.
 Definir los casos de prueba necesarios
para validar los criterios de aceptación
de las historias comprometidas en la
correspondiente iteración.
 Ejecutar los casos de prueba diseñados
Especialistas Analistas de
7 para cada historia de usuario incluida en 7
Calidad Calidad
la iteración.
 Elaboración del informe de cierre de
Sprint para detallar el estado de las
historias de usuario incluidas en la
iteración.
 Velar por el cumplimiento de las normas,
Especialistas Especialista estándares de seguridad.
1 1
SGSI SGSI  Análisis y detección de amenazas de
seguridad de la información.
Apoyo al UX Designer, y tiene experiencia en
aplicar metodologías UX Tiene la
responsabilidad de garantizar un adecuado nivel
de usabilidad del sistema.
Especialistas Especialista Sus funciones serán, entre otras, las siguientes: 4
UX UX
 Sesiones con los usuarios finales para
definir las Interface del Sistema.
 Creación de prototipos.
 Brindar los lineamientos de UX.
 Establecer y velar el cumplimiento de los
Director de
Gestión 1 acuerdos contractuales con el cliente. 1
Proyecto
 Valorar y aprobar cambios de alcances.
Tabla 50: Otros Especialistas

333
Este cálculo de la cantidad de personal es una estimación de acuerdo a la información suministrada
por SUNAT, la cual se irá ajustando de acuerdo a las necesidades del Proyecto.

334
4 Anexos

335
4.1 Anexo 1: Cronograma de los trabajos y planificación de entregables (TECH-5)
Formulario TECH-5: Cronograma de los trabajos y planificación de entregables
AÑO 1 AÑO 2
Plan de actividades
Entregable Mes 1 Mes 2 Mes 3 Mes 4 Mes 5 Mes 6 Mes 7 Mes 8 Mes 9 Mes 10 Mes 11 Mes 12 Mes 13 Mes 14 Mes 15 Mes 16 Mes 17 Mes 18 Mes 19 Mes 20 Mes 21 Mes 22 Mes 23 Total
Plan S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 S14 S15 S16 S17 S18 S19 S20 S21 S22 S23 S24 S25 S26 S27 S28 S29 S30 S31 S32 S33 S34 S35 S36 S37 S38 S39 S40 S41 S42 S43 S44 S45 S46 S47 S48 S49 S50 S51 S52 S53 S54 S55 S56 S57 S58 S59 S60 S61 S62 S63 S64 S65 S66 S67 S68 S69 S70 S71 S72 S73 S74 S75 S76 S77 S78 S79 S80 S81 S82 S83 S84 S85 S86 S87 S88 S89 S90 S91 S92 Meses
Fase de Gestión
Planificación 0
D-1 E-1 Plan de Gestión del Proyecto 1 1 1 1 c 1

Plan de gestión de los interesados 0
Plan para la gestión del alcance 0
Plan de gestión de los requisitos 0
Línea base del alcance 0
Plan de gestión del cronograma 0
Plan de gestión de los riesgos 0
Plan de gestión de los recursos 0
Plan de gestión de los costos 0
Línea base del cronograma 0
Cronograma del proyecto 0
Plan de gestión de la calidad 0
Plan de gestión de las comunicaciones 0
Plan de gestión de las adquisiciones 0
Plan de gestión del cambio 0
Hito: Plan de Gestión Aprobado c 0
Seguimiento y Control del Proyecto 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 21

Informes de desempeño del trabajo 0
Pronósticos del cronograma 0
Pronósticos de costos 0
Actualizaciones a los documentos del proyecto 0
Solicitudes de cambio 0
Mediciones de control de calidad 0
Finalización 0
D-12 E-12 Informe final del Proyecto c 0

Actualizaciones a los documentos del proyecto 0
Transferencia del producto, servicio o resultado final 0
Informe final 0
Hito: Informe Final de Proyecto Aprobado c 0
Fase Carga Inicial de Datos 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17
Etapa de Preparación de Ambientes 1 1 1 1 1 1 1 1 1 1 1 1 3
Planificación de la Carga Inicial de Datos 1 1 1 1 1
Estrategía 1 1 1 1 1
Realizar Estrategía 1 1 1 1 1
Entrega del informe Final de Estrategia al Cliente 1 1 1 1 1
Etapa de Implementación de la Carga Inicial de Datos 1 1 1 1 1
Inventariar Fuentes 1 1 1 1 1
Recibir Capacitacion de Legados 1 0.25
Realizar Inventario y Mapeo de las 6 Fuentes Identificadas 1 1 1 1 1
Hito: Capacitación Recibida por Sunat c 0
Realizar Modelo de Datos 1 1 1 0.75
Realizar revision de procesos MVP1 y MVP2 1 1 1 0.75
Realizar revisión de épicas de MVP1 y MVP2 1 1 1 0.75
Realizar Modelo Conceptual 1 1 1 0.75
Realizar Modelo Lógico 1 1 1 0.75
Realizar Modelo Físico 1 1 1 0.75
Construir Base de Datos 1 1 1 0.75
Hito: Base de Datos Configurada y Disponible c 0
Realizar Migración 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Crear Modelo de Equivalencia (ODS) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Construir Jobs de Extraccion de Legados hacia ODS 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Construir Jobs de Transformacion de Datos Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Contruir Jobs de Carga en Modelo Final 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Efectuar pruebas de Migración “Unidad Ejecutora Mejoramiento del Sistema de Información de la SUNAT - MSI”
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Hito: Migración MVP1 Verificada c c c c 0
E-5 Informe de carga inicial de datos del MVP1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 c
1 1 1 1 1 1 1 1 1 1 11.5
D-5 SPI N°1 001-2019-SUNAT/BID 1 1 1 1 1 1 1 1
Arquitectura de Datos de la solución: Incluye el modelo de datos

definido para el Sistema de Cuenta Única de Contribuyente
0
Documento con el detalle de los Agentes Extractores de Datos que
obtendrán datos desde los sistemas legacy 3360
Parámetros de configuración y toda la data para la carga inicial de datos,
0
incluye los saldos iniciales de las cuentas de los contribuyentes (PRD)
Estrategía 1 1 1 1 1
Realizar Estrategía 1 1 1 1 1
Entrega del informe Final de Estrategia al Cliente 1 1 1 1 1
Etapa de Implementación de la Carga Inicial de Datos 1 1 1 1 1
Inventariar Fuentes 1 1 1 1 1
Recibir Capacitacion de Legados 1 0.25
Realizar Inventario y Mapeo de las 6 Fuentes Identificadas 1 1 1 1 1
Hito: Capacitación Recibida por Sunat c 0
Realizar Modelo de Datos 1 1 1 0.75
Realizar revision de procesos MVP1 y MVP2 1 1 1 0.75
Realizar revisión de épicas de MVP1 y MVP2 1 1 1 0.75
Realizar Modelo Conceptual 1 1 1 0.75
Realizar Modelo Lógico 1 1 1 0.75
Realizar Modelo Físico 1 1 1 0.75
Construir Base de Datos 1 1 1 0.75
Hito: Base de Datos Configurada y Disponible c 0
Realizar Migración 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Crear Modelo de Equivalencia (ODS) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Construir Jobs de Extraccion de Legados hacia ODS 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Construir Jobs de Transformacion de Datos 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Contruir Jobs de Carga en Modelo Final 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Efectuar pruebas de Migración 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 17.5
Hito: Migración MVP1 Verificada c c c c 0
D-5 E-5 Informe de carga inicial de datos del MVP1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 c 11.5
0
0
obtendrán datos desde los sistemas legacy
0
Documento con el detalle de los temas técnicos de seguridad de Datos 0
Plan de Ejecución de carga inicial de datos, incluye la documentación de
0
las estructuras a cargar, los procesos de transformación y carga de datos
Reporte de ejecución de la carga de datos, incluye el detalle de

actividades y pruebas realizadas sobre el SW y los datos para garantizar 0
el correcto funcionamiento del sistema luego de la carga inicial de datos.
Hito: Migración MVP2 Verificada c c c 0

D-8 E-8 Informe de carga inicial de datos del MVP2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 c 8
0
0
obtendrán datos desde los sistemas legacy
0
Documento con el detalle de los temas técnicos de seguridad de Datos 0
Documento de resultados, base de conocimiento y lecciones aprendidas - 0
Plan de Ejecución de carga inicial de datos, incluye la documentación de

0
las estructuras a cargar, los procesos de transformación y carga de datos
Reporte de ejecución de la carga de datos, incluye el detalle de

Desarrollo y Configuración Agentes Extractores de Datos 0
Sistema Legacy Carrito de Pagos 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Sistema Legacy Declaraciones y Pagos (Bancos) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Sistema Legacy SIRAT 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Sistema Legacy CPE y CIBELLE (Comprobantes de Pagos y Libros
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
electrónicos)
Sistema Legacy RSIRAT 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Sistema Legacy SIGAD 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Hito: AED del MVP1 Configurados y Operativos MVP1 c c c c c c c c c 0
Hito: AED del MVP1 Configurados y Operativos MVP2 c c c c c c 0
Hito: Migración MVP2 Verificada c 0
Fase de Desarrollo, Pruebas y Puesta en Producción 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Etapa Preparación de Ambientes 1 1 1 1 1
Ambientes de Desarrollo y Pruebas 1 1 1 1 1
Preparación liniamientos de infraestructura y ambientes,

1 1 1 1 1
configuraciones loadbalancer, red,
Recepción de la Información Necesaria por parte de Sunat 1 0.25
Arquitectura del Sistema 1 0.25
Historias de usuario 1 0.25
Materiales producidos por la consultoría “Servicio de Elaboración de la
1 0.25
Arquitectura del Sistema de Cuenta Única”
Configuraciones de red Necesarias 1 Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT 0.25
Material y documentación de la infraestructura actual 1 0.25
Capacitación Aspectos Generales de la Sunat 1 “Unidad Ejecutora Mejoramiento del Sistema de Información de la SUNAT - MSI” 0.25
Capacitación en conceptos generales y particulares de Cuenta Única de
1 0.25
Contribuyente
Lineamientos técnicos, estándares, metodologías y buenas prácticas
1 SPI N° 001-2019-SUNAT/BID 0.25
promovidas por la Sunat
“CONTRATACIÓN DEL SERVICIO
c
Hito: Información Entregada por Parte de la Sunat
DE DESARROLLO, PRUEBAS Y PUESTA EN PRODUCCIÓN DEL SISTEMA DE CUENTA ÚNICA DE CONTRIBUYENTE – MVP1 Y MVP2” 0
Instalación Configuraciones Base
Configuración de IAM
1
1
1
1
1
1
1
1
337
1
1
Configuración de Políticas 1 1 1 1 1
Configuración de Grupos 1 1 1 1 1
Desarrollo y Configuración Agentes Extractores de Datos 0
Sistema Legacy Carrito de Pagos 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Sistema Legacy Declaraciones y Pagos (Bancos) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Sistema Legacy SIRAT 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Sistema Legacy CPE y CIBELLE (Comprobantes de Pagos y Libros
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
electrónicos)
Sistema Legacy RSIRAT 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Sistema Legacy SIGAD 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Hito: AED del MVP1 Configurados y Operativos MVP1 c c c c c c c c c 0
Hito: AED del MVP1 Configurados y Operativos MVP2 c c c c c c 0
Hito: Migración MVP2 Verificada c 0
Fase de Desarrollo, Pruebas y Puesta en Producción 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 19
Etapa Preparación de Ambientes 1 1 1 1 1
Ambientes de Desarrollo y Pruebas 1 1 1 1 1
Preparación liniamientos de infraestructura y ambientes,

1 1 1 1 1
configuraciones loadbalancer, red,
Recepción de la Información Necesaria por parte de Sunat 1 0.25
Arquitectura del Sistema 1 0.25
Historias de usuario 1 0.25
Materiales producidos por la consultoría “Servicio de Elaboración de la
1 0.25
Arquitectura del Sistema de Cuenta Única”
Configuraciones de red Necesarias 1 0.25
Material y documentación de la infraestructura actual 1 0.25
Capacitación Aspectos Generales de la Sunat 1 0.25
Capacitación en conceptos generales y particulares de Cuenta Única de
1 0.25
Contribuyente
Lineamientos técnicos, estándares, metodologías y buenas prácticas
1 0.25
promovidas por la Sunat
Hito: Información Entregada por Parte de la Sunat c 0
Instalación Configuraciones Base 1 1 1 1 1
Configuración de IAM 1 1 1 1 1
Configuración de Políticas 1 1 1 1 1
Configuración de Grupos 1 1 1 1 1
Configuración de Usuarios 1 1 1 1 1
Configuración de Roles 1 1 1 1 1
Creación de VPCs 1 1 1 1 1
Configuración de Subnets 1 1 1 1 1
Configuración de Internet Gateways 1 1 1 1 1
Configuración de Nat Gateways 1 1 1 1 1
Configuración de Route Tables 1 1 1 1 1
Creación y configuración VPN 1 1 1 1 1
Creación de Maquinas Virtuales AED 1 1 1 1 1
Configuración de Politicas de seguridad, red y Balanceadores 1 1 1 1 1
Instalación y configuración de Gradle 1 1 1 1 1
Instañación de JDK 8 1 1 1 1 1
Creación de Maquinas Virtuales Kubernetes 1 1 1 1 1
Instalación y configuración de Kubernetes 1 1 1 1 1
Instalación de ZeeBe 1 1 1 1 1
Instalación de Drools 1 1 1 1 1
Creación de Maquinas Virtuales Monitoreo Nube 1 1 1 1 1
Instalación de Prometheus 1 1 1 1 1
Instalación de Grafana 1 1 1 1 1
Creación de Maquinas Virtuales Monitoreo MS 1 1 1 1 1
Instalación de Elastic Stack 1 1 1 1 1
Creación de Maquinas Virtuales Kong - Api Gateway 1 1 1 1 1
Instalación de Kong 1 1 1 1 1
Creación de Maquinas Virtuales Kafka 1 1 1 1 1
Instalación de Kafka 1 1 1 1 1
Instalación y configuración de Zookeeper 1 1 1 1 1
Creación de Maquinas Virtuales MongoDB 1 1 1 1 1
Instalación de MongoDB 1 1 1 1 1
Configuración de eguridad de datos en reposo con HSM y TLS. 1 1 1 1 1
Creación de BD's 1 1 1 1 1
Creación de Maquinas Virtuales Redis 1 1 1 1 1
Instalación de Redis 1 1 1 1 1
Creación de Maquinas Virtuales Consul 1 1 1 1 1
Instalación de Server consul 1 1 1 1 1
Creación de Maquinas Repositorios 1 1 1 1 1
Instalación de Gitlab 1 1 1 1 1
Configuración de Branchs 1 1 1 1 1
Instalación de Docker registry y artifactory 1 1 1 1 Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT 1
Configuración de repositorios docker y java 1 1 1 1 1
Creación de Maquinas CI/CD 1 1 1 1 “Unidad Ejecutora Mejoramiento del Sistema de Información de la SUNAT - MSI” 1
Instalación y Configuración de Jenkins 1 1 1 1 1
Instalación y Configuración del Sonar 1 1 SPI N° 001-2019-SUNAT/BID
1 1 1
Mecanismos de Backup 1 1 1 1 1
Definición de máquinas a respaldar. 1 1 1 1 1
Configuración de backups 1 1 1 1 1
Monitoreo 1 1 1 1 338
1
Configuración de monitoreos con Graphana y Prometeus. 1 1 1 1 1
Configuración de moniteroe con Elastick Stack 1 1 1 1 1
Certificación 1 1 1 1 1
Instalación de Kong 1 1 1 1 1
Creación de Maquinas Virtuales Kafka 1 1 1 1 1
Instalación de Kafka 1 1 1 1 1
Instalación y configuración de Zookeeper 1 1 1 1 1
Creación de Maquinas Virtuales MongoDB 1 1 1 1 1
Instalación de MongoDB 1 1 1 1 1
Configuración de eguridad de datos en reposo con HSM y TLS. 1 1 1 1 1
Creación de BD's 1 1 1 1 1
Creación de Maquinas Virtuales Redis 1 1 1 1 1
Instalación de Redis 1 1 1 1 1
Creación de Maquinas Virtuales Consul 1 1 1 1 1
Instalación de Server consul 1 1 1 1 1
Creación de Maquinas Repositorios 1 1 1 1 1
Instalación de Gitlab 1 1 1 1 1
Configuración de Branchs 1 1 1 1 1
Instalación de Docker registry y artifactory 1 1 1 1 1
Configuración de repositorios docker y java 1 1 1 1 1
Creación de Maquinas CI/CD 1 1 1 1 1
Instalación y Configuración de Jenkins 1 1 1 1 1
Instalación y Configuración del Sonar 1 1 1 1 1
Mecanismos de Backup 1 1 1 1 1
Definición de máquinas a respaldar. 1 1 1 1 1
Configuración de backups 1 1 1 1 1
Monitoreo 1 1 1 1 1
Configuración de monitoreos con Graphana y Prometeus. 1 1 1 1 1
Configuración de moniteroe con Elastick Stack 1 1 1 1 1
Certificación 1 1 1 1 1
Validación de contenedores 1 1 1 1 1
Validación de API Gateway 1 1 1 1 1
Validación de Kafka 1 1 1 1 1
Ansible 1 1 1 1 1
Creación y ejecución de playboooks 1 1 1 1 1
Hito: Ambientes Desarrollo y Pruebas Configurados y Disponibles c 0
Tunning y Pruebas de Componentes de Ambientes 1 1 1 1 1
Hito: Ambientes Desarrollo y Pruebas - Operativos y Disponibles c 0
D-2 E-2 Informe de preparación de ambientes de Desarrollo y Pruebas 1 1 1 1 1 1 1 1 c 2
Componentes Técnológicos Correctamente Instalados 0
Componentes Técnológicos Correctamente Configurados 0
Configuraciones de Red y Seguridad Realizadas 0
Licencias Necesarias Adquiridas y Configuradas 0
Informe sobre lo Actuado señalando la Correcta Instación de los
0
Ambientes
Revisión Física de los Ambientes por Parte de Sunat 0
Hito: Informe de preparación de ambientes de Desarrollo y Pruebas -
0
Aprobado c
Instalación y Configuración de Ambientes de Preproducción y
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4.5
Producción
Hito: Entrega Ambientes de Preproducción y Produccón por parte de
0
Sunat c
Apoyo en Instalación y configuración de Preproducción y Producción 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 7
Hito: Ambientes de Preproducción y Produccón Configurados y
0
Operativos c
Etapa Desarrollo, Pruebas y Puesta en Producción de los MVPs 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9
Realizar MVP 1 0
Incremento de Producto 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4.5

Hito: Toda la Información de las Reglas de Negocio Entregadas por
0
Sunat c
Hito: Personal del Proyecto Disponible por Sunat c 0
Hito: Reunión de Incremento de Producto Realizada c 0
SPRINT 0 1 1 1 1 1 1 1.5
Levantamiento 1 1 1 1 1 1 1.5
Diagrama de Dependecias 1 1 1 1 1 1 1.5
Backlog Inicial 1 1 1 1 1 1 1.5
Plan de Sprints 1 1 1 1 1 1 1.5
Conformación de Equipos de Trabajo 1 1 1 1 1 1 1.5
Capacitación al Equipo de Trabajo 1 1 1 1 1 1 1.5
Procesos de Negocio 1 1 1 1 1 1 1.5
Revisión de lineamientos técnicos, estándares, metodologías y buenas
1 1 1 1 1 1 Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT 1.5
prácticas de Sunat
Definición de playboooks para Ansible 1 1 1 1 1 1 “Unidad Ejecutora Mejoramiento del Sistema de Información de la SUNAT - MSI” 1.5
Creación de arquetipos mínimos para desarrollo de componentes. 1 1 1 1 1 1 1.5
Definición de pipelines jenkins 1 1 1 1 1 1 1.5
Definición de lineamientos DevOps 1 1SPI N° 001-2019-SUNAT/BID
1 1 1 1 1.5
Identificación de Microservicios(componentes) 1 1 1 1 1 1 1.5
Lineamientos de Backups 1 1 1 1 1 1 1.5
Lineamientos de UX
Desarrollo UX Sprint 1
1 1 1 1 1
1
1
1 1 1 339
1.5
1
Hito: Equipos de Trabajo Conformados y Capacitados c 0
RELEASE 1 1 1 1 1 1 1 1 1 1 1 1 1 3
Hito: Ambientes de Preproducción y Produccón Configurados y
0
Operativos c
Etapa Desarrollo, Pruebas y Puesta en Producción de los MVPs 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9
Realizar MVP 1 0
Incremento de Producto 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4.5

Hito: Toda la Información de las Reglas de Negocio Entregadas por
0
Sunat c
Hito: Personal del Proyecto Disponible por Sunat c 0
Hito: Reunión de Incremento de Producto Realizada c 0
SPRINT 0 1 1 1 1 1 1 1.5
Levantamiento 1 1 1 1 1 1 1.5
Diagrama de Dependecias 1 1 1 1 1 1 1.5
Backlog Inicial 1 1 1 1 1 1 1.5
Plan de Sprints 1 1 1 1 1 1 1.5
Conformación de Equipos de Trabajo 1 1 1 1 1 1 1.5
Capacitación al Equipo de Trabajo 1 1 1 1 1 1 1.5
Procesos de Negocio 1 1 1 1 1 1 1.5
Revisión de lineamientos técnicos, estándares, metodologías y buenas
1 1 1 1 1 1 1.5
prácticas de Sunat
Definición de playboooks para Ansible 1 1 1 1 1 1 1.5
Creación de arquetipos mínimos para desarrollo de componentes. 1 1 1 1 1 1 1.5
Definición de pipelines jenkins 1 1 1 1 1 1 1.5
Definición de lineamientos DevOps 1 1 1 1 1 1 1.5
Identificación de Microservicios(componentes) 1 1 1 1 1 1 1.5
Lineamientos de Backups 1 1 1 1 1 1 1.5
Lineamientos de UX 1 1 1 1 1 1 1.5
Desarrollo UX Sprint 1 1 1 1 1 1
Hito: Equipos de Trabajo Conformados y Capacitados c 0
RELEASE 1 1 1 1 1 1 1 1 1 1 1 1 1 3
SPRINT 1 1 1 1 1 1 1.25
Diseño, Desarrollo, Definición de casos de pruebas, CI/CD Sprint 1 1 1 1 1 1.25
EP009 - US089 Extraer documentos de sistemas legacy 1 1 1 1 1 1.25
EP009 - US038 Listar definición de documentos normalizados 1 1 1 1 1 1.25
EP098 - US320 Listar parametría - Especificación Genérica 1 1 1 1 1 1.25
EP009 - US084 Mantener reglas de normalización 1 1 1 1 1 1.25
EP009 - US126 Generación de documentos normalizados 1 1 1 1 1 1.25
EP009 - US085 Mantener reglas de registro de movimientos en cuenta 1 1 1 1 1 1.25
EP009 - US158 Listar cuentas 1 1 1 1 1 1.25
EP009 - US081 Mantener cuentas 1 1 1 1 1 1.25
EP009 - US159 Listar tipos de movimiento 1 1 1 1 1 1.25
EP009 - US082 Mantener tipos de movimiento 1 1 1 1 1 1.25
EP009 - US281 Registrar movimientos de cuenta única 1 1 1 1 1 1.25
EP098 - US323 Seleccionar usuario de Cuenta Única 1 1 1 1 1 1.25
EP098 - US324 Mantener supervisores para aplicación de solicitudes 1 1 1 1 1 1.25
EP098 - US325 Mantener gestores para evaluación de solicitudes 1 1 1 1 1 1.25
EP098 - US322 Parametrizar asignación automática de solicitudes 1 1 1 1 1 1.25
Servicios del COE - Centro de Excelencia 1 1 1 1 1 1.25
Cierre del Sprint 1 1 1 1 1 1.25
Desarrllo UX para el siguiente Sprint 1 1 1 1 1 1.25
SPRINT 2 1 1 1 1 1 1.25
EP021 - US090 Liquidar declaración jurada 1 1 1 1 1 1.25
EP013 - US069 Consultar documentos normalizados 1 1 1 1 1 1.25
EP098 - US313 Consulta Cuenta Única - Especificación Genérica 1 1 1 1 1 1.25
EP013 - US070 Listar documentos normalizados 1 1 1 1 1 1.25
EP012 - US088 Re-normalización de documentos 1 1 1 1 1 1.25
EP012 - US127 Re-proceso de documento normalizado 1 1 1 1 1 1.25
EP028 - US097 Imputar pago 1 1 1 1 1 1.25

SPRINT 3 1 1 1 1 1 1.25
EP028 - US098 Extorno de pagos 1 1 1 1.25

1 1
EP028 - US180 Reversión de pago 1 1 1 1.25

1 1
EP021 - US282 Validaciones DJ Rectificatoria 1 1 1 1 1 1.25
EP027 - US100 Generación automática de créditos 1 1 1 1.25
“Unidad Ejecutora
1 1
Mejoramiento del Sistema de Información de la SUNAT - MSI”
EP009 - US078 Consulta de consistencia 1 1 1 1 1 1.25
EP013 - US077 Consultar por movimientos 1 1 1 1 1 1.25
EP013 - US067 Consultar cuenta de deuda credito y transitoria SPI N° 001-2019-SUNAT/BID 1 1 1 1 1 1.25
manual
“CONTRATACIÓN DEL SERVICIO DE DESARROLLO, PRUEBAS
EP007 - US030 Seleccion automatica de rectificatorias para veredicto
1 1
1 1 1 Y PUESTA EN PRODUCCIÓN DEL SISTEMA DE CUENTA ÚNICA DE CONTRIBUYENTE – MVP1 Y MVP2” 1.25
EP007 - US031 Veredicto automático por silencio administrativo
EP007 - US024 Listar declaraciones juradas rectificatorias pendientes de
1 1 1 1 1
340
1.25
1 1 1 1.25
veredicto 1 1
EP007 - US025 Registro de documento de veredicto de rectificatoria 1 1 1 1 1 1.25
EP098 - US313 Consulta Cuenta Única - Especificación Genérica 1 1 1 1 1 1.25
EP013 - US070 Listar documentos normalizados 1 1 1 1 1 1.25
EP012 - US088 Re-normalización de documentos 1 1 1 1 1 1.25
EP012 - US127 Re-proceso de documento normalizado 1 1 1 1 1 1.25
EP028 - US097 Imputar pago 1 1 1 1 1 1.25

SPRINT 3 1 1 1 1 1 1.25
EP028 - US098 Extorno de pagos 1 1 1 1.25

1 1
EP028 - US180 Reversión de pago 1 1 1 1.25

1 1
EP021 - US282 Validaciones DJ Rectificatoria 1 1 1 1 1 1.25
EP027 - US100 Generación automática de créditos 1 1 1 1.25

1 1
EP009 - US078 Consulta de consistencia 1 1 1 1 1 1.25
EP013 - US077 Consultar por movimientos 1 1 1 1 1 1.25
EP013 - US067 Consultar cuenta de deuda credito y transitoria 1 1 1 1 1 1.25
EP007 - US030 Seleccion automatica de rectificatorias para veredicto
1 1 1 1.25
manual 1 1
EP007 - US031 Veredicto automático por silencio administrativo 1 1 1 1 1 1.25
EP007 - US024 Listar declaraciones juradas rectificatorias pendientes de
1 1 1 1.25
veredicto 1 1
EP007 - US025 Registro de documento de veredicto de rectificatoria 1 1 1 1 1 1.25
EP007 - US026 Listar veredictos de rectificatoria 1 1 1 1 1 1.25
EP007 - US033 Consultar veredictos de rectificatoria 1 1 1 1 1 1.25
EP007 - US032 Asignar Veredictos pendientes 1 1 1 1 1 1.25
EP007 - US028 Aplicar veredicto de rectificatoria 1 1 1 1 1 1.25
E-3 Informe de implementación del Release 1 y creación de ambiente
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9.75
D-3 de pre-producción c
Actas de conformidad de cada demostración del sistema que forme
0
parte del release.
Documento con prototipos de pantallas, adjuntando el informe de
0
aplicación de user experience (UX).
Documentación de negocio, como mínimo: Épicas, Historias de usuario y
0
Documentos técnicos de sistemas utilizados para el desarrollo. 0
Datos requeridos para la utilización y que no tienen pantallas para
0
registro pre-cargados en las bases de datos.
Requerimientos funcionales y no funcionales atendidos. Se debe remitir
0
la evidencia de su cumplimiento.
Funcionalidades implementadas y disponibles. 0
Documentación de Arquitectura (anexos técnicos de este TDR)
0
actualizados, de ser el caso.
Documentos de Pruebas: Plan y casos de pruebas. 0
Informe de pruebas funcionales, no funcionales y sus resultados llevadas
0
a cabo.
Acta de Aceptación de usuario. 0
Informe histórico de Sprints ejecutados, así como todas las historias de
0
Código fuente en el repositorio SUNAT 0
Reporte de trazabilidad de historia de usuario versus código fuente. 0
Evidencias de seguridad en aplicaciones. 0
Carga inicial de datos (Plan de ejecución de carga inicial de datos y
0
Reporte de ejecución de la carga de datos)
Ambientes de preproducción funcionando correctamente sobre la
0
Plataforma de LA SUNAT.
Versión actualizada del sistema configurada en el ambiente, de acuerdo
0
con el modelo de DevOps definido.
Configuraciones del sistema debidamente actualizadas de manera a
soportar la utilización de la versión más actual del sistema en el 0
ambiente configurado.
Documentación de todas las pruebas realizadas en el ambiente para
0
asegurar su correcto funcionamiento y compatibilidad.
Manuales, documentación y diagramas técnicos actualizados. 0
Documentación de las configuraciones de seguridad, Backups y todo lo
que sea necesario para asegurar la disponibilidad del sistema, la
0
seguridad de la información, así como los aspectos técnicos y normativos
vigentes solicitadas en estos términos de referencia.
Informe de capacitación a técnicos de Sunat 0
Incremento de Producto 2 1 1 1 1 1 1 1 1 1 1 1 1 3
RELEASE 2 1 1 1 1 1 1 1 1 1 1 1 1 3
SPRINT 4 Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT
1 1 1 1 1
Diseño, Desarrollo, Definición de casos de pruebas, CI/CD Sprint 1 1 1 1 1
EP007 - US118 Realizar reversión de veredicto de rectificatoria “Unidad Ejecutora Mejoramiento del Sistema de Información de la SUNAT - MSI”
1 1 1 1 1
EP007 - US027 Editar o eliminar veredicto borrador 1 1 1 1 1
EP007 - US094 Consultar Resoluciones de Intendencia por Veredictos de
Rectificatoria
1 1 1 1 SPI N° 001-2019-SUNAT/BID 1
EP009 - US177 Verificación de consistencia 1 1 1 1 1
“CONTRATACIÓN DEL SERVICIO DE DESARROLLO, PRUEBAS
EP003 - US079 Mantener motivos de ajuste 1 1 1 1
Y PUESTA EN PRODUCCIÓN DEL SISTEMA DE CUENTA ÚNICA DE CONTRIBUYENTE – MVP1 Y MVP2” 1
EP003 - US156 Listar motivos de ajuste en cuenta
EP003 - US001 Registro de documento de ajuste
1
1
1
1
1
1
1
1
341
1
1
EP003 - US002 Listar ajustes 1 1 1 1 1
EP003 - US008 Modificar ajuste preliminar 1 1 1 1 1
Acta de Aceptación de usuario. 0
Informe histórico de Sprints ejecutados, así como todas las historias de
0
0
Ambientes de preproducción funcionando correctamente sobre la
0
Versión actualizada del sistema configurada en el ambiente, de acuerdo
0
con el modelo de DevOps definido.
0
0
RELEASE 2 1 1 1 1 1 1 1 1 1 1 1 1 3
SPRINT 4 1 1 1 1 1
EP007 - US118 Realizar reversión de veredicto de rectificatoria 1 1 1 1 1
EP007 - US027 Editar o eliminar veredicto borrador 1 1 1 1 1
EP007 - US094 Consultar Resoluciones de Intendencia por Veredictos de
1 1 1 1 1
Rectificatoria
EP009 - US177 Verificación de consistencia 1 1 1 1 1
EP003 - US079 Mantener motivos de ajuste 1 1 1 1 1
EP003 - US156 Listar motivos de ajuste en cuenta 1 1 1 1 1
EP003 - US001 Registro de documento de ajuste 1 1 1 1 1
EP003 - US002 Listar ajustes 1 1 1 1 1
EP003 - US008 Modificar ajuste preliminar 1 1 1 1 1
EP003 - US004 Aplicar ajustes en cuenta 1 1 1 1 1
EP003 - US009 Consulta de detalle de documentos de ajuste 1 1 1 1 1
EP003 - US006 Realizar reversión de ajuste aplicado 1 1 1 1 1
EP003 - US329 Generar documentos de ajuste automaticamente 1 1 1 1 1
EP003 - US337 Registro masivo de documentos de ajuste 1 1 1 1 1
EP009 - US547 Ajuste automático por saldos inconsistentes 1 1 1 1 1
EP013 - US066 Estado general de la cuenta del contribuyente 1 1 1 1 1
EP098 - US043 Listar solicitudes - Especificación Generica 1 1 1 1 1
Servicios del COE - Centro de Excelencia 1 1 1 1 1
Cierre del Sprint 1 1 1 1 1
Desarrllo UX para el siguiente Sprint 1 1 1 1 1
SPRINT 5 1 1 1 1 1
EP053 - US570 Registro de pago con error (legacy) 1 1 1 1 1
EP002 - US157 Listar motivos de suspension manual 1 1 1 1 1
EP002 - US080 Mantener motivos de suspension manual 1 1 1 1 1
EP002 - US013 Registrar documento de suspensión 1 1 1 1 1
EP002 - US014 Listar suspensiones 1 1 1 1 1
EP002 - US018 Modificar documento de suspensión preliminar 1 1 1 1 1
EP002 - US021 Consultar detalle de suspensión 1 1 1 1 1
EP002 - US017 Evaluar documentos de suspensión 1 1 1 1 1
EP002 - US022 Registrar o Modificar fecha de fin de suspensión 1 1 1 1 1
EP002 - US023 Activar o suspender cuenta según plazo de suspensión 1 1 1 1 1
EP002 - US328 Generar documentos de suspensión automaticamente 1 1 1 1 1
EP013 - US074 Consulta de seguimiento de documentos y eventos 1 1 1 1 1
EP021 - US174 Generar cuenta de control de Renta y Retenciones de
1 1 1 1 1
Renta
EP028 - US545 Generar cuenta de control de pago a Renta 1 1 1 1 1

SPRINT 6 1 1 1 1 1
EP013 - US071 Consultar cuenta de control 1 1 1 1 1
EP026 - US103 Emitir Ordenes de Pago 1 1 1 1 1
EP026 - US479 Realizar reversión de Orden de Pago 1 1 1 1 1
EP040 - US163 Ajuste por emisión de OP y RM 1 1 1 1 1
EP013 - US072 Consulta de saldos deudores 1 1 1 1 1
EP013 - US073 Consulta de liquidación de declaración 1 1 1 1 1
RELEASE 3 1 1 1 1 1 1 1 1 1 1 1 1 3
SPRINT 7 1 1 1 1 1
EP053 - US572 Registro de la reimputación de ingreso como recaudación
1 1 1 1 1
(legacy) Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT
EP045 - US508 Registrar RI de Fraccionamiento (RSIRAT) 1 1 1 1 1
EP004 - US165 Listar motivos de comunicación de diferencias “Unidad Ejecutora Mejoramiento
1 1 1del
1 Sistema de Información de la SUNAT - MSI” 1
EP004 - US164 Mantener motivos de comunicación de diferencias 1 1 1 1 1
EP004 - US035 Registrar comunicacion de diferencias de saldos 1 1 1 1 1
EP004 - US036 Listar comunicaciones de diferencias SPI N° 001-2019-SUNAT/BID 1 1 1 1 1
“CONTRATACIÓN DEL SERVICIO DE DESARROLLO, PRUEBAS Y PUESTA1EN

EP004 - US037 Asignar casos de comunicación de diferencias pendientes 1 1PRODUCCIÓN
1 DEL SISTEMA DE CUENTA ÚNICA DE CONTRIBUYENTE – MVP1 Y MVP2” 1
EP004 - US060 Consultar detalles de comunicaciones de diferencias de
datos
1 1 1 1 1 342
EP004 - US039 Resolver solicitud de comunicación de diferencias con
1 1 1 1 1
cuenta
EP004 - US102 Realizar reversión de Comunicacion de diferencias 1 1 1 1 1
EP028 - US545 Generar cuenta de control de pago a Renta 1 1 1 1 1

SPRINT 6 1 1 1 1 1
EP013 - US071 Consultar cuenta de control 1 1 1 1 1
EP026 - US103 Emitir Ordenes de Pago 1 1 1 1 1
EP026 - US479 Realizar reversión de Orden de Pago 1 1 1 1 1
EP040 - US163 Ajuste por emisión de OP y RM 1 1 1 1 1
EP013 - US072 Consulta de saldos deudores 1 1 1 1 1
EP013 - US073 Consulta de liquidación de declaración 1 1 1 1 1
RELEASE 3 1 1 1 1 1 1 1 1 1 1 1 1 3
SPRINT 7 1 1 1 1 1
EP053 - US572 Registro de la reimputación de ingreso como recaudación
1 1 1 1 1
(legacy)
EP045 - US508 Registrar RI de Fraccionamiento (RSIRAT) 1 1 1 1 1
EP004 - US165 Listar motivos de comunicación de diferencias 1 1 1 1 1
EP004 - US164 Mantener motivos de comunicación de diferencias 1 1 1 1 1
EP004 - US035 Registrar comunicacion de diferencias de saldos 1 1 1 1 1
EP004 - US036 Listar comunicaciones de diferencias 1 1 1 1 1
EP004 - US037 Asignar casos de comunicación de diferencias pendientes 1 1 1 1 1
EP004 - US060 Consultar detalles de comunicaciones de diferencias de
1 1 1 1 1
datos
EP004 - US039 Resolver solicitud de comunicación de diferencias con
1 1 1 1 1
cuenta
EP004 - US102 Realizar reversión de Comunicacion de diferencias 1 1 1 1 1
EP004 - US092 Aplicar documento de diferencias en cuenta 1 1 1 1 1
EP009 - US010 Ajuste automático por tolerancia 1 1 1 1 1
EP013 - US075 Consulta de liquidación de declaraciones con arrastre de
1 1 1 1 1
créditos por varios periodos
SPRINT 8 1 1 1 1 1
EP053 - US571 Registro de modificación de datos (legacy) 1 1 1 1 1
EP012 - US086 Re-proceso individual de cuentas 1 1 1 1 1
EP012 - US087 Re-proceso masivo de cuentas 1 1 1 1 1

EP021 - US178 Generación de créditos al vencimiento de renta anual 1 1 1 1 1
EP013 - US076 Información personalizada para las DDJJ 1 1 1 1 1
SPRINT 9 1 1 1 1 1
EP013 - US068 Reporte de gestión 1 1 1 1 1
EP015 - US289 Listar formularios 1 1 1 1 1
EP015 - US288 Configurar formularios 1 1 1 1 1
EP015 - US290 Configurar versiones 1 1 1 1 1
EP015 - US291 Listar versiones 1 1 1 1 1
EP015 - US293 Listar casillas 1 1 1 1 1
EP015 - US292 Configurar casillas 1 1 1 1 1
EP015 - US295 Listar plantillas 1 1 1 1 1
EP015 - US294 Configurar plantillas 1 1 1 1 1
EP015 - US147 Listar documentos de cuenta única 1 1 1 1 1

EP015 - US148 Visualizar documentos de cuenta única 1 1 1 1 1
EP028 - US296 Reversión de extorno de pago 1 1 1 1 1

EP015 - US540 Administrar numeración correlativa de valores y
resoluciones “Unidad Ejecutora Mejoramiento del Sistema de1 1Información
1 1 de la SUNAT - MSI” 1
Cierre del Sprint “CONTRATACIÓN DEL SERVICIO DE DESARROLLO, PRUEBAS Y PUESTA EN PRODUCCIÓN1 DEL
1 1 1 SISTEMA DE CUENTA ÚNICA DE CONTRIBUYENTE – MVP1 Y MVP2” 1
D-4 E-4 – Informe de Puesta en Producción del MVP 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 c 343
10
0
parte del MVP.
EP015 - US288 Configurar formularios 1 1 1 1 1
EP015 - US290 Configurar versiones 1 1 1 1 1
EP015 - US291 Listar versiones 1 1 1 1 1
EP015 - US293 Listar casillas 1 1 1 1 1
EP015 - US292 Configurar casillas 1 1 1 1 1
EP015 - US295 Listar plantillas 1 1 1 1 1
EP015 - US294 Configurar plantillas 1 1 1 1 1
EP015 - US147 Listar documentos de cuenta única 1 1 1 1 1

EP015 - US148 Visualizar documentos de cuenta única 1 1 1 1 1
EP028 - US296 Reversión de extorno de pago 1 1 1 1 1
EP015 - US540 Administrar numeración correlativa de valores y

1 1 1 1 1
resoluciones

D-4 E-4 – Informe de Puesta en Producción del MVP 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 c 10
0
parte del MVP.
Documento con prototipos de pantallas, adjuntando el informe de
aplicación de user experience (UX). 0

0
Documentos técnicos de sistemas utilizados para el desarrollo. 0
Datos requeridos para la utilización y que no tienen pantallas para
0
registro pre-cargados en las bases de datos.
0
la evidencia de su cumplimiento.
Funcionalidades del MVP implementadas y disponibles. 0
Informe de capacitación técnica y funcional. 0
Manuales de usuario virtuales del sistema. 0
0
actualizados, de ser el caso.
Documentos de Pruebas: Plan y casos de pruebas. 0
0
a cabo para la puesta en producción.
Informe histórico de Sprints ejecutados en el MVP, así como todas las
0
historias de usuario incluidas y sus correspondientes aceptaciones.
Código fuente en el repositorio SUNAT. 0
Tutorial auto administrado para el usuario del sistema. 0
Videos de clase virtual funcional del sistema. 0
Reporte de ejecución de la carga de datos) 0
Ambiente de producción funcionando correctamente sobre la

0
Versión actualizada del sistema configurada en los respectivos
0
ambientes, de acuerdo con el modelo de DevOps definido.
0
Manuales de operación de los ambientes de producción funcionando
0
correctamente
0
Validación y Correccion 1 1 1 1 1 1 1 1 2
Etapa Desarrollo, Pruebas y Puesta en Producción de los MVP2

Superintendencia Nacional de Aduanas y de Administración1 Tributaria - SUNAT
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 6
RELEASE 4 1 1 1 1 1 1 1 1 1 1 1 1 3
SPRINT 10 SPI N° 001-2019-SUNAT/BID 1 1 1 1 1
“CONTRATACIÓN DEL SERVICIO DE DESARROLLO, PRUEBAS Y PUESTA EN PRODUCCIÓN DEL SISTEMA
EP037 - US143 Generar infracción por retenciones y percepciones no
1 1 1 1
DE CUENTA ÚNICA DE CONTRIBUYENTE – MVP1 Y MVP2” 1
pagadas
EP037 - US012 Emitir Infracción por omisión a la presentación 1 1 1 1 344
1
EP037 - US020 Generar Infracción por rectificación (Declarar datos falsos) 1 1 1 1 1
EP037 - US513 Emitir RM automática 1 1 1 1 1
0
0
0
Manuales de operación de los ambientes de producción funcionando
0
correctamente
0
Etapa Desarrollo, Pruebas y Puesta en Producción de los MVP2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 6
RELEASE 4 1 1 1 1 1 1 1 1 1 1 1 1 3
SPRINT 10 1 1 1 1 1
EP037 - US143 Generar infracción por retenciones y percepciones no
1 1 1 1 1
pagadas
EP037 - US012 Emitir Infracción por omisión a la presentación 1 1 1 1 1
EP037 - US020 Generar Infracción por rectificación (Declarar datos falsos) 1 1 1 1 1
EP037 - US513 Emitir RM automática 1 1 1 1 1
EP037 - US567 Registro de infracciones de procesos independientes 1 1 1 1 1
EP037 - US184 Consulta de documentos de infracciones 1 1 1 1 1
EP037 - US188 Calcular gradualidad infraccion 1 1 1 1 1
EP037 - US007 Realizar baja de Infracción 1 1 1 1 1
EP037 - US466 Realizar reversión de RM 1 1 1 1 1
EP037 - US538 Reproceso de detección de infracciones 1 1 1 1 1
SPRINT 11 1 1 1 1 1
EP001 - US051 Registrar Solicitud de Compensación de créditos 1 1 1 1 1
EP001 - US052 Seleccionar contribuyente 1 1 1 1 1
EP001 - US151 Mantener criterios de uso de créditos 1 1 1 1 1
EP001 - US054 Asignar solicitudes de compensación de créditos 1 1 1 1 1
EP001 - US160 Listar tributos compensables 1 1 1 1 1
EP001 - US083 Mantener tributos compensables 1 1 1 1 1
EP001 - US150 Consultar saldos de créditos de Cuenta Unica para Uso o
1 1 1 1 1
Reconocimiento de Pagos con Error
EP001 - US055 Resolver Solicitudes de Compensación de créditos 1 1 1 1 1
EP001 - US091 Aplicar compensación en cuenta 1 1 1 1 1
EP001 - US120 Realizar reversión de compensación 1 1 1 1 1
EP001 - US056 Consultar detalles de solicitudes de compensación 1 1 1 1 1
EP001 - US153 Seleccionar crédito de compensación 1 1 1 1 1
EP001 - US053 Listar solicitudes de compensación 1 1 1 1 1
EP001 - US327 Generar solicitudes de compensación de oficio
1 1 1 1 1
automáticas
EP009 - US548 Conclusión de trámites enviados a legacy 1 1 1 1 1
D-6 E-6 - Informe de implementación del Release 4 1 1 1 1 1 1 1 1 1 1 1 1 c 3
0
parte del release.
Prototipos de pantallas, adjuntando informe de aplicación de user
0
experience (UX)
0
Documentos técnicos de sistemas utilizados para el desarrollo 0
Datos requeridos para utilización y no tienen pantallas para registro pre-
0
cargados en las BBDD
0
la evidencia de su cumplimiento
Funcionalidades implementadas y disponibles 0
0
actualizados, de ser el caso
Documentos de Pruebas: Plan y casos de pruebas 0
0
a cabo.
Acta de Aceptación de usuario 0
Informe histórico de Sprints ejecutados y todas las historias de usuario
0
incluidas y sus aceptaciones.
Código fuente en el repositorio SUNAT
Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT 0
Reporte de trazabilidad de historia de usuario vs código fuente. “Unidad Ejecutora Mejoramiento del Sistema de Información de la SUNAT - MSI” 0
0
Reporte de ejecución de la carga de datos) SPI N° 001-2019-SUNAT/BID
RELEASE 5 “CONTRATACIÓN DEL SERVICIO DE DESARROLLO, PRUEBAS Y PUESTA EN PRODUCCIÓN DEL SISTEMA DE CUENTA ÚNICA
1 1 1 1DE
1 1CONTRIBUYENTE
1 1 1 1 1 1 – MVP1 Y MVP2” 3
SPRINT 12 1 1 1 1 1
1
EP015 - US175 Listar solicitudes del contribuyente 1 1 1 1 1
EP012 - US348 Registrar documento de modificación de coeficiente de
1 1 1 1 1
Renta
0
parte del release.
0
experience (UX)
0
Datos requeridos para utilización y no tienen pantallas para registro pre-
0
cargados en las BBDD
0
Funcionalidades implementadas y disponibles 0
0
0
a cabo.
Acta de Aceptación de usuario 0
Informe histórico de Sprints ejecutados y todas las historias de usuario
0
incluidas y sus aceptaciones.
Reporte de trazabilidad de historia de usuario vs código fuente. 0
0
RELEASE 5 1 1 1 1 1 1 1 1 1 1 1 1 3
SPRINT 12 1 1 1 1 1
EP015 - US175 Listar solicitudes del contribuyente 1 1 1 1 1
EP012 - US348 Registrar documento de modificación de coeficiente de
1 1 1 1 1
Renta
EP012 - US349 Listar documentos de modificación de coeficiente de
1 1 1 1 1
Renta
EP012 - US350 Modificar documento preliminar de modificación de
1 1 1 1 1
EP012 - US352 Aplicar documento de modificación de coeficiente de
1 1 1 1 1
Renta
EP012 - US351 Consultar documento de modificación de coeficiente de
1 1 1 1 1
Renta
EP012 - US354 Generar documento de modificación de coeficiente de
1 1 1 1 1
Renta autom. o masiva
EP012 - US353 Realizar reversión de documento de modificación de
1 1 1 1 1
EP012 - US340 Registrar documento de modificación de prorrata cálculo
1 1 1 1 1
de IGV
EP012 - US341 Listar documentos de modificación de prorrata para el
1 1 1 1 1
cálculo de IGV
EP012 - US342 Modificar doc. preliminar de modificación de prorrata
1 1 1 1 1
para el cálculo de IGV
EP012 - US344 Aplicar documento de modificación de prorrata para el
1 1 1 1 1
cálculo de IGV
EP012 - US343 Consultar detalle de doc. de modificación de prorrata
1 1 1 1 1
para el cálculo de IGV
EP012 - US345 Realizar reversión de documento de mod. de prorrata
1 1 1 1 1
para cálculo de IGV
EP012 - US346 Generar documento de modificación de prorrata IGV
1 1 1 1 1
automática o masiva
SPRINT 13 1 1 1 1 1
EP008 - US105 Registrar solicitud de devolución 1 1 1 1 1
EP008 - US107 Resolver casos de devolución 1 1 1 1 1
EP008 - US044 Aplicar devolución en cuenta 1 1 1 1 1
EP008 - US302 Realizar reversión de devolución 1 1 1 1 1
EP008 - US034 Consultar detalles de solicitud de devolución 1 1 1 1 1
EP008 - US108 Listar solicitudes de devolución 1 1 1 1 1
EP008 - US106 Asignar solicitudes de devolucion 1 1 1 1 1
EP008 - US333 Generar solicitudes de devolución de oficio automáticas 1 1 1 1 1
RELEASE 6 1 1 1 1 1 1 1 1 1 1 1 1 3
SPRINT 14 1 1 1 1 1
EP005 - US040 Registrar Solicitud de Reconocimiento de Pago con Error 1 1 1 1 1
EP005 - US045 Seleccionar crédito para reconocimiento de pago con
1 1 1 1 1
|| error
EP005 - US047 Asignar solicitudes de reconocimiento de pago con error 1 1 1 1 1
EP005 - US048 Resolver caso de solicitud de reconocimiento de pago con
1 1 1 1 1
error
EP005 - US049 Listar solicitudes de reconocimiento de pago con error 1 1 1 1 1
EP005 - US311 Aplicar reconocimiento de pagos con error en cuenta 1 1 1 1 1
EP005 - US050 Consulta de solicitudes de reconocimiento de pago con Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT 1 1 1 1 1
error
EP005 - US096 Realizar Reversión de Reconocimiento de Pago con Error
“Unidad Ejecutora Mejoramiento del Sistema de Información de la SUNAT - MSI” 1 1 1 1 1
EP005 - US331 Generar solicitudes de reconocimiento de pago con error
1 1 1 1 1
de oficio automáticas
Servicios del COE - Centro de Excelencia SPI N° 001-2019-SUNAT/BID 1 1 1 1 1
“CONTRATACIÓN DEL SERVICIO DE DESARROLLO, PRUEBAS Y PUESTA EN PRODUCCIÓN DEL SISTEMA DE CUENTA ÚNICA DE CONTRIBUYENTE
Desarrllo UX para el siguiente Sprint 1 1 1 1
– MVP1 Y MVP2” 1
SPRINT 15
Diseño, Desarrollo, Definición de casos de pruebas, CI/CD Sprint
1 1 1 1
1 1 1 1
346
1
1
EP006 - US276 Listar campos modificacion de datos 1 1 1 1 1
EP006 - US057 Registrar de solicitud de modificacion de datos 1 1 1 1 1
EP008 - US034 Consultar detalles de solicitud de devolución 1 1 1 1 1
EP008 - US108 Listar solicitudes de devolución 1 1 1 1 1
EP008 - US106 Asignar solicitudes de devolucion 1 1 1 1 1
EP008 - US333 Generar solicitudes de devolución de oficio automáticas 1 1 1 1 1
RELEASE 6 1 1 1 1 1 1 1 1 1 1 1 1 3
SPRINT 14 1 1 1 1 1
EP005 - US040 Registrar Solicitud de Reconocimiento de Pago con Error 1 1 1 1 1
EP005 - US045 Seleccionar crédito para reconocimiento de pago con
1 1 1 1 1
error
EP005 - US047 Asignar solicitudes de reconocimiento de pago con error 1 1 1 1 1
EP005 - US048 Resolver caso de solicitud de reconocimiento de pago con
1 1 1 1 1
error
EP005 - US049 Listar solicitudes de reconocimiento de pago con error 1 1 1 1 1
EP005 - US311 Aplicar reconocimiento de pagos con error en cuenta 1 1 1 1 1
EP005 - US050 Consulta de solicitudes de reconocimiento de pago con
1 1 1 1 1
error
EP005 - US096 Realizar Reversión de Reconocimiento de Pago con Error 1 1 1 1 1
EP005 - US331 Generar solicitudes de reconocimiento de pago con error
1 1 1 1 1
de oficio automáticas
SPRINT 15 1 1 1 1 1
EP006 - US276 Listar campos modificacion de datos 1 1 1 1 1
EP006 - US057 Registrar de solicitud de modificacion de datos 1 1 1 1 1
EP006 - US058 Listar solicitudes de modificación de datos 1 1 1 1 1
EP006 - US059 Asignar casos de modifcacion de datos 1 1 1 1 1
EP006 - US062 Resolver Casos de Modificación de Datos 1 1 1 1 1
EP006 - US310 Aplicar solicitud de modificación de datos 1 1 1 1 1
EP006 - US117 Realizar reversión de modificación de datos 1 1 1 1 1
EP006 - US063 Consultar detalles solicitudes de modificacion de datos 1 1 1 1 1
EP006 - US332 Generar solicitudes de modificacion de datos de oficio
1 1 1 1 1
automáticas
EP014 - US266 Seleccionar créditos de Cuenta de Ingreso como
1 1 1 1 1
Recaudación SUNAT
EP014 - US267 Solicitud reimputación de cuenta de ingreso
1 1 1 1 1
(Detracciones)
EP014 - US269 Listar solicitudes reimputación de cuentas de ingreso
1 1 1 1 1
(Detracciones)
EP014 - US272 Consultar solicitudes de reimputacion de cuentas de
1 1 1 1 1
ingreso Detracciones
EP014 - US270 Asignar solicitudes de reimputacion 1 1 1 1 1
EP014 - US271 Resolver casos de reimputación de cuentas de ingreso
1 1 1 1 1
(Detracciones)
EP014 - US312 Aplicar casos de reimputación de cuentas de ingreso
1 1 1 1 1
(Detracciones)
EP014 - US137 Realizar reversión de reimputación de cuentas de ingreso 1 1 1 1 1
EP014 - US335 Generar solicitud de reimputación de montos en cuenta
1 1 1 1 1
de ingreso
EP041 - US546 Generar reporte preliminar de créditos prescritos 1 1 1 1 1
D -7 E-7 – Informe de Puesta en Producción del MVP 2 c 0
0
parte del MVP.
0
experience (UX).
0
Datos requeridos para utilización y que no tienen pantallas para registro
0
0
Funcionalidades del MVP implementadas y disponibles 0
Informe de capacitación técnica y funcional 0
Manuales de usuario virtuales del sistema 0
0
0
| Informe histórico de Sprints ejecutados en el MVP, todas las historias de
usuario y sus aceptaciones.
0
Tutorial autoadministrado para usuario del sistema, para guiar en su
0
uso, indicando oral y visualmente los datos a registrar
Videos de clase virtual funcional del sistema. Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT 0
Reporte de ejecución de la carga de datos) “Unidad Ejecutora Mejoramiento del Sistema de Información de la SUNAT - MSI” 0
Fase de Migración Desarrollo y Pruebas 1 1 1 1 1 1 1 1 2
Etapa Instalación, Configuración y Migración de Ambientes de SPI N° 001-2019-SUNAT/BID 0
Hito: Ambientes de Desarrollo y Pruebas de Sunat Dispoibles c 0
Configuración de IAM en Cloud SUNAT
Configuración de Políticas,Grupos, Usuarios,Roles
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
347
2
2
Configuración de redes, balanceadores y firewall 1 1 1 1 1 1 1 1 2
Configuración de VPN 1 1 1 1 1 1 1 1 2
experience (UX).
0
Datos requeridos para utilización y que no tienen pantallas para registro
0
0
Funcionalidades del MVP implementadas y disponibles 0
Informe de capacitación técnica y funcional 0
Manuales de usuario virtuales del sistema 0
0
0
Informe histórico de Sprints ejecutados en el MVP, todas las historias de
0
usuario y sus aceptaciones.
Tutorial autoadministrado para usuario del sistema, para guiar en su
0
uso, indicando oral y visualmente los datos a registrar
Videos de clase virtual funcional del sistema. 0
0
Fase de Migración Desarrollo y Pruebas 1 1 1 1 1 1 1 1 2
Etapa Instalación, Configuración y Migración de Ambientes de
0
Hito: Ambientes de Desarrollo y Pruebas de Sunat Dispoibles c 0
Configuración de IAM en Cloud SUNAT 1 1 1 1 1 1 1 1 2
Configuración de Políticas,Grupos, Usuarios,Roles 1 1 1 1 1 1 1 1 2
Configuración de redes, balanceadores y firewall 1 1 1 1 1 1 1 1 2
Configuración de VPN 1 1 1 1 1 1 1 1 2
Migración de AED y ETL 1 1 1 1 1 1 1 1 2
Adecuación y ejecución de playbooks para Kubernetes 1 1 1 1 1 1 1 1 2
Adecuación y ejecución de playbooks para Monitoreo Nube 1 1 1 1 1 1 1 1 2
Adecuación y ejecución de playbooks para Monitoreo MS 1 1 1 1 1 1 1 1 2
Adecuación y ejecución de playbooks para Kong - Api Gateway 1 1 1 1 1 1 1 1 2
Adecuación y ejecución de playbooks para Kafka 1 1 1 1 1 1 1 1 2
Adecuación y ejecución de playbooks para MongoDB 1 1 1 1 1 1 1 1 2
Adecuación y ejecución de playbooks para Redis 1 1 1 1 1 1 1 1 2
Adecuación y ejecución de playbooks para Consul 1 1 1 1 1 1 1 1 2
Adecuación y ejecución de playbooks para Repositorios 1 1 1 1 1 1 1 1 2
Adecuación y ejecución de playbooks para CI/CD 1 1 1 1 1 1 1 1 2
Configuración de pipelines 1 1 1 1 1 1 1 1 2
Ejecución de pipelines 1 1 1 1 1 1 1 1 2
Configurar Monitoreo 1 1 1 1 1 1 1 1 2
Carga Inicial de Datos 1 1 1 1 1 1 1 1 2
Certificación de ambientes 1 1 1 1 1 1 1 1 2
Manuales, documentación y diagramas técnicos actualizados 1 1 1 1 1 1 1 1 2
Informe de capacitación a técnicos de Sunat 1 1 1 1 1 1 1 1 2
Hito: Ambientes de Sunat de Desarrollo y Pruebas Disponibles y
0
Operativos c
Hito: Capacitación Técnica Aprobada c 0
D-9 E-9 – Informe de Migración de los ambientes de Desarrollo y Pruebas 1 1 1 1 1 1 1 1 c 2
Ambientes de desarrollo y pruebas funcionando correctamente sobre la
0
0
soportar la utilización de la versión más actual del sistema en cada uno 0
de los ambientes configurados.
Código fuente del sistema actualizado en las herramientas del modelo
0
de DevOps en la Plataforma de LA SUNAT.
Documentación de todas las pruebas realizadas en los ambientes para
0
asegurar su correcto funcionamiento.
Manuales de operación de los ambientes de desarrollo y pruebas
0
funcionando correctamente.
Documentación de las configuraciones de seguridad, backups y todo lo
0
Informe de capacitación a técnicos de LA SUNAT. 0
Fase de Capacitación y Transferenica de Conocimiento 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4
Capacitación Técnico de LA SUNAT 0
Capacitación en Uso, Administración y Operación MVP 1 1 1 1 1 1 1 1 1 2
Hito: Capacitación Funcional Aprobada c 0
D-10 E-10 - Informe de Capacitación y Transferencia de Conocimientos c 0
Conformidad de la capacitación 0
Fase de Mantenimiento Correctivo y Soporte 0
Mantenimiento Correctivo 0
Soporte y Operación Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT 0
E-11 - Informe mensual de Mantenimiento Correctivo y de Soporte y
0
D-11 Operación “Unidad Ejecutora Mejoramiento del Sistema de Información de la SUNAT - MSI” c
Informe de Atención de Incidencias atendidos 0
Informes con las actividades de soporte, identificando la cronología de
0
actividades. SPI N° 001-2019-SUNAT/BID
Informes con las actividades de soporte, identificando el estatus de
tickets de soporte. “CONTRATACIÓN DEL SERVICIO DE DESARROLLO, PRUEBAS Y PUESTA EN PRODUCCIÓN DEL SISTEMA DE CUENTA ÚNICA DE CONTRIBUYENTE – MVP1 Y MVP2” 0
Prestación Accesoria: Mantenimiento Evolutivo

348
0
E-11-1 - Informe mensual de Soporte y Operación 0

D-11-1 c
Hito: Capacitación Funcional Aprobada c 0
D-10 E-10 - Informe de Capacitación y Transferencia de Conocimientos 1 1 1 1 1 1 1 1

c 2
Conformidad de la capacitación 0
Fase de Mantenimiento Correctivo y Soporte 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9
Mantenimiento Correctivo 0
Soporte y Operación 0
E-11 - Informe mensual de Mantenimiento Correctivo y de Soporte y
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9
D-11 Operación c
Informe de Atención de Incidencias atendidos 0
Informes con las actividades de soporte, identificando la cronología de
0
actividades.
Informes con las actividades de soporte, identificando el estatus de
0
tickets de soporte.
Prestación Accesoria: Mantenimiento Evolutivo 0
Hito: Informe mensual de Mantenimiento Correctivo y de Soporte y

Operación aprobado.
c c c c c c c c c 0
D-11-1 E-11-1 - Informe mensual de Soporte y Operación c 0
D-11-2 E-11-2 - Informe de Actividades de Mantenimiento Evolutivo c 0
D-11-3 E-11-3- Informe de Actividades de Mantenimiento Evolutivo c 0
Tabla 51: TECH-5: Cronograma de los trabajos y planificación de entregables

349
4.1 Anexo 2: Ruta Crítica.
Plan de actividades AÑO 1 AÑO 2
Plan S1 S2 S4 S5 S7 S8 S9 S12 S16 S20 S24 S28 S29 S32 S36 S37 S40 S44 S45 S48 S49 S52 S53 S56 S57 S60 S61 S64 S65 S68 S69 S72 S73 S77 S84 S85 S89 S92
Hito: Capacitación Recibida por Sunat c

Hito: Información Entregada por Parte de la Sunat c
Hito: Perosnal del Proyecto Disponible por Sunat c
Hito: Toda la Información de las Reglas de Negocio Entregadas por Sunat c
Hito: Ambientes Desarrollo y Pruebas Configurados y Disponibles c
Hito: Equipos de Trabajo Conformados y Capacitados c
E-1 Plan de Gestión del Proyecto c
Hito: Reunión de Incremento de Producto Realizada c
Hito: Base de Datos Configurada y Disponible c
Hito: Plan de Gestión Aprobado c
Hito: Ambientes Desarrollo y Pruebas - Operativos y Disponibles c
E-2 Informe de preparación de ambientes de Desarrollo y Pruebas c
Hito: AED del MVP1 Configurados y Operativos MVP1 c c c c c c c c c
Hito: Informe de preparación de ambientes de Desarrollo y Pruebas - Aprobado c
Hito: Migración MVP1 Verificada c c c c
Hito: Entrega Ambientes de Preproducción y Produccón por parte de Sunat c
Hito: Ambientes de Preproducción y Produccón Configurados y Operativos c
E-3 Informe de implementación del Release 1 y creación de ambiente de pre-producción c
E-4 – Informe de Puesta en Producción del MVP 1 c
E-11-1 - Informe mensual de Soporte y Operación c
Hito: Informe mensual de Mantenimiento Correctivo y de Soporte y Operación aprobado. c c c c c c c c
Hito: AED del MVP1 Configurados y Operativos MVP2 c c c c c c
E-5 Informe de carga inicial de datos del MVP1 c
Hito: Migración MVP2 Verificada c c c
E-6 - Informe de implementación del Release 4 c
Hito: Migración MVP2 Verificada c
E-7 – Informe de Puesta en Producción del MVP 2 c
E-11-2 - Informe de Actividades de Mantenimiento Evolutivo c
Hito: Ambientes de Desarrollo y Pruebas de Sunat Dispoibles c
Hito: Ambientes de Sunat de Desarrollo y Pruebas Disponibles y Operativos c
E-8 Informe de carga inicial de datos del MVP2 c
Hito: Capacitación Técnica Aprobada c
E-9 – Informe de Migración de los ambientes de Desarrollo y Pruebas c
Hito: Capacitación Funcional Aprobada c
E-10 - Informe de Capacitación y Transferencia de Conocimientos c
E-11 - Informe mensual de Mantenimiento Correctivo y de Soporte y Operación c
E-12 Informe final del Proyecto c
Hito: Informe Final de Proyecto Aprobado c
E-11-3- Informe de Actividades de Mantenimiento Evolutivo c
Tabla 52: Ruta Crítica

350
4.2 Anexo 3: Cronograma de Hitos
Hitos Fecha
Hito: Plan de Gestión Aprobado Semana 08
Hito: Informe Final de Proyecto Aprobado Semana 92
Hito: Capacitación Recibida por Sunat Semana 01
Hito: Base de Datos Configurada y Disponible Semana 07
Hito: Migración MVP1 Verificada Semana 20, 32, 44, 53
Hito: Migración MVP2 Verificada Semana 56, 68, 77
Semana 12, 16, 20, 24, 28, 32, 36, 40,
Hito: AED del MVP1 Configurados y Operativos MVP1
44,
Hito: AED del MVP1 Configurados y Operativos MVP2 Semana 48, 52, 56, 60, 64, 68
Hito: Migración MVP2 Verificada Semana 64
Hito: Información Entregada por Parte de la Sunat Semana 01
Hito: Ambientes Desarrollo y Pruebas Configurados y Disponibles Semana 04
Hito: Ambientes Desarrollo y Pruebas - Operativos y Disponibles Semana 08
Hito: Informe de preparación de ambientes de Desarrollo y Pruebas - Aprobado Semana 12
Hito: Entrega Ambientes de Preproducción y Produccón por parte de Sunat Semana 29
Hito: Ambientes de Preproducción y Produccón Configurados y Operativos Semana 37
Hito: Toda la Información de las Reglas de Negocio Entregadas por Sunat Semana 02
Hito: Personal del Proyecto Disponible por Sunat Semana 01
Hito: Reunión de Incremento de Producto Realizada Semana 05
Hito: Equipos de Trabajo Conformados y Capacitados Semana 04
Hito: Ambientes de Desarrollo y Pruebas de Sunat Dispoibles Semana 72
Hito: Ambientes de Sunat de Desarrollo y Pruebas Disponibles y Operativos Semana 73
Hito: Capacitación Técnica Aprobada Semana 84
Hito: Capacitación Funcional Aprobada Semana 84
Hito: Informe mensual de Mantenimiento Correctivo, y Soporte y Operación
Semana 45, 49, 53, 57, 61, 65, 73, 77
aprobado.
Tabla 53: Cronograma de Hitos

351

S001-2019 Cuc Sunat Tech4 VF PDF

Cargado por

Copyright:

Formatos disponibles

S001-2019 Cuc Sunat Tech4 VF PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

S001-2019 Cuc Sunat Tech4 VF PDF

Cargado por

Copyright:

Formatos disponibles

Formulario TECH-4: Descripción del enfoque, metodología y plan

de trabajo para responder a los Términos de Referencia

ÍNDICE GENERAL ............................................................................................................................... 1

LISTADO DE ILUSTRACIONES ......................................................................................................... 9

LISTADO DE TABLAS ...................................................................................................................... 12

1 ENFOQUE TÉCNICO Y METODOLOGÍA ................................................................................. 14

1.1 DEFINICIONES ....................................................................................................................... 14

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

2 PLAN DE TRABAJO ............................................................................................................... 191

2.1 INTRODUCCIÓN ................................................................................................................... 191

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

3 ORGANIZACIÓN Y DOTACIÓN DE PERSONAL ................................................................... 319

3.1 ORGANIGRAMA ................................................................................................................... 319

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

Ilustración 1: Ámbitos de transformación de la Administraciones tributarias ..................................... 17

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

Tabla 1: Compensaciones .................................................................................................................. 35

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

1.2.1 Objetivos estratégicos del Proyecto

El objetivo del proyecto persigue el fortalecimiento institucional de la SUNAT en sus funciones

 Mejorar la efectividad del control del cumplimiento Aduanero y Tributario, a través de

 Brindar servicios de calidad para facilitar y fomentar el cumplimiento voluntario,

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

 Profundizar el desarrollo de la conciencia aduanera y fiscal en la ciudadanía

 Fortalecer el desarrollo institucional de la SUNAT y sus recursos humanos

A través del cumplimiento de estos objetivos se contribuirá a:

 Apoyar la mejora de la elaboración de estudios y estadísticas tributarias, que permitirán

 Eliminar la problemática originada por la existencia de diversos sistemas y fuentes

 Permitir al contribuyente y al usuario de comercio exterior una consulta unificada de

 Relación con el Contribuyente

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

Cálculo de la brecha fiscal

Ilustración 1: Ámbitos de transformación de la Administraciones tributarias

Es en este contexto, es donde la implementación del Sistema de Cuenta Única de Contribuyente

o Información unificada, integrada y actualizada del estado de cumplimento de

 Ofrecer al contribuyente información consolidada de su situación de forma inmediata e

o Favoreciendo e incentivando el cumplimiento voluntario de sus obligaciones.

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

o Facilitando la adecuación organizativa y el diseño de políticas de cobro

 Establecer métricas de gestión que permitan implementar procesos de mejora continua.

Contribuyendo todo lo anterior a: minorar los costos de la Administración y a aumentar la

La Transformación cultural es imprescindible para el cambio de mentalidad y

1.2.2 La experiencia del CONSORCIO

1.2.2.1 Visión de las Administraciones Tributarias y Aduaneras

En un entorno de transformación digital y evolución tecnológica constante, los grandes objetivos de

 Ofrecer al ciudadano herramientas que faciliten el cumplimiento de sus obligaciones

 Mejorar la eficiencia interna y los procesos de mejora continua de la Administración

Superintendencia Nacional de Aduanas y de Administración Tributaria - SUNAT

 Proporcionar mecanismos para garantizar la trazabilidad y la transparencia en la gestión.

 Agilizar y reducir el coste del mantenimiento de los sistemas y su rápida adecuación a

El CONSORCIO cubre las necesidades de transformación de las TRES ÁREAS CLAVE de