Centro de contratación:

Centro Informático para la Gestión Tributaria Económico-financiera y Contable (CIXTEC) Consellería de Facenda. Xunta de Galicia

Órgano de contratación:

Dirección General del CIXTEC

Denominación del contrato:

Servicio consistente en la evolución y actualización continua del Sistema de Facturación (SEF) que constituye el Punto General de Entrada de Facturas y el Registro Contable de Facturas de la Comunidad Autónoma de Galicia, mediante tramitación documentalmente simplificada

Ref. Expediente:

2016-004

CPV:

Tipo de contrato:

Servicios

Tramitación:

Procedimiento:

Abierto

Forma:

Importe licitación:

239.580,00 €

Plazo de ejecución:

72514200-3

Contrato armonizado:

No

Ordinaria

Pluralidad de criterios Desde la formalización del contrato hasta el 31 de enero de 2018.

PLIEGO DE PRESCRIPCIONES TÉCNICAS 1.

ANTECEDENTES.

El Sistema Electrónico de Facturación (en adelante SEF) permite a las empresas y proveedores en general, realizar de forma directa la presentación telemática de facturas ante Xunta de Galicia y también ante las Entidades del Sector Público de ella dependientes así como la gestión y seguimiento de estados de tramitación. La Comunidad Autónoma de Galicia fue pionera en la puesta en funcionamiento de la factura electrónica y así, ya en el año 2010, publicó la siguiente normativa: - “DECRETO 3/2010, de 8 de enero, por el que se regula la factura electrónica y la utilización de medios electrónicos, informáticos y telemáticos en materia de contratación pública de la Administración de la Comunidad Autónoma de Galicia y entes del sector público dependientes de la misma” (DOG, núm. 25, del 25 de enero del 2010). - “ORDEN de 12 de febrero de 2010 por la que se regulan los procedimientos del sistema electrónico de facturación de la Xunta de Galicia” (DOG, núm. 31, del 16 de febrero del 2010). Posteriormente, el SEF se tuvo que adaptar a la “Ley 25/2013, de 27 de diciembre, de impulso de la factura electrónica y la creación del registro contable de facturas en el Sector Público” (BOE, núm. 311, de 28 de diciembre de 2013) así como las distintas órdenes que se fueron publicando a nivel estatal: - “Orden HAP/492/2014, de 27 de marzo, por la que se regulan los requisitos funcionales y técnicos del registro contable de facturas de las entidades del ámbito de aplicación de la Ley 25/2013, de 27 de diciembre, de impulso de la factura electrónica y la creación del registro contable de facturas en el Sector Público” (BOE, núm. 77, de 29 de marzo del 2014). - “Orden HAP/1074/2014, de 24 de junio, por la que se regulan las condiciones técnicas y funcionales que debe reunir el Punto General de Entrada de Facturas Electrónicas” (BOE, núm. 154, de 25 de junio del 2014). - “Orden HAP/1650/2015, de 31 de julio, por la que se modifican la Orden HAP/492/2014, de 27 de marzo, por la que se regulan los requisitos funcionales y técnicos del registro contable de facturas de las entidades del ámbito de aplicación de la Ley 25/2013, de 27 de diciembre, de impulso de la factura electrónica y creación del registro contable de facturas en el Sector Público y la Orden HAP/1074/2014, de 24 de junio, por la que se regulan las

1

condiciones técnicas y funcionales que debe reunir el Punto General de Entrada de Facturas Electrónicas” (BOE, núm. 187, de 6 de agosto del 2015). Como consecuencia de la normativa estatal, en el 2015 se publicó nueva normativa a nivel autonómico con la finalidad de convertir al Sistema Electrónico de Facturación (SEF) como Punto general de entrada de facturas electrónicas de la Comunidad Autónoma de Galicia, en virtud del cual se publicó la “ ORDEN de 26 de febrero de 2015 por la que se regulan el Punto general de entrada de facturas electrónicas y el Registro Contable de Facturas de la Comunidad Autónoma de Galicia” (DOG, núm. 50, de 13 de marzo del 2015).

2.

OBJETO DEL CONTRATO

Evolución y actualización continua, así como la incorporación de nuevas funcionalidades y los desarrollos que fueran necesarios para la tramitación de las facturas presentadas por los proveedores de las entidades del Sector Público Autonómico en el Sistema Electrónico de Facturación (SEF) lo cual constituye el Punto General de Entrada de Facturas y el Registro Contable de Facturas de la Comunidad Autónoma de Galicia. También es objeto de la contratación los desarrollos que fueran necesarios para la tramitación de las facturas presentadas por los proveedores de las entidades del Sector Público Autonómico.

3.

DESARROLLOS A REALIZAR

3.1. Adhesión de entidades al punto general de entrada de facturas En la actualidad están incorporadas al Punto General de Entrada de Facturas de la Comunidad Autónoma, tanto la Administración General de la Xunta de Galicia (Consellerías, etc.) como la mayor parte de las Entidades del Sector Público Autonómico, incluyendo las tres Universidad, Sanidad, Educación etc. En cualquier caso y debido a que las administraciones públicas están en constante evolución, durante la vigencia del contrato podrán incorporarse al sistema nuevas entidades, bien fuera por la fusión o creación de nuevas entidades, bien por el cambio de estructura de la propia Administración General de la Xunta. Es, por lo tanto, objeto de esta contratación la realización de los desarrollos que en su caso fuera preciso realizar en el SEF como consecuencia de la incorporación de nuevas Entidades del Sector Público Autonómico al Punto General de Entrada de Facturas, así como los trabajos previos/posteriores que en su caso fuera preciso realizar como consecuencia de dichas incorporaciones, fusiones, cambios de estructura etc. Están añadidas en el objeto del contrato, como mínimo las siguientes tareas y/o desarrollos: -

La carga inicial de datos

-

La parametrización inicial del sistema

-

La realización de los ajustes que fuera preciso realizar en el sistema para integrar a las nuevas entidades

-

La realización de procesos de pruebas y paralelos previos a la implantación definitiva del sistema.

Al margen contemplar de lo descrito anteriormente, los oferentes deberán expresar en sus ofertas los desarrollos que proponen para facilitar la incorporación de nuevas entidades al sistema en el sentido de automatizar al máximo posible los procedimientos de incorporación/fusión etc.

2

3.2. Intercambio de Facturas del SEF con los Sistemas de Información EconómicoFinancieros En la actualidad, el SEF dispone de un Servicio Web de Intercambio de Facturas (SWIF) a través del cual se realizan los intercambios de información entre el propio SEF y los Sistemas de Información Económico-Financieros de las distintas entidades. A través del SWIF se transmite toda la información de las facturas presentadas y también permite realizar la comunicación (SEF – Sistema Económico-Financiero de la entidad y viceversa) de los cambios de estado de las mismas. En la actualidad este método de comunicación se emplea para la comunicación entre el SEF y los Sistemas de Información Económico-Financieros de la totalidad de las Entidades del Sector Público, con la excepción del Sistema de Información Económico-Financiero de la propia Administración General de la Xunta (XUMCO2). En un primer momento la integración entre el SEF y XUMCO2 se realizó con un alto grado acoplamiento entre ambos sistemas y, de esta forma, el SEF actualiza directamente la base de datos XUMCO2 y por su parte, el XUMCO para actualizar el SEF emplea DTS que se ejecutan en segundo plano y modo “background”. Los oferentes deberán expresar en sus ofertas los trabajos que van a realizar para establecer un método de comunicación SEF – XUMCO2 a través de servicios web, ya sea incorporando nuevas funcionalidades al SWIF o desarrollando un nuevo servicio web, así como el plan para puesta en funcionamiento de dichas funcionalidades. También es objeto del contrato las modificaciones que en su caso fuera preciso realizar, bien fuera como consecuencia de la incorporación de nuevas Entidades del Sector Público Autonómico al Punto General de Entrada de Facturas y que por lo tanto requerirán integración del SEF con el Sistema de Información Económico-Financiero de la entidad incorporada o también por los cambios normativos, funcionales y operativos que supusieran la transmisión de estados o información diferente a la que se está transmitiendo en la actualidad. 3.3. Módulo de Comunicaciones. En la actualidad el SEF informa de los estados de tramitación de las facturas (los definidos por la legislación vigente), de distintas formas: - Directamente a través del propio sistema: Cualquier proveedor puede consultar y/o exportar a través del sistema y en tiempo real el estado en el que se encuentran cada una de las facturas. - Por Web Services (B2B): Cualquier proveedor puede invocar los servicios B2B para consultar los estados de las facturas: - A través de correo electrónico: En la actualidad a cualquier proveedor que presente las facturas directamente en el sistema (a través de formulario o incorporando archivos XML en formato Facturae) y también para aquellos otros proveedores que presentan las facturas a través de correo electrónico, la comunicación del estado del trámite de las mismas es realizado a través del correo electrónico. Con la facilidad de conseguir un mayor grado de transparencia, es preciso dotar al sistema de mayor flexibilidad en lo que se refiere a las comunicaciones (y no sólo del estado de trámite de las facturas). Para ello los oferentes deberán proponer nuevas funcionalidades: - Permitir la comunicación de otros estados (p.e. Rechazo de la propuesta de anulación). - Flexibilidad en la elección por parte del proveedor del(s) correo(s) electrónico al cual se le informa - Flexibilidad en la elección (por parte del proveedor y/o del receptor) de las comunicaciones que se desean realizar. - Nuevas posibilidades de comunicación: Avisos, alertas etc. lo cual incluye también otros medios para comunicar (p.e. sms etc.), dándole la posibilidad de la elección el proveedor. 3

- Posibilidad de aportar ficheros a las comunicaciones. - Apoyar las comunicaciones a través de correo electrónico. - Mejora de la gestión de los comunicados por parte del administrador. Los oferentes deberán proponer en sus ofertas cuáles son los desarrollos que van a realizar tanto para dar un mayor grado de flexibilidad y transparencia como para establecer nuevos canales de comunicación. 3.4. Servicios Web de presentación de facturas En la actualidad el SEF dispone de un servicio de intercambio de datos (servicio Web) a través del cual los proveedores pueden realizar una serie -

Presentar facturas a través de ficheros XML en el estándar Facturae.

-

Consultar el estado de las facturas

-

Descargar facturas

-

Descargar los destinos de las facturas

-

Etc.

Se trata de ampliar las funcionalidades del servicio Web para que permita que los proveedores puedan darse de alta en el sistema a través de dicho servicio. 3.5. Firma digital de facturas por cuenta de un tercero. Una factura electrónica puede ser firmada electrónicamente, por el emisor, por el receptor o por un tercero. La firma electrónica de la factura garantiza que ésta no es modificada con posterioridad a la presentación de la misma, certificando por lo tanto la autenticidad y la integridad de la información. En la actualidad el SEF permite la presentación de facturas de distintas formas: 1-. Manualmente, mediante formulario. 2-. Mediante la incorporación de fichero XML de forma manual. 3-. Envío de fichero XML a través de B2B. 4-.Envío de fichero XML a través de correo electrónico. Para el caso de presentación de facturas de forma manual a través de formulario, el SEF permite firmar las facturas electrónicamente de dos formas: Por el emisor o por el receptor pero no permite firmarla por un tercero. Para el resto de las formas de presentación las facturas pueden ser firmadas por el emisor, por el receptor o por un tercero. Se trata de realizar los desarrollos necesarios para que cualquier factura presentada de forma manual a través de formulario poda ser firmada electrónicamente por un tercero. 3.6. Mejoras de acceso al sistema. En la actualidad los proveedores pueden acceder al sistema a través de distintas formas. La forma menos limitativa es a través de usuario y contraseña. Con este método un usuario puede darse de alta en el sistema (previo al informe de una serie de datos). Otra forma es empleando un certificado digital de persona física de entre cualquiera de los emitidos por las autoridades certificadoras de firma reconocida admitidas por la Consellería de Facenda: http://www.conselleriadefacenda.es/web/facenda/servizos-y-tramites/ov-perceptores/admisionautoridades-certificadoras El SEF deberá adaptar su funcionamiento para que los proveedores puedan acceder, presentar y consultar facturas mediante certificado digital de persona jurídica así como mantener todas las funcionalidades existentes actualmente en el sistema para los otros métodos de acceso, habida 4

cuenta además que el titular del certificado podrá gestionar todas las facturas correspondientes a esa persona jurídica, independientemente del método por el que hayan sido introducidas en el sistema. 3.7. Evolución funcional en el modulo de presentación de facturas por correo electrónico. Actualmente el SEF permite, al proveedor, la presentación de facturas a través de correo electrónico mediante un archivo (xml, xsig) de factura cumpliendo el estándar Facturae. El proveedor no puede realizar ninguna gestión adicional a través de correo electrónico. El SEF deberá permitir las siguientes nuevas funcionalidades a través de correo electrónico: -

Presentar propuestas de anulación.

-

El estándar facturae permite adjuntar archivos al propio ficherio XML que contiene la factura de dos formas direrentes: 1) Codificado dentro del propio fichero XML 2) Incorporar archivos asociados a la factura sin ser codificados (fuera del fichero XML). En la actualidad el método de presentar facturas a través de correo electrónico ya permite presentar archivos codificados dentro del propio XML. Se trata de que el sistema también permita incorporar archivos asociados a la factura sin ser codificados, esto es, fuera del fichero XML

3.8. Evolución funcional del módulo de gestión de usuarios. El SEF dispone de funcionalidades que permiten que los usuarios de la administración puedan gestionar las facturas que presentan los proveedores. Para ello, existen distintos perfiles: -

Tramitadores (mecanizador, validador, conformador, consulta etc.).

-

Seguridad.

-

Administradores.

En la actualidad el sistema solamente permite que un usuario tenga un perfil. Se trata de desarrollar un módulo de administración de perfiles que permita: -

Creación de nuevos perfiles.

-

Acceso a varios perfiles (cambiar de perfil a voluntad por el propio usuario).

3.9. Integración con la Plataforma de Validación de Certificados Electrónicos (PVCE). Actualmente el SEF está utilizando un servicio de seguridad y cifrado propio del CIXTEC (DllCryptoWS) a través del cual se realiza la validación de los certificados electrónicos empleados por los usuarios para el acceso al sistema y para la verificación de las firmas electrónicas de las facturas recibidas. En la actualidad existe una nueva plataforma la cual está compuesta por un conjunto de módulos basados en tecnologías javaee que ofrecen servicios agrupados por funcionalidad, entre los que destacan los servicios de certificados electrónicos, de firmas electrónicas y de cifrado. Estos módulos utilizan para algunas de sus operaciones los servicios ofrecidos por la plataforma @firma desplegada en modo federado. La plataforma de gestión y validación de certificados de la Consellería de Facenda (PVCE) permite la validación de los certificados electrónicos empleados en las relaciones electrónicas con los ciudadanos y otras administraciones públicas, facilitando también la identificación de los titulares de los certificados a partir de su contenido, proporciona servicios para la realización y validación de firmas electrónicas, y servicios criptográficos para el cifrado y descifrado de información. 5

Los servicios ofrecidos por esta plataforma permiten la identificación electrónica de los ciudadanos que emplean los sistemas de información de la Consellería de Facenda y la realización y validación de firmas electrónicas en múltiples formatos. Se deberá adaptar el sistema a los cambios requeridos por la nueva plataforma de validación de certificados electrónicos. 3.10. Integración del SEF con el Servicio de Validación de NIF y con el Servicio de Verificación de Entidades. Actualmente el SEF obtiene los datos demográficos del proveedor durante la fase solicitud de alta y/o modificación en el sistema. Durante esta fase los datos son facilitados directamente por el propio interesado (Proveedor) lo cual supone que en algunos casos estos no sean introducidos de forma correcta (bien sea por equivocación del propio proveedor o por que se introducen incompletos). Para evitar estos problemas se hace necesario la integración del SEF con los siguientes sistemas: -

Integración con el Servicio de Validación de NIF:

Este servicio facilita el resultado de la validación del NIF o NIE de un contribuyente dado, siendo esta información la que figura en el momento de la solicitud en el sistema de información de la Agencia Tributaria y sirve fundamentalmente para consultar el NIF de personas jurídicas y de entidades sin personalidad jurídica así como también de personas físicas contribuyentes. Toda persona jurídica, así como los obligados tributarios tendrán un número de identificación fiscal. La Agencia Estatal de Administración Tributaria le asigna el número de identificación fiscal a las personas jurídicas y entidades que lo soliciten, y en caso de que no lo soliciten podrá proceder de oficio a darlos de alta en el Censo de Obligados Tributarios y asignarles el número de identificación fiscal que les corresponda. De este modo, el Censo de Obligados Tributarios, de competencia estatal, está formado por la totalidad de las personas físicas y jurídicas, así como los obligados tributarios que deban tener un número de identificación fiscal para sus relaciones de naturaleza tributaria o con trascendencia tributaria. -

Integración con el Servicio de Verificación de Entidades:

Permite consultar la información registrada para un determinado documento de identidad. En el formulario de consulta se deberá indicar el NIF del ciudadano, en caso de ser ciudadano español, o el NIE o el número de tarjeta de identificación de extranjero (TIE), en el caso de ciudadanos extranjeros. En este último caso, el NIE solamente es obligatorio si no se especifica el campo Número de soporte. Como respuesta el servicio devuelve la información de carácter personal registrada en el documento de identidad. Para cualquiera de las dos integraciones y para el caso de que las altas y/o modificaciones en el SEF sean dadas de alta por el propio interesado, se deberá contemplar que el sistema informe de forma adecuada para que este de el consentimiento expreso a la consulta en el Servicio de Validación de NIF o en el Servicio de Verificación de Entidades. Para el caso de que las altas en el sistema sean dadas por un empleado público, la Agencia Tributaria convalida el NIF, nombre y apellidos del empleado público que realizó la consulta. Tanto para el caso de que el alta y/o modificación sea realizada por el propio interesado (previo consentimiento expreso) o por un empleado público, se deberá prever que el sistema envíe los datos de forma correcta para poder obtener la respuesta de la consulta realizada. 3.11. Histórico de facturas y organización de archivos asociados. Desde la entrada en vigor de la ley estatal: “Ley 25/2013, de 27 de diciembre, de impulso de la factura electrónica y creación del registro contable de facturas en el Sector Público” y de la orden autonómica: “ORDEN de 26 de febrero de 2015 por la que se regulan el Punto general de entrada de 6

facturas electrónicas y el Registro Contable de Facturas de la Comunidad Autónoma de Galicia” se vio incrementado de forma muy considerable el número de facturas presentadas en el sistema, provocando un aumento considerable del espacio de almacenamiento y una mayor complejidad en la gestión de la información de las facturas y los documentos asociados a misma. En la actualidad la información de las facturas está almacenada en el Gestor de base de datos: SQL Server 2005 y los archivos asociados a las facturas en un sistema de archivos NTFS. Se trata de optimizar el acceso y organización al almacenamiento de la información, garantizando un nivel óptimo de rendimiento. Los oferentes deberán proponer en sus ofertas cuál es modelo de solución para optimizar el almacenamiento de la información de las facturas. 3.12. Emisión de facturas. En la actualidad el SEF permite que los Gestores responsables de la contratación y/o de la gestión económica y la contabilidad de las Entidades del Sector Público Autonómico puedan gestionar electrónicamente las facturas que los proveedores presentan en el Punto General de Entrada de Facturas. El Sistema ha implementado los flujos y la inteligencia necesaria para que los distintos actores que intervienen en la gestión lo hagan de la forma más automatizada posible estando configurado tan sólo como para tramitar facturas recibidas. Debido a que algunas de las entidades que forman parte del Sector Público Autonómico cobran por los servicios que prestan, se hace preciso que las facturas derivadas de los servicios prestados por estas entidad se puedan generar de forma electrónica en formato XML en la versión más actualizada del estándar Facturae con la finalidad de que éstas se puedan transmitir también telemáticamente en dicho formato. Los oferentes deberán especificar en sus ofertas cuál es la propuesta para que el SEF pueda: - Generar Facturas electrónicas en formato facturae (debiendo poder elegir la versión deseada en función del destinatario de la factura). Las facturas deberán poder generarse de forma manual en el propio sistema a través de formularios o en su caso mediante la funcionalidad necesaria que permita recibirlas en archivos XML en el formato Facturae que corresponda. - En caso de que las facturas sean generadas a través de formulario, el sistema debe incorporar la lógica necesaria para realizar todas aquellas validaciones que fueran necesarias para que las facturas sean legalmente válidas. El sistema informará en tiempo real el usuario que está emitiendo la factura de los errores producidos impidiendo generar (emitir) la factura hasta que se cumplan todos los requisitos. - Para el caso de que las facturas sean incorporadas en el sistema a través de un archivo XML en formato Facturae, el sistema también deberá realizar las comprobaciones que fueran necesarias para garantizar que éstas son legalmente válidas (previo su envío el receptor). En caso de que las facturas no sean legalmente válidas, el sistema debe incorporar la lógica necesaria para informar al emisor de la factura (devolviendo las que no son válidas así como los códigos de error y las descripciones de error necesarias) para que en su caso proceda a emitirlas de nuevo. Para el caso de las facturas válidas, también informará al emisor de la factura en el momento que sean entregadas el destinatario. - Para las facturas que sean incorporadas a través de un archivo XML en formato Facturae, el sistema deberá permitir que éstas puedan ser incorporadas al mismo a través de distintas vías: Subirlas directamente en el sistema por un usuario (1), mediante web services (B2B) (2), a través de correo electrónico (3) o a través de otras propuestas por los oferentes (4). Para cualquiera de los casos anteriores se deberá establecer la lógica que fuera preciso para realizar las validaciones y asimismo la información necesaria a enviar al interesado (emisor de la factura). Por ello, se deberán desarrollar los web services que permitan la comunicación automática entre los Sistemas Económico-Financieros de las Entidades y el 7

SEF con la finalidad de que este último pueda recibir las facturas emitidas por los primeros. Los web services deberán contemplar también todo el intercambio de mensajería entre los sistemas (emisor de la factura y SEF). - Una vez que las facturas están incorporadas correctamente en el sistema por cualquiera de las opciones elegidas por el emisor (1-formulario, 2-incorporación de archivos, 3-Web Services 4-Etc.) el sistema ya estará en disposición de poder transmitir las facturas electrónicas de cualquiera de las Entidades del Sector Público Autonómico cara a su receptor. Para ello, los oferentes deberán proponer en sus ofertas los web services necesarios para transmitir las facturas al destino correcto así como el modelo de mensajería necesario para ello y también para informar al emisor de la factura tanto de la correcta presentación de la misma en el destino como de los sucesivos estados de la factura. - El sistema deberá contemplar la diversidad de casuísticas que se pueden producir para el destinatario de una factura (1.-Que el destinatario de la factura sea una entidad pública que ya está integrado en el Punto General de Entrada de Facturas de la Comunidad Autónoma de Galicia (SEF), 2.-Que el destinatario de la factura sea una entidad pública que está integrada en el Punto General de Entrada de Facturas del Estado (FACe), 3.-Que el destinatario de la factura sea una entidad que tiene su propio Punto General de Entrada de Facturas (ya sea público o privado). Para cualquiera de los casos los oferentes deberán prever y proponer cuáles son los servicios web que van a proponer así como los mecanismos o modelo de mensajería propuesto. Para cada uno de los requerimientos descritos anteriormente, los oferentes deberán proponer en sus ofertas cuál es el modelo de solución propuesto. 3.13. Actualización continua El licitador deberá realizar todos aquellos trabajos derivados de la adecuación o, en su caso, de la adaptación del sistema como consecuencia de cambios normativos, cambios tecnológicos etc. en los módulos del sistema cuyas funcionalidades se describen a continuación: a) Adecuación a las modificaciones normativas ocurridas durante la vigencia del contrato En este apartado se incluyen las modificaciones que sea necesario realizar como consecuencia de la aprobación de leyes, reglamentos u otras normas que sean de aplicación durante el período de vigencia del contrato. b) Adecuación a los cambios de versión del estándar Facturae. En este apartado se incluyen las modificaciones que sea necesario realizar en los módulos ya operativos de la aplicación como consecuencia de los cambios de versión de Facturae, que sean de aplicación durante el período de vigencia del contrato. c) Adecuación los cambios de los sistemas de información con los que se comunica el SEF. En este apartado se incluyen las modificaciones que sea necesario realizar en los módulos ya operativos de la aplicación como consecuencia de los cambios en los sistemas de información con los que se comunica el SEF, que sean de aplicación durante el período de vigencia del contrato. d) Actualización tecnológica En este apartado se incluye la adaptación de los sistemas empleados a las modificaciones tecnológicas que podan acontecer durante la vida del contrato y que sean necesarias para el adecuado funcionamiento del Sistema.

8

Está expresamente incluida la posible migración tecnológica a nuevas versiones del software empleado para el desarrollo, así como la modificación de sistemas de ficheros, sistemas operativos y navegadores. e) Rectificación de comportamientos erróneos del sistema En este apartado se incluyen la realización de las modificaciones y adaptación que deban realizarse en el sistema como consecuencia de aquellos funcionamientos erróneos que se detectan por los usuarios durante la vigencia del contrato. Con carácter previo a la modificación debe realizarse un análisis sobre las causas del mal funcionamiento, y el tiempo necesario estimado para su corrección. Este análisis se realizará en un tiempo máximo de 24 horas. El CIXTEC podrá con carácter extraordinario ampliar este plazo atendiendo a la especial complejidad del incidente. Para la gestión de estas actuaciones se utilizará el sistema de gestión de incidentes y peticiones que a tales efectos determine el CIXTEC. f) Rendimiento del sistema. En este apartado se incluyen las modificaciones y adaptaciones que sea necesario realizar en los módulos ya operativos de la aplicación como consecuencia de la elevada utilización del sistema por parte de los usuarios. g) Cambios de estructura orgánica y códigos DIR3 de las entidades adheridas el sistema. En este apartado se incluyen las modificaciones y adaptaciones que sea necesario realizar en los módulos ya operativos de la aplicación como consecuencia de los cambios de estructura orgánica y códigos DIR3 de las entidades adheridas el sistema. 3.14. Evolución de la arquitectura técnica y de nuevas versiones del sistema. La arquitectura técnica actual de la aplicación del SEF es la siguiente: -

Servidor de aplicación: Jboss 5 y .Net Framework sobre IIS 6.

-

Sistema operativo del servidor de aplicación: Windows 2005.

-

Gestor de base de datos: SQL Server 2005.

Los oferentes deberán contemplar que es objeto del contrato todas aquellas actuaciones que fuera preciso realizar para adaptar el sistema a la arquitectura definida en el apartado “Plataforma tecnológica” de este Pliego de Prescripciones Técnicas. Las actuaciones incluyen expresamente cualquier adaptación necesaria para los cambios de versión ya sea del propio sistema o del software que conforma la arquitectura del mismo, y por lo tanto, también la consiguiente migración del sistema operativo, gestor de base de datos, servidor de aplicaciones y herramientas de desarrollo (entorno integrado de desarrollo, gestión de versiones, gestión de dependencias, construcción de aplicaciones, etc.) Cualquier cambio de versión y/o migración del sistema y/o del software que conforma la arquitectura del mismo deberá contemplar las pruebas unitarias, pruebas de integración, pruebas de carga, calidad de código, despliegue de aplicaciones e integración continua así como los mecanismos de comprobación del correcto despliegue de las versiones. Los oferentes deberán proponer en sus ofertas cuál va a ser el procedimiento propuesto para cada una de las fases del ciclo de vida del sistema. 4.

ACTUALIZACIÓN TÉCNICA ESPECÍFICA Y ESPECIALIZADA

El licitador debe contribuir a la actualización técnica en aquellas materias especializadas que tengan relación directa con el objeto del contrato mediante módulos de actualización tecnológica. 9

El módulo debe ser realizado por especialistas en la materia y se referirá a los siguientes contenidos: - Plataformas tecnológicas en las que se desarrollarán los servicios (Arquitectura JEE) - Herramientas de desarrollo, seguimiento y control de proyectos bajo las diferentes arquitecturas utilizadas (Eclipse, Maven, Junit, Subversion) - Gestor de base de datos documental Sharepoint (contexto tecnológico del gestor documental, aplicaciones directas en las búsquedas y organización de la información) La duración de un módulo que contemple todo el contenido referido anteriormente será de 10 horas. 5.

CONDICIONES PARA LA EJECUCIÓN DEL CONTRATO

5.1. Recursos adscritos a la ejecución del contrato - Le corresponde a la empresa adjudicataria en exclusividad la selección del personal, que reuniendo los requisitos establecidos en los Pliegos que rigen la contratación, formarán parte del equipo de trabajo adscrito a la ejecución del contrato, sin perjuicio de la verificación por parte del CIXTEC del cumplimiento de tales requisitos. - La empresa adjudicataria asume la obligación de ejercer de manera real, efectiva y contínua, sobre el equipo de trabajo encargado de la ejecución del contrato, el poder de dirección inherente a todo empresario; así como cuantos derechos y obligaciones se deriven de la relación contractual entre empleado y empleador. - La empresa adjudicataria velará especialmente por que el equipo de trabajo adscrito a la ejecución del contrato desarrolle su actividad sin extralimitaciones en las funciones desempeñadas respecto de la actividad delimitada en los pliegos objeto de la contratación. 5.2. Funcionamiento del equipo de trabajo La empresa adjudicataria deberá designar un coordinador técnico y responsable, integrado en su propia organización, que tendrá entre sus obligaciones: Actuar como interlocutor de la empresa contratista con el CIXTEC, canalizando la comunicación entre la empresa y el equipo de trabajo adscrito a la ejecución del contrato y el CIXTEC, en todo lo relativo a las cuestiones derivadas de la ejecución del contrato. Distribuir el trabajo entre el personal encargado de la ejecución del contrato y transmitir al equipo de trabajo las órdenes e instrucciones de trabajo que sean necesarias en relación con la prestación del servicio contratado. Supervisar el correcto desempeño por parte de los integrantes del equipo de trabajo de las funciones que tienen encomendadas, así como su asistencia. Organizar el régimen de vacaciones del personal adscrito a la ejecución del contrato, debiendo a tal efecto, coordinarse adecuadamente la empresa adjudicataria con el CIXTEC, a los efectos de no alterar el buen funcionamiento del servicio. Informar al CIXTEC acerca de las variaciones, ocasionales o permanentes, en la composición del equipo de trabajo adscrito a la ejecución del contrato. 5.3.

Modificación del equipo de trabajo

La empresa adjudicataria procurará que exista estabilidad en el equipo de trabajo y que las variaciones en su composición sean puntuales y obedezcan a razones justificadas, en orden a no alterar el buen funcionamiento del servicio, informando en todo momento al CIXTEC. 10

5.4. Lugar de realización del objeto del contrato La empresa adjudicataria estará obligada a ejecutar el contrato en sus dependencias e instalaciones, salvo que, excepcionalmente, sea autorizada a prestar sus servicios en el CIXTEC. Para la realización del objeto de esta contratación los miembros del equipo de trabajo estarán obligados a desplazarse a las dependencias de la Consellería de Facenda o CIXTEC, o a cualquier otra localización de la mencionadas en el pliego cuando las necesidades del proyecto así lo exijan. El importe de los gastos de desplazamiento y dietas forma parte del precio del contrato, no pudiendo el adjudicatario repercutir al CIXTEC ninguna cuantía adicional por estos motivos. 5.5. Plataforma tecnológica La plataforma tecnológica en la que se desarrollará el servicio está basada en la arquitectura técnica Java Platform, Enterprise Edition (JEE) descrita a continuación. 5.5.1.

Arquitectura tecnológica JEE

Con el objeto de la homogeneización de los ciclos de desarrollo y operación de los sistemas de información, reducir la complejidad en su construcción, evolución y despliegue, así como garantizar la integración e interoperabilidad de éstos, el CIXTEC ha definido un modelo global de arquitectura tecnológica JEE, al que se deberán ajustar todos los desarrollos de aplicaciones. La arquitectura tecnológica JEE está dividida en tres grandes bloques: -

Arquitectura de desarrollo, que recoge las especificaciones del entorno de desarrollo y las herramientas a utilizar.

-

Arquitectura de ejecución, que determina el ambiente de ejecución de las aplicaciones, especificando un conjunto de componentes con funciones concretas dentro de las mismas.

-

Arquitectura técnica, que define la infraestructura donde se ejecutan las aplicaciones: JVM, servidor de aplicaciones y servidor de base de datos, entre otros. 5.5.2.

Arquitectura de desarrollo

A continuación se describe el entorno de desarrollo para la creación y gestión del desarrollo de aplicaciones del CIXTEC. 5.5.2.1.

Gestión de la configuración

Los objetivos de la gestión de la configuración son el control de los cambios realizados sobre una aplicación y la disponibilidad constante de una versión estable. Un sistema de control de versiones proporciona un mecanismo para el almacenamiento de los elementos que se deben gestionar, posibilitando la realización de cambios sobre esos elementos y un registro de todas las acciones realizadas con cada uno de ellos. La gestión de la configuración en el desarrollo de aplicaciones se realizará mediante la integración con el sistema de control de versiones implantado en el CIXTEC. Este sistema está basado en Apache Subversion, sistema open source de control de versiones con un modelo de repositorios centralizado. La utilización del sistema de control de versiones en el desarrollo de aplicaciones deberá ajustarse al contenido de la “Guía de utilización del Sistema de Control de Versiones”. 5.5.2.2.

Pruebas y validación

La fase de pruebas es una de las principales fases del ciclo de vida de una aplicación y de ella depende en gran medida el grado de calidad del producto final, por eso se hace necesaria la realización de un esfuerzo importante para su su diseño y ejecución. 11

Los distintos tipos de pruebas existentes, hacen necesario el uso de distintas herramientas para su desarrollo y automatización: -

Pruebas unitarias: se realizarán mediante el uso de las librerías open source JUnit y Mockito.

-

Pruebas funcionales: para la realización de pruebas funcionales se utilizará la suite de herramientas open source Selenium.

-

Pruebas de carga: se realizarán mediante la utilización de la herramienta open source Apache JMeter.

5.5.2.3.

Gestión de dependencias y gestión de proyectos

La mayor parte de los proyectos de desarrollo de software precisan de la utilización de componentes ya existentes y desarrollos de terceros, lo que provoca la existencia de una serie de dependencias sobre estos componentes y deber a realizar una gestión de las mismas de manera automatizada. Apache Maven es una herramienta open source para la gestión de dependencias y construcción de proyectos, que permite la definición de repositorios de componentes propios y de terceros, el control de la construcción del proyecto (build), su compilación, la automatización de la ejecución del análisis estático del código fuente y de las pruebas unitarias, la generación de paquetes y la obtención de informes y documentación. En los desarrollos de aplicaciones del CIXTEC se utilizará la herramienta Apache Maven 2, y se hará uso de los repositorios habilitados donde se encuentran los componentes autorizados (propios y de terceros) para utilizar en el desarrollo de aplicaciones. Si un proyecto necesita de un componente no incluido en la relación de librerías autorizadas, deberá solicitar la aprobación de su utilización. 5.5.2.4.

Entorno integrado de desarrollo

Para el desarrollo de aplicaciones del CIXTEC se usará como entorno integrado de desarrollo (ID) de referencia a plataforma Eclipse for Java EE Developers. Para la integración con los demás elementos que forman parte del entorno de desarrollo se utilizarán las siguientes herramientas integradas en Eclipse: Integración con la herramienta de gestión de dependencias y construcción de proyectos (Apache Maven): m2eclipse. Integración con el sistema de control de versiones (Apache Subversion): Subclipse. Herramientas para el análisis estático del código fuente: CheckStyle, FindBugs, PMD. 5.5.2.5.

Plataforma de desarrollo

Las aplicaciones del CIXTEC se desarrollarán bajo las especificaciones definidas por la plataforma Java EE 6, mediante la utilización del Oracle Java Development Kit 6 (JDK 6). 5.5.3.

Arquitectura de ejecución

La arquitectura de ejecución define el funcionamiento de la aplicación en ejecución. Esta arquitectura define los patrones y tecnologías a utilizar en la implementación de la aplicación. 5.5.3.1.

Modelo de arquitectura en capas

El modelo de arquitectura de software de las aplicaciones estará basado en la división en capas que tiene como objetivo fundamental a separación de la lógica de negocio de la lógica de diseño de la aplicación. 12

La división en capas se establecerá según el siguiente modelo: -

Capa de presentación. Esta capa comprende todos los aspectos relacionados con la interacción con los usuarios (presentación de la información, captura de la información, eventos de usuario, …)

-

Capa de negocio. Los servicios de negocio comprenden toda la lógica de negocio de un sistema. Debe ser vista como un conjunto de servicios expuestos a la capa de presentación o a otros sistemas.

-

Capa de acceso a datos. La capa de persistencia es la encargada de servir de puente entre la capa de negocio y el proveedor de datos, encapsulando las especificidades de éste.

Además, existirán una serie de servicios comunes que ofrecerán las funcionalidades necesarias para realizar tareas relacionadas con la gestión de trazas, gestión de cachés, internacionalización y gestión de excepciones. 5.5.3.1.1.

Capa de presentación

La capa de presentación es la que presenta el sistema al usuario, comunicándole la información al usuario y capturando la información del usuario. Esta capa se comunica únicamente con la capa de negocio. También es conocida cómo interfaz gráfica y debe tener la característica de ser "amistosa" (comprensible y fácil de usar) para el usuario. Esta capa se debe limitar únicamente a la solicitud o presentación de información al usuario y nunca deberá realizar procesos ni toma de decisiones sobre los datos. Particularmente, las clases “controlador” nunca deberán contener ninguna lógica de negocio. En el diseño de la capa de presentación se utilizará el patrón de diseño MVC, que divide la aplicación en tres áreas de responsabilidad: modelo, vista y controlador. Para su implementación se usarán las funcionalidades ofrecidas por el framework Spring MVC. Para la generación de las vistas se utilizarán conjuntamente las tecnologías JSP, JSLT y Apache Tiles. Para la definición y gestión de flujos de navegación entre páginas dentro de la aplicación se utilizará el módulo Spring Web Flow. 5.5.3.1.2.

Capa de negocio

En esta capa se desarrollarán los componentes de servicio que dan soporte a la capa de presentación y a la integración con otros sistemas de información. En ella se implementará la lógica de la aplicación, de los procesos de negocio y en general toda la lógica de operaciones no persistentes. Consistirá en un conjunto de servicios con interfaces bien definidos, facilitando de este modo la adopción de una arquitectura orientada a servicios (SOA). Aquellos servicios con una funcionalidad de negocio reutilizable por otros sistemas podrán ser expuestos en forma de servicios web. Para el resto de casos, se emplearán servicios de negocio implementados como clases Java simples (POJOs) con una clara orientación a servicio, haciendo uso de las funcionalidades que el framework Spring ofrece. Se evitará el uso de la tecnología EJB. 5.5.3.1.3.

Capa de acceso a datos

El acceso a datos es una de las tareas más críticas que pueden existir en un sistema de información. Los componentes que conforman una aplicación deben ser independientes de la fuente de datos, de manera que se posibilite la utilización de distintos medios de almacenamiento, facilitar la 13

migración de un SGBD a otro, etc. Una capa de persistencia se encarga de recuperar, insertar, actualizar y borrar datos en el almacenamiento persistente (base de datos). Para encapsular y lograr la abstracción del acceso a los orígenes de datos se usará el patrón Data Access Object (DAO) y el patrón Object Relational Mapping (ORM) proporcionado por Hibernate integrado con Spring. Los componentes DAO darán servicio a la capa de negocio de la aplicación y utilizarán objetos de dominio para la comunicación de datos a la misma. Si en una determinada aplicación el acceso a datos es residual podrá optarse por otras implementaciones basadas únicamente en DAO, sin necesidad de utilizar el patrón ORM. 5.5.3.1.4.

Servicios comunes

Para la implementación de las funcionalidades transversales, y con el fin de mantener una homogeneidad entre aplicaciones se usarán las tecnologías detalladas a continuación: -

Validación de datos: Hibernate Validation

-

Internacionalización: Spring i18n

-

Trazas: Simple Logging Facade for Java (slf4j) + Log4J

-

Publicación y consumo de servicios: Apache CXF para la implementación de las especificaciones JAX-WS y JAX-RS .

-

Generación de informes: JasperReports + iText

-

Inyección de dependencias (DI): Spring

-

Criptografía: BouncyCastle

-

Monitorización: JMX + Spring AOP 5.5.4.

Arquitectura técnica

La infraestructura donde tiene lugar la ejecución de las aplicaciones está conformada por los elementos detallados a continuación. 5.5.4.1.

Cliente

Se deberán utilizar tecnologías abiertas que permitan el acceso desde distintas plataformas cliente cumpliendo con el principio de neutralidad tecnológica, evitando utilizar soluciones que sólo funcionen bajo determinados sistemas operativos. Los sistemas operativos cliente a tener en cuenta son: -

Microsoft Windows (XP, Windows Vista, Windows 7, Windows 8.1)

-

Apple Mac OS X

-

Linux

Las aplicaciones que requieran del uso de un navegador web, serán compatibles con los navegadores de uso más extendido, entre los que deberán figurar al menos los siguientes: -

Internet Explorer (versiones 8, 9, 10 y superiores)

-

Google Chrome

-

Mozilla Firefox

-

Safari

14

5.5.4.2.

Servidor

En el entorno servidor distinguimos los siguientes elementos: -

Las aplicaciones se desplegarán en servidores de aplicaciones JBoss EAP 6 configurados en alta disponibilidad y tolerancia a fallos mediante su agrupación en clúster. Estos servidores harán uso del Oracle JDK 6. Se evitarán tecnologías particulares asociadas a un determinado servidor de aplicaciones, con el fin de lograr la compatibilidad con cualquier servidor certificado para Java EE 6 Full Profile.

-

El sistema de gestión de base de datos utilizado por las aplicaciones como mecanismo de almacenamiento persistente será Microsoft SQL Server 2008 R2.

La versión de sistema operativo sobre la que se ejecuta el servidor de aplicaciones es Red Hat Enterprise Linux 6.5, mientras que el sistema de gestión de base de datos se ejecuta sobre servidores Microsoft Windows Server 2008 R2. 5.6. Medios físicos y lógicos El adjudicatario deberá contar con los medios propios, de toda índole, necesarios para llevar a cabo con éxito los trabajos objeto del contrato. Los medios físicos y lógicos utilizados por el adjudicatario deben ser compatibles y adecuados para dar cumplimiento a los elementos y tareas que constituyen el objeto del contrato y que se describen en los apartados “OBJETO DEL CONTRATO” y “ DESCRIPCIÓN DE LOS TRABAJOS A REALIZAR” de este pliego de prescripciones técnicas. El adjudicatario aportará por su cuenta, las herramientas hardware y software complementarios y que se estime pertinentes para el mejor cumplimiento de las prestaciones que constituyen el objeto del contrato. Estas herramientas deben ser compatibles con las utilizadas por el CIXTEC y su uso requiere de la autorización previa del CIXTEC. Los oferentes deberán contar con los medios técnicos necesarios para la conexión remota con el CIXTEC desde sus dependencias, así como del equipo hardware y licencias software imprescindibles para la prestación remota del servicio. Todos estos medios deberán adaptarse a las modificaciones de los requerimientos que en su caso pueda establecer el CIXTEC en el plazo de vigencia del contrato. El coste de los equipos y licencias irá en todo caso por cuenta del adjudicatario. 5.7. Metodología de trabajo La planificación, ejecución, análisis, construcción e implantación de aplicaciones o sistemas TIC se ajustarán a la metodología Métrica V3, de gestión de proyectos para cada unidad o módulo que se realice al amparo de este contrato. La empresa adjudicataria será responsable del correcto uso de los entornos de desarrollo así como del paso a preproducción de las nuevas versiones de los productos, de acuerdo con las especificaciones remitidas desde el CIXTEC. 5.8. Calidad de los trabajos El adjudicatario se compromete a realizar los trabajos que constituyen el objeto del presente contrato de acuerdo con los estándares profesionales más elevados. En la ejecución del presente contrato el adjudicatario estará obligado, de acuerdo con las circunstancias, a emplear a su propio personal de la mayor cualificación. Durante el desarrollo de los trabajos y en la ejecución de las diferentes fases del proyecto el CIXTEC podrá establecer controles de calidad sobre la actividad desarrollada y las aplicaciones, 15

siempre en el marco del plan de calidad aplicable. En todo caso, el adjudicatario entregará mensualmente al director técnico un informe de estado del proyecto en curso. Las revisiones remitidas al CIXTEC deberán estar en condiciones de poder ser puestas en funcionamiento. El adjudicatario deberá elaborar un Plan de pruebas y realizar y documentar las pruebas necesarias para garantizar esta circunstancia. El personal del CIXTEC podrá testar los resultados aportados por el adjudicatario. En el caso de detectarse por el personal del CIXTEC defectos o deficiencias que desaconsejen la implantación en producción de la revisión remitida, estas deberán ser solucionadas en el plazo máximo de 5 días a contar desde la notificación por parte del CIXTEC. Cuando de los controles de calidad realizados se deduzca que la calidad de los servicios no es la adecuada, el CIXTEC requerirá del adjudicatario la adopción de las medidas que sean necesarias para corregir la situación. Estas medidas pueden incluir la realización de modificaciones en el equipo de trabajo. El incumplimiento por el adjudicatario de las medidas requeridas puede dar lugar a penalizaciones e incluso a la resolución del contrato por parte del CIXTEC, al no adecuarse el servicio prestado a las condiciones de calidad exigida. 5.9. Entrega del código fuente El código fuente resultante de los desarrollos realizados es de propiedad exclusiva del CIXTEC. Con cada entrega parcial que se realice, la empresa entregará además de los ejecutables y de la documentación, la versión correspondiente del código fuente así como todos los elementos necesarios para la correcta implantación del desarrollo entregado en los entornos de preproducción y producción. La empresa adjudicataria no podrá, en ningún caso, utilizar o ceder a un tercero todo o parte del código sin la expresa autorización del CIXTEC, debidamente documentada. 5.10. Documentación de los trabajos El adjudicatario se compromete a generar para cada producto obtenido toda la documentación que le sea requerida por el CIXTEC. La documentación elaborada constará como mínimo de los siguientes documentos: -

Especificación de requisitos

-

Análisis funcional

-

Arquitectura técnica

-

Diseño técnico

-

Plan de pruebas

-

Documento de instalación

-

Plan y guía de implantación

-

Manual de Administración y Operación

-

Plan de Contingencia

-

Resumen técnico de las modificaciones sufridas por el producto desde la última revisión

-

Manual de usuario completo y actualizado con los cambios y nuevas versiones

-

Guía rápida de usuario, en la que figuren las modificaciones que el producto haya sufrido desde la última modificación

La documentación se realizará de acuerdo con el formato y estructura definido por el CIXTEC.

16

La documentación es propiedad exclusiva del CIXTEC sin que el contratista pueda conservarla, ni obtener copia de ella o facilitarla a terceros sin la expresa autorización del CIXTEC. El adjudicatario se compromete a entregar el número de ejemplares y el soporte de la documentación que el CIXTEC determine. 5.11. Formación del personal de la empresa adjudicataria La formación del personal del adjudicatario correrá por cuenta de él, no asumiendo el CIXTEC, en ningún caso, ningún coste derivado de la formación 6.

CONFIGURACIÓN DE LA OFERTA

La oferta presentada deberá detallar de forma exhaustiva los trabajos y condiciones que constituyen el compromiso de la empresa, con sujeción a lo dispuesto en este Pliego de Prescripciones Técnicas. La oferta deberá ser elaborada en la forma prevista en el apartado “2 Forma” de la cláusula “7 Licitación” del Pliego de Cláusulas Administrativas. La estructura de los documentos que configuran la oferta debe adaptarse al siguiente esquema: 6.1. Oferta técnica 6.1.1.

Enfoque global

Este apartado tiene por objeto mostrar el conocimiento funcional del licitador y el conocimiento del contexto real y operativo en el que se van a llevar a cabo los desarrollos incluidos en el objeto del contrato. El licitador deberá exponer con carácter genérico y detallado cuál es la situación actual del contexto funcional en el que se enmarcan los procedimientos y requerimientos funcionales a los que atiende el objeto de esta contratación. En la exposición debe especificarse con claridad la situación actual de los desarrollos exigidos en este contexto funcional. La exposición puede incluir un esquema gráfico en el que se visualicen las relaciones funcionales y tecnológicas existentes. En caso de que el licitador plantee cambios en el modelo actual, debe incluir por separado la exposición del modelo actual y la exposición del modelo resultante como consecuencia de las modificaciones propuestas. 6.1.2.

Descripción detallada de la propuesta.

En este apartado el licitador debe concretar al mayor nivel de detalle posible cuál es su oferta para dar solución a los requerimientos exigidos en los apartados en los apartados “OBJETO DEL CONTRATO” y “ DESCRIPCIÓN DE LOS TRABAJOS A REALIZAR” de este Pliego de prescripciones técnicas Deben incluirse como mínimo todos los elementos detallados en estos apartados, excepto en el caso en que específicamente se recoja en este pliego su carácter no obligatorio. 6.1.3.

Diseño de la arquitectura técnica

En este apartado deberán relacionarse todos los elementos técnicos que van a ser utilizados por el licitador en la ejecución del contrato. Deberán detallarse las compatibilidades con los elementos tecnológicos utilizados por el CIXTEC, y las posibles sinergias o evoluciones en función del estado de la tecnología y de las versiones utilizadas. 17

Los elementos propuestos deben respetar las condiciones de ejecución fijadas en el apartado “CONDICIONES PARA LA EJECUCIÓN DEL CONTRATO” de este pliego de prescripciones técnicas. 6.2. Plan de trabajo 6.2.1.

Enfoque metodológico

En este apartado se expondrá la metodología propuesta por el adjudicatario para la planificación, ejecución, análisis, construcción e implantación de las aplicaciones o sistemas TIC que constituyen el objeto del contrato. Deben incluirse expresamente las medidas propuestas por el adjudicatario para garantizar la calidad de los trabajos realizados. Los sistemas expuestos deben respetar las condiciones de ejecución fijadas en el apartado “CONDICIONES PARA LA EJECUCIÓN DEL CONTRATO” de este pliego de prescripciones técnicas. 6.2.2.

Programación

En este apartado debe recogerse en detalle a programación temporal de la ejecución de las tareas propuestas durante toda la vigencia del contrato. Podrán indicarse los recursos destinados la cada tarea así como la dedicación parcial o exclusiva de los mismos en cada momento. Se debe incluir un cronograma y el detalle de la propuesta de tareas a realizar para la ejecución del contrato. Se detallará el alcance y contenido de las actividades y tareas contempladas en el proyecto, del cronograma empleado, así como el detalle de la propuesta de ejecución del contrato. Deberá incluir métodos de camino crítico tipo PERT o CPM, y el diagrama de Gantt completo de todas las tareas y subtarefas contempladas en la oferta del licitador. 6.3. Precio Ver apartado “Documentación relativa los criterios evaluables de forma automática por aplicación de fórmulas” y el ANEXO PE080R”PROPOSICIÓN ECONÓMICA” del Pliego de Cláusulas Administrativas. 6.4. Actualización técnica Ver apartado “Documentación relativa los criterios evaluables de forma automática por aplicación de fórmulas” y el ANEXO MO090R”ACTUALIZACIÓN TÉCNICA” del Pliego de Cláusulas Administrativas. Santiago de Compostela, a 26 de enero de 2016 El Director General del CIXTEC

Fdo.: M. Mauro Fernández Dabouza

18