PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA … · 3.1. Detalle de las soluciones de Administración...

PLIEGO DE PRESCRIPCIONES TÉCNICAS

PARA LA CONTRATACIÓN DEL SERVICIO DE

IMPLANTACIÓN DE VARIAS SOLUCIONES DE ADMINISTRACIÓN ELECTRÓNICA EN EL

AYUNTAMIENTO DE CASTELLÓN DE LA PLANA

1. Introducción

2. Objeto del contrato

3. Requerimientos Específicos

3.1 Detalle de las soluciones de Administración Electrónica incluidas en el alcance del proyecto.

3.2 Principios Generales de la Solución Propuesta

3.3 Requerimientos Funcionales del Proyecto

3.3.1. Parametrización general

3.3.2. Administración.

3.3.3. Firma electrónica.

3.3.4. Lógica de negocio

3.3.5. Interfaz de usuario

3.3.6. Datos – Carga de contenidos y Migraciones

3.3.7. Datos – Exportaciones y generación de datos

3.3.8. Datos – Integraciones

3.3.9. Personalización de los componentes implantados

3.4 Requerimientos Técnicos del Proyecto

3.4.1. Entorno de aplicación

3.4.2. Arquitectura de aplicación

3.4.3. Acceso a Aplicación

3.4.4. Navegadores

3.4.5. Rendimiento

3.4.6. Seguridad

3.4.7. Infraestructura

3.4.8. Disponibilidad

3.4.9. Datos

3.4.10. Mantenimiento

3.5 Requerimientos Jurídicos

3.6 Documentación

3.6.1. Documentación requerida en la oferta.

3.6.2. Entregables requeridos durante la ejecución del proyecto.

3.7 Formación

3.8 Metodología de gestión de proyecto.

3.9 Estructura del equipo de trabajo

3.10 Calendario del proyecto

4. Hitos del proyecto

5. Pruebas de aceptación

6. Mejoras

7. Plazo de ejecución del contrato

8. Importe Base de Licitación

9. Facturación

10. Garantía

11. Penalizaciones

12. Solvencia Técnica

13. Criterios de Valoración

13.1 Criterios de valoración objetivos.

13.2 Criterios de valoración subjetivos.

14. Condiciones Generales

14.1 Propiedad Intelectual

14.2 Transferencia Tecnológica

1. Introducción

La entrada en vigor de la Ley 11/2007, de 22 de Junio, de acceso electrónico de los ciudadanos a los Servicios Públicos, y la Ley 3/2010, de 5 de mayo, de Administración Electrónica de la Comunitat Valenciana supuso el reconocimiento del derecho de los ciudadanos a relacionarse electrónicamente con las Administraciones Públicas, así como la obligación de éstas a garantizar ese derecho. Ambas normativas suponen el marco en el que se ha basado el Ayuntamiento de Castellón de la Plana, junto con su Plan Marco de Modernización y Calidad de los servicios Municipales, para afrontar su proceso de modernización, convirtiéndose en un Ayuntamiento referente en materia de Administración Electrónica.

El presente pliego es un reflejo de la evolución que desea afrontar el Ayuntamiento de Castellón de la Plana, siguiendo las directrices marcadas en el Plan Marco de Modernización y Calidad de los servicios Municipales aprobado por el Pleno del Ayuntamiento y en su posterior desarrollo en el Plan Director de Administración Electrónica, en sus anualidades de 2012 a 2014.

Este contrato tiene como objetivo ejecutar las principales acciones identificadas en dicho Plan para los dos primeros ejercicios. Se trata de dos bloques complementarios, uno orientado a la implantación de una plataforma de Administración Electrónica orientada al ciudadano y otro que persigue el aumento de la eficiencia y calidad de los procesos internos a la vez que el ahorro de costes propiciado por su uso. Este segundo bloque incluye herramientas de tramitación electrónica de expedientes, entrada en registro de documentos con escaneado, distribución electrónica de documentación, firma electrónica y archivado electrónico.

Conscientes de la necesidad de maximizar el ahorro de costes, esta contratación va a valorar las propuestas que aporten cualquier tipo de ahorro presente y futuro, como por ejemplo, tal y como se indica en el apartado de mejoras, propuestas que maximicen la aportación de software sin coste de licenciamiento o propuestas que aporten reutilización de activos de software, procesos desarrollados colectivamente con otras administraciones públicas o propuestas que aporten beneficios tangibles e inmediatos a otras administraciones públicas que reutilicen los mismos componentes ofertados, como por ejemplo a la iniciativa “Tu Municipio en Red” liderada por la Generalitat Valenciana, Diputaciones de la Comunidad Valenciana y FVMP.

2. Objeto del contrato

El objeto del contrato es el servicio de instalación, configuración, puesta en marcha, mantenimiento y uso continuado durante la vigencia del contrato, de varias soluciones software en el ámbito de la administración electrónica.

Estos servicios en forma de consultoría, formación y software se deben ofrecer por el licitador en modalidad servicio de software SaaS (software as a service), incluyéndose en las propuestas el coste de todos los servicios necesarios para su implantación, utilización, funcionamiento, mantenimiento y uso en todos sus ámbitos. Las propuestas se deberán presentar preferiblemente considerando que la infraestructura hardware necesaria para facilitar el servicio se ubicará en las instalaciones del CPD del Ayuntamiento de Castellón, aunque el proveedor del servicio la facilitará, instalará, mantendrá, operará, y será de su propiedad.

Los componentes o módulos funcionales que estos servicios deben incluir se detallan en numerosos requisitos especificados en el apartado siguiente.

Por supuesto, este contrato tiene también como objetivo el cumplimiento de los requerimientos y funcionalidades definidos para el proyecto al amparo de las leyes 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos y 3/2010, de 5 de mayo, de la Generalitat, de Administración Electrónica de la Comunitat Valenciana, y la Ordenanza Municipal de Administración Electrónica de este ayuntamiento, siempre desde un punto de vista lo más coordinado posible con el resto de Administraciones Públicas.

Se deberán garantizar además las configuraciones añadidas necesarias para integrar todos los componentes objeto de este contrato, así como la integración con las soluciones actuales del Ayuntamiento y la continuidad del servicio implantado.

Adicionalmente, se incluye como parte objeto del contrato todos aquellos trabajos relativos a la asistencia y el soporte de la solución propuesta, y en general todas aquellas tareas que aseguren el éxito de su implantación.

3. Requerimientos Específicos

A continuación se detalla el alcance del proyecto y los requerimientos de alto y bajo nivel que éste debe cumplir.

3.1. Detalle de las soluciones de Administración Electrónica incluidas en el alcance del proyecto

Las acciones identificadas en el Plan Director de Administración Electrónica del Ayuntamiento de Castellón de la Plana que plantean la puesta en marcha de distintas soluciones, incluyen tanto aspectos técnicos como organizativos. El alcance de este proyecto incluye varias de estas acciones del Plan Director, concretamente, la puesta en funcionamiento, integración y parametrización de los módulos funcionales de administración electrónica indicados a continuación. Los módulos o bloques principales son CIUDADANO, TRAMITADOR, FIRMA y REGISTRO, y cada uno de ellos se componen de otros submódulos o componentes. Son los siguientes:

• Módulo CIUDADANO - Portal Ciudadanía: donde se ofrecerá de forma pública el catálogo de trámites disponibles, tanto electrónicos como presenciales, incorporando toda la información de instancias, plazos, descripción de la tramitación, etc. Este componente contempla un área privada (Carpeta Ciudadana) donde, mediante certificado digital reconocido se podrán realizar trámites con la organización y consultar el estado de los mismos.

• Módulo CIUDADANO - Catálogo de Trámites: como componente utilizado tanto por la sede como por el tramitador y que albergará la colección completa de los trámites ofrecidos a la ciudadanía.

• Módulo CIUDADANO - Componentes accesorios integrados con el Portal de la Ciudadanía y con el tramitador de expedientes electrónico: al menos, gestor de notificaciones electrónicas, gestión de la representación de ciudadanos y empresas, gestión de pagos mediante pasarela;

• Módulo CIUDADANO - Bus de Integración SOA para interoperabilidad: como sistema de soporte principal para garantizar la interoperabilidad e integración entre todos los componentes del sistema objeto de este proyecto así como con el resto de componentes existentes del ayuntamiento a integrar (backoffice y otros).

• Módulo TRAMITADOR - Gestor de tramitación electrónica de expedientes para el funcionario que permita realizar una completa gestión del ciclo de vida del expediente en todas su fases y sea cual sea su tipo (expediente papel, o mixto).

• Módulo TRAMITADOR - Gestión de órganos de gobierno. Este componente incluirá la gestión de estos órganos, tanto unipersonales como colegiados, así como la gestión de sus resoluciones y libros

electrónicos de estas.

• Módulo FIRMA - Portafirmas, que permita funcionalidades de bandeja de documentos a firmar, consulta de documentos firmados, implementación de circuitos de firma, implementación de firma desatendida, gestión de delegaciones y sustituciones.

• Módulo FIRMA – Componente de firma. Incluye el applet y los servicios necesarios para efectuar la firma electrónica de documentos, que se ofrecerá de forma desacoplada y que obligatoriamente utilizarán en el resto de módulos y componentes del proyecto.

• Módulo REGISTRO - Registro Presencial y Electrónico: se implantará una solución de registro presencial y electrónico de entrada/salida, con el objeto de constatar y guardar constancia de las solicitudes de los interesados y las respuestas de la administración. Este módulo debe incluir necesariamente funcionalidades de escaneo y digitalización certificada de documentos con sello de órgano. La solución de Registro ofertada deberá integrarse y garantizar su funcionamiento como un registro unificado que contemple tanto las funcionalidades del registro electrónico como las del registro presencial, garantizando la concurrencia, numeración única y consolidación de apuntes. La solución de registro electrónico deberá cumplir los requerimientos específicos del registro electrónico especificados en la Ordenanza reguladora de Administración Electrónica del Ayuntamiento de Castellón de la Plana.

• Componente transversal a todos los Módulos - Gestión documental y archivo electrónico: las soluciones a implantar deberán integrarse con la solución actual de Gestor Documental y Archivo Electrónico Longevo municipal tanto para los expedientes vivos como para los archivados o, en su defecto, incluir en el alcance ofertado una alternativa mejorada de la actual que plantee la sustitución de los sistemas actuales de gestión documental y archivo electrónico con plena funcionalidad.

Aunque quedan fuera del alcance del proyecto los costes futuros previstos durante toda la vida útil de las soluciones ofertadas, estos deben valorarse económicamente en la oferta. Se entiende por costes futuros previstos durante toda la vida útil de las soluciones ofertadas, los costes que no se incluyen en el alcance de la oferta presentada y que se refieren a costes de utilización, mantenimiento correctivo y adaptativo (tanto debido a cambios legislativos como de evolución de versión del software relacionado con el proyecto), y soporte técnico del servicio, así como de cualquier mantenimiento o inversión en licencias de software complementario, todos ellos necesarios, a juicio del licitador, para garantizar la operatividad, estabilidad y buen

funcionamiento de las soluciones tecnológicas ofertadas así como para la óptima consecución y rentabilización de estas soluciones. Dado que se estima segura la necesidad de mantenimientos evolutivos del servicio, se incluirá necesariamente en esta valoración una bolsa de horas para soporte y/o evolutivos de al menos 200 horas anuales a partir del momento de finalización del proyecto. Esta valoración económica tiene por objeto poder conocer la estimación de costes de mantenimiento en toda su vida útil prevista.

3.2. Principios Generales de la Solución Propuesta

A continuación se enumeran algunos de los principios generales de especial relevancia para la solución objeto de este contrato y que rigen el desarrollo de la Administración Electrónica en el ámbito del Ayuntamiento de Castellón de la Plana, de conformidad a lo establecido en la Ley 11/2007 de acceso electrónico de los ciudadanos a los Servicios Públicos, la Ley 3/2010 de Administración Electrónica de la Comunitat Valenciana y la Ordenanza reguladora de la Administración Electrónica del Ayuntamiento de Castellón de la Plana.

La solución propuesta se regirá por estos principios generales.

i.Flexibilidad y Modularidad: se exige que el sistema se adapte a los distintos escenarios que puedan darse en el Ayuntamiento de Castellón de la Plana en función de su tamaño y grado de madurez tecnológica así como la posibilidad de futuras implantaciones no completas.

ii.Reutilización de Componentes: se valorará como mejora la oferta de un entorno que aporte una alta la reutilización de componentes ya existentes, propios de otros organismos públicos o existentes en el mercado, con el fin de dotar de mayor valor a la solución implantada, basándose en la aplicación de mejores prácticas.

iii.No Intrusión: la Solución de Administración Electrónica permitirá la coexistencia con sistemas y/o componentes preexistentes en el Ayuntamiento.

iv.Integración e Interoperabilidad: el sistema debe estar diseñado técnica y funcionalmente con el fin de garantizar la interoperabilidad con los distintos niveles de administración existentes en el Ayuntamiento. El sistema estará adaptado para garantizar la cooperación en la utilización de medios electrónicos por otras Administraciones Públicas, así como para garantizar la interoperabilidad de los sistemas y soluciones y la

prestación conjunta de servicios.

v.Neutralidad tecnológica: deberá garantizarse la independencia de los medios tecnológicos utilizados, siendo la propia evolución tecnológica la que determinará el uso, en cada momento, del medio tecnológico más adecuado.

3.3. Requerimientos funcionales del Proyecto

A continuación se enumeran y describen los requerimientos funcionales, técnicos, jurídicos, documentales, formativos, organizativos, metodológicos y temporales que deberán cumplir cada uno de los módulos y componentes del proyecto. Asimismo el licitador podrá incluir cualquier mejora que desee. Las mejoras que serán valoradas de acuerdo con lo establecido en el apartado de mejoras de los criterios de valoración. El licitador deberá incluir cualquier otro elemento y funcionalidad no descritos en los requerimientos siguientes y que sean necesarios para la correcta comprensión y el correcto funcionamiento del conjunto.

3.3.1. Parametrización general.

Requerimientos aplicables a TODOS los módulos:

• Solución multi-idioma. Todos los componentes de la solución propuesta deberán contemplar como mínimo las dos lenguas oficiales de la Comunitat Valenciana para todo el contenido tanto interno como externo, además de estar preparado para incluir adicionalmente aquellos idiomas que se consideren necesarios. Se incluye parametrización completa inicial en Castellano y Valenciano.

• Solución multi-entidad/institución y multi-sede. Todos los componentes de la solución propuesta deberán contemplar como mínimo dos instituciones y dos sedes, además de estar preparado para incluir tantas sedes e instituciones como se consideren necesarias. Se incluye parametrización completa inicial para 2 instituciones/entidades y 2 sedes que el Ayuntamiento indicará.

• Los sistemas y aplicaciones implicados en los servicios electrónicos se sincronizarán con la hora oficial (ROA).

3.3.2. Administración.


• Se proporcionarán herramientas gráficas de usuario para la

completa gestión y administración del sistema, incluyendo entre otros control de usuarios, perfiles, roles, grupos de usuarios, permisos y accesos, definición de formularios, mantenimiento de todos los parámetros configurable, etc. Estas herramientas serán de uso sencillo y permitirán la autonomía por parte de la organización en el diseño, creación, actualización y organización de todos los componentes y servicios incluidos en todos los módulos (Sede Electrónica, Portal Ciudadanía/Oficina Virtual, Catálogo de Trámites, componentes accesorios, Tramitador, Gestor de Órganos de Gobierno, Registro, etc). Estas herramientas darán una completa flexibilidad de perfiles y roles para contemplar toda la casuística necesaria a nivel de usuario y a nivel de administración.

Requerimientos aplicables al módulo CIUDADANO :

• El sistema dispondrá de una herramienta de usuario para la generación de formularios que permita la definición, diseño y modificación de formularios de tramitación de forma autónoma y con una mínima o, idealmente nula, necesidad de programación o conocimientos técnicos.

• En la tramitación o posterior aportación de documentación, se permitirá anexar documentos en distintos formatos, inicialmente, entre otros, PDF, CAD, DOC, ODT, etc. Este abanico de formatos aceptados será parametrizable por el usuario administrador.

3.3.3. Firma electrónica.


• Todos los módulos y componentes de este contrato que requieran el uso de autenticación, validación de certificado electrónico y firma electrónica de formularios y documentos deben integrarse con los componentes ejecutados en el módulo de FIRMA de este contrato.

• El sistema admitirá la identificación y autenticación de usuarios a los servicios mediante usuario y contraseña, cuando así lo permita el administrador, o mediante los certificados digitales e-DNI y los sistemas de firma electrónica de ACCV y Camerfirma, tanto para certificados de ciudadano o empresa como para empleado público.

Requerimientos aplicables a módulo FIRMA y, por extensión, a TODOS los módulos que usen los componentes de firma.

• El sistema debe incluir la funcionalidad de bandeja de documentos a firmar y consulta de documentos firmados por cada usuario.

• El sistema debe incluir funcionalidad para permitir implementar circuitos de firma secuenciales que contemplen firma por funcionario y/o firma desatendida de uno o varios documentos. Estos circuitos de firma se podrán definir por tipología de circuito o expediente, permitiendo en cada caso definir el workflow de firmantes y los roles de firmantes para cada tipo de documento. Esta definición y parametrización de circuitos de firma deberá poder realizarse de forma intuitiva y sin necesidad de codificación por software.

• El sistema debe incluir funcionalidad configurable por el administrador la gestión de delegaciones y sustituciones de firmantes, permitiendo, en el mejor de los casos, configurar delegaciones en base a información parametrizada complementaria e integrada con la relación de puestos de trabajo (RPT) municipal así como configurar sustituciones de forma planificada y sustituciones imprevistas, que tendrán que redefinir el firmante de documentos que puedan incluso estár ya en la bandeja de portafirmas de documentos a firmar.

• El motor de firma incorporado en el sistema utilizará firmas electrónicas avanzadas y reconocidas, según requerimientos establecidos en la Ley 59/2003, de firma electrónica y en la Directiva Europea 1999/93/CE.

• El sistema debe admitir los sistemas de firma electrónica: eDNI y cualquier otro que sea de firma electrónica avanzada reconocidos al menos por las autoridades de certificación ACCV (Autoridad de Certificación de la Comunidad Valenciana) y Camerfirma, incluyendo el formato tanto software como usb o tarjeta criptográfica.

• Los certificados electrónicos reconocidos emitidos por otros prestadores de servicios de certificación serán admitidos como válidos, siempre y cuando el prestador de servicios de certificación ponga a disposición la información que sea precisa en condiciones que resulten tecnológicamente viables.

• Las herramientas ofertadas deberán tener capacidad de firmar digitalmente con un formato de firma que soporte firma de larga duración y garantice la posibilidad de resellado, permitiendo obtener documentos electrónicos con plenas garantías jurídicas de forma indefinida, según define el Instituto Europeo de Estandarización (ETSI) y la RFC 3126 Electronic Signature Formats for long term electronic signatures. El formato

seleccionado y el soporte a estas capacidades solicitadas deberán ser expresamente indicados en la oferta y argumentarse con claridad.

• Los documentos firmados por el funcionario se almacenarán en formato de firma que soporta larga duración. Si este formato soportara opciones, se deberá poder configurar por parametrización en el sistema en base a los datos que se indiquen (tamaño del fichero y otro datos).

• En cada acción de firma ejecutada por el usuario, el sistema permitirá la opción de generar copia auténtica en PDF con inclusión del código seguro de verificación (CSV).

• Los documentos enviados al exterior (ciudadania o entidad jurídica), y por tanto siempre registrados de salida, podrán implementarse en varios formatos, pero como mínimo siempre deberán suministrarse para su envío al ciudadano al menos en el formato PDF, y tendrán su origen en los documentos originales firmados (con formato de larga duración) o no firmados, previa generación e inclusión visual del correspondiente del código seguro de verificación (CSV) para el caso de documentos firmados en este Ayuntamiento.

• El sistema dispondrá de mecanismos que garantizarán que los documentos administrativos firmados electrónicamente incluirán referencia temporal (sellado de tiempo TSA), que se garantizará a través de medios electrónicos cuando la naturaleza del documento así lo requiera.

• El sistema deberá dar garantía de autenticidad e integridad de documentos electrónicos a través de código seguro de verificación (CSV).

• El sistema deberá incorporar CSV en todos los documentos generados para su envío al ciudadano, como por ejemplo certificado de empadronamiento o cualquier duplicado de recibo de una tasa o impuesto.

• El sistema dispondrá de un validador de documentos electrónicos emitidos por el Ayuntamiento y que incorporen código seguro de verificación (CSV). El proceso de validación solicitará al usuario la introducción de parte del CSV que incorpora el documento a validar y mostrará el documento original firmado electrónicamente que deberá estar almacenado, junto con su CSV que formará parte de los metadatos del documento, en el gestor documental del

municipal.

• El sistema debe permitir validar (con el código seguro de validación o CSV) aquellos documentos que hayan sido firmados electrónicamente con las plataformas municipales anteriores a este proyecto.

• El sistema debe implementar mecanismos que permitan actuaciones administrativas automatizadas mediante el empleo de firmas con sello de órgano, de forma que permita añadir trámites de expedición electrónica automatizada (sin intervención de persona física), entre otros, de certificados e informes que se expidan por cualquier aplicación del ayuntamiento. Esta automatización consiste al menos en firmar un documento mediante el sello de órgano deseado, posterior firma opcional del funcionario, aplicar opcionalmente código seguro de verificación (CSV) al documento firmado con el sello de órgano y su almacenamiento en el gestor documental municipal. Se debe suministrar una herramientas de uso sencillo que permita ampliar los trámites automatizados sin necesidad de codificación de nuevo software.

• El sistema será capaz de firmar cualquier tipo de archivo: Word, OpenOffice, Excel, TIFF, DXF, XML, HTML, etc, independientemente de que después administrativamente se parametricen y limiten los formatos que el ayuntamiento decida admitir.

• Se permitirá en aquellos procesos que así lo requieran la firma en segundo plano de lotes de documentos electrónicos, entendiendo por segundo plano que el sistema deje trabajar al usuario mientras realiza y controla la correcta ejecución de la firma de un lote de documentos.

• Se permitirá en aquellos procesos que así lo requieran la firma múltiple de varios documentos con una sola intervención del usuario para teclear el P.I.N. Se entiende que esta selección múltiple realizará la firma individual de cada uno de ellos.

3.3.4. Lógica de negocio

Requerimientos aplicables al módulo CIUDANDANO

• El catálogo de trámites será completo y mostrará toda la información necesaria para poder realizar la tramitación independientemente del canal que el ciudadano seleccione.

• El sistema permitirá mostrar la agrupación de trámites de su catálogo según la clasificación realizada por el usuario en distintas familias.

• El sistema aportará mecanismos para posibilitar el versionado de trámites, de forma que puedan coexistir distintas versiones de un mismo trámite y permitiendo definir la vigencia de publicación para su iniciación online o presencial para cada una de las versiones.

• El sistema debe dar solución a los distintos requisitos de documentación a aportar en función de la casuística de cada trámite.

• El sistema permitirá ofrecer al ciudadano 5 niveles de tramitación online, en función de la configuración de cada trámite, entendiendo como nivel 1, la mera publicación de información del trámite en el catálogo de la sede, nivel 2, la posibilidad de facilitar documentación y formularios descargables sobre este trámite, nivel 3, la posibilidad de iniciar el trámite online, nivel 4, la posibilidad de comunicar y notificar al cidadano avances o requerimientos sobre este trámite, y nivel 5 la completa gestión electrónica interna del trámite y el expediente asociado a la tramitación online iniciada.

• La sede electrónica permitirá al ciudadano iniciar tramitación electrónica de los tramites así configurados. Se deberá permitir iniciar estos temas con o sin certificado digital por parte del ciudadano, en función de la configuración del trámite.

• El sistema ofrecerá al ciudadano la posibilidad de interactuar sobre sus trámites, expedientes, tributos, etc mediante un servicio de acceso restringido que garantice la confidencialidad y seguridad de estos datos. Este acceso por parte del solicitante, se realizará a través de un espacio privado denominado Carpeta Ciudadana, mediante la cual el ciudadano podrá realizar la presentación y consulta de estado de sus trámites, historial de procedimientos, documentos aportados, registros de entrada y salida, recibos, autoliquidaciones y liquidaciones y notificaciones realizadas por la administración. El sistema permitirá obtener copias electrónicas de los documentos que formen parte de un procedimiento.

• El sistema garantizará al ciudadano el derecho a no aportar datos y documentos que ya obren en poder de la Administración. Para ello, ofrecerá facilidades que idealmente permitirán al ciudadano seleccionar los documentos que desee de entre los presentados

anteriormente, siempre disponibles para el usuario cuando desee aportar documentación, en cualquier fase de la tramitación o en cualquier otro trámite iniciado.

• El sistema garantizará al ciudadano el derecho al acceso al estado de la tramitación, tanto de los trámites iniciados telemáticamente como los presenciales.

• Un trámite debe poder ser presentado tanto por una persona física como por una persona jurídica.

• El sistema permitirá que el ciudadano efectué el pago de todas las modalidades de tramitación electrónica, es decir, cualquier trámite, autoliquidación o recibo de su carpeta a través de la pasarela de pago a implantar.

• El sistema de pasarela de pagos aportará facilidades de usuario para efectuar la consolidación de pagos electrónicos en la gestión tributaria municipal.

• El sistema ofrecerá posibilidad de envío de notificaciones electrónicas al solicitante, en caso de que así lo haya elegido el ciudadano. Se incluirá las funcionalidades de: adjuntar documentos en las notificaciones, enviar mensajes de texto SMS o correos electrónicos al solicitante, visualización del acuse antes de su firma y sellado de tiempo. Estas notificaciones telemáticas se generarán, si así lo elige el usuario, a partir de documentos registrados de salida.

• En caso de ser ofertado, el Perfil del Contratante estará soportado por un sistema que permita acreditar fehacientemente el momento de inicio y de final de la difusión pública de la información.

Requerimientos aplicables a los módulos CIUDADANO y TRAMITADOR.

• El sistema ofrecerá mecanismos para facilitar el control de plazos, fecha y hora e identificación de las personas.

• El sistema permitirá la presentación de un trámite aunque se encuentre fuera de plazo.

• El sistema permitirá realizar el avance y seguimiento de los trámites iniciados de forma telemática de manera que sea posible asociar los trámites/expedientes a un flujo de tramitación para permitir el avance de su estado de tramitación y dar visibilidad de ello al ciudadano; recoger y enviar documentos de/hacia el ciudadano; (comunicarse con el ciudadano) a través del

componente de comunicaciones/notificaciones;

• El sistema permitirá al ciudadano subsanar/alegar telemáticamente o presencialmente a un trámite ya iniciado, presentando opcionalmente documentación, se presente telemáticamente o presencialmente.

• El sistema permitirá al ciudadano continuar un procedimiento iniciado por un medio, por otro diferente, entendiendo por medio el canal utilizado: presencial, on-line/telemático o telefónico.

• Los documentos adjuntos a la solicitud, ya sean generados por el ciudadano o por la administración, deben cumplir los estándares especificados en los Esquemas Nacionales de Interoperabilidad y de Seguridad. En este sentido, los documentos que aporte el ciudadano deben estar catalogados con el conjunto mínimo de metadatos que marca el ENI (fecha de creación, autor, firmas y otros) y que se gestiona de acuerdo con las normas de seguridad (cifrado y privacidad), además de los que requiera el gestor documental o el gestor de archivo municipal.

• El sistema debe permitir la posibilidad de habilitar autorizaciones de representación de las personas habilitadas, tanto para empresas o ciudadanos en representación de otros ciudadanos como de funcionarios habilitados. Deberá gestionar las representaciones tanto por autorización expresa como a representación en base a convenios con terceras entidades que habilitan representación masiva de colectivos como colegios profesionales. El sistema deberá también permitir acreditación de la representación por distintos medios, presenciales o telemáticos.

• El sistema incluirá en la carpeta ciudadana la funcionalidad de expedición electrónica de los volantes de Empadronamiento haciendo uso del tratamiento automatizado con sello de órgano. Este volante de empadronamiento emitido con la expedición automatizada debe mostrar sólo los datos del interesado (individuales), y no de la unidad familiar o grupo de personas junto con las que se encuentra empadronado.

Requerimientos aplicables al módulo TRAMITADOR

• El tramitador debe ser un gestor de tramitación electrónica de expedientes para el funcionario debe permitir realizar una completa gestión del ciclo de vida del expediente en todas su fases y sea cual sea su tipo (expediente o papel, o mixto).

• Este tramitador debe contemplar necesariamente la implementación de gestión sin workflow predefinido y, por tanto, con libre envío de cualquier tarea o encargo sobre el expediente a cualquier usuario y, opcionalmente, permitirá la gestión del expediente con workflow predefinido, en el mejor de los casos, la implementación de procedimientos o tipos de expedientes mixtos, es decir, reglados por workflow parcialmente para cierto tipo de subprocesos.

• El tramitador, en caso de permitir implementación de procedimientos o subprocesos con workflow predefinido, deberá contemplar el versionado de procesos. Este versionado permitirá la coexistencia de expedientes vivos basados en una versión de workflow con otros basados en una versión distinta.

• El tramitador permitirá gestionar de parte o de oficio cualquier tipo de expediente.

• El sistema dispondrá de una herramienta de gestión de tramitaciones que permitirá al usuario/funcionario:

• gestionar trámites en todo su ciclo de vida, es decir, hasta el archivado del expediente, iniciados tanto telemáticamente como presencialmente;

• distribución de trámites iniciados a departamento destino;

• comunicación y envío al ciudadano de...

• avisos sobre el estado de su tramitación, vía correo electrónico o vía SMS, integrándose con la plataforma de envío de SMSs municipal;

• notificaciones electrónicas, a través de un sistema de notificación electrónica que permita realizar notificaciones fehacientes desde un expediente o por decisión propia del empleado público;

• documentación relacionada con su tramitación;

• actualizar el estado de su tramitación;

• El sistema permitirá al usuario/funcionario la gestión del inicio de cualquier tramitación presencial o telemática.

• La herramienta debe cumplir que:

• todas las tramitaciones se almacenarán en el repositorio

único que contendrá tanto las iniciadas presencialmente como las iniciadas telemáticamente;

• todos los trámites iniciados, de forma telemática o de forma presencial, estarán en un único repositorio accesible y consultable por los usuarios/funcionarios;

• todos los trámites iniciados, se distribuirán a destino con una única herramienta;

• todos los trámites se podrán gestionar de forma centralizada o descentralizada, por los departamentos gestores;

• la información utilizada para la atención ciudadana sea la misma que ve el ciudadano cuando efectúa la tramitación online, es decir, que el catálogo de trámites sea el mismo que en el componente de ciudadano en la sede electrónica;

• el funcionario pueda efectuar la tramitación ante el ciudadano de forma similar a como lo hace el ciudadano, previa identificación del ciudadano/tercero , de forma integrada con la base de datos de terceros municipal, y consulta de la carpeta del ciudadano/tercero para conocer todo su historial (tramites, expedientes, registros, documentos, etc), consulta o búsqueda del trámite a iniciar; en el mejor de los casos el funcionario podrá realizar el inicio y finalización del trámite, entregando al ciudadano acuse de recibo de presentación en el registro presencial con la respectiva firma y sello de tiempo digitales, y demás evidencias legales; terminado el inicio presencial del trámite, éste pasará a la bandeja de trámites iniciados que se encargará de atender el equipo correspondiente;

• el funcionario enumere (documentación digital o papel) o aporte (adjuntando en soporte digital) toda la documentación que presenta el ciudadano;

• el trámite se registre directamente en el registro presencial y se obtenga acuse de recibo para el ciudadano;

• el ciudadano pueda presentar digitalmente documentación de un trámite iniciado presencialmente, y viceversa.

• El tramitador permitirá gestionar las instancias, solicitudes o entradas por registro , integrando ambas gestiones (registro y tramitador), heredando por tanto toda la información de registro, documentación digitalizada incluida.

• El sistema pondrá a disposición del ayuntamiento las herramientas para implementar la actuación administrativa automatizada para los trámites que con el sistema actual se tratan de esta forma, que son: expedición electrónica de certificados de empadronamiento, expedición electrónica de certificado de bienes, expedición electrónica de informe de bienes, recibos acreditativos de la recepción de los documentos electrónicos presentados en el Registro Electrónico del Ayuntamiento con la respectiva firma y sello de tiempo digitales, y demás evidencias legales.

• Este módulo debe incluir la gestión de órganos de gobierno unipersonales y colegiados. Este componente incluirá la gestión de estos órganos, tanto unipersonales como colegiados, así como la gestión de sus resoluciones y libros electrónicos de estas. El módulo gestionará todo el ciclo de vida de las sesiones de órganos colegiados, como Junta de Gobierno y Pleno así como los circuitos de firma y aprobación de las resoluciones de éstos órganos y de los unipersonales, como los Decretos de Alcaldía . Esta componente debe estar integrada con el tramitador y debe permitir su gestión sin obligatoriedad de gestión íntegra de los expedientes afectados en el tramitador, es decir, se podrá gestionar cualquier resolución, convocatoria, orden del día, etc, de órganos de gobierno relacionados con expedientes que podrán estar o no gestionados en el tramitador.

Requerimientos aplicables al módulo REGISTRO

• El sistema estará dotado de un sistema de registro electrónico que permitirá enviar y/o recibir solicitudes, escritos, y comunicaciones de/hacia el ciudadano, indicando siempre al usuario/ciudadano fecha y hora de cualquier documento registrado.

• El sistema dará garantía de la fecha y hora oficial del Registro conforme a lo establecido en la Ley 11/2007 de acceso electrónico de los ciudadanos a los Servicios Públicos.

• La solución propuesta debe disponer de la capacidad para generar justificantes de apuntes registrales firmados electrónicamente y accesible por parte del solicitante.

• El sistema dará solución de registro presencial y electrónico de entrada/salida, con el objeto de constatar y guardar constancia de las solicitudes de los interesados y las respuestas de la administración.

• Este módulo debe incluir funcionalidades completas o

complementarias de escaneo y digitalización certificada de documentos con sello de órgano de la documentación aportada en la entrada de registro presencial.

La solución de Registro ofertada deberá integrarse con el resto de módulos y componentes detallados en este pliego, y garantizar su funcionamiento como un registro unificado que contemple tanto las funcionalidades del registro electrónico como las del registro presencial, garantizando la concurrencia, numeración única y consolidación de apuntes. La solución de escaneado debe permitir trabajar con escaneado al instante, en el momento de registrar con el ciudadano presente, así como escaneado en diferido, permitiendo un escaneado masivo que identifique automáticamente la separación entre distintos documentos e instancias/solicitudes. La oferta deberá definir con máximo detalle este procedimiento de escaneado.

• La solución de registro electrónico deberá cumplir los requerimientos específicos del registro electrónico especificados en la Ordenanza reguladora de Administración Electrónica del Ayuntamiento de Castellón de la Plana.

Requerimientos aplicables a TODOS los módulos

En relación a la gestión documental y archivo...

• Se realizarán todas las tareas necesarias para, o bien integrar el sistema con el Gestor Documental y Sistema de Archivo electrónico del Ayuntamiento, o bien ofertar un sistema que lo sustituya con plenas funcionalidades iguales o mayores que el sistema actual. En caso de integrar los sistemas ofertados con el actual sistema de archivo, el Ayuntamiento aportará los WebServices (WSs) que permitan enlazar con el gestor documental y Archivo del Ayuntamiento, para los diversos espacios documentales de gestión de expedientes y archivos activos, semi-activo e histórico. La ejecución del proyecto incluirá la revisión y adaptación de las estructuras de datos (metadatos) de documento y expediente a las definidas por la gestión documental y de archivo municipales, incorporando a su vez como propuesta -que el ayuntamiento deberá aceptar-, los metadatos y modificaciones necesarias para el cumplimiento de las normas técnicas que desarrollan el RD 4/2010 que regula el Esquema Nacional de Interoperabilidad (ENI).

• El sistema interactuará con el gestor documental y archivo

haciendo uso exclusivo de las colecciones de WSs citadas.

• El sistema garantizará...

• la conservación de los documentos que formen parte de un expediente;

• el almacenamiento de todos los documentos electrónicos utilizados en las actuaciones administrativas que gestiona;

• la integridad, autenticidad, confidencialidad, calidad, protección y conservación de los documentos;

• la incorporación de un mecanismo de identificación y acreditación en los documentos electrónicos que presenten los ciudadanos;

• la interoperabilidad en relación con la recuperación y conservación de los documentos electrónicos en su ciclo de vida;

• la adecuación de los metadatos a aquellos definidos en las normas técnicas del Esquema Nacional de Interoperabilidad;

3.3.5. Interfaz de usuario

• En relación al interface gráfico de de usuario, todas las aplicaciones que conforman la solución, a excepción de las de firma y consulta de documentos en movilidad, deben de funcionar en entorno navegador según restricciones indicadas en apartado posterior de [Requerimientos Técnicos – Arquitectura – Navegadores - e - Infraestructura].

• El interface gráfico de usuario deberá ser intuitivo, amigable, usable y claro. Se deberá aportar en la memoria de la documentación que acompaña la oferta dos ejemplos de prototipos de pantallas complejas que formarán parte de la solución ofertada con leyenda explicativa de los elementos de interacción con el usuario de estas pantallas.

3.3.6. Datos – Carga de contenidos y Migraciones

Los diferentes componentes que forman la solución ofertada deben proporcionar herramientas para la creación y actualización de contenidos. Del mismo modo, la solución debe garantizar la autonomía

por parte del Ayuntamiento de Castellón de la Plana sobre todas estas tareas. Así pues, se deberá facilitar herramientas de usuario que no requieran especialización técnica alguna para las tareas siguientes. De igual forma, se deberán realizar las siguientes tareas de carga y migración de datos.

Módulo CIUDADANO.

• Se deberá realizar la definición y carga de un catálogo inicial de trámites, tipos de trámites y formularios de solicitud para el Portal de la Ciudadanía. El proyecto incluye los trabajos de migración completa y detallada de todos los trámites del sistema actual, así como de su clasificación por los tipos de trámite y formularios de solicitud asociados. Así mismo, se ampliará la integración con el catálogo ampliado ofertado para aquellos trámites o clasificación que el Ayuntamiento indique.

TODOS los módulos

• Para todos los demás módulos de la plataforma tecnológica que sustituyan o amplíen aplicaciones que estén actualmente en explotación o uso en el Ayuntamiento, se deberá realizar la carga de datos inicial necesaria así como la migración entre dichos sistemas, siempre que el ayuntamiento facilite acceso a la información a migrar. El adjudicatario propondrá las adaptaciones necesarias sobre la información a migrar para que se cumplan los requerimientos del modelo de datos del nuevo sistema, pudiendo aportar distintas alternativas para el destino de los datos migrados. Entre otros, se realizarán al menos las cargas y migraciones siguientes:

• carga de los tramites y su clasificación del portal de ciudadano actual;

• carga o migración de todos los documentos (firmados y no firmados) y expedientes de ciudadanos del portal del ciudadano y carpeta actual;

• migración de todos los documentos (firmados y no firmados) y expedientes de contratación del sistema de tramitación actual;

• migración de decretos electrónicos gestionados por el sistema actual;

• carga o migración de circuitos de firma y todos los documentos (firmados y no firmados) asociados a cada circuito del sistema actual;

• migración de entradas y salidas del registro presencial y telemático actual;

3.3.7. Datos – Exportaciones y generación de datos

La solución propuesta debe generar de forma periódica, datos en forma de indicadores, que faciliten el seguimiento de uso de todos los servicios ofrecidos por el software disponible en el ámbito de todos los módulos del contrato. Se ofertará una propuesta de estos indicadores de seguimiento de uso que al menos incluya mediciones de calidad, tiempo y coste, y se asumirán los indicadores que durante la ejecución el proyecto el Ayuntamiento decida incorporar.

3.3.8. Datos – Integraciones

Cada uno de los servicios de la solución ofertada, deberán utilizar interfaces que permitan ofrecer y consumir funcionalidades entre los distintos componentes de todos los módulos que la forman. Esta infraestructura de comunicación entre componentes debe ser trasparente a la tecnología concreta sobre la que se han construido cada uno de estos componentes. Del mismo modo, esta filosofía, basada en soluciones SOA, se debe mantener en la integración con sistemas externos a la solución propuesta.

Todo producto o solución software que forme parte de la oferta, debe estar adaptada de forma íntegra a esta filosofía SOA y a los los requerimientos del bus de integración ofertado desde el momento inicial de su puesta en marcha.

Por ello, el proyecto incluye tanto la integración final vía webservice (WS) como, en una primera fase del proyecto, la integración con llamadas a procedimientos almacenados facilitados por el ayuntamiento, con los sistemas actuales y futuros dentro del presente ejercicio. Las integraciones a realizar son:

• las necesarias para implantar todos los componentes contratados en la totalidad de los módulos; el adjudicatario deberá aportar en la oferta las colecciones de WSs necesarias para su correcta integración con el resto de módulos y componentes;

• la solución de firma electrónica corporativa (portafirmas, applet de firma y otros módulos de firma), tanto en el ámbito de este o cualquier otro proyecto en curso;

• todos los componentes contratados con el repositorio documental y el archivo electrónico municipales, implementados actualmente

bajo Alfresco Community; en caso de que el adjudicatario oferte sustitución de estos sistemas de gestión documental y archivo, la integración se realizará con el nuevo producto.

• el tablón de edictos electrónico municipal (integración a nivel de presentación y búsquedas);

• el perfil del contratante municipal (integración a nivel de presentación y búsquedas);

• el Backoffice de gestión municipal actual para los datos de padrón, la gestión de terceros (alta/baja/modificación), el callejero municipal y la relación de puestos de trabajo para la estructura organizativa departamental; el modelo garantizará la permanente consistencia de los datos aun cuando los datos cambien, por ejemplo cuando la RPT cambie y un departamento se desdoble, fusione o elimine;

• el registro presencial y electrónico municipal actualmente en producción, así como la adaptación a la nueva aplicación municipal de registro incluida en este proyecto;

• el sistema de licitación electrónica de este ayuntamiento, cuya implantación está planificada en los próximos 12 meses en el ámbito de otro contrato y para la que se facilitará colección de webservices a utilizar;

• Plataforma municipal de envío de SMSs;

• GIS municipal, para georeferenciación, siempre que sea viable la propuesta de integración detallada por el Ayuntamiento;

• Otros subsistemas actualmente en la WEB municipal que permitan tramitación sin identificación con certificado digital pero que requieran registro, como los servicios URYS (Unidad de reclamaciones y sugerencias) y SMC (servicio de mantenimiento ciudad), autoliquidaciones en modelo C60 modalidad 3, y otros servicios, hasta un máximo de 15.

3.3.9. Personalización de los componentes implantados

• La soluciones ofertadas así como los diferentes componentes que engloban, deberán estar adaptados a la apariencia y diseño gráfico propio del Ayuntamiento de Castellón de la Plana, tales como colores, libro de estilos, temática, logotipos e imagen corporativa.

3.4. Requerimientos Técnicos del Proyecto

Los componentes que se habiliten como parte de la solución propuesta deberán cumplir los siguientes requerimientos técnicos.

3.4.1. Entorno de aplicación.

Directrices de accesibilidad y usabilidad: se respetarán los protocolos internacionales de accesibilidad y usabilidad, siguiendo los estándares W3C y las Web Content Accessibility Guidelines 1.0, para facilitar el acceso a la información a colectivos discapacitados. Se deberá certificar un grado mínimo de accesibilidad <AA> al menos en la parte pública de la solución ofertada, intentando por todos los medios alcanzar el grado <AAA>.

Los servicios de soluciones software objeto de este proyecto, se instalarán según la política de entornos del Ayuntamiento. Al menos existirán 4 entornos diferentes: desarrollo, preproducción I, preproducción II y producción; el ayuntamiento proporcionará información más detallada sobre las reglas de obligado cumplimiento para la gestión de estos entornos así como de las actualizaciones que se vayan sucediendo durante la ejecución del proyecto. La política de entornos será comunicada con más detalle por el Ayuntamiento al inicio del proyecto, y el adjudicatario deberá asumirla aun cuando le suponga la aportación de infraestructura propia. No obstante a lo anterior, el licitador deberá aportar con la oferta una propuesta de política de entornos y de actualizaciones para su evaluación.

3.4.2. Arquitectura de aplicación

Se definen los siguientes requerimientos:

• Coste de licenciamiento: todas las soluciones ofertadas deben poder ser empleadas por el Ayuntamiento con un nulo o mínimo coste de licenciamiento inicial, maximizando por tanto el uso de software en modalidad de código abierto. En todo caso, cualquier coste de licenciamiento estará fuera del alcance de este contrato. Para el caso de uso de aplicaciones declaradas como de código abierto, deberán utilizarse licencias o acuerdos que aseguren que los programas, datos e información compartida cumplen estos principios.

• Uso de estándares: se deben utilizar tecnologías basadas en

estándares aceptados de manera generalizada, garantizando un mantenimiento sencillo del sistema, así como en el desarrollo de nuevas funcionalidades e integraciones con otros sistemas.

• Portabilidad: para cualquier software complementario al servicio ofrecido que sea necesario, se debe garantizar que se permite ejecutar al menos en sistemas operativos windows y linux, y cualquier hardware de arquitectura Intel, además de su portabilidad entre entornos. Esta portabilidad debe garantizarse del mismo modo entre diferentes gestores de base de datos, al menos, Oracle, SQLServer y MySQL.

• Escalabilidad: los componentes deben estar diseñados y desarrollados para soportar el aumento en la carga de procesos o usuarios, necesitando únicamente adecuar la arquitectura hardware del entorno en el que se ejecuta.

• Crecimiento funcional modular: la solución propuesta debe tener una arquitectura y diseño que permita la incorporación de funcionalidades a partir de la incorporación de nuevos módulos sin que éstos afecten al resto del sistema. Por tanto, la integración entre componentes deberá realizarse sin la utilización de interfaces o protocolos nativos y se deberá garantizar el desacoplamiento de capas, permitiendo que la sustitución de componentes por otros nuevos no cause ningún impacto en el resto de componentes. Por tanto, cualquier componente existente como cualquier nuevo componente desarrollado en el ámbito de este proyecto, deberá estar sujeto a este principio de modularidad de componentes y servicios software. Para ello, se deberá aportar documentación sobre su arquitectura, integración o cualquier otro aspecto que garantice este principio.

• Seguridad: la solución propuesta debe garantizar que las funciones básicas de confidencialidad, integridad y disponibilidad se cumplan en un entorno A-A-A (autenticación, autorización y auditoría). El sistema deberá contar con herramientas y procedimientos de salvaguarda, recuperación, exportación e importación de datos. Estas herramientas y procedimientos deben enumerarse en la memoria de la oferta.

• Interoperabilidad: El sistema dará garantía de interoperabilidad técnica, semántica y organizativa entre sus distintos componentes, así como con componentes externos. El sistema garantizará la comunicación entre componentes y herramientas de BackOffice existentes través de manuales técnicos de integración, permitiendo

la fácil incorporación de nuevas aplicaciones.

• Cumplimiento de requisitos marcados por organismos que cedan el código a reutilizar: todas las aplicaciones objeto de este contrato que procedan de cesión de cualquier código por cualquier organismo público, ya sean de nuevo desarrollo o ya existentes , deben de cumplir y adecuarse a los requisitos definidos por el organismo que cede el código, tanto en lo relativo a documentación como a cumplimiento de normas de integración. En el caso de ofertar código cedido a reutilizar, el ofertante deberá aportar, si existiera, esta documentación de requisitos de documentación e integración.

3.4.3. Acceso a las aplicaciones

• En los casos que así se decida por el Ayuntamiento, el sistema debe proporcionar y garantizar la identificación del usuario, ya sea funcionario o ciudadano. Esta identificación se realizará mediante usuario y contraseña o mediante certificados digitales, tal y como se detalla en apartados anteriores.

• El sistema debe garantizar la navegación segura en todos los componentes de la solución.

3.4.4. Navegadores

• el sistema debe garantizar la compatibilidad con los estándares o recomendaciones publicadas por el World Wide Web Consortium (W3C), que implícitamente y a día de hoy garantizan el correcto funcionamiento en navegadores Internet Explorer, Firefox, Chrome y otros.

3.4.5. Rendimiento

• el sistema debe garantizar un rendimiento razonable de las aplicaciones y, como tal, hacer un uso razonable de los recursos necesarios; para ello,...

▪ se garantizará la ejecución de transacciones instantáneas simples en tiempos siempre inferiores a 2 segundos, la ejecución de transacciones instantáneas de complejidad media, como la firma de un documento, en tiempos siempre inferiores a 5 segundos; estos tiempos se medirán excluyendo los tiempos de ejecución acumulados debidos a causas ajenas al sistema, como p.e. disponibilidad de

servicios de terceros o velocidad de líneas de comunicaciones;

▪ la oferta deberá aportar detalle de infraestructura hardware para el adecuado rendimiento de los sistemas ofertados (ver apartado de requisitos de infraestructura);

3.4.6. Seguridad

El sistema debe:

• registrar un log de auditorias para consulta e informe de los accesos y las acciones de los diferentes usuarios, dando constancia de su login, IP, host, etc;

• garantizar la privacidad y seguridad de las comunicaciones dentro de los componentes /herramientas/soluciones ofertadas y entre estos y los todos los existentes en el Ayuntamiento;

3.4.7. Infraestructura

• La oferta deberá aportar detalle de infraestructura hardware (incluyendo comunicaciones) adecuada para el óptimo y razonable rendimiento de los sistemas ofertados. Deberá aportar para la instalación de cada solución ofertada, el dimensionando de estos requerimientos con rangos de estimaciones de carga o volumen. Estos requisitos de infraestructura se entenderán como compromiso vinculante para la correcta ejecución del proyecto, y la infraestructura aportada por el adjudicatario para dar el servicio contratado, los cumplirá.

• Cualquier aplicación complementaria indicada en la oferta que sea necesaria para el buen funcionamiento del servicio ofertado, en relación con el servidor donde se ejecuten, deben:

• ser multiplataforma y funcionar de forma independiente sobre diversos sistemas operativos y gestores de bases de datos, dando prioridad al software de código abierto y a las aplicaciones web;

• tener total compatibilidad con ejecución en servidor virtual Vmware VSphere 5 para 2 CPUs;

• tener un consumo máximo de RAM en servidor (físico o virtual) de 8 Gb;

• tener total compatibilidad con ejecución en servidor con sistema operativo Linux Ubuntu 10.04 64 bits y superiores durante el año de ejecución.

• Las aplicaciones de la solución ofertada, en relación con los clientes donde se ejecuten, deben:

• tener total compatibilidad con los estandares o recomendaciones publicadas por el World Wide Web Consortium (W3C), que implícitamente y a día de hoy garantizan el correcto funcionamiento en navegadores Internet Explorer, Firefox, Chrome y otros;

3.4.8. Disponibilidad

Las soluciones ofertadas deben de maximizar la disponibilidad de los sistemas, garantizando para ello:

• una política y procedimientos de actualización claros que garanticen esta máxima disponibilidad;

• una clara y adecuada política de transacciones que prevenga, y por tanto contemple y evite, bloqueos de ejecución;

La memoria de la oferta incluirá:

• una catalogación completa de las situaciones en las que se prevean indisponibilidades del sistema;

• la política de entornos y procedimientos de actualización, indicando clara y motivada casuística en la que estas actualizaciones serán “en frio” (con indisponibilidad de los sistemas) o en caliente (con los sistemas disponibles);

3.4.9. Datos

• La oferta incluirá documentación detallada del modelo de datos de la solución ofertada, incluyendo tablas, campos, claves, claves ajenas y todo tipo de restricciones definidas (integridad, consistencia y otras).

• La solución implantada garantizará la completa integridad y consistencia de los datos según el modelo de datos. Para ello se garantizará el correcto control transaccional que contemplará toda la casuística existente que evite romper la integridad y consistencia

de los datos.

• Todo producto o solución software utilizado para prestar el servicio contratado, debe adaptarse para el almacenamiento de cualquier tipo de elemento (documentos, expedientes y otros) en el archivo electrónico activo, semi-activo e histórico del ayuntamiento, tanto en su versión actual como en las adaptaciones que éste sufra durante el periodo de ejecución de este proyecto como consecuencia de la adaptación a la reciente normativa técnica para cumplimiento de los RRDD de 2010 del ENS y ENI. Este requerimiento se desarrolla con más detalle en el apartado de requerimientos funcionales.

3.4.10. Mantenimiento

Todas las soluciones implantadas contemplarán con cargo al proyecto un servicio de soporte y mantenimiento correctivo y adaptativo, pruebas y seguimiento desde el momento de puesta en preproducción y durante todo el periodo de garantía del proyecto. El modelo de relación para este servicio deberá quedar definido en la oferta. Este servicio y mantenimientos se facilitarán por medios remotos, helpdesk o hotline (vía telefónica o correo electrónico) o presencial, de un técnico en las instalaciones del Ayuntamiento si así lo requiere el Ayuntamiento. Las adaptaciones del mantenimiento adaptativo incluirán, sin más coste que el especificado en la oferta, la incorporación de todos los cambios necesarios debidos a aparición de nuevas versiones de los productos objeto de este contrato durante la ejecución del proyecto.

Tal y como se indica en el apartado 3.1 de este Pliego, la oferta deberá aportar una valoración económica de costes futuros previstos de las soluciones ofertadas, entre otros, los costes de mantenimiento.

3.5. Requerimientos Jurídicos

La solución presentada debe estar en correspondencia con las normativas estipuladas en la Ley 11/2007 de acceso electrónico de los ciudadanos a los Servicios Públicos, el Real Decreto que la desarrolla, en RD de 2010 de ENI (incluidas las normas técnicas de interoperabilidad de lo desarrollan) y el RD 2010 del ENS, la Ley 3/2010 de Administración Electrónica de la Comunitat Valenciana y la Ordenanza Municipal de Administración Electrónica de este ayuntamiento. Las funcionalidades que cumplan con el resto de requisitos de este pliego deberán estar totalmente alineadas con la citada normativa.

Quedará incluido en el ámbito del proyecto cualquier adaptación, sea desarrollo o cualquier otro tipo de trabajo, a la normativa que pudiera surgir durante el desarrollo del proyecto y posterior periodo de garantía. Así mismo, las propuestas de mantenimientos anuales posteriores a la finalización del contrato, incluirán el coste de las adaptaciones de las herramientas suministradas a los cambios normativos que aparezcan durante ese periodo.

Los licitadores deberán demostrar capacidad de soporte de ámbito legal para el asesoramiento al Ayuntamiento de Castellón de la Plana según lo indicado en el apartado de solvencia del Pliego de Clausulas administrativas (PCA).

Cualquier acción propuesta o derivada del alcance del proyecto tiene que acompañarse de las acciones necesarias para que sus implicaciones cumplan íntegramente con la LOPD.

Todo producto o solución software que forme parte de la oferta, debe estar orientado a mejorar la simplificación administrativa, reducción de tiempos y plazos de los procedimientos.

3.6. Documentación

3.6.1. Documentación requerida en la oferta.

Los licitadores deberán aportar en su oferta toda la documentación detallada según lo indicado en el apartado correspondiente del Pliego de Cláusulas administrativas (PCA).

3.6.2. Entregables requeridos durante la ejecución del proyecto.

La ejecución del proyecto deberá incluir los entregables definidos y asociados a los Hitos detallados en el apartado 4 de este pliego. Estos entregables deberán ser validados por el Director del Proyecto del Ayuntamiento en el momento de su aportación durante la ejecución del proyecto. De no ser validados estos entregables, se entenderán rechazados y el hito asociado no podrá ser validado.

3.7. Formación

La oferta incluirá una propuesta de plan de formación y divulgación de cada uno de los módulos y componentes de la solución ofertada a los empleados del Ayuntamiento de Castellón de la Plana. La propuesta incluirá la planificación dentro del proyecto de implantación, garantizando el nivel suficiente de aprendizaje de los usuarios, acorde a las

necesidades de la organización.

El plan de formación deberá incluir al menos: (1) Tipos de cursos que se ofrecen (online, presencial, etc), (2) Temario a impartir para cada curso planificado, (3) Número recomendado de asistentes a cada sesión y perfil de los mismos, (4) Duración estimada de las sesiones y (4) Lugar de impartición de los cursos. El Ayto pondrá a disposición dependencias para su impartición. La propuesta de formación incluirá:

• al menos 10 ediciones de formación para usuarios finales de aplicaciones o procedimientos para el módulo Ciudadano;

• al menos 10 ediciones de formación para usuarios finales de aplicaciones o procedimientos para el módulo Tramitador;

• al menos 5 ediciones de formación para usuarios finales de aplicaciones o procedimientos para el módulo Firma;

• al menos 10 ediciones de formación para usuarios finales de aplicaciones o procedimientos para el módulo Registro;

• al menos 4 ediciones de formación dirigidas a técnicos desarrolladores y administradores de aplicaciones para todos los módulos y componentes;

• al menos 4 ediciones de formación dirigidas a técnicos y administradores de sistemas para todos los módulos y componentes;

Cada edición de formación (curso completo) tendrá al menos 10 horas de duración y se podrá organizar en sesiones de entre 2,5 horas y 5 horas de duración, según indique el Ayuntamiento para cada tipo de curso. No se limitará el número de asistentes a cada edición.

Se facilitará documentación detallada a los asistentes. El contenido será prioritariamente práctico y se ofrecerá sobre el entorno de pruebas de las aplicaciones. El contenido de cualquier acción formativa deberá ser aprobado por el Director de Proyecto den Ayuntamiento de Castellón de la Plana.

3.8. Metodología de gestión de proyecto

Los licitadores adjuntarán en sus ofertas una descripción detallada de la metodología de trabajo propuesta durante la ejecución del proyecto y en la fase posterior de garantía. No obstante a lo anterior, el adjudicatario adaptará su metodología a la metodología de gestión del proyecto que

tiene implantada el Ayuntamiento. Para ello, el Ayuntamiento definirá una disciplina de reuniones presenciales de seguimiento y una documentación y protocolos que el adjudicatario estará obligado a respetar, no obstante a lo cual éste podrá sugerir cualquier cambio o mejora que estime oportuna. Esta disciplina de reuniones presenciales y documentación exigida podrá ser revisada y modificada por el Ayuntamiento según sus necesidades.

Las reuniones de seguimiento serán al menos de dos tipos:

• Comité de dirección del proyecto, con la función de supervisar el desarrollo del proyecto, validar los planes de actuación y facilitar las actividades en las que participe personal de la empresa adjudicataria y del Ayuntamiento de Castellón de la Plana. Este Comité estará formado al menos por un Director del proyecto por parte del Ayuntamiento, quien validará los planes, y un Representante de la empresa adjudicataria. Este comité se reunirá presencialmente en el ayuntamiento al menos de forma bimestral y elaborará actas de cada sesión.

• Comité de gestión operativa del proyecto, con la función de supervisar periódicamente el desarrollo del proyecto, acciones planificadas, ejecutadas, desvíos de planificación y evaluar riesgos. Este comité se reunirá presencialmente en el ayuntamiento al menos de forma quincenal y se ocupará de preparar los informes de progreso y planes, para su aprobación por el comité de dirección. Estará formado por el jefe de proyecto del ayuntamiento, el jefe de proyecto de la empresa adjudicataria, quien preparará los informes de progreso y planes, y otras personas que se consideren oportunas para tratar temas específicos de una iniciativa concreta. La empresa adjudicataria, garantizará la transmisión del conocimiento tecnológico a este Comité mediante documentación aportada en cada reunión.

El adjudicatario pondrá a disposición del ayuntamiento una herramienta para poder reportar y gestionar las incidencias a lo largo del proyecto; esta herramienta podrá se reemplazada a petición del ayuntamiento por la que designe el ayuntamiento si así lo estima oportuno. La herramienta dará visibilidad del estado de cada incidencia así como la posibilidad de adjuntar o distribuir documentación entre los interesados de la incidencia. La oferta presentada debe proponer y detallar mínimamente una herramienta en este sentido.

3.9. Estructura del equipo de trabajo

Los licitadores deberán describir en sus ofertas el equipo de trabajo propuesto para la prestación del servicio, en concreto deberán detallar al menos lo siguiente:

• Perfiles que forman parte del equipo de trabajo.

• Detalle de las dedicaciones de cada persona.

• Funciones específicas de cada uno de los perfiles dentro del equipo.

• Currículum de las personas propuestas para asumir estos perfiles, dedicaciones y funciones. En caso de cambio durante la ejecución de la persona propuesta en la oferta a instancia del licitador, el ayuntamiento deberá dar su conformidad. Si el ayuntamiento lo considerase oportuno, solicitará el cambio de cualquier persona del equipo, y el adjudicatario deberá aceptar la propuesta y ejecutarla previa conformidad del ayuntamiento posterior a entrevista personal con la nueva persona propuesta para el equipo.

3.10. Calendario del proyecto

Los licitadores adjuntarán en sus ofertas un calendario detallado de la planificación de los trabajos necesarios para la ejecución del proyecto. El calendario incluirá fechas-tope para cada hito del proyecto, tanto los exigidos de mínimos como los definidos voluntariamente por el licitador. Al tratarse de un proyecto plurianual, el calendario propuesto deberá respetar el presupuesto asignado a cada ejercicio. El plazo de finalización del proyecto terminará como máximo el 7 de diciembre de 2014.

4. Hitos del proyecto

El proyecto estará sujeto a cumplimiento de hitos concretos. Estos serán valorados por el Ayuntamiento. El cumplimiento de estos hitos en calendario y contenido será condición necesaria para que se acepte la facturación de las distintas partidas del proyecto en su desglose por hitos. Se entenderá cumplido un hito cuando así lo valide el Director de Proyecto del Ayuntamiento de Castellón de la Plana, en función de los resultados esperados en la ejecución, y de la aceptación y validación de cada entregable asociado a cada hito. El retraso de cualquier hito podrá dar lugar a penalizaciones económicas y, en su caso, si el ayuntamiento así lo estima, a la cancelación del proyecto pendiente

de ejecutar. Las penalizaciones económicas se describen en el apartado correspondiente.

El licitador debe aportar en su oferta el detalle de hitos propuestos, respetando el mínimo de hitos descrito a continuación, pero permitiendo el orden cronológico y agrupación de hitos o subhitos que el licitador estime adecuado. Cada hito deberá incluir al menos su descripción, calendario, descripción de entregables asociados e importe asociado. El importe a facturar asociado a cada hito, deberá ser equilibrado según el número de hitos total y siempre deberá ajustarse a la asignación presupuestaria de cada ejercicio.

Los hitos mínimos obligatorios para todos y cada uno de los módulos, así como su descripción, entregables, importe y calendario asociado, son los siguientes:

Hito 1Descripción: finalización de la toma de requerimientos ampliada, análisis detallado, alcance detallado y revisado, y entrega y validación de la documentación de análisis de situación actual y especificación funcional.

El adjudicatario, previo al inicio del resto de acciones, deberá realizar un análisis y estudio detallado de la situación y sistemas de información del ayuntamiento. Estas conclusiones se deberán plasmar en en entregable asociado a este hito, el cual deberá evidenciar el correcto y completo conocimiento del estado del arte del ayuntamiento en eAdministración y contener una descripción detallada de sistemas de información del ayuntamiento en este ámbito así como mayor concreción del alcance del proyecto especificado en la oferta. El ayuntamiento deberá validar como conforme este documento para continuar con la ejecución del proyecto.

Entregable:

• documento detallado de alcance, análisis funcional, diseño funcional, calendario de hitos y tareas, jornadas presenciales y remotas, y resto de información que detalle al máximo el calendario del proyecto.

Importe: a definir por el licitador en la oferta.

Calendario: a definir fecha de finalización por el licitador en la oferta.

Hito 2Este hito se desglosará por módulos y componentes en tantos sub-hitos como indique el licitador en su propuesta, debiendo indicar para cada

uno de ellos descripción, entregable, importe y calendario siguientes.

Descripción: Instalación y configuración en preproducción de cada uno de los componentes o módulos y correspondiente visto bueno por el Ayuntamiento tras la ejecución satisfactoria de las pruebas de aceptación.

Entregables:

• documentación de pruebas de aceptación realizadas por el adjudicatario;

• documentación de pruebas de aceptación a realizar por el ayuntamiento;



Hito 3Este hito se desglosará por módulos y componentes en tantos sub-hitos como indique el licitador en su propuesta, debiendo indicar para cada uno de ellos descripción, entregable, importe y calendario siguientes.

Descripción: Desarrollo de todas las integraciones indicadas en este pliego y puesta en marcha en preproducción y correspondiente visto bueno por el Ayuntamiento tras la comprobación de su correcta ejecución.

Entregables:

• documento de especificación funcional detalle de cada integración;

• manuales técnicos de integración, que detallen la comunicación entre componentes y herramientas de BackOffice existentes;

• todas las aplicaciones, código fuente y demás herramientas, información y datos utilizadas para llevar a cabo las integraciones, acompañadas de un adecuado manual de ejecución;

• modelos y mapeos de los datos integrados.




Descripción: Desarrollo y ejecución en preproducción de todas las migraciones indicadas en este pliego y correspondiente visto bueno por el Ayuntamiento tras la comprobación de su correcta ejecución.

Entregables:

• documento de especificación funcional detalle de la migración;

• todas las aplicaciones, código fuente y demás herramientas, información y datos utilizadas para llevar a cabo la migración, acompañadas de un adecuado manual de ejecución;

• modelo y mapeo de datos migrados.




Descripción: igual que el hito 2 (inst alación y configuración) pero referido a producción en lugar de a preproducción y correspondiente visto bueno por el Ayuntamiento tras la comprobación de su correcta ejecución.

Entregables: igual que el hito 2 (instalación y configuración) pero referido a producción en lugar de a preproducción, excepto los documentos de pruebas de aceptación, que no proceden en este caso.



Hito 6

Este hito se desglosará por módulos y componentes en tantos sub-hitos como indique el licitador en su propuesta, debiendo indicar para cada uno de ellos descripción, entregable, importe y calendario siguientes.

Descripción: igual que el hito 3 (i ntegraciones ) pero referido a

producción en lugar de a preproducción y correspondiente visto bueno por el Ayuntamiento tras la comprobación de su correcta ejecución.

Entregables: actualización de los entregables del hito 3 (integraciones) pero referido a producción en lugar de a preproducción.



Hito 7


Descripción: igual que el hito 4 (migraciones) pero referido a producción en lugar de a preproducción y correspondiente visto bueno por el Ayuntamiento tras la comprobación de su correcta ejecución.

Entregables: actualización de los entregables del hito 4 (migraciones) pero referido a producción en lugar de a preproducción.



Hito 8


Descripción: finalización de la formación (según requerimientos detallados en el apartado de formación)

Entregables:

• manuales de usuario y técnicos descritos en el apartado de formación;

• manuales de administrador de la aplicación;

• manuales de usuario de la aplicación;

• manuales del administrador técnico de sistemas del entorno;

• informe de todas las formaciones impartidas y del nivel de satisfacción de los asistentes, en base a una encuesta que se deberá diseñar por el adjudicatario previa aceptación del ayuntamiento;



Hito 9


Descripción: Recepción de documentación final de proyecto y correspondiente visto bueno por el Ayuntamiento tras la comprobación de su correcta ejecución, entre otros, mediante valoración del compromiso de cumplimiento de indicadores de grado de implantación final del proyecto ofertados.

Entregables:

• documento actualizado del análisis funcional detallado (solo si procede y ha habido cambios respecto al inicial);

• definición detallada de arquitectura del sistema;

• actualización de cualquiera de todos los entregables anteriores que proceda;

• cuadro de mando que refleje el grado de implantación de cada componente, en números absolutos, en números relativos y en porcentajes sobre el valor objetivo mínimo y máximo propuestos para cada indicador;



5. Pruebas de aceptación

El adjudicatario proporcionará al ayuntamiento un guión detallado de pruebas. Este deberá ejecutar esta batería de pruebas de aceptación en su entorno de preproducción antes de facilitarlas al ayuntamiento para sus pruebas. Tras la

instalación en el entorno de preprodución del ayuntamiento de cada módulo o actualización del software, el ayuntamiento ejecutará las pruebas de aceptación y su resultado tendrá que ser conforme para validar la subida a producción.

6. Mejoras

Se valorarán como mejora las actuaciones indicadas en el Pliego de Cláusulas Administrativas (PCA).

7. Plazo de ejecución del contrato

El servicio se ejecutará a partir del día siguiente a la formalización del contrato y en un plazo máximo de 24 meses desde su inicio. En cualquier caso, la ejecución del contrato finalizará como máximo del 7 de diciembre de 2014.

8. Importe Base de Licitación

El importe máximo de licitación (IVA incluido) se establece en 234.820 Euros.

9. Facturación

Se establece un sistema de facturación por hitos cumplidos, cuya conformidad dará el ayuntamiento de forma escrita al adjudicatario. El importe a facturar propuesto asociado a cada hito deberá respetar la asignación presupuestaria de cada ejercicio.

10. Garantía

Se fija un periodo de garantía de al menos 12 meses sobre todos los módulos y componentes instalados en el ámbito de este contrato, contados desde la fecha de firma del acta de recepción del proyecto, y durante los cuales la empresa licitadora se hace responsable de la resolución de las incidencias que

éstos puedan generar y de la corrección de cualquier problema de funcionamiento que pudiera detectarse. La extensión de esta garantía será valorada como mejora según lo indicado en el apartado de mejoras del Pliego de Clausulas Administrativas (PCA).

11. Penalizaciones

Se establece el sistema de penalizaciones económicas siguiente.

• Penalizaciones por retraso en cumplimiento de hitos según calendario de ejecución propuesto por el adjudicatario, siempre que el ayuntamiento estime que el retraso se debe a causas atribuibles al adjudicatario:

• Cualquier hito cumplido con un retraso de más de 7 días naturales tendrá una penalización económica de un 0,1 % del total del importe de adjudicación; por cada retraso adicional de 7 días, la penalización se incrementará en 0,1%.

• El adelanto de ejecución de un hito permitirá recuperar la penalización por retraso de cualquier hito anterior o futuro y, por tanto, también la compensación de penalización económica, que se facturará en el siguiente hito a facturar.

• Penalizaciones por incumplimiento de cualquiera de los requisitos que figuran en este pliego, siempre que el Ayuntamiento estime que el incumplimiento se debe a causas atribuibles al adjudicatario:

• El Ayuntamiento podrá aplicar penalizaciones por cualquiera de los requisitos y principios indicados en este pliego que oscilarán entre el 0,1% y el 100% del importe del proyecto pendiente de facturar , o incluso, si así lo estima la dirección técnica del proyecto del Ayuntamiento, constituirán causa de resolución del contrato. El porcentaje de penalización a aplicar lo fundamentará la dirección técnica del proyecto en base a la repercusión que tenga el incumplimiento en el resultado final del proyecto, aplicando criterios de proporcionalidad con respecto al incumplimiento producido.

• Penalizaciones por incumplimiento del compromiso de grado de implantación ofertado mediante la propuesta de valoración de indicadores, siempre que el Ayuntamiento estime que el incumplimiento se debe a causas atribuibles al adjudicatario.

• La oferta incluirá una propuesta de valores de todos los

indicadores de grado de implantación y éxito de cada solución comprometidas por el adjudicatario según lo indicado en el apartado de “Documentación a aportar” del PCA. Este compromiso solo se valorará como 100% cumplido, si se alcanzan los grados de implantación ofertados, o 0% cumplido si no se alcanzan los grados comprometidos, no admitiendo cumplimientos parciales. Esta valoración de cumplimiento total de los compromisos ofertados, la realizará el Ayuntamiento tras la comprobación de los resultados indicados en el entregable de cuadro de mando descrito en el hito 9. En el caso de que no se alcancen todos los compromisos de grado de implantación ofertados, el Ayuntamiento podrá aplicar penalización del 10% del importe total de adjudicación.

12. Solvencia Técnica

Las solvencia técnica se evaluará según lo indicado en el Pliego de Cláusulas Administrativas (PCA).

13. Criterios de Valoración

Se aplicarán los criterios de valoración detallados en el Pliego de Cláusulas Administrativas (PCA).

14. Condiciones Generales

14.1. Propiedad Intelectual

El Ayuntamiento de Castellón de la Plana tendrá la propiedad de los nuevos programas y elementos software que sean desarrollados dentro del ámbito de este contrato y, por lo tanto, estará autorizada a la reproducción total o parcial, traducción, adaptación o cualquier otra transformación que pudiera requerir la utilización de estos elementos desarrollados o modificados, así como su distribución a los centros en que se juzgue necesario su uso.

14.2. Transferencia Tecnológica

Durante la ejecución de los trabajos objeto del contrato, el adjudicatario se compromete, en todo momento, a facilitar a las personas designadas por el Ayuntamiento de Castellón de la Plana la información y documentación que soliciten, para disponer de un pleno conocimiento de las circunstancias en que se desarrollan los trabajos, así como de los eventuales problemas que puedan plantearse y de las tecnologías, métodos y herramientas utilizados para resolverlos.

Castellón, a 22 de junio de 2012

Firmado:Jorge Fuentes Herrero

Jefe de Sección de Innovación y Desarrollo Tecnológico

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA … · 3.1. Detalle de las soluciones de Administración...

Documents

Transcript of PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA … · 3.1. Detalle de las soluciones de Administración...