PROCEDIMIENTO ABIERTO

PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁN LA REALIZACIÓN DEL CONTRATO DE SERVICIO DE CERTIFICACIÓN DE CALIDAD DE APLICACIONES Y PRODUCTOS SOFTWARE EXP.:049/10-SE PROCEDIMIENTO ABIERTO

ÍNDICE 1. REQUISITOS TÉCNICOS... 3 1.1. REQUISITOS PARTICULARES DEL SERVICIO... 3 1.2. TIEMPO Y FORMA DE EJECUCIÓN...27 1.3. CONTROL ECONÓMICO Y DE FACTURACIÓN...32 2. FORMATO Y CONTENIDO DE LA PROPUESTA...33 2.1. PROPUESTA RELATIVA A LOS CRITERIOS CUYA VALORACIÓN DEPENDE DE UN JUICIO DE VALOR (SOBRE 3)...34 2.2. PROPUESTA RELATIVA A LOS CRITERIOS CUANTIFICABLES MEDIANTE LA MERA APLICACIÓN DE FÓRMULAS (SOBRE 4)...38 Nota: Cualquier consulta en relación con el presente procedimiento de adjudicació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. Pág. 2 de 45

1. REQUISITOS TÉCNICOS En los apartados siguientes se detallan los requisitos generales pertenecientes a todos los conceptos de contratación asociados al presente procedimiento. El licitador debe ajustar su Oferta a la terminología utilizada en este apartado. 1.1. REQUISITOS PARTICULARES DEL SERVICIO El Servicio tiene como objeto la certificación de la calidad de productos software generados durante el desarrollo de aplicaciones y sistemas informáticos en la entidad pública o por terceros colaboradores de Red.es y que serán proporcionados al adjudicatario de la Oficina de Certificación en forma de entregables. Actualmente, Red.es dispone de una Oficina o Servicio de Certificación (se utilizarán indistintamente ambos términos a lo largo de este documento), el adjudicatario del presente proceso de contratación tendrá que asegurar la continuidad del proceso de certificación y llevar a cabo las distintas actividades de certificación para el aseguramiento de la calidad, esto ha de alcanzarse mediante un proceso de mejora continua. En el presente pliego se describe el servicio actualmente en funcionamiento y las características particulares que se consideran necesarias para el nuevo servicio, ambas serán requisitos esenciales para el Servicio de Certificación. El Servicio actual basa su ejecución en tres modelos: el modelo de calidad, el modelo tecnológico y el modelo operativo. A continuación se describen las principales características de estos modelos y las necesidades detectadas que se deben cubrir. 1.1.1. MODELO DE CALIDAD El modelo de calidad describe las reglas básicas de la propia actividad de control de calidad. 1.1.1.1. MAPA DE ENTORNOS En la actualidad, la actividad de prueba llevada a cabo en la instalación de Red.es sigue un modelo basado en 5 entornos: - El entorno de desarrollo está soportado sobre infraestructura de los proveedores de desarrollo. - El entorno de pruebas, en su mayoría está soportado por los proveedores de desarrollo, y sólo para determinadas Pág. 3 de 45

aplicaciones, es soportado en infraestructura de Red.es. Sobre este entorno se realizan las pruebas de sistema y la prueba de validación de usuario. - El entorno de PREPRODUCIÓN, es base para la prueba, certificación y aceptación de las aplicaciones. En este entorno se lleva a cabo la certificación. El entorno es proporcionado íntegramente por el proveedor del Servicio de Certificación y será el responsable de su soporte, gestión, administración y operación. Constituye el primer entorno controlado de la instalación (ningún miembro de los equipos de desarrollo tendrá acceso al mismo). Todas las actuaciones sobre el mismo se llevarán a cabo siguiendo la distinta documentación generada por los equipos de desarrollo (Manual de despliegue, de instalación, de explotación, etc.). Habrá que dotar de los mecanismos de comunicaciones y seguridad necesarios para que en determinadas situaciones el entorno de preproducción sea accesible desde Red.es o desde un tercero aprobado por Red.es. En determinadas certificaciones el entorno para llevar a cabo la certificación no será el entorno de preproducción sino un entorno soportado por un proveedor de desarrollo que habilitará el acceso para llevar a cabo una certificación en remoto o en las oficinas del proveedor de desarrollo. - El entorno de demo se considera un entorno plenamente productivo, y es utilizado para pruebas sobre nuevos aplicativos, nuevas versiones, etc., en función de las necesidades particulares de cada aplicativo. Este entorno es soportado en infraestructura de Red.es. - El entorno de producción, que es soportado en infraestructura de Red.es. 1.1.1.2. ESTÁNDARES Y NORMATIVAS CORPORATIVOS Como marco normativo base para la actividad de desarrollo, Red.es establece estándares para la nomenclatura tanto de productos documentales como de los principales elementos software involucrados en la construcción de aplicaciones. El ámbito de dicha normativa aplica a conceptos como el nombre de la aplicación, estructura de directorios, generación de código java, HTML, nomenclatura de elementos de la base de datos, shell scripts del sistema operativo, entregables, comentarios de documentación mínimos, legibilidad de código, etc. Existen unas guías de buenas prácticas para la codificación en java, y para la descripción de elementos Oracle. Pág. 4 de 45

En este sentido el licitador hará una propuesta de este tipo de normativas y estándares, lo más detallada posible. 1.1.1.3. PUNTOS DE CONTROL DE CALIDAD Los diferentes puntos de control se realizan a lo largo de las fases del ciclo de vida: Fase de inicio/definición y análisis: anticipación de deficiencias o falta de completitud en los requerimientos técnicos o funcionales. o Verificación especificación de requisitos o Verificación documento de análisis Fase de elaboración / diseño: detección temprana de incumplimientos relacionados con la arquitectura de las aplicaciones y sus modelos de datos, exigiendo un correcto diseño de procesos y estructuras de datos. o Verificación diseño modelo de procesos o Verificación diseño modelo de datos o Verificación casos de prueba Fase de construcción y prueba: detección del incumplimiento de patrones y modelos de desarrollo, para garantizar una correcta construcción de desarrollos, empleo de componentes base y gestión de recursos. Minimizar el riesgo de detección de problemas en producción referentes al rendimiento y explotación de los aplicativos, garantizando la completitud y exhaustividad del proceso de prueba. o Verificación funcional del aplicativo o Verificación Codificación de Elementos SW / modelo estático o Verificación del rendimiento y explotabilidad / modelo dinámico o Verificación documentación técnica del aplicativo o Verificación documentación funcional del aplicativo Fase de transición / implantación: garantizar un correcto despliegue de componentes de aplicación en el entorno Pág. 5 de 45

productivo mediante la puesta en marcha de la estrategia más adecuada. o Verificación plan de despliegue Actualmente las distintas actividades para el cumplimiento de estos puntos de control están integradas dentro del ciclo de vida software desde las primeras fases. De este modo posibles desviaciones pueden ser detectadas en fases tempranas. Las verificaciones y controles se ejecutan mediante un conjunto de actividades, que se detallan en el modelo operativo. Se debe anexar una relación de los distintos controles que se verificarán en cada una de las actividades descritas en el modelo operativo y clasificados según su nivel de exigibilidad. 1.1.1.4. TIPOS DE CONTROLES Dentro del modelo de calidad se establecen dos tipos de controles enfocados a dar cobertura a riesgos específicos. Exigibles: controles que necesitan ser cumplidos para mitigar los riesgos que comprometan la correcta ejecución de la aplicación y su desempeño. Recomendables: controles que proveen cobertura proporcionando capacidades adicionales que facilitan la forma en la que se desarrollan, prueban y mantienen las aplicaciones pero no impactan directamente en el desempeño. Se establecen tres niveles de exigibilidad de controles, en cada uno de estos niveles cambiará la clasificación de algunos controles de recomendable a exigible o al revés, siendo el nivel N1 el más exigible y N3 el menor. Es responsabilidad de Red.es clasificar una certificación dentro de uno de estos niveles de exigibilidad. 1.1.1.5. INFORMES DE CALIDAD El proceso de certificación de calidad, dará como resultado informes cuantitativos, que en base a la definición de criterios y a la ponderación de los mismos, ofrecerá una visión global objetiva de la cobertura de requisitos de la certificación. La estructura solicitada para estos informes es como sigue: a) Resumen ejecutivo: Debe incluir una breve relación de los resultados obtenidos en cada uno de estos ámbitos indicando si el Pág. 6 de 45

resultado de la certificación es de aceptación o rechazo dentro de ellos y en función de la exigibilidad de los controles: Instalación/despliegue: Indicando si el entregable se puede instalar y las incidencias detectadas en la instalación. Indicando aceptación o rechazo dentro de este ámbito. Verificación de la documentación aportada: Resumen de muy alto nivel de las deficiencias detectadas. Indicando aceptación o rechazo dentro de este ámbito. Verificación estática de código: Resumen de muy alto nivel de las deficiencias detectadas. Indicando aceptación o rechazo dentro de este ámbito. Ejecución y verificación de pruebas unitarias: Resumen de muy alto nivel de las deficiencias detectadas. Indicando aceptación o rechazo dentro de este ámbito. Ejecución y verificación de las pruebas funcionales: Resumen de muy alto nivel del resultado de las pruebas funcionales llevadas a cabo y si este interfiere o no en el correcto funcionamiento de la aplicación de cara a liberar la versión en producción. Indicando aceptación o rechazo dentro de este ámbito. Ejecución de pruebas de carga y estrés: Resumen de muy alto nivel de las deficiencias detectadas, indicando explícitamente el número de usuarios concurrentes que soporta la aplicación en el entorno de producción, el comportamiento del sistema tras la carga de estrés y cobertura de código de la agenda empleada. Indicando aceptación o rechazo dentro de este ámbito en función de los requisitos. Ejecución de pruebas de estabilidad: Resumen de muy alto nivel de las deficiencias detectadas, si hace un uso adecuado de los distintos recursos y cobertura de código de la agenda empleada. Indicando aceptación o rechazo dentro de este ámbito en función de los requisitos. Verificación de controles de seguridad, configuración PHP y Drupal: Resumen de muy alto nivel de las deficiencias detectadas. Indicando aceptación o rechazo dentro de este ámbito. Navegación mapa web: Resumen de muy alto nivel de las deficiencias detectadas. Indicando aceptación o rechazo para cada uno de los navegadores y versiones para los que se ha certificado el aplicativo. Pruebas de regresión: Resumen de muy alto nivel de las deficiencias detectadas y cobertura de código de la prueba. Indicando aceptación o rechazo dentro de este ámbito en función de los requisitos. Pág. 7 de 45

Mejoras: Se propondrán mejoras al aplicativo en distintos ámbitos, mejoras funcionales, en el proceso de instalación, en la documentación o en cualquier otro aspecto. Visión de la mejora de la calidad del aplicativo a lo largo de las distintas certificaciones de las que ha sido objeto. b) Análisis detallado de la certificación: permite analizar el impacto de las no conformidades levantadas sobre la calidad global de la entrega. Cada uno de los puntos de control de la certificación provee un modelo de ponderaciones que contribuye a la calidad global de cada uno de los ámbitos a verificar. Este apartado se complementará con archivos anexos, en caso de que el detalle así lo amerite (p.e. para el caso de certificaciones de código). c) Informe de pruebas de carga, estrés y estabilidad: detalle de los niveles de servicio observables en operación. Extrapolación a los entornos de producción de las conclusiones relativas a los niveles de concurrencia de usuarios y detalle de la distribución de cargas entre componentes y por procesos. Informando del consumo de recursos desde el punto de vista de infraestructura de sistemas (memoria, disco, cpu, conexiones BBDD, ldap, a otros sistemas, etc.) y experiencia de usuario. El resultado de estos informes debe ser presentado a los jefes de proyecto de desarrollo de aplicaciones de Red.es. Y en general se podrá proponer añadir otro contenido que ayude a mejorar la calidad de los informes de certificación. 1.1.2. MODELO TECNOLÓGICO El modelo tecnológico describe el entorno hardware y software utilizado para la certificación de aplicaciones, es el entorno de preproducción. El entorno es proporcionado íntegramente por el proveedor del Servicio de Certificación y será el responsable de su soporte, gestión, administración y operación. A título informativo, a continuación se describen los elementos de base (comunes entre el entorno de producción y el de pruebas) y las herramientas de pruebas. 1.1.2.1. INFRAESTRUCTURA TECNOLÓGICA. Las actividades de certificación se podrán realizar sobre algunas de las siguientes infraestructuras tecnológicas, la primera (Infraestructura Tecnológica A) corresponde con la existente en Red.es, y la segunda (Infraestructura Tecnológica B) correspondiente a otras, Ministerios, Entidades o terceros y por último (Infraestructura Tecnológica C) corresponde a la que tienen los distintos proveedores de desarrollo. La mayor parte de las certificaciones se llevarán a cabo sobre la Infraestructura Tecnológica A. Pág. 8 de 45

1.1.2.2. INFRAESTRUCTURA TECNOLÓGICA A. La infraestructura de sistemas de Red.es da soporte a tres tipos de arquitecturas: Para aplicaciones J2EE Para portales PHP/MYSQL Para aplicaciones cliente/servidor La siguiente figura muestra la arquitectura correspondiente a un modelo de tres capas que tienen los distintos servicios que Red.es tiene en producción. Peticiones desde Internet Balanceadores de carga HOST servidor web apache HOST servidor web apache HOST servidor web apache HOST servidor web apache mod_jk mod_jk Balanceadores de carga HOST contenedor servlets TOMCAT App J2EE App J2EE HOST contenedor servlets TOMCAT App J2EE App J2EE BBDD BDApp.1 BDApp.1 BDApp.N BDApp.N Fig.1.-Arquitectura J2EE Red.es. Pág. 9 de 45

Los datos sobre hardware y versiones indicados a continuación son meramente informativos sobre la situación actual y pueden evolucionar en función de los requisitos de los distintos servicios. Los servidores web son variados. Como referencia, puede tomarse una máquina HP DL360 G5 o G6 con dos procesadores Intel Xeon quad core y 4GB de ram. El almacenamiento se monta desde un sistema Celerra que lo comparte por NFS. Para los servidores de aplicaciones como referencia podría tomarse una máquina HP DL360 G5 o G6 con dos procesadores Intel Xeon quad core y 4GB de ram. El almacenamiento es local. Los servidores de base de datos son, en su mayoría, máquinas SunFire V440 con 4 USIIIi 1.28Ghz y 8Gb RAM. Su almacenamiento está montado remotamente en un Clariion CX500. Actualmente, entre todos los sistemas de almacenamiento no locales, se tienen asignados (no necesariamente ocupados) aproximadamente 1 Tb (1000 Gb). Las versiones de software base y SO de cada una de las capas son las indicadas a continuación actualmente, pero se debe prever la posibilidad de cambiar de versiones, o incluso de certificar la viabilidad de un cambio de versión: En granja web opensuse 11 Servidor web: Apache En servidores de aplicaciones SuSE Linux Enterprise Server 10 Y OpenSuse 11.0. Contenedor de Servlets: Tomcat (versión dependiente de la aplicación) JDK: Versiones dependientes de la aplicación. En servidores BBDD Solaris 8 y 10 BBDD: Oracle, versiones dependientes de la aplicación 9i, 10G y 11G. El software indicado anteriormente es únicamente un mínimo, y se tienen instaladas múltiples aplicaciones adicionales. En particular, deberá disponerse de un servidor de correo (SMTP) a través del cual las aplicaciones puedan certificarse los envíos de correo de las aplicaciones (recibirá volúmenes importantes de correo). Otro servicio destacable es el de DNS. Para la certificación será necesaria la instalación de, al menos, un servidor DNS (BIND 9) sobre una SuSE Linux Enterprise Server 9 SP3. El balanceo web se realiza mediante balanceadores HW: Alteon 184 Pág. 10 de 45

Alteon Application Switch 3408 Y para determinadas aplicaciones, es imprescindible el uso de software y tarjetas criptográficas. Se dispone de: Firma Electrónica ASF v4.1 Tarjeta n-cipher modelo nshield PCI 500TPS F2 Se recuerda una vez más que el listado anterior no es exhaustivo, que la información es orientativa, que puede ser susceptible de cambios por necesidades de los servicios, y que el adjudicatario deberá disponer del software y hardware que sea necesario para llevar a cabo las certificaciones. La siguiente figura muestra la arquitectura correspondiente a aplicaciones php/mysql. El adjudicatario deberá ser capaz de asegurar que la certificación se realiza en un entorno que dé resultados extrapolables al entorno de producción y proporcionar la extrapolación en los resultados. Peticiones desde Internet Balanceador de carga HOST servidor web apache php HOST servidor web apache php BBDD BDApp.1 BDApp.1 BDApp.N BDApp.N Fig.2.-Arquitectura PHP/MySQL Red.es. Los datos sobre hardware y versiones indicados a continuación son meramente informativos sobre la situación actual, pero pueden variar en cualquier momento. Pág. 11 de 45

Los servidores de base de datos son, en su mayoría, máquinas HP DL360 G5 o G6 con dos procesadores Intel Xeon dual core y 4GB de ram Y almacenamiento local. Las versiones de software base y SO de cada una de las capas son las indicadas a continuación actualmente, pero se debe prever la posibilidad de cambiar de versiones, o incluso de certificar la viabilidad de un cambio de versión: En granja web opensuse 64 bits Servidor web: Apache En servidores BBDD opensuse 64 bits BBDD: MySQL 5.5 El balanceo web se realiza mediante balanceadores HW: Alteon 184 Alteon Application Switch 3408 La siguiente tabla recopila algunos de los datos anteriormente comentados: SERVIDORES WEB SERVIDORES APLICACIONES Apache 2.2 x86 64 bits OpenSuse 11.0 Apache 2.2 x86 32 bits OpenSuse 11.0 Apache 2.2 Suse Enterprise x86 64 bits Server 10 SP2 PHP 6.12 x86 32 bits OpenSuse 11.0 PHP 6.14 x86 64 bits OpenSuse 11.0 Drupal 5.2 x86 64 bits OpenSuse 11.0 Tomcat 5.0 x86 32 bits OpenSuse 11.0 Tomcat 5.5 x86 64 bits OpenSuse 11.0 Tomcat 6.0 x86 64 bits OpenSuse 11.0 JAVA DEVELOPMENT KIT 1.5 x86 64 bits OpenSuse 11.0 JAVA DEVELOPMENT KIT 1.5 x86 64 bits OpenSuse 11.0 SERVIDORES BBDD 1.6 MySQL 5.5 x86 64 bits OpenSuse 11.0 Oracle 9i 9i Sparc 64 Solaris 8 Oracle 10G Sparc 64 Solaris 10 Oracle 11G Sparc 64 Solaris 10 Pág. 12 de 45

El adjudicatario deberá ser capaz de asegurar que la certificación se realiza en un entorno que dé resultados extrapolables al entorno de producción y proporcionar la extrapolación en los resultados. La infraestructura propuesta debe ser dedicada. Se recuerda una vez más que el listado anterior no es exhaustivo, que la información es orientativa, que puede ser susceptible de cambios por necesidades de los servicios, y que el adjudicatario deberá disponer del software y hardware que sea necesario para llevar a cabo las certificaciones. El licitador debe presentar una propuesta de la Infraestructura Tecnológica A que servirá de soporte para el entorno de certificación, haciendo una descripción detallada de los distintos elementos de la misma y características y descripción del CPD donde se ubicará el entorno. 1.1.2.3. INFRAESTRUCTURA TECNOLÓGICA B. Los aplicativos a los que dará soporte esta arquitectura son aplicaciones J2EE basadas en un modelo MVC. El Framework utiliza la siguiente tecnología: JDK WAS Jboss Tomcat Struts Axis Spring Hibertnate Oracle 9i, 10g, Oracle Real Application Cluster (RAC) PostgreSQL Para estos aplicativos se utilizará IBM Tivoli Performance Viewer y JMeter para pruebas de rendimiento y carga. Y para determinadas aplicaciones, es imprescindible el uso de software Plataforma Firma Electrónica ASF y Alfresco como gestor documental. El hardware básico que será necesario para la aplicación está compuesto por servidores con arquitectura x86/linux (Red Hat V-9, SuSE 9 y 10, Solaris, Windows, HP-UX) que proporcionan entre otros los siguientes servicios: Pág. 13 de 45

Servicios Entorno Arquitectura J2EE y Web Services HTTP, SOAP, WSDL Servidor de Aplicaciones WAS 5.1 sobre Linux. Servidor Web IBM HTTP SERVER 2.0.47 Servidores de Base de Datos ORACLE 9I ENTERPRISE ED 9.2.0.4.0 Maquina Virtual jdk 1.4.2 1.3 Algunos de estos servidores están virtualizados mediante VMware. Esta plataforma también dará soporte a aplicaciones OBI, los estándares y auditorias son los propuestos por Oracle: OWB Oracle Warehouse Builder version 10.2.04 OBIEE:Oracle Business Intelligence Enterprise Edition version 10.1.3.4 Estos son algunos aspectos de carácter general de los aplicativos soportados en esta plataforma: Metodología de desarrollo: Métrica v3 Arquitectura J2EE Diseño arquitectónico: Basado en Struts y completado con soluciones propias del proyecto Sistemas operativos: Windows (varias versiones), Solaris (varias versiones), HP-UIX (varias versiones) Lenguajes: Java, JavaScript, jsp, xml, etc. Entorno de desarrollo: Eclipse, Websphere Studio Application Developer Business Inteligence: OWB v10.2.04 (Oracle Warehouse Builder), OBIEE v10.1.3.4 (Oracle Business Inteligence Enterprise Edition) Herramienta de control de versiones: CVS El adjudicatario deberá ser capaz de asegurar que la certificación se realiza en un entorno que dé resultados extrapolables al entorno de producción y proporcionar la extrapolación en los resultados. Se recuerda una vez más que el listado anterior no es exhaustivo, que la información es orientativa, que puede ser susceptible de cambios por necesidades de los servicios, y que el adjudicatario deberá disponer del software y hardware que sea necesario para llevar a cabo las certificaciones. Pág. 14 de 45

El licitador debe presentar una propuesta de la Infraestructura Tecnológica B que servirá de soporte para el entorno de certificación, haciendo una descripción detallada de los distintos elementos de la misma y características y descripción del CPD donde se ubicará el entorno. 1.1.2.4. INFRAESTRUCTURA TECNOLÓGICA C. Se han identificado determinadas situaciones en las que algunas actividades de certificación deberán ser llevadas a cabo en las oficinas del proveedor de desarrollo. Esta infraestructura está constituida por los entornos de los proveedores de desarrollo y por tanto, es su responsabilidad el soporte, gestión, administración y operación en los entornos de desarrollo. Las características de esta infraestructura serán similares a las descritas en los apartados anteriores Infraestructura tecnológica A y Infraestructura tecnológica B. Para llevar a cabo estas actividades de certificación el licitador enviará personal a las oficinas del proveedor de desarrollo, estas actividades se facturarán por medio de la bolsa de horas. 1.1.2.5. HERRAMIENTAS EL licitador deberá hacer una propuesta de herramientas que darán soporte a las distintas actividades de certificación que posteriormente se describen. Habrá que indicar para cada herramienta la actividad de certificación que cubre. Herramientas de análisis de código estático Herramienta de análisis de rendimiento en cliente Herramienta de análisis de rendimiento en servidor Herramienta de análisis de rendimiento de base de datos Control de procesos y gestión de incidencias (Actualmente se utiliza Atlassian JIRA como herramienta de ticketing, gestión de certificaciones y registro y control de incidencias detectadas. El adjudicatario se encargará de su administración, parametrizaciones y adaptaciones necesarias). Se podrá proponer cualquier otra herramienta/s. Herramientas para Cobertura de código Pág. 15 de 45

Y en general se podrá proponer cualquier otra herramienta que ayude a mejorar la gestión del servicio y la calidad de las certificaciones. El licitador deberá hacerse cargo de los costes de licenciamiento de las distintas herramientas propuestas. Se valorará la utilización de herramientas a modo de cuadro de mandos con un sistema reporting avanzado, acceso a información de certificaciones, que permitan analizar, monitorizar y visualizar la evolución de la calidad software de los distintos aplicativos certificados. 1.1.3. MODELO OPERATIVO El modelo operativo detalla la forma en que se realizará la prestación del servicio. Complementa con una visión de proceso a los dos modelos anteriores. En el modelo operativo se definen los diferentes actores y sus interacciones, y los workflows de las certificaciones. 1.1.3.1. ACTORES En el ciclo de vida de un proyecto de software intervienen, de forma simplificada, los siguientes actores: Proveedor de Desarrollo: Equipo o empresa que desarrolla el software, liderados por un jefe de proyecto. Desarrollo de Aplicaciones: Área en Red.es que gestiona los desarrollos. Explotación de Sistemas: Área en Red.es responsable del soporte, gestión, administración y operación de la infraestructura de sistemas de Red.es y los distintos servicios que en ella se explotan. Gestiona la Oficina de Certificación como parte de sus funciones. Oficina de Certificación: Bajo la responsabilidad de Explotación de Sistemas, asegura la calidad del software antes de su paso a producción. 1.1.3.2. RELACIÓN ENTRE ACTORES En líneas generales, los distintos actores interactúan de la siguiente forma: Desarrollo de Aplicaciones encarga los desarrollos al Proveedor de Desarrollo. El Proveedor de Desarrollo realiza sus entregas de acuerdo con la planificación establecida. La Oficina de Certificación inicia el proceso de certificación y termina emitiendo un informe de certificación. Pág. 16 de 45

Basándose en el contenido de este informe, y en otras consideraciones, Explotación de Sistemas pasa la entrega al entorno de Producción. Si el entregable se fuera a desplegar en producción, la oficina de certificación realizará las distintas tareas de integración para construir los desplegables que posteriormente explotación instalará en producción. La oficina de certificación da soporte insitu o remoto, a criterio de Red.es, a los despliegues en producción. En resumen, las relaciones que se establecerán son las que se detallan en la siguiente tabla. Proveedor de Desarrollo Desarrollo de Aplicaciones Oficina de Certificación Explotación de Sistemas Proveedor de Desarrollo Comunicación y resolución de disconformidades (*) Desarrollo de Aplicaciones Gestión de los desarrollos Entregas en diferentes hitos de cada proyecto Alcance de certificaciones Seguimiento y análisis de certificaciones (*) Oficina de Certificación Alineamiento estándares normativas Red.es a Generación de y demanda de Planificación de actividades Tareas de integración. Soporte a los despliegues. Alineamiento con la cmdb. Explotación de Sistemas Decisión respecto a subidas a producción Coordinación y planificación de actividades Gestión y alcance de la Oficina (*) Se trata de una relación a tres bandas o supervisada. Si bien es posible que existan otras relaciones, cabe remarcar que no existen, ni deben existir, comunicaciones entre la Oficina de Certificación y el Proveedor de Desarrollo que no estén supervisadas por Desarrollo de Aplicaciones. El adjudicatario del servicio deberá prestar soporte a Explotación de Sistemas en los distintos despliegues que se lleven a cabo. Este soporte será telefónico y en determinadas ocasiones y por la criticidad del despliegue podría ser in-situ. Pág. 17 de 45

El licitador hará una propuesta detallada para estar en todo momento alineado con Explotación de Sistemas en cuanto a versiones de software base, aplicativos e infraestructura de sistemas. 1.1.3.3. GESTIÓN DEL PROCESO DE CERTIFICACIÓN Se han identificado una serie de actividades certificación A i que podrán ser solicitadas a la oficina de certificación. Estas actividades se pueden clasificar en tres tipos de servicios: 1. Pruebas funcionales. Incluirán las actividades de certificación que tienen por objeto probar que el sistema cumple con las funciones específicas para las que ha sido creado. Incluye pruebas funcionales para cambios mayores o menores de versión, pruebas de regresión, etc. 2. Pruebas técnicas. Incluye las pruebas de análisis de código estático, cobertura de código, pruebas de carga, de estabilidad, controles de seguridad, etc. 3. Certificación de documentación. Incluyen la revisión de documentación de requisitos, arquitectura, funcional, manuales de explotación, plan de despliegue, instalación, etc. En el momento de planificar una certificación se consensuará el conjunto de actividades a realizar, teniendo en cuenta tanto condicionantes externos al proyecto (plazos, ciclo de vida, prioridad asignada en ese momento, etc.) como condicionantes internos (tamaño o naturaleza de los entregables, etc.). Algunas de estas actividades pueden aplicar o no en función del tipo de aplicación a certificar. A modo informativo, en los párrafos siguientes se describe una certificación completa, incluyendo todas las actividades propuestas. El licitador podrá hacer una propuesta que incluya cambios o modificaciones en los distintos flujos de trabajo. Una vez realizada la entrega por parte del desarrollador, se inicia la certificación de la misma según la planificación prevista 1. Las actividades propuestas se numeran con An de cara a su valoración económica. Previo a la realización de cada una de las siguiente actividades es importante realizar una primera verificación de la entrega, dejando constancia de todas las disconformidades encontradas a través de la herramienta de gestión de incidencias en el primer día del proceso de certificación. Estas disconformidades únicamente reflejarán la ausencia de los 1 En caso de retraso en la entrega se revisaría la planificación, por lo que, efectivamente, será según la planificación prevista. Pág. 18 de 45

diferentes productos que debería contener la entrega, pero no incluyen el resultado de analizar el contenido de los productos efectivamente entregados. A partir de este momento y si el tipo de actividad de certificación lo requiere, el equipo de certificación llevará a cabo la instalación de la aplicación (A1) en los entornos correspondientes, reflejando los errores detectados en el proceso de instalación en un plazo máximo de 2 días hábiles desde el inicio de la certificación. Una vez realizada la instalación de forma correcta se comienza con las diferentes actividades a realizar como parte del proceso de certificación. A2 - Verificación de la documentación aportada (contenido). Lectura de la documentación, realización de los controles referidos a cada documento. A3 - Verificación estática del código de la aplicación. Analizar tanto de forma automática como de forma manual en aquellos controles que lo requieran, el código de la aplicación para detectar errores a nivel estático. Por cada una de las disconformidades detectadas, se debe informar el archivo y línea donde se encuentra, así como el motivo de la misma. A4 - Ejecución y verificación de las pruebas unitarias. El equipo de certificación ejecutará y verificará la correcta ejecución de las pruebas unitarias automatizadas proporcionadas por el desarrollador. Se verifica asimismo la cobertura de código alcanzada con la ejecución de la prueba. A5 - Ejecución y verificación de las pruebas funcionales para cambios de versión mayores. Una entrega es clasificada como un cambio de versión mayor en el aplicativo cuando hay cambios significativos en su funcionalidad. Corresponde a Red.es clasificar una entrega como cambio de versión mayor o cambio de versión menor. De una manera ordenada, se realizarán pruebas funcionales para todos los perfiles que pudieran existir en el sistema. Estas pruebas deben ser lo más exhaustivas posible, al menos cubriendo un 70% en cuanto a cobertura de código se refiere. El licitador tendrá que generar y ejecutar unos planes de prueba que cubran la funcionalidad entregada. Para ello contará con la distinta documentación aportada por el proveedor de desarrollo. Además deberá ejecutar los planes de pruebas proporcionados por el proveedor de desarrollado. A6 - Ejecución y verificación de las pruebas funcionales para cambios de versión menores. Pág. 19 de 45

Una entrega es clasificada como un cambio de versión menor en el aplicativo cuando se han añadido o modificado pequeñas funcionalidades o cuando se solucionan incidencias. Corresponde a Red.es clasificar una entrega con cambio de versión mayor o cambio de versión menor. Estas pruebas funcionales estarán limitadas a la funcionalidad afectada en la entrega. El licitador tendrá que generar y ejecutar unos planes de prueba que cubran la funcionalidad entregada. Para ello contará con la distinta documentación aportada por el proveedor de desarrollo. Además deberá ejecutar los planes de pruebas proporcionados por el proveedor de desarrollado. A7 Ejecución de pruebas de carga y estrés. Análisis de los resultados de rendimiento, provenientes, según proceda, de: infraestructura (S.O.), máquina virtual, aplicación, base de datos... Se realizarán un conjunto de pruebas de carga y estrés ajustando la configuración de la agenda para modular la carga, con el fin de verificar el comportamiento de la aplicación bajo distintos escenarios de carga y concurrencia. En estas pruebas se debe asegurar un uso adecuado de los distintos recursos de los sistemas, monitorizando tanto parámetros del lado de servidor, como experiencia de usuario y conexiones a otros sistemas, así mismo habrá que indicar la cobertura de código de las agendas utilizadas. El conjunto de pruebas deberá ser capaz de proporcionar el número máximo de usuarios con los que la aplicación proporciona niveles de servicio adecuados. Terminadas las pruebas, los resultados obtenidos serán analizados exhaustivamente, logrando así formar un criterio para ofrecer conclusiones y recomendaciones sobre el rendimiento general del sistema. Existirán 2 grupos de agendas, las proporcionadas por el proveedor de desarrollo (implementadas para JMeter) y las generadas por la Oficina de Certificación para la herramienta que se haya ofertado. Antes de lanzar las agendas proporcionadas por el Proveedor de desarrollo hay que parametrizarlas de forma adecuada al entorno de certificación, ajustar los datos de prueba, la bbdd o aplicativo siguiendo la documentación aportada por desarrollo. La Oficina de Certificación deberá implementar un segundo grupo de agendas implementadas en la herramienta ofertada y que ofrezcan una cobertura de código de al menos el 70%. Pág. 20 de 45

A8 - Ejecución de pruebas de estabilidad. Análisis de los resultados de rendimiento, provenientes, según proceda, de: infraestructura (S.O.), máquina virtual, aplicación, base de datos... Se realizarán un conjunto de pruebas de estabilidad ajustando la configuración de la agenda para modular la carga, con el fin de asegurar la estabilidad del aplicativo. En estas pruebas se debe asegurar un uso adecuado de los distintos recursos de los sistemas, monitorizando tanto parámetros del lado de servidor, como experiencia de usuario y conexiones a otros sistemas. Las pruebas de estabilidad se realizarán por un periodo de 48 horas, con una carga que se considere adecuada par poder detectar cualquier incidencia de estabilidad. En caso de inestabilidad manifiesta, se detendrá la prueba de forma anticipada notificando la incidencia detectada. Terminadas las pruebas, los resultados serán analizados exhaustivamente, logrando así formar un criterio para ofrecer conclusiones y recomendaciones sobre la estabilidad en general del sistema. Para la ejecución de las pruebas de estabilidad podrán utilizarse tanto las agendas proporcionadas por el proveedor de desarrollo como las generadas por la Oficina de Certificación, argumentando la elección de una u otra basándose en criterios de calidad de los datos de prueba, cobertura de código, etc. Incluso se considerará la posibilidad de ejecutar ambas agendas, reduciendo el tiempo de ejecución a 24h cada una. A9 Verificación de controles Drupal, de seguridad y configuración PHP. Se llevarán a cabo distintos chequeos en busca de vulnerabilidades conocidas tanto en la programación como en la configuración de php. Drupal es el gestor de contenidos adoptado por Red.es para dar soporte a la mayoría de portales, por lo que se considera adecuado aumentar estos controles a aspectos específicos de Drupal. También podrán solicitarse auditorías de seguridad para el resto de aplicaciones (J2EE, etc.). A10 Navegación mapa web. Para aplicaciones web tanto J2EE como PHP se llevará a cabo una navegación por todo el mapa web, detectando enlaces rotos, experiencia de usuario adecuada a los requisitos, cumplimientos de usabilidad, de guía estilos o de normativas. Esta actividad se llevará a cabo en distintos navegadores y versiones de estos (Explorer, Firefox, Safari, Chrome, etc.). Pág. 21 de 45

A11 - Pruebas de regresión. Ejecución y verificación de pruebas de regresión. El proveedor del Servicio de Certificación implementará un conjunto de pruebas de regresión lo más automatizadas posible, con una cobertura de código de al menos el 70% y con un juego de datos de prueba lo más amplio posible, que puedan asegurar que la implementación de nuevos requisitos no ha afectado al resto de funcionalidad. A12 Certificación rápidas de parches y scripts. Estos suelen producirse como consecuencia de alguna incidencia en producción, por lo que requieren de una flexibilidad en cuanto a poca planificación y rapidez en la certificación. Sobre estas certificaciones rápidas se podrán solicitar algunas de las actividades anteriores pero muy reducidas en cuanto a la dedicación de recursos ya que solo afectan a una funcionalidad muy limitada. Esta actividad se solicita sin planificación y debe estar certificada en corto periodo de tiempo. Durante todas estas actividades es posible que surjan disconformidades. Éstas deberán ser reflejadas en la herramienta de gestión en el mismo momento en que se detecten, sin retrasar su notificación a una posible re-verificación, etc. Una vez finalizadas todas las actividades de certificación, se genera el informe con los resultados obtenidos de todas las pruebas realizadas. Dicho informe no debería aportar información nueva respecto a disconformidades, puesto que todas ellas habrán sido notificadas en Jira con anterioridad a la elaboración del mismo. El licitador podrá completar las actividades denominadas como A1 a A12 con tareas adicionales para mejorar el proceso de certificación. Habrá que indicar la duración de cada una de las actividades descritas anteriormente en función del tamaño del proyecto (pequeño o grande). Tal como se ha indicado anteriormente, durante la certificación surgen de forma habitual disconformidades con algunos de los controles definidos en el modelo de calidad. Algunas de estas disconformidades podrían dar lugar a reentregas incluso antes de la emisión del informe de certificación. Estas reentregas deberían subsanar aquellas disconformidades que afectan a controles exigibles y por tanto provocarían un resultado de rechazo en el informe. El Servicio de Certificación deberá tener la flexibilidad necesaria para poder recibir esas reentregas y realizar las actividades de certificación necesarias, reduciendo los plazos y centrando los esfuerzos en certificar solo la funcionalidad afectada por la incidencia y el resto mediante pruebas de regresión, facilitando así la reducción de tiempos tras las reentregas. El Pág. 22 de 45

informe de certificación será único, e incluirá la información relativa a las actividades realizadas sobre la versión inicial y las reentregas. El licitador deberá describir de forma clara y concisa los flujos y distintos estados por los que pasaría una certificación donde se contemplen las distintas casuísticas. En el momento en que se produzcan disconformidades sobre controles exigibles, el responsable de la Oficina de Certificación podría, en casos extremos, solicitar que se detengan las actividades de certificación y se emita un informe con la información de la que se disponga hasta el momento. Estos casos se darán, por ejemplo, si existen disconformidades que impidan manifiestamente que la aplicación pueda pasar a producción y el proveedor de desarrollo no responde planificando una reentrega dentro de los tiempos establecidos en sus SLAs. Tanto en el caso de interrupción de la certificación como en el caso de que exista una o más reentregas, se repercutirán las variaciones necesarias en la planificación y en la posterior facturación, facturándose únicamente las actividades realizadas en caso de interrupción y facturándose las actividades que haya sido necesario repetir en su totalidad en caso de reentregas. Durante la ejecución del contrato actual del Servicio de Certificación se ha establecido una herramienta (basada en el producto comercial Atlassian Jira) para agilizar las relaciones entre los diferentes actores, al tiempo que permite tener un histórico de las mismas. Jira se utiliza como herramienta de gestión del proceso de certificación, así como para el registro y control de las incidencias detectadas en el proceso de certificación. La parametrización, administración y mejora de esta herramienta forman parte integrante del objeto de este contrato. El licitador podrá ofertar otras herramientas que den soporte al proceso. Habitualmente las anteriores actividades de certificación se realizarán en las oficinas del proveedor de certificación, pero en determinadas ocasiones algunas de las actividades habrá que realizarlas en otras ubicaciones, ya sea en otros Ministerios o Entidades o en las oficinas del proveedor de desarrollo. Estas actividades llevadas a cabo in-situ se facturarán mediante bolsa de horas. EL licitador podrá proponer o modificar los distintos flujos de trabajo para mejorar el servicio de certificación. 1.1.3.4. TAREAS DE INTEGRACIÓN DE SISTEMAS El servicio de certificación tendrá que llevar a cabo tareas de integración aportando calidad al proceso de despliegue en producción. Estás tareas incluirán la parametrización y configuración tanto de aplicativo como de bbdd, compilación, generación de desplegables o cualquier otra actividad necesaria para ayudar en el despliegue de aplicativos. El servicio de certificación dará soporte remoto y a veces insitu al grupo de explotación de sistemas en los distintos despliegues en producción. Pág. 23 de 45

En este sentido se deberá hacer una propuesta sobre tareas de integración y el modelo de relación con el equipo de explotación de sistemas de Red.es. 1.1.3.5. CLASIFICACIÓN DE PROYECTOS Dada la gran variedad de proyectos que gestiona Red.es en cuanto a sus dimensiones, se hará una clasificación de estos en dos categorías. La clasificación de un aplicativo en estas categorías se realiza en base al doble criterio de esfuerzo de desarrollo y líneas de código del siguiente modo: Proyecto pequeño (PP): Los que requieren menos de 24 meses-hombre y producen menos de 80.000 Líneas de código. Proyecto grande (PG): Los que requieren más de 24 meses-hombre o producen más de 80.000 Líneas de código. Los proyectos que desarrolla Red.es no exceden en gran medida el tamaño definido para proyectos grandes, ya que si se presenta algún caso, el desarrollo se subdivide en proyectos menores o fases, por lo que no hay proyectos extremadamente grandes que desvirtúen el baremo propuesto. Corresponde a Red.es la clasificación de cada uno de los aplicativos en estas categorías. De forma general, los proyectos realizarán entregas parciales, según los hitos del proyecto y el tamaño del mismo. Existen distintos tipos de entregas a los que debe dar soporte la Oficina de certificación: Aplicativo nuevo. Aplicativo que nunca ha existido en producción. Se clasificará como proyecto pequeño o grande y se solicitaran la mayor parte de las actividades de certificación. Debido a que la Oficina de Certificación se integra en todas las fases del ciclo de vida software, es habitual que se hayan realizado anteriormente certificaciones de documentación y de parte del funcional. Nuevas versiones. Se refiere a aplicativos que incorporan nueva funcionalidad y mejoras significativas. Se clasificará como proyecto pequeño o grande y se solicitaran algunas de las actividades de certificación. Parches y scripts. Se refiere a pequeños desarrollos que solventan alguna incidencia en producción. Por su criticidad requieren de una certificación rápida. Los tiempos máximos para una certificación completa por tipo de proyecto serán: Pág. 24 de 45

Certificación de proyecto pequeño: 7 días laborables desde el inicio de la certificación. Certificación de proyecto grande: 14 días laborables desde el inicio de la certificación. Certificación rápida de parche y script: 4 días laborables desde su solicitud. 1.1.3.6. COMPETENCIAS REQUERIDAS El objeto del contrato deberá ser prestado en modalidad de servicio, por lo que será el adjudicatario el encargado de tener disponibles y organizar los medios técnicos necesarios para realizar dicha prestación con el nivel de calidad exigido en el presente Pliego. Red.es no establece la cantidad de personas que deben prestar el servicio de certificación. Los medios personales ofertados por el licitador para la prestación del Servicio deberán tener la solvencia técnica y profesional definida a continuación. Los licitadores deberán disponer de medios personales que posean cualificación y conocimientos que se detallan a continuación: Instalación, configuración y administración de servidores web (especialmente Apache) Instalación, configuración y administración de servidores de aplicaciones (especialmente Tomcat) Instalación, configuración y administración de servidores de directorio, LDAP (especialmente Active Directory y OpenLDAP) Instalación, configuración y administración de servidores de correo (especialmente Exim, Sendmail) Instalación, configuración y administración de DNS (BIND) Conocimientos de gestores de contenidos Conocimientos J2EE Conocimiento PHP Conocimientos Drupal Configuración y mantenimiento hardware Sparc e Intel Administración de S.O. Solaris, Linux (Suse y RedHat) Administración de Cluster (preferiblemente Sun Cluster) Herramientas de gestión de volúmenes en disco (SDS/Veritas) Gestión de almacenamiento en red (NAS-SAN) Pág. 25 de 45

Herramientas de backup (preferiblemente Omniback) Administración de BBDD Oracle v.9 o v10 sobre UNIX (preferiblemente Sun Solaris) y MySQL Backup y Recovery mediante RMAN Oracle Enterprise Manager (OEM) Tuning Conectividad TCP/IP Programación de shell scripts Conocimientos profundos en TCP/IP Administración de redes Routing dinámico (RIP, OSPF) Tecnologías LAN y WAN Configuración y administración de routers (Enterasys, Cisco, ) Alta disponibilidad (VRRP, balanceo) Configuración y administración de firewalls (Checkpoint, Stonegate, Fortinet) Encriptación y Certificados digitales ACLs Auditorías de seguridad Soluciones de seguridad Legislación de seguridad (L.O.P.D. y L.S.S.I.) Gestión de proyectos Durante el plazo de vigencia del contrato el adjudicatario deberá mantener la disponibilidad de medios personales que cuenten con cualificación y conocimientos en los ámbitos citados anteriormente. En el caso de que Red.es detecte que el adjudicatario no dispone de dichos medios se reserva el derecho de aplicar las penalizaciones que se establecen el Pliego de Condiciones Particulares. 1.1.4. PROCESO DE MEJORA DEL SERVICIO Una vez implantado el servicio debe iniciarse un proceso de mejora continua de la oficina de certificación. El licitador deberá hacer una propuesta detallada de un plan de mejora del servicio, implantando y documentando los procesos, Pág. 26 de 45

procedimientos y mejoras en general que cree necesarios para ir dotando de madurez al servicio. Dentro de este ámbito se realizarán una serie de tareas adicionales: Realización de plantillas sobre la distinta documentación exigida. Realización de un paquete de documentos que incluyan las plantillas, presentaciones y controles exigibles por la Oficina de Certificación y que se entregarán a un proveedor nuevo de desarrollo que le informen de los distintos puntos de control que deberán cumplir sus entregables. Presentación y formación a proveedores de desarrollo sobre la oficina de certificación, las certificaciones y cómo interactuar con la Oficina de Certificación. 1.2. TIEMPO Y FORMA DE EJECUCIÓN 1.2.1. PLANIFICACIÓN, DIRECCIÓN Y SEGUIMIENTO DE LOS TRABAJOS Corresponde a Red.es la supervisión y dirección de los Servicios, proponer las modificaciones convenientes o, en su caso, proponer la suspensión de los mismos si existiese causa suficientemente motivada. Red.es designará un Director Técnico cuyas funciones en relación con el presente Pliego serán: o Velar por el cumplimiento de los trabajos exigidos y ofertados. o Coordinar y colaborar las acciones con los medios personales ofertados para la buena marcha del proyecto. El Director Técnico podrá incorporar al equipo de trabajo a las personas que estime necesarias para verificar y evaluar todas las actuaciones a su cargo. El personal ofertado para la realización de los trabajos deberá integrarse, a petición de Red.es, en grupos de trabajo mixtos en los que también participarán técnicos propios de Red.es o personal de otras empresas colaboradoras. Las tareas, funciones y competencias de cada uno de los integrantes de los grupos mixtos se determinarán en todo momento según el criterio del Director Técnico, quien además podrá designar jefes de equipo que lideren cada uno de los grupos de trabajo que se puedan crear de forma simultánea. Pág. 27 de 45

El Director Técnico podrá fijar reuniones periódicas entre Red.es y el adjudicatario con el fin de determinar, analizar y valorar las incidencias que, en su caso, se produzcan en ejecución del contrato. Para el seguimiento y control del servicio, el licitador propondrá un modelo de relación que describa de forma detallada los distintos aspectos del mismo y que este basado en un modelo externalizado de servicios. Se debe hacer una propuesta de informe de servicio mensual detallada donde aparezcan, entre ostros, un resumen ejecutivo, indicadores de volumen del servicio, indicadores de calidad del servicio, y distintos aspectos que se consideren adecuado. Este modelo debe contemplar la asignación de un responsable del servicio con dedicación total en las oficinas de Red.es para llevar a cabo labores de gestión del servicio, interlocución, seguimiento, análisis y presentación de certificaciones, alineamiento con grupos de desarrollo y explotación, planificaciones y en general a cualquier actividad que ayude a mejorar el servicio de certificación. 1.2.2. TRANSICION El adjudicatario deberá garantizar que el servicio esté plenamente operativo 21 días naturales después de la fecha de notificación de la adjudicación definitiva del Contrato. Para ello, deberá diseñar un plan de transición (y presentarlo incluido en la oferta) que garantice el cumplimiento de este plazo. Red.es deberá validar esta disponibilidad completa del servicio, por lo que no se considerará operativo el servicio hasta que el adjudicatario reciba la aceptación por parte de Red.es. La demora en el inicio del servicio plenamente operativo dará lugar a la aplicación de las penalizaciones descritas en el apartado 6 del PCP. La primera factura se emitirá una vez que el servicio esté 100% operativo, e incluirá únicamente la parte proporcional del coste base mensual a los días hábiles del mes en que el servicio haya estado plenamente operativo. 1.2.3. SUSTITUCIÓN DE LOS MEDIOS PERSONALES La valoración final de la productividad y calidad de los trabajos del personal que preste la Asistencia Técnica corresponde al Director Técnico, siendo potestad suya solicitar el cambio de los medios personales por otros de igual categoría, mediante aviso de quince días de antelación a la empresa adjudicataria. Pág. 28 de 45