DIRECCIÓN DE TECNOLOGÍA Y SISTEMAS

Transcripción

1 DIRECCIÓN DE TECNOLOGÍA Y SISTEMAS SUBDIRECCIÓN DE SISTEMAS DE GESTION XX09NNNN PLIEGO DE CONDICIONES TÉCNICAS CONSTRUCCION, MANTENIMIENTO Y MEJORAS EVOLUTIVAS DE LOS Septiembre 2009

2 ÍNDICE 1. OBJETO DEL CONTRATO CARACTERÍSTICAS DEL SISTEMA PRESTACIONES A REALIZAR LOTE 1: SOPORTE Y ATENCIÓN A CLIENTES LOTE 2: MANTENIMIENTO Y EVOLUCIÓN DE OPV, PEC Y ADO Mantenimiento correctivo, preventivo y perfectivo de OPV, PEC y ADO Mejoras evolutivas de la OPV, el PEC y el ADO LOTE 3: MANTENIMIENTO Y EVOLUCIÓN DE OV2 Y CONSTRUCCIÓN DE NUEVOS SERVICIOS Mantenimiento correctivo, preventivo y perfectivo de la OV Construcción de nuevos servicios de la OV Mejoras Evolutivas de la OV2: REQUISITOS DE LAS PRESTACIONES A REALIZAR PRODUCTOS FINALES EQUIPO DE TRABAJO PLAZO DE EJECUCIÓN FORMACION CONTROL DE CALIDAD OTRAS CONDICIONES ACUERDO DE NIVEL DE SERVICIO (ANS) Lote 1: Soporte y Atención a clientes Lote 2: Mantenimiento y evolución de OPV, PEC y ADO Lote 3: Mantenimiento y evolución de OV2 y construcción de nuevos servicios SISTEMA DE SEGUIMIENTO CONDICIONES DE PRESTACIÓN DEL SERVICIO REQUERIMIENTOS METODOLÓGICOS Página 2 de 91

3 9.5. OTROS REQUERIMIENTOS Procedimiento de valoración de las mejoras de carácter evolutivo Procedimientos de Control y Seguimiento de los trabajos PRESUPUESTO ALTERNATIVAS Y NEGOCIACIÓN FORMA DE PAGO PLAN DE FACTURACIÓN ASPECTOS GENERALES Lote 1: Soporte y Atención a clientes Lote 2: Mantenimiento y evolución de OPV, PEC y ADO Lote 3: Mantenimiento y evolución de OV2 y construcción de nuevos servicios DETALLE DEL PLAN Lote 1 Soporte y Atención a clientes Lote 2 Mantenimiento y evolución de OPV, PEC y ADO Lote 3 Mantenimiento y evolución de OV2 y construcción de nuevos servicios PERÍODO DE GARANTÍA PRESENTACIÓN DE OFERTAS Y DOCUMENTACIÓN REQUERIDA...77 SOLICITUDES DE PARTICIPACIÓN Y PRESENTACIÓN DE OFERTAS DOCUMENTACIÓN ECONÓMICA VALORACIÓN DE OFERTAS PUNTUACIÓN GLOBAL (PG) PUNTUACIÓN TÉCNICA (PT) Lote 1 Soporte y Atención a clientes Lote 2 Mantenimiento y evolución de OPV, PEC y ADO Lote 3 Mantenimiento y evolución de OV2 y construcción de nuevos servicios PUNTUACIÓN ECONÓMICA (PE) Página 3 de 91

4 16. SUBCONTRATACIÓN DIRECCIÓN TÉCNICA DEL PROYECTO PROPIEDAD INDUSTRIAL E INTELECTUAL CONFIDENCIALIDAD Y PROTECCIÓN DE DATOS PERSONALES...87 ANEXO 1 CUESTIONARIO DE PERSONAL...90 Página 4 de 91

5 1. OBJETO DEL CONTRATO El presente Pliego tiene por objeto la contratación de los servicios necesarios para realizar la construcción, el mantenimiento, soporte y mejoras evolutivas de los sistemas transaccionales de Internet de Correos (en adelante los STI). Los STI lo conforman la Oficina Virtual (OPV), el Portal de Entidades Colaboradoras (PEC), el Portal de Acceso a la Red Postal (ADO) y la nueva Oficina Virtual (OV2). Los servicios a contratar serán: o El soporte técnico de segundo nivel y la atención a clientes de los STI. o El mantenimiento permanente (correctivo y preventivo), la incorporación de evolutivos (nuevos servicios y productos) y el soporte de tercer nivel de los sistemas OPV, PEC y ADO. o La construcción de nuevo productos y servicios, el mantenimiento permanente, la incorporación de evolutivos de productos y/o servicios existentes y el soporte de tercer nivel en la OV2. El presente Pliego se divide en tres lotes independientes que podrán ser adjudicados por separado: LOTE Lote 1 Lote 2 Lote 3 PROYECTO Soporte y Atención a clientes Mantenimiento y evolución de OPV, PEC y ADO Mantenimiento y evolución de OV2 y construcción de nuevos servicios Los licitadores podrán presentarse a uno o varios de los lotes, pudiendo presentar una oferta integradora que aporte valores añadidos a la oferta. 2. CARACTERÍSTICAS DEL SISTEMA El conjunto de servicios que actualmente ofrecen los STI pueden agruparse en dos partes diferenciadas según la plataforma tecnológica que los soporta: 1. Los servicios ofrecidos por los sistemas cuya plataforma tecnológica está basada en las arquitecturas DNA y.net de Microsoft con una estructura en tres capas: OPV-PEC-ADO o Presentación. IIS (Internet Information Server). Páginas ASP. Soluciones desatendidas masivas y web services. Informes en Crystal Reports. o Negocio. Objetos COM+ desarrollados en Visual Basic, C++, y.net. Página 5 de 91

6 o Base de datos. SQL Server o Windows 2003 Advanced Server. o Además la plataforma corporativa de Correos emplea para la integración entre sistemas: Integración a través del bus Webpshere MQ/Broker 6.0 de IBM, siguiendo las normas publicadas en la intranet de Correos Spazio de Primeur, siguiendo las normas de Correos, siendo necesaria la aportación de la licencia del cliente software en su caso. Estos servicios (OPV-PEC-ADO) están formados por los siguientes sites : Frontal web ( Dentro de este frontal actualmente se dispone de los siguientes servicios: envíos de cartas y documentos, envío de paquetería, filatelia, cambio de domicilio y apartado postal electrónico. Además dentro de este frontal se gestionan soluciones masivas y desatendidas de estos servicios para grandes clientes (notificaciones digitales, telegramas online y telefónicos, burofax, PRISMAS, EPG, etc.) y marcas blancas de los mismos (correo digital, telegramas, etc.), así como su integración con el resto de Sistemas de Información de Correos. La plataforma dispone de varios sistemas de pago: TPV-virtual, PayPal y con cargo a un contrato de gran cliente con Correos. Frontal de admisión de servicios online que permite la admisión, en oficinas y unidades de admisión masiva, de los productos de la OPV y la generación de los informes de explotación correspondientes. Este frontal incluye además los frontales de control de producción de envíos de Correo Digital. Este frontal es de uso exclusivo de personal interno de correos. Frontal de atención al cliente de soporte para la gestión de los diferentes niveles de Atención al Cliente y para la gestión contable de los servicios del portal. Frontal post-venta de explotación del servicio para la gestión comercial y de incidencias. Frontal de convivencia con la OV2 que permita la gestion integrada de envíos independiente del sistema que los gestiona. PEC: Portal de entidades colaboradoras, Frontal destinado a que las empresas que colaboran con Correos puedan realizar sus gestiones de forma Online. Se compone de frontales tanto para las entidades colaboradoras como para la gestion interna de su actividad (admisión y gestion comercial y financiera) ADO: Portal de Acceso a la Red, es un portal dedicado a los operadores postales para el acceso a Correos. Servicios en OutSourcing: Servicios Internet que ofrece correos y que están alojados externamente Página 6 de 91

7 Tu sello: permite la realización de pliegos de sellos personalizados Cambio de domicilio: servicio que se presta a aquellos ciudadanos que realicen un cambio de domicilio y quieran informar a empresas afiliadas. Correo Electrónico Seguro-Apartado postal electrónico Servicios sindicados: Estos servicios suponen la integración de algún servicio/producto de correos dentro de los portales de terceros (ej. e-bay). 2. Los servicios ofrecidos por los sistemas cuya plataforma tecnológica está basada en arquitectura J2EE: OV2 o IBM WebSphere Application Server Network Deployment Version 7.0 o IBM HTTP Server 7 o Oracle 11g o J2EE 1.4 o Además la plataforma corporativa de Correos emplea para la integración entre sistemas: Integración a través del bus Webpshere MQ/Broker 6.0 de IBM, siguiendo las normas publicadas en la intranet de Correos Spazio de Primeur, siguiendo las normas de Correos, siendo necesaria la aportación de la licencia del cliente software en su caso. Estos servicios (OV2) están formados por los siguientes sites : Frontal web. Conviviendo con el sistema basado en DNA en este frontal actualmente se dispone del servicio de preparación de envíos nacionales en la modalidad de Postal Expres. También dentro de este frontal se gestionan soluciones masivas y desatendidas de este servicio para grandes clientes y marcas blancas así como su integración con el resto de Sistemas de Información de Correos. Frontal web con funcionalidades de BackOffice internas de la compañía. Este BackOffice proporciona servicios de Atención al cliente, Informes y alertas y administración de presentación del frontal de clientes Sistema de aseguramiento de la convivencia e integración con la OPV, PEC y ADO (en J2EE y.net) Página 7 de 91

8 3. PRESTACIONES A REALIZAR El servicio contratado en cada lote deberá responder a las necesidades de los STI con sujeción a los parámetros de calidad comprometidos en el correspondiente Acuerdo de Nivel de Servicio para la realización de las siguientes prestaciones: 3.1. Lote 1: Soporte y Atención a clientes Dentro de este lote, las prestaciones a realizar son: Soporte telefónico de segundo nivel a clientes y usuarios internos para la resolución de dudas relacionadas con la funcionalidad y operativa de los servicios que ofrezca Correos a través de los STI (OPV, PEC, ADO, OV2). Registro de las dudas planteadas por los clientes y usuarios así como documentación de la resolución las mismas mediante las herramientas que Correos determine. Resolución de consultas, generación de informes y gestión de alertas planteadas por los gestores del sistema. Realización de tareas de administración del sistema Lote 2: Mantenimiento y evolución de OPV, PEC y ADO El servicio contratado deberá responder a las necesidades de mantenimiento permanente, soporte técnico de tercer nivel a clientes y usuarios y mejoras en la que estos portales requieran en cada momento (OPV, PEC y ADO) para responder a las necesidades de Correos, así como la incorporación de mejoras evolutivas en dichos portales con sujeción a los parámetros de calidad comprometidos en el correspondiente Acuerdo de Nivel de Servicio, incluyendo la realización de las siguientes prestaciones: Mantenimiento correctivo, preventivo y perfectivo de OPV, PEC y ADO Elaboración de un estudio de auditoria y documentación del estado del sistema periódico. Resolución de las incidencias en los módulos funcionales que componen los sistemas objeto del contrato y documentación de la solución a las mismas mediante las herramientas que Correos determine (actualmente ARS-Remedy). En este sentido el servicio contratado incluye las tareas de soporte de tercer nivel para OPV, PEC y ADO, así como sus sistemas asociados. Realización de las adaptaciones/modificaciones necesarias a los módulos funcionales que estuvieran en producción, para su Página 8 de 91

9 corrección y optimización, así como para incorporar posibles cambios requeridos por Correos. Administración, control y seguimiento de los servicios ofrecidos a través del canal. Mantenimiento y actualización/elaboración de toda la documentación funcional correspondiente. Transmisión de formación, información y conocimientos al personal técnico de soporte de Correos, al personal del CAU y a los clientes y usuarios, según las necesidades del servicio. Resolución de consultas, generación de informes ad-hoc y gestión de alertas planteadas por los gestores del sistema Mejoras evolutivas de la OPV, el PEC y el ADO Análisis de nuevos servicios a incorporar a la OPV, PEC, ADO y sus diferentes frontales, incluyendo la recogida de requerimientos de negocio (calidad de servicio, de diseño, imagen, criterios de accesibilidad, estándares, contenidos, etc.) y técnicos (arquitectura, disponibilidad, seguridad, rendimiento, accesibilidad de navegadores y plataformas de cliente, etc.) Elaboración de prototipos y su documentación asociada que presenten a Correos diversas opciones sobre el nivel de servicio, diseño gráfico y arquitectura de los contenidos y nuevos servicios del portal. Diseño, construcción e implantación de nuevos servicios, incluyendo la definición del entorno tecnológico (hardware y software), la elaboración del diseño técnico y de casos de pruebas, la construcción del servicio, su validación e implantación adjuntado con la documentación y certificaciones definidas en la metodología MARCO de Correos. Traducción de todos los contenidos en los distintos idiomas del STI Formación a los usuarios y elaboración de los manuales de formación necesarios. Construcción de los evolutivos de servicios o redefinición de los existentes, entre los que se incluye: A. Integración con la OV2. - Definición de los procesos e interfases que permitan la convivencia de las nuevas funcionalidades que se implementen sobre OV2 con OPV. PEC, ADO y sus sistemas asociados. Página 9 de 91

10 - Construcción y realización de pruebas de integración de los desarrollos necesarios sobre OPV, PEC, ADO y sus sistemas asociados para la citada convivencia. B. Comercialización de nuevos productos y herramientas: - Adaptación del PEC al nuevo marco contractual con las Entidades Colaboradoras. - Incorporación de la nueva cartera de productos prevista para el 2010 y 2011 y/o adaptación de los productos existentes a su nueva tarificación. Adaptación a los cambios de tarifas. - Gestión de campañas comerciales. - Rediseño del servicio de Correo Digital y la integración con Correo Híbrido. - Integración con plataformas de medios de pago. - Extensión del modelo de AR electrónico a los productos del canal y a los distintos sites C. Mejoras operativas y técnicas de las plataformas - Adaptación y creación de interfaces con otros sistemas de Información de Correos: por ejemplo, conversor de PDF s, sistemas de servicios telegráficos, SAP, SGId, etc. - Adaptación a la nueva normativa de Correos: códigos de barras, etiquetados, etc. - Resolución de vulnerabilidades Lote 3: Mantenimiento y evolución de OV2 y construcción de nuevos servicios El servicio contratado deberá responder a las necesidades de construcción, mantenimiento permanente, soporte técnico de tercer nivel a clientes y usuarios y mejoras evolutivas de la OV2 con sujeción a los parámetros de calidad comprometidos en el correspondiente Acuerdo de Nivel de Servicio, incluyendo la realización de las siguientes prestaciones: Mantenimiento correctivo, preventivo y perfectivo de la OV2 Elaboración de un estudio de auditoria y documentación del estado del sistema periódico. Resolución de las incidencias en los módulos funcionales que componen los sistemas objeto del contrato y documentación de la solución a las mismas mediante las herramientas que Correos Página 10 de 91

11 determine (actualmente ARS-Remedy). En este sentido el servicio contratado incluye las tareas de soporte de tercer nivel para OV2. Realización de las adaptaciones/modificaciones necesarias a los módulos funcionales que estuvieran en producción, para su corrección y optimización, así como para incorporar posibles cambios requeridos por Correos. Administración, control y seguimiento de los servicios ofrecidos a través del canal. Mantenimiento y actualización/elaboración de toda la documentación funcional correspondiente. Transmisión de formación, información y conocimientos al personal técnico de soporte de Correos, al personal del CAU y a los clientes y usuarios, según las necesidades del servicio. Resolución de consultas, generación de informes ad hoc y gestión de alertas planteadas por los gestores del sistema Construcción de nuevos servicios de la OV2 Creación de nuevos módulos de negocio y servicios sobre la plataforma OV2 de acuerdo a las especificaciones técnicas y funcionales del pliego y las que se vayan derivando de los productos intermedios a lo largo del ciclo de vida de la construcción del sistema. El alcance previsto incluye la construcción de al menos: Módulos de producto: los módulos de las categorías de Preparación de envíos registrados y de Envío de documentos con todos sus productos asociados: A. Preparación de envíos registrados: Paquetería nacional, paquetería internacional, cartas y notificaciones, tanto en su canal masivo como web. A titulo orientativo la funcionalidad prevista será: Pre-registro de todo tipo de envíos postales, tanto nacionales como internacionales: o Proceso estructurado en pasos o etapas, con validación completa del proceso al final de cada una de ellas, y con la realización de una validación total al final del proceso, que garanticen la integridad y coherencia de los datos informados o Introducción de datos de destinatarios: a. De forma manual b. Recuperando un envío realizado anteriormente Página 11 de 91

12 c. Repitiendo idénticamente un envío anterior (envíos recurrentes) d. Mediante fichero de datos e. Haciendo uso de una libreta de direcciones o Elección de producto y valores añadidos en base a los datos de caracterización del envío, y a las necesidades del cliente (éste no debe preelegir, si no lo desea, el producto que va a utilizar) o Posibilidad de abandonar y recuperar posteriormente el proceso de pre-registro en cualquier paso del mismo o Generación de toda la documentación y etiquetas asociadas a cada envío, según su tipo y destino (incluyendo la totalidad de la información aduanera) o Conexión con pasarelas de pago y Módulo de Facturación de la OV2 o Generación de un histórico de envíos en el que quedarán asociados a cada uno de ellos sus distintos eventos, por usuario (recogidos de SGIE o Mercurio) o Funcionalidades de administración y gestión del sistema (con gestión de perfiles) o Acceso y corrección de datos en centros de cambio (internacional) o Gestión de incidencias desde el propio aplicativo El Módulo será capaz de integrarse con sistemas de información externos a Correos, previo registro e identificación de usuarios a través del Módulo de Gestión de Clientes El Módulo se integrará con IRIS, para completar el proceso de admisión de cada envío B. Envío de documentos profesionales: Servicio para la venta de los productos asociados a la categoría de envío de documentos (Burofax, Telegramas ), tanto en su canal masivo como el web garantizando el mínimo impacto posible sobre los clientes actuales de estos productos. o Burofax-Telegrama Online A titulo orientativo la funcionalidad prevista será: Túnel de compra: Integración con el módulo de control de acceso de la OV2 Introducción de destinatarios (manual, recuperar un destinatario anterior, mediante fichero) Introducción del documento (validación del PDF utilizando la plataforma corporativa y muestra del PDF-A Generado si aplica) Selección de valores añadidos Enlace con las pasarela pagos (si aplica) Página 12 de 91

13 Integración con los SI de Correos necesarios (SGIE, Mercurio, IRIS, e-documento, facturación /contabilidad, etc.) Backoffice: Integración con el módulo de control de accesos SGID Informes que permitan el seguimiento del comportamiento del sistema. Estos deberán poder generarse con información diaria/semanal/mensual/anual referida a envios contratados, admitidos, impresos, entregados o devueltos y distinguiendose por Ámbito Nacional / Zonas / Oficinas/USES. Además los informes deberían permitir llegar a detalle de las incidencias o Correo Digital A titulo orientativo la funcionalidad prevista será, similar a la anterior: Túnel de compra y canal masivo: Integración con el módulo de control de acceso Introducción de destinatarios Introducción del documento Selección de valores añadidos Enlace pasarela pagos (si aplica) Integración Módulo facturación /contabilidad Integración con correo híbrido Envío de ficheros de impresión Control de impresión por fichero Control de admisión por lotes Cuadro de mando Integración con el módulo de control de accesos SGID Informes que permitan medir la calidad del servicio (plazos y volumen de envíos entre la admisión, envío a Correo Híbrido, Impresión y admisión) y alarmas sobre existencia de envíos con problemas. Módulos Core: además de la adaptación de los módulos core actuales a las especificaciones de los módulos de productos nuevos, a titulo orientativo se contempla la construcción de la siguiente funcionalidad prevista: A. Módulo de gestión de clientes: para la identificación, acceso y perfilado de clientes, Mi Oficina Virtual y el Portal del Cliente. B. Módulo de utilidades. Proporcionará los servicios de infraestructura que emplearán tanto los demás módulos del Core cómo el resto de la plataforma Página 13 de 91

14 Gestión de ficheros de intercambio (envíos, devolución de resultados, control de envíos, validaciones, certificaciones, eventos, certificación de contenidos, etc.) Comunicación con S3C (Firmas, verificación, cifrados, verificación de certificados, verificación de certificados revocados, etc.) Conversión de formatos de ficheros y validación. Gestión interfaces con la plataforma de comunicaciones ( , sms). Gestión de las comunicaciones con sistemas externos. Gestión de Alertas Gestión de eventos de Auditoria C. Módulo de seguimiento. Encargado de gestionar la información de trazabilidad de los envíos. Administrar estados de envíos (lógica de estados por productos, clientes, etc.) Administración de las comunicaciones con los sistemas de trazabilidad (Mercurio, edocumento, SGIE, etc.) Administración de los canales de envío de eventos: web, masivos, s, SMS, etc. Generación de informes de estados (búsquedas, masivos, etc.) Consulta de estados de envíos (por código de envío, código de cliente, fechas, producto ) Consulta de los ear Carga de una certificación (prueba de entrega/contenido) con objeto de verificación y/o impresión de diligencia de la certificación con CSV. Cotejo de una diligencia de certificación. D. Módulo de promociones. Proporcionará las funcionalidades para la explotación y configuración de las promociones de productos y servicios Administrar promociones de productos, por cliente, canal, envío, volumen, etc Administrar promociones por cupones. Administración promociones de características de productos. Obtención de los descuentos promocionales. Cálculo de Informes sobre promociones. Verificar códigos promocionales. E. Categoría de envío de documentos. Construcción del módulo de metaproducto que de servicio a la categoría de envío de documentos. F. Módulo financiero. Este módulo permitirá la gestion de tarifas a emplear por todos los servicios de la OV2 (su carga masiva, Página 14 de 91

15 consulta y actualización) y la Integración con la plataforma corporativa de medios de pago que permitirá el control y eliminación de pagos duplicados, pagos rotos, la gestión de conciliaciones automáticas de pagos, las devoluciones automáticas, la integración con el sistema de facturación y CRM y la integración con los sistemas contables de Correos G. Módulo de impresión. Generación de PDF s con los datos de los servicios contratados en la OV2 necesarios, como por ejemplo: Manifiestos, Etiquetas, Comprobantes de pago, documentación aduanera, Autorizaciones, etc. El Módulo de Impresión deberá gestionar, al menos, la impresión de los siguientes documentos o similares: Relaciones de envíos Albaranes de entrega (para facturación) Copia Certificada (documento físico + MAC) Acuse de Recibo (documento físico + MAC) CN22 CN23 CP72 DUA (Declaración Formal de Exportación) Declaración de no realización de DUA a través del agente propuesto por Correos Etiquetas identificativas código 2D PDF417 (puede ser por producto o etiqueta única para todo tipo de productos registrados) PEM (próximamente será sustituido por el CP72 único) Etiquetas de códigos de barras de envíos no registrados Facturas de envíos realizados (actualmente solo de envíos abonados a través de TPV) Resguardos de imposición de envíos H. Módulo de Back-office. Desarrollar o en su caso modificar el Back-office para que incluya los siguientes componentes: Gestión de perfiles de acceso de usuarios de Correos Vinculación de usuarios OV2 a contrato Generación de cuadros de mando Consulta y modificación de envíos I. Integración con las plataformas en DNA y.net Mejoras Evolutivas de la OV2: Análisis de nuevos servicios a incorporar a la OV2, incluyendo la recogida de requerimientos de negocio (calidad de servicio, de diseño, imagen, criterios de accesibilidad, estándares, contenidos, Página 15 de 91

16 etc.) y técnicos (arquitectura, disponibilidad, seguridad, rendimiento, accesibilidad de navegadores y plataformas de cliente, etc.) Elaboración de prototipos y su documentación asociada que presenten a Correos diversas opciones sobre el nivel de servicio, diseño gráfico y arquitectura de los contenidos y nuevos servicios del portal. Diseño, construcción e implantación de nuevos servicios, incluyendo la definición del entorno tecnológico (hardware y software), la elaboración del diseño técnico y de casos de pruebas, la construcción del servicio, su validación e implantación adjuntado con la documentación y certificaciones definidas en la metodología MARCO de Correos. Formación a los usuarios y elaboración de los manuales de formación necesarios. Construcción de los evolutivos de servicios existentes en la plataforma o redefinición de los existentes, entre los que se incluye: A. Integración con OPV-PEC-ADO - Definición de los procesos e interfases que permitan la convivencia de las nuevas funcionalidades de la OV2 con OPV, PEC, ADO y sus sistemas asociados. - Construcción y realización de pruebas de integración de los desarrollos necesarios sobre OV2 y sus sistemas asociados para la citada convivencia. B. Comercialización de nuevos productos y herramientas: - Evolución del servicio de paquetería y preparación de envíos para permitir: unificar los ficheros de información de retorno de estados a clientes unificado con el resto de SI de Correos - Adaptación a los cambios de tarifas o estructura para el 2010 y Gestión de campañas comerciales. - Integración con plataformas de medios de pago. - Extensión del modelo de AR electrónico a los productos existentes en la OV2 C. Mejoras operativas y técnicas de las plataformas Página 16 de 91

17 - Adaptación y creación de interfaces con otros sistemas de Información de Correos: por ejemplo, SAP, SGId, etc. - Adaptación a la nueva normativa de Correos: códigos de barras, etiquetados, etc. - Resolución de vulnerabilidades Requisitos de las prestaciones a realizar A continuación se detallan los requisitos generales que deben cumplir las prestaciones identificadas para cada uno de los lotes. I. Requisitos de organización de la OV2 (sólo aplica al lote 3) La OV2 está diseñada sobre una estructura basada en módulos: Módulos Core: los que forman el núcleo de la OV2, es decir, el soporte común de funcionalidades sobre las que se construirán los productos, metaproductos y servicios (utilidades, gestion de clientes, medios de pago, utilidades, interfaces, promociones, seguimiento, etc.). Dentro de estos módulos se incluyen los de gestión de categorías de producto, es decir, los que reúnen las funcionalidades básicas y comunes a los productos de una misma categoría. Módulos de producto: específicos de la lógica de negocio de la compañía. Contienen las funcionalidades para la venta interactiva de productos y servicios, y para la gestión y explotación de esta operativa. En ambos casos deben existir funcionalidades de gestión y mantenimiento a través de aplicaciones de Back Office. Las prestaciones (mantenimiento, evolutivos y construcción de nuevos productos y servicios) deben cubrir la construcción y/o modificación de todos los módulos anteriores (core, producto y backoffice) afectados en cada momento, manteniendo la coherencia con el diseño actual de OV2 (tanto técnico como gráfico) de forma que se permita poner en producción de forma rápida nuevos productos y servicios acorde a la filosofía actual. II. Requisitos de negocio (sólo aplica al lote 3) La OV2 debe ser una plataforma multi-idioma, multi-canal, multi-navegador y adaptada para discapacitados, garantizando el acceso completo a sus servicios. Para ello las páginas que constituyan el Front Office de la plataforma deberán estar construidas de forma que se visualicen correctamente en los principales navegadores: Internet Explorer. Versiones 6.x y superiores (7.x, 8.x, etc.), Mozilla versión 3.x y superiores, Chrome y los utilizados por Nokia y iphone Página 17 de 91

18 Además las páginas citadas deberán estar diseñadas de forma que se ajusten al menos al nivel A de las Directrices de Accesibilidad para el Contenido Web 1.0 del W3C. Además los desarrollos en la OV2 deberán: - adaptarse a las guías de estilos de Correos para aplicaciones de Back Office y la definida para el Front Office de OV2. - seguir las líneas de la arquitectura, organización de contenidos y esquemas de navegación de Correos. - seguir la guía de recomendaciones para mejora de la usabilidad y experiencia de usuario - cumplimentar el cuadro de mando de Experiencia de Usuario de los indicadores de gestión de la web. - Incluir controles de disponibilidad. Deberán implementarse todos aquellos controles a nivel de código y a nivel de servidor de aplicaciones, que garanticen la disponibilidad en todo momento del aplicativo. Para ello deberán capturarse todas las posibles excepciones y errores producidos dentro de la aplicación, manejando su comportamiento. - Proporcionar como parámetros mínimos para alcanzar el Acuerdo de Nivel de Servicio de la OV2: tamaños por página que no excedan en ningún caso los 150 Kb, tiempos de espera de visualización por página que no exceda de 1 segundo y servir, sin problemas de rendimiento, una media de 200 páginas por segundo. - Mantener e incrementar en su caso los modos de acceso a la OV2, incluyendo al menos: http, HTTPS, FTP/sFTP/Spazio/Editran, (X.25 e IP), WAP, CRM, post, redes de confianza y/o WebServices - Garantizar el cumplimiento de la legislación vigente aplicable a este tipo de plataformas y productos y servicios, al menos: ley general de telecomunicaciones LGTel 23/2003, RD 424/2005, RD 1494/2007, Ley Orgánica 15/1999, Ley 59/2003 firma electrónica, ley 209/2003, RD 1720/2007 de protección de datos, Ley 11/2007, Ley 56/2007 factura electrónica, Orden EHA/962/2007, ley 30/2009, orden 2971/2007, Ley 34/2002, Ley 24/1998 Postal, etc. III. Requisitos de seguridad (aplica a los lotes 2 y 3 salvo indicación expresa) a) Normativa y Conformidad (aplica a los lotes 1, 2 y 3). La ejecución del proyecto incluirá la elaboración y entrega de todos aquellos documentos cuya existencia venga derivada del cumplimiento de la legislación vigente, del marco normativo de seguridad establecido para los Página 18 de 91

19 sistemas de información de Correos o, en su caso, sean necesarios para llevar a cabo una gestión adecuada del servicio, la aplicación o el sistema. En este sentido, el proveedor deberá hacer entrega de un informe acreditativo de las medidas de seguridad física existente en los centros de tratamiento de datos y de las entradas y salidas de información producidas bajo cualquier tipo de soporte, así como un informe periódico relativo al respaldo de la información y el acceso físico autorizado a los centros de tratamiento. El proveedor del servicio, deberá informar a sus empleados de las obligaciones legales existentes en el tratamiento de datos de carácter personal así como de los requerimientos de seguridad exigidos por CORREOS. En caso necesario, CORREOS proporcionará al adjudicatario acceso al marco normativo de seguridad y los documentos de buenas prácticas que sean de aplicación. La empresa adjudicataria exigirá a los técnicos que formen parte del equipo de trabajo objeto de este contrato, el cumplimiento de la normativa de seguridad establecida en Correos sobre obligaciones y funciones del personal, quedando obligada, la empresa adjudicataria, frente a Correos por las responsabilidades que puedan derivar de su incumplimiento. Asimismo cualquier acción que implique labores de desarrollo se someterá a las recomendaciones y directrices establecidas en los documentos de buenas prácticas en el desarrollo de sistemas J2EE existentes en CORREOS. b) Control de Acceso y SSO El módulo de Administración, deberá integrarse (delegar los procesos de Autenticación y Autorización) con el Sistema Corporativo de Gestión de Identidades (SGId), y con el Sistema de Single SignOn, permitiendo la gestión centralizada de usuarios, logón único y autenticación fuerte Dicha integraciones deberá llevarse a cabo mediante conectores y desarrollos que deberán cumplir los estándares corporativos de integración para arquitecturas J2EE, DNA y.net. Dicha integración deberá ser asumida por el proyecto. El modelo establecido en CORREOS para controlar el acceso a los Sistemas de Información es un modelo de control de acceso basado en roles (RBAC), de manera que el Sistema tendrá que permitir el establecimiento de distintos grupos de usuarios en función de las actividades que se realicen en el mismo. Dichos grupos, deberán estar identificados y detallados en base a los privilegios de los mismos y sus responsabilidades asociadas. c) Respaldo y recuperación El conjunto del Sistema, Pasarela y modulo de Administración, deberá disponer de un plan de contingencia ante desastres alineado con la Página 19 de 91

20 estrategia corporativa de respaldo, siendo responsabilidad del proyecto elaborar un Plan de Contingencia que incluya las tareas y prioridades de recuperación de los componentes que permiten dar servicio al activo, ante los distintos escenarios de desastre contemplados en el Proceso de Continuidad del Negocio. Adicionalmente, el proyecto deberá: Proponer la arquitectura más adecuada para lograr la recuperación del Servicio, según los tiempos requeridos por el Área de Seguridad Informática y establecidos por el negocio. El diseño de dicha arquitectura, se fundamentará en una estrategia de recuperación basada en la existencia de medios tecnológicos de respaldo en un centro de proceso de datos alternativo. Proveer el software, licencias, y demás componentes necesarios para implementar los mecanismos de protección ante contingencias en el centro alternativo, que resulten de la propuesta de arquitectura de recuperación ante desastres. Integrarse en la Arquitectura Corporativa de Backup, basada en Tivoli Storage Manager (TSM), y adicionalmente mediante el agente TDP correspondiente, y asumiendo todas las tareas derivadas de la integración, puesta en marcha de las operaciones de copia y coste de licencias. Procedimentar todas las operaciones de copia de acuerdo a la Política y Normativa corporativas, así como las contenidas en el proceso de Respaldo y Recuperación de Activos de Información d) Comunicaciones Cada unidad de despliegue (sistema físico) componente del Sistema, (servicio, aplicación o herramienta), deberá ubicarse en el dominio de seguridad de red que el Área de Seguridad Informática de CORREOS determine, de acuerdo con las normativas vigentes. El proyecto deberá documentar los flujos de información, puertos y protocolos necesarios para la comunicación entre componentes del Sistema, incluso aunque se encuentren en el mismo sistema físico Los protocolos de comunicaciones en los que viaje el usuario y la contraseña en claro, quedan expresamente prohibidos, como por ejemplo ftp y telnet. El estándar para el cifrado de la información en tránsito es SSL, siendo obligatorio su uso para todas las operaciones de administración y aquellas otras, que lo requiera el nivel de confidencialidad de la información transmitida. e) Integridad y Confidencialidad Página 20 de 91

21 El nivel de confidencialidad en integridad de la Información será determinado por el Área de Seguridad Informática de CORREOS, siendo responsabilidad del proveedor la implementación de los correspondientes controles de Seguridad (firmado, cifrado y no repudio) tanto para datos en transito como para los almacenados, que se pudieran derivar del mismo. El proyecto deberá diseñar e implementar dichos controles utilizando los estándares de cifrado y firma, soportados por la Plataforma Criptográfica Corporativa. En caso de almacenarse imágenes o documentos, el sistema deberá permitir su clasificación atendiendo al grado de sensibilidad establecido por la normativa interna de clasificación de la información. f) Sistemas Operativos y Software Base Todos los sistemas en Explotación (Preproducción y Producción) de CORREOS que soporten la pasarela, deberán tener implantados los procedimientos operativos de seguridad (POS) que se encuentren publicados y sean aplicables, en la condiciones descritas en la normativa de seguridad (es decir, siempre antes de la puesta en explotación de cualquier sistema) El proyecto podrá solicitar los documentos orientativos sobre la influencia de los POS en los Sistemas Operativos y Software base que soportan los Sistemas de Información Corporativos, para conocer las posibles limitaciones que éstos pueden producir en los entornos de Producción y Preproducción. g) Auditoria Todos los componentes de la Aplicación, deberán generar eventos de Auditoria, e integrarse con la Arquitectura de Auditoria Corporativa. El proyecto deberá asumir todas las tareas derivadas de la integración, aportando el conector específico o realizando la transformación del log para su adaptación al conector genérico. Los eventos de seguridad mínimos que debe generar cualquier sistema en explotación de CORREOS son los siguientes: Autenticación y accesos al sistema (acertados y fallidos). Cambios en las cuentas y grupos de usuarios y contraseñas (acertados y fallidos) Cambios accesos y modificaciones del sistema de log o auditoría (acertados y fallidos) Acciones realizadas con privilegios de administrador Cambios en los privilegios asociados a cada rol La generación de los citados eventos y trazas de auditoria del sistema deberán permitir el cumplimiento de las políticas de auditoria corporativa: Registro de accesos o Control de privilegios administrativos Página 21 de 91

22 o Cumplimiento de la LOPD o Gestión única de Identidades Adicionalmente el Área de Seguridad Informática de Correos, establecerá, si fuese necesario, controles adicionales para asegurar la integridad de los eventos de auditoría de negocio. h) Buenas prácticas en programación: Deberán de evitarse fallos de seguridad en la programación que permitan ataques externos e internos a la misma. Se deberán tener en cuenta en la programación los documentos publicados internamente relativos a las buenas prácticas en programación J2EE y aplicaciones Web. El desarrollo de la OV2 deberá prestar especial atención en los siguientes puntos del sistema: Validación de datos de entrada: validar todas las entradas para evitar ataques de Cross Site Scripting o SQL Injection Autenticación: protección de ataques de suplantación o replicación de la sesión Autorización: restricción del acceso de usuarios a recursos de sistema, mantener privilegios de administración separados. Gestión de la sesión: protección de cookies de sesión y accesos no autorizados Criptografía. Uso de algoritmos claves y sistemas de criptografía estándar de Correos Manipulación de parámetros: validación de parámetros y variables mantenidas durante la sesión. Gestión de excepciones: captura de excepciones y filtrado de errores Seguridad del lado del cliente: borrado de datos confidenciales. Auditoria y registro: auditoria de acciones y protección de la integridad de los registros. i) Análisis de la Seguridad y Penalizaciones (aplica exclusivamente al lote 3). Adicionalmente a la realización del Plan de Pruebas de Seguridad establecido por la metodología de Correos, y de forma previa a la entrada en producción del sistema, la adjudicataria contratará la ejecución de un Hacking Ético a una empresa especializada en Seguridad que realizará una auditoria a nivel de Aplicación. Los trabajos relativos al análisis de la Seguridad de la Aplicación, tendrán una duración mínima de 15 jornadas. El resultado de dichos trabajos se presentará a Correos en formato de Informe de Vulnerabilidades firmado, en el que las mismas serán calificadas en función de su criticidad y que necesariamente deberá incluir tanto las evidencias recogidas en el proceso como las recomendaciones para su resolución. El adjudicatario asumirá la resolución de la totalidad de las vulnerabilidades detectadas. Página 22 de 91

23 IV. Requisitos de construcción por fases Las fases inicialmente previstas para la construcción de nuevos servicios en OV2 son 4 también se deben considerar para los mantenimientos evolutivos de los lotes 2 y 3-: a) Fase de análisis y diseño (si Correos no lo proporcionara) y construcción b) Fase de pruebas, validación e implantación c) Fase de auditoria de seguridad externa (hacking) d) Fase de lanzamiento a) Fase de análisis, diseño y construcción. Las tareas previstas para esta fase son: 1. Elaboración de un plan de convivencia entre la OPV, PEC y ADO y la OV2 que incluya: la planificación de la puesta en producción de cada fase en función de su impacto en la plataforma actual, la arquitectura y modelos técnicos de integración y el detalle de las pruebas necesarias a realizar para asegurar esta convivencia (planes de prueba de Sistemas, Usabilidad, Seguridad, Carga/Rendimiento, ). Este plan de convivencia debe ser desarrollado y consensuado con el proveedor de la actual plataforma y validado por Correos. 2. Cierre de requisitos funcionales de detalle a plasmar en el documento de análisis funcional correspondiente. 3. Definición de diseño óptimo, que cumpla los requisitos funcionales el resto de requisitos definidos en este punto y construcción de los mismos. b) Fase de pruebas, validación e implantación Los objetivos de esta fase son la entrega y aceptación del sistema en su totalidad, para lo cual el adjudicatario deberá llevar a cabo todas las actividades previstas para la validación y paso a producción: 1. Pruebas y validación : Se realizarán todas las pruebas de aceptación del sistema para su posterior paso a producción. Se actualizará toda la documentación y el catálogo de componentes. El adjudicatario definirá todos y cada uno de los diferentes casos de prueba para cada tipo de prueba, de manera que se cubra la verificación de los requisitos funcionales, técnicos, de integración, etc., del sistema; realizará todas las pruebas correspondientes al Plan de Pruebas de Desarrollo y recogerá los resultados en los informes correspondientes. Así mismo, el adjudicatario, además de la elaboración del resto de planes de prueba, colaborará con el personal de las distintas Áreas Técnicas y Áreas Usuarias de Correos en la ejecución del resto de planes de pruebas previstos para la fase de Validación e Página 23 de 91

24 Implantación. Los distintos tipos y planes de pruebas serán al menos: Plan de Pruebas de Desarrollo Pruebas unitarias y de conexión. El objetivo de las pruebas unitarias es verificar el nivel más bajo de componente de código. La unidad menor es generalmente un módulo, un método de una clase java o un grupo pequeño de métodos estrechamente relacionados. El objetivo de las pruebas de conexión es validar que dos o más unidades de código (después de su validación unitaria) interaccionan correctamente entre si. Unas pruebas de conexión exhaustivas (según el método de caja blanca) deberán asegurar que todas las llamadas a otros módulos son identificadas y ejecutadas. Pruebas de integración con otras herramientas. El objetivo de las pruebas de integración con otras herramientas es validar la comunicación vía APIs entre el sistema a desarrollar y los paquetes de software y desarrollos de terceros. Pruebas de sistema. El objetivo de las pruebas de sistema es verificar los requisitos documentados en la especificación funcional; esto implicará la validación de los procesos a corto plazo (por ejemplo casos de pantallas o de uso) y los procesos del negocio desde el inicio hasta su conclusión. Pruebas de integración. El objetivo de las pruebas de integración es verificar la comunicación con los sistemas externos; es decir, pruebas entre el sistema desarrollado y los otros sistemas. Las pruebas de integración deberán asegurar que el formato y el intercambio de datos con los sistemas externos concuerden con la especificación de interfaces externos. Plan de Pruebas de Certificación Pruebas de plataforma e instalación. El objetivo de las pruebas de plataforma es verificar que el sistema funciona correctamente en una plataforma lo más parecida posible al entorno real. Las pruebas de plataforma deberán identificar y resolver cualquier incidencia relativa a la plataforma de implementación y/o los problemas relativos a la coexistencia entre el nuevo sistema y otras aplicaciones. Pruebas de Código Página 24 de 91

25 El objetivo de estas pruebas es certificar que el código fuente generado cumple con los requisitos de calidad definidos por Correos en sus documentos de Buenas Prácticas, Estándares, Métricas, etc., para lo cual se realizará un análisis estático y dinámico del código con las herramientas que Correos determine. Plan de Pruebas Funcional y Usabilidad. El objetivo de las pruebas funcionales y usabilidad es verificar que el sistema funciona correctamente y cumple con la normativa de Usabilidad, en definitiva que cumple con los requisitos documentados en la especificación funcional. Para realizar esta certificación el adjudicatario entregará el Plan de Pruebas Funcional que cubra como mínimo el 85% de la funcionalidad y en el formato acordado con Correos de forma que este pueda ser cargado y ejecutado a través de la herramienta de HP Quality Center. Plan de Pruebas de Rendimiento y Seguridad Estas pruebas se realizarán con las herramientas que Correos determine, en un principio LoadRunner de HP. Pruebas de prestaciones. El objetivo de las pruebas de prestaciones es establecer la respuesta del sistema bajo las condiciones reales y verificar el funcionamiento del sistema. La actuación del sistema se prueba según los requisitos no funcionales documentados. Estos definen el comportamiento esperado, en términos de tiempos de respuesta de pantallas, para los procesos de negocio online cuando se realizan peticiones de usuarios concurrentes (promedio y pico). El diseño de las pruebas deberá contemplar los distintos componentes que involucra el sistema: - Elementos de sistemas: servidores web, servidores de aplicación, BBDD,... - Elementos de comunicaciones LAN y WAN: bus de integración, líneas, electrónica de red, balanceadores de carga,... - Características de alta disponibilidad, si así fuera necesario. Los juegos de datos necesarios para las pruebas tendrán en cuenta casos en los que las bases de datos almacenen cantidades de información similares a las que se van a encontrar en producción. Las pruebas de prestaciones se realizarán únicamente sobre aquellas funcionalidades que Página 25 de 91

26 Correos considere que puedan tener un mayor impacto en el rendimiento. En cuanto a las pruebas de comunicaciones, deberán diseñarse previendo al menos dos tipos de pruebas: una en la que se obtenga la ocupación de ancho de banda para cada uno de los casos, y, otra, simulando las cargas reales que existen en las líneas (por ejemplo, en franjas horarias clave o simulando otras aplicaciones que se ejecutan concurrentemente). A continuación se describen los tres tipos de prueba de comportamiento más importantes: - Pruebas del Volumen: El objetivo de estas pruebas es verificar el comportamiento del sistema cuando esta sujeto a cargas reales bajo condiciones de trabajo normales. - Pruebas de carga: El objetivo de estas pruebas es simular el caso más desfavorable respecto a la demanda de datos en el sistema dentro de un entorno de pruebas con una carga real. - Pruebas de estrés: El objetivo es evaluar el funcionamiento del sistema bajo las condiciones de operación excesivas. Para ello será necesario la utilización de herramientas de pruebas que simulen un empeoramiento de las condiciones de un entorno de pruebas real. Pruebas de recuperación. El objetivo de las pruebas de recuperación es discernir si el sistema puede o no recuperarse después de varios tipos de errores de aplicación y errores no relacionados con la aplicación, tales como la corrupción de la base de datos o los intentos fallidos debidos al hardware y a la red. Pruebas de requerimientos de seguridad del sistema. El objetivo de las pruebas de requisitos de seguridad es validar las características relacionadas con la seguridad de los sistemas calificados como de alta criticidad. Las pruebas se realizarán como una etapa extra de pruebas dentro de las pruebas de comportamiento. Las principales tareas a realizar durante dichas pruebas serán las siguientes: - Garantizar la correcta autenticación y control de acceso de la aplicación. - Deberán crearse baterías de pruebas de datos para su ejecución sobre la aplicación, garantizando la correcta validación de los datos de entrada y salida. - Validación de todos los controles criptográficos utilizados. Página 26 de 91

27 - Ejecución de pruebas de carga sobre la aplicación, comprobando que garantiza su correcta disponibilidad. - Comprobación del correcto registro de eventos del sistema. Una vez realizadas todas las pruebas de seguridad, deberán corregirse todas las posibles vulnerabilidades de seguridad que hayan aparecido durante las mismas. Una vez finalizadas las pruebas, deberá emitirse un informe de estado en donde aparecerán las distintas pruebas de seguridad realizadas, así como las posibles vulnerabilidades que no han podido ser corregidas sin las hubiese. Test de Usabilidad, accesibilidad y experiencia de usuario Se realizarán pruebas de usabilidad con varios tipos de usuarios (internos, externos, redactores, publicadores, proveedores) para certificar que el resultado cumple con los requerimientos, realizando un informe preliminar que servirá para solventar las deficiencias encontradas y un informe final que sirva de documento para la tarea de aceptación. Se realizará un test de accesibilidad, realizando un informe preliminar que servirá para solventar las deficiencias encontradas y un informe final que sirva de documento para la tarea de aceptación Se presentará un informe de Experiencia de Usuario a través de los informes recogidos por la herramienta de medición de tráfico y audiencias web utilizada por Correos. Se realizará una análisis de impacto comunicacional del portal resultante Plan de Pruebas de Aceptación Pruebas de aceptación del usuario. El objetivo de las pruebas de aceptación del usuario es demostrar que el sistema cubre los requisitos del negocio y criterios de aceptación definidos en el Catálogo de Requisitos. Certificación del Sistema Se realizarán las pruebas correspondientes a los Planes de Prueba de Certificación, Rendimiento y Seguridad en los entornos de certificación y preproducción realizando las migraciones y cargas de datos pertinentes. 2. Implantación Página 27 de 91