Oferta Técnica Contraloría-v2.1 (25042022)x

El Servicio de Fábrica de Software
para la Implementación de
Subsistemas del Sistema
Integrado de los Servicios de
Control de la CGR y OCIS
Oferta Técnica
SBCC N» 003-2021-CG-UE002/BID3 - Fábrica de
Software para la Implementación de Subsistemas del
Sistema Integrado de los Servicios de Control de la CGR y
OCIS
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
1 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Contenidos
1
2
Enfoque Técnico, Metodología y Organización __ 5
1.1
Pilares de Nuestra Oferta _____________________________ 5
1.2
Visión general del Proyecto ___________________________ 9
Enfoque Técnico ________________________ 11
2.1
Estructura Organizativa _____________________________ 11
2.1.1 Asignación de Perfiles a la Estructura Organizativa ____________________ 12
2.1.2 Perfiles y Funciones ____________________________________________ 12
2.2
Modelo de relación del proyecto _______________________ 16
2.2.1 Estructura de los comités de seguimiento ___________________________ 17
2.2.2 Interlocutores oficiales del servicio _________________________________ 21
2.3
Planteamiento General de la Solución __________________ 23
2.4
Estrategia metodológica _____________________________ 24
2.4.1 SCRUM ______________________________________________________ 24
2.4.2 Kanban ______________________________________________________ 26
2.4.3 Metodología de calidad y pruebas __________________________________ 26
2.4.4 Plan de transición del modelo tradicional hacia el modelo ágil ____________ 42
3
Metodología integral del proyecto ___________ 43
3.1
Portfolio de Servicio ________________________________ 43
3.2
Gestión del Cambio ________________________________ 45
3.2.1 Inducción a la Agilidad __________________________________________ 45
3.2.2 Capacitación y Mentoría _________________________________________ 45
3.3
Modelo de desarrollo _______________________________ 47
3.3.1 Metodología de desarrollo ágil ____________________________________ 48
3.3.2 Entorno de integración continua ___________________________________ 54
3.3.3 Modelo de pruebas funcionales y aceptación _________________________ 55
3.4
Gestión Operativa del Proyecto _______________________ 60
3.4.1 Plataforma de Gestión __________________________________________ 60
3.4.2 Gestión de la Demanda _________________________________________ 63
3.4.3 Estimación de los trabajos _______________________________________ 64
3.4.4 Gestión de la Línea Base_________________________________________ 64
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
2 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
3.4.5 Modelo Económico _____________________________________________ 65
3.5
Medición e indicadores ______________________________ 65
3.5.1 Enfoque para la Determinación de Acuerdos de Nivel de Servicio (ANS) ____ 67
3.5.2 ANS Iniciales Propuestos ________________________________________ 69
4 Descripción del plan de trabajo, personal de las
principales actividades, incluyendo entre otros
planes, componentes, fases y alcances incluidos en
los TDR. _________________________________ 75
4.1
Fases del Servicio __________________________________ 75
4.1.1 Fase Pre-Operativa del Servicio y Etapa de Implementación _____________ 75
4.1.2 Fase II Ejecución del Servicio - Etapa de Implementación _______________ 79
4.1.3 Fase II Ejecución del Servicio - Etapa Operativa ______________________ 89
4.1.4 Fase III Transferencia y Cierre ____________________________________ 92
4.1.5 Garantía del Servicio ___________________________________________ 93
5 Relación del plan de trabajo con el enfoque
técnico y la metodología. ____________________ 95
6 Propuestas de valor agregado para innovación
tecnológica y de gestión. ____________________ 96
6.1
Modelo de gobierno extendido con AMS+ _______________ 96
6.2
Modelo maduro y automatizado de medición de proyectos
ágiles y ANS __________________________________________ 101
6.3
Nueva arquitectura Java ____________________________ 103
6.3.1 Arquitectura propuesta ______________________________________ 103
6.3.2 Capa de presentación web ____________________________________ 107
6.3.3 Frameworks Java para el desarrollo de la arquitectura ___________ 107
6.3.4 JVM _______________________________________________________ 108
6.3.5 CI/CD _____________________________________________________ 109
6.3.6 Arquitecturas, metodologías, patrones y diseños de software _____ 110
6.4
Nueva Arquitectura de Datamart _____________________ 115
6.4.1 Arquitectura Propuesta _________________________________________ 116
6.4.2 Herramientas para el Desarrollo del Datamart _______________________ 118
6.4.3 Buenas Prácticas para el Desarrollo de Datamarts ____________________ 121
6.4.4 Ciclo de Vida del Desarrollo para Datamart _________________________ 121
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
3 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
4 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
1 Enfoque Técnico, Metodología y
Organización
El contenido del presente documento constituye la oferta técnica elaborada por Inetum Perú, en
adelante Inetum, en respuesta al expediente Contraloría General de La República del Perú con
objeto “El Servicio de Fábrica de Software para la Implementación de Subsistemas del
Sistema Integrado de los Servicios de Control de la CGR y OCIS”. Inetum acata en la presente
oferta de manera general todas las condiciones, básicas y particulares, que vienen expuestas en los
pliegos administrativo y técnico de la licitación.
1.1 Pilares de Nuestra Oferta
Abordar un servicio como este, requiere de una estrategia, capacitación y experiencia que
resuelva los principales retos identificados y cumpla los objetivos
trazados en periodos oportunos.
En la propuesta de Inetum se ha planteado no solo identificar los retos
asociados al proyecto sino proponer estrategias de mitigación de los
riesgos y problemas derivados, que maximicen las garantías de éxito del
proyecto.
Inetum quiere y aspira a ser por ello, el acompañante perfecto de CGR
en este proyecto.
A continuación, se repasa la estrategia para facilitar la lectura del resto de apartados de la propuesta
de colaboración y su contextualización en el proyecto global, indicando los puntos en los que Inetum
considera que su propuesta es diferenciadora.
1. Equipo con amplio conocimiento contrastado en el negocio y tecnologías
implicadas
Este proyecto está enfocado en brindar un modelo flexible y maduro orientado a satisfacer el
desarrollo y soporte integral de las nuevas aplicaciones contenidas en su alcance.
Inetum ha participado con éxito en desarrollos similares como por ejemplo el proyecto de
desarrollo y mantenimiento de la infraestructura DevOps y aplicaciones transversales de
Belcorp, Pacífico Seguros y Vida, entre otros.
Por este motivo, somos conocedores de las características y problemáticas diversas asociadas
a este tipo de proyectos, lo cual aporta un alto valor añadido para poder abordar con muchas más
garantías.
Inetum ha conformado un equipo con conocimiento y experiencia contrastada, tanto en la
tecnología en la que CGR ha decidido basar la implementación de la nueva solución, como en las
funcionalidades inherentes a los diferentes módulos objeto de la implementación dentro del alcance
del proyecto.
2. Sistemas de aseguramiento y control de calidad de las aplicaciones
Inetum lleva años en una dinámica de mejora de los diferentes servicios, tanto en el aseguramiento
de la calidad del código de las aplicaciones como de su integridad y entrega. Al igual que CGR,
Inetum tiene una preocupación porque las aplicaciones no solo hagan lo que tienen que
hacer, sino que lo hagan de una manera adecuada y mantenible, y que la calidad del código
implantado para tal efecto sea la satisfactoria.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
5 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Para ello, Inetum, pondrá a disposición de este servicio y de las diferentes aplicaciones implicadas,
un entorno de integración continua, así como de análisis de métricas de calidad de código,
integrando las aplicaciones involucradas en el alcance.
3. Adquisición del conocimiento
Con el equipo que Inetum propone para este proyecto, la transferencia del conocimiento
podrá ser minimizada en cierta medida, ya que se trata de un equipo experimentado en
los ámbitos tecnológicos y de negocio que se requieren abordar en este caso, así como
también en el planteamiento de soluciones bajo el modelo de fábrica de software.
Por otra parte, Inetum se apoyará en sus experiencias previas trabajando para grandes
clientes en este ámbito.
Además, contamos con experiencia en la gestión de Servicios tipo ANS de Mantenimiento
de Aplicaciones desarrolladas en tecnología Java-EE en distintas entidades de la
Administración Pública a nivel nacional e internacional.
4.
Certificaciones
Inetum es una empresa que, entre otras certificaciones, tiene sus procesos certificados
según CMMI en un Nivel 5 a nivel internacional, y cuyos controles internos de
verificación y validación que garantizan el funcionamiento fluido de los proyectos y
servicios en todo el ciclo de vida, desde la planificación hasta la entrega son predicados y
aplicados en sus diversas sedes, como es el caso de Inetum España SA Sucursal Perú.
5. Cercanía y confianza
Inetum cuenta con más 500 profesionales localizados en Perú y una trayectoria de más
de 20 años en el ámbito de las nuevas tecnologías, dónde posee dos Centros de Trabajo,
totalmente desplegados y brindando servicio en remoto y en línea a nuestros clientes.
Para este servicio estamos proponiendo un equipo de profesionales cualificados y con alto
grado de dedicación y experiencia en los entornos tecnológicos objeto del servicio. Pero
además Inetum cuenta con contrastada capacidad y solvencia para cubrir eventuales
contingencias en los entornos objeto de la prestación del servicio, puesto que dispone de
un plantel multidisciplinar de profesionales cualificados por entorno de trabajo.
Esta cercanía, se demuestra a través de los profesionales del equipo regular de
Inetum, que ya trabajan para nuestros proyectos, es decir, no son fruto de una acción
de búsqueda de CV en una base de datos general para poder abordar esta oferta.
6. Marco de trabajo
Inetum tiene implantada una metodología propia de trabajo "AMS+”, que cubre todo el
ciclo de vida de desarrollo software, combinando la adaptabilidad de las prácticas Agile,
con la predictibilidad que proporcionan los procesos de alta madurez en el modelo CMMI.
Esta metodología se desarrolló como marco de trabajo en los Centros de Ingeniería de
Software (CIS) de Inetum, extendiéndose posteriormente como marco de trabajo común
para todos los proyectos de desarrollo o servicios de mantenimiento de Inetum, tanto si
se prestan estos servicios desde nuestros Centros de Servicio, como si se prestan
con equipos constituidos específicamente para un proyecto de un cliente
concreto. Dicho modelo de trabajo aporta ventajas diferenciadoras entre las que
destacamos las siguientes:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
6 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
 Mayor madurez de proceso: esta forma de trabajo se ajusta a las buenas
prácticas establecidas por el modelo CMMI. Bajo este modelo de procesos se lleva
a cabo el desarrollo software en los proyectos bajo un enfoque de “llave en mano”.
 Orientación a servicios: Adicionalmente se dispone de un modo de trabajo
complementario al anterior basado en servicios continuos de desarrollo. Todas las
peticiones basadas en Acuerdos de Nivel de Servicio, sea la gestión de incidencias
como toda la gestión de peticiones de mantenimiento evolutivo estarían cubiertas
bajo procesos específicos orientados a la prestación de servicios.
 Mayor enfoque a las necesidades de los clientes: este modelo está basado en
ciclos de vida iterativos e incrementales, con iteraciones cortas, lo que permite
aportar visibilidad de los resultados parciales de los desarrollos a los clientes y dirigir
el trabajo en las siguientes iteraciones de acuerdo a sus necesidades.
Adicionalmente, hay que destacar que este modo de trabajo se basa en buenas
prácticas de metodologías de desarrollo ágil (SCRUM y Kanban), que centran el
trabajo en generar valor continuado al proyecto entre equipos de personas que
realizan el trabajo de manera colaborativa.
Este enfoque de desarrollo, que permite aportar flexibilidad y rapidez de respuesta,
está integrado con las prácticas de CMMI de manera que no se perjudique la
visibilidad en todo el ciclo de desarrollo ni la calidad del producto final.
 Mayor control y capacidad de predicción: para el control y seguimiento del
proyecto se emplean técnicas de gestión cuantitativa a partir del análisis de un
conjunto de indicadores trazados con los objetivos de negocio y del uso de modelos
de rendimiento, lo cual aporta un enfoque complementario a la gestión tradicional
de proyectos.
 Mayor eficiencia en el desarrollo: el trabajo que se realiza parte de arquitecturas
estándares desarrolladas, de patrones de diseño estables y de componentes
reutilizables que permiten reducir el plazo y el coste del desarrollo. Asimismo, la
forma de trabajo se establece y apoya en un conjunto de herramientas que facilitan
la gestión del proyecto, el desarrollo técnico y que mejoran la calidad de los
entregables.
 Mayor flexibilidad en el desarrollo de software: con este modelo la producción
del software puede estar deslocalizada en diferentes ubicaciones, pues siempre se
siguen unas pautas comunes en el desarrollo, siendo posible el trabajo en paralelo
en varios centros de desarrollo para un mismo proyecto.
 Mejora Continua: el modelo implantado incluye además un proceso sistematizado
y controlado para la mejora continua del modelo implantado, que proporciona
impactos positivos y cuantificables como; aumento del volumen de negocio,
reducción de costes y plazo en los proyectos, facilidad en replicar la metodología a
otros centros, mayor facilidad en la propagación de buenas prácticas a otras áreas,
mayor estabilidad en los procesos técnicos y de gestión.
Este marco metodológico contempla dos modelos de trabajo que aplican perfectamente a
la organización por fases del proyecto de CGR:
 Proyectos de Desarrollo de Software: en el que se plantea el desarrollo software a
través de un proyecto en el que a partir de un alcance funcional y a partir de un
conjunto de requisitos y restricciones del proyecto se establece una estimación de
coste y plazo del proyecto. Todas las actividades realizadas están basadas en
procesos definidos a partir del modelo CMMI-DEV nivel 3. Este se enmarca en la
creación de los sistemas que serán motivo del alcance.
 Servicios de Desarrollo de Software: enfocado más a actividades de
mantenimiento evolutivo, correctivo y soporte. Se plantea el desarrollo a través de
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
7 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
un servicio continuo en el que se identifica las aplicaciones ya entregadas por el
servicio, los tipos de peticiones aceptadas en el servicio y se presta el servicio en
base a unos Acuerdos de Nivel de Servicio (ANS) acordados con el cliente. Las
actividades dentro de este planteamiento se ajustan al modelo CMMI-SVC nivel 3.
7. Prácticas ágiles
A nivel metodológico, Inetum, como estrategia de compañía, apostó en el año 2007 por
el uso de metodologías ágiles para el desarrollo de software, teniendo como principal
objetivo definir e implementar un marco de trabajo ágil y sistemático para todos los
equipos de desarrollo que asegurase la productividad y la calidad de software entregado.
En este sentido, y después de un estudio de mercado nos decantamos por adoptar el
Framework SCRUM para el Desarrollo de Software y KANBAN para Servicios Continuos de
Desarrollo definiendo un modelo de trabajo basado en la colaboración y transparencia de
los equipos.
Para poder llevar a la práctica este enfoque y alineado en todo momento con el
aseguramiento de la Calidad de Software, Inetum hizo una apuesta pionera al combinar
con éxito su modelo de trabajo basado en metodologías ágiles con el marco de procesos
CMMI® (Capability Maturity Model Integration), en los ámbitos de servicio y desarrollo de
aplicaciones.
Para la implementación del modelo metodológico Inetum ha realizado una inversión
importante en el estudio, integración, implantación y evolución de un ecosistema de
tecnologías que satisfacen las necesidades del ciclo de vida del desarrollo software
haciendo uso de estas metodologías. En este sentido, hay que indicar que Inetum
implementa una estrategia / solución para unir el mundo del Desarrollo con el mundo de
Operación bajo estándares idóneos de seguridad de información, DevSecOps.
El uso de los ecosistemas de herramientas integrados de Inetum permiten disponer
de una trazabilidad desde los requisitos del cliente hasta el código desarrollado, teniendo
constancia de quien lo ha realizado y en qué momento. Por otro lado, permite establecer
y medir indicadores tales como la velocidad del equipo, la tasa de esfuerzo en corrección
de errores, y otros que facilitan la mejora en las estimaciones futuras en base a la
experiencia acumulada, además de proporcionar al cliente el seguimiento del grado de
avance del proyecto en base a la información aportada por los equipos de desarrollo.
8. DevSecOps
Inetum
propone
la
automatización
integral y paulatina del
proyecto en todos sus
aspectos,
utilizando
herramientas y scripting
donde sea posible para
evitar tareas repetitivas y
rutinarias para producir
software de calidad y
seguro más eficiente.
En la práctica, las líneas
de
trabajo
que
aplicaremos
en
el
Proyecto
son
las
siguientes:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
8 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
 Full DevOps, que incluye automatizar compilaciones, pruebas, despliegues en cada
etapa del ciclo de vida del desarrollo del software, gradualmente y de manera continua.
 Relación Agile con el negocio y con el departamento de TI de CGR para una
comunicación eficiente y eficaz, que responde a los cambios y que adopta un enfoque
Lean para las TI.
 DevSecOps para asegurar la seguridad de las aplicaciones iniciando por sus
componentes más críticos.
1.2 Visión general del Proyecto
En el planteamiento general para abordar este proyecto se distinguen dos fases
claramente diferenciadas:
1. Fase 1: ejecución de un Proyecto de alcance establecido con orientación a cumplir
un enfoque de producto(s) mínimo(s) viable(s) (MVPs) al inicio y con unas fechas
objetivo acordadas.
2. Fase 2: Servicio de Mantenimiento Post-Implantación del producto(s) inicial(es)
resultante(s) de la Fase 1, y de mejora continua (evolutiva o correctiva) de la
operación de los mismos.
En paralelo, y a lo largo de los dos años de contrato, se irán acometiendo los trabajos
relacionados con la puesta en marcha de la plataforma de desarrollo DevSecOps.
Teniendo en cuenta que, durante la Fase 1, será necesario contratar, instalar, configurar
y desplegar una plataforma en la CGR sobre la que se integrarán los desarrollos de la Fase
1 del Proyecto. Es decir, que durante la Marcha Blanca ya se espera contar con una primera
versión disponible de esta plataforma, para que los desarrollos que se vayan avanzando
en cada una de las entregas establecidas para el Proyecto de Fase 1 puedan irse integrando
y funcionando sobre la misma.
En esta línea de trabajo, seguiremos mejorando la infraestructura que alojará la nueva
arquitectura de microservicios hasta el fin del proyecto de Fase 1. Posteriormente, y
durante la Fase 2, se abordará la optimización de todos los elementos construidos e
instalados buscando que la infraestructura definitiva provisionada en los entornos de CGR
sea óptima y escalable.
Asumiendo estas necesidades, Inetum plantea conformar un equipo de trabajo con la
suficiente solvencia para garantizar a buen término el Proyecto de Fase 1. Además, que
este equipo se mantendrá implicado durante la Fase 2 para ir resolviendo las tareas de
mantenimiento y mejoras de la nueva solución.
La Gestión del Proyecto se llevará a cabo de manera diferenciada en cada Fase:

Fase 1: Gestión de Proyecto con seguimiento de la planificación y los hitos
establecidos de cada una de las entregas previstas. La metodología de desarrollo
será una metodología Ágil basada en SCRUM. En esta fase los Informes de
Seguimiento serán revisados a nivel de avances generales sobre la planificación,
estado del proyecto, gestión de riesgos, decisión sobre prioridades, gestión de
cambios de alcances, etc. Se buscará que estén alineados al ciclo de
producción acordado con CGR de forma que se sustente un incremento de
valor, aunque la facturación seguirá, independientemente, su esquema de
forma de pago y normativa asociada a cada una de las aprobaciones de los
entregables requeridos por CGR.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
9 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS

Fase 2: Gestión de Servicio con seguimiento de los incidentes y mejoras realizados
en los ciclos de soporte establecidos. La metodología de desarrollo será una
metodología Ágil basada en Kanban. Parte de la capacidad de nuestro equipo de
trabajo será destinada a la resolución de este tipo de tareas (Correctivos o
Evolutivos/Adaptativos menores) derivadas de la Fase 1, y el resto de la capacidad
del equipo será destinada a las tareas de producción de nuevas funcionalidades,
módulos o sistemas aún pendientes en el plan. En esta fase el seguimiento y los
Informes también estarán alineados al ciclo de producción acordado con
CGR.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
10 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
2 Enfoque Técnico
2.1 Estructura Organizativa
Para llevar a cabo el proyecto Inetum propone la siguiente estructura organizativa en la
que diferencia el Equipo del Proyecto por parte de Inetum, el Equipo de Apoyo que
actúa como refuerzo, los roles por parte de la CGR (propuestos por Inetum) y los
Órganos de Gestión del proyecto:
Obsérvese en la figura, como quedan perfectamente diferenciados los perfiles-roles de
proyecto, alineados totalmente con los tipos de trabajo especificados en el pliego.
Asimismo, como planteamos un equipo de valor agregado que además de permitir la
mejora en los procedimientos y buenas prácticas del proyecto, también intervengan en
escenarios de contingencia ante riesgos o problemas.
Aunque se ha hecho la diferenciación entre Equipo del Proyecto y Equipo de Apoyo, no hay
que interpretar esta diferenciación como una diferenciación de niveles de conocimiento. Lo
que se quiere remarcar al indicar un Equipo de Apoyo es la aportación por parte de
Inetum de personal con un conocimiento extra o especializado en una amplia
gama de disciplinas si el proyecto así lo requiere y bajo un modelo de consumo de horas
aprobado por CGR.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
11 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
2.1.1 Asignación de Perfiles a la Estructura Organizativa
Se proponen los siguientes perfiles y recursos que conforman el Equipo de Inetum para
el desarrollo del Proyecto durante la fase 1 Desarrollo e Implementación de la Sede
Electrónica, según la estructura organizativa descrita previamente en este apartado.
Perfil-Rol
Horas perfil Fase I
Horas perfil Fase II
(# Personas)
(# Personas)
Jefe de Proyecto
2,112 horas (1 p.)
2,112 horas (1 p.)
Arquitecto de Hardware y
Software
1,408 horas (1 p.)
704 horas (1 p.)
Especialista de Base de datos
1,056 horas (1 p.)
528 horas (1 p.)
Diseñador Web
1,232 horas (1 p.)
1,232 horas (1 p.)
Analista Programador
89,056 horas (46 p.)
42,240 horas (20 p.)
Analista Programador BI
5,808 horas (3 p.)
2,112 horas (1 p.)
Analista de Sistemas
21,120 horas (15 p.)
11,264 horas (8 p.)
Analista de Control de Calidad
10,560 horas (15 p.)
5,632 horas (8 p.)
Documentador
4,224 horas (2 p.)
2,112 horas (1 p.)
Analista de soporte a incidentes 4,224 horas (2 p.)
4,224 horas (2 p.)
2.1.2 Perfiles y Funciones
A continuación, se detallan las funciones y responsabilidades de cada uno los perfiles
propuestos:
Director de Proyecto, máximo representante de Inetum ante CGR que se encargará
de realizar el control y seguimiento al cumplimiento del contrato del Proyecto. Sus
responsabilidades son las siguientes:
Centralizar y coordinar escalamientos de CGR ante temas de vital importancia.
Definir las directrices generales del proyecto y seguimiento mensual o bimestral de
su cumplimiento.
Realizar un seguimiento del grado de cumplimiento de los objetivos generales del
proyecto.
Alinear los procesos principales a las expectativas de CGR.
Verificar los informes de calidad integral del servicio entregado y su plan de mejora.
Jefe de Proyecto, asegura el seguimiento continuo de la realización de trabajos del
proyecto. Es responsable de:


Liderar el equipo del proyecto para alcanzar los objetivos del proyecto.
Elaborar el Plan de Gestión del Proyecto, y gestionar el cumplimiento de los planes
que lo conforman, las metas, plazos y cronogramas establecidos para el servicio.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
12 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
















Coordinar la ejecución del proyecto y asegurar el seguimiento continuo del plan de
trabajo del proyecto con los pares asignados por la CGR y presentar los informes
mensuales respectivos.
Calcular y dar visibilidad sobre las jornadas horas/hombre utilizadas, emitiendo
informes mensuales a la CGR.
Coordinar los intereses, objetivos y expectativas de los diferentes grupos de
interés, de manera permanente, y presentar los informes respectivos a CGR.
Sponsor de Inetum para incluir las prácticas de agilidad con referencia a AMS+
Inetum que permitan la evolución de la metodología y su difusión en todo el equipo
del proyecto.
Administrar el personal asignado al Proyecto (selección, evaluación permanente,
capacitación, incentivos, movimientos). Deberá informar necesariamente y de
forma oportuna a la CGR sobre los cambios, estructura organizacional y
movimientos que acontezcan a lo largo del servicio. La no comunicación de dichos
cambios a la CGR y los supuestos inconvenientes en la ejecución del Servicios
serán de responsabilidad exclusiva y atribuible a INETUM.
Velar por el nivel de calidad de los trabajos.
Definición y supervisión de la documentación y productos a entregar.
Participar en las reuniones y proporcionar al Comité de Dirección, Comité de
Seguimiento y/o Desarrollo la información suficiente para supervisar el servicio.
Velar por el cumplimiento de estándares, normas técnicas y metodologías de
desarrollo de software, de gestión de proyectos, normas de seguridad y control de
calidad, establecidas por la CGR y por el Estado Peruano.
Proponer cambios y mejoras para el desarrollo y diseño de sistemas en función a
los requerimientos definidos por la CGR.
Implementar el plan de aseguramiento y control de calidad establecido y aprobado
por CGR, dicho plan será presentado durante la fase preoperativa del proyecto de
acuerdo a la página 16 de los TdR.
Velar por el correcto y oportuno cumplimiento del Plan de Aseguramiento y Control
de Calidad solicitando a los responsables de Calidad y Pruebas la ejecución de
pruebas específicas.
Solicitar y gestionar la verificación de entregables una vez concluidos, así como la
absolución de observaciones que se presenten.
Velar por el cumplimiento de los procedimientos definidos por la CGR para el
proyecto y por los que se establezcan durante el mismo.
Garantizar que la documentación de artefactos generados se alinee a las normas
establecidas en CGR y que los documentos elaborados queden registrados en sus
sistemas de gestión.
Velar por el correcto funcionamiento de los mecanismos y procedimientos de
información a ser utilizados por INETUM con respecto al control, seguimiento y
cumplimiento en la atención de los requerimientos efectuados por la CGR (para
estos últimos debe considerarse lo establecido en el numeral 17 “Penalidades”).
Velar por el cumplimiento e integridad del servicio conforme al documento de
"Acuerdos de Niveles de Servicio" acordado con CGR.
Arquitecto de Sistemas. Dispone de un conocimiento experto del entorno tecnológico
del proyecto y realizan las siguientes funciones:



Diseño técnico de los módulos a desarrollar de acuerdo con los documentos de
visión y alcance recibidos o incluso, la elaboración del propio documento de visión
y alcance.
Valoración del esfuerzo técnico necesario para la realización de las soluciones
técnicas y del plazo de realización.
Líder de implementación de alcance DevSecOps junto con el equipo de desarrollo
del proyecto.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
13 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS












Elaboración de la documentación técnica de arquitectura de HW, SW o Nube
correspondiente a los programas implicados e incorporación a los registros
correspondientes.
Elaboración de la documentación técnica base para la implantación de los
programas.
Análisis y diagnóstico de incidencias y problemas complejos.
Propuesta de soluciones técnicas integrales, transversales y/o reutilizables.
Programación de los componentes más complejos y críticos.
Realización de propuestas para mejorar la funcionalidad o rendimiento.
Propuesta de acciones correctoras de raíz.
Aseguramiento de la mejora continua y optimización de los componentes
tecnológicos.
Diseño e implementación de los pipelines DevOps y/o DevSecOps, según aplique.
Apoyo en la integración de las automatizaciones en los diversos componentes de
la solución con el apoyo del resto del equipo técnico.
Auditoría de seguimiento de buenas prácticas de programación y/o eventuales
Code Reviews planificados.
Cumplimiento de SLAs asociados al servicio.
Especialista de Base de Datos. Dispone de un conocimiento experto del entorno
tecnológico de la(s) base(s) de datos transaccionales y OLAP del proyecto y realizan las
siguientes funciones:










Diseño técnico integral de la base de datos a desarrollar de acuerdo con los
documentos de visión y alcance técnicos recibidos del arquitecto o analistas.
Valoración del esfuerzo técnico necesario para la realización de la(s) base(s) de
dato(s) y del plazo de realización.
Elaboración de la documentación técnica de arquitectura de HW, SW o Nube
correspondiente a la(s) base(s) de dato(s).
Elaboración de los Estándares de Base de Datos[1]
Análisis y diagnóstico de incidencias y problemas complejos.
Propuesta de soluciones técnicas integrales sobre la(s) base(s) de dato(s).
Realización de propuestas para mejorar el rendimiento de la(s) base(s) de dato(s)
o “tunning”.
Propuesta de acciones correctoras de raíz.
Auditoría de seguimiento de buenas prácticas de programación sobre la(s) base(s)
de dato(s).
Cumplimiento de SLAs asociados al servicio.
Analista(s) Sistema(s). Disponen de un conocimiento intermedio o amplio de la solución
del proyecto y realizan las siguientes funciones:






Ordenar y estructurar la definición de los requerimientos del proyecto y la correcta
elaboración del producto o solución.
Identificar las necesidades y determinar soluciones a problemas de negocio.
Incluir las prácticas de agilidad con referencia a AMS+ Inetum que permitan la
evolución de la metodología.
Diseño técnico y funcional de los requerimientos sobre los módulos a desarrollar
de acuerdo a los documentos de visión y alcance recibidos o incluso, la elaboración
del propio documento de visión y alcance de los requerimientos
funcionales/técnicos.
Valoración del esfuerzo necesario para la realización de requerimientos y del plazo
de realización.
Definición y diseño inicial de los componentes, clases u otros aspectos técnicos
correspondientes a los programas implicados y presentación a los documentadores
para sus registros correspondientes.
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Gestión del Proyecto, fila 9. Se agregaron precisiones sobre los roles en relación con el TdR, incluida la de
las actividades del perfil del especialista en base de datos.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
14 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS







Propuesta de soluciones.
Realización de propuestas para mejorar la funcionalidad o rendimiento.
Propuesta de acciones correctoras.
Aseguramiento de la mejora continua con estandarización y buenas prácticas
Pruebas de aceptación con usuarios.
Pruebas post producción de funcionalidades entregadas.
Cumplimiento de SLAs asociados al servicio.
Analista(s) Programador(es). Disponen de un conocimiento amplio del entorno
tecnológico del proyecto y realizan las siguientes funciones:







Definición y diseño final de los componentes, clases u otros aspectos técnicos
correspondientes a los programas implicados y presentación a los documentadores
para sus registros correspondientes.
Programación de los componentes de la solución.
Creación y/o modificación de programas de acuerdo con la documentación
elaborada por los Analistas de Sistemas.
Apoyo los Analistas de Sistema en parte de sus labores cuando estos lo requieran.
Propuesta de soluciones.
Realización de pruebas unitarias de cada programa.
Cumplimiento de SLAs asociados al servicio.
Analista(s) Programador(es) BI. Disponen de un conocimiento amplio del entorno
tecnológico de los componentes BI del proyecto y realizan las siguientes funciones:







Definición y diseño final de los componentes BI, modelo de base datos asociado u
otros aspectos técnicos correspondientes a los programas implicados y
presentación a los documentadores para sus registros correspondientes.
Diseño, configuración y/o programación de los componentes o reportes de la
solución.
Creación y/o modificación de componentes o reportes de acuerdo con la
documentación elaborada por los Analistas de Sistemas.
Apoyo los Analistas de Sistema en parte de sus labores cuando estos lo requieran.
Propuesta de soluciones.
Realización de pruebas unitarias e integrales de cada componente.
Cumplimiento de SLAs asociados al servicio.
Documentadores. Disponen de un conocimiento documental del entorno tecnológico y
solución(es) del proyecto y realizan las siguientes funciones:




Elaboración de la documentación funcional, técnica o de implantación de los
programas.
Documentación de análisis y diagnóstico de incidencias y problemas.
Ajustes y detalles sobre los diversos documentos de planificación del proyecto.
Cumplimiento de SLAs asociados al servicio.
Diseñador Web UX/UI. Disponen de un conocimiento técnico y dominio de la
experiencia de usuario sobre las aplicaciones del proyecto y realizan las siguientes
funciones:



Elaboración de la estrategia UX/UI, y su implantación en las diversas fases del
requerimiento.
Diseño web UX y UI y la elaboración de sus entregables que permitan su
implementación en la fase de desarrollo.
Pruebas y ajustes con usuarios finales sobre el diseño propuesto y su usabilidad.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
15 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS



Ajustes y detalles sobre los diversos documentos de planificación del proyecto
relacionados a su alcance.
Comunicación constante con el equipo para contribuir en los ajustes oportunos y
preventivos que afecten la experiencia del usuario usando la aplicación.
Cumplimiento de SLAs asociados al servicio.
Analista de Control de Calidad. Encuadrado dentro del equipo de desarrollo su principal
cometido será asegurar la calidad de los productos entregados.





Elaboración del plan de pruebas, realización de pruebas funcionales y de
integración / aceptación.
Ejecución del plan de pruebas, incluyendo pruebas de integración.
Diseño e implementación de pruebas automatizadas y su mantenimiento en el
tiempo.
Apoyo en las pruebas de certificación y aceptación.
Cumplimiento de SLAs asociados al servicio.
Analista(s) de Soporte. Disponen de un conocimiento funcional amplio de la solución
implementada del proyecto y realizan las siguientes funciones:











Disponer de un canal de comunicación con usuarios oportuno y fiable.
Recopilar los incidentes reportados y clasificarlos de manera ordenada y
metodológica.
Identificar los inconvenientes reportados y determinar soluciones en línea.
Identificar los inconvenientes reportados y determinar soluciones técnicas de fondo
que ameriten ser escalados a los equipos técnicos de fábrica.
Valoración del esfuerzo necesario para la corrección de un incidente.
Propuesta de soluciones.
Realización de propuestas para mejorar la funcionalidad o rendimiento.
Propuesta de acciones correctoras de fondo (análisis causa-raíz ).
Pruebas post producción de funcionalidades entregadas.
Pruebas de aceptación con usuarios sobre la solución a sus incidentes reportados.
Cumplimiento de SLAs asociados al servicio.
Equipos de apoyo (especializado). Asesoramiento experto de consultores y
especialistas de las organizaciones integrantes de Inetum para apoyar al Equipo de
Trabajo en todo momento ante cualquier eventualidad, incidencia, problema técnico,
dudas o consultas que les puedan surgir. Tanto a nivel tecnológico como de negocio u
operación del Servicio. De esta forma aseguramos la continuidad de todos los servicios
ofertados en este proyecto. Las especialidades incluidas en este rol son:



Seguridad de información e implementación DevSecOps.
Arquitectura e innovación Cloud.
Automatización de pruebas y pipelines Shift-left testing.
2.2 Modelo de relación del proyecto
Una buena parte del éxito o fracaso de un modelo de prestación de servicios TIC gestionado (basado
en ANS) está directamente relacionada con la eficiente constitución, coordinación e integración
de los distintos equipos de trabajo habilitados para desarrollar las tareas en cada una de sus
fases.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
16 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
En este sentido es especialmente importante la constitución de un equipo mixto, formado por
personal del CGR y por personal INETUM , que involucre a las personas clave de ambas
organizaciones en cada una de las tareas que será necesario abordar con el objetivo de garantizar
su ejecución, evolución y mejora progresiva de la productividad en el mantenimiento de
las aplicaciones, siempre desde la flexibilidad y capacidad de adaptación a los nuevos retos
planteados al CGR mediante la utilización e integración eficaz de nuevas tecnologías, procesos y
herramientas.
Es fundamental la coordinación de las distintas personas y equipos implicados en el servicio para el
desarrollo y evolución de aplicaciones, orientada a saber en todo momento qué funciones y qué
responsabilidades tienen, cuándo deben participar, cómo deben actuar, a quién deben informar,
preguntar y de qué y/o quién tienen que recibir información. Con esta finalidad la Inetum siguiendo
las directrices del CGR, propone para la gestión del servicio un modelo de relación basado en la
siguiente estructura de Comités, que permite un perfecto control del servicio por parte de CGR
y una eficiente participación y responsabilidad de Inetum en la consecución de los
objetivos.
El modelo de relación propuesto inicialmente para la prestación del servicio será el establecido
en el pliego de prescripciones técnicas (PPT) del servicio con la inclusión de ciertas responsabilidades
e interlocutores adicionales, siempre que la SGTIC lo considere así oportuno, con el objetivo de cubrir
eficientemente las necesidades a nivel estratégico, táctico y operativo. Dicho modelo de relación
inicial podrá ser revisado y adaptado a lo largo de la prestación del servicio, bajo la aprobación
de la SGTIC, con el objetivo de garantizar la flexibilidad y la adaptación del servicio a la
evolución del negocio.
2.2.1 Estructura de los comités de seguimiento
Inetum es consciente y flexible en que esta estructura del modelo de relación pueda ser
modificado por CGR durante la prestación del servicio para cubrir de manera más eficiente
los objetivos de gestión y lograr una mejor provisión y gestión de los servicios. [1]
2.2.1.1 Comité Gerencial
Su objetivo es la gestión global de la prestación de los servicios objeto del contrato, asegurando
que todas las decisiones y acciones relacionadas con el servicio se discuten y se acuerdan
abiertamente, y que ambas partes reconocen sus obligaciones respectivas.
Este comité estará compuesto como mínimo por los siguientes integrantes:
Por CGR
•
•
•
•
Gerente de Tecnologías de la Información
Subgerente de Sistemas de Información
Líder del Proyecto
Los StakeHolder (personas involucradas en el Proyecto) que la CGR estime conveniente.
Por INETUM
•
•
•
Director de Servicios o Gerente de Delivery
Jefe de Proyecto
Miembros del equipo técnico o funcional del proyecto que INETUM incluya para brindar detalle
sobre algún punto de la agenda (a demanda) [2]
Este Comité tiene entre sus funciones las siguientes:
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Gestión del Proyecto, fila 4. Se detalla la estructura de los comités.
[2] De acuerdo a la absolución de la Sesión Técnica 1 – Gestión del Proyecto, fila 4. Se incluye precisión requerida sobre Inetum y asistencia a demanda.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
17 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS












Supervisar y evaluar el avance global del servicio, así como del cumplimiento de los objetivos
de los indicadores globales y particulares del modelo.
Poner en común las directrices estratégicas que afecten al servicio y sus necesidades, así
como el seguimiento y verificación de la ejecución de la estrategia y de las decisiones
adoptadas.
Aprobar cambios en el ámbito del servicio que, por su impacto o importancia estratégica, no
se hayan gestionado en los niveles previos de seguimiento y que deben estar ligados a los
objetivos de negocio del CGR.
Resolución de conflictos escalados desde el nivel inferior, como pueden ser desacuerdos o
discrepancias relativas al personal y a los recursos asignados al servicio o la forma de prestar
dicho servicio.
Seguimiento y de los ANS y de la componente variable que ha de facturar en función del
cumplimiento de los objetivos, aprobándolos o tomando decisiones ante desviaciones en su
cumplimiento.
Aprobar los cambios de Acuerdo de Nivel de Servicio.
Seguimiento económico del contrato, teniendo en cuenta la planificación a medio/largo plazo.
Revisión y aceptación de proyectos de mejora.
Revisiones del contrato, así como variaciones en la Línea Base y posibles variaciones
económicas en el contrato.
Aprobación del Plan Anual de estrategia de evolución de aplicaciones y previsión de demanda
Seguimiento y verificación de la ejecución de la estrategia y de las decisiones adoptadas
En general, tratar cualquier incidencia o problema significante surgido durante la ejecución
del servicio.
Su periodicidad será Mensual), excepto en las etapas de adquisición del conocimiento y
estabilización (marcha blanca) que proponemos una periodicidad quincenal si el CGR lo considera
oportuno. Para ello se establecerá anualmente un calendario por anticipado. El Comité Ejecutivo se
constituirá durante la reunión de Kick-Off (Arranque del servicio), siendo ésta la primera reunión en
que actúe como tal. Podrán convocarse Comités Ejecutivos de forma extraordinaria ante situaciones
relevantes que alguna de las partes convoque.
2.2.1.2 Comité Operativo
Su objetivo es la supervisión y control de los trabajos en todas las fases del proyecto, haciendo
hincapié en las etapas de adquisición del conocimiento y estabilización (marcha blanca) para asegurar
la transferencia de la responsabilidad del servicio en todos sus niveles, así como la evaluación del
del servicio, acordando el enfoque común y proponiendo las modificaciones que se consideren
oportunas. Está conformado como mínimo por las siguientes personas:
Por CGR
Líder del Proyecto
Subgerente de Sistemas de Información
Los StakeHolder (personas involucradas en el Proyecto) que la CGR estime
conveniente.
•
•
•
Por INETUM
Jefe de Proyecto
Analistas de sistemas.
Miembros del equipo técnico o funcional del proyecto que INETUM incluya para
brindar detalle sobre algún punto de la agenda (a demanda)
•
•
•
Este Comité se responsabilizará de revisar la información del proyecto en los siguientes ámbitos:
Ámbito de seguimiento del servicio
Su objetivo es evaluar la estrategia a seguir y el nivel real del servicio prestado, y entre sus funciones
están:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
18 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS














Seguimiento cumplimiento de la estrategia tecnológica, así como trasladar las directrices
estratégicas en la operativa diaria del servicio.
Impulso de la evolución tecnológica y diseño del Plan Anual de estrategia de evolución de
aplicaciones y previsión de demanda
Realizar el seguimiento y control para comprobar que se consiguen los niveles de calidad
acordados y, en el caso de deficiencias no resueltas a nivel operativo, controlar que se
implementan las actividades pertinentes para su resolución.
Revisión de los elementos de aseguramiento de calidad, definición y seguimiento de los
planes de mejora.
Revisar los niveles de servicio (ANS) medidos mensualmente y evaluar su cumplimiento y
las posibles desviaciones sobre los valores objetivo de los ANS.
Gestión de la planificación, incluyendo la definición, revisión, actualización y control del
cumplimiento de la planificación.
Análisis de peticiones y/o incidencias que se consideren significativas.
Coordinar los grupos y personas asignados a la entrega del servicio, asegurando que el
personal asignado para la ejecución de los servicios por Inetum está disponible y cuenta con
los medios, formación y soporte necesarios para la correcta ejecución de sus tareas.
Gestionar los acuerdos con terceros que intervienen en la entrega de los servicios.
Analizar e implementar los requerimientos de cambio en procesos de gestión.
Garantizar que el trabajo se realiza siguiendo los procedimientos y guías del modelo de
gestión del CGR.
Revisión de horas incurridas mensuales, así como tratar aspectos económicos del acuerdo
(facturación, penalizaciones, etc.) sin perjuicio de que las decisiones definitivas se escalen al
Comité Ejecutivo.
Revisar y facilitar al Comité Ejecutivo cualquier información que le sea solicitada o necesaria
para la correcta realización del comité.
Escalar al Comité Ejecutivo aquellos aspectos que escapan de la competencia del comité o
que no pueden ser resueltos en este nivel.
Ámbito de la Gestión de la Demanda
Su objetivo es realizar el seguimiento y la gestión de la demanda de forma eficiente, optimizada y
acorde a las necesidades de negocio y objetivos estratégicos del CGR, y entre sus funciones están:







Definición y aprobación de los criterios de aceptación de las peticiones de desarrollo en base
al cumplimiento de objetivos de negocio, estudios de viabilidad (análisis de coste/beneficio),
etc.
Revisión y seguimiento del Plan anual de mantenimientos y/o nuevos desarrollos de gran
alcance.
Revisión y aprobación de nuevas iniciativas de mantenimiento y desarrollo de gran alcance
en base a los criterios definidos y a las necesidades y objetivos estratégicos de negocio.
Revisión y seguimiento de la capacidad comprometida para el desarrollo realizando los
ajustes requeridos y solicitando aumentos en caso de ser necesario. Actualización del Plan
de Capacidad en consecuencia.
Detección de incrementos/decrementos de capacidad de la Línea Base establecida.
Valoración y recomendación de aprobación del Plan de Contingencia ante excesos de
demanda.
Revisión y seguimiento de iniciativas y proyectos realizados por terceros si estos afectan al
servicio.
Ámbito de Calidad y Mejora Continua
El objetivo es posibilitar un servicio innovador y eficiente, realizando el seguimiento y gestión de las
actuaciones en el ámbito de la innovación y mejora continua acorde a las necesidades de negocio y
objetivos estratégicos. Entre sus funciones están:


Propuesta y análisis de las iniciativas en el ámbito de la innovación y mejora continua para
el Servicio.
Valoración y aprobación de las iniciativas, así como su plan de implantación acorde a los
objetivos de negocio.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
19 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS


Revisión de los procesos de innovación y mejora continua implantados en el Servicio y
propuestas de modificación cuando sea necesario.
Potenciar una cultura corporativa basada en la mejora, excelencia e innovación, asegurando
que llega a todos los niveles del Servicio.
2.2.1.3 Comité de Desarrollo
Este comité gestionará todo lo referente al proceso de atención de requerimientos en fábrica de la
Inetum para lo cual se programará un seguimiento a la planificación de sprints (semanal, quincenal,
mensual) o a solicitud de la CGR según una causal de urgencia.
En este comité, se administrará el avance y los cambios al plan de atención del proyecto,
eventualmente se podrán realizar ajustes a dicha programación (con los sustentos respectivos) ya
sea a pedido de CGR o de Inetum, contando con el visto de cambio de la CGR. Este Comité estará
compuesto como mínimo por los siguientes integrantes:
Por CGR

Líder del Proyecto.

El personal que la CGR estime conveniente.
Por INETUM


Analistas de sistemas.
Miembros del equipo técnico o funcional del proyecto que INETUM incluya para brindar detalle
sobre algún punto de la agenda (a demanda)
2.2.1.4 Comité excepcional para la adquisición del conocimiento y estabilización del
proyecto
El objetivo es supervisar y controlar los trabajos en las etapas de adquisición del conocimiento y
estabilización (marcha blanca), asegurando que se realizan las tareas según la planificación y
abordando los posibles problemas que puedan surgir en la transferencia del conocimiento entre los
distintos agentes implicados en el inicio de la relación entre Inetum y CGR.
Está formado por el responsable de la gestión del servicio del CGR, y por el responsable de la
gestión del servicio de Inetum y se incorporará a este Comité el responsable(s) de estabilización
del servicio de ambas partes. Siendo conscientes que existen varios aspectos técnicos y funcionales,
se asumen que podrían haber responsables de diferentes líneas o tareas que permitan la constitución
del servicio según el plan de trabajo inicial definido.
El Comité se responsabilizará, entre otras, de las siguientes funciones:





Gestión y seguimiento de la estrategia del proyecto inicial.
Planificación y seguimiento de actividades y tareas a nivel operativo que permitan el arranque
idóneo del servicio.
Control y seguimiento de las tareas técnicas iniciales.
Identificación y análisis de riesgos operativos de cambios.
Resolución de conflictos operativo o escalado de aquellos cuya decisión requiera la
intervención del nivel superior.
El comité debe ser más operativo que formal, por ello estará constituido permanentemente, siendo
los participantes los que decidan la realización de puntos de revisión entre siete y quince días con
revisión diaria de la situación operativa.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
20 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
2.2.2 Interlocutores oficiales del servicio
A continuación, se describen las tareas principales de los distintos interlocutores oficiales, asignados
al servicio, para la gestión de la relación y comunicación de Inetum. Comprendiendo que estos serán
determinantes para aclarar cualquier asunto relevante que el proyecto requiera.
Interlocutor
Responsable del
contrato y del
control económico
Responsable de la
estabilización
Responsable o
Jefe de Proyecto
de la gestión del
servicio
(Servicio Base)
Responsables
Operativos
Descripción
Es el máximo responsable del Servicio por parte de Inetum, encargado del
aseguramiento de todos los requisitos del contrato. Forma parte del Comité
Ejecutivo y es la persona de referencia para el CGR en relación a la gestión
global de la prestación de los servicios, las modificaciones contractuales o
gestión de cláusulas.
Se responsabilizará de la definición y ejecución de los Planes de “Adquisición
del conocimiento y toma de control” y “Estabilización del Servicio” definidos,
así como de su seguimiento y control de las etapas de estabilización y
devolución del Servicio.
Asegurará la transferencia de conocimiento y de la responsabilidad del
Servicio desde el equipo saliente al nuevo equipo de Inetum.
Formará parte del Comité de Seguimiento del Servicio.
Su participación en el servicio se circunscribe a las etapas de adquisición del
conocimiento y estabilización (marcha blanca).
Interlocución con el responsable de la gestión del servicio de CGR:
o Principal interlocutor con CGR para la gestión del proyecto.
o Participación en Comités de Servicio y por invitación en el Comité
Ejecutivo.
o Preparar los informes de seguimiento.
Gestión del Servicio:
o Responsable de la consecución de los objetivos estratégicos y
tecnológicos del proyecto.
o Orientar la ejecución del proyecto según los objetivos marcados y tomar
las decisiones que afectan a su marcha.
o Responsable de desarrollar el plan de trabajo.
o Responsable de la organización, desarrollo y control permanente del
proyecto.
o Definición de los requerimientos de trabajo y detección de posibles
mejoras.
o Desarrollar iniciativas para mejorar la prestación del Servicio.
o Asegurar el cumplimiento de la planificación.
o Asegurar el cumplimiento de ANS.
o Aseguramiento de calidad de la ejecución y entregables del Servicio.
Gestión de recursos:
o Planificación de tareas, organizando el equipo de trabajo y valorando el
impacto en el servicio de los cambios realizados.
o Asegurar la adecuación de los integrantes del equipo a las necesidades
del Servicio.
o Asegurar que los integrantes del equipo conocen y aplican el Modelo de
Gestión de servicios TIC del CGR.
Gestión de riesgos y problemas:
o Entender la aceptación de criterios y pronta identificación de los
problemas, para que una correcta acción pueda ser seguida.
o Gestión de riesgos del proyecto.
o Velará por el cumplimiento de todas las normas de seguridad.
Máximo responsable desde el punto de vista funcional, técnico y operativo de
su grupo de aplicaciones.
Reporta y colabora con el responsable de la gestión del servicio, así como
con el responsable de la estabilización en la adquisición del conocimiento de
su grupo de aplicaciones y la estabilización del servicio.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
21 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Interlocutor
(Servicio Base)
Líder de Equipo de
Desarrollo
(Servicio Bajo
Demanda)
Arquitecto técnico
(Servicio Base)
Gestor de
incidentes o
problemas
(Servicio Base)
Gestor de control
de calidad
(Servicio Base)
Descripción
Coordina la ejecución del servicio con el Jefe del Equipo de Desarrollo del
Servicio Bajo Demanda, de cara a ofrecer un servicio alineado durante todo
el ciclo de vida del software.
Interlocución con el CGR para tratar incidencias y evolutivos bajo su ámbito
de responsabilidad.
Responsable en su ámbito de:
o Análisis de requerimientos.
o Documentación funcional y técnica.
o Diseño de la parametrización del sistema de información.
o Resolución de incidencias y consultas.
o Apoyo a los equipos de desarrollo.
o Conformidad con los objetivos del negocio, las funcionalidades de los
sistemas de información y posibles desarrollos especiales.
o Elaboración del mapa de procesos, definiendo actividades y tareas.
o Definir la necesidad de desarrollos especiales, interfaces o
modificaciones.
o Definir los niveles de autorización de acceso a la información, junto con
el CGR.
o Especificar las necesidades de información y el formato de datos para
asegurar la integración de las aplicaciones y las cargas de datos.
o Definir el Plan de Pruebas.
o Formar a los usuarios.
o Apoyar a los usuarios colaborando en la resolución de sus dudas
funcionales y técnicas.
Máximo responsable desde el punto de vista técnico y operativo a nivel del
Servicio Bajo Demanda.
Experto conocedor de las tecnologías del Lote.
Reporta y colabora con el responsable de la gestión del servicio.
Asimismo, coordina la ejecución del servicio con los responsables operativos
del Servicio Base.
Responsable del seguimiento de los requisitos técnicos no funcionales del
entorno tecnológico del sistema de información del CGR.
Estudio y diseño técnico de los programas e interfaces.
Elaboración de diseños técnicos.
Análisis de problemas técnicos y propuesta de soluciones técnicas más
eficaces.
Implementación de los programas y/o configuración de las herramientas de
acuerdo a las necesidades del CGR.
Comunicar a los especialistas técnicos o al responsable operativo cualquier
problema que surja.
Responsable de la coordinación de los recursos técnicos necesarios para la
resolución proactiva de los problemas o incidencias graves detectados.
Se encarga de mantener actualizado el repositorio de gestión de problemas.
Desde el inicio de la estabilización conforma el plan de calidad y se encarga
de que este se lleve a cabo.
Puede participar en el Comité de Servicio cuando hay aspectos de calidad
que se tienen que tratar.
Encargado de garantizar la calidad de los entregables realizados, en especial
la correcta realización de pruebas integrales y unitarias y la calidad en las
entregas de documentación asociada a las peticiones realizadas.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
22 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
2.3 Planteamiento General de la Solución
La Solución Técnica de Inetum contempla la integración de los diferentes escenarios
tecnológicos propuestos para cada una de las capas de la solución global.
Los usuarios accederán a un Front-End desarrollado con tecnología Angular, TypeScript y
JavaScript, apoyado sobre una capa de servicios REST desarrollados con
SpringBoot, que en algunos casos serán desplegados como microservicios en
contenedores de AWS (cloud) o servidores On Premise que CGR asigne para el
Back-End. Esta capa de microservicios se integrará con componentes inclusive
soluciones preexistentes de CGR, otros sistemas de terceros, así como el resto de
desarrollos de Back-End sobre el Servidor de Aplicaciones Payara.
Inetum asesorará desde su experiencia en este tipo de soluciones para la mejor
distribución de los distintos elementos que componen la solución funcional (módulos web
de acceso multidispositivo por parte de los usuarios, y módulos web de acceso a través del
escritorio de PC) entre cada una de las capas tecnológicas que componen esta solución
técnica requerida:
Frente de la
solución
Tecnologías asociadas
Base de datos
ORACLE 19*[1]
Java Runtime
Environment (JRE)
Java 11
IDE
Las últimas versiones de Visual
Studio Code, Netbeans o Eclipse
Back-End
Front-End
Spring Boot 2, Spring Cloud, JSON
Web Token – JWT
Angular 10, Angular Material
Design, Bootstrap 4
Sistema Operativo del RedHat Enterprise Linux*[2]
servidor de
aplicaciones
Servidor de
Aplicaciones
Payara Server 5
* A ser provisto por CGR
Inetum usará solo herramientas licenciadas. En base a nuestra experiencia y análisis, algunas
herramientas tendrán tipo de licenciamiento Open Source y otras comerciales. Aquellas herramientas
o software que por sus características requieran su uso bajo licenciamiento comercial o suscripción,
estas serán adquiridas por Inetum a nombre de la CGR, acorde a lo indicado en el numeral 3.
Plataforma Tecnológica de los TdR. Inetum, en el Excel Herramientas y Artefactos, identifica el tipo
de licenciamiento para cada una de ellas. Estas herramientas serán transferidas a la CGR al final del
servicio según corresponda.[3]
[1] De acuerdo a la absolución de la Sesión Técnica 3 – Enfoque de Innovación y sección de Arquitectura, fila 21. Se considera iniciar el servicio con la versión de
Oracle 19.
[2] De acuerdo a la absolución de la Sesión Técnica 3 –Arquitectura, fila 23. Se cambia, a solicitud de la CGR, el SO a ser utilizado durante el presente servicio.
[3] De acuerdo a la absolución de la Sesión Técnica 1 – Herramientas y Condiciones de Uso. Se hace referencia al archivo Herramientas y Artefactos.xls en el que
se detalla lo solicitado en las filas 18, 19, 20, 21, 22, 23.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
23 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
2.4 Estrategia metodológica
En este apartado exponemos las metodologías base a poner en práctica para la ejecución
de este proyecto.
2.4.1 SCRUM
Para este proyecto Inetum utilizará el marco de trabajo ágil SCRUM. Inetum dispone
de conocimiento, perfiles cualificados y herramientas con las que utilizar dicho modelo de
trabajo. Entre los principales objetivos que se consiguen con su uso se encuentran:


Facilitar el proceso de desarrollo.
Detectar de forma temprana errores y cambios debidos a posibles equivocaciones
en la toma de requisitos (representadas como historias de usuario), asegurando
que lo que se ha desarrollado es lo que se ha solicitado.
Scrum, dispone de unas reglas específicas para su utilización, no obstante, como cualquier
buena práctica o metodología, podrá adaptarse a CGR proporcionando una correcta
gestión y optimizando al máximo, tiempos, coste y alcance dentro del proceso de
desarrollo, así como integrándola con el resto de metodologías implicadas.
Entre las principales características de Scrum, se encuentran la autogestión y auto
organización del equipo de trabajo, así como la implicación y disponibilidad por parte de
CGR de la figura del Product Owner para facilitar los requisitos, la aceptación de los
trabajos entregados, así como la
resolución de cualquier tipo de duda. Cabe mencionar, que si bien Scrum servirá como guía
para el proyecto, podrá tener toques o inclusiones de otras prácticas ágiles que el equipo
considere de valor.
En cuanto a los entregables principales que se obtienen durante el ciclo de vida del
desarrollo de software bajo este modelo. A continuación, se proporciona la relación:
DESCRIPCIÓN DE ENTREGABLES
Entregable
Descripción
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
24 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Alcance Funcional
Historias de usuario
Criterios de aceptación.
Requisitos de Interfaces de software.
Diseño UX/UI (prototipos).
Plan de Ejecución
Definición del alcance del desarrollo.
Plan de Entregas o roadmap de releases del proyecto
acorde con el Product Backlog priorizado.
Matriz de riesgos.
Diseño Técnico Alto Nivel
Diagrama de la Arquitectura de Solución.
Diagrama de servidores e infraestructura asociada.
Catálogo de Interfaces Externas / Internas (servicios).
Pipeline DevOps o DevSecOps
Código Fuente
Paquetes de código fuente.
Resultados de pruebas unitarias.
Componentes y base de
datos
Componentes finales y esquema de base de datos
transaccional y OLAP.
Manual de Despliegue
Requerimientos y características de implantación.
Instalación y configuración de software de base.
Componentes a desplegar.
Procedimiento de despliegue.
Procedimiento de carga de datos iniciales.
Manual de Usuario
Descripción del manual de usuario de la aplicación.
Plan de Pruebas
Casos de prueba por tipo
Pruebas automatizadas
Especificación Shift-left y pruebas automatizadas
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
25 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Informe de Ejecución de
Pruebas
Resumen del resultado de la ejecución.
Indicadores de pruebas.
2.4.2 Kanban
Dentro del mantenimiento de aplicaciones donde se engloben los mantenimientos
correctivos, preventivos y soporte, la naturaleza y las necesidades difieren de un modelo
puro de desarrollo. Por estas actividades proponemos desarrollar la metodología ágil
basada en Kanban, que hace énfasis en la entrega justa a tiempo y destaca para ser una
técnica de gestión de tareas muy visual, garantizando así, uno de los puntos clave de esta
propuesta: la combinación de agilidad y respuesta a las necesidades de negocio. Kanban
no define la estimación, pero sí se puede garantizar una predictibilidad gracias a la
limitación del Work In Progress.
Inetum dispone de conocimiento, perfiles cualificados y herramientas con las que utilizar
dicho modelo de trabajo. Kanban puede utilizarse con éxito en la gestión y soporte de
incidentes (IT Service Management, ITSM) para optimizar el modo en que se planifican y
ejecutan las tareas cotidianas. Entre los principales objetivos que se consiguen con su uso
se encuentran:




Facilitar el proceso de soporte, su flujo de trabajo y visibilidad de estado.
Detectar de forma temprana cuellos de botella o temas más críticos.
Involucra al equipo en todos sus frentes sobre temas prioritarios o urgentes.
Calibrar la capacidad según el estado del trabajo pendiente de entrega.
Nosotros concebimos Kanban como el complemento natural a Scrum, de forma que puedan
ser integrados como respuesta a la metodología integral del servicio. Los principales
beneficios esperados de utilizar un modelo Kanban para los procesos de mantenimiento
correctivo serán:




Apropiado por mantenimientos correctivos, en los que se realiza una fijación de
incidentes o errores continua guiada por prioridades.
Representa una mejora de la asignación de tareas y la gestión de la carga de trabajo
Está basado en un modelo “pull” donde los miembros del equipo recogen nuevas
tareas tan pronto como tengan disponibilidad.
Efectivo para cambiar frecuentemente la prioridad ante exigencias de negocios o
urgencia operativa.
2.4.3 Metodología de calidad y pruebas
La metodología que Inetum aplica a sus servicios y proyectos define los procesos y actividades que
se deben articular en cuanto a Pruebas de Control de Calidad de los productos entregados. Esta
Metodología de Aseguramiento y Control de Calidad será presentada en la Fase Pre-Operativa del
servicio, de acuerdo con la página 16 de los TdR.[1][2][3]
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Ciclo de vida del software, fila 12. Se precisa, a solicitud de la CGR, que se agregará un hito de control para
la conformidad técnica (certificación) por parte del equipo técnico de la CGR, el cual será posterior a las pruebas de aceptación de usuario, lo cual será propuesto en
la Fase Pre-Operativa y validado en la Fase Operativa.
[2] De acuerdo a la absolución de la Sesión Técnica 2 – Aseguramiento y Control de Calidad, fila 4. Se presenta el documento de Metodología de Aseguramiento y
Control de Calidad en la Fase Pre-Operativa del servicio, solicitado en la página 16 de los TdR. Se agrega la certificación de parte de la CGR como hito en la
metodología de control de calidad.
[3] De acuerdo a la absolución de la Sesión Técnica 2 – Aseguramiento y Control de Calidad. El presente plan detalla lo solicitado por la CGR en las filas 5, 7 y 10.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
26 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
2.4.3.1 Aseguramiento de Calidad y Control de Calidad


El servicio propuesto por Inetum incluye activar el proceso de QA y QC.
El QA o aseguramiento de calidad está muy inclinado en la prevención de defectos y enfocado
100% al proceso del ciclo de vida de desarrollo caso diferente, pero a la vez complementario es
el QC o control de calidad que está enfocado en el producto cuyo objetivo principal seria
identificar los defectos. Ambos frentes se necesitan para velar por la calidad del producto final
Niveles Pruebas
Los niveles de pruebas que según ISTQB que son las instancias donde normalmente se aplica los
diferentes tipos de pruebas a considerar como parte del alcance del servicio de Calidad por
Inetum serán los siguiente:




Pruebas Unitarias o de Componente (Participación 100% del Dev): este tipo de pruebas
son ejecutadas normalmente por el equipo de desarrollo, básicamente consisten en la
ejecución de actividades que le permitan verificar al desarrollador que los componentes
unitarios están codificados bajo condiciones de robustez, esto es, soportando el ingreso de
datos erróneos o inesperados y demostrando así la capacidad de tratar errores de manera
controlada. Por último, es importante que toda la funcionalidad de cada componente unitario
sea cubierta, por al menos, dos casos de prueba, los cuales deben centrarse en probar al
menos una funcionalidad positiva y una negativa.
Pruebas de Integración (Participación 100% del Dev): este tipo de pruebas son ejecutas
por el equipo de desarrollo y consisten en la comprobación de que elementos del software
que interactúan entre sí, funcionan de manera correcta.
Pruebas de Sistema (Participación 100% del Tester): este tipo de pruebas deben ser
ejecutadas idealmente por un equipo de pruebas ajeno al equipo de desarrollo, la obligación
de este equipo consiste en la ejecución de actividades de prueba en donde se debe verificar
que la funcionalidad total de un sistema fue implementada de acuerdo a los documentos de
especificación definidos en el proyecto. Los casos de prueba a diseñar en este nivel de
pruebas deben cubrir los aspectos funcionales y no funcionales del sistema. Para el diseño
de los casos de prueba en este nivel, el equipo debe utilizar como bases de prueba
entregables tales como: requerimientos iniciales, casos de uso, historias de usuario, diseños,
manuales técnicos y de usuario final, etc. Por último, es importante que los tipos de pruebas
ejecutados en este nivel se desplieguen en un ambiente de pruebas / ambiente de
preproducción cuya infraestructura y arquitectura sea similar al ambiente de producción,
evitando en todos los casos utilizar el ambiente real del cliente, debido principalmente, a que
pueda ocasionar fallos en los servidores, lo que ocasionaría indisponibilidad en otros servicios
alojados en este ambiente.
Pruebas de Aceptación (Participación 100% del Usuario Final): Independientemente de
que se haya tercerizado el proceso de pruebas y así la firma responsable de estas actividades
haya emitido un certificado de calidad sobre el sistema objeto de prueba, es indispensable,
que el cliente designe a personal que haga parte de los procesos de negocio para la ejecución
de pruebas de aceptación, es incluso recomendable, que los usuarios finales que participen
en este proceso sean independientes al personal que apoyó el proceso de desarrollo.
Tipos de Pruebas
Los tipos de pruebas a considerar como parte del alcance del servicio de Calidad por Inetum
serán los siguiente:
•
Verificación de Requisitos: Proceso que permite encontrar, mediante el uso de listas de
chequeo funcionales predefinidas, falencias en los documentos de Especificación de
requisitos. Estas falencias pueden estar orientadas a: Ambigüedades e inconsistencias y
Estructura del documento (Completitud).
•
Preparación de Pruebas: Su objetivo es Diseñar, desarrollar y revisar matrices funcionales
y casos y condiciones de prueba funcional.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
27 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
•
Pruebas Unitarias: Es la prueba inicial del código nuevo y/o cambiado en un módulo.
Verifica las Especificaciones lógicas internas del programa o módulo y valida la lógica.
•
Pruebas de Estándares: Verifica el cumplimiento de los estándares de: programación, GUI,
servicios y base de datos
•
Pruebas Funcionales: Verifican la ejecución apropiada de los componentes de la aplicación
y no requiere que la aplicación bajo prueba interactúe con aplicaciones. La comunicación
entre los módulos del sub- sistema es probada en un ambiente controlado y aislado dentro
del proyecto.
•
Pruebas de Sistemas: Verifican la ejecución apropiada de todos los componentes de la
aplicación, incluyendo las interfaces con otras aplicaciones. Se realizan pruebas de tipo
funcional y estructural para verificar que el sistema está alineado funcional y
operacionalmente. También incluyen las pruebas de Regresión, donde se verifica que no se
produzcan cambios en alguna parte del sistema como resultado de cambios realizados en
otra parte del mismo sistema
•
Pruebas de Esfuerzo: Pruebas del servicio las pruebas de carga y stress (pruebas de
performance)
Pruebas Integrales: Su objetivo es probar la aplicación en un ambiente que incluya interfaces
externas a la aplicación e inclusive externas a la organización validando que la funcionalidad
de negocio no sea impactada por los sistemas con que interactuará
•
•
Pruebas a Documentación: Verificar la completitud de la documentación, así como el
cumplimiento de estándares.
•
Pruebas de Seguridad, Control de accesos y evaluación de vulnerabilidades: Comprobar la
seguridad y control de accesos de usuarios y al sistema, conforme a las responsabilidades
de cada actor del sistema. Verificar que el funcionamiento del sistema esté acorde a lo
descrito en las especificaciones de los requerimientos funcionales. Revisar el Manejo de
excepciones y control de errores de la aplicación.
•
Pruebas de Fallas y Recuperación: Probar la capacidad del sistema para recuperar datos
y restablecerse después de una falla. Verificar que el sistema soporte manejo personalizado
de errores y funcione correctamente en caso de falla de algún componente.
2.4.3.2 Metodología de Aseguramiento de Calidad
El aseguramiento de calidad es una parte vital para obtener un producto de calidad, este enfoque se
centra en el proceso verificando que cada fase del ciclo de vida de desarrollo (indistinto de la
metodología de desarrollo) cumpla con ciertas condiciones que permite prevenir defectos durante la
construcción del producto. Los beneficios del aseguramiento de calidad son:
•
•
•
•
Identificación de bugs en etapas tempranas
Cumplimiento con normas o políticas de la empresa
Mejora continua en ciclo de vida de desarrollo
Velocidad y Ahorro en el ciclo de vida de desarrollo
Inetum cuenta con su propia metodología de aseguramiento de calidad construida en base a buenas
prácticas y experiencia obtenida durante los años.
Pre-Planificación: Esta es la fase inicial de la metodología, con el objetivo principal de tener
primeras reuniones con el cliente e identificar los lineamientos, criterios y/o condiciones según
políticas de la empresa que se deberían de cumplir y que formarían parte del alcance que estaría
verificando el equipo de aseguramiento de calidad
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
28 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Entradas:
• Lineamientos y/o políticas propio de la empresa
• Documentación del Gobierno TI de la empresa
• Documentación de aspectos auditables de la empresa
Salidas
• Plan Alto Nivel de Aseguramiento de Calidad
Planificación: Habiéndose realizado diferentes reuniones con el cliente y habiendo entendido el
contexto de la realidad del cliente, se toma un tiempo para definir el Plan de Aseguramiento de
Calidad General de todo el proceso del ciclo de vida de desarrollo donde se define el alcance,
estrategia, riesgos y puntos a verificación durante el proceso en cada fase del ciclo de desarrollo. Los
puntos de verificación o checklist de casos se realizan por cada fase del ciclo de desarrollo. Este plan
se comparte con el equipo de negocio, así como también con el equipo de desarrollo
Entradas.
• Plan Alto Nivel de Aseguramiento de Calidad
Salidas
• Plan Detalle de Aseguramiento de Calidad
• Checklist de Puntos de Verificación por Etapa
Ejecución: Esta fase de ejecución se da por cada etapa del ciclo de vida de desarrollo y según la
experiencia obtenida se propone ejecutarla semanalmente, para verificar que se las etapas,
artefactos, lineamientos y/o condiciones definidas en el CheckList se cumplan a cabalidad y se
identificar alguna anomalía comunicarle directamente a la persona responsable de la etapa o del
artefacto para su rápida regularización
Entradas
• Checklist de Puntos de Verificación por Etapa (Ejecutado)
Salidas
• Reporte de Observaciones
• Informe de Ejecución
Resultados: Esta etapa se aplica al finalizar cada fase del ciclo de desarrollo, tiene como objetivo
compartir los resultados del aseguramiento de calidad y compartir también que las anomalías
identificadas en la ejecución se resolvieron apropiadamente
Entradas
• Checklist de Puntos de Verificación por Etapa (Ejecutado)
• Reporte de Observaciones
• Informe de Ejecución
Salidas
• Resultados Final de QA por Etapa
2.4.3.3 Metodología de Control de Calidad Tradicional
Esta metodología propuesta por Inetum se activa cuando el objeto de prueba se desarrolla bajo la
metodología Waterfall
A continuación, se detalle las fases del método de testing tradicional propuesto:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
29 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Estimación y Planeación
Cuando el requerimiento es asignado al equipo operativo de tester’s una de las primeras
actividades que se realiza es el de estimación de las pruebas que va a permitir calcular el esfuerzo
más probable que se invertirá en el proceso de certificación, posterior a ello esta estimación es
presentada al equipo de contraloría en pro de su respectiva aprobación. Con la aprobación de la
estimación se da inicio a la etapa de Planeación donde se plasmará el alcance de las pruebas, el
objetivo y el enfoque estratégico que se a aplicar en pro de cumplir con lo establecido,
permitiéndonos tener un control de las pruebas frente a posibles desviaciones que se puedan
presentar durante el proceso.
Entrada
• Documentación del Proyecto (Documento funcional, Documento de prototipo, entre
otros)
• Riesgos del Proyectos
• Restricciones del Proyectos
Salida
•
•
•
•
Plan de Proyecto de Pruebas
Cronograma de Proyecto de Pruebas
Estimación de Proyecto de Pruebas
Informe de Avance
Análisis y Diseño
Posterior a la aprobación del Plan de Pruebas, el equipo operativo de Teser’s realiza actividades
relacionado al análisis y diseño de casos de pruebas, es importante tener detallado los casos de
pruebas según las técnicas de diseño aplicadas en un documento estructurado, debido a que nos
va a permitir tener una trazabilidad bidireccional con los requisitos y el alcance planteado en la
Planeación de Pruebas. Es en esta etapa donde se realiza la generación de dato en caso las
pruebas lo ameriten
Entrada
• Documentación del Proyecto (Documento funcional, Documento de prototipo, entre
otros)
• Riesgos del Proyectos
• Restricciones del Proyectos
• Plan de Proyecto de Prueba
Salida
• Diseño de Casos de Pruebas
• Data de Prueba
• Informe de Avance
Ejecución y Gestión de Bugs (Certificación Nivel de Sistemas)
Posterior a la aprobación del Diseño de Casos de Pruebas, el equipo operativo de Tester’s realiza
actividades relacionado a la ejecución de las pruebas. La gestión de los bugs identificados durante
la etapa de ejecución es de vital importancia, para eso Inetum cuenta con Tester’s capacitados
para dicha gestión apuntando en todo momento culminar las pruebas según los tiempos estimado
en la Planeación de las Pruebas.
La ejecución de las pruebas inicia con el Smoke Test cuyo es verificar la estabilidad del aplicativo
con la ejecución de un conjunto de casos de pruebas básicos
La ejecución de las pruebas culmina cuando la ejecución de los casos de pruebas de Regresión
es exitosos.
Entrada
• Documentación del Proyecto (Documento funcional, Documento de prototipo, entre
otros)
• Riesgos del Proyectos
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
30 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
•
•
•
Salida
•
•
•
•
Restricciones del Proyectos
Plan de Proyecto de Prueba
Diseño de Casos de Pruebas
Ejecución del Diseño de Casos de Pruebas
Listado de Bugs
Evidencias de Ejecución
Informe de Avance
Pruebas de Usuario (Certificación Nivel de Aceptación)
Una vez terminado la ejecución de los casos de pruebas según la estrategia de pruebas definida
en la etapa de Planeación y siempre y cuando el estado del 100% de casos de pruebas este
conforme, el Líder QC coordina con el equipo de Usuario Final (CGR) para que se active el proceso
de certificación en un nivel de aceptación por parte del Usuario Final. Lo que sugerimos en este
proceso es tener una primera reunión con el usuario final que ejecutara las pruebas a nivel de
aceptación con el objetivo de proponerle un conjunto de casos de pruebas a nivel de negocio
(flujos prioritarios) que podrían formar parte del alcance de sus pruebas, el usuario las podría
admitir y/o complementar con otros casos de pruebas de negocio definido por el mismo, durante
la ejecución el equipo de tester acompaña al usuario final en pro de gestionar proactivamente
algún inconveniente o identificación de bugs que surja durante el proceso de certificación por
parte del usuario final, este proceso de certificación por parte del usuario culmina cuando todos
los casos de pruebas ejecutados que han formado parte del alcance de las pruebas en un nivel
de aceptación se encuentran en el estado conforme, esta conformidad se debe de dar de manera
formal (correo) y con ello es el input para que el equipo de tester coordine directamente con el
equipo de desarrollo el pase a PRD del incremento funcional o aplicativo (objeto de prueba)
Entrada
• Diseño de Casos de Pruebas Ejecutados
• Listado de Bugs
• Evidencias de Ejecución
Salida
• Correo de Conformidad por parte del Usuario Final
Gestión de Pase a PRD
Este es una fase netamente de desarrollo, pero se considera dentro de la metodología de
certificación debido a que el equipo tester tiene que estar muy al pendiente del pase a PRD del
incremento funcional o aplicativo (objeto de prueba) con el objetivo principal de apoyar (en caso
aplique) en las pruebas en Producción junto con el usuario final buscando la estabilización del
aplicativo en PRD.
Entrada
• Correo de Conformidad por parte del Usuario Final
Salida
• Formalización de pase a PRD
• Casos de Pruebas Ejecutados en PRD
Conformidad Técnica CGR: Como parte de la etapa de Gestión de Pase a PRD se agregará
un hito de control para la conformidad técnica (certificación) por parte del equipo técnico
de la CGR, el cual será posterior a las pruebas de aceptación de usuario, lo cual será
propuesto en la Fase Pre-Operativa y validado en la Fase Operativa.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
31 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Entrega y Feedback
Una vez ejecutado de manera exitosa los casos de pruebas de Regresión, el equipo operativo de
Tester’s genera la Carta de Certificación del Proyecto de Prueba y gestiona una reunión con todos
los participantes del proyecto con el objetivo de retroalimentar al equipo en general según los
datos obtenidos desde las pruebas apuntando a la mejora continua, en esta etapa también se
realizan las entregas formales de los artefactos generados durante el proceso de certificación.
Entrada
• Documentación del Proyecto (Documento funcional, Documento de prototipo, entre
otros)
• Riesgos del Proyectos
• Restricciones del Proyectos
• Plan de Proyecto de Prueba
• Diseño de Casos de Pruebas Ejecutados
• Listado de Bugs
• Evidencias de Ejecución
Salida
• Documento de Feedback
• Documento Checkist de Entrega
• Carta de Certificación
Seguimiento
Llevar un seguimiento del objeto de pruebas que actualmente está en producción, permite
ofrecer un apoyo proactivo en caso se identifique una incidencia en producción, sugiriendo de
manera inmediata un plan de acción que mitiguen los posibles riesgos a materializar.
Normalmente el seguimiento que realiza el equipo operativo de tester’s es en paralelo, es decir
a medida que va atendiendo otros requerimientos consulta cada cierto tiempo el comportamiento
del aplicativo en producción. Solo en caso de que se presente algún tipo de incidencia y que este
dentro de los 3 meses posterior al termino de las pruebas, Inetum asume sin costo alguno la
atención de la incidencia en caso contrario el apoyo de la certificación estaría dentro de la bolsa
de hora a facturar.
Entrada
• Datos del comportamiento del aplicativo en producción
Salida
• Documento de Seguimiento
2.4.3.4 Soporte de Artefactos de Pruebas Metodología Tradicional
Los artefactos propuestos por Inetum que darían soporte a la operación de pruebas bajo la
metodología tradicional serían las siguientes:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
32 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
•
Plantilla de Estimación: Documento de apoyo para obtener el cálculo del esfuerzo que se
requiere para el proceso de certificación de los proyectos de pruebas.
•
Plantilla de Cronograma: Documento visual de la planificación de las actividades del proceso
de pruebas, con este documento podemos visualizar el periodo de duración de cada actividad,
sus fechas de inicio y fin.
•
Plantilla de Plan de Pruebas: Documento que describe el alcance, enfoque, los recursos y
planificación de las actividades de pruebas previstas. Identifica, entre otros, los elementos de
prueba, las prestaciones a ser probadas, las tareas de pruebas, quien realiza cada tarea, el
entorno de pruebas, las técnicas de diseño de pruebas y los criterios de entrada y salida a utilizar,
y cualquier riesgo que requiera un plan de contingencia. Es un registro del proceso de
planificación de pruebas.
•
Plantilla de Diseño: Documento donde se registra el enunciado y el paso a paso de cada caso
de prueba que será ejecutados según la estrategia de pruebas definida.
•
Reporte de Bugs: Documento que informa acerca de cualquier imperfección en un componente
o sistema que puede causar que el componente o sistema no realice la función requerida.
•
Reporte de Evidencias: Documento generado durante la ejecución de las pruebas, este
documento muestra como evidencia las pantallas del objeto de prueba, en pro de que el analista
de calidad analice las evidencias e identifique los posibles errores del aplicativo.
•
Plantilla de Feedback: Documento donde se registra todos los inconvenientes que se
presentaron en cada una de las etapas del proceso de pruebas en pro analizar cada inconveniente
y plantear medidas correctivas con la finalidad de que no vuelvan a aparecer en los próximos
proyectos.
•
Plantilla de CheckList: Documento que permite verificar la entrega formal de los artefactos
generados durante el proceso de certificación.
•
Plantilla de Carta de Certificación: Documento que permite dar a conocer el estado del objeto
de pruebas una vez terminado la ejecución de los casos de regresión. En el escenario que el
cliente requiera salir a producción con errores aún no solucionados se emitiría una carta de
certificación condicionada.
•
Plantilla de Seguimiento: Documento que permite registrar información acerca del
comportamiento del aplicativo objeto de pruebas en producción.
•
Plantilla de Fastrack Tradicional: Documento utilizado para proyectos de pruebas que tengan
una duración menor a 5 días, este documento normalmente soporta el proceso de certificación
de desarrollos de tipo evolutivo y correctivo. En este documento se registra de manera integrado
el alcance, la estrategia, el diseño de los casos de pruebas y el resultado de las pruebas.
•
Plantilla de Informe de Avance: Documento que informa acerca del avance del proyecto de
pruebas, describiendo las actividades realizadas por el analista de calidad diariamente, así como
también los inconvenientes presentados durante el día en pro de tomar las medidas necesarias
para cumplir con los tiempos estimados.
•
Plantilla de Panorama de Proyectos de Pruebas Tradicionales: Documento que permita
registrar datos acerca de los diferentes proyectos de pruebas atendidos en el modelo tradicional,
esto con la finalidad de generar los indicadores operativos y de servicio acordados con CGR
2.4.3.5 Metodología de Control de Calidad Agile
Esta metodología propuesta por Inetum se activa cuando el objeto de prueba se desarrolla bajo el
marco de trabajo ágil. Se debe tener en cuenta que el tester forma parte del equipo de desarrollo.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
33 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
A continuación, se detalla las actividades principales en cada evento del marco agile testing:
Planeación del Sprint
Al comienzo de cada Sprint se planifica el trabajo que se hará durante el mismo. Este es un
trabajo colaborativo de todo el Equipo Scrum. La planificación del sprint tiene un timebox de un
máximo de 8 horas para un sprint de 1mes, para sprints de menos de un mes, el timebox de
este evento suele ser más corto.
El propósito de este evento de planificación es responder 2 preguntas:
1. ¿Qué es lo que se puede entregar como parte del incremento resultante de este sprint?
2. ¿Cómo se realizará el trabajo necesario para entregar este incremento?
El equipo Scrum completo colabora para identificar cuáles son los Items del Producto Backlog
que pueden ser realizados durante este sprint y que conformarían el incremento de Producto
necesario para alcanzar el Objetivo del Sprint
Las funciones principales del Tester en este evento son:
•
•
•
Entender el objetivo, impacto y alcance del Sprint a nivel de negocio
Estimar y registrar el esfuerzo de las tareas de prueba de la iteración por HU y velar por que
el equipo dentro de la estimación contemple el esfuerzo necesario para las pruebas de dicha
HU
Realizar el plan y estrategia de la prueba
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
34 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Iteración del Sprint
Posterior a la planeación del sprint el equipo scrum inicia actividades para la construcción del
Items del Product Backlog que fueron seleccionados para trabajar durante un determinado sprint,
al finalizar el sprint, el incremento del producto debe estar terminado, esto significa que está en
una condición tal que lo hace utilizable y que además cumple con la definición de terminado del
equipo scrum. Las funciones principales del Tester en este evento son:
•
•
•
•
•
•
Diseñar y ejecutar las pruebas
Divulgar/registrar bugs
Asistir al equipo en temas relacionados con pruebas
Gestionar defectos
Ejecutar retest, regresión
Asistir al product Owner en pruebas de aceptación (En caso de ser necesario)
Revisión del Sprint
Al finalizar cada sprint se realiza una reunión de revisión del sprint, donde se evalúa el incremento
funcional potencialmente entregable construido por el equipo de desarrollo. El timebox de esta
reunión es de 4 horas para un sprint de 1 mes de duración, para sprint más cortos este evento
habitualmente dura menos tiempo. En esta reunión el equipo scrum y los stakeholder revisan el
resultado del sprint, cuando decimos resultado hablamos de producto utilizable y potencialmente
entregable que los interesados utilizan y evalúan durante esta misma reunión, aceptando o
rechazando así las funcionalidades construidas
Las funciones principales del Tester en este evento son:
•
•
•
•
Participar activamente en la reunión de revisión del sprint
Participar en la preparación de la demostración
Participar en la demostración de funcionamiento
Resolver dudas del product Owner u otros stakeholders interesados
Pruebas de Aceptación de Usuario: En un esquema agile la participación del usuario es muy
frecuente durante la iteración de cada sprint, en las reuniones diarias el usuario final se pone
en contexto del avance del incremento funcional y al mismo tiempo se da cuenta si lo que el
equipo de desarrollo (dev + qa) esta construyendo esta alineado a las expectativas que el
espera. Las pruebas de aceptación de usuario en un esquema agilen se ejecuta en el evento
de revisión del sprint, en este evento el equipo de desarrollo (dev + qa) expone el incremento
funcional ya termina y es el usuario final quien da la conformidad en evidencia que lo
construido por el equipo en dicho sprint cumple con las expectativas descritas al inicio del
spint, con esta conformidad el incremento funcional quedaría listo para el despliegue a
producción.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
35 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Conformidad Técnica CGR: Como parte de Revisión del Sprint se agregará un hito de
control para la conformidad técnica (certificación) por parte del equipo técnico de la CGR,
el cual será posterior a las pruebas de aceptación de usuario, lo cual será propuesto en
la Fase Pre-Operativa y validado en la Fase Operativa.[1]
Scrum Diario
Estos 4 objetivos son logrados mediante las reuniones diarias de Scrum (Daily Scrum):
1.Incrementar la comunicación.
2.Explicar los compromisos.
3.Dar visibilidad a los impedimentos.
4.Sincronizar frecuentemente.
Estas reuniones tienen una frecuencia diaria y un timebox de 15 min, cada día en estos 15 min
los miembros del equipo de desarrollo sincronizan sus actividades y replanifican lo que crean
necesario hasta el siguiente scrum diario.
Todos y cada uno de los miembros toman turnos para responder las siguientes 3 preguntas y de
esa manera comunicarse entre ellos:
1. Dar claridad con respecto al cumplimiento de compromisos adquiridos en la última reunión
respondiendo la pregunta ¿Qué hice ayer?
2. Adquirir nuevos compromisos a ejecutar respondiendo la pregunta ¿Qué haré hoy?
3. Dar visibilidad de los posibles obstáculos o impedimentos detectados respondiendo la
pregunta ¿Qué impedimentos tengo?
[1] De acuerdo a la absolución de la Sesión Técnica 2 – Aseguramiento y Control de Calidad, fila 4. Se presenta el documento de Metodología de Aseguramiento y
Control de Calidad en la Fase Pre-Operativa del servicio, solicitado en la página 16 de los TdR. Se agrega la certificación de parte de la CGR como hito en la
metodología de control de calidad.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
36 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Retrospectiva
La retrospectiva del equipo es el corazón de la mejora continua y las prácticas emergentes,
mediante el mecanismo de retrospectiva, el equipo reflexiona sobre la forma en la que realizó su
trabajo y los acontecimientos que sucedieron en el sprint que acaba de concluir para mejorar sus
práctica. Esta reunión tiene lugar inmediatamente después de la reunión de revisión y antes de
la planificación del próximo sprint. Las funciones principales del Tester en este evento son:
•
•
•
Compartir con el equipo los asuntos detectados que no se deben repetir en el próximo Sprint
Compartir con el equipo las actividades que se deben repetir en el próximo Sprint
Cooperar con el equipo para encontrar la causa raíz de lo que salió mal durante el Sprint
Nota: En agilidad los despliegues a producción se realizan mediante release que es un road map
de paquetes conformado por sprint y a su vez pbi y son esos paquetes referenciados en algun
realease que se despliegan a Producción, ya en producción a nivel de testing con el objetivo
de verificar la estabilidad del producto en PRD, lo que se realiza es lo siguiente: (1) se puede
ejecutar algunos casos de pruebas estrategicos de manera automatica (2) el usuario final
puede realizar algunas pruebas manuales (3) el equipo de tester realiza algunas pruebas
manuales. Esto depende de la estrategia que se defina en su momento
2.4.3.6 Soporte de Artefactos de Pruebas Metodología Agile
Scrum es un marco de trabajo que nos permite encontrar prácticas emergentes en dominios
complejos, como la gestión de proyectos de innovación. No es un proceso completo, y mucho menos
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
37 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
una metodología, en lugar de proporcionar una descripción completa y detallada de cómo deben
realizarse las tareas de un proyecto, genera un contexto relacional e iterativo, de inspección y
adaptación constante para que los involucrados vayan creando sus propios procesos y artefactos.
Bajo esta premisa y por la experiencia obtenida Inetum propone el uso del artefacto Fastrack Ágil.
•
Plantilla de Fastrack Agil: Documento utilizado para proyectos de pruebas bajo el marco de
trabajo ágil. En este documento se registra de manera integrado el alcance, la estrategia, el
diseño de los casos de pruebas y el resultado de las pruebas.
•
Plantilla de Panorama de Proyectos de Pruebas Ágil: Documento que permita registrar
datos acerca de los diferentes proyectos de pruebas atendidos en el modelo ágil, esto con la
finalidad de generar los indicadores operativos y de servicio acordados con CG
2.4.3.7 Automatización de Pruebas – Control de Calidad
La automatización es una estrategia de las pruebas de software que mediante el uso de técnicas y
herramientas busca acelerar la ejecución de las pruebas ¿Cuándo aplicar automatización de pruebas?
•
•
•
•
•
Cambios: Alta frecuencia en la recepción de versiones de software
Reutilización: Procesos que son utilizados por varios aplicativos
Incremento de cobertura: Para minimizar riesgo - regresión
Ecosistema: Aumentar la eficiencia en los procesos
Desarrollo: Modelos de integración, entrega y despliegue continuo -> DevOps
A continuación, algunos principales beneficios de la automatización de pruebas:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
38 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
2.4.3.8 Herramientas de Pruebas – Control de Calidad
#
Herramienta
s
Categoría
Tipo
de Prueba
Comentario
1
TestLink
OpenSource
General
TestLink es una herramienta
gratuita que permite crear y
gestionar casos de pruebas
y organizarlos en planes de
prueba. Estos planes permiten
a los miembros del equipo
ejecutar casos de prueba y
registrar
los
resultados
dinámicamente,
generar
informes,
mantener
la
trazabilidad
con
los
requerimientos,
así
como
priorizar y asignar tareas.
2
Mantis
OpenSource
General
Mantis es una aplicación Open
Source que sirve para controlar
los
errores
aparecidos
en el software y que permite a
desarrolladores,
testers
o
clientes reportar fallos y realizar
el seguimiento de estos hasta
su resolución
3
Jira
OpenSource
General
Jira es una herramienta en línea
para la administración de tareas
de
un
proyecto,
el
seguimiento de errores e
incidencias y para la gestión
operativa de proyectos
4
Bugzilla
OpenSource
General
Bugzilla es una herramienta
basada en Web de seguimiento
de errores (Bug Tracking
System o BTS, por sus siglas en
inglés),
originalmente
desarrollada y usada por el
proyecto Mozilla.
5
Jmeter
OpenSource
Pruebas de
Performance
JMeter es una herramienta que
facilita la gestión integral de los
procesos
de
pruebas
de
rendimiento
6
Neotys
OpenSource
Pruebas de
Performance
Neoload es una herramienta de
prueba de estrés y carga de alta
eficiencia
7
Wapt
OpenSource
Pruebas de
Performance
WAPT es una herramienta de
prueba de carga y rendimiento
que funciona para cualquier
sitio web, desde un simple
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
39 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
servicio web hasta una solución
ERP o CRM personalizada
8
Sonarq
OpenSource
Pruebas de Caja
Blanca
SonarQube es una plataforma
web que se utiliza para analizar
y cuantificar la calidad del
código
fuente.
Es
una
herramienta de código abierto
que provee varias ediciones
dependiendo de la necesidad de
los usuarios
9
Selenium
OpenSource
Automatización
de Pruebas
Selenium es un recurso que se
utiliza
para
automatizar
pruebas de sistemas. Esta
herramienta permite al usuario
reproducir el ambiente real de
la aplicación. A lo que se suma,
que a través de una extensión
se pueden crear los scripts de
prueba de manera sencilla.
10
Postman
OpenSource
Pruebas de
Microservicios
Postman es una aplicación que
nos permite realizar pruebas
API
11
Rest Assured
OpenSource
Pruebas de
Microservicios
(Automatizado)
Rest Assured es utilizado para
las pruebas funcionales de
servicios 'REST', y nos da la
posibilidad
de
validar
las
respuestas HTTP recibidas del
servidor
12
Karate
OpenSource
Pruebas de
Microservicios
(Automatizado)
Karate es un marco de
automatización de pruebas de
uso general de código abierto
que
puede realizar secuencias de
comandos de llamadas a puntos
finales HTTP y afirmar que las
respuestas JSON o XML son las
esperadas
13
Junit
OpenSource
Pruebas Unitarias
Automatizada
s
JUnit se trata de un Framework
Open Source para la
automatización de las pruebas
(tanto unitarias, como de
integración) en los proyectos
Software.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
40 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
El presente listado busca utilizar herramientas OpenSource para el desarrollo del sistema materia de
este alcance. Aquellas herramientas o software que por sus características solo permita su uso bajo
licenciamiento, estas licencias serán adquiridas por Inetum a nombre de la CGR, acorde a lo indicado
en el numeral 3. Plataforma Tecnológica de los TdR. Se adjunta un Excel con el listado de
Herramientas y Artefactos, así como su esquema de licenciamiento para cada una de ellas, las
mismas que han sido propuestas por Inetum.[1]
2.4.3.9 Equipo de Aseguramiento y Control de Calidad
El equipo estará encabezado por un Líder QA & QC quien será el responsable principal de la operativa
y los resultados de esos 2 frente, este a su vez estará apoyado por un Líder de QA velando por el
cumplimiento del aseguramiento de calidad a nivel proceso y por otro lado está el Líder de QC velando
por el cumplimiento del control de calidad a nivel proceso. Cada líder con su respectivo equipo.
Con respecto al equipo de la Contraloría, sugerimos los siguientes roles:
Líder de QA & QC CGR: Responsable directo de dar seguimiento al proceso de aseguramiento de
calidad y control de calidad ejecutado por el equipo Inetum. Encargado de revisar los resultados
del equipo Inetum. Este líder nos apoyara en desbloquear cualquier inconveniente por parte de
CGR que podría conllevar a generar retraso al proceso de qa & qc
Usuarios Finales CGR: Responsable de dar la conformidad de los productos desarrollados por
parte del equipo Inetum.[2]
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
41 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Aseguramiento y Control de Calidad, fila 8. Se precisa, a solicitud de la CGR, las herramientas que se
utilizarán dentro del proceso de aseguramiento y control de calidad.
2.4.4 Plan de transición del modelo tradicional hacia el modelo ágil
[2] De acuerdo a la absolución de la Sesión Técnica 1 – Aseguramiento y Control de Calidad, fila 6. Se precisa, a solicitud de la CGR, los roles y funciones del personal
de la CGR dentro del proceso de aseguramiento y control de calidad.
Dicha transición será realizada durante la etapa pre-operativa teniendo en cuenta que la CGR
manifiesta su intención de iniciar el proyecto bajo la metodología propuesta. El detalle de este plan
se encuentra en la pestaña D-3, incluido en el archivo Plan de Trabajo Proyecto Contraloría.xls[1]
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Aseguramiento y Control de Calidad, fila 9. Se agrega, a solicitud de la CGR, el Plan de Transición del modelo
tradicional hacia el modelo ágil; incluyendo plazos, actividades, responsables, entre otros dentro del documento Plan de Trabajo Proyecto Contraloria.xls
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
42 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
3 Metodología integral del proyecto
Inetum se compromete a la prestación de los servicios que son objeto de esta licitación bajo la
prescripción definida en el Modelo de Gestión de Servicio TI del CGR, basado en las mejores prácticas
ITIL, asegurándose de que todo el equipo de trabajo sea conocedor del modelo bajo el cual debe
realizar todas sus actividades.
En los siguientes apartados se especifica la propuesta de modelo de gestión de Inetum compuesto
también de una serie de elementos basados en las mejores prácticas ITIL y CMMI.
3.1 Portfolio de Servicio
El catálogo de servicios a ejecutar como parte del Lote 3 se estructura en un Servicio Base, que
incluye los servicios relacionados con el entorno productivo y con el seguimiento de desarrollos, y un
Servicio Bajo Demanda que incluye el mantenimiento y/o nuevos desarrollos y servicios
adicionales.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
43 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Inetum garantiza la continuidad de estos servicios en la siguiente franja horaria, que será de
aplicación a todos los servicios a excepción de las guardias necesarias para garantizar la ejecución
de las estadísticas a final de cada mes (se ejecutarán de forma remota). El calendario laboral de
aplicación para la prestación de estos servicios será el de la localidad de Madrid.
Día
Horario Inicial
Lunes a viernes
8:00
Horario Final
17:00
Inetum aplicará este horario de forma flexible, en función de las necesidades del servicio:

Ampliando el horario final ante peticiones puntuales de colaboración del CGR como, por
ejemplo, apoyo para la elaboración de ponencias, informes, etc.

Adaptando el horario inicial o final del servicio, de todo o parte del equipo, bajo petición del
CGR.

Atendiendo peticiones recibidas fuera de este horario conforme a acuerdo explicito con CGR
y considerando un cómputo especial de “horas extras”. Asimismo, no computando los
tiempos fuera del horario de servicio para la determinación del cumplimiento de plazos
establecido en los ANS.
De igual forma, en el caso de incidencias de alto impacto Inetum propondrá activar el procedimiento
de “Trabajo Hasta Finalización” (THF), es decir, trabajar hasta que se resuelva la petición,
independientemente del horario de prestación servicio. Para la activación del procedimiento de
trabajo hasta finalización se requerirá la aprobación del responsable de servicio de Inetum, que se
encargará de comunicarlo a los responsables de la CGR para su validación.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
44 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
3.2 Gestión del Cambio
3.2.1 Inducción a la Agilidad
A continuación, presentamos la estrategia de INETUM para la Gestión del Cambio e inducción en la
forma de trabajo Ágil promovida por nuestra metodología propuesta para la CGR, la cual consta de
5 etapas principales:[1]
Las actividades de gestión recurrentes se dan a lo largo de todo el ciclo de gestión de cambio y son
necesarias para el éxito del proyecto. Nuestra consultoría se brindará durante el primer mes
del proyecto y por un total de 24 horas instructivas.
Un mayor alcance de estas actividades se muestra en el siguiente esquema, que estarán a cargo de
los nuevos Formadores de Contraloría:
•Identificar y
mapear
stakeholders
•Observar
comportamientos
•Planificar y
moderar
reuniones
Procesos
Participativos
•Desarrollar un
clima que estimule
las ideas
•Generar clima de
confianza
•Técnicas de
brainstormmig
•Taller de Product
Owners
Innovación y
Agilidad del
Negocio
•Evaluar posibles
situaciones de
conflicto
•Entender causa
raíz de conflictos y
actuar como
moderadores
•Mentor y Coach
Gestionar
Conflictos
•Involucrar a
patrocinador y lideres
•Monitorear el
comportamiento de
stakeholders
•Técnicas de adhesión
al cambio
Gestionar
Stakeholders
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Estrategias para el análisis de requerimientos y definición del alcance, fila 13. Se precisa, de acuerdo con
lo solicitado por la CGR, una estrategia para la transferencia de conocimiento como parte de la metodología de desarrollo de software, la cual podrá ser perfectible
en la Fase Pre-Operativa.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
45 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
3.2.2 Capacitación y Mentoría
Contaremos con un Plan de Capacitación orientado a definir la estrategia y plan de actividades para
capacitar y cualificar metodológicamente a los actores de CGR asignados al proyecto y afectados por
los cambios relacionados con la implementación de nuestra metodología de proyecto. Se espera que
el resultado sea un efecto dinamizador dentro de la estructura organizativa de CGR mejorando de
este modo el clima e interacción con el trabajo propio del proyecto y el avance en el cumplimiento
de las expectativas. La capacitación en la metodología para el personal del proyecto de CGR será
durante toda la fase II de Ejecución del servicio.[1]
Las acciones formativas en el nuevo marco de trabajo nos llevarán a conseguir los siguientes
beneficios:

Incrementar el valor añadido de los actores que participan en cualquier fase del ciclo de vida,
dotándolos de las habilidades y técnicas específicas para su intervención.

Que todos los actores afectados comprendan los motivos que impulsan la implantación de
un nuevo modelo o funcionalidad y su lineamiento general.

Aportar los conocimientos de los medios y herramientas con los que contarán en su puesto
de trabajo.

Potenciar la capacidad de trabajo de los actores del sistema en conjunto con el equipo de
proyecto.

Facilitar la actualización de procedimientos, estándares y modelo de operación que ya se
vienen proponiendo de cara a su realización en el nuevo proyecto.

Instruir sobre las versiones de la solución de SW liberadas a los ambientes de CGR para uso
de analistas, usuarios u otros miembros de CGR involucrados en el proyecto.
Finalmente, en detalle las actividades a realizar serán:

Elaboración de los calendarios de formación de cada colectivo (sesiones de retrospectiva del
servicio mensuales(con una duración mínima de 2 horas) a cargo del Jefe de Proyecto y
Analistas principales de INETUM). Estas sesiones no son consideradas como horas
facturables del proyecto.

Preparación de presentaciones y material de formación.

Designación de los temas a tratar priorizados según la fase y coyuntura del proyecto.

Identificar de forma detallada las personas que deben asistir a cada curso de formación por
parte de CGR y equipo técnico de INETUM asignado al proyecto.

Comunicar la programación de sesiones a las personas invitadas, recibir su feedback sobre
posibles observaciones y realizar los ajustes correspondientes para posteriores sesiones del
calendario de formación.

Realizar la difusión final del contenido de formación y su publicación en la plataforma de
gestión de contenido del proyecto (Confluence).

Crear una nota de release ("Release Note") asociada a cada despliegue de la solución de SW
donde se identifiquen las funcionalidades o ajustes incluidos en la versión entregada. Del
mismo modo, cada entrega incluirá una sesión técnico-funcional donde se instruya al equipo
CGR sobre las funcionalidades entregadas. Cada sesión tendrá una duración promedio de 2
horas o hasta que se cubra la agenda de funcionalidades incluidas.[2][3]
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Gestión del Proyecto, fila 10. Inetum acepta, a solicitud de la CGR, que la capacitación y mentoría será
durante toda la ejecución del servicio.
[2] De acuerdo a la absolución de la Sesión Técnica 1 – Gestión del Proyecto, fila 10. Inetum adiciona, a solicitud de la CGR, que la capacitación y mentoría, será
después de cada versión certificada por la CGR
[3] De acuerdo a la absolución de la Sesión Técnica 3 – Gestión del Proyecto, fila 30, 31. Inetum adiciona, a solicitud de la CGR, el plan de capación a ser
desarrollada durante el servicio
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
46 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
3.3 Modelo de desarrollo
Proponemos cumplir con la actual metodología de desarrollo determinada por CGR en base a
la NTP-ISO/IEC 12207 y a la Ley de Gobierno Digital[1], a través de los lineamientos señalados
en los siguientes documentos ya anunciados por la CGR y en cumplimiento normativo del Estado
Peruano que serán puestos a disposición del proyecto:
Documentos sujetos a revisión y/o actualización por parte de INETUM producto de los
acuerdos con CGR y con relación al alcance del proyecto:





Documento de Metodología de Desarrollo de Software de la CGR.
Documento de Estándares de Programación
Documento de Estándares de Base de Datos
Documento de Plan de Aseguramiento y Control de la Calidad
Acuerdos de Niveles de Servicio del presente Proyecto.
Documentos sujetos a actualización por parte de CGR producto de factores externos al
proyecto, normativos o de mejoras recolectados del proyecto:




Documento de Dirección de Proyectos de la CGR.
Documento de Seguridad de la Información de la CGR
Normas y lineamientos de Control Interno de la CGR
Normas de control Interno aprobado con resolución Nº 320-2006-CG
Normas Técnicas NO modificables a cumplirse en el proyecto:



NTP-ISO/IEC 27001
NTP-ISO/IEC 12207
NTP-ISO/IEC 15504[2]
Así mismo, como antes mencionamos, proponemos como iniciativa de modernización la adecuación
y evolución de la metodología hacia una basada en los estándares agile (metodología ágil)
y la automatización de pruebas. Queremos destacar que en este tipo de proyectos de
modernización es fundamental la agilidad y la rapidez de la entrega de componentes, por dos razones
básicas:


Los sistemas involucrados deben ser flexibles al cambio y adaptación del negocio.
Es importante obtener beneficios rápidos que ayuden a que el proceso de modernización sea
bien acogido porque de forma rápida se aprecian los beneficios que aportan.
Con ello, reafirmamos nuestro interés en alinear la metodología actual a los estándares
ágiles propuestos de forma que no se afecte el cumplimiento a la norma, sino que se
simplifique y agilice.
Equivalencia de los componentes para la aplicación de la metodología propuesta:[3]
Componentes de acuerdo al TDR
Componente de Análisis de Sistemas
Equivalencia en la metodología
Modelamiento de Negocio
Fase de inception
Modelamiento de Sistema
Fase de inception
Componente de Desarrollo de Software
Fase de desarrollo
Componentes de Certificación de Calidad
Grupo de testing
Componente de Gestión de Incidentes
Fase de retroalimentación
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Ciclo de vida del software, fila 18. Se incluye el lineamiento basado en la Ley de Gobierno Digital
[2] De acuerdo a la absolución de la Sesión Técnica 1 – Ciclo de vida del software, fila 13. Se incluye los lineamientos indicados por el Estado Peruano y otros
estándares incluidos en los TdR (ítem D de PRESTACIONES, en página 7 del TdR)
[3] De acuerdo a la absolución de la Sesión Técnica 1 – Ciclo de vida del software, fila 15. Se agrega la relación entre la metodología y los componentes establecidos
en los TdR, en el numeral 4.1 Prestaciones, Tabla 1. Componentes del servicio (página 4).
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
47 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Equivalencia de los roles dentro de la metodología propuesta:[1]
Recurso
Rol en la metodología propuesta
Fase de participación
Delivery Manager
Transition Manager/ Delivery Manager
Jefe de Proyecto
Scrum Master
Fase de inception / Fase de desarrollo
Arquitecto de Hardware y Software
Equipo de despliegue
Fase de inception / Fase de desarrollo
Especialista de Base de datos
Equipo de despliegue
Fase de inception / Fase de desarrollo
Diseñador Web
Equipo de desarrollo
Fase de desarrollo
Analista programador
Equipo de desarrollo
Fase de desarrollo
Analista programador - BI
Equipo de desarrollo
Fase de desarrollo
Analista de Sistemas
Equipo de desarrollo
Fase de desarrollo
Analista de Control de Calidad
Equipo de desarrollo
Fase de desarrollo / Grupo de testing
Documentador
Equipo de desarrollo
Fase de desarrollo
Analista de gestión de incidentes
Equipo de desarrollo
Fase de retroalimentación
Durante la etapa preoperativa, Inetum se compromete a afinar las relaciones de perfiles y roles en
base al análisis a ser realizado en dicha etapa en conjunto con el equipo de la CGR.
3.3.1 Metodología de desarrollo ágil
La adopción de una metodología ágil implica cambios e introducción de nuevos elementos
(componentes técnicos, operativos y roles profesiones) en la prestación de los servicios. Por ello, se
plantea una estrategia global que permita abordar los aspectos funcionales orientándose a la entrega
de valor (producto mínimo viable) y mejora continua.
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Ciclo de vida del software, fila 16. Se incluye la relación entre perfiles (recursos) y roles propios de la
metodología propuesta para cada componente del servicio indicados en el TdR.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
48 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
La selección/priorización de requerimientos resultado de la fase de Inception se realizará de forma
periódica y programada e independiente del desarrollo de la solución que se encuentre en curso. El
resultado de este proceso será una planificación a alto nivel con una propuesta de alcance para las
entregas más próximas (Release Plan)
Es evidente que, dada la limitación de tamaño de esta propuesta no es posible detallar todos y cada
uno los aspectos, pero si creemos que es relevante destacar y resumir los más importantes:
3.3.1.1 Estrategia Inicial
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
49 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
El desarrollo se llevará a cabo a través de iteraciones (Sprints) de 1 a 4 semanas de duración a partir
de una lista de funcionalidades priorizadas en el Inception a través del Backlog de Producto. Los
objetivos de este enfoque son:




Desarrollo del sistema cumpliendo los requisitos funcionales, no funcionales y de calidad
establecidos
Adecuación a las restricciones de esfuerzo y plazo acordadas (estimaciones)
Inclusión de acciones de mejora continua en el ámbito del proyecto.
Parámetros para el seguimiento y control de la ejecución de cada sprint (calidad, plazo y
coste).
Cuando se pidan cambios durante un sprint en curso:


Se podrá canjear la funcionalidad a incluir por otra actividad equivalente del backlog
Se agregará al sprint la funcionalidad requerida y se modificará el objetivo de la entrega
(fecha)
3.3.1.2 Roles
* Los roles y artefactos/entregables serán revisados y confirmados en la Fase PreOperativa de mutuo acuerdo entre ambas partes.
Los roles más importantes son:



Stakeholders, entre los que destacan los usuarios de negocio del CGR. Ellos son los que
conocen el negocio y definen las historias de usuario que es necesario implementar. Para ello
establecen requerimientos funcionales y operativos para las aplicaciones que dan cobertura
a su actividad, y verifican en cada entrega que el resultado es el esperado.
Product owner, que es el responsable del producto, entendiendo por producto cada una de
las aplicaciones. Es un perfil con conocimiento del negocio con capacidad y autoridad para
tomar decisiones y conocimiento funcional de los sistemas existentes, así como de los nuevos
sistemas a desarrollar.
o Es el responsable de transmitir la visión global y necesidades del proyecto y de
gestionar las necesidades funcionales con el resto de Stakeholders del CGR,
priorizarlas en el Product Backlog, y de manera conjunta con el equipo planificar y
desarrollar en función de la mayor prioridad.
o Es también el responsable de maximizar el valor de producto a través de la
colaboración cercana con los usuarios finales y la gestión del backlog mientras
participa durante el desarrollo de las peticiones de servicio dentro del equipo agile.
o Este rol lo ideal es que sea asumido por el CGR, pero en un servicio tan
grande como es éste, lo puede asumir Inetum con los perfiles de analista de
sistemas del equipo clave.
Scrum Master. Es el rol responsable de que se vivan los principios y valores de Scrum y
que este se ejecute correctamente durante el desarrollo y por tanto se asegura y ayuda al
equipo para que apliquen de manera correcta el framework de trabajo agile. Este rol lo
puede asumir Inetum con los perfiles de analista de sistemas o líderes técnicos del
equipo de proyecto.
[3] De acuerdo a la absolución de la Sesión Técnica 1 – Ciclo de vida de software, fila 11. Se precisa, de acuerdo con el numeral 7 del TdR, la lista de roles
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
50 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
3.3.1.3 Artefactos o Entregables
En conformidad con el numeral 7 de los TdR, la lista de artefactos/entregables podrá ser actualizada,
con nuevos entregables o actualizaciones, previo análisis en la Fase Pre-Operativa de mutuo acuerdo
entre las partes.[1] [2]
Los principales artefactos o entregables tendrán una revisión asociada a los Sprints, donde se
definirán las actividades de actualización y entrega. En este mismo sprint se definirá los responsables
de factoría para su implementación.
Estos entregables serán complementarios a los mencionados y definidos en el punto 4.1 Fases del
Servicio donde se encuentran los entregables requeridos por cada fase de acuerdo con solicitud del
TdR. Estos son los entregables por tipo que se propone implantar como parte del nuevo framework
de trabajo son: [3]
Asociados a la Metodología
Metodología de Gestión de Proyecto
Donde se detalla el procedimiento general atendido con la gestión del
proyecto para las áreas de proceso a continuación: gestión de alcance,
tiempos, recursos, comunicación y stakeholders.
Metodología de Análisis y Desarrollo de SW
Donde se detalla el procedimiento desde la identificación del requerimiento
pasando por su implementación en Producción y estabilización.
Metodología de Pruebas de SW
Donde se detalla el procedimiento para el ciclo de pruebas, desde la definición
de alcance hasta su aceptación y conformidad.
Metodología de Desarrollo de Datamarts
Donde se detalla el procedimiento desde la identificación del Datamart
pasando por su implementación en Producción y estabilización.
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Gestión del Proyecto, fila 6. Se precisa, de acuerdo con el numeral 7 del TdR, que la lista de entregables
podrá ser actualizada en la Fase Pre-Operativa según el análisis correspondiente, con nuevos entregables que se identifiquen o actualización de los existentes.
[2] De acuerdo a la absolución de la Sesión Técnica 1 – Ciclo de vida de software, fila 11. Se precisa, de acuerdo con el numeral 7 del TdR, la lista de entregables
podrá ser actualizada en la Fase Pre-Operativa según el análisis correspondiente, con nuevos entregables que se identifiquen o actualización de los existentes.
[3] De acuerdo a la absolución de la Sesión Técnica 1 – Ciclo de vida de software, fila 17. Se lista, a solicitud de la CGR, la lista de documentos de la metodología
propuesta.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
51 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Asociados a la solución técnica
Especificación de Arquitectura SW
Donde se detallan las configuraciones, los componentes y su vistas
técnicas de implementación
Especificación de BD
Donde se detallan las configuraciones, el modelo y diccionario de los
objetos de base de datos para sus propiedades o parámetros.
Especificación de Datamarts
Donde se detallan las configuraciones, modelo de los objetos,
integraciones, vistas y reportes.
Especificación DevSecOps
Donde se detallan los roles, las configuraciones principales del pipeline
de automatización, sus estaciones, herramientas y/o componentes
integrados.
Código Fuente de SW
Solución de proyectos, clases y otros con contenido de programación.
También puede contener las imágenes de contenedores.
Código Fuente de Automatización
Solución de proyectos y/o scripts de automatización vinculados a los
tipos pruebas o complementos DevSecOps
Guía de despliegue
Donde se detallan la estrategia, configuraciones y los pasos para la
entrega en ambientes de la solución
Asociados a la calidad
Plan de Aseguramiento de Calidad
Donde se explica la estrategia integral de calidad en las
diferentes áreas de proceso del proyecto
Plan de Pruebas de Software
Donde se explica la estrategia y táctica utilizadas para los
diferentes tipos de prueba de los componentes de SW.
Casos de Prueba
Donde se describen los pasos seguidos para cada escenario
de prueba según su tipo.
Bitácora de Observaciones
Lista descriptiva de las observaciones y su tipología
resultante de la ejecución de los casos de prueba.
Evidencias de Pruebas
Capturas de pantallas o datos que respalden el resultado de
una prueba ejecutada.
Set de Datos de Pruebas
Scripts de construcción o preparación de datos de pruebas o
archivos con registros de datos para fines de pruebas.
3.3.1.4 Eventos
Los principales eventos necesarios para la producción de servicios en agile son:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
52 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Finalmente, respecto de la implantación del modelo agile, proponemos dos acciones clave:


Inception del modelo. Sesión de trabajo en la que un coach agile de Inetum explicará al
responsable del servicio y jefes de área del CGR el detalle de todo el modelo y se trabajará
para su adecuación a la situación real del servicio. Se propone planificar esta sesión una vez
haya finalizado la fase de estabilización del servicio (preoperativa).
Inetum dispone de Jira como herramienta de gobierno de todo este modelo, en la que están
perfectamente parametrizados todos los artefactos y eventos y que se propone utilizar en
este servicio. Como muestra, a continuación, mostramos algunos ejemplos de estos
artefactos:
3.3.1.5 CMMI
La metodología propuesta de desarrollo para este proyecto y el modelo CMMI N3 de Inetum de
mejores prácticas para los procesos de desarrollo, son compatibles y en conjunto brindan una
disciplina de cumplimiento de procesos, entregables, así como medición para la mejora continua.
Esto sin afectar la rapidez, y principios de la agilidad y a la vez en cumplimiento de los procesos
básicos del CMMI N3 de Gestión de Proyectos Integrada (IPM por sus siglas en inglés) y Análisis de
Decisión y Resolución (DAR por sus siglas en inglés), y Medición y Análisis (MA por sus siglas en
inglés).
Asimismo, Inetum por medio de su área de Gestión de Calidad y Seguridad de Procesos institucional
hará una inspección semestral al proyecto para identificar el nivel de cumplimiento de nuestro modelo
metodológico propuesto versus el implementado. Como resultado, se emitirá a CGR un informe de
los hallazgos y nivel de cumplimiento a la fecha contrastado con las prácticas CMMI-DEV a seguir.[1]
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Ciclo de vida del software, fila 14. Se precisa, de acuerdo con el numeral 5 del TdR y los objetivos
específicos de la CGR, que Inetum garantizará una inspección semestral al proyecto para identificar el nivel de cumplimiento del CMMI.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
53 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
3.3.2 Entorno de Integración Continua
Adicionalmente, se propone la implementación de un entorno de integración continua para cada
aplicación java, similar al que tenemos en nuestras factorías, dando un gran resultado. Nuestro
esquema inicial propuesto parte de la definición de un pipeline objetivo para la automatización de
las fases del ciclo de desarrollo como se muestra a continuación:[1]
Sobre este se elabora una especificación DevSecOps que posteriormente se traslada a compromisos
de implementación en los requerimientos canalizados a factoría. Este pipeline consta del siguiente
stack sugerido de herramientas:
Este entorno, nos aportará todas las ventajas de aplicar la integración continua, especialmente:


Todas las posibles violaciones de normas de calidad de código le saltarán al desarrollador de
forma automática en su IDE de desarrollo, lo que garantiza que se corrijan de forma
inmediata y no progresen a fases posteriores.
Todas las noches lanzaremos una consolidación del software y un despliegue
nocturno, en el que además de probar que es compilable y desplegable, se pueden
lanzar las pruebas automatizadas.
[1] De acuerdo a la absolución de la Sesión Técnica 3 – Enfoque de Innovación, fila 13 y a la sección Estrategias de Integración y Despliegue en la Infraestructura
de la CGR, fila 25. Se precisa, a solicitud de la CGR, la integración con otros sistemas y componentes de software de la CGR mediante el entorno de integración
continua.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
54 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS

Visibilidad de la situación y porcentaje de avance sobre la automatización del proyecto
comparando las estaciones del pipeline automatizadas versus el total de estaciones definido
en su especificación para el alcance del proyecto.
Otro software cuyos requerimientos se identifiquen como producto de la necesidad del servicio
brindado o integraciones requeridas que permitan cumplir los objetivos del proyecto serán analizados
e implementados de acuerdo a aprobación entre Inetum y CGR para que sean incluidos dentro del
alcance de herramientas del entorno de integración continua.[1]
Finalmente, es importante indicar que tanto Jira como Confluence estarán licenciados bajo
un esquema de suscripción SaaS. Además, el entorno de desarrollo que proponemos para
el resto de herramientas a utilizar, en caso de que el CGR opte por esta propuesta de
metodología ágil para el desarrollo del proyecto, sería el entorno virtualizado del CGR. Por
tanto, en el servidor virtualizado del CGR instalaremos y configuraremos el resto de las
herramientas acordadas.
3.3.3 Enmascaramiento de Datos
Existen diferentes rutinas de enmascaramiento de datos que se utilizan para distintos propósitos.
Estas rutinas de enmascaramiento se diferencian en el grado de exposición de los datos y la cantidad
de control que mantenemos.
Enmascaramiento ligero en bases de datos de corrección de errores: para ser eficaz, el
enmascaramiento ligero en corrección de errores debe tener el menor número de cambios posible.
Los elementos que se pueden enmascarar de manera segura en una base de datos de corrección de
errores incluyen cuentas bancarias o tarjetas de crédito. En general, cualquier información opaca
que sólo interesa a una organización externa puede ser enmascarada en estas circunstancias.
Enmascaramiento medio en bases de datos de desarrollo interno: las bases de datos que son
utilizados por los departamentos para desarrollo, prueba y formación interna y que no tienen la
visibilidad fuera de la organización reciben un nivel medio de enmascaramiento. Elementos como la
información de identificación personal en bases de datos o los datos sensibles como números de
cuentas bancarias son viables para un enmascaramiento de nivel medio.
Enmascaramiento completo en bases de datos que se externalizan: cuando el control operativo de
las bases de datos de prueba y desarrollo se entrega a terceros, entonces se requiere un
enmascaramiento completo de los datos. En estos casos sólo la información en tiempo real debe
transmitirse al personal remoto para realizar su trabajo.
Técnicas de enmascaramiento de datos

Sustitución: Esta técnica de enmascaramiento consiste en reemplazar al azar el contenido
de una columna de datos con información que parece similar pero que en realidad no tiene
relación alguna con la información real. La sustitución es muy eficaz en términos de preservar
la apariencia de los datos. La desventaja es que necesitas un gran almacén de información
sustituible para cada columna que debe ser sustituida.

Shuffling o barajado de datos: Esta técnica de enmascaramiento utiliza los datos
existentes como su propio conjunto de datos de sustitución y baraja los datos de tal manera
que los registros del conjunto de datos no revelan detalles protegidas. El Shuffling es similar
a la sustitución, excepto que los datos de sustitución se derivan de la propia columna.

Número y varianza de datos: La técnica del número y varianza de datos modifica cada
número o valor de una columna por un porcentaje aleatorio de su valor real. Esta técnica es
útil sólo para datos numéricos y de fecha. Por ejemplo, el campo de fecha se podría convertir
simplemente cambiando la zona horaria, creando así una diferencia en el significado de los
datos. Ofrece la ventaja de proporcionar un disfraz razonable para los datos, mientras se
mantiene el rango y la distribución de los valores en la columna dentro de los límites
existentes.
[1] De acuerdo a la absolución de la Sesión Técnica 3 – Estrategias de Integración y Despliegue en la Infraestructura de la CGR, fila 27, Se precisa, a solicitud de
la CGR, que Inetum se comprometa a implementar "Otro software cuyos requerimientos se identifiquen como producto del servicio brindado o integraciones que
permitan cumplir los objetivos del servicio".
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
55 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS

Encriptación: Esta es una técnica simple y frecuentemente usada para alterar los datos
estadísticamente dándole un aspecto realista. Esta técnica de enmascaramiento deforma los
datos y también hace que sean más largos. Para que vuelvan a ser útiles, los datos se tienen
que desencriptar, revelando su significado original. Esta técnica de enmascaramiento ofrece
la opción de dejar los datos en un lugar visible a las personas que tengan la clave de
desencriptación correspondiente sin dejar de ser inútil a cualquiera sin la clave. Sin embargo,
es una de las técnicas menos útiles para bases de datos de prueba anónimas.

Truncamiento: Esta es una de las mejores técnicas, y tiene la ventaja adicional de hacer el
sistema más sofisticado y capaz. El truncamiento simplemente elimina los datos sensibles y
retiene la estructura de datos significativa. Sin embargo, desde un punto de vista de una
base de datos de testeo, es una de las menos deseables técnicas utilizadas para el
enmascaramiento de datos. Eliminar columnas o reemplazar valores con nulos no es una
estrategia útil para los equipos de testeo que tienen que trabajar con datos lo más reales
posible.

Enmascaramiento de salida: Enmascaramiento implica anonimato de datos cuando ciertos
campos se enmascaran con un carácter de máscara (digamos una X). Esta técnica no permite
que nada se pueda deducir de la base de datos ya que el contenido de los datos se disfraza
mientras conserva su apariencia y sentido. Es rápida y potente sólo si los datos son
específicos e invariables. En otros casos se convierte en un proceso complejo y lento.

Enmascaramiento selectivo: Esta técnica de enmascaramiento aplica operaciones de
enmascaramiento sobre una muestra de datos de la tabla. Las filas de la muestra deben ser
recuperados al azar de todo el contenido de la tabla.
3.3.4 Modelo de pruebas funcionales y aceptación
Las pruebas funcionales son el principal elemento del plan de calidad para garantizar la adecuación
de los servicios. Por eso Inetum propone un modelo de pruebas funcionales basado en los siguientes
principios:
De acuerdo a estas premisas, la automatización de los casos de prueba se identifica como elemento
clave de mejora del servicio y, aplicado específicamente al ámbito de pruebas funcionales, la
automatización será el pilar que permita disponer de un proceso de testing sólido que
garantice el éxito de cualquier proceso de cambio y modernización de aplicaciones asegurando
además la continuidad del servicio de mantenimiento y evolución de la versión que se encuentre en
ese momento en producción.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
56 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Cumpliendo con lo expuesto, se propone el siguiente enfoque para abordar las pruebas funcionales:
Este modelo, basado en la automatización, permitirá:

Disponer de un registro de pruebas automatizadas completo que podrá ejecutarse
en distintos entornos, garantizando que las pruebas que se pasan son las mismas en todos
ellos.

La ejecución se realizará, en los distintos entornos, con las mismas pautas de información
de entrada/salida y bajo los mismos criterios de resultado esperado. Esto permitirá
realizar comparativas entre los resultados obtenidos sobre el código original (en
funcionamiento en producción y bajo el servicio de mantenimiento y evolución) y el código
sobre el que se estén realizando las acciones de modernización.

Al disponer de las pruebas automatizadas, se podrán ejecutar tantos ciclos de prueba
como se consideré necesarios, esto supone que, por ejemplo, tras las correcciones
realizadas, podrán volverse a lanzar todas las pruebas funcionales identificadas como
necesarias (especialmente las pruebas de regresión), y no solo aquellas directamente
relacionadas con los cambios. Esto aporta mayor garantía de que los cambios no han
afectado ninguna funcionalidad

El modelo establecido, incluye, en el último paso, los mecanismos que permitirán analizar
cada ejecución realizada de cara a identificar los puntos de mejora del proceso y las buenas
prácticas que retroalimentarán la mejora continua de todo el procedimiento.

Las pruebas automatizadas podrán ser ejecutadas tanto por el equipo del servicio base, en
la fase de aceptación, como por el equipo de QA del servicio a demanda, permitiendo la
realización de un testing temprano que aumente la calidad del software entregado en
primera instancia.
3.3.4.1 Identificación del Plan de Pruebas Funcionales
La primera tarea a realizar será la identificación, por parte del equipo del servicio base, de las pruebas
funcionales a realizar, de acuerdo a los elementos de software, procesos funcionales y/o servicios
que puedan estar impactados por las modificaciones realizadas y cuya funcionalidad debe ser
comprobada.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
57 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
En base a esta identificación inicial, se establecerán los planes de prueba a ejecutar que estarán
compuestos por:

Pruebas funcionales específicas contenidas en el plan de pruebas para la verificación del
desarrollo realizado que ya hayan sido automatizadas en algún otro momento.

Pruebas funcionales específicas adicionales necesarias para la verificación de los
cambios realizados para garantizar que la funcionalidad no cambia tras el proceso de
modernización, serán, por tanto, casos no automatizados.

Pruebas de regresión ya definidas y automatizadas, que deban ejecutarse para verificar
que no se ha producido pérdida de funcionalidad en ningún punto de la aplicación. En este
punto se podrá determinar la ejecución total de los planes de regresión de la aplicación
modificada, la ejecución parcial de determinadas funcionalidades e incluso la ejecución de
pruebas+ regresivas de otras aplicaciones que pudieran verse afectadas indirectamente por
los cambios.

Pruebas de regresión adicionales no contempladas en los planes de pruebas regresivas
definidos y por tanto no automatizadas.
Como resultado de este ejercicio se obtendrán la versión completa del plan o planes de pruebas
funcionales a ejecutar, así como la identificación de si estás se encuentran automatizadas o no.
3.3.4.2 Juegos de Datos para Pruebas y Criterios de Aceptación
Una vez establecidos los planes de pruebas se realizará el análisis de los casos de prueba incluidos
con el fin de determinar la información que se precisa para la ejecución de los mismos, así como los
resultados esperados y los criterios que permitirán dar por válida la ejecución.
Esta información será de utilidad para establecer criterios de ejecución y resultados únicos que
permitan comparar las ejecuciones sobre el código original y el código tras los cambios, y para
facilitar la automatización de aquellos casos de pruebas que proceda.
3.3.4.3 Automatización
Una vez determinados los planes de prueba a ejecutar, los juegos de datos base y los criterios de
aceptación, se realizará el análisis de los casos de uso a ejecutar que no estén aún automatizados
para evaluar si procede o no su automatización, de acuerdo los criterios siguientes:




Viabilidad técnica de la automatización.
Criticidad del caso de uso.
Evaluación coste/beneficio de la automatización versus la ejecución manual.
Otras consideraciones.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
58 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
De acuerdo al resultado del análisis, para todos los casos de prueba para los que se determine la
viabilidad se procederá a la realizar la automatización en las siguientes fases:

Fase de Diseño. Análisis detallado desde el que se obtendrá un entregable que definirá a
alto nivel el diseño del script a crear y el conjunto de datos de prueba necesarios.

Fase de Construcción (scripting). Desarrollo del guion y scripts necesarios para
automatizar el caso de prueba. Este guion será ejecutado en los entornos de desarrollo
asegurando su correcto funcionamiento tanto en escenarios de prueba positivos y negativos.
También se proveerán los datos de prueba.

Fase de testeo. Los scripts de testeo son desplegados en la plataforma de testing y pasan
a estar operativos para su uso por los equipos del servicio. El producto pasa a formar parte
del ecosistema del CGR y se sigue el ciclo de vida del software habitual.

Fase de medición y análisis. En la última fase se mide y analiza los resultados con el
objetivo de asegurar la conveniencia de los escenarios implementados y estrategias
consideradas.
Las tareas de análisis y preparación serán llevadas a cabo por el equipo del servicio base y se
generará una petición de trabajo al servicio a demanda para la automatización del caso de prueba.
Una vez finalizado, podrá proceder a su testeo, en base al plan y juego de pruebas suministrado por
el equipo del servicio base. Lógicamente para ello se propone utilizar la herramienta para la
automatización de pruebas. Finalizado el proceso de automatización, ya estará disponible el caso de
prueba para todos los equipos que requieran su ejecución (equipos del servicio base, equipos del
servicio a demanda o incluso los equipos de explotación del CGR), pudiendo realizar pruebas
funcionales, de integración o de regresión, sobre los entornos que se determine y tantas veces como
sea necesario.
La implantación de entornos de integración continua facilita enormemente el lanzamiento de las
pruebas automatizadas, simplemente mediante Jobs de Jenkins, llegando incluso a ejecutarlas cada
noche en un proceso de construcción continua de software.
3.3.4.4 Verificación de Ejecuciones y Validación
Tras la ejecución de los planes de pruebas, se procederá a la comprobación y análisis de los
resultados obtenidos.
Para poder llevar a cabo una correcta validación de las pruebas ejecutadas, será imprescindible
disponer de una ejecución similar de los mismos planes de prueba, en un entorno en el que se
encuentre el código de la versión vigente en producción en ese momento. De acuerdo a lo definido
como resultados esperados y criterios de aceptación:
Se evaluará el resultado de las pruebas, recopiando las evidencias de la ejecución necesarias.
Se realizará la comparativa de los resultados obtenidos en el entorno con los cambios para
la modernización y la ejecución sobre la versión vigente.
3.3.4.5 Gestión de Incidencias y Retroalimentación
En esta última fase, el equipo responsable de la realización de las pruebas llevará a cabo el análisis
de incidencias y errores registrados tras la ejecución, tanto automatizadas como las ejecutadas
manualmente.
En el caso de que la ejecución esté dentro del proceso de testing llevado a cabo por el equipo del
servicio a demanda en la fase de desarrollo, se tratarán los errores, realizando las correcciones
procedentes y el despliegue del código corregido en el entorno correspondiente.
En el caso de errores detectados en la ejecución de las pruebas de aceptación de la entrega software,
el equipo del servicio base analizará los resultados y si se trata de defectos en la entrega
se encargará de la gestión y priorización de la resolución con el equipo de desarrollo
correspondiente.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
59 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Una vez resuelto el problema y realizado el despliegue en entornos previos o bien la nueva
entrega, para la aceptación, se procederá a la repetición de las pruebas con el lanzamiento
de la ejecución de los escenarios E2E definidos que garantizará, además de la verificación de la
resolución del error especifico que el resto de las funcionalidades no se han visto afectadas por los
cambios realizados en la nueva entrega.
Una vez finalizado todo el proceso, dentro del marco de mejora continua, se utilizarán los
datos obtenidos para alimentar las buenas prácticas y evaluar la necesidad de acciones
correctoras o de mejora, no solo del código de las aplicaciones, si no de los propios procedimientos
del modelo de pruebas funcionales.
3.4 Gestión Operativa del Proyecto
3.4.1 Plataforma de Gestión
Inetum asume la utilización de su herramienta Jira propuesta para la gestión de la demanda,
cálculo de indicadores con soporte en MS Excel y PowerBI para la facturación y en general como
soporte de todos los datos necesarios para el reporting del servicio. No obstante, Inetum cuenta
desde hace años con un modelo de procesos implementado sobre Jira Project y Service Desk alineado
en CMMI DEV y CMMI SVC para la prestación de Servicios de Desarrollo Gestionado, que
unifican tanto los procesos de desarrollo como de servicios TI bajo un marco común del modelo
CMMI.
Inetum dispone de esta suite de herramientas para la operativa, seguimiento y control de
los Servicios de Desarrollo Gestionado en sus factorías de software y en múltiples de sus clientes.
Esta suite de herramientas ofrece un entorno unificado y perfectamente integrado entre sus distintos
componentes, que permite la aplicación de distintos modelos operativos de servicio: helpdesk,
incidentes, peticiones de nuevos servicios, etc.
Inetum ofrece a la CGR la implantación y utilización de sus herramientas de seguimiento y control
para la prestación del Servicio, dejando claro que, en caso de ser adjudicataria, Inetum es totalmente
flexible para utilizar estas herramientas o las que la CGR proporcione para el servicio. Las horas de
participación del personal adicional de parte de Inetum para el éxito del proyecto no serán
contabilizadas o descontadas de las horas materia del presente servicio.[1]
El software de gestión, tal como el de administración de requerimientos y de gestión del proyecto
considerará la integración con componentes de la CGR, tales como: base de datos, directorio activo.
Asimismo, la configuración del software de gestión debe ser acorde a la necesidad de la CGR.
Adicionalmente, cualquier componente o licencia necesaria para la integración con el directorio activo
deberá ser adquirida por la Firma a nombre de la CGR.
3.4.1.1 Acerca de Jira
Inetum utiliza como estándar la herramienta Jira para la gestión del ciclo de vida de
desarrollo en servicios similares, dado que esta herramienta proporciona un conjunto de
funcionalidades que facilitan el control y seguimiento del desarrollo, la productividad del
equipo y se integra perfectamente con otras herramientas para construcción y pruebas de
software. También permite la planificación y seguimiento de proyectos ágiles.
Toda la actividad realizada por el equipo quedará registrada en la herramienta de Jira,
tanto a nivel de información de la tarea de desarrollo, como de esfuerzo necesario. De esta
forma garantizaremos que tenemos la capacidad de realizar un reporte de servicio con
toda la información necesaria (incluido el esfuerzo dedicado para cada tarea).
El mantenimiento de la información en el día a día es responsabilidad de analistas de
sistemas y analistas programadores, entre otros, por lo que los datos de explotación del
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
60 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Gestión del Proyecto, fila 8. Se aclara, de acuerdo con lo solicitado por la CGR, que las horas de
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
participación del personal adicional que intervenga en el proyecto no serán contabilizadas por Inetum.
Jira se encuentran siempre actualizados y en cualquier momento pueden ofrecer una
imagen fiel del estado de situación de los trabajos.
Según nuestra recomendación, se tendría un proyecto definido en Jira donde se
recogerían todas las tareas de desarrollo durante la primera fase, y en la segunda fase las
tareas de evolución e incidencias de mantenimiento correctivo.
En terminología de la herramienta, el componente sería la petición que se va a
desarrollar. En cada uno de esos proyectos se definirían las tareas correspondientes a las
peticiones de desarrollo y mantenimiento. Las tareas de Jira estarán agrupadas por petición
y estarán registradas desde el primer momento en que se haga la planificación de la
petición.
Cada componente está formado por Tareas que son los diferentes módulos o trabajos en
los que se divide una petición.
En el caso del ejemplo previo, la tarea está dividida en muchas subtareas, que serían los
trabajos que se van a realizar, desde el análisis, crear EJB’s, commands, pruebas, pase a
producción, y otros.
Las tareas estarán en el apartado de Trabajo Pendiente (Backlog) hasta que sean
asignadas a una persona y se comience el trabajo. Cada tarea estará estimada y tendrá
una fecha de entrega. La persona responsable de cada tarea registrará en la herramienta
las horas dedicadas cada día, lo que permitiría hacer un seguimiento diario.
La herramienta proporciona un gráfico denominado ‘Pizarra’ en el que se puede ver en una
sola pantalla todas las tareas del proyecto y el estado en el que está cada una de ellas. La
pizarra está definida con un criterio de metodología Scrum, de forma que tiene tres
columnas para clasificar las tarjetas que recogen las tareas:


Trabajo por hacer.
Trabajo en curso.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
61 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS

Trabajo finalizado.
Con este sencillo esquema se puede controlar el conjunto del trabajo a realizar, ya que
cada persona que tiene asignada una tarea tiene la obligación de mantener su tarjeta
correctamente clasificada y de imputar las horas de trabajo dedicadas. En cada tarjeta
queda reflejado el grado de avance y el tiempo restante que le queda para finalizar y
quedan marcadas con un color diferente cuando se aproxima la fecha de finalización
prevista.
Siguiendo la metodología Scrum, la herramienta permite crear ‘Sprints’. El/la jefe/a del
proyecto puede visualizar en una sola pantalla todos los trabajos de un sprint. En un
momento dado, si es necesario, se puede cambiar una tarea de sprint sin problema.
Conclusiones/Beneficios de JIRA




Utilizando esta herramienta se puede conocer en tiempo real la relación de tareas,
el estado, el grado de avance y los tiempos dedicados a las diferentes tareas del
proyecto, tanto del backlog como del trabajo ya realizado.
El análisis de la información recogida en la herramienta permite mejorar de forma
continua la planificación del día a día y ser más eficientes a la hora de realizar
estimaciones, dado que permite conocer en todo momento las desviaciones de los
tiempos de trabajo estimados sobre los tiempos incurridos en cada tarea.
La herramienta permite conocer también la carga de trabajo actual y a futuro de
los diferentes miembros del equipo, por lo que ayuda a identificar y adelantarse,
facilitando tomar las medidas necesarias, a posibles picos o valles de trabajo.
El propio equipo de trabajo es el encargado de mantener viva la información
contenida en la herramienta, incluyendo estas acciones como una más a la hora de
realizar las peticiones o trabajar con incidencias. De esta forma, también sirve a los
propios miembros del equipo para conocer qué trabajo se ha estado realizando en
cada momento y poder realizar las imputaciones fielmente.
En resumen, Inetum considera que la utilización de esta herramienta para la gestión del
proyecto aporta un beneficio cualitativo en el servicio prestado a CGR.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
62 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
3.4.2 Gestión de la Demanda
En este apartado haremos foco en la gestión de la demanda, y especialmente, en los mecanismos
de aseguramiento de la adecuación a la demanda que son requeridos por el CGR.
El principal objetivo de la gestión de la demanda en un modelo gestionado es predecir y regular
los ciclos del servicio, adaptando la resolución a los picos de mayor exigencia para asegurar que
el servicio se sigue prestando de acuerdo con los plazos y niveles de calidad acordados con el CGR.
En consecuencia, la gestión de la demanda es una actividad crítica del Servicio, dado que es aquí
donde se relacionan todas las partes involucradas en la gestión y control de la calidad de
las peticiones, por tanto, es necesario contar con una capacidad de recursos adecuada al nivel de
servicio exigido (ANS), sobre todo en momentos donde la demanda puede ser más elevada. En
resumen, el foco principal de la gestión de la demanda es optimizar y racionalizar el uso de los
recursos garantizando el cumplimiento de ANS y de los niveles de calidad.
Para prestar el servicio de forma eficiente, Inetum implantará el siguiente esquema operativo:
El servicio base será el encargado de analizar de forme periódica una serie de inputs que identifican
la demanda, entre los que se encuentran:

Plan de trabajo anual. El objetivo de analizar este plan realizado por el CGR es disponer
de las líneas estratégicas de negocio por venir, y tener un calendario aproximado de dicho
plan que se vaya actualizando de manera periódica. Con ello se podrá anticipar la demanda
a realizar por el servicio a demanda, su ocupación y detectar posibles “huecos” donde entre
en juego la anticipación de la demanda. Se recomienda tener con negocio del CGR la cercanía
suficiente para establecer con ellos las líneas en las que se está trabajando en formato
estratégico, proponiendo para ello reuniones con una periodicidad mensual, momento que
también se aprovechará para realizar las actualizaciones necesarias al plan vigente.

Backlog de adecuación tecnológica. El plan de sistemas para la adecuación tecnológica
de los sistemas y las migraciones por obsolescencia. En coordinación con los grupos de
producción e innovación, se identificará aquella demanda generada de la evolución de
versiones de componentes de las aplicaciones derivadas de pérdidas de soporte de versiones,
inclusión de nuevas funcionalidades de la versión de un producto o la propuesta de mejoras
desde las áreas de innovación del CGR sobre las arquitecturas de las aplicaciones.

Backlog de perfectivos. Como parte del análisis proactivo de aplicaciones en los entornos
productivos, se obtendrán peticiones de perfectivo que repercutirán en mejoras de
estabilidad y rendimiento en producción.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
63 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS

Informes de demanda y actividad. Su análisis permite la identificación de la disponibilidad
de carga de trabajo en el siguiente periodo, que podrán ser ocupadas con la demanda
anticipada.

Automatización de tareas de soporte. La automatización de tareas de soporte como parte
de los planes de mejora a implantar, además de ser en sí una posible petición de demanda,
permite disponer de mayor disponibilidad del equipo base para la generación de análisis, y
por tanto, generar peticiones para el servicio a demanda.
La gestión de la demanda se desarrolla en base a dos flujos de trabajo principales:

El primero gestiona el proceso de asignación de la petición, contando con tres fases
principales: estimación de los trabajos, gestión de plazos y cambios no previstos.

El segundo asegura la calidad del trabajo realizado por el servicio, es decir, la aceptación o
no por parte del CGR una vez resuelta la petición.
3.4.3 Estimación de los trabajos
Aplicando los procedimientos y actuaciones necesarias para realizar la estimación de los trabajos. El
sistema de estimación será una herramienta fundamental a la hora de calcular el impacto del
esfuerzo que representa en el servicio bajo demanda las nuevas iniciativas que el CGR precise
abordar. Para ello se utilizarán las herramientas determinadas por la CGR, o las ofertadas por Inetum
con aplicabilidad comprobada. El Artefacto ofertado por Inetum se encontrará anexo a este plan en
el documento Plantilla_Estimacion_INETUM_V2022.xls[1]
Una vez se ha realizado la estimación del esfuerzo que supondrá un requerimiento, se deberá traducir
dicha estimación en un alcance acotado de los trabajos, así como el impacto que tendrá en la
capacidad de los recursos que conforman el equipo. Esto se traducirá en un plazo mínimo de
resolución de la petición. Es fundamental optimizar dicho plazo mínimo, esto se realizará mediante
la selección de la ruta óptima de asignación de tareas a los recursos.
A partir de este punto se incluirá la solicitud de trabajo dentro de la planificación de los equipos
implicados y de la planificación global, permitiendo determinar el intervalo de tiempo más adecuado
para la ejecución de las tareas de las nuevas peticiones solicitadas.
Para una adecuada gestión de los plazos mediante un óptimo uso de los recursos deberá tenerse
en cuenta entre otras cosas:

Tipo del trabajo a abordar y tamaño del mismo.

Complejidad de los trabajos a realizar.

Dependencias entre tareas y equipos, con el objeto de minimizar tiempos de espera no
productivos.

Capacidad de agrupar peticiones similares o que tienen ciertas sinergias en un plazo de
tiempo determinado.

Especialización o “seniority” de recursos en ciertas tipologías de peticiones.
3.4.4 Gestión de la Línea Base
La línea base recoge el conjunto de actividades y tareas que se han de llevar a cabo de manera
habitual para cubrir las necesidades de la CGR. El modelo propuesto para gestionar la capacidad
disponible es predictivo, y se regirá por las siguientes reglas:

Revisión de la demanda en el Comité de Servicio para recabar la información de la
demanda futura, en función de la previsión de las futuras peticiones.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
64 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS

Mensualmente, se revisará y ajustará el Plan de Capacidad, a partir de la información
obtenida de los Comités de Servicio.

Mensualmente, el responsable de servicio de Inetum determinará si son necesarios
cambios a realizar en el equipo base (por ejemplo, la incorporación de nuevos perfiles o
recursos) y el momento de realizarlos. Para evitar problemas en los equipos de trabajo y
garantizar la calidad en la prestación del servicio, proponemos inicialmente limitar la
fluctuación máxima de recursos entre dos periodos de revisión a un ±10% de la línea base
20% Técnica
si el CGR
lo considera
oportuno).
[1] De acuerdo con(ampliable
la absolución deal
la Sesión
1 – Metodología
de estimación
de horas, fila 26. Se acepta, a solicitud de la CGR, la metodología para la
estimación de horas. Sin embargo, Inetum presenta su plantilla de estimación como opción y esta será evaluada por la CGR en la etapa preoperativa.
El modelo de fluctuación permite alinear las necesidades temporales “pico” de la CGR bajo las
siguientes premisas:

La CGR tendrá flexibilidad para adaptar la capacidad de los equipos de Inetum a sus
necesidades.

El CGR gozará de una base de fluctuación respecto a la línea base (LB) comprometida.

Mensualmente dispondrá una fluctuación sobre la LB de ±10% de carga de trabajo
para escenarios excepcionales o “pico”. Este rango será acordado entre las partes en el
periodo de negociación.
En el caso de que se produjesen cambios significativos sobre los servicios valorados según
la línea base, el CGR podrá solicitar la revisión de estas líneas base, así como los límites
de aplicación. Estos cambios se validarán y acordarán de buena fe entre CGR y Inetum,
comprometiéndose Inetum en dar una respuesta eficiente en el mínimo tiempo.
3.4.5 Modelo Económico
De acuerdo con lo prescrito por el pliego el modelo económico establece dos tipos de tarifa:

Tarifa Servicio Base, para todos los roles del equipo de proyecto de las fases 1 y 2

Tarifa Servicio Especial a Demanda, para trabajos fuera de horario o para horas adicionales
que no estén contempladas en el proyecto. En este último caso, se deberá acreditar la aprobación
por parte de CGR para su ejecución. En este escenario se manejará una conversión conforme a
acuerdo entre Inetum y CGR.
Según lo expuesto, en base a la estimación de horas necesarias para la resolución del requerimiento
se calculará su precio y su impacto en el consumo mensual de la Línea Base. Cabe mencionar que
todo se realizará en mantenimiento de los niveles de servicio ofrecidos por Inetum, cuyo
incumplimiento, se entiende, implicará la aplicación de penalizaciones.
3.5 Medición e indicadores
Inetum realizará las tareas de seguimiento y control necesarias para asegurar la calidad del servicio,
encaminadas a detectar tanto problemas en los desarrollos, como desviaciones que puedan surgir,
con el objetivo de tomar medidas correctoras que faciliten la resolución de problemas.
Como mecanismos para este Seguimiento y Control, Inetum preparará y presentará una serie de
informes que describirán el estado del proyecto en cada momento, así como el estado de los
desarrollos en marcha, o los trabajos previstos.
Los informes necesarios para el seguimiento de la buena marcha del servicio se fijarán entre CGR
e Inetum al principio del contrato, y se irán ajustando a nuevas necesidades siempre que sea
preciso. Estos informes no tendrán el mismo contenido durante la Fase I y el resto de Fases, puesto
que en el año 2022 nos gestionaremos como proyecto y en el 2023-2024 como un servicio.
Los informes de seguimiento del proyecto serán presentados en los Comités de Seguimiento con
la periodicidad que se defina en el Comité de Dirección (se propone mensualmente). Es
responsabilidad de Inetum producir los informes de seguimiento, incluyendo la creación de
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
65 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
herramientas o procesos que faciliten este seguimiento. Se contempla la elaboración, entre otros, de
los siguientes tipos de informes:

Informes de Seguimiento: reflejan la información relativa al seguimiento de los diferentes
servicios (Desarrollo de la Sede, Incorporación de nuevos trámites, Mantenimiento y
Plataforma de Microservicios) surgidos durante el desarrollo del contrato y en general recoge
cualquier información considerada relevante por la persona responsable del Proyecto.

Análisis de Incidencias o Problemas: se elaboran con el objetivo de recoger las
incidencias y puntos críticos surgidos durante el desarrollo del contrato y en general recoger
cualquier información considerada relevante por el Jefe de Proyecto.

Evolución de la Documentación Técnica: se elabora con el objetivo de recoger el estado
y grado de avance de la documentación englobada en el servicio.
Estos tipos de informes se obtendrán a partir de la información proporcionada por las
herramientas de gestión y seguimiento.
El Informe de Seguimiento se enviará a los participantes del comité de seguimiento al menos 48
horas antes de la hora convocada de dicho comité. El objetivo de este informe es contar con la
información suficiente para realizar la revisión de los puntos a tratar en dicho comité que permita a
los participantes tomar las decisiones correctas. El informe contendrá al menos:

Estado general del proyecto, en cuanto avance del mismo en función de sus fases. Este
avance se reportará teniendo en cuenta el porcentaje de avance de acuerdo con el plan, y
el porcentaje de avance real del proyecto en general. Para la obtención de este indicador,
Inetum se apoyará en el Cronograma del Proyecto, actualizado por el Jefe de Proyecto de
Inetum con el porcentaje de avance estimado de cada elemento.

Previsión de carga de trabajo para los siguientes 3 meses.

Facturación del mes analizado.

Gráfico del consumo del presupuesto (consumido vs disponible).

Información de la capacidad medida en horas de desarrollo teniendo en cuenta la
capacidad disponible y las horas comprometidas.

Seguimiento del plan de calidad, medición de los indicadores de calidad.

Identificación de riesgos o alertas y posibles medidas correctoras o de mitigación.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
66 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
3.5.1 Enfoque para la Determinación de Acuerdos de Nivel de Servicio
(ANS)
INETUM se compromete al cumplimiento de los indicadores planteados en esta oferta técnica, con
los siguientes condicionantes:

El grado de cumplimiento del acuerdo de nivel de servicio y los tiempos asociados se
contabilizarán a través de la herramienta de gestión de peticiones JIRA proporcionada por
INETUM, a la que tendrá acceso el equipo de trabajo.

Se asumen como tiempos indicados en los ANS (Acuerdo de nivel de servicio), los tiempos
medidos sin contabilizar los tiempos empleados en actuaciones de terceros (Ej. operadores,
mantenimiento hardware, etc.).

Se asume que todas las peticiones, incidencias y cambios se tramitan y acuerdan a través
de los responsables del servicio de CONTRALORIA e INETUM.

Se acordará con CONTRALORIA la tipificación de incidencias por los distintos equipos
implicados en el servicio.

El cierre, registro y seguimiento de las incidencias, peticiones, solicitudes de trabajo, etc.
será comunicado mediante la herramienta de gestión de peticiones establecida.

Los ANS planteados se medirán a partir de la fecha de registro en la herramienta según sea
el modelo de medición de cada ANS.

Antes de determinar el cálculo de los ANS, si existen discrepancias en los incidentes se podrá
hacer los ajustes manuales a los tiempos o a los estados, posterior a la fecha.

INETUM está exento de responsabilidad por incidentes o desviaciones en los ANS (retrasos,
etc) por causas no imputables a INETUM.

Se seleccionarán, determinarán, acotarán y formalizarán los ANS definitivos aplicables
al proyecto durante la Fase Pre-Operativa y en concordancia con la necesidad real de CGR.
siendo estos plasmados en un documento independiente "Acuerdos de Nivel de
Servicio del Proyecto". [1]
INETUM consciente de la importancia de los indicadores de nivel de servicio de cara al seguimiento
y evolución de los servicios de CGR, propone lo siguiente enfoque para determinar acciones sobre el
Acuerdo de Nivel de Servicio:

Si se detecta un deterioro en la calidad y operación del servicio que no se refleja con los
indicadores definidos, INETUM:
o Identificará los hechos y se cuantificará el impacto en el servicio.
o Realizará un Plan de Acción, en el que se revisarán los indicadores actuales, la forma de
cálculo, así como la necesidad y posibilidad de incorporar nuevos indicadores al servicio
que mejoren la regulación del proyecto.

Si los indicadores se cumplen con facilidad, INETUM:
o Comunicará la situación con el responsable del servicio.
o Planteará objetivos en base a los resultados obtenidos.

Si alguno de los indicadores se incumple de manera reiterada, INETUM:
o Comunicará al responsable del servicio un plan de cumplimiento y mejora de los
indicadores en un plazo determinado.

Si los indicadores no son claros, INETUM:
o Identificará los indicadores susceptibles de ser eliminados.
o Definirá nuevos indicadores en base a las necesidades de negocio y del servicio.
o Buscará un acuerdo de cumplimiento de los nuevos objetivos.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
67 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Gestión del Proyecto, fila 7. Se detalla, de acuerdo con el TdR numeral 7. ENTREGABLES, los indicadores
de gestión de proyectos que se obtienen con la herramienta de gestión de proyecto propuesta en la PT. Adicionalmente, se detalla a solicitud de la CGR, que el
refinamiento de los indicadores se realizará en la Fase Pre-Operativa.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
68 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
3.5.2 ANS Iniciales Propuestos
Los siguientes indicadores serán analizados y acotados durante la Fase Pre-Operativa y en
concordancia con la necesidad real de CGR siendo estos plasmados en un documento independiente
"Acuerdos de Nivel de Servicio del Proyecto durante la Fase Pre-Operativa y en concordancia con la
necesidad real de CGR siendo estos plasmados en un documento independiente "Acuerdos de Nivel
de Servicio del Proyecto
ANS relativo a la documentación contemplada en la prestación del
servicio

La frecuencia de aplicación será mensual.
Definición
Tiempo de entrega de los informes de seguimiento del servicio. Los días 12 del
siguiente, o en su defecto el día útil posterior inmediato, se revisará el informe de
seguimiento del servicio del mes que acaba de concluir.
Cálculo
Informe entregado en tiempo (S/N)
Valor Exigido
VE=100% de los informes se entregarán en <= 8 horas hábiles antes de la reunión del
comité en el que se vayan a tratar.
ANS relativo a la satisfacción de cliente con el servicio
La frecuencia de aplicación será anual. Se efectuaría cada fin de año y se armará en conjunto.
Definición
Indicador destinado a medir el índice de satisfacción de los actores participantes como
consecuencia de la prestación de los servicios objeto del pliego. En general, cada
pregunta planteada en la encuesta tendrá cinco posibles respuestas, con un valor
comprendido entre 1 (valor mínimo) y 5 (valor máximo).
Se elaborarán varios tipos de encuestas, con diferentes preguntas y respuestas en
función del grupo objetivo al que vayan dirigidas (tecnología, usuarios CONTRALORIA
en general), y una pregunta clave que determinará en gran medida la puntuación
obtenida.
Cálculo
La concreción de las encuestas, grupos objetivos y modelo de cálculo del valor final
obtenido se determinarán en el mes anterior a la realización de las encuestas.
Valor Exigido
VE=80%
La frecuencia de aplicación será mensual
Definición
Tiempo de respuesta a quejas y sugerencias sobre el servicio.
Cálculo
Total de quejas y sugerencias en medio que habilitará CONTRALORIA respondidos en
tiempo / Total de quejas y sugerencias recibidas en el período x 100
Valor Exigido
VE=100% de quejas y sugerencias se responderán en <= 5 días
ANS de soporte y gestión de usuarios
A continuación, se proponen unas definiciones para la severidad de las incidencias reportadas al
equipo de soporte. La criticidad propuesta se fundamenta en el impacto en la operativa del negocio
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
69 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
de CONTRALORIA y puede ser revisado y modificado antes de la implementación de la herramienta
de seguimiento JIRA.
Propuesta de Criticidad de Incidencias
Toda aquella interrupción o disfunción en los servicios y/o procesos que
dé lugar a una completa inoperatividad del sistema o de un módulo o
Bloqueante funcionalidad principal del mismo. También se incluyen aquellas que sin
1
llegar a la inoperatividad descrita tengan un impacto en la producción o
impidan dar adecuadamente el servicio, cuando se vean afectados un
volumen elevado de los usuarios que utilizan dicha operativa.
Alta
2
Son aquellas disfunciones que afectan a una parte de la funcionalidad,
sin que suponga la caída total del sistema o un proceso crítico, pero sí
deben ser resueltos en un periodo corto de tiempo pues no hay una
alternativa para seguir con su operativa.
Media
3
Toda aquella disfunción en los servicios y/o procesos del sistema que,
sin entrar en la categoría de crítica o alta, no suponga una interrupción
de estos pues se tiene procedimientos alternativos manuales o
automáticos para seguir con la operativa.
Baja
4
Cualquier disfunción en los servicios y/o procesos del sistema, no
contemplada en las anteriores definiciones.
Dado que la decisión de asignar un nivel de criticidad a las incidencias por parte del usuario que la
reporta, o del agente de soporte que la gestiona, conlleva un cierto grado de subjetividad, se propone
elaborar una matriz de decisión donde la combinación de ciertas variables indique objetivamente el
nivel de criticidad. En principio las variables que determinarían la criticidad serían las siguientes:




Proceso afectado.
Áreas afectadas.
Número de usuarios afectados.
Pérdida monetaria (S/N).
Los agentes de soporte dispondrán de esta matriz para determinar la criticidad de las incidencias. Se
recomienda automatizar en la herramienta de gestión JIRA la asignación de la prioridad informando
las variables anteriormente relacionadas en el alta de cada incidencia. En todo caso el agente siempre
tendría la posibilidad de modificar el grado de criticidad calculado automáticamente si su criterio es
diferente. Para seguimiento de este tipo de casuísticas se dispondría de un informe de incidencias
que mostraría aquellas en la que la asignación automática ha sido cambiada.
ANS relativos al soporte de nivel 1 y gestión de usuarios
La frecuencia de aplicación será mensual.
Definición
Atención de canales: Llamadas, chat
Porcentaje mensual de requerimientos e incidentes del canal atendidos dentro del
tiempo máximo establecido.
Cálculo
Total de requerimientos e incidentes atendidos en tiempo / Total de requerimientos e
incidentes atendidos en el periodo x 100
Valor Exigido
VE=80% de incidentes se atenderán (responderán) en <= 40 segundos
La frecuencia de aplicación será mensual, mientras se tenga el canal activo.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
70 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Definición
Atención de canales: Correo
Porcentaje mensual de requerimientos e incidentes del canal atendidos dentro del
tiempo máximo establecido.
Cálculo
Total de requerimientos e incidentes atendidos en tiempo / Total de requerimientos e
incidentes atendidos en el periodo x 100
Valor Exigido
VE=75% de requerimientos e incidentes se atenderán en <= 60 minutos
La frecuencia de aplicación será mensual.
Definición
Abandono de llamadas
Porcentaje mensual de llamadas abandonadas
Cálculo
Total de llamadas no abandonadas / Total de llamadas en el periodo x 100
Valor Exigido
VE = 90%
La frecuencia de aplicación será mensual.
Definición
Tiempo promedio de atención telefónica para incidentes
Tiempo promedio entre el momento en que termina la marcación de las llamadas y el
momento en que son atendidas
Cálculo
Total de llamadas resueltas en tiempo / Total de llamadas contestadas x 100
Valor Exigido
VE=75% de llamadas se resolverán en <= 40 minutos
La frecuencia de aplicación será mensual.
Definición
Tiempo de resolución de requerimientos.
Tiempo de resolución de una consulta, obtención de un informe o gestión de usuario
que no requiere la atención del nivel 2 o nivel 3.
Quedan fuera de la medición del ANS aquellos requerimientos cuyo tiempo de
cumplimiento no depende exclusivamente del equipo de soporte de nivel 1, como
puede ser por ejemplo la necesidad de aprobación de un alta de usuario o la obtención
de un informe mediante un proceso batch planificado.
Cálculo
Total de requerimientos resueltos en tiempo / Total de requerimientos resueltos x 100
Valor Exigido
VE=75% de requerimientos se resolverán en <= 120 minutos
La frecuencia de aplicación será mensual.
Definición
Solución de incidentes en primer nivel.
Corresponde al porcentaje de incidentes solucionados por la mesa de servicios sin
realizar escalamientos a otros niveles de soporte.
Cálculo
Total de incidentes resueltos en primer nivel 1 / Total de incidentes atendidos x 100
Valor Exigido
VE>=30% de incidentes se resolverán en el primer nivel de soporte durante el primer
año.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
71 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
VE>=35% de incidentes se resolverán en el primer nivel de soporte durante el segundo
año.
VE>=40% de incidentes se resolverán en el primer nivel de soporte durante el tercer
año.
ANS relativos al soporte de nivel 2
La frecuencia de aplicación será mensual
Nivel de Servicio
Descripción / Datos a considerar
Cumplimiento del tiempo de
resolución requerido por
CONTRALORIA.
Criticidad Aplicaciones y
Productos
Valor Exigido: 85% criticidad 1, 2, 3 y
4
Método de Cálculo
Valor resultado = Número de
tickets
de
la
criticidad
determinada
atendidos
a
tiempo / número total de
tickets
de
la
criticidad
determinada atendidos en el
período x 100. El tiempo
tomado, es el tiempo efectivo
(no se contempla bloqueantes
terceros)
Criticidad
Criticidad
Criticidad
Criticidad
1:
2:
3:
4:
4 horas
6 horas
8 horas
16 horas
ANS relativos al mantenimiento correctivo en Fábrica
(incidencias)
La frecuencia de aplicación será mensual.
Definición
Plazo de resolución de incidencias con la prioridad especificada.
El tiempo de resolución se contabiliza desde que se asigna la petición en JIRA al Nivel 3
de atención del servicio, hasta que se sube la corrección al entorno de Producción.
Cálculo
Valor resultado = Número de incidencias de la prioridad especificada resueltas en el tiempo
especificado / Total de incidencias cerradas de la prioridad especificada cerradas en el
periodo x 100
Prioridad
Bloqueante
Valor
Exigido
VE=85% de los VE=80% de los casos VE=80%
de
los VE=75% de los casos
casos se resuelven se resuelven <= 8 casos se resuelven se resuelven <= 32
<=
4
horas horas hábiles
<= 24 horas hábiles horas hábiles
naturales
Alta
Media
Baja
ANS de Proyectos
La frecuencia de aplicación será mensual.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
72 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Definición
Cumplimiento de la fecha de ejecución del plan de Proyectos
Cálculo
Valor resultado = Número de actividades planificadas ejecutadas en el periodo de
todos los proyectos / Número de actividades planificadas de todos los proyectos x
100
Por planificadas se entienden las actividades con fecha de finalización planificada
dentro del periodo considerado. Se exceptúan los casos donde la responsabilidad no
sea de Inetum, debidamente sustentados.
Valor Exigido
VE=70% de los casos
Dado el desconocimiento sobre el nivel de disponibilidad actual de las aplicaciones, no se puede fijar
un Valor Exigido, y por tanto un ANS, a estas mediciones.
ANS de Requerimientos
La frecuencia de aplicación será mensual.
Definición
Plazo de estimación de las peticiones de requerimientos
Valor = Número de requerimientos críticos estimados a tiempo / Número de
requerimientos críticos solicitados en el periodo x 100
Valor = Número de requerimientos no críticos estimados a tiempo / Número de
requerimientos no críticos solicitados en el periodo x 100
Cálculo
Se contemplan los tickets que han cursado el estado de estimación en el periodo de
evaluación.
Críticos: Tickets con Prioridad Alta.
No Critica: Prioridad Media y Baja.
Criticidad
Crítica
No crítica
Valor Exigido
VE=85% de los casos se estiman
<= 40 horas hábiles
VE=75% de los casos se estiman <= 80 horas
hábiles
La frecuencia de aplicación será mensual.
Definición
Plazo de respuesta de fecha de entrega de las peticiones de requerimientos
cuando se ha realizado la estimación de la petición
Cálculo
Valor resultado = Número de respuestas de fecha de entrega a tiempo / Número de
solicitudes de fecha de entrega en el período x 100
Valor Exigido
VE=80% de los casos se responde en <= 4 días
La frecuencia de aplicación será mensual.
Definición
Cumplimiento de la fecha de entrega de las peticiones de requerimientos
Cálculo
Valor resultado = Número de requerimientos entregados en el período / Número de
requerimientos planificados en el periodo x 100
Por entregados se entiende su entrega en el entorno de preproducción.
Por planificados se entienden los requerimientos con fecha de entrega planificada
dentro del período considerado.
Valor Exigido
VE=90% de los casos
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
73 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
La frecuencia de aplicación será mensual.
Definición
Defectos bloqueantes provocados por peticiones
implementadas por Inetum en el servicio de AMS.
de
requerimientos
Cálculo
Valor resultado = Número de defectos bloqueantes reportados en productivo tras una
semana de despliegue en el período / Número de total de defectos reportados en el
período x 100
Valor Exigido
VE=5%
La frecuencia de aplicación será mensual.
Definición
Calidad del código.
En el momento de la recepción de las aplicaciones en el servicio AMS de Inetum
mediante la herramienta definida, se medirán los valores de Complexity, Reliability,
Security y Coverage o sus equivalentes. Esta medición establecerá los niveles de
partida de calidad del código.
Estos mismos valores se volverán a medir para las aplicaciones modificadas en
mantenimiento evolutivo.
Estas mediciones estarán sujetas a la disponibilidad de las herramientas de
medición y su grado de integración con las aplicaciones a medir.
Cálculo
Dato obtenido directamente de Herramienta (parameter Complexity, Reliability,
Security y Coverage)
Valor resultado = Número de peticiones que cumplen con el VE / Número total de
peticiones x 100
Valor Exigido
VE=85% de los casos igual o mejor el valor inicial del parámetro en la aplicación.
Sobre la Medición y Control de Deuda técnica
Reafirmamos a CGR nuestro compromiso de reducción de deuda técnica en las aplicaciones del
servicio. Para ello, nos basaremos en los valores obtenidos de la herramienta SonarQube. En concreto
se obtendrán los valores relativos a Deuda Técnica del código fuente, Complexity, Reliability, Security
y Coverage. Inetum proporcionará mediante su equipo de Analistas de Calidad un archivo histórico
donde se tengan los valores obtenidos de la herramienta que permitan el análisis y plan efectivo de
mejora.
Nuestra propuesta parte de la obtención de informes periódicos durante la Fase de Ejecución del
servicio. En base a este criterio, y con el conocimiento ya adquirido sobre la aplicación,
consensuaremos con los Responsables del Servicio y Responsables de Calidad de CGR un % de
evolución anual sobre cada una de las aplicaciones, módulos o componentes.
Este % anual será objetivo de cumplimiento siempre y cuando se realicen peticiones o
requerimientos en el servicio de factoría sobre dicha aplicación. No obstante, y como parte de posible
demanda anticipada, se podrán proponer requerimientos concretos al servicio para la reducción de
la deuda técnica en aplicaciones (horas de desarrollo facturables tipificados como requerimientos no
funcionales).
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
74 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
4 Descripción del plan de trabajo,
personal de las principales
actividades, incluyendo entre
otros planes, componentes, fases
y alcances incluidos en los TDR.
4.1 Fases del Servicio
A continuación, se muestran las diferentes fases del servicio que ejecutaremos dentro de la duración
estipulada del contrato y los entrebables comprometidos conforme al TdR de CGR.

Fase Pre-Operativa: fase inicial en la que el equipo de Inetum junto con el equipo de la
CGR formalizan el comienzo del proyecto, y se elaboran y aprueban los planes de actuación
que regirán el mismo. Esta fase tendrá una duración máxima de 15 días calendario.

Fase II Ejecución del Servicio. Etapa de Implementación: fase en la que se realizan
las actividades necesarias para la Implantación del Servicio, y se ejecutan pruebas piloto
para asegurar la implantación adecuada y completa de todos los componentes que conforman
el servicio. Esta fase tendrá una duración máxima de 15 días calendario.

Fase II Ejecución del Servicio. Etapa Operativa del Servicio: con una duración de 690
días calendario, durante la cual prestaremos el servicio requerido en función de los modelos
establecidos.

Fase III Transferencia y Cierre: fase última del servicio en la que se transmitirá todo el
conocimiento adquirido durante la ejecución del contrato al equipo de la CGR, o al equipo del
proveedor que la CGR designe. Está previsto que esta etapa se desarrollará en los últimos
60 días calendario de la Fase II Ejecución del Servicio.
4.1.1 Fase Pre-Operativa del Servicio y Etapa de Implementación
Desde Inetum consideramos que podemos aportar los siguientes aceleradores que aseguren la
calidad en el modelado del servicio, tanto durante la fase Pre-Operativa como en la etapa de
Implementación del mismo:



Apoyo de perfiles especializados: además de los perfiles requeridos para el servicio,
Inetum también aportará el apoyo de consultores senior (Transition Manager) con
conocimiento diferencial en el ámbito de AMS, que aportarán su experiencia para el
aseguramiento de esta implantación en ámbitos similares al que se da en este contrato.
Uso de nuestra metodología de transición de servicios: nacida de la experiencia de
Inetum en la prestación de servicios similares en diversos proyectos y clientes locales,
regionales e internacionales.
Cercanía y flexibilidad: orientación al cliente, cercanía y flexibilidad para adaptarse al
contexto, versatilidad a la hora de abordar la asunción del conocimiento y estabilización
(secuencial o en paralelo) y modelar la prestación del servicio en función de las necesidades
de la CGR.
Inetum plantea la etapa inicial del servicio como un proyecto con un modelo de gobierno
especializado en la Transición de AMS liderado por la figura del Transition Manager, especialista
en el modelado, despliegue y gestión de servicios de mantenimiento de aplicaciones. El objetivo
básico de este proyecto es asumir la provisión del servicio con el menor riesgo operativo posible para
la CGR y dentro de los plazos comprometidos.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
75 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Cabe mencionar que la CGR proveerá a Inetum de los documentos de análisis de sistemas. Dichos
documentos serán utilizados por Inetum durante esta etapa para su posterior adecuación de los
artefactos customizados materia de la presente metodología.[1]
Este proyecto se estructura en 7 líneas de trabajo distintas que son los hilos conductores de la Fase
Pre-operativa y de la etapa de Implementación del servicio:
Sobre el Transition Manager
El equipo de trabajo contará con el apoyo de un Facilitador de Servicio (Transition Manager), que es
el responsable de darle fluidez a la ejecución del plan.
Inetum pone a disposición de la CGR un perfil senior (Senior Manager) con experiencia en la gestión
y coordinación de equipos multidisciplinarios (>50 personas) y multitecnología (SAP, WEB, .NET,
JAVA, etc.) ligados a proyectos y servicios de aplicaciones. Con orientación a resultados y con
experiencia en reporting e interlocución multi-nivel (jefaturas, gerencias y direcciones). Sólidos
conocimientos de herramientas de gestión y control. Implicación directa en FW AMS+. Experto en
diagnósticos de modelos de colaboración y modelado de servicios como el propuesto.
Actuará de facilitador durante las fases pre-operativas y de implantación del nuevo servicio y de sus
procesos operativos. Finalmente, será responsable de transmitir las bases y lineamientos para el(los)
posterior(es) facilitador(es) de servicio durante la etapa de Ejecución.
Sobre el seguimiento y control
Se llevará a cabo un control diario (daily meeting) con el equipo de Inetum y el responsable del
servicio de la CGR. Asimismo, se llevará un control semanal (o con mayor frecuencia si se considera
oportuno) con responsables tácticos de la CGR. Las actividades para realizar son:


Seguimiento: como medio para un correcto seguimiento de las dos etapas iniciales,
proponemos la utilización de un Cuadro de Mando de indicadores de seguimiento (KPI’s), que
ayudarán a medir y evaluar el grado de avance de la misma.
Comité de Seguimiento: el responsable del Servicio de Inetum informará a la CGR de
forma periódica, del avance de las fases y otros aspectos relevantes que puedan afectar al
transcurso de estas etapas. Se pondrá especial foco en revisar el avance en función del
Cuadro de Mando de seguimiento definido, detectando posibles acciones correctoras sobre
los planes en marcha.
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Estrategias para el análisis de requerimientos y definición del alcance, fila 12 y 14. Se precisa, de acuerdo
con lo solicitado por la CGR, la CGR entregará los documentos de análisis de sistemas durante la etapa preoperativa.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
76 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS

Aprobación y cierre: la CGR evaluará los entregables y los resultados de las etapas
Preoperativa y de Implementación del Servicio para proceder al inicio oficial de la etapa
Operativa.
Sobre el plan y lineamientos iniciales
La fase Pre-Operativa que proponemos a continuación tiene como referente nuestra metodología de
servicio para la Gestión de Aplicaciones AMS+ que nos permite contemplar tanto los ámbitos
operativos, como los ámbitos de gestión que establecerán los procedimientos que regirán el servicio
durante la Fase Operativa y que serán consensuados y aprobados por la CGR.
Esta propuesta se puede considerar un boceto de Plan de Transición del que se partirá para elaborar
durante la primera etapa del proyecto el Plan de Transición definitivo, consensuado y aprobado por
la CGR.
El inicio de esta fase se producirá una vez firmado el contrato, y tiene como principales objetivos los
dos siguientes:


Consensuar este plan de transición con la CGR para adaptarlo a las fechas reales e incorporar,
si es necesario, las consideraciones la CGR requiera.
Realizar el acopio de toda la información disponible, y la elaboración de los planes necesarios
para comenzar los trabajos de la fase de implementación propiamente dicha.
A continuación, mostramos nuestro plan inicial propuesto de actividades y entregables para la fase
Pre-Operativa:
Nº
Entregables
Meses
1
Fase I Pre-operativa
D-1 Revisiones con Comité de Seguimiento
D-2 Constitución del proyecto
D-3 Plan de Transición
D-4 Plan de Gestión del Proyecto
D-5 Cronograma del proyecto
D-6 Plan de Gestión de Riesgos
D-7 Modelo de Relación y Comunicación
D-8 Modelo de Reporting y Gestión Contractual
D-9 Plan de Aseguramiento y Control de Calidad
D-10 Documento con los Acuerdos de Nivel de Servicio (ANS)
D-11 Metodología para los procesos de ciclo de vida del software en base a la NTP-ISO/IEC 12207
D-12 Procedimiento de Pase a Producción
D-13 Procedimiento de Control de Versiones
D-14 Plan de Transferencia Tecnológica
D-15 Procedimiento y contenido de encuestas de satisfacción
D-16 Declaración jurada de implementación de un Sistema de Gestión de la Seguridad de la Información
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
77 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS



Revisiones con comité de seguimiento periódicas donde se revisará y aprobará el plan de
transición definitivo y toda la documentación generada en esta fase.
Primera reunión de Constitución del Proyecto como acto formal para dar comienzo al
mismo.
Plan de transición y la revisión detallada con la CGR considerando:
o
Reunión de lanzamiento del servicio, en la que se analizarán todos los aspectos del plan
de transición presentado.
o
Revisión de la estructura del equipo propuesto.
o
Revisión del plan de incorporación del equipo.
o
Incorporación en el plan de transición de las modificaciones identificadas en la revisión,
incluyendo el plan de incorporación de profesionales al equipo para adaptarlo a las
necesidades de la CGR y del servicio.
o
Cuadro de mandos de seguimiento de la etapa Pre-Operativa y de la etapa de
Implantación.

Plan de Gestión del Proyecto, con los procedimientos de gestión de la demanda y capacidad,
procedimientos de provisión del servicio, uso de las herramientas, modelo operativo completo
del servicio.

Cronograma del Proyecto, documento vivo a lo largo de la duración del proyecto con la
planificación de todas las actividades actualizada.

Plan de gestión de riesgos con una serie de riesgos a considerar en las etapas Pre-Operativa
y de Implantación para mitigar que no haya impedimentos o retrasos para la prestación del
servicio.

Plan de Gestión del Conocimiento, mayor información en sección 4.1.2.5

Modelo de Relación y Comunicación con las responsabilidades previstas para de cada uno
de los perfiles que conforman el modelo.

Modelo de Reporting y Gestión Contractual con los procedimientos, plantillas y
dashboards de seguimiento y control económico del Servicio.

Plan de Aseguramiento y Control de Calidad con las actividades orientadas a la
identificación de los estándares y procedimientos de calidad relevantes al proyecto.

Documento con los Acuerdos de Nivel de Servicio (ANS) para la medición del Servicio
prestado. Como punto de partida de tendrán en cuenta los ANS indicados en el pliego, los
cuales aceptamos en todos sus términos.

Otros entregables a elaborar por Inetum durante esta etapa serán:
o
Metodología para los procesos de ciclo de vida del software alineado al cumplimiento de
la NTP-ISO/IEC 12207.
o
Procedimiento de Pase a Producción.
o
Procedimiento de Gestión de Versiones.
o
Plan de Transferencia Tecnológica e Infraestructura.
o
Estándares iniciales para implementación de Base de Datos, Arquitectura y
Programación de Software, Datamarts y DevOps
o
Procedimiento y contenido de Encuestas de Satisfacción.
o
Declaración jurada de implementación de un Sistema de Gestión de la Seguridad de la
Información.
o
Documento propuesto de estándares de integración con otros sistemas y componentes
de software de la CGR.
o
Estructura de código fuente
o
Documento de Especificación de DevSecOps, con detalle de diagramas, roles, y
herramientas.
o
Otros documentos acordados durante esta fase con CGR.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
78 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Sobre relevamiento inicial de información del proyecto
Como punto de partida, CGR compromete a proporcionar los siguientes documentos de análisis de
sistemas que permitan agilizar el entendimiento del alcance y posteriores actividades afines:

Modelado del Proceso a nivel de explotación 1.

Reglas de Negocio.

Requerimientos Funcionales y No Funcionales.

Historias de Usuario.

Prototipos básicos.
Asimismo, estos no limitarán en ninguna forma la aplicación de la metodología de desarrollo de
software propuesta. El análisis de sistemas realizado por la CGR no descontará horas de la bolsa
contratada.
Sobre el sistema de gestión de versiones
INETUM usará un sistema de gestión de versiones para el control de los sistemas informáticos
involucrados y la actualización (requerida) de los documentos de gestión e ingeniería del Proyecto,
este procedimiento de gestión de versiones será entregado en la FASE PRE-OPERATIVA.
Para el Control de Versiones e interacción con CGR, INETUM utilizará el repositorio de versiones de
la CGR Gitlab. Inetum realizará la configuración de la herramienta en los entornos provistos por la
CGR incluyendo su integración al ciclo de vida del software. La CGR será la encargada de administrar
dicho repositorio luego de su implementación. Dicha implementación no consumirá horas de
desarrollo de la fábrica.
4.1.2 Fase II Ejecución del Servicio - Etapa de Implementación
La etapa de Implementación iniciará a la finalización de la fase Pre-Operativa, y tendrá una
duración de 15 días calendario. El principal objetivo consistirá en la puesta en marcha de los recursos
humanos, procedimentales y técnicos de Inetum, así como la puesta en marcha de los
procedimientos de trabajo, herramientas utilizadas y tareas que considere la CGR. Para acelerar el
proceso de implementación se utilizará el checklist de preparación de la implementación, un
conjunto de procedimientos y plantillas de Inetum, basadas en su amplia experiencia en este tipo de
servicios, que aceleran el proceso notablemente. Uno de los aspectos de éxito será la correcta
coordinación y participación de los distintos equipos para la puesta en marcha del Servicio que
comprenderá:





Implantación de la Gestión global del Servicio.
Implantación del modelo Operativo.
Implantación de la tecnología y entornos de Trabajo.
Seguimiento y control de proyecto.
Plan de Gestión del conocimiento.
Se iniciará la puesta en marcha del Servicio y sus operaciones con la implantación del modelo
de Servicio bajo un modelo de trabajo normalizado con procedimientos de gestión, mecanismos
de trabajo, mediciones de calidad, fiabilidad, etc., contando con el apoyo de nuestros Centros de
Servicios especializados en llevar a cabo servicios gestionados, avalados en numerosas
experiencias de éxito y por su certificación CCMI nivel 5.
Nuestra propuesta de valor para esta etapa de Implementación del Servicio conjuga una serie de
valores:[1]
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Estrategias para el análisis de requerimientos y definición del alcance, fila 15. Se detalla la fase de
implantación de acuerdo a los TdR acápite 4.1 PRESTACIONES.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
79 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS

Intangibles. Equipos contrastados de implementación formados en nuestras experiencias
en proyectos con transiciones de Servicio complejas, con un amplio volumen de sistemas de
información y organizaciones involucradas), y tecnologías análogas.

Tangibles. Basados en la metodología AMS+ de Inetum desarrollada bajo nuestra
experiencia, representando, por tanto, una garantía de rigor y eficiencia en el proceso,
adaptándola a los requerimientos y alcance de los servicios demandados por la CGR.
A continuación, mostramos nuestro plan inicial propuesto de actividades y entregables para la etapa
de Implementación:
Nº
Entregables
Meses
1
Etapa de Implantación del Servicio (Fase II Ejecución del Servicio)
D-17 Revisiones con Comité de Seguimiento
D-18 Plan y Cronograma de Implementación del Servicio
D-19 Implantación de la Gestión Global del Servicio
D-20 Implantación del Modelo Operativo
D-21 Implantación de la Tecnología y Espacio de Trabajo
D-22 Pruebas piloto de ejecución del servicio
D-23 Informe de Pruebas Piloto de ejecución
D-24 Manual de Normas y Procedimientos del Servicio
D-25 Informe de Etapa de Implantación del Servicio y cronograma actualizado con las actividades realizadas
D-26 Implantación herramienta (software) para la Gestión de Requerimientos
D-27 Implantación herramienta (software) para la Gestión del Proyecto
D-28 Declaraciones juradas del personal de aceptación de las políticas de Seguridad
4.1.2.1 Implantación de la Gestión Global del Servicio




Puesta en marcha del modelo de gestión existente: Organización, Servicios, Flujos de
Información, Metodología / Procedimientos, Estándares, Herramientas, Reporting,
Documentación, etc.
Establecimiento de los comités de seguimiento del servicio. Se revisará el Modelo de Gobierno
propuesto consensuando con la CGR los comités necesarios según el nivel de toma de
decisiones requerido, los participantes en dichos comités, y la frecuencia con la que deben
ser convocados.
Diseño del modelo y procedimientos operativos de trabajo: procedimientos para trabajar “in
situ” y en modo factorizado, procedimientos de gestión de la demanda, procedimientos para
la mejora continua, procedimientos de aseguramiento de la Calidad, procedimientos de
gestión del conocimiento y de la documentación, etc.
Formación al equipo de trabajo. Se realizará una formación de los procedimientos utilizados
para dar respuesta a los diferentes servicios del contrato. En base a estas formaciones y el
uso del propio modelo podrán ir surgiendo adecuaciones a los procedimientos.
4.1.2.2 Implantación del Modelo Operativo

Poner en marcha y, en su caso, mejorar los procedimientos de trabajo y estándares
ya existentes.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
80 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS


Implantar los mecanismos de Factorización e Industrialización de los trabajos, que
permitirán la reducción de plazos, la automatización planificada de tareas, la reducción de
errores y la facilidad del mantenimiento a las funcionalidades comprendidas en la solución
propuesta para:
o Planeamiento de los Servicios de Control (en adelante PSC)
o
Expediente Digital del Servicio de Control (eCONTROL)
o
Sistema de Seguimiento a Implementación de Recomendaciones y Situaciones
Adversas de Resultados de los Servicios de Control (SERES)
o
Datamart de fichas de control para trabajo en campo
o
Otro software cuyos requerimientos o integraciones que se identifiquen, analisen e
incluyan formalmente dentro del alcance del proyecto
Todas estas tareas de implantación del Servicio se realizarán de forma coordinada con el
montaje e implantación del modelo organizativo/operativo del Servicio abarcando los
siguientes componentes:
o
Componente de análisis de sistemas para el modelamiento de negocio y sistema de
información requerido plasmados en diagramas (Star UML y/o Bizagi)
complementarios a la especificación de los requerimientos.
o
Componente de desarrollo de software para la atención de los nuevos desarrollos,
cambios correctivos y evolutivos, y actividades complementarias de configuración y
soporte a usuarios.
o
Componente de aseguramiento y control de calidad para la atención del ciclo integral
de desarrollo y entrega de software.
o
Componente de gestión y atención de incidentes para la puesta en marcha y
operación de los módulos implementados en la solución. Este componente se
encuentra alineado a los horarios de atención requeridos por CGR.
4.1.2.3 Implantación de la Tecnología y Espacio de Trabajo.
Las tareas principales de esta actividad son las siguientes:
Disponibilidad de los espacios de trabajo para el equipo de Inetum.
Habilitar las conectividades necesarias entre las distintas ubicaciones de los equipos de
trabajo.
Configurar Oracle RAC en su versión 19 para todos los entornos de trabajo. La estrategia de
configuración será presentada durante la etapa pre-operativa.
Habilitar los perfiles de trabajo para entornos y sistemas de información: usuarios, permisos,
roles, etc.
Revisión de los elementos de seguridad necesarios.
En paralelo a todas estas actividades se irán realizando Pruebas Piloto de ejecución de los servicios
según el modelo establecido y con las herramientas seleccionadas para verificar la adecuación de los
mismos, así como la correcta comprensión de los mismos por parte del equipo de Inetum y del equipo
de la CGR.
Siendo los principales entregables a la finalización de estas tareas los siguientes:
Informe de Pruebas Piloto de ejecución.
Manual de Normas y Procedimientos del Servicio.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
81 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Informe de Etapa de Implantación del Servicio y cronograma actualizado con las actividades
realizadas.
Implantación herramienta (software) para la Gestión de Requerimientos que abarcará hasta
su entrega en Producción.
Implantación herramienta (software) para la Gestión del Proyecto.
Declaraciones juradas del personal de aceptación de las políticas de Seguridad.
4.1.2.4 Seguimiento y Control de Proyecto.
De acuerdo con el plan de actividades señaladas en el presente punto, donde se detallan los tiempos
y ocurrencia de los mismos.
4.1.2.5 Plan de Gestión del Conocimiento
La gestión del conocimiento del proyecto tiene como objetivo plasmar y gestionar el conocimiento
recibido y generado durante la prestación del servicio en dos grandes áreas de conocimiento:
•
Conocimiento de las aplicaciones, explicitado en la documentación técnica de las aplicaciones
(documentación de técnica-funcional).
•
Conocimiento generado durante la prestación del servicio (know how), relacionado con tareas
frecuentes, work-arrounds habituales, incidencias repetitivas y procedimientos de actuación
en su aparición etc. Este conocimiento no suele incorporarse en la documentación técnica de
las aplicaciones pero es fundamental para asegurar la despersonalización del conocimiento,
es decir, para que el conocimiento no esté únicamente en la “cabeza de la persona experta”,
sino que sea compartido por todo el equipo del servicio de Inetum y CGR. Este conocimiento
está relacionado a la metodología y marco de trabajo (documentación metodológicaprocedimental).[1]
Gestión de la Documentación
Documentación Técnica de Aplicaciones
La documentación técnica de las aplicaciones (requisitos, análisis funcional, diseño técnico,
entre otros) es una documentación que debe generarse y mantenerse actualizada en cada
entrega o despliegue a Producción. Las actividades iniciales serán:
o
Identificación del repositorio de documentación. Cada equipo de Inetum localizará
el repositorio de documentación técnica de las aplicaciones que estén bajo su
responsabilidad.
o
Identificación del grado de completitud. Cada equipo de Inetum evaluará el grado
de completitud y precisión de la documentación técnica respecto de las versiones de las
aplicaciones desplegadas en Producción y, en caso de existencia de diferencias,
realizarán un “gap analysis” que defina las diferencias y las necesidades de actuación
sobre ellos para garantizar su nivelado con las aplicaciones reales, de ser necesario.
Organización y gestión de la documentación
[1] De acuerdo con la absolución de la Sesión Técnica 1 – Base de Datos de Conocimiento, fila 24 y 25. Se menciona, de acuerdo con el TdR Anexo 10 las
características requeridas para este aspecto.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
82 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
La gestión de la documentación establece una estructura de partida para organizar la
información, la cual será revisada y establecida durante la Fase Preoperativa.
Se muestra a continuación un ejemplo de la estructura de partida para organizar la
información. A lo largo de la vida del servicio se realizarán las modificaciones y añadidos que
se considere necesarios, siempre de común acuerdo entre Inetum y CGR.
En “Documentación de Productos” se incluirán todos los productos incluidos en el servicio.
Herramienta de Gestión del Conocimiento
Toda la información que se genere durante la prestación del servicio debe registrarse en una
herramienta donde se haya configurada la estructura organizativa de la información para que esté
disponible para su uso. Esta herramienta además cumplirá con los procesos de gestión siguientes:
Generación de conocimiento: para la producción e incremento del conocimiento. Conjunto
de acciones e iniciativas que la CGR e Inetum implementarán para aumentar el conocimiento
del equipo de trabajo.
Codificación: Poner el conocimiento organizacional de forma tal que sea accesible a quienes
lo necesiten. Organizarlo de forma explicito, portátil y fácil de entender. Aplicando
características como:
clasificación, almacenamiento,
indexación, estandarización
documental.
Distribución: los miembros del proyecto deberán estar enterados y tener acceso al
conocimiento del proyecto y la solución de software para aplicarlo en sus trabajos.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
83 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Usabilidad: aplicarda para generar valor a la organización, al proyecto. La premisa de su
contenido debe ser el incremento del conocimiento.
Inetum propone la utilización de la herramienta Confluence para la gestión del conocimiento. En ese
sentido, Confluence contiene una serie de ventajas significativas:
• Espacios de trabajo colaborativos.
• Integración con otras herramientas como JIRA.
• Alta usabilidad.
Plan de Formación Continua del Equipo de Proyecto
Durante el tiempo de ejecución del proyecto Inetum trabajará para que el conocimiento sea
diversificado en los diferentes miembros del equipo de trabajo del proyecto, principalmente en el
ámbito funcional, de manera que se asegurará que ante la entrada de un volumen elevado de
requerimientos éstos puedan ser atendidos dentro de la capacidad total del equipo.
Esto también permite asegurar los niveles de conocimiento necesario ante situaciones de ausencia,
vacaciones o posibles modificaciones en la composición de los miembros del equipo.
Es por ello que definiremos el Plan de Formación Continua del Proyecto como una herramienta para
mantener un nivel de calidad en el servicio.
El proceso de formación seguirá siempre la misma pauta:
•
Marcar objetivos, con especial hincapié durante los primeros meses de ejecución del
proyecto, que será donde existan mayores dependencias de conocimiento.
•
Planificar la formación, en base a estos objetivos se prioriza la formación, considerando las
necesidades que pueda tener el proyecto en cada fase.
•
Realizar tareas formativas, con la ejecución de las sesiones de formación, instructivos y
acciones de formación propuestas periodicamente.
Base de datos del conocimiento (BDC)
Para poder organizarlo de una manera adecuada, consideramos que un espacio de conocimiento es
un “contenedor” estructurado de información relacionada con el servicio. Este “contenedor” permite
disponer y compartir dicha información de la manera más adecuada en cada momento, y tiene
procesos de llenado y vaciado, que se ejecutan cuando se genera nueva información o la almacenada
ya no es necesaria.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
84 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Consideramos que un recurso de conocimiento es un elemento o forma de acceder a la información
que forma parte de un espacio de conocimiento. El conjunto de espacios de conocimiento y los
recursos asociados conformarán nuestra Base de Datos de Conocimiento. Para poder ordenar nuestra
BDC debemos de realizar previamente una catalogación en distintos aspectos que planteamos a
continuación, para el ambito de este proyecto:
ORGANIZACIÓN DE LA BDC
Espacios de conocimiento
Transversales / Verticales
Si la información contenida es común la consideramos Transversal. Por ejemplo: un estándar,
un procedimiento sobre un proceso del servicio o un manual de uso de una herramienta del
servicio.
Si la información se refiere a un ámbito o sistema concreto, la consideraremos Vertical.
Públicos / Privados
Público: Si la información puede ser consultada por cualquier persona que tenga acceso al
espacio.
Privado: Si la información debe estar restringida a un grupo de usuarios.
Recursos de conocimiento
Páginas de Información
Biblioteca de Documentos
Ofrecen
la
posibilidad
de
almacenar
información de forma estructurada y controlar
el histórico de cambios realizados, así como
restaurar versiones anteriores
Estructura donde almacenar/referenciar la
documentación generada. Las diferentes
versiones e histórico de cambios deben estar
disponibles.
Contactos
Calendario, Roadmap / Release Plan
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
85 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Facilita
la
comunicación
proporcionando
mecanismos para contactar y revisar la
actividad de cada persona, y los contactos de
cada área implicada en el servicio.
Proporcionan información sobre hitos, eventos,
festivos, vacaciones y la planificación de tareas
del servicio en un diagrama de Gantt.
Noticias
Foros de discusión
Constituyen una fuente de conocimiento
importante de situaciones que se producen en
momentos puntuales (paradas de sistemas,
publicación de versiones, etc.).
Permite trabajar ideas o problemáticas de
forma colaborativa, permitiendo consensuar
soluciones con un grupo afín de expertos.
Repositorios de código fuente
Búsqueda
Almacenan el código fuente de un sistema de
forma estructurada, utilizando sistemas de
control de versiones que permitan establecer la
trazabilidad entre los diferentes cambios
acometidos en un sistema.
Elemento que permite localizar los diferentes
recursos de conocimiento almacenados en base
a diferentes criterios de búsqueda. La búsqueda
será facetada de forma que se facilite localizar
la información.
Actividad
Cuadro de Mando
Recurso que ofrece información cronológica de
la actividad reciente que ha tenido lugar en el
espacio de conocimiento, proporcionando
acceso directo a los recursos de información
generados, actualizados o sobre los que se ha
interactuado de algún modo.
Facilita la monitorización y seguimiento de la
actividad.
¿Qué herramienta sustentará la BDC?
Confluence es la herramienta que se considera idónea para sustentar la BDC. Confluence es una
herramienta que se estructura en “espacios de conocimiento”, que en nuestra implantación
asociamos a cada aplicación de forma que permita crear, capturar y compartir el conocimiento
relacionado a la solución integral de software. Es decir, cada aplicación que conforma la solución
tendrá su propio espacio en Confluence, y es en este espacio donde se incorpora toda la información
de la misma relacionada a la metodología establecida para el proyecto.
Adicionalmente, Confluence genera un modelo de trabajo colaborativo donde los miembros del
equipo de trabajo pueden interactuar sobre información y documentos de forma concurrente,
mejorando mucho la productividad a la hora de acceder y compartir el conocimiento.
4.1.2.6 Configuración Oracle RAC 19.
Inetum realizará la instalación y configuración de las base de datos, sobre la infraestructura
tecnológica que proporcionará la CGR, para los ambientes de desarrollo, capacitación, certificación
(Stand Alone) y para producción se instalará Oracle 19RAC. Asimismo, para el ambiente de
producción, Inetum realizará la configuración de la base de datos de la CGR en la modalidad de
Oracle RAC 19 considerando la buenas prácticas y estándares internacionales relacionados al servicio.
La documentación técnica de estas configuraciones será entregada a la CGR como parte de la
documentación de la puesta a producción.[1]
Inetum realizará la evaluación y diseño de la mejor propuesta con relación a la infraestructura con
la que dispone la CGR y acorde al informe de dimensionamiento de la infraestructura de hardware y
comunicaciones en al plazo definido en los TdR.
Con la finalidad de dimensionar los componentes necesarios para el despliegue de Oracle, Inetum
pone a disposición un Excel de Levantamiento de información, el cual recaba, dentro de sus
[1] De acuerdo a la absolución de la Sesión Técnica 3 – Base de datos. Se agrega la actividad de Configurar Oracle RAC en conformidad con lo solicitado en
la página 11 del TdR. La respuesta absuelve las filas 14, 15, 16.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
86 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
parámetros, la cantidad de usuarios concurrentes que ingresan a la base de datos a nivel nacional
de la CGR. Dicho documento ha sido diligenciado por la CGR, donde se detalla la siguiente información
relevada:
Servidores de base de datos ORACLE Producción – IBM Power (Servidores Virtuales)
Base de Datos de Aplicativos Informáticos con los que deberá interactuar SISCO
Ítem
S.O. y Nivel de
Tecnología
Nodos
(Instancias)
Descripción
RAC
01
6100-09-10-1731
NODO1
Base de Datos
Principal
SI
Espacio
utilizado
por BD (GB)
Producto
Versión
(BDatos)
Standard
10.2.0.2
Standard
10.2.0.2
700
02
6100-09-10-1731
NODO2
Base de Datos
Principal
SI
03
7100-05-03-1846
NODO1
BD del Sistema de
Gestión Documental
--
1600
Standard
12.1.0.1
04
7100-05-06-2028
NODO1
Reportes
--
150
Standard
12.1.0.1
05
6100-09-10-1731
NODO1
Históricos
--
7300
Standard
12.1.0.1
06
7100-05-06-2028
NODO1
Análisis de datos
--
850
Standard
12.1.0.1
Servidores Físicos de la Infraestructura Power
ID
MODELO
PRI-01
IBM Power System S924
PRI-02
IBM Power System S924
CON-01
IBM Power System S924
CON-02
IBM Power System S924
PROCESADORES/CORE
POWER9
2900 MHz
20 Cores
POWER9
2900 MHz
20 Cores
POWER9
2900 MHz
20 Cores
POWER9
2900 MHz
20 Cores
MEMORIA
512GB
512GB
512GB
512GB
Características del Storage
Almacenamiento
Marca
Modelo
Part
Number
IBM
2076-124
85Y5897
Tipo de
Conexión
N° discos
para la
solución
Tamaño y
velocidad de
discos
Nivel de
RAID de
discos
Capacidad
Actual
Espacio
utilizado
Capacidad
Máxima
FC
36
600GB y
10krpm
10
8.27TB
8.27 TB
9.27 TB
Aspectos complementarios
Usuarios Concurrentes
1000
Usuarios Nominales
2500
Conexión a sucursales
Si
Tiempo de pérdida aceptable
0
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
87 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
RPO
0
RTO
0
Replicación
Si
Escenario de Replicación
dbTwice
Lenguaje de Programación
Java 8
.Net - Framework 4.0, 4.5
Visual Fox 9.0
GeneXus 4.0
Oracle Forms 4.5
Oracle Reports 2.5
Tipo de Respaldo
RMAN a Disco
Observaciones
Ninguna
Tiempo Ejecución de Backup
8-10 horas
Software de Respaldo Integrado
Tivoli TSM
Observaciones
Actualmente, para los sistemas de
información, no hay un proceso de
carga de datos manual
Tiempo Ejecución de Backup
No aplica
Aplicaciones Relacionadas a Base
de Datos con las que Trabaja
DBLinks
IIE 7.5
IBM WebSphere 8.5 WAS y BPM
WebLogic
Payara 5
Laserfiche
Alfresco
Otros
Finalmente, con la información recabada, Inetum presentará dentro de los primeros sesenta (60)
días calendario del servicio un informe de instalación y configuración que incluirá las actividades
realizadas en este componente. Cabe resaltar que el escenario de alta disponibilidad para la
base de datos de Producción será implementado por Inetum de acuerdo al Informe de
Dimensionamiento de la Infraestructura de Hardware y Comunicaciones indicado en los
TdR (página 11) resultante de la aprobación por parte de la CGR.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
88 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
4.1.3 Fase II Ejecución del Servicio - Etapa Operativa
Tras la finalización de la etapa de Implementación del Servicio comenzará la etapa Operativa,
donde Inetum empezará a trabajar de forma activa en la coordinación de las actividades de los
servicios y en la mejora de la eficiencia de los procesos para optimizar el Servicio, de forma que se
maximicen los niveles de Servicio establecidos por la CGR.
Las principales actividades y entregables a realizar durante este periodo serían los siguientes:
Nº
Entregables
1
2
3
4
5
6
7
8
9
10
11
Meses
12
13
14
15
16
17
18
19
20
Etapa Operativa del Servicio (Fase II Ejecución del Servicio)
D-29 Gestión del Proyecto
D-30 Reuniones de coordinación
D-31 Plan y Cronograma del proyecto actualizado
D-32 Plan mensual de Ciclo de Atención
D-33 Informe de Gestión Mensual
D-34 Informe de Cierre Mensual
D-35 Definición de mecanismos y criterios de estimación
D-36 Informe de dimensionamiento de la infraestructura de hardware y comunicaciones
D-37 Configuración e instalación de los servidores de aplicaciones
D-38 Configuración de la base de datos en Producción
D-39 Informe de Instalación y Configuración
D-40 Configuración plataforma de Integración Continua y Automatización
D-41 Inception
D-42 Ejecución componente Análisis de Sistemas
D-43 Ejecución componente Desarrollo de Software
D-44 Ejecución componente Certificación de Calidad
D-45 Plan de Entregas
D-46 Implantación herramienta (software) para la Gestión de Incidencias
D-47 Ejecución componente Gestión de Incidencias
D-48 Capacitaciones y evaluaciones de los nuevos desarrollos
D-49 Repositorio de documentos de ingeniería y de gestión actualizado y digitalizado (incluyendo Mapa de red)
D-50 Encuestas de satisfacción
D-51 Sesiones de transferencia técnica al equipo de CGR
Gestión del Proyecto, siguiendo el Plan de Gestión del Proyecto previamente aprobado por
la CGR.
Plan y Cronograma del Proyecto actualizado. Durante la primera semana de cada mes
durante la etapa Operativa se realizará una actualización del Plan y Cronograma del Proyecto,
con los cambios acordados del mismo a lo largo del mes anterior. Si se considera necesario
esta actualización se podría realizar con una frecuencia mayor.
Reuniones de Coordinación dos veces al mes entre el equipo de Gestión de la CGR y el
equipo de Gestión de Inetum. Estas reuniones también pueden ser convocadas a
requerimiento de una de las partes.
Plan Mensual de Ciclo de Atención, que se elaborará y aprobará durante la primera
semana de cada mes.
También durante la primera semana de cada mes se elaborarán y entregarán a la CGR para
su aprobación el Informe de Gestión Mensual y el Informe de Cierre Mensual con los
indicadores y datos referentes al mes anterior del Servicio.
Definición de Mecanismos y Criterios de Estimación, evaluando conjuntamente el
equipo de Inetum y la CGR las diferentes alternativas y definiendo la que mejor se adapte a
las aplicaciones de la CGR. Esta actividad se realizará durante el primer mes de la etapa
Operativa.
Informe de dimensionamiento de la infraestructura de hardware y comunicaciones
que se elaborará durante las dos primeras semanas de la etapa Operativa.
Configuración e instalación de los servidores de aplicaciones y de la base de datos
en Producción, actividad que se realizará durante el primer mes de la etapa Operativa,
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
89 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
21
22
23
24
siempre y cuando el software y hardware necesario para esta instalación se encuentren
disponibles para el equipo de Inetum. Una vez finalizada esta actividad se entregará el
Informe de Instalación y Configuración a la CGR para su revisión y aprobación.
Una vez instalados los servidores de aplicaciones dará comienzo la Configuración de la
Plataforma de Integración Continua y Automatización que facilite los despliegues en
los diferentes entornos. Está prevista una duración de 2 meses para esta tarea, aunque será
necesaria una revisión periódica posterior para actualización y mejora de los procesos
inicialmente implantados.
En el primer mes de la etapa Operativa se llevará a cabo la actividad denominada Inception,
consistente en una serie de reuniones y puesta en común que debe mantener el equipo de
Inetum con el equipo de la CGR para trasladar la visión del modelo de trabajo propuesto, la
metodología a aplicar y las responsabilidades que van a tener cada uno de los roles que
intervienen en el servicio.
Durante toda la duración de la etapa Operativa se ejecutarán los componentes que son objeto
del alcance de este servicio: Componente de Análisis de Sistemas, Componente de
Desarrollo de Software y Componente de Certificación de Calidad y Componente de
Gestión de Incidencias, siguiendo la metodología y procedimientos definidos.
Durante la ejecución del servicio se determinará el Plan de Entregas idóneo según la
capacidad del servicio y las prioridades definidas. Como una primera aproximación inicial en
esta planificación consideramos que se producirán entregas trimestrales en el entorno de
Producción de los productos con el ciclo de certificación de calidad completo, y que la primera
subida a Producción se llevará a cabo en el tercer mes desde el comienzo de la fase Operativa.
Una vez subido el primer módulo al entorno de Producción comenzará la ejecución del
Componente de Gestión de Incidencias. Previo al comienzo de este componente debe
estar instalada y configurada la Herramienta de Gestión de Incidencias, este trabajo
comenzará un mes antes del comienzo en ejecución del componente.
Cada nueva entrega supondrá la realización de Capacitaciones y Evaluaciones de los
nuevos desarrollos. También se realizarán capacitaciones sobre entregas anteriores
cuando se considere necesario por la incorporación de nuevo personal, o por necesidad de
refuerzo de la formación previamente recibida.
En todo momento el equipo de Inetum mantendrá el Repositorio de documentos de ingeniería
y de gestión actualizado y digitalizado. Esta tarea también incluye la actualización del Mapa
de red en caso de que sea necesario.
Ejecución de Encuestas de Satisfacción con el Servicio. Se realizarán cada 4 meses, la
primera de ellas un mes después de la fecha de subida al entorno de Producción del primer
módulo desarrollado.
En los últimos 180 días de la etapa Operativa se planificarán las Sesiones de transferencia
técnica al equipo de la CGR sobre la solución implementada.
4.1.3.1 Fase de Estabilización (Marcha Blanca)
Esta fase se inicia al culminar la Etapa de Implantación con los elementos requeridos para una
eventual operación plena. Sin embargo, puede estar sujeta a regularización de algún punto pendiente
considerado no crítico. Asimismo, se ponen en marcha los controles de seguimiento del servicio y la
simulación de los indicadores de ANS acordados al proyecto pero que aún no estarán sujetos a
penalizaciones. Esta fase tendrá una duración de 3 meses.
Además, durante esta fase cada equipo del servicio debe:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
90 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Monitorizar activamente sus actividades asegurando que no existan elementos no solicitados
o identificados en etapas anteriores (gaps). De este modo se asegura que todo opera
correctamente.
Resolver brechas que se desprendan del punto anterior, el equipo base INETUM debe
trabajar con el equipo base de CGR para resolver también brechas en la interacción.
Completar formación sobre aquellos temas que requieran
reforzamiento mediante sesiones de repaso adicionales.
mayor
conocimiento
o
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
91 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
4.1.4 Fase III Transferencia y Cierre
El objetivo de esta etapa es asegurar una devolución del Servicio profesional, rápida y eficaz
habilitando al nuevo proveedor para prestar el Servicio proporcionado por Inetum, optimizando las
condiciones para dicha transferencia y garantizando totalmente la continuidad en la ejecución del
Servicio durante el período de devolución, y por supuesto, reduciendo al mínimo cualquier
efecto adverso en dicha devolución.
Durante la etapa de devolución del Servicio, Inetum se compromete a:
Seguir prestando los servicios con el mismo nivel de calidad, compromiso e intensidad de la
etapa Operativa del Servicio.
Facilitar toda la documentación correspondiente al Servicio prestado.
Colaborar de buena fe y realizar todos los esfuerzos necesarios para facilitar una adecuada
devolución de las actividades, a fin de evitar que se produzcan circunstancias anómalas que
pudieran alterar la devolución del Servicio.
Todos los puntos anteriores tomando en consideración el nivel de cumplimiento del 100% del
Acuerdo de Nivel de Servicio (ANS) establecidos en el contrato.
4.1.4.1 Metodología propuesta para la Transferencia y Cierre
Para el cumplimiento de los compromisos anteriormente mencionados, Inetum propone seguir un
Plan de Devolución estructurado y adaptado a las necesidades de la SGTIC que permita el
cumplimiento de los siguientes objetivos:
Guiar todo el proceso de cambio de manera consensuada con la SGTIC y el adjudicatario
entrante.
Realizar las tareas especificadas en el programa de Transferencia de conocimiento
garantizando la calidad del Servicio y asegurando el cumplimiento del ANS:
o
Suministrando toda la documentación y material necesario sobre el Servicio
y los sistemas de información que lo soportan.
o
Colaborando en todas las acciones necesarias que se definan conjuntamente
para el efectivo traspaso de responsabilidad en la prestación del Servicio al
proveedor entrante.
Ejecutar el programa de traspaso de los activos que se hayan desarrollado dentro del
Servicio y sean necesarios para la efectiva continuidad de los mismos.
Identificar a las personas más apropiadas para la realización de las labores de transferencia
de conocimiento sin merma en la calidad del Servicio. Las personas inicialmente
encargadas de realizar estas labores serán personal experimentado de cada área de Servicio.
Esta metodología de Inetum, probada y contrastada, minimiza el impacto del cambio hacia los
usuarios finales de los sistemas de información.
4.1.4.2 Plan de Transferencia y Cierre Servicio
A continuación, mostramos nuestro plan inicial propuesto de actividades y entregables para la fase
de Transferencia y Cierre:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
92 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Nº
Entregables
21
Meses
22
23
Fase III Transferencia y cierre
D-52 Informe del Procedimiento de Transferencia del Conocimiento
D-53 Transferencia del conocimiento
D-54 Actas de conformidad sobre la Transferencia del Conocimiento
D-55 Última ejecución de Pase a Producción de las Aplicaciones
D-56 Informe de etapa Operativa del servicio
D-57 Informe final del Proyecto
D-58 Entrega formal de documentos de Ingeniería actualizados
D-59 Matriz de entregables al cierre del servicio
D-60 Entrega formal de medio óptico o magnético con la documentación de Gestión e Ingeniería
D-61 Entrega formal del código fuente, scripts de base de datos y los ejecutables encargados
Informe del Procedimiento de Transferencia del Conocimiento. Se elaborará y
aprobará por parte de la CGR durante las 3 semanas previas a la fecha prevista del comienzo
de la fase de Transferencia y Cierre, detallando las medidas y actividades necesarias para
llevar a cabo la devolución del Servicio, evitando que se produzca una discontinuidad del
mismo.
Transferencia del conocimiento. Durante los 2 meses de Ejecución de la Transferencia y
Cierre, se realizará la transferencia de conocimientos, así como la ejecución de las diferentes
actividades de devolución conforme al Plan acordado por las partes. En la parte final de esta
fase, tras las actividades de captura de conocimientos y transferencia del conocimiento
mediante el desempeño de funciones paralelas en la prestación de los servicios (shadowing),
se iniciará una fase de arranque solapado donde Inetum irá cediendo gradualmente el
control de los sistemas de información y entornos funcionales.
Una vez finalizada la transferencia de conocimiento, se firmarán las Actas de Conformidad
sobre la Transferencia de Conocimiento.
En paralelo a la transferencia de conocimiento se procederá a la ejecución de los últimos
pases al entorno de Producción de las aplicaciones.
Para proceder a la entrega final y cierre del servicio se deberán realizar las siguientes
entregas:
o
Informe de la etapa Operativa del Servicio.
o
Informe final del Proyecto.
o
Entrega formal de documentos de Ingeniería actualizados.
o
Matriz de entregables al cierre del servicio.
o
Entrega formal de medio óptico o magnético con la documentación de Gestión e
Ingeniería.
o
Entrega formal del código fuente, scripts de base de datos y los ejecutables
encargados.
4.1.5 Garantía del Servicio
INETUM ofrecerá una garantía de un (01) año la cual se inicia al terminar la Fase Operativa del
Servicio. Esta garantía permitirá remediar los errores que se reporten de pase a producción de los
desarrollos y mantenimientos realizados por INETUM y/o para completar o corregir documentación
en caso haya sido observado.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
93 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
24
INETUM designará por lo menos un analista de sistemas y un analista programador, los cuales
estarán disponibles en todo momento para resolver las ocurrencias que se presenten de ser
atribuibles a INETUM. En caso de que la ocurrencia no sea atribuible a INETUM, se imputarán, de
acuerdo con el tarifario de la oferta, las horas trabajadas en el análisis de dicha ocurrencia.
INETUM garantiza que todos los servicios suministrados son de calidad, y a empleado las últimas
mejoras en cuanto a diseño y materiales. INETUM garantiza que los bienes están libres de defectos
que puedan manifestarse durante su uso normal y en las condiciones imperantes, ya sea que dichos
defectos sean el resultado de alguna acción u omisión por parte de la Firma Consultora o provengan
del diseño, los materiales o la mano de obra.[1]
[1] De acuerdo a la absolución de la Sesión Técnica 1 – Gestión del Proyecto, fila 5. Se detalla, de acuerdo con el TdR punto 19. GARANTÍA DEL SERVICIO la
vigencia de la garantía de un año.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
94 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
5 Relación del plan de trabajo con
el enfoque técnico y la
metodología.
ASPECTOS DEL PLAN
DE TRABAJO
DESCRIPCIÓN
RELACIÓN ENFOQUE TÉCNICO Y
LA METODOLOGIA
PAGINA DE
REFERENCIA
Fase Pre-operativa
Fase inicial en la que el equipo de
Inetum junto con el equipo de la
CGR formalizan el comienzo del
proyecto, y se elaboran y
aprueban los planes de actuación
que regirán el mismo. Esta fase
tendrá una duración máxima de
15 días calendario
Fase II Ejecución del
Servicio. Etapa de
Implementación
Fase en la que se realizan las
actividades necesarias para la
Implantación del Servicio, y se
ejecutan pruebas piloto para
asegurar la implantación
adecuada y completa de todos
los componentes que conforman
el servicio. Esta fase tendrá una
duración máxima de 15 días
calendario
1.2 Visión General Proyecto
2.3 Planteamiento General de la
solución
3.3 Gestión Operativa del proyecto
8/63
19/63
34/63
Fase II Ejecución del
Servicio. Etapa
Operativa del Servicio
con una duración de 690 días
calendario, durante la cual
prestaremos el servicio requerido
en función de los modelos
establecidos
2.2 Modelo de Relación proyecto
2.4 Estrategia Metodológica
3.2 Modelo de desarrollo
13/63
19/63
28/63
Fase III Transferencia
y Cierre
Fase última del servicio en la que
se transmitirá todo el
conocimiento adquirido durante
la ejecución del contrato al
equipo de la CGR, o al equipo del
proveedor que la CGR designe.
Está previsto que esta etapa se
desarrollará en los últimos 60
días calendario de la Fase II
Ejecución del Servicio.
3.3 Gestión Operativa del proyecto
34/63
1.1 Pilares de nuestra oferta
1.2 Visión General Proyecto
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
95 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
4/63
8/63
6 Propuestas de valor agregado
para innovación tecnológica y de
gestión.
6.1 Modelo de gobierno extendido con AMS+
El framework de gestión y producción de servicios de Inetum proporciona una visión global,
integrando en el perímetro del servicio a todos los stakeholders involucrados, a la vez que promueve
constantemente la mejora continua e innovación. Por tanto, como mejora del servicio, se propone
incorporar los siguientes elementos del framework:
Aspectos de mejora continua con AMS+
Uno de los pilares fundamentales de este marco de trabajo es la Mejora Continua del Servicio
(Innovation Accelerator) tanto en su gestión como en la evolución de las aplicaciones y tecnologías
que las soportan, proponiendo iniciativas de valor basadas en nuevas tecnologías y nuevos conceptos
de transformación de los servicios clásicos de AMS.
Los objetivos principales que se persiguen son:
Mejorar la gestión del servicio.
Inmersión en el Agile Outsourcing de Inetum.
Eficiencia y optimización de costes.
Innovación asegurando la continuidad del servicio.
Para identificar las acciones de mejora es necesario realizar un análisis continuo del servicio desde
distintos ejes como se muestra en la siguiente figura:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
96 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
La Voz del Cliente
Mediante diferentes técnicas, que se ejecutan con una periodicidad determinada, se obtiene
información sobre la visión de la calidad del servicio por parte del cliente, y los puntos de mejora a
priorizar. Intervienen los diferentes roles del cliente implicados en el servicio, tanto de tecnología
como usuarios finales.
Los niveles a los que proponemos evaluar “la voz” del cliente son:
1 – Encuesta de satisfacción del cliente
Global en el CGR, muestra la calidad de la relación CGRInetum.
ENCUESTA DE SATISFACCIÓN
Competencias Profesionales
Competencias Técnicas
Proactividad
Pilotaje
Escucha y Comunicación
Calidad del Delivery
Notas Ponderadas  1 = Insatisfecho … 4= Muy Satisfecho
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
97 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
2 – Valoración CDS / Kano
Permite evaluar la satisfacción del cliente en un
centro de servicio determinado, o un proyecto
significativo.
La valoración evalúa el nivel de satisfacción
tomando una cierta distancia (se es menos
sensible a los acontecimientos del día anterior).
El taller Kano permite ir más allá y comprender
con los equipos las áreas de mejora y las
expectativas fuera del contrato.
3 – Valoración del comité de seguimiento
El CGR realiza una valoración mensual, por
dominio/aplicación.
4 – Retrospectiva / Starfish project
Al final de una fase importante de un evolutivo/proyecto.
Permite identificar líneas de mejoras y elementos tratados parcialmente.
RETRO STARFISH
5 – Puntuación de usuario
En la entrega de un tícket resuelto se pide una valoración del servicio al usuario final.
Evaluación periódica del nivel de madurez industrial
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
98 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
El nivel de madurez industrial del servicio AMS se evalúa puntuando diferentes aspectos del servicio:
grado de automatización de pruebas y procesos, adopción de prácticas ágiles, grado de implantación
de procesos DevOps con despliegues automatizados, etc.
A partir de un completo checklist se obtiene la puntación de madurez para cada concepto evaluado.
El objetivo es que el nivel de madurez vaya aumentando en cada medición.
Análisis del rendimiento y KPI’s
Con la información obtenida en los informes de seguimiento del servicio en cuanto a los KPI’s de
referencia (incluyendo los que está pendiente de definir el CGR) y cumplimiento de ANS’s, se
identificarán aspectos de mejora prioritarios, sobre todo en aquellos donde se produzcan
incumplimientos de los ANS’s comprometidos por Inetum y en aquellos que se esté por debajo de
las expectativas del CGR.
Retroalimentación de colaboradores
Inetum es una compañía Lean. Un enfoque Lean apoyado e impulsado por la Dirección General de
la compañía para todos sus gerentes y gestores en el conjunto de su estructura de operaciones.
En base a esto, AMS+ se basa en un fortalecimiento del modo colaborativo dentro de los equipos de
Inetum, y entre equipos y clientes, con lo que se consigue:
Aportar más fluidez y agilidad a los proyectos.
Fortalecer las relaciones entre los actores del proyecto.
Modernizar la gestión a través de técnicas visuales y participativas.
En este sentido, la comunicación constante con los colaboradores en el servicio permitirá la
recopilación de ideas de mejora sugeridas por ellos mismos, aprovechando las reuniones diarias
internas de los equipos, o convocando periódicamente sesiones de trabajo específicas con este fin.
Innovación y automatización
Con base en la experiencia de INETUM en Performace & Transformation e Innovación planteamos el
uso de la tecnología para hacer más eficientes los procesos de gestión del servicio AMS.
Evidentemente esta transformación debe amoldarse a la estrategia de evolución tecnológica
establecida por el CGR a medio y largo plazo. El objetivo es detectar mejoras operativas y
estratégicas susceptibles de ser aplicadas.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
99 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
El objetivo de automatización será del 60% al finalizar el proyecto. Este es un indicador viable en
base a nuestras experiencias previas. Para sustentar y medir este objetivo como cumplido se tomarán
las estaciones del pipeline DevSecOps especificado para el proyecto que se encuentren
automatizadas versus el total de estaciones consideradas en su alcance (ver punto 3.3.2. Entorno
de Integración Continua). Las actividades automatizables a las que se hace mención son:[1]









Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
Pruebas
unitarias (Unit Testing)
de Calidad de Código (Code Quality & SAST)
de API / microservicios (API Testing & Performance)
funcionalidad automatizadas sobre GUI
de regresión
de compatibilidad
de seguridad
de rendimiento
sintéticas o de monitoreo de salud de la aplicación (Synthetic monitoring)
Es importante resaltar que las actividades de automatización serán especificadas o actualizadas
durante la Fase de Ejecución del proyecto y estarán sujetas a la aprobación de CGR. Será importante
la predisposición y priorización de estas actividades para lograr el objetivo propuesto por Inetum.
Para ello proponemos la celebración de comités y workshop periódicos durante toda la Fase de
Prestación del Servicio. En dichos comités participarán, además de las personas del servicio, personal
del equipo de Inetum externo al mismo con una amplia experiencia en servicios análogos de
outsourcing y oficinas técnicas y de calidad. El objetivo es detectar mejoras operativas y estratégicas
susceptibles de ser aplicadas.

Comité de Estrategia y Mejora Continua (trimestral/semestral): tendrá como objetivos
acordar estrategias en la prestación del servicio, identificar iniciativas y realizar el seguimiento
de las iniciativas relacionadas con los planes de mejora en curso.[2]

Workshops periódicos: Cubriremos la realización de 4 workshops anuales dirigidos por
expertos en áreas o aplicaciones estratégicas del servicio.
Su enfoque se basará en las propuestas de mejora que CGR considere relevantes y aplicables
como resultado de los comités mensuales que sostendremos. Es decir, a partir de nuestro
backlog de propuestas de innovación periódicas, el CGR decidirá cuál de ellas amerita ser
llevada a un workshop. Cada workshop se estima que podría tomar entre 3 a 4 horas efectivas.
El Jefe de Proyecto Inetum formalizará la programación del workshop y especialista a cargo,
así como la agenda y alcance sobre la bitácora técnica actualizada en comités de seguimiento.
El primer workshop de innovación será realizado durante el primer trimestre del
proyecto. [3]
Es importante resaltar que los workshops permitirán mostrar aspectos tecnológicos conforme
a la realidad o casuística que se recolecte en nuestras propuestas de innovación presentadas.
Algunos ejemplos de la posible temática de los workshops serían los siguientes:
o
o
o
o
o
o
o
o
o
o
Concienciación y formación en seguridad.
DevSecOps: dónde aplica y cómo aplicar la seguridad en DevOps.
Arquitectura Digital: Evangelización sobre innovación y tecnología.
Cyberseguridad extendida.
Inteligencia Artificial, motor de la transformación.
Soluciones de iOT para negocio.
QA: integración continua, entrega continua, operación continua.
API management.
Cloud: gestión de entornos, migración, nube híbrida, APIs, microservicios y
serverless.
Analítica avanzada: uso de Big Data y tecnología analítica para monitorizar y
predecir procesos claves coberturados por el servicio.
[1] De acuerdo con la absolución de la Sesión Técnica 3 – Enfoque de Innovación Fila 11. Se agrega, a solicitud de la CGR, que la automatización del ciclo de
vida del desarrollo de software, será realizada en un 60%. Sin embargo, se aclara que es responsabilidad de ambas partes lograr dicha automatización.
[2] De acuerdo con la absolución de la Sesión Técnica 3 – Enfoque de Innovación Fila 8. Se desarrolla la propuesta de innovación dentro del primer trimestre
de iniciado el servicio.
[3] De acuerdo con la absolución de la Sesión Técnica 3 – Enfoque de Innovación Fila 5. Se especifica la cantidad de los workshops y su duración.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
100 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Para el caso de las propuestas de innovación sólo serán procedentes previa aprobación del
CGR. Nuestra misión será justificar un caso de negocio y ROI plasmados en un entregable
de propuesta técnica que permita viabilizar su ejecución. Sin embargo, no genera un
compromiso u obligatoriedad de aceptación o implementación por parte del CGR. Así mismo, si el
CGR aprobase la propuesta, esta pasaría a convertirse en un requerimiento evolutivo o de nuevo
desarrollo a ser atendido por el servicio de mantenimiento en el frente de aplicación que corresponda.
Soporte de nuestros FabLab – Centros de Innovación
Inetum cuenta hoy en día con 6 Centros de Innovación, llamados FabLabs, los mismos son espacios
de trabajo dedicados a la innovación y al acompañamiento de las empresas en su transformación
digital mediante soluciones a medida.
Se trata por tanto de auténticos talleres de trabajo dentro de los cuales, los participantes contribuyen
activamente en el proceso de materialización de sus proyectos. Los clientes tocan, exploran e
interactúan con las tecnologías puestas a su disposición producto de los workshops de
innovación, para entender las ventajas y los límites que pueden proporcionarle las
propuestas técnicas recibidas. A su lado, los ingenieros e investigadores que componen el
equipo del FabLab y expositores de los workshops, aplican su experiencia tecnológica al
servicio de sus ideas durante todo el proceso. Juntos, elaboran escenarios a medida en
pruebas de concepto, demostraciones o incluso laboratorios adaptados a sus necesidades
revisadas.
6.2 Modelo maduro y automatizado de medición de
proyectos ágiles y ANS
En un servicio como el que se presenta, puede haber iniciativas que se descompongan en varias
peticiones de servicio pero que, desde la perspectiva de usuario, tenga una visión global de proyecto.
Por tanto, es importante que la información de las peticiones (obtenidas de Serena) pueda agruparse
y medirse con esta visión de conjunto para evaluar los tiempos dedicados en la línea de tiempo del
desarrollo con el objetivo de reducir el Time to Market.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
101 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Los indicadores que se proponen en el modelo de medición:
Demora en la implantación de proyectos (LEADTIME). Este indicador evalúa el tiempo
desde que una petición de desarrollo es solicitada por el CGR, hasta que la misma es
implantada en producción. Estableciendo medidas entre las diferentes fases de un proyecto,
se identificarán los tiempos de demora en cada una de estas fases, permitiendo identificar
cuellos de botella en el proceso, o demoras sistemáticas inicialmente no detectadas y que
deben ser revisadas.
Ciclo en EB (CYCLETIME). Este indicador evalúa el tiempo desde que el Equipo Base (EB)
inicia una petición de desarrollo hasta que lo da por finalizado.
Ciclo en EB-BD (TOUCHTIME). Este indicador evalúa el tiempo que una petición está en
el ámbito del EB y en el del BD, sin contar en el ámbito del CGR en tareas propias de revisión
de la calidad de los desarrollos, promoción de entonos propios etc.
La frecuencia de aplicación será mensual.La frecuencia de aplicación será mensual.La frecuencia de
aplicación será mensual, mientras se tenga el canal activo.La frecuencia de aplicación será
mensual.La frecuencia de aplicación será mensual.La frecuencia de aplicación será mensual.La
frecuencia de aplicación será mensual.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
102 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
6.3 Nueva arquitectura Java
La aparición de nuevas tecnologías está suponiendo una revolución en un entorno socioeconómico
en el que el proceso de digitalización es imparable para ciudadanos, empresas y por supuesto
administraciones públicas.
Es en este contexto de cambio en el que desde Inetum planteamos esta propuesta de mejora, como
una oportunidad de abordar un cambio que no sólo ha de ser tecnológico y centrado en la eficiencia
técnica, sino como una oportunidad para pensar en los servicios que presta el CGR en clave
digital primero, de forma que le permita integrar end-to-end la conceptualización e implementación
de los servicios, desde la solicitud, pasando por el reconocimiento del derecho hasta llegar a la
tramitación de las prestaciones e, incluso llevar a convertirse en una Administración proactiva en
todo el proceso.
Es por este motivo por el que para la definición e implantación de una nueva arquitectura para
aplicaciones java se tienen en cuenta los siguientes planos:
Plano de procesos, en el que están los funcionarios, los procesos operativos
para gestionar el día a día de las actividades de negocio, la estructura
de departamentos etc.
El plano de aplicaciones, que suele estar formado por un
conjunto de funcionalidades “verticales” que resuelven las
necesidades de cada uno de los departamentos.
El plano de las infraestructuras que soportan la
explotación de las aplicaciones y las telecomunicaciones.
Generalmente, los proyectos se abordan con una visión muy
centrada en alguna de las capas, lo que lleva a generar silos en cada
una de ellas.
Nuestra propuesta rompe con esta aproximación tradicional y, siendo
conscientes de que el proyecto se enmarca en la capa de
aplicaciones, queremos que sea una palanca de transformación, tanto
de los procesos de negocio como de las infraestructuras y es por esto por lo
que se propone una arquitectura basada en microservicios.
Para conseguir esto, se deben realizar las siguientes actividades:
Conceptualización de una arquitectura funcional de las aplicaciones del lote.
Evaluación de generalizar procesos específicos de un área dentro de procesos existentes
transversales.
Identificación de duplicidades de tareas, procesos o partes de proceso.
Identificación de procesos específicos de áreas de negocio.
Reflejo de los procesos en componentes tecnológicos (microservicios, librerías, etc.) tanto
funcionales como no funcionales, a nivel conceptual.
Una vez realizado este trabajo, tendremos una visión conceptual de la arquitectura funcional y su
reflejo en la arquitectura técnica, cuidando especialmente la reutilización de componentes para una
arquitectura eficiente. Lógicamente, este trabajo de “arquitectura funcional” no es viable realizarlo
en el ámbito del lote para todas las aplicaciones de la CGR, por lo que de común acuerdo se
seleccionará un subconjunto acotado sobre el que se pueda definir.
6.3.1 Arquitectura propuesta
Nuestra propuesta de arquitectura conceptual es la que mostramos en la siguiente ilustración:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
103 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Como puede observarse en el diagrama, proponemos una arquitectura basada en microservicios
java, estructurando los servicios en contenedores independientes que permitan un escalado y
evolución independiente. Por eso, a priori definimos los siguientes microservicios-contenedores:

Autenticación y autorización. Una de las buenas prácticas a implementar en una
aplicación basada en una arquitectura de microservicios, es que el frontal de la
aplicación (web o móvil) no tenga que mantener ni pasar datos de la sesión a los
servicios, sino un token específico con los permisos. Este diseño favorece el
desacoplamiento de los microservicios y por tanto su escalabilidad y mantenibilidad
independiente.
Partiendo de un Directorio Activo (que entendemos estaría disponible en la CGR) nuestro
modelo desglosa este proceso en 2 partes:
o
o
o
o
Autenticación, que delegaremos en el Directorio Activo. En este directorio se
debe gestionar que el usuario está acreditado. Para interactuar con este
directorio activo, la aplicación dispondrá de un microservicio específico que
será invocado directamente (sin pasar por el gestor de mensajería Kafka)
desde el API Gateway.
Autorización, que implementaremos en un microservicio transversal. En este
microservicio, una vez autenticado el usuario, se comprobará su nivel de
acceso y se generará su token correspondiente, que le acredita el nivel de
acceso a los diferentes microservicios de la aplicación.
Como parte de las propuestas de innovación, Inetum recomienda que los
procesos de autenticación y autorización serán delegados a un “Proveedor
de Identidad” el cual gestionará todos los aspectos de seguridad antes
mencionados, adicionalmente en caso surgieran nuevos requerimientos de
seguridad (ejm biometría facial) estos podrán ser anexados alrededor de este
Proveedor de identidad.
El proveedor de identidad propuesto es “WSO2 Identity Server” en su
modalidad de uso no comercial, el cual permite solo su uso a los
colaboradores de la contraloría y de INETUM. De esta forma, la CGR tendrá
centralizado en el directorio activo toda la gestión de autorizaciones de
acceso y será la propia aplicación la que mantenga el nivel de acceso a la
aplicación de los distintos usuarios, en función de su rol. Es importante
mencionar que el licenciamiento Comunitario permitirá a la CGR probar el
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
104 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
producto y posterior a ello, determinar su homologación. En caso esto último
suceda, la CGR deberá asumir los costos de suscripción y/o soporte asociadas
al producto.[1]
Además, en este proceso de autenticación y autorización es importante destacar que
proponemos no encolar los mensajes en el gestor de mensajes asíncronos Kafka, porque de
esta forma la respuesta al Login (que percibe el usuario nada más intentar entrar en la
aplicación) no va a depender de cuanta carga de trabajo de gestión de mensajes tenga
encolados Kafka por el trabajo de otros usuarios.






Autorización, auditoría y seguridad. Además del proceso de autorización antes
comentado, este proveedor de identidad también se propone que gestione la
auditoría y la seguridad. Es importante destacar que, en este tipo de arquitecturas,
no es suficiente un log de servidor como auditoría con en las aplicaciones monolíticas,
porque los microservicios están distribuidos. Por tanto, es un servicio tecnológico de
vital importancia, dado que debe guardar los registros de actividad en una base de
datos, para que posteriormente, ante cualquier problema, se pueda consultar la
información y extraer las conclusiones necesarias. Lógicamente, en el momento de
realizar el diseño detallado, es posible que la autorización se implemente en un
microservicio diferente del de auditoría y seguridad.
Microservicios transversales técnicos (no funcionales). Al igual que en el caso
anterior, en tiempo de diseño veremos en cuantos microservicios se deben desglosar,
en función de las necesidades asimétricas de escalado que necesiten dichos servicios
y los requisitos de mensajería que se estime que van a demandar. En principio, los
identificados son:
o Impresión y generación de pdf’s.
o Gestión de documentos.
o Gestión de notificaciones.
o Componentes comunes.
o Librerías técnicas, que gestionarán aspectos tecnológicos específicos que van
a ser usados por varias funcionalidades: Gestión de errores del API Rest,
listados paginados, CRUD, descarga de ficheros CSV, gestión de QR’s, Firma
digital, logs.
Microservicios funcionales. Nuestra propuesta es generar un microservicio por
cada grupo funcional definido. Lógicamente una mayor granularidad es posible, pero
también aumentaría la complejidad de la arquitectura y también la mensajería a
través de Kafka en su versión community. Por tanto, esta aproximación propuesta
lógicamente se habrá de revisar cuando se defina la implementación concreta,
cuando estén muy claros los requisitos no-funcionales de capacidad y rendimiento,
necesidades de escalados diferentes entre funcionalidades de un microservicio etc,
siempre con la visión de balanceo entre los parámetros de complejidad-valor
obtenido.
Microservicios de Movilidad y de terceros. Creemos que, al ser funcionalidades
a terceros o provenientes de terceros, es mejor que se implementen en un
microservicio específico, para de esta forma poder adaptarse a la evolución de cada
tercero (aplicaciones móviles, fuentes de datos externas, etc.), además de escalar
de forma independiente.
Extracción de ficheros para analítica de datos BI.
Gestión de componentes distribuidos, en tales aspectos los hemos dividido en:
o Configuración externalizada, esto permitirá que los microservicios
puedan ejecutarse en cualquier ambiente (ejm Dev,Qa,Prd) sin necesidad de
pasar por un proceso de recompilación o reconfiguración, lo cual promueve
un fácil despliegue o generación de nuevos ambientes de forma rápida. Las
herramientas para utilizar según sea el caso serán “Spring Config Server”
y “ConfigMap de Kubernetes” (Open source).
o Servicio de registro y descubrimiento de servicios, debido a la
configuración de alta disponibilidad y demanda, la aplicación necesita
conocer de forma rápida y dinámica la ubicación y tipos de servicios que tiene
a disposición y para lograr ese objetivo nos apoyaremos en la gestión de
registro y descubrimiento de servicios utilizando “Eureka Server” (Open
source).
[1] De acuerdo con la absolución de la Sesión Técnica 3 – Enfoque de Innovación, fila 12. Inetum recomienda el uso de un Proveedor de Identidad como parte de
la innovación.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
105 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Circuit Breaker, los servicios en general pueden fallar por diversos motivos,
una función principal de la arquitectura de microservicios no es evitar estos
fallos sino gestionarlos y tolerarlos, de tal forma que la aplicación sea auto
suficiente de poder reponerse ante fallas de los microservicios, para dicho fin
se utilizara un mediador de comunicación entre servicios el cual permitirá
acciones como reintentos, disyuntores entre otros patrones de resiliencia,
para dicho efecto se implementara las librerías “Resilience4J” y un
dashboard centralizado “Histryx” (Open source).
o Tracing distribuido, para ejecutar una capacidad de negocio muchas veces
se necesitará la ejecución de más de un servicio, y para mantener una visión
de como los servicios interactúan se implementará una herramienta de
tracing basado en “Sleuth” y “Zipkin” (Open source).
o Logging distribuido, tener una visión de que sucede tanto dentro como
fuera de los servicios es muy importante para detectar y resolver fallos o
mejorar la performance de la aplicación, debido a eso se implementara un
logging distribuido basado en el stack ELK en su versión community
(Elastic search, Logstash y Kibana).
Integración con aplicaciones legadas. Según sea el caso o el contexto de las
aplicaciones legadas, los microservicios se podrán integrar con las aplicaciones
legadas ya sea a través de:
o Invocaciones directas entre los microservicios y las aplicaciones legadas.
o Invocaciones por eventos a través del bus de eventos (Kafka community).
o Invocaciones y transformación de mensajes a través del ESB (WSO2 EI
community).
Exposición y gestion API’s. La arquitectura de microservicios no expone
directamente los servicios sino se intermedian a través de un API Gateway el cual
permite la implementación de políticas de seguridad, balanceo, composición de
servicios (patrón “Backend For FrondEnd”), migración de monolitos a
microservicios (patrón “Strangler”), etc. Se utilizará como API Gateway “Zuul”.
Gestión de código fuente.
o Los microservicios utilizarán un modelo de “Monorepo” y “Multirepo”
según sea el escenario de la aplicación.
o Los repositorios de código estarán basados en Git. En caso se defina un
servidor on premise, este servidor Git se instalará en la infraestructura que
proporcione la contraloría, caso contrario la contraloría indicara el servicio de
nube según sus lineamientos (se sugiere utilizar como servicio de nube
Bitbucket).
o El modelo de branching estará orientado a “GitFlow” para gestión de
soporte o mantenimiento y para la generación de nuevas aplicaciones o
versiones de aplicación se utilizará “Trunk Based Development”.
Contenerización de componentes. Ya sean componentes propios de la aplicación
(microservicios, SPA’s, etc) o componentes de gestión (Servidor de configuración,
servidor de descubrimiento, etc) estos se empaquetarán y se ejecutaran en un
entorno de contenedores.
o Las imágenes se almacenarán en un servidor de registro propio (Docker
registry server, versión community). Este servidor se instalará en la
infraestructura que disponga la contraloría.
o Para la generación de imágenes se utilizará Docker desktop en su versión
personal (para proyectos no comerciales).
o Para el uso de los componentes en las máquinas de los desarrolladores se
implementará sus ambientes con Docker-compose.
Orquestación de contenedores. Para la gestión del ciclo de vida y entorno de
ejecución de los contenedores se utilizará Kubernetes. La infraestructura para la
instalación del cluster de kubernetes será proporcionado por la contraloría.
o





Otro elemento relevante del diseño es que toda la mensajería necesaria entre los distintos
microservicios se propone que sea enrutada a través del gestor de colas de mensajes Kafka. En este
sentido, es importante destacar que la granularidad de los microservicios impactará directamente en
el volumen de mensajes a gestionar por Kafka. Por tanto, va a ser un elemento relevante a la hora
del diseño final esta granularidad, para asegurar el rendimiento del gestor de colas.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
106 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Cabe resaltar que la arquitectura de la solución se irá implementando gradualmente durante el
transcurso de la ejecución del proyecto y que su soporte a la alta disponibilidad en Producción será
implementado por Inetum de acuerdo al Informe de Dimensionamiento de la Infraestructura de
Hardware y Comunicaciones indicado en los TdR (página 11) resultante de la aprobación por parte
de la CGR.[1]
La solución informática a desarrollar contemplará adicionalmente la integración con otros sistemas o
componentes de la CGR, tal como el Sistema de Seguridad. La arquitectura analizada y propuesta
por la Firma será evaluada y aprobada por la CGR.
6.3.2 Capa de presentación web
Por otro lado, para las interfaces de usuario web se propone utilizar los framework’s Angular,
Angular Material y FlexLayout. Con esta solución tecnológica, en la capa de presentación se
gestionará tanto la propia presentación como el control y la navegación. Esto permite varias ventajas:



La presentación es responsive nativa, por tanto, estará adaptada de base para su
visualización en móviles y tabletas.
Al incorporar la capa de control, permite que el Api Gateway sea más sencillo y
eficiente, y no se necesitará mantener y pasar datos de sesión entre servicios,
evitando problemas de seguridad desde el diseño (únicamente se pasa un token para
verificar el nivel de acceso a las diferentes funcionalidades).
La lógica de navegación a implementar en esta capa tendrá en cuenta los requisitos
de negocio, es decir, esta lógica debe ser definida en función del proceso de gestión
necesario para el usuario de negocio. Este modelo de diseño no significa que haya
una gestión por procesos configurables, sino que los procesos de navegación serán
diseñados de forma que reproduzcan el proceso de negocio. Lógicamente, para esta
capa de presentación también es necesario realizar componentes comunes para
resolver necesidades como listados paginados, CRUD, autenticación y autorización,
etc.
6.3.3 Frameworks Java para el desarrollo de la arquitectura
Los siguientes frameworks a ser listados, formarán parte de la estructura del código para el desarrollo
de aplicaciones. Sin embargo, el uso de estas dependerá exclusivamente del requerimiento a ser
remitido por la CGR, por lo este listado puede variar incluso integrando nuevos componentes. [1]





Spring Boot. El mundo Java ha estado construyendo aplicaciones de Spring durante
mucho tiempo. Spring Boot es una versión particular de Spring que facilita mucho el
proceso al manejar muchos de los detalles de configuración. Spring Boot fue creado
para automatizar el inicio de los proyectos de Spring de cualquier tipo, no solo
microservicios. Para simplificar aún más las cosas, una vez que ha terminado con la
aplicación, Spring Boot se mezcla en un servidor web y emite un solo archivo JAR
que es prácticamente todo lo que se necesita, además de la JVM.
Eclipse MicroProfile. En 2016, la comunidad Java Enterprise decidió “limpiar”
JavaEE 7, para que las personas pudieran construir microservicios simples con las
piezas clásicas. Lanzaron un número elevado de bibliotecas, pero mantuvieron el
código para procesar las solicitudes REST, analizar JSON y administrar la inyección
de dependencias. Así, terminaron con algo rápido y simple, Eclipse MicroProfile.
Dropwizard. La infraestructura/framework de Dropwizard entrega un modelo muy
simple para el desarrollo con muchas de las decisiones importantes que se tomaron
en su nombre, y ha seguido este camino.
WildFly Thorntail. La gente de Red Hat construyó su propia versión de MicroProfile
completada con una herramienta de configuración. Su sitio web lo ayuda a crear su
propio archivo de compilación de Maven simplemente especificando las
características que necesita. Maven luego se encarga de ensamblar todo.
Helidon. Este framework atrae mucha atención dado el respaldo que Oracle
garantiza. Los arquitectos de Helidon siguieron muchos de los mismos temas que se
repiten en los otros frameworks: limpiar la Edición de Java Enterprise y conservar el
núcleo ligero y basado en servlets que se ha ganado la confianza del mundo.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
107 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS

Cricket. Cricket es pequeño a pesar de incluir varios extras como un almacén de
datos de valor fundamental para evitar que conecte una base de datos, y un
programador para controlar el procesamiento repetitivo en segundo plano. No hay
otras dependencias que agreguen complicaciones o bloqueos, por lo que es bastante
fácil agregar el código a Cricket e iniciar un microservicio independiente.

Jersey.
Uno
de 3los
enfoques
estándar
desarrollar
servicio
web
esconfirma,
la APIa de
[1] De acuerdo con la absolución
de la Sesión
Técnica
– Enfoque
de Innovación,
fila 6 ypara
la sección
Arquitectura, un
fila 17,
18, 19, 20,
22. Se
solicitud
de la CGR, que la arquitectura Java
de la solución
irá implementando
gradualmente
durante el conocido
transcurso de como
la ejecución
del proyecto.
para se
servicios
web RESTful
(también
JAX-RS),
una especificación
general que se ha implementado en el framework de Jersey. El enfoque depende en
gran medida del uso de las anotaciones para especificar la asignación de ruta y los
detalles de retorno. Todo lo demás desde el análisis de los parámetros y el embalaje
del JSON está a cargo de Jersey.

Play. Una de las mejores maneras de experimentar el poder de cross-language
power de la JVM es con el framework Play, una pila de código Scala que se enlaza
con Java o con cualquiera de los otros lenguajes de JVM. La base es muy moderna,
con un modelo asíncrono y sin estado que no sobrecarga al servidor con subprocesos
interminables intentando realizar un seguimiento de los usuarios y sus datos de
sesión. También hay una serie de características adicionales que se pueden usar para
desarrollar un sitio web como OpenID, validación y soporte de carga de archivos.

Swagger. Crear una API puede parecer tan simple como escribir un código que
escucha en un puerto y ofrece respuestas, pero los desarrolladores de Swagger
empiezan a diferir. Han creado un lenguaje completo de especificación de API
llamado OpenAPI que puede usar para escribir lo que el API hará. Esto puede parecer
un paso adicional, pero el equipo de Swagger también ha proporcionado un código
que convierte esta especificación en pruebas automatizadas, documentación y más.

Restlet. Una de las diferencias más grandes entre los distintos frameworks es el
número de conexiones a otros servicios y bibliotecas. El proyecto Restlet ofrece una
de las colecciones más grandes de funciones y conexiones. Ya está integrado con
bibliotecas como JavaMail, en caso de que su microservicio necesite hablar POP, IMAP
o SMTP a algún servidor de correo, y Lucene/Solr, en caso de que desee crear índices
de grandes porciones de texto en los que se puedan realizar búsquedas y metadatos
alrededor de estos.

Squash. La depuración de los microservicios suele ser un verdadero desafío, ya que
las partes están ligeramente acopladas y es difícil rastrear el flujo de datos a través
de todas las capas del sistema. Squash permite configurar puntos de interrupción en
el código, que se ejecuta en un clúster Kubernetes, y luego recibir todos los datos
en su IDE como si fuera uno que se ejecuta localmente. Squash también se integra
con los tiempos de ejecución de Node.js y Python en caso de que su colección de
microservicios no sea solo para Java.

Telepresence. Otra opción para depurar es usar Telepresence para crear un proxy
local para un microservicio en un clúster de Kubernetes distante. Las llamadas para
este servicio se desviarán a la versión local donde puede configurar puntos de
interrupción o hacer cualquier otra cosa que pueda imaginar en la máquina local.

Zipkin. Es un mecanismo para registrar eventos en varios microservicios y luego
correlacionarlos para que los problemas puedan ser aislados y estudiados a medida
que se extienden a través de la colección de máquinas. Hay una implementación de
Zipkin para Java, así como al menos otros seis lenguajes para que los sistemas
multilingües puedan ser abordados. Algunos de los frameworks más sofisticados
como Spring ya tienen Zipkin integrado de alguna forma.
6.3.4 JVM
Ha habido un importante cambio de filosofía en la liberación de versiones de Java; desde la versión
9 de Java liberada en septiembre de 2017 se van a liberar versiones por calendario y no por
funcionalidades, de esta forma cada 6 meses se liberará una versión de Java, y esto se ha cumplido
hasta la fecha. En marzo de 2018 se publicó Java 10 y en septiembre del mismo año Java 11.
También se ha llegado al acuerdo de que cada año y medio saldrá una versión LTS de Java que
incluirá un soporte a largo plazo; es el caso de Java 11 y está previsto que el soporte sea de 8 años,
hasta 2026.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
108 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Pero esto implica que ya no hay soporte de Java 9 y Java 10, y el soporte de Java 8 finalizó en enero
del año 2019.
La recomendación de Inetum es pasar a Java 11 directamente desde Java 8 sin pasar por
Java 9 ni por Java 10.
Ventajas de usar Java 11
•
•
•
•
•
•
•
•
•
•
•
Soporte. El soporte de Java 8 finalizó en enero del año 2019. El soporte de Java 11 será
hasta 2026.
Nuevas funcionalidades de Java 9, Java 10 y Java 11:
Modularización. Los módulos permiten la encapsulación en tiempo de compilación, de
esta forma se puede restringir el acceso a una serie de paquetes. Esta funcionalidad está
disponible desde Java 9.
Inferencia de tipos. Este es el principal cambio de Java 10, a partir de este momento se
puede utilizar var para crear objetos sin tener que definir el tipo. Además, con Java 11,
se ha añadido el uso de var en las lambdas permitiendo las anotaciones en estos
parámetros.
Nuevos métodos en las colecciones. Se tienen más facilidades para crear colecciones ya
inicializadas. Se puede usar el método estático of() de List, Set, Stream o Map.
Nuevos métodos en los streams. Se pueden usar los métodos takeWhile(), dropWhile(),
iterate() y ofNullable() en los streams. Los dos primeros se usan para eliminar o escoger
los primeros elementos mientras se cumple una condición, el método iterate() genera
una iteración de valores y el método ofNullable() genera un Stream con un elemento si
el elemento no es null o vacío.
Nuevos métodos en los Optional. En Java 9 se añadieron los métodos ifPresentOrElse(),
or() y stream() para aportar funcionalidad extra a los ya conocidos métodos de Java 8.
Los Optional avanzan también con Java 10 y se añade el método orElseThrow().
Métodos privados en las interfaces. Java 9 da la posibilidad de tener métodos privados
dentro de las interfaces para facilitar la legibilidad de código y que no se hagan métodos
por defecto infinitos.
Comando jshell del terminal. Desde Java 9 se tiene un nuevo comando disponible en el
terminal, el comando jshell. Con este comando se puede probar directamente por consola
cualquier sentencia de java sin necesidad de un IDE.
Comando javo del terminal. Además del ya incluido jshell, con Java 11, se pueden
ejecutar ficheros Java desde consola.
Nuevos recolectores de basura. Aunque este cambio puede parecer transparente para
los programadores, se ha cambiado el recolector de basura por defecto.
La evaluación sobre el uso de la versión 17 de java será realizada durante la Fase Operativa y en
concordancia con la necesidad tecnológica del proyecto, así como la aprobación por CGR.[1]
6.3.5 CI/CD
Ya que la arquitectura de microservicios involucra un gran desafío para la gestión de integración y
despliegue de los componentes, es necesario establecer herramientas para la automatización de
dichos procesos, para lograr dicho objetivo se utilizarán como herramienta principal “Jenkins”
(Open Source)


Integración continua (CI), este proceso se ejecutará cada vez que haya algún cambio
en el código ya sea a nivel de desarrollo o de producción, este proceso:
o Compilará el código para asegurar que los cambios introducidos no generen
un “Build break” por una mala codificación.
o Ejecutará las pruebas unitarias que se establezcan en la aplicación
asegurando coherencia en el código.
o Análisis de código estático, tanto a nivel de mantenibilidad, performace y
seguridad utilizando “SonarQube” (Open Source), esta herramienta se
instalará en la infraestructura que proporcione la contraloría.
Entrega continua (CD), este proceso se ejecutará cada vez que haya algún cambio
en el código en flujo desde el desarrollo hasta producción, este proceso:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
109 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Generará un artefacto (imagen docker).
Publicara el artefacto en el repositorio de imágenes.
Realizará el despliegue del artefacto en los ambientes que se definan (ejm
QA, Prod), para dicho fin se utilizará “Helm” como herramienta de
[1] De acuerdo con la absolución de la Sesión
Técnica 3 – Arquitectura, fila 17. Se aclara la evaluación de la versión 17 de Java, así como el uso de frameworks,
despliegue.
librerías principales entre otros.

El despliegue podrá ser realizado en ambientes de Desarrollo, Pruebas,
Preproducción y Producción que CGR disponga para el proyecto. Este despliegue se
desarrollará a detalle durante la etapa preoperativa.
o
o
o
6.3.6 Arquitecturas, metodologías, patrones y diseños de software
Patrones de Arquitectura de software complementarios
Para la construcción de las aplicaciones dentro del servicio de fabrica principalmente se utilizará el
estilo arquitectónico de microservicios, pero dependiendo de del tipo de aplicación y requerimiento
podría complementarse con los siguientes patrones de arquitectura:[1]







Arquitectura en capas. Cada capa representa una capacidad técnica, lo que
permite a los desarrolladores cambiar fácilmente la funcionalidad de la arquitectura
técnica. El criterio de diseño principal para la arquitectura en capas separa las
diferentes capacidades técnicas en capas, cada una con una responsabilidad distinta.
Arquitectura de pipeline. La arquitectura de pipeline define un flujo de
transformación para un flujo de datos continuo compuesto por pasos conectados pero
independientes.
Arquitectura de microkernel. La lógica de la aplicación se divide entre
componentes complementarios independientes y el sistema central básico, lo que
brinda extensibilidad, adaptabilidad y aislamiento de las características de la
aplicación y la lógica de procesamiento personalizado.
Arquitectura orientada a eventos. Un patrón de arquitectura de software
asíncrono y distribuido que integra aplicaciones y componentes a través de la
producción y el manejo de eventos. Un evento es la ocurrencia de algo que se
considera significativo en una aplicación de software, como un cambio de estado,
que puede ser de interés para otras aplicaciones u otros componentes dentro de la
misma aplicación.
Arquitectura orientada a servicios impulsada por orquestación. Evolución de
las arquitecturas en capas para el desarrollo de sistemas de software mediante la
creación de servicios interoperables acoplados libremente que trabajan juntos para
automatizar los procesos comerciales. Un servicio es una parte de una aplicación de
software que realiza una tarea específica, brindando funcionalidad a otras partes de
la misma aplicación de software o a otras aplicaciones de software.
Arquitectura basada en servicios. Granularidad de servicio más grande, servicios
organizados en torno a áreas de dominio. La arquitectura basada en servicios tiende
hacia una base de datos monolítica. Los sistemas con requisitos transaccionales
complejos se asignan más claramente a las arquitecturas basadas en servicios.
Coordinación externalizada a través de un mediador como un bus de servicio.
Arquitectura monolítica. Cuando toda la funcionalidad de un sistema tiene que
implementarse en conjunto, consideramos un monolito y podemos identificar varios
tipos de sistemas monolíticos:
o Monolito de proceso único cuando todo el código se implementa como un
solo proceso.
o Monolito modular, es una variante del monolito de proceso único que
consiste en módulos separados, cada uno de los cuales se puede trabajar de
forma independiente, pero que aún deben combinarse para su
implementación.
o Monolito distribuido es un sistema que consta de múltiples servicios, pero
por alguna razón, todo el sistema debe implementarse en conjunto.
Puntos de vista arquitectónicos.[1]
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
110 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Dentro de la construcción de las aplicaciones se debe tener en consideración las diferentes puntos
de vista de arquitectura ya que estos nos dará una visión cercana a lo que la contraloría necesita
como solución. Para poder definir los puntos de vista primero debemos entender que:
[1] De acuerdo con la absolución
de la vista,
Sesión Técnica
– Enfoque
de Innovación, fila de
7. Seuno
detalla,
solicitudaspectos
de la CGR, puntos
de vista arquitectónicos,
se

Una
es 3una
representación
o a más
estructurales
de una
define las diferentes formas de documentar arquitecturas, pero la implementación de cada diagrama se dará durante la etapa de Operación.

arquitectura que ilustra cómo la arquitectura aborda una o más preocupaciones de
uno o más de sus stackeholders.
Un Punto de vista, es una colección de patrones, plantillas y convenciones para
construir un tipo de vista. Define las partes interesadas cuyas preocupaciones se
reflejan en el punto de vista y las pautas, principios y modelos de plantilla para
construir su punto de vista.Arquitectura en capas. Cada capa representa una
capacidad técnica, lo que permite a los desarrolladores cambiar fácilmente la
funcionalidad de la arquitectura técnica. El criterio de diseño principal para la
arquitectura en capas separa las diferentes capacidades técnicas en capas, cada una
con una responsabilidad distinta.
Durante la construcción de las aplicaciones se estarían aplicando los siguientes puntos de vista de
arquitectura:







Contexto. Describe las relaciones, dependencias e interacciones entre el sistema y
su entorno (las personas, los sistemas y las entidades externas con las que
interactúa).
Funcional. Describe los elementos funcionales del sistema, sus responsabilidades,
interfaces e interacciones primarias. Una vista funcional es la piedra angular de la
mayoría de los AD y, a menudo, es la primera parte de la descripción que las partes
interesadas intentan leer. Conduce la forma de otras estructuras del sistema, como
la estructura de información, la estructura de concurrencia, la estructura de
implementación, etc. También tiene un impacto significativo en las propiedades de
calidad del sistema, como su capacidad para cambiar, su capacidad para protegerse
y su rendimiento en tiempo de ejecución.
Información. Describe la forma en que la arquitectura almacena, manipula,
administra y distribuye información. El objetivo final de prácticamente cualquier
sistema informático es manipular la información de alguna forma, y este punto de
vista desarrolla una visión completa, pero de alto nivel de la estructura de datos
estáticos y el flujo de información. El objetivo de este análisis es responder a las
grandes preguntas sobre contenido, estructura, propiedad, latencia, referencias y
migración de datos.
Concurrencia. Describe la estructura de concurrencia del sistema y asigna
elementos funcionales a unidades de concurrencia para identificar claramente las
partes del sistema que pueden ejecutarse simultáneamente y cómo se coordinan y
controlan. Esto implica la creación de modelos que muestren las estructuras de
procesos y subprocesos que utilizará el sistema y los mecanismos de comunicación
entre procesos utilizados para coordinar su funcionamiento.
Desarrollo. Describe la arquitectura que soporta el proceso de desarrollo de
software. Las vistas de desarrollo comunican los aspectos de la arquitectura de
interés para las partes interesadas involucradas en la construcción, prueba,
mantenimiento y mejora del sistema.
Despliegue. Describe el entorno en el que se implementará el sistema, incluida la
captura de las dependencias que tiene el sistema en su entorno de tiempo de
ejecución. Esta vista captura el entorno de hardware que su sistema necesita
(principalmente los nodos de procesamiento, las interconexiones de red y las
instalaciones de almacenamiento en disco requeridas), los requisitos del entorno
técnico para cada elemento y la asignación de los elementos de software al entorno
de tiempo de ejecución que los ejecutará.
Operacional. Describe cómo se operará, administrará y admitirá el sistema cuando
se ejecute en su entorno de producción. Para todos los sistemas, excepto los más
simples, instalar, administrar y operar el sistema es una tarea importante que debe
considerarse y planificarse en el momento del diseño. El objetivo del punto de vista
operativo es identificar estrategias de todo el sistema para abordar las
preocupaciones operativas de las partes interesadas y para identificar soluciones que
los aborden.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
111 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Nota: La construcción de los diferentes diagramas pertenecientes a cada punto de vista serán
definidos según la necesidad de cada aplicación.
Artefactos de arquitectura de Software
Para llevar un mejor orden sobre los tipos de artefactos que se entregaran y los niveles de detalle
que se necesiten para el desarrollo de código de la aplicación se seguirá la metodología “C4 Model”
(Modelo de diseño de arquitectura de software basado en abstracciones.), el cual establece 4 niveles
de detalle:




Nivel 1: Un diagrama de contexto del sistema, proporciona un punto de partida, que
muestra cómo el sistema encaja en el mundo que lo rodea.
Nivel 2: Un diagrama de contenedor muestra los bloques de construcción técnicos
de alto nivel.
Nivel 3: Un diagrama de componentes muestra los componentes dentro del
contenedor.
Nivel 4: Se puede usar un diagrama de código (por ejemplo, clase UML) muestra
cómo se implementa un componente.
Patrones, principios y Best Practice de desarrollo de Software
Una forma de garantizar una buena implementación de código de las aplicaciones para el servicio de
la contraloria es aplicando patrones, principios y Best Practice de desarrollo como los siguientes:

Clean Code
o Enfoque TPM (Total Productive Maintenance), uso de la filosofía 5S
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
112 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS




Seiri u Organización

Seiton o Sistematización

Seiso o Limpieza

Seiketsu o Estandarización

Shutsuke o Disciplina
o Uso de Getters y Setters (Tell Don't Ask), uso de:

Patrón DTO

Anemic models
o Optimización de Estructuras Condicionales, uso de:

“Cláusulas de guarda”
o Construcciones Semánticas de Entidades
o Análisis y Mejora del Código, (Code Smells y Refactors)
o Contextos estáticos
o Composición de colaboradores
o Interfaces.
Patrones de diseño
o Patrones Creacionales

Factory Method

Abstract Factory

Builder

Prototype
o Patrones Estructurales

Adapter

Proxy

Decorator
o Patrones de Comportamiento

Chain of Responsibility

Observer

State
Principios SOLID
o S – Single Responsibility Principle (SRP)
o O – Open/Closed Principle (OCP)
o L – Liskov Substitution Principle (LSP)
o I – Interface Segregation Principle (ISP)
o D – Dependency Inversion Principle (DIP)
Arquitectura hexagonal
o Controllers
o Application Services
o Dominio
o Repositorios
o Puertos
o Adaptadores.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
113 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
114 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
6.4 Nueva Arquitectura de Datamart
Las grandes corporaciones guardan sus datos en almacenes, desde los que se satisfacen las
necesidades organizacionales y se facilita la toma de decisiones. Conocer las diferentes tecnologías
disponibles y desarrollar una correcta arquitectura de datos es clave a la hora garantizar su óptima
explotación. Inetum, durante la Fase Pre-Operativa, alineará la siguiente propuesta de desarrollo de
datamart en cumplimiento de lo especificado el Anexo 12 de los TdR.[1]
Diferencia entre Data Warehouse y Datamart
Un Data Warehouse es una gran infraestructura digital que almacena todos los datos de
una compañía. Estos presentaban un problema, que radicaba en su crecimiento: a mayor cantidad
de datos, mayor complejidad y menor rendimiento en las consultas sobre bases de datos tipo OLTP
(Procesamiento de Transacciones En Línea). Ante esta realidad, mastodónticos de tener modelos de
datos de grandes proporciones, el Data Warehouse se convierte en algo difícil de analizar, y surgen
como solución los Datamarts.
Estos centros de datos, son también herramientas de Business Intelligence orientadas,
principalmente a la consulta, pero en este caso por áreas. Dicho de otra manera, los Datamart son
fragmentos de un Data Warehouse, de los que se nutren, destinados al análisis de datos de un área
concreta de la organización.
De este modo, se adecua la extracción de información a las necesidades de secciones de
negocio concretas, lo que permite analizar en detalle el comportamiento de áreas específicas. En
consecuencia, los Datamart ofrecen indicadores clave de un área determinada facilitando y
optimizando la toma de decisiones.
Ventajas de los Datamart
Los Datamart son mucho más operativos para el análisis de la información que tiene cada área.
Veámoslo con un ejemplo muy gráfico de la gestión analógica: una empresa puede contar con cientos
o miles de archivadores con información del conjunto de la compañía. Si necesitamos encontrar un
dato concreto la búsqueda va a ser mucho más sencilla, rápida y operativa si estos archivadores
están divididos por áreas, puesto que buscaremos en aquellos que contienen información del área
que nos interesa, discriminando de entrada todos los demás. Y lo mismo sucede en los entornos
digitales.
Siguiendo esta lógica, una empresa puede crear un Datamart para el área de finanzas que contenga
y gestione los datos que interesan a los profesionales de esa área. A partir de esa información pueden
trabajar con análisis, alertas y KPI's específicamente desarrollados para su actividad concreta,
mejorando la toma de decisiones y en consecuencia las operativas. Y esto puede hacerse en todos
los demás, contando con un Datamart financiero, un Datamart de planeamiento, un Datamart de
logística, etc.
[1] De acuerdo con la absolución de la Sesión Técnica 3 – Datamart, fila 28. Se especifica, a solicitud de la CGR, que Inetum se compromete a cumplir con alinear
su propuesta de desarrollo de datamart acorde y según el nivel de detalle del Anexo 12 de los TdR, durante la Fase Pre-Operativa.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
115 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Beneficios de los Datamart
Los Datamart pueden alimentarse del Data Warehouse corporativo o nutrirse de distintas fuentes de
datos, aunque sea del modo que sea su uso tiene grandes ventajas.







Sencillez de creación frete a las estructuras más complejas de los Data Warehouse.
Facilidad de manejo.
Menores requerimientos técnicos para su implementación y mantenimiento.
Mayor rapidez de consulta.
Análisis detallado de departamentos concretos.
Posibilidad de identificación de amenazas y oportunidades que en visiones generales pueden
pasar desapercibidas.
Mejora de la toma de decisiones.
Tipos de Datamart
Existen tres tipos principales de Datamarts en función del tipo de datos que utilizan y su estructura
relacional:



Centro de datos dependiente. Se trata de datos centralizados y dependientes unos de otros
para garantizar la coherencia.
Centro de datos independiente. Suelen ser pequeños, no utilizan el almacén central y suelen
partir de fuentes externas.
Centro de datos híbrido. Se trata de una combinación de los anteriores.
6.4.1 Consideraciones para el Desarrollo del Datamart
Para el desarrollo del Datamart de Fichas de Control de Trabajo en Campo, se tiene en cuanta las
siguientes consideraciones:






Realizar el análisis del requerimiento de información para definir las variables, indicadores y
alertas.
Se realizará la trazabilidad de los campos origen, siempre cuando contemos con el acceso a
las fuentes y soporte necesario para poder realizar el mapeo, de obtener se dé un software
enlatado CGR deberá de coordinar con su actual proveedor para facilitar el apoyo y soporte
necesario para poder cumplir con esta tarea.
Se diseñará un modelo físico y lógico, que sea flexible y escalable, que permita el crecimiento
de sus dimensiones y variables. Para ello se tomará en cuenta como fuente de origen a:
o Sistema Integrado de Administración financiera (SIAF)
o Sistema Electrónico de Contrataciones del Estado (SEACE).
o Sistemas de Control.
o Otros sistemas relacionados a los ya indicados.
Se construirán ETL’s que permitan que permitan poblar el datamart, bajo las reglas y
consideraciones que se revisen durante la etapa de diseño.
Se realizará la instalación y configuración necesaria para poder tener implementado la
plataforma tecnología de BI y de todos los componentes del Datamart que estarán a cargo
de la FIRMA CONSULTORA, que permitirá realizar el desarrollo y disponibilizar sus
aplicaciones a nivel de servidor. Para los clientes a nivel de usuario se generará una guía que
permita su instalación y uso de la herramienta, para permita que el usuario pueda adaptarse
fácilmente. Como también se realizará una ronda de capacitaciones con las personas que
defina CGR, en como estaría construido el datamart como en el uso de las herramientas de
BI.
La CGR deberá de proporcionar las licencias y el acceso a las instancias de la Base de Datos
Oracle para la integración del datamart para los siguiente entornos:[1]
o Desarrollo, ambiente donde se realizará la codificación necesaria, pruebas unitarias
y pruebas de concepto si CGR lo solicitase.
o Certificación, ambiente donde se desplegará el desarrollo y donde se realizarán las
pruebas de integración y pruebas de calidad.
o Performance, ambiente donde se realizarán las pruebas de performance de los
procesos con la finalidad de poder detectar aquellos procesos degradados y así
[1] De acuerdo con la absolución de la Sesión Técnica 3 – Arquitectura, fila 24. Se especifica, a solicitud de la CGR, que la base de datos que usará el Datamart
será la de Oracle.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
116 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS





afinarlos para reducir inconvenientes por ejecución de procesos degradados en
producción.
o Producción, ambiente donde se desplegará la solución con todas las
consideraciones de acuerdo con el proceso de gobierno de despliegues que se defina
antes del primer despliegue.
La licencia de Pentaho será la versión comunitaria para los ambientes pre productivos y
Enterprise para el entorno de producción. Este licenciamiento tendrá una vigencia de 3 años
desde la puesta en producción.[1]
El Sistema Operativo para esta solución deberá de ser el proporcionado por la CGR, según la
herramienta pentaho, el cual está indicado en la sección 6.4.3 Herramientas de Desarrollo
del Datamart.
Como parte del servicio se dará el soporte post-instalación y post-pase durante el periodo
de servicio, de acuerdo con la garantía según lo indicado en el documento.
Se cumplirá con la documentación de proyecto requerida, según formatos establecidos previo
al inicio de la planificación.
Se considera realizar el desarrollo en base a las buenas prácticas y lineamientos de CGR, en
caso de no tenerlo se definirá en conjunto entre CGR y la FIRMA CONSULTORA.
6.4.2 Arquitectura Propuesta
Nuestra propuesta de arquitectura conceptual es la que mostramos en la siguiente ilustración:
En el diagrama de Arquitectura propuesto, se esta considerando trabajar con una solución de BI
Pentaho que cuenta con diversas herramientas Open Source que permite gestionar, desarrollar
y visualizar dashboard/informes/graficas que permitan al usuario usar lo para su gestión, el cual
es una herramienta que esta basado en JAVA.
Las actividades de Data Warehousing se realizan usando las herramientas de Pentaho Data
Integration (PDI), Spoon es la herramienta gráfica para construir los procesos ETL, Kitchen/Pan
son las herramienta que permiten calendarizar la ejecución de los procesos ETL.
[1] De acuerdo con la absolución de la Sesión Técnica 3 – Datamart, fila 29. Se accede, a solicitud de la CGR, que para el entorno productivo se utilizará la versión
licenciada de Pentaho.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
117 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Las construcción de soluciones para actividades de Inteligencia de Negocios son apoyadas por
las siguientes herramientas:

Pentaho Metadata Editor (PME) permite crear una capa de metadatos sobre el DWH
con términos del negocio; ésta capa es la fuente para crear reportes a demanda usando
herramientas como WAQR (Web-based Ad Hoc Query and Reporting)

Pentaho Report Designer (PRD) permite crear reportes avanzados que contienen
fórmulas, agrupaciones, hipervínculos, parámetros, gráficos

Pentaho Schema Workbench (PSW) permite crear cubos de análisis OLAP

Community Tools (CTools) conjunto de herramientas Open Source que permiten
construir tableros de mando (Dashboards) con indicadores claves de rendimiento (KPIs)
El servidor central Pentaho Server posee un cliente web conocido como Pentaho User Console
(PUC) a través del cual se accede al contenido publicado por las herramientas PME, PRD, PSW
y CTools. Además, requiere de 3 repositorios para su operación normal: hibernate, quartz y
jackrabbit.
6.4.3 Herramientas para el Desarrollo del Datamart

Oracle SQL Developer. Oracle SQL Developer es un entorno de desarrollo integrado y
gratuito que simplifica el desarrollo y la administración de Oracle Database en
implementaciones tradicionales y en la nube. SQL Developer ofrece un desarrollo completo
de las aplicaciones PL/SQL, una hoja de trabajo para ejecutar consultas y scripts, una consola
de DBA para administrar la base de datos, una interfaz de informes, una solución completa
de modelado de datos y una plataforma de migración para trasladar las bases de datos de
terceros a Oracle. Esta herramienta también permite conectarse a PostgreSQL.

Pentaho. Pentaho es una aplicación de software para la gestión de la inteligencia
empresarial (Business Intelligence y Big Data). Está desarrollada con la filosofía opensource
por lo que no tiene coste de licencias. Como plataforma cubre y satisface todos los requisitos
de BI en términos de análisis y de gestión de datos, administración y seguridad. Ofrece
soluciones para informes, análisis multidimensional (OLAP), minería de datos (Data Mining),
tableros de mando (Dashboard) y consultas ad-hoc. Cuenta con herramientas para la
extracción de datos, transformación y carga (ETL).
Funcionalidades
Pentaho es una suite muy completa que cubre multitud de áreas analíticas y motores para
el procesamiento de información y la generación de conocimiento. Estas herramientas están
soportadas e integradas sobre un servidor web y dispone de un entorno de configuración y
desarrollo.
La suite Pentaho está compuesta por múltiples aplicaciones independientes entre sí, que
trabajan juntas para crear y distribuir soluciones BI. Para ello se tomara en cuenta las
siguientes para el uso de CGR:

Aggregation Designer (Diseñador de agregaciones). Dispone de una interfaz para
optimizar el rendimiento de las consultas de cubos OLAP, permitiendo la creación de
nuevas tablas agregadas dentro de las dimensiones seleccionadas. Ayuda a obtener
datos pre-calculados sobre los archivos de esquema de Pentaho Analysis (Mondrian) en
XML mejorando el rendimiento de los análisis.

PDI - Pentaho Data Integration (Integrador de datos). Cuenta con un motor ETL
(extracción, transformación y carga) y una interfaz de usuario que le permite la gestión
y desarrollo de los flujos de la integración de datos, es decir, la recopilación de estos, la
depuración y/o transformación, y la posterior conservación en un formato apropiado y
accesible para el usuario y otras aplicaciones. Este módulo también es llamado “Kettle”
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
118 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
actualmente. Posee la capacidad de gestionar diferentes almacenes de Big Data en
clústeres distribuidos en la nube. Esta herramienta permite conectarse a origenes como:
XML, TXT, JDBC, ORACLE, PostGresSQL, ODBC, Excel, DBF, MDB, etc.

PME – Pentaho Metadata Editor (Editor de metadatos). Dispone de un editor de
metadatos útil para personalizar la capa de metadatos modelando la estructura de la
base de datos para generar un modelo lógico de metadatos. Luego el módulo de
Informes interactivos de Pentaho utilizará el modelo resultante para crear informes
dentro del servidor Business Analytics (BA) sin requerir de otras aplicaciones externas.

PRD – Pentaho Report Designer (Diseñador de informes). Ofrece una interfaz de
usuario con opciones de diseño que facilitan la preparación de informes de buena calidad
con visualizaciones muy detalladas que pueden contener una variedad de gráficos e
incluso sub-informes. Su motor de informes trabaja con una plantilla en formato ZIP que
consta de recursos XML para definir el estilo del informe.

PSW - Pentaho Schema Workbench (Desarrollador de esquemas). Cuenta con
una interfaz de usuario y elementos para la creación y edición de modelos
multidimensionales (MDX - multi-dimensional expressions) de forma gráfica o manual.

Design Studio (Estudio de Diseño). Consiste en una aplicación con complementos
basados en Eclipse, que sirve para crear automatizaciones y acciones secuenciales que
faciliten la creación de flujos de procesos empresariales orientados a resultados dentro
del servidor BA.
Los componentes web de Pentaho son compatibles con la mayoría de los navegadores,
conoceremos cuáles son a continuación:

Analizador (Analyzer). Proporciona un conjunto de opciones avanzadas en un visor
OLAP intuitivo para profundizar en el almacén de datos (Mondrian), realizar consultas
parametrizadas, crear medidas, aplicar filtros y dar formato a los datos, configurar y
generar hipervínculos, confeccionar gráficas de varios tipos y diseñar visualizaciones
detalladas.

CTools - Community Tools. Proporciona un marco de opciones para desarrollar paneles
dinámicos mediante CSS, JavaScript y HTML. Los usuarios tendrán una mayor facilidad
para explorar los conjuntos de datos a través de tablas, gráficos, entre otros elementos.

Diseñador de cuadros de mando (Dashboard Designer). Proporciona una serie de
contenidos de diseño, temas personalizables y plantillas predeterminadas, que se
pueden combinar para que los informes sean atractivos, y ofrezcan información
comprensible para el análisis del usuario en un vistazo.

Asistente de fuente de datos (Data Source Wizard). Proporciona asistencia para
preparar los modelos de datos (relacionales o multidimensionales) de cada una de las
fuentes de datos importadas para los análisis.

Editor de modelos de fuente de datos (Data Source Model Editor). Proporciona
opciones para ajustar y optimizar los modelos existentes. Permite la inserción,
eliminación y combinación de campos procedentes de diferentes tablas y ubicaciones.

Informes interactivos (Interactive Reports). Proporciona una interfaz de diseño de
informes donde el usuario de negocio puede de forma muy simple (con tan solo arrastrar
y soltar), insertar múltiples elementos a un informe, trabajar sobre una plantilla o darle
el formato deseado, con independencia del apoyo de los desarrolladores de TI.

Consola de usuario (User Console). Proporciona un entorno de diseño con opciones
para la administración de la plataforma, la configuración del servidor de Pentaho, y los
accesos a los componentes previamente mencionados.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
119 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Por otra parte, la consola de administración de Pentaho, consiste es una interfaz web para
configurar el servidor de integración de datos, administrar las aplicaciones empresariales,
aplicar permisos a informes y repositorios. Las aplicaciones del servidor son las siguientes :

Servidor de Business Analytics (BA): Esta basado en Java y ofrece una interfaz web
(HTML5) donde el usuario puede crear, administrar y compartir recursos de BI.

Servidor de Data Integration (DI): Es un servidor para la ejecución de flujos ETL y
de integración de datos. Permite programar flujos automatizados y almacenar el historial
de revisiones y seguridad.
Requisitos de Infraestructura para Pentaho
SERVIDOR : Requisitos minimos a tener en cuenta para la instalación del servidor de
Pentaho.
WORKSTATION : Requisitos minimos para tener en cuenta para la instalación de las
estaciones de trabajo de pentaho.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
120 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
6.4.4 Buenas Prácticas para el Desarrollo de Datamarts
Inetum considera el poder llevar las buenas prácticas de la teoría a la realidad, el cual nos permite
tener un mejor desarrollo, donde consideramos las siguientes practicas:








Asegurarse de que ha sido suministrado un diccionario de datos antes de empezar con las
etapas fuertes de desarrollo.
Guardar planes de Consultas, tiempos de ejecución y referencias de rendimiento en la base
de datos.
Guardar ETL’s, validaciones y errores en tablas compartidas de la Base de Datos.
Evitar transacciones con tiempos de ejecución largos.
Usar la Integridad Referencial cuidadosamente.
Aprender a reconocer cuando el rendimiento decrece en realidad.
Entender siempre la optimización de la Base de Datos y los planes de Consultas (Query
Plans).
Conocer las limitaciones de la Base de Datos.
6.4.5 Ciclo de Vida del Desarrollo para Datamart
Modelo Tradicional (Cascada)
El framework tradicional para ejecutar procesos de Datamart es el modelo en cascada
(waterfall). Mediante este enfoque se ordenan las etapas del proceso para el desarrollo de
software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa
anterior. Este método conlleva los siguientes pasos secuenciales:
Definición del
Gobierno y
Planificación
Definición del
Requerimiento
Modelamiento
Logico de Datos
Mapeo de Fuentes
Testeo de
Integración
Construcción de la
Integración
Diseño de
Integración
Modelamiento
Fisico
Construcción de
Capa de Acceso
Testeo de Capa de
Acceso
Construcción de BI
Testeo de BI
Entrega
A continuación se detalla las etapas y artefactos que se elaboraran durante todo el ciclo de
vida del proyecto, para ello tener en cuenta que los SLA de aprobación de los artefactos son
los indicados en la parte superior del documento:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
121 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Definición del Gobierno y Planificación: En esta etapa se definira el modelo de
gobierno del proyecto, los niveles de comunicación y el plan de trabajo. Donde se tendran
como entregables los siguientes artefactos:

Plan de Comunicacion, Se elaborara en conjunto a CGR, un plan de comunicación,
con la finaliada de poder identificar a los usuarios estrategicos que permitan ayudar
al desarrollo del proyecto.

Plan de Gobierno, Se definira entre las partes a los responsables y roles que se
asumiran durante el desarrollo del proyecto.

Planificación del Proyecto, Se eleborara un plan de trabajo que permita tener un
panorama de cada fase de la implementación del proyecto.
Definición del Requerimiento: En esta etapa se realizaran reuniones de
entendimiento con el usuario y responsables de TI de la CGR, con la finalidad de poder
tener el entendimiento de la necesidad del usuario. Donde se tendra como entregable el
siguiente artefacto:

Plantilla de Diseño Funcional, Documento que se elaborara en base a una
especificación de las características del datamart que los usuarios finales acuerden,
como tambien se definira el contenido de los dashboards e informes, donde tendra
las reglas de negocio, indicaciones y un bosquejo inicial de las variables.

Plantilla de Diccionario de Datos, Documento que se elaborara en base a un
listado de datos organizado que define de manera rigurosa, las características lógicas
y puntuales tales como nombre, tipo de contenido y descripción de negocio, de tal
forma que se cuente con un elemento común, para el entendimiento de la base de
datos.

Plantilla de Glosario de Terminos, Documento que se elaborara en base a un
listado que permitira tener una recopilación de definiciones o explicaciones de
palabras que versan sobre un mismo tema u ordenada de forma alfabética.
Modelamiento Logico de Datos: En esta etapa se definira el tipo de modelo de datos
a usar y se generara una grafica en alto nivel del modelo que permitira aterrizarlo en un
diseño logico del modelo de dato, como también définir la matruz BUS. Donde se tendra
como entregable el siguiente artefacto:

Diagrama de Modelo de Datos Logico, Diagrama que será elabarado como
resultado del analisis de la necesidad del usuario, que permitira dimensionar las
entidades y areas que puedan cubrir las espectativas del cliente.

Plantilla de Matriz BUS, Documento que permite identificar de modo gráfico las
métricas vs. las dimensiones a analizar en el modelo multidimensional a
implementar.
Mapeo de Fuentes: En esta etapa se realizara la revisión de las fuentes de los origenes,
de haber el caso que las fuentes sean custodiadas o sea de un software enlatado será
necesario que el cliente pueda ayudar a proporcionar un mapeo de los origenes. Donde
se tendra como entregable el siguiente artefacto:

Plantilla de Matriz de Trazabilidad, Documento que se elaborara en base a una
tabla que relaciona cada uno de los requerimientos con el entregable que se haya
solicitado. Este cuadro es de doble sentido. Te permite identificar qué resultado se
alcanza a través de cada requisito y, a la vez, qué requisitos son los que permiten
obtener un determinado entregable.
Diseño de Integración: En esta etapa se diseñara el bosquejo de como seran las
integraciones y se realizara la especificación tecnica necesaria para el desarrollo de las
integraciones. Donde se tendra como entregable el siguiente artefacto:
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
122 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS

Plantilla de Diseño Técnico, Documento que contara con la especificación técnica
de los objetos que se construiran y sus modificaciones, como también diagramas de
componente, secuencia, flujos y modelo de datos fisico y logico.
Construcción de la Integración: En esta etapa realizara la codificación necesaria bajo
los estandares y buenas practicas para cumplir con el alcance del desarrollo. Luego de
las pruebas del desarrollador se realizara el despliegue en el ambiente de certificación.
Donde se tendra como entregable el siguiente artefacto:

Plantilla de Prueba Unitaria, Documento que contara con las evidencias de las
pruebas unitarias, el cual contemplara imagenes e descripciones que puedan
evidenciar estas pruebas hechas por el desarrollador para el componente
desarrollado.

Plantilla de Prueba Integral, Documento que contara con las evidencias de las
pruebas integrales, el cual contemplara imagenes e descripciones que puedan
evidenciar estas pruebas hechas por el desarrollador para corroborar la integracion
de los componentes desarrollados.
Testeo de Integración: En esta etapa se ejecutaran los casos de Pruebas y se sacaran
las evidencias correspondientes para poder validar la integridad de los datos. Donde se
tendra como entregable el siguiente artefacto:

Plantilla de Casos de Pruebas, Documento que permitira mapear los casos de
pruebas de las integraciones.

Plantilla de Evidencias de Pruebas, Documento que permitira mapear las
evidencias de la ejecucion de los casos de prueba.
Construcción de Capa de Acceso: En esta etapa se desarrollara el universo de datos
a la cual será consultada por los dashboard e informes que exploran su información del
datamart. Donde se tendra como entregable el siguiente artefacto:

Plantilla de Prueba Unitaria, Documento que contara con las evidencias de las
pruebas unitarias, el cual contemplara imagenes e descripciones que puedan
evidenciar estas pruebas hechas por el desarrollador para el componente
desarrollado.
Testeo de Capa de Acceso: En esta etapa se ejecutaran los casos de Pruebas y se
sacaran las evidencias correspondientes para poder validar la capa de acceso, validando
variables, variables calculadas e indicadores. Donde se tendra como entregable el
siguiente artefacto:

Plantilla de Casos de Pruebas, Documento que permitira mapear los casos de
pruebas de las integraciones.

Plantilla de Evidencias de Pruebas, Documento que permitira mapear las
evidencias de la ejecucion de los casos de prueba.
Construcción de BI: En esta etapa se realizara la construcción de los Dashboard e
Informes que usara el negocio para consultar al datamart. Donde se tendra como
entregable el siguiente artefacto:

Plantilla de Prueba Unitaria, Documento que contara con las evidencias de las
pruebas unitarias, el cual contemplara imagenes e descripciones que puedan
evidenciar estas pruebas hechas por el desarrollador para el componente
desarrollado.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
123 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Testeo de BI: En esta etapa se ejecutaran los casos de Pruebas y se sacaran las
evidencias correspondientes para poder validar los Dashboard e Informes. Donde se
tendra como entregable el siguiente artefacto:

Plantilla de Casos de Pruebas, Documento que permitira mapear los casos de
pruebas de las integraciones.

Plantilla de Evidencias de Pruebas, Documento que permitira mapear las
evidencias de la ejecucion de los casos de prueba.
Entrega: En esta etapa se realizara los preparativos para la entrega de la solución de
Datamart, Dashboards e Informes. Teniendo en cuenta el empaquetado de los
componentes. Donde se tendra como entregable el siguiente artefacto:

Plantilla de Manual de Instalación, Documento que permitira tener como guia de
como realizar la instalación del universo de datos.

Plantilla de Manual de Operación, Documento que se elaborara, en el caso de
que alla algun proceso que dependa de la ejecución paulatina de algun proceso del
datamart.

Plantilla de Manual de Configuración, Documento que se elaborar en el caso que
se tenga que solicitar alguna configuración especifica para el funcionamiento de un
componente de la Base de Datos o de la Aplicacion de BI.

Plantilla de Manual de Usuario, Documento que servira como guia rapida en el
uso de dashboard o informe que se considere como uso del usuario final.
Modelo Agile
Las metodologías ágiles son un conjunto de métodos basados en el desarrollo iterativo e
incremental de software, donde los requerimientos y soluciones evolucionan con el tiempo
según la necesidad del usuario. De esta manera, el trabajo es llevado a cabo mediante la
colaboración de equipos autoorganizados y multidisciplinarios, gestionando entre ellos un
proceso de toma de decisiones a corto plazo.
RELEASE
Requerimientos
Desarrollar
Grafico e
Informes
ETL
ITERACION 1
ITERACION 2
VALOR
VALOR
Entregar Valor
al Cliente
ITERACION 4
VALOR
VALOR
DATA
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
124 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS
Sprint o Iteración:
El ciclo de trabajo bajo el enfoque de la metodología Agil, parte los entregables en sprints o
iteraciones. Define las siguientes fases de desarrollo que, en mayor o menor medida,
deberían incluirse en cualquier proyecto de analíticas avanzadas.
A continuación se detalla las etapas del sprint o iteración que se elaboraran durante todo el
ciclo de vida del proyecto:
Comprensión del negocio: Esta fase inicial se centra en la comprensión de los objetivos
y requisitos del proyecto desde una perspectiva empresarial, y luego convertir este
conocimiento en una definición y un plan preliminar diseñado para alcanzar los objetivos.
Comprensión de Datos: Esta fase comienza con una colección inicial de datos y
procesos con actividades con el objetivo de familiarizarse con los datos, identificar la
calidad de los problemas, para descubrir las primeras señales dentro de los datos y
detectar temas interesantes para poder formular las hipótesis necesarias que ayudarán
en la definición de los procesos de analíticas.
Preparación de datos: Esta fase cubre todas las actividades para construir el conjunto
de datos necesarios para entrenar los modelos de analíticas avanzadas. Estas tareas son
ejecutadas en múltiples oportunidades y sin orden. Las tareas incluyen selección y
transformación de tablas, registros y atributos y limpieza de datos para las herramientas
de modelado.
Modelado: En esta fase se seleccionan y aplican varias técnicas de modelado y se
entrenan los modelos para resolver el problema en cuestión. Hay varias técnicas que
tienen requerimientos específicos para la formación de los datos, por lo que
frecuentemente es necesario volver a la fase de preparación de datos para aproximar el
problema desde un ángulo diferente.
Evaluación: En esta etapa en el proyecto ha construido un modelo (o modelos) que
parece tener gran calidad, desde una perspectiva de análisis de datos.
Despliegue: Esta fase depende de los requerimientos, pudiendo ser simple como la
generación de un dashboard, informe o compleja como la implementación de un proceso
de explotación de información que atraviese a toda la organización.
22/10/2021 | ©2021 Inetum | Of47094 CGR-21-FR-09-001
125 / Ошибка! Неизвестный аргумент ключа.
Clasificación: Documento confidencial
FÁBRICA DE SOFTWARE PARA LA IMPLEMENTACIÓN DE SUBSISTEMAS DEL SISTEMA INTEGRADO
DE LOS SERVICIOS DE CONTROL DE LA CGR Y OCIS