PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁN LA REALIZACIÓN DEL CONTRATO DE

Transcripción

1 PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁN LA REALIZACIÓN DEL CONTRATO DE Servicio de desarrollo y mantenimiento de la Herramienta de Gestión de Dominios PROCEDIMIENTO SIMPLIFICADO Este archivo está almacenado en la sede electrónica de Red.es, accesible desde csv.red.es con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

2 1. INTRODUCCIÓN REQUISITOS TÉCNICOS Requisitos de operación Procedimiento de validación de los nuevos desarrollos Requisitos de seguridad Plan de calidad Implantación de software Informes y seguimiento Medios personales Acuerdos de nivel de servicio Planificación, dirección y seguimiento de los trabajos Horario y lugar de realización de los servicios Actividades formativas Soporte Técnico Obligaciones de información y documentación Devolución del servicio CONTROL ECONÓMICO Y DE FACTURACIÓN Hitos de facturación FORMATO Y CONTENIDO DE LA PROPUESTA Propuesta relativa a los criterios cuya valoración depende de un juicio de valor (sobre 3) Propuesta relativa a los criterios cuantificables mediante la mera aplicación de fórmulas (sobre 4) ANEXO I. Arquitectura de la herramienta Descripción de la arquitectura tecnológica actual Descripción funcional de la herramienta ANEXO II. Estimación de funcionalidades por la métrica de puntos Casos de uso Estimación de funcionalidades Estimación de esfuerzo Ejemplo de aplicación del método. 77 Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 2 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

3 Nota: Cualquier consulta en relación con el presente procedimiento de licitación debe dirigirse por correo electrónico a la dirección sg.contratacion.consultas@red.es, indicando: Asunto: número de expediente. Cuerpo: nombre de la empresa, datos de la persona que realiza la consulta y texto de la consulta. El plazo de recepción de consultas finalizará 3 días hábiles antes del fin del plazo de presentación de ofertas. Red.es no tendrá obligación de responder las consultas realizadas transcurrido dicho plazo. Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 3 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

4 1. INTRODUCCIÓN En España, la es la Autoridad de Asignación de los dominios de nivel superior geográfico del.es que, a tal fin, dispone de un Sistema Informático, compuesto por una herramienta de gestión de nombres de dominios y una infraestructura hardware y de comunicaciones, que se encarga de permitir a todos los actores implicados en el ciclo de Asignación de los dominios bajo interactuar entre sí, con el objeto de solicitar, administrar y gestionar los nombres de dominio bajo este indicativo. El funcionamiento de dicha herramienta, así como la normativa que regula los procedimientos externos a la misma, se encuentran enmarcados dentro de los distintos niveles que componen la estructura organizativa de Red.es. Red.es pone en marcha el presente procedimiento de licitación con el objeto de contratar el servicio de desarrollos evolutivos y mantenimiento de la herramienta de gestión de nombres de dominios.es. Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 4 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

5 2. REQUISITOS TÉCNICOS El objeto del Contrato consiste en la prestación de un Servicio de desarrollos evolutivos, mantenimiento y soporte de la herramienta de gestión de nombres de Dominios.es. El Servicio objeto del contrato se realizará sobre la arquitectura de la herramienta descrita en el Anexo I del presente pliego. En este apartado se detallan las características técnicas mínimas del servicio objeto del procedimiento de licitación. Se especifican requisitos mínimos. Las propuestas que incumplan u ofrezcan características inferiores no serán tomadas en consideración en el procedimiento de adjudicación. El licitador puede ofertar prestaciones superiores a las solicitadas. El adjudicatario deberá garantizar la prestación y cumplimiento del Servicio siendo responsable del cumplimiento de todas y cada una de las funciones encomendadas dentro del presente pliego. Las tareas que forman parte del servicio objeto del contrato quedan definidas a continuación. Es conveniente aclarar que no se trata de un listado exhaustivo de las tareas que deberá realizar el adjudicatario en ejecución del contrato. Para las labores de coordinación de los servicios contratados, el adjudicatario nombrará un Responsable del proyecto como interlocutor único con Red.es Requisitos de operación El objeto del contrato incluye la realización de los siguientes servicios: Servicio de desarrollos evolutivos. Servicio de mantenimiento de la herramienta de gestión de dominios. Peticiones de cambio. Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 5 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

6 Servicio de desarrollos evolutivos La actual herramienta de gestión de nombres de dominio debe adaptarse a las nuevas necesidades detectadas, y por tanto es necesario que evolucione con el objeto de incluir las funcionalidades que se presentan desglosadas en la versión que se indica a continuación. El enfoque de esta versión seguirá la metodología de Red.es (ver apartado Metodología), basada en el proceso unificado. La versión contará con las fases de inicio, elaboración, construcción y transición, y se realizará dos iteraciones como máximo por cada una de ellas. El proceso estará basado en la métrica de puntos de minimización de riesgos. Casos de Uso (ver anexo II) y enfocado a la La fase final de la última iteración de la versión será la etapa de transición, durante la cual el adjudicatario se compromete a realizar las tareas necesarias para la correcta puesta en producción de la misma, considerando como tales la subida de la versión a su entorno de validación, el soporte al despliegue de ésta en los entornos que Red.es considere, la formación o los scripts de carga, por ejemplo, o incluso la monitorización de los entornos a petición de Red.es, para determinar la estabilidad del mismo. Se detalla a continuación la versión planificada junto a las funcionalidades que deben ser incluidas en ella, como evolución a la actual versión de la herramienta cuya descripción se ha detallado en el anexo I del presente pliego: Desarrollo de la Versión 7.2 de la herramienta En esta versión se deberán incluir, al menos, las siguientes funcionalidades: RD1. Proceso de conciliación manual: creación de un proceso que permita forzar la conciliación de pago de forma no Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 6 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

7 RD2. automática, bajo petición asíncrona. Lo que permitirá resolver aquellos casos en los que haya constancia y prueba del ingreso, pero el pago no se haya procesado de forma correcta por la plataforma de pago. Se habilitará esta opción dentro del perfil de Operador de Red (OR), de modo que el OR pueda realizar esta operación con un solo clic en la solicitud del dominio. Facturas de abono (facturas rectificativas): Habilitar la posibilidad de realizar dentro de la herramienta la gestión de facturas de abono (facturas rectificativas). En el perfil de Operador de Red (OR) se podrá realizar las acciones de: a. Subir el fichero correspondiente a la nueva factura b. Crear un flujo en la herramienta que permita consultar el fichero en el histórico RD3. CIF de extranjeros (VAT identification number): comprobar la validez del CIF de extranjeros (VAT identification number) desde la herramienta. Incluir un campo en el formulario de alta para personas jurídicas en el caso de Usuarios Finales y Agentes Registradores para que se cumplimente este dato. RD4. Resoluciones en histórico de dominio: habilitar la visualización de las resoluciones de cancelación en el histórico del dominio desde el perfil de Operador de Red (OR). RD5. Nuevas estadísticas de los motivos de cancelación, adaptación de la herramienta para obtener estadísticas de las cancelaciones de dominios y los diferentes motivos de cancelación. Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 7 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

8 Los posibles motivos aparecen estipulados en la normativa vigente (que puede consultarse en el siguiente enlace: Mantenimiento de la herramienta de gestión de Dominios Acciones de soporte y consultoría Red.es podrá requerir la realización de acciones de soporte por parte del Adjudicatario, con el objeto de complementar cuestiones que actualmente no están contemplados en la herramienta. Dentro de esta categoría de acciones pueden comprenderse, entre otras, la realización de las siguientes actuaciones: Generación de scripts funcionales. Se realizarán, probarán y enviarán a Red.es los scripts funcionales que cubran la carencia de facilidades no implementadas hasta la fecha. Consultoría y apoyo: labores de resolución de dudas, realización de presentaciones, determinación de posibles mejoras de la herramienta, transferencia de conocimiento, etc. Labores de consultoría con objeto de realizar estudios de la infraestructura existente para proponer mejoras o formas de optimización, etc. Ejecución de acciones correspondientes al rol definido en los procedimientos establecidos en el plan de contingencia diseñado para el respaldo del Servicio. Parametrización de herramientas: en este caso, Red.es se reserva el derecho de requerir al equipo del adjudicatario para que realice las labores de parametrización en las dependencias de Red.es, o las que se determinen en un momento determinado. Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 8 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

9 Soporte a las tareas de certificación de las aplicaciones, parches o scripts que el adjudicatario desarrolle como parte del servicio. Apoyo al grupo de Explotación de Sistemas de Red.es para la configuración y administración de la herramienta. Elaboración de cambios estéticos menores, tales como modificación de logotipos, cabeceras, colores, literales, textos, etc. Impartición de formación sobre la versión o versiones evolutivas a entregar. Soporte específico derivado de despliegues en entornos de Red.es (demo, producción, etc.). Realización de pruebas funcionales y/o monitorización de la herramienta para comprobar el correcto funcionamiento de la misma, ante cambios en su configuración u otros sistemas que tengan relación con ella, así como para comprobación ante determinadas circunstancias especiales, como por ejemplo, la validación ante actualizaciones de entorno/infraestructura, upgrades tecnológicos, etc Mantenimiento correctivo A lo largo de la ejecución del contrato el adjudicatario deberá realizar las acciones de soporte de mantenimiento correctivo determinadas por Red.es, que consistirán en la resolución de: RMC1. Defectos de construcción de la herramienta (errores de codificación, casos de prueba no contemplados, validaciones de datos no contempladas, etc.). RMC2. Integraciones defectuosas tanto entre las diversas partes o componentes de la herramienta, como en el entorno de actuación Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 9 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

10 de la misma (interfaces con otros sistemas, traspasos de información entre ellos, etc.). RMC3. Disfunción o desajuste entre las funcionalidades o características de la herramienta ofrecidas por el mismo en su puesta en explotación y la definición vigente de dichas funcionalidades (realizadas en las etapas de especificación y análisis de la herramienta). RMC4. Del mismo modo el adjudicatario deberá asumir todas aquellas incidencias detectadas como consecuencia de las posibles auditorías de seguridad que Red.es realice a la herramienta, o aquellas derivadas de las certificaciones que se realicen para la subida del código y la documentación a alguna forja para la liberación de código, sin coste adicional. RMC5. Será obligación del adjudicatario dar el soporte necesario al equipo que realice las implantaciones de estos parches en la infraestructura tecnológica de Red.es, así como al equipo que se encargue de realizar la certificación. La resolución de estos errores/defectos se podrá incluir en la versión planificada o determinar la generación de un parche no planificado. Sin embargo, aquellos que surjan después, deberán ser asumidos por el mismo, todo ello sin perjuicio de que Red.es aplique las penalizaciones descritas en el apartado 6 del PCP, conforme con lo establecido en el apartado 2.2 No conformidades. Las actividades derivadas de este mantenimiento contemplarán en todo momento la metodología de Red.es, y estarán sujetas a los niveles de servicio establecidos el apartado 2.8 del presente pliego. Red.es realizará un control de los trabajos realizados por el adjudicatario, comprobando si se cumple el acuerdo de nivel de servicio. Si la resolución de una incidencia implica un despliegue en los servidores de producción, Red.es procederá a certificar el Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 10 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

11 desarrollo para validar el mismo, de conformidad a lo descrito en el apartado Oficina de certificación Peticiones de cambio. Se entiende por petición de cambio toda aquella modificación solicitada por Red.es, y que puede incluir mejoras, nuevos requisitos o adaptación de los existentes. Las peticiones de cambio podrán ser originadas por Red.es o el propio adjudicatario, mediante la cumplimentación de un formulario de petición de cambio, y será Red.es quien determine la viabilidad o no del mismo, pudiendo aceptarlo o rechazarlo. Red.es decidirá, así mismo, en que versión debe incorporarse dicha petición, pudiendo ser alguna de las versiones planificadas, aunque también podrá determinar la generación de un parche no planificado (ver modelo de soporte). El adjudicatario remitirá, una estimación de coste y esfuerzo, que incluirá siguiendo la métrica de puntos Casos de uso que puede encontrarse como Anexo II, los casos de uso a incluir, los casos de uso a modificar, las transacciones por cada uno de ellos, los actores nuevos a incluir (en caso que la petición de cambio así lo requiera de cara a que Red.es pueda determinar el coste final de la inclusión de dicha petición). Red.es aprobará la estimación mediante acta firmada o por el Director técnico designado por Red.es. Si bien las versiones evolutivas están planificadas, y su funcionalidad cerrada, cabe la posibilidad de que surjan nuevas versiones sin planificar debido a cambios de alcance o errores. Estas nuevas versiones pueden ser de dos tipos: RME1. Parches críticos (hotfix): estos parches son originados por errores graves (o peticiones de cambio urgentes) sobre versiones desplegadas en producción (aunque también pueden surgir por errores detectados en las Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 11 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

12 fases de validación y/o certificación), que necesitan corregirse de forma urgente, ya que ponen en peligro la operativa de la herramienta. implementación de estos parches no podrá suponer nunca un retraso sobre la planificación del resto de versiones del proyecto estimadas. RME2. Versiones sucesivas: son originadas bien por errores menores o bien por peticiones de cambio no urgentes sobre versiones entregadas por el adjudicatario, ya se encuentren en fase de validación/certificación, o desplegados en producción. Sobre este tipo de versiones se pueden dar varias casuísticas: o Error menor detectado en producción: Red.es determinara si dicho error debe ser resuelto en una de las versiones planificadas (no supondrá la replanificación de la misma) o planificar su resolución en una nueva versión o parche, sin detrimento de que Red.es aplique las penalizaciones establecidas en el apartado 6 del Pliego de Condiciones Particulares. o Error detectado en validación o certificación: Red.es determinará si debe ser resuelto en dicha entrega o si pospone su resolución para una fase posterior o si se generará una nueva versión que contemple su resolución, sin detrimento de que Red.es aplique las penalizaciones correspondientes. La o Petición de cambio no crítica: Red.es determinará la inclusión de la misma en una nueva versión o parche cuya fecha se determinará. Una vez solicitada la petición de cambio (en el caso de que el solicitante sea Red.es), Red.es enviará el formulario de la petición al adjudicatario, por los medios y herramientas determinados, el cual dará una respuesta en un plazo máximo de 32 horas laborables, haciendo una estimación de costes y esfuerzo basándose en la métrica de puntos de caso de uso del Anexo II, indicando los casos de uso a incluir, los casos de uso a modificar, las transacciones por cada Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 12 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

13 uno de ellos, los actores nuevos a incluir (en caso que la petición de cambio así lo requiera), y el número de Puntos Casos de Uso sin ajustar, de cara a que Red.es pueda determinar el coste final de la inclusión de dicha petición en la herramienta El plazo en el que el adjudicatario debe dar dicha respuesta empezará a contar desde el momento en que Red.es envíe al adjudicatario el formulario de petición Procedimiento de validación de los nuevos desarrollos Validación de la entrega El Director Técnico designado por Red.es aceptará las versiones, mediante acta de aceptación formal firmada por el mismo, y podrá requerir del adjudicatario, en determinados casos, el soporte necesario para la ejecución de las pruebas de validación. En algunas ocasiones, Red.es podrá requerir la presencia en las dependencias de Red.es de los medios personales adscritos para los perfiles solicitados en el apartado 2.7 del presente pliego, cuando los mismos sean necesarios para realizar dicha validación. Red.es podrá requerir que el adjudicatario forme a los usuarios de la herramienta, como paso previo a la validación de la entrega de la versión por parte del Director Técnico designado por Red.es Entorno de Validación El adjudicatario pondrá a disposición de Red.es un entorno de VALIDACIÓN aislado y similar al entorno de PRODUCCIÓN para la realización de los cambios en el aplicativo previos a su puesta en producción. Cualquier cambio deberá realizarse previamente en este entorno, antes de su instalación en el entorno DEMO o Productivo de Red.es. Dicho entorno, estará ubicado en servidores propios del adjudicatario, deberá ser accesible desde las oficinas de Red.es y accesible para los integradores del mismo. Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 13 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

14 Las plataformas hardware y software necesarias para reproducir dicho entorno serán propiedad y responsabilidad del adjudicatario. El adjudicatario deberá ofrecer la infraestructura necesaria a Red.es para garantizar la disponibilidad para los entornos de validación del adjudicatario con objeto de realizar las pruebas funcionales necesarias para validar el correcto funcionamiento de la herramienta. Cualquier labor de mantenimiento sobre los servidores, que puedan poner en riesgo los niveles de servicio acordados por producir una parada en la prestación del servicio, deberá ser notificada a Red.es con una antelación de al menos 24 horas, que decidirá si la parada es o no viable. En cualquier caso, la no disponibilidad del servicio no podrá ser superior a la ventana de mantenimiento programada y siempre que se pueda se realizará fuera del horario laboral No Conformidades El adjudicatario se compromete a entregar el producto libre de problemas o incidencias, tanto en el código fuente como en la documentación. La Oficina de Certificación determinará en cada momento el número de controles que una versión incumple, quedando bajo decisión de Red.es la puesta en producción de la versión, sin detrimento de las posibles penalizaciones establecidas en el Apartado 6 del Pliego de Condiciones Particulares. Se consideran como no conformidad los errores detectados que impidan el correcto funcionamiento de la herramienta, los que conlleven vulnerabilidades de seguridad de la herramienta, aquellos que impidan la correcta puesta en producción del producto, los que impidan el despliegue del mismo en cualquier entorno de Red.es (demo, por ejemplo), o aquellos detectados en la fase de validación, que pongan en riesgo los plazos, los medios o los recursos destinados. Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 14 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

15 Asimismo se considerarán como no conformidades de un producto, las incidencias detectadas que se deban a errores en el software, las pruebas realizadas sobre scripts solicitados al adjudicatario o las incidencias detectadas sobre peticiones de cambio que comprometan los plazos, medios recursos destinados Prestación de servicios o los El adjudicatario deberá garantizar la prestación y cumplimiento del Servicio solicitado, siendo responsable del cumplimiento de todas y cada una de las funciones encomendadas dentro del presente Pliego. Todos los trabajos realizados garantizarán que los diferentes servicios continúen prestándose atendiendo a criterios de Autenticidad, Integridad, Confidencialidad, Accesibilidad, Facilidad de uso, Alta disponibilidad, Modularidad y Escalabilidad y habrán de asegurar el Acuerdo de Nivel de Servicio recogido en el apartado 2.8 de este Pliego Marco de trabajo para la liberación de código/documentación Red.es cuenta con un marco de trabajo destinado a la liberación de las versiones de la herramienta en forjas destinadas a la compartición de código fuente. Este marco de trabajo le será facilitado al adjudicatario. El adjudicatario deberá cumplir con este marco de trabajo, de cara a las futuras liberaciones del código y la documentación Requisitos de seguridad El adjudicatario deberá aportar los correspondientes procedimientos de contingencia que aseguren la continuidad de los servicios en caso de fallo de sus comunicaciones de voz y datos y de sus sistemas informáticos principales. Dichos procedimientos deberán ser aprobados por Red.es. Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 15 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

16 El adjudicatario deberá aportar un procedimiento de contingencia ante paros parciales o totales como consecuencia de una huelga o por cualquier otro motivo de índole similar. El adjudicatario documentará en dicho procedimiento y de acuerdo con Red.es, los plazos mínimos de comunicación de parada del servicio para dichos eventos. El procedimiento tendrá validez cuando sea aprobado por el Director Técnico de Red.es mediante un acta de aprobación. Cualquier incidencia relevante que afecte a la prestación del Servicio deberá ser informada de forma inmediata a Red.es Plan de calidad El adjudicatario del Servicio será el encargado de asegurar en todo momento la calidad de los productos desarrollados y de su correcta entrega para la puesta en producción en los sistemas de Red.es. Para asegurar la calidad de los productos desarrollados, Red.es realizará un proceso de certificación de los productos entregados con un informe de valoración de la entrega. En este proceso de certificación, red.es podrá realizar pruebas sobre el entorno que el adjudicatario ponga a disposición de red.es para las validaciones funcionales del desarrollo solicitado. En este sentido, se deberá cumplir todos los controles, establecidos por Red.es, incluidos aquellos derivados de la seguridad del código y los relacionados con su autoría, de cara a una posterior liberación del mismo 2.5. Implantación de software El adjudicatario deberá dar soporte al equipo que realice las implantaciones de la herramienta en Red.es. Estas implantaciones se realizarán en el horario que Red.es considere oportuno según la criticidad y el Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 16 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

17 impacto de la implantación, y si fuera necesario para la prestación del servicio, podrá realizarse fuera del horario y días laborales establecidos en el apartado 2.10 del presente Pliego. El soporte se realizará in-situ en las oficinas de Red.es si así se considera necesario. Una vez finalizada cualquier implantación de software, para su aceptación, el adjudicatario deberá ejecutar las pruebas necesarias para asegurar la correcta implantación del mismo entregando un informe de las mismas al Director Técnico de Red.es Metodología Los sistemas desarrollados y/o documentados como parte de los trabajos realizados deberán seguir la Metodología de Gestión de Proyectos y de Ingeniería del Software propia de Red.es, basada en el Proceso Unificado de Desarrollo, salvo que, por circunstancias particulares del proyecto, se indique lo contrario. Basada el Proceso Unificado y usando notación UML, dicha metodología, establece un ciclo de vida iterativo-incremental dirigido por los casos de uso y encaminado a abordar en las primeras etapas del proyecto aquellos aspectos del sistema que conformen sus principales riesgos funcionales y de arquitectura. Asimismo pretende optimizar el discurrir paralelo de actividades independientes contribuyendo a la reducción de tiempos de desarrollo (requisitos, análisis, diseño, implementación, pruebas e implantación). Todo ello contribuirá a fomentar la detección de posibles desviaciones y la ejecución de las acciones correctoras de forma rápida y en consecuencia con el menor esfuerzo e impacto posible. Los entregables código y documentación - de la solución habrán de ajustarse a las normas (nomenclatura, estándares, plantillas, ) establecidas por Red.es y que serán entregadas a la empresa adjudicataria al comienzo de los trabajos para su cumplimiento y uso. El Director Técnico designado por Red.es podrá establecer excepciones al cumplimiento de dichas normas, en aquellos puntos que considere, siempre Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 17 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

18 y cuando las particularidades del proyecto así lo recomienden, debiendo comunicar al adjudicatario las normas específicas que le serán de aplicación en estos casos. Toda esta documentación ya descrita en puntos anteriores se detalla a continuación con el fin de certificar los documentos como punto clave en el proceso de certificación de la herramienta. La documentación requerida según la metodología propia de Red.es, para la certificación del producto entregado, es la siguiente: 1. Plan de proyecto 2. Plan de Gestión de Riesgos 3. Formulario de Requisitos Origen y Derivados 4. Listado de Requisitos Origen y Derivados 5. Formulario y Listado de Petición de Cambios 6. Informes de Seguimiento de Proyecto 7. Informe de Cierre de Proyecto 8. Documento de Arquitectura del Software (opcional) 9. Glosario 10. Manual de Instalación y log de Instalación de toda la plataforma a instalar. 11. Manual de Administrador 12. Manual de Usuario 13. Modelo de Análisis 14. Modelo de Diseño 15. Modelo de Datos 16. Modelo y Plan de Despliegue 17. Evaluación de Pruebas 18. Plan y resultado de las pruebas. La documentación del proyecto deberá quedar catalogada, almacenada y controlada conforme a un plan de versiones en soporte digital, en formato Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 18 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

19 Documento de texto / PDF, de forma que pueda ser impresa cuando sea necesario. Excepcionalmente, a criterio de Red.es, parte de esta documentación podrá no ser requerida por circunstancias relativas al proyecto o de alguna de sus fases Oficina de certificación Los diferentes servicios prestados por Red.es están soportados, en su mayoría, sobre aplicaciones informáticas que se encuentran dentro de un proceso de mejora continua en aspectos relativos a calidad de las aplicaciones desarrolladas, nuevas funcionalidades o nuevos desarrollos. Dentro de este marco de trabajo, Red.es ha puesto en marcha una Oficina para Certificación de todas las aplicaciones que soportan los diferentes servicios que en la actualidad presta Red.es o vaya a prestar en un futuro. Por este motivo, Red.es provee un servicio de certificación de calidad de las aplicaciones y sistemas informáticos. El detalle de la relación entre las diferentes partes implicadas en un proceso de certificación y las acciones más importantes a tener en cuenta son: La gestión y seguimiento del servicio de certificación se centralizará en la relación con el área de desarrollo de aplicaciones y con el área de Explotación de Sistemas de Red.es. La Oficina de Certificación (en adelante OC ) deberá ser receptora de todas aquellas planificaciones y variaciones de las mismas (calendario de revisiones) que pudiesen afectar a la prestación del servicio. Esto afecta tanto a las revisiones ordinarias, alineadas con el ciclo de vida, como a las revisiones bajo demanda. Las certificaciones realizadas concluirán en un informe de certificación, cuyo detalle contendrá información sobre las no conformidades identificadas, la severidad de las mismas y una visión global cuantitativa de la calidad implícita Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 19 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

20 al desarrollo, que podrá ser utilizada como base para los procesos de aceptación y rechazo establecidos. Es fundamental en el caso de la prueba de rendimiento la preparación de los casos de prueba, tanto de los casos de pruebas unitarias como los cuadernos de carga para las pruebas de rendimiento, aunque estos últimos podrían ser absorbidos gradualmente por la oficina de certificación. Esta tarea será responsabilidad del proveedor. El proveedor del desarrollo podrá hacer seguimiento de las no conformidades detectadas y gestionarán la adecuación a los niveles de calidad exigidos por la OC a través de la resolución de estas casuísticas. Las evoluciones del modelo de calidad llevarán asociado un plan de comunicación a los equipos de desarrollo. De cara a anticipar la demanda de trabajo de certificación, los hitos de liberación de entregables deberán ser planificadas en el tiempo y comunicados con una anticipación mínima de 1 mes para certificaciones planificadas y un tiempo por determinar para certificaciones bajo demanda. Para otros detalles y documentación referentes a la OC el adjudicatario podrá dirigirse al Responsable del Contrato de Red.es, que en su caso le podrá poner en contacto con los responsables de la OC. La aceptación del presente pliego implica la aceptación de la figura de la OC, de sus procesos e informes y la obligación en todo caso de certificar todo el código derivado del desarrollo surgido del presente pliego mediante su entrega, por los medios que esta estipule dicha OC. Un informe negativo por parte de la OC no implica la no implantación de dicho código, sino que dicho informe servirá al Director Técnico Responsable del Contrato, para valorar la calidad del desarrollo y los riesgos que va a Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 20 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

21 implicar su implantación en su caso. Red.es se reservará el derecho de emplear esta OC para certificar las aplicaciones y configuraciones realizadas Informes y seguimiento Con carácter semanal, el adjudicatario deberá presentar a Red.es un informe de actividad y de seguimiento del proyecto. El formato del informe será definido por el adjudicatario y validado por Red.es y como mínimo contendrá el estado de avance del proyecto, los riesgos detectados y próximos hitos. El adjudicatario deberá presentar, siempre que red.es lo requiera, un informe mensual con las incidencias detectadas y el cumplimiento de los niveles de servicio (ANS) establecidos en el apartado 2.8 del presente pliego, así como otros indicadores que puedan surgir y que por su operativa sea necesario medir para el buen desarrollo del servicio. Además de los informes de actividad y de seguimiento del servicio, Red.es podrá solicitar al adjudicatario la realización de nuevos informes tanto periódicos como puntuales con cualquier tipo de información precisa sobre el servicio, que el adjudicatario deberá elaborar y enviar a Red.es en el formato que éste determine Medios personales De conformidad con lo establecido en el artículo 64.2 del texto refundido de la Ley de Contratos del Sector Público, aprobado por Real Decreto Legislativo 3/2011, de 14 de noviembre, los licitadores se comprometerán a dedicar o adscribir a la ejecución del contrato los medios personales o materiales suficientes para ello. A este compromiso se le atribuye el carácter de obligación esencial a los efectos previstos en el artículo 223 letra f) del texto refundido de la Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 21 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

22 Ley de Contratos del Sector Público, aprobado por Real Decreto Legislativo 3/2011, de 14 de noviembre, y de conformidad con lo indicado en el apartado 12 del Pliego de Condiciones Particulares. El adjudicatario se compromete como mínimo a adscribir 1 medio personal del perfil técnico de cada tipo descrito a continuación, salvo que Red.es, por necesidades del servicio, considere necesario aumentar el número de perfiles requeridos: PERFIL 1: Responsable de proyecto Titulación Conocimiento s Titulación universitaria en Informática, Telecomunicaciones o titulación universitaria equivalente. Altos conocimientos en la gestión de proyectos de desarrollo software. Habilidades en la interlocución con el cliente y en la toma de requisitos. Gestor avanzado en la dirección y coordinación de equipos de trabajo y en la elaboración de planes estratégicos y de negocio. Altos conocimientos de modelos de análisis, diseño, programación y otras labores técnicas relacionadas con proyectos software. Conocimientos en Metodologías de software, especialmente Proceso Unificado de Desarrollo, RUP u otros métodos de desarrollo incremental. Conocimientos en Metodologías de gestión del servicio basado en estándares (ITIL, etc.). Conocimientos de procedimientos basados en la calidad del servicio (SQA). Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 22 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

23 Experiencia Funciones Conocimientos y manejo de procesos basados en IT- Governance (gestión de la demanda, etc.). Conocimientos en herramientas de reporte de información de resultados, cuadros de mando, etc. Conocimientos tecnológicos de arquitecturas basadas en J2EE y entornos Open-Source. Conocimientos de herramientas de planificación y seguimiento de proyectos. Haber realizado durante dos años labores de Responsable de proyecto y contar con 5 años de experiencia en la realización de funciones similares a las indicadas a continuación. Gestión y planificación de las acciones llevadas a cabo en el servicio. Reporte actuaciones e informes de proyectos/versiones del desarrollo en curso. Planificación de recursos y plazos para el desarrollo de las distintas funcionalidades. Asesoramiento a usuarios. Coordinación de todo el proyecto y equipos de trabajo. Identificación de necesidades. Propuesta de soluciones. Seguimiento y control del servicio, garantizando plazos de ejecución y coste del proyecto. PERFIL 2: Jefe de Proyecto Titulación Titulación universitaria en Informática, Telecomunicaciones o Conocimiento s titulación universitaria equivalente. Altos conocimientos en la gestión de proyectos de desarrollo software. Habilidades en la interlocución con el cliente y en la toma de requisitos. Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 23 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

24 Experiencia Funciones Altos Conocimientos en la dirección y coordinación de equipos de trabajo y en la elaboración de planes estratégicos y de negocio. Altos conocimientos de modelos de análisis, diseño, programación y otras labores técnicas relacionadas con proyectos software. Conocimientos en tecnologías de presentación y tratamiento de datos y metadatos: HTML, XML, XSL, CSS, etc. Altos conocimientos de bases de datos relacionales, en particular Oracle 11g. Conocimientos Metodologías de software, especialmente Proceso Unificado de Desarrollo, RUP u otros métodos de desarrollo incremental. Conocimientos de tecnologías Webservices, SOA, firma electrónica, SOAP, XML-RPC, UDDI, WSDL. Conocimientos en despliegue de plataformas de servidores de aplicaciones, así como de servidores web sobre sistemas operativo Linux y/o Solaris (Unix). Haber realizado durante dos años labores de jefe de proyecto y contar con 5 años de experiencia en la realización de funciones similares a las indicadas a continuación. Análisis y definición de los objetivos del proyecto. Planificación de recursos y plazos para el desarrollo de las distintas funcionalidades. Asesoramiento a usuarios. Coordinación de recursos del proyecto, realizando labores de interlocución con los distintos departamentos. Identificación de necesidades. Propuesta de soluciones. Seguimiento y control del proyecto, garantizando plazos de ejecución y coste del proyecto. PERFIL 3: Analista/Arquitecto Software/Consultor Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 24 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

25 Titulación Conocimiento s Titulación universitaria en Informática, Telecomunicaciones o titulación universitaria equivalente Altos conocimientos en desarrollo de sistemas software sobre Java con fuerte impacto de tecnologías Internet, así como de toma de requisitos y modelado de arquitecturas software basadas en SOA. Altos conocimientos en modelos arquitectónicos (SOA, MDA, MDD). Altos conocimientos en el paradigma Orientado a Objetos (OO). Altos conocimientos en paradigmas Orientados a servicios (SOC). Altos conocimientos en modernización de sistemas basados en modelos (ADM, etc.). Conocimientos en tecnologías de presentación y tratamiento de datos y metadatos: HTML, XML, XSL, CSS, etc. Conocimientos de arquitectura J2EE y patrones de diseño (Model-View-Controller, etc.). Altos conocimientos de bases de datos relacionales, en particular Oracle 11g. Altos conocimientos de arquitecturas LAMP (Linux, Apache, etc.). Conocimientos de metodologías basadas en notación UML. Conocimientos de tecnologías Webservices, SOA, firma electrónica, SOAP, XML-RPC, UDDI, etc. Conocimientos de arquitecturas tecnológicas y plataformas open-source. Conocimientos de herramientas de análisis y diseño Orientado a Objetos. Conocimientos de herramientas de automatización y generación de código, persistencia, etc. Conocimientos de estilos arquitectónicos. Conocimientos de modelado de datos relacional y objeto- Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 25 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

26 Experiencia Funciones relacional (OR). Conocimientos de herramientas de desarrollo en J2EE. Conocimientos de herramientas de generación de pruebas. Haber realizado durante dos años labores de analista/arquitecto software/consultor y contar con 3 años de experiencia en la realización de funciones similares a las indicadas a continuación. Toma de requisitos para la realización del análisis funcional. Análisis y diseño de la herramienta. Desarrollo de funcionalidades. Generación de documentación, manuales y formación. PERFIL 4: Analista Programador Titulación Titulación universitaria en Informática, Telecomunicaciones o Conocimiento s titulación universitaria equivalente Altos conocimientos en desarrollo de sistemas software sobre Java con fuerte impacto de tecnologías Internet, así como de toma de requisitos y modelado de arquitecturas software basadas en SOA. Conocimientos en tecnologías de presentación y tratamiento de datos y metadatos: HTML, XML, XSL, CSS, etc. Conocimientos de arquitectura J2EE y patrones de diseño (Model-View-Controller, etc.). Altos conocimientos de bases de datos relacionales, en particular Oracle 11g. Conocimientos de arquitecturas LAMP (Linux, Apache, etc.) Conocimientos de metodologías basadas en notación UML. Conocimientos de tecnologías Webservices, SOA, firma electrónica, SOAP, XML-RPC, UDDI, etc. Conocimientos de herramientas de desarrollo J2EE (Eclipse, etc.). Conocimientos de herramientas automáticas para el testeo de Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 26 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

27 Experiencia Funciones aplicaciones. Haber realizado durante dos años labores de Analista programador y contar con 3 años de experiencia en la realización de funciones similares a las indicadas a continuación. Desarrollo de funcionalidades. Pruebas unitarias, modulares y de integración. Generación de documentación, manuales y formación. PERFIL 5: Técnico de Soporte Titulación Titulación universitaria en Informática, Telecomunicaciones o titulación universitaria equivalente Conocimiento Altos conocimientos en la definición, planificación y ejecución de s pruebas software. Altos Conocimientos de herramientas ofimáticas y de generación de informes y presentaciones. Conocimientos en tecnologías de presentación y tratamiento de datos y metadatos: HTML, XML, XSL, CSS, etc. Conocimientos de arquitectura J2EE y Model- View-Controller. Conocimientos de arquitecturas LAMP (Linux, Apache, etc.). Altos conocimientos de bases de datos relacionales, en particular Oracle 11gR2. Altos Conocimientos en lenguajes de manipulación de SGBD Objeto-Relacionales (PL/SQL, etc.). Experiencia Haber realizado durante dos años labores de Técnico de soporte y contar con 2 años de experiencia en la realización de funciones similares a las indicadas a continuación. Funciones Pruebas unitarias, modulares y de integración. Ejecución de acciones de soporte. Generación de consultas/listados/informes. Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 27 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

28 Para acreditar la cualificación del personal requerido, el adjudicatario, previo al inicio de los trabajos, deberá presentar Curriculum Vitae de los medios personales que prestarán los servicios objeto del contrato, utilizando el modelo Europass ( Se deberá justificar convenientemente el cumplimiento de los requisitos anteriormente mencionados. Los medios personales para la prestación del Servicio tendrán que tener los conocimientos y la experiencia necesarios para garantizar los trabajos contratados Sustitución medios personales La valoración final de la calidad y adecuación de los trabajos que el adjudicatario vaya realizando a través del personal que preste el Servicio corresponde al Director Técnico del proyecto designado por Red.es, siendo potestad suya solicitar la sustitución de los medios personales por otros de igual categoría, mediante aviso con quince días de antelación a la empresa adjudicataria. La sustitución deberá realizarse en un plazo máximo de 5 días contados a partir de la finalización del plazo de preaviso de quince días. Si durante la ejecución del contrato, la empresa adjudicataria propusiera el cambio del personal que realiza el Servicio, la sustitución de dicho personal requerirá en todo caso el cumplimiento de las siguientes condiciones: Justificación escrita, detallada y suficiente, explicando el motivo que suscita el cambio. Presentación de posibles candidatos con un perfil de cualificación técnica igual o superior a la de la persona que se pretende sustituir. Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 28 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

29 Aceptación del candidato por parte del Director Técnico del Proyecto designado por Red.es. En todo caso, la solicitud del cambio deberá notificarse con veinte días naturales de antelación. El incumplimiento de lo anterior, dará lugar a la aplicación de las correspondientes penalizaciones, reflejadas en el apartado 6 del Pliego de Condiciones Particulares Acuerdos de nivel de servicio El adjudicatario deberá cumplir los Acuerdos de Nivel de Servicio descritos en el presente apartado. Como tiempo máximo de resolución, se considera el periodo máximo que transcurre desde la comunicación de la incidencia hasta la resolución de la misma. Los tiempos de resolución de incidencias computarán siempre en horario laboral según se indica en el apartado 2.10 del presente pliego. La prioridad de las incidencias se determina en función del impacto y la urgencia, según la siguiente matriz:!"# $" $ El impacto se define como la medida del ámbito y la criticidad de la incidencia para el negocio. La repercusión es, con carácter general, directamente proporcional al número de usuarios o equipamiento afectado por el incidente. A menudo es equivalente a la extensión con que el incidente Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 29 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

30 distorsiona el nivel de servicio acordado o esperado. Los criterios usados para definir el impacto de las incidencias son: 1. Extenso / Generalizado El incidente afecta globalmente al servicio ofrecido en una determinada ubicación, e impide totalmente su funcionamiento normal. Afecta al 100% del equipamiento o a más del 75% de usuarios. 2. Significativo / Amplio El incidente afecta significativamente al servicio ofrecido en una determinada ubicación, y deteriora su uso. Afecta a más del 50% del equipamiento o a entre el 50 y el 75% de los usuarios. 3. Moderado / Limitado El incidente afecta parcialmente al servicio ofrecido por el equipamiento desplegado en una determinada ubicación, y deteriora su uso. Afecta a entre el 25% y el 50% del equipamiento o a menos del 50% de los usuarios. 4. Menor / Localizado El incidente tiene escaso impacto en el servicio ofrecido en una determinada ubicación. Afecta a menos del 25% del equipamiento o a menos del 25% de los usuarios. La urgencia mide la rapidez necesaria para resolver una incidencia de un determinado impacto, basada en las necesidades de negocio del cliente y en función del tipo de aplicación, sistema y/o usuario afectados: Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 30 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

31 1. Crítica 2. Alta 3. Media 4. Baja El incidente se debe atender inmediatamente. Todos los recursos se centran en la resolución. El incidente se debe atender a la mayor brevedad posible. El incidente puede ser aplazado o está planificado lo suficientemente lejos en el tiempo para permitir una respuesta sin pérdida de productividad. No existe una urgencia formal para atender la incidencia y el trabajo normal puede continuar hasta la respuesta. El adjudicatario deberá gestionar las incidencias a través del sistema de Gestión de Incidencias de Red.es, usando para ello los procedimientos establecidos a tal efecto. La recepción y gestión de las incidencias tanto en los entornos de producción como pruebas/preproducción, se realizará vía Web, de forma centralizada, a través de la herramienta que a tal efecto Red.es pondrá a disposición del adjudicatario, usando los procedimientos establecidos a tal efecto. Sobre dicha herramienta se realizará el registro y control de incidencias, tiempos de resolución, etc Parámetros de Medida para el cómputo de penalizaciones: A efectos de no tener en cuenta en el cómputo la existencia de posibles demoras no imputables al adjudicatario, a través de la herramienta de ticketing de Red.es se establecerán periodos que no serán computables a efectos del Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 31 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=

32 establecimiento de penalizaciones. En este sentido, la herramienta de ticketing de Red.es, que deberá utilizar el adjudicatario en la prestación del servicio, contempla estados de parada de reloj (p. e. cuando se necesita la acción del cliente), que implican que el tiempo transcurrido desde su inicio hasta su terminación no se computa a efectos de penalizaciones. El adjudicatario únicamente podrá activar el estado parada de reloj cuando se produzca una causa justificada, que deberá, en todo caso, acreditar de forma pormenorizada y exhaustiva. Red.es auditará el uso por parte del adjudicatario del estado parada de reloj. Red.es revisará mensualmente el nivel de prestación del servicio del adjudicatario a efectos de valorar si procede o no la imposición de penalizaciones de acuerdo con el sistema previsto en el presente apartado. No obstante lo señalado anteriormente, Red.es podrá aumentar o reducir el periodo que se tendrá en cuenta, en cuyo caso será notificado con antelación al adjudicatario. La tabla siguiente detalla los niveles del servicio, que serán utilizados para el cómputo de las penalizaciones, en función al porcentaje de cumplimiento del servicio. Nivel de prestación del Servicio % Cumplimiento del servicio (x) (porcentaje de incidencias o peticiones que no superan los Tmax) Nivel verde: óptima X 90% Nivel amarillo: no óptima 80% X <90% Nivel rojo: insuficiente 60% X< 80% Nivel negro: muy deficiente X < 60% Este archivo está almacenado en la sede electrónica de Red.es, accesible desde Pág. csv.red.es 32 de 78 con el código seguro de verificación RC8Y+z6LUX6p4Ms9AX/uxhDdJnE=