TÉRMINOS DE REFERENCIA

TÉRMINOS DE REFERENCIA

1. ANTECEDENTES:

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.

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 Componente 2 se incluye la acción 2.2. de Implementación de la plataforma de soporte al Proceso de Contratación orientada a la Gestión por Resultados y maximización del valor por el dinero. En este aspecto, se considera que la actual plataforma de sistemas del OSCE que soporta al Sistema Electrónico de Contrataciones del Estado SEACE será parte del proceso de migración, con un periodo de convivencia común aún por determinar, por lo que es necesario asegurar que su funcionamiento se dé en las mejores condiciones técnicas de operación.

Por ese motivo se ha programado dentro del Proyecto el desarrollo de funciones complementarias organizadas en Proyectos Complementarios que permitan ofrecer mejoras inmediatas para sostenibilidad de sistema en mención. Siendo la fase de pruebas, parte del ciclo de vida del desarrollo de software y no teniendo la Oficina de Tecnologías de la Información – OTI las capacidades suficientes para realizar éstas actividades con los proyectos complementarios que se van a desarrollar, se ha identificado la necesidad de contratar el servicio de pruebas de software, con lo que se permitirá cumplir con esta etapa del ciclo de vida de los proyectos complementarios, asegurando el correcto entendimiento y desarrollo de los requerimientos, así como contar con los elementos para poder planificar de manera adecuada los diversos ciclos de pruebas a ser ejecutados.

Por tal motivo, es necesaria la contratación de una empresa que proporcione los servicios de pruebas (testing y calidad) de software para estos Proyectos Complementarios, que faciliten el uso de los servicios y mejore los tiempos de respuesta de parte de la Entidad hacia los usuarios externos e internos.

2. OBJETIVO DEL SERVICIO:

SERVICIO DE PRUEBAS DE SOFTWARE PARA PROYECTOS COMPLEMENTARIOS DEL OSCE

El presente servicio, permitirá la realización de pruebas de aceptación de software para los proyectos complementarios, ampliando las capacidades del equipo de tecnologías de la información y de la plataforma del proceso de contratación pública.

El objetivo del servicio específico es apoyar la ejecución de los servicios desarrollados a través de la prueba de las aplicaciones que faciliten el uso de los servicios y mejore los tiempos de respuesta de parte de la Entidad hacia los usuarios externos e internos, agregando valor al proceso mediante el enfoque de mejoramiento de la eficiencia, eficacia y transparencia.

3. ALCANCE DEL SERVICIO

3.1.Descripción de los Servicios de Pruebas

Las pruebas de software son un proceso formal y por lo tanto se debe de gestionar como tal en el contexto del Proyecto, es por lo que se establece a continuación las macro actividades mínimas que se deben de considerar en la prestación del servicio de pruebas:

Macro Actividades Servicio de Pruebas

El servicio solicitado consiste en que el proveedor pone a disposición de la entidad una cantidad determinada de recursos (horas de trabajo efectivo de analistas y líder de calidad) con el fin de efectuar pruebas de funcionales, análisis de código y pruebas de desempeño sobre el software creado por el servicio de Desarrollo de Software para Proyectos Complementarios de OSCE o proyectos de desarrollo de software de OSCE en coordinación con la administración de Proyecto BID. Adicionalmente, y en coordinación entre el proveedor y la entidad, se pueden incluir pruebas de volumen, pruebas de seguridad y pruebas de estrés.

Cada requerimiento de prueba se inicia a solicitud de la entidad y se planifica de manera independiente.

A continuación, se describen las actividades que conforman el servicio de pruebas:

Macro Actividad	Descripción
Planificación	El objetivo de esta actividad en el poder establecer la estimación y alcances de las pruebas solicitadas, para ello el proveedor presentará una estimación en tiempo y recursos al responsable del proyecto por parte de la entidad, quien, a su vez, revisará y dará el visto bueno si lo considera adecuado.

	Por otro lado, el proveedor deberá de establecer el “Plan de Pruebas” del proyecto, el cual determinará la estrategia para la ejecución de las pruebas. Dicho plan de pruebas deberá contener al menos: • Riesgos del producto. • Alcance y estrategia. • Tipos de pruebas a ejecutar. • Criterio de terminación de las pruebas. • Recursos para la preparación y ejecución de las pruebas. • Xxxx xx Xxxx de las pruebas Cabe señalar que el “Plan de Pruebas” es un documento vivo, por lo que podrá ser actualizado durante todo el ciclo de vida de las pruebas, con base a los resultados de las pruebas ejecutadas, cambios de alcance y de prioridades y necesidades del negocio.
Análisis y Diseño de Pruebas	El propósito de esta actividad es el diseñar los casos y guiones de pruebas que serán necesarios para evaluar que los productos de software desarrollados cumplan con los requerimientos especificados, tanto funcionales, como no funcionales; lo anterior con base al “Plan de Pruebas” establecido para el proyecto por la Entidad. Como parte del Diseño de las Pruebas, el proveedor deberá identificar los datos requeridos para la ejecución de los casos de prueba, así como todos aquellos requerimientos adicionales para poder ejecutar las tareas de pruebas (Accesos, Disponibilidad de Ambiente, entre otros), mismos que serán solicitados por el proveedor a la Entidad para su respectiva gestión por parte del personal asignado, con el fin de asegurar la ejecución de las actividades de pruebas conforme a los tiempos planificados.
Implementación y Ejecución	Durante la ejecución de esta actividad se busca asegurar que se cuenta con los insumos necesarios, validar que se cuenta con el ambiente y los datos necesarios y ejecutar las pruebas en base a los documentos de “Plan de Pruebas” y “Estimación” aprobados. Durante la ejecución de cada uno de los ciclos de pruebas, se registrarán todos los defectos detectados, clasificándolos en base a los criterios de calidad definidos a fin de que el equipo de desarrollo de software pueda proceder a su corrección. La ejecución de las pruebas se realizará para todos los casos de prueba definidos y aprobados.
Evaluación de criterios de salida y Reporte de Pruebas	En la medida que se van ejecutando las pruebas se consolidan los resultados de la ejecución de las pruebas, evaluando los criterios esperados para cada caso de prueba, indicando cuáles fueron aprobadas exitosamente y cuáles no. Con la información generada durante la ejecución de las pruebas se deberán de obtener las métricas de acuerdo con lo establecido en el “Plan de Pruebas”.

Control Durante cada ciclo de pruebas se irán ejecutando tareas de seguimiento y control con la finalidad de asegurar que se cumple con lo establecido en el Plan de Pruebas.
Las desviaciones, comentarios y riesgos serán comunicados al equipo de gestión del proyecto de la Entidad con la finalidad de establecer acciones correctivas o preventivas de manera coordinada.

Tabla Macro Actividades Servicio de Pruebas

Estas actividades se deben de ejecutar de manera concurrente con el ciclo de desarrollo, por lo que es de vital importancia la correcta coordinación con el equipo de gestión del proyecto.

3.1.1. Tipos de Pruebas

A continuación, se describen los tipos de pruebas que podrían ser ejecutados en el presente servicio de pruebas:

Tipo de Prueba	Descripción
Funcionales	Las pruebas deben enfocarse a los requerimientos principales que serán mapeados directamente según las reglas del negocio. El propósito de estas pruebas es verificar la aceptación de los datos, el procesamiento correcto de los mismos, la recuperación de éstos y la implementación adecuada de las reglas del negocio. El objetivo de las pruebas funcionales puede ser enfocado directamente a los requerimientos a probar como son: casos de uso, historias de usuario o funciones del negocio. La meta de esta prueba es verificar los procesos, acceso y recuperación de los datos, así como la implementación apropiada de las reglas de negocio.
Análisis de Código	Las pruebas de código se dividen en dos, análisis estático del código y análisis en tiempo de ejecución. En el primer tipo de pruebas se hace énfasis en la estructura del código, los estándares de programación, las reglas arquitectónicas, la detección de anti-patrones, definición de las estructuras y secuencia de uso de APIs, funcionalidades o componentes, según corresponda. En el segundo se determina qué problemas tiene el aplicativo al ser ejecutado, los consumos altos de memoria, la degradación del desempeño, los tiempos de los métodos y la cantidad de llamados que se hacen, la cantidad de código que se alcanza a probar con las pruebas funcionales.

Tipo de Prueba	Descripción
Desempeño	La prueba de desempeño es una prueba en la cual los tiempos de respuesta, transacciones y otros requerimientos de tiempo son medidos y evaluados. El objetivo de esta prueba es verificar los requerimientos de desempeño que hayan sido alcanzados. El perfil de desempeño es implementado y ejecutado para perfilar y afinar los comportamientos de la ejecución de los objetivos de las pruebas y las funciones de las condiciones, así como, la carga de trabajo o las configuraciones de hardware.
Pruebas de Volumen	Revisa que los múltiples queries, reportes y transacciones satisfagan los requerimientos de concurrencia y volumen de datos indicados en el “Plan de Pruebas”. Las pruebas de volumen consisten en determinar si al probar con una cantidad de datos incrementada en la base de datos se alcanza el límite y se provoca una falla en el software. Las pruebas de volumen también identifican la carga máxima o el volumen de procesos que se puedan manejar en un periodo determinado. Por ejemplo, si en una prueba se está procesando una cierta cantidad de registros para generar un reporte, una prueba de volumen podría usar una base de datos grandes para verificar que el software se comporte normalmente y genere el reporte correctamente.
Pruebas de Seguridad	Consisten en validar la correcta aplicación de los roles de usuario que se encuentran en el análisis, así como los niveles de seguridad y el otorgamiento de privilegios. Las pruebas de seguridad y control de acceso se enfocan en dos áreas principales de seguridad: Seguridad a nivel de la aplicación, incluyendo acceso a las funciones de negocio o los datos, y la seguridad a nivel de aplicativo, incluyendo el acceso remoto o local al aplicativo. La seguridad a nivel de la aplicación asegura que los Usuarios tengan restricción a ciertas funciones o tengan restringidos algunos datos que no necesiten ver. La seguridad a nivel de aplicativo asegura que solo aquellos Usuarios a quienes se les ha otorgado el acceso al aplicativo, sean capaces de acceder a las aplicaciones, a través de la forma adecuada, siendo esto por la cobertura nacional del aplicativo.
Pruebas de Estrés	Las pruebas de estrés son un tipo de pruebas de desempeño implementadas y ejecutadas para encontrar errores debido a la concurrencia de Usuarios en el servidor, así mismo se valida la carga de memoria o espacio en disco, quizá se puedan detectar errores que no son identificados en condiciones normales. Otros errores que se pueden encontrar son errores en bases de datos o errores en la red. Consiste en verificar el mínimo de memoria disponible en el servidor cuando existe concurrencia, la capacidad máxima de clientes conectados simultáneamente y múltiples Usuarios realizando diferentes transacciones con la misma cuenta.

Para la realización de estas pruebas el proveedor utilizará herramientas de su elección provistas por ellos mismos.

3.1.2. Roles involucrados en las fases del servicio

Para la ejecución del servicio, el Postor deberá proveer los siguientes roles:

Rol	Descripción
Líder Técnico de Calidad	Es responsable de: • Generar el cronograma del proyecto. • Asegurar la definición del “Plan de Pruebas”. • Coordinar las actividades del equipo de pruebas. • Planificar las actividades para ejecutar el “Plan de Pruebas”. • Dar seguimientos a los resultados de las actividades de prueba. • Elaborar y presentar resultados del avance de las actividades de prueba. • Elaborar y presentar las métricas de pruebas. • Asegurar la elaboración del “Reporte de Pruebas”.
Analista de Pruebas	Es responsable por. • Realizar el análisis correspondiente para la elaboración de los casos o guiones de prueba. • Ejecución de las actividades definidas en el “Plan de Pruebas” • Registrar y comunicar los defectos o errores detectados durante la ejecución de las pruebas.

Tabla Roles Servicio de Pruebas

Los perfiles deben cumplir la especificación detallada en la sección “Perfiles y responsabilidades del equipo del Postor”

3.1.3. Entregables del Servicio de Pruebas

Como resultado de la ejecución de las actividades del servicio de pruebas, se listan los entregables para el presente servicio:

Macro Actividad	Entregable	Descripción
Planificación	Plan de Pruebas	Documento en donde se plasma la Estrategia, casos y alcance de las pruebas a ser ejecutadas durante los ciclos de pruebas del producto de software, este documento es el principal entregable acordado con la Entidad con respecto a la calidad esperada del Producto de Software que está siendo desarrollado.
	Cronograma	Documento en donde se especifican las actividades, responsables, tiempos e hitos correspondientes a las actividades de pruebas de Software.

Macro Actividad	Entregable	Descripción
Análisis y Diseño de Pruebas	Matriz de Casos de Pruebas	Documento donde se detallan los diferentes escenarios y casos de prueba a ser realizados, mismos que corresponden a los diferentes aspectos que serán evaluados durante la ejecución de los ciclos de pruebas.
	Guiones de Prueba	Especifican la secuencia de pasos, precondiciones y datos de prueba a ser utilizados para la ejecución del control de calidad sobre las aplicaciones correspondientes a los requerimientos de negocio, así como las dependencias entre los diferentes guiones.
Implementación y Ejecución	Evidencia de Pruebas	Captura organizada en forma de captura de pantallas organizadas en una presentación Powerpoint o Word. Debe ser un solo archivo con un índice del contenido. Por cada caso de prueba debe existir una diapositiva de inicio de caso de prueba indicando si la prueba fue exitosa o no, otra con la captura de pantalla inicial y finalmente la captura de la pantalla final. Esta presentación se presentará al usuario final por personal del Equipo de Gestión del Proyecto BID el que será responsable de identificar y registrar sus opiniones y evaluar la necesidad de un nuevo requerimiento de servicio de pruebas de software. El personal del Proveedor no interviene en esta actividad.
	Reporte de defectos o errores	Documento donde se plasman los defectos o errores detectados derivados de la ejecución de los diferentes casos y guiones de prueba durante los ciclos de certificación del producto de software. Los defectos o errores deberán ser clasificados en orden de severidad, acorde a lo establecido en el plan de pruebas.
Evaluación de criterios de salida y Reporte de Pruebas	Reporte de Pruebas	Documento donde se plasman los resultados obtenidos para el Producto de Software evaluado y una vez que se han alcanzado los criterios de calidad de la etapa de pruebas, en sus distintos ciclos de prueba, con el fin de ser comunicados al equipo de gestión de proyectos.
Control	Informe de Avance	Informe periódico donde se informa del avance de las actividades de Control de calidad, los acuerdos, riesgos y problemáticas del proyecto.

Tabla Entregable Servicio de Pruebas

En caso de que se requiera algún entregable diferente a los listados en la presente sección, se podrá realizar previo acuerdo con la Entidad.

3.1.4. Métricas del Servicio de Pruebas

En esta sección se describen las métricas que se estarán reportando periódicamente, en el “Reporte de Pruebas”:

Métrica	Descripción
Densidad de defectos o errores Reportados	Número de casos de pruebas con defectos o errores indicados en el “Reporte de Pruebas” respecto al total de casos de prueba planificados. Valor representado en Porcentaje (%).
Densidad de Número de Casos de Pruebas Completadas	Número de casos de pruebas completadas y registradas en el “Reporte de Pruebas” respecto al total de casos de prueba planificados. Valor representado en Porcentaje (%).

Tabla Métricas Servicio de Pruebas

3.2.Ambientes tecnológicos del servicio

Para la ejecución del servicio se requerirá de lo siguiente:

a) Ambiente de Pruebas Funcionales

En este ambiente se realizarán las actividades y tipos de pruebas comprendidas en el Plan de Pruebas, este ambiente contendrá las herramientas necesarias para la homologación del ambiente de pruebas y será provisto por la Entidad.

Será responsabilidad de la Entidad el asegurar de que el ambiente de pruebas se encuentre homologado con el ambiente productivo.

La Entidad proporcionará los accesos remotos a los ambientes tecnológicos de pruebas funcionales y pruebas de aceptación, así como un ambiente físico para las reuniones, de ser necesario.

3.3.Recursos para proveer por el proveedor

El Proveedor deberá proporcionar a su personal equipamiento tales como computadores, impresoras, internet y otros que considere necesarios para el cumplimiento de sus funciones, todo sin costo adicional para la Entidad. Además, el Proveedor deberá asegurar la disponibilidad, calidad y continuidad de la conectividad con sus equipos tecnológicos, de manera que garantice la operatividad del servicio.

3.4.Metodología para el desarrollo de las pruebas

La metodología deberá estar alineada a la ISO/EIC 25000 y el estándar IEEE 829 en lo referido a los procesos y actividades relacionadas al alcance del servicio.

Además, deberá proporcionar los artefactos/documentos que correspondan a cada fase del servicio, de acuerdo con los estándares y/o formatos propios o proporcionados por la Entidad, según se acuerde al inicio del servicio.

3.5.Bolsa de horas

Como se ha mencionado, el objeto de este servicio es la realización de pruebas a los productos de software que se desarrollen para la implementación de los proyectos complementario. Se ha estimado que el desarrollo de estos proyectos en la modalidad de Fábrica de Software tomará 8500 horas.

Tomando en cuenta esto el servicio de testing y calidad se desarrollará bajo el concepto de tener una cantidad de horas a consumirse denominado Bolsa de horas, la cual ascenderá a 2200 horas, cuyo consumo será definido mediante las ofertas de horas elaboradas por el Proveedor y debidamente aprobada por el equipo de gestión de proyectos.

3.5.1. Horario para la atención de las líneas de servicio

• Para el servicio de pruebas, el Proveedor necesariamente estará disponible durante el horario laboral regular de la Entidad.

3.5.2. Garantía del servicio

La garantía sobre cada servicio de prueba de software probado y aceptado estará vigente durante todo el tiempo de vigencia servicio, resolviendo y corrigiendo de manera inmediata observaciones identificadas en la documentación entregada donde se evidencie la responsabilidad del Proveedor, sin generar costo alguno para la Entidad.

Una vez concluida la totalidad del servicio, el Postor proporcionará una garantía de seis (06) meses sobre los servicios probados y aceptados.

3.6.Mecánica del servicio

3.6.1. Planificación

Un requerimiento de servicio para pruebas de software se inicia con el envío del correo electrónico al Proveedor solicitándole la elaboración del Plan de Pruebas basado en el Diseño de la aplicación en desarrollo.

El proveedor tendrá un plazo de cinco (5) días calendario para aceptar el requerimiento y convenir las condiciones de este, esto es, la cantidad de horas que estima consumirá de la “bolsa de horas” para cumplir con el encargo, debe incluir las actividades de las etapas de “Análisis y Diseño de Pruebas” (3.6.2) e “Implementación y ejecución” (3.6.3). Dentro de este plazo se realizarán reuniones con los analistas responsables de la Entidad para las aclaraciones y precisiones correspondientes. El “Plan de Pruebas” y el “Cronograma” correspondiente deberán ser aprobados previamente a su ejecución.

El servicio de pruebas de software se realizará en el ambiente descrito en el numeral 3.2. que tendrá instalado el software a ser examinado. Este software estará configurado en el estado inicial previsto en el requerimiento para las pruebas.

Cabe precisar que esta actividad preliminar no genera desembolso alguno de horas-hombre del servicio.

Esta etapa concluye cuando el “Plan de Pruebas” y el “Cronograma”, tal como están descritos en 3.1.3, son aprobados por el equipo de Gestión de Proyecto.

En caso no se llegue a un acuerdo por más de tres requerimientos la Entidad puede evaluar la rescisión del contrato.

3.6.2. Análisis y Diseño de Pruebas

Cuando la etapa de Planificación (3.6.1) concluye, se procede a iniciar la etapa de Análisis y Diseño.

El proveedor preparará el análisis y elaborará el diseño detallado de las pruebas. No deberá exceder el plazo establecido para estas actividades en el “cronograma” entregado en la etapa anterior, dentro de este plazo se realizarán reuniones con los analistas responsables de la Entidad para las aclaraciones y precisiones necesarias. La “Matriz de Casos de Pruebas” y los “Guiones de Prueba” deben ser elaborados en este momento.

Esta etapa concluye cuando la “Matriz de Casos de Pruebas” y los “Guiones de Prueba”, tal como están descritos en 3.1.3, son entregados y aprobados por el equipo de Gestión de Proyecto.

Al finalizar esta etapa el proveedor puede solicitar un reajuste en el número de horas a consumir en la implementación y ejecución de las pruebas.

3.6.3. Implementación y ejecución

Al terminar la etapa de “Análisis y Diseño” (3.6.2) se puede iniciar la etapa de “Implementación y Ejecución”.

El proveedor organizará su equipo de trabajo y ejecutará el “plan de pruebas” basándose en le establecido en la “Matriz de Casos de Pruebas” y los “Guiones de Prueba”. No deberá exceder el plazo establecido para estas actividades en el “cronograma” entregado en la etapa de planificación y reajustado en la etapa de Análisis y Diseñó. Como de resultado de estas pruebas se elaborará el “Reporte de defectos o errores” y se preparará la “Evidencia de Pruebas”.

Esta etapa concluye cuando el “Reporte de defectos o errores” y la “Evidencia de Pruebas”, tal como están descritos en 3.1.3, son entregados y aprobados por el equipo de Gestión de Proyecto.

3.6.4. Evaluación de criterios de salida y Reporte de Pruebas.

Al terminar la etapa de “Implementación y Ejecución” (3.6.3) se inicia la etapa de “Evaluación de criterios de salida y Reporte de Pruebas”.

El proveedor, basándose en la información de las etapas anteriores elaborará el “Reporte de Pruebas” como se describe en 3.1.3. La respuesta al entregable será emitida por el equipo de gestión de la Entidad en máximo diez (10) días calendario posteriores a la entrega.

Si la entrega fuera observada, el Proveedor tendrá cinco (05) días para subsanarlo y volver a solicitar la conformidad. Cabe precisar que el Proveedor está obligado a absolver las observaciones de cada revisión que se realice.

Si la entrega es aceptada se dará por concluido el requerimiento.

Los entregables deberán ser presentados por la mesa de partes física o virtual de la Entidad en el plazo establecido de los productos según cronograma aprobado y deberá contener un informe ejecutivo y un medio magnético incluyendo los entregables acordados en la etapa pre-operativa.

El video de Evidencia de Pruebas será presentado al usuario final por personal del Equipo de Gestión del Proyecto BID el que será responsable de identificar y

registrar sus opiniones y evaluar la necesidad de un nuevo requerimiento de servicio de pruebas de software. El personal del Proveedor no interviene en esta actividad.

Las horas-hombre destinadas para corregir los documentos, no serán facturadas.

En caso de que los resultados de las pruebas indiquen que los productos de software deban ser devueltos para corrección, se generará un nuevo requerimiento que cubra las pruebas que se deberán realizar sobre el producto de software corregido.

3.6.5. Control

El proveedor deberá emitir un “Informe de Avance”, tal como es descrito en 3.1.3, cada semana a menos que en la etapa de planificación se determine otra cosa. La entidad podrá solicitar un “Informe de Avance” cada vez que lo considere necesario.

3.6.6. Gestión de la bolsa de horas

El presente servicio se ejecutará según demanda, el equipo de gestión del proyecto de la entidad supervisará el consumo de la bolsa de horas previamente aprobado; se elaborará el cálculo de horas utilizadas, conforme se vayan concluyendo los productos resultantes de los requerimientos.

3.7.Etapas del servicio

Las etapas que conforman el servicio son las siguientes:

3.7.1. Pre-Operativa

Se considera desde el primer día hábil posterior a la firma del contrato, con la firma del acta de inicio del servicio (kick off); hasta los diez (10) días calendarios posteriores al inicio del servicio, considerando, las siguientes actividades:

- Acuerdos para utilización de la metodología de la Entidad o la que la misma indique o acuerde con el Proveedor, así como los artefactos y estándares de documentación y pruebas a utilizarse.

- Definición de los criterios (estándares) de calidad que debe cumplir.

- Definición del procedimiento a detalle de atención de requerimientos.

- Definición de contactos y mecanismos de comunicación entre ambas partes.

- Proveer la configuración del ambiente de prueba a ser utilizado para el servicio.

Cabe precisar que esta fase pre-operativa no genera desembolso alguno de horas- hombre del servicio.

3.7.2. Operación

- En esta etapa se atienden los requerimientos del servicio de pruebas de software.

- Para los pagos deberá considerase un entregable conteniendo el Informe ejecutivo con los productos concluidos y entregados, cantidad de horas consumidas, penalidades incurridas, listado de documentos generados.

- Los entregables de esta etapa deberán ser presentados en la mesa de partes física o virtual de la Entidad, durante los primeros diez (10) días calendario de la conclusión y aceptación del requerimiento o etapa de este, y son los que se especifican en el punto 3.1.3

3.8.Estructura del servicio

Como parte de la supervisión y toma de decisiones del servicio, se ha estructurado lo siguiente:

3.8.1. Equipo de gestión del proyecto

Estará a cargo del Equipo de Gestión del Proyecto, que ejerce el control estratégico y busca la oportuna toma de decisiones sobre los aspectos que modifiquen el tiempo, costo y alcance del servicio, siendo la instancia superior de toma de decisiones respecto del servicio en ejecución.

Responsabilidades

• Toma decisiones estratégicas sobre los requerimientos

x Xxxx por el cumplimiento de los acuerdos y los niveles de servicio

o Define, modifica y aprueba las directrices del servicio

o Define las estrategias de comunicación y viabiliza la ejecución del servicio.

o Define y controla el gobierno del servicio

o Realiza el análisis funcional de cada uno de los requerimientos a probar.

3.8.2. Equipo técnico

Equipo conformado por personal del Equipo de Gestión del Proyecto, la Oficina de Tecnologías de Información OTI, la Dirección SEACE o/o el área que esté involucrada en el aplicativo a probar según corresponda, y deberá revisar el avance del desarrollo de los requerimientos por parte del Proveedor.

Responsabilidades:

• Supervisa el avance y control del cronograma de atención de los requerimientos, aprobando sus eventuales mejoras o funcionalidades necesarias no identificadas, las cuales podrán ingresar como un nuevo requerimiento de ser el caso.

• Define las acciones a realizar para el cumplimiento del cronograma de actividades.

• Coordina y ejecuta la aprobación de las pruebas de aceptación.

3.8.3. Cambio de personal

De realizarse alguna rotación o reemplazo del personal asignado por el Proveedor para prestar el servicio, deberá considerarse que el personal ingresante deberá tener el mismo perfil o superior que el personal saliente, además dicha rotación o reemplazo estará sujeto a aprobación del comité de gestión y de aprobarse, el Proveedor deberá enviar formalmente una comunicación informando el cambio a realizar. La Entidad no reconocerá ningún doble cargo de horas-hombre en ninguna actividad o etapa del proyecto producto del cambio de personal, debiendo el Proveedor asumir las consecuencias y cumplir el cronograma acordado.

La Entidad podrá durante todo el proceso de ejecución del servicio, solicitar el cambio de personal asignado por parte del Provedor en caso lo considere necesario. De solicitarse el cambio, el Proveedor tendrá diez (10) días calendario

para remitir el o los perfiles propuestos, una vez aceptado, el Proveedor tendrá tres (03) días calendario para formalizar el cambio y asegurar la continuidad del servicio. Todo retraso o costo adicional que genere el presente cambio será asumido en su totalidad por el Proveedor, pudiendo aplicarse penalidades en caso de que corresponda.

3.9.Acuerdos de niveles de servicio y penalidades

Los niveles de atención del servicio se medirán desde el inicio del servicio y en la tabla siguiente se resume los niveles de servicio, los cuales serán medidos por cada requerimiento:

Código	Forma de medición	SLA	Penalidad
SLA-01 Cumplimiento de plazos de pruebas de aceptación del requerimiento	(Fecha real de entrega del requerimiento – Fecha planificada de entrega de requerimiento) / Total de días planificados para la entrega del requerimiento.	>=20 %*	0.25 % Del monto de pruebas de aceptación

*En el ítem SLA-01, se aplicará el 0.25% del monto de la propuesta del requerimiento, por cada día adicional al 20% del tiempo propuesto. En caso se supere el 50% del tiempo estimado en la oferta aprobada del requerimiento, por 3 o más requerimientos durante la ejecución del servicio, la Entidad podrá resolver el Contrato de considerarlo pertinente.

**

4. PRODUCTOS E INFORMES POR ENTREGAR

Por cada requerimiento con oferta aceptada por la Entidad, el Proveedor deberá entregar su producto con las pruebas de aceptación concluidas y (documentos técnicos concluidos, debidamente aceptados por el equipo técnico).

5. DURACION DEL SERVICIO

Tendrá una duración de dos (2) años contados a partir de la firma del contrato o hasta que se consuman las horas contratadas (ver numeral 3.5).

El servicio podrá ser ampliado de acuerdo con las condiciones contractuales correspondientes.

6. PERFIL DEL POSTOR

El postor no deberá tener vigente el contrato para el Desarrollo de Software para la Entidad.

El postor deberá acreditar experiencia en contratos de testing y calidad, pruebas funcionales, pruebas de certificación, pruebas de aceptación y/o servicios similares al objeto del servicio, con por lo menos cinco (05) contratos cuyos montos sean superiores a US $ 30,000 o su equivalente en soles, en los últimos cinco (05) años anteriores a la fecha de la presentación de las propuestas.

Se consideran servicios similares a los siguientes:

• Servicios de pruebas/soporte y/o mantenimiento y/o mejoras de aplicaciones

• Pruebas de Sistemas de Información y/o Sistemas Informáticos y/o Soluciones Informáticas

• Todos los casos, en donde se certifique actividades de: pruebas funcionales soporte de aplicaciones y/o sistemas informáticos.

Acreditación:

La experiencia 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.

7. PERFIL DEL PERSONAL CLAVE

7.1.Servicio Pruebas

• Líder Técnico Calidad

o Profesional en carreras relacionadas a tecnologías de la Información, informática, sistemas, industrial o afines.

o Experiencia laboral no menor de cinco (05) años en el sector público o privado en labores relacionadas a pruebas de aplicativos.

o Experiencia al menos de tres (03) años liderando equipos de pruebas.

o Experiencia como gestor de proyectos.

o Deseable con certificado o curso de ISTQB Test Manager.

• Analista de Calidad

o Profesional o Técnico en carreras relacionadas a tecnologías de la Información, informática, sistemas, industrial o afines.

o Experiencia laboral no menor de dos (02) años en el sector público o privado en labores relacionadas a pruebas de aplicativos.

o Capacitación certificada en calidad de software o ISTQB.

o Deseable con certificado ISTQB de nivel fundamentos.

Los estudios solicitados, se acreditarán con copia simple del título, grado o certificados y/o constancias. La experiencia debe estar sustentada con los certificados, contratos, órdenes de servicio, o recibos de honorarios con su respectiva conformidad, los mismos que deben coincidir con la información proporcionada en la hoja de vida.

8. COSTO DE LA CONSULTORÍA Y FORMA DE PAGO:

El servicio es a todo costo, incluido los impuestos xx xxx, el cual será pagado previa conformidad del servicio.

La Entidad emitirá un único pago por cada servicio de prueba de software concluida, siendo el pago por la cantidad de horas acordadas.

9. CONFIDENCIALIDAD:

El Postor se obliga a mantener y guardar estricta reserva y absoluta confidencialidad sobre todos los documentos e informaciones del OSCE a los que tenga acceso en ejecución del presente contrato. En tal sentido, deberá abstenerse de divulgar tales documentos, software e informaciones, sea en forma directa o indirecta, a personas naturales o jurídicas, salvo autorización expresa y por escrita por la Entidad.

10. SUPERVISIÓN Y CONFORMIDAD DEL SERVICIO:

• La supervisión general del servicio estará a cargo del Equipo de Gestión del Proyecto.

• la supervisión de cada requerimiento estará a cargo del Equipo de Gestión del Proyecto.

• La conformidad del servicio estará a cargo del Equipo de Gestión del Proyecto, previo informe técnico de la Oficina de Tecnologías de Información OTI y las oficinas involucradas.