TÉRMINOS DE REFERENCIA CONTRATACIÓN PARA EL DESARROLLO DE LOS SERVICIOS DE FIRMA ELECTRÓNICA Y GENERACIÓN DE EXPEDIENTE ELECTRÓNICO
TÉRMINOS DE REFERENCIA
CONTRATACIÓN PARA EL DESARROLLO DE LOS SERVICIOS DE FIRMA ELECTRÓNICA Y GENERACIÓN DE EXPEDIENTE ELECTRÓNICO
El 00 xx xxxx xx 0000 xx Xxxxxxxx xx xx Xxxxxxxxx xxx Xxxx firmó el Contrato xx Xxxxxxxx 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 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, xx xxxxx 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.
Desarrollar 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.
-
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.
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.
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.
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.
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, xx xxxxx 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 estructura contenida en la Guía de Aplicación de la Norma Técnica de Interoperabilidad 2da edición electrónica del Xxxxxxxxxx xx Xxxxxxxx x Xxxxxxxxxxxxxxxx Xxxxxxxx xx Xxxxxx, 0000. (NIPO: 630-16-339-9).
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 |
1 |
Arquitectura |
MVC y/o derivado MVC |
Modelo Vista Controlador |
2 |
Lenguaje de Programación |
Java 8+ |
Framework: Spring Boot 2.0+ |
3 |
Motor de Base de Datos |
MSSQL Server u Oracle 12c |
|
4 |
Plataforma |
Web |
|
5 |
Servicio web |
SOAP / REST |
|
6 |
Servidor de Aplicaciones |
JBoss |
|
7 |
Otros |
Seguridad:
Técnica de Diseño Web: |
(*) 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:
Item |
Descripción |
Estándar |
Especificación |
1 |
Arquitectura |
MVC y/o derivado MVC |
Modelo Vista Controlador |
2 |
SDK |
Flutter |
Disponibilidad para Android y para IOS (generación del código de forma simultánea para ambas plataformas). |
3 |
Motor de Base de Datos |
SQLite 3.4+ |
Integración a través de servicios web: MSSQL Server u Oracle 12c Uso SQLite según corresponda. |
4 |
Plataforma |
Android & IOS |
Dispositivos móviles (Celulares, Tablets, Smartphones). |
5 |
Servicio web |
SOAP / REST |
|
Los diagramas solicitados deberán cumplir con la notación UML 2.0 como mínimo.
REQUERIMIENTOS:
La consultoría deberá incluir los siguientes aspectos:
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).
Analizar, construir, programar y probar los servicios para generación de firma electrónica, generación de expediente electrónico y componente móvil:
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.
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.
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á:
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.
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.
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: Xxxxxxxx, 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.
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.
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.
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) que se encuentra en el repositorio de documentos firmados.
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).
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.
Análisis/Construcción:
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.
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.
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.
Definir el Diagrama de Actores del Sistema de Información (servicios y componentes) incluyendo la Matriz de Perfiles y Accesos (ver Anexo N°02).
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.
Definir casos de pruebas para certificación de los servicios y componentes desarrollados, con la participación de la OTI y DSEACE.
Programación
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).
Generar código fuente de los servicios y aplicación adecuadamente utilizando IDE Eclipse.
Versionar código fuente (repositorio GIT) incluyendo configuración y manejo de dependencias (usando Maven), comentando las principales actividades.
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 .
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.
Pruebas
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.
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 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.
Pase a producción
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.
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.
Transferencia de conocimientos
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)
Capacitación teórica - práctica al equipo de OTI, DSEACE y/u otras áreas usuarias.
Entrega de la documentación desarrollada en el proyecto (tanto en formato word como en formato original. Ejm: diagramas, otros).
Realizar el acompañamiento técnico durante el proceso de transferencia, configuración, instalación e implementación del proyecto.
Transferencia de servicios y componentes
Código fuente de los servicios y componentes adecuadamente comentando y versionado.
-
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.
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.
-
Participar de la reunión inicial del proyecto (kick-off) (ref. inciso 3.2.1)
Transferencia de servicios y componentes (ref. inciso 3.2.8)
Reuniones semanales para establecimiento de objetivos y revisión de avances (sprint o hitos específicos) de los productos solicitados.
Reuniones semanales en compañía del equipo BID, OTI y/o área usuaria.
Presentación preliminar de la solución antes de realizar la presentación final del producto.
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
Plan de trabajo / cronograma de actividades.
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) 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.
Máximo 15 días calendario, contados desde el día hábil siguiente de la suscripción del contrato respectivo
20%
Segundo
Entregable
Desarrollo de funcionalidades solicitadas (ref. inciso 3.2.4):
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).
Integración de código fuente en el repositorio del proyecto (código adecuadamente documentado/ comentado).
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
Desarrollo de funcionalidades solicitadas (ref. inciso 3.2.4):
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)
Integración de código fuente en el repositorio del proyecto (código adecuadamente documentado/ comentado).
Transferencia de conocimientos (ref. inciso 3.2.7).
Transferencia de servicios y componentes (ref. inciso 3.2.8).
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
Pruebas (ref. inciso 3.2.5).
Actas de aceptación de las pruebas funcionales.
Informe Final.
A los 90 días calendario, contados desde el día siguiente de vencido el plazo de servicio del tercer entregable.
10%
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.
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.
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.
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.
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.
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).
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 XXXX.
Xxxxx 00: Formato de especificación del caso de uso
Anexo 02: Diagrama de Actores
Anexo 03: Diseño del Sistema de Información