Contratación del Servicio de Mantenimiento y Evolución
Contratación del Servicio de Mantenimiento y Evolución
de las Aplicaciones de Gestión de Osakidetza
Índice
1 INTRODUCCIÓN _ 4
2 OBJETO DEL CONTRATO _ 6
2.1 Línea de Mantenimiento y Evolución _ _ 6
2.1.1 Mantenimiento Correctivo/Preventivo/Perfectivo 6
2.1.2 Mantenimiento Adaptativo/Evolutivo a pequeña escala 7
2.2 Línea de Desarrollo (Evolutivo a gran escala) _ 8
2.3 Gestión del Inventario, Repositorios y Documentación _ 8
2.4 Calidad del Software _ _ 9
2.5 Gestión y Administración del servicio_ _ 9
3 DEFINICIÓN DEL SERVICIO _ 11
3.1 Fases del servicio_ 11
3.1.1 Fase de transición 11
3.1.2 Fase de prestación regular 12
3.1.3 Fase de devolución 12
3.2 Descripción detallada de los servicios de mantenimiento _ 13
3.2.1 Línea de Mantenimiento y Evolución 14
3.2.2 Línea de Desarrollo (Evolutivo a gran escala) 16
3.3 Horario de la prestación del servicio 17
3.4 Ubicación de la prestación del servicio 17
4 CONFIGURACIÓN DEL SERVICIO_ 19
4.1 Modelo de Gestión del Servicio _ 19
4.2 Modelo de Relación 19
4.3 Equipo de Trabajo 19
4.3.1 Constitución inicial del Equipo de Trabajo 21
4.3.2 Modificaciones en la composición del Equipo de Trabajo 21
4.3.3 Veracidad de los datos 22
4.3.4 Condicionantes del equipo de trabajo ofertado 22
4.3.5 Currículo de los componentes del Equipo de Trabajo. 22
4.4 Asignación de recursos a fases del proyecto 22
5 ESPECIFICACIONES TÉCNICAS 24
5.1 Infraestructura 24
5.2 Estándares 24
6 CONTROL Y SEGUIMIENTO 25
7 INDICADORES DE NIVEL DE SERVICIO (ANS) 26
7.1 Indicadores de Servicio 26
7.1.1 Mantenimiento Correctivo 27
7.1.2 Mantenimiento Adaptativo/Evolutivo a pequeña escala 28
7.1.3 Desarrollo: Evolutivo a gran escala 28
7.2 Indicadores de Calidad 28
7.2.1 Tipología de Incidencias 28
7.2.2 Peticiones reabiertas 29
7.2.3 Reducción del mantenimiento correctivo 29
7.2.4 Errores del Proveedor 29
Página
7.2.5 Desviación Estimación evolutivos 29
7.3 Indicadores de Productividad 30
7.3.1 ESFUERZO (I): Línea de Mantenimiento y Evolución 30
7.3.2 ESFUERZO (II): Línea de Desarrollo 30
8 CONTENIDO DE LAS OFERTAS 31
9 PROPIEDAD DE LOS PRODUCTOS ENTREGADOS 33
10 CONFIDENCIALIDAD 34
11 PRESUPUESTO, PLAZOS Y PENALIZACIONES 35
11.1 Presupuesto _ 35
11.2 Facturación _ 35
11.2.1 Facturación Base 35
11.2.2 Facturación Línea de Desarrollo 35
11.3 Plazo de ejecución 36
11.4 Penalizaciones 36
11.4.1 Mantenimiento Correctivo 36
11.4.2 Mantenimiento Adaptativo y Evolutivo 36
12 CRITERIOS DE ADJUDICACIÓN 37
13 CONSULTAS AL PLIEGO _ 40
14 ANEXO I. RELACIÓN DE APLICACIONES 41
14.1 Aplicaciones SAP 41
14.2 Aplicaciones NO SAP _ 44
15 ANEXO II. DIRECTRICES Y ESPECIFICACIONES TÉCNICAS (DET) _ 46
15.1 Especificaciones para Desarrollo 46
15.2 Arquitectura de Referencia 46
15.2.1 Vista lógica 47
15.3 Directrices de Desarrollo 48
15.3.1 Construcción de Aplicaciones por Capas 48
15.3.2 Capa de Presentación 48
15.3.3 Capa de Negocio 49
15.3.4 Capa de Persistencia 51
15.4 Directrices tecnológicas de IOC_ 52
15.4.1 Entorno tecnológico 53
15.4.2 Dispositivos de entrada/salida 54
15.4.3 Seguridad, acceso, autenticación y autorización 55
15.4.4 Monitorización 57
15.4.5 Backup/Restore 57
15.5 Interoperabilidad 58
15.5.1 Servicios Web 59
15.5.2 Gestor de Eventos 60
15.6 Explotación Información - Business Intelligence 62
15.7 Sistemas SAP 62
15.8 Alineamiento con las Directrices Tecnológicas _ 63
16 ANEXO III. ESPECIFICACIONES DEL CLIENTE (MAQUETA) 64
17 ANEXO IV. CUESTIONARIO DE PERSONAL _ 65
1 INTRODUCCIÓN
Osakidetza dispone de una base instalada de aplicaciones, integrada tanto por desarrollos a medida como por productos xx xxxxxxx, sobre las cuales da soporte a su actividad. El mantenimiento y evolución de estas aplicaciones y sistemas de información es imprescindible para asegurar la continuidad de las funciones que proveen.
Actualmente, la creciente demanda en materia de sistemas de información hace necesario replantearse los modelos de gestión y de atención a ciudadanos y profesionales, avanzando hacia nuevos canales de comunicación, definiendo procesos integrados entre los distintos niveles de atención sanitaria, y suministrando plataformas y herramientas para dar soporte a las decisiones en el ámbito de la gestión Económico-Financiera y de Recursos Humanos.
Por lo tanto, es necesario contemplar en este nuevo contexto la reingeniería de procesos como una tarea vital, en el que las TIC serán un elemento determinante que hará posible la implementación de nuevos modelos de gestión, haciendo un uso mucho más eficiente de los recursos. Esto supondrá, en un plazo razonable, una disminución del coste del servicio, que repercutirá en un retorno de la inversión que se realice en este ámbito.
Con esta perspectiva, Xxxxxxxxxx está apostando por la innovación tecnológica como la palanca para optimizar procesos, de forma que en la actualidad, cualquier iniciativa que se vaya a poner en marcha no se concibe sin el uso de una aplicación informática ya implantada, contemplando su adecuación a las nuevas necesidades, o bien si fuese el caso, planificando su sustitución por nuevas soluciones, de forma progresiva y no disruptiva, o bien acometiendo el desarrollo de un nuevo sistema de información.
Así pues, y con el fin de satisfacer las necesidades descritas, la Subdirección de Informática y Sistemas de Información de Osakidetza, en el marco de sus competencias, se plantea la contratación de los servicios de mantenimiento integral y evolución de sus aplicativos de gestión, que concentran la mayor parte de los sistemas de información que gestiona en este área.
Los principales objetivos que se persiguen con la contratación de estos servicios pueden resumirse en los siguientes puntos:
• Asegurar el mantenimiento y evolución coherente de las aplicaciones que dan servicio al ámbito de la gestión tanto Económico-Financiera como de Recursos Humanos de Osakidetza.
• Implantar un modelo de servicio de producción y mantenimiento integral de aplicaciones gestionado, alineado con las necesidades actuales de la Consejería de Salud del Gobierno Xxxxx.
• Mejorar la productividad y la eficiencia en la función TIC.
• Optimizar los costes asociados a la función de mantenimiento de aplicaciones.
• Disponer de flexibilidad ante necesidades no previstas.
• Disponer de una visión global del software de gestión que, al mismo tiempo, facilite el funcionamiento integrado y coherente de los sistemas de información y asegure su normalización y estandarización.
Osakidetza mantendrá las funciones de control, dirección y de relación con el negocio, garantizando el compromiso de los niveles de servicio.
Con el fin de garantizar los objetivos descritos, los licitadores deberán aportar en la Documentación Jurídica “Sobre A”, documento que acredite estar actualmente en posesión de certificación vigente como Partner de Servicios de SAP para el ámbito de España, en todas y cada una de las siguientes categorías y soluciones SAP:
1. Soluciones Horizontales:
Certificación de partner de servicios en todas y cada una de las siguientes soluciones:
a. Financial Management (Excelencia en la Gestión Financiera):
SAP ERP Financial (Escenario básico)
b. Human Capital Management (Gestión xxx xxxxxxx y las Personas): Administración de Personal y Gestión de Recursos Humanos (Escenario básico).
c. Human Capital Management (Gestión xxx xxxxxxx y las Personas): Portal para la Gestión de Recursos Humanos.
d. Supply Chain Management (Cadena de Suministro): Supply Chain Management (Escenario básico).
2. Soluciones Sectoriales:
Certificación de partner de servicios en la solución:
a. Public Sector: Recursos Humanos.
2 OBJETO DEL CONTRATO
El objeto del contrato consiste en el mantenimiento, evolución e integración del catálogo de aplicaciones que se detalla en el ANEXO I, así como los desarrollos que sea necesario acometer durante la vigencia del contrato.
El contrato tendrá un plazo de ejecución de dos años, prorrogable por otros dos, de acuerdo con la legislación vigente.
Para la ejecución del contrato se tendrán en consideración los siguientes aspectos:
• El conjunto de aplicaciones que se relacionan en el ANEXO I formarán la línea base sobre el que los adjudicatarios realizarán sus trabajos.
• Esta línea base podrá ser modificada durante la vigencia del contrato, con la incorporación y retirada de aplicaciones, dentro de lo señalado en el presente Xxxxxx.
• Los adjudicatarios deberán garantizar los servicios que se detallan en el pliego de prescripciones técnicas, con la calidad y condiciones de nivel de servicio que se definen.
• El 50% del precio ofertado se dedicará a los servicios de mantenimiento evolutivo de gran tamaño y nuevos desarrollos con las condiciones que más adelante se explican.
Los servicios a prestar se encuadran en tres tipos de líneas de trabajo:
2.1 Línea de Mantenimiento y Evolución
Comprende servicios que requieren actuaciones de dimensión predecible en su mayor parte. En consecuencia se proveen con una plantilla predefinida con una Dimensión Base, si bien podrá exigirse al proveedor modificaciones según los criterios y procedimientos contemplados en este Pliego.
Los servicios que contempla esta línea de trabajo son los siguientes:
2.1.1 Mantenimiento Correctivo/Preventivo/Perfectivo
Este servicio contempla actividades propias de la operativa sobre incidencias así como las tareas propias de la gestión de un servicio de esta naturaleza.
En el aspecto operativo, el adjudicatario 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 este expediente, así como la resolución de problemas e incidencias debidas a fallos en las mismas.
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 Osakidetza), hasta el seguimiento y resolución de los mismos.
La puesta en producción de todo mantenimiento correctivo deberá ir acompañada de
la correspondiente documentación en la que se indiquen claramente los errores que corrige, así como la relación de incidencias registradas que soluciona.
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.
La resolución de un error en producción puede motivar el despliegue de equipos de desarrollo para edición de parche y actuaciones presenciales.
Toda petición de mantenimiento correctivo, así como las actividades asociadas a la petición, quedarán registradas en la herramienta de gestión de incidencias y peticiones de Osakidetza y deberá venir acompañada de la documentación asociada correspondiente, indicando al menos la definición del problema y su solución, junto con el resultado de las pruebas realizadas.
Dentro del mantenimiento preventivo se incorporan todas las intervenciones periódicas con el fin de detectar posibles fallos ocultos antes que éstos aparezcan. lncluye comprobación de consistencia de los datos, pruebas forzadas del software o hardware, errores en la configuración del hardware o software, incluyendo el gestor de base de datos, etc.
El mantenimiento perfectivo comprende mejoras en la operativa actual del software que no impiden el correcto funcionamiento de la actividad diaria y sí supone una mejora en el rendimiento y uso de los recursos.
2.1.2 Mantenimiento Adaptativo/Evolutivo a pequeña escala
Se describen los 2 tipos de mantenimiento:
• Mantenimiento Adaptativo
Son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, software de base, gestores de base de datos, comunicaciones, etc. Incluye, entre otros:
o Cambios en el entorno de los datos o su procesamiento
o Cambios en la plataforma o arquitectura tecnológica
o Modificación de procedimientos existentes que no implican nuevas funcionalidades
o Exportaciones e importaciones de datos dedicados a la integración con otras aplicaciones del entorno, para mantenimiento de integridad de la información
o Integración con otros aplicativos a nivel de plataforma tecnológica
o La parametrización de aplicaciones
Este tipo de mantenimiento se regirá por los mismos criterios descritos en el mantenimiento evolutivo.
• Mantenimiento Evolutivo
Son las incorporaciones, modificaciones y eliminaciones necesarias para cubrir la evolución o cambio de las necesidades del usuario, es decir, la incorporación de nuevas funcionalidades a la cobertura actual del software. Incluye, entre otros:
o Cambios en los requisitos de la aplicación
o Modificaciones derivadas de cambios en la normativa
o Modificaciones de alcance limitado que supongan mejoras del aplicativo
y por tanto incorporables a la versión base
En base al esfuerzo requerido para su resolución, esta tipología de actividad se ha dividido en dos niveles:
o Mantenimiento Evolutivo a pequeña escala
Son actividades relacionadas con el desarrollo evolutivo, cuyo tamaño y complejidad no son excesivos. Se estima un esfuerzo menor a 100 horas-persona.
Se incluye en la línea de trabajo, “Línea de Mantenimiento y Evolución” (punto 2.1).
o Mantenimiento Evolutivo a gran escala
Corresponderán a actuaciones de tamaño y complejidad más significativas, en concreto, aquellas cuyo esfuerzo sobrepase el límite establecido para el mantenimiento evolutivo a pequeña escala.
Se incluye en la “Línea de Desarrollo” (punto 2.2).
En el desarrollo de esta línea de trabajo se solicitará al proveedor que colabore con el Grupo de responsables Funcionales de Osakidetza, para la elaboración del análisis Funcional.
2.2 Línea de Desarrollo (Evolutivo a gran escala)
Comprende las actuaciones necesarias para abordar el mantenimiento evolutivo de gran tamaño y los nuevos desarrollos derivados de la reingeniería o el desacoplamiento de funciones de las aplicaciones objeto del contrato. Depende de las necesidades de Osakidetza durante la vigencia del contrato y requerirán recursos variables a lo largo del contrato que se adecuarán a las necesidades de cada momento.
En el desarrollo de esta línea de trabajo el proveedor deberá nombrar un jefe de proyecto, como responsable único de cada demanda ante Osakidetza, estableciendo los plazos, hitos y entregables del proyecto.
En consecuencia con lo dicho, la facturación será variable y la cuantía aplicable cada mes se determinará en función del trabajo realizado y los objetivos alcanzados.
2.3 Gestión del Inventario, Repositorios y Documentación
Dada la naturaleza y características del servicio objeto del contrato se hace imprescindible contar con un inventario detallado de las aplicaciones que conforman su alcance. Por tanto, deberá recoger toda aquella información que se considere necesaria y suficiente para la gestión adecuada del servicio.
El inventario deberá estar accesible desde las instalaciones de Osakidetza.
Será responsabilidad del adjudicatario mantener actualizado en todo momento el inventario de aplicaciones, y por ende, sus correspondientes fichas descriptivas.
Además del inventario, y específicamente en las aplicaciones NO SAP, es
imprescindible disponer de todos los artefactos de cada aplicación, necesarios para la realización de las actividades de mantenimiento encomendadas al adjudicatario, entre otros, el código fuente, los contenidos estáticos, los scripts de creación de base de datos, los ficheros de configuración, etc.
Se subraya también la necesidad de generar la documentación y elementos adicionales fijados por el Servicio de Implantación de Osakidetza para cada aplicación.
El incumplimiento sobre la obligación del mantenimiento y actualización del inventario, del repositorio y de la documentación generará la no aceptación del trabajo.
2.4 Calidad del Software
El aseguramiento del cumplimiento de la calidad de los productos se considera fundamental para garantizar la correcta prestación de los servicios, es por ello que de forma específica, se implementará como línea de trabajo, la gestión de calidad del software.
Osakidetza está actualmente poniendo en marcha la Oficina de Calidad del Software corporativa, cuyo objetivo es la creación de un modelo de referencia que marcará la estrategia a seguir para verificar, validar y asegurar que el software de aplicación, cumple los requerimientos especificados y las necesidades y expectativas del usuario. La normativa y procedimientos de pruebas que determine esta Oficina de Calidad serán de obligado cumplimiento para el adjudicatario de este expediente.
2.5 Gestión y Administració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, gestión de la organización estructural y de trabajo de sus equipos y de generar la documentación necesaria.
Se contemplan principalmente los siguientes tipos de funciones:
• Priorización, coordinación, supervisión y seguimiento general de los servicios incluidos en el contrato.
• Coordinación con unidades funcionales de Osakidetza
• Coordinación y supervisión de integraciones y estándares.
• Documentación, información y gestión del conocimiento.
Se incluyen en esta línea de trabajo las actividades relativas a la gestión y seguimiento del propio servicio, cuyos indicadores e informes deben ser reportados al comité de seguimiento para su aprobación y control.
Se deberán cumplimentar mínimamente los informes detallados en el apartado de “Control y seguimiento” del presente pliego de bases técnicas, valorándose tanto la incorporación de nuevos indicadores como informes adicionales que proponga el licitador y que contribuyan a la mejora en la gestión del servicio.
Complementariamente, las herramientas de gestión a utilizar en este contrato son las siguientes:
• La herramienta utilizada por el 1º nivel de CAU de Osakidetza, para registro y gestión de las consultas e incidencias técnicas y funcionales de los aplicativos, es el producto HP-Service Manager.
• La herramienta utilizada en Osakidetza para la Gestión de la Demanda y el flujo de Mantenimiento, es el producto HP-PPM (Project and Portfolio Management).
En caso de requerirse la integración de las herramientas actuales y futuras de Osakidetza, con la herramienta propia del proveedor, los costes derivados de esta integración correrán a cargo del adjudicatario.
3 DEFINICIÓN DEL SERVICIO
3.1 Fases del servicio
Se identifican las siguientes fases:
3.1.1 Fase de transición
El objetivo de esta fase es la recepción de los elementos básicos e imprescindibles para la prestación del servicio, entre Osakidetza y el suministrador entrante.
Como primeras tareas de la fase de transición, el proveedor entrante deberá realizar las siguientes:
• Implantación completa del plan de infraestructuras.
• Presentación de un plan detallado de calidad, que deberá ser aprobado por
Osakidetza.
• 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 transición del conocimiento y del plan de activación del servicio.
El suministrador entrante pondrá en conocimiento de Osakidetza 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.
Esta fase se ejecutará de acuerdo al plan detallado de actividades del proceso de transferencia de conocimiento y al plan de activación del servicio, ambos realizados por el suministrador entrante en la fase de transición.
El suministrador entrante tiene obligación de documentar todas las actividades del proceso de transición, así como conseguir la aprobación de inicio del servicio.
Dentro de la fase de transición y como parte de la transferencia de conocimiento, el suministrador del servicio deberá adquirir y mantener posteriormente la información necesaria para la prestación del servicio.
En el ámbito de las aplicaciones NO SAP, será responsabilidad del adjudicatario reinstalar en sus propias dependencias el conjunto de aplicaciones, incluyendo ya no solo el código fuente, sino también el conjunto de artefactos adicionales que la conforman (contenidos estáticos, scripts de base de datos, la base de datos, etc.) proveyéndose así de la autonomía suficiente para realizar las actividades de mantenimiento que le serán encomendadas.
Deberá proveerse además de una conexión simétrica con suficiente ancho xx xxxxx como para soportar el tráfico que se genere durante el tiempo de resolución de las actividades de mantenimiento que le sean requeridas. Se contempla la opción de conexión VPN, aunque no se descartan otras posibles alternativas que deberán ser valoradas.
El coste de las licencias necesarias para poder realizar las tareas de mantenimiento en sus propias instalaciones correrá a cargo del adjudicatario.
Se iniciará también en esta fase la gestión del inventario de aplicaciones, así como la
de los repositorios de artefactos software, y de documentación.
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 prestación regular. Osakidetza realizará una comprobación formal de la capacitación del suministrador entrante para asumir el servicio, así como la revisión de la documentación actualizada y/o generada y el acta de conformidad firmada por el suministrador entrante tras la fase de transición.
Las ofertas indicarán los plazos en que el proveedor se compromete a las siguientes acciones:
• Entrega de la documentación actualizada.
• Disponibilidad de las herramientas necesarias para la prestación y gestión del servicio y su integración conforme a lo exigido en el pliego.
• Implementación de los procedimientos necesarios para la prestación y gestión del servicio.
• Equipo base establecido completamente operativo.
El suministrador entrante recibirá, si no lo ha recibido durante las etapas anteriores, la documentación asociada a las aplicaciones transferidas, el código fuente de las aplicaciones transferidas y todas las peticiones de servicio especificados en el presente pliego.
La lista y priorización de peticiones serán realizadas directamente por Osakidetza en función de las necesidades.
3.1.2 Fase de prestación regular
La fase de servicio regular comenzará a la finalización de la fase de transición y finalizará con el inicio de la fase de devolución del servicio.
Durante esta fase, tanto Osakidetza como el suministrador entrante, podrán proponer las adaptaciones a los elementos del modelo que estimen oportuno.
En caso de que esto suceda, la parte solicitante deberá generar un informe que justifique la necesidad y los beneficios previstos de dicha adaptación.
El suministrador prestará el servicio bajo su plena responsabilidad, resolviendo las incidencias y peticiones existentes.
El suministrador entregará los informes acordados, que permitan realizar un seguimiento del servicio prestado.
Durante la fase de prestación del servicio se aplicarán las condiciones generales definidas en el presente Xxxxxx.
3.1.3 Fase de devolución
Antes del cese o finalización de contrato, el suministrador estará obligado a devolver el control del servicio a Osakidetza y/o al suministrador o suministradores que ésta determine. Con anticipación suficiente al inicio de la fase de devolución del servicio, se hará una evaluación y planificación de todas las actividades.
El suministrador deberá realizar el proceso de transición de salida, conforme a la
metodología que Osakidetza determine, responsabilizándose del cumplimiento de los siguientes puntos:
• Garantizar la viabilidad del proyecto.
• Asegurar que se mantienen los servicios a Osakidetza durante el traspaso del control de servicios.
• Colaborar activamente con Osakidetza y con el futuro suministrador entrante durante este proceso, para facilitar la transición de los servicios sin causar perjuicios.
• Entregar una planificación detallada de la transición para hacerse cargo el suministrador entrante por completo del servicio, incluyendo los tiempos de solape con los recursos existentes que serán remplazados, así como, los perfiles de las personas que lo llevarán a cabo.
• Asegurar la devolución de cualquier dato de carácter personal empleado en las pruebas.
• Incluir cualquier otra documentación que estime oportuna.
• Entrega al suministrador entrante de la documentación técnica de cada uno de los sistemas. Dicha documentación deberá incluir los mecanismos de integración de sistemas que garanticen aislar al resto de sistemas de Osakidetza de cualquier cambio que se considere necesario.
3.2 Descripción detallada de los servicios de mantenimiento
El conjunto de aplicaciones que se relacionan en el ANEXO I formarán la línea base
sobre el que los adjudicatarios realizarán el servicio de mantenimiento.
Esta línea base podrá ser modificada durante la vigencia del contrato, con la
incorporación y retirada de aplicaciones, tal y como se detalla a continuación.
Para la incorporación de nuevas aplicaciones se establecen las siguientes responsabilidades:
• Se mantendrá el modelo utilizado para la xxxxxxxx del servicio, es decir, realizando las fases de transición y prestación regular, si bien su duración será acorde con la importancia y complejidad de la aplicación.
• El suministrador deberá tener acceso a la información sobre el estado de las aplicaciones, las incidencias existentes, incidencias resueltas, documentación funcional y técnica y aquella información que ayude a agilizar el traspaso de conocimiento de la nueva aplicación.
• El suministrador aportará un plan de trabajo y la estimación de proceso de inclusión de nuevas aplicaciones y su impacto dentro de la Dimensión Base. Osakidetza tiene la responsabilidad de ajustar y validar dicho plan.
• A esta nueva aplicación se le aplicarán los parámetros indicados dentro de los acuerdos a nivel de servicio, aunque por un periodo transitorio acordado no serán causa de deducción. Transcurrido este periodo, la aplicación pasará a formar parte de la línea de servicio regular.
Para la retirada de aplicaciones, el suministrador facilitará el traspaso de conocimiento tal y cómo se detalla en la fase definida dentro de este pliego como Fase de Devolución.
La Dimensión Base se revisará periódicamente con el suministrador. La frecuencia
definida para dicha revisión es la siguiente:
• Quincenalmente durante las Fases de Transición
• Trimestralmente durante la Fase de Prestación regular del servicio
A continuación se definen los servicios solicitados, a los que deberán ajustarse los licitadores en su oferta.
3.2.1 Línea de Mantenimiento y Evolución
3.2.1.1 Línea de mantenimiento correctivo
Inicialmente, las aplicaciones sobre las que se realizarán estos servicios son las que figuran en el ANEXO I, si bien esta relación puede ser modificada durante la vigencia del contrato por diferentes motivos, entre otros:
• Incorporación de aplicaciones que finalizan su desarrollo y puesta en producción.
• Incorporación de nuevas aplicaciones que asume Osakidetza.
• Retirada de aplicaciones por obsolescencia, sustitución por nuevos desarrollos o falta de adecuación a nuevas situaciones.
Una vez incorporadas las aplicaciones, regirán las mismas condiciones que para el resto.
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 objeto del contrato, la resolución de problemas e incidencias debidas a fallos en las mismas, 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 Osakidetza), 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 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 participará en la gestión de la incidencia con Osakidetza con el fin de garantizar un menor impacto en el servicio. En el caso de considerarse necesario por parte de Osakidetza, é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.
Cada modificación realizada dentro de esta línea de mantenimiento correctivo deberá venir acompañada de la documentación asociada correspondiente, que constará de al menos: documentación del problema y de la solución y documento que recoja la propuesta y posterior resultado de ejecución de pruebas unitarias, de conjunto y de
carga, cuando Osakidetza así lo determine.
La puesta en producción de una modificación de tipo correctivo en cualquier desarrollo quedará supeditada a la aceptación final de Osakidetza.
Toda petición de mantenimiento correctivo, así como las actividades asociadas a la petición, quedarán registradas en la herramienta de gestión de Osakidetza. El proveedor deberá hacer uso de la misma para la gestión del flujo de vida de la petición, siguiendo el procedimiento establecido por Osakidetza.
La actividad de mantenimiento correctivo está asociada a la puesta en Producción, por lo que deberá seguir los procedimientos definidos por Osakidetza. El Suministrador proporcionará mecanismos de escalado para la resolución de incidencias adicionales en las 48 horas posteriores a la implantación.
El equipo asignado a estas tareas estará formado por perfiles 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.
Estarán incluidas actividades características del mantenimiento de los sistemas SAP como son:
• Notificación a SAP de errores de producto mediante mensajes OSS.
• Implantación de correcciones proporcionadas por SAP mediante notas OSS.
• Revisión de parches de SAP, incluidos parches legales. El adjudicatario deberá proponer, y en cualquier caso validar la compatibilidad y riesgos de instalación de parches. Si bien la instalación de los mismos queda fuera del alcance del presente contrato, será obligación del adjudicatario revisar sobre los distintos entornos de cada sistema la correcta aplicación de los mismos y las subsiguientes actividades de ajuste.
• Configuración de escenarios EHP, o cualquier otro mecanismo que SAP articule para la evolución funcional del software.
3.2.1.2 Línea de Mantenimiento adaptativo/evolutivo (pequeña escala)
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.
La decisión de si una petición es tratada dentro de esta línea de servicio es tomada únicamente por Osakidetza.
Las tareas del Suministrador se centrarán, además de las habituales de programación, y según sea necesario, el análisis funcional, diseño de la solución, parametrización de producto, realización de pruebas y lo que corresponda de las actividades de pruebas de integración.
Toda petición de mantenimiento evolutivo quedará registrada en la herramienta de gestión de Osakidetza. El proveedor deberá hacer uso de la misma para la gestión del flujo de vida de la petición, siguiendo el procedimiento establecido por Osakidetza.
La actividad de esta línea de servicio estará asociada al desarrollo y puesta en explotación, por lo que deberá seguir los procedimientos definidos por Osakidetza.
Cada modificación realizada dentro de esta línea de mantenimiento evolutivo deberá venir acompañada de la documentación asociada correspondiente, que constará de al
menos: documentación de requisitos funcionales y documento que recoja la propuesta y posterior resultado de ejecución de pruebas unitarias, de conjunto y de carga, cuando Osakidetza así lo determine.
La puesta en producción de una modificación de tipo evolutivo en cualquier desarrollo quedará supeditada a la aceptación final de Osakidetza o quien ésta determine.
Será asimismo responsabilidad del adjudicatario, cuando Osakidetza así lo determine, la formación destinada a los usuarios de los desarrollos realizados, aun cuando ésta implique desplazamiento a sus ubicaciones de trabajo u otras sedes (siempre en el ámbito de la Comunidad Autónoma de Euskadi).
El equipo asignado a estas tareas estará formado por perfiles con capacidad de gestión de proyectos de desarrollo, de análisis y diseño y con la experiencia y conocimiento técnico y funcional necesarios para el correcto desempeño de su trabajo.
Estarán incluidas actividades características del mantenimiento de los sistemas SAP como son:
• Notificación a SAP de errores de producto mediante mensajes OSS.
• Implantación de correcciones proporcionadas por SAP mediante notas OSS.
• Revisión de parches de SAP, incluidos parches legales. El adjudicatario deberá proponer, y en cualquier caso validar la compatibilidad y riesgos de instalación de parches. Si bien la instalación de los mismos queda fuera del alcance del presente contrato, será obligación del adjudicatario revisar sobre los distintos entornos de cada sistema la correcta aplicación de los mismos y las subsiguientes actividades de ajuste.
• Configuración de escenarios EHP, o cualquier otro mecanismo que SAP articule para la evolución funcional del software.
3.2.2 Línea de Desarrollo (Evolutivo a gran escala)
En este servicio se incluyen aquellas actividades relacionadas con el desarrollo de nuevas funcionalidades y/o nuevas aplicaciones y sistemas de información, que por tanto, no están incluidas en la línea evolutiva, y en gran parte corresponderán a actuaciones de tamaño y complejidad importantes.
El suministrador realizará un estudio previo de los trabajos a realizar y ofrecerá a Osakidetza una propuesta de proyecto que incluya cronograma, hitos de entrega, dedicación de recursos, estimación económica y análisis de riesgos. La estimación económica se basará en los costes unitarios ofertados para cada perfil.
Con esta información y siguiendo los cauces y procedimiento que se describen en este Pliego, Osakidetza tomará la decisión que considere oportuna.
Una vez aceptado el proyecto y su importe económico e iniciada su ejecución, se facturará en base a los hitos de entrega definidos en el cronograma realizado. Dicha facturación imputará lo asignado a esta línea desarrollo.
Las tareas correspondientes al suministrador para esta línea de servicio 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 hasta la puesta en producción.
El suministrador se encargará de la gestión del proyecto en cuanto a planificación
temporal, de tareas, recursos,... así como del seguimiento y documentación.
La actividad de esta línea de servicio estará asociada al desarrollo y puesta en Producción, por lo que deberá seguir los procedimientos definidos por Osakidetza.
Cada desarrollo deberá venir acompañado de la documentación asociada correspondiente, que constará de al menos: documentación de requisitos funcionales, documentación de requisitos técnicos y documento que recoja la propuesta y posterior resultado de ejecución de pruebas unitarias, de conjunto y de carga, cuando Osakidetza así lo determine.
La puesta en producción de los desarrollos realizados quedará supeditada a la aceptación final de Osakidetza.
Será asimismo responsabilidad del adjudicatario, cuando Osakidetza así lo determine, la formación correspondiente destinada a los usuarios de los desarrollos realizados, aun cuando ésta implique desplazamiento a sus ubicaciones de trabajo u otras sedes (siempre en el ámbito de la Comunidad Autónoma de Euskadi).
El equipo asignado a estas tareas estará formado por perfiles con experiencia en desarrollo de proyectos en formato “cerrado”. Deberá estar formado por un equipo 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 servicio.
3.3 Horario de la prestación del servicio
La dedicación de los recursos ofertados será de jornada completa. El horario de trabajo podrá verse afectado por las circunstancias y necesidades en cada momento de los proyectos y sistemas de información a mantener. Por lo tanto, los licitadores deberán comprometerse a una disponibilidad horaria según lo exija la criticidad o urgencia de determinados sistemas de información.
El horario normal de los trabajos será el siguiente:
• De 8 a 18 horas, de lunes a jueves.
• De 8 a 15 horas, los viernes
En el caso de que los servicios contratados pudieran implicar para el suministrador (por razones de cumplimiento de plazos u otras razones) la decisión de realización de los servicios en régimen de turnos o en sábados o festivos, o en régimen de nocturnidad, Osakidetza no aceptará sobrecostes adicionales por estas circunstancias, que deberán ser absorbidos siempre por el adjudicatario.
3.4 Ubicación de la prestación del servicio
Sin perjuicio de lo que expresan los siguientes párrafos, Osakidetza se reserva el derecho de modificar la política en cuanto a ubicaciones del equipo durante el transcurso del contrato, sin que ello suponga un coste adicional para Osakidetza.
La prestación del servicio tendrá un carácter mixto, con un equipo presencial continuado en las instalaciones de Osakidetza, y una parte en remoto.
• Instalaciones de Osakidetza.
En dependencias de Osakidetza se ubicarán sólo los coordinadores funcionales, equipo de consultores que mantienen una interlocución continuada con Osakidetza.
Los consultores in-situ requeridos, deberán asegurar el conocimiento funcional de al menos los siguientes módulos:
• BW
• Logística y Finanzas
• Recursos Humanos
El licitador propondrá la composición detallada del equipo presencial, pudiendo ofertar perfiles complementarios.
• Instalaciones del suministrador y factorías de software.
El resto de los trabajos se realizarán en las instalaciones del adjudicatario.
Se requiere que al menos, el responsable del servicio, los consultores y el núcleo de desarrollo de mayor nivel (analistas), estén ubicados en dependencias del suministrador sitas en la Comunidad autónoma de Euskadi, con el objeto de poder atender in situ, tanto a las actividades de soporte al despliegue de los grandes evolutivos, como la resolución de incidencias críticas, que pudieran requerir el desplazamiento de los técnicos a instalaciones de Osakidetza. Las ofertas incluirán la propuesta a este respecto.
Para la realización del trabajo de manera remota, los costes de conexión, infraestructura (hardware y software) que fuesen necesarios, correrán por cuenta del suministrador. Se deberá garantizar la conectividad bidireccional desde el proveedor a Osakidetza, y viceversa, entre los entornos de ambas organizaciones para facilitar la construcción, pruebas e identificación de incidencias de la cartera de aplicaciones a mantener.
Todas aquellas empresas que vayan a hacer uso de factorías de software, deberán presentar una declaración responsable de estar en disposición de acreditar la certificación de calidad CMMI como mínimo con nivel 3. Los niveles de calidad en este formato de prestación deberán ser equivalentes a los de trabajo presencial.
Adicionalmente, y en el caso de factorías de software, se exige al suministrador una serie de condiciones para que puedan ser aceptables:
✓ Titularidad del Servicio: el suministrador no podrá subcontratar a un tercero la prestación de este tipo de servicios.
✓ La factoría deberá de estar ubicada en territorio de la Unión Europea.
✓ Infraestructura: Osakidetza deberá conocer y aceptar expresamente las medidas de seguridad, equipamiento y comunicaciones de las instalaciones del suministrador desde las que se preste este servicio.
✓ La instalación y adecuación de los locales será totalmente por cuenta del suministrador.
4 CONFIGURACIÓN DEL SERVICIO
4.1 Modelo de Gestión del Servicio
El adjudicatario del expediente deberá definir el Modelo de Gestión del Servicio, basado en las mejores prácticas y normas existentes en el mercado (lSO 20000, ISO 27001, lTlL, ) y futuras evoluciones de estos estándares.
4.2 Modelo de Relación
El modelo de relación tiene como objetivo asegurar la coordinación del adjudicatario con los diferentes interlocutores Osakidetza.
El Modelo de Relación debe cubrir todos los niveles de información y decisión, desde el nivel operativo hasta el estratégico, facilitando la toma de decisiones, el seguimiento de los objetivos globales y la resolución de potenciales conflictos.
Por otra parte, el Modelo de Relación deberá garantizar la flexibilidad y la adaptación del servicio a la evolución de la Organización, pudiendo cambiar durante la vigencia del contrato, en particular ante eventuales reorganizaciones.
El Modelo de Relación constará principalmente de:
• Una estructura de comités que sirva como principal elemento de decisión y seguimiento del contrato y de los servicios prestados por el adjudicatario.
• La definición de unos interlocutores de ámbito de actividad que actuarán de interlocutores en la relación por ambas partes, tanto a nivel de comité, como en la línea operativa de coordinación diaria.
• Un modelo de trabajo general con las fronteras e interacciones claramente delimitadas a nivel de actividad y esquematizada hacia cada una de las áreas de la Subdirección de Informática de Osakidetza, que intervienen en cualquier lugar del ciclo de vida de las aplicaciones.
• Será necesario una vez adjudicado el contrato, revisar y redactar un Modelo de Relación que cubra todo el ámbito de este contrato, así como la relación con el resto de unidades de la Subdirección de Informática.
El licitador deberá presentar en su oferta el Modelo de Relación y el Modelo Organizativo que considere más adecuado para la prestación del servicio.
4.3 Equipo de Trabajo
Se establece un umbral mínimo de horas por perfil para los dos años de duración del contrato, de la siguiente forma:
Perfiles | Horas |
Jefe de proyecto | 3.520 |
Coordinador funcional | 10.560 |
Consultor / Analista | 12.320 |
Analista Programador | 14.080 |
Programador | 10.520 |
TOTAL | 51.000 |
Aquellas empresas que no alcancen el mínimo de horas exigidas por perfil, quedarán
excluidas automáticamente.
Para la gestión y el desarrollo del servicio, los licitadores deberán detallar los siguientes aspectos en su propuesta:
• Organigrama del equipo de trabajo, identificando responsables y funciones a desarrollar según considere para la ejecución del servicio de este pliego.
• Detalle del equipo total de trabajo, que los licitadores consideren necesario, identificando las personas, categoría y funciones a desarrollar para la ejecución de las tareas previstas con el alcance definido en este pliego.
• Relación nominal de los participantes, junto su correspondiente documento de currículo
En la composición del equipo de trabajo se deberán ofertar los perfiles indicados en la tabla anterior y no otros, con las siguientes consideraciones:
• Para las tareas de Gestión y Administración del servicio deberán incluirse al menos los siguientes perfiles:
✓ Jefe de Proyecto: El Jefe del Proyecto designado por el adjudicatario, será el Responsable del Servicio ante Osakidetza.
✓ Coordinador Funcional: Por cada área funcional especificada en el ANEXO I “Relación de aplicaciones” objeto del contrato, el adjudicatario deberá de proporcionar a Osakidetza un interlocutor, que deberá principalmente asegurar el Conocimiento Funcional o Técnico específico de las soluciones implantadas en su área y de los cambios y evoluciones que, como consecuencia de la actividad ordinaria de mantenimiento, se produzcan en la misma, en colaboración permanente con el Responsable Funcional del área de Osakidetza.
• Para las tareas de Mantenimiento y Desarrollo el adjudicatario deberá de disponer de un Equipo Humano con capacidad suficiente para realizar las tareas asociadas a los servicios solicitados.
Asimismo, deberá garantizar la gestión de un equipo variable que se adecue a las demandas de servicios que vaya solicitando Osakidetza en función de las necesidades de cada momento.
El equipo de trabajo propuesto estará formado por personal técnico con categoría profesional y nivel de especialización adecuados a las necesidades planteadas en cada momento, de acuerdo con las actividades que se vayan desarrollando, valorándose especialmente la inclusión de profesionales con certificación SAP en los módulos objeto del expediente y detallados en el ANEXO I.
El licitador debe comprometerse, en caso de ser adjudicatario, a mantener el equipo, según lo establecido en su oferta, y durante el periodo fijado en cada actividad específica.
La gestión de la carga de trabajo durante las épocas vacacionales será la misma que para el resto del periodo del contrato y estará sujeta a la planificación acordada con Osakidetza. No podrá reducir unilateralmente la carga de trabajo durante las épocas vacacionales.
Asimismo, el suministrador deberá asegurar la disponibilidad de recursos con los conocimientos requeridos para mantener los niveles de servicio y la planificación acordados que permita hacer frente a sus posibles contingencias imprevistas en su personal.
La modificación de alguno de los componentes del equipo adscrito a la ejecución de los trabajos, sin observar el procedimiento y requisitos exigidos que se señalan a continuación, facultará a Osakidetza para calificar dicha modificación como una rotación no planificada. La reiteración en el número de rotaciones no planificadas (mayor o igual al 30 % del Equipo en un año) faculta a Osakidetza para instar a la resolución del contrato.
El equipo será configurado y dimensionado por el licitador en base a la información suministrada en el pliego, así como a su experiencia por el tipo de actividades a realizar.
4.3.1 Constitución inicial del Equipo de Trabajo
El equipo humano a incorporar tras la formalización del contrato para la ejecución de los trabajos deberá estar formado por componentes relacionados en la oferta adjudicataria.
Si tras la adjudicación, se observara que el equipo de proyecto no se corresponde con el Documento de Propuesta Técnica objeto de la misma y:
• Caso que el adjudicatario presente justificación escrita, detallada y suficiente, explicando el motivo que suscita el cambio, se procederá a:
✓ La presentación por el adjudicatario de posibles candidatos con un perfil de cualificación técnica igual o superior al de la persona que se pretende sustituir.
✓ Aceptación de alguno de los candidatos por parte de la Dirección del Proyecto de Osakidetza
• Caso de que se demostrase que el cambio no se corresponde con causa justificada, de fuerza mayor y no imputable al adjudicatario, Osakidetza se reserva el derecho no solo a la aprobación de la persona o personas sustitutivas, sino incluso a la revisión de la adjudicación y en su caso la rescisión del pedido/contrato, si este hecho fuera elemento determinante en la mencionada adjudicación.
4.3.2 Modificaciones en la composición del Equipo de Trabajo
Osakidetza podrá solicitar el cambio de cualquiera de los componentes del equipo, con un preaviso de un mes, por otro de igual categoría, si existen razones justificadas que lo aconsejen.
Si es el adjudicatario el que propone el cambio de una de las personas del Equipo Base, deberá solicitarlo con al menos quince días de antelación y cumplir los siguientes requisitos:
• Justificación escrita, detallada y suficiente, explicando el motivo que suscita el cambio.
• Presentación de posibles candidatos para un perfil cuya cualificación técnica sea igual o superior al de la persona que se pretende sustituir.
• Aceptación por Osakidetza de los candidatos propuestos.
Los posibles inconvenientes de adaptación al entorno de trabajo y al proyecto debidos a las sustituciones en los componentes del Equipo, deberán subsanarse mediante periodos de solapamiento sin coste adicional, durante el tiempo necesario. El plazo de solapamiento mínimo entre el perfil entrante y el saliente será de 15 días.
Los adjudicatarios deberán garantizar que disponen de los mecanismos adecuados para minimizar la rotación no planificada del personal que compondrá el Equipo de Trabajo, para evitar la pérdida de conocimiento y el impacto en los niveles de servicio e imagen.
Por rotación planificada se entiende aquella que se comunica a Osakidetza como mínimo un mes antes de que se produzca, y se acompaña de un solapamiento del recurso saliente con el entrante para la adecuada transferencia de conocimiento durante un periodo no inferior a un mes.
4.3.3 Veracidad de los datos
Osakidetza se reserva la facultad de solicitar, en cualquier momento, antes o después de la adjudicación y durante el curso de los trabajos, de cualquier otro tipo de documento complementario, en orden a la comprobación de cuantos datos haya ofrecido la empresa adjudicataria, tanto respecto a la misma, como a los recursos de que disponga.
La falsedad en los mismos podrá implicar asumir penalizaciones, y en último término, podrá provocar la resolución del contrato.
4.3.4 Condicionantes del equipo de trabajo ofertado
La falsedad en el nivel de conocimientos técnicos del personal ofertado, deducida del contraste entre lo reflejado en el currículo y los conocimientos reales demostrados en la ejecución de los trabajos, podría en último término, provocar la revisión de la adjudicación y en su caso la rescisión del contrato.
4.3.5 Currículo de los componentes del Equipo de Trabajo.
Se deberá adjuntar el currículo individual detallado de todos y cada uno de los componentes del grupo de trabajo propuesto para la realización de las tareas y actividades de los trabajos objeto de contratación, junto con el papel/perfil (conforme a los indicados en el cuadro anterior) que asumen en la realización descrita.
En el caso de que el profesional disponga de alguna certificación SAP en los módulos objeto del expediente, deberá adjuntarla al currículo.
La no inclusión del currículo de alguno de los participantes, puede suponer la imposibilidad de una adecuada evaluación del criterio de “Medios adscritos para la ejecución del proyecto”, pudiendo el licitador no ser puntuado por este concepto.
Para la descripción de los recursos humanos se utilizarán el formulario que se detalla en el ANEXO IV.
4.4 Asignación de recursos a fases del proyecto
En la fase de prestación regular, el equipo estará configurado para proveer los
servicios de mantenimiento, soporte y evolución, así como desarrollos de
tamaño limitado y no excesiva complejidad, con una Dimensión Base equivalente al 50% del total de recursos ofertados y una distribución coherente con los servicios a prestar.
Durante la Fase de Transición el equipo tendrá una configuración diferente y una dimensión inferior.
Los recursos necesarios para nuevos desarrollos y evoluciones más complejas, serán requeridos en función de las necesidades y computarán económicamente en el 50% restante de lo ofertado.
5 ESPECIFICACIONES TÉCNICAS
5.1 Infraestructura
Osakidetza proveerá la infraestructura (hardware y software) necesarias para facilitar la prestación del servicio de la siguiente forma:
• Aplicaciones SAP:
Osakidetza proveerá tres entornos diferenciados:
o Producción.
o Integración.
o Desarrollo.
• Aplicaciones NO SAP:
Osakidetza pondrá a disposición del adjudicatario los siguientes entornos:
o Producción
o Pre-Producción
o El entorno de Desarrollo deberá ser proporcionado por el adjudicatario.
Dado que, a priori, el equipo de trabajo realizará la mayor parte de su trabajo en oficinas propias, el adjudicatario deberá asumir la instalación de las infraestructuras requeridas para el desarrollo del servicio, esto incluye:
• Aislamiento total (desde nivel de red) de los puestos informáticos del equipo de trabajo del resto de la red del adjudicatario.
• Dotación de línea dedicada, de caudal suficiente, para la conexión a los entornos de preproducción y producción necesarios.
5.2 Estándares
En el ANEXO II, Directrices y Especificaciones Técnicas, se describen, a título informativo, los estándares actuales, si bien estos podrán ser modificados por Osakidetza durante el contrato.
En el ANEXO III, se detallan las Especificaciones del Cliente, maqueta actual, si bien ésta podrá ser también modificada por Osakidetza durante el contrato.
6 CONTROL Y SEGUIMIENTO
El propósito de las tareas de control y seguimiento es el de proveer una visión objetiva del estado actual de la prestación del servicio y determinar las posibles desviaciones a fin de aplicar las acciones correctoras que sean necesarias. En este sentido se denomina seguimiento a la evaluación rutinaria del estado, mientras que llamamos control, a la toma de los valores que definen el estado.
Los productos resultantes de esta tarea son los informes de seguimiento, un documento donde se anotan los resultados de la evaluación de una iteración de control. Existirán una serie de informes de seguimiento requeridos para el correcto análisis de la evolución del Servicio.
Se deberán incluir mínimamente tres tipos de informes de periodicidad mensual:
• Informes de Seguimiento: Relación detallada de consultas, incidencias, problemas y peticiones, resumen acumulado del mes actual, acumulado del mes anterior y variación neta del mes, etc.
• Informes del Nivel de Servicio: Grado de cumplimiento de los indicadores, evolución anual, análisis de incidencias o problemas, propuestas de actuación, etc.
El análisis del nivel de cumplimiento de los Indicadores de Nivel de Servicio, se realizará en base al informe que automáticamente genera el sistema de Gestión de Incidencias y Gestión de la Demanda de Osakidetza.
• Evolución de la Documentación Técnica: Aplicaciones documentadas con entidades asociadas, documentación en curso, grado de avance, etc.
De lo detallado anteriormente se deriva que el licitador deberá describir en su Oferta:
• El modelo de control y seguimiento a aplicar durante la prestación del servicio, incluyendo las reuniones de seguimiento a celebrar, su objetivo, su periodicidad, los asistentes necesarios, los controles que deben ser ejecutados, etc.
• Los informes de seguimiento que deberán obtenerse en cada fase del servicio, y para cada solicitud de trabajo realizada. Se detallará su objetivo y al menos parcialmente, su contenido.
• Los indicadores de calidad del servicio a medir, y su criticidad asociada.
• Los métodos de aplicación de las posibles acciones correctoras.
7 INDICADORES DE NIVEL DE SERVICIO (ANS)
Se han establecido los siguientes tipos de indicadores de nivel de servicio:
• Indicadores de Servicio
• Indicadores de Calidad
• Indicadores de Productividad
7.1 Indicadores de Servicio
Cubren cada uno de los elementos de servicio objeto de este pliego:
• Servicio de Mantenimiento Correctivo, Mantenimiento Preventivo, Adaptativo y Evolutivo a pequeña escala
• Servicio de Desarrollo. Evolutivo a gran escala
Para cada indicador se detallan una serie xx xxxxxx:
• Identificador. Código que identifica el indicador
• Descripción. Descripción del indicador
• Fórmula de cálculo. Método para calcular el indicador
• Plazo máximo. Límite temporal para el cumplimiento del indicador
• Periodicidad. Frecuencia de cálculo del indicador
• Valor objetivo. Valor fijado como objetivo para el indicador
• Penalización. El incumplimiento del indicador tiene penalización o no.
Un atributo de catalogación importante para las incidencias y los problemas es la urgencia o la criticidad de los mismos (prioridad), que influye sobre los tiempos de resolución requeridos y los indicadores de nivel de servicio asociados.
Sus valores son:
Prioridad | Descripción |
Muy Urgente | Incidencias que impactan gravemente sobre el negocio o la imagen de Osakidetza. Requieren de una intervención inmediata e ininterrumpida hasta su resolución definitiva. |
Urgente | Incidencias que no impactan sobre el negocio o la imagen de Osakidetza pero que impiden la ejecución normal de una o más partes de la aplicación objeto del Servicio o de otras con las que se relaciona. Afectan a aplicaciones definidas por Osakidetza como NO críticas. |
Normal | Incidencias que no impactan sobre el negocio o la imagen de Osakidetza y no impiden el funcionamiento normal de la aplicación objeto del Servicio o de otras con las que se relaciona. Afectan a aplicaciones definidas por Osakidetza como NO críticas. |
Cualquier incidencia que afecte a una aplicación crítica será considerada inicialmente como Muy Urgente. No obstante, y tras su revisión, podrá ser modificada por Osakidetza a prioridad Urgente o Normal.
A efectos del cálculo de indicadores, y por ende, de las penalizaciones asociadas, el cómputo de horas se realizará en base al horario laboral de trabajo establecido, excepto para las peticiones de mantenimiento correctivo de prioridad muy urgente, o urgente, aplicándose en este caso el horario natural.
Se asumen las siguientes definiciones:
• Tiempo de Respuesta: Tiempo transcurrido desde el alta de la petición hasta que ésta se acepta (revisa).
• Tiempo de Resolución: Tiempo transcurrido desde que se acepta la petición hasta que ésta se resuelve satisfactoriamente
• El cálculo del valor objetivo se aplicará sobre el total de peticiones dadas de alta en el período.
7.1.1 Mantenimiento Correctivo
Id. | Descripción | Fórmula de Cálculo | Plazo Máximo | Periodicidad | Valor Objetivo | Penalización |
IN_02 | Tiempo Resolución problemas Muy Urgentes Porcentaje de problemas catalogados como Muy Urgentes resueltos en el plazo máximo de resolución establecido sobre el total de problemas finalizados (en el período). | Tiempo Resolución = Fecha Solución - Xxxxx Xxxxxxxxxx (Nº problemas Muy Urgentes resueltos en plazo / Nº total de problemas) * 100 | 4 horas | Mensual | >= 95% | Si |
IN_03 | Tiempo Resolución problemas Urgentes Porcentaje de problemas catalogados como Urgentes resueltos en el plazo máximo de resolución establecido sobre el total de problemas finalizados (en el período). | Tiempo Resolución = Fecha Solución - Xxxxx Xxxxxxxxxx (Nº problemas Urgentes resueltos en plazo / Nº total de problemas) * 100 | 8 horas | Mensual | >= 95% | Si |
IN_04 | Tiempo Resolución problemas Normales Porcentaje de problemas catalogados como Normales resueltos en el plazo establecido sobre el total de problemas finalizados (en el período). | Tiempo Resolución = Fecha Solución - Xxxxx Xxxxxxxxxx (Nº problemas Normales resueltos en plazo establecido / Nº total de problemas) * 100 | Fecha entrega prevista | Mensual | >= 95% | Si |
7.1.2 Mantenimiento Adaptativo/Evolutivo a pequeña escala
Id. | Descripción | Fórmula de Cálculo | Plazo Máximo | Periodicidad | Valor Objetivo | Penalización |
IN_05 | Desviación Planificación Evolutivo Urgente Porcentaje de peticiones Urgentes finalizadas en el plazo establecido sobre el total de peticiones finalizadas (período). | 100 x (Fecha Entrega Petición - Fecha Prev. Entrega) / Plazo de Petición. (Nº de peticiones finalizadas en el plazo establecido / Nº total de peticiones) * 100 | Fecha entrega prevista | Trimestral | >= 95% | Si |
IN_06 | Desviación Planificación Evolutivo Normal Porcentaje de peticiones finalizadas en el plazo establecido sobre el total de peticiones finalizadas (período). | 100 x (Fecha Entrega Petición - Fecha Prev. Entrega) / Plazo de Petición. (Nº de peticiones finalizadas en el plazo establecido / Nº total de peticiones) * 100 | Fecha entrega prevista | Trimestral | >= 95% | Si |
7.1.3 Desarrollo: Evolutivo a gran escala
Id. | Descripción | Fórmula de Cálculo | Plazo Máximo | Periodicidad | Valor Objetivo | Penalización |
IN_07 | Desviación Planificación Desarrollo Porcentaje de peticiones finalizadas por debajo del máximo de desviación de plazo establecido sobre el total de peticiones finalizadas (período). | 100 x (Fecha Entrega Petición - Fecha Prev. Entrega) / Plazo de Petición. (Nº de peticiones finalizados por debajo del máximo de desviación de plazo establecido / Nº total de peticiones) * 100 | 20% sobre Fecha Entrega de Desarrollo Prevista | Trimestral | >= 95% | Si |
7.2 Indicadores de Calidad
7.2.1 Tipología de Incidencias
Por aplicación y Total general.
Aplicación | Tipo Servicio | Nº Actuaciones por Tipo Servicio | Total Anual | ||
Enero | ……. | Diciembre | |||
XX - XXXXXXX | Consultas | 999.999 | 999.999 | 999.999 | 999.999 |
Incidencias | 999.999 | 999.999 | 999.999 | 999.999 | |
Mto. Correctivo | 999.999 | 999.999 | 999.999 | 999.999 | |
Mto. Evolutivo/Adaptativo | 999.999 | 999.999 | 999.999 | 999.999 | |
Mto. Preventivo | 999.999 | 999.999 | 999.999 | 999.999 | |
TOTAL | 999.999 | 999.999 | 999.999 | 999.999 | |
7.2.2 Peticiones reabiertas
Se aplicará al Mantenimiento Adaptativo y Evolutivo:
Descripción | Umbral | Periodicidad | Penalización |
Número de peticiones reabiertas | Max. 5% | Trimestral | SI |
7.2.3 Reducción del mantenimiento correctivo
Descripción | Umbral | Periodicidad | Penalización |
Reducción mantenimiento correctivo | Min. 5% | Anual | No |
7.2.4 Errores del Proveedor
Se aplicará al Mantenimiento Adaptativo y Evolutivo:
Id. | Descripción | Fórmula de Cálculo | Valor Objetivo | Periodicidad | Penalización |
IN_08 | Ratio de Peticiones con errores críticos (bloqueantes) en pruebas de aceptación Porcentaje de peticiones con errores críticos en pruebas de aceptación (Pre-produccion) | (Nº de peticiones con errores críticos en las pruebas de aceptación / Nº Total de Peticiones en Pruebas de Aceptación dentro del periodo )*100 | <=15% | Mensual Se calculará acumulado ( mes a mes) | Si |
IN_09 | Ratio de Peticiones con errores NO críticos en pruebas de aceptación Porcentaje de peticiones con errores NO críticos en pruebas de aceptación (Pre-producción) | (Nº de peticiones con errores NO críticos en las pruebas de aceptación / Nº Total de Peticiones en Pruebas de Aceptación dentro del periodo )*100 | <=20% | Mensual Se calculará acumulado ( mes a mes) | Si |
IN_10 | Ratio de Propagación de errores a Producción Porcentaje de horas dedicadas a la resolución de errores en Producción, derivados de la implantación de una versión evolutiva | (Total horas estimadas de correctivos correspondientes a versiones parches derivadas de la implantación de un evolutivo) / (Total horas estimadas contenido de la versión evolutiva) * 100. | <=5% | Mensual Se calculará acumulado ( mes a mes) | Si |
7.2.5 Desviación Estimación evolutivos
Se aplicará al Mantenimiento Adaptativo y Evolutivo:
Id. | Descripción | Fórmula de Cálculo | Plazo Máximo | Periodicidad | Valor Objetivo | Penalización |
IN_11 | Ratio de peticiones estimadas en el mes Porcentaje de peticiones estimadas por debajo del máximo de desviación del plazo establecido sobre el total de solicitudes de estimación en el mes) | 100 x (número de peticiones estimadas dentro de plazo máximo/número total de solicitudes de estimación) | 10 días laborables | Trimestral | >= 90% | Si |
7.3 Indicadores de Productividad
7.3.1 ESFUERZO (I): Línea de Mantenimiento y Evolución
Se deberá detallar la evolución mensual, por aplicación y con un total general, con el desglose de horas reales y el importe que supondría a la tarifa hora contratada (Informes separados)
Aplicación | Tipo Servicio | Evolución mensual en horas | Total Anual | ||
Enero | ……. | Diciembre | |||
XX - XXXXXXX | Consultas | 999.999 | 999.999 | 999.999 | 999.999 |
Mto. Correctivo | 999.999 | 999.999 | 999.999 | 999.999 | |
Mto. Evolutivo/Adaptativo | 999.999 | 999.999 | 999.999 | 999.999 | |
Mto. Preventivo | 999.999 | 999.999 | 999.999 | 999.999 | |
TOTAL | 999.999 | 999.999 | 999.999 | 999.999 | |
Aplicación | Tipo Servicio | Evolución mensual en € (IVA inc.) | Total Anual | ||
Enero | ……. | Diciembre | |||
XX - XXXXXXX | Consultas | 999.999,99 | 999.999,99 | 999.999,99 | 999.999,99 |
Mto. Correctivo | 999.999,99 | 999.999,99 | 999.999,99 | 999.999,99 | |
Mto. Evolutivo/Adaptativo | 999.999,99 | 999.999,99 | 999.999,99 | 999.999,99 | |
Mto. Preventivo | 999.999,99 | 999.999,99 | 999.999,99 | 999.999,99 | |
TOTAL | 999.999,99 | 999.999,99 | 999.999,99 | 999.999,99 | |
7.3.2 ESFUERZO (II): Línea de Desarrollo
Se deberá detallar la evolución mensual, por aplicación y con un total general, con el desglose de horas reales y el importe que supondría a la tarifa hora contratada (Informes separados)
Aplicación | Tipo Servicio | Evolución mensual en horas | Total Anual | ||
Enero | ……. | Diciembre | |||
XX - XXXXXXX | Invertidas | 999.999 | 999.999 | 999.999 | 999.999 |
Facturadas | 999.999 | 999.999 | 999.999 | 999.999 | |
Diferencia | 999.999 | 999.999 | 999.999 | 999.999 | |
TOTAL | 999.999 | 999.999 | 999.999 | 999.999 | |
Aplicación | Tipo Servicio | Evolución mensual en € (IVA inc.) | Total Anual | ||
Enero | ……. | Diciembre | |||
XX - XXXXXXX | Invertido | 999.999,99 | 999.999,99 | 999.999,99 | 999.999,99 |
Facturado | 999.999,99 | 999.999,99 | 999.999,99 | 999.999,99 | |
Diferencia | 999.999,99 | 999.999,99 | 999.999,99 | 999.999,99 | |
TOTAL | 999.999,99 | 999.999,99 | 999.999,99 | 999.999,99 | |
8 CONTENIDO DE LAS OFERTAS
Con carácter obligatorio, las propuestas deberán presentarse en papel y en soporte digital, compatible con las herramientas instaladas en Osakidetza (MSWord 2010, Adobe Acrobat Reader 10).
Las ofertas se presentarán en dos modalidades:
• Oferta resumen ejecutivo, donde se recogerán los aspectos fundamentales de la oferta y sus elementos de valor añadido esenciales, conteniendo la información más relevante para la evaluación de la oferta por Osakidetza según los criterios de adjudicación publicados.
Este resumen ejecutivo no podrá superar el número de 25 páginas (25 páginas A4).
• Oferta completa, donde se podrá explicar y detallar los diferentes aspectos de la oferta, siempre que supongan una información directamente relacionada con los servicios propuestos en el pliego.
La oferta completa no podrá superar el número de 300 páginas (300 páginas A4).
Ambas modalidades de ofertas se deberán ajustar al siguiente contenido y formato:
1. Introducción
Se detalla el contexto en el que se realiza la oferta y las capacidades globales del licitador para entender y satisfacer los requerimientos del contrato.
En este apartado se expondrá la estrategia que la empresa ofertante considera apropiada para alcanzar los objetivos del proyecto.
2. Descripción de la solución propuesta
Este capítulo deberá agrupar los datos necesarios para realizar la evaluación técnica de la propuesta y se estructurará en:
2.1.Planteamiento General
En este apartado se expondrá la estrategia que la empresa ofertante considera apropiada para alcanzar los objetivos del proyecto.
2.2. Descripción de líneas de trabajo:
Descripción detallada de cada una de las líneas de trabajo y servicios a prestar y los mecanismos y herramientas para gestionar la calidad de software.
2.3. Herramientas a utilizar
Descripción de las herramientas que a priori se consideran adecuadas para la realización del proyecto, justificando su adecuación a los objetivos del mismo.
3. Organización y Equipo de Trabajo
3.1. Modelo organizativo:
Modelo global del proyecto y del equipo humano, distribución de funciones y responsabilidades, tareas, coordinación, dedicación al proyecto, flujos de comunicación, etc.
3.2. Equipo de Trabajo
Dimensión, configuración, perfiles y calidad del equipo de trabajo propuesto.
A efectos de detallar el equipo de trabajo, indicar que:
• El volumen de horas ofertadas por perfil deberá incluirse en el sobre “B”, oferta económica.
• El resto de aspectos relacionados con el equipo de trabajo, miembros, perfiles, certificaciones, funciones, curriculum, organización, etc, se incluirán en el sobre “C”, oferta técnica.
4. Plan de Trabajo
Descripción específica para cada una de las fases del proyecto; contenido, estrategia, operativa de trabajo y relación entre tareas.
Se incluirá la planificación en el tiempo de cada fase, hitos y productos resultantes, que permitirán la certificación del proyecto.
5. Metodología y Calidad
Se describirá la Metodología seguida por el licitador para el desarrollo de proyectos de estas características.
Adicionalmente se describirán los procedimientos a seguir para el control del proyecto, a fin de detectar posibles desviaciones y tomar las acciones correctivas adecuadas.
9 PROPIEDAD DE LOS PRODUCTOS ENTREGADOS
Todos los estudios y documentos, así como los productos y subproductos elaborados por el suministrador como consecuencia de la ejecución del contrato serán propiedad de Xxxxxxxxxx, quien podrá reproducirlos, publicarlos y divulgarlos, total o parcialmente, sin que pueda oponerse a ello el suministrador autor material de los trabajos.
El suministrador renuncia expresamente a cualquier derecho que sobre los trabajos realizados como consecuencia de la ejecución del contrato pudieran corresponderle, y no podrá hacer ningún uso o divulgación de los estudios y documentos utilizados o elaborados en base a este pliego de condiciones, bien sea en forma total o parcial, directa o extractada, original o reproducida, sin autorización expresa de Osakidetza.
10 CONFIDENCIALIDAD
En consideración al tipo de información procesada, el adjudicatario está obligado a mantener la más absoluta confidencialidad sobre todos aquellos datos y documentos a que tenga acceso con motivo de la adjudicación. A ellos accederán exclusivamente las personas estrictamente imprescindibles para el desarrollo de las tareas inherentes a la misma. Todas ellas serán advertidas del carácter confidencial y reservado de la información a la que tendrán acceso.
Todos los ficheros que se pongan a disposición del adjudicatario para la ejecución del contrato son propiedad de Osakidetza y están registrados y sometidos a la salvaguarda que establece la legislación vigente, en especial la relativa a la protección de datos personales. Toda cesión a terceros será perseguida en los tribunales.
Osakidetza se reserva el derecho de establecer cualquier tipo de marcaje de los ficheros que se dejarán al adjudicatario, de manera que sus características puedan constituirse como prueba que posibilite localizar el origen y los responsables de las eventuales cesiones.
Bajo ningún caso ni circunstancia el adjudicatario podrá suministrar a terceros ni utilizar para sí ni para otros los datos facilitados por Osakidetza para fines distintos a los contemplados en el objeto del presente contrato.
El adjudicatario estará obligado a poner en conocimiento de Osakidetza, inmediatamente después de ser detectada, cualquier sospecha de eventuales errores que se puedan producir en el sistema de seguridad de la información.
El adjudicatario faculta a Osakidetza para que al terminar el proyecto pueda responsabilizarlo y/o repercutirle los costes derivados de posibles reclamaciones ocasionadas por negligencia y/o falta de confidencialidad del mismo.
Adicionalmente y como condición general, todos los servicios prestados deberán contar con las medidas de seguridad y de confidencialidad adecuadas al grado de sensibilidad de la información suministrada, de acuerdo con lo descrito en la LOPD.
11 PRESUPUESTO, PLAZOS Y PENALIZACIONES
11.1 Presupuesto
El presupuesto máximo asignado y los plazos máximos de ejecución para este contrato son los siguientes:
• Presupuesto máximo asignado : 2.400.000€ (sin IVA)
La valoración económica esta expresada en euros, es máxima e incluye la totalidad de los conceptos devengables.
Se deberán detallar claramente los siguientes aspectos:
• Perfiles profesionales propuestos.
• Dedicación horas/perfil.
• Nº de técnicos/perfil.
La suma total de los conceptos anteriormente señalados no podrá exceder del precio de licitación total.
Por otro lado, se prevé una posible ampliación de 400.000€ (sin IVA), para dar cobertura a adaptaciones derivadas de cambios legislativos, migraciones tecnológicas por obsolescencia de productos, implantación no contemplada de infraestructuras y tecnologías y evolutivos urgentes de carácter estratégico, no existentes en el momento de la elaboración de este expediente, por lo que el valor estimado del contrato asciende a 5.200.000€ (SIN IVA).
11.2 Facturación
La facturación será mensual en base a las consideraciones siguientes:
11.2.1 Facturación Base
En este concepto se incluye los siguientes servicios:
• Línea de “Mantenimiento, y Evolución”
o Mantenimiento Correctivo
o Mantenimiento adaptativo/evolutivo a pequeña escala
• Gestión y administración del servicio.
El importe estimado será de un 50% del presupuesto.
El importe a facturar será lineal, si bien Osakidetza se reserva la facultad de modificar la Dimensión Base, y por tanto la facturación, conforme a los criterios que se explican en este Pliego.
11.2.2 Facturación Línea de Desarrollo
En este concepto se incluye la Línea de “Desarrollo”, que abarca el mantenimiento evolutivo a gran escala,
El importe estimado será de un 50% del presupuesto.
El importe a facturar será variable y la cuantía aplicable cada mes se determinará en función del trabajo realizado y los objetivos alcanzados.
11.3 Plazo de ejecución
El plazo de ejecución será de 2 años contados desde la fecha de finalización de la fase de transición descrita en el punto 3.1.1 xxx Xxxxxx de Bases Técnicas, no pudiendo ésta última, tener una duración superior a 2 meses contados desde la fecha de formalización del contrato.
Asimismo, el contrato podrá ser prorrogado según la legislación vigente.
11.4 Penalizaciones
En las reuniones de Control del Servicio y sobre la base de los informes de Nivel de Servicio, se comprobarán las desviaciones respecto a los Niveles de Servicio establecidos, siendo objeto de penalizaciones en los términos que a continuación se establecen, dentro del régimen de servicio regular, y con periodicidad mensual.
La suma de penalizaciones no superará en ningún caso el 15%.
11.4.1 Mantenimiento Correctivo
Tipo Mantenimiento | Rango de desviación | Penalización sobre fijo mensual |
Muy urgente | De 1 al 5% | 1% |
Del 6 al 10% | 2% | |
Superior al 10% | 3% | |
Xxxxxxx | Xx 0 xx 8% | 1% |
Del 9 al 15% | 2% | |
Superior al 15% | 3% | |
Normal | De 1 al 10% | 1% |
Del 10 al 20% | 2% | |
Superior al 20% | 3% |
11.4.2 Mantenimiento Adaptativo y Evolutivo
Tipo Mantenimiento | Rango de desviación | Penalización sobre fijo mensual | |
Adaptativo/ | De 1 al 5 % | 1% | |
Evolutivo | y | ||
Del 6 al 10% | 2% | ||
Nuevas | |||
Superior al 10% | 3% | ||
aplicaciones | |||
12 CRITERIOS DE ADJUDICACIÓN
Para la elección de los criterios de valoración y su ponderación se han tenido en consideración los aspectos más significativos recogidos en el Pliego de Bases Técnicas que se acompaña a este expediente, a fin de garantizar que las ofertas de los licitadores se ajusten a lo exigido para el suministro objeto de este expediente.
De acuerdo con lo antedicho, los criterios que servirán de base para la adjudicación del presente contrato serán los siguientes:
JUICIOS DE VALOR 50
• Planteamiento de la Solución Técnica 30
✓ Descripción del contenido de los trabajos: Descripción de cada
una de las líneas de trabajo y servicios a prestar 20
✓ Medios adscritos para la ejecución del contrato: Descripción detallada del equipo de trabajo, calidad y organización 10
• Gestión del Proyecto 20
✓ Coherencia y contenido del Plan de Trabajo: Plan de trabajo contenido e hitos 10
✓ Control y Seguimiento del proyecto: Descripción detallada de los procedimientos a seguir para el control del proyecto 10
Umbral mínimo de la suma de los 2 criterios anteriores: 25. Se valorarán con carácter previo los criterios de adjudicación en los que se haya establecido un umbral mínimo de puntuación. Las ofertas deberán superar ese umbral para continuar en el proceso selectivo y ser valoradas conforme al resto de los criterios de adjudicación.
FÓRMULA 50
• Precio de la oferta 30
Atendiendo a la tabla que se presenta a continuación, la valoración del precio se realizará de la siguiente forma:
o Se establecen 7 tramos para determinar la puntuación obtenida, según el porcentaje de baja con respecto al importe de licitación, que se calculará de la siguiente forma:
o 1 −
Porcentaje de baja = (Precio ofertado)
(Precio de licitación)
o En cada uno de los tramos, el valor obtenido será el resultante de la interpolación del porcentaje de la Baja entre los valores de dicho tramo, de la siguiente forma:.
▪ Interpolación %baja =
puntos tramo∗ (%baja ofertado–%límite inferior tramo) (%limite superior tramo–%límite inferior tramo)
o Los puntos valorados para cada tramo se sumarán hasta alcanzar el porcentaje de baja presentada.
o La oferta cuyo importe sea igual al importe de licitación se valorará con 0 puntos.
Descripción tramo puntos | Puntos |
Porcentaje de baja de hasta un 5% con respecto al importe de licitación. | 7 |
Porcentaje de baja superior al 5% e igual o inferior al 7,5% con respecto del importe de licitación. | 7 |
Porcentaje de baja superior al 7,5% e igual o inferior al 10 % con respecto del importe de licitación. | 7 |
Porcentaje de baja superior al 10% e igual o inferior al 15% con respecto del importe de licitación. | 3 |
Porcentaje de baja superior al 15% e igual o inferior al 20% con respecto del importe de licitación. | 3 |
Porcentaje de baja superior al 20% e igual o inferior al 25% con respecto del importe de licitación. | 2 |
Porcentaje de baja superior al 25%. Este último tramo se valorará de forma que se darán 1 punto a la oferta más económica, interpolándose las restantes ofertas que se sitúen en este tramo de manera proporcional. | 1 |
Total Puntos | 30 |
• Horas ofertadas 20
Para la valoración de este criterio, se parte del equipo mínimo detallado en capítulo 4, y que se detalla a continuación:
Jefe proyecto | Coord. funcional | Consultor/ Analista Funcional | Analista programador | Programador | TOTAL horas (equipo mínimo) |
3.520 | 10.560 | 12.320 | 14.080 | 10.520 | 51.000 |
Se valorará el número de horas adicionales (mejora) sobre el mínimo exigido para los 2 años del contrato, para los perfiles de:
• Consultor/Analista funcional
• Analista Programador
• Programador
Atendiendo a la siguiente tabla:
Valoración | Consultor/ Analista Funcional | Analista programador | Programador |
Horas: Mínimo exigido (2 años) | 12.320 | 14.080 | 10.520 |
Puntos por mejora (Pmax) | 9 | 6 | 5 |
Mejora de referencia (Mref) | 25% | 35% | 35% |
Y de la siguiente manera para cada perfil ofertado:
o Para ofertas con %Mejora Horas Ofertadas por perfil <= %Mejora Horas de Referencia por perfil (Mof <= Mref):
Puntos perfil = 0,80 * Pmax * (1- (Mref - Mof) / Mref)
o Para ofertas con % Mejora Horas Ofertadas por perfil > %Mejora Horas de Referencia perfil (Mof > Mref):
Puntos perfil = 0,80 * Pmax + 0,20 * Pmax * (Hof/ Maxhof)
La puntuación total de este criterio, se obtendrá de las suma de los puntos obtenidos en cada perfil.
Puntos criterio = Σ Puntos perfil
Mof = % Mejora de Horas Ofertado por perfil
Mof = (Horas perfil ofertadas–Horas perfil mínimo exigido)
(Horas perfil mínimo exigido)
Pmax = Puntuación máxima por perfil (tabla)
Mref = % Mejora horas de Referencia por perfil (tabla)
Hof = Horas Ofertadas por perfil
Maxhof = Máximo horas ofertadas por perfil (mayor volumen horas ofertadas perfil)
13 CONSULTAS AL PLIEGO
Durante el periodo de licitación y ante cualquier necesidad de aclaración sobre cuestiones referidas a las especificaciones recogidas en el presente Pliego de Bases Técnicas, los licitadores deberán remitir por correo electrónico las preguntas e información que consideren necesarias para elaborar la Propuesta Técnica.
Los licitadores podrán dirigir sus consultas o aclaraciones a la dirección de correo electrónico de la Subdirección de Informática y Sistemas de Información:
Los licitadores deberán identificar, a un único responsable de la oferta, que será durante al periodo de licitación, el interlocutor único con Osakidetza para cualquier tipo de consulta o aclaración sobre los términos expuestos en el presente Xxxxxx, no admitiéndose ninguna consulta o aclaración de persona distinta a la señalada.
Así mismo los licitadores para formular sus consultas o aclaraciones deberán cumplimentar la siguiente información:
• Nº. Pregunta
• Capítulo/Apartado
• Página
• Párrafo
• Descripción de la Consulta
14 ANEXO I. RELACIÓN DE APLICACIONES
14.1 Aplicaciones SAP
El núcleo de los Sistemas de Información de Gestión de Osakidetza está constituido por la plataforma SAP. Las aplicaciones SAP objeto del contrato son sólidas, maduras, y altamente basadas en el producto estándar SAP, por lo que necesitan un escaso nivel de mantenimiento correctivo. A continuación se incluye relación de aplicaciones SAP incluidas en este expediente, detallando en la última columna el esfuerzo en horas del equipo de desarrollo destinado a la línea base a lo largo del último año.
ID. | Aplicación SAP | Área | Ámbito funcional | Versión SAP | Componentes SAP | Descripción | TOTAL horas últ. año (línea base) |
A56 | SAP ECC Gestión Financiera / Controlling | ECOFIN | Finanzas | ECC 6.0 | FI / CO | Gestión financiera / controlling: contabilidad, tesorería, centros de coste, beneficio, etc. | 2.880 |
A56 | SAP ECC Gestión de Materiales | ECOFIN | Logística | ECC 6.0 | MM / WM | Gestión de la cadena de suministros: materiales, proveedores, compras, almacenes, etc. | |
A56 | SAP ECC Tramitación de facturas electrónicas | ECOFIN | Finanzas | ECC 6.0 | VIM | Tramitación de facturas electrónicas de proveedores. | |
A56 | SAP ECC Gestión de Ventas y Distribución | ECOFIN | Logística | ECC 6.0 | SD | Gestión de ventas: prestaciones, deudores, facturación a terceros, etc. | |
A56 | SAP ECC Gestión de Mantenimiento | ECOFIN | Mantenimiento | ECC 6.0 | PM | Gestión de mantenimiento preventivo y correctivo: inventario de equipos, gestión de ubicaciones técnicas, planes de mantenimiento, etc. | |
A56 | SAP ECC Gastos de Viaje | ECOFIN | Gastos de Viaje | ECC 6.0 | FI-TV | Gestión de gastos de viaje. | |
A56 | SAP ECC Administración y Gestión de Personal | RRHH | Gestión de empleados | ECC 6.0 | ES-PS-HR | Administración y gestión de personal: actos administrativos, relaciones con terceros (Haciendas Forales, Seguridad Social). | 1.114 |
A56 | SAP ECC Nómina | RRHH | Gestión de empleados | ECC 6.0 | PY-ES | Cálculo de nómina. | |
A56 | SAP ECC Planificación de Turnos | RRHH | Gestión de empleados | ECC 6.0 | PT-SP | Cartelera: gestión de turnos de trabajo. | |
A56 | SAP ECC Gestión de Tiempos | RRHH | Gestión de empleados | ECC 6.0 | PT | Cartelera: gestión del cómputo horario y la retribución Variable. |
ID. | Aplicación SAP | Área | Ámbito funcional | Versión SAP | Componentes SAP | Descripción | TOTAL horas últ. año (línea base) |
A56 | SAP ECC Gestión de Organización | RRHH | Gestión de empleados | ECC 6.0 | ES-PS-HR | Gestión de plantilla y organización de personal. | 807 |
A56 | SAP ECC Normalización Lingüística | RRHH | Euskera | ECC 6.0 | BC-BMT-OM | Gestión del plan de normalización del uso del Euskera. | |
A56 | SAP ECC Vigilancia Salud Laboral | RRHH | Salud Laboral | ECC 6.0 | EHS | Gestión de la salud laboral de los empleados. | |
A56 | SAP ECC Prevención de Riesgos Laborales | RRHH | Prevención de riesgos laborales | ECC 6.0 | EHS-IHS | Gestión de la prevención de riesgos laborales. | |
A56 | SAP ECC Formación | RRHH | Formación | ECC 6.0 | PE | Gestión de la formación continuada. | |
A56 | SAP ECC Selección y Provisión | RRHH | Selección y Provisión | ECC 6.0 | ES-PS-HR | Gestión de Selección y Provisión de candidatos en procesos selectivos. | |
A56 | SAP ECC Contabilidad RRHH | RRHH | Contabilidad RRHH | ECC 6.0 | PY-XX-DT | Contabilidad financiera y gestión de costes de personal. | |
F02 | Portal del empleado | RRHH | Portal del empleado | NW Portal 7.02 | ESS / MSS | Automatización de flujos de información entre el empleado y las Direcciones de Personal. | 685 |
B83 | SAP BI Presupuestación | BW | Finanzas | BW 7.0 | BI-IP | Presupuestación general de Osakidetza para el Departamento de Hacienda y Finanzas del Gobierno Xxxxx | 2.444 |
B83 | SAP BI Reporting Financiero | BW | Finanzas | BW 7.0 | BI | Herramienta de ayuda a la toma de decisiones (cuadro de mando). | |
B83 | SAP BI Reporting RR.HH. | BW | RRHH | BW 7.0 | BI | Herramienta de ayuda a la toma de decisiones (cuadro de mando). | |
B83 | SAP BI Tesorería | BW | Finanzas | BW 7.0 | BI-IP | Estimación general de tesorería de Osakidetza para el Departamento de Hacienda y Finanzas del Gobierno Xxxxx | |
K05 | Catálogo corporativo de materiales | ECOFIN | Logística | NW MDM 7.1 | SRM-MDM Catalog | Catálogo corporativo de materiales con el fin de optimizar el proceso de aprovisionamiento. | 0 |
Notas:
1. El sistema SAP BW es una de las fuentes de la plataforma corporativa de Business Intelligence de Osakidetza, soportada en el producto OBIEE de Oracle. Aunque la construcción de informes en la plataforma OBI queda fuera del alcance del presente expediente, la construcción de los procesos ETL de aprovisionamiento de información para OBI de datos de SAP BW se abordará en el marco del presente contrato.
2. Actualmente el sistema SAP BW está en fase de migración tecnológica a una nueva versión de producto, por lo que la versión del sistema en el momento de la adjudicación del presente expediente previsiblemente será la SAP BW 7.4.
3. Actualmente el portal del empleado está en fase de migración tecnológica a una nueva versión de producto, por lo que la versión del sistema en el momento de la adjudicación del presente expediente previsiblemente será la SAP Enterprise Portal 7.4.
14.2 Aplicaciones NO SAP
Osakidetza dispone de varias aplicaciones NO SAP que complementan ciertas funcionalidades en el ámbito de la gestión.
ID. | Aplicación | Área | Ámbito funcional | Tecnología | Descripción | TOTAL horas últ. año (línea base) |
A36 | Eginbide | ECOFIN | Contratación Administrativa | J2EE+Oracle | Gestión de expedientes de contratación administrativa. | 313 |
A37 | Currículum Vítae | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que sirve como registro corporativo de los distintos méritos formativos y profesionales de los aspirantes o empleados de Osakidetza. | 1.296 |
A52 | Bilbide | ECOFIN | Logística | J2EE+Oracle | Gestión de almacenes periféricos de Atención Primaria. | 4 |
A62 | Listas de contratación 2004 | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona el proceso selectivo de contratación temporal de personal (convocatoria 2004). | 0 |
A63 | Euskera | RRHH | Normalización Lingüística | J2EE+Oracle | Aplicación utilizada para la solicitud de cursos de euskera y perfiles lingüísticos. | 289 |
A86 | Desarrollo Profesional | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona las diferentes convocatorias xx Xxxxxxx Profesional realizadas en Osakidetza. Semiacoplada con Curriculum Vitae, posee baremadora automática de méritos de Curriculum. | 15 |
A89 | Concurso de Traslados 2012 | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona el proceso selectivo de Concurso de Traslados (convocatoria 2012). | 10 |
A99 | OPE 2006 | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona el proceso selectivo de Oferta Pública de Empleo (convocatoria 2006). | 0 |
B01 | Concurso de Traslados 2009 | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona el proceso selectivo de Concurso de Traslados (convocatoria 2009). | 0 |
B17 | Listas de contratación 2008 | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona el proceso selectivo de contratación temporal (convocatoria 2014). | 0 |
B22 | OPE 2008 | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona el proceso selectivo de Oferta Pública de Empleo (convocatoria 2008). | 0 |
B41 | Listas de contratación 2011 | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona el proceso selectivo de contratación temporal (convocatoria 2011). | 0 |
ID. | Aplicación SAP | Área | Ámbito funcional | Tecnología | Descripción | TOTAL horas últ. año (línea base) |
B50 | OPE 2011 | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona el proceso selectivo de Oferta Pública de Empleo (convocatoria 2011). | 0 |
B71 | Listas de contratación 2014 | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona el proceso selectivo de contratación temporal (convocatoria 2014). | 51 |
B72 | Concurso de Traslados 2016 | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona el proceso selectivo de Concurso de Traslados (convocatoria 2016). | 0 |
B73 | OPE 2014-2015 | RRHH | Gestión, Organización y Desarrollo Profesional | J2EE+Oracle | Aplicación que gestiona el proceso selectivo de Oferta Pública de Empleo (convocatoria 2014-2015). | 22 |
J03 | Factura electrónica | ECOFIN | Factura electrónica proveedores | J2EE+Oracle (Producto comercial Techedge) | Portal de factura electrónica de Osakidetza. | 95 |
S20 | Jakinsarea | RRHH | Formación continuada | PHP + Oracle (Moodle 2.4.4) | Portal de formación de Osakidetza. Tiene como finalidad poner a disposición de todos los profesionales, el máximo posible de recursos, herramientas, experiencias, espacios de relación y oportunidades para favorecer el aprendizaje compartido y el intercambio de conocimiento. | 28 |
15 ANEXO II. DIRECTRICES Y ESPECIFICACIONES TÉCNICAS (DET)
Este anexo, DET (Directrices y Especificaciones Técnicas), contiene las Directrices y Especificaciones Técnicas de los Sistemas de Información de Osakidetza en el ámbito TIC.
15.1 Especificaciones para Desarrollo
Este apartado refleja los principales aspectos del diseño técnico de la arquitectura de referencia para aplicaciones web, definida por Osakidetza.
Una arquitectura de referencia es un conjunto de patrones diseñados y probados para ser usados en un contexto específico, en nuestro caso, en los sistemas de misión crítica de Osakidetza. Es una guía de ayuda para ser usada por los arquitectos y desarrolladores, que permite conceptualizar nuevas aplicaciones rápidamente reutilizando un diseño suficientemente probado.
La arquitectura de referencia refleja las decisiones y aspectos técnicos de diseño basados en la experiencia de Osakidetza en el desarrollo, mantenimiento y evolución de aplicaciones web. El principal propósito de la arquitectura de referencia para aplicaciones web es por lo tanto, homogeneizar el desarrollo, despliegue y explotación en producción de las aplicaciones.
En este sentido, la implementación de la arquitectura de referencia aportará los siguientes beneficios perseguidos por Osakidetza:
• Mejorar el rendimiento de las aplicaciones.
• Garantizar la escalabilidad y la tolerancia a fallos.
• Facilitar las integraciones entre sistemas.
• Aprovechar las tecnologías estándares y capacidades proporcionadas por los recursos hardware y software existentes en la organización.
• Reducir el coste del mantenimiento (evolutivo y correctivo) mediante la simplificación del diseño de la solución y la implementación del mismo.
15.2 Arquitectura de Referencia
Una de las características generales de los proyectos con éxito es que existe un diseño previo bien fundamentado que define la arquitectura general del sistema, las soluciones de infraestructura y plataforma (por ejemplo alta disponibilidad, recuperación frente a desastres, copia de seguridad y restauración, monitorización), y realiza un mapeo de requerimientos a elementos de la arquitectura.
Desde el punto de vista de sistemas de información, este requerimiento estratégico debe tener una base de arquitectura y diseño previo que permita cumplirlo durante la evolución del ciclo de vida.
Los principios de la arquitectura de referencia, describen los principios fundamentales que se han considerado para el diseño de dicha arquitectura. Los principios representan los preceptos o reglas básicas que guían el proceso de diseño.
La arquitectura de referencia se describe usando tres vistas diferentes:
• Vista lógica o conceptual, en la que se presenta la arquitectura mediante una visión de alto nivel que permite entender los diferentes componentes que
intervienen y las interacciones existentes entre ellos.
• Vista de implementación, en la que se proporcionan detalles adicionales sobre la tecnología y productos para la construcción de los diferentes componentes.
• Vista de despliegue, en la que se describe de forma pormenorizada la información del sistema relativa a la instalación y explotación que se realiza por entornos.
15.2.1 Vista lógica
El propósito de la vista lógica es permitir un entendimiento de alto nivel de la arquitectura de referencia y de las diferentes capas y componentes en las que está estructurada. También se define la integración con otros sistemas.
Sobre esta vista lógica se deberían plasmar todos los elementos que deben ser considerados cuando se diseña una nueva aplicación.
Las aplicaciones deben de tomar este diseño como referencia e indicar:
• Las capas de la arquitectura de referencia que se implementarán
• Servicios externos con los que interactúa la aplicación
• Clientes que usarán la aplicación
• Servicios de persistencia de datos
En la siguiente figura se muestra la vista lógica de la arquitectura de referencia para aplicaciones web.
Figura 1. Vista lógica de la arquitectura de referencia
15.3 Directrices de Desarrollo
Se contemplan como directrices de desarrollo, las normativas, estándares y recomendaciones para la elaboración de un código fuente homogéneo, estandarizado y de calidad, con el objeto de minimizar las tareas de mantenimiento y la deuda tecnológica.
También se incorporan las especificaciones para la obtención de sistemas de información seguros, con un rendimiento óptimo y adaptado a las necesidades de las tecnologías definidas por las Arquitecturas de Software que se tomarán como referencia en los desarrollos.
A continuación se enumeran algunas de las directrices de desarrollo que deberán cumplir las soluciones desarrolladas para Osakidetza:
15.3.1 Construcción de Aplicaciones por Capas
El principal objetivo de la construcción de aplicaciones por capas, es la separación de la lógica de negocio, de la lógica de diseño. Su principal ventaja, es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sea necesario llevar a cabo algún cambio, sólo se necesita intervenir al nivel requerido.
El ejemplo clásico de este tipo de práctica y el que se contempla a nivel de directriz, es el consistente en separar las aplicaciones en tres capas: Presentación, Negocio y Persistencia.
Por lo tanto, las aplicaciones serán desarrolladas en capas; es decir, se diseñará las aplicaciones separando entre los modelos de datos, la lógica de aplicación, y la interfaz de usuario. Si optamos por esta separación de responsabilidades, podremos compartir totalmente el modelo de datos y sólo tendremos que adaptar la interfaz de usuario.
Por cada capa se consideran una serie de directrices de desarrollo basadas en el modelo de tres capas propuesto por la Arquitectura de Referencia de Osakidetza.
15.3.2 Capa de Presentación
Mediante la capa de presentación se separa la interacción del usuario respecto a la lógica de negocio.
El uso de la arquitectura en tres capas en el desarrollo de aplicaciones, ha favorecido la aparición de tecnologías que facilitan la implantación de esta capa, además de un conjunto de buenas prácticas que mejoran el proceso de su implementación.
Directrices de Desarrollo para la Capa de Presentación:
• Finalidad: Presentar la información al usuario.
La capa de presentación, también llamada "capa de usuario", deberá presentar el sistema al usuario, comunicar la información necesaria y capturar la misma en un proceso que realiza un filtrado para validar los datos respecto al formato. No deberá procesar datos ni tomar decisiones.
Esta capa se comunica únicamente con la capa de negocio. También es
conocida como interfaz gráfica y debe tener la característica de ser "amigable" (comprensible y fácil de usar) para el usuario.
• Modularidad: Controlar la relación entre las vistas.
En una vista sólo debe hacerse referencia a otras vistas relacionadas con su funcionalidad. En ejecución, se recomienda integrar la vista con un sistema xx xxxxxxxxxx, para poder aumentar de esta manera la reusabilidad y el encapsulamiento de funcionalidades.
• Internacionalización y localización: Preparar las aplicaciones para diferentes idiomas y convenciones.
Las aplicaciones estarán preparadas para que puedan adaptarse a diferentes idiomas y convenciones (formatos de fecha, moneda, etc.), sin necesidad de realizar cambios de relevancia en el código.
• Validaciones: Realizar validaciones sobre los datos introducidos por los usuarios.
La vista será la responsable de la validación inicial de los datos introducidos por el usuario. La validación debe ser obligatoria sólo para el caso xx xxxxxx y formato. Nunca deberá realizarse una validación de negocio desde esta capa.
• Catálogo de controles: Elaborar un catálogo con la lista de controles.
Se especificará, si es posible, la función del control, los posibles validadores/conversores que se le puedan asociar, los eventos que pueda lanzar y los atributos que puedan cambiarse para manipular su aspecto externo.
Los controles deberían permitir el tratamiento de componentes y eventos que posibiliten extraer de la vista toda la lógica de interfaz. La consecuencia principal de este enfoque, es que desde la vista nunca se manipularán los controles. El objetivo es que la construcción de la vista sea una tarea totalmente autónoma del resto de componentes de la función de negocio.
• Uso xx xxxxxxxxxx: Facilitar el mantenimiento haciendo uso xx xxxxxxxxxx.
Se debe utilizar un framework xx xxxxxxxxxx (templates) en la capa de presentación, ya que de esta manera se facilita el mantenimiento del diseño de los sistemas de información. Existen frameworks que posibilitan aislar el diseño de la aplicación en un único fichero de plantilla (o más, si se necesitan). Esto facilita la tarea de hacer modificaciones en el diseño.
• Controles de interfaz: Utilizar un identificador único para los controles de interfaz.
Todos los controles de interfaz, deben mantener un identificador único para facilitar su compresión, reutilización y batería de pruebas del mismo.
• Independencia entre capas: Evitar el acoplamiento entre distintas capas.
Cada capa debe tomar la responsabilidad que le corresponde. En este caso, debe evitarse que la capa de presentación realice atribuciones que le correspondan a otras capas.
15.3.3 Capa de Negocio
La capa de negocio expone la lógica necesaria a la capa de presentación para que el usuario, a través de la interfaz, interactúe con las funcionalidades de la aplicación.
Se utilizarán componentes de negocio para abstraer la lógica de negocio de otros problemas generales de las aplicaciones, como la concurrencia, transacciones, persistencia, seguridad, etc…
Directrices de Desarrollo para la Capa de Negocio:
• Reglas de negocio: Implementar las reglas de negocio en esta capa.
Los módulos que requieran una funcionalidad deberán encontrarla en un solo lugar y única versión. No debe haber réplica de funcionalidades en ninguna de las otras capas (Persistencia y/o Presentación)
• Validaciones de datos: Garantizar el valor correcto de los datos.
Esta capa debe garantizar que los datos requeridos para procesarla hayan sido debidamente validados, y sólo se puede iniciar el flujo del proceso de negocio si la validación resultó correcta.
• Comunicación entre capas: Definir la estrategia de comunicación entre capas. La comunicación entre capas se debe establecer mediante objetos del modelo. Se crearán entidades sin métodos, sólo tendrán propiedades, campos y atributos, que nos servirán para almacenar información, como puede ser la asociación de las propiedades a las columnas de la base de datos.
• Transacciones: Tratar convenientemente las transacciones de los datos.
La capa de modelo de datos proporciona los datos al sistema, pero las transacciones que involucren a dichos datos, se deben manejar desde la capa de negocio.
• Excepciones: Encapsular en la capa de negocio las excepciones y trasladarlas de forma correcta a la capa de presentación.
El objetivo es simplificar el manejo de excepciones de la aplicación. Se recomienda tener bien definida una política para el tratamiento de excepciones y disponer de una jerarquía propia de excepciones. Como norma general, las aplicaciones no deberán nunca extender las excepciones del sistema, sino las de su propia jerarquía de clases.
• Servicios encapsulados: Encapsular la capa de negocio en servicios.
Se debe encapsular la capa de negocio en servicios, para de esta forma aislar la base de datos respecto de una interacción directa con el usuario. Estos servicios de negocio conforman un "puente" entre el usuario y los datos. Responden a peticiones de usuarios u otros servicios de negocio aplicando procedimientos formales y reglas de negocio a datos relevantes.
• Acceso a servicios: Controlar el acceso a los servicios en la capa de negocio. El control de acceso al servicio de negocio debe hacerse en la capa de negocio, puesto que podemos tener distintas capas de presentación, como por ejemplo, una capa de presentación web y una capa de presentación Web Services.
El control de acceso puede realizarse tanto a nivel de método, dentro de cada servicio, como a nivel de servicio vertical.
• Inyección de Dependencias: Uso del patrón de diseño ‘Inyección de Dependencias’ (DI), como forma de ‘Inversión de control’ (IoC)
La Inversión de Control (Inversion of Control en inglés, IoC) es un método
de programación en el que el flujo de ejecución de un programa se invierte respecto a los métodos de programación tradicionales. En la Inversión de Control se especifican respuestas deseadas a sucesos o solicitudes de datos concretas, dejando que algún tipo de entidad o arquitectura externa lleve a cabo las acciones de control que se requieran en el orden necesario y para el conjunto de sucesos que tengan que ocurrir. Es el principio subyacente a la técnica de Inyección de Dependencias, siendo términos frecuentemente confundidos.
La Inyección de Dependencias (Dependency Injection en inglés, DI) es un patrón de diseño orientado a objetos, en el que se suministran objetos a una clase en lugar de ser la propia clase quien cree el objeto. La forma habitual de implementar este patrón es mediante un "Contenedor DI" y objetos planos o simples, por ejemplo los llamados POJO. El contenedor inyecta a cada objeto, los objetos necesarios según las relaciones plasmadas en un fichero de configuración. Típicamente este contenedor es implementado por un framework externo a la aplicación.
La implementación de un patrón de diseño como la ‘Inyección de Dependencias’ permite gestionar de una manera eficiente las dependencias entre los diferentes componentes de una aplicación, sin tener que recurrir a un acoplamiento no deseable entre estos.
15.3.4 Capa de Persistencia
La necesidad de vincular los datos guardados en una base de datos relacional, con los objetos de una aplicación orientada a objetos, determina la aparición del concepto de persistencia de objetos. Siguiendo el paradigma de desarrollo en tres capas, la persistencia queda recogida en su propia capa, separada de la lógica de negocio y de la interfaz de usuario.
La persistencia de la información es probablemente la parte más crítica en una aplicación de software y permite ejecutar operaciones en el almacenamiento persistente (base de datos). El modelo de objetos de un sistema, difiere en muchos aspectos del modelo relacional. La interfaz que une esos dos modelos se llama asociación objeto-relacional (ORM en inglés). La capa de persistencia encapsula el comportamiento necesario para mantener los objetos.
Directrices de Desarrollo para la Capa de Persistencia:
• Asociación Objeto-Relacional: Usar un mapeador Objeto Relacional para implementar la capa de persistencia.
Se debe utilizar un mapeador Objeto-Relacional para implementar la capa de persistencia, ya que es una técnica que permite convertir los tipos de datos utilizados en un lenguaje de programación orientado a objetos y los utilizados en una base de datos relacional, lo que posibilita el uso de las características propias de la orientación a objetos.
• Uso del patrón DAO: Crear una clase DAO por cada objeto de negocio del sistema
El patrón CRUD, reconocido como el patrón más importante del acceso a datos, indica que cada objeto debe ser creado en base de datos para que sea persistente. Para esto es necesario asegurar que existen operaciones que permiten a la capa inferior (de acceso a datos) leerlo, actualizarlo o borrarlo.
Mediante la implementación de DAO's pueden proporcionarse las operaciones CRUD necesarias para cada aplicación. No es obligatorio que cada DAO implemente todas las operaciones CRUD (puede no ser necesario en la lógica funcional del sistema). Por lo tanto, se recomienda crear un DAO distinto por cada objeto de negocio en el sistema.
• Manejo de la caché: Usar la caché en las aplicaciones para reducir tiempos de lectura.
Se recomienda utilizar un sistema de caché en las aplicaciones, para reducir tiempos de lectura, ya que la mayoría de accesos de lectura acceden a una pequeña parte de los datos de la aplicación. Normalmente, hay un conjunto de datos que son relevantes a todos los usuarios y que, por lo tanto, son accedidos con más frecuencia.
• Concurrencia de usuarios: Permitir la concurrencia de usuarios.
Se debe permitir que varios usuarios trabajen en la misma base de datos, protegiendo los datos de ser escritos erróneamente. En la mayoría de los casos, se utilizará el bloqueo optimista, soportado por la mayoría de los motores de persistencia como la opción por defecto.
• Referencias circulares entre objetos: Evitar las referencias circulares entre objetos de la capa de persistencia.
Se deben evitar las referencias circulares, facilitando la localización de los objetos. De esta manera, se devuelve el objeto solicitado sin necesidad de realizar un recorrido para localizarlo, lo que supone un acceso más efectivo.
• Actualización en cascada: Utilizar la actualización en cascada siempre que sea posible.
Utilizar la posibilidad que ofrecen algunos frameworks para la actualización en cascada de objetos. Una actualización en cascada permite que las modificaciones hechas a un objeto se repliquen en los objetos relacionados. De esta manera se mejora el mantenimiento de los objetos, se asegura que los cambios introducidos se replican de manera eficiente y se mantiene la integridad de los datos.
.
15.4 Directrices tecnológicas de IOC
Osakidetza dispone de múltiples aplicaciones desarrolladas en diversas tecnologías (principalmente Java y .Net), y albergadas en diferentes plataformas (principalmente Apache HTTP Server, Microsoft IIS y Citrix XenApp como soluciones de presentación, Oracle WebLogic y Microsoft IIS como servidores de aplicación y Oracle RDBMS y Microsoft SQL Server como servidores de BBDD).
El modelo de referencia de las aplicaciones es una solución Web (sin plug-in’s), con arquitectura de n-capas preferentemente 3 capas: presentación, negocio y persistencia, compatible con tecnología de virtualización y almacenamiento SAN y NAS.
Dicha arquitectura es escalable horizontalmente en cuanto a las capas de negocio y persistencia (reparte la carga equitativamente entre los diversos servidores que ejecutan la lógica de negocio y estos a su vez, mediante un pool de conexiones acceden a la capa de persistencia), y es tolerante a fallos garantizando la continuidad de negocio.
Los servidores que atienden a las capas de negocio y persistencia están ubicados en los dos CPDs de la Dirección General de Osakidetza siendo el reparto de los mismos proporcional en un CPD u otro; la capa de presentación está distribuida en los puestos de trabajo fijos, portátiles, móviles y tabletas en los diversos centros de Osakidetza (Hospitales, Centros de salud, etc.).
De modo que la solución (producto/aplicación/desarrollo) a suministrar deberá ser compatible con el modelo de arquitectura indicado en el párrafo anterior y con la relación de productos y tecnologías que se indican a continuación (las que apliquen).
15.4.1 Entorno tecnológico
En conjunto, el entorno tecnológico de las soluciones actualmente en producción es:
• Plataformas de desarrollo:
✓ .NET sobre Windows 2012R2
✓ Java sobre Red Hat Enterprise Linux 7
✓ Aplicaciones móviles:
✓ Node.js, Express, AngularJS, MongoDB sobre Red Hat Enterprise Linux 7
✓ Ionic, Xxxxxxx sobre Android, iOS o WindowsPhone
• Plataforma de virtualización:
✓ VMWare vSphere 5.5
• Almacenamiento:
✓ SAN: EMC VPLEX
✓ NAS Hitachi HUS
• Sistemas Operativos
✓ Servidores:
o Windows 2012 R2
o Red Hat Enterprise Linux 7
✓ Puesto de trabajo fijo: Windows 7 Enterprise N SP1 32 bits
✓ Puesto de trabajo móvil: Android, iOS, WindowsPhone
• Servidores Web:
✓ Apache Webserver 2.4
✓ MS IIS 8.5 (S.O. Windows 2012 R2)
✓ Oracle Web Server 11.1.1.7
✓ Web Dispatcher de SAP Netweaver 7.20
✓ Nginx 1.8.0
• Servidores de Aplicación:
✓ Apache Tomcat 7
✓ Oracle Weblogic Server 12c + JDK 8.0
✓ MS IIS 8.5 + .NET Framework 4.5
✓ Application Server de SAP Netweaver 7.X
✓ Node.js 4.1.0
• Sistemas de Gestión de Bases de Datos
✓ Oracle 12c (RAC)
✓ Microsoft SQL Server 2008R2, SQL Server 2012
✓ MongoDB 2.6
• Gestión de contenidos:
✓ MS SharePoint 2010 Enterprise
✓ EMC Documentum 7.2
• Infraestructura SOA:
✓ Oracle Service Bus 12c (12.2.1) + JDK 8.0
• Plataforma de firma (PKI):
✓ Izenpe
• Autenticación:
✓ Directorio Activo de MS (AD)
✓ Directorio Ligero de MS (LDS)
• Puesto de trabajo fijo:
✓ Navegador: IE 8.0
✓ Office 2010 Standard
✓ Oracle Client 11gR2
✓ Java 1.6.0_23
✓ Framework 3.5 y 4.0
• Modo de ejecución/escritorio:
✓ local: puesto fijo o móvil
✓ remoto: Citrix Xen Desktop 7.6
Consideraciones en relación a los de productos y tecnologías indicados anteriormente:
• En cuanto al navegador, se debe evitar el uso de Applets (Java), componentes ActiveX (.NET), Flash u otras tecnologías que impliquen la descarga y ejecución de software embebido en el navegador.
• Al respecto de Office 2010, no está permitido el uso, dependencia o interrelación con Access.
• A corto/medio plazo Osakidetza evolucionará:
o S.O. de Servidor:
▪ Windows Server 2008 R2 a Windows Server 2012 R2
o S.O. de Puesto de trabajo:
▪ Windows 7 a Windows 10
o Navegador:
▪ IE8 a IE11 nativo preferentemente y Enterprise Mode de IE11 para compatibilidad con IE8.
o Servidor de Aplicaciones:
▪ Weblogic 11g a Oracle Weblogic Server 12c
▪ MS IIS 7.5 a MS IIS 8.5
o SGBD:
▪ Oracle 11g a Oracle 12c
▪ XX XXX Xxxxxx 0000X0 a SQL Server 2012
o Infraestructura SOA:
▪ Oracle Service Bus 11.1.1.7 a 12c (12.2.1)
15.4.2 Dispositivos de entrada/salida
La solución deberá ser capaz de interactuar con diversos dispositivos de entrada y salida de diversos fabricantes; siendo dichos dispositivos: pantallas táctiles, impresoras térmicas, monitores, por tanto el interface con los mismos será en base a
estándares xxx xxxxxxx.
Así mismo la solución deberá adaptarse a la resolución de las diversas pantallas.
En relación a dispositivos móviles se deben tener en cuenta ciertas particularidades en relación a las características de movilidad, tamaño, comunicación inalámbrica e interacción con las personas:
• Son aparatos pequeños.
• La mayoría de estos aparatos se pueden transportar en el bolsillo del propietario o en un pequeño bolso.
• Tienen capacidad de procesamiento.
• Tienen conexión permanente o intermitente a una red.
• Tienen memoria (RAM, tarjetas MicroSD, flash, etc.).
• Normalmente se asocian al uso individual de una persona, tanto en posesión como en operación, de modo que puede adaptarlos a su gusto.
• Tienen una alta capacidad de interacción mediante la pantalla o el teclado.
En lo que se refiere a dispositivos sobre los que tienen que ejecutar soluciones de movilidad hay dos ámbitos que son las soluciones orientadas a profesionales de Osakidetza y soluciones orientadas al ciudadano.
Las aplicaciones orientadas al ciudadano se ejecutarán en dispositivos de consumo ya sean móviles, tabletas o cualquier otro dispositivo al que vaya destinada la solución. En este caso el desarrollo deberá ejecutarse en dispositivos con los diferentes sistemas operativos que haya en el mercado.
En las aplicaciones orientadas a los profesionales de Osakidetza deberán de ejecutarse en el dispositivo elegido y homologado para soportar la solución. Habrá que tener en cuenta los siguientes aspectos:
• Ergonomía, tamaño y usabilidad del dispositivo, se refiere a que cumpla las expectativas del usuario en ámbito en el que se va a desarrollar el proyecto.
• Especificaciones de limpieza y resistencia a los golpes.
• Características de comunicaciones como pueden ser conectividad Wifi y 4G.
15.4.3 Seguridad, acceso, autenticación y autorización
El tratamiento de los datos cumplirá lo establecido por la legislación vigente en materia de seguridad y protección de datos.
En el ámbito intranet se permitirá el acceso mediante los transportes RMI, JMS, HTTP y HTTPS.
El proveedor de servicios de certificación de Osakidetza es Izenpe.
Osakidetza ha dotado a todos sus profesionales de certificados corporativos reconocidos, en soporte tarjeta criptográfica, con capacidad de firma de documentos y mails, cifrado y autenticación en el AD.
Además, para los nuevos SI que necesitan firma electrónica ágil, Osakidetza ha implantado una solución horizontal de firma, basada en certificados alojados en HSMs, llamada “firma centralizada”. Son certificados con las mismas características y garantías que los alojados en tarjeta criptográfica. Estos HSM son de última
generación y cumplen con las más exigentes normas internacionales (FIPS 140-2 Level 2 and Level 3, Common Criteria at EAL 4+ y RoHS compliant). Permiten la firma a través de CSP propio (applets) y la firma directa basada en una Pasarela de firma propietaria.
Izenpe es también el proveedor de la infraestructura de autenticación, validación y firma basada en certificados electrónicos. Osakidetza dispone de 2 Zain en HA (equipos TrustedX de Safelayer) en propiedad y su backup, en modo servicio, en los Zain de Izenpe. La integración con estos equipos se puede realizar mediante su librería Smartwrapper. Provee diferentes servicios web (validación, evolución de firmas, firma en servidor, etc.) alojados en los OSB de Osakidetza.
Así mismo, Osakidetza dispone de su propia infraestructura de Custodia de documentos firmados, para asegurar la validación de cualquier firma realizada en sus sistemas de información con certificados electrónicos. Está constituida por 2 equipos Siaval en HA, de la empresa SIA, y HSM Ncipher propios.
Para la firma electrónica de documentos in-situ por parte de sus pacientes, Osakidetza dispone de una solución denominada “firma biométrica”, que asegura la validez de todas las firmas implicadas. Se apoya en la solución SmartAccess de Telefónica.
Osakidetza está inmerso en la adecuación de toda su infraestructura y sistemas de información al reglamento europeo eIDAS. Tanto en cuestión de certificados como de niveles de aseguramiento (autenticación).
Los sistemas de autenticación validos son:
• Autenticación basada en Directorio Activo (Microsoft Active Directory) corporativo, que permite identificar un empleado de Osakidetza mediante usuario/contraseña o la tarjeta profesional.
• Token de Kerberos, que habrá sido emitido por el Directorio Activo corporativo.
• Autenticación basada en infraestructura de certificación digital (PKI). Esta autenticación permite la identificación de personas (certificados personales) o de sistemas de información (certificados de servidor)
• Certificados X.509 de servidor, que permitirán identificar sistemas (máquinas) y establecer confianza entre ellas.
• Certificados X.509 de cliente, que permitirán identificar individuos (personas)
• Para los servicios web, el estándar WS-Security permitirá aplicar políticas de autenticación.
• El bus de servicios sólo se utilizará para la autenticación basada en certificados X.509 de servidor.
El sistema de autorización se implementará por medio de la definición de roles de usuario en base a los cuales se gestionarán los permisos y acciones sobre los distintos procesos por los que estará compuesta la solución. De modo que cada usuario en función del rol que tenga asignado podrá acceder a una serie de funcionalidades, así como a los datos relativos a su organización de servicio, centro de trabajo, servicio/área de atención.
Se crearán grupos de autorización del Directorio Activo. Por cada perfil que tenga la aplicación (medico, enfermera, administrativo, administrador de la aplicación,…) se creará un grupo de autorización en el DA. Se mapeará el perfil al grupo.
15.4.4 Monitorización
Osakidetza dispone de una plataforma de monitorización a través de la cual ya tiene establecida una línea de monitorización base de su infraestructura y SI.
En este sentido la solución deberá incluir un apartado en el que se describan los elementos a monitorizar para asegurar un correcto funcionamiento del sistema, servicio o producto suministrado de forma integral dentro de la mencionada plataforma de monitorización.
La monitorización se podrá llevar a cabo a través de alguna combinación de los siguientes productos o métodos que Osakidetza integra dentro de su plataforma de monitorización:
• SCOM mediante Management Pack para sistemas Microsoft
• Instalación de agente de CA Wily Introscope para tecnología Web
• Instalación de agente de Pandora FMS para sistemas Linux, Unix
• Enterprise Manager Cloud Control para SGBD Oracle
• Mensajes SNMP
• Activación de log’s que se enviarán a un servidor virtual dedicado
Con el objetivo de monitorizar la solución que vaya a ser suministrada, deberán detallarse los objetos concretos a monitorizar para garantizar su correcto funcionamiento más allá de los aspectos generales de la infraestructura de sistemas que los alberguen; dicha relación de objetos podrá incluir, aunque no exclusivamente, algunos como:
• Procesos en ejecución
• Puertos de comunicaciones a la escucha
• Eventos concretos en registros del sistema
• Unidades de disco o File Systems
Para cada uno de ellos deberán incluirse los umbrales de consumo que se consideren anormales, especificándose 2 valores a partir de los cuales establecer el correspondiente nivel de alerta preventiva o alerta crítica según proceda.
Adicionalmente podrán suministrarse scripts o procesos para llevar a cabo:
• Pruebas sintéticas de los sistemas cuyo resultado determine el correcto funcionamiento del sistema o el correspondiente nivel de alerta preventiva
• Operativas sobre el sistema que puedan ayudar a determinar o especificar la condiciones concretas de los errores o alertas producidos.
• Operativas sobre el sistema para intentar remediar automáticamente la condición de la alerta o error, como reinicio de procesos o servicios, etc.
Todos estos procesos deberán entregarse con su correspondiente documentación, y su operativa deberá resultar sencilla de modo que pueda ser realizada por un operador.
15.4.5 Backup/Restore
Osakidetza dispone de una infraestructura para la realización de copias de seguridad y restauración a través de red basada en Veritas Netbackup.
De modo que la solución deberá especificar los procedimientos necesarios a llevar a cabo para la recuperación del servicio ante la pérdida del mismo, corrupción de sus datos o alguno de sus componentes. En este sentido se plantearán escenarios de recuperación independientes para cada uno de los posibles componentes impactados y el orden de ejecución en caso de que deban ejecutarse secuencialmente para la
recuperación de varios componentes o del sistema completo en su conjunto.
A partir de los procedimientos anteriormente descritos y en cada uno de ellos, se inferirá los elementos concretos sobre los que se requiere hacer Backup, en qué orden, con qué frecuencia y política de persistencia deben llevarse a cabo para poder satisfacer los distintos escenarios de recuperación del servicio contemplados. Así mismo deberán indicarse las restricciones que pudieran existir para la realización del Backup: posible impacto en el servicio, restricciones horarias, etc.
Los distintos procedimientos de recuperación suministrados con la solución deberán ser validados por Osakidetza para garantizar su compatibilidad con la infraestructura de copia de seguridad y restauración existente.
15.5 Interoperabilidad
Los requisitos de integración de diversos sistemas de información de Osakidetza se realizaran de acuerdo a una arquitectura orientada a servicios (SOA) sobre la plataforma Oracle SOA Suite (Oracle BPEL Process Manager, Oracle Service Bus (OSB), Oracle Business Rules, ...).
Dicha arquitectura proporciona una forma bien definida de exposición e invocación de Servicios Web, lo cual facilita la interacción entre diferentes sistemas propios o de terceros.
Sobre la misma arquitectura SOA, Osakidetza implementa una solución de integración orientada a Eventos; es un diseño a medida que gestiona un conjunto de sistemas que publican eventos y un conjunto de aplicaciones que se suscriben a determinados eventos. Dicha solución se denomina Gestor de Eventos-Event Manager y es responsable de recibir los eventos publicados, ejecutar las validaciones adecuadas, enrutar y almacenar los eventos para su envío a los subscriptores que estén asociados a cada uno de los elementos recibidos.
Relación de estándares de comunicación soportados:
• Protocolos a nivel de mensaje:
o SOAP 1.1 y SOAP 1.2
o WSDL 1.1 y WSDL 1.2 Binding
o SOAP con Attachments
o JSON – REST (para aplicaciones móviles)
• Protocolos de seguridad a nivel de mensaje:
o WS-Security 1.0/1.1
o WS-SecurityPolicy
o WS-Policy
o WSPolicyAttachment
o WS-Security: Username Token Profile 1.0/1.1
o WS-Security: X.509 Token Profile 1.0/1.1
o WSSecurity: XXXX Xxxxx Profile 1.0/1.1
o WS-Security: KerberosToken Profile 1.1
o WS-Reliable Messaging 1.0
o WS-Addressing
o WS-I Basic Profile 1.1
o WSSecurity: JWT Token (aplicaciones móviles en internet)
• Protocolos a nivel de transporte:
o HTTP 1.0, HTTP 1.1
o TLS, SSL
o Interoperabilidad con registros UDDI v3-compliant
o Sistemas middleware basados en JMS/MQ
o HTTPS
15.5.1 Servicios Web
Los Servicios Web se implementarán de acuerdo con las especificaciones WSDL v1.1, SOAP v1.1, v1.2, JSON-REST (en el caso de aplicaciones móviles), UDDI v2.XX y XML v1.0, con el objetivo de incorporar las recomendaciones de la WS-I definidas en la especificación Basic Profile v1.0, v2.0 y de esta manera asegurar la interoperabilidad entre los sistemas.
El estándar de codificación que se utiliza en los mensajes XML es UTF-8. La seguridad aplicada a los servicios web cubrirán los siguientes aspectos:
• Autenticación: Verificar que el cliente (usuario o aplicación) es quien dice ser. La identidad de un usuario se realizará en base a la información presentada por el usuario (usuario/contraseña, certificado, token SAML)
• Autorización: Xxxxxxx acceso a los servicios en base a la identidad del cliente o a los roles asignados.
• Confidencialidad, privacidad: Mantener la información secreta mediante el uso de algoritmos de encriptación estándar de elementos XML.
• Integridad, no repudio: Asegurar que un mensaje permanece inalterado durante la transmisión mediante la firma digital. La firma también valida la identidad del remitente y proporciona una marca de tiempo para garantizar que una transacción no puede ser repudiada más tarde ni por el remitente ni por el destinatario.
Osakidetza usa Oracle Web Service Manager (OWSM) para gestionar y aplicar políticas a los servicios web publicados en la plataforma SOA.
La política estándar que Osakidetza ha definido para los servicios proporciona:
• Autenticación mediante certificado x509
• Protección del mensaje mediante firma (sin encriptado)
Existen dos versiones de la política en OWSM, una para servicios y otra para clientes. Para garantizar la interoperabilidad, cada política tiene su versión compatible con tecnología .NET y Java.
• oracle_wss10_x509_token_with_message_sign_service_policy
• oracle_wss10_x509_token_with_message_sign_service_policy_net
• oracle_wss10_x509_token_with_message_sign_client_policy
• oracle_wss10_x509_token_with_message_sign_client_policy_net
• oracle_http_jwt_token_server_policy
Los clientes y aplicaciones que acceden a través de internet entran a la DMZ a través del firewall de aplicaciones (WAF). El WAF aplica reglas contra ataques y define patrones de seguridad.
• Es responsabilidad de cada aplicación publicada en la DMZ controlar el acceso y autorizar a los usuarios.
• El OSB de internet publica los servicios a los que pueden acceder las aplicaciones de internet.
• El OSB de internet audita todas las llamadas a los Servicios Web mediante una política propietaria de Osakidetza gestionada por OWSM.
• En el OSB de internet se protegen todos los servicios con la política oracle_wss10_x509_token_with_message_sign_service_policy. Esta política autentica a las aplicaciones mediante certificado x509 y firma el mensaje de petición y respuesta.
• El OSB de internet delega la ejecución a servicios publicados en la Intranet.
• En la intranet, se despliegan instancias independientes de servicios web para dar servicio a las peticiones que llegan desde el OSB de Internet.
• Entre el OSB de intranet y el OSB de intranet, se realiza una federación de servicios con las condiciones de seguridad habituales.
Nota: OSB -> Oracle Service Bus 11.1.1.7 -> Paso a OSB 12c
Así mismo, Osakidetza utiliza SAP PI (SAP (SAP NetWeaver Process Integration 7.3 EHP 1) como bus de integración complementario al OSB para las integraciones con el sistema SAP ECC.
15.5.2 Gestor de Eventos
A continuación se describen los requisitos técnicos que tienen que cumplir las aplicaciones para publicar y/o recibir eventos.
15.5.2.1 Estándares de comunicación
La mensajería del Servicio Osakidetza se implementará de acuerdo con las especificaciones del estándar HL7 versión 2.XX o con cualquier otro formato propio de Osakidetza; de esta manera se asegura la interoperabilidad entre los sistemas de información.
A continuación se presenta la relación de tecnologías soportadas para la publicación y subscripción a eventos, así como si la modalidad soporta transaccionabilidad y las opciones de seguridad disponibles:
Modalidad | Tecnología | Transaccional | Orden | Seguridad |
Publicación Mensajería JMS | Sí | Sí, si el publicador establece el parámetro UnitOfOrder | Autenticación (user/pass) | |
Publicación | Servicio web | No | No | Ninguna, Autenticación (user/pass) y WS-Security |
Subscripción Mensajería JMS | Sí | Sí. Event Manager garantiza la entrega en el mismo orden que ha | Autenticación (user/pass) | |
recibido los mensajes | ||||
Subscripción | Servicio OSB | Sí | Sí. Event Manager garantiza la entrega en el mismo orden que ha recibido los mensajes | Ninguna |
Subscripción | Servicio web | Sí | Sí. Event Manager garantiza la entrega en el mismo orden que ha | Ninguna, Autenticación (user/pass) y WS-Security |
recibido los mensajes |
Por cada modalidad y tecnología se deben cumplir unos requisitos técnicos que serán indicados al adjudicatario para la implementación de esta forma de integración.
15.5.2.2 Mensajería. Definición de Evento
Un evento es un documento XML definido mediante un XSD, donde:
• id: Es el identificador del tipo de evento. Se genera durante el proceso de alta del evento en el sistema de administración de Event Manager. Durante el procesamiento de un evento se verifica que el id sea válido.
• correlation: Es un campo libre en el que el publicador del evento indica un número correlativo relativo a su sistema.
• source: Es el identificador del publicador. Se genera durante el proceso de alta de un publicador en el sistema de administración de Event Manager. Durante el procesamiento de un evento se verifica que el source sea válido.
• timestamp: Lo establece el publicador del evento en el momento del envío.
• metadata: Puede contener un xml que ayude a describir el contenido del evento. Event Manager puede utilizar esta información para tomar decisiones de enrutado.
• payload: Es el contenido del evento. Puede ser cualquier cadena de texto o XML.
El resultado devuelto cuando se publica un evento en Event Manager es un XML definido por un XSD, donde:
• uuid: Es un identificador único que se asigna a cada evento procesado por Event Manager.
• processed: true o false, si el evento se ha procesado correctamente o con errores.
• errorCode: Si se ha producido un error, aqui se informa el código del error.
• errorDescription: Si se ha producido un error contiene la descripción de éste.
Se realiza gestión de errores: codificación de errores y descripción de los mismos.
15.6 Explotación Información - Business Intelligence
La herramienta usada para desarrollo de tecnología Business Intelligence es Oracle Business Intelligence Enterprise Edition (OBIEE).
Esta herramienta es una herramienta web, que está soportada por una cada de presentación en Apache, y un servidor Web (Weblogic). En esta capo web de Weblogic se definen los ROLES de usuario (grupos y perfiles de usuario) que luego se usan para la Seguridad de Acceso a Datos y a partes de la aplicación
En este servidor también se alberga el RPD, que es donde se desarrolla toda la metadata y las distintas Áreas accesibles por usuarios.
Todos los datos accesibles desde OBI están almacenados en una única BBDD de Producción.
Para realizar la carga de datos (Incremental), utilizamos la herramienta de extracción (ETL) en ODI.
Para poder realizar las cargas incrementales necesitamos que los orígenes de datos tengan alguna fecha o característica que indique que el dato se ha modificado el día anterior, y así poder hacer cargas de sólo aquello que no existe en destino o se ha modificado. (Un LAST_MODIFIED por ejemplo). Las cargas son normalmente diarias, aunque existen cargas anuales o trimestrales.
Versiones utilizadas:
• Motor Business Intelligence
o Oracle Business Intelligence 11.1.1.6.2
• Servidor Web
o WebLogic Server: 10.3.5.0
• BBDD (Exadata)
o Exadata: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
• ETL
o ODI -> Oracle Data Integrator 11g Build ODI_11.1.1.7.0 GENERIC_130302.2156
15.7 Sistemas SAP
Los sistemas SAP que tiene implantados Osakidetza son:
• SAP ERP Central Component 6.0 EHP 5.
o ABAP.
o NetWeaver Java 7.0. Adobe Document Server.
o Linux, Oracle 11.
• SAP NetWeaver Business Warehouse 7.0.
o En fase de migración a SAP BW 7.4.
o Linux, Oracle 11.
• SAP Enterprise Portal 7.0 EHP 2.
o En fase de migración a SAP Enterprise Portal 7.4.
o Linux, Oracle 11.
• SAP NetWeaver Process Integration 7.3 EHP 1.
o Linux, Oracle 11.
• SAP MDM 7.1 SP8
o Linux, Oracle 11.
• SAP Solution Manager 7.0 EHP1
o Linux, Oracle 11.
Por cada sistema Osakidetza dispone de tres entornos diferenciados:
• Desarrollo.
• Integración.
• Producción.
Indicar además que existen una serie de soluciones integradas de forma nativa con los sistemas SAP mencionados, y que se detallan a continuación:
• ARCHIVE LINK.
Solución de archivado SAP.
• TOPCALL
Sistema de fax corporativo.
• EDICOM
Solución de comercio electrónico de empresa a empresa.
15.8 Alineamiento con las Directrices Tecnológicas
Para verificar que una solución (producto/aplicación/desarrollo) está alineada tecnológicamente con las directrices anteriormente indicadas, se debe entregar la siguiente documentación:
• Procesos de negocio.
• Flujo de información entre los diferentes componentes de la solución.
• Documentación Técnica de la solución
Debe incluir la arquitectura de la solución especificando los componentes lógicos y físicos de la misma, así como el diagrama de capas lógicas y su distribución en la infraestructura, los productos software y/o hardware requeridos, protocolos utilizados, necesidades de comunicación (apertura de puertos, balanceadores, …), etc.
• Especificaciones hardware y software necesarias para la implantación de la solución, acorde al uso (usuarios, concurrencia, disponibilidad, volumetría/almacenamiento, ...)
Cada entregable deberá figurar en un documento, según el orden y títulos indicados en la relación anterior.
16 ANEXO III. ESPECIFICACIONES DEL CLIENTE (MAQUETA)
Actualmente, la versión de maqueta que se instala en los equipos de Osakidetza es la
2.6; aunque convive con versiones anteriores instaladas.
• Hardware:
o Procesador con un mínimo de Tecnología de 45 nm, Caché L2 de 3 Mb. y FSB de 1.066 Mhz.
o Memoria RAM 2 Gb
o Disco duro 250 Gb
o Monitor 19 pulgadas con resolución 1440x900 mayoritaria o 1280x1024.
• Sistema Operativo
o Windows 7 Enterprise N (32 Bit) SP1 + Windows Media Feature Pack
17 ANEXO IV. CUESTIONARIO DE PERSONAL
Este formulario se deberá cumplimentar por cada profesional propuesto:
Empresa licitante: | |||||||||
Profesional: | |||||||||
Categoría ofertada: | |||||||||
Antigüedad | Empresa | Categoría | F. Alta | F. Baja | Actividad Informática | ||||
Titulación Académica | Título académico | Centro | Años | Fecha Expedición | TIC S/N | ||||
Actividades desarrolladas | Nombre proyecto | Perfil (*1) | F. Inicio | F. Fin | Categoría | Entidad Usuaria | Funcionalidad (*2) | Tecnología (*2) | Contenido del Trabajo |
(*1) En un mismo proyecto, puede haber trabajado en diferentes perfiles.
(*2) Funcionalidad y Tecnología se refiere a los módulos funcionales y tecnologías con los que ha trabajado por cada proyecto.
Página 65/65