Pliego de Condiciones Técnicas · 2016-12-07 · Pliego de Condiciones Técnicas. Implantación y...

SCR6150c Versión 2.0(12/01/05)

Pliego de Condiciones Técnicas:

Implantación y mantenimiento de nuevo LIMS para Salud Pública

Fecha: 19/06/16 Referencia: 049/2016

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 no puede ser 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.

http://www.ejie.es/

Pliego de Condiciones Técnicas. Implantación y mantenimiento de nuevo LIMS para Salud Pública ii/70

Control de documentación

Título de documento: Pliego de Condiciones Técnicas. Implantación y mantenimiento de nuevo LIMS para Salud Pública

Histórico de versiones

Código: pct_lims_SP

Versión: 1.0

Fecha: 19/06/2016

Resumen de cambios:

Cambios producidos desde la última versión

Primera versión.

Control de difusión

Responsable: Juan José Villa Parrado

Aprobado por: Aitor Landa

Firma: Fecha:

Distribución: Alex Etxeberria, Iñigo Díaz, Aitor Landa

Referencias de archivo

Autor: Juan José Villa Parrado

Nombre archivo: PCT Sistema de Gestión de Laboratorios_v1.0 .docx

Localización:

Pliego de Condiciones Técnicas. Implantación y mantenimiento de nuevo LIMS para Salud Pública 3/70

Contenido

Capítulo/sección Página

1 Introducción 5

2 Necesidad e idoneidad de la contratación 6

3 Objeto del contrato 8

3.1 Objeto y Alcance del Servicio 8

3.2 Descripción del Servicio 8

4 Presupuesto y valor estimado 9

4.1.1. Presupuesto 9

4.1.2. Valor estimado 9

5 Requisitos del producto/servicio 11

5.1 Situación del problema 11

5.1.1. Estado inicial 11

5.1.2. Estado final 11

5.1.3. Requisitos de implantación inicial del nuevo sistema de

laboratorios, licencias y soporte de un año 13

5.1.4. Requisitos de soporte, licencias y mantenimiento

estándar del producto 44

5.1.5. Requisitos de mantenimiento a medida 45

6 Metodología Aplicable y Entorno Tecnológico. 46

6.1 Metodología de desarrollo, normativa y Guía de

Estilo 46

6.2 Metodología de pruebas 48

6.3 Modelo de aseguramiento de la calidad (SQA) 49

6.3.1. Nivel de Aseguramiento de la Calidad 50

6.3.2. Plan SQA y actividades de aseguramiento de la calidad 50


6.4 Herramientas del ciclo de vida de las aplicaciones 50

6.5 Entorno Tecnológico. 51

7 Descripción de entregables. 55

7.1 Normativa para la puesta en producción y posterior

explotación del sistema 56

8 Planificación y Organización 57

8.1 Plan de Proyecto 57

8.1.1. Plan de Entregas e Hitos de Control 57

8.1.2. Diagrama de Gantt 57

8.2 Organización del Equipo de Trabajo 57

8.2.1. Asignación de recursos a fases del proyecto 57

8.2.2. Asignación de recursos a los servicios de soporte y

mantenimiento estándar del producto 58

8.2.3. Asignación de recursos a los servicios de mantenimiento

a medida 59

8.2.4. Equipo de Trabajo 59

8.3 Transferencia Tecnológica. 61

9 Mecanismos de Seguimiento, Control y Supervisión 62

9.1 Mecanismos de Seguimiento y Control. 62

9.2 Supervisión del proyecto 62

10 Plazo de entrega y Plan de Facturación 63

11 Criterios de Adjudicación. 65

11.1 Criterios valorables mediante fórmula 65

11.2 Criterios no evaluables mediante fórmula 66

12 Estructura y Formato de la Propuesta 69

12.1 Estructura normalizada y contenido de las

propuestas. 69


1 Introducción

EJIE, Eusko Jaurlaritzaren Informatika Elkartea – Sociedad Informática del Gobierno Vasco, es la Empresa pública de servicios de las tecnologías de la información y las comunicaciones (TIC), cuya razón de existir es contribuir a la consecución de un Sector Público Vasco, moderno y eficiente, en el Marco Legal establecido por el Gobierno, con la seguridad y calidad necesarias y con el debido respeto al medio ambiente.

EJIE tiene como meta final la consecución de la satisfacción de sus clientes, siendo el instrumento común de prestación de servicios TIC en el Sector Público Vasco, y comprometiéndose en:

Construir y mantener con eficiencia y calidad la infraestructura de los Sistemas de Información, posibilitando su continuidad y seguridad.

Garantizar la interoperabilidad entre las distintas administraciones.

Servir de apoyo a las necesidades de planificación y realización de la función informática de los Departamentos y Organismos Autónomos del Gobierno, asegurando la cobertura de sus demandas con el compromiso y profesionalidad adecuados a las relaciones contractuales que se establezcan.

Por tanto EJIE debe ser, un instrumento común de referencia para la prestación de servicios TIC en el Sector Público Vasco:

Aportando valor añadido.

Proporcionando soluciones competitivas.

Transmitiendo confianza a sus clientes.

Contando con personas cualificadas y comprometidas.

Se puede obtener información más detallada y extensa en nuestra dirección de Internet http://www.ejie.eus

http://www.ejie.eus/


2 Necesidad e idoneidad de la contratación

La actividad objeto de contratación es necesaria para la prestación de un servicio que es competencia de EJIE. Dicha actividad está incluida entre los servicios que pueden ser contratados, conforme a la Instrucción sexta de las Instrucciones sobre las buenas prácticas en la contratación de servicios de Gobierno Vasco, y su objeto no contiene prestaciones que con arreglo a la Instrucción quinta deben ser satisfechas con medios propios.

Su prestación no puede ser asumida con los recursos humanos y técnicos de que dispone el EJIE siendo además inconveniente o imposible su reorganización.

Los documentos contractuales elaborados en la fase de preparación del contrato incorporan las debidas garantías para dar cumplimiento a la Instrucción octava, sobre las buenas prácticas en la celebración de contratos de servicios a fin de evitar que se incurra en los supuestos de cesión ilegal de trabajadores.

Sistema de Gestión de Laboratorios de Salud Pública

Actualmente el Departamento de Salud dispone de un sistema informático destinado a la gestión de los laboratorios normativos de la CAPV. Este sistema da soporte a las necesidades relacionadas con la gestión de muestras, desde la recepción hasta la emisión del boletín de resultados, así como a otras necesidades como el mantenimiento de los equipos o el personal.

Las funcionalidades principales de las que dispone el sistema actual son las siguientes:

Gestión y mantenimientos de los datos básicos del sistema: Laboratorios, actividades, perfiles,

atributos, parámetros, grupos, procedimientos y ficheros de configuración entre otros.

Proceso de recepción de las muestras: Mantenimiento de las muestras, emisión de etiquetas,

emisión del boletín de recepción, emisión de las listas de trabajo, carga de muestras de otros

sistemas, mantenimiento de tablas intermedias para la carga de muestras de otros sistemas.

Proceso de Análisis y resultados: Registro de resultados por muestras, por parámetros, consulta del

estado de una muestra, listado de muestras pendientes de analizar.

Proceso de Validación de las muestras: Validación de nivel 2, validación de nivel 1, informes de

validación, edición de muestras pendientes de validar.

Emisión de informes (explotación de datos): edición de boletines de resultados, reedición de

boletines, emisión de estadísticas predeterminadas, emisión de informes agrupados, emisión de la

traza de muestras.

Tal y como se ha comentado, la aplicación da soporte a otras necesidades derivadas de las actividades auxiliares de los laboratorios:

Gestión de Personal, mantenimiento y gestión del personal adscrito al laboratorio que contempla los

siguientes procesos:

Mantenimiento de la ficha de personal

Mantenimiento de las áreas de conocimiento

Emisión de fichas de personal.

Emisión de informes de calificación

Gestión de equipos. Permite la gestión y control de los equipos utilizados en el laboratorio.

Contempla los siguientes procesos:

Mantenimiento de equipos y actuaciones

Mantenimiento de tipos de medidas


Emisión de etiquetas

Emisión de informes de equipos predeterminados.

Se han identificado diversas áreas en las que el sistema actual debería ofrecer mejoras y funcionalidades adicionales. Al mismo tiempo, la tecnología empleada para construir el sistema actual ha quedado obsoleta, lo que dificulta su mantenimiento tanto evolutivo como correctivo.

Necesidad de contratación

Por todo lo anterior el Departamento de Salud, en su apuesta por implementar el uso de nuevas tecnologías así como mejorar su atención y gestión interna, se plantea la Implantación de un nuevo sistema de información en el que estén centralizadas e integradas las funcionalidades relacionadas con la gestión de las actividades llevadas a cabo en los laboratorios de Salud Pública de dicho Departamento.

El objeto del presente documento es servir de Pliego de Condiciones Técnicas en la contratación de los servicios y licencias (si aplicasen) necesarios para cumplir con los requerimientos anteriores.


3 Objeto del contrato

3.1 Objeto y Alcance del Servicio

De acuerdo a lo indicado anteriormente, el objeto de este pliego es la contratación de los servicios para la realización de la implantación, soporte y mantenimiento de un nuevo Sistema de Gestión de Laboratorios para los laboratorios de Salud Pública del Departamento de Salud del Gobierno Vasco.

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.

3.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 Requisitos del producto/servicio dentro del presente Pliego de Condiciones Técnicas.


4 Presupuesto y valor estimado

En documento separado y siguiendo lo establecido en el modelo de Pliego de Condiciones Particulares, se deberá incluir el importe Total de la Oferta Económica, para la correcta evaluación del apartado “Proposición económica” contemplado en la sección de Criterios de Valoración.

En el precio estarán incluidos todos los conceptos incluyendo los impuestos, gastos, tasas y arbitrios de cualquier esfera fiscal, derechos, gastos repercutibles, costes de transporte, entrega y, en su caso instalación, seguros, aranceles, licencias y autorizaciones de todo tipo que recaigan sobre la operación hasta la entrega y recepción de los bienes y el beneficio industrial del contratista y todo tipo de impuestos a excepción del I.V.A., del que se especificará el tipo (%) e importe total.

4.1.1. Presupuesto

El presupuesto máximo para este contrato es de 288.000,00 € (IVA no incluido). Este valor será el tomado como base para los Criterios de Valoración explicados posteriormente. Dentro de dicho presupuesto deberán incluirse tanto el proyecto de implantación inicial como los servicios de soporte y mantenimiento posteriores. Los precios máximos para cada uno de ellos serán los siguientes:

Concepto Importes máximos

(sin IVA)

Implantación del sistema de laboratorios, soporte y licenciamiento de un año inicial. 220.000,00 €

Servicio anual de licencias, soporte y mantenimiento estándar de producto.

Nota: Contratación inicial de un año y un máximo de 2 años adicionales

20.000,00 €

Tarifa horaria media para bolsa de horas de mantenimiento a medida del sistema.

Nota: Contratación inicial de dos años y un máximo de 2 años adicionales. La cuantificación de la bolsa de horas será de un máximo de 400 horas anuales.

60,00 €

El Presupuesto, en base a lo anterior, está divido en:

Implantación de nuevo sistema de Laboratorios para Salud Pública …………………………. 220.000,00

€

Soporte y mantenimiento estándar (Contratación inic.l 1 año x 20.000 €/año) ……………….. 20.000,00

€

Mantenimiento a medida – Bolsa de horas (Contrato inic. de 2 años x 400 h/año x 60 €/h)…. 48.000,00

€

4.1.2. Valor estimado

El Valor Estimado está divido en:


Implantación de nuevo sistema de Laboratorios para Salud Pública ……………………. 220.000 €

Soporte y mantenimiento estándar (máximo de 3 años x 20.000 €/año) ………………… 60.000 €

Mantenimiento a medida – Bolsa de horas (máximo de 4 años x 400 h/año x 60 €/h)…. 96.000 €

Lo que resulta en un VALOR ESTIMADO total de 376.000,00 € (IVA no incluido) incluyendo las potenciales prórrogas anteriormente descritas.

Las licencias de software de base que estén incluidas dentro de los estándares tecnológicos del presente Pliego de Condiciones Técnicas no deberán considerarse dentro de la oferta económica y serán proporcionadas por EJIE. Dentro de éstas licencias se encuentran las siguientes:

Servidor:

o Sistema Operativo

o Software de infraestructura: Monitorización, Operación, Virtualización, etc.

o Motor de Base de Datos

o Servidor de Aplicaciones

Cliente

o Sistema operativo

o Motor de ejecución en cliente si fuera necesario

Del mismo, el hardware necesario para proporcionar la funcionalidad y arquitectura en los diferentes entornos, será proporcionado por EJIE y no deberá considerarse dentro de la oferta económica a prestar en ningún caso.


5 Requisitos del producto/servicio

5.1 Situación del problema

5.1.1. Estado inicial

En la actualidad el departamento realiza la gestión de laboratorios mediante un sistema de información desarrollado a medida sobre tecnología Visual Basic. Dicho sistema permite gestionar toda la información relativa a la actividad desarrollada en los laboratorios normativos de la CAPV.

Gestión y mantenimientos de los datos básicos del sistema

Proceso de recepción de las muestras.

Proceso de Análisis y resultados

Proceso de Validación de las muestras

Emisión de informes (explotación de datos)

Gestión del personal adscrito al laboratorio

Gestión y control de los equipos utilizados en el laboratorio.

Por otro lado, el departamento cuenta con otra aplicación destinada a la gestión de almacén. Esta aplicación permite la gestión y control del material necesario en el laboratorio.

Por último, cabe mencionar que el sistema actual no ofrece la posibilidad de realizar la explotación de datos relativos a la actividad llevada a cabo por los laboratorios.

5.1.2. Estado final

El estado final deseado se caracteriza por un sistema de Gestión de Laboratorios, que se encuentre implantado y estable en entorno productivo, funcionando en condiciones óptimas en cuanto a funcionalidad y rendimiento, que sustituya a los anteriores aplicativos cubriendo la totalidad de las necesidades detectadas y que se detallan a continuación.

Deberán contemplarse el soporte y licencias correspondientes a los siguientes colectivos definidos de modo preliminar:

Usuarios de soporte y administradores de sistema que se estimen necesarios.

Usuarios correspondientes a la administración central de Salud Pública en el Gobierno Vasco

Usuarios correspondientes a los laboratorios de Salud Pública del Gobierno Vasco

y/o a aquellas que se determinen en la fase de análisis como necesarias para el correcto funcionamiento del sistema de laboratorios por parte de EJIE.

Dichas necesidades son orientativas para la correcta elaboración de una oferta en respuesta al presente Pliego de Condiciones Técnicas. No obstante, estas funcionalidades demandadas podrán ser completadas por el ofertante y, en todo caso, terminarán de ser concretadas en los trabajos de análisis a desempeñar en virtud del presente Pliego de Condiciones Técnicas.


Las tareas incluidas en los servicios objeto de contratación en respuesta al presente pliego incluyen:

Análisis del Sistema de Información. La empresa adjudicataria del contrato trabajará de forma coordinada

con los responsables que designe EJIE y el Departamento de Salud, para la ejecución y documentación de

las tareas de análisis del sistema de información.

Diseño del Sistema de Información. De forma coordinada con los responsables que designe EJIE, la

empresa adjudicataria realizará y documentará las tareas de diseño del módulo objeto de la contratación.

Construcción del Sistema de Información. Es responsabilidad de la empresa adjudicataria la realización de

todos los trabajos de desarrollo informáticos necesarios para la adaptación del sistema de información y

cobertura de los requerimientos incluidos en el presente Pliego de Condiciones así como aquellos que sean

detectados en la fase de análisis..

Implantación del Sistema de Información en los diferentes entornos: Desarrollo, Pruebas y Producción. El

adjudicatario realizará las labores de implantación del Sistema, incluyéndose hasta el entorno productivo,

realizando las pruebas necesarias y respetando los procedimientos de implantación e instalación

establecidos por EJIE

Operación y Monitorización. El nuevo sistema deberá integrarse dentro de los procesos y sistemas de

control para la operación, backup, recuperación y monitorización de EJIE para su correcto funcionamiento en

los diferentes entornos.

Formación. Deberán realizarse las actividades de formación necesarias tanto a nivel funcional como técnico

que fueran requeridas.

Soporte y licencias (si aplicaran). Se incluyen como necesidades aspectos de soporte adicionales a los

mencionados anteriormente. Estas se detallarán posteriormente en el presente documento.

Lo anterior se formalizará en un conjunto de servicios agrupados del siguiente modo:

1. Implantación inicial del sistema de laboratorios y un año de licenciamiento y soporte posterior a la

implantación y aceptación de la misma por parte de EJIE.

2. Soporte, mantenimiento y licenciamiento estándar de producto de un año a partir a partir de la

finalización de los servicios contemplados en el punto 1 y una contratación adicional de un máximo de

2 años.

3. Mantenimiento a medida del producto, en formato de bolsa de horas, a partir de la implantación del

nuevo sistema de laboratorios y su aceptación por parte de EJIE. La duración del servicio será de dos

años iniciales y un máximo de dos años de modo adicional.

Duración de los servicios

A modo aclaratorio, con una duración estimada de 10 meses de implantación del nuevo sistema de laboratorios y una fecha estimada de proyecto al 01/09/2016, podríamos simbolizar los servicios anteriores en el siguiente calendario:


5.1.3. Requisitos de implantación inicial del nuevo sistema de laboratorios, licencias y soporte de un año

Sin perjuicio de lo anterior, 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 Condiciones 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 correspondientes. 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:


5.1.3.1. Gestión de Tablas Maestras

Gestión de Tablas Maestras

Descripción: La aplicación debe poder gestionar todas las tablas maestras de la aplicación. En esta sección los apartados de gestión, propiedades y relaciones

son orientativos pero su especificación concreta quedará definida en la fase de análisis.

ID

Requerimiento

Requerimiento Descripción detallada

RQ-MAE-001 Mantenimiento Laboratorio Laboratorio: Cada una de las sedes del laboratorio de Salud Pública.

Propiedades: Denominación, direcciones de contacto, personal de contacto, aspectos específicos de cada laboratorio que han de constar en los informes (encabezamientos…), acreditaciones disponibles y posibilidad de inclusión de código de identificación.

Gestión: Alta, baja, modificación de un laboratorio, generación de listados, búsqueda y ordenación con filtros.

Relaciones: Con secciones (que componen el laboratorio).

RQ-MAE-002 Mantenimiento Secciones Sección: Cada una de las unidades diferenciadas (por estrategia, afinidad metodológica, área de trabajo…) que componen cada sede de un Laboratorio.

Propiedades: Código de identificación, denominación, personal de contacto, acreditaciones.

Gestión de Secciones: Alta, baja, modificación de una sección, generación de listados, búsqueda y ordenación con filtros

Relaciones: Con laboratorios, personal adscrito, procedimientos, y parámetros/subparámetros.


RQ-MAE-003 Mantenimiento Actividades Actividad: Analítica o grupo de analíticas relacionada/s con un programa o área de trabajo diferenciada.

Propiedades: Código de identificación, denominación. Los contadores de muestras para cada laboratorio y la codificación de muestras serán por actividad y año. Comunes para todas las sedes de laboratorio.

Deberá incluir la opción de ocultar la actividad en las muestras para que no se muestren en el informe de actividades.

Gestión de Actividades: Alta, baja y modificación de una actividad, asignación de atributos y perfiles para la actividad. Generación de listados, búsqueda y ordenación con filtros.

Relaciones: Atributos, perfiles, procedimientos, parámetros/subparámetros, solicitantes y tipo de

informe.

RQ-MAE-004 Mantenimiento de Atributos Atributos: Características de las muestras y las solicitudes, que se registran en el momento de la recepción y que son específicas de la muestra-solicitud. (ej. Solicitante, punto de muestreo, estado de la muestra, tamaño de la muestra, marca, fecha de muestreo…).

Propiedades: Código de identificación, denominación, opción de inclusión o no en informes. Comunes a todas las sedes.

Gestión de Atributos: Alta, baja y modificación de atributos. Generación de listados, búsqueda y ordenación con filtros.

Relaciones: Actividades y Solicitantes.

RQ-MAE-005 Mantenimiento de Perfiles Perfil: Dentro de una Actividad, es un grupo de subparámetros que componen el ensayo o

conjunto de ensayos a realizar sobre una muestra.

Propiedades: Código de identificación, denominación. Comunes a todas las sedes.

Gestión de Perfiles: Alta, baja, activación/desactivación y modificación de perfiles (inclusión

exclusión de subparámetros/procedimientos). Generación de listados, búsqueda y ordenación

con filtros.


Relaciones: Actividades, parámetros, procedimientos y solicitantes.

RQ-MAE-006 Mantenimiento de Parámetros Parámetro: Ensayo analítico específico que puede llevarse a cabo mediante uno o varios

métodos/procedimientos.

Propiedades: Código de identificación, denominación, y código para bases de datos europeas. Comunes a todas las sedes.

Gestión de Parámetros: Alta, baja y modificación de parámetros. Generación de listados,

búsqueda y ordenación con filtros.

Relaciones: Grupos de parámetros, subparámetros, perfiles, procedimientos, actividades y

secciones.

RQ-MAE-007 Mantenimiento de Subparámetro Subparámetro: Parámetro en el que se han especificado aspectos técnicos metodológicos o que

tienen relevancia para la expresión de resultados.

Propiedades: Código de identificación, denominación, código parámetro para bases de datos europeas, procedimiento de ensayo, código metodológico para bases de datos europeas, expresión de resultados (unidades, cifras significativas) incertidumbre. (Los aspectos subrayados han de poder modificarse, si se precisa, desde la introducción de resultados).

Gestión de Subparámetros: Alta, baja y modificación de subparámetros. Generación de

listados, búsqueda y ordenación con filtros.

Relaciones: Grupos, perfiles, procedimientos, actividades, secciones.

RQ-MAE-008 Mantenimiento de Procedimientos Procedimiento: Método protocolizado de ensayo para llevar a cabo el análisis de uno o varios

subparámetros.

Propiedades: Código de identificación, denominación, status de acreditación, matrices a las que aplica, expresión de resultados (cifras significativas, unidades), incertidumbre y código del fundamento metodológico para bases de datos europeas.

Gestión de Procedimientos: Alta, baja, modificación de procedimientos, listado con la

posibilidad de selección previa que restrinja la información de procedimientos y permita


ordenaciones alternativas. Un procedimiento puede llegar a tener varias técnicas.

Relaciones. Perfiles, parámetros, actividades, secciones.

RQ-MAE-009 Mantenimiento de Grupos Grupo: Agrupación de subparámetros cuyo objeto es que consten bajo el mismo epígrafe dentro de un informe.

Propiedades: Código de identificación y denominación.

Gestión de Grupos: Permitir el alta, baja, modificación y listado con la posibilidad de filtros y ordenación.

Relaciones: Subparámetros y actividades.

RQ-MAE-010 Mantenimiento de Técnicas Técnica: Método de análisis diferenciado por su fundamento.

Propiedades: Código de identificación, denominación y código metodológico para bases de datos europeas.

Gestión de Técnicas: Permitir el alta, baja, modificación, listado con la posibilidad de filtros y ordenación.

Relaciones: Subparámetros y actividades.

RQ-MAE-011 Mantenimiento de Solicitantes

Solicitante: Servicio, entidad o persona física que requiere un análisis al laboratorio.

Propiedades: Código de identificación, denominación, y dirección.

Gestión de Solicitantes: Permitir el alta, baja, modificación, listado con la posibilidad de filtros y ordenación.

Relaciones: Actividades.

RQ-MAE-012 Mantenimiento de Matrices (Tipos de muestras)

Matriz (Tipo de muestra): Objeto o tipo de material sobre el que se realiza el análisis.

Propiedades: Código de identificación, denominación y código tipo de muestra para bases de datos europeas.

Gestión de Matrices: Permitir el alta, baja, modificación, listado con la posibilidad de filtros y


ordenación.

Relaciones: Actividades, subparámetros, procedimientos y grupos.

RQ-MAE-013 Mantenimiento de Unidades Unidades Analíticas: Tipos de magnitudes sobre las que se realiza el análisis.

Gestión de Unidades Analíticas: Permite el alta, baja y modificación de los tipos de magnitudes que se necesiten en la aplicación.

Relaciones: Procedimientos y subparámetros.

5.1.3.2. Gestión de Muestras

Gestión de muestras

Descripción: La aplicación será útil para dar de alta a las muestras, previa solicitud analítica, registrar los resultados analíticos, validarlos por parte del el personal

autorizado y, finalmente, para la emisión de los correspondientes informes analíticos.

ID

Requerimiento


RQ- MUE -001

Recepción y registro de muestras La recepción de muestras conlleva la realización de una serie de acciones que se definirán en la fase de análisis y entre las que destacamos algunas de ellas brevemente:

- Dar de alta muestras asignándoles un código único (código correlativo anual por actividad

y por laboratorio).

- Recoger toda la información de la muestra, incluyendo los datos del solicitante y las fechas

de recepción y muestreo.

- Podrá recogerse toda la información precisa para la generación de informes de análisis

(requisitos ENAC) y para la explotación de resultados.

- Asignación de un perfil analítico.


- Modificación de atributos o perfiles mientras no se haya realizado la validación final.

- Copia de muestra previa con el objeto de facilitar altas de muestras.

RQ- MUE -002 Listados de Muestras recibidas Emisión de listados de las muestras recibidas, pudiéndose filtrar por actividad, fecha, sección, tipo de perfil, dichos listados se definirán en la fase de análisis.

RQ- MUE -003 Muestras de Códigos de barras Las muestras recepcionadas podrán usar códigos de barras para su identificación.

RQ- MUE -004 Consulta de la muestra registrada Generación de consultas parametrizables por el usuario sobre las distintas muestras dadas de alta

en la aplicación y sobre su estado en lo referente al proceso de análisis.

RQ-MUE-005 Generación de etiquetas para muestras

registradas

La aplicación generará el número de etiquetas necesarias con los datos de identificación que se consideren y código de barras si es preciso. Se podrá volver a generar etiquetas en caso de modificación o consulta de las muestras ya registradas en cualquier momento.

El formato de las distintas etiquetas a generar se definirá en la fase de análisis del proyecto.

RQ-MUE-006 Baja de muestra Posibilidad de dar de baja a una muestra que previamente se ha dado de alta, sin perder la trazabilidad en el proceso (registro del motivo de la baja).

Debe poder conocerse la persona-usuario que ha dado de baja la muestra.

RQ-MUE-007 Muestras pendientes de analizar Posibilidad de obtener información sobre muestras pendientes de analizar como por ejemplo:

análisis pendientes por muestra, pendiente de analizar por sección, pendiente de analizar por

parámetro y otros que puedan ser requeridos por el usuario. Obtención de listados con los

resultados de las consultas que se verán por pantalla y con posibilidad de ser impresos.

RQ-MUE-008 Parametrización de Resultados La parametrización de resultados debe de permitir una serie de acciones que se definirán en la

fase de análisis. A modo de ejemplo se describen algunas de ellas:

Permitir la notación exponencial.

Poder definir el redondeo en función del parámetro o de la magnitud, incluso hacer el


redondeo por tramos.

Indicación de las unidades.

Indicación del límite de cuantificación.

Indicar la incertidumbre de los resultados.

Posibilidad de incluir Límite inferior y superior.

Posibilidad de incluir valores por defecto.

Mostrar alertas cuándo se sobrepasen los valores máximos y mínimos.

Se llevará a cabo una parametrización general para cada parámetro, asignando unidades, cifras significativas (por tramos del rango si es necesario), forma de expresión (decimal, exponencial), límite de cuantificación, incertidumbre (por tramos del rango si es necesario). Ahora bien, será posible la modificación de estos aspectos en el proceso de registro individual de resultados.

RQ-MUE-009 Cálculos/algoritmos matemáticos a

realizar en las muestras

La aplicación podrá obtener los resultados a registrar a partir de cálculos/algoritmos realizados con datos de la muestra o del análisis.

RQ-MUE-010 Registro de Resultados por Muestras

individuales

En la introducción de resultados y su modificación se mostrarán a los usuarios sólo aquellos parámetros para los que tengan permiso. En esta fase también podrán añadirse nuevos parámetros, así como las fechas de inicio y final de análisis, modificando los datos que se estimen oportunos. Se guardarán los datos modificados en las entidades correspondientes así como una traza con todos los cambios realizados.

RQ-MUE-011 Incluir comentarios en registro de

muestras individuales

Se podrán incluir comentarios estándar automáticos y específicos según condición, visualización del cumplimiento de la Norma y la inclusión de valores del tipo “límite” inferior o superior. Esto quedará definido en la fase de análisis.

RQ-MUE-012 Registro de Resultados por parámetro Podrá seleccionarse un parámetro que afecte a varias muestras visualizándolo en todas ellas y siendo posible, además, ver los parámetros que aún no han sido validados.

Podrá fijarse un valor del parámetro y asignarlo a todas las líneas seleccionadas.

En caso de cambio, se guardará la traza, y se actualizarán los datos en las entidades correspondientes.

Será posible incluir y quitar muestras.

Posibilidad de asignar a una determinación/parámetro dos unidades de medida diferentes.


Estas y otras funcionalidades que se pueden hacer en el registro de resultados por parámetro se definirán en la fase de análisis.

RQ-MUE-013 Registro de Resultados por grupo de

Muestras

Entrada de resultados por grupo.

Seleccionado un grupo de muestras que no han sido validadas podrán fijarse los distintos valores que son necesarios para el registro de resultados, podrán quitarse parámetros a una o varias muestras. También deberán ser contemplados requerimientos para muestras individuales (RQ-MUE-008). Todas las funcionalidades quedarán definidas en la fase de análisis.

Se valorará positivamente introducir los datos de forma matricial.

RQ-MUE-014 Carga resultados a partir de fichero Carga automática de resultados a partir de ficheros de formato txt, csv, excel y otros formatos que tendrán unas estructuras determinadas y que se definirán en la fase de análisis.

RQ-MUE-015 Carga automática de resultados Conexión instrumental para la carga automática de resultados desde los equipos del área de Metalobolopatías. Para los aparatos existentes Auto Delfia , Delfia, HPLC-MS, y un cromatógrafo de líquidos. Este proceso se definirá en la fase de análisis.

RQ-MUE-016 Validación de Resultados Existirán varios Niveles de Validación como pueden ser a Nivel de Sección y a Nivel de Jefe de Laboratorio. El usuario sólo podrá validar al Nivel que tenga permiso, siempre y cuando la muestra haya sido validada por el Nivel inferior a él. Podrán validarse todos aquellos parámetros que tengan valor. Antes de realizar la validación se podrá consultar la muestra. Se actualizarán los campos de usuario y validación.

Se podrán añadir comentarios, tanto estándar prediseñados, como específicos en los distintos niveles de validación.

Existirán filtros de selección que se definirán en la fase de análisis.

RQ-MUE-017 Listado de muestras pendientes de

Validar

La aplicación mostrará la muestras pendientes de validar de cada uno de los niveles que hay definidos en la aplicación, dependiendo del valor seleccionado en el filtro. Si filtramos por nivel de validación de Jefe de Laboratorio, mostrará todas las muestras que aún no hayan sido validadas a ese nivel.

También se podrá filtrar por Sección para aquellos usuarios que tengan acceso a más de una sección.

RQ-MUE-018 Desvalidación de Resultados Existirá la posibilidad de realizar la “desvalidación” de los resultados, según permiso asignado, en los distintos niveles de validación. Con que un único parámetro se desvalide, si la muestra esta


validada a ese nivel, toda la muestra quedará no validada a ese nivel.

RQ-MUE-019 Desvalidación muestra a muestra Posibilidad de “desvalidar” resultados muestra a muestra.

RQ-MUE-020 Desvalidación parámetro a parámetro Posibilidad de “desvalidar” resultados parámetro a parámetro.

RQ-MUE-021 Custodia y trazabilidad

Hay que reflejar en la aplicación todas las actuaciones que se realicen con la muestra, desde el

momento que se registra en el laboratorio. Esta información puede ser consultada en cualquier

momento desde la aplicación.

RQ-MUE-022 Facilitar la visualización de las muestras La aplicación deberá facilitar en la medida de lo posible la visualización de la gestión de muestras

reduciendo el número de clics a realizar. El nivel de usabilidad a alcanzar será determinada en la

fase de análisis del proyecto.

5.1.3.3. Gestión de Boletines e Informes

Gestión de Boletines e Informes

Descripción: Permitirá gestionar los boletines e informes que generará la aplicación

ID Requerimiento Requerimiento Descripción detallada

RQ-BOL-001 Idioma de los boletines e Informes En los informes de resultados analíticos el idioma será el indicado por el solicitante: en euskera, castellano o euskera y castellano tal y como requiere la normativa.

RQ-BOL-002 Acreditación de valores Los valores que aparecen en los informes o boletines de resultados que correspondan a ensayos que no estén acreditados deberán aparecer con un asterisco u otra marca que los


diferencie de los parámetros acreditados, siempre cumpliendo las pautas que ENAC disponga al respecto.

RQ-BOL-003 Especificación ISO 17025 Los informes han de cumplir las especificaciones requeridas por la UNE EN ISO 17025 y la Entidad Nacional de Acreditación.

RQ-BOL-004 Mantenimiento de Comentarios Podrán diseñarse comentarios tipo para las situaciones más habituales que luego podrán ser

elegidas como opción a la hora de elaborar el informe. También podrán incluirse comentarios

específicos si así se requiere.

RQ-BOL-005 Tipo de Boletines por Actividad Podrá asignarse un tipo de boletín a cada actividad. La configuración del mismo que se definirá

en la fase de análisis.

RQ-BOL-006 Tipo de Boletines por Perfil Podrá asignarse un tipo de boletín a cada perfil. La configuración del mismo que se definirá en

la fase de análisis.

RQ-BOL-007 Recepción y boletín/informe de recepción Se permitirá filtrar las muestras por los atributos o datos adicionales recogidos en el momento de la recepción de la muestra (fecha de recepción, de muestreo, solicitante…). Eligiendo el periodo en el que se han recibido las muestras. Los campos de fecha desde y fecha hasta se rellenarán por defecto con la fecha del sistema.

Se podrá determinar la información a mostrar. Se podrá elegir el número de copias, el orden de los atributos y parámetros. Deberá mostrar la información relativa al Solicitante, fecha de recepción, atributos y perfil analítico.

El boletín de recepción se podrá utilizar como lista de trabajo en cada sección del Laboratorio.

RQ-BOL-008 Informes de Validación Informes en los que se mostrará la actividad, la muestra, la fecha de inicio y las fechas de

validación, nivel de validación y resto de la información a este respecto que se requiera sobre

la muestra.


RQ-BOL-009 Boletín de Resultados A continuación se adelantan algunas características que deberán cumplir los boletines de resultados, las cuales se detallarán durante la fase de análisis:

Los informes dispondrán de un identificador único y correlativo por laboratorio.

El formato de los boletines, el cual será escogido en el momento de la validación, ha de

ser flexible, fácilmente configurable por los usuarios.

Podrán emitirse los boletines de análisis automáticamente al realizar la validación del

Jefe de Laboratorio.

La expresión de resultados en los informes será compatible con las posibilidades

planteadas en la configuración de los parámetros (notación científica, decimal…).

Los formatos diseñados considerarán la incertidumbre como información a incluir, si

fuera necesario

La aplicación deberá permitir agrupar muestras de un mismo cliente/solicitante en un

mismo boletín.

En caso de desvalidación de resultados, se guardará el boletín emitido, relacionándose

con el nuevo.

Todos los comentarios reseñados en RQ-MUE-011 y RQ-BOL-004 podrán ser incluidos

en los informes. En cualquier caso, los informes cumplirán con todos los requisitos de

las normas ISO 17025, ISO-15189 y los requisitos del acreditador ENAC al respecto.

RQ-BOL-010 Boletines parciales Será posible la emisión de informes parciales especificándose claramente cuál es su nivel de validación. Estos informes deberán ser lo más flexibles y adecuarse a las necesidades del usuario que se determinará en la fase de análisis.

5.1.3.4. Gestión de usuarios

Gestión de usuarios

Descripción: Permitirá gestionar; dar permisos al personal de los Laboratorios que utilizan la aplicación. Permitirá dar de alta/baja a los usuarios así como definir

los niveles de permiso de cada uno de ellos. Podrán realizarse consultas de los usuarios ordenados por Laboratorio u otros criterios a concretar en la fase de


análisis.


RQ-USU-001 Alta/Baja/Modificación de usuarios La aplicación ha de permitir dar el alta, baja y modificación de usuarios por Laboratorio, con al menos la siguiente información:

Código.

Nombre y apellidos.

Cargo.

Sección/es a la que está asociado.

Laboratorio al que ha sido asignado.

Además deberá contener aquella información que se consideré oportuna por parte de los

usuarios y que quedará definida en una fase de análisis.

Deberá determinarse el modo de provisión y gestión de usuarios de modo coordinado con el

sistema de provisión XLNETs si así se considera oportuno por parte de EJIE en las fases de

análisis y/o diseño del proyecto.

RQ-USU-002 Asignación de Perfiles/Roles Todos los usuarios que accedan a la aplicación deberán tener asociado al menos un

determinado perfil. Los perfiles tendrán asociados una serie de funcionalidades, que conllevará

que puedan acceder o no a ciertas partes de la aplicación. Se valorará positivamente que todo

el tratamiento de perfiles sea fácilmente configurable y modificable por un usuario

administrador de la aplicación. La asignación de perfiles quedará definida.

RQ-USU-003 Asignación de permisos Los usuarios de la aplicación deben tener establecidos diferentes niveles de permisos considerando las siguientes responsabilidades:

Validación a nivel de Responsable Técnico.

Validación a Nivel de Jefe de Laboratorio.

Desvalidación de resultados.

Los permisos son a nivel del laboratorio en el que trabaja.


Los usuarios sólo tendrán acceso a las muestras de las secciones a los que están

asociados.

Así como aquellas que se definan en la fase de análisis


5.1.3.5. Gestión de Equipos

Gestión de Equipos

Descripción: Realización del Registro, Mantenimiento, Calibración, Verificación de los equipos de los Laboratorios


RQ-EQU-001 Mantenimiento de Equipos La aplicación ha de poder dar de alta, baja y modificación de equipos del laboratorio en los que se registrará la información mediante fichas de equipos, proveedores.

Existirá un listado de equipos con sus respectivos filtros de selección que permitan la búsqueda por los parámetros que se consideren (p.ej. diferenciando los que precisan calibración de los restantes). Todo esto se definirá en la fase de análisis.

RQ-EQU-002 Registro Operaciones Descripción y registro de operaciones a realizar en cada equipo.

RQ-EQU-003 Etiquetas de identificación Emisión de etiquetas de identificación de los equipos y de su estado de uso.

RQ-EQU-004 Consulta de Operaciones de Equipos Consulta de los equipos con operaciones pendientes de realizar.

RQ-EQU-005 Calibración y Verificación Entrada de datos de las operaciones de calibración, creación de hojas de cálculo.

RQ-EQU-006 Etiquetas de Calibración Emisión de Etiquetas de Calibración de los equipos y su estado de uso.

RQ-EQU-007 Asignación de Certificados Asignación de las correspondientes certificados a los equipos.


5.1.3.6. Gestión de Personal y conocimiento

Gestión de Personal y conocimiento

Descripción: Inclusión de asignación de tareas y responsabilidades en función del puesto y la cualificación del personal


RQ-PER-001 Mantenimiento Personal Poder dar de alta, modificar los datos del personal de cada Laboratorio.

La información del personal del laboratorio que se podrá gestionar mediante la aplicación se definirá en la fase de análisis. Dentro de esa información deberá estar entre otra la siguiente información:

Áreas de conocimiento.

Cualificaciones.

Planes de formación.

Puestos de trabajo.

Curriculums Vitae actualizados.

RQ-PER-002 Mantenimiento de Conocimiento Asignación de conocimientos y titulaciones por puesto de trabajo.


5.1.3.7. Módulo de Explotación de la Información

Módulo de explotación de la información

Descripción: Consulta de las distintas actividades analíticas de los Laboratorios y volcado de datos ficheros Excel y/o PDF


RQ-EST-001 Consulta de Muestras recibidas La consulta se podrá realizar por Laboratorio o de forma global para los tres Laboratorios para un periodo de tiempo. La consulta se podrá realizar bajo el filtro de distintos criterios tales como :

Área analítica.

Solicitante.

Actividad.

Tipo de análisis.

Tipo de muestra.

Estado de Gestión.

En un determinado periodo.

Esto quedará definido en la fase de análisis.

RQ-EST-002 Consulta de Número de Muestras

analizadas

Número de muestras analizadas, en un determinado periodo, por Área analítica, Solicitante, Actividad, Tipo de análisis, Tipo de muestra, parámetros realizados por actividad, perfil y método.

RQ-EST-003 Carga de trabajo en muestra Carga de trabajo en muestra, en un periodo por Laboratorio, Área analítica, Actividad, Tipo de análisis, Tipo de muestra y Estado de la gestión.

RQ-EST-004 Carga de trabajo por Parámetro Carga de trabajo por Parámetro, en un periodo por Laboratorio, Área analítica, Parámetro, Tipo de análisis, Método y Estado de la gestión.


RQ-EST-005 Resultados Históricos Resultados históricos de un periodo por Laboratorio, Área analítica, Parámetro y Tipo de análisis.

RQ-EST-006 Representación Gráfica Representación gráfica de las consultas que se determinen en la fase de análisis. Se valorará positivamente que se puedan visualizar diferentes tipos de gráficas para una misma consulta.

RQ-EST-007 Tiempo de respuesta Estadística referida al tiempo de respuesta de un Laboratorio por muestra o por parámetro.

5.1.3.8. Gestión de medios y reactivos preparados internos

Gestión de medios y reactivos preparados internamente

Descripción: Gestión de medios y reactivos preparados internamente, garantizando su control y trazabilidad


RQ-REA -001 Mantenimiento de Reactivos Fichas de identificación de los medios y reactivos donde se recoja, componentes, fechas de fabricación, caducidad, baja y demás información que es necesaria que la aplicación recoja y que se definirá en la fase de análisis.

RQ-REA -002 Emisión de etiquetas Emisión de las etiquetas necesarias para los reactivos y preparados internos.

RQ-REA -003 Control de unidades Control de unidades y su caducidad.


5.1.3.9. Integraciones

Integraciones

Descripción: Una de las principales características del sistema de información es su conexión con diferentes sistemas externos.

ID

Requerimiento


RQ-INT-001 Integración mediante Webservices Se desarrollará uno o varios webservices, que podrán ser llamados por las aplicaciones que así lo precisen. El/los webservice/s deberá permitir una serie de funcionalidades que se definirán en la fase de análisis. Podemos destacar algunas de ellas a modo de ejemplo:

Solicitud de análisis de una muestra.

Consulta de resultados de una muestra.


5.1.3.10. Módulo Internet

Módulo Internet

Descripción: Solicitud de analítica por un tercero a través de la web. En caso de aceptación de la muestra por parte del laboratorio, se procederá a su registro


RQ-CLI-001 Gestión de Solicitantes y permisos Dar de alta, baja y modificación a los distintos solicitantes así como la asignación de los permisos necesarios.

RQ-CLI-002 Estado de las muestras y resultados El solicitante podrá comprobar el estado de las muestras y sus resultados a través del módulo.

RQ-CLI-003 Boletines de resultados El solicitante tendrá la posibilidad de visualizar los boletines validados y firmados, incluso teniendo la posibilidad de descargarlos.

RQ-CLI-004 Históricos de resultados Posibilidad de consultar históricos de solicitudes y resultados, pudiendo descargar la información en formato Excel, PDF o similares.

5.1.3.11. Seguridad

Seguridad

Descripción: El nuevo sistema deberá cumplir los requerimientos definidos a continuación que doten al sistema de una completa seguridad.



RQ-SEG-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.

RQ-SEG-002

Acceso y autorización La autenticación de usuarios para el acceso a la aplicación se realizará mediante XLNET si

así se considera oportuno por parte de EJIE. En el caso del módulo de Internet se definirán

los requisitos que garanticen el acceso seguro por parte de declarantes autorizados.

RQ-SEG-003 Permisos de usuario Cada usuario sólo debe visualizar los módulos para los que tiene permisos y los datos

correspondientes.

RQ-SEG-004 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 de otro tipo también como pérdida de usuario, tarjeta con certificado de

acceso, etc. Los escenarios de contingencia a cubrir se detallarán en fase de análisis.

REQ-SEG-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.


El uso de una herramienta alternativa a OSA podrá ser valorada positivamente por EJIE, siendo tarea del adjudicatario realizar las tareas necesarias si así fuera oportuno.

REQ-SEG-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.

REQ-SEG-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.


5.1.3.12. Migración de datos

Migración de datos

Descripción: Se deberá realizar una migración de los datos existentes en la base de datos de la aplicación actual, de modo que se garantice que no se produzcan

pérdidas de información.


RQ-MIG-001

Migración de datos Se deberá migrar aquella información existente en la base de datos actual de la aplicación de

Gestión de Laboratorios y que se considere necesaria para que no se produzcan pérdidas de

información de negocio.

RQ-MIG-002

Procedimientos de calidad En el proceso de migración de datos deberán realizarse tareas de análisis de calidad y

transformación que se consideren necesarias para asegurar el éxito en la migración.

RQ-MIG-003

Volumetría de datos A modo de requerimiento general y con el propósito de estimación de esfuerzos, deberá

considerarse la migración de la totalidad de la información residente en el sistema actual.

Algunos datos aproximados en el momento de la redacción de este documento que podrían

ser relevantes son los siguientes:

Año inicial: 2002

Muestras: 500.000

Analíticas y estados de las mismas: 16.000.000


5.1.3.13. Generales

Generales

Descripción: De modo general, el nuevo sistema deberá satisfacer los siguientes requerimientos.


RQ-GEN-001

Bilingüismo La aplicación deberá permitir la consulta de la información tanto en euskera como en

castellano, así como la transición entre ambos idiomas a demanda del usuario.

También se debe valorar el que se permita el mantenimiento y presentación de la información

relativa a las muestras.

RQ-GEN-002

Estructura general del Sistema El Sistema tendrá una estructura basada entre otras en las siguientes entidades:

Actividades.

Perfiles.

Atributos.

Parámetros Analíticos/Subparámetros.

Procedimientos.

Grupos/SubGrupos.

Técnicas.

Unidades Analíticas.

Estas entidades se determinarán en las fases de análisis.


RQ-GEN-003 Soporte para el despliegue en fases En el caso de que dentro del proyecto se determine necesario un despliegue en fases de la

solución, deberá garantizarse el funcionamiento de la solución global, realizando aquellas

acciones que se precisen oportunas, y la compatibilidad con el aplicativo anterior, hasta que

el nuevo no esté totalmente operativo.

RQ-GEN-004 Norma UNE-EN ISO/IEC 17025

Norma UNE-EN ISO 15189

La aplicación ha de cumplir los requisitos recogidos en la Norma UNE-EN ISO/IEC 17025

Requisitos generales para la competencia de los laboratorios de ensayo y calibración y la

Norma UNE-EN ISO 15189 Laboratorios clínicos. Requisitos particulares para la calidad y

competencia.

RQ-GEN-005 Traza y auditoría Dado que se trata de una aplicación con datos de nivel alto en cuanto a protección de dato se

refiere, se garantizará en todo momento la auditoría y trazabilidad de acceso y modificación a

la información. Así como se facilitará una explotación ágil y sencilla de dicha trazabilidad, en

todos los módulos de la aplicación, permitiendo distinguir las operaciones realizadas con la

información. Esta explotación deberá realizarse no sólo a nivel de responsable de seguridad

del fichero sino a nivel de ciertos perfiles de usuario, dada la sensibilidad de la información

que contiene, por lo que este tipo de operaciones deberán quedar especialmente reflejadas.

RQ-GEN-006 Almacenamiento de documentación La información documental referente a los boletines e informes se deberá albergar en un gestor documental. El gestor documental concreto a utilizar, se concretará en fase de análisis. Si antes del arranque de la aplicación no se hubiera concretado aún el Gestor Documental a utilizar, se implementará la aplicación de modo que se encapsule el tratamiento de la documentación en clases, métodos y objetos, de modo que el cambio posterior tenga el mínimo impacto.

Además en fase de análisis, se revisará la tipología de documentación que es necesario

almacenar.

RQ-GEN-008 Codificación Internacional Posibilidad de utilizar una codificación internacional (Standard Sample Description for food and feed-SSD.


RQ-GEN-009 Unicidad de la lógica de negocio El sistema deberá contar con las facilidades necesarias para que la lógica de negocio sea común para la totalidad de los laboratorios con el objeto de facilitar las tareas de implantación, formación, soporte y mantenimiento posterior.

5.1.3.14. Requerimientos técnicos generales

Requerimientos técnicos generales

Descripción: 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 Condiciones Técnicas.


RQ-TEC-001 Arquitectura general del sistema Las ofertas recibidas como respuesta al presente Pliego de Condiciones 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.

• Los entornos contemplados deberán ser los siguientes: desarrollo, pruebas-integración, y producción.

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

RQ-TEC-002 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, podrá ser requerida por parte de EJIE la ejecución de

las pruebas de carga y rendimiento del sistema necesarias para garantizar esta condición.

RQ-TEC-003 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.

RQ-TEC-004 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.


RQ-TEC-005 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:

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

RQ-TEC-006 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.

RQ-TEC-007 Multinavegador, usabilidad y

accesibilidad

El sistema deberá soportar la navegación a través de los distintos navegadores.

Todo el diseño del sistema se realizará teniendo en cuenta criterios de usabilidad.

Así mismo, con especial relevancia en la parte expuesta en Internet, tendrá que cumplir los niveles de Accesibilidad (W3C), con nivel triple A.

RQ-TEC-008 Entorno tecnológico base El entorno tecnológico para la construcción será el determinado en los estándares tecnológicos referidos en el presente Pliego de Condiciones Técnicas.


5.1.3.15. Otros requerimientos

Otros

Descripción: 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 Condiciones Técnicas.

ID

Requerimiento


RQ-OTR-001 Despliegue. Plan de despliegue El despliegue de la nueva plataforma de Gestión de Laboratorios deberá realizarse teniendo en

consideración a diferentes actores 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.

RQ-OTR-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 Condiciones Técnicas.

RQ-OTR-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.

RQ-OTR-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 Condiciones Técnicas.

RQ-OTR-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 tanto a nivel funcional como técnico. Deberá establecerse, por tanto, un plan de formación e impartirse los cursos o charlas que se fijen dentro de este plan.

Se deberá valorar la conveniencia de contar con un módulo de eLearning. En el caso de que

fuera necesario contar con una herramienta de este tipo, el producto seleccionado deberá ser

Moodle.


RQ-OTR-006 Contingencia. Definición y acciones

necesarias

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.

RQ-OTR-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.

RQ-OTR-008 Configuración Configuración analítica integral de los tres Laboratorios, carga de datos y verificación del correcto funcionamiento.

Soporte “in situ”, en la puesta en marcha del sistema en cada Laboratorio (mínimo dos jornadas).

RQ-OTR-009 Soporte, garantía y licencias Soporte técnico, contra defectos de programación, nuevas versiones del producto. Soporte técnico, licencias (si aplicaran) y de mantenimiento durante 1 año.

Deberá concretarse el modo de prestación de dicho servicio en la oferta técnica a presentar.


5.1.4. Requisitos de soporte, licencias y mantenimiento estándar del producto

Dentro de los servicios a prestar en virtud del presente Pliego de Condiciones Técnicas está el de los servicios de soporte, licencias y mantenimiento estándar del producto. Éste deberá contener los siguientes servicios mínimos:

5.1.4.1. Duración del servicio

El período de validez del contrato será de un año prorrogable hasta un máximo de dos años adicionales. La prestación efectiva de los servicios se hará con arreglo al siguiente calendario:

Contratación inicial: un año natural de prestación del servicio según se detalla posteriormente en el presente Pliego de Condiciones Técnicas. El servicio deberá encontrarse activado, una vez hayan finalizado los servicios correspondientes a la implantación inicial del nuevo producto incluyendo el primer año de soporte y licenciamiento contemplado anteriormente en dicho apartado.

Contratación adicional: Un máximo de dos años adicionales de prestación del servicio una vez finalizado el periodo inicial de contratación.

La prórroga del contrato se producirá de manera expresa por EJIE. Como se ha señalado anteriormente, la prórroga es por un periodo máximo, siendo facultad de EJIE, S.A. ejecutar la misma por un periodo inferior que quedará formalizado en la contratación adicional contemplada si ésta finalmente se formalizara.

5.1.4.2. Características del servicio

Licencias (si aplicaran) para los usuarios correspondientes a:

o Usuarios de soporte y administradores de sistema que se estimen necesarios.

o Usuarios correspondientes a la administración central de Salud Pública en el Gobierno Vasco

o Usuarios correspondientes a los laboratorios de Salud Pública del Gobierno Vasco

y/o a aquellas que se determinen en la fase de análisis como necesarias para el correcto funcionamiento del sistema de laboratorios por parte del Departamento de Salud del Gobierno Vasco y EJIE.

De modo adicional, para el servicio de soporte, deberán contemplarse los siguientes:

Soporte telefónico en horario de oficina, tanto a nivel funcional como técnico

Respuesta a incidencias técnicas y corrección si procede en un plazo no superior a 24 horas.

Implantación y soporte de las correcciones en los distintos entornos.

Implantación en los distintos entornos de actualizaciones de producto estándar. Mínimo una versión

anual

Los servicios anteriormente mencionados podrán ser mejorados por los ofertantes y serán valorados en consecuencia.

Los procesos y herramientas a seguir para cada uno de los servicios de soporte deberán ser detallados en las ofertas presentadas, valorándose positivamente su integración con las herramientas de soporte estándar existente en EJIE.


5.1.5. Requisitos de mantenimiento a medida

Se requiere disponer de un servicio de mantenimiento a medida del producto más allá de las posibles actualizaciones que pudieran derivarse de la evolución estándar del producto contempladas anteriormente en el Pliego de Condiciones Técnicas. Dicho servicio de mantenimiento vendrá caracterizado por los siguientes elementos principales:

5.1.5.1. Duración del servicio

El período de validez del contrato será de dos años prorrogables hasta un máximo de dos años adicionales. La prestación efectiva de los servicios se hará con arreglo al siguiente calendario:

Contratación inicial: dos años naturales de prestación del servicio según se detalla posteriormente en el presente Pliego de Condiciones Técnicas. El servicio deberá encontrarse activado, una vez hayan finalizado los servicios correspondientes a la implantación inicial del nuevo producto sin incluir el primer año de soporte y licenciamiento contemplado anteriormente en dicho apartado.

Contratación adicional: Un máximo de dos años adicionales de prestación del servicio una vez finalizado el periodo inicial de contratación.

La prórroga del contrato se producirá de manera expresa por EJIE. Como se ha señalado anteriormente, la prórroga es por un periodo máximo, siendo facultad de EJIE, S.A. ejecutar la misma por un periodo inferior que quedará formalizado en la contratación adicional contemplada si ésta finalmente se formalizara.

5.1.5.2. Características del servicio

El servicio se prestará en formato de “bolsa de horas” según los siguientes criterios:

El número máximo de horas facturables será de 400 anuales.

Toda solicitud de actividad vendrá precedida de una valoración y planificación previa a realizar por

parte del adjudicatario previa solicitud de EJIE.

En términos económicos y de esfuerzo asociado, únicamente se considerará una tarifa media que se

corresponderá con la ofertada en respuesta al siguiente Pliego de Condiciones Técnicas.

En caso de EJIE considere apropiada dicha valoración y planificación asociada, el trabajo deberá

cumplir con lo especificado en la valoración.

En el caso de que se haya producido cualquier desviación conforme a lo valorado en un inicio, deberá

presentarse a EJIE por escrito la justificación del mismo y el posible impacto en el servicio, quedando

posteriormente en manos de EJIE la potestad de aceptar o no la misma y las consecuentes medidas

que pudieran derivarse de esta aceptación o rechazo.

Los servicios anteriormente mencionados podrán ser mejorados por los ofertantes y serán valorados en consecuencia.

Los procesos y herramientas a seguir para cada uno de los servicios de soporte deberán ser detallados en las ofertas presentadas, valorándose positivamente su integración con las herramientas de soporte estándar existente en EJIE.


6 Metodología Aplicable y Entorno Tecnológico.

La organización del trabajo y la prestación del servicio estará basada en ARINbide, PROBAMET y el modelo SQA de EJIE. No obstante, tal y como se ha mencionado con anterioridad, el nivel de cumplimiento de los mismos dentro de los servicios a prestar deberá concretarse en las fases iniciales del proyecto. Aun así, las ofertas presentadas deberán tomar como referencia dichos modelos y metodologías, que se explican brevemente a continuación.

Al tratarse de la implantación de una solución existente, y de ciertos servicios derivados como el del soporte telefónico, el ofertante deberá proponer una adaptación de dichas metodologías para poder realizar los diferentes servicios a prestar. Dicha adaptación será convenientemente valorada en el criterio correspondiente del presente Pliego de Condiciones Técnicas.

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

ARINbide-Predictivo 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 EJIE 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 EJIE.

Para todo el ciclo de vida del proyecto, ARINbide-Predictivo 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-Predictivo 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-Predictivo 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-Predictivo y las fases de ejecución de PROBAMET.

En la sección “Perfil del contratante>Información técnica>Metodología de desarrollo” de la página web de EJIE se puede obtener información detallada sobre ARINbide-Predictivo, PROBAMET y el modelo SQA de EJIE.

En las distintas fases del proyecto y, teniendo en cuenta las mencionadas metodologías la empresa adjudicataria deberá basarse, entre otros, en los siguientes elementos:

Catálogo de Requisitos de Usuario detallado en el documento CRU. Lo realizará en su totalidad el

adjudicatario y en sus dependencias, que incluye:

http://www.ejie.eus/y79-04/es/contenidos/informacion/metodologia_desarrollo_ejie/es_0212/metodologia_desarrollo.html

http://www.ejie.eus/y79-04/es/contenidos/informacion/aseguramiento_calidad_ejie/es_0215/aseguramiento_calidad.html






La descripción del sistema

Los requisitos de usuario

Los casos de uso

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

Análisis del Sistema de Información, ASI, recogido en documento ERS. Lo realizará en su totalidad el

adjudicatario y en sus dependencias, que incluye :

La especificación de requisitos del sistema

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

Las clases del sistema

El prototipo de interfaz

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

Diseño del sistema. Lo realizará en su totalidad el adjudicatario 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 en sus dependencias, teniendo en cuenta las directrices

de EJIE 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 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 Salud.

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 realizará los siguientes puntos

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

Llevará a cabo la instalación de la aplicación en el entorno de desarrollo de EJIE, 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 efectuará los siguientes

puntos

Preparará los paquetes y dará soporte a la realización por EJIE de la correspondiente implantación

en el entorno de test o preexplotación


Ejecución de las Pruebas del sistema, y en el caso de que se requiera, estas pruebas se realizarán

en las dependencias de E.J.I.E 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 EJIE

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

Manuales requeridos para la prestación del servicio en producción y definidos por los procesos ITIL

de EJIE.

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.

Sistema implantado en entorno de producción.

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 EJIE 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

6.2 Metodología de pruebas

De forma alineada y paralela a ARINbide-Predictivo, 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-Predictivo.

En la sección “Perfil del contratante>Información técnica>Aseguramiento de la calidad” de la página web de EJIE se puede obtener información detallada sobre PROBAMET y el modelo SQA de EJIE.

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:

http://www.ejie.eus/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/adjuntos/Estandares%20de%20desarrollo%20software.v2.0.pdf

http://www.ejie.eus/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/adjuntos/Estandares%20de%20desarrollo%20software.v2.0.pdf

http://www.euskadi.net/informatika





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

6.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-Predictivo.

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 EJIE, 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-Predictivo 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

En la sección “Perfil del contratante>Información técnica>Aseguramiento de la calidad” de la página web de EJIE se puede obtener información detallada sobre los roles contemplados, las actividades y entregables del Modelo SQA, así como de las herramientas y tecnologías a utilizar.

http://www.ejie.eus/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/adjuntos/Estandares%20de%20calidad%20de%20producto%20software%20v1.4.pdf

http://www.ejie.eus/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/adjuntos/Estandares%20de%20calidad%20de%20producto%20software%20v1.4.pdf

http://www.ejie.eus/y79-04/es/contenidos/informacion/aseguramiento_calidad_ejie/es_0215/adjuntos/Indicadores.zip





6.3.1. Nivel de Aseguramiento de la Calidad

El NAC asignado para este proyecto es: MEDIO

6.3.2. Plan SQA y actividades de aseguramiento de la calidad

Al inicio del proyecto se elaborará el Plan de Aseguramiento de la Calidad (PSQA), 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-Predictivo 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-Predictivo 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-Predictivo

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-Predictivo, 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.

6.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 EJIE, 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 EJIE, 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 PCT-Anexo Herramientas se detallan las herramientas homologadas.

6.5 Entorno Tecnológico.

El entorno tecnológico de referencia será el establecido en los estándares del Gobierno Vasco junto con los específicos del Departamento de Salud. Se deberán aplicar por tanto aquellos que se consideren necesarios para la ejecución del servicio, conforme a las características específicas de cada una de las aplicaciones incluidas en el alcance del presente pliego de condiciones técnicas.

El adjudicatario se compromete a adoptar y soportar en todo momento cualquier modificación o adaptación del entorno tecnológico establecido por el Gobierno Vasco e incluido dentro de sus estándares, así como todas aquellas otras actualizaciones específicas impuestas por el Departamento.

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:

http://www.ejie.eus/y79-04/es/contenidos/informacion/herramientas_ejie/es_0213/herramientas.html

hhttp://www.ejie.eus/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/adjuntos/PBT-Anexo%20Herramientas%20v1.1.pdf


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.

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.

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 PCT-Anexo Pasarela de Pagos se detalla información de referencia

acerca del sistema.

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

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.

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 PCT-Anexo NORA 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 su despliegue en el servidor de aplicaciones 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 PCT-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 y soluciones corporativas existentes son los siguientes:

http://www.ejie.eus/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/adjuntos/PBT-Anexo%20Pasarela%20de%20Pagos%20v1.0.pdf

http://www.ejie.eus/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/adjuntos/PBT-PLATEA-Anexos%20v2.3.pdf

http://www.ejie.eus/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/adjuntos/PBT-Anexo%20NORA%20v2.0.pdf

http://www.ejie.eus/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/adjuntos/PBT-Anexo%20UDA%20v1.0.pdf

http://code.google.com/p/uda/


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:

FOP, iText o JasperReports para tecnología JEE.

Business Intelligence:

Oracle Business Intelligence

Sistemas de Información Geográfica:

GIS Corporativo, basado en productos ESRI (ArcGIS 10.2, Oracle Spatial)

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 que tienen especial relevancia dentro del objeto del presente Pliego de Condiciones serán, entre otros:

Servidor

- Sistema Operativo

Para servidores Linux: RedHat Enterprise Linux 7

Para servidores Windows: Windows Server 2012 R2

- Infraestructura de Virtualización

Plataforma de Virtualización VMWare

- BBDD. Las alternativas son las siguientes:

Oracle. Versión 12c

SQL Server 2012

- Servidor web

Apache v2

- Servidor de aplicaciones

Para tecnología J2EE

Producto Comercial: Oracle WebLogic Server 11 o 12

Producto Open Source

o WildFly 9 o superior

o Tomcat 8 o superior

Para tecnología .NET

IIS v8

- Business Intelligence (si procede)

Oracle Business Intelligence 11.1.1

Cliente

- Sistema Operativo: Windows 7 32 y 64 bits

- Versión de Motor de ejecución. Si fuera necesario:

Java 7 y Java 8


Framework .NET v4

- Versión de Navegador. Si fuera necesario, deberían soportarse las siguientes versiones:

Internet Explorer 9-11

Mozilla Firefox a sus últimas versiones

Google Chrome a sus últimas versiones

Otros estándares tecnológicos horizontales en el Gobierno Vasco /EJIE

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

Basado en Documentum

Gestión de versionado de aplicaciones:

Subversion

Documentación y trabajo en grupo:

SharePoint Portal Server

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 PCT-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, …)

El nuevo sistema, y según sus necesidades, podrá utilizar otros módulos y servicios específicos para el Departamento de Salud, tales como:

SIABP-Sistema de Aseguramiento con Base Poblacional

Registro Vasco de Profesionales Sanitarios

Las integraciones con los sistemas se concretarán en las fases de análisis y diseño del proyecto.

http://www.ejie.euskadi.net/y79-04/es/contenidos/informacion/anexos_pbt_ejie/es_0214/adjuntos/PBT-Anexo%20Herramientas%20v1.1.pdf


7 Descripción de entregables.

Los productos a entregar, tanto productos software como la documentación, serán aquellos que define la adaptación de la metodología de desarrollo ARINbide-Predictivo en referencia a las fases definidas dentro del alcance del proyecto. Dicha adaptación metodológica será propuesta por el adjudicatario y aceptada, si procede, por el responsable del proyecto de EJIE.

No obstante, dado que para este caso particular se trata de la implantación y posterior parametrización de un producto existente, se definen los siguientes entregables mínimos:

Producto instalado en los diferentes entornos

Elementos asociados con el ciclo de gestión y pruebas de sistemas

Documentación de análisis

Documentación de diseño

Documentación de gestión del proyecto y servicio

Manuales mínimos

o Usuario

o Administración

Modelo de gestión y servicio de soporte y mantenimiento.

Acciones y elementos de formación

Otros documentos que pudieran ser requeridos a propósito de los productos a entregar y tareas a

realizar.

Igualmente, dentro del alcance definido del proyecto, la Metodología de Pruebas PROBAMET, así como el modelo de Aseguramiento de la Calidad de Sistemas Software, detallan los entregables a proporcionar en el ámbito de la calidad. Deberá proponerse una adaptación a los mismos dada la naturaleza de los servicios a prestar,

Con independencia de lo descrito y requerido a nivel metodológico (metodología de desarrollo ARINbide-Predictivo, y Metodología de Pruebas PROBAMET), a continuación se detallan las 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 artefactos necesarios para el correcto funcionamiento del sistema en los distintos entornos tales como: ejecutables, 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 y/o electrónico. Se valorará positivamente la entrega de los fuentes del producto a implantar.

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.

7.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 tales como:

Ficha de proyecto y Plan de Implantación: primera aproximación a Gestión de Cambios donde se informa qué se va a hacer y calendario aproximado.

Documento de albergue: recoge el diseño lógico e información de cualquier elemento no estándar o que pueda impactar tanto en necesidades de infraestructura como de usuario final.

Manual de implantación: recoge 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 producción: contiene toda información que necesita tanto operación como los procesos para poder dar correctamente el servicio de explotación a partir del día de Puesta en Producción del proyecto.

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.


8 Planificación y Organización

8.1 Plan de Proyecto

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

Así mismo, 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.

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

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

8.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 actividades del proyecto, siguiendo el siguiente modelo:


Descripción Perfil Gest. Proyecto

Análisis Diseño Construcción Implantación Soporte y licencias (1año)

Total Horas

Horas % Horas % Horas % Horas % Horas % Horas %

Jefe Proyecto

Analista Funcional

Analista Técnico

Analista-Programador

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.

(**) No es obligatoria la presentación de personal en la totalidad de los perfiles definidos en la tabla anterior. La composición del equipo de trabajo es variable en cada una de las ofertas presentadas pero la totalidad de los miembros del equipo presentado deberá tener asociado al menos un perfil que se corresponda con dicha tabla.

8.2.2. Asignación de recursos a los servicios de soporte y mantenimiento estándar del producto

El licitador deberá incluir en su Documento de Propuesta Técnica un desglose de horas y % de dedicación total por perfil y actividades correspondientes a este servicio, siguiendo el siguiente modelo:

Descripción Perfil Gest. Servicio

Prestación del servicio de Soporte

Total Horas

Horas % Horas %

Jefe Proyecto

Analista Funcional

Analista Técnico


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.


8.2.3. Asignación de recursos a los servicios de mantenimiento a medida

El licitador deberá incluir en su Documento de Propuesta Técnica un desglose de horas y % de dedicación total por perfil y actividades correspondientes a este servicio, siguiendo el siguiente modelo:

Descripción Perfil Gest. Servicio

Prestación del servicio de Mantenimiento (máx.)

Total Horas

Horas % Horas %

Jefe Proyecto

Analista Funcional

Analista Técnico


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.


8.2.4. 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 se compromete, en caso de ser adjudicatario, a mantener el equipo, según lo establecido en la oferta, y durante el periodo fijado en cada actividad específica. Los recursos asignados a la ejecución del contrato deberán estar asignados desde el inicio del mismo. En el caso de modificación o sustitución de recursos, deberá comunicarlo previamente a EJIE, con la antelación mínima necesaria en función de la criticidad del servicio, y en cualquier caso no mayor 15 días naturales, y EJIE aprobará o rechazará dicha


modificación o sustitución. En todo caso el sustituto o sustitutos tendrán un perfil igual o superior al ofertado, o recurso a sustituir.

EJIE podrá solicitar el cambio de los recursos asignado a los servicios, por inadecuación de los recursos o por incumplir los requisitos tanto de solvencia como técnicos exigidos, o haber declarado el contratista unas circunstancias que no son veraces, en cuyo caso podrá conllevar la rescisión del contrato y adjudicación al licitador siguiente en las calificaciones.

8.2.4.1. Constitución inicial del equipo de trabajo

El equipo técnico a incorporar tras la formalización del contrato para la ejecución de los trabajos deberá estar formado por componentes y perfiles 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 establecido en la oferta 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 sustituto/s con un perfil de cualificación técnica igual o

superior al de la persona que se pretende sustituir.

Aceptación del sustituto/s por parte de la Dirección del Proyecto de EJIE

Caso de que se demostrase que el cambio no se corresponde con causa justificada, EJIE se reserva el

derecho no solo a la aprobación del sustituto/s 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.

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

La valoración de la calidad de los servicios objeto del presente pliego corresponde a la Dirección del Proyecto de EJIE, 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 o superior, si existen razones justificadas que lo aconsejen.

Si el adjudicatario propusiera el cambio de alguna de las personas del equipo de trabajo, se deberá solicitar por escrito con quince días naturales 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 sustituto/s con un perfil de cualificación técnica igual o superior al de la persona que se

pretende sustituir.

Aceptación del sustituto/s por parte de la Dirección del Proyecto de EJIE

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 EJIE, esto no fuera posible, las dos primeras semanas de trabajo del sustituto/s no serán facturables corriendo a cargo del adjudicatario.

8.2.4.3. Horario 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. Se deberá garantizar una presencia rápida en EJIE,

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 EJIE

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

La jornada de trabajo estará de acuerdo a la establecida por EJIE,

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 EJIE

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 EJIE), 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

8.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 EJIE, y a tales efectos, la información y documentación que ésta solicite para disponer de un pleno conocimiento de los trabajos desarrollados, así como de los eventuales problemas que puedan plantearse y de las tecnologías, métodos, y herramientas utilizados para resolverlos.


9 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 EJIE y del Gobierno Vasco.

El control y seguimiento de la calidad de servicio, será realizado por la Dirección del Proyecto de EJIE

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

9.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 EJIE

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 EJIE, 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 EJIE, 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.

9.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 EJIE, 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 el presente pliego (si existieran).


10 Plazo de entrega y Plan de Facturación

El plazo de ejecución máximo previsto es desde la formalización del contrato hasta la finalización del primer año de soporte post-producción es de 24 meses con la posibilidad de prórroga de has un máximo de 2 años adicionales de los servicios contemplados anteriormente como prorrogables en el presente documento. Las condiciones de prórroga vendrán determinadas por la aceptación de los servicios de EJIE anteriormente mencionados y realizados en los periodos anteriores así como por la disponibilidad presupuestaria suficiente. La prórroga de los servicios se realizará y comunicará de manera expresa por parte de EJIE siguiendo sus procesos de contratación definidos a tal efecto.

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 EJIE

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:

Servicio 1 - Implantación inicial del nuevo sistema y soporte de un año adicional

La aprobación implica:

La implantación en el entorno correspondiente, y la aprobación por la Dirección del Proyecto de

EJIE 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 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

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

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

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

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

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

A la Aceptación Definitiva de la Dirección del Proyecto de EJIE de los trabajos realizados. 20%


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.

Servicio 2 - Soporte, licencias y mantenimiento estándar

Se realizarán pagos semestrales, a periodo vencido, con la parte proporcional de los servicios

prestados durante el semestre.

Servicio 3 - Mantenimiento a medida

Facturación mensual correspondiente a las horas aprobadas por la Dirección de Proyecto de EJIE

durante dicho periodo correspondientes al servicio de mantenimiento a medida.

Conceptos comunes a la totalidad de los servicios

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 EJIE


11 Criterios de Adjudicació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:

Descripción de los criterios de valoración

Apartado/Aspecto evaluado Peso

Valoración Económica 55

Proposición económica implantación inicial y primer año de soporte 35

Proposición económica soporte estándar del producto y licencias 12

Proposición económica mantenimiento a medida 8

Entendimiento del proyecto y calidad de la solución 30

Resumen ejecutivo y estructura general de la oferta 4

Implantación del nuevo sistema LIMS 18

Soporte, licencias y mantenimiento estándar 5

Servicio de mantenimiento a medida 3

Planificación, metodología y gestión del servicio 15

Planificación y equipo de trabajo 8

Metodología y calidad 4

Gestión del servicio 3

TOTAL 100

11.1 Criterios valorables mediante fórmula

Proposición económica implantación inicial y primer año de soporte:

Se valorará bajo la siguiente fórmula:

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

Precio de la oferta evaluada


La oferta que presente un importe superior al máximo establecido en el presente documento, recibirá cero puntos en el presente apartado y quedará automáticamente excluida del resto del proceso de valoración.

Como se ha comentado con anterioridad, dentro del precio ofertado se entenderán ya incluidos: las dietas, gastos de desplazamiento y/o cualquier otro gasto necesario para la realización del servicio.

Proposición económica soporte estándar del producto y licencias:

Se valorará bajo la siguiente fórmula, tomando como el precio de la oferta el correspondiente al importe anual asociado a dicho concepto:

Total puntos apartado x Precio anual oferta más ventajosa (la de menor precio)

Precio anual de la oferta evaluada



Proposición económica mantenimiento a medida:

Se valorará bajo la siguiente fórmula:

Total puntos apartado x Precio tarifa media oferta más ventajosa (la de menor precio)

Precio tarifa media de la oferta evaluada



Valoración final

Será la resultante de la suma de los puntos obtenidos en los apartados mencionados con anterioridad.

11.2 Criterios no evaluables mediante fórmula

Dentro del este grupo se incluirán los apartados de:

- Entendimiento del proyecto y calidad de la solución

- Planificación, metodología y gestión del servicio


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 condiciones técnicas, así como la calidad del contenido, grado de detalle y concreción del análisis propuesto.

Dentro de este criterio se realizará la valoración en los siguientes apartados:

Resumen ejecutivo y estructura general de la oferta__________________4 puntos

Análisis de los requerimientos y propuesta de solución________ 18 puntos

Soporte y mantenimiento estándar _______ _ 5 puntos

Servicio de mantenimiento a medida_______ _ 3 puntos

La valoración de los puntos anteriores se realizará en correspondencia a los siguientes criterios y rangos de porcentajes con respecto a los valores máximos anteriores:

Puntuaciones Mínimo Máximo

Básico (ver Nota 1) 0% 35%

Medio 36% 60%

Bueno 61% 80%

Excelente 81% 100%

Nota 1: En caso de que la oferta no se ajuste a las necesidades planteadas en el pliego de condiciones técnicas en lo relativo a cualquiera de los apartados de valoración anteriores, la puntuación será de cero, excluyéndose automáticamente esta oferta del resto del proceso selectivo.

Planificación, metodología y gestión del servicio

Se valorará la planificación y equipo de trabajo para el cumplimiento de la misma, metodología a seguir para la prestación del servicio y el procedimiento para la gestión del mismo.

Dentro de este criterio se realizará la valoración en los siguientes apartados:

Planificación y equipo de trabajo________________________________ 8 puntos

Metodología y calidad________________________________________ 4 puntos

Gestión del servicio__________________________________________ 3 puntos

La valoración de los puntos anteriores se realizará en correspondencia a los siguientes criterios y rangos de porcentajes con respecto a los valores máximos anteriores:

Puntuaciones Mínimo Máximo

Básico (ver Nota 2) 0% 35%

Medio 36% 60%

Bueno 61% 80%

Excelente 81% 100%

Nota 2: En caso de que la oferta no se ajuste a las necesidades planteadas en el pliego de condiciones técnicas en lo relativo a cualquiera de los apartados de valoración anteriores, la puntuación será de cero, excluyéndose automáticamente esta oferta del resto del proceso selectivo.


Umbral mínimo puntuación que debe obtenerse en los criterios no evaluables mediante fórmulas:

Conforme al artículo 150.4 del TRLCSP, para ser admitidos a la valoración global, se exigirá que en los criterios no cuantificables por fórmulas (Plan y equipo de trabajo y Calidad técnica de la Solución) los licitadores alcancen un umbral mínimo de puntuación, de forma que no serán tenidas en cuenta las ofertas cuya puntuación no supere los 25 puntos sumando las puntuaciones de los aspectos anteriores:

- Entendimiento del proyecto y calidad de la solución

- Planificación, metodología y gestión del servicio

Estas ofertas quedarán automáticamente excluidas del resto del proceso selectivo.


12 Estructura y Formato de la Propuesta

El licitador sólo podrá presentar su propuesta contemplando una única alternativa.

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

Las ofertas deberán obligatoriamente seguir el siguiente esquema, teniendo en cuenta las limitaciones y apartados siguientes.

Documentos de Propuesta Técnica, incluyendo:

1. Documento de resumen ejecutivo de la oferta (máximo 25 páginas)

1.1. Documento de resumen ejecutivo de la oferta

2. Documento de propuesta técnica (máximo de 150 páginas)

2.1. Índice.

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

2.3. Solución técnica

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.

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

“Requisitos” 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

2.3.2. Implantación del nuevo sistema LIMS

2.3.2.1. Descripción del alcance global de la solución

2.3.2.2. Entregables y productos intermedios y finales

2.3.2.3. Enfoque técnico y condicionantes tecnológicos


2.3.2.4. Riesgos y factores críticos de éxito

2.3.3. Soporte, licencias y mantenimiento estándar

2.3.4. Servicio de mantenimiento a medida

2.4. Planificación, metodología y gestión del servicio

2.4.1. Equipo de trabajo

2.4.2. Organización del equipo de trabajo.

Composición del equipo de trabajo propuesto, ordenado por perfiles

profesionales.

Por cada uno de los miembros del equipo, se deberán detallar sus

principales funciones y responsabilidades, así como su tiempo total

de dedicación en el proyecto.

2.4.3. Plan de trabajo

2.4.3.1. Fases, actividades y tareas

A alto nivel se describirán las principales fases, actividades y tareas

del proyecto, incluyendo también el cronograma previsto, junto con la

asignación de recursos a cada una de ellas y su tiempo previsto de

dedicación.

2.4.4. Aplicación de metodologías (ARINBide y Probamet).

Podrán incorporarse metodologías complementarias a éstas siempre y

cuando aporten valor a la solución ofertada.

2.4.5. Procedimientos de gestión, control y seguimiento, y aseguramiento de la

calidad

Se incluirá en este apartado: la descripción de las medidas dispuestas por el

licitador para asegurar la correcta gestión del proyecto, los mecanismo de control y

seguimiento a aplicar, los procesos de aseguramiento de calidad, así como

aquellas otras medidas que se prevé emplear para vigilar y garantizar el adecuado

cumplimiento del contrato. Podrán concretarse:

Modelo de gestión

Seguimiento y control

Procesos de seguimiento y control

Informes

Indicadores

Aseguramiento de la calidad (Modelo SQA)

3. Anexos (opcionales)

3.1. Podrá incorporarse información anexa que podrá servir como aclaración a algún

aspecto del Documento de Propuesta Técnica

3.2. Dicha información no será valorable más allá de dicho carácter aclaratorio.

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

Pliego de Condiciones Técnicas · 2016-12-07 · Pliego de Condiciones Técnicas. Implantación y...

Documents

Transcript of Pliego de Condiciones Técnicas · 2016-12-07 · Pliego de Condiciones Técnicas. Implantación y...