ORGANISMO SUPERVISOR DE CONTRATACIONES DEL ESTADO (OSCE)

El 00 xx xxxx xx 0000 xx Xxxxxxxx xx xx Xxxxxxxxx xxx Xxxx firmó el contrato xx xxxxxxxx 4428/OC-PE con el Banco Interamericano de Desarrollo (BID) para financiar el Proyecto, para la Mejora de la Eficiencia en la Gestión de la Inversión y las Contrataciones Públicas (PE-L1231) compuesto por los proyectos de inversión: “Mejoramiento de la gestión de la inversión pública”, a cargo del Ministerio de Economía y Finanzas; y “Mejoramiento de la Capacidad para la Generación del Conocimiento y Mejora Continua en la Gestión de la Contratación Pública”, a cargo del Organismo Supervisor de las Contrataciones del Estado (OSCE).

El proyecto a cargo del OSCE (en adelante El Proyecto) tiene como objetivo el mejoramiento para la capacidad para la generación del conocimiento y mejora continua en la gestión de la contratación pública dentro del ciclo de inversión pública.

El Proyecto está organizado en tres (03) componentes:

• Componente 1: Capacidad del marco institucional.

• Componente 2: Desarrollo e implementación de una plataforma de soporte al proceso de contratación orientado a la gestión por resultados y maximización del valor por el dinero.

• Componente 3: Capacidad del capital humano.

En el marco de este proyecto, las consultorías realizadas para el análisis, diseño y planificación de un modelo mejorado para la Contratación Pública han recomendado que el nuevo modelo sea soportado por una Plataforma Tecnológica que contemple un enfoque de componentes y servicios desplegados sobre un entorno de Nube Pública.

Se contempla una Plataforma Tecnológica que sirva de soporte a los distintos usuarios del ecosistema de la gestión de la contratación pública, basada en una arquitectura flexible, que integre de forma ágil a diferentes tipos de componentes que sean reutilizables en varias partes del proceso y que pueden evolucionar de forma independiente.

Algunos de los componentes podrán ser sistemas legados, o productos de software existente en sus modalidades de software comercial (COTS), software como servicio (SAAS) o software libre de fuente abierta (OPEN), mientras que otros componentes se desarrollarán a medida, tanto basado en un manejador de procesos de negocios (BPMS) como desarrollo local (LDSW).

El desarrollo a medida se requiere para componentes de soporte a la plataforma de contrataciones que está siendo desarrollada, entre ellos: construcción de proceso de migración de proveedores, migración de compradores, cargas iniciales de información, construcción de módulo de gestión de contrato de obra, entre otros, además del desarrollo de interfaces e integración con los sistemas internos y externos.

Por tal motivo, es necesaria la contratación del servicio de desarrollo de software que facilite la disposición de estos componentes con calidad, oportunidad y pertinencia.

2. OBJETIVO DEL SERVICIO

El objetivo de esta adquisición es contratar el servicio de desarrollo de software que permita gestionar las tareas de construcción de componentes de sistemas en las diferentes fases del ciclo de vida de desarrollo de software, de acuerdo a la metodología de desarrollo de software del OSCE.

3. ALCANCE DEL SERVICIO

Esta adquisición debe proveer el servicio de desarrollo de software. En este servicio se proveerán distintos productos de software empleando las mejores prácticas, metodologías, modelos, frameworks o patrones, entre otros, de acuerdo a la metodología de desarrollo de software provista por El Proyecto, de modo que pueda satisfacer los requerimientos de la nueva plataforma de contratación pública.

El proveedor deberá desarrollar los distintos productos de software que le sean solicitados, pudiendo estos requerir de todas las fases del ciclo de vida de desarrollo de software o alguna fase particular, como ejemplo, además de la construcción de soluciones, módulos o servicios, podría también solicitarse la elaboración de un prototipo, la actualización de un catálogo de componentes, entre otros.

Entre los productos que se podrán solicitar al proveedor, además del mantenimiento de los productos que desarrolle, también se contempla el mantenimiento a las aplicaciones, sistemas o componentes de software que se desplieguen en la plataforma que sean legados, adquiridos o desarrollados por terceros, considerando cada caso como un producto de software que será debidamente solicitado.

El servicio requerido contempla lo siguiente:

Item

Descripción

Unidad

Cantidad

Duración

Servicios de desarrollo de software

Horas- Hombre

15,000

Hasta el 20 xx xxxxxx 2024

Para todos los efectos de este documento, se tendrá en cuenta las siguientes referencias:

a) La “entidad” se refiere al OSCE a través de “El Proyecto”

b) El “oferente” o el “postor” se refiere a la firma que presenta la oferta

c) El “proveedor” se refiere al oferente que resulte adjudicado.

4. REQUISITOS DEL SERVICIO

El servicio debe cumplir con los requisitos que se detallan a continuación.

4.1. Marco metodológico para la gestión y provisión del servicio

El proveedor deberá emplear la metodología de desarrollo de software estandarizada en el proyecto, la cual está basada en los estándares y mejores prácticas de la industria nacionales e internacionales.

Con respecto a la gestión del servicio el proveedor deberá presentar en su propuesta una descripción general del marco metodológico de gestión del servicio que empleará, y debe abarcar los aspectos que se indican en el numeral 4.1.2

El proveedor que resulte adjudicado debe presentar el desarrollo detallado de este marco metodológico de gestión del servicio durante la etapa de configuración inicial del servicio (etapa preoperativa).

El marco metodológico debe abarcar los siguientes aspectos:

4.1.1. Metodología para el ciclo de vida de desarrollo de software

Es el conjunto de procesos que debe ejecutarse para producir software, es decir, para atender una solicitud de servicio. La secuencia, organización y alcance de las fases, en las que se ejecutan los procesos, está determinada por el modelo de ciclo de vida que siga el equipo de trabajo que atiende la solicitud de servicio y por las características de la solicitud de servicio.

La solicitud de servicio que implementa nuevas funcionalidades o características para un aplicativo de software o nuevos productos de software siempre ejecuta todos los procesos básicos del ciclo de vida de software. En función a las características de la solicitud de servicio, el nivel de detalle de cada proceso y las aprobaciones requeridas puede cambiar. Los procesos básicos que conforman el ciclo de vida de software son:

1- planificación

2- monitoreo y control

3- análisis de requerimientos 4- diseño

5- programación

6- pruebas de software

7- despliegue del software 8- gestión de configuración 9- verificación y validación

10- aseguramiento de la calidad de proceso

Si la solicitud de servicio sólo cambia funcionalidades o características, sólo corrige defectos o es del tipo mantenimiento de la operación, es posible que no requiera ejecutar alguno de estos procesos básicos.

La metodología de la entidad contempla el desarrollo de productos de software a través de los modelos de ciclo de vida del desarrollo: cascada, ágil con scrum, ágil con Kanban, híbrido, e Iterativo e incremental con RUP.

La metodología que la Entidad recomienda seguir es el ciclo de vida Ágil con Xxxxx.

a) Ágil con Scrum. Se planifica un roadmap del producto o productos, se elabora el product backlog, se planifica un conjunto de sprints, se elabora el diseño de la arquitectura y luego se inicia la ejecución de los sprints para implementar la solicitud de servicio o solicitudes de servicio relacionadas al producto o productos. Las fases son:

a. Planificación

b. Roadmap de producto, que debe incluir un producto mínimo viable y las fechas, hitos o sprints en los que se planifica liberar releases.

c. Product Backlog

d. Sprints planificados

e. Diseño de Arquitectura. Qué tan completo debe estar depende de la complejidad del producto a construir y de la experiencia previa exitosa del equipo en proyectos similares. Mientras menos complejo sea el producto y mientras mayor sea la experiencia del equipo en productos similares, menos completo puede estar el diseño de arquitectura para iniciar los sprints.

f. Sprint 1

i. En cada sprint se ejecutan los procesos de análisis de requerimientos, diseño y programación, para los requerimientos de software priorizados en dicho sprint de acuerdo con el objetivo del sprint. El proceso de pruebas de software también puede ejecutarse dentro de cada sprint. En el contexto de una fábrica de testing, el proceso de pruebas de software se ejecuta fuera de los sprints. Los pases a producción se pueden realizar en algunos sprints de acuerdo con el Roadmap de producto.

g. Sprint 2

h. Sprint n

En la figura que sigue se muestra las etapas, fases, procesos y entregables de la metodología de desarrollo de software.

Figura 1 Flujo general consolidado de trabajo del Servicio de Desarrollo de Software.

En la sección 6.2. “Artefactos y entregables por solicitud de servicio” se muestra el cuadro de entregables explicando cuáles aplican según el tipo y complejidad de la solicitud. Cabe señalar que no todos los entregables del flujo aplican a todas las solicitudes de servicio.

Por cada Solicitud:

- La entidad genera el Input 1 y lo envía al proveedor del servicio de desarrollo de software.

- El proveedor del servicio de desarrollo de software genera el Producto 1 y el Producto 2 antes de iniciar las iteraciones para implementar la solicitud.

- El proveedor del servicio de desarrollo de software genera el Producto 3, 4 y 5 en cada iteración hasta terminar la solicitud.

De forma continua en cada iteración el proveedor del servicio de desarrollo de software recibe los eventuales defectos detectados por la Fábrica de Testing y procede a resolverlos generando el Registro de Defectos actualizado. La resolución de un defecto puede implicar corregir el Análisis de Requerimientos, el Diseño Técnico y/o la Construcción.

Durante el servicio, el proveedor del servicio de desarrollo de software:

- Por cada iteración, genera el Plan de iteración y el Informe de Cierre de Iteración.

- Cada 15 días, por cada Solicitud no cerrada, genera el Informe del estado de la solicitud.

- Cada 15 días genera el Informe del estado del servicio.

4.1.2. Metodología para la gestión del servicio de desarrollo de los productos de software

Se debe proponer una metodología para la gestión de la construcción de los productos de software, la que debe incluir al menos los siguientes aspectos:

a) Estimación

Se debe emplear un procedimiento o herramienta de estimación que permita cuantificar el esfuerzo, tiempo y costo de cada producto de software a desarrollar y entregar; por ejemplo, metodologías basadas en puntos de historia de usuarios, puntos de casos de uso, puntos de función, técnicas basadas en juicios de expertos con métodos Delphi, planning poker, entre otras.

Cada producto debe tener un plan de trabajo aprobado por el Coordinador del Servicio que incluya un cronograma detallado de actividades y las horas hombre de los perfiles profesionales atribuibles a cada una de las actividades previstas en el plan.

b) Gestión del cronograma y avance

Establecer los mecanismos de colaboración permanente entre los equipos de coordinación técnica del servicio (descritos en la sección 4.2.2) para la revisión de los avances del plan de producción y planes de trabajo de cada producto de software y la toma de decisiones.

Se deben contemplar, por lo menos:

• Formato de actas de reuniones de seguimiento.

• Formato de reporte periódico con el estado y avance de los productos en desarrollo.

• Formato de reporte mensual con el cumplimiento de las actividades, tareas y cumplimento de los Acuerdos de Nivel de servicio para el periodo.

• Formato de seguimiento de la priorización, programación y ejecución del servicio.

c) Gestión de cambios en los requerimientos de los productos

Establecer los mecanismos de gestión de cambios cuando sean solicitados por el Gestor del Servicio sobre un requerimiento de producto.

d) Gestión de la calidad de los procesos de desarrollo y productos de software

Proponer un proceso de calidad que permita realizar el seguimiento y comprobación de la correcta aplicación del proceso de desarrollo de software y su mejora continua, así como de los artefactos producidos.

e) Transferencia de conocimiento

Establecer mecanismos que permitan la transferencia de conocimiento de cada una de las fases del ciclo de vida de desarrollo de software, de acuerdo con la metodología de desarrollo de software y siguiendo los lineamientos de gestión del servicio que se indican en la sección 4.2.6.

4.2. Gestión del Servicio de desarrollo de software

El proveedor deberá implantar un modelo de gestión que contemple los elementos del modelo de servicio de desarrollo de software que se muestra en la siguiente figura:

Figura 2 Modelo referencial del servicio de desarrollo de software.

Con base a este modelo se definen los elementos que se describen a continuación.

4.2.1. Gestión del servicio de desarrollo de software

El Equipo de Gestión del Proyecto BID (EGP) ejerce el control estratégico y constituye la instancia superior de toma de decisiones sobre El Proyecto.

El EGP designará a un Coordinador del Servicio de la Entidad, quien dirigirá el Equipo de Coordinación Técnica del Servicio y será el encargado de tomar las decisiones en los aspectos relativos a la ejecución del servicio. Esta designación se registrará en el Acta de Inicio del Servicio.

El equipo de Coordinación Técnica del Servicio será el encargado de realizar las coordinaciones con el proveedor para la ejecución satisfactoria del servicio. Estará a cargo de

un Coordinador del Servicio de la Entidad, designado por el EGP, y contará con la participación de un equipo de analistas y especialistas técnicos de la entidad.

El Coordinador del Servicio de la Entidad será quien otorgue la conformidad a las solicitudes de requerimientos de productos que le presente el Equipo de Coordinación Técnica (descrito en la sección 4.2.2) y tomará decisiones sobre cualquier aspecto que afecte el tiempo, costo o alcance de las correspondientes solicitudes de requerimiento de productos.

El Coordinador del Servicio será el encargado de otorgar la conformidad a artefactos y entregables de cada requerimiento de producto, de acuerdo con lo que se indica en la sección 6.3, “Revisión y conformidad de los entregables y artefactos”, esto en coordinación con el equipo de analistas y especialistas técnicos de la entidad.

El Coordinador del Servicio de la Entidad supervisa el avance y control del cronograma de atención de las solicitudes de servicios; analiza y evalúa los ajustes a los planes o sus eventuales mejoras o la inclusión de funcionalidades adicionales no contempladas inicialmente y si es pertinente coordina las acciones necesarias para su incorporación, gestionando si es necesario una solicitud de control de cambios o un nuevo requerimiento relacionado de ser el caso.

El Coordinador del Servicio de la Entidad supervisa el cumplimiento de los acuerdos de niveles de servicio

4.2.2. Coordinación técnica

El Equipo de Coordinación Técnica permanente se encargará de la gestión de los requerimientos y estará conformada por dos equipos conjuntos:

• Equipo de Coordinación Técnica de la Entidad

• Equipo de Coordinación Técnica del Proveedor

El equipo de coordinación técnica de la entidad estará a cargo de un Coordinador Técnico de la Entidad y contará con la asistencia de un equipo analistas y especialistas técnicos de la entidad.

El equipo de coordinación técnica del proveedor estará a cargo de Coordinador Técnico del Proveedor y contará con la asistencia de un equipo de especialistas técnicos del proveedor.

El Equipo de Coordinación Técnica del Proveedor debe estar disponible para realizar reuniones virtuales o presenciales, si son pertinentes, cuando el Equipo de Coordinación Técnica de la Entidad lo solicite y de igual forma de manera recíproca. Las reuniones se realizarán preferentemente dentro del horario de 8:30 am a 5:30 PM, de lunes a viernes.

Los roles mínimo-necesario del Equipo de Coordinación Técnica del Proveedor son los siguientes:

o El Coordinador técnico del servicio del Proveedor:

▪ Es el contacto oficial del proveedor con el equipo de coordinación técnica de la entidad. Responsable de la gestión del servicio que brinda el proveedor.

o Líder técnico de desarrollo de software

▪ Especialista que supervise el diseño y desarrollo de software

o Líder de calidad

▪ Especialista que supervise la calidad de los productos y las pruebas correspondientes

Los perfiles a quienes se asigna el rol de Coordinador Técnico del Servicio, Líder técnico de desarrollo de software y Líder de calidad, deberán cumplir con el perfil requerido en la sección 8.4.4, “Equipo de Trabajo del Proveedor”.

4.2.3. Gestión de necesidades de desarrollo de software

La gestión de necesidades de desarrollo de software es una función interna de la Entidad, fuera del ámbito del Servicio de Desarrollo de Software.

Sin embargo, es a partir de esta función que se identifican las necesidades de las áreas usuarias de la entidad y se convertirán en requisitos que luego serán organizados en solicitudes de servicio de desarrollo de software.

Esta función incluye actividades como: estudio de solicitudes de usuarios, reuniones y talleres de relevamiento de necesidades, coordinación con líderes funcionales, implantación de mesas de trabajo multidisciplinarias entre áreas técnicas y de negocio, entre otras.

La entidad contará con Equipos de Proyectos que estarán conformados por analistas técnicos y funcionales, así como arquitectos y especialistas, gestores de calidad y gestores de proyecto que trabajarán en conjunto con las áreas usuarias para identificar las necesidades y convertirlas en especificaciones de requisitos.

El equipo de coordinación técnica de la entidad trabajará en conjunto con los equipos de proyectos de la entidad y las áreas usuarias para especificar los requisitos, establecer sus alcances, priorizarlos, agruparlos y organizarlos en productos de software.

4.2.4. Productos de software

Un producto de software estará definido por un conjunto de requisitos especificados con la finalidad de satisfacer algunas necesidades identificadas por la entidad.

El desarrollo de un producto podrá requerir la aplicación de una o más fases del ciclo de vida del desarrollo de software, según se detalló en la sección 4.1.1

La metodología de la entidad contempla posibles escenarios basados en 6 variables:

1. Naturaleza del trabajo

o Desarrollo o mantenimiento de software

o Otros:

▪ Migraciones de datos o de tecnología

▪ Prueba de concepto, preanálisis / modelado de procesos o datos de negocio, estudio de factibilidad, investigación y exploración con prototipos, entre otros.

2. Tipo de solicitud de servicio

o Desarrollo o mantenimiento de software

▪ Desarrollo

▪ Desarrollo particionado Desarrollo – Requerimientos

Desarrollo – Diseño Desarrollo – Programación

▪ Mejora

▪ Mejora particionada

Mejora – Requerimientos Mejora – Diseño

Mejora – Programación

▪ Mantenimiento

▪ Correctivo

o Mantenimiento de la operación

▪ Modificar configuraciones

▪ Modificar datos en ambiente productivo

▪ Solicitud de reporte o extracción de información

3. Modelo del ciclo de vida a usar para atender la solicitud de servicio

o Cascada

o Ágil con Scrum / RUP (iterativo e incremental)

o Ágil con Kanban

o Híbrido

4. Complejidad

o Estándar

o Mayor complejidad. Por ejemplo,

▪ Varios conceptos operacionales, por ejemplo, funcionalidad o característica requerida debe estar presente en computadora y en smartphone

▪ Nueva tecnología

▪ Nuevo proceso de negocio

▪ Equipo que atiende la solicitud sin experiencia en dominio y/o tecnología

5. Rango de esfuerzo estimado

6. Equipo de Software

o Equipo interno

o Proveedor de desarrollo de software

o Servicio de fábrica de software con servicio de fábrica de testing

El detalle de los artefactos y entregables que se deriva de estos posibles escenarios se detalla en la sección 6.2.

4.2.5. Gestión de Solicitudes de Servicio de productos de desarrollo de software

Los productos de desarrollo de software serán requeridos por la Entidad al proveedor a través de solicitudes de servicio presentadas por el equipo de coordinación técnica de la entidad al equipo de coordinación técnica del proveedor.

Cada solicitud de servicio se definirá orientado al logro de un objetivo específico, dentro de un marco de temporalidad, alcance y esfuerzo, teniendo un inicio y un fin.

Las solicitudes de servicio estarán dadas por conjuntos de actividades enmarcadas en el ciclo de vida de desarrollo de software que generen los correspondientes artefactos o entregables.

El equipo de coordinación técnica y especialistas técnicos del proveedor trabajarán en conjunto con equipo de coordinación técnica de la entidad para estudiar el alcance de cada solicitud de servicio.

El proveedor presentará a la entidad una propuesta de atención a la solicitud presentada, presentando el plan de trabajo, el detalle de los artefactos o entregables a desarrollar, así

como el dimensionamiento de recursos por cada perfil profesional necesario en horas- hombre y los hitos de facturación correspondientes asociados a los artefactos o entregables que correspondan.

La gestión de las solicitudes de servicio también contempla la coordinación de la priorización, programación y ejecución del servicio, así como. el seguimiento y control de los planes de trabajo de cada servicio, la gestión de cambios, la gestión de la calidad y el proceso de entrega.

4.2.6. Transferencia de conocimientos

Los equipos de coordinación técnica de la entidad y del proveedor también coordinarán la transferencia de conocimientos necesaria entre las partes, en los siguientes aspectos:

i Para el conocimiento por parte del proveedor de las aplicaciones, sistemas o componentes de software desplegados o que se prevé desplegarlos en la plataforma de la entidad, que sean legados o que hayan sido desarrollados por terceros con códigos fuentes custodiados por la entidad

ii Para la capacitación funcional y técnica al personal de la entidad sobre las actividades realizadas, artefactos y entregables elaborados en cada una de las fases del ciclo de vida de desarrollo de software que se hayan ejecutado para la implementación del producto de software. La cantidad de horas de la capacitación funcional y técnica dependerá de la magnitud y complejidad del producto de software.

Las acciones de transferencia de conocimientos podrán ser contempladas como actividades dentro de los planes de trabajo de los servicios requeridos o constituir solicitudes de servicio específicas, si es pertinente.

4.2.7. Aprobación de solicitudes de servicio

La aprobación de la estimación, cronograma y plan de trabajo presentado por el proveedor a cada solicitud de servicio será otorgada, si corresponde, por el coordinador del servicio previa recomendación del equipo de coordinación técnica de la entidad.

4.2.8. Planeamiento de la ejecución del servicio

Las solicitudes de servicio que son aprobadas serán programadas para ser atendidas por el proveedor de acuerdo con la priorización y planificación que actualice mensualmente el equipo de coordinación técnica.

Para cada solicitud de servicio planificada, el proveedor deberá asignar al equipo técnico necesario, desarrollar las actividades pertinentes y elaborar los artefactos o entregables correspondientes.

4.2.9. Equipos de trabajo para atención de solicitudes de servicio

El proveedor deberá disponer de personal necesario para atender las solicitudes de servicio que se demanden, de acuerdo con la estimación de recursos prevista en la especificación de cada producto que se programe para su construcción. Este personal puede requerirse que

acuda a las oficinas de la entidad o que pueda trabajar desde las instalaciones del proveedor según se especifique en la respectiva solicitud.

El proveedor debe describir en su propuesta los principales tipos de perfiles profesionales con los que contará en sus equipos de trabajo para atender las solicitudes de servicio.

Entre los perfiles que el postor proponga, debe considerar necesariamente los siguientes perfiles:

• Jefe de Proyecto o similar (Rol de coordinador técnico)

• Arquitecto de software

• Analista líder de Calidad o similar (Rol de líder de calidad)

• Desarrollador senior

De acuerdo con el volumen de las solicitudes de servicio, el proveedor deberá asignar al equipo técnico necesario para desarrollar los productos que se programen, contemplando las actividades pertinentes y los artefactos correspondientes.

El proveedor debe contar con una capacidad de desarrollo para disponer de al menos cuatro equipos de desarrollo de productos en simultáneo.

4.2.10. Ambientes tecnológicos para el desarrollo y despliegue de los productos

La nueva Plataforma Tecnológica de la Compra Pública será desplegada sobre una nube pública y contará con al menos cuatro ambientes tecnológicos o entornos que serán suministrados por la entidad:

• Ambientes de Desarrollo

(i) Ambiente de desarrollo de componentes y pruebas unitarias

(ii) Ambiente de integración y pruebas funcionales

• Ambiente de Certificación

• Ambiente de Producción

Para la construcción de los productos de software, la entidad brindará al proveedor durante la prestación del servicio el acceso a los Ambientes de Desarrollo, que incluye un ambiente para desarrollo de componentes y pruebas unitarias y un ambiente de Integración y pruebas funcionales.

El proveedor adjudicado debe cumplir estrictamente con las políticas, procesos, procedimientos, protocolos de seguridad establecidos por la entidad para acceder y conectarse a los ambientes tecnológicos provistos por la entidad para la prestación del servicio.

4.2.11. Revisión de la entrega y conformidad de los productos

Cada solicitud de servicio atendida por el proveedor comprenderá un conjunto de artefactos y entregables cuya conformidad será emitida por el Coordinador del Servicio y el apoyo del equipo de coordinación técnica, de acuerdo con lo especificado en la sección 6.3, “Revisión y conformidad de los entregables y artefactos”.

Si un artefacto o entregable es observado, el proveedor deberá subsanarlo en el plazo que se le indique y volver a solicitar la conformidad.

No se contabilizan como parte de las horas del servicio a las horas-hombre dedicadas a la corrección de errores o subsanaciones de los artefactos o entregables observados.

Al completarse la conformidad de la totalidad de los artefactos y entregables previstos para un producto, se otorgará la aceptación definitiva correspondiente y se iniciará el período de garantía del producto.

4.2.12. Garantía del servicio de desarrollo

Por cada solicitud de servicio atendida por el proveedor, el periodo de garantía es de doce

(12) meses, contados a partir de la fecha en que el producto recibe la conformidad de la entidad. Durante este periodo el proveedor debe cumplir sin costo adicional con las siguientes condiciones:

• Resolver los incidentes y problemas detectados durante el periodo de garantía que se presenten con cada producto realizado por la fábrica, dentro de los tiempos acordados en los acuerdos de nivel de servicio (ANS) y sin cargo adicional para la entidad.

• Realizar la corrección de defectos derivados de las fases y actividades contempladas en cada producto encomendado.

• Participar en reuniones periódicas para hacer seguimiento a la atención y solución de incidentes de las aplicaciones y productos de software objeto del contrato.

• Actualizar la documentación de los productos de software, reflejando las características y funcionalidades actualizadas como resultado de la corrección de defectos, resolución de problemas o incidencias.

• Presentar un “Informe de cierre de garantía” el cual deberá contener la información sobre incidentes resueltos, precisando, entre otros, el origen de la falla o el error, impacto de incidencia, acciones realizadas para solución definitiva, así precisar qué clases, recursos, objetos de base de datos u otros fueron modificados para su solución.

4.2.13. Propiedad intelectual de los productos, artefactos y entregables.

Todo el material creado, producido o desarrollado por el proveedor para la entidad durante la prestación del servicio, como documentos de análisis y diseño, casos de prueba, código fuente, scripts de pruebas de software, entre otros, serán de propiedad de la entidad.

En caso de que el proveedor provea componentes de software previamente elaborados, debe entregar a la entidad el código fuente con una licencia que le otorgue a la entidad los derechos de uso, copia, adaptación y modificación a perpetuidad sin incurrir en costos adicionales y sin perder los derechos patrimoniales.

4.2.14. Atención de Incidencias

Las interrupciones no planificadas que generan un fallo o error en los productos desarrollados o componentes bajos requerimientos de mantenimiento en la plataforma y ameritan una

respuesta urgente se considerarán “incidencias” y constituirán un tipo de producto especial que debe ser atendido por el proveedor.

Para la atención de cada incidencia, el proveedor deberá realizar actividades que permitan determinar el origen de la falla o el error, así como la respectiva corrección definitiva. Deberá considerarse la resolución de los problemas generados por el fallo o error, directos o indirectos, así como el análisis del origen de la incidencia y la ejecución de los posibles mecanismos de prevención o mitigación definitiva.

La atención de incidencias originadas por fallas o errores de productos dentro de sus períodos de garantía no incurren en costos adicionales.

4.2.15. Recursos y herramientas para la gestión del servicio de desarrollo de software

El proveedor es responsable de asegurar que sus profesionales cuenten con los equipos de cómputo, así como los ambientes físicos o remotos pertinentes para conectarse a la plataforma tecnológica en nube de la entidad.

Además, deberá contar con al menos las siguientes herramientas tecnológicas automatizadas para soportar la gestión, seguimiento y control del ciclo de vida de desarrollo de software:

• Herramientas para gestión de proyectos (ej. MS-Project).

• Herramientas para la gestión del ciclo de vida de las aplicaciones (ej. Jira)

• Herramientas para la gestión de defectos, incidentes y problemas (ej. Jira)

• Herramientas para la gestión de versiones de los productos de software (ej. Gitlab, bitbucket)

De acuerdo con lo indicado en la sección 4.5, Cumplimiento de los requisitos del servicio, la entidad podrá realizar Inspecciones y Pruebas para comprobar la aplicación de estas herramientas en cualquier momento durante la vigencia del contrato, en forma aleatoria o periódica, según se requiera, y el proveedor deberá brindar las facilidades necesarias para tal efecto.

4.3. Arquitectura de los productos de software

4.3.1. Arquitectura de componentes

La arquitectura de la nueva plataforma de adquisiciones (descrita como referencial en este documento) está prevista para operar de forma integral en la Nube Pública a través de la utilización de componentes, gestión de API´s y desarrollos basados en microservicios. Se prevé aprovechar las ventajas de la nube en términos de flexibilidad, eficiencia, escalabilidad y costos. Sin embargo, algunos de los componentes de la plataforma podrán ser adquiridos como productos de software comerciales o constituir sistemas legados que podrán requerir ser instalados bajo arquitecturas legadas de acuerdo con requerimientos específicos sobre plataformas IaaS o PaaS.

Entre los productos previstos para ser desarrollados por el proveedor se encuentran los siguientes:

• Migración de Proveedores

• Migración de Compradores

• Carga Inicial de catálogo CUBSO

• Mantenimiento de aplicaciones

• Gestión de Contrato de Obra

Esta relación es referencial, podrán añadirse o sustituirse productos según sean identificados por el Equipo de Gestión del Proyecto.

4.3.2. Arquitectura tecnológica

El conjunto de tecnologías a utilizar en la Entidad y que sirve de referencia para los servicios a desarrollar se muestran en la siguiente figura:

Figura 3 Stack tecnológico referencial para el desarrollo de productos de software

Para los nuevos desarrollos se contempla el uso de api manager como componente de exposición de APIs hacia los canales que tiene la OSCE, permite integrar distintos aplicativos mediante interfaces en JSON y XMLs. El api manager tiene las siguientes funcionalidades:

• Exposición de apis mediante el uso xx xxxxxxx u openapi

• Asegurar las apis con diferentes mecanismos de seguridad: whitelist, cors filter, client certificate, jwt, api key, SAML y OAUTH.

• Publicar solo apis sin tener exponer más servicios o puertos que no son necesarios.

Se debe contemplar también atenciones relacionadas a componentes legados basados en los elementos siguientes:

a) Front / Negocio: Apache – Java JBoss, Oracle Web Logic, IIS, ASP

b) Base Datos: Oracle Enterprise, MS SQLServer

c) Sistema Operativo: Linux / RedHat, Windows Server

En la fase de configuración inicial del servicio se detallará con precisión la arquitectura tecnológica que se empleará para el desarrollo de los productos.

4.4. Acuerdos de nivel de servicio (ANS)

Las actividades desarrolladas por el proveedor deberán cumplir con los Acuerdos de Niveles de Servicio (ANS) que establezca la entidad, considerando los siguientes:

(i) ANS para atención de incidencias

(ii) ANS para atención de entregables o artefactos del servicio

(iii) ANS para subsanación de errores u observaciones en los entregables o artefactos del servicio

4.4.1. ANS para atención de incidencias

Las incidencias que se produzcan sobre los productos de software desarrollados que se encuentren en producción durante el tiempo de estabilización o garantía se catalogarán en dos niveles de criticidad, según los parámetros siguientes:

Tipo de Servicio

Descripción

XXXXX 0

Criticidad Alta

Cuando la incidencia afecta a productos desarrollados que se encuentran en producción con los siguientes impactos:

- Dificultades que experimentan los usuarios o procesos y que causan una parada en el trabajo que impacta en los procesos críticos de negocio de la Entidad.

- El error que se presenta en alguna de sus funcionalidades del producto impide completar el proceso que se está ejecutando.

XXXXX 0

Criticidad Baja

Cuando la incidencia afecta a productos desarrollados que se encuentran en producción con los siguientes impactos:

- Dificultades que experimentan los usuarios que limitan la funcionalidad del aplicativo, no impactando en los procesos críticos del negocio.

- El error que se presenta en alguna de sus funcionalidades del producto puede ser resuelto por una funcionalidad alternativa y no impide completar el proceso que se está ejecutando.

Parámetros del ANS

Tiempo de contacto (TC)

Se inicia cuando el proveedor es notificado de una incidencia y

concluye cuando se pone en contacto con la Entidad

Tiempo de respuesta (TR)

Se inicia cuando el proveedor es notificado de una incidencia y

concluye con la respuesta cualificada que deberá incluir la estimación del tiempo de recuperación del servicio.

Tiempo de recuperación del servicio (TRS)

Se contabiliza desde que el proveedor es notificado de una incidencia hasta que el servicio es restablecido.

Factor de desviación en el tiempo de atención

(Exceso en el Tiempo de Atención respecto al Tiempo máximo comprometido) / (Tiempo máximo comprometido) x 100%

Unidad Impositiva Tributaria (UIT)

Monto monetario de referencia en el Perú para tributos

Horario de Atención

24 horas al día todos los días del año, sin excepción

Criticidad

Tiempo de atención

máximo comprometido

Penalidad por incumplimiento en cada incidencia

TRS

NIVEL 1

minutos

2 horas

1 día

• 10% de una UIT si la suma de los factores de desviación en los tiempos TC y TR es mayor a 20%

• 30% adicional de UIT por cada día de atraso en el TRS

XXXXX 0

minutos

4 horas

4 días

• 10% de una UIT si la suma de los factores de desviación en los tiempos TC y TR es mayor a 20%

• 20% adicional de UIT por cada día de atraso en el TRS

Las incidencias originadas por productos que no hayan sido desarrollados por el proveedor serán atendidas según los niveles de servicio acordados en cada tipo de solicitud de servicios correspondiente.

4.4.2. ANS para tiempos de atención de entregables o artefactos del servicio

Definición de los plazos de atención:

Definición de Tiempos de Atención
Tiempo de entrega comprometido	Tiempo de entrega comprometido del entregable o artefacto
Tiempo de entrega	Tiempo de entrega real del entregable o artefacto
F = Factor de Desviación en el tiempo de entrega	(Exceso de Tiempo de entrega atribuible al proveedor respecto al Tiempo de entrega comprometido) / (Tiempo de entrega comprometido)

Penalidad por Incumplimiento

- Si F está entre 20% y 30% : 5% de la valorización del

entregable o artefacto

- Si F está entre 30% y 50% : 10% de la valorización del

entregable o artefacto

- Si F > = 50% : 30% de la valorización del entregable o artefacto

4.4.3. ANS para subsanación de errores u observaciones en entregables o artefactos del servicio

La firma proveedora debe cumplir con la corrección de errores o el levantamiento de observaciones solicitados, sobre el mismo alcance, en el proceso de aprobación de los entregables y artefactos, bajo el siguiente acuerdo de nivel de servicios:

ANS	Parámetro	Penalidad
	En caso de persistir
Cumplimiento en la atención de subsanaciones por errores u observaciones	errores u observaciones luego de dos iteraciones de solicitudes de subsanación por el mismo	10% de la valorización del entregable o artefacto por cada solicitud de subsanación adicional
	entregable o artefacto

Las iteraciones de las solicitudes de subsanación por el mismo entregable o artefacto no contemplan las que se efectúen por efecto de solicitudes de cambio aprobadas.

4.4.4. Aplicación de penalidades

Para la aplicación de penalidades, la entidad informará por escrito mensualmente al proveedor sobre los incumplimientos de los acuerdos de nivel de servicios (ANS), el cual tendrá un plazo de siete (7) días calendario para efectuar su descargo.

La evaluación del descargo será realizada por la entidad y el resultado será comunicado por escrito al proveedor. Si el descargo no es aceptado, se procederá a ejecutar la penalidad.

El cobro de las penalidades se aplicará sobre cualquier facturación que se realice al proveedor, luego de haber sido aprobada la penalidad, en el marco del mismo contrato.

Si el monto de penalidades acumuladas supera el 10% del monto total del contrato, durante la ejecución del mismo, la entidad podrá resolver el contrato.

4.5. Cumplimiento de los requisitos del servicio

El proveedor adjudicado debe satisfacer el cumplimiento de los requisitos del servicio en todo momento durante la vigencia del contrato.

La entidad podrá realizar Inspecciones y Pruebas para comprobar el cumplimiento de los requisitos del servicio, en cualquier momento durante la vigencia del contrato, en forma aleatoria o periódica, según se requiera, y el proveedor deberá brindar las facilidades necesarias para tal efecto.

Para acreditar el cumplimiento de los requisitos del servicio el proveedor puede presentar prueba documental que podrá consistir en informes, evaluaciones o mediciones propias o de terceros, licencias, entre otros.

El hallazgo de cualquier situación anómala que implique el incumplimiento de los requisitos del servicio será comunicado por escrito al proveedor, otorgándole un plazo no menor a (15) días calendario para efectuar su descargo o subsanar la situación anómala.

La evaluación del descargo o de la subsanación de la situación anómala detectada será realizada por la entidad y el resultado será comunicado por escrito al proveedor. Si el descargo no es aceptado o no ha sido subsanada la situación anómala, la entidad podrá resolver el contrato.

5. ETAPAS DEL SERVICIO

Las etapas que conforman el servicio son las siguientes:

5.1. Configuración inicial (pre operativa)

a) La Etapa de configuración inicial se inicia el primer día hábil posterior a la firma del contrato con una duración de 15 días.

b) La primera actividad de esta etapa será la reunión y firma del Acta de Inicio del Servicio (kick off). En esta reunión se presentarán y se registrará en el Acta la identificación de los roles Coordinador del Servicio de la Entidad, el Coordinador Técnico del Proveedor, así como la definición de contactos y mecanismos de comunicación entre ambas partes.

c) Dentro de los primeros 7 días de esta etapa, el Coordinador Técnico del Proveedor debe coordinar con el Coordinador de Servicio de la Entidad la revisión y entrega de los siguientes documentos:

i. Documento detallado del Marco Metodológico para la gestión y operación del servicio, de acuerdo con los requisitos descritos en la sección 1.

ii. Informe de disponibilidad y configuración de los recursos y herramientas descritos en la sección 4.2.15

Los entregables serán evaluados por el Coordinación del Servicio con el apoyo del equipo de coordinación técnica y si se realizan observaciones, el proveedor debe levantarlas en el plazo señalado por la Entidad de acuerdo con el nivel de complejidad.

d) En los primeros 7 días de esta etapa, el Coordinador de servicio Entidad debe coordinar con el Coordinador Técnico del Proveedor la revisión y entregar los siguientes documentos:

i. Documento que detalla la base tecnológica prevista para el desarrollo de los productos de software.

ii. Informe de disponibilidad y procedimientos de acceso a los recursos y ambientes de desarrollo en la nube de la entidad.

Ambas partes deben firmar un acta de acuerdo sobre estos documentos para proceder a la etapa de operación.

5.2. Operación

a) Tendrá una duración hasta el 20 xx xxxxxx del 2024 o hasta que se consuman las horas contratadas o hasta que se alcance el monto máximo del contrato adjudicado.

b) Se inicia a partir del día siguiente de otorgada la conformidad a los entregables de la etapa de configuración inicial. Se generará un acta de Inicio de la Etapa de Operación.

c) En esta etapa, el coordinador del servicio de la entidad realizará la gestión de las solicitudes de servicios y el proveedor atenderá las solicitudes de servicio.

5.3. Transición de salida

a) La transición de salida se iniciará treinta (30) días antes de la finalización del plazo máximo previsto del contrato o cuando se hayan consumido más del 90% de las horas contratadas, lo que ocurra primero.

b) Esta etapa tendrá una duración de treinta (30) días calendarios y no generará ningún costo de horas-hombre. Mientras se realiza el proceso de transición, el servicio sigue ejecutándose sin interrupciones y los entregables deberán ser presentados según los plazos establecidos en los requerimientos de productos que se encuentren en desarrollo.

c) Esta etapa permitirá la realización de la transferencia del entorno del servicio a la Entidad o a un nuevo proveedor, según corresponda, realizándose, entre otras, actividades como:

i. Informe de entrega del servicio a la Entidad

ii. Informe final del servicio que detalle las actividades realizadas en esta etapa, acompañado de todos los activos de software generados durante la ejecución del servicio.

iii. Entrega de toda información creada, mejorada, modificada, generada y recibida durante toda la ejecución del servicio, que no se encuentre mencionada anteriormente y que es propiedad de la Entidad en todos sus extremos.

iv. Entrega de toda la data generada en las herramientas de software de soporte y gestión, en formato de exportación.

d) En casos de situación de fuerza mayor o casos fortuitos, durante la ejecución del servicio, la Entidad podrá modificar o hacerse cargo de una o varias fases de los requerimientos del servicio, previa coordinación oportuna con el proveedor adjudicado, tomando en cuenta los mismos procedimientos y requisitos para la terminación del contrato establecidos en las condiciones generales del contrato.

6. ENTREGABLES DEL SERVICIO

En las fases del servicio se contarán con los siguientes entregables

6.1. Entregables de gestión del servicio

6.1.1. Etapa de configuración inicial

Entregables de esta etapa	Plazo Máximo
Acta de Inicio del Servicio	Día 1 (kick off)
Documento detallado del Marco Metodológico para la gestión y operación del servicio	Hasta los 7 días de iniciado el servicio, presentación por correo electrónico
Informe de disponibilidad y configuración de los recursos y herramientas para el soporte y la gestión del servicio	Hasta los 15 días de iniciado el servicio

• Los 3 entregables deberá ser enviado máximo a los 15 días de iniciado el servicio por mesa de parte de la entidad.

6.1.2. Etapa de operación

• Informes mensuales de los servicios que debe incluir:

o Informe de estado de solicitudes de servicio: solicitados, aprobados, planificados, en proceso y concluidos en el período.

o Informe de estado de gestión de cambios de solicitudes de servicio.

o Informe de priorización y planeamiento de la atención del servicio para los próximos 90 días.

o Informe de atención de incidencias, cumplimiento de Acuerdos de Nivel de Servicio y penalidades aplicadas.

o Informe de resumen de avance de cada solicitud de servicios en curso, indicando fechas planificadas para entrega de artefactos o entregables, consumo y costos de recursos asociados.

o Reporte de horas hombre de servicios profesionales consumidos por artefactos o entregables de solicitudes de servicio concluidos y aprobados en el mes.

• El detalle de los informes mensuales podrá ser ajustado de acuerdo con el marco metodológico de gestión y operación del servicio que se apruebe en la etapa de configuración inicial.

6.1.3. Etapa de transición de salida

• Informe de entrega del servicio a la Entidad, que incluye:

o Informe final del servicio que detalle las actividades realizadas en esta etapa, acompañado de todos los activos generados durante la ejecución del servicio.

o Entrega de toda información creada, mejorada, modificada, generada y recibida durante toda la ejecución del servicio, que no se encuentre mencionada anteriormente y que es propiedad de la Entidad en todos sus extremos.

o Entrega de toda la data generada en las herramientas de software de soporte y gestión, en formato de exportación.

6.2. Artefactos y entregables por solicitud de servicio

Se indican los artefactos y entregables mínimos de acuerdo con las fases del ciclo de vida de desarrollo de software que estén especificadas en la solicitud de servicio.

Cuadro de Entregables por Tipo de Solicitud de Desarrollo de Software
R=Responsable			Leyenda: SI = entregable es requerido COND1=el entregable se elabora sólo si la solicitud requiere modificar o crear alguna pantalla COND2=el entregable se elabora sólo si la solicitud requiere modificar o crear Manual del Usuario	Tipo de Solicitud
Servicio Desarrollo de Software	Centro de Desarrollo (equipo técnico PBID)	Entregables Input es enviado por la Entidad (El Proyecto) al Proveedor del Servicio de Desarrollo de Software Producto es generado por el Servicio de Desarrollo de Softare		DESARROLLO o MEJORA	MANTENIMIENTO		CORRECTIVO
Servicio Desarrollo de Software	Centro de Desarrollo (equipo técnico PBID)		Complejidad Alta:		SI	NO	SI	NO
	R	Input 1	Solicitud	SI	SI	SI	SI	SI
	R		Informe Fase Cero	SI	SI		SI
	R		Guía Preliminar de Arquitectura	SI	SI		SI
	R		Estrategia de Mitigación de Riesgos	SI	SI		SI
R		Producto 1	Estimación de la solicitud	SI	SI	SI	SI	SI
R			Cronograma de la solicitud	SI	SI	SI	SI	SI
R			Product Backlog (de la Solicitud)			SI	SI	SI
R		Producto 2	Product Backlog (de la Solicitud)	SI	SI
R			Diseño Técnico (del Producto Mínimo Viable PMV)	SI	SI
R			Prototipo y Diseño de Experiencia de Usuario (del PMV)	COND1	COND1
R			Plan de Trabajo	SI	SI
R		Producto 3	Especificación de requerimientos	SI	SI	SI	SI	SI
R		Producto 3	Prototipo y Diseño de Experiencia de Usuario (actualizado)	COND1	COND1	COND1	COND1	COND1
R		Producto 4	Diseño Técnico	SI	SI	SI	SI	SI
R		Producto 5	Código software	SI	SI	SI	SI	SI
R			Manual de Usuario	COND2	COND2	COND2	COND2	COND2
R			Instructivo de Pase a Producción	SI	SI	SI	SI	SI
R			Informe de pruebas de desarrollo	SI	SI	SI	SI	SI
R			Catálogo de Componentes	SI	SI	SI	SI	SI
R		Producto 12	Registro de defectos actualizado	Defectos enviados por Fábrica de Testing
R		Plan de iteración
R			Informe de cierre de iteración
R			Informe del estado de la solicitud
R			Informe del estado del servicio

6.2.1. Fase de planificación – Producto 1

• Estimaciones.

Contiene las estimaciones para realizar el trabajo.

- Estimación del alcance, que incluye:

o El conjunto de requerimientos de software a alto nivel a implementar

o Los entregables de esta solicitud

- Estimación del esfuerzo, incluyendo horas por perfiles profesionales a utilizar para completar la solicitud, correspondiente a los procesos de planificación, monitoreo y control, análisis de requerimientos, diseño, programación, despliegue del software, gestión de configuración, verificación y validación y aseguramiento de la calidad de proceso.

• Cronograma

-Las actividades planificadas del ciclo de vida del software para la solicitud, agrupadas de acuerdo con el modelo de ciclo de vida en fases o en iteraciones, con responsables asignados, fechas estimadas de inicio y fin, a un nivel de detalle que permite realizar seguimiento oportuno y detectar posibles desviaciones de forma oportuna.

• Product Backlog. Contiene el alcance de la solicitud en forma de una lista de ítems.

- La lista de ítems de lo que se necesita hacer para lograr el objetivo de la solicitud.

o Usualmente en la forma de historias de usuario (requerimientos de software, funcionales y no funcionales) y tareas

o Cada ítem tiene:

▪ Una descripción, que incluye el rol que usará esta funcionalidad o característica

▪ Prioridad

▪ Estimación del tamaño o complejidad

▪ Sprint en el que está planificado implementarse

SPRINT CERO – Producto 2

• Product Backlog. Contiene el alcance de la solicitud en forma de una lista de ítems.

- La lista de ítems de lo que se necesita hacer para lograr el objetivo de la solicitud.

o Usualmente en la forma de historias de usuario (requerimientos de software, funcionales y no funcionales) y tareas

o Cada ítem tiene:

▪ Una descripción, que incluye el rol que usará esta funcionalidad o característica

▪ Prioridad

▪ Estimación del tamaño o complejidad

▪ Sprint en el que está planificado implementarse

• Plan de la iteración. Contiene el plan específico para la iteración que comienza.

- Objetivo de la iteración (sprint), es decir, qué se desea lograr en la iteración

- La lista de ítems seleccionados del Product Backlog para esta iteración (sprint)

- Un plan de trabajo que muestra cómo se entregará el incremento y que permite entender el progreso a lo largo de la iteración (sprint) en la reunión diaria (Daily Scrum)

• Prototipo validado y Diseño de la Experiencia de Usuario del producto mínimo viable.

• Plan de trabajo

- El modelo de ciclo de vida a seguir.

- Hitos

- Capacitación o inducciones necesarias para el equipo de trabajo

- Cronograma adjunto

- Organización del equipo de trabajo, roles y responsabilidades

- Partes interesadas involucradas, cliente, usuarios finales, roles y responsabilidades

- Riesgos y dependencias

- Descripción del entorno de trabajo necesario

6.2.2. Fase de Análisis de Requerimientos – Producto 3

• Análisis de Requerimientos, especificaciones de requerimientos, casos de uso o historias de usuario. Contiene la lista de especificaciones de requerimientos de software (historias de usuario o casos de uso) de la solicitud (para el modelo de ciclo de vida cascada) o para la iteración (para el modelo de ciclo de vida Ágil).

• Prototipo validado. Es una implementación de la parte visible del producto de software que resultará de la solicitud y que sirve para confirmar el entendimiento del alcance y de los requerimientos de software de la solicitud.

6.2.3. Fases de diseño técnico – Producto 4

• Fase de diseño Técnico

o Documento de diseño Técnico. Debe incluir diseño arquitectónico, diseño detallado de los componentes, la arquitectura, seguridad, interfaces y demás características del producto. Modelo físico de datos, diccionario de datos. Además de la definición de los casos de prueba necesarios para la certificación.

o Ficha técnica de desarrollo – Ingeniería. Debe incluir, por ejemplo: IDE desarrollo Front y Back End, IDE repositorio de datos, IDE diseño de software, herramientas para repositorio de software, tecnologías front y back end, plataforma de aplicaciones, repositorio de código fuente, revisión de código fuente, entre otros.

o Ficha técnica de desarrollo para cada ambiente. Debe incluir, por ejemplo: base de datos (base, esquemas, roles y usuarios), almacenamiento (directorios de recursos externos, configuración, archivos), directorios de logs, servidor de aplicaciones (clusters, datasources), infraestructura necesaria (cuentas de correo, recaptcha v3, Google analytics, etc.)

6.2.4. Fase de Construcción – Producto 5

• Código software. Es el código software creado o modificado tanto el código fuente como el código ejecutable que se instala en ambiente productivo. Usualmente el código software está controlado en una herramienta de gestión como GitHub o similar.

• Manual de Usuario. Es una descripción de cómo usar el producto software resultado de la solicitud. Incluye todas las funcionalidades y características que tiene el software producido en la solicitud.

• Manual de Pase a entre ambientes. Es un manual que contiene las instrucciones para realizar el pase del código software a ambientes superiores, es decir, los pasos detallados para que el rol responsable proceda a instalar el producto de software resultado de la solicitud. Incluye los pasos para revertir la instalación en caso sea necesario.

• Librería de componentes y servicios reutilizables. Es un repositorio con los componentes, servicios, objetos, scripts de software, porciones de líneas de código software que implementan funcionalidades y características comunes que están disponibles a ser reutilizados en siguientes solicitudes junto con explicaciones de cómo usarlos o invocarlos.

• Informe de revisión de pares de código software. Contiene el resultado de ejecutar un checklist para evaluar una porción de código software y detectar defectos de forma temprana, incluye también los posibles defectos identificados, el estado de resolución de los defectos, los datos básicos de la revisión como el revisor, el autor del código software revisado, la fecha de la revisión y el resultado de la decisión final de la revisión.

• Casos de prueba de desarrollo. Es la lista de escenarios y condiciones esenciales que el desarrollador verifica ejecutando el software para considerar que el software que ha producido está listo y terminado y puede continuar el siguiente proceso de pruebas de software. Se elaboran con base en los requerimientos de software funcionales, no funcionales y el diseño técnico.

o Informe de pruebas de desarrollo. Es una descripción del resultado de las pruebas de software esenciales que ejecutó el desarrollador. Describe las pruebas realizadas, los defectos encontrados, conclusiones, propuestas para realizar análisis causa raíz y propuestas para mejorar el checklist para realizar revisiones de pares de código software. Incluye: Validación de cumplimiento de estructura de base de datos

o Validación de arquitectura de software

o Validación de estándares de presentación y de usabilidad (UX)

o Análisis estático de código fuente (Cero bugs, cero vulnerabilidades). Coordinar umbrales y compuertas de calidad con la entidad

• Informe de auditoría de entregable. Es el resultado de revisar un entregable antes de enviarlo al cliente para su aprobación. Contiene los entregables revisados, fecha, esfuerzo invertido, revisor, observaciones identificadas, estado de resolución de las observaciones y conclusiones.

6.2.5. Validación de la entrega

El proveedor del servicio facilitará la validación de los productos de software:

• Validación técnica por la entidad

o Validación de cumplimiento de estructura de base de datos

o Validación de arquitectura de software

o Validación de estándares de presentación y de usabilidad (UX)

• Pruebas funcionales

o Pruebas sobre el producto con los actores funcionales

o Validación del alcance y aceptación funcional

• Empaquetado

o Entrega de artefactos empaquetados e instrucciones de despliegue o instalación, según corresponda

6.2.6. Fase de Pruebas de Software

• Plan de pruebas

• Casos de prueba

• Matriz de defectos

• Informe de pruebas

• Informe de análisis causa raíz

a Estos artefactos corresponden a la fábrica de testing. Durante esta fase, el proveedor de servicio de desarrollo: Monitoreo de los resultados de las pruebas de certificación

b Si existen observaciones, se deben subsanar y retornar a la fase de entrega

6.2.7. Fase de Despliegue del Software

• Informe de despliegue

• Nueva línea base de código de software.

Durante esta fase, el proveedor de servicio de desarrollo:

a Monitoreo de los resultados del pase entre ambientes.

b Si existen observaciones, se deben subsanar y retornar a la fase de entrega

6.2.8. Fase de monitoreo y estabilización

• Informes de monitoreo del comportamiento durante el periodo convenido en el plan de trabajo del producto

• Ejecución de trasferencia de conocimiento de acuerdo con el plan de trabajo del producto

• Atención de incidencias y solicitudes de mantenimiento correctivo durante período de estabilización y garantía

• Presentar un “Informe de cierre de monitoreo y estabilización” el cual deberá contener la información sobre incidentes resueltos, precisando, entre otros, el origen de la falla o el error, impacto de incidencia, acciones realizadas para solución definitiva, así precisar qué clases, recursos, objetos de base de datos u otros fueron modificados para su solución.

• Realizar una reunión de cierre de monitoreo y estabilización en la cual el proveedor informe a la entidad sobre las incidencias más relevantes que haya corregido.

6.2.9. Fase de Aseguramiento de la Calidad del Proceso

• Informe de revisión de aseguramiento de la calidad del proceso de desarrollo de software. Es el informe resultado de una revisión o auditoria de proceso interna que realiza el proveedor de servicios de desarrollo de software a su equipo de trabajo para verificar que su equipo sigue los procesos estándares establecidos, registrar las eventuales no conformidades y tomar acciones para resolver las posibles no conformidades.

6.2.10. Fase de monitoreo y control

• Informe del progreso y estado de la solicitud de servicio. Contiene información del grado de progreso, las posibles desviaciones significativas y las acciones correctivas a tomar.

o Riesgos y dependencias identificados y su análisis

o Para el modelo del ciclo de vida cascada:

Grado de progreso. Alguna o varias de las siguientes:

- Comparación del registro del esfuerzo real versus la estimación planificada al momento. Por ejemplo, si la estimación de esfuerzo de la solicitud es 20 horas y al momento se han registrado 5 horas el progreso en relación con el esfuerzo es 40%.

- Valor ganado logrado.

o Para el modelo de ciclo de vida ágil:

Evolución de los sprints planificados (Release burndown) Evolución en el sprint activo (Sprint burndown)

o Acciones correctivas planificadas y el estado de las acciones correctivas si hay desviaciones significativas

• Cronograma actualizado de la solicitud de servicio. Es el mismo entregable Cronograma de la Fase de Planificación, que se debe mantener actualizado durante la atención de la solicitud.

• Cierre de la iteración (Revisión del sprint). Contiene el resultado logrado en la iteración (sprint).

o Historias de usuario (requerimientos) terminados.

o Informe del resultado del pase a producción, si para esta iteración (sprint) estaba planeado un pase a producción.

o Anotaciones de la retroalimentación e la iteración (sprint) incluyendo posibles acciones de mejora para el equipo de trabajo.

6.3. Revisión y conformidad de los entregables y artefactos

Los entregables de la gestión del servicio, así como los artefactos y entregables por cada solicitud de servicios serán evaluados por el equipo de coordinación técnica de la entidad quien elevará el informe correspondiente al Coordinador del servicio.

La conformidad será emitida por el Coordinador del Servicio previo informe del equipo de coordinación técnica de la Entidad y podrá solicitar emitir opinión técnica a las Direcciones Técnicas y Oficinas de OSCE.

Si un artefacto o entregable es observado, el proveedor deberá subsanarlo en el plazo que se le indique y volver a solicitar la conformidad.

No se contabilizan como parte de las horas del servicio a las horas-hombre dedicadas a la corrección de errores o subsanaciones de los artefactos o entregables observados.

7. COSTO DEL SERVICIO Y FORMA DE PAGO

El servicio es a todo costo incluido impuestos y el costo se calcula con base en los precios unitarios de hora-hombre de los perfiles profesionales aplicados al dimensionamiento de cada solicitud de servicios de desarrollo de software aprobada.

Cualquier costo de gestión, administración, soporte, atención de incidencias u otro, se considera incluido dentro del precio unitario de hora-hombre de los perfiles profesionales. El costo de gestión incluye al equipo de coordinación técnica del proveedor.

7.1. Costo de cada servicio

Cada producto de software solicitado por la entidad será dimensionado por el proveedor y aprobado por la entidad y en función de la demanda de horas-hombre de perfiles profesionales.

El costo de cada solicitud de servicio será el que resulte de la multiplicación del número de horas hombre de cada perfil profesional por el precio unitario.

7.2. Forma de Pago

Los pagos se realizarán por cada hito definido en el plan de trabajo de cada solicitud de servicio, previa conformidad correspondiente. El importe del pago de cada hito corresponderá a los precios unitarios de hora-hombre previstos multiplicados por la cantidad de horas dimensionadas para los artefactos o entregables correspondientes.

7.3. Categorías estandarizadas para precios unitarios de hora-hombre por perfiles profesionales

Los precios por hora hombre de los distintos perfiles profesionales que considere el oferente en sus equipos de trabajo deberán ser estandarizados en las cuatro Categorías que se muestran a continuación:

Categoría de perfil

profesional

Descripción de categoría

Perfiles Profesionales del Servicio

[Se muestra una lista de ejemplo que debe ser completada por el postor]

Categoría 1	Gestor de proyecto	- Gerente de proyecto - Jefe de proyecto - Scrum máster
Categoría 2	Arquitecto o especialista técnico o líder técnico	- Arquitecto de software - Arquitecto de nube - Administrador de base de datos
Categoría 3	Analista de sistemas o analista de calidad	- Analista de sistemas - Analista funcional - Analista de calidad - Ingeniero de requerimientos
Categoría 4	Desarrollador	- Desarrollador de software - Especialista de migración - Especialista en APIS

7.4. Lista de precios unitarios

El oferente deberá presentar la lista de precios unitarios ofertados por cada una de cuatro categorías de perfiles profesionales indicados en la sección anterior.

Categoría de perfil profesional	Descripción de categoría	Costo Unitario por Hora-Hombre
Categoría 1	Gestor de proyecto
Categoría 2	Arquitecto especialista técnico o líder técnico
Categoría 3	Analista de sistemas o analista líder de calidad
Categoría 4	Desarrollador

7.5. Valorización de la oferta

Debido a que los servicios contemplados serán requeridos a demanda por cada solicitud de servicio durante la ejecución del contrato, para efectos de establecer un valor de comparación entre ofertas y un valor de adjudicación del contrato, se empleará un modelo de valorización que está compuesto por números de horas referenciales asignados a cada categoría estandarizada, los cuales deben de ser cotizados por ~~la firma postora~~ el proveedor con base en la lista de precios unitarios ofertados.

El número de horas indicado por cada categoría en esta valorización no representa necesariamente la cantidad y categoría de perfiles que serán requeridos durante la ejecución del contrato, pero son representativos de la carga de trabajo esperada durante de operación del servicio.

Sin embargo, el monto total resultante en el cuadro de valorización se considerará el precio final de la oferta.

Categoría	Descripción	% ponderado de horas para valorización	Cantidad de horas para valorización	Precio Unitario De Hora- Hombre	Precio Total
Categoría 1	Gestor de proyecto o Consultor	10%	1,500	-	-
Categoría 2	Arquitecto o Líder Técnico	20%	3,000	-	-
Categoría 3	Analista de sistemas o analista líder calidad	20%	3,000	-	-
Categoría 4	Desarrollador	50%	7,500	-	-
Total del Servicio de Desarrollo de Software			15,000	N.A.

8. REQUISITOS DEL OFERENTE

La firma oferente debe satisfacer los siguientes requisitos:

8.1. Restricciones respecto del oferente del servicio

El oferente no deberá tener vigente algún contrato se pruebas de calidad en la Entidad.

8.2. Capacidad financiera

• El oferente deberá proporcionar Carta de una entidad bancaria que otorga línea de crédito, o el flujo de efectivo y posición bancaria que acredite su capacidad financiera equivalente al 30% del monto ofertado.

8.3. Experiencia

• El postor deberá acreditar:

✓ Acreditar al menos cinco (05) contratos con clientes distintos por la provisión de servicios de desarrollo de sistemas/software/aplicativos cuyos montos de cada contrato sea superior a USD 50,000 (Cincuenta Mil dólares estadounidenses) o su equivalente en soles. Los contratos pueden encontrarse concluidos o en curso.

✓ Acreditar una facturación en los últimos tres (03) años, computados desde enero de 2020 hasta diciembre de 2022, por servicios de desarrollo de sistemas/software/aplicativos cuya sumatoria no debe ser menor a USD 500,000 (Quinientos Mil dólares estadounidenses) o su equivalente en soles.

• La experiencia y facturación del postor se acreditará con copia simple de (i) contratos u órdenes de servicios, y su respectiva conformidad o constancia de prestación; o (ii)

comprobantes de pago cuya cancelación se acredite documental y fehacientemente, con voucher de depósito, nota de abono, reporte de estado de cuenta, cualquier otro documento emitido por Entidad del sistema financiero que acredite el abono o mediante cancelación en el mismo comprobante de pago.

• Cuando en los contratos u órdenes de servicios o comprobantes de pago se encuentre expresado en moneda extranjera, debe indicarse el tipo de cambio venta publicado por la Superintendencia de Banca, Seguros y AFP correspondiente a la fecha de suscripción del contrato, de emisión de la orden de servicios o de cancelación del comprobante de pago, según corresponda.

8.4. Capacidad técnica

8.4.1. Marco metodológico para la gestión y operación del servicio

El oferente debe presentar con su oferta la descripción del Xxxxx Xxxxxxxxxxxx para la gestión y operación del servicio de desarrollo de software. Este marco metodológico deberá incluir las siguientes secciones, de acuerdo con el requisito especificado en la sección 4.1.2.

i. Metodología para la gestión de la construcción de los productos de software

8.4.2. Madurez en la industria del desarrollo de software

El oferente debe acreditar un nivel de madurez en las prácticas de la industria de desarrollo de software a través de la acreditación oficial CMMI expedita por el CMMI-Institute en un nivel de 3, 4 o 5.

8.4.3. Recursos y herramientas para la gestión del servicio de desarrollo de software

El oferente debe presentar con su oferta la descripción de los recursos y herramientas que dispone para la gestión del servicio de desarrollo de software, de acuerdo con los requisitos específicos en la sección 4.2.15.

8.4.4. Equipo de trabajo del Proveedor

El oferente debe acreditar en su oferta que cuenta con los siguientes perfiles en el equipo de trabajo para prestación del servicio:

a) Coordinador Técnico del Servicio

o Profesional con mínimo diez (10) años de experiencia en gerencia proyectos de tecnologías de información.

o Al menos seis (06) años de experiencia en gerencia de proyectos relacionados a desarrollo de software.

o Acreditar certificación vigente en Gestión de Proyectos del Project Management Institute (PMP) o similar como IPMA o PRINCE2.

o Acreditar certificación como scrum master emitido por una organización que brinde servicios de entrenamiento y certificación en scrum master.

b) Líder técnico de desarrollo de software

o Profesional con mínimo ocho (08) años de experiencia en diseño o desarrollo de soluciones de software.

o Experiencia mínima de seis (06) años en proyectos de desarrollo de software que involucren lenguaje Java, base de datos Oracle y frameworks de javascript

o Acreditar estudios de desarrollo de software con lenguaje Java con no menos de 60 hora de capacitación

o Acreditar certificación oficial como Java developer (Oracle).

c) Arquitecto de Software

o Profesional con mínimo ocho (8) años de experiencia en diseño o desarrollo de soluciones de software.

o Experiencia mínima de cuatro (04) años en arquitectura de software que involucre lenguaje Java, base de datos Oracle y frameworks de javascript

o Experiencia mínima de un (01) año en arquitectura de nube

o Acreditar certificación en nube (aws, azure, Oracle, GCP)

o Acreditar certificación OCP, Oracle Certified Professional.

d) Desarrollador senior

o Profesional con mínimo seis (06) años de experiencia en desarrollo de soluciones de software.

o Experiencia mínima de cuatro (04) años en proyectos de desarrollo de software que involucren lenguaje Java, base de datos Oracle y frameworks de javascript

o Acreditar certificación oficial como Java developer (Oracle).

e) Líder de calidad

o Profesional con mínimo cuatro (04) años de experiencia en el diseño y desarrollo de pruebas técnicas y/o funcionales de aplicaciones de software.

o Acreditar estudios relacionados con la gestión o automatización de pruebas de software con no menos de 60 hora de capacitación

o Acreditar certificación oficial ISTQB

El oferente debe adjuntar una hoja de vida por cada perfil solicitado que demuestre el cumplimiento de los requisitos, acreditándolos de la siguiente manera:

● El nivel profesional debe acreditarse con copia simple del título o grado universitario

● La Experiencia debe acreditarse adjuntando copias simples de certificados o constancias de trabajo y constancias de participación en proyectos o actividades similares a las solicitadas. Se debe incluir el correo electrónico de un representante del cliente o del empleador correspondiente y una breve descripción de cada uno de los proyectos o experiencias realizados.

● Las certificaciones técnicas o profesionales deben acreditarse con una copia simple de las mismas.

El proveedor debe garantizar la participación del personal clave evaluado en su oferta en los roles correspondientes durante la ejecución del servicio.

La Entidad no reconocerá ningún doble cargo de horas de servicio en ninguna actividad o etapa del proyecto producto del cambio de personal, debiendo el Proveedor asumir las consecuencias y cumplir el cronograma acordado.

9. SUPERVISIÓN Y CONFORMIDAD DEL SERVICIO PARA LOS PAGOS

La supervisión estará a cargo del coordinador del servicio de la Entidad.

La conformidad del servicio será otorgada por la Coordinación Técnica del Proyecto, quién podrá solicitar opinión a los órganos o usuarios funcionales del OSCE, en caso de ser necesario.

Si el producto es observado, la Coordinación General del Proyecto notificará al consultor el plazo máximo de acuerdo con la complejidad para subsanar las observaciones, el mismo que se contabilizará desde el día siguiente de notificada las observaciones.

10. CONFIDENCIALIDAD DE LA INFORMACIÓN

El proveedor y su personal se compromete a guardar reserva de la información privilegiada que conociera en el ejercicio de sus funciones, tareas y demás actividades como parte de la ejecución de la prestación, no revelando en forma oral, escrita, ni por cualquier otro medio, hechos, datos, procedimientos, documentación e información de acceso restringido (confidencial), a la que tuviera acceso a partir del inicio de las prestaciones relacionadas con el referido servicio, manteniendo la confidencialidad de la misma de manera permanente.

Cualquier contravención grave a lo anterior, entendiendo como grave aquella que afecte negativamente y a cualquier nivel las relaciones oficiales del OSCE con las autoridades nacionales, o bien que se traduzca en difusión pública o comercial que lesione de cualquier manera la confidencialidad de información del OSCE, podrá dar lugar a dar por terminado el contrato, lo cual se realizará mediante comunicación escrita al oferente denunciando tales hechos.

De igual manera se compromete a cumplir con: la Política Integrada de la Gestión de la Calidad ISO 9001, Gestión de Seguridad de la Información ISO 27001 y Gestión Antisoborno ISO 37001 del OSCE, las Políticas de Seguridad de la Información del OSCE, y demás normas y Leyes correspondientes a seguridad de la información, vigentes.

En caso que incumpliera con cualquiera de las obligaciones estipuladas en el presente acuerdo, el OSCE está autorizado a iniciar todas las acciones judiciales o extrajudiciales necesarias para resarcirse del perjuicio y la obligación de confidencialidad perdurará mientras la información conserve las características para considerarse Confidencial.

11. PROPIEDAD INTELECTUAL

El contratante será el titular de todos los datos de transacciones, bitácoras (logs), parámetros, documentos electrónicos y archivos adjuntos y, en general, de los artefactos y entregables que le suministre la firma proveedora contratada, siempre y cuando se genere

en virtud de la ejecución de los servicios objeto de la presente licitación para el respectivo contrato.

El proveedor no podrá utilizar la información indicada en el párrafo anterior, durante la ejecución del contrato ni con posterioridad al término de su vigencia, sin autorización escrita del contratante. Por tal motivo, una vez que la firma proveedora entregue dicha información al contratante al finalizar la relación contractual, deberá borrarla de sus registros lógicos y físicos.

Cuando sea aplicable al iniciar sus prestaciones, el proveedor deberá informar a la contraparte de la entidad contratante del software sobre el cual la firma proveedora tiene derechos de propiedad intelectual, sea como autor o a través de licenciamiento, y que será utilizado durante la ejecución del contrato.

La propiedad intelectual del software o cualquier otro derecho de terceros que se pueda involucrar en la ejecución del contrato, estará regida por los respectivos acuerdos de derechos que tenga el proveedor y/o la entidad contratante.

12. CLÁUSULA ANTISOBORNO

i. El proveedor declara conocer los compromisos antisoborno del OSCE, el cual se estable en su Política del Sistema Integrado de Gestión y se encuentra disponible en el portal web del OSCE:(xxxxx://xxx.xxx.xx/xxxxxxxxxxx/xxxx/xxxxx%X0%X0xx/0000-xxxxxxxx- delsistemaintegrado-degestion-del-osce)

ii. El proveedor declara no haber, directa o indirectamente, ofrecido, negociado o efectuado pago o, en general, entregado beneficio o incentivo ilegal en relación al servicio a prestarse o bien a proporcionarse. En línea con ello, se compromete a actual en todo momento con integridad, a abstenerse de ofrecer, dar o prometer, regalo u objeto alguno a cambio de cualquier beneficio, percibido de manera directa o indirecta; a cualquier miembro del Consejo Directivo, funcionarios públicos, empleados de confianza, servidores públicos; así como a terceros que tengan participación directa o indirecta en la determinación de las características técnicas y/o valor referencial o valor estimado, elaboración de documentos del procedimiento de selección, calificación y evaluación de oferta, y la conformidad de los contratos derivados de dicho procedimiento.

iii. El proveedor se compromete a denunciar, en base de una creencia razonable o de buena fe cualquier intento de soborno, supuesto o real, que tuviera conocimiento a través del canal de denuncias de soborno ubicado en el portal web del OSCE (xxxxx://xxxx.xxxx.xxx.xx/xxxxxxxxxxxxxxxxxxxxxx/).

13. MATERIAL DE ORIENTACIÓN PARA DENUNCIAR ACTOS DE CORRUPCION EN LOS PROCESOS DE CONTRATACIÓN (ANEXO N° 4 DE LA DIRECTIVA N° 004-2022-OSCE/SGE)

En el Organismo Supervisor de las Contrataciones del Estado promovemos la ética e integridad de la función pública, por lo que, si conoces de algún acto de corrupción ejercido

por un/a servidor/a del OSCE, comunícanos tu denuncia ingresando de manera virtual a la Plataforma Digital Única de Denuncias del Ciudadano (xxxxx://xxxxxxxxx.xxxxxxxxx.xxx.xx/).

Ejemplos:

(i) Adecuación o manipulación de las especificaciones técnicas, expediente técnico o términos de referencia para favorecer a un proveedor específico.

(ii) Generación de falsas necesidades con la finalidad de contratar obras, bienes o servicios.

(iii) Otorgamiento de la buena pro obviando deliberadamente el procedimiento requerido conforme x xxx.

(iv) Permisividad indebida frente a la presentación de documentación incompleta de parte del ganador de la buena pro.

(v) Otorgamiento de la buena pro a postores de quienes se sabe han presentado documentación falsa o no vigente.

(vi) Otorgamiento de la buena pro de (o ejercicio de influencia para el mismo fin) a empresas ligadas a exfuncionarios, de quienes se sabe están incursos en algunos de los impedimentos para contratar con el Estado que prevé la ley.

(vii) Admisibilidad de postor (o ejercicio de influencia para el mismo fin) ligado a una misma empresa, grupo empresarial, familia o allegado/a, de quien está incurso en alguno de los impedimentos para contratar con el Estado que prevé la ley.

(viii) Pago indebido por obras, bienes o servicios no entregados o no prestados en su totalidad.

(ix) Sobrevaloración deliberada de obras, bienes o servicios y su consecuente pago en exceso a los proveedores que las entregan o brindan.

(x) Negligencia en el manejo y/o mantenimiento de equipos y/o tecnología que impliquen la afectación de los servicios que brinda la institución.

¿Conoces de alguno de estos actos de corrupción, o de otros que pueden haberse cometido?, COMUNÍCANOS.

Notas:

(1) La denuncia puede ser anónima.

(2) Si el denunciante decide identificarse, se garantiza la reserva de su identidad y/o de los testigos que quieran corroborar la denuncia, y puede otorgar una garantía institucional de no perjudicar su posición en la relación contractual establecida con la Entidad o su posición como postor en el proceso de contratación en el que participa o en los que participe en el futuro.

(3) Es importante documentar la denuncia, pero si no es posible, se recomienda proporcionar información valiosa acerca de donde obtenerla o prestar colaboración con la entidad para dicho fin.

(4) La interposición de una denuncia no constituye impedimento para gestionar por otras vías que la ley prevé para cuestionar decisiones de la administración o sus agentes (OSCE, Contraloría General de la República, Ministerio Público, etc.).

(5) La interposición de una denuncia no servirá en ningún caso para paralizar un proceso de contratación del Estado.

Document Metadata

Table of Contents

ORGANISMO SUPERVISOR DE CONTRATACIONES DEL ESTADO (OSCE)

Document Metadata