cdn.€¦ · web viewsolicitud de cotizaciÓ. n. referencial. organismo supervisor de...

SOLICITUD DE COTIZACIÓN REFERENCIAL

ORGANISMO SUPERVISOR DE CONTRATACIONES DEL ESTADO (OSCE)Proyecto “Mejoramiento de la Capacidad para la Generación del Conocimiento y Mejora Continua en la

Gestión de la Contratación Pública”

La República del Perú ha suscrito un Contrato de Préstamo N° 4428/OC-PE con el Banco Interamericano de Desarrollo (BID) y se propone utilizar una parte de los fondos para contratar los siguientes servicios de consultoría individual:

I. CONTRATACIÓN PARA EL DESARROLLO DEL PROYECTO DE APLICATIVO MÓVIL ÚNICO OSCE Y ALERTAS OSCE

II. CONTRATACIÓN PARA EL DESARROLLO DE LOS SERVICIOS DE FIRMA ELECTRÓNICA Y GENERACIÓN DE EXPEDIENTE ELECTRÓNICO

En ese sentido, se solicita cotizaciones referenciales los cuales deberán ser enviados vía correo electrónico a [email protected], a más tardar el 04 de mayo de 2020, para cuyo efecto se remite la información referencial.

Se adjunta los siguientes formularios:

1. FORMULARIO 1: Experiencia del consultor individual en desarrollo de software2. FORMULARIO 2: Cotización

1

FORMULARIO 1

Nombre del Consultor

Universidad/centro de capacitación Año

EXPERIENCIA GENERAL

ENTIDAD CARGO INICIO TERMINACIÓN MESES * DIAS * PRINCIPALES ACTIVIDADES DESARROLLADAS

0 0

0 0

0 0

0 0

0 0

0 0

0 0

0 0

0 0

0 0

AÑOS 0

MESES 0

FORMULARIO 1: EXPERIENCIA DEL CONSULTOR INDIVIDUAL EN DESARROLLO DE SOFTWARE

2. OTROS ESTUDIOS/ESPECIALIZACION

Nota: Puede ampliar la cantidad de líneas de acuerdo a su necesidad

1. FORMACIÓN ACADEMICA

2

FORMULARIO 2

SOLICITUD DE COTIZACIÓN

Rubro

Tiempo propuesto

(meses) Costo S/.

Honorarios

Otros gastos operativos

Subtotal

Impuestos Locales

Precio total

3

I. CONTRATACIÓN DE UN CONSULTOR INDIVIDUAL PARA EL DESARROLLO DEL PROYECTO DE APLICATIVO MÓVIL ÚNICO OSCE Y ALERTAS OSCE

1. ANTECEDENTES

El 21 de mayo de 2018 el Gobierno de la República del Perú firmó el Contrato de Préstamo No.4428/OCPE con el Banco Interamericano de Desarrollo para financiar el Proyecto “Mejoramiento de la Capacidad para la Generación del Conocimiento y Mejora Continua en la Gestión de la Contratación Pública” (en adelante el Proyecto), el cual tiene como objetivo fortalecer la gestión de la inversión y las contrataciones públicas para contribuir con la reducción de las brechas de inversión en sectores clave de la economía y por áreas geográficas del Perú.

Los objetivos específicos del Proyecto son: (i) mejoramiento de la gestión de la inversión pública para la efectiva prestación de servicios y la provisión de la infraestructura prioritaria; (ii) 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.

Para el logro de los objetivos señalados, el Proyecto contempla la ejecución de los componentes siguientes:

▪ Componente 1: Mejora de la 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: Mejora de la capacidad del capital humano.

Considerando que hoy en día existen una serie de problemáticas e iniciativas orientadas a mejorar la situación actual del proceso de compras y que el resultado del componente 1 se generará a mediano plazo, es que el Organismo Supervisor de Contrataciones del Estado (OSCE) requiere desarrollar e implementar proyectos complementarios que permitan obtener mejoras inmediatas, resultados demostrables y preparación del ambiente necesario para los cambios con mayor impacto a generarse en el futuro con las diferentes implementaciones.

Por lo mismo, el Organismo Supervisor de Contrataciones del Estado (OSCE) requiere contar con el desarrollo del proyecto de aplicación móvil única OSCE el cual permitirá generar una arquitectura única base para desarrollos móviles sobre el cual se acoplarán nuevos servicios para ser utilizados por los usuarios integrándolos a dicha aplicación única móvil. Además este proyecto consta del desarrollo de un servicio móvil denominada Alertas OSCE, el cual será montado en la arquitectura de esta aplicación única móvil.

2. OBJETIVO GENERAL Y OBJETIVOS ESPECÍFICOS DE LA CONSULTORÍA

2.1. OBJETIVO GENERAL

4

El presente servicio, permitirá el desarrollo e implementación de una arquitectura para la aplicación móvil única para el Organismo Supervisor de Contrataciones del Estado (OSCE), con la finalidad de contar con un solo portal de servicios móviles que sea de fácil uso para el usuario. Así mismo, se desarrollará el servicio o módulo de Alertas OSCE como primer paso al inicio de implementación de nuevas funcionalidades montadas en la nueva arquitectura.

2.2. OBJETIVOS ESPECÍFICOS

2.2.1. Crear una aplicación única móvil que genere representatividad institucional, siendo intuitivo y seguro para el usuario. Esta aplicación móvil

2.2.2. Desarrollar una arquitectura robusta para móviles que permita ser sostenible y escalable en el tiempo, permitiendo la adición de nuevas funcionalidades, módulos o integraciones futuras con otros sistemas de información.

2.2.3. Desarrollar el servicio o módulo móvil Alertas OSCE, que permita registrar alertas de usuarios autorizados por OSCE acerca de anormalidades en obras u otras situaciones que el OSCE determine.

3. ALCANCE DEL SERVICIO

3.1. REQUISITOS:

La consultoría se encargará de realizar el análisis, propuesta, programación e implementación de la arquitectura móvil única de la organización, así como también del módulo y/o servicio móvil para el registro y seguimiento de alertas reportadas por los usuarios autorizados por OSCE (participante, proveedor, entidad, ciudadano u otros) como primera funcionalidad que soporte la arquitectura creada. Estos desarrollos se harán con una tecnología moderna, escalable y sostenible en el tiempo, garantizando el ciclo de vida de los productos y servicios de software que se suministre, desarrolle y opere; velando en todo momento por el cumplimiento de la normativa peruana vigente, en particular la relacionada al ciclo de vida de software y protección de datos personales. Asimismo con los parámetros de evaluación y gestión de proyectos de sistemas de información basado en estándares, así como el de seguridad física y control de accesos.

▪ Los estándares a tomar en cuenta para el desarrollo de los servicios web (webservices, APIs , otros) y/o aplicaciones web serán los siguientes:

Item

Descripción Estándar Especificación

1 Arquitectura MVC y/o derivado MVC

Modelo Vista Controlador

2 Lenguaje de Programación

Java 8+ Framework: Spring Boot 2.0+Front End: Angular Material 8+

3 Motor de Base de Datos

MSSQL Server u Oracle 12c

5

4 Plataforma Web

5 Servicio web SOAP / REST

6 Servidor de Aplicaciones

JBoss

7 Otros Seguridad:- Protocolo OAUTH2- JSON Web Token

(JWT)Técnica de Diseño Web:- Diseño Responsive

(*) Diseño responsive de acuerdo a punto 2 (Lenguaje de programación)Front End: Angular Material 8+

▪ Los estándares a tomar en cuenta para el desarrollo de aplica cione s móviles serán los siguientes:

Item Descripción Estándar Especificación



2 SDK Flutter Disponibilidad para Android y para IOS (generación del código de forma simultánea para ambas plataformas).


SQLite 3.4+ Integración a través de servicios web: MSSQL Server , Oracle 12c u otros.Uso SQLite según corresponda.

4 Plataforma Android& IOS

Dispositivos móviles (Celulares, Tablets, Smartphones).


▪ Los diagramas solicitados deberán cumplir con la notación UML 2.0 como mínimo.

3.2. REQUERIMIENTOS:

La consultoría deberá incluir los siguientes aspectos:

6

3.2.1. Participar de la reunión inicial del proyecto (kick-off) para la entrega de documentación o recursos por parte del equipo del Proyecto BID, con la finalidad de iniciar el análisis funcional y el desarrollo del producto (Proyecto BID hará entrega del documento de requerimientos, ficha del proyecto, entre otros insumos).

3.2.2. Analizar, construir, programar y probar la aplicación única móvil OSCE que tendrá incluída un módulo móvil denominado “Alertas OSCE”.

a) Arquitectura móvil Única

● Elaborar la propuesta de arquitectura móvil único que establezca la especificación técnica y prototipo estándar (diseño de interfaces) que permita implementar nuevos servicios y/o módulos móviles centralizándolos en un solo aplicativo.

● Especificar técnicamente la propuesta de arquitectura que debe adoptarse como aplicación única móvil en la institución, permitiendo que éste sea escalable en el tiempo, asimismo que se puedan implementar nuevos servicios y/o módulos móviles futuros. La arquitectura, como especificación técnica, debe contemplar definición de frameworks, lenguaje de programación a utilizar, estándares para la definición de APIs, patrones de diseño a utilizar y criterios para el almacenamiento local y la persistencia de datos.

● Las alternativas de solución para la selección de la tecnología apropiada en cada capa, deben ser especificadas por el proveedor y sustentadas con respecto a volumen de transacciones, tiempo de respuesta esperado, interfaces, número de usuarios concurrentes esperados, volumen y tipo de información.

● Para la arquitectura de las aplicaciones móviles del OSCE se ha considerado dividir las funciones de cualquier desarrollo en tres capas lógicas:

- Presentación o FrontEnd. Se encarga de facilitar al usuario final el acceso a las funciones de la aplicación de manera comprensible y oportuna. Estas funciones pueden ser desarrolladas en código nativo a los dos sistemas operativos con mayor presencia en el mercado (Android e IOS) o utilizando tecnologías web (javascript, HTML).

- Capa de Negocio. Tiene como misión aplicar las transformaciones

necesarias a los datos de la institución para hacerla legible a la capa de presentación. Esta capa se implementa siguiendo los criterios de la arquitectura SOA y microservicios. El proveedor deberá proveer las recomendaciones para la definición y diseño de APIs y servicios, los criterios para la selección de lenguaje de programación y los mecanismos para su implementación y despliegue.

- Capa de Datos. provee de toda la información que maneja el OSCE. Las principales fuentes de datos la constituye los RDBMS (Oracle) y MSSQL

7

Server de su centro de datos, pero debe considerarse también el acceso a otras fuentes como archivos de datos no estructurados ( excel, word u otros) y servicios externos (RENIEC, SUNAT, etc.). El proveedor debe indicar la estrategia a seguir para el acceso a estas fuentes de datos según su disponibilidad y naturaleza.

● Desarrollar el módulo de seguridad el cual permita:

- Descargar la aplicación móvil del Play Store, App Store y/o sitio oficial de OSCE. Debe estar disponible tanto para IOS versión 12 como para Android versión 9 (Pie) o superior.

- Inscribirse como usuario, se verificará la información ingresada usando los API disponibles en la OSCE, en caso lo requiera la aplicación.

- Asimismo se debe considerar el uso por usuarios no identificados o anónimos, estos usuarios sólo tendrán acceso a funciones y aplicaciones que OSCE determine.

- Ingresar a la aplicación móvil única (iniciar sesión) a través de un usuario y contraseña, y acceder a todas las funcionalidades que le correspondan según perfil asignado. Tomar en cuenta que la autorización se realizará por Token, el cual debe ser generado utilizando el protocolo OAuth2 con forma de envío JWT (JSON Web Token). El Token debe ser generado con un tiempo de expiración configurable, máximo de una (01) hora. De igual forma, este módulo debe contemplar la recuperación de contraseña, en caso el usuario no la recuerde.

- Recibir mensajes, noticias e información emitida por el OSCE.- Hacer consultas, comentarios y contestar mensajes hacia el OSCE.- Mostrar una lista de aplicaciones de OSCE a las que tiene acceso el usuario

según el perfil (participante, proveedor, entidad, ciudadano u otros) y permitir que pueda iniciarlas desde la misma aplicación. El proceso de instalación de estas aplicaciones debe ser automático sin requerir intervención del usuario.

- Modificar la información del perfil indicando preferencias en el tipo de noticias e información que se recibirá.

- Permitir manejar una foto de perfil asignada por el usuario.- Administrar las aplicaciones móviles de OSCE a través de un sistema web

que permita:

a. Gestionar el módulo de seguridad donde se puedan registrar, actualizar o eliminar usuarios.

b. Emitir noticias para uno o un grupo de usuarios.c. Enviar mensajes a un usuario y ver la respuesta.d. Visualizar la actividad de cada usuario.e. Gestionar las aplicaciones de OSCE a las que tiene acceso cada usuario

permitiendo asignarlas o retirarlas.

● Especificar el prototipo estándar (diseño de interfaces) que deberá ser usado tanto por la aplicación central móvil como por cada uno de los servicios y/o módulos adheridos a la nueva arquitectura. El diseño debe ser concebido con

8

los colores y logos acorde a la institución, así como el diseño de interfaces debe ser creado bajo estándares actuales en el mercado.

b) Módulo móvil “Alertas OSCE”:

● Desarrollar e implementar el módulo móvil denominado Alertas OSCE, el cual permitirá a los usuarios autorizados por el OSCE registrar anomalías acerca de acerca de anormalidades en obras u otras situaciones que el OSCE determine.

● Solicitar al usuario permisos de geolocalización para uso exclusivo de la aplicación (en caso no se haya dado los permisos necesarios durante la instalación del aplicativo en el dispositivo móvil del usuario).

● Mostrar al usuario cuando ingrese a sesión:- Un mapa de un radio aproximado a su geolocalización donde visualice

puntos de interés determinados por OSCE cercanas a su radio (desarrollar y consumir servicio web que permita mostrar dichos puntos) u otros puntos u objetos de interés del OSCE.

- La posibilidad de gestionar información de georeferenciación de puntos de interés determinados por OSCE.

- El número de alertas, comentarios y visitas realizadas por parte del usuario.

● Visualizar información del punto de interés al dar un pique en el icono mostrado en el mapa (obra). La información debe ser obtenida desde un servicio web (desarrollar y consumir servicio web) el cual debe considerar el nombre del punto de interés y otro tipo de información determinado por el OSCE.

● Alertar a través de un botón (opción que se mostrará cuando el usuario visualice la información del punto de interés u otra indicación dada por OSCE). Una vez que el usuario pulse el botón “Alertar”, se capturarán los datos de geolocalización de dicho punto de interés además de solicitar el motivo de la alerta (combo con opciones predeterminadas), descripción de la alerta (campo libre de texto) y se permitirá la carga de fotos que deberán ser tomadas como parte de la aplicación móvil (se puede permitir tomar hasta 4 fotos por alerta). Finalmente, se enviará la alerta a través del botón “Enviar”.

● Enviar un correo electrónico tanto al usuario que envió la alerta, como al administrador de alertas para el seguimiento respectivo.

● Buscar puntos de interés a partir de filtros (provincia, departamento, distrito, nombre) y de igual manera a través del mapa interactivo, puesto que mientras el usuario va avanzando en el mapa, se mostrarán los puntos de interés para luego poder alertar.

9

● Seguimiento de alertas realizadas por el usuario hasta la fecha actual (Listar alertas realizadas por el usuario y estatus en la que se encuentra la alerta, mostrar respuesta por parte de la institución).

● Buscar y listar alertas realizadas por otros usuarios a través de la aplicación, mostrando fecha, nombre, ubicación y motivo de alerta (aquellos que se encuentren en su radio de geolocalización o dentro del distrito que el usuario colocó como registro).

c) Módulo web para seguimiento de alertas

● Visualizar las alertas realizadas por todos los usuarios a través de un sistema web donde se:

- Permita a la institución gestionar las alertas realizadas por los usuarios.- Permitir ingresar a sesión con perfil administrador y visualizar

mediante una bandeja las alertas que provienen de los registros realizados por los usuarios desde su aplicación móvil.

- Responder las alertas a los usuarios mediante un botón, y colocar el estado de la atención de la alerta (pendiente, aceptada, respondida, cancelada).

- Enviar correo electrónico y notificación al veedor sobre la respuesta dada por la OSCE .

- Gestione un módulo de seguridad donde se puedan registrar, actualizar o eliminar usuarios.

d) Seguridad

● Permitir guardar registros de auditoría (acciones) de importancia, así como la información en el documento de evidencias (log estructurado).

- Registros de Auditoría- Documento de evidencias (log estructurado): Documento que permitirá

registrar la auditoría de los movimientos o acciones principales realizadas durante los procesos resaltantes.

e) Realizar las pruebas unitarias de los servicios y aplicativo móvil a lo largo de todo el desarrollo, que permita la correcta puesta en marcha.

3.2.3. Análisis/Construcción:

10

a) Realizar las especificaciones de caso de uso (ver Anexo N°01) que será utilizado tanto para el desarrollo de la arquitectura como del servicio y/o módulo móvil de Alerta.

b) Definir el Diagrama de Actores (servicios y componentes) incluyendo la Matriz de Perfiles y Accesos (ver Anexo N°02).

c) Realizar el documento de Diseño del Sistema de Información (servicios y componentes) el cual debe contener como mínimo (ver Anexo N°03):

● Arquitectura del sistema, aplicación, módulo o servicio web.- En caso de servicios web, se debe especificar: métodos, entradas, salidas,

nombre del campo, tipo de dato, longitud, obligatoriedad (si/no), descripción del método y del campo.

● Diagrama de componentes.

● Diagrama Entidad Relación.

● Diccionario de Datos:- Especificación de cada tabla (nombre de tabla, descripción de tabla, nombre

de columna, tipo de dato, nulo/no nulo, primary key (PK), foreign key (FK), tabla de referencia, descripción por columna).

d) Definir casos de pruebas para certificación de los servicios y componentes desarrollados.

3.2.4. Programación

a) Codificar o desarrollar los requerimientos (ref. inciso 3.2. REQUERIMIENTOS) del documento en base a la investigación y documentación generada durante el Análisis (ref. inciso 3.2.2.a. Aplicativo único móvil OSCE (Arquitectura móvil único), 3.2.2.b. Módulo móvil “Alertas OSCE”, 3.2.2.c. Módulo web para el seguimiento de alertas, 3.2.2.d. Seguridad).

b) Generar código fuente de los servicios y aplicación adecuadamente utilizando IDE Eclipse y Flutter según corresponda.

c) Versionar código fuente (repositorio GIT) incluyendo configuración y manejo de dependencias (usando Maven), comentando las principales actividades.

d) Realizar revisiones a través de depuraciones de calidad de código fuente (análisis estático utilizando SONARLINT, SONARQUBE u otros equivalentes) y análisis de vulnerabilidad.

e) Realizar las pruebas unitarias de la arquitectura y del módulo móvil a lo largo de todo el desarrollo, que permita la correcta puesta en marcha.

3.2.5. Pruebas

a) Realizar pruebas de integración para validar consistencia y ajustes necesarios de acuerdo con los requisitos y diseño definitivo aprobado por el equipo de gestión del proyecto.

b) El consultor deberá desplegar el producto en el ambiente de pruebas funcionales de aceptación, donde el equipo técnico realizará la validación del requerimiento

11

con el o los usuarios expertos que defina, validando el completo funcionamiento el requerimiento solicitado y los casos de pruebas generados en el análisis (punto 3.4).La entidad, podrá adicionar un máximo de 20% de los casos de prueba, que considere necesarios para verificar o validar los requerimientos funcionales y no-funcionales del producto.

3.2.6. Pase a producción

a) La OTI, con el acompañamiento del consultor, ejecutará esta fase desplegando el software certificado en el ambiente de producción que se defina, tomando como base la documentación elaborada y provista por el consultor.

b) Cabe precisar que los despliegues en producción se ejecutarán de acuerdo con los horarios que establezca la OTI de acuerdo a su protocolo.

3.2.7. Transferencia de conocimientos

a) Creación de manuales técnicos y manual funcional:

● Manual del desarrollador: El cual permita la configuración y habilitación del entorno del desarrollador (Ejm. Configuración de librerías, otros).

● Manual de especificaciones técnicas:- Base de datos: tablas, procedimientos, vistas y demás objetos creados.- Servicios y componentes (Especificación).- Configuración (permisos, niveles de autorización y otros).- Consideraciones generales para mantener la disponibilidad.

● Manual de usuario (funcional)b) Capacitación teórica - práctica al equipo de OTI, DSEACE y/u otras áreas

usuarias.c) Entrega de la documentación desarrollada en el proyecto (tanto en formato word

como en formato original. Ejm: diagramas, otros).d) Realizar el acompañamiento técnico durante el proceso de transferencia,

configuración, instalación e implementación del proyecto.

3.2.8. Transferencia de servicios y componentes

a) Código fuente de los servicios y componentes adecuadamente comentando y versionado.

12

4. METODOLOGÍA4.1. La metodología deberá estar alineada a la NTP ISO/IEC 12207 en lo referido a los

procesos y actividades relacionadas al alcance del servicio. Además, deberá proporcionar los artefactos que correspondan a cada fase del servicio, de acuerdo con los estándares proporcionados por la Entidad.

4.2. Debido a la situación de pandemia establecida por la OMS y la Declaratoria de Estado de Emergencia establecido por el Estado Peruano, es posible que muchas de las reuniones presenciales enumeradas en este TdR, sean reemplazadas por remotas, utilizando alguna herramienta de telecomunicaciones, videoconferencia y/o trabajo colaborativo, que en caso sea necesario proporcionará el Equipo de Gestión del Proyecto del BID.

5. ACTIVIDADES A REALIZAR5.1. Participar de la reunión inicial del proyecto (kick-off) (ref. inciso 3.2.1)5.2. Analizar, construir, programar y probar (ref. inciso 3.2.2)5.3. Análisis/Construcción (ref. inciso 3.2.3)5.4. Programación (ref. inciso 3.2.4)5.5. Pruebas (ref. inciso 3.2.5)5.6. Pase a producción (ref. inciso 3.2.6)5.7. Transferencia de conocimientos (ref. inciso 3.2.7)5.8. Transferencia de servicios y componentes (ref. inciso 3.2.8)5.9. Reuniones semanales para establecimiento de objetivos y revisión de avances (sprint

o hitos específicos) de los productos solicitados.5.10. Presentación preliminar de la solución antes de realizar la presentación final del

producto.5.11. Reuniones semanales en compañía del equipo BID, OTI y/o área usuaria.5.12. Generación de actas de cada reunión realizada.

6. PRODUCTOS E INFORMES A ENTREGAR

El consultor deberá presentar sus entregables a través de correo electrónico a las direcciones electrónicas que se le indicará en la reunión inicial del proyecto y mientras dure la situación de pandemia. Cuando las actividades se normalicen, se entregarán además a través de los canales que oficialice el OSCE.

Los productos presentados se realizarán de acuerdo con el siguiente cuadro:

N° Descripción de Entregable Plazo de Servicio

Primer Entregable

a) Plan de trabajo / cronograma de actividades.

b) Análisis funcional y construcción de la arquitectura móvil única (ref. inciso 3.2.2.a), módulo móvil “Alertas OSCE” (ref. inciso 3.2.2.b), módulo web para seguimiento de alertas (ref. inciso 3.2.2.c).

▪ Realizar las especificaciones de caso

Máximo 15 días calendario, contados desde el día hábil siguiente de la suscripción del contrato respectivo20%

13

de uso- ver Anexo N°01 que será utilizado para el desarrollo del módulo móvil y módulo web (ref. inciso 3.2.3.a).

▪ Definir el Diagrama de Actores del Sistema de Información (servicios y componentes) incluyendo la Matriz de Perfiles y Accesos - ver Anexo N°02 (ref. inciso 3.2.3.b).

▪ Realizar el documento de Diseño del Sistema de Información de servicios y componentes - ver Anexo N°03 (ref. 3.2.3.c).

▪ Definir casos de pruebas para certificación de los servicios y componentes desarrollados, con la participación de la OTI y DSEACE (ref. inciso 3.2.3.d)

c) Informe N°01.

Segundo Entregable

a) Desarrollo de funcionalidades solicitadas (ref. inciso 3.2.4):

▪ Aplicativo único móvil OSCE - Arquitectura móvil único (ref. inciso 3.2.2.a).

▪ Módulo móvil “Alertas OSCE” (ref. inciso 3.2.2.b).

▪ Seguridad (ref. inciso 3.2.2.d).b) Integración de código fuente en el

repositorio del proyecto (código adecuadamente documentado/ comentado).

c) Informe N°02.

A los 45 días calendario, contados desde el día siguiente de culminada y aprobada el primer entregable.30%

Tercer Entregable


▪ Módulo web para seguimiento de alertas (ref. inciso 3.2.2.c).

b) Integración de código fuente en el repositorio del proyecto (código adecuadamente documentado/ comentado).

c) Transferencia de conocimientos (ref. inciso 3.2.7).

d) Transferencia de servicios y componentes (ref. inciso 3.2.8).

e) Informe N°03.

A los 75 días calendario, contados desde el día siguiente de vencido el plazo de servicio del segundo entregable. 40%

14

Cuarto Entregable

a) Pruebas (Ref. inciso 3.2.5).b) Actas de aceptación de las pruebas

funcionales.c) Informe Final.

A los 90 días calendario, contados desde el día siguiente de vencido el plazo de servicio del tercer entregable. 10%

7. DURACIÓN DEL SERVICIO

El plazo máximo para la ejecución del servicio será de noventa (90) días calendario contados a partir del día siguiente hábil de la firma del contrato respectivo.

8. RECURSOS Y FACILIDADES A SER PROVISTOS POR LA ENTIDAD CONTRATANTE

OSCE facilitará al consultor la documentación necesaria que le apoye al análisis y actividades que debe realizar, establecidas en la reunión inicial del proyecto. Asimismo, apoyará al consultor a conseguir información de otras fuentes y para lograr la participación de los invitados a entrevistas y sesiones de trabajo que se programen durante la consultoría.

9. PERFIL

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

● Experiencia en programación en móviles para IOS/Android.

● Conocimientos en bases de datos Oracle y/o SQL

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

El Consultor será elegido según el método de Consultores Individuales, establecido en las Políticas de Consultores que están recogidas en el documento GN-2350-9 (marzo 2011).

La comparación de Currículos Vitae, se realizará tomando en cuenta la experiencia relacionada con las funciones que realizará y que están indicadas en el numeral 4.

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. Estos documentos serán solicitados al candidato elegido de forma previa a la suscripción del contrato. En caso que éste no las presente, o las mismas no coincidan con lo establecido en la Hoja de Vida, se escogerá al candidato que le sigue en el orden de mérito y así sucesivamente hasta agotar la lista de elegibles.

15

10. GARANTÍA DEL SERVICIO

La garantía sobre cada aplicativo desarrollado, estará vigente durante todo el tiempo del servicio, resolviendo y corrigiendo de manera inmediata incidencias identificadas en el ambiente de producción o donde se evidencie la responsabilidad del proveedor, sin generar costo alguno para la entidad.

Una vez concluida la totalidad del servicio, el proveedor proporcionará una garantía de seis (06) meses sobre los proyectos desarrollados durante la ejecución del servicio.

11. SUPERVISIÓN Y CONFORMIDAD DEL SERVICIO

La supervisión y conformidad del servicio estará a cargo del equipo de gestión del Proyecto BID (aspectos funcionales y normativos) y la OTI (aspectos técnicos).

12. CONFIDENCIALIDAD DE LA INFORMACIÓN

Toda información obtenida y a la que haya tenido acceso el Consultor, así como sus informes y los documentos que produzca, relacionados con la ejecución de su contrato, deberá ser considerada confidencial, no pudiendo ser divulgados sin autorización expresa por escrito del OSCE.

13. ANEXOS- Anexo 01: Formato de especificación del caso de uso- Anexo 02: Diagrama de Actores- Anexo 03: Diseño del Sistema de Información

16

II. CONTRATACIÓN DE UN CONSULTOR INDIVIUDAL PARA EL DESARROLLO DE LOS SERVICIOS DE FIRMA ELECTRÓNICA Y GENERACIÓN DE EXPEDIENTE ELECTRÓNICO

1. ANTECEDENTES

El 21 de mayo de 2018 el Gobierno de la República del Perú firmó el Contrato de Préstamo No.4428/OCPE con el Banco Interamericano de Desarrollo para financiar el Proyecto “Mejoramiento de la Capacidad para la Generación del Conocimiento y Mejora Continua en la Gestión de la Contratación Pública” (en adelante el Proyecto), el cual tiene como objetivo fortalecer la gestión de la inversión y las contrataciones públicas para contribuir con la reducción de las brechas de inversión en sectores clave de la economía y por áreas geográficas del Perú.

Los objetivos específicos del Proyecto son: (i) mejoramiento de la gestión de la inversión pública para la efectiva prestación de servicios y la provisión de la infraestructura prioritaria; (ii) 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.

Para el logro de los objetivos señalados, el Proyecto contempla la ejecución de los componentes siguientes:

▪ Componente 1: Mejora de la 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: Mejora de la capacidad del capital humano.

Considerando que hoy en día existen una serie de problemáticas e iniciativas orientadas a mejorar la situación actual del proceso de compras y que el resultado de todo el proyecto se tendrá a mediano plazo, es que el Organismo Supervisor de Contrataciones del Estado (OSCE) requiere desarrollar e implementar proyectos complementarios que permitan obtener mejoras inmediatas, resultados demostrables y preparación del ambiente necesario para los cambios con mayor impacto a generarse en el futuro con las diferentes implementaciones.

Por lo mismo, el Organismo Supervisor de Contrataciones del Estado (OSCE) requiere contar con el desarrollo del proyecto de firma electrónica y generación de expediente electrónico, que tiene como objetivo la implementación de dos (02) servicios web, de los cuales el primer servicio deberá generar una o más firmas electrónicas a través de factores de autenticación, y el segundo servicio permitirá generar un expediente electrónico que apunta a los documentos digitales firmados electrónicamente por métodos del primer servicio. Estos componentes podrán ser utilizados por otros módulos, componentes o sistemas de información, mediante el consumo del servicio y el envío de parámetros específicos.

Este desarrollo permitirá generar documentos y expedientes electrónicos que soporten los actos administrativos realizados a través del medio electrónico, de modo que posean la

17

misma validez y eficacia jurídica que los actos realizados por medios físicos tradicionales, de acuerdo a lo estipulado en el artículo Nº30 del Decreto Supremo Nº 006-2017-JUS, Decreto Supremo que aprueba el TUO de la Ley Nº27444- Ley del Procedimiento Administrativo General, de junio de 2017.

Asimismo, como se menciona en la octava disposición complementaria final del Reglamento de la Ley Nº 30225, Ley de Contrataciones del Estado, aprobado por Decreto Supremo Nº 344-2018-EF, OSCE puede implementar mecanismos electrónicos para recibir la documentación de las partes o de terceros y para notificar los actos administrativos emitidos durante sus procedimientos.

2. OBJETIVO GENERAL Y OBJETIVOS ESPECÍFICOS DE LA CONSULTORÍA

2.1. OBJETIVO GENERALDesarrollar dos (02) servicios web que puedan ser consumidos por cualquier módulo, componente o sistema de información; permitiendo el primero, que a través del envío de parámetros se genere como resultado la firma electrónica de documentos digitales, y el segundo la generación de un expediente electrónico. El software desarrollado debe cumplir con la normativa peruana respectiva.

2.2. OBJETIVOS ESPECÍFICOS2.2.1. Desarrollar (01) un servicio web que permita firmar electrónicamente un

documento (que se denominará documento electrónico) por uno o más individuos, considerando factores de autenticación que aseguren los datos del firmante y la integridad del documento. Estos documentos firmados, se almacenarán en un repositorio de documentos firmados, con sus respectivos códigos de verificación.

2.2.2. Desarrollar (01) un servicio web que permita generar un expediente electrónico. El expediente electrónico (1) es el equivalente digital de un expediente administrativo y consta de documentos electrónicos, índice, firma y metadatos. El servicio de gestión de expedientes electrónicos, permitirá el armado de los expedientes electrónicos a través de la agregación de los documentos del repositorio de documentos firmados. Este expediente apunta virtualmente a dichos documentos finales firmados, implementando con la agrupación de ellos una foliación electrónica a través del índice electrónico.

2.2.3. Desarrollar el componente móvil que permita el envío de los passwords de un solo uso, que se complementará con los mencionados dos servicios.

2.2.4. Implementar mecanismos de seguridad necesaria al desarrollar los servicios a través del uso y envío de token para integraciones de cualquier tipo (permisos entre aplicaciones, envío de códigos de seguridad, otros). Asimismo, se deberá realizar análisis de vulnerabilidad de los servicios y su componente móvil.

2.2.5. Desarrollar los productos de modo que cumplan con la normativa peruana pertinente, sostenible y escalable de acuerdo a la demanda en el tiempo y se pueda instalar on premise o nube.

NOTA AL PIE DE PÁGINA (1): En el Decreto Supremo Nº 006-2017-JUS, Decreto Supremo que aprueba el TUO de la Ley Nº27444- Ley del Procedimiento Administrativo General, de junio de 2017; se indica en su Artículo Nº30, sobre el Procedimiento Administrativo Electrónico, lo siguiente: que sin perjuicio del uso de medios físicos tradicionales, el procedimiento administrativo podrá realizarse total o parcialmente a través de tecnologías y medios electrónicos, debiendo constar en un expediente, escrito electrónico, que contenga los documentos presentados por los administrados, por terceros y por otras entidades, así como aquellos documentos remitidos al administrado. Asimismo indica en el numeral 30.3, que “los actos administrativos realizados a través del medio electrónico, poseen la misma validez y eficacia jurídica que los actos realizados por medios físicos tradicionales”. Sin embargo, a la fecha no existe normativa que establezca la estructura de dicho expediente electrónico. Por ello, se ha tomado la

18

estructura contenida en la Guía de Aplicación de la Norma Técnica de Interoperabilidad 2da edición electrónica del Ministerio de Hacienda y Administraciones Públicas de España, 2016. (NIPO: 630-16-339-9).

3. ALCANCE DEL SERVICIO

3.1. REQUISITOS:

La consultoría se encargará de realizar el análisis y la programación del servicio de firma electrónica y generación de expediente electrónico, así como del componente móvil, los cuales serán desarrollados en una tecnología moderna, escalable y sostenible en el tiempo, garantizando el ciclo de vida de los productos y servicios de software que se suministre, desarrolle y opere; velando en todo momento por el cumplimiento de la normativa peruana vigente, en particular la relacionada al ciclo de vida de software y protección de datos personales. Asimismo con los parámetros de evaluación y gestión de proyectos de sistemas de información basado en estándares, así como el de seguridad física y control de accesos.

▪ Los estándares a tomar en cuenta para el desarrollo de los servicios web (webservices, apis, otros) y/o aplicativos web serán los siguientes:

Item

Descripción Estándar Especificación



2 Lenguaje de Programación

Java 8+ Framework: Spring Boot 2.0+Front End: Angular Material 8+


MSSQL Server u Oracle 12c

4 Plataforma Web


6 Servidor de Aplicaciones

JBoss

7 Otros Seguridad:- Protocolo OAUTH2- Jason Web Token

(JWT)Técnica de Diseño Web:- Diseño Responsive (*)

(*) Diseño responsive de acuerdo a punto 2 (Lenguaje de programación)Front End: Angular Material 8+

▪ Los estándares a tomar en cuenta para el desarrollo de aplicativos móviles serán los siguientes:

19

Item Descripción Estándar Especificación



2 SDK Flutter Disponibilidad para Android y para IOS (generación del código de forma simultánea para ambas plataformas).


SQLite 3.4+ Integración a través de servicios web: MSSQL Server u Oracle 12cUso SQLite según corresponda.

4 Plataforma Android& IOS

Dispositivos móviles (Celulares, Tablets, Smartphones).


▪ Los diagramas solicitados deberán cumplir con la notación UML 2.0 como mínimo.

3.2. REQUERIMIENTOS:

La consultoría deberá incluir los siguientes aspectos:

3.2.1. Participar de la reunión inicial del proyecto (kick-off) para la entrega de documentación o recursos por parte del equipo del Proyecto BID, con la finalidad de iniciar el análisis funcional y el desarrollo del producto (Proyecto BID hará entrega del documento de requerimientos, ficha del proyecto, entre otros insumos).

3.2.2. Analizar, construir, programar y probar los servicios para generación de firma electrónica, generación de expediente electrónico y componente móvil:

a) Servicio de Firma Electrónica: El servicio debe permitir:

● Acceder desde cualquier aplicación que lo invoque, sea web (mediante cualquier navegador) o aplicación móvil; a través de la autorización por token. Este debe ser generado utilizando OAuth 2 con envío de JWT (JSON Web Token). El token debe ser generado con un tiempo de expiración máximo de una (01) hora, configurable.

20

● Recibir como parámetros de entrada: el documento para firmar (como mínimo debe soportar las extensiones txt, xls, csv, doc, xml, pdf, jpg), y un listado de firmantes que debe contener como mínimo: nombres completos, número de DNI, números de celular y correos electrónicos.

● Realizar una o varias firmas electrónicas a dicho documento específico según el mencionado listado de firmantes (de uno o más individuos). La firma debe asignarse a cada una de las páginas del documento, en caso de ser requerido por OSCE.

● Generar un PIN (código de un solo uso) seguro utilizando el protocolo OAuth 2 y forma de envío JWT (JSON Web Token), para luego ser enviado a cada individuo de la lista de firmantes enviada como parámetro del servicio. El PIN (código de un solo uso) debe ser generado por un intervalo de expiración de tiempo parametrizable, de igual manera el envío del PIN debe poder ser enviado mínimamente por medio de los siguientes tres (03) canales digitales:

- Correo electrónico:

▪ Enviar al correo electrónico institucional del firmante la ruta de ingreso para visualizar el documento que se va a firmar (documento de "n" páginas con peso máximo de 12 MB).

▪ Generar y enviar PIN (código de un solo uso), fecha y hora de solicitud, geolocalización desde donde fue generado el PIN vía correo electrónico.

- Mensaje de texto (certificado de preferencia):

▪ Enviar vía mensaje de texto la ruta de ingreso para visualizar el documento que se va a firmar (documento de "n" páginas con peso máximo de 12 MB).

▪ Generar y enviar PIN (código de un solo uso), fecha y hora de solicitud desde donde fue generado el PIN vía mensaje de texto (SMS).

- Vía aplicación móvil:

▪ Generar un evento (socket) que permita notificar que se ha solicitado una firma mediante una función escucha al aplicativo móvil que invoca el servicio.

▪ Se debe enviar una notificación a la aplicación móvil donde se pueda visualizar la fecha, hora y geolocalización de la solicitud desde donde se ha solicitado la petición.

▪ Los PIN deben ser generados con un intervalo de expiración de tiempo de configurable.

21

▪ Generar tabla de notificaciones de firma para aplicativo móvil, el cual luego pueda ser consumido por el mismo (app móvil) en un intervalo de tiempo de 1 minuto (configurable), exponer esta tabla mediante un método del servicio. La tabla de notificaciones debe tener en cuenta (fecha de solicitud, hora de solicitud, geolocalización de la solicitud, ruta del documento donde se visualiza el documento que se va a firmar, número de celular).

▪ Permitir firmar automáticamente desde el aplicativo móvil (llamando a un método del servicio), para la firma validar PIN internamente (comparar hash de PIN para dejar evidencia del hecho).

Importante: La finalidad de enviar este PIN a través de los tres canales mencionados, es para constituirse como un segundo factor de autenticación, dado que el primero será el certificado SEACE, a través del cual ingresan a los sistemas de OSCE. Esto fortalecerá el mecanismo de firma.

● Vía cualquiera de los (03) tres canales digitales, validar el PIN (código de un solo uso) que es ingresado por el usuario, generar hash de los dos PIN y comparar. Si son iguales el servicio debe enviar un "OK" de lo contrario debe emitir un error.

● Cargar el documento (con “n” páginas) al “repositorio temporal” antes de que el documento sea firmado.

● Cargar dicho documento en el “repositorio de documentos firmados” cuando se genere la primera firma por el primer firmante (individuo).

● Generar un registro de acciones en una tabla de auditoría cada vez que se genere una firma, donde se registren los datos principales de los firmantes (tipo de documento y número de documento del firmante, hora de firma, fecha de firma, IP donde se originó la firma, entre otros) cada vez que el documento sea validado y firmado, así como la información en el documento de evidencias (log estructurado).

● Recibir un trazo en representación de una firma manuscrita (imagen) e incrustarla en el documento original. Este trazo es representación de la firma manuscrita de forma opcional para imprimir en el documento haciendo un símil del documento firmado. Cabe destacar que aunque este trazo no tiene valor legal, pueden dar cierta sensación de seguridad a los firmantes y suelen usarse durante el periodo de cambio institucional hacia las firmas electrónicas y/o digitales.

● Crear un archivo estructurado XML cuando todas las firmas de la lista de firmantes (uno o más) se hayan generado, este archivo XML contendrá:

22

- Metadatos del documento (como mínimo: tipo de documento, autor, área que la generó, código único, fecha y hora de recepción )

- Cuerpo del documento: el documento original convertido en código base64.- Firma de la lista de firmantes (una o más firmas)- Hash del documento: El hash debe generarse a partir de los metadatos,

cuerpo y firma de la lista de firmantes, este debe ser generado mínimamente utilizando SHA2 u otro superior (seguro).

● Generar Código Seguro de Verificación (CSV) el cual tendrá la siguiente nomenclatura:- Sede u órgano: Lugar donde se generó el documento (código de entidad +

código de la Unidad).- Huella del documento: Hash generado en el documento XML (metadato +

cuerpo del documento + firma).- Id interno firmante: Cadena del tipo documento + número de documento.- Tiempo: Cuando se generó el documento (fecha y hora).

● Generar un código QR a partir del Código Seguro de Verificación (CSV), este código QR debe ser incrustado en el documento XML una vez que el documento tenga la firma de toda la lista de firmantes.

● Conservar el documento en su formato original en el “repositorio de documentos firmados”, el Código Seguro de Verificación con su Código QR generado a partir de éste y el archivo XML. Estos dos últimos elementos son salidas del servicio: el documento firmado por todos los que aparecen en el listado, almacenado en el repositorio de documentos firmados, y su respectivo CSV en formato QR para comprobar la integridad del documento firmado.

● Finalmente, invocar al servicio de Gestión de Expediente Electrónico cuando ya se haya generado el XML + CSV (Código Seguro de Verificación) + QR del CSV automáticamente, solamente si la respuesta del servidor es OK (no existe error). Esta invocación debe ser configurable y debe llegar como parámetro para que el servicio de Firma Electrónica pueda identificar si debe o no llamar al servicio de Gestión de Expediente Electrónico, ya que en algunas ocasiones puede darse que no necesariamente un documento firmado se asigne a un expediente.

b) Servicio de Gestión de Expediente Electrónico: El servicio debe permitir:

● Ser invocado desde cualquier aplicación web o móvil, a través de la autorización por Token, el cual debe ser generado utilizando el protocolo OAuth 2 con forma de envío JWT (JSON Web Token). El token debe ser generado con un tiempo de expiración máximo de una (01) hora, configurable. Similar al primer servicio.

23

● Generar carpetas asignadas a un expediente electrónico de manera virtual y no física. Es decir, apuntando a los documentos electrónicos firmados del primer servicio y no volviendo a copiar los documentos en otro repositorio.

● Crear carpetas padres y subcarpetas asignando documentos desde el repositorio de documentos firmados a cada uno de ellos según corresponda. Esto se hará desde un módulo configurador, y dependerá del proceso en el que se vaya a utilizar el expediente electrónico. Por ejemplo, uno de los primeros proyectos de la cartera de servicios del proyecto BID que consumirá estos dos servicios es “Presentación de Ofertas”, que se encuentra en la fase de Selección, tal como se ve en la siguiente figura:

Figura. Fases de la contratación

● Crear de manera automática un archivo XML denominado "Índice Electrónico" que contendrá información acerca del documento asignado a la carpeta o subcarpeta. El archivo XML contendrá los siguientes datos:- Índice Contenido: Cabecera, código que identifica al índice de forma única

e inequívoca y lo relaciona con el expediente al que pertenece el documento.

- Fecha Índice Contenido: Cabecera, es la fecha en la que el índice se conforma.

- Documento Foliado: Es el código único del documento dentro del expediente.

- Tipología Documental: Catalogación del documento para el cual ha sido concebido. Ejm: Contrato, Base, Base Integrada, entre otros.

- Fecha Creación del Documento: Es la fecha en la que se crea el documento, debe ser igual o inferior a la fecha de incorporación al expediente. Formato: YYYMMDD.

- Fecha Incorporación Expediente: Es la fecha en la que el documento comienza a hacer parte del expediente. Formato: YYYMMDD.

- Valor Huella (HASH): Es el código generado por el resultado del cálculo del algoritmo de la función resumen, para garantizar que el documento no va a ser modificado una vez se conforma el expediente.

- Función Resumen: Es el identificador de la función que se utilizó para calcular el valor de la huella. Ejm: MD5.

24

- Orden Documento Expediente: Es el valor consecutivo del orden del documento dentro del expediente a medida que se va conformando. El valor del consecutivo debe ser coherente con la fecha de incorporación al expediente.

- Página Inicio: Es la página en la que inicia el documento dentro del orden establecido en el expediente, y deberá ser consecutivo para el total de páginas de todos los documentos que conforman el expediente.

- Página Fin: Última página del documento. Ejm: Documento 1 = 30 páginas de la 1 a la 30, Documento 2 = 20 páginas de la 31 a la 50.

- Formato: Es el formato contenedor del documento electrónico. Conjunto de reglas (algoritmo) que define de manera correcta de intercambiar o almacenar datos en memoria. Su objetivo es lograr la normalización y perdurabilidad para asegurar la independencia de los datos de sus soportes. Ejm: PDF/A, XLSX, otros.

- Tamaño: Es el tamaño del documento en bytes, megabytes o gigabytes. Ejm: 15MB.

- Expediente Foliado: Es el conjunto de datos que se heredan del expediente para relacionar al expediente con el índice.

● Actualizar la versión del documento en una subcarpeta, siendo este documento el final. Ejm: TdRv2 el cual será apuntado como documento final en la carpeta, más no la versión 1 de este ejemplo (TdRv1) esto se debe determinar en base a la fecha y hora de firmado el documento.

● Descargar el último documento firmado y válido (última versión).

● Comparar archivos el cual tendrá dos (02) opciones:- Primera opción: Cualquier usuario podrá leer el código QR desde un

documento impreso a través de un lector de QR (dispositivo móvil u otro), el aplicativo podrá capturar la información y validar la misma (el Código Seguro de Verificación) e indicar si el documento es válido, de ser el caso se mostrará el documento, de lo contrario se mostrará un mensaje indicando la invalidez del documento.

- Segunda opción: Comparación de documentos digitales a través de la comparación del hash. El usuario podrá cargar un archivo (documento) para luego ser contrastado con el documento (versión final) que se encuentra en el repositorio de documentos firmados.

c) Componentes :

● Módulo de Configuración (Para el servicio de expediente electrónico):

- Este módulo permitirá generar una estructura árbol general de las carpetas virtuales que se deberán crear por el proceso que vaya a invocar el servicio de expediente electrónico. Este árbol o estructura será usado cuando se requiera crear un expediente electrónico virtual, como se ve en la figura anterior de Fases de la Contratación.

25

- Finalmente, se podrá crear, editar, actualizar o eliminar carpetas o subcarpetas.

● Módulo de Generación de Firma por App Móvil:

Este módulo permitirá lo siguiente:

- Mostrar una notificación cada vez que se solicite firmar un documento y el firmante tenga instalada la función de firma desde aplicación móvil.

- Mostrar una notificación cada vez que se solicite firmar un documento luego de ser validado y revisado por el firmante (usuario de la aplicación móvil). La notificación mostrada debe contener la ubicación desde donde se está realizando la solicitud, la fecha de solicitud, la hora de solicitud y dos botones de SI o NO con el que el usuario indique si está intentando firmar un documento.

- Permitir que el usuario pueda visualizar y revisar el documento que va a firmar de manera electrónica (antes que se genere alguna firma).

- Una vez revisado el documento por el usuario, éste a través del botón "Validar y Firmar" pueda generar una firma manuscrita de manera opcional, para ello a través de una ventana emergente se solicitará un grafo al usuario el cual podrá realizarse con el puntero del mouse o de manera táctil (para tablets, IPAD, otros).

- Invocar al método para generación de PIN provisto por el servicio de firma electrónica.

- Invocar el servicio de firma electrónica con el método correspondiente a la revisión y comparación de PIN (no debe solicitar el PIN como ingreso, la comparación debe realizarse de manera interna).

- Invocar al servicio de firma electrónica y generar el archivo XML + CSV (Código Seguro de Verificación) + QR del CSV una vez que todas las firmas de la lista de firmantes se hayan generado. Es importante, que al momento de hacer click en firmar, aparezca un mensaje claro al usuario, de “manifestación de voluntad” de querer firmar y hacer suyo el documento electrónico, para mitigar posibles problemas de repudio del mencionado documento.

- Descargar el último documento firmado y válido (última versión).- Contar con la opción Comparación de archivos el cual tendrá dos (02) sub-

opciones:

▪ Primera subopción: Cualquier usuario podrá leer el código QR desde un documento impreso a través de un lector de QR (dispositivo móvil u otro), el aplicativo podrá capturar la información y validar la misma (el Código Seguro de Verificación) e indicar si el documento es válido, de ser el caso se mostrará el documento, de lo contrario se mostrará un mensaje indicando la invalidez del documento.

▪ Segunda subopción: Comparación de documentos digitales a través de la comparación de Hash. El usuario podrá cargar un archivo (documento) para luego ser contrastado con el documento (versión final)

26

que se encuentra en el repositorio de documentos firmados.

d) Seguridad :

● Los servicios, componente y la aplicación móvil deben permitir guardar registros de auditoría (acciones) de importancia, así como la información en el documento de evidencias (log estructurado).- Registros de Auditoría

▪ Datos principales de los firmantes (firmante, hora de firma, fecha de firma, ip donde se originó la firma, entre otros) cada vez que el documento sea validado y firmado.

▪ Datos utilizados para generación de XML, CSV, QR (fecha de creación, hora, documento al que pertenece, entre otros).

- Documento de evidencias (log estructurado): Documento que permitirá registrar la auditoría de los movimientos o acciones principales realizadas durante el proceso de firma.

▪ Al enviar un correo electrónico: El documento debe contemplar los datos de usuario remitente, remitente, destino, fecha y hora de envío, fecha y hora de entrega, asunto, mensaje, archivos anexos (de ser el caso), metadata del correo electrónico enviado.

▪ Al enviar un mensaje de texto: El documento debe contemplar los datos de usuario de envío, remitente, destino (número de celular), fecha y hora de envío y fecha y hora de entrega, mensaje enviado).


3.2.3. Análisis/Construcción:

a) Realizar un análisis preliminar (a un alto nivel) de los procesos que consumirán y/o utilizarán el servicio de firma electrónica, servicio de gestión de expediente electrónico y del componente móvil que consumirá estos servicios a través de integraciones o interfaces.

b) Identificar y plantear el proceso TO BE que se utilizará para la generación del servicio de firma electrónica, servicio de gestión del expediente electrónico y el componente móvil.

27

c) Realizar las especificaciones de caso de uso (ver Anexo N°01) que será utilizado para el desarrollo del servicio de firma electrónica, servicio de gestión de expediente electrónico y el componente móvil.

d) Definir el Diagrama de Actores del Sistema de Información (servicios y componentes) incluyendo la Matriz de Perfiles y Accesos (ver Anexo N°02).

e) Realizar el documento de Diseño del Sistema de Información (servicios y componentes) el cual debe contener como mínimo (ver Anexo N°03):

● Arquitectura del sistema, aplicativo, módulo o servicio web.- En caso de servicios web, se debe especificar: métodos, entradas, salidas,

nombre del campo, tipo de dato, longitud, obligatoriedad (si/no), descripción del método y del campo.

● Diagrama de componentes.

● Diagrama Entidad Relación. - Diccionario de Datos: Especificación de cada tabla (nombre de tabla,

descripción de tabla, nombre de columna, tipo de dato, nulo/no nulo, primary key (PK), foreign key (FK), tabla de referencia, descripción por columna).

Importante: Los desarrollos deben ser escalables e instalables on premise o nube.

f) Definir casos de pruebas para certificación de los servicios y componentes desarrollados, con la participación de la OTI y DSEACE.

3.2.4. Programación

a) Codificar o desarrollar los requerimientos (ref. inciso 3.2. REQUERIMIENTOS) del documento en base a la investigación y documentación generada durante el Análisis (ref. inciso 3.2.2.a. Servicio de Firma Electrónica, 3.2.2.b. Servicio de Gestión de Expediente Electrónico, 3.2.2.c. Componentes, 3.2.2.d. Seguridad).

b) Generar código fuente de los servicios y aplicación adecuadamente utilizando IDE Eclipse.

c) Versionar código fuente (repositorio GIT) incluyendo configuración y manejo de dependencias (usando Maven), comentando las principales actividades.

d) Realizar revisiones a través de depuraciones de calidad de código fuente (análisis estático utilizando SONARLINT, SONARQUBE u otros equivalentes) y análisis de vulnerabilidad .


3.2.5. Pruebas

a) Realizar pruebas de integración para validar consistencia y ajustes necesarios de acuerdo con los requisitos y diseño definitivo aprobado por el equipo de gestión.

b) El consultor deberá desplegar el producto en el ambiente de pruebas funcionales de aceptación, donde el equipo técnico realizará la validación del requerimiento con el o los usuarios expertos que defina, validando el completo funcionamiento

28

el requerimiento solicitado y los casos de pruebas generados en el análisis (punto 3.6).La entidad, podrá adicionar un máximo de 20% de los casos de prueba, que considere necesarios para verificar o validar los requerimientos funcionales y no-funcionales del producto.

3.2.6. Pase a producción

a) La OTI, con el acompañamiento del consultor, ejecutará esta fase desplegando el software certificado en el ambiente de producción que se defina, tomando como base la documentación elaborada y provista por el consultor.

b) Cabe precisar que los despliegues en producción se ejecutarán de acuerdo con los horarios que establezca la OTI de acuerdo a su protocolo.

3.2.7. Transferencia de conocimientos

a) Creación de manuales técnicos y manual funcional:

● Manual del desarrollador: El cual permita la configuración y habilitación del entorno del desarrollador (Ejm. Configuración de librerías, otros).

● Manual de especificaciones técnicas:- Base de datos: tablas, procedimientos, vistas y demás objetos creados.- Servicios y componentes (Especificación).- Configuración (permisos, niveles de autorización y otros).- Consideraciones generales para mantener la disponibilidad.- Manual de usuario (funcional)

b) Capacitación teórica - práctica al equipo de OTI, DSEACE y/u otras áreas usuarias.

c) Entrega de la documentación desarrollada en el proyecto (tanto en formato word como en formato original. Ejm: diagramas, otros).

d) Realizar el acompañamiento técnico durante el proceso de transferencia, configuración, instalación e implementación del proyecto.

3.2.8. Transferencia de servicios y componentesa) Código fuente de los servicios y componentes adecuadamente comentando y

versionado.

29

4. METODOLOGÍA4.1. La metodología deberá estar alineada a la NTP ISO/IEC 12207 en lo referido a los

procesos y actividades relacionadas al alcance del servicio. Además, deberá proporcionar los artefactos que correspondan a cada fase del servicio, de acuerdo con los estándares proporcionados por la Entidad.

4.2. Debido a la clasificación de pandemia establecida por la OMS y la Declaratoria de Estado de Emergencia establecido por el Estado Peruano, es posible que muchas de las reuniones presenciales enumeradas en este TdR, sean reemplazadas por remotas, en tanto dure la circunstancia de fuerza mayor, utilizando alguna herramienta de telecomunicaciones, videoconferencia y/o trabajo colaborativo, que en caso sea necesario proporcionará el Equipo de Gestión del Proyecto del BID.

5. ACTIVIDADES A REALIZAR5.1. Participar de la reunión inicial del proyecto (kick-off) (ref. inciso 3.2.1)5.2. Analizar, construir, programar y probar (ref. inciso 3.2.2)5.3. Análisis/Construcción (ref. inciso 3.2.3)5.4. Programación (ref. inciso 3.2.4)5.5. Pruebas (ref. inciso 3.2.5)5.6. Pase a producción (ref. inciso 3.2.6)5.7. Transferencia de conocimientos (ref. inciso 3.2.7)5.8. Transferencia de servicios y componentes (ref. inciso 3.2.8)5.9. Reuniones semanales para establecimiento de objetivos y revisión de avances (sprint o

hitos específicos) de los productos solicitados.5.10. Reuniones semanales en compañía del equipo BID, OTI y/o área usuaria.5.11. Presentación preliminar de la solución antes de realizar la presentación final del

producto.5.12. Generación de actas de cada reunión realizada.

6. PRODUCTOS E INFORMES A ENTREGAR

El consultor deberá presentar sus entregables a través de correo electrónico a las direcciones electrónicas que se le indicará en la reunión inicial del proyecto y mientras dure la situación de pandemia. Cuando las actividades se normalicen, se entregarán además a través de los canales que oficialice el OSCE.

Los productos presentados se realizarán de acuerdo con el siguiente cuadro:

N° Descripción de Entregable Plazo de Servicio

Primer Entregable

a) Plan de trabajo / cronograma de actividades.

b) Análisis funcional y construcción de los servicios (ref. inciso 3.2.3) de Firma Electrónica (ref. inciso 3.2.2.a), Gestión de Expediente Electrónico (ref. inciso 3.2.2.b), Componentes (ref. inciso 3.2.2.c).

▪ Análisis preliminar (a un alto nivel)

Máximo 15 días calendario, contados desde el día hábil siguiente de la suscripción del contrato respectivo20%

30

de los procesos que consumirán y/o utilizarán los servicios y componentes (ref. inciso 3.2.3.a).

▪ Identificar y plantear el proceso TO BE que se utilizará para la generación del servicio de firma electrónica, servicio de gestión del expediente electrónico y componente (ref. inciso 3.2.3.b).

▪ Realizar las especificaciones de caso de uso - ver Anexo N°01 que será utilizado para el desarrollo del servicio de firma electrónica, servicio de gestión de expediente electrónico y componente (ref. inciso 3.2.3.c).

▪ Definir el Diagrama de Actores del Sistema de Información de servicios y componentes incluyendo la Matriz de Perfiles y Accesos - ver Anexo N°02. (ref. inciso 3.2.3.d).

▪ Realizar el documento de Diseño del Sistema de Información de servicios y componentes - ver Anexo N°03 (ref. inciso 3.2.3.e).

▪ Definir casos de pruebas para certificación de los servicios y componentes desarrollados, con la participación de la OTI y DSEACE (ref. inciso 3.2.3.e).

▪ Informe N°01.

Segundo Entregable


▪ Servicio de firma electrónica (ref. inciso 3.2.2.a).

▪ Servicio de gestión de expediente electrónico (ref. inciso 3.2.2.b).

▪ Seguridad (ref. inciso 3.2.2.d).b) Integración de código fuente en el


c) Informe N°02.

A los 45 días calendario, contados desde el día siguiente de culminada y aprobada el primer entregable.30%

31

Tercer Entregable


▪ Componentes (ref. inciso 3.2.2.c).- Módulo Configuración

(Expediente).- Módulo Generación de firma por

App Móvil.

▪ Seguridad (ref. inciso 3.2.2.d)b) Integración de código fuente en el


c) Transferencia de conocimientos (ref. inciso 3.2.7).

d) Transferencia de servicios y componentes (ref. inciso 3.2.8).

e) Informe N°03.

A los 75 días calendario, contados desde el día siguiente de vencido el plazo de servicio del segundo entregable. 40%

Cuarto Entregable

a) Pruebas (ref. inciso 3.2.5).b) Actas de aceptación de las pruebas

funcionales.c) Informe Final.

A los 90 días calendario, contados desde el día siguiente de vencido el plazo de servicio del tercer entregable. 10%

7. DURACIÓN DEL SERVICIO

El plazo máximo para la ejecución del servicio será noventa (90) días calendario contados a partir del día siguiente hábil de la firma del contrato respectivo.

8. RECURSOS Y FACILIDADES A SER PROVISTOS POR LA ENTIDAD CONTRATANTE

OSCE y el equipo del Proyecto BID facilitarán al consultor, en la medida de sus respectivas competencias, la documentación necesaria para el análisis y actividades que debe realizar, establecidas en la reunión inicial del proyecto. Asimismo, apoyará al consultor a conseguir información de otras fuentes y para lograr la participación de los invitados a entrevistas y sesiones de trabajo que se programen durante la consultoría.

9. PERFIL

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

● Experiencia laboral no menor de dos (06) años en el sector público o privado en labores relacionadas en Tecnologías de la Información.

32

● Experiencia laboral mínima de tres (04) años realizando funciones relacionadas al análisis de sistemas.

El Consultor será elegido según el método de Consultores Individuales, establecido en las Políticas de Consultores que están recogidas en el documento GN-2350-9 (marzo 2011).

La comparación de Currículos Vitae, se realizará tomando en cuenta la experiencia relacionada con las actividades a realizar y productos a entregar.

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. Estos documentos serán solicitados al candidato elegido de forma previa a la suscripción del contrato. En caso que éste no las presente, o las mismas no coincidan con lo establecido en la Hoja de Vida, se escogerá al candidato que le sigue en el orden de mérito y así sucesivamente hasta agotar la lista de elegibles.

10. GARANTÍA DEL SERVICIO

La garantía sobre cada aplicativo desarrollado, estará vigente durante todo el tiempo del servicio, resolviendo y corrigiendo de manera inmediata incidencias identificadas en el ambiente de producción o donde se evidencie la responsabilidad del proveedor, sin generar costo alguno para la entidad.

Una vez concluida la totalidad del servicio, el proveedor proporcionará una garantía de seis (06) meses sobre los proyectos desarrollados durante la ejecución del servicio.

11. SUPERVISIÓN Y CONFORMIDAD DEL SERVICIO

La supervisión y conformidad del servicio estará a cargo del equipo de gestión del Proyecto BID (aspectos funcionales y normativos) y la OTI (aspectos técnicos).

12. CONFIDENCIALIDAD DE LA INFORMACIÓN

Toda información obtenida y a la que haya tenido acceso el Consultor, así como sus informes y los documentos que produzca, relacionados con la ejecución de su contrato, deberá ser considerada confidencial, no pudiendo ser divulgados sin autorización expresa por escrito del OSCE.

13. ANEXOS- Anexo 01: Formato de especificación del caso de uso- Anexo 02: Diagrama de Actores- Anexo 03: Diseño del Sistema de Información

33

cdn.€¦ · web viewsolicitud de cotizaciÓ. n. referencial. organismo supervisor de...

Documents