pliego de bases técnicas - osakidetza · el objeto del presente documento es servir de pliego de...

Pliego de Bases Técnicas. Análisis, Desarrollo, Implantación y despliegue de nuevo sistema de Gestión de Centros Alimentarios i/85

Pliego de Bases Técnicas Análisis, Desarrollo, Implantación y despliegue de nuevo sistema de Gestión de Centros Alimentarios

Fecha: Junio de 2012 Referencia: 030/2012

EJIE S.A.

Mediterráneo, 14

Tel. 945 01 73 00*

Fax. 945 01 73 01

01010 Vitoria-Gasteiz

Posta-kutxatila / Apartado: 809

01080 Vitoria-Gasteiz

www.ejie.es

Este documento es propiedad de EJIE, S.A. y su contenido es confidencial. Este documento no puede ser reproducido, en su totalidad o parcialmente, ni mostrado a otros, ni utilizado para otros propósitos que los que han originado su entrega, sin el previo permiso escrito de EJIE, S.A.. En el caso de ser entregado en virtud de un contrato, su utilización estará limitada a lo expresamente autorizado en dicho contrato. EJIE, S.A. no podrá ser considerada responsable de eventuales errores u omisiones en la edición del documento.

Pliego de Bases Técnicas. Análisis, Desarrollo, Implantación y despliegue de nuevo sistema de Gestión de Centros Alimentarios ii/85

Contenido

Capítulo/sección Página

1 Introducción 6

1.1 Perfil de la compañía 6

1.2 Antecedentes 6

1.2.1. Origen de la aplicación 6

1.2.2. Carencias y necesidades detectadas 7

1.3 Conclusiones 8

2 Objeto del contrato 9

2.1 Objeto y alcance del servicio 9

2.2 Descripción del servicio 9

3 Contenido 10

3.1 Situación actual 10

3.1.1. Aplicación de Registro de Centros Alimentarios (P41) 11

3.2 Objetivos a alcanzar 20

3.2.1. Gestión de Centros Alimentarios de la CAPV 21

3.2.2. Explotación de datos 25

3.2.3. Seguridad 28

3.2.4. Requerimientos técnicos generales 30

3.2.5. Otros requerimientos 34

4 Metodología Aplicable y Entorno Tecnológico 37

4.1 Metodología de desarrollo, normativa y Guía de Estilo 37

Pliego de Bases Técnicas. Análisis, Desarrollo, Implantación y despliegue de nuevo sistema de Gestión de Centros Alimentarios iii/85

4.2 Metodología de Pruebas 40

4.3 Modelo de aseguramiento de la calidad (SQA) 41

4.3.1. Nivel de Aseguramiento de la Calidad 42

4.3.2. Plan SQA y actividades de seguimiento de la calidad 42

4.4 Herramientas del ciclo de vida de las aplicaciones 44

4.5 Entorno Tecnológico. 44

5 Descripción de entregables 48

5.1 Normativa para la puesta en producción y posterior explotación del sistema

49

6 Planificación y Organización 50

6.1 Plan de Proyecto 50

6.1.1. Plan de Entregas e Hitos de Control 50

6.1.2. Diagrama de Gantt 50

6.2 Organización del Equipo de Trabajo 51

6.2.1. Asignación de recursos a fases del proyecto 51

6.2.2. Equipo de Trabajo 52

6.3 Transferencia Tecnológica 55

7 Presupuesto y oferta económica 56

8 Mecanismos de Seguimiento, Control y Supervisión 57

8.1 Mecanismos de Seguimiento y Control 57

8.2 Supervisión del proyecto 58

9 Plazo de ejecución y Plan de Facturación 59

10 Criterios de Valoración 61

11 Garantía y Confidencialidad. 63

11.1 Garantía 63

Pliego de Bases Técnicas. Análisis, Desarrollo, Implantación y despliegue de nuevo sistema de Gestión de Centros Alimentarios iv/85

11.2 Confidencialidad de la información 63

11.3 Protección de datos 64

12 Propiedad intelectual 65

13 Prestaciones superiores o complementarias a las exigidas 66

14 Estructura y Formato de la Propuesta 67

14.1 Estructura normalizada y contenido de las propuestas. 67

14.2 Formato de la Propuesta. 69

14.3 Sobres y Elementos. 69

15 Anexo A. Procedimientos a implementar mediante PLATEA Tramitación70

15.1 Alertas 70

15.1.1. Objetivo 70

15.1.2. Descripción del proceso 70

15.1.3. Flujo del proceso 72

15.1.4. Necesidades de negocio 73

15.2 Autorización Sanitaria 73

15.2.1. Objetivo 73




15.3 Procedimiento General de Inspección de Establecimientos Alimentarios76

15.3.1. Objetivo 76




Pliego de Bases Técnicas. Análisis, Desarrollo, Implantación y despliegue de nuevo sistema de Gestión de Centros Alimentarios v/85

15.4 Seguimiento de Denuncias, Notificaciones y Reclamaciones. 79

15.4.1. Objetivo 79




15.5 Procedimiento de Intervención de Establecimientos Alimentarios. 82

15.5.1. Objetivo 82




Pliego de Bases Técnicas. Análisis, Desarrollo, Implantación y despliegue de nuevo sistema de Gestión de Centros Alimentarios 6/85

1 Introducción

1.1 Perfil de la compañía

EJIE, empresa pública del Gobierno Vasco contribuye, mediante la prestación de servicios informáticos, a conseguir una Administración Pública Vasca moderna y eficiente, construyendo y manteniendo la infraestructura de los Sistemas de Información y posibilitando su continuidad y seguridad en base a un personal cualificado y a unos recursos y costes adecuados a la demanda.

EJIE, tiene como meta final la consecución de la satisfacción de sus clientes, para ello se ha impuesto como objetivos permanentes los siguientes:

Prestar servicios de manera eficiente y con calidad, asegurando el cumplimiento de los plazos de respuesta y un nivel "cero" de reclamaciones e incidencias.

Prestar servicios competitivos en relación al sector, en base a la permanente adecuación de los servicios internos al ámbito de actuación y asignando los recursos óptimos mediante la aplicación de los principios de racionalidad, especialidad y eficiencia.

Integrarse activamente con sus clientes en un entorno de transparencia, comunicación y con objetivos comunes: comprensión del problema, enfoque adecuado y resolución satisfactoria.

Obtener una imagen corporativa de servicio eficiente, de calidad y de empresa en punta tecnológica en el sector.

1.2 Antecedentes

El Departamento de Sanidad y Consumo del Gobierno Vasco cuenta en la actualidad con una serie de herramientas que dan soporte a diferentes procesos de la Dirección de Salud Pública, entre ellos se encuentra la aplicación Registro de Centros Alimentarios (P41).

1.2.1. Origen de la aplicación

La aplicación P41- Registro de Centros Alimentarios surgió en el año 2004 con el objetivo de normalizar todas las actividades de inspección y control sanitario de establecimientos alimentarios. Hasta ese momento la gestión de los centros alimentarios se llevaba a cabo mediante hojas de cálculo en Excel y una base de datos Access. La nueva aplicación permitiría la gestión centralizada desde la Dirección de Salud Pública del seguimiento e interrelación de las Subdirecciones y Comarcas.

El sistema de información se diseñó aplicando la solución tecnológica más apropiada en el momento (tecnología Web, J2EE y Oracle), de manera que cubría las necesidades del servicio de Inspección de la


Dirección de Salud Pública. Además, con la puesta en marcha de esta nueva aplicación se realizó una carga inicial con los datos que hasta el momento se habían registrado en el antiguo sistema.

La aplicación facilita que los datos obtenidos en las inspecciones (actas de inspección, protocolos de datos, resultados de muestras analíticas), más los procedimientos administrativos que se generan (autorizaciones y registros sanitarios, expedientes sancionadores, etc.) aporten un elevado número de datos, necesarios para conocer la situación sanitaria de los establecimientos y de los elementos que en ellos se manipulan y/o distribuyen. Además permiten, tras su análisis, evaluar el trabajo desarrollado y programar las actividades de acuerdo a las necesidades.

Así pues, con la aplicación construida era posible llevar a cabo la gestión del registro de centros alimentarios, sus diferentes planes de inspección anual, el registro individualizado de cada inspección, así como las diferentes naturalezas de estas y las tablas con datos necesarios para la gestión.

De igual forma, era necesario implementar un sistema informacional que permitiera explotar de forma ágil y dinámica la información almacenada, de cara a poder obtener indicadores de gestión en sus diferentes niveles. Para cubrir esta necesidad se utilizó la herramienta Business Objects.

1.2.2. Carencias y necesidades detectadas

Podemos agrupar las principales carencias detectadas en los siguientes grupos:

Cambios derivados del Real Decreto 191/2011

Debido a que el Real Decreto 191/2011 del 18 de Febrero, sobre Registro General Sanitario de Empresas Alimentarias y Alimentos, aprobó que el RGSEAA (gestionado por AESAN) funcionase con nuevos criterios de adjudicación de sector categoría y actividad, el Ministerio no está admitiendo las inscripciones de establecimientos con actividades que han desaparecido y se exige que la inscripción inicial de los establecimientos se haga en base a los nuevos criterios.

Como la aplicación P41 (gestionada por la CAPV), no sólo es una herramienta para registro de datos administrativos de establecimientos alimentarios, sino también para la gestión de la actividad del control oficial sobre los mismos, lo cual complica el modo de abordar los nuevos criterios de actuación. La modificación de claves, categorías y actividades en los establecimientos (que está ligado a la adjudicación de la Instrucción Técnica correspondiente), es muy compleja sin que se produzcan consecuencias importantes en el funcionamiento del sistema de registro de los datos de control.

Las actuales carencias de la aplicación, obligan a que hasta disponer de una herramienta informática que recoja de forma normalizada estos cambios, se haya establecido un sistema manual por parte del usuario, que permite trabajar con los nuevos criterios de claves, categorías y actividades sin bloquear el sistema.

eAdministración

De modo adicional, dentro del Gobierno Vasco, desde hace algunos años se está apostando por el uso de servicios comunes de la eAdministración ligados a la tramitación. El uso de dichos servicios facilita, entre otros aspectos, todo lo relacionado con la teletramitación de expedientes. El sistema de información actual no utiliza ninguno de estos servicios y, por tanto, no se aprovecha de sus bondades.


Usabilidad del sistema

En el momento de su construcción inicial, el sistema se elaboró sobre la tecnología más avanzada dentro de los estándares del Gobierno Vasco. No obstante, la evolución tecnológica desde el momento de su concepción ha sido notable incorporando aspectos relacionados con la usabilidad de los sistemas, aspecto muy importante para una herramienta que, como esta, tiene que ser utilizada como herramienta de trabajo habitual.

1.3 Conclusiones

Debido a los aspectos anteriores, el Departamento de Sanidad y Consumo en su apuesta por implementar el uso de nuevas tecnologías y abrir nuevos canales de comunicación con el ciudadano, se plantea la construcción e implantación de un nuevo sistema de información. Dicho sistema incluirá como objetivo destacado la integración de la aplicación con PLATEA Tramitación y construcción de un nuevo sistema analítico de explotación de datos

El objeto del presente documento es servir de Pliego de Bases Técnicas para la contratación de los servicios necesarios para cumplir con los requerimientos anteriores.


2 Objeto del contrato

2.1 Objeto y alcance del servicio

De acuerdo a lo indicado anteriormente, el objeto de este pliego es la contratación a una empresa del sector, en modalidad de CONTRATO CERRADO, para la realización del análisis, diseño, construcción y puesta en marcha de los sistemas de información para el despliegue del Sistema de Gestión de Centros Alimentarios en Euskadi, e integrarlo con la infraestructura de PLATEA Tramitación.

Los requerimientos principales que ayudan a concretar el alcance de los servicios a prestar se detallan en el apartado Descripción del servicio. Asimismo, el conjunto de los entregables resultantes de los trabajos definidos como alcance del servicio se explicarán posteriormente dentro del apartado Descripción de entregables del presente documento.

2.2 Descripción del servicio

Para la consecución de los objetivos marcados dentro del apartado de Objeto y alcance del servicio será necesario realizar una serie de tareas que se concretarán en el siguiente apartado de Contenido dentro del presente Pliego de Bases Técnicas.


3 Contenido

3.1 Situación actual

Tal y como se ha comentado en el apartado introductorio, el Departamento de Sanidad y Consumo cuenta con una aplicación que cubre gran parte de la funcionalidad necesaria para dar soporte a los procesos relacionados con la gestión de Registro de Centros Alimentarios.

Actualmente la aplicación P41-Centros Alimentarios es la herramienta utilizada para automatizar el proceso de normalización de todas las actividades de inspección y control sanitario de establecimientos alimentarios. La Dirección de Salud Pública gestiona un elevado número de establecimientos alimentarios (aproximadamente 22.000) y de técnicos que intervienen en su control (más de 150). Y en el tiempo de vida de la aplicación se han gestionado más de 130.000 inspecciones. El actual sistema de información permite:

• Contar con un censo actualizado de centros alimentarios.

• Disponer, de cada establecimiento, los datos referidos a:

Situación sanitaria (a través de los datos de protocolo).

Clasificación del establecimiento según riesgo (Clasificación que vendrá generada por el histórico de inspecciones, alimentos que manipula, resultado de inspección, etc.)

Expedientes sancionadores.

• Recoger los datos por sector (cárnico, pesquero,…) con la finalidad de realizar evaluaciones a nivel comarcal, territorial y de la CAPV.

• Realizar la planificación anual de inspecciones de centros.

• Gestionar las autorizaciones sanitarias y los registros sanitarios de alimentos.

• Contar con un sistema de seguimiento de las alertas y denuncias alimentarias.

• Gestionar, dentro del mapa de proceso, las instrucciones técnicas y los manuales de procedimientos generales y específicos necesarios para cada actividad.

• Realizar inspecciones con dispositivos TabletPC con sistemas de sincronización.

• Gestionar la documentación asociada a los establecimientos, inspecciones y solicitudes.

• Gestionar los usuarios y perfiles de acceso a la aplicación dependiendo de sus roles.


Los usuarios que acceden a la aplicación pertenecen a los siguientes grupos:

• Dirección de Salud Pública.

• Subdirecciones de Salud Pública en cada Territorio Histórico.

• Comarcas.

• Inspectores.

A continuación realizamos una breve descripción de los módulos que cubre la aplicación existente con el objeto de que sirva para ayudar a entender el ámbito y alcance de los trabajos concernientes a este Pliego de Bases Técnicas.

3.1.1. Aplicación de Registro de Centros Alimentarios (P41)

Cobertura funcional

La aplicación de Gestión de Registro de Centros Alimentarios está compuesta por los siguientes módulos:

1. Parametrización General

Recoge todas aquellas tablas necesarias para el correcto funcionamiento de la aplicación.

Realiza el mantenimiento (alta/baja/modificación) sobre las diferentes entidades manejadas por el sistema y permite realizar sobre ellas las siguientes acciones: búsquedas, descarga Excel, imprimir y ayudas.

Siguiendo el esquema anterior, aunque adaptándose a las particularidades de cada caso, el aplicativo permite el mantenimiento de los conjuntos de datos asociados a las siguientes entidades agrupadas según la siguiente relación:

1.1. Tipos de objeto

1.2. Tablas de tabla

1.2.1. Tabla de Documentos a Presentar

1.2.2. Tabla de Tipos de Documentos

1.2.3. Tabla de Agrupaciones de Protocolos

1.2.4. Tabla de Tipos de Origen de Denuncia

1.2.5. Tabla de Tipos de Alertas

1.2.6. Tabla de Categorías de Productos

1.2.7. Tabla de Tipos de Peligros

1.2.8. Tabla de Naturaleza del Peligro.

1.2.9. Tabla de Resultados de Inmovilizaciones

1.2.10. Tabla de Títulos de Representantes


1.2.11. Tipo de Solicitud

1.2.12. Documentos a Presentar en una Solicitud

1.2.13. Motivos de Documentación Incompleta

1.2.14. Tipos de Defecto

1.2.15. Acciones a realizar sobre una alerta

1.3. Subdirecciones-Comarca-Municipios

1.4. Contadores

1.5. Calendarios

1.6. Tipos de fechas

2. Claves

Permite la configuración de todas aquellas tablas relacionadas con las claves a las que pertenece un establecimiento.

2.1. Sectores

2.2. Categorías

2.2.1. Categorías

2.2.2. Categorías por sector

2.3. Actividades

2.3.1. Actividades

2.3.2. Actividades por sector

2.3.3. Actividades por categoría y sector

2.4. Documentos a presentar por tipo de solicitud

3. IT

En esta sección se definirán las distintas Instrucciones Técnicas y los Protocolos que las componen. Estas son las directrices necesarias para realizar una Inspección.

Acciones permitidas para Instrucciones Técnicas: visualizaciones, altas, modificaciones, bajas, anulaciones de Instrucciones Técnicas, búsquedas, descarga Excel, imprimir y ayudas.

3.1.1. Generales

3.1.2. Específicas

3.1.2.1. Claves IT

4. Solicitudes

4.1. Relación de solicitudes

Esta opción permite acceder al listado de las solicitudes que se encuentren en estado no final.


Se mostrarán las Solicitudes que pertenezcan al Establecimiento seleccionado y todas aquellas que no estén en un estado final.

Acciones permitidas para las Solicitudes son las siguientes: ver los datos de una solicitud, altas, anexiones de documentos, visualizaciones de documentos anexados, listado de fechas de vencimiento, listado de Documentos presentados, de histórico de actuaciones, los Establecimientos e Inspecciones asociados, búsquedas, descarga Excel, imprimir, ayudas.

5. Establecimientos

5.1. Relación de establecimientos

Esta opción permite acceder al listado de aquellos establecimientos que no se encuentren en un estado final.

Acciones permitidas para los establecimientos: visualizaciones, altas, modificaciones, anexiones de documentos, visualizaciones de documentos, listado de fechas de vencimiento, de histórico de actuaciones, ir a inspecciones, ir a denuncias, ir a expedientes sancionadores, de claves, ir a solicitudes, ampliaciones de plazos de autorizaciones, listado de historia de establecimientos, búsquedas, descarga Excel, imprimir, ayudas y verificaciones de convalidaciones.

5.2. Fechas de vencimiento

5.3. Histórico de actuaciones

5.4. Claves

5.5. Historia de establecimientos

6. Expedientes Sancionadores

6.1. Relación de expedientes sancionadores

Esta opción permite acceder al listado de expedientes sancionadores.

Acciones permitidas para los establecimientos: visualizaciones, altas, modificaciones,.., de histórico de actuaciones, ir a inspecciones, listado de historia de establecimientos, búsquedas, descarga Excel, imprimir, ayudas.

7. Inspecciones

7.1. Parametrización

7.1.1. Valoraciones

7.1.2. Tipos de actividad

7.1.3. Valoraciones por tipos de actividad

7.1.4. Clasificación Higiénico-Sanitaria

7.1.5. Clasificación de Establecimientos

7.1.6. Tipos de Inspecciones

7.1.7. Tipos de Inspecciones por Deficiencias


7.1.8. Frecuencias de Inspección

7.1.9. Evaluación por Tipo de Inspección

7.1.10. Pasa Ciclo HACCP

7.1.11. Puntuación por HACCP

7.2. Relación de Inspecciones

Este módulo se encarga de establecer los requisitos y actividades previas que de manera general deben tener en cuenta los Inspectores a la hora de planificar las inspecciones a establecimientos alimentarios, así como las pautas a seguir durante la inspección propiamente dicha y todos aquellos criterios que deben aplicarse a la hora de cumplimentar y tramitar la documentación generada por la misma.

Se trata de planificar previamente la inspección a realizar y dotarse del material necesario para ello. Además se tramitan y archivan los documentos que contienen la información recabada durante la inspección, de acuerdo a unos criterios preestablecidos.

Acciones permitidas para las inspecciones: Visualizaciones, altas, modificaciones, anexar documentos, ver documentos anexados, listado de establecimientos, evaluar inspecciones, imprimir inspecciones, clasificaciones, ver clasificaciones, finalizar inspecciones, histórico de actuaciones, búsquedas, descarga Excel, imprimir y ayudas.

Además este proceso podrá ser llamado desde otros procesos, como por ejemplo Relación de Alertas, Relación de Denuncias...

8. Alertas

8.1. Parametrización

8.1.1. Naturaleza por tipo de peligro

8.1.2. Tipos de Valoración por Alertas

8.1.3. Notificaciones

8.1.3.1. Plazas

8.1.3.2. Tipos de Notificación

8.1.3.3. Plazas por Tipo de Notificación

8.2. Relación de Alertas

Esta opción permite acceder al listado de las Alertas. Se mostrarán solo aquellas que no se encuentren en estado final.

Acciones permitidas para alertas son: visualizaciones, altas, modificaciones, anexiones de documentos, visualizaciones de documentos, listado del histórico de actuaciones, listado de establecimientos afectados, listado de inspecciones, finalizar alerta, acciones a realizar, notificaciones a subdirecciones, notificaciones a comarcas, búsquedas, descargas a Excel, impresiones y ayudas.

8.2.1. Establecimientos Afectados

Se mostrará el listado de establecimientos afectados por una Alerta.


8.2.2. Productos Afectados

Se mostrará el listado de Productos afectados asociados a un establecimiento y una alerta concreta.

8.2.3. Lotes Inmovilizados

Mostrará la información correspondiente a los lotes inmovilizados, cuando se selecciona un producto afectado por una alerta.

8.2.4. Proveedor Afectado

Mostrará la información correspondiente a los proveedores afectados, cuando se selecciona un producto afectado por una alerta.

9. Denuncias

9.1. Relación de Denuncias

Esta sección es el proceso principal de la gestión de denuncias y desde donde se van a realizar la mayoría de las acciones sobre las diferentes denuncias.

Acciones permitidas para la relación de denuncias: visualizaciones, altas, modificaciones, búsquedas, anexar documentos, visualizar documentos anexados, visualización de inspecciones, generar inspecciones, finalizar denuncias, información del Establecimiento, descarga Excel, imprimir y ayudas.

10. Estados y Actuaciones

Este módulo no es específico de un área concreta sino que pretende ser un módulo utilizable por cualquier área. El módulo de Estados y Actuaciones permitirá gestionar los estados en los que se pueden encontrar un objeto (solicitud, inspección, alerta, etc.) así como las actuaciones realizadas con ellos.

10.1. Estados

10.2. Estados por Tipos de Objetos

10.3. Actuaciones

10.4. Autorización de Actuaciones a Perfiles

10.5. Autorización de Actuaciones a Usuarios

10.6. Actuaciones por Objeto

10.7. Estados por Actuación y Objeto


11. Seguridad

El módulo de Seguridad y Auditoría tiene como misión principal gestionar, organizar y controlar el acceso de los diferentes usuarios, así como facilitar el seguimiento y auditoría de las diferentes aplicaciones, permitiendo garantizar un nivel adecuado de seguridad en dichas aplicaciones.

11.1. Perfiles

Podría definirse los siguientes tipos de Perfiles de Usuario:

11.1.1. Perfil Administrador.

Este perfil se ha asignado a todos los usuarios de la aplicación cuya ubicación son los Servicios Centrales del Departamento en Lakua. Tendrá acceso a TODOS los procesos de la aplicación.

11.1.2. Perfil para las Subdirecciones.

Este perfil se ha asignado a todos los usuarios de la aplicación cuya ubicación son las diferentes Subdirecciones dependientes del Departamento de Sanidad. Tendrán acceso a todos los procesos de la aplicación, excepto a aquellos que sirven para configurarla adecuadamente. Básicamente accederán a los listados de Establecimientos, Inspecciones, Alertas, Denuncias y Expedientes Sancionadores.

A cada usuario se le asignarán restricciones por Subdirección, no permitiendo que vea datos de las demás Subdirecciones.

11.1.3. Perfil para los Coordinadores Comarcales.

Este perfil tendrá acceso a los mismos procesos que en el caso del perfil para las Subdirecciones pero los datos que podrá consultar y manipular estarán restringidos a nivel de Comarca.

11.1.4. Perfil para los Técnicos de Salud Pública.

Este perfil se ha definido para los Inspectores dependientes tanto de las Comarcas como de las Subdirecciones.

11.1.5. Perfil para los Administrativos.

Podrán acceder a solicitudes, inspecciones y establecimientos.

11.2. Usuarios

11.3. Procesos

11.4. Procesos por Perfiles

11.5. Restricciones de Acceso

11.5.1. Por Subdirección

11.5.2. Por Comarca

11.5.3. Por Inspector

11.5.4. Por Sección

11.5.5. Por Tema


11.6. Log Auditoria

11.7. Tablas a Auditar

12. Documentación

La Gestión de Documentación tiene como objetivo gestionar documentos (de Word, Excel, Power Point, pdf, o cualquier documento escaneado) y relacionarlos con objetos de las aplicaciones, entendiendo por objeto una solicitud, una inspección, un contrato, etc.

Además también deberá permitir la generación y mantenimiento de documentación a incluir como puntos de menús dentro de cualquier aplicación, como por ejemplo, la relativa a las ayudas, procedimientos, normativas, etc. que deberán estar accesibles en cualquier momento para el usuario.

Primeramente será necesario definir en el sistema las diferentes tablas que se encargaran de que todo el sistema de documentación funcione correctamente. De esta manera será posible:

Ordenar todos los documentos existentes en la base de datos

Poder generar convenientemente los puntos de menú de documentación, con sus correspondientes documentos.

12.1. Secciones y Temas

12.2. Documentos

La información completa correspondiente a los módulos de la aplicación, se encuentra recogida en el Manual de Usuario de la aplicación que se incluye como anexo al presente Pliego de Bases Técnicas.

Datawarehouse

Adicionalmente a las funcionalidades mencionadas con anterioridad, asociado a la aplicación P41 existe un DatawareHouse basado en la herramienta Business Objects con información agregada para su explotación por diferentes tipologías de usuarios.

El periodo de extracción de informes puede ser anual, semestral, trimestral, mensual o diario. Y la información puede explotarse a nivel general de la CAPV o desglosarse a nivel territorial, comarcal o incluso a nivel de Técnico de Salud Pública.

A continuación se listan algunos de los informes predeterminados existentes en el Sistema Informacional:

- PG. 06-03 Informe Anual Seguimiento Planes de control comarcal.rep

- PG. 06-04 Informe Semestral consolidación datos territorial.rep

- PG. 06-01-1 Seguimiento Individual de Planes de control.rep

- PG. 06-02 Informe Trimestral Seguimiento Planes de control comarcal.rep

- PG. 06-06 Informe Anual Seguimiento Planes de control territorial.rep

- PG. 06-07 Informe Semestral consolidación datos CAPV.rep

A continuación se muestran algunos ejemplos de informes existentes en el Sistema Informacional:


- Informe Anual de Seguimiento de Planes de Control, a nivel de Comarca:

- Informe Anual Seguimiento Planes de control territorial:


- Informe Semestral Seguimiento Planes de control CAPV:

Componentes tecnológicos

La aplicación P41 está desarrollada sobre la infraestructura WebLogic Sever 8.1 utilizando un framework propio creado para la gestión de mantenimientos en J2EE y sus correspondientes clases para controlar el


acceso a BD. Este framework genera gran cantidad de código poco versátil y difícil de personalizar y mantener.

De modo esquemático, los componentes tecnológicos que conforman la solución anterior se resumen en la siguiente tabla:

Componentes tecnológicos

Concepto Descripción

Plataforma base • Servidor web: Apache 2.X

• Servidor de aplicaciones: BEA WebLogic Server 8.1

• Base de datos: Oracle 8

• Procesos batch: PL/SQL

• Análisis del Datawarehouse: Business Objects 5.1.7

• Productos de Office utilizados: MS Excel 2003 y MS Word 2003

• Arquitectura: Aplicación Web Intranet

• Integrada con las aplicaciones externas: Q33.

• Infraestructura común EJGV: XLNETs, Control-M, K31.

Estado actual de implantación

Todas las funcionalidades comentadas con anterioridad se encuentran productivas y estables.

3.2 Objetivos a alcanzar

La ejecución de las tareas a realizar dentro del ámbito de la futura contratación debe ir encaminada a la consecución de unos objetivos que figurarán como requerimientos a cumplir. Dichos requerimientos deberán ser concretados en la fase de Análisis del proyecto que se derive de la contratación de los servicios a propósito del presente Pliego de Bases Técnicas.

Estos requerimientos explícitos para el nuevo sistema de información deberán complementarse con el resto de requerimientos comunes a los proyectos de Desarrollo e Implantación de Sistemas de Información liderados por EJIE, que son explicitados en este documento en sus apartados correspondiente. Por ejemplo aquellos relativos a la Entorno Tecnológico, Metodología de Desarrollo y Pruebas, etc.

Con la finalidad de estructurar de un modo claro los requerimientos específicos a cumplir por el adjudicatario final del proyecto, detallamos los mismos en unas tablas agrupándolos según la siguiente disposición:


3.2.1. Gestión de Centros Alimentarios de la CAPV

Nuevo sistema de información para la Gestión de Centros Alimentarios de Euskadi

La aplicación de Registro de Centros Alimentarios de la CAPV recogerá la información relativa a los Establecimientos Alimentarios. Esta información debe estar validada por las entidades competentes a tal fin, y se aportarán mecanismos para garantizar que resulte correcta y coherente.

Dentro de este apartado se detallan los requerimientos que tiene que cumplir.

ID Requerimiento Requerimiento Descripción detallada

NEC-001 Gestión de las tomas de muestras Necesidad de crear un nuevo módulo en la aplicación, que gestione las tomas de muestra enviadas a los laboratorios.

• Realizar un seguimiento de las muestras de alimentos recogidas y de sus resultados.

• Los análisis pertenecientes a fuera de la CAPV deben poder introducirse en la aplicación.

NEC -002 Integración con el Ministerio de Sanidad, Política Social e Igualdad (AESAN).

• Comunicación con el Ministerio de Sanidad a través de Jaso, con los servicios que se determinen para garantizar la interoperabilidad entre los sistemas de información.

• Dentro del nuevo sistema de Registro General Sanitario de Alimentos, se va a facilitar la carga automática de ficheros de importación a través del lenguaje de etiquetado XML, para dar de alta y modificar tanto datos de empresas como de productos en la nueva base de datos implementada por el Ministerio.


Para ello, la aplicación debe generar automáticamente estos ficheros XML definidos por el ministerio, para enviarlos al Registro General Sanitario. Y a su vez, la nueva aplicación debe estar preparada para recibir ficheros XML enviados por el Ministerio.

Ahora mismo, estos datos deben introducirse manualmente por los usuarios del Dpto. en el Registro General Sanitario, provocando la duplicidad el trabajo, al tener que mantenerlos en dos aplicaciones.

NEC -003 Modificación del procedimiento de solicitudes.

Modificación del flujo de las solicitudes, permitiendo la modificación de una solicitud cuando se encuentra en estado ‘Pte. Completar’.

NEC -004 Modificación del procedimiento de alertas. Modificar el flujo de las alertas de tipo ‘’Información’ para que no sea necesario cerrarlas, únicamente se enviarán con carácter informativo.

NEC -005 Independizar la clasificación de establecimientos de la CAPV de la clasificación del RGSEAA.

• Elaboración de un nuevo listado de claves categorías y actividades para proceder al registro de establecimientos alimentarios en el Registro de Establecimientos Alimentarios de la CAV (REACAV) y/o en el Registro General Sanitario de Establecimientos Alimentarios y Alimentos (RGSEAA).

• La clasificación utilizada por el REACAV tiene que funcionar de forma independiente a la clasificación del RGSEAA. Aunque estará vinculado a nivel de intercambio de documentación y claves con el Ministerio.


NEC -006 Actuaciones masivas • Permitir realizar actuaciones masivas para gestionar documentación y modificaciones de estados y actuaciones.

NEC -007 Adaptación al nuevo “Sistema Normalizado de Control Oficial de Establecimientos Alimentarios en la CAPV”, para adecuarse al Real Decreto 191/2011 del 18 de Febrero, sobre Registro General Sanitario de Empresas Alimentarias y Alimentos.

Esto implica:

• La eliminación de las solicitudes periódicas de convalidación.

• La creación de una nueva figura de inicio de actividad de establecimientos denominada “comunicación previa de inicio de actividad” (distinta a la solicitud de autorización).

• La exigencia de que los establecimientos cuya actividad esté ligada a productos de origen animal (POAS), presenten una solicitud de autorización y de inspección favorable para su autorización. No así los establecimientos que no operan con productos de origen animal (NO POAS), los cuales no están obligados a presentar solicitud, sino comunicación previa de inicio de actividad.

• Los POAS serán autorizados tras la inspección favorable e incluidos en el REACAV y el RGSEAA, los NO POAS, no requieren ser autorizados aunque también serán incluidos en el REACAV y el RGSEAA.

• Los establecimientos que hasta el momento se incluían en los sectores 91, 92, 93, 94 y 95 no están obligados a realizar una solicitud, ni a tener autorización expresa, aunque si deben ser incluidos en el REACAV, tras presentar una comunicación previa de inicio de actividad.

NEC -008 Integración con PLATEA Tramitación • Digitalizar los trámites que actualmente se gestionan desde las oficinas comarcales. Proporcionando a los ciudadanos y empresas la posibilidad de realizar sus trámites accediendo a un nuevo servicio publicado en el portal de la Sanidad Pública Vasca (o Sede Electrónica general del Gobierno Vasco), donde podrá consultar las gestiones que ha


efectuado independientemente del canal utilizado (presencial o telemática).

Ofreciendo la opción de realizar

o Solicitudes de autorización inicial de establecimientos.

o Consultar el estado de las solicitudes realizadas.

o Aportar documentación requerida.

o Etc.

• Implementar los procedimientos que ahora gestiona la aplicación mediante el Modelo C de PLATEA Tramitación. En el apartado Anexo A.Procedimientos a implementar mediante PLATEA Tramitación se indican cuáles son estos procedimientos.

NEC -009 Integración con Firma Electrónica • Incorporar la firma digital en los informes generados por la aplicación, eliminando la actual necesidad de firmar manualmente los documentos.

NEC -010 Migración de la aplicación al callejero de NORA.

• Migración de la aplicación al nuevo callejero del Eustat, pasando a trabajar con NORA.

• Migración de la codificación de Q33 a la codificación que utiliza NORA.

NEC -011 Gestión documental • Utilizar un gestor documental para manejar toda la documentación asociada a solicitudes, expedientes y establecimientos que ahora se adjunta en la aplicación.

NEC-012 Migración de datos • La nueva herramienta de Registro de Centros Alimentarios presenta un cambio drástico tanto en arquitectura como en su concepción de base, sobre todo en lo relativo a los aspectos de tramitación. No obstante, esto no oculta la necesidad de contar en el nuevo sistema de información de la información histórica.


• Deberá, por tanto, contemplarse dentro del alcance del proyecto el desarrollo de una migración de la información de aquellos aspectos que, en la fase de análisis, se consideren pertinentes y necesarios para dar soporte a las funcionalidades de negocio requeridas por los usuarios.

3.2.2. Explotación de datos

Explotación de datos

Una de las partes más importantes de la nueva plataforma será dotarla de las funcionalidades para analizar la información almacenada en la plataforma. Esta plataforma no ha de serlo únicamente entre los diferentes módulos que conforman la aplicación, sino también con los sistemas terceros de los que se requiera información o funcionalidad concreta.

Para poder realizar un análisis completo de la información almacenada, será necesario contar con información de los diferentes sistemas transaccionales, historificada o no, así como de información agregada en un Datawarehouse que permita un análisis “multidimensional”. Dicho análisis de la información podrá realizarse a través de informes predefinidos, procedimientos de “Query ad-hoc” o incluso de cuadros de mando.

Los detalles de la explotación de datos necesaria serán definidos en la fase de análisis del proyecto.


EXPL-001 Información del sistema transaccional Todos los módulos a implantar dentro del proyecto deberán contar con funcionalidades de consultas concretas sobre el sistema transaccional, esté esta información en la BBDD de la operativa general o almacenada como histórico.


Las consultas y funcionalidades concretas a realizar se concretarán en la fase de análisis del proyecto.

EXPL-002 Integración con otras fuentes de información

Si, para tener una visión completa de la información, se necesita integrarse con sistemas terceros más allá de los diferentes módulos que conformen la plataforma, las funcionalidades de explotación de datos tendrán que contemplar dichas integraciones.

EXPL-003 Herramienta de explotación de datos La solución de explotación de datos deberá estar basada en Oracle Business Intelligence Enterprise Edition 11g.

EXPL-004 Datawarehouse La nueva plataforma de Registro de Centros Alimentarios deberá incorporar una solución de Datawarehouse que contenga los datos agregados entre otras de las siguientes fuentes:

• Fuentes principales:

o Solicitudes

o Notificaciones

o Establecimientos

o Alertas

o Denuncias

o Inspecciones

• Fuentes secundarias:

o Base de datos poblacional

o Datos maestros (estados, actuaciones, inspectores, claves, categorías, actividades,


protocolos, etc.)

EXPL-005 Procedimientos de carga del Datamart Los procedimientos de carga del Datamart deberán ser totalmente parametrizables para facilitar su posterior mantenimiento. Para el desarrollo de los procedimientos de ETL deberá valorarse el uso de la herramienta estandarizada en la actualidad por la Dirección de Informática y Telecomunicaciones para este fin: Oracle Warehouse Builder aunque, si procede, podrán proponerse otras como Oracle Data Integrator quedando para la fase de arquitectura de la solución del proyecto la concreción de la misma por parte de la Dirección del Proyecto de EJIE

EXPL-006 Informes. Requerimientos generales La nueva plataforma de Registro de Centros Alimentarios deberá proporcionar los informes necesarios para cubrir los escenarios de negocio que se definan en la fase de análisis del proyecto. Dichos informes deberán poder realizarse contra los datos de la Base de Datos transaccional (incluyendo los registros historificados) así como contra la información agregada en el Datawarehouse/Datamarts

EXPL-007 Informes. Interactividad Los informes generados podrán ser tanto interactivos como información estática en función de las necesidades de negocio. Estos últimos, a su vez, deberán ser exportables a diferentes formatos como .pdf, .html, etc.

EXPL-008 Informes. Planificación y publicación Aunque esta necesidad deberá concretarse en la fase de análisis del proyecto de implantación, deberá cubrirse el escenario de generación planificada de informes y posterior almacenamiento, envío y/o publicación en un portal de informes.

EXPL-009 Query ad-hoc La información agregada almacenada en el Datamart deberá ser objeto de ser explotada por herramientas de "Query ad-hoc" por los diferentes usuarios identificados en función de su perfil. No obstante, dentro del entregable del proyecto deberán generarse las queries y procedimientos de análisis más habituales para su reutilización por los usuarios que convenga.

EXPL-010 Seguridad La totalidad de la información manejada en la explotación de datos deberá tener los controles de seguridad que se definan: autenticación, autorización, control de acceso a datos, etc. Asimismo, el acceso a la información deberá cumplir con lo descrito en la LOPD proporcionando, en su caso, las soluciones de auditoría que se definan.


3.2.3. Seguridad

Seguridad

Los sistemas de información del Gobierno vasco incorporan controles de seguridad que cubren los aspectos generales de: autenticación, autorización, control de acceso a datos, etc. Esta característica de seguridad será transversal a la totalidad de las funcionalidades contempladas dentro de la plataforma y deberá integrarse con XLNets como sistema general de seguridad de acceso a las aplicaciones del Gobierno Vasco.

ID Requerimiento

Requerimiento Descripción detallada

SEGU-001 Controles generales La totalidad de las funcionalidades proporcionadas por cada uno de los módulos deberán contar con el control de acceso que se defina en el análisis funcional garantizando los procesos de:

• Autenticación

• Autorización

• Control de acceso a datos concretos

• Auditoría de acceso a la información

Los procesos anteriores deberán poder realizarse tanto a través de usuario/contraseña como con certificados digitales.

SEGU-002 Integración con XLNets La plataforma deberá integrarse con el repositorio de seguridad horizontal del Gobierno XLNets


para la consecución de los objetivos anteriormente mencionados.

SEGU-003 Mecanismo de contingencia En aquellos casos que así se requiera, los controles de seguridad deberán proporcionar un mecanismo alternativo a utilizar en escenarios de contingencia, no sólo de Sistemas de Información, sino también ante posibles extravíos de tarjetas, etc.

SEGU-004 Firma electrónica Ciertos módulos funcionales, integrados con Teletramitacion, precisarán de funcionalidad de Firma Electrónica. Dicha funcionalidad deberá ser proporcionada a través de los servicios de firma estándares utilizados por las aplicaciones del Gobierno Vasco.

SEGU-005 Auditoría y trazabilidad Adecuándose a la normativa de la LOPD, los sistemas deberán guardar una trazabilidad de acceso y modificación de los datos albergados por el aplicativo. Para ello, podrán ayudarse de la solución horizontal de Oracle Selective Audit (OSA) para las aplicaciones del Gobierno Vasco.

SEGU-006 Seguridad. Seguridad perimetral y encriptación de la información.

La solución propuesta a implantar deberá asimismo definir los escenarios de seguridad perimetral, acceso a datos concretos, encriptación de información, etc. La solución propuesta deberá ser validada por los responsables de EJIE a nivel técnico y del equipo jurídico del Departamento de Sanidad para los componentes legales.

SEGU-007 Niveles y mecanismos de exposición de las funcionalidades

Los escenarios de seguridad planteados deberán contemplar no sólo los Sistemas de Información sino también la seguridad y exposición de la funcionalidad a través de los diferentes canales de comunicación.


3.2.4. Requerimientos técnicos generales

Requerimientos técnicos generales

Dentro de este apartado plasmamos los requerimientos tecnológicos generales y tareas asociadas que deben llevarse a cabo por parte del proveedor adjudicatario del presente Pliego de Bases Técnicas.


TECN-001 Arquitectura general del sistema Las ofertas recibidas como respuesta al presente Pliego de Bases Técnicas deberán definir la arquitectura general del sistema propuesto cubriendo:

• Plataformas base necesarias y/o compatibles para la solución propuesta: Sistema operativo, Servidores de Aplicaciones, Sistemas gestores de base de datos, etc.

• Arquitectura general del sistema: descomposición en capas del sistema, despliegue de los diferentes componentes, exposición de las diferentes funcionalidades, etc.

• Entornos contemplados: desarrollo, pruebas, integración, preproducción, formación, etc.

• Dimensionamiento aproximado de los elementos físicos necesarios (hardware, almacenamiento, comunicaciones, etc.) para dar soporte a la funcionalidad requerida

• Otros aspectos que las empresas ofertantes consideren de interés para la correcta valoración de la oferta.

Asimismo, dentro del alcance de las tareas a realizar, deberá terminar de concretarse la arquitectura del sistema adecuándose a las particularidades de los Sistemas de Información del


Gobierno Vasco.

TECN-002 Integración en los procesos actuales Los trabajos a realizar, deberán contemplar las tareas necesarias para el trabajo según los estándares y procedimientos de gestión del Gobierno Vasco. Entre otros:

• Herramientas de compilación y despliegue

• Traspaso entre entornos

• Procedimientos de backup y recuperación

• Monitorización de los sistemas

• Identificación y gestión de incidencias y problemas

TECN-003 Rendimiento y soporte de carga El sistema a implantar deberá ser capaz de soportar la carga y proporcionar el rendimiento necesario. Para ello:

• Dentro del proyecto deberán fijarse los SLA requeridos para cada uno de los servicios a proporcionar y, en caso de requerir del uso de servicios de terceros, fijar los SLA requeridos para cada uno de dichos servicios externos.

• La plataforma deberá estar diseñada y desarrollada para el soporte de dichos requerimientos.

• Los diferentes elementos deberán estar preparados para funcionar en esquemas de reparto de carga para ser capaces de soportar, no sólo los requerimientos derivados de un uso habitual de la herramienta, sino también los "picos" de actividad que pudieran darse.

• Dentro de los procedimientos de calidad, deberán realizarse las pruebas de carga y rendimiento del sistema necesarios para garantizar esta condición.


TECN-004 Monitorización y análisis de métricas Con el objeto de analizar y detectar posibles anomalías en el comportamiento del sistema, la nueva plataforma deberá dotarse de sistemas de monitorización y análisis de métricas que permitan realizar las tareas anteriores.

TECN-005 Escalabilidad y procedimiento de gestión de la capacidad

La plataforma deberá ser altamente escalable, tanto desde su diseño como para el despliegue posterior de la misma. Deberá fijarse el procedimiento de escalabilidad así como un procedimiento de "gestión de la capacidad" que permita a los equipos de soporte de sistemas del Gobierno Vasco realizar las acciones necesarias que sean requeridas para escalar en aquellos casos que así se determinen.

TECN-006 Alta disponibilidad y contingencia La solución deberá funcionar en escenarios de "alta disponibilidad" así como en escenarios de "contingencia". Para ello, además de la preparación de la plataforma desde su análisis/diseño/desarrollo hasta su implantación final, deberán realizarse las adaptaciones necesarias del sistema para la integración del mismo en el Plan de Continuidad de Negocio de los Sistemas de Información del Gobierno Vasco.

TECN-007 Uso de estándares Para la totalidad de la integración, deberán primarse y valorarse el uso de estándares de integración como:

• Estándares como HL7

• WS-Profile

Esta orientación hacia el uso de estándares no se circunscribirá únicamente al escenario de integración con sistemas terceros sino que aplicará a la totalidad de los componentes de la nueva plataforma.


TECN-008 Mecanismo y naturaleza de las integraciones

Los escenarios de integración podrán ser síncronos, asíncronos, procedimientos de extracción y carga, replicación de datos, etc. Deberá definirse el mecanismo de integración a utilizar en cada caso y realizar las acciones necesarias para la consecución de los objetivos marcados.

Las tecnologías de integración deberán adaptarse, en la medida de lo posible, a las herramientas y estrategias de integración existentes en los sistemas de información del Gobierno Vasco

En el caso de sistemas terceros, se deberán llegar a los acuerdos que sean precisos en dichas situaciones.

TECN-009 Uso de sistemas horizontales del Gobierno Vasco

Siempre que sea necesario cubrir determinada funcionalidad, la nueva plataforma deberá primar el uso de los sistemas horizontales del Gobierno Vasco como es el caso de:

• XLNets como sistema de seguridad para la autenticación/autorización de los usuarios. • Oracle Selective Audit (OSA) como solución de auditoría de acceso a datos. • Uso de los servicios proporcionados por Izenpe como CA: Firma electrónica, TSA, etc.

La imposibilidad de la no utilización de dichos sistemas horizontales, deberá quedar convenientemente justificada en cada caso y validada a posteriori por los equipos de EJIE competentes al efecto.

TECN-010 Entorno tecnológico base El entorno tecnológico para la construcción será el siguiente: • Módulo transaccional:

o JEE sobre WebLogic Server 11g o Oracle Database 10g como repositorio de Base de Datos

• Módulo analítico o OBIEE 11g como herramienta BI o Oracle Database 10g como respositorio de Base de Datos.

TECN-011 Compatibilidad con los navegadores La totalidad de las funcionalidades contempladas deberá construirse bajo los criterios de compatibilidad con los navegadores Internet Explorer 8+ , Firefox 3+ y Google Chrome 9.


3.2.5. Otros requerimientos

Otros

En este apartado se recogen otros requerimientos que, no pudiendo ser clasificados dentro de ninguno de los grupos anteriores, entran dentro del alcance de las tareas a realizar para dar solución a los requerimientos planteados dentro de este Pliego de Bases Técnicas.

ID Requerimiento

Requerimiento Descripción detallada

OTRO-001 Despliegue. Plan de despliegue El despliegue de la nueva plataforma de Registro de Centros Alimentarios deberá realizarse teniendo en consideración a diferentes actores (establecimientos alimentarios, coordinadores, inspectores, técnicos de salud pública, etc.) y factores (estado de los sistemas, despliegue de las comunicaciones).

Se requerirá realizar un plan de despliegue. Éste incluirá tanto una estrategia como una planificación, de manera conjunta con los diferentes colectivos implicados.

OTRO-002 Despliegue. Seguimiento del despliegue Una vez definido del plan de despliegue, deberá realizarse el seguimiento correspondiente incluyendo:

• Seguimiento del estado de las diferentes tareas

• Detección de problemas o riesgos

• Fijar responsabilidades para las acciones correctivas en cada caso


• Ejecución de las tareas que, dentro del proceso de despliegue, sean competencia del proyecto a realizar tras la adjudicación del presente Pliego de Bases Técnicas

OTRO-003 Despliegue. Soporte al despliegue Tras la puesta en producción del sistema, y hasta el despliegue final del mismo, deberá existir un equipo de soporte a dicho proceso de despliegue. Dentro de sus responsabilidades estarán las siguientes:

• Soporte correctivo de los aplicativos

• Soporte adaptativo de los aplicativos

• Soporte funcional a los usuarios

• Adaptación del sistema para su adecuación a la fase de despliegue

OTRO-004 Despliegue. Soporte post-producción Posteriormente al despliegue final del sistema de información, deberá proporcionarse un periodo de soporte post-producción tanto a los usuarios finales como a los equipos técnicos definidos por la Dirección de Proyecto de EJIE, incluyendo aquellos aspectos de mantenimiento evolutivo que se determinen.

Este periodo de soporte deberá tener una duración mínima de tres meses tras la finalización de la última fase del despliegue y garantizar los tiempos de respuesta y calidad de servicio definida por la Dirección del proyecto de EJIE.

La naturaleza de este servicio deberá quedar reflejada en las ofertas que se presenten en respuesta al presente Pliego de Bases Técnicas.

OTRO-005 Formación Deberá formarse a los usuarios finales de los diferentes sistemas de información, así como a los responsables del mantenimiento del mismo. Deberá establecerse, por tanto, un plan de formación e impartirse los cursos o charlas que se fijen dentro de este plan.


OTRO-006 Contingencia. Definición y acciones necesarias

La criticidad de la nueva plataforma de Registro de Centros Alimentarios precisa de la definición de un plan de contingencia y de unas acciones que deberán llevarse a cabo para que las diferentes situaciones contempladas puedan soportarse.

Deberán definirse las diferentes contingencias que pueden darse en los escenarios de negocio impactados por la implantación de la nueva plataforma, procedimientos a llevar a cabo en cada caso, y dotar a los sistemas de información de las funcionalidades necesarias para poder soportar los requerimientos planteados.

OTRO-007 Faseado del proyecto Podrán contemplarse diferentes fases en la construcción y despliegue de la solución en los diferentes entornos si así se considera necesario. Este faseado no podrá en ningún caso implicar variaciones en el coste asociadas siendo potestad de EJIE el tomar la decisión a este respecto que garantice los criterios que se determinen en cada momento.


4 Metodología Aplicable y Entorno Tecnológico

4.1 Metodología de desarrollo, normativa y Guía de Estilo

La organización del trabajo y ejecución del proyecto estará basada en la metodología de planificación y desarrollo de sistemas de información ARINbide v1.0., y la metodología de pruebas PROBAMET v2.0.

ARINbide v1.0 se concibe como una metodología práctica para el ciclo de vida completo del software, basada en Métrica 3, y adaptada a las necesidades y directrices de E.J.I.E. Además consta de un apartado para el establecimiento de una metodología de Gestión de Proyectos. Como Plan de Calidad la propia metodología, en sus apartados de trabajo habitual, genera los registros de calidad necesarios para el sistema de calidad de E.J.I.E.

Para todo el ciclo de vida del proyecto, ARINbide define los siguientes procesos:

• Ingeniería del Software (ISW)

• Gestión del Proyecto (GPR)

• Gestión de Riesgos del Proyecto (GRP)

• Gestión de la configuración (GCO)

• Mantenimiento del Sistema de Información (MSI)

El proceso principal de ingeniería del software (ISW) describe y normaliza la secuencia de fases y actividades a realizar en el proyecto de desarrollo de un sistema de información, así como los entregables a obtener en cada una de ellas. En este ámbito, ARINbide v1.0 contempla el desarrollo de las siguientes fases metodológicas:

• Catálogo de Requisitos de Usuario (CRU) (proceso diferenciado dentro del Análisis del Sistema de Información, ASI)

• Análisis del sistema (ASI)

• Diseño del sistema (DSI)

• Construcción del sistema (CSI)

• Implantación y aceptación del sistema (IAS)

El ciclo de vida descrito en la metodología de desarrollo ARINbide se alinea y complementa a lo largo del tiempo con la metodología de pruebas corporativa PROBAMET, centrándose ésta última en la especificación de todas las actividades relacionadas con la planificación, definición y ejecución de los diferentes tipos de pruebas. Existe una correspondencia entre las fases de ejecución de ARINbide y las fases de ejecución de PROBAMET.


Información detallada sobre las fases y entregables de la metodología ARINbide, se encuentra en la página web de E.J.I.E.: http://www.ejie.net/metodologia_desarrollo.htm

En las distintas fases del proyecto, teniendo en cuenta la mencionada metodología ARINBIDE, y según el alcance de aplicación de la misma acordada entre la dirección del proyecto y la empresa adjudicataria en las fases iniciales del proyecto, ésta última deberá contemplar, entre otros, los siguientes elementos:

• Catálogo de Requisitos de Usuario. Debe incluir:

La definición del sistema

La definición, análisis y validación del catálogo de requisitos

• Análisis del Sistema de Información. Debe incluir:

La relación de los módulos del sistema.

Análisis de las aplicaciones, ASI (ERS)

Especificación del Plan de Pruebas, según las directrices establecidas en PROBAMET

El adjudicatario partirá de los entregables resultantes de las actividades del Catálogo de Requisitos de Usuario.

• Diseño del sistema. Lo realizará en su totalidad el adjudicatario de los proyectos de implantación y en sus dependencias. Debe incluir:

Diseño de las aplicaciones, DSI. (EDS)

Especificar el detalle del Plan de Pruebas del sistema por cada uno de los niveles de prueba: unitarias, de integración, de sistema, de implantación y de aceptación, según las directrices establecidas en PROBAMET

• Construcción del sistema.

Lo realizará en su totalidad el adjudicatario de los proyectos de implantación en sus dependencias, teniendo en cuenta las directrices de E.J.I.E. en lo que se refiere a los módulos estándar, las normas de funcionamiento y albergue de las aplicaciones en Internet/Intranet, el Manual de Identidad Corporativa del Gobierno Vasco y las directrices de la Dirección de Atención a la Ciudadanía en lo que respecta a estética, diseño y funcionalidades de las páginas Web.

Incluirá la ejecución del Plan de Pruebas, para verificar el cumplimiento de los requisitos establecidos en el mismo, abarcando pruebas unitarias, de integración y del sistema, siguiendo el modelo y las actividades descritas en la metodología PROBAMET

Los entregables de esta fase incluyen en la Especificación de Construcción del Sistema (ECS) y el sistema construido.


Asimismo, deberán respetarse las convenciones adoptadas para un desarrollo de aplicaciones homogéneas recogidas en el Libro de Estilo del Departamento de Sanidad y Consumo

El diseño del sistema tendrá en cuenta el nivel de accesibilidad AA (WAI-AA), para aquellos módulos que sean accesibles desde Internet.

Todos los sistemas desarrollados deberán soportar al menos los siguientes idiomas: euskera, castellano.

La aplicación, las páginas, los textos, los mensajes de error/aviso y/o cualquier otro componente (tool-tip, textos en imagen,….) dirigidos al usuario final deberán estar al menos en ambos idiomas: euskera y castellano.

• Implantación en desarrollo.

La empresa adjudicataria del proyecto de implantación realizará la entrega de la aplicación en el sistema de corporativo de control de versiones Subversion, tanto de la entrega inicial como de las sucesivas

La empresa adjudicataria del proyecto de implantación llevará a cabo la instalación de la aplicación en el entorno de desarrollo de E.J.I.E., habiendo realizado previamente las pruebas necesarias durante la fase de construcción

Ejecución de las Pruebas del sistema, acorde con lo establecido en la metodología PROBAMET y el Modelo SQA, evaluando los resultados

• Implantación en entorno de test o preexplotación.

La empresa adjudicataria del proyecto de implantación preparará los paquetes y dará soporte a la realización por E.J.I.E. de la correspondiente implantación en el entorno de test o preexplotación

Ejecución de las Pruebas del sistema, en sus distintos niveles de prueba, incluidas las Pruebas de Aceptación, acorde con lo establecido en la metodología PROBAMET y el Modelo SQA, evaluando los resultados

• Pruebas de prestaciones:

Conforme a lo establecido en el Modelo SQA, realización de pruebas de rendimiento y carga, que incluyen la verificación de los niveles de respuesta de la aplicación ante las previsiones de carga del sistema, así mismo se verificará el comportamiento global del sistema en cuanto a consumo de memoria y CPU de sus componentes, así como según se considere de capacidad, stress, escalabilidad

• Implantación en producción y puesta en marcha del sistema. Incluirá:

Fuentes de la aplicación.

BBDD: scripts y carga inicial de datos.


Sistema implantado en entorno pruebas de E.J.I.E.

Informe de los resultados de los distintos niveles de pruebas, acorde con el Modelo SQA.

Manual de instalación / Explotación.

Manuales de Usuario y la Ayuda On-line deberán estar en ambos idiomas: euskera y castellano.

Formación a los usuarios y administradores del sistema.

Soporte a la implantación en producción

Sistema implantado en entorno de producción.

Para las fases de implantación y pruebas de aplicaciones JEE en entorno de desarrollo, existe un Manual de tareas de ant, donde se describe el conjunto de tareas disponibles y el uso que debe hacerse de ellas.

En todas las fases del proyecto, así mismo será de referencia el documento de Estándares de desarrollo de sistemas software, que establece requisitos obligatorios y recomendaciones a seguir en todo el proceso de ejecución del proyecto, en cuando a la elaboración de los productos y la entrega de los mismos a E.J.I.E. Cabe destacar que para el caso de desarrollo de aplicativos con interfaz web basado en navegador que será desplegado en el contexto de internet, las pruebas del sistema deberán contemplar los ensayos necesarios para garantizar que el sistema se comporta correctamente en los navegadores más utilizados (Internet Explorer, Firefox, Chrome, Opera, y Safari). Mientras que si el contexto de despliegue es intranet (con PCs gestionados), el sistema deberá soportar los navegadores homologados por los estándares tecnológicos publicados por la Dirección de informática y telecomunicaciones del GV para dicho contexto. Para el caso de extranet, la lista de navegadores a soportar se deberá decidir en función de los colectivos usuarios de la aplicación y del uso o no de PCs gestionados.

Igualmente será de referencia el Documento de Estándares Tecnológicos de Gobierno Vasco, publicado en: www.euskadi.net/informatika

4.2 Metodología de Pruebas

De forma alineada y paralela a ARINbide, la metodología de pruebas PROBAMET, define las fases y actividades referentes al proceso de pruebas de un producto software. El adjudicatario del presente pliego deberá contemplar la realización de dichas actividades, de forma paralela a las actividades de ARINbide.

Información detallada sobre las fases y entregables de la metodología PROBAMET, se encuentra a disposición del licitador en http://www.ejie.net/aseguramiento_calidad.htm

PROBAMET describe las siguientes fases:

• Planificación y Seguimiento de las Pruebas – PPB


• Análisis y Diseño de las Pruebas – APB

• Ejecución de las Pruebas – EPB

Por tanto, en la ejecución del proyecto se contemplarán los siguientes puntos:

• Planificación de las Pruebas. Incluye:

Plan de Pruebas, determinando los tipos de pruebas a realizar y el alcance

Planificación (cronograma) de actividades

Identificación de factores de riesgo

• Seguimiento de las Pruebas. Incluye:

Revisión de la documentación de Planificación

Informes de seguimiento de las pruebas realizadas

• Análisis y Diseño de las Pruebas:

Especificación de los casos de prueba

Análisis de la cobertura de requisitos del sistema con dichos casos de prueba (Matriz de Trazabilidad)

• Ejecución de las Pruebas. Incluye:

Preparación de los entornos técnicos y herramientas necesarias

Ejecución de los distintos niveles de prueba, según el alcance definido en el Plan de Pruebas

Análisis estático de código.

Pruebas Unitarias: probando cada módulo o componente por separado.

Pruebas de Integración: con el objetivo de probar los interfaces entre módulos e ir incrementando la prueba de los módulos y sistemas.

Pruebas de Sistema: sobre el sistema completo, distinguiéndose Pruebas del Sistema Funcionales y Pruebas del Sistema No Funcionales

Pruebas de Aceptación: pruebas del usuario.

Obtención de los informes de pruebas, con seguimiento y resultado

4.3 Modelo de aseguramiento de la calidad (SQA)

EJIE contempla la calidad en distintos ámbitos de aplicación, tanto calidad en los procesos como calidad en los productos.


Para asegurar la calidad en el proceso de gestión del proyecto, durante le ejecución del mismo el adjudicatario deberá contemplar y proveer la documentación que sea requerida en cumplimiento de la metodología ARINbide.

Por otro lado, con el objetivo de asegurar la calidad en el proceso de elaboración y la calidad de los productos software y documentales obtenidos, será de referencia obligatoria el Modelo de Aseguramiento de la Calidad (Modelo SQA) definido por E.J.I.E., así como el documento Estándares de calidad de sistemas software, que contempla:

• Asignación del valor del Nivel de Aseguramiento de la Calidad (NAC) del sistema a desarrollar

• Elaboración del Plan SQA y realización de las actividades de aseguramiento de la calidad, en base al NAC asignado

• El proceso para la realización de las actividades de aseguramiento de calidad definidas, alineadas con la metodología de desarrollo ARINBIDE y cumpliendo implícitamente la metodología de pruebas PROBAMET

• La obtención de indicadores estandarizados de calidad, con el cumplimiento de sus umbrales permitidos.

• El conjunto de herramientas que facilitan la aplicación del modelo y las metodologías

Información detallada sobre los roles contemplados, las actividades y entregables del Modelo SQA, así como de las herramientas y tecnologías a utilizar, se encuentra a disposición del licitador en http://www.ejie.net/aseguramiento_calidad.htm

A continuación se detalla el modelo de aseguramiento de la calidad establecido para el proyecto objeto de contratación

4.3.1. Nivel de Aseguramiento de la Calidad

El NAC asignado para este proyecto es: ALTO

4.3.2. Plan SQA y actividades de seguimiento de la calidad

Al inicio del proyecto se elaborará el Plan SQA del mismo, estableciendo el detalle de las actividades de calidad a realizar, sus esfuerzos y fechas de compromiso según el Plan de Entregas obtenido en ARINbide y en función del NAC calculado.

Según el Modelo SQA, se contempla la realización de las siguientes actividades:


• Verificación documental: Revisión de la documentación entregable de ARINBIDE y PROBAMET, realizada para asegurar que el formato y contenido de la documentación del proyecto cumple con las metodologías y los estándares de calidad de EJIE. Incluye para todos los entregables:

Checklists de Verificación de ARINbide

Checklists de Verificación de PROBAMET

• Auditorías Fin de Fase SQA: Para la realización de estas auditorías, se seguirán los correspondientes formularios de “Checklist de Auditorías SQA”, y de dispondrá de la información y documentación recopilada en cada fase. Los resultados y conclusiones se incluyen en el Informe de aseguramiento de la calidad ISQA. Se contemplan las siguientes:

Auditoría ASI: Coincide con el final de la fase de Análisis del Sistema.

Auditoría DSI: Una vez terminada la fase de Diseño del Sistema.

Auditoría CSI-I: Coincide con el final de las actividades de Construcción, Pruebas Unitarias y Pruebas de Integración.

Auditoría CSI-II: Una vez terminadas las Pruebas Funcionales de Sistema.

Auditoría CSI-III: Después de la realización de las Pruebas No Funcionales de Sistema: Pruebas de Prestaciones, Seguridad, Accesibilidad, Usabilidad y Pruebas de Fallo y Recuperación del Sistema.

• Ejecución selectiva de pruebas: Se contempla la ejecución selectiva de un conjunto de pruebas adicionales con el objetivo de reforzar el proceso de calidad, independientemente de las pruebas que se definan en el Plan de Pruebas de PROBAMET.

• Auditoría Final SQA: Se realizará al finalizar todas las actividades previstas en el proyecto para la fase de Implantación (IAS) de ARINbide, y las pruebas de Aceptación de usuario, en base al Plan SQA del proyecto. Sigue la misma operativa que las Auditorías de Fin de Fase y obtiene de forma incremental el mismo informe pero dando la visión global del grado de calidad del proyecto y las conclusiones derivadas.

• Recogida y Análisis de Indicadores (Cuadro de mando): Como resultado de las distintas actividades del modelo, se actualizan automáticamente los indicadores de calidad, ayudando también en la toma de acciones correctivas. Existe un mapa de indicadores que la aplicación a implantar deberá cumplir, en base al NAC asignado. La no superación de los límites establecidos podría suponer que el sistema no sea instalado en el entorno de producción

Dada la no existencia de una Oficina Técnica de Calidad de proyecto, paralela a la ejecución del presente proyecto, y por tanto, la asunción de dicho rol por el adjudicatario del presente pliego (además de las tareas del rol propio de Desarrollo y Pruebas), el adjudicatario deberá contemplar la ejecución de las tareas mencionadas en el presente apartado.


4.4 Herramientas del ciclo de vida de las aplicaciones

Como soporte e instrumento necesario en la ejecución de todas las fases del proyecto, existe un conjunto de Herramientas homologadas por E.J.I.E., que abarcan todo el ciclo de vida de las aplicaciones, y que facilitan la realización de distintas tareas y normalizan la obtención de entregables.

Estas herramientas homologadas son las que se utilizan en el entorno de trabajo de E.J.I.E., no pudiendo utilizarse en el mismo otras herramientas similares o equivalentes.

Para los trabajos a realizar en las dependencias del proveedor, su uso es recomendado frente a otros productos o herramientas del mercado, para dar cobertura a los cometidos para los que están destinadas. No obstante, en los casos en los que el resultado de uso de las herramientas sea un entregable con un formato específico y normado, su uso será obligatorio frente a otras herramientas de mercado, o bien en cualquier caso deberá proporcionarse un formato compatible.

En el documento PBT-Anexo Herramientas se detallan las herramientas homologadas.

4.5 Entorno Tecnológico.

El entorno tecnológico será el definido en los estándares del Gobierno Vasco y del Departamento de Sanidad y Consumo y que se consideren necesarios para la ejecución de este proyecto conforme a sus características específicas.

Existen un conjunto de utilidades y sistemas horizontales de uso corporativo que dan solución tecnológica a distintos ámbitos funcionales de uso común, que se citan a continuación, y que el proyecto objeto de contratación deberá contemplar según sus necesidades.

Para las áreas funcionales de tramitación de expedientes del sistema final se deberán seguir las directrices marcadas por el modelo básico de tramitación (MBT) del Gobierno Vasco, es decir, identificar la familia a la cual pertenece el procedimiento a mecanizar, recoger los datos mínimos definidos como invariantes de información, modelar los trámites establecidos como invariantes de tramitación, e informar al sistema de visión de ciudadano (Mis Gestiones). Además, con objeto de simplificar y homogeneizar los puntos de acceso y las interfaces gráficas de usuario, y de asegurar una correcta interpretación de las normas legales vigentes, el nuevo producto deberá hacer uso del conjunto de módulos y sistemas comunes que constituyen el núcleo de elementos corporativos horizontales de base de plataforma tecnológica de e-Administración, PLATEA, desarrollando y completando por lo tanto todo aquello que dichos sistemas requieran:

• Sistemas de infraestructura de tramitación, PLATEA-Tramitación. Permiten ofrecer al administrado una visión homogénea de los procesos de tramitación gestionados por cualquier departamento de Gobierno Vasco, facilitar al empleado público las herramientas básicas y únicas de gestión de tareas de tramitación, definir y establecer los flujos de tramitación adscritos al modelo básico de tramitación, y aportar las soluciones técnicas necesarias que garantizan el cumplimiento de las normativas y procedimientos legales vigentes en materia de tramitación.


Para la publicación de contenidos y aplicaciones en internet, deberá seguirse la normativa corporativa así como las herramientas de soporte al modelo de presencia en internet:

• Herramientas de gestión de contenidos, portales, ejes de catalogación y buscador: PLATEA-Internet. Gestionan la creación, publicación y mantenimiento de contenidos en los portales de internet administrados por Gobierno Vasco, y su catalogación en ejes homogéneos que faciliten su búsqueda. Facilita igualmente los mecanismos para la integración de las aplicaciones en la propia infraestructura de portales.

Como plataforma de integración entre sistemas:

• La infraestructura de integración. Simplifica y estandariza los modelos de intercambio de datos y de procesos entre aplicativos, proporcionando para ello las herramientas y sistemas necesarios para su implementación en base a una plataforma tecnológica unificada, normalizada y compartida. Ofrece soluciones corporativas normadas que ofrecen utilidades y gestionan el intercambio síncrono de información (exposición de servicios), y el intercambio asíncrono (suscripción a eventos).

Como referencia obligada respecto a los ámbitos mencionados, deberá considerarse el documento PLATEA – Plataforma Tecnológica para la e-Administración.

El sistema final deberá utilizar el sistema de seguridad homologado en el entorno de Gobierno Vasco:

• XLNetS. Gestiona los procesos de autenticación y autorización de accesos a usuarios (y sistemas) para aplicativos y recursos, desarrollados bajo distintas tecnologías.

Para las necesidades de gestión documental, deberá utilizarse el sistema corporativo existente:

• Dokusi. Sistema Integral de Gestión Documental cuyo principal objetivo es la implantación de todas las funciones de gestión documental necesarias en los procesos de producción administrativa. Expone su uso a las aplicaciones departamentales mediante su capa de servicios - framework de servicios documentales – FSD, proporcionando además otras utilidades para la carga masiva de documentación, e interfaces gráficas.

En el documento PBT-PLATEA-Anexos se anexa explicación detallada de los sistemas corporativos involucrados en PLATEA.

Como solución corporativa de información de datos de localización:

• NORA. Sistema horizontal de gestión de datos de localización –dirección postal-, que proporciona información actualizada y normalizada hasta nivel de portal. Ofrece diversas alternativas tecnológicas de uso, y como principal valor añadido aporta el tratamiento de Altas Provisionales, solución que permite a las aplicaciones asegurar la normalización de los datos de su negocio, y a su vez favorecer la actualización continua de la información. Incluye además datos y servicios de información geográfica (visor y geolocalizador). En el documento PBT-Anexo NORA se detalla información de referencia acerca del sistema.

Para facilitar el tratamiento de pago telemático del ciudadano a la administración:


• Pasarela de pagos: Sistema que provee los servicios necesarios para gestionar peticiones de pago generadas por la administración para el ciudadano, incluida la aplicación internet de pago electrónico on-line u off-line. En el documento PBT-Anexo Pasarela de Pagos se detalla información de referencia acerca del sistema.

Para los desarrollos basados en entorno tecnológico JAVA, el nuevo sistema a implantar utilizará el conjunto de Utilidades de Desarrollo de Aplicaciones (UDA) homologadas para el entorno de desarrollo Weblogic 11:

• UDA: Conjunto de herramientas, tecnologías, componentes y normativas funcionales y técnicas que permiten acelerar y normalizan el proceso de construcción de aplicaciones JEE en el ámbito de Gobierno Vasco – EJIE. En el documento PBT-Anexo UDA se detalla más información acerca del sistema, así como en la dirección http://code.google.com/p/uda/

Debido a la diversidad de aplicaciones y las distintas necesidades, pueden surgir nuevos patrones de comportamiento para los que no exista un componente disponible en UDA en el momento del desarrollo de la aplicación. En estos casos, el adjudicatario puede desarrollar su propio componente para cubrir la funcionalidad necesaria bajo la supervisión del grupo de Consultoría de Áreas del Conocimiento, y una vez desarrollado el componente (junto con su documentación) deberá ponerla a disposición de este grupo para ser incorporado en la lista de componentes de UDA

Otros productos

Otros productos y soluciones corporativas existentes son los siguientes:

Gestión de procesos batch:

• K31/O75: Soluciones corporativas para la ejecución de procesos desasistidos

• CONTROL-M: Planificación de procesos batch

Generación de informes:

• Jreport. Existe un middleware corporativo (T43) para uso por las aplicaciones departamentales, con tecnología J2EE.

• Reporting Services (Microsoft)

Business Intelligence:

• Oracle Business Intelligence Enterprise Edition (11g)

Sistemas de Información Geográfica:

• GIS Corporativo, basado en productos ESRI (ArcIMS, ARcSDE, ArcView)

Servicio de envío de mensajes SMS:


• SMS Corporativo, basado en plataforma Latinia

Además de los sistemas horizontales especificados, el nuevo sistema, según sus necesidades, deberá utilizar los módulos y servicios establecidos por el Plan de Informática y Telecomunicaciones del G.V. y especificados en el documento de guía de estándares tecnológicos.

Las plataformas tecnológicas y productos comunes de base serán, entre otros:

• Servidor web: Apache Web Server 2 sobre Linux Red Hat Enterprise.

• Bases de datos: Oracle 10g sobre HP-UX SQL Server 2005

• Seguridad: XLNets y PKI Izenpe

• Infraestructura para la Gestión de contenidos y portales (PLATEA-Internet): Interwoven TeamSite 6.7 Open Deploy 6.1 Autonomy

• Infraestructura para la gestión documental (dokusi): Documentum

• Gestión de versionado de aplicaciones: Subversion

• Documentación y trabajo en grupo: SharePoint Portal Server

Además, para el entorno tecnológico JEE, en caso de nuevos desarrollos:

• Servidor de aplicaciones: Oracle Weblogic Server 11g (10.3.5) sobre Linux Red Hat Enterprise

• Herramientas para desarrollo:

Utilidades de Desarrollo de Aplicaciones (UDA)

IDE (PC compatible con Windows XP SP1): Eclipse, con OEPE y plug-ins UDA

En todos los casos, y según corresponda al entorno tecnológico a utilizar, se utilizarán igualmente las Herramientas del ciclo de vida de las aplicaciones. En el documento PBT-Anexo Herramientas se relacionan las herramientas homologadas.

Existe asimismo un conjunto de librerías software soportadas, recogidas en los manuales de albergue de aplicaciones, que deberán contemplarse según corresponda, en el proceso de diseño técnico y construcción del sistema (FOP, POI, JasperReports, LinearBarCode, JfreeChart, IAIK, …)


5 Descripción de entregables

Los productos a entregar, tanto productos software como documentación, serán aquellos que define la metodología de desarrollo ARINBIDE, en referencia a las fases definidas dentro del alcance del proyecto.

Igualmente, dentro del alcance definido del proyecto, la Metodología de Pruebas, así como el modelo de Aseguramiento de la Calidad de Sistemas Software, detallan los entregables a proporcionar en el ámbito de la calidad.

Con independencia de lo descrito y requerido a nivel metodológico (metodología de desarrollo Arinbide, y Metodología de Pruebas PROBAMET), a continuación se añaden tareas y entregables a realizar/suministrar por el adjudicatario:

Implantación en el Entorno de Desarrollo de EJIE.

Definición, ejecución y gestión del Plan de Pruebas

Preparación de componentes y soporte a la implantación en el entorno de Test o Preproducción.

Soporte a la implantación en el entorno de Producción.

La documentación de usuario deberán estar en ambos idiomas: euskera y castellano.

La aplicación, las páginas, los textos, tablas de códigos, los mensajes de error/aviso y/o cualquier otro componente (tool-tip, textos en imagen,….) dirigidos al usuario final deberán estar en ambos idiomas: euskera y castellano.

Entrega de fuentes de todos los componentes, ficheros de configuración, elementos gráficos utilizados,…..y cualquier otro elemento que se considere necesario para el normal y adecuado mantenimiento/evolución del sistema, en soporte magnético (DVD).

Confección y entrega de la documentación (funcional, técnica, de explotación y de usuario) correspondiente a cada una de las fases del proyecto tanto en formato papel, como en formato electrónico.

Todos los entregables deberán proporcionarse utilizando las herramientas homologadas en EJIE para el ciclo de vida de las aplicaciones, o en su caso proporcionando formatos compatibles.


5.1 Normativa para la puesta en producción y posterior explotación del sistema

EJIE cuenta con actividades formalizadas para la gestión e implantación de los sistemas de información generados en los distintos entornos, establecidas en base a los procesos de Gestión de Cambios y Gestión de Despliegues.

A partir de estos procesos se garantiza que los sistemas que serán instalados en la infraestructura de EJIE cumplen con los estándares y normativas técnicas de la organización, que no impactarán en el correcto funcionamiento del resto de productos y que se conocen los procedimientos y particularidades relacionadas con su operación y soporte.

Para ello, es necesario que durante el ciclo de vida del proyecto, el equipo de trabajo genere una serie de entregables, que serán validados a través del proceso de Gestión de Cambios:

Documentos de requisitos de proyecto para procesos: contendrá requisitos relacionados con las necesidades infraestructura y el soporte futuro de los procesos que pueden afectar al diseño técnico o funcional de sistema de información a generar.

Documento de albergue: recogerá el diseño de la solución desde el punto de vista técnico, incluyendo aspectos de monitorización, crecimiento, estacionalidad si fuera necesario.

Documentos de aprovisionamiento de entorno: fichas utilizadas para el aprovisionamiento de un entorno estándar sobre el que luego desarrollar o implantar el nuevo sistema.

Manual de implantación: deberá recoger los aspectos técnicos y configuraciones necesarias que deben ser realizadas para implantar la aplicación en un entorno tecnológico de EJIE.

Manual de soporte: contendrá el conocimiento necesario para que EJIE pueda proporcionar soporte técnico al sistema implantado, de forma autónoma y a través de sus procesos de soporte. Incluirá datos referentes a errores conocidos, procedimientos de resolución, proveedores de soporte, contactos, garantías, modelos de cambio y cualquier aspecto relevante para el soporte del sistema.

Manual de operación: refleja la información necesaria para el arranque, parada, y mantenimiento técnico del nuevo sistema, incluyendo aspectos de monitorización, capacidad y personal de contacto en caso de fallo.

Para cada uno de estos documentos EJIE dispone de plantillas estándar que el proveedor deberá utilizar y entregar según los procedimientos establecidos.

Asimismo, en la cumplimentación de las plantillas se podrá solicitar el asesoramiento de los distintos Responsables de Proceso y Coordinadores de Infraestructura, para asegurar que la solución construida e implantada cumple con la normativa de EJIE y es posible operarla y soportarla con garantías.


6 Planificación y Organización

6.1 Plan de Proyecto

6.1.1. Plan de Entregas e Hitos de Control

El licitador deberá incluir en su Documento de Propuesta Técnica una descripción de las principales:

• Fases y tareas del proyecto,

• Entregas resultantes de cada fase,

• Hitos de control y/o verificación,

Junto con sus correspondientes fechas orientativas de finalización.

Asimismo, el licitador podrá establecer propuestas de entregas y/o certificaciones parciales acordes con el planteamiento del proyecto establecido, siempre que:

• Lo considere más adecuado para facilitar la implantación y puesta en marcha del objeto del contrato.

• No se establezca nada en sentido contrario en los apartados de: Objeto, Alcance y Descripción del Proyecto.

6.1.2. Diagrama de Gantt

El licitador deberá presentar un Diagrama de Gantt o Cronograma de las Fases y Tareas propuestas para la ejecución de las realizaciones objeto del presente pliego. Asimismo, este diagrama de Gantt deberá venir explicado en un formato de tabla especificando:

• Nombre de la tarea y descripción de la misma

• Fecha de inicio estimada

• Fecha de fin estimada


6.2 Organización del Equipo de Trabajo

El licitador deberá describir en su Documento de Propuesta Técnica:

• La organización (perfiles) del equipo de proyecto asignado a la realización de las actividades resultantes del presente pliego

• Las funciones de los mismos

• La relación nominal de los participantes, junto su correspondiente documento de currículo.

6.2.1. Asignación de recursos a fases del proyecto

El licitador deberá incluir en su Documento de Propuesta Técnica, un desglose de horas y % de dedicación total por perfil y fase del proyecto, siguiendo el siguiente modelo:

Gest. Proyecto Análisis Diseño Construcción Implantación Descripción Perfil

Horas % Horas % Horas % Horas % Horas %

Total Horas

Jefe Proyecto Analista Funcional Analista Técnico Analista-Program. Programador Diseñador … TOTAL

(*) Este desglose de horas se considerará como orientativo y será tenido en consideración en el momento de valorar el grado de aproximación a la planificación del proyecto según la estimación del licitador, permitiendo, de esta forma, valorar la idoneidad del dimensionamiento del equipo de trabajo propuesto y su adecuación a la consecución de los objetivos. No obstante, este desglose de horas no se considera vinculante al no tratarse de una contratación de horas de desarrollo, sino un proyecto “llave en mano” según el importe total ofertado.


6.2.2. Equipo de Trabajo

El equipo de trabajo propuesto estará formado por personal técnico con categoría profesional y nivel de especialización adecuados a las necesidades planteadas en cada momento, de acuerdo con las actividades que se vayan desarrollando. El licitador debe comprometerse, en caso de ser adjudicatario, a mantener el equipo según lo establecido en el Documento de Propuesta Técnica, y durante el periodo fijado en cada actividad específica.

6.2.2.1. Certificaciones en PLATEA, Geremua y Dokusi

Con el fin de asegurar la capacitación técnica del personal involucrado en el desarrollo de los proyectos, en el ámbito del uso de plataformas y sistemas corporativos, se establece como requisito la acreditación de dichos conocimientos en base a Certificaciones de los técnicos propuestos por el licitador. La expedición de dichas acreditaciones, así como la formación destinada a la consecución de las mismas se lleva a cabo por Tecnalia.

Se han establecido dos perfiles de Certificación (analista y desarrollador), para cada una de las siguientes especialidades:

• Infraestructura de tramitación electrónica, PLATEA-Tramitación

• Infraestructura de presencia en internet, PLATEA-Internet

• Infraestructura de integración

• Framework J2EE, Geremua

• Sistema Integral de Gestión Documental, Dokusi

En concreto, para el proyecto objeto del presente pliego, la empresa licitadora deberá presentar personal certificado conforme al siguiente cuadro:

Nº de certificaciones Especialidad Analista Desarrollador

Fecha límite de acreditación

PLATEA-Tramitación 2 3 01/10/2012 PLATEA-Internet N/A N/A N/A Integración 1 1 01/10/2012 Geremua N/A N/A N/A DOKUSI 1 1 01/10/2012

Para los casos en caso de que las fechas límite de acreditación sean posteriores a la fecha de adjudicación del contrato, la oferta del proveedor deberá recoger compromisos firmes y concretos de cumplimiento de las acreditaciones del personal propuesto en caso de ser adjudicatario. Cualquier incumplimiento de las fechas de preceptividad comprometidas en la oferta del adjudicatario, podrá suponer la rescisión del contrato y ser tenido en cuenta a efectos de calificación de solvencia técnica para siguientes procesos de contratación.


6.2.2.2. Veracidad de los datos

E.J.I.E. se reserva la facultad de solicitar, en cualquier momento, antes o después de la adjudicación y durante el curso de los trabajos, de cualquier otro tipo de documento complementario, en orden a la comprobación de cuantos datos haya ofrecido la empresa adjudicataria, tanto respecto a la misma, como a los recursos de que disponga.

La falsedad en los mismos podrá implicar asumir penalizaciones y, en último término, podrá provocar la resolución del contrato.

6.2.2.3. Condicionante del equipo de trabajo ofertado

La falsedad en el nivel de conocimientos técnicos del personal ofertado, deducida del contraste entre lo reflejado en el currículo y los conocimientos reales demostrados en la ejecución de los trabajos podría, en último término, podrá provocar la revisión de la adjudicación y en su caso la rescisión del pedido/contrato.

6.2.2.4. Constitución inicial del equipo de trabajo

El equipo humano a incorporar tras la formalización del contrato para la ejecución de los trabajos deberá estar formado por componentes relacionados en la oferta adjudicataria y consecuentemente valorados.

Si tras la adjudicación se observara que el equipo de proyecto no se corresponde con el Documento de Propuesta Técnica objeto de la misma y:

• Caso que el adjudicatario presente justificación escrita, detallada y suficiente, explicando el motivo que suscita el cambio, se procederá a:

La presentación por el adjudicatario de posibles candidatos con un perfil de cualificación técnica igual o superior al de la persona que se pretende sustituir.

Aceptación de alguno de los candidatos por parte de la Dirección del Proyecto de E.J.I.E.

• Caso de que se demostrase que el cambio no se corresponde con causa justificada, de fuerza mayor y no imputable al adjudicatario, E.J.I.E. se reserva el derecho no solo a la aprobación de la persona o personas sustitutivas, sino incluso a la revisión de la adjudicación y en su caso la rescisión del pedido/contrato, si este hecho fuera elemento determinante en la mencionada adjudicación.


6.2.2.5. Modificaciones en la composición del equipo de trabajo

La valoración final de la productividad y calidad de los trabajos de las personas que realizan los trabajos objeto del presente pliego corresponde a la Dirección del Proyecto de E.J.I.E., siendo potestad suya solicitar el cambio de cualquiera de los componentes del equipo de trabajo, con un preaviso de quince días, por otro de igual categoría, si existen razones justificadas que lo aconsejen.

Si el adjudicatario propusiera el cambio de una de las personas del equipo de trabajo, se deberá solicitar por escrito con quince días de antelación, y requerirá de las siguientes condiciones:

• Justificación escrita, detallada y suficiente, explicando el motivo que suscita el cambio.

• Presentación de posibles candidatos con un perfil de cualificación técnica igual o superior al de la persona que se pretende sustituir.

• Aceptación de alguno de los candidatos por parte de la Dirección del Proyecto de E.J.I.E.

Los posibles inconvenientes de adaptación al entorno de trabajo y al proyecto debidos a las sustituciones de personal, deberán subsanarse mediante periodos de solapamiento sin coste adicional, durante el tiempo necesario. Si a criterio de la Dirección del Proyecto de E.J.I.E. esto no fuera posible, las dos primeras semanas de trabajo del sustituto no serán facturables corriendo a cargo del adjudicatario los gastos que se deriven de esta condición.

6.2.2.6. Jornada laboral y lugar de realización de los trabajos.

Los trabajos de desarrollo se realizarán normalmente en las dependencias del adjudicatario en cuyo caso:

• La jornada de trabajo estará de acuerdo a la establecida por el adjudicatario,

• Los componentes del grupo de trabajo deberán estar en una única ubicación y desarrollarán su labor con hardware y software propiedad del adjudicatario. Dicha ubicación deberá ser lo suficientemente cercana a E.J.I.E., S. A. como para garantizar una presencia rápida en E.J.I.E., ante cualquier eventualidad que pudiera surgir.

Las pruebas de integración, de carga, aceptación y la puesta a punto de los productos se realizarán en los locales de E.J.I.E.

En aquellos casos en que los trabajos deban ser realizados en las dependencias de E.J.I.E, estos se realizarán en las siguientes condiciones:

• La jornada de trabajo estará de acuerdo a la establecida por E.J.I.E.,

• Con carácter general los componentes del grupo de trabajo deberán desarrollarán su labor con hardware y software propiedad del adjudicatario, salvo para labores de instalación, implantación, y puesta en marcha, que se realizará mediante los puestos asignados por la Dirección del Proyecto de E.J.I.E.


• Si por circunstancias excepcionales y cuando la realización efectiva de los trabajos no se ajuste a la planificación o así se requiera por las necesidades del servicio, el adjudicatario deberá comprometerse a una plena disponibilidad incluso fuera del horario habitual (salvo acuerdo previo por la Dirección del Proyecto de E.J.I.E.), sin que la realización del trabajo tenga una consideración especial a efectos de cómputo de horas o tarifa aplicable a las mismas

6.2.2.7. Currículo de los componentes del grupo de trabajo.

Se deberá adjuntar el currículo individual detallado de todos y cada uno de los componentes del grupo de trabajo propuesto para la realización de las tareas y actividades de los trabajos objeto de contratación, junto con el papel/perfil (conforme a los indicados en el cuado anterior) que asumen en la realización descrita.

No obstante, si se quisiera proponer un panel de expertos o centros de competencia adicionales para dar soporte en ciertos aspectos, los CV presentados podrán ser meramente orientativos para aquellas personas dedicadas a la realización de esta tipología de trabajos.

La no inclusión del currículo de alguno de los participantes, puede suponer la imposibilidad de una adecuada evaluación del apartado de “Organización del Proyecto”, pudiendo el licitador no ser puntuado por este concepto.

Datos del currículo: • Apellidos y Nombre, • Edad, • N.I.F., N.S.S. y justificación/certificación de alta en la empresa (certificado de la S. Social) • Conocimientos metodológicos y tecnológicos principales. • Formación Reglada: Centro, Titulación y Fechas (desde-hasta). • Formación no Reglada: Centro, Curso y Fecha (desde-hasta). • Experiencia Acumulada: Total Años. • Experiencia profesional: Empresa, Puesto / Responsabilidades, Meses o Años, Fecha (desde-

hasta). • Conocimientos y Experiencia obtenida Proyectos: Proyecto, Puesto / Responsabilidades, Meses,

Fecha (desde-hasta), y principales tecnologías utilizadas, para al menos los principales o correspondientes a experiencias similares.

6.3 Transferencia Tecnológica

Durante la ejecución de los trabajos objeto del contrato el adjudicatario se compromete, en todo momento, a facilitar a las personas designadas por la Dirección del proyecto de E.J.I.E. así como la información y documentación que ésta solicite. Todo esto para disponer de un pleno conocimiento de los trabajos desarrollados o de los eventuales problemas que puedan plantearse y de las tecnologías, métodos, y herramientas utilizados para resolverlos.


7 Presupuesto y oferta económica

En documento separado y siguiendo lo establecido en el modelo de Pliego/Hoja de Cláusulas Administrativas se deberá incluir el importe Total de la Oferta Económica, con y sin I.V.A. Y opcionalmente, cualquier otro desglose de estimación de esfuerzos que se considere relevante para la correcta evaluación del apartado “Proposición económica” contemplado en la sección de Criterios de Valoración.

Del mismo modo podrán detallarse también posibles prestaciones superiores a las solicitadas, ofertadas por el licitador y debidamente argumentadas en cuanto al nivel de esfuerzo requerido, siempre y cuando E.J.I.E. las considere como tales desde el punto de vista del proyecto y si así se especificase en el apartado de “Prestaciones Superiores/Complementarias a las Exigidas” contemplado en la sección de Criterios de Valoración.

En el precio ofertado se entenderán ya incluidos: las dietas, gastos de desplazamiento y/o cualquier otro gasto necesario para la realización del servicio. Con independencia de lo aquí indicado será necesario incluir el desglose de cualquier gasto o aspecto objeto del presente pliego si así fuera requerido de forma expresa en el Pliego/Hoja de Cláusulas Administrativas.

El presupuesto y oferta económica se establece con un importe máximo de 400.000 € (IVA no incluido). Este valor será el tomado como base para los Criterios de Valoración explicados posteriormente.


8 Mecanismos de Seguimiento, Control y Supervisión

La gestión del proyecto se realizará según las normas procedimentales y de calidad de la Gestión de Proyectos de E.J.I.E.

El control y seguimiento de la calidad de servicio, será realizado por la Dirección del Proyecto de E.J.I.E. conjuntamente con la persona propuesta por la empresa adjudicataria.

Durante el desarrollo y ejecución del proyecto, E.J.I.E. podrá establecer controles de calidad sobre la actividad desarrollada.

8.1 Mecanismos de Seguimiento y Control

El equipo de trabajo estará dirigido por un Responsable del Proyecto con dedicación estable y suficiente, quien coordinará las tareas implicadas en el proyecto y será el interlocutor principal con la Dirección del Proyecto de E.J.I.E.

Deberán establecerse todos los mecanismos de control que permitan verificar de forma continuada el cumplimiento de los objetivos especificados, tanto en plazos como en términos de calidad final. Para ello se contempla:

• Reuniones de seguimiento: a partir del plan de entregas requerido se celebrarán reuniones periódicas o coincidiendo con los puntos de decisión, destinadas a revisar el grado de cumplimiento de las tareas planificadas, le entrega de productos, las reasignaciones de personal, la validación de las programaciones de actividades a realizar, etc.

• Reuniones de control económico: de control económico del proyecto para llevar a cabo el plan de pagos establecido.

• Informes de situación y progreso: con los que la empresa adjudicataria comunicará a la Dirección del Proyecto de E.J.I.E., del estado puntual de los trabajos, de los objetivos alcanzados, de las incidencias ocurridas, etc.

• Certificaciones parciales: si procede.

• Hojas de control de tareas: si procede.

Documentos de gestión de proyectos: a solicitud del responsable de E.J.I.E., la empresa adjudicataria cumplimentará los documentos de gestión de proyectos, según un modelo definido: actas de reuniones, registro de inspección y ensayo, informes de progreso, control de configuración (módulos-componentes instalados), etc.


8.2 Supervisión del proyecto

Tanto la dirección como la supervisión del Proyecto serán llevadas a cabo por el personal de EJIE, S.A. asignado al proyecto.

Los productos del trabajo deberán ser aprobados tanto por el Responsable del Proyecto por parte del adjudicatario, como por la Dirección del Proyecto de E.J.I.E., si los encuentran conformes, emitirán su informe favorable, empezándose a computar desde ese momento el período de garantía que todo trabajo de realización externa debe aportar en previsión de defectos no detectados en las pruebas realizadas.

El incumplimiento de los plazos pactados sin causa que lo justifique, dará lugar a las penalizaciones que se acuerden en las condiciones particulares (si existieran).


9 Plazo de ejecución y Plan de Facturación

El equipo de proyecto propuesto deberá tener disponibilidad para su incorporación en un plazo máximo de dos semanas a partir de la fecha de adjudicación de los trabajos a realizar.

La finalización de los servicios a contratar así como sus entregables asociados tendrán como fecha límite el 1 de diciembre del 2013.

El adjudicatario tiene derecho al abono, con arreglo a los precios convenidos, de los trabajos que realmente ejecute, con sujeción al contrato otorgado, a sus modificaciones aprobadas y a las órdenes dadas por escrito por E.J.I.E.

La facturación del precio del contrato, se efectuará a través de la presentación de las correspondientes facturas expedidas con los requisitos legales exigidos y repartidas de forma orientativa según el cuadro siguiente:

• La aprobación implica: La implantación en el entorno correspondiente si procede, y la aprobación por la Dirección del Proyecto de E.J.I.E. de las tareas correspondientes.

• El plan de facturación definitivo se establecerá sobre la base del plan de proyecto establecido en la fase de definición inicial del mismo, teniendo en cuenta que:

En función del plan del proyecto y de acuerdo con la Dirección del Proyecto de E.J.I.E, podrán ser establecidas entregas parciales, que podrán implicar facturaciones acordes al alcance de las mismas, tras las correspondientes verificaciones y certificaciones.

La no conformidad de los productos recepcionados, tanto en cuanto al alcance funcional respecto el plan de entregas preestablecido, como en cuanto al incumplimiento de las normas/estándares

A la Aprobación del Documento de Análisis Funcional. 15%

A la Aprobación en el Entorno de Desarrollo. 35%

A la Aprobación en el Entorno de Test. 10%

A la Aprobación en el Entorno de Producción. 15%

A la Finalización del Soporte Post-Producción del sistema. 10%

A la Aceptación Definitiva de la Dirección del Proyecto de E.J.I.E. de los trabajos realizados. 15%


establecidos, y/o en cuanto al nivel de calidad de los mismos, pueden provocar la paralización del plan de facturación hasta que se resuelvan las no conformidades.

Caso de que los trabajos efectuados no se puedan adecuar a la prestación contratada, como consecuencia de vicios o defectos graves imputables al contratista, no pudiendo ser utilizados por E.J.I.E. en tiempo y/o condiciones estará exento de la obligación de pago o tendrá derecho, en su caso, a la recuperación del precio satisfecho.

El plan de facturación establecido al inicio del proyecto podrá ser revisado y/o modificado, a lo largo del proyecto y como consecuencia de actividades de replanificación del mismo, establecidas en los procedimientos de control y seguimiento del proyecto.

• Para llevar a cabo el abono de los importes relativos a los conceptos de cada una de las facturas será requisito imprescindible disponer de la certificación de conformidad de los mismos emitida por la Dirección del Proyecto de E.J.I.E.


10 Criterios de Valoración

Los criterios de adjudicación que servirán de base para la valoración de las propuestas, así como sus pesos de ponderación se recogen a continuación. Para la evaluación de las propuestas se establece un criterio de ponderación con una puntuación máxima de 100 puntos.

A continuación se detalla la puntuación y aspectos que se tendrán en cuenta para la adjudicación del trabajo:

Característica Objeto de valoración Puntos

Valoración económica 35

Plan y equipo de trabajo 30

Entendimiento del proyecto y calidad de la solución 25

Prestaciones superiores/complementarias a las exigidas 10

Valoración económica

La proposición económica se valorará mediante la siguiente fórmula:

Total puntos proposición económica x Precio oferta más ventajosa (la de menor precio) Precio de la oferta evaluada

En caso de que la oferta presentada no se ajuste a los valores de referencia del pliego por exceso se adjudicarán 0 (cero) puntos en este concepto, excluyéndose automáticamente esta oferta del resto del proceso selectivo.

Plan y equipo de trabajo

Se valorará la organización, planificación y estrategia de realización de los servicios así como la calidad profesional del equipo presentado.


Entendimiento del proyecto y calidad de la solución

En este apartado se analiza si la propuesta que realiza el proveedor se ajusta tanto en alcance como en profundidad a las necesidades marcadas en el pliego de bases técnicas.

En caso de que la oferta no se ajuste a las necesidades planteadas en el pliego de bases técnica, la puntuación será de cero, excluyéndose automáticamente esta oferta del resto del proceso selectivo.

Prestaciones superiores/complementarias a las exigidas

En este apartado se valorará aquellas mejoras tanto funcionales como técnicas que el proveedor plantee en su oferta y que se consideren beneficiosas para los trabajos a contratar.


11 Garantía y Confidencialidad.

Las cláusulas relativas a la propiedad intelectual, garantía y confidencialidad de la información, así como el resto de condiciones generales de contratación se encuentran disponibles en la web de E.J.I.E. (www.ejie.net) en el apartado perfil de contratante.

11.1 Garantía

El período de garantía será como mínimo de 1 año a partir de la aceptación del trabajo. No obstante los licitadores especificarán, en su caso, el tiempo de garantía ofrecido superior al mínimo así como el alcance de la misma.

11.2 Confidencialidad de la información

La Dirección del proyecto entregará la información y documentación que considere necesaria para la realización del presente trabajo, debiendo la empresa adjudicataria comprometerse a:

• Tratar con absoluta confidencialidad todo el material y la información que reciba como consecuencia de los trabajos realizados objeto de la adjudicación, durante el periodo de tiempo de duración de la misma,

• No utilizar la misma para otros fines que los recogidos en el presente Pliego de Condiciones Técnicas.

• No duplicar, copiar, revelar, ceder o vender total o parcialmente la información obtenida, en todo o en parte, a terceros sin autorización escrita de E.J.I.E.,

• Advertir a sus empleados de sus obligaciones respecto a la confidencialidad de la información, velando por el cumplimiento de la misma,

• Restringir la utilización de la información obtenida como consecuencia de los trabajos realizados objeto del presente pliego de bases técnicas, exclusivamente para aquellos empleados que tengan necesidad de conocerla y con la finalidad de realizar los trabajos expuestos.

• Poner todos los medios a su alcance para conservar el carácter confidencial y reservado tanto de la información y documentación recibida de E.J.I.E., como de los resultados obtenidos del trabajo realizado.

• La devolución de toda la información, material y/ soportes informáticos obtenidos, así como a la descarga de la misma de sus equipos informáticos o (si existieran), una vez finalizado el periodo de contratación correspondiente.


Cualquier infracción en este sentido será calificada como grave y será causa de resolución del contrato, sin perjuicio de las responsabilidades penales, o de otro tipo, en que se puedan incurrir.

11.3 Protección de datos

El adjudicatario quedará obligado al cumplimiento de lo dispuesto en la Ley Orgánica de Protección de Datos, sobre protección de datos de carácter personal. En este sentido, deberá sujetarse a los preceptos de la Ley Orgánica 15/1999, de 13 de diciembre, LOPD, y su Reglamento de Desarrollo, RD 1720/2007, de 21 de diciembre.


12 Propiedad intelectual

Todos los derechos de propiedad intelectual y de ‘Copyright’ de cualquier producto o subproducto derivados de los trabajos realizados bajo la correspondiente adjudicación serán propiedad exclusiva de E.J.I.E., obligándose las partes a otorgar el documento oportuno cuando éste sea necesario, para la debida constancia pública de este hecho ante cualquier Organismo o Registro, tanto de la Comunidad Autónoma como de la Administración Central del Estado Español.

Asimismo todo producto o subproducto derivada de la correspondiente contratación no podrá ser utilizado para otros fines fuera del ámbito de la misma, sin el permiso expreso y por escrito de E.J.I.E.

La empresa adjudicataria será responsable de daños y perjuicios que se deriven del incumplimiento de esta obligación.


13 Prestaciones superiores o complementarias a las exigidas

El Licitador podrá incluir en su propuesta de colaboración cuantas prestaciones adicionales considere oportunas para la mejora de su actuación, siendo valoradas conforme a lo establecido en el apartado de Criterios de Valoración, caso de que en el mencionado apartado no se establezca criterios de valoración específicas de las mismas estas podrán ser cuantificadas dentro del conjunto del apartado correspondiente a Entendimiento del Proyecto y Planteamiento de la Solución.

En cualquier caso, indicar que:

• Deberán ser:

Descritas en cuanto a sus objetivos, funcionalidad y alcance,

Necesariamente valoradas tanto en cuanto:

Esfuerzo: Horas, (dentro del Documento de Propuesta Técnica Técnica), como en

Coste: Euros, (dentro del Documento de Propuesta Económica), La finalidad de esta solicitud es la de permitir a E.J.I.E. realizar un mejor y más adecuado análisis comparativo de las propuestas recibidas.

Caso que:

Elementos similares hayan sido diferentemente valorados en las distintas propuestas recibidas, o que

Determinadas prestaciones hayan sido (a juicio de EJIE) sobrevaloradas.

Se definirá por parte de E.J.I.E. un patrón general de esfuerzo por perfil para las mismas y se re-estimará su valoración a los precios correspondientes de los perfiles de cada uno los licitadores.

• Posibles mejoras correspondientes a la ampliación del periodo mínimo de garantía establecido, deberán ser referidas e indicadas, pero en ningún caso valoradas en cuanto a esfuerzo y coste.

• Con independencia de lo indicado en los puntos anteriores, las Prestaciones Superiores/Complementarias ofrecidas por el licitador, serán valoradas siempre y cuando E.J.I.E.:

Considere que realmente están fuera del alcance base del proyecto.

Las considere como tales desde el punto de vista del proyecto.


14 Estructura y Formato de la Propuesta

El licitador sólo podrá presentar su propuesta contemplando una única alternativa siempre y cuando no se indique lo contrario en los requerimientos a cumplir detallados anteriormente en este pliego.

14.1 Estructura normalizada y contenido de las propuestas.

La propuesta que se presente por el licitador deberá aportar la información que se requiere en todos sus apartados y estar obligatoriamente estructurada de la siguiente forma:

Documento de Propuesta Técnica, incluyendo

• Índice.

• Presentación y Características Generales:

Identificación del pliego al que responde la propuesta.

Acatamiento con carácter general a las condiciones del pliego.

A partir de este punto, los siguientes apartados se particularizarán para cada una de las soluciones que se oferten.

• Descripción de la Solución.

Se incorporará al inicio de este apartado el resumen de los aspectos más significativos y relevantes de la solución propuesta. Se deberá incluir información detallada de la propuesta en relación con los requisitos de este pliego. Se trata, en definitiva, de una memoria descriptiva del proyecto.

• Matriz de trazabilidad de los requerimientos

Dentro de la descripción de la solución técnica, o en un capítulo separado, deberá incluirse una matriz de trazabilidad de los requerimientos indicados en el apartado Requerimientos del presente documento donde se indique claramente los siguientes elementos:

Id de requerimiento según la nomenclatura definida anteriormente

Requerimiento según lo explicado con anterioridad como denominación simple del mismo (segunda columna)

Capítulo y página de la propuesta donde se explica el cómo así como el nivel de cobertura del mismo

• Metodología y Entorno Tecnológico.


• Planificación y Organización.

Se indicarán las principales fases/tareas del proyecto y el cronograma de trabajos (apartado orientativo tal y como se ha comentado con anterioridad en el presente Pliego de Bases Técnicas)

Organización del equipo de proyecto, junto perfiles, funciones y responsabilidades.

Equipo de trabajo.

Datos relativos de todos los componentes del equipo de trabajo, incluyendo el cuadro de asignación de recursos a fases del proyecto.

Composición del equipo de trabajo propuesto, ordenado por categorías profesionales.

Currículo de cada uno de los componentes, de acuerdo a lo indicado en el apartado Equipo de Trabajo y recogido en Anexo al Documento de Propuesta Técnica.

• Procedimientos de Gestión, Control y Calidad de Proyectos

Se incluirá en este apartado la descripción de las medidas dispuestas por el licitador para asegurar la calidad de los trabajos, medios humanos y materiales, aseguramiento de calidad, así como aquellas otras que se prevé aplicar para vigilar y garantizar el adecuado cumplimiento del contrato.

• Prestaciones superiores o complementarias a las exigidas, si las hubiera:

El adjudicatario podrá incluir en su propuesta cuantas prestaciones adicionales considere oportunas para la mejora de su actuación, estas (salvo ampliaciones en la garantía) deberán ser necesariamente valoradas tanto en cuanto al nivel de esfuerzo (horas por perfil) como económicamente y de forma separada en los Documentos de Propuesta Técnica y Propuesta/Oferta Económica

• Garantía, Confidencialidad y Propiedad Intelectual.

Nota: En ningún caso se deberá incluir información Económica en el Documento de Propuesta Técnica. Documento de Propuesta/Oferta Económica, incluyendo:

• Importe Total de la oferta Económica: con y sin I.V.A.

• Relación completa de los costes contenidos en la propuesta, indicando:

Número de horas por persona y categoría/perfil.

Coste hora por categoría/perfil. Siguiendo el modelo establecido.

• Cualquier otro requisito establecido en el Pliego/Hoja de Cláusulas Administrativas.


14.2 Formato de la Propuesta.

El soporte físico de las propuestas deberá ser:

• Papel, debidamente encuadernada, y

• CD/DVD, en formato electrónico (.pdf).

14.3 Sobres y Elementos.

Todas las propuestas deberán entregarse en sobre o paquete debidamente cerrado, y

• Con etiqueta indicando sobre el mismo:

Descripción/Título y

Referencia Presentes en la carátula del presente Pliego.

• Recogiendo en su interior:

Documento de Propuesta Técnica, siguiendo la estructura requerida en el apartado de Estructura y Formato de la Propuesta, del presente documento.

Documento de Propuesta Económica siguiendo la estructura requerida en el apartado de Presupuesto/Oferta económica, del presente documento y de lo indicado en el Pliego/Hoja de Cláusulas Administrativas

Soporte Magnético con los documentos electrónicos correspondientes, rotulado sobre el mismo: Descripción/Título y Referencia del Pliego.


15 Anexo A. Procedimientos a implementar mediante PLATEA Tramitación

En este apartado se definen algunos de los procedimientos que la nueva aplicación debe desarrollar con PLATEA Tramitación. Será en la fase de análisis del proyecto dónde se concretarán la totalidad de los procedimientos a implantar con PLATEA Tramitación así como aquellos que quedarán circunscritos al ámbito del negocio del nuevo Sistema de Información.

15.1 Alertas

15.1.1. Objetivo

El objetivo del proceso es establecer, definir y poner en marcha los requisitos y acciones necesarias, ante las notificaciones recibidas a través Sistema Coordinado de Intercambio Rápido de Información (S.C.I.R.I.) para garantizar la protección de los consumidores frente a los riesgos en productos alimentarios que se comunican mediante dicho sistema.

Actuación inicial: Recepción de las Notificaciones a través del S.C.I.R.I.

Actuación final: Cierre S.C.I.RI.

Actuaciones intermedias:

- Entrada en el Proceso de intervención cautelar.

- Entrada en el Proceso de toma de muestras.

- Entrada en el Proceso general de inspección.

15.1.2. Descripción del proceso

Entradas:

PROVEEDOR ENTRADA

Agencia Española de Seguridad

Notificaciones de S.C.I.R.I. (Sistema Coordinado de

Intercambio Rápido de Información)


Salidas:

SALIDAS DEL PROCESO CLIENTES

Notificaciones de Alerta Dirección Salud Pública

Subdirección (vía aplicación)

Subdirector (vía fax)

Coordinadores Comarcales (vía aplicación)

Notificaciones de alerta en establecimientos TSP auxiliares y salud pública (vía aplicación)

Informe cierre de alerta Subdirecciones Salud pública

Dirección salud pública

AESAN

Documentación generada en la alerta

Notificaciones

Actas

Informes

Documentación intermedia

Aplicación

Archivo documental


15.1.3. Flujo del proceso


15.1.4. Necesidades de negocio

Indicadores:

- Nº de alertas - Nº medio de establecimientos afectados por alerta - Nº medio de visitas de inspecciones por alerta - Volumen de producto inmovilizado por alerta - Destino del producto inmovilizado por alerta - Nº de alertas por tipo de notificación, agente causal y tipo de alimento - Nº de controles realizados sin visita

Periodicidad: Anual.

15.2 Autorización Sanitaria

15.2.1. Objetivo

El objetivo del proceso es establecer, definir y poner en marcha los requisitos administrativos/sanitarios, para realizar la tramitación y concesión de la autorización sanitaria de funcionamiento/renovación de la autorización/baja de la actividad/cambios de actividad o cambios de tipo administrativo en los establecimientos dedicados a las actividades de importación, preparación, fabricación, transformación, envasado, almacenamiento, transporte, distribución, manipulación y comercialización de productos alimenticios, ubicados en la Comunidad Autónoma del País Vasco.

Actuación inicial:

- Solicitud de Autorización, baja de actividad.

- Solicitud de cambios de tipo administrativo.

- Solicitud de cambios de actividad del establecimiento.

Actuación final: Envío resolución al solicitante.


- Proceso de Intervención cautelar

- Proceso General de Inspección.



Entradas:

PROVEEDOR ENTRADA

Interesado que presenta la solicitud Solicitud de Autorización, Cambios o Baja de la actividad.

Salidas:

SALIDAS DEL PROCESO CLIENTES

Archivo de documentación

Documentación generada en todo el proceso:

Solicitud, memoria, documentación requerida,

requerimientos, resoluciones.

Registro informático Documentación escaneada

Registros sobre la situación administrativa/sanitaria del establecimiento.

Solicitante Resolución de autorización, denegación, baja.

Documento que recoge los cambios solicitados

Documento que recoge el Nº de Registro General

Sanitario de Alimentos adjudicado por la Agencia

Española de Seguridad Alimentaría.

Requerimientos que se generen por incumplimientos.

Notificaciones

Agencia Española de Seguridad Alimentaría Oficio de comunicación sobre autorizaciones,

renovaciones, bajas o cambios autorizados

Proceso general de inspección Solicitud y documentación registrada favorable

Proceso de intervención Resolución de desistimiento

Resolución de denegación de autorización sanitaria de funcionamiento.



Indicadores:

- Tiempo medio de tramitación administrativa (hasta que se envía respuesta al solicitante).

- Nº o % de autorizaciones fuera de plazo.

- Variación media de la puntuación de nuevos establecimientos autorizados, entre la inspección de autorización y la primera inspección de seguimiento por frecuencia.

Periodicidad: Trimestral, Semestral, Anual.

15.3 Procedimiento General de Inspección de Establecimientos Alimentarios

15.3.1. Objetivo

El objetivo de este proceso es el de establecer los requisitos y actividades previas que de manera general deben tener en cuenta los Inspectores a la hora de planificar las inspecciones a establecimientos alimentarios, así como las pautas a seguir durante la inspección propiamente dicha y todos aquellos criterios que deben aplicarse a la hora de cumplimentar y tramitar la documentación generada por la misma. Con el fin de verificar la adecuación de los establecimientos, y sus actividades, a la normativa vigente, conseguir las mejoras necesarias en caso de incumplimientos y garantizar que todos los establecimientos y actividades alimentarias, que se desarrollan en la C.A.P.V., cumplen los principios de higiene y seguridad alimentaria.

Actuación inicial: Planificar previamente la inspección a realizar y dotarse del material necesario para ello.

Actuación final: Tramitar y archivar los documentos generados en la inspección, de acuerdo a unos criterios preestablecidos.

Actuaciones intermedias: A determinar.


Entradas:

PROVEEDOR ENTRADA

- Programa Anual:

C.A.P.V. -> Subdirección -> Comarca -> Individual.

- Proc. Trámite Adm. Autorización Sanitaria

Fecha de Inspección

Establecimientos a inspeccionar

- Proceso de Clasificación de Establecimientos Objeto de la inspección:


Alimentarios


- Proceso de Programas Especiales

Seguimiento según riesgo

Autorización / Convalidación

Verificación de mejoras

Desarrollo de Programas especiales

Inventario de establecimientos Antecedentes histórico/administrativos

Comarca de Salud Pública Equipamiento: material (actas, cuestionarios, etc.) y útiles de inspección.

Salidas:

CLIENTE SALIDA

- Proceso de Clasificación de Establecimientos

Alimentarios


- Programas Especiales

- Inventario/archivo de establecimientos

- Responsable del establecimiento

- Demanda externa.

- Proceso de intervención en establecimientos

alimentarios

Documentación generada en la inspección

- Cuestionarios de recogida de información.

- Actas

- Informes técnicos sobre condiciones del

establecimiento

- Comunicaciones al establecimiento

- Proceso de Seguimiento de Programas de

Inspección

- Proceso de Seguimiento de Programas

Especiales

Actividades realizadas.



Indicadores:

- Índice de 2as visitas.

- Índice de V/F por tipo de establecimiento.

- Índice de cumplimiento de visitas de mejora en el plazo máximo.

- Índice de variación en la valoración de condiciones higiénico sanitarias entre establecimientos con HACCP y sin HACCP por tipo de establecimiento

- Desviación media del número de V/F por establecimiento en visitas sucesivas

- Variación de la criticidad de establecimientos (incremento / decremento de puntuación en la clasificación) por tipo de establecimiento, por comarca / Subdirección / CAPV.

- Tiempo efectivo de trabajo por inspección.

Periodicidad: Mensual, Trimestral, Semestral, Anual.

15.4 Seguimiento de Denuncias, Notificaciones y Reclamaciones.

15.4.1. Objetivo

El objetivo del proceso es establecer, definir y poner en marcha los requisitos y acciones necesarias, ante las notificaciones procedentes de Organismos Oficiales o Particulares y realizar la investigación correspondiente sobre los establecimientos, así como el inicio de otras acciones derivadas de dicha investigación, para garantizar la protección de los consumidores frente a los problemas notificados a través de este sistema.

Actuación inicial: Recepción de las Notificaciones.

Actuación final: Envío de Informe final de la Investigación realizada.

Actuaciones intermedias: Entrada en el procedimiento de intervención cautelar, procedimiento de toma de muestras, procedimiento de alertas etc.



Entradas:

PROVEEDOR ENTRADA

- Organismos Oficiales no pertenecientes a la C.A.P.V. (CCAA, AESA, Agencias de Seguridad Alimentaria etc)

- Organismos Oficiales pertenecientes a la C.A.P.V.(Otros Departamentos, Otras Direcciones, Ayuntamientos, Oficinas de Consumo etc)

- Particulares

Notificación de reclamación.

- TSP Acta de inspección.

Salidas:

CLIENTE SALIDA

- Organismos Oficiales.

- Denunciante

- Técnicos Salud Pública

- Subdirecciones de S.P.

- Denunciado

Informe final de los resultados de la investigación realizada.

Procedimiento de intervención cautelar. Acta de inspección.

AESA Informe para comunicación de alerta a la AESA.

Procedimiento de toma de muestras Informe para el procedimiento de toma de muestras

Proceso de clasificación de establecimientos (Histórico de actuaciones)

Información de la responsabilidad del establecimiento en los hechos denunciados (denuncia achacable al establecimiento) para el apartado de historial y confianza.

Archivo de establecimientos Denuncia finalizada



Indicadores:

- % de denuncias por origen.

- Nº denuncias positivas achacables al establecimiento segmentado por sectores.

Periodicidad: Trimestral, Anual.

15.5 Procedimiento de Intervención de Establecimientos Alimentarios.

15.5.1. Objetivo

El objetivo de este proceso es el de establecer, definir y poner en marcha los requisitos, las pautas de actuación y los criterios que deben aplicar los Inspectores a la hora de adoptar medidas cautelares con motivo de las inspecciones a establecimientos alimentarios, de las Resoluciones de Denegación del Director de Salud Pública o del Director Territorial, en su caso, en los procesos de Autorización Sanitaria de Funcionamiento, de las notificaciones recibidas a través del Sistema Coordinado de Intercambio Rápido de Información (S.C.R.I.), de los resultados analíticos obtenidos en los muestreos, de las investigaciones derivadas de las notificaciones y reclamaciones procedentes de Organismos Oficiales o particulares, como resultado de las actuaciones en brotes alimentarios y de la aplicación de Programas o Planes Especiales de Actuación, todo ello con el fin de garantizar la protección de los consumidores frente a los riesgos que pudieran generarse en los mencionados procesos.

Actuación inicial: Levantamiento del acta de inspección recogiendo la/s medida/s cautelar/es, causa, duración y finalidad por la que se deben adoptar las mismas.

Actuación final: Tramitar, y en su caso archivar, según los criterios establecidos la documentación generada en el proceso.


- Tramitación al Director de Salud Pública como propuesta de cierre o clausura del establecimiento para aquellos casos en que persiste el riesgo después de que el Inspector adoptó las medidas inmediatas con carácter de urgencia o en aquellos casos en que los hechos no son ilícitos el Inspector no puede adoptar dichas medidas y en aquellos establecimientos que carecen de Autorización Sanitaria de Funcionamiento ligada a Registro Sanitario.

- Tramitación al Director Territorial como propuesta de cierre del establecimiento en aquel caso en que carece de Autorización Sanitaria de Funcionamiento no ligada a Registro Sanitario.

- Tramitación al Director de Salud Pública para que dicte Resolución de decomiso y destrucción de la mercancía cuyo consumo suponga un riesgo para la salud de la población.


- Tramitación a la Dirección de Salud Pública en el caso de reexpedición de mercancías.

- Tramitación al Director de Salud Pública o al Director Territorial, en su caso, para el inicio del correspondiente expediente sancionador.


Entradas:

PROVEEDOR ENTRADA

- Proceso General de Inspección

- Proceso de Alertas Alimentarias

- Proceso de toma de muestras

- Proceso de Denuncias/Reclamaciones

- Proceso de Brotes Alimentarios

- Proceso de Autorización Sanitaria

- Programas especiales

- Actas de Inspección

- Instrucción y directrices de actuación en

Alertas Alimentarias

- Resolución Negativa de Autorización

Sanitario y/o convalidación del RGSA

Salidas:

CLIENTE SALIDA

- Proceso de Clasificación de Establecimientos

Alimentarios

- Inventario/Archivo de establecimientos

- Responsable del establecimiento

Expedientes resueltos.



Indicadores:

- Indice de cumplimiento de planes de muestras por programa

- Tiempo medio desde 2ª inspección hasta propuesta de expedientes

- Nº de expedientes con resolución de cierre

- Gravedad de sanciones (% expedientes por tipo de gravedad)

- Nº de expedientes sancionadores iniciados sobre establecimientos inspeccionados

- Nº de expedientes de paralización de actividad sobre establecimientos inspeccionados

- Nº o % de expedientes fuera de plazo % de propuestas de expedientes con iniciación de expediente

Periodicidad: Trimestral, Anual.

pliego de bases técnicas - osakidetza · el objeto del presente documento es servir de pliego de...

Documents