Adquisición e Implantación de un Sistema para la Gestión y ... · SAP Volumen usuarios SAP ECC...

Planificación de Turnos_2016-2018 Página 1/71

Adquisición e Implantación de un Sistema para la

Gestión y Planificación de Turnos de personal

en Osakidetza


Índice Página

1 INTRODUCCIÓN ............................................................................................................... 5

2 SITUACIÓN ACTUAL ........................................................................................................ 7

3 OBJETO DEL CONTRATO ............................................................................................... 9

4 REQUISITOS FUNCIONALES DE LA SOLUCIÓN ..................................................... 11

4.1 Estructura básica y Configuración del Sistema .................................................... 11

4.2 Gestión ...................................................................................................................... 12

4.3 Planificación ............................................................................................................. 12

5 REQUISITOS TÉCNICOS DE LA SOLUCIÓN ............................................................. 14

5.1 Alcance técnico de la solución ................................................................................. 14

5.2 Entornos .................................................................................................................... 14

6 LÍNEAS DE TRABAJO .................................................................................................... 16

6.1 Consultoría ............................................................................................................... 16

6.2 Integración con los S.I. Corporativos ..................................................................... 16

6.3 Formación ................................................................................................................. 16

6.4 Implantación ............................................................................................................ 17

7 MANTENIMIENTO POST-IMPLANTACIÓN ............................................................... 19

7.1 Mantenimiento integral ........................................................................................... 19

7.2 Soporte de hot-line ................................................................................................... 19 7.2.1 Asistencia en el centro – acceso remoto ............................................................................. 20 7.2.2 Tiempos de respuesta .......................................................................................................... 20

8 PRODUCTOS A OBTENER ............................................................................................. 22

9 PLANIFICACIÓN DEL PROYECTO.............................................................................. 23

10 EQUIPO DE TRABAJO ................................................................................................... 24

11 CONTENIDO DE LAS OFERTAS .................................................................................. 25

12 PROPIEDAD DE LOS PRODUCTOS ............................................................................. 27

13 CONFIDENCIALIDAD .................................................................................................... 28

14 PRESUPUESTO, PLAZOS Y FORMA DE PAGO ......................................................... 29

14.1 Presupuesto .............................................................................................................. 29

14.2 Plazos ........................................................................................................................ 29

14.3 Forma de pago .......................................................................................................... 29

15 CRITERIOS DE ADJUDICACIÓN ................................................................................. 30

16 CONSULTAS AL PLIEGO ............................................................................................... 32

17 ANEXO I: DIRECTRICES Y ESPECIFICACIONES TÉCNICAS (DET).................... 33

17.1 Especificaciones para Desarrollo ............................................................................ 33

17.2 Arquitectura de Referencia ..................................................................................... 33 17.2.1 Vista lógica .................................................................................................................... 34

17.3 Directrices de Desarrollo ......................................................................................... 35


17.3.1 Construcción de Aplicaciones por Capas ....................................................................... 35 17.3.2 Capa de Presentación ..................................................................................................... 35 17.3.3 Capa de Negocio ............................................................................................................ 36 17.3.4 Capa de Persistencia ...................................................................................................... 38

17.4 Directrices tecnológicas de IOC .............................................................................. 39 17.4.1 Entorno tecnológico ....................................................................................................... 40 17.4.2 Dispositivos de entrada/salida ........................................................................................ 41 17.4.3 Seguridad, acceso, autenticación y autorización ............................................................ 42 17.4.4 Monitorización ............................................................................................................... 44 17.4.5 Backup/Restore .............................................................................................................. 44

17.5 Interoperabilidad ..................................................................................................... 45 17.5.1 Servicios Web ................................................................................................................ 46 17.5.2 Gestor de Eventos .......................................................................................................... 47

17.6 Explotación Información- Business Intelligence ................................................... 49

17.7 Alineamiento con las Directrices Tecnológicas ..................................................... 49

18 ANEXO II: ESPECIFICACIONES DEL CLIENTE (MAQUETA) ............................... 50

19 ANEXO III: CUESTIONARIO DE ESPECIFICACIONES TÉCNICAS (CET) .......... 51

19.1 Arquitectura y Tecnología ...................................................................................... 51 19.1.1 Tecnologías de desarrollo .............................................................................................. 51 19.1.2 Frameworks ................................................................................................................... 51 19.1.3 Arquitectura de Software ............................................................................................... 52 19.1.4 Tecnologías de virtualización ........................................................................................ 52 19.1.5 Sistemas Operativos ....................................................................................................... 52 19.1.6 Servidores Web y de Aplicación .................................................................................... 52 19.1.7 Sistemas de Gestión de Base de Datos (SGBD) ............................................................ 53 19.1.8 Appliances y otros componentes hardware .................................................................... 54

19.2 Capa de Presentación .............................................................................................. 54 19.2.1 Modelo de Cliente .......................................................................................................... 54 19.2.2 Equipo de trabajo del usuario final ................................................................................ 54 19.2.3 Modo de ejecución ......................................................................................................... 54 19.2.4 Requisitos en el equipo de trabajo del usuario final....................................................... 54 19.2.5 Cliente Rico (RIA- Rich User Interface) ....................................................................... 55 19.2.6 Sistema de Plantillas ...................................................................................................... 56 19.2.7 Librerías de JavaScript ................................................................................................... 56

19.3 Capa de Negocio ....................................................................................................... 56 19.3.1 Tecnologías para la comunicación entre capas .............................................................. 56 19.3.2 Transacciones ................................................................................................................ 57 19.3.3 Escalabilidad .................................................................................................................. 57 19.3.4 Requisitos de almacenamiento ....................................................................................... 57

19.4 Capa de Persistencia ................................................................................................ 58 19.4.1 Método de Acceso a Base de Datos ............................................................................... 58 19.4.2 Tecnologías para la implementación de Persistencia ..................................................... 58 19.4.3 Gestión de Caché ........................................................................................................... 58

19.5 Elementos de Interfaz de usuario ........................................................................... 59 19.5.1 Dispositivos ................................................................................................................... 59 19.5.2 Tamaños ......................................................................................................................... 59 19.5.3 Resoluciones .................................................................................................................. 59 19.5.4 Navegadores .................................................................................................................. 59 19.5.5 Internacionalización y Localización .............................................................................. 60 19.5.6 Accesibilidad ................................................................................................................. 60 19.5.7 Usabilidad ...................................................................................................................... 60

19.6 Seguridad, acceso, autenticación y autorización ................................................... 60

19.6.1 Ámbito de uso ................................................................................................................ 60


19.6.2 Protocolos de Acceso ..................................................................................................... 61 19.6.3 Autenticación ................................................................................................................. 61 19.6.4 Autorización .................................................................................................................. 61 19.6.5 Firma electrónica ........................................................................................................... 61 19.6.6 Legislación en materia de seguridad .............................................................................. 61

19.7 Interoperabilidad ..................................................................................................... 62 19.7.1 Servicios Web ................................................................................................................ 62 19.7.2 Eventos .......................................................................................................................... 62 19.7.3 Servicios en la Nube (Cloud) ......................................................................................... 63

19.8 Mantenimiento y Operación ................................................................................... 63 19.8.1 Retrocompatibilidad ....................................................................................................... 63 19.8.2 Gestión de versiones ...................................................................................................... 64 19.8.3 Distribución en dispositivos móviles ............................................................................. 64 19.8.4 Acceso e interacción en dispositivos móviles ................................................................ 64 19.8.5 Impresión ....................................................................................................................... 65 19.8.6 Gestión de Errores ......................................................................................................... 65 19.8.7 Logs y Trazas ................................................................................................................. 65 19.8.8 Monitorización ............................................................................................................... 66 19.8.9 Backup y Restore ........................................................................................................... 66

19.9 Directrices de Desarrollo ......................................................................................... 67 19.9.1 Gestión y Versionado del Código Fuente ...................................................................... 67 19.9.2 Librerías y Ficheros de Configuración ........................................................................... 67 19.9.3 Gestión de Dependencias ............................................................................................... 68 19.9.4 Versionado de Binarios .................................................................................................. 68 19.9.5 Gestión de la Configuración y los Activos .................................................................... 68 19.9.6 Integración Continua ...................................................................................................... 69 19.9.7 Documentación .............................................................................................................. 69 19.9.8 Automatización de Pruebas ............................................................................................ 70

19.10 Diagrama de Arquitectura ...................................................................................... 71


1 INTRODUCCIÓN En el ámbito hospitalario, la gestión y planificación de turnos es un proceso clave debido al impacto que tiene sobre la masa salarial a través de la gestión de la capacidad y la bolsa de trabajo. La planificación de los turnos a su vez, puede convertirse en un ejercicio de gran dificultad cuando la organización no dispone de las herramientas adecuadas. El reto de Osakidetza es avanzar hacia modelos más eficientes y optimizados en la gestión de los colectivos sujetos a turnos , y en particular dentro del ámbito de enfermería y auxiliares de enfermería. El objetivo último de la transformación de la gestión y planificación de turnos se centra en realizar una gestión más eficiente de los recursos humanos a la vez que se mejora la calidad de la asistencia. Esto es posible por el hecho de automatizar tareas manuales, mecanizar procesos y liberar el tiempo dedicado por profesionales sanitarios altamente cualificados a tareas administrativas para centrarlo fundamentalmente en actividades asistenciales y desarrollo profesional. Los beneficios que se derivan de abordar la transformación con el soporte de la analítica avanzada, permitirán a Osakidetza mejorar en tres dimensiones del negocio que son interdependientes:

• Reducción de costes y mejora de la eficiencia : Osakidetza podrá optimizar la asignación de turnos y visibilidad de recursos humanos, en beneficio de una mejor gestión de la capacidad productiva, mayor flexibilidad en la adaptación a la demanda, mayor velocidad en la respuesta ante acontecimientos del día a día, mayor previsión, anticipación y eficiencia.

• Mayor tiempo dedicado a la atención : Las actividades de gestión y planificación de turnos descansan en gran medida sobre los profesionales responsables de la supervisión de las unidades. Estos profesionales tienen gran experiencia asistencial, y sin embargo, a la hora de ejercer el rol de supervisión dedican gran parte de su jornada laboral a cuadrar horas, contratos, suplir bajas, incidencias y en definitiva a realizar tareas administrativas en lugar de enfocar su día a día a la supervisión de las actividades asistenciales y a la discusión de casos clínicos. Está demostrado que las soluciones analíticas y de soporte avanzado a la decisión permiten liberar estas tareas en gran medida, y como consecuencia, enfocar a estos profesionales a las tareas de verdadero valor añadido para la organización.

• Mejor gestión de los equipos humanos , que reduce el riesgo y aumenta la seguridad. Una solución avanzada de gestión y planificación de turnos permite realizar asignaciones sobre la base a reglas complejas y por lo tanto permite tener en cuenta las capacidades y formación de los profesionales a la hora de realizar la asignación de turnos. A su vez, estas soluciones son muy bien valoradas por los propios profesionales dado que incrementan la transparencia en la gestión y por lo tanto mejoran la satisfacción en el propio puesto de trabajo dado que establece criterios objetivos en la asignación de turnos. Como consecuencia también se incrementa la estabilidad de la plantilla y por lo tanto el conocimiento existente en los propios equipos de trabajo.

Así pues y en aras de mejorar en los aspectos indicados el objeto de este expediente es la Adquisición e Implantación de un software para la P lanificación y Gestión de Turnos de personal para Osakidetza .


Este software deberá implantarse en la toda la red asistencial de Osakidetza que se compone de 20 organizaciones sanitarias:

1. OSI Araba o Sede Txagorritxu o Sede Santiago

2. OSI Arabako Errioxa – Rioja Alavesa 3. Red de Salud Mental de Araba 4. OSI Barakaldo-Sestao 5. OSI Ezkerraldea-Enkarterri – Cruces 6. OSI Barualde – Galdakao 7. OSI Uribe 8. OSI Bilbao – Basurto 9. Hospital de Górliz 10. Hospital de Santa Marina 11. Red de Salud Mental de Bizkaia 12. OSI Donostialdea 13. OSI Goierri – Alto Urola 14. OSI Bajo Deba 15. OSI Bidasoa 16. OSI Alto Deba 17. OSI Tolosaldea 18. Red de Salud Mental de Gipuzkoa 19. Centro Vasco de Transfusión y Tejidos Humanos (CVTTH 20. Emergencias


2 SITUACIÓN ACTUAL El núcleo de los Sistemas de Información de Gestión de Recursos Humanos (en adelante RRHH) de Osakidetza está constituido por la plataforma SAP, tal y como se detalla en la tabla siguiente.

Aplicación SAP Descripción Ámbito funcional Versión SAP Componentes

SAP Volumen usuarios

SAP ECC Administración y Gestión de Personal

Administración y gestión de personal: actos administrativos, relaciones con terceros (Haciendas Forales, Seguridad Social).

Gestión de empleados ECC 6.0 ES-PS-HR 500

SAP ECC Nómina Cálculo de nómina del personal. Gestión de empleados ECC 6.0 PY-ES 570

SAP ECC Planificación de Turnos

Cartelera: gestión de turnos de trabajo del personal.

Gestión de empleados ECC 6.0 PT-SP 1.370

SAP ECC Gestión de Tiempos

Cartelera: gestión del cómputo horario y la retribución variable del personal.

Gestión de empleados ECC 6.0 PT 490

SAP ECC Gestión de Organización

Gestión de plantilla y organización de personal.

Gestión de empleados ECC 6.0 ES-PS-HR 450

SAP BI Reporting RR.HH.

Herramienta de ayuda a la toma de decisiones (cuadro de mando)

Gestión de empleados BW 7.0 BI 80

SAP ECC Normalización Lingüística

Gestión del plan de normalización del uso del Euskera Euskera ECC 6.0 BC-BMT-OM 165

SAP ECC Vigilancia Salud Laboral

Gestión de la salud laboral de los empleados Salud laboral ECC 6.0 EHS 95

SAP ECC Prevención de Riesgos Laborales

Gestión de la prevención de riesgos laborales

Prevención de riesgos ECC 6.0 EHS-IHS 130

SAP ECC Formación continuada

Gestión de la formación continuada del personal. Formación ECC 6.0 PE 270

SAP ECC Selección y Provisión

Gestión de Selección y Provisión de candidatos.

Selección y provisión

ECC 6.0 ES-PS-HR 570

SAP ECC Contabilidad RRHH

Contabilidad y gestión de costes de personal.

Contabilidad RRHH ECC 6.0 PY-XX-DT 205

Portal del empleado Automatización de flujos de información entre el empleado y las Direcciones de Personal.

Portal del empleado

NW Portal 7.02

ESS / MSS 40.000

A pesar de disponer de una gestión de RRHH robusta y sólida, soportada en la plataforma anteriormente detallada, Osakidetza no dispone de ninguna solución para la planificación de turnos y simulación de plantillas. Los responsables de área (supervisores, adjuntos, equipos de dirección), dedican gran parte de su actividad laboral a buscar soluciones para la planificación de los turnos de su personal, que exige revisiones diarias, debido a los numerosos imprevistos que surgen en las distintas unidades. En lo que se refiere a los sistemas de información de soporte a la toma de decisiones, nos encontramos con que en los hospitales existe un soporte informático básico para este proceso, pero este soporte se orienta fundamentalmente al registro, y a su vez, los sistemas de soporte no proporcionan instrumentos orientados al día a día del trabajo de la enfermería, ni al soporte a sus decisiones, de forma que:

• La información sobre la planificación de los trabajadores se encuentra desperdigada en forma de múltiples hojas de cálculo, almacenadas como ficheros en los equipos de cada responsable.


• Las supervisoras intercambian y rellenan estas plantillas con la planificación de

sus trabajadores, y sobre estas hojas realizan sus cálculos de presencia, trabajo, vacaciones, etcétera.

• La recopilación de información a partir de estas planillas es costosa, y se realiza de forma manual.

• Los mandos superiores tienen limitada su visión del trabajo realmente realizado; la explotación de la información por parte de los cuadros de mando no puede contar con todo el detalle de la operación de los trabajadores.


3 OBJETO DEL CONTRATO El objeto de este expediente es la adquisición e implantación de un software para la Planificación y Gestión de Turnos de personal, así como su integración con el sistema de Gestión de Personal de Osakidetza , basado en el módulo HR de SAP El objeto del contrato incluye:

• Software comercial , para Planificación y Gestión de Turnos de personal en Osakidetza . El producto ofertado por los licitadores, deberá suministrarse en régimen de licenciamiento corporativo (número ilimitado de usuarios y centros). La solución propuesta deberá ser Multiidioma , garantizando la implantación en euskera y castellano.

• Integración del producto ofertado con la solución SAP ECC

• Implantación de la solución Aunque la solución ofertada deberá ser de propósito general y deberá permitir la planificación de turnos de cualquier colectivo profesional de Osakidetza (35.000 profesionales), el ámbito de implantación se ceñirá al colectivo de enfermería (en torno a 12.000 enfermera/os), y a los colectivos gestionados por éstas, siendo el alcance total de esta implantación el de unos 16.000 profesionales. Asimismo, señalar que estas tareas de implantación e integración no suponen en ningún caso servicios añadidos, sino que resultan imprescindibles para la puesta en marcha del software objeto del contrato, ya que forman un todo junto con la adquisición de las licencias.

El presupuesto máximo asignado para este expediente es de 1.150.000€ (sin IVA ). El plazo de ejecución será de 20 meses contado desde la fecha de formalización del contrato.

La solución se instalará de forma centralizada, pero el despliegue se abordará por Organización de Servicios, con soporte local on-site, y formación al personal sanitario, e informático.

El precio de las licencias ofertadas incluirá obligatoriamente durante toda la vigencia del contrato:

• Poner a disposición de Osakidetza y autorizar el uso de la última versión o actualización disponible en el mercado de todos los productos relacionados en el objeto del presente pliego

• Entregar a Osakidetza todas las versiones mayores de productos y tecnología, que incluyen versiones generales de mantenimiento, versiones de funcionalidad seleccionada y actualizaciones de documentación

• Dar acceso a la base de conocimiento y soporte Web (sistemas de soporte al cliente basados en la web), incluida la posibilidad de registrar peticiones de servicio en línea

• Servicio telefónico y local de soporte, para la resolución de incidencias y peticiones de servicio.

Los entornos a utilizar en el proyecto y cuyas licencias deberán ser suministradas,


serán los siguientes: • Entorno de Pre-producción • Entorno de Producción • Entorno de Desarrollo

Toda la plataforma hardware y software de base (sistema operativo) requeridos para la implantación del nuevo producto, así como los servicios de administración, monitorización, y operación de la misma, serán suministrados por la Subdirección de Informática y Sistemas de Información de la Organización Central de Osakidetza , no estando incluidos en el objeto de este contrato. La solución ofertada deberá ser multiplataforma (hardware y sistema operativo), pudiendo implantarse, bajo los estándares de Osakidetza que se detallan en Anexo I. Las estaciones de trabajo (PCs) y su software de base, serán los existentes en las Organizaciones de Servicio de Osakidetza , por lo que quedan también, fuera del alcance de este contrato, siendo necesario que el producto ofertado se ajuste a la maqueta de Osakidetza que se detalla en el Anexo II.


4 REQUISITOS FUNCIONALES DE LA SOLUCIÓN El Sistema de Información para la Planificación y Gestión de Turnos, se considera una herramienta de trabajo imprescindible para incrementar la productividad y mejorar la calidad asistencial. Dentro del enfoque en el uso de las nuevas tecnologías, Osakidetza pretende incorporar una solución de gestión y planificación de turnos adaptada a sus necesidades, así como los servicios necesarios para poner en funcionamiento dicha solución en las diferentes organizaciones de la red sanitaria. A continuación se describe el conjunto de funcionalidades que deberá cumplir la nueva solución.

4.1 Estructura básica y Configuración del Sistema

• Sistema Multiidioma , garantizando la implantación en euskera y castellano.

• Interfaz gráfica ágil e intuitiva . Tendrá un grado importante de usabilidad en aras de maximizar la productividad del usuario, teniendo en cuenta que se trata de un profesional sanitario altamente cualificado, cuya labor principal es la asistencia sanitaria y no la gestión administrativa.

• Cumplimiento de la legislación específica en materia de RRHH (autonómica

y nacional).

• Motor de Cálculo propio, con capacidad de calcular y realizar previsiones a futuro.

• Sistema Multicéntrico. El sistema permitirá definir la estructura jerárquica de las Organizaciones de Servicio de Osakidetza , así como de las distintas unidades de cada hospital, teniendo en cuenta que Osakidetza es un ente multisociedad compuesto por 20 Organizaciones de Servicios sanitarias. Deberá incluir capacidades de:

o Gestión de varias organizaciones o Gestión de la estructura organizativa o Posibilidad de creación de múltiples estructuras. o Número ilimitado de niveles de estructura para una organización

• Gestión de maestros . Horarios, ciclos, turnos, motivos de ausencia,

vacaciones, etc.

• Gestión de seguridad y accesos. Permitirá gestionar usuarios y permisos (funcionalidades, servicios, colaboradores, etc.), garantizando la trazabilidad de los cambios efectuados.

• Personalización . Permitirá opciones múltiples de personalización:

o Visión de las carteleras, relación de empleados y servicios, cambios de turnos, ausencias, etc.

o Uso de reglas de gestión adaptables a cada organización. o Definición y parametrización de Alertas.


4.2 Gestión La solución deberá cumplir los siguientes requisitos funcionales relacionados con la gestión de turnos:

• Mecanización de cartelera . Permitirá la introducción de cambios de turno,

ausencias, incidencias, guardias, etc. Proporcionará mecanismos de ayuda para localizar los profesionales más adecuados en cada momento, permitiendo las cesiones entre unidades.

• Parametrización . Dispondrá de herramientas de parametrización con objeto de contemplar los distintos elementos establecidos en Osakidetza , así como los cambios que puedan producirse a lo largo del tiempo en ellos, con sus correspondientes efectos en el cómputo de la jornada.

• Empleados virtuales . Permitirá trabajar con empleados ficticios que todavía no tienen una relación laboral formalizada en el sistema de gestión de Recursos Humanos.

o Creación y empleo de colaboradores virtuales o Transformación en empleados reales

• Coberturas. Permitirá definir por cada unidad las necesidades a cubrir. El

sistema mostrará cómo se están cubriendo las necesidades, disparándose en su caso, alertas con el fin de prevenir situaciones de falta de cobertura.

• Indicadores . Dispondrá de indicadores que permitan visualizar en tiempo real los parámetros asociados a los empleados y relativos a la gestión de turnos, por ejemplo: cálculos de jornada, días libres pendientes, etc. La solución permitirá definir de forma flexible nuevos tipos de indicadores según las necesidades actuales y futuras de Osakidetza .

• Informes . Dispondrá de informes operacionales que faciliten la gestión y seguimiento de las carteleras.

• Movilidad. se valorarán aquellas soluciones que permitan el registro y consulta de información multi dispositivo (PC, Smartphone, Tablet, etc.), en las siguientes transacciones:

o Gestión de control de Presencia/ausencia o Consulta y Visualización de los turnos y horarios por cada empleado. o Seguimiento de las Solicitudes de Modificaciones de horarios/turnos así

como sus resultados (aceptadas, rechazadas, etc.)

4.3 Planificación La solución deberá cumplir los siguientes requisitos funcionales relacionados con la planificación de turnos:

• Planificación de cartelera . Permitirá la confección de la cartelera de turnos (al

menos anual) por cada unidad, ajustada a diferentes parámetros (jornada, capacidad, etc.). Permitirá así mismo la planificación de guardias de diferente tipología (localizadas, presencia física, etc.).


• Patrones de turnos . Permitirá confeccionar y utilizar ruedas o patrones de

turnos.

• Planificación automática. De forma complementaria al uso de patrones, el sistema proporcionará un motor de planificación automática con el fin de optimizar los recursos humanos de las unidades. El sistema permitirá parametrizar las reglas de planificación más habituales, basándose en múltiples aspectos (deseos del empleado, ausencias previstas, necesidades de cada unidad, etc.).

• Multiasignación y préstamos de colaboradores entre diferentes departamentos de la organización.

• Simulación de escenarios . Proporcionará la funcionalidad de cálculo y comparación de escenarios con el fin de simular y evaluar situaciones posibles.

• Empleados virtuales . Permitirá trabajar con empleados ficticios que todavía no tienen una relación laboral formalizada en el sistema de gestión de Recursos Humanos.

• Parametrización . Dispondrá de herramientas de parametrización con objeto de contemplar los modelos de planificación establecidos o los nuevos modelos que puedan surgir.


5 REQUISITOS TÉCNICOS DE LA SOLUCIÓN

5.1 Alcance técnico de la solución El Sistema propuesto debe cumplir los siguientes requisitos:

• La solución ofertada debe tener carácter Multisociedad, debe ser capaz de dar soporte a todas las sociedades que integran Osakidetza , en su modelo de actual de Organizaciones Sanitarias Integradas (OSIs).

• Se plantea una única instalación centralizada , siendo el licitador quien deberá proponer el modelo de arquitectura que considere óptimo, para la correcta operativa de su producto. El modelo propuesto deberá ser aprobado por Osakidetza , valorándose aquellas soluciones que se adecúen a los estándares de Osakidetza Anexo I, y facultándose a ésta el derecho de modificarlo.

La aplicación ofertada debe funcionar con las comunicaciones que actualmente están disponibles, detallando el licitador en su propuesta las necesidades de ancho de banda requeridas.

• El licitador deberá detallar en su oferta las necesidades de infraestructura

de soporte al sistema, que deberán garantizar en todo momento la continuidad de servicio. Osakidetza una vez aprobado el dimensionamiento propuesto, será responsable del suministro de la misma.

• La solución ofertada debe estar basada en cliente ligero, solución Web, y será ejecutada por un navegador desde los puestos clientes sin necesidad de instalar ningún software adicional. Se podrán utilizar los siguientes navegadores:

� Internet Explorer � Chrome � Firefox

• La solución ofertada debe integrarse con el Directorio Activo de

Osakidetza .

• La solución propuesta, deberá integrarse con el sistemas SAP de Osakidetza , en base a las tecnologías indicadas en el Anexo I

• En relación con el puesto cliente , la solución ofertada debe hacer uso de la maqueta de Osakidetza , cuyas características y software de base se detalla en Anexo II .

• El adjudicatario deberá dotar de los mecanismos y herramientas necesarios

para permitir la alta disponibilidad y continuidad de servicio del producto ofertado.

5.2 Entornos Los entornos a utilizar en el proyecto y para los cuales deberán ser suministradas las licencias suficientes, serán los siguientes:

• Entorno de Desarrollo:


o Osakidetza suministrará la infraestructura y el software de base instalado

o Una vez entregado el entorno, la gestión del mismo correrá por cuenta del adjudicatario, proveyendo Osakidetza únicamente el servicio de backup

• Entorno de Pre-producción/certificación (integració n):

o Osakidetza se hará cargo de la gestión de este entorno, a excepción del despliegue de las versiones de aplicación y software de base (aplicación y BBDD) si éste no corresponde a estándar Osakidetza , que correrán a cargo del adjudicatario.

o Su finalidad es la de las pruebas de carga y certificación de arranques o nuevas versiones de productos

• Entorno de Producción:

o Osakidetza se hará cargo de la gestión de este entorno, a excepción del despliegue de las versiones de aplicación y software de base (aplicación y BBDD) si éste no corresponde a estándar Osakidetza , que correrán a cargo del adjudicatario.

o En caso de que se conceda acceso al entorno de producción a usuarios técnicos, el acceso se realizará bajo las condiciones previstas en este contrato con respecto al registro de accesos y las circunstancias que puedan justificar ese acceso.

Todos los entornos de trabajo de Desarrollo, Pre-producción y Producción se ubicarán en el CPD de la Dirección General de Osakidetza , ubicado en Vitoria-Gasteiz.


6 LÍNEAS DE TRABAJO Este proyecto incluye principalmente las siguientes líneas de trabajo:

6.1 Consultoría El licitador deberá incluir en su propuesta la realización de un estudio de consultoría que permita definir las normas de gestión y planificación de tu rnos de todos los centros de Osakidetza de forma homogénea y estandar izada , con la posibilidad de que cada centro tenga sus propias desviaciones respecto a dicho estándar.

6.2 Integración con los S.I. Corporativos El licitador deberá definir de forma detallada en su oferta el modelo d e integración propuesto, que deberá cumplir los estándares detallados en el Anexo I . La solución propuesta deberá, además, tener en consideración las siguientes necesidades:

• Osakidetza dispone de una arquitectura SOA (Service Oriented Architecture) para gobernar y orquestar los servicios disponibles en la organización. El sistema de información ofertado deberá inventariar y hacer públicos los contratos de los servicios que pondrá a disposición de otros sistemas de información.

• Los requisitos de integración en tiempo real del producto ofertado, deberán de ser resueltos mediante uno de estos dos métodos: � Escenario 1 - Propagación y consumo de eventos: Event Manager

(desarrollo propio) � Escenario 2 - Consumo de servicios: Oracle SOA Suite (Oracle BPEL

Process Manager, Oracle Service Bus, Oracle Business Rules, ...)

El producto ofertado deberá integrarse de forma intensiva y bidireccion al con el sistema SAP implantado , en relación con los datos de tiempos de los empleados, datos administrativos, laborales, de costes y organizacionales, es decir, toda la información susceptible de ser utilizada para una planificación de turnos, tal y como:

• Datos personales • Turnos, guardias, absentismos, presencias • Estructura organizativa (plazas, puestos funcionales, …) • Plan de turnos teórico y real • Secuencias de turnos, asignaciones temporales, centros de coste • Calendarios de festivos • Contingentes y saldos horarios, etc.

La correcta operativa de la integración requerida se considera vital para el éxito del proyecto por lo que deberá describirse de forma detallada.

6.3 Formación La planificación, gestión y ejecución de la formación, correrá a cargo del proveedor, que formará directamente a los siguientes tipos de usuarios:


• Formación a formadores: el adjudicatario formará a los referentes dentro del personal de Osakidetza que indique la dirección del proyecto. La formación deberá ser la suficiente para que los referentes puedan realizar la formación en cascada. Esta formación se realizará antes de la puesta en marcha de la aplicación.

• Formación técnica : orientada al departamento de informática y enfocada a la administración de la aplicación y a las herramientas de desarrollo y programación inherentes, si es que las hubiera. Además, se impartirá formación sobre el modelo de datos, destinada a poder explotar la información mediante herramientas de Business Intelligence. Esta formación se realizará antes de la puesta en marcha de la aplicación.

La documentación de los cursos de formación, así como la documentación y guías de uso de las diferentes funcionalidades que ofrezca la aplicación ofertada, es tarea del proveedor, que deberá proporcionar puntualmente antes de que cualquier formación tenga lugar o cualquier funcionalidad entre en producción. El licitador entregará en la oferta una planificación detallada que explique el alcance de los contenidos de formación y en el que se deberá indicar el número de horas previstas de formación para los usuarios y para el personal de informática. Este número de horas es orientativo y en ningún caso será el límite de horas a impartir si la formación no ha llegado al nivel adecuado para la adopción de sistema. Formación online: se creará el material para disponer de toda la formación en formato online en la plataforma de formación corporativa de Osakidetza basada en la herramienta Moodle.

6.4 Implantación El proceso de implantación que requerirá el desplazamiento on-site del equipo de implantación a cada una de las Organizaciones de Servicios, y que el licitador deberá dimensionar y detallar en su oferta, incluirá al menos las siguientes tareas: • Se deberá realizar la parametrización del producto para cumplir el “modelo de

normas de gestión y planificación ” definido en la fase de consultoría.

• El proveedor deberá proporcionar las mejores prácticas actuales existentes en el mercado, para la gestión y planificación de turnos en hospitales

• Se designará un centro piloto de arranque, donde se realizarán las pruebas de la parametrización así como de cualquier integración necesaria con los sistemas existentes. Esta fase incluirá una fase de pruebas para realizar un paralelo de nómina.

• Dentro de la garantía del proyecto, se incluyen las tareas de soporte y resolución

de incidencias que se produjeran durante la implantación de la solución en Osakidetza .

El soporte tendrá varios niveles:

• Nivel 1: presencial proporcionado por el licitador, durante periodo de soporte post-arranque.


• Nivel 2: presencial o remoto proporcionado por el licitador en horario de oficina.

Los equipos de soporte harán uso del Sistema de Gestión de Incidencias corporativo de Osakidetza . Las herramientas de gestión a utilizar en este contrato, son las siguientes:

• La herramienta utilizada para registro y gestión de las consultas e incidencias técnicas y funcionales de los aplicativos, es el producto HP-SM (Service Manager).

• La herramienta utilizada para la Gestión de la Demanda, es el producto HP-PPM (Project and Portfolio Management).


7 MANTENIMIENTO POST-IMPLANTACIÓN El servicio de Mantenimiento post-implantación, que se contratará una vez finalice este expediente, pero cuyo coste deberá detallar el licitador , deberá incluir al menos los servicios que se detallan a continuación:

7.1 Mantenimiento integral Incluye los servicios de mantenimiento propiamente dicho de la solución implantada. A los efectos de una mejor comprensión, se consideran los siguientes tipos de mantenimiento:

• Preventivo: Es aquel incluye las revisiones periódicas, verificaciones calibraciones y ajustes que aseguran que la solución se mantienen dentro de sus especificaciones operativas, y previenen la aparición de fallos. En cada revisión se realizarán los ajustes, modificaciones y sustituciones que se estime necesarios para un correcto funcionamiento del sistema.

• Correctivo: Es aquel que incluye aquellos cambios precisos para corregir los

errores del producto software y que tienen como finalidad restablecer los parámetros originales de funcionamiento.

• Evolutivo : Es aquel que incluye mejoras y nuevas funcionalidades. El

adjudicatario incluirá en sus productos todas aquellas funcionalidades que considere mejoras de carácter general para la aplicación, teniendo en especial consideración aquellas propuestas por Osakidetza .

7.2 Soporte de hot-line El Mantenimiento deberá incluir los Soportes de Mantenimiento de 1º, 2º y 3º nivel desde el Centro de Soporte del licitador, incluyéndose, por tanto, todos aquellos viajes que se consideren necesarios realizar para el correcto funcionamiento de la aplicación contratada/instalada. El horario será el habitual de oficina. Los contenidos de los soportes de mantenimiento de 1º, 2º y 3º nivel son los siguientes:

• Mantenimiento de 1º Nivel : Acceso al servicio de soporte telefónico del licitador para la resolución de consultas a nivel usuario sobre el funcionamiento de la aplicación contratada y de nuevas funcionalidades instaladas.

• Mantenimiento de 2º Nivel: Asesoramiento a nivel de tablas y funcionamiento interno de la aplicación. En errores producidos por la utilización incorrecta de la aplicación contratada o por causas ajenas al adjudicatario, ya puedan ser de hardware y/o de conexiones con otras aplicaciones, el adjudicatario se compromete al asesoramiento y, si es posible, resolución de cualquier problema que haya podido causar éste sobre la aplicación contratada, siempre y cuando no impliquen desplazamientos al centro del cliente en el cual esté instalada la aplicación.

• Mantenimiento de 3º Nivel: Corrección de errores existentes en la aplicación por los medios que la compañía considere oportunos en función de la gravedad


y la posibilidad de proporcionar al cliente una solución adecuada, quedando incluidos cuantos viajes sean necesarios para la total resolución de los problemas indicados a continuación:

o Parada del entorno de Producción. Afectación amplia o total de la aplicación y que no sean causas ajenas al adjudicatario, es decir, que sean imputables al mismo.

o Incidencias que afectan a la operativa diaria de los usuarios dificultando su tarea y que el soporte del adjudicatario remoto no sea capaz de solucionar en 48 horas.

7.2.1 Asistencia en el centro – acceso remoto Deberá existir comunicación vía VPN para que desde el centro de mantenimiento pueda acceder a los centros. La mayoría de las incidencias se resolverán de forma remota, mediante la consulta de la incidencia y el posterior envío del software adaptado. Sin embargo, hay otro tipo de servicios que requieren asistencia en el centro:

• Jornadas de trabajo con otros proveedores para resolver incidencias conjuntas. • Implantación en centro piloto de una versión nueva para su validación y

aceptación

7.2.2 Tiempos de respuesta En lo referente a los niveles de servicio deberán mantenerse orientativamente los siguientes ratios:

• El tiempo máximo de respuesta será el siguiente: � Horario de oficina: 2 horas desde la notificación de la incidencia. � Fuera de Horario de oficina: primera hora del día siguiente válido

• Si se reporta una incidencia debido a un error de la aplicación que reproduce

un problema que impide la explotación correcta de la aplicación y no admite una solución temporal razonable, se procederá a aplicar una solución de emergencia.

Dicha solución de emergencia implicará que una vez localizado el error se procederá a su pronta reparación y al envío al Cliente de una versión de la aplicación para su instalación. El tiempo máximo de envío de esta versión de urgencia desde su diagnóstico será de:

� 24 horas laborables si el error es crítico (no es posible trabajar con la aplicación)

� 48 horas laborables si el error es muy grave (gran degradación en el uso del sistema)

� y una semana natural en el resto de los casos.

Además, el servicio técnico tomará las acciones que sean necesarias para restaurar la integridad de los datos gestionados por la aplicación, en caso de que ésta se hubiera visto comprometida. Se registrará todas las incidencias y dará contestación telefónicamente o por correo electrónico con la consiguiente solución, enviando mensualmente por correo un informe que detallará las consultas abiertas en el mes, las consultas


cerradas con una descripción de su solución y las consultas que se encuentran pendientes, así como los parámetros de calidad del servicio.


8 PRODUCTOS A OBTENER El resultado final consistirá en la implantación del Sistema Informático que dará soporte a la gestión y planificación de turnos, junto con la documentación del Sistema. Los productos a obtener serán, como mínimo, los siguientes:

• Planificación del proyecto. • Especificaciones hardware y software necesarias para la implantación del

producto. • Documentación Técnica del producto. • Informes de seguimiento del proyecto. • Manual de Usuario. • Manual de Explotación. • Manual de Instalación.


9 PLANIFICACIÓN DEL PROYECTO Es necesario que los licitadores presenten los cronogramas en los que se deben especificar los contenidos o tareas y su distribución en el tiempo. Estos cronogramas incluirán, asimismo, los diferentes hitos a cubrir y los entregables.


10 EQUIPO DE TRABAJO Las empresas interesadas en la adjudicación del contrato presentarán en su propuesta la descripción de su equipo de trabajo, especificando los recursos humanos que destinarán al proyecto, sus perfiles profesionales, y las dedicaciones por cada una de sus categorías. Asimismo, se indicarán los precios unitarios/jornada por cada categoría profesional ofertada. Existirá un Director del Proyecto por parte de la empresa adjudicataria, representante de la misma e interlocutor y responsable de los trabajos ante la Dirección del Proyecto de Osakidetza . Osakidetza aportará también la figura de un Director de Proyecto, con la función de coordinar la participación de los recursos humanos del mismo que sean necesarios en cada momento. Osakidetza controlará, mediante la figura de su Director de Proyecto, el cumplimiento de los términos acordados, así como la calidad y adecuación del servicio objeto de este contrato, quedando ambos sujetos a lo que marca la Ley de Contratos de las Administraciones Públicas (texto refundido), en cuanto hace referencia a completar los términos y calidad de los productos desarrollados. Asimismo, deberán identificarse los responsables únicos en cuantas actividades que, por su importancia, se considere oportuno: análisis, desarrollo, control de calidad, y sus funciones y relaciones con el resto del equipo y Osakidetza . Osakidetza , por su parte, deberá asegurar la colaboración de Técnicos, responsables de la aplicación en las distintas fases del proyecto.


11 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

Descripción detallada de las herramientas/productos ofertados que a priori se consideran apropiados para la realización del proyecto, justificando su adecuación a los objetivos del mismo y realizando una descripción exhaustiva de la funcionalidad que incorporan. Se aportará también detalle exhaustivo tanto del tipo de licenciamiento y volumen de licencias ofertadas, como de los costes de mantenimiento (una vez finalizado el contrato) y las modalidades del mismo.

3. Arquitectura tecnológica y modelo de integración Descripción detallada de la arquitectura propuesta, modelo y elementos que la componen, con objeto de garantizar la escalabilidad y continuidad de servicio. Se valorarán positivamente aquellas soluciones alineadas con los estándares de Osakidetza , detallados en el Anexo I. Se deberá detallar también, de forma exhaustiva la infraestructura requerida para la arquitectura propuesta, describiendo de forma detallada las características de esta infraestructura.


Se incluirá también un detalle exhaustivo de la estrategia y modelo de integración del producto ofertado con el sistema SAP descrito.

4. Plan de Trabajo

Descripción específica para cada una de los servicios a prestar: descripción del contenido, estrategia y operativa de trabajo y relación entre tareas, destacando especialmente las tareas relacionadas con el despliegue de la solución, migración de datos y formación y coaching. Se incluirá la planificación en el tiempo de cada línea de trabajo, hitos y productos resultantes, que permitirán la certificación del proyecto. Se incluirán los procedimientos a seguir para el control del proyecto, a fin de detectar posibles desviaciones y tomar las acciones correctivas adecuadas.

5. Mejoras y prestaciones adicionales a las requeri das en el pliego Se valorarán exclusivamente aquellas mejoras relacionadas con los siguientes aspectos:

• La prestación de un soporte post-arranque (soporte telefónico, presencial, etc.). • La posibilidad de trabajar en movilidad Para que sean valoradas estas propuestas, deberán estar suficientemente documentadas, y en el caso de tratarse de servicios, necesariamente valoradas en cuanto al nivel de esfuerzo (horas/perfil).

6. 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 volumen de horas/perfil, del equipo de trabajo propuesto.

7. Cuestionario de Especificaciones Técnicas (CET) Para verificar que la solución (producto/desarrollo) está alineada tecnológicamente con las directrices tecnológicas de Osakidetza , se debe entregar cumplimentado el cuestionario detallado en el Anexo III (CET).


12 PROPIEDAD DE LOS PRODUCTOS Todos los productos descritos en el punto 8 de este documento que entregue el adjudicatario quedarán en propiedad exclusiva de Osakidetza , así como su propiedad intelectual, quedando el adjudicatario obligado a renunciar a cualquier derecho sobre estos conceptos.


13 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 tengan acceso con motivo de esta 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, 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.


14 PRESUPUESTO, PLAZOS Y FORMA DE PAGO

14.1 Presupuesto El presupuesto máximo asignado y los plazos máximos de ejecución para este proyecto son los siguientes:

• Presupuesto máximo asignado : 1.150.000€(SIN IVA) La valoración económica esta expresada en Euros, es máxima e incluye la totalidad de los conceptos devengables. El importe anterior se deberá distribuir en las siguientes partidas, cuyos precios máximos se indican a continuación: Se deberán detallar claramente los siguientes aspectos:

• Importe del licenciamiento del producto ofertado. Se deberá detallar además el coste del mantenimiento anual del producto, que no podrá ser superior al 25% del coste de licenciamiento del mismo.

El mantenimiento anual, incluirá al menos los servicios detallados en el capítulo 7, de este pliego.

• Importe de la implantación del proyecto: Se deberá detallar el importe por cada una de las líneas de trabajo que conforman el proyecto de implantación.

La suma total de los conceptos anteriormente señalados no podrá exceder del precio de licitación total. La valoración económica deberá ir obligatoriamente en el sobre B : “Oferta económica y criterios evaluables de forma automática mediante la aplicación de fórmulas”.

14.2 Plazos El plazo de ejecución será de 20 meses desde la fecha de formalización del contrato.

14.3 Forma de pago Se realizará de la siguiente forma:

� Las licencias del producto se facturarán de forma independiente � Para el resto de las tareas del proyecto, se presentará una factura a la

finalización de cada una de las líneas de trabajo detalladas en el capítulo 6 de este Pliego, y tras el VºBº del responsable de Osakidetza .


15 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: ................................. ..................................................... 70

• Descripción del contenido de la solución: Descripción detallada de las funcionalidades del producto ofertado .................................................. 35

� Estructura básica y configuración del sistema ....................................... 5

� Gestión de turnos ................................................................................ 15

� Planificación de turnos ......................................................................... 15

• Modelo de integración: Descripción detallada del tipo, mecanismos y puntos de integración ................................................................................... 15

• Arquitectura tecnológica propuesta: Descripción detallada de la arquitectura propuesta, componentes y garantía de escalabilidad y continuidad de servicio ............................................................................... 5

• Coherencia y contenido del Plan de Trabajo: Plan de trabajo contenido e hitos: Estrategia de Implantación, migración, formación y soporte ............................................................................................................ 10

• Mejoras y prestaciones adicionales: sólo mejoras relacionadas con la prestación de un soporte post-arranque (soporte telefónico, presencial, etc.) y con la posibilidad de trabajar en movilidad .......................... 5

Umbral mínimo de la suma de los 5 criterios anterio res: 40 puntos . 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: .......................................... ............................................................ 30

• Precio de la oferta .............................. ................................................ 25

Atendiendo a la tabla que se presenta a continuación, la valoración del precio se realizará de la siguiente forma: � 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:

Porcentaje de baja = 1 −��

�� ó��


� 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.

Interpolación %baja = puntostramo∗�%� � �� %�í"�� "�

�%��"��#$%�� " %�í"�� "�

� Los puntos valorados para cada tramo se sumarán hasta alcanzar el porcentaje

de baja presentada. � La oferta cuyo importe sea igual al importe de licitación se valor ará con 0

puntos .

Descripción tramo puntos Puntos Porcentaje de baja de hasta un 5% con respecto al importe de licitación. 5 Porcentaje de baja superior al 5% e igual o inferior al 7,5% con respecto del importe de licitación. 5

Porcentaje de baja superior al 7,5% e igual o inferior al 10 % con respecto del importe de licitación.

5

Porcentaje de baja superior al 10% e igual o inferior al 15% con respecto del importe de licitación. 4



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 25

• Precio del mantenimiento anual .................... ....................................... 5 El precio menor del mantenimiento anual recibirá 5 puntos y el resto proporcionalmente aplicando la siguiente fórmula:

Precio Mínimo

---------------------------------- x 5 Precio Ofertado

El mantenimiento del producto ofertado, se contratará una vez finalizado este expediente, y deberá incluir al menos los servicios detallados en el capítulo 7 de este pliego. La evolución de versiones del producto ofertado durante la vigencia del contrato, se considera incluida en el presente expediente.

Comité de expertos

Susana Iglesias Tamayo Fernando Asensio Nicolás González López


16 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:

[email protected] 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 Pliego, 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


17 ANEXO I: 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.

17.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.

17.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.

17.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


17.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 :

17.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 .

17.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 Presentac ió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 de plantillas , 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 de campos y formato. Nunca deberá realizarse una validación de negocio d esde 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 de plantillas: Facilitar el mantenimiento haciendo uso de plantillas.

Se debe utilizar un framework de plantillas (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 e l 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.

17.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 e xcepciones . 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 direct a 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.

17.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, sepa rada 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 Persisten cia:

• 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 q ue 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 l os 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 . .

17.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).

17.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, Cordova 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 � MS SQL Server 2008R2 a SQL Server 2012

o Infraestructura SOA: � Oracle Service Bus 11.1.1.7 a 12c (12.2.1)

17.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 del mercado. 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.

17.4.3 Seguridad, acceso, autenticación y autorizac ió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.


17.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.

17.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.

17.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: SAML Token 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

17.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: Otorgar 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

17.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.

17.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

recibido los mensajes

Autenticación (user/pass)

Subscripción Servicio OSB Sí Sí. Event Manager garantiza la entrega

Ninguna


en el mismo orden que ha recibido los

mensajes

Subscripción Servicio web Sí Sí. Event Manager garantiza la entrega en el mismo orden

que ha

recibido los mensajes

Ninguna, Autenticación (user/pass) y WS-Security

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.

17.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.


17.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

17.7 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 cumplimentado el cuestionario detallado en el Anexo III (CET).


18 ANEXO II: 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 Pack1


19 ANEXO III: CUESTIONARIO DE ESPECIFICACIONES TÉCNICAS (CET)

Este documento, CET (Cuestionario de Especificaciones Técnicas ), contiene un cuestionario para evaluar el grado de alineamiento de la solución ofertada con respecto a las Directrices y Especificaciones Técnicas que figuran en el PBT del expediente de contratación de la solución. Dicho cuestionario servirá de herramienta para la toma de decisiones por parte de Osakidetza a la hora de adjudicar el expediente. De modo que los licitadores deberán cumplimentar dicho cuestionario y adjuntarlo a la oferta junto con el resto de documentación solicitada en el expediente.

19.1 Arquitectura y Tecnología Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

19.1.1 Tecnologías de desarrollo ¿Qué tecnología/s se han utilizado/utilizarán en el desarrollo de la solución?

- JAVA/JEE - .NET - PHP - Ruby - Python - Scala - JavaScript - Otras:

19.1.2 Frameworks ¿Qué framework/s se han utilizado/utilizarán en el desarrollo de la solución, ya sean full-stack o combinados para las capas de Presentación, Negocio y Persistencia? Añadir la versión.

- Spring Framework (JEE) - Struts 2 (JEE) - Grails (JEE) - JSF (JEE) - .NET Framework (Indicar lenguajes a emplear: C#, ASP.NET, C++, otros) - Symfony (PHP) - Laravel (PHP) - CodeIgniter (PHP) - Yii (PHP) - Zend (PHP) - Ruby on Rails (Ruby) - Sinatra (Ruby) - Django (Python) - Flask (Python) - Play (Scala y Java)


- AngularJS (JavaScript) - EmberJS (JavaScript) - Backbone (JavaScript) - Otros:

19.1.3 Arquitectura de Software ¿Qué patrón de arquitectura de software se ha utilizado/utilizará en el desarrollo de la solución?

- Arquitectura de capas: o C/S (cliente/servidor) o 3 capas (presentación, negocio, persistencia)

- Otro:

19.1.4 Tecnologías de virtualización ¿La solución es compatible con tecnologías de virtualización de infraestructura? En caso afirmativo indique cual y la versión.

- Si o VMWare vSphere o Otra:

- No

19.1.5 Sistemas Operativos ¿Con qué sistemas operativos en cuanto a servidores y equipos de trabajo de usuario final, es compatible la solución? Añadir la versión.

- Servidores:

o Microsoft

o Red Hat

o Otros:

- Equipo de trabajo de usuario final: (PC, portátil, móvil, tableta, …)

o Microsoft Windows

o Android

o iOS

o WindowsPhone

o Otros:

19.1.6 Servidores Web y de Aplicación Si la solución requiere servidores web y/o servidores de aplicación, ¿con qué middleware/s es compatible en cada caso? Añadir la versión.

- Servidor Web:

o Apache Webserver


o Microsoft IIS

o Oracle Web Server

o Web Dispatcher de SAP Netweaver

o Nginx

o Otro:

- Servidor de Aplicaciones:

o Apache Tomcat

o Oracle Weblogic Server

o Microsoft IIS

o Aplication Server de SAP Netweaver

o Node,js (Express, Mongoose, Socket.io)

o Otro:

19.1.7 Sistemas de Gestión de Base de Datos (SGBD) ¿Qué SGBDs son/serán soportadas por la solución? Añadir la versión.

- Microsoft SQL Server o Juego de caracteres: o Modo de autenticación: o Servicios adicionales:

� Integration Services � Reporting Services � Otro:

- Oracle Database o Juego de caracteres:

- Oracle RAC o Juego de caracteres:

- Oracle MySQL - MongoDB - Otro:

¿Cuántos esquemas de Base de Datos usará la solución? ¿Requiere acceder a la Base de Datos por otra vía que no sea a través de la solución?

- Si o Permisos de escritura o Permisos de administración

- No ¿Requiere acceder a esquemas de otras aplicaciones? En caso afirmativo indicar con qué tecnología/producto y versión. - Si

o Streams o GoldenGate o Otro:

- No


¿Cuál es la volumetría de datos aproximada que almacenará la solución en sus esquemas propietarios? ¿Es de esperar un aumento considerable en el volumen de datos almacenados con el transcurso del tiempo? ¿Es necesario realizar una gestión de datos históricos?

19.1.8 Appliances y otros componentes hardware ¿La solución requiere hardware adicional especifico tipo appliance o similar? En caso afirmativo indique características y detalles

- Si - No

19.2 Capa de Presentación Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

19.2.1 Modelo de Cliente ¿Qué modelo de cliente tiene la solución?

- Cliente ligero - Cliente rico - Cliente pesado

19.2.2 Equipo de trabajo del usuario final

¿Qué tipo de equipo de trabajo requiere la solución?

- Puesto fijo (PC, Portatil): - Puesto movil: (Tablet, móvil):

19.2.3 Modo de ejecución ¿Qué modo de ejecución requiere la solución?

- Escritorio local - Escritorio remoto:

o Citrix Xen Desktop o Otro

19.2.4 Requisitos en el equipo de trabajo del usuar io final ¿La solución requiere instalar algún software en el equipo de trabajo del usuario final?


- Si

o Propio de la solución o De terceros (*)

- No (*) Si el software requerido es de terceros, conteste a las siguientes cuestiones: Si la solución requiere el uso de navegador ¿utiliza Applets (Java), componentes ActiveX (.NET), Flash u otras tecnologías que impliquen la descarga y ejecución de software embebido en el navegador? En caso afirmativo especifique.

- Si - No

¿La solución requiere componentes de Microsoft Office? En caso afirmativo indique cual/es y la versión.

- Si - No

¿La solución requiere algún otro software adicional al indicado anteriormente? En caso afirmativo, especifique.

- Si o Equipo de trabajo fijo o Equipo de trabajo movil

- No ¿La solución accede o hace uso de impresoras, escáneres o ficheros del equipo de usuario? En caso afirmativo, especifique:

- Si - No

19.2.5 Cliente Rico (RIA- Rich User Interface) ¿La solución hace uso de algún framework RIA (RichUser Interface)?

- Sí - No

En caso afirmativo, ¿qué frameworks RIA utilizará la aplicación?

- JSF - Java Applet - HTML5 - GWT - Silverlight - Adobe Flex - Ionic Framework - Otros

En caso de utilizar JSF, ¿qué implementación será utilizada? Añadir la versión.


- Mojarra JavaServer Faces - Apache MyFaces - Otros

En caso de utilizar JSF, ¿qué librería/s de componentes o extensiones serán utilizadas? Añadir la versión.

- PrimeFaces - RichFaces - IceFaces - OpenFaces - Otras:

19.2.6 Sistema de Plantillas ¿La Solución hace uso de algún sistema de plantillas?

- Sí - No

En caso afirmativo, ¿qué motor de plantillas utiliza la solución? Añadir la versión.

- Freeemarker - Velocity - Tiles - Otros:

19.2.7 Librerías de JavaScript ¿La Solución hace uso de alguna librería de JavaScript?

- Sí - No

En caso afirmativo, ¿qué librería/s de JavaScript utilizará la solución? Añadir la versión

- jQuery - Dojo - MooTools - Kendo - React - YUI - Prototype - Otros

19.3 Capa de Negocio Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

19.3.1 Tecnologías para la comunicación entre capas ¿Qué tecnologías utilizará la solución para la comunicación entre capas? Indicar la


Versión

- EJBs - Spring Framework - Web Services - Otros

19.3.2 Transacciones ¿La solución hará uso de transacciones?

- Sí - No

En caso afirmativo, ¿qué tecnologías utilizará la solución para gestionar las transacciones? Indicar la Versión

- EJBs - Spring Framework - Web Services - Otros

19.3.3 Escalabilidad ¿La solución soporta ejecución en balanceo de carga sobre múltiples instancias simultáneas?

- Si - No

En caso afirmativo, ¿se requiere persistencia de las sesiones de usuario? (indicar tipo):

- Si o Por IP de origen o Basada en cookies o Otros (indicar):

- No

19.3.4 Requisitos de almacenamiento ¿La solución requiere espacio en disco para almacenar archivos?

- Si - No

En caso afirmativo, indique:

- Tipo de almacenamiento y espacio o SAN, MB/GB/TB: o NAS, MB/GB/TB::

- Tipo de archivos (temporales/persistentes): ¿El almacenamiento ha de ser compartido entre las posibles múltiples instancias desplegadas para la solución?


- Sí - No

19.4 Capa de Persistencia Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

19.4.1 Método de Acceso a Base de Datos ¿Qué tecnologías utilizará la solución para el acceso a la base de datos? Indicar la versión

- Procedimientos Almacenados - JDBC - ADO (.NET) - Otros

19.4.2 Tecnologías para la implementación de Persis tencia ¿Qué tecnologías utilizará la solución para la implementación de persistencia de datos? Indicar la versión

- GridLink, - JPA/EclipseLink - JPA/TopLink - Hibernate - ADO.NET/LINQ (.NET) - NHibernate (.NET) - Entity Framework (.NET) - Otros

19.4.3 Gestión de Caché ¿La solución utilizará algún sistema de caché para el almacenamiento y manejo de información de alta demanda?

- Sí - No

En caso afirmativo, ¿qué tipo de herramientas se utilizarán a tal efecto?

- OSCache, - EhCache, - EJB Cache - JPA Cache - Memcached - Redis - Varnish - Oracle Coherence (Cluster) - Cache de HTML5 - Otras:


19.5 Elementos de Interfaz de usuario Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

19.5.1 Dispositivos ¿Con qué tipos de dispositivos de entrada/salida será capaz de interactuar la solución?

- PC - Smartphones (Indicar si requiere uso de teclado y/o pantalla táctil) - Tablets (Indicar si requiere uso de teclado y/o pantalla táctil) - Impresoras - Otros:

19.5.2 Tamaños ¿ A partir de qué tamaño (en pulgadas) se garantiza la usabilidad de la solución?

- 4 pulgadas - 5 pulgadas - 7 pulgadas - 9 pulgadas - 10 pulgadas - 12 pulgadas - Otros:

19.5.3 Resoluciones ¿Qué resoluciones estarán soportadas por la solución?

- 1440×900 - 1280×1024 - 1280×960 - 1280×800 - 1024×768 - 800×600 - Otras:

19.5.4 Navegadores ¿Qué navegadores serán soportadas por la solución? Añadir a partir de que versión estará soportado cada navegador.

- Internet Explorer - Google Chrome - Mozilla Firefox - Microsoft Edge - Opera - Safari - Otros:


19.5.5 Internacionalización y Localización ¿La solución hace uso de estándares de internacionalización (i18n) ?

- Sí - No

¿La solución hace uso de estándares de localización (L10n) ?

- Sí - No

19.5.6 Accesibilidad ¿Cumplirá la solución algunas de las Pautas de Accesibilidad al Contenido en la Web (WCAG)?

- Sí - No

¿En caso afirmativo, qué nivel de conformidad WCAG 2.0 cumplirá la solución?

- A - AA - AAA

19.5.7 Usabilidad ¿Se utilizarán técnicas y/o herramientas para evaluar la Usabilid ad (UX) de la solución?

- Sí - No

¿En caso afirmativo, qué herramientas se utilizarán a tal efecto?

- Selenium - UsabilityTools - Visual WebsiteOptimizer - Otras:

19.6 Seguridad, acceso, autenticación y autorizació n Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

19.6.1 Ámbito de uso ¿Cuál es/será el ámbito de uso de la solución desde el punto de vista del usuario final? Indique los que proceda

- Interno – Osakidetza (Intranet) - Externo (Internet/Redes privadas)

o Admin Publica: (especificar)


o Proveedor/Empresa: (especificar) o Ciudadano

19.6.2 Protocolos de Acceso ¿Qué tipos de protocolos de comunicación utilizará la solución?

- HTTP - HTTPS - RMI - JMS - Otros:

19.6.3 Autenticación ¿La solución utilizará algún sistema de autenticación ?

- Sí - No

En caso afirmativo, ¿qué tipo?

- Directorio Activo y/o Directorio Ligero de Microsoft (AD y/o LDS) - Token de Kerberos - Infraestructura de certificación digital (PKI) a través de Izenpe - Certificados X.509 de servidor - Certificados X.509 de cliente - Otro:

19.6.4 Autorización ¿La solución utilizará algún sistema de autorización? En caso afirmativo especifique.

- Si o Grupos de autorización de Directorio Activo de MS o Otros

- No

19.6.5 Firma electrónica ¿La solución requiere el uso de firma electrónica? En caso afirmativo indique qué tipo.

- Si - No

19.6.6 Legislación en materia de seguridad ¿La solución está adaptada al cumplimiento de la legislación vigente en materia de seguridad? En caso afirmativo indique cual/es.

- Sí


o LOPD - Ley Orgánica 15/1999 de Protección de los Datos de Carácter Personal, desarrollada posteriormente por el Real Decreto 1720/2007 de 21 de diciembre. Estatal.

� nivel alto � nivel medio � nivel bajo

o LSSICE - Ley 34/2002, de 11 de julio de Servicios de la Sociedad de información y Comercio Electrónico.

o Otras: - No

19.7 Interoperabilidad Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

19.7.1 Servicios Web ¿La solución será capaz de integrarse con Servicios Web ? Es decir, será capaz de exponer (capacidad de publicación) y consumir (capa cidad de suscripción) Servicios Web en formato SOAP y REST ?

- Sí - No

En caso afirmativo, ¿qué implementación se utilizará para la publicación de Servicios Web ? Añadir la versión

- JAX-WS - AXIS 2 - WCF - Otras

¿El aplicativo implementará algún protocolo de seguridad para la comunicación en Servicios Web ?

- Sí - No

En caso afirmativo, ¿qué tipo de protocolo de seguridad se implementará para la comunicación en Servicios Web ? Añadir la Versión

- WSS (WS-Security) - SAML - Otros:

19.7.2 Eventos ¿Necesita la solución recibir eventos de otras aplicaciones de Osakidetza ?

- Sí


- No ¿Publicará la solución eventos al sistema de gestor de eventos de Osakidetza para ser distribuidos a otras aplicaciones?

- Sí - No

¿De qué tecnologías hará uso la solución para la publicación y subscripción a eventos?

- Mensajería JMS - Servicios Web - Servicios OSB

¿Qué estándares para el intercambio de información sanitaria soportará la solución? Indicar la versión

- HL7 - DICOM - SNOMED-CT - LOINC - Otros:

19.7.3 Servicios en la Nube (Cloud) ¿La solución hará uso de algún servicio en la nube para almacenar o consumir servicios?

- Sí - No

En caso afirmativo, indique cuáles son dichos servicios en la nube:

19.8 Mantenimiento y Operación Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

19.8.1 Retrocompatibilidad ¿La solución soporta retrocompatibilidad de versiones?

- Sí - No

En caso afirmativo, ¿de qué tipo? Añadir las versiones soportadas

- Modelo de datos - Componentes de lógica de negocio - Cliente - Otros:


19.8.2 Gestión de versiones ¿La solución soporta actualización de versiones sin corte de servicio?

- Sí - No

19.8.3 Distribución en dispositivos móviles ¿La solución será distribuida en dispositivos móviles?

- Sí - No

En caso afirmativo, ¿de qué manera se llevará a cabo dicha distribución?

- MDM (Mobile Device Management) - Marketplace (Google, Play, Apple Store, etc…) - Fichero con la aplicación empaquetada (APK, etc…) - Otros:

¿Qué tipo de solución se propondrá para movilidad / dispositivos móviles?

- Aplicación nativa - Aplicación híbrida - Aplicación web (adaptada a dispositivos móviles)

Si la solución es nativa, ¿en qué plataformas se llevará a cabo su distribución? Indicar la versión

- Android - iOS - Windows Phone - Otras:

Si la solución es nativa o híbrida, ¿tendrá versión web accesible desde un navegador?

- Si (indicar los navegadores soportados junto a la versión mínima soportada) - No

Si la solución es híbrida, ¿qué frameworks se utilizarán para su desarrollo?

- Ionic Framework - Cordova / PhoneGap - jQuery Mobile - Sencha Touch - Otros:

19.8.4 Acceso e interacción en dispositivos móviles ¿Cómo se efectuará la entrada de datos en el dispositivo móvil?

- Teclado - Pantalla


- Código de Barras - Otros:

¿Cómo se accederá a los recursos hardware del dispositivo móvil?

- De manera nativa - A través de plugins de Cordova / PhoneGap (enumerar) - Otros:

19.8.5 Impresión ¿La solución hace uso de impresión y/o gestión de reports ?

- Sí - No

En caso afirmativo, ¿qué tecnologías de impresión utilizará la aplicación?

- BIRT - JasperReports - ReportServer - Pentaho - FOP - Crystal Reports (.NET) - Otros:

19.8.6 Gestión de Errores ¿La solución hará uso de estándares y/o patrones de software para el contro l y gestión de errores ?

- Sí - No

En caso afirmativo, indique dichos estándares y patrones:

19.8.7 Logs y Trazas ¿La solución maneja algún tipo de fichero de Logs y/o Trazas?

- Sí - No

En caso afirmativo, ¿qué tipo de información se escribe en los ficheros de log y/o trazas?

- Seguridad - BBDD - Errores - Otros


¿Qué librerías/herramientas utilizará la solución para la gestión de Logs y/o Trazas?

- SLF4J - LogBack - Log4j - Apache Commons Logging - NLog (.NET) - Log4net (.NET) - Otros:

19.8.8 Monitorización ¿La solución incluye documentación sobre reglas de monitorización formalmente definidas mediante objetos monitorizables y umbrale s de alerta concretos ? En caso afirmativo especifique.

- Sí - No

¿La solución incluye registro de eventos de error o advertencia en fiche ros de logs o registros del sistema ? En caso afirmativo especifique.

- Sí - No

¿La solución incluye procesos o scripts de pruebas sintéticas mediante l os que se pueda determinar el estado de salud del servicio o sus componentes ? En caso afirmativo especifique

- Sí - No

¿La solución incluye procesos o scripts de remediación automática de condiciones error o restauración del servicio, como reinicio de procesos, servicios, etc. ? En caso afirmativo especifique.

- Sí - No

19.8.9 Backup y Restore Copia de seguridad/Salvaguarda de la solución : ¿La solución incluye documentación sobre los elementos concretos sobre los que se requiere hacer Backup ? En caso afirmativo especifique.

- Sí - No

En caso afirmativo, ¿se incluyen documentación sobre orden de dependencia de los elementos a salvaguardar, recomendaciones de frecuencia y políticas de


persistencia ? En caso afirmativo especifique.

- Sí - No

Restauración de la solución : ¿La solución incluye documentación sobre el procedimiento de restauración del servicio en caso de fallo o corrupción del mismo? En caso afirmativo especifique.

- Sí - No

En caso afirmativo, ¿se incluyen procedimientos de restauración independientes para cada componente de la solución indicando el orden de precedencia de cada uno? En caso afirmativo especifique.

- Sí - No

19.9 Directrices de Desarrollo Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

19.9.1 Gestión y Versionado del Código Fuente ¿Se utilizará alguna herramienta para la gestión y versionado del código fuente y como repositorio durante el desarrollo?

- Sí - No

En caso afirmativo, ¿qué herramientas se utilizarán a tal efecto?

- Git - Subversion - Mercurial - CVS - Visual SourceSafe (.NET) - Otros:

19.9.2 Librerías y Ficheros de Configuración ¿La solución hará uso de ficheros de configuración ?

- Sí - No

¿En caso de utilizarse ficheros de configuración , irán empaquetados con la aplicación?

- Sí


- No

¿La solución hará uso de librerías ?

- Sí - No

¿En caso de utilizarse librerías , irán empaquetadas con la aplicación?

- Sí - No

¿En caso de utilizarse librerías que no vayan empaquetadas con la aplicación, será necesaria la creación de una biblioteca con las librerías necesarias en el Servidor de Aplicaciones ?

- Sí - No

19.9.3 Gestión de Dependencias ¿Se utilizará durante el desarrollo alguna herramienta para la gestión automatizada de dependencias, tareas y/o builds ?

- Sí - No


- Maven - Gradle - NuGet (.NET) - Ant - Otras:

19.9.4 Versionado de Binarios ¿La solución hará uso de alguna herramienta como repositorio para el versionado de los binarios (librerías, etc…) del aplicativo?

- Sí - No

En caso afirmativo, ¿qué herramientas se utilizarán para el versionado de binarios?

- Artifactory - Nexus - Archiva - Otras:

19.9.5 Gestión de la Configuración y los Activos ¿La solución hará uso de alguna herramienta para la gestión de la configuración y


de los activos ? - Sí - No

En caso afirmativo, ¿qué herramientas se utilizarán a tal efecto? - Puppet - Chef - Ansible - Salt - Vagrant - Docker - Otras:

19.9.6 Integración Continua ¿Se llevará a cabo algún tipo de Integración durante la fase de desarrollo y mantenimiento del aplicativo?

- Sí - No


- Jenkins - AnthillPro - Team Foundation Server (.NET) - Git - Otras:

19.9.7 Documentación ¿Se adjuntará algún tipo de documentación junto con la solución?

- Sí - No

En caso afirmativo, indicar el tipo de documentación que se entregará junto a la aplicación y el formato:

- Documentación Técnica (formato digital y/o papel) - Documentación de Usuario (formato digital y/o papel) - Otras:

En caso de aportar documentación técnica en formato digital a partir del código fuente, ¿qué herramientas se utilizarán para su generación?

- Javadoc (Java) - Sandcastle (.NET) - Doxygen (.NET) - phpDocumentos (PHP) - Otras


19.9.8 Automatización de Pruebas ¿Se establecerán planes de pruebas unitarias automatizadas con sus correspondientes test (que serán entregados junto a la solución), para asegurar que cada uno de los módulos de código funcione correctamente por separado?

- Sí - No

¿En caso afirmativo, qué herramientas se utilizarán para los test de pruebas unitarias automatizadas ?

- JUnit (Java) - NUnit (.NET) - PHPUnit (PHP) - QUnit (JavaScript) - Otras:

¿Se establecerán planes de pruebas de integración automatizadas para asegurar el correcto funcionamiento del sistema en su conjunto en base a todos los elementos unitarios que lo componen?

- Sí - No

¿Se establecerán planes de pruebas de aceptación automatizadas en forma de un conjunto de pruebas que deberán ser ejecutadas por los usuarios del sistema para validar que dicho sistema cumple con los requisitos de funcionamiento esperado y proceder así a la aceptación del sistema?

- Sí - No

¿En caso afirmativo, qué herramientas se utilizarán para las pruebas de aceptación automatizadas ?

- Selenium - Otras:

¿Se establecerán planes de pruebas de rendimiento y carga automatizadas en forma de un conjunto de pruebas que deberán ser ejecutadas para analizar y medir el desempeño del aplicativo?

- Sí - No

¿En caso afirmativo, qué herramientas se utilizarán para las pruebas de rendimiento y carga automatizadas ?

- JMeter


- BadBoy - HP LoadRunner - Otras:

19.10 Diagrama de Arquitectura Para mejor comprensión de la arquitectura de la solución, adjunte la representación gráfica de las vistas que se indican a continuación:

- Vista lógica

- Vista de implementación

- Vista de despliegue

Adquisición e Implantación de un Sistema para la Gestión y ... · SAP Volumen usuarios SAP ECC...

Documents

Transcript of Adquisición e Implantación de un Sistema para la Gestión y ... · SAP Volumen usuarios SAP ECC...