OBJETO Y ALCANCE DEL CONTRATO...5

Transcripción

1 PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACION, POR PROCEDIMIENTO ABIERTO, DE SERVICIOS DE MANTENIMIENTO, SOPORTE Y DESARROLLO DE APLICACIONES Y ADMINISTRACIÓN Y GESTIÓN DE SISTEMAS INFORMÁTICOS PARA EL MINISTERIO DE CIENCIA E INNOVACIÓN Febrero de 2010 Página: 1

2 ÍNDICE 1 INTRODUCCIÓN ANTECEDENTES OBJETO Y ALCANCE DEL CONTRATO OBJETO DEL CONTRATO ESTIMACIÓN PRESUPUESTARIA Y ACTUALIZACIÓN DE PRECIOS DISTRIBUCIÓN EN LOTES PERSONAL Y RECURSOS MATERIALES NECESARIOS BASES TÉCNICAS DEL CONTRATO INTRODUCCIÓN ASPECTOS TÉCNICOS GENERALES APLICABLES A TODOS LOS LOTES MODELO DE SERVICIO GENERAL ESPECIFICACIONES APLICABLES AL LOTE ESPECIFICACIONES APLICABLES AL LOTE ESPECIFICACIONES APLICABLES AL LOTE ESPECIFICACIONES APLICABLES AL LOTE ESPECIFICACIONES APLICABLES AL LOTE MODELO DE RELACIÓN Y EQUIPO DE TRABAJO MODELO DE RELACIÓN CON EL SUMINISTRADOR EQUIPO DE TRABAJO DURACIÓN DEL CONTRATO FORMA DE PAGO PERÍODO DE GARANTÍA Y SU EXTENSIÓN RESPONSABILIDAD POR DAÑOS Y PERJUICIOS PROPIEDAD INTELECTUAL Y CONFIDENCIALIDAD DE LA INFORMACIÓN PROTECCIÓN DE DATOS TRANSFERENCIA DE TECNOLOGÍA Página: 2

3 1 INTRODUCCIÓN 1.1 Antecedentes El Real Decreto 1042/2009, de 29 de Junio, por el que se desarrolla la estructura orgánica básica del Ministerio de Ciencia e Innovación, en adelante MICINN, y el Real Decreto 542/2009, de 7 de abril, por el que se desarrollan sus competencias, establecen que le corresponde la propuesta y ejecución de la política del Gobierno en materia de investigación científica, desarrollo tecnológico e innovación en todos los sectores, así como la coordinación de los organismos públicos de investigación de titularidad estatal. En particular, corresponde al Ministerio la elaboración de la propuesta, gestión, seguimiento y evaluación de los programas nacionales y acciones estratégicas del Plan Nacional de Investigación Científica, Desarrollo e Innovación Tecnológica. El Plan Nacional de Investigación Científica y Desarrollo Tecnológico contemplado en La Ley de la Ciencia y denominado desde el 2000 Plan Nacional de Investigación Científica, Desarrollo e Innovación Tecnológica, es el instrumento de programación de la I+D y la innovación tecnológica del Estado, creado por el Gobierno para el fomento y la coordinación general de la investigación científica y técnica. El Plan Nacional se elabora para periodos de cuatro años y en él se establecen, a través de programas específicos, las prioridades gubernamentales y los actores a los que va dirigida la acción pública. El VI Plan Nacional de Investigación Científica y Desarrollo Tecnológico contempla el periodo y responde a los tres principios básicos recogidos en la Estrategia Nacional de Ciencia y Tecnología (ENCYT): Poner la I+D+i al servicio de la ciudadanía, del bienestar social y de un desarrollo sostenible, con plena e igual incorporación de la mujer. Hacer de la I+D+i un factor de mejora de la competividad empresarial. Reconocer y promover la I+D como un elemento esencial para la generación de nuevos conocimientos. Página: 3

4 Es responsabilidad de la Subdirección General de Tecnologías de la Información y las Comunicaciones (en adelante SGTIC) el impulso y coordinación de la política informática del Ministerio y de sus diferentes organismos, el desarrollo de los sistemas de información necesarios para el funcionamiento de los servicios, la implantación de la administración electrónica en el departamento, la gestión y administración de las redes de comunicación de voz y datos, la administración del dominio de Internet y portal del ministerio, el asesoramiento y asistencia en materia de tecnologías de la información. El desarrollo de esta infraestructura de sistemas de información se viene realizando con el apoyo técnico de empresas de consultoría, integración y desarrollo, lo cual ha permitido mantener un continuo nivel de actualización en materia de Tecnología, Información y Comunicaciones (en adelante TIC), además de una mayor flexibilidad en cuanto a la disponibilidad de recursos técnicos en los momentos en los que ha sido necesario. Se plantea con este concurso la contratación de los servicios de apoyo informático que permitan mantener el nivel de actualización y mantenimiento de estos sistemas informáticos, además de la construcción de nuevos módulos en torno a dichos sistemas. Atendiendo a la especificidad de cada sistema de información, el concurso se dividirá en lotes. Aunque todos ellos comparten el procedimiento de licitación y adjudicación, cada uno de los lotes será objeto de un contrato independiente con la empresa adjudicataria del mismo. Página: 4

5 2 OBJETO Y ALCANCE DEL CONTRATO 2.1 Objeto del Contrato El objeto de este expediente es la contratación de servicios de mantenimiento, soporte y desarrollo de aplicaciones y administración y gestión de sistemas informáticos para la Subdirección General de Tecnologías de la Información y las Comunicaciones del Ministerio de Ciencia e Innovación. El alcance de los trabajos detallados en este Pliego de Prescripciones Técnicas, comprende la provisión de los perfiles y esfuerzos horas/hombre necesarios, de acuerdo al modelo de gestión especificado. Los objetivos a alcanzar son: Dotar a los órganos superiores del Ministerio de sistemas de información actualizados conforme a la evolución tecnológica y las normativas vigentes. Establecer las adecuadas medidas de operación, seguridad y disponibilidad en la infraestructura hardware y software de base que permitan asegurar el servicio en todo momento. Implantar gradualmente un modelo de servicio de mantenimiento integral de aplicaciones y sistemas, gestionado en base a Acuerdos de Nivel de Servicio (en adelante, ANS) entre la SGTIC y el suministrador. Fomentar la productividad y la eficiencia en la función TIC. Optimizar el modelo de costes actual asociado a la función de Mantenimiento de Aplicaciones. Incremento de la Calidad del Servicio. 2.2 Estimación presupuestaria y actualización de precios Con carácter general, salvo que explícitamente se indique otra unidad, para las estimaciones de los distintos periodos de tiempo que se contemplan y de sus costes, Página: 5

6 incluido el cálculo de penalizaciones, se ha partido, siguiendo las instrucciones de la Comisión Permanente del Consejo Superior de la Administración Electrónica, de los supuestos siguientes: Jornada laboral: 8 horas. Días laborables: de lunes a viernes, excepto festivos. Mes: 20 jornadas laborales. Año: 11 meses (el decimosegundo, se considera vacaciones, prorrateándose en caso de considerar periodos inferiores al año). 2.3 Distribución en Lotes De acuerdo al artículo 74.3 de la LCSP, se procede a la división del contrato en 5 lotes, diseñados en función de las características de los servicios, la homogeneidad de los entornos físicos y/o lógicos a los que va destinado el servicio objeto de contratación y la agrupación de los servicios por unidad funcional destinataria de los mismos; facilitando, de ese modo, una mayor especialización en los equipos de trabajo. Lote 1: Servicios de soporte al desarrollo de aplicaciones para la solicitud de ayudas y subvenciones a través de la web. Lote 2: Servicios de soporte al desarrollo de aplicaciones en los ámbitos de Tramitación y Gestión Económica. Lote 3: Servicios de soporte al desarrollo de aplicaciones en los ámbitos de Evaluación, Justificación Web, Científico-Técnica y Económica. El Lote también incluye las labores correspondientes a la Arquitectura de Datos de las aplicaciones del Área. Lote 4: Servicios de soporte al desarrollo de las aplicaciones en los ámbitos del portal Web e Intranet del Ministerio, infraestructura de tramitación y procedimientos administrativos de gestión interna (PRO@). Página: 6

7 Lote 5: Servicios de asistencia técnica en el ámbito de técnica de sistemas, operación y comunicaciones. Para cada lote, se presenta el presupuesto máximo estimado indicado en la tabla: Lote TOTAL Lote ,98 Lote ,07 Lote ,38 Lote ,06 Lote ,80 Total ,29 Tabla 1. Distribución del presupuesto máximo por Lote (IVA excluido, sin considerar prórrogas). 2.4 Personal y recursos materiales necesarios Tipología de trabajos a desarrollar Se diferencian dos tipos de actividad dentro de los trabajos objeto del presente pliego: Línea Base (Actividades no planificables): Se caracteriza por el conjunto de actividades que garantizan el correcto funcionamiento y el adecuado nivel de actualización y mejora necesario de los sistemas: o Mantenimiento de base: que incluye mantenimiento correctivo, gestión de incidencias, consultas de usuarios, transferencias de datos, informes analíticos y administración de aplicaciones. o Adaptaciones y mejoras: se caracteriza por el conjunto de modificaciones necesarias en los sistemas informáticos para adaptarse a los cambios de las convocatorias del Plan Nacional de I+D+i, así como las mejoras de los sistemas Intranet e Internet (portal Web). La unidad de medida de esfuerzo en esta tipología de trabajo, de cara al dimensionamiento y gestión por lote, será el número de horas por perfil reconocido en el epígrafe del presente pliego. Página: 7

8 El esfuerzo estimado para la línea base será revisado durante la ejecución del contrato, en función de las fluctuaciones de la demanda a futuro y de acuerdo al procedimiento expresado en el capítulo del presente pliego de prescripciones técnicas. Variable no garantizado (Actividades planificables): está orientado a necesidades específicas que pueden implicar eventuales desarrollos de proyectos, en el ámbito del mantenimiento evolutivo de las aplicaciones objeto del lote y con un alcance cerrado. Dado el carácter eventual de estas actividades, se diferencia de manera nítida de las actividades anteriores, que obedecen a necesidades continuas. Al igual que en la línea base, la unidad de medida de esfuerzo en esta tipología de trabajo, de cara al dimensionamiento y gestión por lote, será a partir de un número de horas por perfil propuesto para abarcar el desarrollo, de acuerdo al modelo de gestión contemplado en el epígrafe y al cuadro tarifario especificado en la tabla 2 del presente pliego de prescripciones técnicas. Cada una de estas líneas de actividad contempla requisitos diferentes relativos a la ubicación geográfica de los equipos, así como un marco de tarifas de referencia diferente. Todas estas particularidades, así como el volumen de cada tipología de actividad por lote, serán detalladas en los siguientes epígrafes de forma genérica, particularizando para cada lote en el capítulo Categorías Profesionales a considerar en la Línea Base y precios unitarios Para identificar al personal que prestará los servicios de tipo Línea Base, se ha usado el Modelo de Referencia de las Funciones Informáticas para la Contratación (MRFI-C), donde se tipifican las categorías profesionales susceptibles de ser contratadas por la Administración Pública ( vigente en Enero de 2010). Las distintas categorías profesionales establecidas para la ejecución del objeto de este contrato, sus requerimientos asociados y el precio máximo por hora/profesional se Página: 8

9 muestran en la tabla 2. No obstante, las funciones y la formación de los distintos equipos de trabajo se efectuarán en base a los perfiles técnicos establecidos en el capítulo 3 Bases técnicas y el apartado 4.2 Equipo de trabajo del presente pliego. Categoría Descripción Requerimientos CS Consultor Senior Titulado Superior con 5 años de experiencia, o Titulado Medio con 7 años de experiencia. CO Consultor Titulado Superior con 2 años de experiencia, o Titulado Medio con 3 años de experiencia. JP Jefe de Proyecto Titulado Superior con 4 años de experiencia, o Titulado Medio con 5 años de experiencia. Titulado Superior con 2 años de experiencia, o AF Analista Funcional Titulado Medio con 3 años de experiencia o ciclo formativo de grado superior con 4 años de experiencia. AP PR TSS TSJ TCOM OP Analista Programador Programador Técnico de Sistemas Senior Técnico de Sistemas Técnico de Comunicaciones Operador Titulado Superior con 6 meses de experiencia, o Titulado Medio con 1 año de experiencia, o Ciclo Formativo de Grado Superior con 2 años de experiencia. Titulado Superior, Titulado Medio con 6 meses de experiencia, o Ciclo Formativo de Grado Superior con 1 año de experiencia, o 4 años de experiencia como Programador. Titulado Superior con 2 años de experiencia, o Titulado Medio con 3 años de experiencia o ciclo formativo de grado superior con 4 años de experiencia. Titulado Superior con 1 año de experiencia, o Titulado Medio con 2 años de experiencia o Ciclo Formativo de Grado Superior con 4 años de experiencia Titulado Medio con un1 año de experiencia o Ciclo Formativo de Grado Superior de Comunicaciones o Electrónica con 2 años de experiencia Ciclo Formativo de Grado Medio con 1 año de experiencia, o 3 años de experiencia como Operador o en trabajos similares. Tarifa hora ( sin IVA) 76,36 56,55 68,01 49,17 42,30 29,91 50,00 35,56 30,57 22,97 Tabla 2. Categorías profesionales consideradas por la SGTIC para la prestación de los servicios definidos en el presente Pliego de Prescripciones Técnicas. Página: 9

10 Al aplicar los requerimientos, a efectos de presentación de la oferta, se tendrán en consideración las siguientes circunstancias particulares, para todas las categorías presentadas, salvo en el caso de la categoría Operador : - Solo se tendrán en cuenta las titulaciones universitarias de las familias Enseñanzas técnicas y Ciencias Experimentales o equivalentes de acuerdo a la normativa vigente. - La titulación media a la que se alude en la tabla equivaldrá a enseñanzas universitarias de primer ciclo o equivalente de acuerdo a la normativa vigente. - La experiencia solo se considerará en Tecnologías de la Información y Comunicaciones. En el capítulo 4, Equipo de Trabajo, se describe el detalle de cláusulas técnicas de gestión de recursos humanos para los trabajos relativos a la Línea Base Variable no garantizado Las actividades correspondientes al variable no garantizado surgen cuando una parte del servicio a prestar para el correcto mantenimiento de las aplicaciones, puede ser aislada, por estar caracterizada por unos objetivos perfectamente determinados y un plazo para su ejecución. Esta situación obliga a aplicar una metodología de trabajo correspondiente a proyecto de llave en mano (vinculado al mantenimiento evolutivo), facturando el trabajo por hitos y aplicando penalizaciones específicas a cada proyecto. Las fases que caracterizan esta modalidad de trabajo y los entregables básicos son esquematizadas en la tabla 3. Etapa Entregable Responsable Definición de requisitos Requisitos funcionales y/o técnicos. SGTIC Estimación de alcance Estimación de coste de horas por perfil propuesto en el equipo de trabajo, planificación, especificación de entregables, hitos de entrega y Suministrador facturación. Aceptación de alcance N/A (La SGTIC expedirá un certificado de aprobación de alcance). SGTIC Desarrollo del Proyecto Entregables especificados en la estimación de alcance. Aceptación de hitos del proyecto N/A (La SGTIC expedirá un certificado de consecución de hitos). Finalización del N/A (La SGTIC expedirá un certificado de validación de entrega del Proyecto proyecto). Tabla 3. Procedimiento de gestión del variable no garantizado. Suministrador SGTIC SGTIC Página: 10

11 El equipo asignado a estas tareas, estará formado por perfiles con experiencia en desarrollo de proyectos en formato cerrado, con capacidades para la gestión de proyectos (estimación, planificación, asignación de recursos, ), realización de análisis y diseño y con la experiencia y conocimiento técnico y funcional necesario para el correcto desempeño de su trabajo. Además, este equipo debe asumir las tareas de gestión, organización y seguimiento del proyecto. Para cuantificar las actividades asociadas al variable no garantizado, la unidad de medida de esfuerzo será el número de horas por perfil (definido el perfil en la tabla 2 del presente Pliego de Prescripciones Técnicas) Dimensionamiento de los lotes El licitador deberá realizar la Oferta Económica en base al dimensionamiento inicial del Servicio contenido en el presente apartado Línea base Analizados todos los sistemas de información contemplados en este pliego, se ha estimado que la cuantía de los recursos humanos necesarios para realizar las tareas especificadas en la línea base de cada uno de los lotes, por año de prestación del servicio, es la que se indica en la tabla anexa, de acuerdo a las categorías definidas con anterioridad: Perfil solicitado (sobre el supuesto del primer año de contrato) Equipo Lote CS CO JP AF AP PR OP TSS TSJ TCOM base Lote Lote Lote Lote Lote Total Página: 11

12 Perfil solicitado (sobre el supuesto del primer año de contrato) Equipo Lote CS CO JP AF AP PR OP TSS TSJ TCOM base Lote Lote Lote Lote Lote Total Tabla 4. Línea base estimada anual por lote (horas por tipo de recurso y número de recursos / año). El adjudicatario de cada lote deberá presentar, al menos, el 80 % del equipo presupuestado (equipo base) indicado en las tablas anteriores durante los 15 primeros días de inicio de los trabajos objeto del contrato. Durante la ejecución de los trabajos, el MICINN podrá, en función de las necesidades reales sobrevenidas, redistribuir las horas a realizar efectivamente entre las diferentes categorías o variar la composición del equipo de trabajo definido, tomando como base de ponderación la escala de tarifas indicada anteriormente. Deben cumplirse dos condiciones: No sobrepasar el importe total del contrato. Corresponder a trabajos del proyecto objeto del servicio. En el apartado 3.3 del presente pliego, se detalla el procedimiento de revisión de la línea base en función de la demanda a atender Variable no garantizado Se muestran, en la tabla 5, los esfuerzos anuales máximos estimados, para los servicios de mantenimiento evolutivo de coste variable (sin compromiso de asignación por parte de la SGTIC), para cada lote y año de duración del contrato. Lote Horas / año Lote Lote Lote Lote Lote 5 0 Total Tabla 5. Alcance máximo del variable no garantizado por cada lote y año de contrato (se expresan las horas disponibles para un perfil de Analista Programador). Página: 12

13 3 BASES TÉCNICAS DEL CONTRATO A continuación se describen en detalle los distintos lotes objeto del contrato, indicando su contenido funcional y tecnológico, los trabajos a realizar y el modelo de servicio asociado. De forma previa, se indican aquellos requisitos generales que aplican al conjunto de los lotes objeto del contrato. 3.1 Introducción Lotes 1, 2 y 3 Una de las principales funciones de la SGTIC consiste en dar soporte tecnológico al ciclo de vida completo de las ayudas y subvenciones del Ministerio de Ciencia e Innovación. El ciclo de vida de una convocatoria de ayuda o subvención, desde el punto de vista de los Sistemas de Información, es: Preparación de la convocatoria o Reuniones de preparación o Publicación en BOE o Publicación WEB Solicitud telemática o Admisión de Solicitudes o Admisión de documentación adicional o Revisión Formal o Diagnóstico Solicitud: Incompleta o con errores subsanables Tramitación o Notificación subsanación o Revisión administrativa o Envío a ANEP y a otros organismos de evaluación o Evaluación o Devolución de resultados de Evaluación o Resolución Provisional o Publicación Trámite de audiencia Página: 13

14 o Recepción Alegaciones o Publicación resolución definitiva o Publicación WEB de la resolución Gestión Económica o Asignación Económica o Gestión Económica del pago o Amortizaciones o Avales Justificación Económica y Científica o Justificación Económica o Justificación Científica o Seguimiento de Ejecución o Incidencias o Justificación final o Consulta de seguimiento o Reintegros La responsabilidad en torno a estos sistemas de información, y el servicio de atención al ciudadano (sobre las aplicaciones de ayudas), recae en el Área de Desarrollo para la Investigación, dependiente de la SGTIC. Esta área es responsable de distintas aplicaciones, con una edad media de 5 años desde su implantación, que han sido desarrolladas y explotadas previamente en otros organismos de la Administración General del Estado. En la actualidad, se dispone de más de una veintena de sistemas integrados para dar soporte a las relaciones entre el ciudadano y el Ministerio, con más de medio centenar de aplicaciones que cubren desde la solicitud de la ayuda por parte del ciudadano, la tramitación, justificación y evaluación por las distintas Direcciones Generales y expertos, hasta la resolución final y gestión económica de las mismas. Página: 14

15 El volumen de usuarios medio de las aplicaciones es muy alto (decenas de miles anualmente) y existe un importante volumen de cambios a implantar para cubrir las modificaciones exigidas por las áreas funcionales del Ministerio. La arquitectura software de las aplicaciones se basa en estándares Java y OAS (Oracle Application Server). El área dispone de una arquitectura propia de desarrollo, Fénix, descrita en el epígrafe de este documento, cuyo objetivo final consiste unificar tecnologías y estándares de diseño y desarrollo para todas las aplicaciones del área. En este escenario, los siguientes epígrafes detallan las cláusulas con las que se pretende provisionar al ADI del soporte necesario para la prestación del servicio objeto del presente pliego. Para articularlo, se define un modelo de gestión transparente, dimensionando y tipificando en detalle la actividad a desarrollar y estableciendo niveles de servicio que permitan la mejora continua de los sistemas y la eficiencia del Área Lote 4 Además del soporte a las aplicaciones de gestión de ayudas y subvenciones, la SGTIC proporciona un conjunto de aplicativos de soporte horizontal a todas las áreas usuarias del Ministerio: portal web, portal Intranet, gestión electrónica de procedimientos administrativos internos, infraestructura de tramitación (repositorio documental, portafirmas, registro) y aplicaciones de gestión (personal, permisos, concursos, formación, acción social): Portal web del Ministerio de Ciencia e Innovación: o Información del Ministerio de Ciencia e Innovación. o Buscador de ayudas y subvenciones. o Acceso a las funcionalidades de administración electrónica del Ministerio. o Sede electrónica del Ministerio. o Portal de Contratación del Ministerio. Página: 15

16 o Entorno colaborativo (web 2.0: blogs, foros, wiki, comunidades). o Multicanal. Intranet del Ministerio de Ciencia en Innovación: o Sistemas informacionales y colaborativos. o Comunicados y noticias. o Directorio. o Sugerencias. o Espacio para recursos humanos. o Espacio para régimen interior. o Espacio para tecnologías. Infraestructura y Aplicaciones Internas: o Escritos (instancia libre, oficio, nota interior). o Acción Social (estudio hijos, gastos sanitarios, ayuda transporte) o Excedencia (voluntaria, hijos, servicios). o Seguridad (acreditaciones, vehículos, externos, edificios). o Permisos (vacaciones, asuntos particulares, nacimiento). o Reconocimiento (grado, antigüedad, servicios previos). o Consulta Nomina (mensual, datos bancarios). o Formación (coordinadores, cursos, plan de formación). o Repositorio documental. Página: 16

17 o Portafirmas. o Registro orgánico interno. La responsabilidad en torno a estos sistemas de información recae en el Área de Desarrollo Horizontal (ADH), dependiente de la SGTIC. La arquitectura software de las aplicaciones se basa en estándares.net, OAS, Vignette y Java. Se trata de un conjunto de aplicativos con un alto grado de despliegue de nuevas funcionalidades durante el ejercicio 2009 y comienzos del 2010, si bien se partía de un conjunto desarrollado en el entorno de otros organismos de la Administración General del Estado. En este escenario, los siguientes epígrafes detallan las cláusulas con las que se pretende provisionar al ADH del soporte necesario para la prestación de los servicios identificados en el presente pliego. Para articularlo, se define un modelo de gestión transparente, dimensionando y tipificando en detalle la actividad a desarrollar, estableciendo métodos y niveles de servicio que permitan la mejora continua de los sistemas y la eficiencia del Área Lote 5 Realización de trabajos de mantenimiento y administración de sistemas, así como efectuar el análisis de incidencias y la gestión de sistemas informáticos, además del mantenimiento de telefonía e instalación de cableado. Además realizar el soporte técnico en consultas y actuaciones relativas al funcionamiento de los mismos presentadas por personal de la SGTIC y del Ministerio. Página: 17

18 3.2 Aspectos técnicos generales aplicables a todos los lotes Requisitos técnicos generales En referencia a los trabajos de análisis y desarrollo de sistemas, se deberán aplicar las siguientes consideraciones de carácter general: Utilización de estándares abiertos y reutilización de componentes comunes proporcionados por las distintas arquitecturas. Integración XML. Navegación intuitiva para el usuario. Las interfaces gráficas accesibles por el ciudadano, disponibles en Internet, deberán dar cumplimiento a las prioridades 1 y 2 de la Norma UNE :2004 dando cumplimiento al REAL DECRETO 1494/2007, de 12 de noviembre, por el que se aprueba el Reglamento sobre las condiciones básicas para el acceso de las personas con discapacidad a las tecnologías, productos y servicios relacionados con la sociedad de la información y medios de comunicación social Normas y arquitectura de los aplicativos (Lotes 1, 2, 3 y 4). La planificación, ejecución, análisis, diseño, construcción e implantación de Aplicaciones y Sistemas de Información se ajustarán a lo contenido en la Metodología MÉTRICA, promovida por el Consejo Superior de Administración Electrónica, en su última versión disponible. Para las aplicaciones basadas en.net: Niveles de Arquitectura. Nivel de Presentación: interfaz ligero HTML para ser consumido desde un explorador web Página: 18

19 Nivel de Servidor de aplicaciones y reglas de negocio: se trata del servidor que ofrece las páginas web y la lógica de negocio de la aplicación. Nivel de Persistencia de datos: sistema gestor de base de datos relacional que ofrece la persistencia de datos. Diseño y construcción Uso de estándares de diseño y codificación definidos en el Ministerio. Sencillez para el usuario. Rendimiento. Reducción de complejidad de tramitación. Firma validación. Presentación flexible y personalización dinámica. Internacionalización y multilenguaje. Gestión de contenidos. Arquitectura orientada a servicios. Definición y gestión de workflows de aprobación y publicación del contenido. Seguridad Página: 19

20 Seguridad de conexión realizada de manera cifrada a través de SSL con certificados de servidor. Autenticación y autorización utilizando certificados de cliente emitidos por una entidad emisora de certificados válida (FNMT o DNI electrónico). Estos certificados serán además validados por un sistema de validación del estado de revocación. Los documentos generados a través de la aplicación se firman utilizando el certificado de cliente en formato Xades garantizando así la identidad, integridad y no repudio del documento. En cuanto al acceso a base de datos se utilizan diferentes grupos de usuario/password para los diferentes esquemas de datos a los que se acceden, evitando así el acceso no autorizado a los datos desde fuera de la aplicación. Arquitectura de software Cliente: Microsoft Internet Explorer 6 o superior Servidor de aplicaciones: Microsoft Internet Information Server 6 (Windows Server 2003) Sistema de información: C#.NET con Framework 2.0, HTML, JavaScript. Base de datos: Oracle 10g y SQL Server 2005 Adicionalmente se utilizan en el servidor de aplicaciones los siguientes productos de terceros: Página: 20

21 Asppdf, Abcpdf y Tallpdf, para la generación de documentos PDF en servidor TextControl, para la generación de documentos ofimáticos editables Infragistics, para la generación de gráficos Para las aplicaciones basadas en la plataforma Vignette Arquitectura del entorno Vignette Intranet Portal: se encuentra dentro de la red local, y se compone de buscador, motor de búsqueda e indexación. Página: 21

22 Servidor de colaboración: servidor dedicado a los entornos colaborativos y participación ciudadana. Gestor de contenidos: servidor que gestiona los contenidos de la capa de presentación. Pre-visualización: vista en real de los contenidos gestionados previa a la publicación en la capa de presentación. La capa de back-office corporativo representa los sistemas base del MICINN con los que interactúa la Intranet. BBDD: gestor de base de datos Correo: servidor de correo electrónico corporativo. LDAP: repositorio de usuarios que se utilizara para validar el acceso a las zonas restringidas del portal. Arquitectura del entorno Vignette Internet La capa de portal contiene los servidores web y los portales. La capa de gestión de portal se encuentra dentro de la red local, y se compone de: buscador, motor de búsqueda e indexación. Página: 22

23 Servidor de colaboración: servidor dedicado a los entornos colaborativos y participación ciudadana. Gestor de contenidos: servidor que gestiona los contenidos de la capa de presentación. Pre-visualización: vista en real de los contenidos gestionados previa a la publicación en la capa de presentación. La capa de back-office corporativo representa los sistemas base del MICINN con los que interactúa la plataforma web. BBDD: gestor de base de datos Correo: servidor de correo electrónico corporativo. LDAP: repositorio de usuarios que se utilizara para validar el acceso a las zonas restringidas del portal. Disco compartido: unidad NAS de almacenamiento. Página: 23

24 Para las aplicaciones basadas en Oracle Application Server: Las aplicaciones en esta tecnología se desarrollarán en Oracle Developer 10G (Database, Forms, Reports y Discoverer) que permite realizar la creación de módulos de formularios, bloques de datos, marcos e informes destinados al entorno intranet que se despliegan en el servidor Oracle Application Server (OAS). Este servidor de las aplicaciones intranet es un servidor disponible en máquinas con sistema operativo Windows. El Gestor de Bases de Datos es Oracle, en él se definen los esquemas para las distintas aplicaciones. OC4J (Oracle Containers for J2EE) es el núcleo del entorno de ejecución de OAS. En la herramienta Forms se emplearán bibliotecas de objetos comunes para unificar el diseño de los elementos del interfaz (cabecera, botonera, campos, etiquetas, alertas, etc.) y librerías comunes que contendrán funciones que se emplearán de manera genérica y que no serán funciones de base de datos. Arquitectura de software El sistema de información utilizando OAS se diseña siguiendo una arquitectura web en tres capas, tal y como se ilustra en el siguiente diagrama: Página: 24

25 Cliente: Oracle Developer Forms Runtime 10 y Jinitiator 1.3 Servidor de Aplicaciones: Oracle Internet Application Server 10 Sistema de información: Oracle Developer 10g (formularios) y Oracle Reports 10g (informes) Base de datos: Oracle 10g Herramientas generales de explotación Se utiliza Oracle Discoverer 10, que permite al usuario final la generación de consultas y listados personalizados. A diferencia de la implementación de listados predefinidos, el uso de esta herramienta permite al usuario seleccionar dinámicamente la información a mostrar, con la posibilidad de incluir condiciones, agrupaciones, cálculos. Para poder ser utilizada por el usuario se precisa realizar previamente un trabajo de configuración, centrado básicamente en la creación de la EUL con los datos del sistema de información en cuestión. Esa capacidad de meta datos oculta la complejidad de la base de datos y permite a los usuarios utilizar conceptos de su negocio con los que está más familiarizado. Página: 25

26 Para las aplicaciones basadas en JEE: La SGTIC ha definido el Framework Fénix para contar con un marco tecnológico de componentes reutilizables. Para constituir Fénix se utilizan herramientas de código abierto y de probado éxito en el mercado. A continuación se especifican las herramientas utilizadas en cada una de las capas del modelo: Presentación: se emplea JSTL, Struts Validator, Struts Tiles y Struts Tags. Este conjunto permite definir plantillas de presentación independientes de aplicación, así como reglas de validación de formularios que pueden ejecutarse tanto en cliente como en servidor. Además soporta multi-idioma. Control: Struts y Core Container de Spring. Todas las peticiones pasan por el mismo controlador (Patrón FrontController - ActionServlet). Spring permite trabajar con un contenedor de objetos para resolver declarativamente las dependencias entre clases (Inyección de dependencias). La capa de control maneja interfaces de clase para las llamadas a la capa de negocio, con lo que se encapsula la complejidad de la implementación del negocio. Negocio: Core Container de Spring. Los objetos de negocio son creados como proxies. Esta capa no tiene conocimiento de como está implementada la capa de persistencia, ya que trabaja con interfaces que abstraen los detalles. La lógica de negocio no depende del origen de datos ni de cómo se accede. Persistencia: ibatis y Spring. IBatis permite independencia respecto al proveedor de datos, elimina la programación de elementos (conexiones, etc.) y separa las sentencias y datos de la programación, empleando en la definición ficheros XML. IBatis se utiliza dentro del contenedor de Spring. Página: 26

27 Dentro de esta arquitectura se encuentran numerosos componentes reutilizables como, por ejemplo, la autenticación de usuarios, firma electrónica, web services, gestión de errores, menús, listas, validaciones, informes, etc. Figura 1. Arquitectura Fénix Implantación de las aplicaciones La implantación se realizará de acuerdo a los procedimientos establecidos por la SGTIC para el despliegue y control de cambios y versiones Formación Como parte del servicio, se formará a los usuarios y al personal técnico propio del MICINN acerca de los nuevos sistemas implantados y/o grandes evoluciones de los mismos. La formación deberá impartirse en las dependencias que indique el Ministerio y regirse bajo el procedimiento de gestión de formación interno que indique la SGTIC. Página: 27

28 3.2.5 Documentación Como parte de las tareas objeto del contrato, el adjudicatario se compromete a generar la documentación de los trabajos realizados de acuerdo con los criterios establecidos para el desarrollo de proyectos en el ámbito de tareas del Lote, conforme a la aplicación de la metodología Métrica V3. La entrega de la documentación definitiva se realizará, a la finalización del trabajo, en un formato estándar (Word, HTML, PDF) y no se considerará finalizado sin la entrega de la documentación correspondiente. Dicha documentación será requerimiento obligatorio para la recepción y abono de los trabajos desarrollados. Además, si la Dirección del Servicio lo estima pertinente, el adjudicatario se compromete a realizar entrega de resultados parciales de los trabajos realizados. De forma específica, para todas las tareas desarrolladas en el marco del variable no garantizado, se entregará documentación de todas las fases del desarrollo incluyendo, como mínimo, la correspondiente a las actividades de: 1. Plan de Proyecto (incluyendo planificación de tareas). 2. Análisis Funcional. 3. Diseño Técnico. 4. Plan de Pruebas. 5. Plan de Implantación. 6. Informe Final de Proyecto. Página: 28

29 3.3 Modelo de servicio general Características generales de la Línea base Soporte a usuarios, mantenimiento correctivo. Esta tipología de tareas contempla actividades propias de la operativa sobre incidencias y cargas de información entre aplicativos, así como las tareas propias de la gestión de un servicio de esta naturaleza En cuanto a las tareas propias de la gestión del servicio, el suministrador se responsabilizará de la gestión del contrato, de la gestión del servicio, del seguimiento y reporte a los distintos comités, de las actividades relacionadas con el aseguramiento de la calidad y la mejora continua del servicio, redacción de actas de reunión, gestión de la organización estructural y de trabajo de sus equipos, gestión de los acuerdos de nivel de servicio (en adelante, ANS) y aseguramiento de un adecuado mantenimiento de la documentación y gestión del conocimiento (incluyendo actividades de transferencia del mismo a la SGTIC). En cuanto a la parte operativa, el suministrador se responsabilizará de la gestión y realización de las actividades necesarias para la corrección de las incidencias surgidas en las aplicaciones software incluidas en el lote correspondiente, la resolución de problemas e incidencias debidas a fallos en las mismas, el soporte a consultas como medio de atención a usuarios y la resolución de peticiones. Las actividades que se incluyen para la realización del mantenimiento correctivo abarcan desde la recepción y registro de los errores e incidencias, su análisis, diagnóstico y propuesta de solución (que deberá ser aprobada por la SGTIC), hasta el seguimiento y resolución de los mismos. También se incluyen como responsabilidad del Suministrador los desarrollos necesarios para corregir los datos erróneos por el mal funcionamiento de la aplicación. La actividad de la línea base correctiva estará directamente ligada con la resolución de los problemas detectados durante la explotación de las Página: 29

30 aplicaciones, lo que implicará actualizaciones al código y actividades para la recuperación de estados estables, y que deberán ser sincronizadas con las actividades de desarrollo de cambios y nuevas versiones que se lleven a cabo sobre las mismas. El Suministrador será responsable de la gestión de la incidencia, con el fin de garantizar un menor impacto en el servicio al Ministerio. En el caso de considerarse necesario por parte de la SGTIC, ésta solicitará el establecer una fase de aceptación de la solución técnica propuesta por el Suministrador. Cualquier actuación sobre el software motivada por un fallo o error de la aplicación será considerada siempre como actividad correctiva y en ningún caso actividad de tipo evolutivo Adaptaciones y Mejoras. Este servicio contempla las actividades relacionadas con la gestión y la mejora de un producto software en producción que no impliquen grandes transformaciones, técnicas y funcionales, en los aplicativos, incluyendo también las posibles actuaciones de mantenimiento adaptativo, perfectivo y preventivo, si las hubiera. En concreto incluye: Las incorporaciones de nuevas funcionalidades, sencillas y de pequeño tamaño, requeridas por el usuario, para la mejora de las prestaciones de los sistemas y aplicaciones. La modificación de una aplicación debido a cambios en el entorno (hardware o software) en el cual se ejecuta. Estos cambios pueden afectar al sistema operativo, a la arquitectura física del sistema informático o al entorno de desarrollo software. La modificación del software para mejorar sus propiedades, sin alterar las especificaciones funcionales, con el fin de prevenir la aparición de futuros errores. El cambio de entorno o baja de aplicaciones en producción. Página: 30

31 La parametrización de aplicaciones. Las tareas del Suministrador en cuanto al mantenimiento adaptativo, perfectivo y preventivo se centrarán, además de las habituales de programación, y según sea necesario, el diseño técnico, realización de pruebas y parte de las actividades de pruebas de integración. La decisión de si una petición es tratada dentro de esta tipología de servicio es tomada únicamente por la SGTIC, y en ningún caso por el Suministrador. Toda petición vinculada a la línea base quedará registrada en la herramienta de soporte proporcionada por la SGTIC, de acuerdo a lo articulado en el procedimiento de gestión de peticiones. Para el caso de la línea de actividad de mantenimiento correctivo, el suministrador deberá actualizar la documentación asociada a las aplicaciones involucradas en un plazo no superior a 48 horas después de su resolución. La actividad de mantenimiento de aplicaciones está asociada a la puesta en explotación, por lo que deberá seguir el calendario de implantaciones definido por la SGTIC. Los trabajos correspondientes a la línea base podrán realizarse tanto en las instalaciones de la SGTIC como en las instalaciones del suministrador. El equipo asignado a estas tareas estará formado por los perfiles indicados en el capítulo anterior, de acuerdo con el volumen propuesto. Se supondrá que el equipo cuenta con capacidad de análisis y diseño y con la experiencia y conocimiento técnico y funcional necesario para el correcto desempeño de su trabajo. Además, este equipo debe asumir las tareas de gestión, organización y seguimiento del servicio Características generales del Variable no garantizado En este servicio se incluyen aquellas actividades relacionadas con el desarrollo eventual de nuevas funcionalidades y peticiones planificables no incluidas en la línea base evolutiva, por su tamaño o complejidad. Página: 31

32 La decisión de si una petición es tratada dentro de esta tipología de servicio es tomada únicamente por la SGTIC, y en ningún caso por el Suministrador. Las tareas correspondientes al Suministrador para el variable no garantizado, serán las propias de un proyecto de desarrollo, desde el estudio de viabilidad del nuevo sistema hasta las pruebas de integración, pasando por todas las fases y actividades propias de un proyecto de desarrollo de software. Además el suministrador se encargará de la gestión del proyecto en cuanto a planificación temporal, de tareas y recursos, así como del seguimiento de los mismos. Toda petición de esta línea de servicio quedará registrada en la herramienta correspondiente de soporte proporcionada por la SGTIC, de acuerdo con el procedimiento de gestión de peticiones. La actividad de esta línea de servicio estará asociada al desarrollo y puesta en explotación, por lo que deberá seguir el calendario de implantaciones definido por la SGTIC. En lo referente a la ubicación del personal del suministrador asignado para la realización de estas tareas, podrá estar ubicado bien en las instalaciones que de la SGTIC o en las instalaciones del suministrador (incluyendo las factorías de software) Fases del servicio La SGTIC propone las siguientes fases para cada aplicación o agrupación de aplicaciones que se arranque dentro del servicio: Fase de transición: Proceso de traspaso del conocimiento entre el suministrador entrante y el saliente, estimada en un mes de duración. Fase de estabilización: Transferencia de responsabilidad al suministrador entrante, arranque y análisis del servicio. Asunción total del servicio por parte del suministrador. Durante esta etapa el nuevo suministrador será el responsable de las diferentes solicitudes. Página: 32

33 Si la SGTIC lo considera oportuno, para uno o varios lotes, se realizará en esta etapa la medición de todos los indicadores y parámetros del servicio que se consideren necesarios por ambas partes, de cara a la definición de unos ANS que regulen la actividad a prestar en el ámbito de cada lote. El modelo de medición y establecimiento de ANS y la correspondiente transformación del servicio gestionado en base a acuerdos de nivel de servicio entre el suministrador y la SGTIC, se presentan en el epígrafe 3.7. El fin de esta fase se sitúa, para los lotes 1, 2 y 3, al concluir el primer año de prestación del servicio, de forma orientativa. Si el Suministrador y la SGTIC no llegaran a un acuerdo de niveles de servicio, tras finalizar la fase de estabilización, sería considerado como causa para la rescisión unilateral del contrato por parte de la SGTIC. Para los lotes 4 y 5 no se determina una fecha previa de fin de la fase de estabilización del servicio, y se determinará durante la ejecución del contrato. Fase de servicio gestionado en base a acuerdos de nivel de servicio: Puesta en marcha de un modelo básico de gestión basado en acuerdos niveles de servicio (ANS) hasta la finalización del contrato. Fase de devolución: Traspaso del conocimiento a la SGTIC o al suministrador o suministradores que la SGTIC indique. El suministrador del servicio, atendiendo a su experiencia y/o metodología, podrá proponer cambios en el modelo siempre que suponga mejorar la calidad del servicio. A continuación se muestra un esquema con las fases indicadas: Página: 33

34 Servicio gestionado en base a ANS Figura 2. Fases del Modelo de Servicio La transferencia de aplicaciones entre suministradores será responsabilidad del suministrador entrante, aunque se espera la máxima colaboración por parte del suministrador saliente durante todo el proceso. Para garantizar dicha colaboración, la SGTIC supervisará los procesos de transferencia. La SGTIC podrá modificar diferentes aspectos del proceso de transición para incluir mejores prácticas identificadas durante las experiencias en la transferencia u otras actividades no incluidas en el presente documento. La duración límite de cada una de las fases, cuyo valor orientativo se cita en la descripción general de cada una de ellas, será fijada por la SGTIC: El suministrador entrante se comprometerá a cumplir con las fechas de finalización de cada una de las fases. Las fechas tentativas de los diferentes hitos para cada aplicación o agrupación de estas serán comunicadas a los suministradores seleccionados durante cada una de las fases de planificación. Debido a que las aplicaciones se arrancarán de modo paulatino, en diferentes planificaciones, el suministrador debe contemplar la posibilidad de solapamiento entre las fases de las diferentes aplicaciones. La Página: 34

35 duración real de cada uno de las diferentes aplicaciones es variable y dependiente de la duración del contrato. A lo largo de toda la vida del servicio, la SGTIC podrá incorporar o retirar aplicaciones al servicio y establecerá un plan de incorporación / retirada para cada caso con el suministrador. Una vez incorporadas / retiradas, regirán las mismas condiciones que para el resto de aplicaciones Fase de transición El objetivo de esta fase es el traspaso de los elementos básicos e imprescindibles para la prestación del servicio, entre el suministrador saliente y el entrante. Se deberá asegurar que existen las condiciones adecuadas para el éxito de la transferencia del servicio, así como introducir las modificaciones que se consideren convenientes. Al inicio de la fase de transición, el suministrador entrante deberá realizar las siguientes tareas: Negociación con el suministrador saliente del proceso de transferencia del conocimiento y de la formación que haya considerado necesaria. Presentación de un plan detallado de calidad, que deberá ser aprobado por la SGTIC. Presentación de un plan para, si se considera importante, completar los recursos humanos ofrecidos en su oferta con otros perfiles de mayor conocimiento específico. Cualquier otro condicionante necesario para la ejecución del proceso de transferencia del conocimiento y del plan de activación del servicio. De manera adicional, el suministrador entrante pondrá en conocimiento de la SGTIC la organización con la que proporcionará el servicio, así como la asignación de recursos y confirmación de roles, tareas y responsabilidades, necesarios para la gestión del servicio. Al inicio de la fase de transición, y con el objeto de garantizar la transferencia de conocimiento y responsabilidad por el nuevo suministrador, la SGTIC revisará el Página: 35

36 backlog de peticiones sobre las aplicaciones incluidas en el servicio con las siguientes prioridades: Reducir, si es viable, la carga de trabajo y la evolución de las aplicaciones durante el periodo de transferencia del servicio. Reducir, en la medida de lo posible, solicitudes de nuevas peticiones que se considere que vayan a finalizar tras la transferencia de responsabilidad. Dentro de la fase de transición y como parte de la transferencia de conocimiento, el suministrador entrante del servicio deberá adquirir / definir y mantener posteriormente la siguiente información: Mapa de aplicaciones dentro del ámbito. Documentación funcional de las aplicaciones en el ámbito. Documentación técnica (modelo de datos, arquitectura, módulos técnicos, seguridad). Metodología y estándares en uso en la SGTIC relativos al mantenimiento y desarrollo de aplicaciones. Procedimientos de trabajo y modelos de relación del servicio. Políticas y planes. Lecciones aprendidas como la resolución de problemas en aplicaciones. Bases de conocimiento para el soporte de primer nivel con preguntas frecuentes y resolución de problemas comunes. Documentación generada durante la transición y la prestación del servicio. Estructura organizativa del servicio. Lista de responsables funcionales y expertos de la SGTIC y del suministrador. Página: 36

37 Ficheros con el código fuente de la aplicación o agrupación de aplicaciones que se engloban dentro del arranque. La fase de transición del servicio finaliza con el hito de transferencia de la responsabilidad de las aplicaciones contenidas dentro de su dominio del suministrador saliente al entrante, fecha que estará definida por la SGTIC. Esta fase se ejecutará de acuerdo al plan detallado de actividades del proceso de trasferencia de conocimiento y al plan de activación del servicio, ambos realizados por el suministrador entrante en la fase de transición y aprobado por la SGTIC. El suministrador entrante tiene obligación de documentar todas las actividades del proceso de transición y entregar esa documentación a la SGTIC cuando termine el proceso de transición, así como conseguir la aprobación de la auditoría de calidad de inicio del servicio. Esta fase tendrá una duración estimada de 1 mes desde el inicio del servicio. Finalizada esta fase se iniciará la fase de estabilización. En casos excepcionales (p. ej. limitaciones temporales en la implantación de infraestructura y/o otros temas logísticos) se podrá prolongar la duración de la presente fase. En tal caso, se solapará con la siguiente fase, aunque siempre deberá finalizar antes de la transferencia de responsabilidad. El suministrador entrante deberá agilizar en tal caso la realización de todas las tareas asociadas para asegurar la consecución en tiempo de los hitos planificados Hito de toma de control Una vez finalizada la fase de transición del servicio se procederá a la transferencia de la responsabilidad, que marcará el inicio de la fase de estabilización. La SGTIC realizará una comprobación formal de la capacitación del suministrador entrante para asumir el servicio: - Revisando y certificando el cumplimiento satisfactorio de cada una de las actividades indicadas en el anterior punto ( Fase de transición). Página: 37