PLIEGO DE PRESCRIPCIONES TÉCNICAS ÍNDICE 1. OBJETO ANTECEDENTES Y SITUACIÓN ACTUAL... 2

Transcripción

1 PROCEDIMIENTO NEGOCIADO SIN PUBLICIDAD PARA LA ADJUDICACIÓN DEL CONTRATO DE SERVICIOS PARA EL DESARROLLO DE COMPONENTES PARA LAS APLICACIONES DE ADMINISTRACIÓN ELECTRÓNICA DEL SENADO PLIEGO DE PRESCRIPCIONES TÉCNICAS ÍNDICE 1. OBJETO ANTECEDENTES Y SITUACIÓN ACTUAL DETALLE DE LOS SERVICIOS QUE SE REQUIEREN COMPONENTE DE DIGITALIZACIÓN CERTIFICADA COMPONENTE DE COPIAS AUTÉNTICAS EN PAPEL Y JUSTIFICANTES DE FIRMA ELECTRÓNICA CON CÓDIGO SEGURO DE VERIFICACIÓN APLICACIÓN DE PRUEBA FORMACIÓN Y DOCUMENTACIÓN EQUIPO DE TRABAJO LUGAR Y PLAZO DE EJECUCIÓN ENTREGA Y CESIÓN DEL DERECHO DE EXPLOTACIÓN DE LA PROPIEDAD INTELECTUAL GARANTÍA, SOPORTE Y MANTENIMIENTO PLAN DEL PROYECTO Y PLAZO DE REALIZACIÓN... 9

2 1. OBJETO El objeto del presente procedimiento es la contratación del proyecto de desarrollo de diversos componentes para las aplicaciones de administración electrónica del Senado, entre los que se incluye uno de digitalización certificada, otro de copia auténtica en papel y justificantes de firma electrónica con código seguro de verificación, así como una aplicación de prueba que los utilice, de conformidad con lo que se contempla en este pliego. 2. ANTECEDENTES Y SITUACIÓN ACTUAL En la actualidad el Senado dispone de diversos componentes internos para el desarrollo de aplicaciones relacionadas con la gestión documental electrónica, entre los que se incluye uno para la firma electrónica y otro para la gestión del repositorio documental. Algunos de estos componentes son adaptaciones específicas para el Senado de plataformas desarrolladas por la Administración General del Estado o InSide), y disponibles a través del Centro de Transferencia de Tecnología del Ministerio de Hacienda y Administraciones Públicas (en adelante MINHAP). En este contexto, y con el objetivo de continuar con la evolución del Senado hacia una gestión de procedimientos electrónicos, se precisa completar los módulos existentes con otros que permitan algunas funcionalidades todavía no disponibles. 3. DETALLE DE LOS SERVICIOS QUE SE REQUIEREN Se requiere el desarrollo de una serie de componentes relacionados con la gestión documental electrónica, descritos en los apartados siguientes. Si se estima conveniente, no será necesario desarrollar desde cero alguno de ellos ya que existen proyectos abiertos por otras administraciones que pueden ser reutilizados adaptándolos a las necesidades concretas del Senado, como los disponibles en la Forja del Centro de Transferencia de Tecnología del MINHAP. La entrega deberá incluir el código fuente de todos los módulos y adaptaciones desarrollados por el contratista. No será necesario incluir el código fuente de las librerías o productos de terceros utilizados como base para el desarrollo. 2

3 3.1 COMPONENTE DE DIGITALIZACIÓN CERTIFICADA Este componente permitirá la digitalización certificada de documentos en papel, de forma que los documentos digitalizados tengan validez jurídica. Para ello, deberá cumplir con los siguientes requisitos: 1) Capacidad de integración del componente dentro de las diversas aplicaciones del Senado que requieran funcionalidades de digitalización. 2) Integración con escáneres que cumplan los estándares de mercado para la digitalización de documentos (TWAIN, SANE, WIA o similar). Como requisito mínimo, deberá funcionar con los escáneres disponibles actualmente en el Senado (se facilitará la información de los modelos concretos al inicio del proyecto). 3) Posibilidad de guardar los documentos en local, o subirlos a la aplicación para su inserción en el repositorio documental u otros repositorios. 4) La aplicación que integra el componente podrá decidir si los ficheros escaneados que se envían al servidor se almacenan en el repositorio documental del Senado, o en otros medios que implemente la propia aplicación (BLOBs, FileSystem, etc.). Para la inserción en el repositorio documental se deberá integrar con los servicios web de gestión documental del Senado, basados en la plataforma InSide del MINHAP. 5) El sistema dispondrá de un procedimiento de comprobación de la integridad del fichero, que validará que el fichero digitalizado está correctamente creado, no habiendo sufrido ningún problema durante el proceso de escaneado o almacenamiento. Este procedimiento podrá activarse opcionalmente y realizará la comprobación de que el fichero no está corrupto una vez cerrado el fichero y habiendo finalizado su almacenamiento. 6) Posibilidad de guardar el fichero en diversos formatos, como mínimo se incluirán los formatos PDF/A, TIFF 6.0 y JPEG ) Permitir la firma del fichero PDF/A en cliente con un certificado del usuario de la aplicación (insertado en un lector de tarjetas de su PC o configurado en su navegador), o la firma en servidor con un sello de órgano del Senado. Para ello se deberá integrar con los servicios web de firma del Senado, basados en la Se proporcionará el descriptor Web Services Description Language (en adelante WSDL). 8) La selección de los formatos y la política de firma deben ser configurables, y deberán permitir de manera opcional el sellado de tiempo para la firma. 9) Permitir la inclusión de ciertos metadatos (configurables por el programador que integra el componente) en el documento antes de insertarlo en el repositorio documental como los relativos a escaneo, serie documental, expediente electrónico, etc. 10) Múltiples posibilidades de configuración por parte del desarrollador que integra el componente en su aplicación: 3

4 o Se deberá poder configurar si se desean mostrar al usuario ciertos tipos de documentos a digitalizar (ej.: documento administrativo en blanco y negro, imagen en color, etc.) y en función del tipo elegido seleccionar automáticamente las opciones de escaneado como la resolución, color o blanco y negro, profundidad de bits, formato de salida, posibilidades de firma, metadatos, etc. Estos tipos de documento así como sus opciones de escaneado asociadas podrán variar en función de la aplicación que integre el componente. o Para cada tipo de documento, posibilidad de configurar el tipo de firma que se requiere, y si esta es opcional u obligatoria. o Posibilidad de configurar un número máximo de páginas por documento escaneado para establecer un tamaño máximo de archivo. o Posibilidad de configurar todas las variables que puedan depender del entorno donde se encuentre desplegada la aplicación (entorno de desarrollo, preproducción, producción, etc.). 11) División del componente en dos módulos técnicos: un módulo cliente que interaccione con el escáner y que se ejecute en el navegador, y un módulo que se ejecute en el servidor y que interaccione con los servicios web del Senado. 12) El módulo técnico de cliente deberá funcionar como mínimo en los siguientes navegadores estándar de mercado: o Microsoft Internet Explorer 9 y posteriores. o Google Chrome 30 y posteriores. o Firefox 30 y posteriores. o Safari 7 y posteriores. 13) El módulo técnico de servidor deberá estar escrito en lenguaje Java, se entregará su código fuente, y deberá funcionar como mínimo en los siguientes servidores de aplicaciones y máquinas virtuales Java: o Oracle Weblogic sobre JVM IBM J9 VM. o Apache Tomcat sobre JVM Oracle 1.6.0_ COMPONENTE DE COPIAS AUTÉNTICAS EN PAPEL Y JUSTIFICANTES DE FIRMA ELECTRÓNICA CON CÓDIGO SEGURO DE VERIFICACIÓN Permitirá la generación de justificantes de firma electrónica o copias auténticas en papel de documentos electrónicos, utilizando un código seguro de verificación. Para ello, deberá cumplir con los siguientes requisitos: 1) Exponer su funcionalidad en forma de servicios web para poder ser utilizado con cualquier aplicación que invoque dichos servicios. 2) Incluir un módulo de código seguro de verificación que permita: o Generar un código seguro de verificación para un documento electrónico firmado. 4

5 o Consultar la autenticidad de un documento firmado a partir de su código seguro de verificación. 3) A partir de una firma o de una validación con la plataforma de firma del Senado (basada el sistema deberá generar un documento PDF/A que pueda ser configurable en función de la aplicación que integre el componente, y que podrá ser: o Un informe o justificante de firma. o Una copia en papel de documento electrónico, utilizando un código seguro de verificación generado con el módulo indicado anteriormente. La ubicación dentro del documento de la información de firma y el código seguro de verificación deberá ser configurable en función del tipo de documento. 3.3 APLICACIÓN DE PRUEBA Esta aplicación mostrará con un ejemplo práctico el uso de los componentes desarrollados. Para ello, desde la aplicación el usuario podrá elegir entre cuatro opciones: 1) Escanear un nuevo documento: Se mostrarán al usuario diversos tipos de documento a escanear, para que el usuario elija entre uno de ellos (aunque la aplicación sólo muestre estos tipos, el componente deberá ser genérico y permitirá definir cualquier tipo personalizado): o Documento administrativo externo: - Color: Escala de grises. - Resolución: 300 ppp. - Profundidad: 8 bits. - Formato: PDF/A. - Almacenado: Servidor (Repositorio Documental). - Firma: Servidor obligatoria. - Metadatos: Metadatos de escaneado (resolución, etc.) + Id Serie Documental + Id Procedimiento + Número de Expediente + Número de Registro. o Documento administrativo interno: - Color: Blanco y Negro. - Resolución: 200 ppp. - Profundidad: 1 bit. - Formato: PDF/A. - Almacenado: Servidor (Repositorio Documental). - Firma: Cliente obligatoria. - Metadatos: Metadatos de escaneado (resolución, etc.) + Id Serie Documental + Id Procedimiento + Número de Expediente. o Libro sin valor histórico: - Color: color. 5

6 - Resolución: 300 ppp. - Profundidad: 24 bits. - Formato: JPEG 2000 o superior. - Almacenado: Servidor (FileSystem). - Firma: No. - Metadatos: Metadatos de escaneado (resolución, etc.). o Libro con valor histórico: - Color: color. - Resolución: 400 ppp. - Profundidad: 24 bits. - Formato: TIFF 6.0 o superior. - Almacenado: Local. - Firma: Cliente opcional. - Metadatos: Metadatos de escaneado (resolución, etc.). Una vez elegido el tipo, se escaneará un documento con las opciones asociadas a dicho tipo (el documento podrá contener múltiples páginas). Si el documento se almacena en el repositorio documental, se deberá mostrar un identificador asociado a éste, para poder recuperarlo posteriormente. 2) Recuperar un documento previamente escaneado y almacenado en el repositorio documental: Dado el identificador de un documento, la aplicación permitirá elegir entre las siguientes opciones: o Obtener el documento original sin modificaciones. o Obtener un informe o justificante de firma. o Obtener una copia auténtica en papel del documento escaneado, que incluya de manera visible los datos de la firma y un código seguro de verificación. 3) Validar la autenticidad de un documento: a partir de un código seguro de verificación, la aplicación permitirá validar la autenticidad de una copia impresa de un documento. 4) Ejecutar el procedimiento de comprobación de la integridad del documento. Una vez finalizada la comprobación se informará al usuario de su resultado y se mostrará en pantalla el documento, solicitando al usuario que verifique que el fichero mostrado es correcto. La aplicación deberá estar escrita en lenguaje Java, se entregará su código fuente, y deberá funcionar como mínimo en los siguientes servidores de aplicaciones y máquinas virtuales Java: 1) Oracle Weblogic sobre JVM IBM J9 VM. 2) Apache Tomcat sobre JVM Oracle 1.6.0_29. 6

7 La integración de la aplicación para la invocación a los distintos servicios web deberá encapsularse en librerías independientes para cada servicio que puedan ser reutilizadas por otras aplicaciones: 1) Librería cliente para servicios web de gestión documental. 2) Librería cliente para servicios web de firma. 3) Librería cliente para servicios web de código seguro de verificación. 4) Librería cliente para servicios web de justificantes de firma y copia auténtica. 5) Otras librerías que se consideren oportunas. Se valorará el que la aplicación esté desarrollada con las tecnologías JavaServer Faces (preferiblemente librería Richfaces), Spring, Hibernate y Maven. Si el contratista lo considera conveniente, el desarrollo podrá utilizar como punto de partida una plantilla de Maven proporcionada por el Senado que contenga las versiones de las librerías utilizadas. 3.4 FORMACIÓN Y DOCUMENTACIÓN A la terminación de los trabajos, o durante el trascurso de los mismos si se considera necesario, se entregará toda la documentación que permita comprender la naturaleza del trabajo realizado, lo que incluirá la documentación técnica detallada de cada uno de los módulos del sistema. Asimismo, se realizará la transferencia de conocimientos mediante consultoría presencial en el Senado que permita a los técnicos de la Cámara disponer de los componentes en funcionamiento permanentemente. La oferta debe incluir, y será objeto de valoración, los servicios necesarios para probar adecuadamente los módulos desarrollados así como para transmitir al personal técnico del Senado todos los detalles de los trabajos realizados. Se deberá especificar el número de jornadas que se dedicarán a estas tareas. 4. EQUIPO DE TRABAJO Los licitadores detallarán en sus ofertas el equipo de trabajo propuesto para la adecuada realización de los trabajos requeridos. A tal efecto, deberán detallar los técnicos que se propongan (iniciales de nombre y dos apellidos), su cualificación y certificaciones, así como su experiencia, que será objeto de valoración, en metodologías y herramientas empleadas, y en proyectos de administración electrónica, gestión documental, y desarrollo de componentes relacionados con la digitalización certificada de documentos y el código seguro de verificación. 7

8 El contratista no podrá modificar la composición del equipo de trabajo inicialmente propuesto en su proposición técnica salvo con el consentimiento expreso del Senado o fuerza mayor. En caso de sustitución de personal, los nuevos integrantes del equipo deberán disponer de un perfil de cualificación técnica igual o superior a la de los técnicos inicialmente propuestos. 5. LUGAR Y PLAZO DE EJECUCIÓN La toma inicial de requisitos y la instalación y pruebas en los entornos de desarrollo y producción deberán realizarse en las instalaciones del Senado. Adicionalmente, se valorará que el desarrollo de los componentes se realice en las instalaciones del Senado, aunque también podrá realizarse en las del contratista, debiéndose especificar en la propuesta la opción elegida. El plazo de ejecución será de seis meses, como máximo, a partir de la fecha de formalización del contrato. 6. ENTREGA Y CESIÓN DEL DERECHO DE EXPLOTACIÓN DE LA PROPIEDAD INTELECTUAL A la terminación de los trabajos el contratista deberá entregar el código fuente de todos los módulos desarrollados y adaptaciones realizadas, así como todas las librerías con las que se haya construido el sistema, que deberán estar libres de derechos de uso para este fin, lo que el contratista declarará en documento firmado. El contratista cederá en exclusiva, sin ninguna limitación de uso o disposición y a perpetuidad el uso de los derechos de explotación del software a favor del Senado, tanto del código fuente desarrollado como de las adaptaciones realizadas. 7. GARANTÍA, SOPORTE Y MANTENIMIENTO El contratista se compromete a colaborar con los técnicos del Senado para la puesta en marcha de los componentes entregados en los entornos de desarrollo y producción de las instalaciones del Senado, así como la integración entre todos ellos. Los trabajos realizados deberán contar con una garantía de al menos un año, a contar desde la recepción de los mismos, durante el cual el contratista se compromete a realizar sin coste alguno las subsanaciones de los errores que se detecten en los programas objeto del contrato. Los licitadores deberán incluir en sus propuestas las características del soporte que, en caso necesario, se comprometen a prestar durante el periodo de garantía (recepción de incidencias, tiempos de respuesta y resolución, etc.). Se valorarán las condiciones de garantía, soporte y mantenimiento ofrecidas por los licitadores. 8

9 8. PLAN DEL PROYECTO Y PLAZO DE REALIZACIÓN Los licitadores deberán entregar un Plan del proyecto que será objeto de valoración, con especificación de la solución ofrecida, las tareas que se han de realizar y la planificación detallada de las fases del proyecto, incluida la puesta en marcha en las instalaciones del Senado y la formación necesaria para su personal técnico. 9