TERMINOS DE REFERENCIA PARA LA CONTRATACION DE UN SERVICIO ESPECIALIZADO DE DESARROLLO E IMPLEMENTACION DEL SISTEMA INTEGRADO DE GESTION DEL NUEVO CENTRO NACIONAL DE PERFILES GENETICOS HUMANOS DEL INSTITUTO DE MEDICINA LEGAL Y CIENCIAS FORENSES DEL...

TERMINOS DE REFERENCIA PARA LA CONTRATACION DE UN SERVICIO ESPECIALIZADO DE DESARROLLO E IMPLEMENTACION DEL SISTEMA INTEGRADO DE GESTION DEL NUEVO CENTRO NACIONAL DE PERFILES GENETICOS HUMANOS DEL INSTITUTO DE MEDICINA LEGAL Y CIENCIAS FORENSES DEL MINISTERIO PUBLICO

CONTENIDO

1. DENOMINACION DE LA CONTRATACION

2. FINALIDAD PUBLICA

3. OBJETIVOS GENERALES

4. ANTECEDENTES DOCUMENTALES

5. ALCANCE DEL SERVICIO

a. CONSIDERACIONES GENERALES

b. GLOSARIO DE TERMINOS

c. REQUERIMIENTOS LEGALES

d. REQUERIMIENTOS GENERALES DEL SERVICIO

e. REQUERIMIENTOS ESPECIFICOS DEL SERVICIO

f. REQUERIMIENTOS FUNCIONALES

g. REQUERIMIENTOS NO FUNCIONALES

6. EJECUCION DEL SERVICIO

7. EQUIPAMIENTO PARA LA PRESTACION DEL SERVICIO

8. PERSONAL PARA LA PRESTACION DEL SERVICIO Y SOPORTE TECNICO

9. ENTREGABLES DEL SERVICIO

10. PENALIDADES

a. PENALIDADES POR RETRASO EN LA EJECUCION DEL SERVIVCIO

b. OTRAS PENALIDADES RELACIONADAS A LA CALIDAD DEL SERVICIO

11. CONFORMIDAD

12. CLAUSULA DE SEGURIDAD Y CONFIDENCIALIDAD

a. CLAUSULA DE SEGURIDAD DE LA INFORMACION

b. XXXXXXXX DE PROTECCION DE DATOS PERSONALES

c. CLAUSULA DE ACUERDO DE CONFIDENCIALIDAD

d. CLAUSULA DE PUBLICIDAD

13. FORMA DE PAGO

14. FINALIZACION DEL SERVICIO

15. RESPONSABILIDAD POR XXXXXX XXXXXXX

16. REQUISITOS DE CALIFICACION

TÉRMINOS DE REFERENCIA PARA LA CONTRATACIÓN DE SERVICIOS

1. DENOMINACIÓN DE LA CONTRATACIÓN

Contratación de un servicio especializado para el desarrollo e implementación de un Sistema de Información, en adelante ALIGEN, para el Nuevo Centro Nacional de Perfiles Genéticos Humanos (CNPGH) del Instituto Nacional de Medicina Legal y Ciencias Forenses del Ministerio Público, en adelante UE010- IML, mismo que debe integrarse principal y funcionalmente con el Sistema CODIS (Sistema de Índice Combinado de ADN) y otras fuentes de información internas proveedoras de información de perfiles genéticos y similares. Dicho sistema estará destinado a mejorar las operaciones internas del Centro y la calidad y oportunidad de la atención de los servicios de los laboratorios de ADN de las Unidades de Biología Molecular y Genética de Lima y de las UML de Arequipa y Lambayeque con los cuales interactuará.

2. FINALIDAD PÚBLICA

Contribuir con los servicios que brindará el Centro Nacional de Perfiles Genéticos Humanos (CNPGH) de la UE010- IML mejorando sus operaciones internas a través de una herramienta especializada (sistema de información) que le permita tener seguimiento y control de los perfiles genéticos elaborados por los servicios de los laboratorios de ADN de las Unidades de Biología Molecular y Genética de Lima y de las UML de Arequipa y Lambayeque cuyo almacenamiento centralizado posterior decantará en un banco de perfiles (base de datos de perfiles) de calidad los cuales podrán ser consultados por diferentes tipos de usuarios mediante determinados criterios de consulta.

3. OBJETIVOS GENERALES

● Fortalecer la operación del Centro Nacional de Perfiles Genéticos Humanos (CNPGH) de la UE010- IML.

● Contar con documentación histórica en formato electrónico o digital, con valor legal y plena eficacia jurídica, de los perfiles genéticos administrados.

● Optimizar el tiempo de búsquedas físicas.

● Brindar seguridad y confiabilidad en la información emitida.

● Establecer el registro de perfiles genéticos humanos cuyo almacenamiento centralizado posterior decantará en un banco de

perfiles (base de datos de perfiles) de calidad información que será consultada a través de búsquedas especializadas.

● Incrementar la eficacia de las búsquedas de perfiles genéticos para la oportuna atención de los casos relacionados con las operaciones del Ministerio Público, los juzgados del Poder Judicial, entre otros.

4. ANTECEDENTES DOCUMENTALES

INFORME 051-2015–MPFN-OCTI-OSIS-EPB: Brinda detalle del Sistema CODIS (Sistema de Índice Combinado de ADN).

INFORME 073-2015–MPFN-OCTI-OSIS-EPB: Detalla las especificaciones técnicas y software complementario a requerimiento verbal de la Oficina de Soporte (OSOP).

INFORME N° 000026-2020- MP-FN-OCTI-OSIS-EPB: Al Instituto Nacional de

Medicina Legal y Ciencias Forenses (IML-UE010) del Ministerio Público se le informa sobre el requerimiento de pronunciamiento técnico respecto a la existencia de equipamiento informático para soportar el proyecto de creación del Centro Nacional de Perfiles Genéticos Humanos (CNPGH) y fortalecimiento de los laboratorios de ADN de las Unidades de Biología Molecular y Genética de Lima y de las UML de Arequipa y Lambayeque siendo la implementación del Software CODIS (Sistema de Índice Combinado de ADN) insumo fundamental para este proyecto. En la formulación del proyecto se planteó algunos requerimientos de mejora de las operaciones de los laboratorios de ADN de estos DFs e implementación del Software CODIS.

INFORME N° 000027-2020- MP-FN-OCTI-OSIS-EPB: Definición y

establecimiento de requerimientos funcionales para un eventual desarrollo

“inhouse” que simule y/o replique las funcionalidades del Software CODIS.

OFICIO MÚLTIPLE N° 00013-2020-MP-FN-JN-IMLCF: Remisión de

información para la formulación de EETTs para el proyecto BID Centro Nacional de Perfiles Genéticos Humanos (CNPGH), equipamiento informático y diseño de software de banco de datos.

OFICIO N° 001022-2020-MP-FN-JN-IMLCF: Continuación del Convenio de cooperación con el Banco Genético Argentino para el desarrollo del software en el contexto del proyecto BID Centro Nacional de Perfiles Genéticos (CNPGH).

5. ALCANCE DEL SERVICIO

a. CONSIDERACIONES GENERALES

El tratamiento del ADN en el ámbito penal, permite mejorar la gestión judicial y policial. Basta encontrar en el lugar del crimen un simple vestigio biológico para identificar en él su ADN y compararlo con las muestras recogidas en las bases de datos de ADN que persiguen la resolución de casos criminales permitiendo la comparación automatizada de perfiles genéticos de sospechosos o convictos y en ocasiones de las víctimas, procedentes de la escena del crimen.

Actualmente, la Sub Gerencia de Laboratorio de Biología Molecular y Genética, en adelante LABIMOG y misma que también fungirá como dependencia usuaria líder, de la UE010- IML, viene llevando a cabo el proceso de registro, control y seguimiento de los casos de ADN, así como los procesos de recepción de contenedores de muestras, asignación de casos, solicitud de contenedores de muestras, entrega de contenedores, pretratamiento, extracción, cuantificación, amplificación, etc.

El Centro Nacional de Perfiles Genéticos Humanos (CNPGH), futuro encargado de brindar credibilidad y validación al registro de las muestras, considerará principalmente los siguientes procesos operativos:

● Recepción de la información de los perfiles genéticos elaborados por los laboratorios de ADN de las Unidades de Biología Molecular y Genética de Lima y de las UML de Arequipa y Lambayeque.

● Verificación, comparación y/o contraste de los perfiles genéticos enviados a través del GeneMapper IDX.

● Análisis de rendimientos ADN URF picos de perfil genético vs concentración corregida por degradación e inhibición.

● Verificación de controles positivos y negativos.

● Verificación de contaminación (niveles de ruido).

● Cotejo de los perfiles genéticos enviados en lote.

● Cotejo de los perfiles genéticos enviados contra los perfiles de los individuos participantes (del proceso y del laboratorio enviado).

● Ingreso a la base de datos de perfiles genéticos.

b. GLOSARIO DE TÉRMINOS

● MPFN: Se debe entender que se refiere al Ministerio Público - Fiscalía de la Nación

● CNPGH: Se debe entender que se refiere al Centro Nacional de Perfiles Genéticos Humanos

● SISCNPGH: Se debe entender que se refiere al Sistema de Información que soportará las operaciones del CNPGH.

● IML: Se debe entender que se refiere al Instituto Nacional de Medicina Legal y Ciencias Forenses (IML-UE010)

● OGTI: Se debe entender que se refiere a la Oficina General de Tecnología de la Información del Ministerio Público

● OSIS: Se debe entender que se refiere a la Oficina de Sistemas de la Oficina General de Tecnología de la Información del Ministerio Público

● OSOP: Se debe entender que se refiere a la Oficina de Soporte de la Oficina General de Tecnología de la Información del Ministerio Público

● CEA: Se debe entender que se refiere a la Carpeta Electrónica Administrativa del Ministerio Público (sistema institucional de trámite documentario)

● SIATF: Se debe entender que se refiere al Sistema Integrado de Apoyo al Trabajo Fiscal (basado en el Antiguo Código de Procedimientos Penales)

● SGF: Se debe entender que se refiere al Sistema de Gestión Fiscal (basado en el Nuevo Código Procesal Penal)

● BFE: Se debe entender que se refiere a la Bandeja Fiscal Electrónica

● TRABAJADOR(ES): Se debe entender que se refiere a los funcionarios, servidores o colaboradores del Ministerio Público

● SOLUCIÓN: Se debe entender que se refiere al Sistema de Información que EL PROVEEDOR proveerá, y también a su infraestructura, procesos y procedimientos con los que ofrece su servicio al Ministerio Público

● CONTENIDO(S): Se debe entender que se refiere a documentos electrónicos firmados digitalmente por determinados funcionarios del Ministerio Público admitidos y/o soportados por la solución provista por EL PROVEEDOR

● PORTAL: Se debe entender que se refiere al Portal Web, Sistema de Información Web más su plataforma tecnológica, infraestructura o equivalente provistos por EL PROVEEDOR

● LAS PARTES: Se debe entender que se refiere al Ministerio Público y a EL PROVEEDOR

c. REQUERIMIENTOS LEGALES

● Cumplir todos los requisitos del Ministerio de Trabajo y Promoción del Empleo (MTPE).

● Cumplir con el DS-009-2011-TR.

● Decreto Legislativo N° 1310 Art. N° 3 en donde se autoriza el uso de tecnologías de la digitalización, información y comunicación para la sustitución de documentos físicos y firmas ológrafas.

● Cumplir con el ARTÍCULO 141-A del CÓDIGO CIVIL (Uso de la firma digitalizada).

● Cumplir con la Ley de Firmas y Certificados Digitales LEY Nº 27269

● Cumplir con el Reglamento De La Ley De Firmas Y Certificados Digitales DS-052-2008-PCM.

● Cumplir con el DS-026-2016-PCM.

● Ley de Contrataciones del Estado N° 30225 y su reglamento de acuerdo a las modificaciones vigentes.

d. REQUERIMIENTOS GENERALES DEL SERVICIO

Se desea contratar un servicio especializado para el desarrollo, pruebas, puesta en producción y estabilización post producción del Sistema de Información, en adelante ALIGEN, para el Nuevo Centro Nacional de Perfiles Genéticos Humanos (CNPGH) de la UE010- IML. Dicho sistema debe cumplir con la implementación de todos los requerimientos funcionales, no funcionales, reglas de negocio, casuísticas especiales, reportería especializada u otro componente que se considere necesario para asegurar su funcionalidad. Entre los requerimientos no funcionales se encuentra la correspondiente consideración y alineación del desarrollo a los estándares tecnológicos del Ministerio Público (ver Anexo1).

Como mínimo debe considerarse:

● Desarrollo del sistema de información, en adelante ALIGEN, según los requerimientos funcionales, no funcionales, reglas de negocio, casuísticas especiales, reportería especializada detallados en este documento y los que, de considerarse oportuno, pertinente y no modifique estructuralmente las funcionalidades del sistema, la UE010- IML a través de LABIMOG considere pertinentes.

● Verificar las funcionalidades del Sistema CODIS (Sistema de Índice Combinado de ADN) e implementar los mecanismos necesarios

para que la información que éste emita pueda ser consumida transparentemente por el sistema a desarrollar y viceversa. Este mismo tratamiento debe considerarse para los sistemas GeneMapper IDX u otra fuente de información que LABIMOG estime pertinente considerar.

● Prueba del sistema desarrollado considerando baterías de pruebas unitarias, funcionales, de rendimiento y de seguridad que aseguren el correcto funcionamiento del mismo.

● Puesta en producción del sistema desarrollado asegurando su disponibilidad y correcto funcionamiento.

● Llevar a cabo actividades técnicas complementarias para asegurar la estabilización y funcionalidad general del sistema post puesta en producción.

● Elaboración de documentación técnica (análisis, diseño, desarrollo, configuración y despliegue) y para el usuario final (segmentada por perfiles de usuario y perfil administrativo).

● Capacitar a todos los tipos de usuarios finales y niveles administrativos para el uso/operación del sistema.

● El sistema, como producto final, y todos sus componentes deben ser técnicamente afines e implementables transparentemente en los ambientes y/o plataformas tecnológicas del Ministerio Público siguiendo sus estándares técnicos (ver Anexo1), metodologías de gestión y de desarrollo de software y modelos de documentación.

e. REQUERIMIENTOS ESPECIFICOS DEL SERVICIO

El servicio debe cubrir lo siguiente: Provisión (desarrollo e implementación) de una solución de software (sistema de información) web segura (https) para el control de calidad de los perfiles genéticos provenientes de los laboratorios de ADN de las Unidades de Biología Molecular y Genética de Lima y de las UML de Arequipa y Lambayeque y posterior almacenamiento en un banco (base de datos) de perfiles genéticos.

Flujo general:

En términos generales:

Los inputs de entrada serían:

- Los resultados del trámite de las solicitudes de muestras y procesamiento de las mismas (pretratamiento, extracción, amplificación y análisis) de los laboratorios de ADN de las Unidades de Biología Molecular y Genética de Lima y de las UML de Arequipa y Lambayeque en el formato que estos técnicamente provean siendo, en caso de ser necesario, considerar su respectiva adecuación funcional.

- Información emitida por el Software CODIS (Sistema de Índice Combinado de ADN) en el formato que este técnicamente provea siendo, en caso de ser necesario, considerar su respectiva adecuación funcional.

o Importante también es el hecho de considerar la validación de identidades con los servicios provisto por XXXXXX.

Los outputs de salida serían:

- La generación de reportes estándar y estadísticos con resultados finales según formato establecido por LABIMOG.

- Mecanismos de integración (servicios web) para que sean consumidos por determinados sistemas de información institucionales (Carpeta Administrativa Electrónica (CEA), sistemas fiscales (SIATF, SGF, BFE), SIGA, etc).

f. REQUERIMIENTOS FUNCIONALES

La solución de software (sistema de información) provista debe cumplir con:

- RF-01 El consumo de información automatizada y/o mecanizada provista por los laboratorios de ADN de las Unidades de Biología Molecular y Genética de Lima y de las UML de Arequipa y Lambayeque.

- RF-02 El consumo de información automatizada y/o mecanizada provista por el Software CODIS (Sistema de Índice Combinado de ADN), los sistemas GeneMapper IDX u otra fuente de información que LABIMOG estime pertinente considerar.

- RF-03 Emisión de reporteria estándar, estadística y resultados en formato establecido por LABIMOG.

- RF-04 La provisión de mecanismos de integración (servicios web) para que sean consumidos por determinados sistemas de información institucionales (Carpeta Administrativa Electrónica (CEA), sistemas fiscales (SIATF, SGF, BFE), SIGA, etc).

- RF-05 Eventual consumo de servicios web públicos disponibles en la plataforma de interoperabilidad del estado (PIDE) o aquellos que se hayan provisto a través de convenios interinstitucionales.

- Asimismo:

REQUERIMIENTOS FUNCIONALES ADICIONALES
INGRESO AL SISTEMA		PERFIL ASOCIADO
RF-06	El sistema debe contar con una interfaz pública y una administrativa, ambas multimodales, para el control de accesos de usuarios (login). Estas interfaces deben autenticar (validar identidad) y autorizar (según determinado perfil pre asignado) a los usuarios que pretendan acceder al sistema. Para esto el sistema debe

	integrarse transparentemente con el Sistema de Administración de Usuarios del Ministerio Público (SAD). La interfaz pública debe permitir el registro y alta de usuarios para los laboratorios aportantes (para entrega/carga de perfiles genéticos) y usuarios externos (para consulta de búsquedas de perfiles genéticos). Estas interfaces deben considerar: ● El ingreso de un usuario y una clave ● Un mecanismo de recuperación de claves y envío de correo (para remisión de credenciales) ● Una glosa informativa referida a la Protección de Datos Personales, Políticas de Seguridad y Confidencialidad de la Información
RF-07	El sistema debe considerar un mecanismo de control de sesiones y tiempo de inactividad. Sólo debe permitirse el ingreso de usuarios con un perfil determinado o pre asignado. Asimismo, la sesión de usuario debe cerrarse transcurridos diez (10) minutos de inactividad. Este valor/parámetro debe ser configurable a través de las opciones de mantenimiento del sistema. En el caso de la interfaz administrativa el cierre de sesión explícito debe redirigir al menú principal/dashboard de sistemas (asignados) del SAD.
VISTA PRINCIPAL DEL SISTEMA (DASHBOARD/HOME)
RF-08	Una vez se ingrese al sistema, y en las pantallas internas, se debe mostrar la siguiente información: ● Nombres y apellidos del usuario logueado ● Usuario o login ● Perfil ● Fecha y hora ● Versión del sistema ● Menus y opciones correspondientes al perfil autorizado
MANTENIMIENTO DEL SISTEMA
RF-09	El sistema debe tener implementado tablas (a nivel de BD) y vistas de usuario para registrar y reportear la auditoría y trazabilidad de todos los eventos y/o movimientos que el sistema genere operacionalmente.	ADMINISTRADOR

	Se debe registrar y reportear los eventos de: ● Consultas ● Modificaciones/Actualizaciones ● Eliminaciones ● Impresión
RF-10	El sistema debe permitir el mantenimiento (CRUD) de todas sus tablas maestras: ● Indicadores ● Tipos de exámenes ● Tipos de muestras ● Tipos de perfiles ● Lotes de Kits (reactivos) ● Peritos ● Laboratorios aportantes ● Usuarios ● Perfiles ● UMLs ● Ubigeos ● Otras identificadas en tiempo de análisis, diseño y desarrollo	ADMINISTRADOR
RF-11	El sistema debe permitir la emisión, como mínimo, de los siguientes reportes: ● Reporte de Custodia ○ Xxxxx de muestra ○ Muestras por ingresante ○ Xxxxxxxx por solicitud ○ Xxxxxxxx entregadas x xxxxxx ○ Xxxxxxxx retornadas xx xxxxxx ○ Xxxxxxxx retornadas a la autoridad solicitante ● Reporte de Análisis ● Informe final ● Reporte de auditoría y trazabilidad ● Reporte de productividad por perito ● Otros establecidos por LABIMOG	ADMINISTRADOR
RF-12	El sistema debe permitir la administración de usuarios (haciendo uso del mecanismo de integración con el Sistema de Administración de Usuarios del Ministerio Público (SAD)) sin intervención de la OGTI, consultando y eventualmente manteniendo a los usuarios creados	ADMINISTRADOR

	por parte de los laboratorios, usuarios externos e internos. Debe permitirse la unitaria o masiva.
RF-13	El sistema debe permitir consultar y hacer seguimiento de información de todos los procesos operativos del sistema, en especial de los casos registrados, en base a criterios de búsqueda estándares, predeterminados o establecidos por LABIMOG.	SUBGERENTE
RF-14	Como parte de estas consultas y seguimientos el sistema debe permitir consultar los pagos realizado en las plataformas del Banco de la Nación (ventanilla y xxxxxx.xx) según TUPA de la UE010- IML y referidos al caso registrado. Este pago está relacionado con casos de tipo: ● Casos civiles del juzgado ● Casos fiscales (Pago exonerado)	SUBGERENTE
RF-15	El sistema debe permitir la asignación/reasignación de casos a un determinado perito. Se debe tomar en cuenta que esta actividad debe hacerse en forma automática y se debe validar que los casos asignados/reasignados a los peritos sea de forma equitativa. Debe considerarse para la asignación/reasignación casos como: ● Perito con descanso médico ● Personal activo ● Escenarios de rotación de personal Asimismo, el sistema debe permitir la edición de las asignaciones/reasignaciones guardando la respectiva auditoría y trazabilidad del cambio.	SUBGERENTE
RF-16	El sistema debe generar un documento de tipo Oficio (según modelo establecido por LABIMOG) bajo el esquema borrador o preliminar (descargable para edición) con todos los datos de las conclusiones del informe emitido por el perito, siendo también necesaria la descarga de este informe para una eventual inclusión/anexo al Oficio. Este oficio es para para la entrega del caso a los clientes particulares o autoridades correspondientes.	SUBGERENTE
RF-17	El sistema debe permitir consultar información histórica por caso: ● Caso atendido	SUBGERENTE

	● Caso en proceso ● Caso finalizado ● Caso reiterado (duplicidad) ● Otros establecidos por LABIMOG
RF-18	El sistema debe permitir registrar la programación de las diligencias (toma de muestras y ratificaciones) relacionadas a un caso. Al finalizar, se debe enviar un correo electrónico al responsable de la diligencia.	SUBGERENTE
RF-19	El sistema debe permitir consultar completamente el registro realizado en Mesa de Partes, con los datos del paquete lacrado recepcionado. Esta consulta debe considerar como criterios: ● Código de lacrado ● Fecha de registro ● Carga de Fotos (de cómo llega) ● Tipo de contenedor a almacenar ● Número y año de caso ● Muestra peligrosa (restos óseos) ● Otros establecidos por LABIMOG	SUBGERENTE
RF-20	El sistema debe permitir registrar los casos de: a) Solicitantes particulares Considerando: ● Nombres y apellidos completos ● Número de DNI/CE/PTP/PAS ● Correo electrónico ● Número de teléfono/celular ● Voucher (Válido solo para filiación por Xxxxxxxxxx) ● Otros establecidos por LABIMOG b) Solicitantes Dependencias Fiscales o Juzgados Considerando: ● Ruc de la autoridad o institución ● Nombres completos del fiscal o juez ● Correo electrónico de la autoridad o institución ● Número de teléfono/celular ● Tipo y número de documento del trámite documentario ● Por defecto, el pago es exonerado ● Otros establecidos por LABIMOG El registro debe generar un código d registro para el caso con el formato: Código UML (región, departamento y sede) , año y correlativo.	MESA DE PARTES

	Otras consideraciones: ● Por defecto el registro debe estar como ‘NN’: no identificado. ● En caso se tenga identificada a la persona se deberá tener implementada la funcionalidad de validación de identidad mediante el servicio RENIEC (Por Nro. DNI y Nombres y apellidos) o de forma manual (si existiese inconvenientes con servicio RENIEC). ● Se debe tener las funcionalidades de registro de cambios de identidad mismo que internamente debe auditarse y guardar trazabilidad.
RF-21	El sistema debe permitir consultar todos los casos registrados como mínimo por los siguientes filtros o parámetros: ● Tipo de muestra ● Nombre de reactivos utilizados ● Año y mes ● Rango de fechas ● Etapa de procesamiento ● Personas involucradas ● Otros establecidos por LABIMOG	MESA DE PARTES
RF-22	El sistema debe permitir consultar y completar el registro previamente realizado por Mesa de Partes con los datos del paquete de lacrado recepcionado. Considerando: ● Código de lacrado ● Fecha de registro ● Carga de contenido gráfico o de sustento de estado (de cómo llega) ● Tipo de contenedor a almacenar ● Número y año de caso ● Muestra peligrosa (restos óseos) ● Observaciones ● Otros establecidos por LABIMOG	ASISTENTE MEDICO LEGAL
RF-23	El sistema debe permitir realizar la transferencia del caso a un determinado perito, a solicitud del mismo o consultando previas asignaciones/reasignaciones hechas en automático o por el Subgerente. Al finalizar, el sistema enviará un correo electrónico del movimiento realizado.	ASISTENTE MEDICO LEGAL

RF-24	El sistema debe permitir consultar los casos asignados/reasignados por el subgerente o quien haga sus veces. La consulta debe hacerse principalmente con el número de caso. Asimismo, el perito puede solicitar al Asistente Médico Legal la evidencia o muestra del caso.	PERITO
RF-25	El sistema debe permitir marcar el avance del proceso por etapas (pretratamiento, extracción, cuantificación, amplificación y análisis) y registrar los insumos utilizados por etapa. Por cada etapa del proceso por el que pase la muestra se debe generar un registro en el sistema.	PERITO
RF-26	El sistema debe permitir la carga, descarga y pre- visualización de contenido que sustente o respalde cada etapa del proceso por que el pasa la muestra. Ejemplos: Para un determinado caso que por ejemplo tenga 25 muestras puede requerirse la carga de aproximadamente 100 fotos de sustento. Para un determinado caso puede requerirse la carga de 4 fotos “escenciales” por muestra. La carga de este contenido de sustento deberá pasar por un algoritmo de alta compresión previo a su almacenamiento.	PERITO
RF-27	El sistema deberá permitir registrar los movimientos de la muestra (entrada/salida, fecha y hora y otros) en custodia brindadas al perito o viceversa. Considerando: Tipos de movimientos de Custodia x Xxxxxx: ● Entrega de muestra por primera vez ● Por reprocesamiento Tipos de movimientos xx Xxxxxx a Custodia: ● Devolución de muestra ● Entrega de muestra sobrante	PERITO
RF-28	El sistema deberá permitir realizar la transferencia del caso al analista genético. Este podrá ver el caso e ingresar la información necesaria y dar la respectiva conformidad como se estipula en el RF-31.	PERITO

RF-29	El sistema deberá permitir generar un informe final (según formato establecido por LABIMOG), una vez dada la conformidad por el área de análisis. Luego, vía mecanismo de integración previamente implementados (RF-04) se enviará dicho informe al Subgerente o quien haga sus veces. El informe debe ser pre-visualizado antes de su envío.	PERITO
RF-30	El sistema deberá permitir registrar los insumos faltantes para luego ser enviados por correo electrónico al Subgerente o quien haga sus veces en caso de no contar con stock de insumos para el caso asignado. El mensaje debe contener: ● Nombre xxx xxxxxx ● Número de caso asignado ● Insumos faltantes ● Observaciones	PERITO
RF-31	El sistema deberá permitir consultar la información transferida por el perito para descargar dicha información y comenzar con el análisis para marcar la conformidad del proceso de análisis. Luego, el sistema deberá permitir cargar la información del Perfil Genético y otros archivos (electroferogramas) para ser enviada al perito por el servicio CEA (RF-04).	ANALISTA GENETICO
RF-32	El sistema deberá permitir cargar la información requerida por el RF-34 cuando se solicite enviar la información de los Perfiles Genéticos analizados al Centro de Perfiles Genéticos. Los archivos que se solicitan se obtienen de los software internos (Ejemplo: GeneMapper IDX, Familias, etc) los cuales son obtenidos con extensión: .csv, .txt, .xls y .hid.	ANALISTA GENETICO
RF-33	El sistema deberá permitir recepcionar el caso devuelto del Centro de Perfiles para su revalidación. Este proceso consta de registrar la trazabilidad y el motivo de devolución. Ejemplo: Contaminación por personal del laboratorio, por traslado o por un externo.	ANALISTA GENETICO

RF-34	El sistema deberá permitir cargar los datos y archivos con extensión (.csv, .xls, .txt, .hid) unitariamente o masivamente necesarios para el debido control de calidad. Considerando: ● Laboratorio procedente ● Nombre completo del responsable de laboratorio ● Correo electrónico del responsable de laboratorio ● Número teléfono o celular del responsable de laboratorio ● Tipo de Muestra ● Fecha de registro ● Archivos (Raw data y Perfil Genético) ● Parámetros de análisis por perfil genético ● Concentración ADN, inhibición y degradación de las muestras por perfil genético (casos de restos óseos) ● Observaciones por perfil genético Para el caso del Ministerio Público (laboratorios de ADN de las Unidades de Biología Molecular y Genética de Lima y de las UML de Arequipa y Lambayeque), el sistema debe vincular la información obtenida de la muestra y los datos iniciales como Raw Data, Perfil Genético y Código de Muestra donde el Centro Nacional de Perfil Genético acreditará dicha información.	LABORATORIO CONTRIBUYENTE
RF-35	El sistema deberá permitir consultar y descargar la información enviada por los laboratorios de ADN de las Unidades de Biología Molecular y Genética de Lima y de las UML de Arequipa y Lambayeque.	OPERADOR PRE BANCO
RF-36	El sistema deberá permitir registrar los parámetros de análisis asociados a la validación realizada por el GeneMapper IDX y otros software internos de uso del Centro Nacional de Perfiles Genéticos.	OPERADOR PRE BANCO
RF-37	El sistema deberá permitir cargar los archivos obtenidos del análisis por el GeneMapper IDX y guardar los datos en dos tablas: ● Archivo 1: Tabla (1) de Perfiles Genético con sus	OPERADOR PRE BANCO

	códigos ● Archivo 2: Tabla (2) de Calidad del Perfil Genético
RF-38	El sistema deberá permitir asignar el tipo de banco al que pertenecen los registros de perfiles genéticos de la Tabla (1) (RF-37).	OPERADOR PRE BANCO
RF-39	El sistema deberá permitir asignar un valor a partir del análisis de rendimiento ADN URF por Picos vs Concentración corregida por degradación e inhibición de perfil genético. (Promedio, desviación estándar, etc).	OPERADOR PRE BANCO
RF-40	El sistema deberá permitir marcar si se cumple con los controles positivos y negativos.	OPERADOR PRE BANCO
RF-41	El sistema deberá permitir marcar la aprobación de la no contaminación en los Perfiles Genéticos (niveles de ruido).	OPERADOR PRE BANCO
RF-42	El sistema deberá permitir cotejar/contrastar/comparar los datos de los individuos que participaron en el proceso del Perfil Genético y del laboratorio contribuyente.	OPERADOR PRE BANCO
RF-43	El sistema deberá permitir marcar la devolución de los Perfiles Genéticos que presenten contaminación, disipación u otra observación. Posteriormente se notificará por correo electrónico a la Jefatura del Centro de Perfiles.	OPERADOR PRE BANCO
RF-44	El sistema deberá permitir consultar y pre-transferir los perfiles genéticos que hayan pasado por todas las pruebas de calidad hacia el Banco Central de Datos Genéticos.	OPERADOR PRE BANCO
RF-44	El sistema deberá permitir visualizar y registrar por unidad o masivamente los Perfiles Genéticos (pre- transferidos) de forma encriptada, asignarlos a un tipo de banco y alguna observación presentada durante el registro, para almacenarlos en el sistema. Asimismo, el	OPERADOR BANCO

	sistema permitirá enviar por correo electrónico al laboratorio procedente el caso del Perfil Genético con observación. El sistema sólo registrará los Perfiles Genéticos únicos o si se presentan casos de duplicidad será almacenado en aceptación del Jefe del Centro de Perfiles Genéticos. En caso de que no se almacene, este se mantendrá como histórico de consulta.
RF-46	El sistema deberá permitir consultar los Perfiles Genéticos por su código de Perfil Genético. Además, se podrá hacer un filtro por tipos de Muestras (Banco): ● Muestras de referencia ● Muestra de evidencia ○ SubBanco de muestra únicas ○ SubBanco de perfiles mezclados ● Muestras de restos óseos identificadas ● Muestras de restos óseos no identificadas	OPERADOR BANCO
RF-47	El sistema deberá permitir cotejar el perfil genético a solicitud de la autoridad competente. Este proceso constará de una comparación del perfil genético contra ‘N’ bancos de perfiles genéticos por unidad o masivamentemediante el algoritmo ALIGEN. El cotejo se realizará mediante el algoritmo ALIGEN o por comparación de códigos de Perfiles Genéticos.	OPERADOR BANCO
RF-48	El sistema deberá permitir consultar y descargar el informe final (según formato establecido por LABIMOG) sobre la identificación (Inclusión de data de trazabilidad y calidad). El sistema debe tener un campo de registro de correlación de la muestra procesada con la data de calidad del perfil genético. Entiéndase calidad como el proceso de validación previo al almacenamiento en el banco central de datos genéticos.	OPERADOR BANCO
RF-49	El sistema deberá permitir generar los siguientes reportes: ● Casos de Perfiles Genéticos duplicados por rango de fechas y otros parámetros. (PRE-BANCO)	JEFATURA CNPGH

● Casos de Perfiles Genéticos duplicados aceptados y no aceptados. (PRE-BANCO)

● Nuevos Perfiles Genéticos ingresados por rango de fechas y otros parámetros.

● Casos de errores de Perfiles Genéticos (contaminación por ruido, contaminación cruzada y límite estocásticos entre otros) por Laboratorio.

● Cantidad de consultas realizadas por entidades externas al MPFN.

● Listado de los laboratorios y usuarios registrados para consultas.

Los reportes pueden incluir tipos tablas y tipos gráficos (curva, barras, dispersión y circular). Asimismo, deben generarse indistintamente en formatos *.PDF, *.XLS,

*.TXT, * .CSV

RF-50

La interfaz publica especifica en el RF-06 deberá permitir consultar información de determinado Perfil Genético a través de los accesos previamente creados y autorizado por el Centro de Banco de Perfiles Genéticos.

USUARIO EXTERNO

RF-51

El sistema deberá permitir responder mediante correo electrónico la solicitud consulta por el usuario con los siguientes datos:

● Perfil Genético buscado

● Código de la muestra

● Tipo de Muestra

● Centro de laboratorio donde se procesó la muestra

● Código xx xxxxxx o QR

La información consultada tendrá un correlativo único y una firma digital (certificado digital clase V) para corroborar la autenticidad de la información. El certificado y su integración funcional debe ser provisto por el PROVEEDOR. El archivo generado debe guardarse como copia de seguridad (backup) en el respectivo almacenamiento interno.

USUARIO EXTERNO

g. REQUERIMIENTOS NO FUNCIONALES

La solución de software (sistema de información) provista debe cumplir con:

REQUERIMIENTOS NO FUNCIONALES
RNF-01	El sistema debe ser capaz de operar adecuadamente con sesiones de hasta 2.000 usuarios concurrentes.
RNF-02	El sistema debe garantizar el almacenamiento eficiente de contenido que sustente o respalde los resultados que arroje la operación del mismo, estos eventualmente pueden ser fotos, archivos (txt, pdf, xls, doc, etc). La eficiencia del almacenamiento debe considerar el pasar por un algoritmo de compresión previo a su almacenamiento.
RNF-03	El sistema debe considerar mecanismos de recuperación ante desastres. Xxxx debe ser luego transferido a la UE010- IML.
RNF-04	El sistema debe poseer un diseño de tipo “responsive” a fin de garantizar la adecuada visualización en múltiples computadores personales, dispositivos tablets y teléfonos inteligentes.
RNF-05	El sistema debe proporcionar alertas visuales claras, informativas e intuitivas antes mensajes de error o del sistema que permita orientar al usuario a la ejecución de una acción correcta o esperada.
RNF-06	El sistema debe garantizar su amigabilidad para el usuario final (estándares UX/UI). Ello debe aplicarse para: ● Pantallas (interiores y exteriores) ● Herramientas de ayuda visual (Tooltips) ● Notificaciones y Mensajes (Alertas y Popups) ● Alineación al Manual de Identidad Corporativa ● Interfaces gráficas de usuario intuitivas y ergonómicas para evitar uso de manuales, soportar sugerencias (intellikey o similar) ● Interfaces gráficas de usuario livianas diseñadas para que funcionen óptimamente en enlaces de datos con ancho xx xxxxx limitado
RNF-07	El sistema debe garantizar que la tasa de errores cometidos por el usuario deberá ser menor del 1% de las transacciones totales ejecutadas en el sistema.
RNF-08	El PROVEEDOR entregará el “Manual de técnico”, “Manual de usuario

	final”, “Manual de Administrador” y “Manual de instalaciones e integración” cada vez que el sistema sea modificado, estos documentos deberán ser actualizados y entregados al responsable técnico de la UE010- IML y de la OGTI.
RNF-09	El PROVEEDOR debe garantizar que las horas definidas, establecidas y destinadas para capacitaciones sean las suficientes para que los usaurios del sistema puedan asimilar oportunamente y eficiente todas las funcionalidades del sistema, así como su operación.
RNF-10	El sistema debe procurar alinearse a los estándares tecnológicos institucionales (ver Anexo1).
RNF-11	El PROVEEDOR debe presentar la arquitectura sobre la cual va a basar su desarrollo, lenguaje de programación, framework, modelo de datos y un diccionario de datos. El PROVEEDOR debe contemplar el uso y correcto control de licencias de software según las tecnologías empleadas, mismas que no deben generar costos adicionales para la UE010- IML y la OGTI. Considerar herramientas que tengan más de 3 años en el mercado con soporte activos y que permitan el mejoramiento y acceso a nuevas versiones de acuerdo con la evolución de las plataformas.
RNF-12	El PROVEEDOR debe brindar actualizaciones del sistema cuando se involucre un tema de seguridad y/o óptimo aprovechamiento de las funciones provistas por el sistema durante toda la etapa de desarrollo y antes de la conformidad.
RNF-13	El sistema debe garantizar que el mismo y sus procedimientos de mantenimiento de datos deban cumplir con las leyes y reglamentos de protección y privacidad de datos médicos y legales.
RNF-14	El sistema debe evitar que las interfaces permitan vulnerabilidad xx Xxxxx Site Scripting. El sitio web no debe ser vulnerable a ataques XSS, que permitan inyectar código que afecte al usuario final mediante el robo de sesiones o la ejecución remota de scripts. Se deberá codificar usando entidades html para limpiar las variables recibidas por GET/POST usando la librería ESAPI de OWASP. Se deberá realizar una validación de datos.
RNF-15	El sistema debe evitar que las interfaces permitan vulnerabilidad de Inyección SQL, para lo cual se deberá utilizar sentencias dinámicas en la

	creación de las consultas SQL. No se deberá concatenar las variables para generar la consulta.
RNF-16	El sistema se debe desarrollar y cumplir las buenas prácticas de programación segura descritas en el “Development Guide de OWASP" y complementariamente en la Guía de Desarrollo de la Oficina de Sistemas (OSIS) de la OGTI.
RNF-17	El sistema debe contar con los debidos controles base para un adecuado desarrollo de aplicaciones seguras según las recomendaciones y líneas base del estándar de desarrollo seguro de OWASP; se debe evitar el riesgo de permitir la extracción automatizada de la información privada del CENTRO NACIONAL DEL BANCO DE PERFILES GENÉTICOS. En caso se presente una vulnerabilidad, el sistema debería permitir ser bloqueada y no operar hasta que el Oficial de Seguridad evalúe el hecho.
RNF-18	Se debe desarrollar el sistema completamente paramétrico, sin tener código “en duro”, garantizando el sistema con los mayores niveles de flexibilidad en cuanto a la parametrización de los tipos de datos, de tal manera que la administración del sistema sea realizada eficientemente por el administrador del sistema.
RNF-19	El sistema debe contemplar que los tiempos de respuesta para abrir documentos electrónicos almacenados no sean mayores a los que se tiene en las funcionalidades que por ejemplo se tiene al usar el Explorador de Windows. Los tiempos deben ser tomados considerando en ambos casos las mismas condiciones tecnológicas.

6. EJECUCIÓN DEL SERVICIO

El servicio será ejecutado en las instalaciones del PROVEEDOR. La UE010- IML coordinará, de ser necesario, con la Oficina General de Tecnología de la Información del Ministerio Público (OGTI) y/o con sus gerencias de línea (OSOP, ORECOM, OSIS) la provisión de acceso remoto a determinados ambientes (desarrollo/pruebas/producción/BD) para el consumo o integración de determinados servicios propietarios del Ministerio Público. Asimismo, para los efectos de una eventual necesaria integración con estos, la UE010- IML también coordinará con la Oficina General de Tecnología de la Información del Ministerio Público (OGTI) y/o con sus gerencias de línea (OSOP, ORECOM, OSIS) para la provisión y habilitación de ambientes de desarrollo, pruebas y/o de base de datos para la ejecución de dicha actividad.

El plazo para la prestación del servicio será de 8 meses (240 días calendarios) y culminará con la acreditación de conformidad de la entrega total y formal del sistema a UE010- IML misma que de considerarlo pertinente coordinará para dichos efectos con la Oficina General de Tecnologías de la Información (OGTI) para la prestación del apoyo consultivo-técnico que se estime pertinente.

PLANIFICACION MACRO	MESES
TAREA	MES 1	MES 2	MES 3	MES 4	MES 5	MES 6	MES 7	MES 8
Planificación
Coordinaciones preliminares
Presentación de equipos de trabajo
Coordinaciones con usuarios líderes de áreas involucradas
Elaboración de plan de trabajo
Presentación de plan de trabajo
Subsanación/aprobación del plan de trabajo
Desarrollo
Ingeniería de requerimientos
Análisis
Diseño
Desarrollo
Pruebas
Implementación
Estabilización
Capacitación
Documentación
Elaboración

Planificación macro

El plazo indicado será contabilizado a partir del día siguiente de haberse recepcionado, revisado y aprobado el Plan de Trabajo, hecho que se materializará en la emisión de un Acta de Conformidad la cual será emitida por la UE010- IML contando para ello con el apoyo consultivo-técnico de la Oficina General de Tecnologías de la Información (OGTI).

Cabe mencionar que como parte de las coordinaciones el PROVEEDOR debe coordinar con la UE010- IML la realización de talleres y/o sesiones de trabajo con el objetivo de la transmisión de conocimiento para el desarrollo del sistema.

El proyecto será gestionado en forma integral combinando las buenas prácticas y recomendaciones del PMBOK para la planificación, monitoreo y gestión en general del proyecto y bajo metodologías ágiles (SCRUM) en lo que respecta al desarrollo del producto, con presentaciones de avances y/o retroalimentación cada 15 días hábiles. Estas sesiones también se deberán llevar a cabo en los otros niveles de gestión del proyecto (técnica, directiva y ejecutiva).

Se utilizará la Guía XXXXX 0xx Ed. para la elaboración de un Plan de Trabajo General del Proyecto que contemple la planificación, ejecución, monitoreo y cierre de todos los elementos necesarios para el proyecto en las 10 áreas de conocimiento: Integración, Alcance, Cronograma, Costos, Calidad, Recursos, Comunicaciones, Riesgos, Adquisiciones, Interesados. Cada vez que se ponga en producción un entregable este se deberá complementar con todas las actividades de capacitación necesarias tanto a la parte funcional como técnica de la UE010- IML u otra dependencia que se estime pertinente hacer partícipe. De esta forma, el proyecto estará gestionado bajo un marco basado en PMBOK, pero el desarrollo se llevará a cabo mediante SCRUM.

El desarrollo se llevará a cabo bajo la metodología SCRUM. La UE010- IML entregará las historias de usuario, así como un backlog completo del producto esperado y el “reléase plan”. El “reléase plan” contendrá un conjunto de “sprints” subdivididos en elementos seleccionados en el “backlog” del producto esperado para el ámbito de cada funcionalidad. Para alcanzar el objetivo de los “releases”, estos serán desarrollados a partir de los más importantes y concluyendo con los menos importantes de acuerdo con las opiniones especializadas en conjunto con las decisiones del negocio de la UE010- IML. Cada “sprint” tendrá una duración de 15 días hábiles.

La siguiente imagen muestra un mapa ágil del producto esperado. Representa una visión de como el producto debería ser desarrollado con una duración total estimada de 8 meses. El mapa conduce la dirección del producto y determina las expectativas de los interesados durante el desarrollo, además de mostrar cómo se realizará todo el esfuerzo a lo largo del tiempo.

PLANIFICACION

MACRO

MESES

TAREA

MES 1

MES 2

MES 3

MES 4

MES 5

MES 6

MES 7

MES

Desarrollo

Ingeniería de

requerimientos

Análisis

Diseño

R1 E3

Desarrollo

S10

S11

S12

S13

S14

S15

S16

Pruebas

S17

S18

Implementación

R10

Estabilización

Capacitación

S= Sprint | R=Reléase | E= Entregable

En este cuadro se detallan los “sprints” con los “releases” y entregables esperados desarrollados bajo la metodología SCRUM. Para su ejecución se tomará en cuenta los insumos y criterios utilizados para el análisis y categorización de las historias de usuario los cuales decantarán en “releases” y “entregables”.

Algunos de los insumos principales serán:

- Las historias de usuario elaboradas en el contexto del análisis de requerimientos, alcance y definición funcional. El análisis de estas historias de usuario permitirá establecer las dependencias tanto de sus componentes informáticos como de los procesos en sí (entrada y salida de la información).

- Documentación elaborada o provista por la UE010- IML.

- Sesiones de trabajo entre las áreas funcionales y técnicas respectivamente en las que se establecerán determinados criterios de implementación y sus consideraciones.

Algunos de los principales criterios serán:

- El valor de las funcionalidades para la UE010- IML que son la guía principal para la priorización y establecimiento de los productos esperados.

- La agrupación de historias de usuario que estará en función de los procesos establecidos por la UE010- IML y por el Centro Nacional de Perfiles Genéticos Humanos (CNPGH).

- Consideración de la previsión necesaria para que el desarrollo se haga dentro de los plazos establecidos para el proceso de desarrollo.

7. EQUIPAMIENTO PARA LA PRESTACIÓN DEL SERVICIO

Todo recurso software, hardware, computadoras, servidores, bases de datos, escáneres de documentos, personal, muebles para el personal o cualquier otro recurso que se necesite para la prestación adecuada y oportuna del servicio, será provisto por el PROVEEDOR. Asimismo, este deberá contar con los mecanismos, equipamiento y ambientes de contingencia necesarios que le permita garantizar la disponibilidad del servicio a efectos de atender con rapidez cualquier incidente que pueda afectar la prestación del mismo.

8. PERSONAL PARA LA PRESTACION DEL SERVICIO Y SOPORTE TECNICO

El PROVEEDOR deberá presentar un Plan de Trabajo, el listado y curriculums vitae (CV) no documentado del personal propuesto para la prestación del servicio en un plazo xxxxxx xx xxxx (10) días contados a partir de la entrega de la Orden de Servicio, previa suscripción del contrato, conforme a lo presentado en su propuesta técnica. Entregado el Plan, la UE010- IML tendrá un plazo máximo de cinco (5) días para aprobar y/o dar conformidad al plan. A partir del día siguiente de la conformidad del plan de trabajo, comenzará a correr el plazo para el desarrollo del sistema.

El PROVEEDOR contará con un Coordinador de Proyecto (o quién haga sus veces) a cargo de gestionar toda la implementación del sistema. El mismo deberá permanecer a tiempo completo durante la ejecución del proyecto (actividades antes, durante y después del desarrollo) y deberá tener la capacidad de decisión respecto a las coordinaciones propias con la UE010- IML. Asimismo, éste coordinará estrechamente toda acción referida al proyecto con los representantes de LABIMOG y con el coordinador que designe la Oficina General de Tecnologías de la Información (OGTI) a través de la Oficina de Sistemas (OSIS). Este nivel de coordinación debe asegurar de que toda actividad referida a la ejecución del proyecto esté consensuada, se dé por entendida y esté acorde a los requerimientos establecidos por el área usuaria. Cabe precisar que LABIMOG de la UE010- IML es la dependencia usuaria final y beneficiaria del servicio. La Oficina General de Tecnologías de la Información (OGTI) a través de la Oficina de Sistemas (OSIS) fungirá como apoyo consultivo-técnico para determinadas actividades que se identifiquen en todas las etapas del proyecto, así como en las fases de desarrollo respectivamente.

Este Coordinador debe tener amplia experiencia en el uso de las buenas prácticas y recomendaciones del PMBOK, pero a la vez, en metodologías ágiles, de preferencia certificado en SCRUM.

El PROVEEDOR contará con todo el personal necesario requerido que sea parte del equipo de análisis y desarrollo que garantice que se alcancen los objetivos del proyecto y que se cumplan los requisitos definidos. Este les brindará toda la infraestructura requerida y el canal de comunicación formal con la UE010- IML siendo el mismo a través de su Coordinador.

EL PROVEEDOR a discreción, demanda o necesidad específica, previamente informada y/o sustentada a todos los involucrados en el proyecto, designará precisamente a este personal necesario que se precie de ser clave (y transversal) y de apoyo para todas las actividades requeridas por el análisis, desarrollo, implementación y estabilización del sistema. Este conjunto de profesionales, bajo la coordinación del Coordinador de Proyecto, deberá considerar como mínimo:

Equipo Clave:

- un (01) especialista en procesos

- un (01) analista funcional

- dos (02) analistas programadores (front end/back end)

- un (01) especialista en bases de datos Equipo de Apoyo

- un (01) documentador

- un (01) asegurador de calidad de software

- un (01) un arquitecto de software

- un (01) especialista en temas y tópicos materia del proyecto

Una vez finalizada la etapa de desarrollo del sistema y a partir del día siguiente de brindada la conformidad del informe final, se ingresará en periodo de mantenimiento y operación por un (01) año. Durante esta fase el PROVEEDOR estabilizará, soportará, subsanará e implementará mejoras solicitadas por la UE010- IML o que se identifiquen en el sistema o para el mismo.

El PROVEEDOR deberá considerar como mínimo un (01) mes calendario de garantía para el Soporte Técnico. La garantía regirá a la firma del Acta de conformidad y la puesta en producción de todo el sistema.

La UE010- IML podrá reportar incidentes telefónicamente o por correo electrónico, considerándose todas estas formas igualmente válidas. EL PROVEEDOR deberá proporcionar un código de incidente (ticket), para el posterior seguimiento de la atención del mismo. Posteriormente, a solicitud de la UE010- IML, el PROVEEDOR deberá proporcionar un informe o reporte del estado del incidente reportado y su correspondiente atención.

9. ENTREGABLES DEL SERVICIO

Todo entregable del servicio debe realizarse por trámite administrativo y documentario regular vía Mesa de Partes de la UE010- IML.

Supuestos: 1 mes = 30 días calendario

- Entregable 1 (A entregar a los 30 días de emitida la OS)

o Plan de trabajo, metodología y cronograma del servicio a realizar acorde a los TRDs

o Documento (diagrama BPMN o flujograma) y análisis de todos los procesos actuales (AS IS)

o Documento validado de los problemas, necesidades y oportunidades del Instituto Nacional de Medicina Legal y Ciencias Forenses (IML- UE010) a través de la Sub Gerencia de laboratorio de Biología Molecular y Genética (LABIMOG) y del Centro Nacional de Perfiles Genéticos Humanos (CNPGH), respecto a los datos e información.

o Documento (diagrama BPMN o flujograma) y propuesta analizada de todos los procesos a futuro (TO BE)

o Documento propuesta de la solución software (alto nivel) considerando servicios, niveles de integración, etc

o Presentación de la propuesta (archivo ppt y documentación de soporte)

o Actas de reuniones y registro de acuerdos

o Informe 1 aprobado por Instituto Nacional de Medicina Legal y Ciencias Forenses (IML-UE010) a través de la Sub Gerencia de laboratorio de Biología Molecular y Genética (LABIMOG)

- Entregable 2 (A entregar a los 60 días de emitida la OS)

o Documento de análisis del sistema (Casos de uso del sistema, modelo de datos, diagrama de clases, diagrama de secuencia, arquitectura del software)

o Documento de diseño del sistema

▪ Prototipos funcionales

▪ Modelo de datos (físico y lógico inc. diccionario de datos)

o Documento propuesta de la solución software (bajo nivel) considerando servicios, niveles de integración, componentes, fuentes de información, etc

o Documento consolidado de RFs y RNFs, reglas de negocio, casuísticas especiales, formatos de reporteria, etc

o Actas de reuniones y registro de acuerdos

o Informe 2 aprobado por Instituto Nacional de Medicina Legal y Ciencias Forenses (IML-UE010) a través de la Sub Gerencia de laboratorio de Biología Molecular y Genética (LABIMOG)

- Entregable 3 (A entregar a los 90 días de emitida la OS)

o Elaboración de código software back-end – ITERACION1

o Elaboración de código software front-end – ITERACION1

o Scripts actualizados de creación y/o actualización de objetos fuente, objetos de base de datos y objetos compilados - ITERACION 1

o Contratos de servicio de servicios web

o Documento actualizado de diseño del sistema

▪ Modelo de datos (inc. diccionario de datos)

o Documento actualizado de propuesta de la solución software (bajo nivel) considerando servicios, niveles de integración, componentes, fuentes de información, etc

o Documento de implementación de medidas de seguridad (OWASP, datos sensibles encriptados e incluir registros y módulos de auditoría y trazabilidad)

o Documento consolidado actualizado de RFs y RNFs, reglas de negocio, casuísticas especiales, formatos de reporteria, etc

o Actas de reuniones y registro de acuerdos

o Informe 3 aprobado por Instituto Nacional de Medicina Legal y Ciencias Forenses (IML-UE010) a través de la Sub Gerencia de laboratorio de Biología Molecular y Genética (LABIMOG)

- Entregable 4 (A entregar a los 120 días de emitida la OS)

o Elaboración de código software back-end – ITERACION2

o Elaboración de código software front-end – ITERACION2

o Scripts actualizados de creación y/o actualización de objetos fuente, objetos de base de datos y objetos compilados - ITERACION 2

o Documento actualizado de diseño del sistema

▪ Modelo de datos (inc. diccionario de datos)

o Documento actualizado de propuesta de la solución software (bajo nivel) considerando servicios, niveles de integración, componentes, fuentes de información, etc

o Documento de implementación de medidas de seguridad (OWASP, datos sensibles encriptados e incluir registros y módulos de auditoría y trazabilidad)

o Documento consolidado actualizado de RFs y RNFs, reglas de negocio, casuísticas especiales, formatos de reporteria, etc

o Actas de reuniones y registro de acuerdos

o Informe 4 aprobado por Instituto Nacional de Medicina Legal y Ciencias Forenses (IML-UE010) a través de la Sub Gerencia de laboratorio de Biología Molecular y Genética (LABIMOG)

- Entregable 5 (A entregar a los 150 días de emitida la OS)

o Elaboración de código software back-end – ITERACION3

o Elaboración de código software front-end – ITERACION3

o Scripts actualizados de creación y/o actualización de objetos fuente, objetos de base de datos y objetos compilados - ITERACION 3

o Contratos de servicio de servicios web

o Documento actualizado de diseño del sistema

▪ Modelo de datos (inc. diccionario de datos)

o Documento actualizado de propuesta de la solución software (bajo nivel) considerando servicios, niveles de integración, componentes, fuentes de información, etc

o Documento de implementación de medidas de seguridad (OWASP, datos sensibles encriptados e incluir registros y módulos de auditoría y trazabilidad)

o Documento consolidado actualizado de RFs y RNFs, reglas de negocio, casuísticas especiales, formatos de reporteria, etc

o Actas de reuniones y registro de acuerdos

o Informe 5 aprobado por Instituto Nacional de Medicina Legal y Ciencias Forenses (IML-UE010) a través de la Sub Gerencia de laboratorio de Biología Molecular y Genética (LABIMOG)

- Entregable 6 (A entregar a los 180 días de emitida la OS)

o Elaboración de código software back-end – ITERACION4

o Elaboración de código software front-end – ITERACION4

o Scripts actualizados de creación y/o actualización de objetos fuente, objetos de base de datos y objetos compilados - ITERACION 4

o Contratos de servicio de servicios web

o Documento actualizado de diseño del sistema

▪ Modelo de datos (inc. diccionario de datos)

o Documento actualizado de propuesta de la solución software (bajo nivel) considerando servicios, niveles de integración, componentes, fuentes de información, etc

o Documento de implementación de medidas de seguridad (OWASP, datos sensibles encriptados e incluir registros y módulos de auditoría y trazabilidad)

o Documento consolidado actualizado de RFs y RNFs, reglas de negocio, casuísticas especiales, formatos de reporteria, etc

o Actas de reuniones y registro de acuerdos

o Informe 6 aprobado por Instituto Nacional de Medicina Legal y Ciencias Forenses (IML-UE010) a través de la Sub Gerencia de laboratorio de Biología Molecular y Genética (LABIMOG)

- Entregable 7 (A entregar a los 210 días de emitida la OS)

o Scripts consolidados y actualizados de creación y/o actualización de objetos fuente, objetos de base de datos y objetos compilados

o Documento actualizado de diseño del sistema

▪ Modelo de datos (inc. diccionario de datos)

o Documento actualizado de propuesta de la solución software (bajo nivel) considerando servicios, niveles de integración, componentes, fuentes de información, etc

o Documento de implementación de medidas de seguridad (OWASP, datos sensibles encriptados e incluir registros y módulos de auditoría y trazabilidad)

o Documento consolidado actualizado de RFs y RNFs, reglas de negocio, casuísticas especiales, formatos de reporteria, etc

o Documento de pruebas (unitarias, funcionales, de rendimiento y de seguridad)

o Documento de subsanación de observaciones a las pruebas realizadas

o Código fuente versionado (en repositorio centralizado autorizado, en GIT institucional y CD)

o Objetos ejecutables versionados (en repositorio centralizado autorizado, en GIT institucional y CD)

o Objetos de base de datos versionados (en repositorio centralizado autorizado, en GIT institucional y CD)

o Documentación consolidada de pases a pruebas (entregables 3 al 6)

o Actas de reuniones y registro de acuerdos

o Informe 7 aprobado por Instituto Nacional de Medicina Legal y Ciencias Forenses (IML-UE010) a través de la Sub Gerencia de laboratorio de Biología Molecular y Genética (LABIMOG)

- Entregable 8 (A entregar a los 240 días de emitida la OS)

o Informe 8 (final) aprobado por Instituto Nacional de Medicina Legal y Ciencias Forenses (IML-UE010) a través de la Sub Gerencia de laboratorio de Biología Molecular y Genética (LABIMOG)

o Presentación final consolidada de la solución software (archivo ppt y documentación de soporte)

o Documento final de análisis y diseño

o Documento final de base de datos

o Documento de pase a producción incluyendo anexos de versionamiento de software, checklist de verificación

o Código fuente final versionado (en repositorio centralizado autorizado, en GIT institucional y CD)

o Manuales, videotutoriales o videoinstructivos de la instalación, configuración, parametrización de todos los componente de la solución por niveles administrativos y funcionales, para usuarios técnicos y usuario final

Durante la etapa de mantenimiento (evolutivos y/o correctivos) el PROVEEDOR deberá entregar informes mensuales detallados que incluya como mínimo:

- Lista de incidentes reportados/evidenciados durante el periodo. Por cada incidente, un análisis detallado de por qué sucedió el mismo, tiempo empleado en su subsanación, el detalle de la solución y qué acciones se llevaron a cabo para evitar un incidente redundante, colateral o de similar naturaleza

- Disponibilidad. Tiempo de disponibilidad de la solución y de todos sus componentes. En casos de indisponibilidad, se deberán detallar los tiempos y razones por la cual el sistema no ha estado disponible y las acciones realizadas para la rehabilitación de la disponibilidad.

- Evolutivos: Detalles de las funcionalidades “extras” necesarias o identificadas a implementar o poner en producción para el periodo y/o las que realmente fueron puestas en producción.

10. PENALIDADES

a. Penalidades por retrasos en la ejecución del servicio

Por cada día de atraso en la ejecución del inicio del servicio se aplicará una penalidad, de acuerdo al procedimiento establecido en la normatividad de adquisición/contratación que sustenta la ejecución del proyecto.

b. Otras penalidades relacionadas a la calidad del servicio

Relacionadas a la calidad del servicio de conformidad a lo establecido en la normatividad de adquisición/contratación que sustenta la ejecución del proyecto. Al PROVEEDOR se le aplicarán penalidades si se presenta alguna de las siguientes situaciones:

Penalidades en la etapa de implantación del servicio:

DESCRIPCIÓN

PENALIDAD

Demora en la entrega del Plan de Trabajo y la relación del personal propuesto para la

Implantación del servicio.

3 a 4 días (10% de la UIT vigente a la fecha)

5 a más días (20% de la UIT

vigente a la fecha)

Por cambiar al personal asignado sin comunicación

previa al MPFN.

Penalidad por ocurrencia del 10% de la UIT vigente a la fecha

Demora en plazo para la Implantación del servicio.

Pasado los 60 días se

penalizará con el 10% de la UIT, por cada día de retraso.

Las penalidades de los ítems 1, 2 y 3, se ejecutarán previo informe mensual del servicio emitido por la UE010- IML en el que se detalle el número de días de retraso y/o modificaciones del personal.

11. CONFORMIDAD

Al finalizar cada mes de servicio la UE010- IML, luego de una verificación de los registros (entregables o evidencia objetiva de trabajo realizado) que puede ser por muestra, individual o total brindará conformidad por escrito del servicio brindado y al informe mensual en formato conciliado. De considerarlo pertinente y sólo para cuestiones estrictamente técnicas referidas a software o equipamiento se coordinará el apoyo de la Oficina General de Tecnologías de la Información (OGTI) para la emisión de un informe técnico complementario no vinculante.

12. CLÁUSULA DE SEGURIDAD Y CONFIDENCIALIDAD

a. Cláusula de Seguridad de la Información

El PROVEEDOR se compromete a aplicar las medidas de seguridad de la información necesarias para proteger la información de la UE010- IML de forma razonable de acuerdo a la naturaleza y riesgos de la información conforme a los parámetros del contrato. Así mismo, es potestativo de la UE010- IML realizar visitas inopinadas para constatar las medidas de seguridad de la información que está aplicando el PROVEEDOR. En caso de incumplimiento la UE010- IML se reserva el derecho de realizar las acciones legales correspondientes.

b. Cláusula de Protección de Datos Personales

Para una oportuna prestación del servicio, el PROVEEDOR podrá tener acceso a datos de carácter personal protegidos por la Ley N° 29733 - Ley de Protección de Datos Personales, por lo que se compromete a efectuar un uso y tratamiento debido y adecuado de los mismos, que será acorde a las actuaciones que resulten necesarias para la correcta prestación de servicios regulada en el presente documento, según las instrucciones facilitadas en cada momento.

La UE010- IML como titular de sus bancos de datos personales y/o responsable del tratamiento será quien decidirá sobre la finalidad, contenido, medidas de seguridad y tratamiento de los datos personales, limitándose el PROVEEDOR como encargado de tratamiento a utilizar dichos datos, única y exclusivamente, para los fines establecidos en la prestación del servicio y de acuerdo a lo indicado por la UE010- IML, bajo responsabilidad legal.

c. Cláusula de Acuerdo de Confidencialidad Obligaciones Específicas

Las partes (la UE010- IML y el PROVEEDOR) se obligan a entregarse todo el material que sea necesario, considerando el principio de reserva establecido en el Decreto Legislativo N° 957, Nuevo Código Procesal Penal según aplique y toda la información restante como confidencial, se comprometen a:

● Mantenerla, con sujeción a la más estricta confidencialidad.

● No divulgar ni comunicar la información técnica facilitada por la otra parte.

● Impedir la copia o revelación de esa información a terceros, salvo que gocen de aprobación escrita de la otra parte, y únicamente en términos de tal aprobación.

● Restringir el acceso a la información a sus empleados y subcontratados, en la medida en que razonablemente puedan necesitarla para el cumplimiento de sus tareas acordadas.

● Utilizar la información o fragmento de esta solamente en relación con la finalidad de la prestación del servicio.

● El PROVEEDOR y sus colaboradores deben firmar cartas de riesgo y de confidencialidad por acceso a la información sensible, al inicio del servicio.

Las partes serán responsables entre sí, ante el incumplimiento de esta obligación, ya sea por sus empleados o por subcontratados.

Exclusiones

Las partes mantendrán esta confidencialidad y evitarán revelar la información a toda persona que no sea empleado o subcontratado, salvo que:

● Que fuera del dominio público en el momento de haber sido revelada.

● Que, después de haber sido revelada, fuera publicada o de otra forma pasara a ser de dominio público, sin quebrantamiento de la obligación de confidencialidad por la parte que recibiera dicha información.

● Que, en el momento de haberle sido revelada, la parte que la recibiera ya estuviera en posesión de la misma por medios lícitos o tuviera derecho legalmente a acceder a la misma.

● Que tuviera consentimiento escrito previo de la otra parte para develar la información.

● Que haya sido solicitada, conforme a la normativa vigente, por autoridades administrativas o judiciales competentes que deban pronunciarse sobre aspectos totales o parciales del mismo, en cuyo caso, la parte que tenga que realizar la presentación deberá comunicárselo a la otra con carácter previo a que dicha prestación tenga lugar.

● Expresamente sea clasificada como pública.

Devolución de la información y compromiso de confidencialidad

Al vencimiento de la prestación del servicio, el PROVEEDOR se compromete a devolver a la otra toda la información remitida entre sí en el plazo de 30 días calendario. El PROVEEDOR deberá mantener el compromiso de confidencialidad por un periodo de 05 años.

Daños y Perjuicios

Las partes acuerdan que el pago de los daños y perjuicios puede no constituir remedio suficiente en caso de incumplimiento real o amenaza de incumplimiento de las disposiciones del presente Acuerdo, y ninguna de las partes se opondrá al otorgamiento de compensaciones equitativa, incluso autorizan las acciones necesarias para el resarcimiento vía medidas cautelares y/o la ejecución forzosa, sin necesidad de demostrar o cuantificar las pérdidas o los daños sufridos.

d. Cláusula de Publicidad

El presente acuerdo no dará derecho alguno a las partes a realizar campañas de publicidad o acciones de marketing relacionadas con el mismo o con las negociaciones entre las partes sin autorización expresa de la otra.

Respecto a las notas de prensa se acuerda que sean coordinadas entre las dependencias correspondientes, debiendo existir un acuerdo expreso, mutuo y escrito, en su caso.

13. FORMA DE PAGO

El pago mensual del servicio se efectuará previa la emisión del Acta de Conformidad del servicio mensual emitido y firmada por la UE010- IML, en respuesta al Informe Mensual del servicio que presentará el PROVEEDOR.

14. FINALIZACIÓN DEL SERVICIO

El PROVEEDOR, en caso aplique, deberá:

● Retirar los equipos y material empleado una vez finalizado el trabajo para el que se le contrató en un plazo no mayor de cinco (5) días calendario.

● Dejar los espacios que ocupaba en iguales condiciones en que se recibieron.

15. RESPONSABILIDAD POR XXXXXX XXXXXXX

El PROVEEDOR garantizará durante todo el periodo de prestación del servicio el correcto funcionamiento de todo el sistema, obligándose a realizar cuantos cambios o adaptaciones sean necesarios para solucionar las deficiencias detectadas imputables a los trabajos y/o productos realizados.

El plazo máximo de responsabilidad del PROVEEDOR por la calidad ofrecida y por los vicios ocultos de los entregables generados por el servicio será de un (1) año contado a partir de la Conformidad Final otorgada.

16. REQUISITOS DE CALIFICACIÓN

De acuerdo a la normatividad de adquisición/contratación que sustenta la ejecución del proyecto, los requisitos de calificación definidos y establecidos son los siguientes:

A	CAPACIDAD LEGAL
	HABILITACIÓN	Requisitos: EL PROVEEDOR, deberá estar inscrito en el Registro Nacional de Proveedores del Estado, encontrarse vigente y sin sanciones legales, administrativas o de otra índole. Acreditación: Copia simple del Registro Nacional de Proveedores del Estado y encontrarse vigente a la fecha de presentación.
B	CAPACIDAD TÉCNICA Y PROFESIONAL
B.1	CALIFICACIONES DEL PERSONAL
	Coordinador del Proyecto		Requisitos: Titulado en Administración, Ingeniería de sistemas, informática, industrial y /o afines. Acreditación: El título será verificado por el comité de selección en el Registro Nacional de

Grados Académicos y Títulos Profesionales en el portal web de la Superintendencia Nacional de Educación Superior Universitaria - SUNEDU a través del siguiente link: xxxxx://xxxxxxx.xxxxxx.xxx.xx/ // o en el Registro Nacional de Certificados, Grados y Títulos a cargo del Ministerio de Educación a través del siguiente link: xxxx://xxx.xxxxxxxxxxxxxxxxx.xx/, según corresponda. En caso el título no se encuentre inscrito en el referido registro, el postor debe presentar la copia del diploma respectivo a fin de acreditar la formación académica requerida.

Perfil/Experiencia:

Deberá tener experiencia en haber supervisado la implementación de soluciones como la ofertada en instituciones del estado o del sector privado, con una experiencia mínima de 03 años.

Experiencia en la gestión de proyectos, desde la concepción hasta la entrega.

Habilidad para preparar e interpretar diagramas de flujo, agendas y planes de acción paso a paso.

Capacidades organizativas, incluida la gestión del tiempo y la realización de varias tareas a la vez.

Familiaridad con el control de la gestión de riesgos y el control de calidad.

Sólidos conocimientos prácticos de Microsoft Project o similar.

Experiencia práctica en las herramientas de gestión de proyectos (p. ej.,

Basecamp x Xxxxxx)

La experiencia del personal clave se acreditará con cualquiera de los siguientes documentos: (i) copia simple de contratos y su respectiva conformidad o (ii) constancias o (iii) certificados o (iv) cualquier otra documentación que, de manera fehaciente demuestre la experiencia del personal propuesto.

Especialista de Procesos

Requisitos:

Titulado en Administración, Ingeniería de sistemas, informática, industrial y /o afines.

Acreditación:

El título será verificado por el comité de selección en el Registro Nacional de Grados Académicos y Títulos Profesionales en el portal web de la Superintendencia Nacional de Educación Superior Universitaria - SUNEDU a través del siguiente link: xxxxx://xxxxxxx.xxxxxx.xxx.xx/ // o en el Registro Nacional de Certificados, Grados y Títulos a cargo del Ministerio de Educación a través del siguiente link: xxxx://xxx.xxxxxxxxxxxxxxxxx.xx/, según corresponda. En caso el título no se encuentre inscrito en el referido registro, el postor debe presentar la copia del diploma respectivo a fin de acreditar la formación académica requerida.

Perfil/Experiencia:

Deberá tener experiencia en haber supervisado la implementación de soluciones como la ofertada en instituciones del estado o del sector privado, con una experiencia mínima de 03 años.

Aptitudes técnicas demostrables.

Conocimiento de los estándares relacionados con los procesos.

Experiencia en simulaciones de procesos.

Conocimiento laboral de paquetes de software de ingeniería de procesos.

Analista Funcional

Requisitos:

Titulado en Ingeniería de sistemas, informática, industrial y /o afines.

Acreditación:

Perfil/Experiencia:

Deberá tener experiencia en haber supervisado la implementación de soluciones como la ofertada en instituciones del estado o del sector privado, con una experiencia mínima de 03 años.

Habilidades analíticas demostrables.

Resolución de problemas y pensamiento crítico.

Conocimientos de seguridad de TI, arquitectura de software y bases de datos.

Conocimiento de diseño de sistemas eficientes.

Conocimiento de análisis y modelado de procesos y datos.

Conocimientos en arquitectura de computadoras y gestión de software.

Capacidad para el análisis de los distintos tipos de organizaciones que incluya aspectos formales y no formales.

Capacidad analítica y de resolución de problemas.

Manejo de técnicas metodológicas formales de análisis y desarrollo, conocimiento en datawarehousing y herramientas para procesos de testing.

La experiencia del personal clave se acreditará con cualquiera de los siguientes documentos: (i) copia simple de contratos y su respectiva conformidad o (ii) constancias o (iii)

certificados o (iv) cualquier otra documentación que, de manera fehaciente demuestre la experiencia del personal propuesto.

Analista Programador FrontEnd

Requisitos:

Titulado en Ingeniería de sistemas, informática, industrial y /o afines.

Acreditación:

Perfil/Experiencia:

Deberá tener experiencia en haber supervisado la implementación de soluciones como la ofertada en instituciones del estado o del sector privado, con una experiencia mínima de 03 años.

Programación en HTML y CSS Programación en JavaScript Trabajo con frameworks y CMS

Trabajo bajo estándares de Diseño UX y UI.

Diseño visual.

Uso de herramientas de diseño visual. Diseño de Experiencia de Usuarios.

Conocimiento de APISs /CMS, herramientas de automatización, frameworks y librerías que cada lenguaje usa, herramientas de los navegadores.

Analista Programador BackEnd

Requisitos:

Titulado en Ingeniería de sistemas, informática, industrial y /o afines.

Acreditación:

Perfil/Experiencia:

Deberá tener experiencia en haber supervisado la implementación de soluciones como la ofertada en instituciones del estado o del sector privado, con una experiencia mínima de 03 años.

Comprensión de los parámetros y criterios de diseño.

Diseño y programación xx xxxxxxxxxx, temas e interfaces.

Conocimiento en el manejo de bases de datos.

Profundos conocimientos de todo el proceso de desarrollo web (diseño, desarrollo y despliegue)

Creación de código reutilizable y bibliotecas para uso futuro

Especialista en Bases de Datos

Requisitos:

Titulado en Ingeniería de sistemas, informática, industrial y /o afines.

Acreditación:

El título será verificado por el comité de selección en el Registro Nacional de Grados Académicos y Títulos Profesionales en el portal web de la Superintendencia Nacional de Educación

Superior Universitaria - SUNEDU a través del siguiente link: xxxxx://xxxxxxx.xxxxxx.xxx.xx/ // o en el Registro Nacional de Certificados, Grados y Títulos a cargo del Ministerio de Educación a través del siguiente link: xxxx://xxx.xxxxxxxxxxxxxxxxx.xx/, según corresponda. En caso el título no se encuentre inscrito en el referido registro, el postor debe presentar la copia del diploma respectivo a fin de acreditar la formación académica requerida.

Perfil/Experiencia:

Deberá tener experiencia en haber supervisado la implementación de soluciones como la ofertada en instituciones del estado o del sector privado, con una experiencia mínima de 03 años.

Asistencia a usuarios de la base de datos. Resolver inconvenientes.

Revisar los parámetros de seguridad.

Hacer modificaciones en la base de datos para facilitar su uso.

Reorganizar datos.

Mantenerse al día de la tecnología de base de datos.

Tener conocimiento técnico de bases de datos y lenguajes de consulta.

Tener conocimiento con la protección de datos.

La experiencia del personal clave se acreditará con cualquiera de los

siguientes documentos: (i) copia simple de contratos y su respectiva conformidad o (ii) constancias o (iii) certificados o (iv) cualquier otra documentación que, de manera fehaciente demuestre la experiencia del personal propuesto.

Asegurador de Calidad de Software

Requisitos:

Titulado en Ingeniería de sistemas, informática, industrial y /o afines.

Acreditación:

Perfil/Experiencia:

Deberá tener experiencia en haber supervisado la implementación de soluciones como la ofertada en instituciones del estado o del sector privado, con una experiencia mínima de 03 años.

Xxxxxxx y experiencia demostrable en el conocimiento e implantación de protocolos y normas de calidad.

Determinación de quiénes son las partes

interesadas dentro de la empresa y cuáles son los requisitos que las partes interesadas revelan.

Implementación de las acciones correctivas en los procesos de no conformidad.

Experiencia en implementación de manuales de puestos, procedimientos, sistemas de gestión de calidad, implementación de la norma ISO 9001:2008.

Arquitecto de Software

Requisitos:

Titulado en Ingeniería de sistemas, informática, industrial y /o afines.

Acreditación:

acreditar la formación académica requerida.

Perfil/Experiencia:

Deberá tener experiencia en haber supervisado la implementación de soluciones como la ofertada en instituciones del estado o del sector privado, con una experiencia mínima de 03 años.

Definir y establecer todos los aspectos de la arquitectura, las directrices, principios y desarrollo de los aspectos técnicos del proyecto de software.

Selección de qué tecnología se va a utilizar en la creación de un determinado software. Realiza continuos procesos de evaluación para determinar si cumple las expectativas del público y de estar abierto a modificar la arquitectura utilizando para ello el feedback de otros miembros del equipo o de los propios usuarios.

EXPERIENCIA

Requisitos:

El postor debe acreditar un monto facturado acumulado equivalente 200.000 (Doscientos mil, con 00/100) soles, por la contratación de servicios iguales o similares al objeto de la convocatoria, durante los ocho (8) años anteriores a la fecha de la presentación de ofertas que se computarán desde la fecha de la conformidad o emisión del comprobante de pago, según corresponda.

Se consideran servicios similares a los siguientes:

- Gestión de Contenido digitalizado con valor legal

- Prestador de Servicio Añadido (boleta de pago electrónica, facturas electrónicas)

- Otros relacionados a prestación de servicios en desarrollo de software, consultoría o infraestructura de TI en el ámbito público o privado.

Acreditación:

La experiencia del postor en la especialidad 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, correspondientes a un máximo de veinte (20) contrataciones.

En caso los postores presenten varios comprobantes de pago para acreditar una sola contratación, se debe acreditar que corresponden a dicha contratación; de lo contrario, se asumirá que los comprobantes acreditan contrataciones independientes, en cuyo caso sólo se considerará, para la evaluación, las veinte (20) primeras contrataciones.

En el caso de servicios de ejecución periódica o continuada, sólo se considera como experiencia la parte del contrato que haya sido ejecutada a la fecha de presentación de ofertas, debiendo adjuntarse copia de las conformidades correspondientes a tal parte o los respectivos comprobantes de pago cancelados.

En los casos que se acredite experiencia adquirida en consorcio, debe presentarse la promesa de consorcio o el contrato de consorcio del cual se desprenda fehacientemente el porcentaje de las obligaciones que se asumió en el contrato presentado; de lo contrario, no se computará la experiencia proveniente de dicho contrato.

Asimismo, cuando se presenten contratos derivados de procesos de selección convocados antes del dd/mm/yyyy, la calificación se ceñirá al método descrito en la normatividad de adquisición/contratación que sustenta la ejecución del proyecto, debiendo presumirse que el porcentaje de las obligaciones equivale al porcentaje de

participación de la promesa de consorcio o del contrato de consorcio. En caso que en dichos documentos no se consigne el porcentaje de participación se presumirá que las obligaciones se ejecutaron en partes iguales.

Si el titular de la experiencia no es el postor, consignar si dicha experiencia corresponde a la matriz en caso que el postor sea sucursal, o fue transmitida por reorganización societaria, debiendo acompañar la documentación sustentadora correspondiente.

Si el postor acredite experiencia de una persona absorbida como consecuencia de una reorganización societaria, debe presentar la respectiva documentación de sustento acorde a lo establecido en la normatividad de adquisición/contratación que sustenta la ejecución del proyecto.

Cuando en los contratos, órdenes de servicios o comprobantes de pago el monto facturado 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.

Sin perjuicio de lo anterior, los postores deben llenar y presentar toda documentación que exija la normatividad de adquisición/contratación que sustenta la ejecución del proyecto.

ANEXO 1

Estándares técnicos para desarrollo de sistemas de información UE010- IML-MPFN

Servidor de aplicaciones	WildFly
Base de datos	Sybase
Lenguajes	Proyectos Grandes - Javascript: Angular JS (Frontend) - Java (Backend) o Jpa – Hibernate o Spring Boot Plantilla - Adminked - AdminLte2 Arquitectura - Microservicios Proyectos Cortos-Medianos - PHP nativo / Zend Framework Plantilla - Mecatronic - AdminLte2 Arquitectura - Monolítica
Estructura de módulos	JAVA 1. Vista-Controlador- Boundary (VCB) 2. Capas • Capa de Presentación - Tecnologías: Angular.js 2.x/HTML5 (referencia plantilla xxxxxxxx.xx), ya no se está desarrollando en JSF ni en Primefaces.

- Patrón MVC

• Capa de Integración de Servicios

- Tecnologías: Rest Services

- Patrón Boundary (JAX-RS)

• Capa de Negocio

- Tecnologías: Stateles EJB, CDI beans

- Patrón IOC

• Capa de acceso a Datos

- Tecnologías: JPA 2.1 con HIbernate

- Patrón DAO ( JPA 2.1 )

3. BackEnd (BE)

- Servicio: RES

- Conexión BD: JPA2 (Hibernate)

4. FrontEnd (FE)

- HTML 5 con CSS3

- Bootstrap

- JQuery

- Angular

- Plantilla: AdminLTE

5. Servicios

- Servicios Web Seguros: SOAP Security

6. Autenticación

• Autenticación tradicional o autenticación en servidor:

- La petición debe de realizarse a nivel de servidor, no en la capa cliente

- La información debe de guardarse en sesiones del servidor, no utilizar cookie para almacenar el token

• Autenticación sin estado basada en tokens:

- Utilizar el estándar JSON Web Tokens (JWT)

- No utilizar sesión para comunicación entre el frontend y backend

- Implementar el generador de tokens basándose en el estándar JWT

- Utilizar la BD de usuarios del MPFN (SAD) - Se brindara acceso al entorno de pruebas/producción

Testing	SonarQube, Selenium, JMeter, JUnit5
Repositorio	Gitlab
Automatización	Xxxxxxx

Document Metadata

Table of Contents

TERMINOS DE REFERENCIA PARA LA CONTRATACION DE UN SERVICIO ESPECIALIZADO DE DESARROLLO E IMPLEMENTACION DEL SISTEMA INTEGRADO DE GESTION DEL NUEVO CENTRO NACIONAL DE PERFILES GENETICOS HUMANOS DEL INSTITUTO DE MEDICINA LEGAL Y CIENCIAS FORENSES DEL...

Document Metadata