SCR6150c - Osakidetza

SCR6150c
Versión 2.0(12/01/05)
Pliego de acuerdo de nivel de servicio:
Especificaciones Técnicas para el mantenimiento y evolución
de las aplicaciones del Departamento de Sanidad y Consumo.
Fecha: Enero del 2011
Referencia:
005/2011
EJIE S.A.
Mediterráneo, 14
Tel. 945 01 73 00*
Fax. 945 01 73 01
01010 Vitoria-Gasteiz
Posta-kutxatila / Apartado: 809
01080 Vitoria-Gasteiz
www.ejie.es
Este documento es propiedad de EJIE, S.A. y su contenido es confidencial. Este documento no puede ser reproducido, en su totalidad o parcialmente, ni
mostrado a otros, ni utilizado para otros propósitos que los que han originado su entrega, sin el previo permiso escrito de EJIE, S.A.. En el caso de ser
entregado en virtud de un contrato, su utilización estará limitada a lo expresamente autorizado en dicho contrato. EJIE, S.A. no podrá ser considerada
responsable de eventuales errores u omisiones en la edición del documento.
Contenido
Capítulo/sección
1
Introducción
5
1.1 Características generales
5
2
6
Objeto del contrato
2.1 Objeto
6
2.2 Áreas Funcionales
6
2.3
Líneas de trabajo
13
2.4 Presupuesto
18
3
19
Definición del Servicio
3.1
Fases del Servicio
19
3.2 Flujos de trabajo
22
3.2.1.
Peticiones de servicio
22
3.2.2.
Entrega
23
4
Pliego de Bases Técnicas
Página
Configuración del Servicio
25
4.1 Organización del Equipo de Trabajo
25
4.2
28
Asignación de recursos a fases del proyecto
4.3 Equipo de Trabajo
28
4.3.1.
Certificaciones en PLATEA y Geremua
28
4.3.2.
Veracidad de los datos
29
4.3.3.
Condicionante del equipo de trabajo ofertado
29
4.3.4.
Constitución inicial del equipo de trabajo
29
4.3.5.
Modificaciones en la composición del equipo de trabajo
30
4.3.6.
Jornada laboral y lugar de realización de los trabajos.
30
4.3.7.
Currículo de los componentes del grupo de trabajo.
31
5
33
5.1 Metodología de desarrollo, normativa y Guía de Estilo
33
5.2 Entorno Tecnológico
34
5.3
37
Modelo de aseguramiento de la calidad
5.3.1.
Controles de calidad (SQA)
38
5.3.2.
Tipologías de pruebas
38
5.3.3.
Metodología de pruebas
38
5.3.4.
Indicadores
39
5.4 Herramientas del ciclo de vida de las aplicaciones
39
6
40
Control y Seguimiento
6.1 Puntos de Control
40
6.2 Indicadores de Nivel de Servicio
43
6.2.1.
Indicadores de Servicio
43
6.2.2.
Indicadores de Calidad
45
7
7.1
Condiciones particulares
47
Modelo de facturación
47
7.2 Penalizaciones
47
7.3 Criterios de valoración
48
7.4
49
8
Pliego de Bases Técnicas
Especificaciones Técnicas
Finalización del servicio
Garantía y Confidencialidad
50
8.1 Garantía
50
8.2
50
Confidencialidad
Pliego de Bases Técnicas
8.3 Derechos y propiedad de los desarrollos y datos
50
8.4 Protección de los datos
51
9
52
Estructura y Formato de la Propuesta
9.1 Estructura normalizada y contenido de las propuestas.
52
9.2 Formato de la Propuesta.
53
9.3
Sobres y Elementos.
53
Anexo I. Relación de aplicaciones
54
1
Introducción
EJIE, empresa pública del Gobierno Vasco contribuye, mediante la prestación de servicios informáticos, a
conseguir una Administración Pública Vasca, moderna y eficiente. Así, construye y mantiene la infraestructura
de los Sistemas de Información y Telecomunicaciones, posibilitando su continuidad y seguridad en base a un
personal cualificado y a unos recursos y costes adecuados a la demanda.
EJIE, tiene como meta final la consecución de la satisfacción de sus clientes. Para ello se ha impuesto como
objetivos permanentes los siguientes:
•
•
•
•
Prestar servicios de manera eficiente y con calidad, asegurando el cumplimiento de los plazos de
respuesta y un nivel "cero" de reclamaciones e incidencias.
Prestar servicios competitivos en relación al sector, en base a la permanente adecuación de los
servicios internos al ámbito de actuación y asignando los recursos óptimos mediante la aplicación de
los principios de racionalidad, especialidad y eficiencia.
Integrarse activamente con sus clientes en un entorno de transparencia, comunicación y con objetivos
comunes: comprensión del problema, enfoque adecuado y resolución satisfactoria.
Obtener una imagen corporativa de servicio eficiente, de calidad y de empresa en punta tecnológica en
el sector.
Podemos desglosar la actividad informática requerida por el Gobierno Vasco en tres ámbitos:
• Infraestructura Operativa. Sistemas informáticos y de Telecomunicaciones.
• Conocimiento funcional de la Administración Pública, y recursos técnicos para desarrollar el negocio.
• Conocimiento tecnológico (TIC) que garantice la viabilidad de los proyectos abordados.
EJIE se estructura en tres áreas de servicio, alineadas con las demandas del Gobierno Vasco:
• Producción: Mantiene operativos los equipos informáticos, el software, las telecomunicaciones, los
aplicativos, y los datos, con los niveles de seguridad requeridos.
• Proyectos y Asistencia Técnica: Asesora y colabora con los departamentos en la definición,
desarrollo, mantenimiento e implantación de sus sistemas de información, garantizando el
cumplimiento de los estándares tecnológicos y la calidad del software. Asimismo se responsabiliza de
la gestión integral de los proyectos comunes (proyectos de infraestructura y proyectos
multidisciplinares). El área se compone de varios grupos asignados a los distintos departamentos del
Gobierno Vasco, y compuestos por un responsable, técnicos de análisis y técnicos de desarrollo.
• Sistemas y Telecomunicaciones: Estudia, desarrolla, mantiene, y soporta las infraestructuras
tecnológicas existentes, y las de nueva implantación.
NOTA: Se puede obtener información más detallada y extensa en la dirección de Internet http://www.ejie.es/
1.1
Características generales
Se pretende establecer un modelo operativo de mantenimiento de aplicaciones que permita además mejorar el
nivel de calidad y documentación de las mismas base a objetivos cuantitativos. Con ello se aspira aumentar el
nivel de flexibilidad, predictibilidad y de respuesta al negocio, proporcionando un seguimiento y medición del
servicio, y consiguiendo una reducción de los riesgos.
EJIE mantendrá las funciones de control, dirección y de relación con el negocio, garantizando el compromiso
de los niveles de servicio, con un único grupo de interlocución para toda la operativa, que en este caso, será el
Grupo de Gestores ANS, en adelante, GGANS.
Un proyecto de estas características supone un proceso de cambio, que necesita de una metodología que
garantice la continuidad del servicio y la adecuada transición del conocimiento y de responsabilidades.
Pliego de Bases Técnicas
5/55
2
Objeto del contrato
2.1
Objeto
Es objeto del presente pliego de bases técnicas la contratación del servicio de mantenimiento y evolución del
conjunto de aplicaciones informáticas enumeradas en el Anexo I. Estos sistemas dan cobertura a las
necesidades de automatización demandadas por el departamento de Sanidad y Consumo del Gobierno Vasco.
El período de validez del contrato será un año y medio prorrogable hasta un máximo de otro año adicionalen
base a los criterios de continuidad definidos en el presente pliego de bases técnicas. La prestación efectiva de
los servicios (obviando el periodo de adquisición del conocimiento) se hará con arreglo al siguiente calendario:
2.2
•
Contratación inicial: 01/07/2011 – 31/12/2012 (18 meses)
•
Contratación adicional con una fecha máxima de prestación del servicio hasta el 31/12/2013
Áreas Funcionales
Las aplicaciones objeto del contrato, dan cobertura a las necesidades demandadas por las siguientes áreas
funcionales del Departamento de Sanidad y Consumo del Gobierno Vasco:
D08-RECIEN NACIDOS
Es el registro de recién nacidos en la C.A.P.V. Se trata de una aplicación cuya gestión está distribuida
entre Lakua, Hospitales de Osakidetza y laboratorios de Salud Publica. Iniciando explotación GIS.
Desarrollando la integración con hospitales a través de Osabide.
G83-T.I.S.
Es el registro de asegurados del Sistema Sanitario Publico Vasco. Se trata de una aplicación cuya
gestión está distribuida entre Lakua y Direcciones Territoriales del Departamento de Sanidad. Tiene,
además usuarios de consulta en farmacia en Lakua/Direcciones Territoriales y en cabeceras de comarca
de Osakidetza e inspecciones médicas. Desarrollando procesos de integración con Osakidetza, SNS,
depuración de algunos datos (DNI, fallecidos,..) además de algún otro sistema de información adicional
como el caso de la nueva plataforma de Receta Electrónica
J15-AGUAS DE CONSUMO.
Es el registro de control de calidad del agua de de la C.A.P.V. Se trata de una aplicación cuya gestión
está distribuida entre Lakua, Direcciones Territoriales, Consorcios de Aguas, Laboratorios privados y
Ayuntamientos. Hay una entrada de datos para empresas /consorcios/aytos a través de Osanet.
Desarrollando alguna pequeña mejora (cod.barras,...)
Pliego de Bases Técnicas
6/55
K43-REGISTRO DE CANCER
Es el registro de personas que padecen o han padecido algún episodio de cáncer en centros sanitarios
de Osakidetza, concertados y privados. La gestión está distribuida entre Lakua y las Direcciones
Territoriales. Iniciando explotación GIS y desarrollando algunas mejoras funcionales (incluso nuevas) y
alguna depuración (fallecidos), así como la integración con TIS y otros catálogos de maestros
corporativos.
K74-PRESTACIONES SANITARIAS
Es el registro de solicitudes, aprobación y tramitación del gasto derivado a personas que requieren algún
tipo de prestación sanitaria no cubierta por el actual sistema sanitario público vasco. La gestión está
distribuida entre Lakua y Direcciones Territoriales.
K74/R64-ORTOPROTESIS
Es el registro de solicitudes, aprobación y reintegro del gasto derivado a personas que requieren algún
tipo de prestación ortoprotésica. La gestión está distribuida entre Lakua y las Direcciones Territoriales.
L12-FARMACIA
Es el repositorio de las recetas facturadas por los COF al Departamento de Sanidad y el registro de
distribución de los talonarios, incluye el mantenimiento del Nomenclátor, maestro de dietas, farmacias y
colegiados médicos. La gestión está distribuida entre Lakua y las Direcciones Territoriales y las
cabeceras de comarca de Osakidetza. Dispone de un gran DW. Integra los subsistemas:
Gestion de Visados Registro del visado de recetas en las inspecciones medicas. Gestion en todas las
inspecciones de la CAPV. Esta adaptada (aunque no se utiliza) a Receta Electronica.
Medicamentos extranjeros. Registro de los pacientes a los que se les ha prescrito una especialidad
farmacéutica no registrada en España. El objetivo de esta aplicación es la gestión del suministro de
medicamentos extranjeros en la CAPV, la tramitación de las ordenes de suministro y el posterior análisis
de la información.
Procesos de facturación. Procesos de facturación de las diferentes recetas médicas emitidas por los las
farmacias de la CAPV en base a a los criterios establecidos por la Dirección de Farmacia.
Dicho aplicativo pasará a ser la fuente de datos y perderá importancia en el mantenimiento con la
entrada en producción de la nueva plataforma de Receta Electrónica y Vademécum Corporativo.
L31-ITEMP
Es el registro de bajas por incapacidad laboral en la CAPV. La gestión está distribuida entre Lakua,
Direcciones Territoriales e inspecciones medicas. Se integra con TIS, Tesorería y Osakidetza. Se está
desarrollando un proceso de control sobre los casos de LagunAro. Se esta migrando a la nueva
infraestructura en cluster, jaso,… Más adelante deberá adaptarse a los requerimientos del nuevo sistema
de ITEMP a realizar por parte de Osakidetza.
Pliego de Bases Técnicas
7/55
L33-EDOS
Es el registro de las personas que padecen o han padecido algún tipo de enfermedad de declaración
obligatoria. La gestión está distribuida entre Lakua y Direcciones Territoriales. Lleva un DW muy utilizado
y una explotación GIS en su 1ª fase.
L45-REINTEGRO DE GASTOS
Gestiona los pagos a las personas que habiendo recibido una prestación sanitaria que requiere pago
anticipado bien por la naturaleza de la misma o por tratarse de una prestación no cubierta por ninguno
de los sistemas sanitarios públicos ni concertados. La gestión está distribuida entre Lakua y las
Direcciones Territoriales.
M42-LABORATORIOS
Es el registro de las personas que padecen o han padecido algún tipo de análisis en sangre u orina
derivados de algún control de trafico u otros en la C.A.P.V. La gestión está distribuida entre Lakua y las
Direcciones Territoriales del Departamento de Sanidad. Se esta desarrollando una ultima fase web que
contiene la gestión de Almacenes.
N60 – SANCIONES
Aplicativo de gestión de las sanciones construido sobre ATEA (antiguo gestor de expedientes basada en
SAP). Actualmente sólo utilizado por la Delegación Territorial de Guipúzcoa y sin expectativas de un
despliegue mayor. Aplicación antigua posiblemente migrada a la infraestructura de PLATEA durante el
periodo de prestación del servicio.
O22-ESKURA-TSE
Es el conjunto de servicios on-line autenticados con TSE / ONA a través del portal de Osanet. Se
realizan adaptaciones funcionales a nuevos servicios (Tasas, Estupefacientes, Vacunas,…) y algunas
tecnológicas (infraestructura, Izenpe,…) en función de las necesidades.
A futuro deberá adaptarse a las necesidades planteadas por el proyecto de Osarean,
O38-DOCENCIA
Es el registro de las ayudas destinadas para docencia de personas físicas o jurídicas desde su solicitud,
tramitación,… formación e investigación. La gestión está distribuida entre Lakua y las Direcciones
Territoriales del Departamento de Sanidad. Se desarrollan mejoras en base a necesidades.
O39-REGISTRO DE ACTIVIDAD DE MATADEROS.
Pliego de Bases Técnicas
8/55
Es el registro de los ganaderos y propietarios de los animales sacrificados en los mataderos. Se trata de
una aplicación instalada en las tres Direcciones Territoriales y en los mataderos. La información llega vía
IKT.
O43-POLICIA SANITARIA MORTUORIA
Es el registro de defunciones en la CAPV. La gestión se lleva en las DDTT y la entrada de datos es a
través de un aplicativo expuesto en el portal de Osanet por parte de las funerarias. Se integra con TIS y
RVA y, a futuro, deberá integrarse con otros sistemas adicionales.
O45-PERMISO DE TRAFICO Y ARMAS
Es el registro de las personas que acuden a cada Dirección Territorial para solicitar un examen de
contraste para la posterior petición de un permiso de tráfico o de armas. La gestión esta distribuida en las
tres Direcciones Territoriales.
P04-CONTRATACION SANITARIA
Es el sistema de facturación de los episodios asistenciales clínicos de la CAPV por dos conceptos
(Contrato Programa con Centros de Osakidetza / Conciertos con centros asistenciales privados). La
gestión está distribuida entre Lakua y las Direcciones Territoriales. La Dirección de Aseguramiento, a lo
largo del 2011, se plantea la revisión de todo el modelo y, por tanto, del Sistema de Información que da
soporte.
P15-ATENCION AL CLIENTE
Se trata del registro de quejas y reclamaciones de los ciudadanos ante el Sistema Sanitario Publico
Vasco. La gestión está distribuida entre Lakua y Direcciones Territoriales y en fase de integración de los
centros asistenciales de Osakidetza y otros puntos. Hay una entrada de quejas a través de Osanet.
P41-INSPECCIÓN DE CENTROS ALIMENTARIOS
Se trata del registro de centros alimentarios y la gestión de inspecciones, alertas etc derivadas de su
actividad. La gestión está distribuida entre Lakua, Direcciones Territoriales y cabeceras de comarca de
Osakidetza. Desarrollando los procesos HACCP, parametrizaciones,…adaptación DW,..integración con
Laboratorios y el posible cambio de la infraestructura de movilidad (paso de “tablet” a “ultraportatil”).
P70-RECETA ELECTRONICA
Consiste en un sistema que integra las prescripciones de centros de atención primaria de Osakidetza
(3s-Osabide) con sus correspondientes dispensaciones en las oficinas de farmacia de la CAPV.
Funcionando desde 2005 esta operativa en Markina, San Miguel de Basauri, LLodio, Amurrio, Gordexola,
Getxo, Azpeitia, Legazpia, Getaria, Tolosa y Donosita y actualmente desplegando en Irun, Renteria,
Oiarzun, Hondarribia y Aia, Sopelana, S.Ignacio, Deusto, Miribilla,y parte de Vitoria, Arceniega y otros
Pliego de Bases Técnicas
9/55
municipios de Alava. La gestión se lleva desde Lakua y dispone de entradas en Osanet para medicos,
farmacéuticos, responsables de Sanidad y pacientes. Desde la Dirección de Farmacia se ha lanzado el
montaje de una nueva plataforma de Receta Electrónica que cubra la totalidad de los escenarios
relacionados con el tratamiento de Recetas Médicas. Aun así, pero se continúa dando soporte al sistema
actual así como posibles mantenimientos adicionales.
P80-LEGIONELA
Se trata del registro de posibles focos de infección (torres de refrigeración) debidos a este virus.
Iniciando explotación GIS
Q51-REGISTRO DE ACREDITACIONES DE FORMACION
Se trata del registro de Acreditaciones de cursos etc al personal del Departamento. La gestión está
distribuida entre Lakua, Direcciones Territoriales. Tiene una entrada en el potal de Osanet para
acreditadotes externos. Se esta completando el desarrollo a través de PLATEA del modulo RIS (Se
analizara el trabajo para valorar el abordar nuevas fases).
Q71-VOLUNTADES ANTICIPADAS
Se trata del registro de las voluntades anticipadas de cualquier ciudadano/a en la CAPV. La gestión está
en Lakua y vía Internet/telefono para dar servicio 24x7. Hay una entrada en Osanet para los ciudadanos
y médicos.
Q86-REGISTRO DE DIABETES
Se trata del registro de casos de diabetes en la CAPV. La gestión está distribuida entre Lakua y las
Direcciones Territoriales.
Q95- I-SARE
Se trata de la funcionalidades de colaboración asociadas a la “comunidad virtual de inspectores médicos”
Q97-SISTEMA INTEGRADO DE ASEGURAMIENTO
Es una aplicación que hace la función de integradora entre el conjunto de aplicaciones de Aseguramiento
y cubrir sus carencias de información y funcionales para obtener como resultado un sistema que
proporcione la información completa de los asegurados de SSPV, permita su explotación, segmentación
etc cumpliendo siempre la normativa vigente en materia de seguridad. Se utiliza y desarrolla la parte de
integración y servicios, pero no se ha potenciado la parte de contenedor de datos detallados de los
asegurados.
Del mismo modo que en el caso de la G83, a lo largo del 2011 la Dirección se plantea la implantación de
un nuevo sistema de información que palie las carencias del actual. Para poder llevar a cabo dicha
Pliego de Bases Técnicas
10/55
implantación, casi con toda seguridad, será necesario realizar acciones de mantenimiento sobre el
aplicativo actual para mantener “retro-compatibilidad”.
R27-REGISTRO DE CENTROS SANITARIOS (SIIOS)
Es el registro de centros sanitarios de la C.A.P.V desde su solicitud, condiciones, servicios,
equipamiento, etc, . Es una aplicación cuya gestión está distribuida entre Lakua y Direcciones
Territoriales del Departamento de Sanidad. Lleva una explotación GIS en 1ªfase. Cuenta con un módulo
de integración de los Centros Sanitarios con el Gobierno Central.
R52/R85-OSANET y portales
Es el portal de la sanidad vasca. Se trata del marco de actuación en internet para la gestión de
contenidos, aplicaciones, foros, etc…del Departamento de Sanidad y Osakidetza (Servicio Vasco de
Salud). Si bien su objetivo y orientación real es la de proveer de una serie de servicios telematicos a la
ciudadanía vasca, se encuentra ubicado en el marco general de la administración vasca ‘euskadi.net’. La
gestión está distribuida entre Lakua y Osakidetza.
El papel del portal de Osanet podrá verse condicionada por el proyecto de Osarean mencionado con
anterioridad.
R69-TUBERCULOSIS
Se trata de un DW con el registro de casos de tuberculosis en la CAPV. La gestión está distribuida entre
Lakua y las Direcciones Territoriales.
S29-INVESTIGACION COMISIONADA
Aplicación que gestiona las ayudas de Osteba en el ambito IC. Se activa solo en periodos concretos y se
trata de una recepción de solicitudes via web a través de formularios sin ninguna gestión adicional en
Backoffice.
S60-ORDENACION FARMACEUTICA
Es el registro de farmacias de la C.A.P.V desde su solicitud, condiciones, servicios, equipamiento, etc, .
Gestión distribuida entre Lakua y Direcciones Territoriales del Departamento de Sanidad. Lleva
asociada explotación GIS.
S61-ESTABLECIMIENTOS BIOCIDAS
Es el registro de establecimientos que trabajan con Biocidas en la C.A.P.V . Gestión distribuida entre
Lakua y Direcciones Territoriales.
Pliego de Bases Técnicas
11/55
S82-PUBLICACIONES DE OSTEBA
Es el registro de publicaciones de Osteba. Desarrollos finalizados a falta de implantación en Producción.
T75-GIS
Es una aplicación para la gestión Infografica de Sanidad. En desarrollo.
U15-SIPCA
Esta aplicación gestiona el pago de las tasas del Departamento de Sanidad y Consumo, comunicándose
con la pasarela de pagos e informando a SIPCA. En fase de Desarrollo.
U90-SIFCO-FONDO COHESION
Se trata de un proyecto de integración de las prestaciones sanitarias de la CAV y el Ministerio de
Sanidad. En uso la parte de Prestaciones y RNIP y en desarrollo la TIS, Centros y profesionales
sanitarios.
V15-VACUNAS
Es la aplicación de gestión de vacunas de la CAPV desde su planificación, adquisición, prescripción y
administración al paciente. En de desarrollo 2ªfase (integración Osakidetza) pendiente de formación e
implantación final en Producción.
V19-PORTAL OSAKIDETZA
Se trata del portal de Osakidetza (integrado en Osanet). Al igual que en el caso del portal de Osanet, los
siguientes pasos a realizar sobre este portal se verán condicionados por el proyecto de Osarean.
V45-SISTEMA DE DIFUSION SIDA
Se trata de un servicio de publicaciones asociado a Osanet.
W40/O41-RED DE VIGILANCIA MICROBIOLOGICA
Es la aplicación de gestión de vigilancia ante pandemias, alertas sanitarias, etc en la CAPV de cara a la
planificación y organización de los mecanismos sanitarios a aplicar. La O41 es la aplicación actual
mientras que la W40 está en fase de desarrollo 1ªfase partiendo de modelo de la Comunidad
Valenciana.
Pliego de Bases Técnicas
12/55
W51-AGUAS DE RECREO-PISCINAS
Es el registro de establecimientos con agua de recreo (PISCINAS) de la CAPV. Sistema implantado en
Producción para una primera fase.
X31-Digitalización de ayudas y subvenciones a coste 0
Proyecto de digitalización basado en PLATEA que, entre otras, cuenta con las siguientes
funcionalidades:
-.Ayudas a ENTIDADES para organización de cursos, reuniones, publicaciones periódicas y
funcionamiento de entidades (orientadas a ASOCIACIONES).
-. Ayudas para BECAS (orientado a PERSONAS).
2.3
Líneas de trabajo
Durante la prestación del servicio la lista inicial de sistemas de información incluidos en el ámbito del contrato
podrá verse modificada por diversos motivos, entre otros:
•
•
•
Incorporación de aplicaciones que tras su puesta en producción, finalizan su período de garantía
Sustitución de aplicaciones ya obsoletas por nuevos desarrollos
Eliminación de aplicaciones cuyas funcionalidades han sido también eliminadas en el departamento o
cubiertas por otros sistemas de información.
A los nuevos sistemas de información que sean incorporados en el alcance del servicio, se le aplicarán las
mismas condiciones de funcionamiento que a las definidas inicialmente en el Anexo I.
Las modificaciones sobre el ámbito de las aplicaciones objeto del contrato podrá dar lugar a la revisión de las
prestaciones económicas inicialmente acordadas. Esta revisión se realizará semestralmente, y sus condiciones
particulares se regirán según lo expuesto en el apartado “modelo de facturación” del presente documento.
Con objeto de definir más detalladamente el alcance y condiciones del contrato, se han establecido varias
líneas de trabajo, caracterizadas principalmente por agrupaciones lógicas de actividades que deberán
desarrollarse.
La catalogación de las peticiones de servicio que se registren dentro de la línea de trabajo que le corresponda
será realizada por el GGANS de EJIE.
El equipo asignado a la resolución de las actividades especificadas en cada línea de trabajo estará formado por
perfiles con capacidad, experiencia, y conocimientos necesarios para el correcto desempeño de su trabajo.
En general, las actividades asignadas al adjudicatario deberán ser realizadas en sus propias dependencias.
Para los casos en que EJIE lo considere necesario, el personal asignado al servicio de mantenimiento deberá
desplazarse a los locales de EJIE con la rapidez que se requiera en cada actuación.
MANTENIMIENTO BÁSICO
Pliego de Bases Técnicas
13/55
Las actividades englobadas en este tipo de mantenimiento son:
•
Atención a Consultas y Soporte Técnico de Aplicaciones
Definido como el conjunto de actividades de soporte y atención a consultas e incidencias técnicas, entre
EJIE y el personal técnico del proveedor respecto a las aplicaciones objeto del ANS.
Estas actividades deberán ser realizadas preferentemente mediante la herramienta de gestión de
peticiones de servicio (Mantis), frente al canal telefónico. En este último caso, una vez atendida la llamada,
ésta también deberá darse de alta como petición de servicio en la herramienta de gestión.
•
Mantenimiento Correctivo (errores en el software)
Se define como aquel proceso orientado a la reparación de defectos existentes en un sistema software.
Estos defectos pueden manifestarse de distintas formas:
o
o
Cuando el programa falla o termina inesperadamente.
Un programa produce un resultado que no es acorde con los requisitos.
Se contemplan dos tipos básicos de mantenimiento correctivo:
o
o
Reparaciones de emergencia: ejecutadas en cortos periodos de tiempo y generalmente sobre un
único programa.
Reparaciones planificadas: arreglan defectos que no requieren una atención inmediata y reexaminan todas las reparaciones de emergencia.
El mantenimiento correctivo incluye actividades que comprenden desde la colaboración activa con EJIE en
el diagnóstico de los defectos detectados y su propuesta de solución, hasta el seguimiento y resolución de
los mismos. También se incluyen como responsabilidad del adjudicatario los desarrollos necesarios para
corregir los datos erróneos por el mal funcionamiento de la aplicación así como la actualización de la
documentación e involucración en los procesos que procedan en función del cambio llevado a cabo.
Toda actuación sobre el software motivado por un fallo o error de la aplicación será considerada
siempre como actividad correctiva y en ningún caso actividad de tipo evolutivo.
MANTENIMIENTO EVOLUTIVO / ADAPTATIVO
•
Mantenimiento Evolutivo:
Son las incorporaciones, modificaciones y eliminaciones necesarias para cubrir la evolución o cambio de
las necesidades del usuario, es decir, la incorporación de nuevas funcionalidades a la cobertura actual del
software. Incluye, entre otros:
o
o
o
Cambios en los requisitos de la aplicación
Modificaciones derivadas de cambios en la normativa
Modificaciones de alcance limitado que supongan mejoras del aplicativo y por tanto incorporables a
la versión base
En base al esfuerzo requerido para su resolución, esta tipología de actividad se ha dividido en dos niveles:
o
Mantenimiento Evolutivo a pequeña escala
Son actividades relacionadas con el desarrollo evolutivo, cuyo tamaño y complejidad no son
excesivos. Se estima un esfuerzo menor a 100 horas-persona.
Pliego de Bases Técnicas
14/55
o
Mantenimiento Evolutivo a gran escala
Corresponderán a actuaciones de tamaño y complejidad más significativas, en concreto, aquellas
cuyo esfuerzo sobrepase el límite establecido para el mantenimiento evolutivo a pequeña escala.
En los casos en que sea necesario y bajo demanda, se solicitará al proveedor que colabore con el grupo
de asistencia técnica de EJIE para la elaboración del análisis funcional.
•
Mantenimiento Adaptativo:
Son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de
configuración del hardware, software de base, gestores de base de datos, comunicaciones, etc. Incluye,
entre otros:
o
o
o
o
o
o
Cambios en el entorno de los datos o su procesamiento
Cambios en la plataforma o arquitectura tecnológica
Modificación de procedimientos existentes que no implican nuevas funcionalidades
Exportaciones e importaciones de datos dedicados a la integración con otras aplicaciones del
entorno, para mantenimiento de integridad de la información
Integración con otros aplicativos a nivel de plataforma tecnológica
La parametrización de aplicaciones
Este tipo de mantenimiento se regirá por los mismos criterios descritos en el mantenimiento evolutivo.
GESTIÓN DEL INVENTARIO, REPOSITORIOS Y DOCUMENTACIÓN
Dada la naturaleza y características del servicio objeto del contrato se hace imprescindible contar con un
inventario detallado de las aplicaciones que conforman su alcance. Dicho inventario partirá del conjunto de
aplicaciones actualmente en la BBDD repositorio de EJIE así como en un conjunto de fichas descriptivas de los
mismos y que actualmente usa el grupo de asistencia técnica de EJIE. Por tanto deberá recoger toda aquella
información que se considere necesaria y suficiente para la gestión adecuada del servicio:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Código y denominación de la aplicación
Responsable funcional en EJIE
Área
Presupuesto
Conocimiento Funcional
Responsable técnico del proveedor
Características técnicas de la aplicación (tecnología, sistema de base de datos, arquitectura, etc.)
Status (versión actual en los distintos entornos)
Tamaño de la aplicación (nº de programas y complejidad)
Plataforma HW y SW
Herramientas de Desarrollo
Documentación existente
Problemas específicos en la aplicación
Estabilización de la aplicación
Tipología de incidencias y horas
Interrelación con otras aplicaciones
Etc.
El inventario deberá estar implantado/albergado en las instalaciones de EJIE y el mantenimiento del mismo
entrará dentro del alcance de los trabajos a realizar. Será responsabilidad del adjudicatario mantener
actualizado en todo momento el inventario de aplicaciones, y por ende, sus correspondientes fichas
descriptivas.
Pliego de Bases Técnicas
15/55
Además del inventario, es imprescindible disponer de todos los artefactos de cada aplicación, necesarios para
la realización de las actividades de mantenimiento encomendadas al adjudicatario, entre otros, el código
fuente, los contenidos estáticos, los scripts de creación de base de datos, los ficheros de configuración, etc. así
como la documentación asociada.
Estos artefactos deberán ser versionados adecuadamente, pero siempre desde una visión completa de
aplicación, es decir, qué conjunto concreto de elementos componen la versión “x” de la aplicación (código
fuente, scripts, estáticos, etc.). Deberá establecerse un procedimiento de gestión de la entrega de la
totalidad de los artefactos mencionados con anterioridad que deberá regirse, en un principio, bajo el concepto
de “release” o versión de producto, que incluirá tanto los artefactos programáticos como la documentación
asociada a cada una de las versiones.
El adjudicatario deberá mantener actualizado en todo momento el repositorio (herramienta homologada,
SUBVERSION) de artefactos de aplicación. Para la documentación se trabajará con Micoroft Sharepoint como
repositorio de documentación a tal efecto.
Asociado al ciclo de vida del desarrollo software, nuestra metodología de desarrollo ARINBIDE ya marca el
conjunto de entregables que deben obtenerse en cada una de las fases que la componen. También en este
aspecto, es fundamental disponer de toda la documentación perfectamente actualizada y dentro de la entrega
de una versión concreta del producto.
Se subraya también la necesidad de generar la documentación y elementos adicionales fijados por el servicio
de gestión del cambio de EJIE para cada implantación:
•
•
•
•
•
•
•
•
Manual de implantación
Manual de explotación
Instrucciones implantación
Carga de código en las zonas de traspaso
Proceso de compilación y despliegue (compile.txt)
Cálculo de volumetría de datos
Plantillas de pruebas de capacidad
Otros documentos según la tipología y características de la aplicación (seguridad LOPD, plan de
continuidad de negocio, configuración de recursos en XLNetS, etc.)
Como en el resto de los casos, la documentación asociada será un artefacto más asociado a una versión del
aplicativo cuya entrega deberá seguir el mecanismo de gestión de entregas que se determine.
El adjudicatario deberá mantener actualizado en todo momento el repositorio de documentación asociada a
cada aplicación.
Excepto la documentación necesaria para realizar el proceso de implantación del cambio (que se generará
previamente), las actualizaciones aquí definidas deberán realizarse en un plazo máximo de 48 horas desde
el cierre de la solicitud de trabajo y entrar en el procedimiento de gestión de entrega
El incumplimiento sobre la obligación del mantenimiento y actualización del inventario, del repositorio y de la
documentación generará la no aceptación del trabajo.
GESTIÓN DE LA CALIDAD (DEL PRODUCTO) Y PRUEBAS
•
Mantenimiento Perfectivo. Su objetivo principal es tratar de refinar y mejorar la calidad de las
aplicaciones en todos sus aspectos, ya no solo del software sino también del resto de sus entregables
(documentación).
Pliego de Bases Técnicas
16/55
Aunque este grupo de actividades (calidad y pruebas) tomarán como referencia la tipología de mantenimiento
perfectivo, su alcance real sin embargo se extiende directamente a los mantenimientos correctivo, evolutivo y
adaptativo.
Por lo tanto, con objeto de mejorar progresivamente la calidad de las aplicaciones incluidas en el ámbito del
presente pliego de bases técnicas, y siguiendo el modelo estándar de aseguramiento de la calidad del producto
de GV-EJIE, se incluye en esta línea de trabajo las actividades derivadas de la ejecución de un plan de
aseguramiento de la calidad cuyo alcance está contemplado en las fases descritas en el apartado de “Fases
del servicio” del presente documento.
Estas actividades deberán realizarse haciendo uso del conjunto de herramientas homologadas en el entorno de
GV-EJIE para tal fin.
Los defectos y no conformidades detectados durante la ejecución del plan de aseguramiento de la calidad
deberán subsanarse con la generación de solicitudes de trabajo del tipo “mantenimiento correctivo”.
Cada nueva aplicación que con posterioridad al arranque del proyecto se incorpore en el alcance del servicio
de mantenimiento objeto del contrato, deberá ser incluida en el plan de aseguramiento de la calidad del
producto en los mismos términos y condiciones que las originalmente detalladas en el pliego de bases técnicas.
Por cada trabajo que se lleve a cabo sobre las aplicaciones, consecuencia de las peticiones de mantenimiento
demandadas, deberá garantizarse que el sistema actualizado mantiene al menos los mismos niveles de calidad
(iguales o superiores, pero nunca inferiores), previos a la actuación. Utilizando como referencia el modelo
estándar de aseguramiento de la calidad del producto de GV-EJIE, y por tanto de la metodología de pruebas,
se recalcularán al menos:
•
•
•
Los indicadores estándar de calidad (de código estático, y de rendimiento)
Los resultados de las pruebas:
o Unitarias. Para evitar la introducción de un nuevo defecto al intentar reparar el inicialmente
detectado, se relanzarán todas las definidas. Dentro de este apartado deberán incrementarse
de modo sustancial el número de pruebas unitarias automatizadas para cada una de las
aplicaciones.
o De integración. En un principio, se ejecutarán sólo para las que afecten a los módulos
reparados, y a todos aquellos que dependan directa o indirectamente de estos. No obstante, y
en función de la naturaleza del cambio a realizar, dichas pruebas podrán extenderse a otros
módulos o sistemas que se vean afectados.
o De sistema. En un principio, se ejecutarán solo para las que afecten a los módulos reparados, y
a todos aquellos que dependan directa o indirectamente de estos. . No obstante, y en función
de la naturaleza del cambio a realizar, dichas pruebas podrán extenderse a otros módulos o
sistemas que se vean afectados.
o De regresión. Como en el caso de las pruebas unitarias, se relanzarán todas las definidas y
automatizadas, que deberán incrementarse a la largo de la fase de prestación de servicios.
Controles de calidad (SQA) para los entregables (documentación) que se hayan visto afectados.
Un decremento en los niveles de calidad calculados supondrá la no aceptación del trabajo por parte de EJIE,
siendo responsabilidad del adjudicatario realizar las acciones y tareas que sean necesarias para restablecer al
menos los mismos niveles de calidad previos a la actuación.
La aplicación de este plan de calidad tendrá como objetivo la reducción de las actuaciones de
mantenimiento correctivo en un 5% anual.
GESTIÓN Y ADMINISTRACIÓN DEL SERVICIO
Se incluyen en esta línea de trabajo las actividades relativas a la gestión y seguimiento del propio servicio,
cuyos indicadores e informes deben ser reportados al comité de seguimiento para su aprobación y control. Se
Pliego de Bases Técnicas
17/55
incluyen por lo tanto los informes detallados en el apartado de “Control y seguimiento” del presente pliego de
bases técnicas:
2.4
Presupuesto
El presupuesto máximo ANUAL al cual se referirán las ofertas en respuesta al presente Pliego de Bases
Técnica, deberán ser con arreglo a los siguientes aspectos:
•
Presupuesto base
En este concepto se incluye: Mantenimiento básico; Mantenimiento evolutivo a pequeña escala;
Gestión del inventario, repositorios, y documentación; Gestión de la calidad pruebas; Gestión y
administración del servicio.
En un principio, la facturación de estos servicios ser harán con arreglo a la parte proporcional con
carácter mensual siempre y cuando los trabajos realizados hayan sido aceptados por EJIE.
El importe máximo a este respecto para cada uno de los años de prestación del servicio será de 170.000
€ (IVA no incluido)
•
Presupuesto evolutivo/adaptativo
Abarca el Mantenimiento evolutivo a gran escala, y el Mantenimiento adaptativo.
El importe máximo a este respecto para cada uno de los años de prestación del servicio será de
210.000 € (IVA no incluido)
Pliego de Bases Técnicas
18/55
3
Definición del Servicio
3.1
Fases del Servicio
El modelo de prestación del servicio se ha dividido en varias fases consecutivas, estableciendo un período
inicial de adquisición progresiva de conocimientos, una fase central de prestación normal del servicio, y una
fase final orientada a la transición de responsabilidades hacia a EJIE o hacia un nuevo adjudicatario.
Secuencia de fases del servicio
FASE 1: DIAGNOSTICO
Esta fase inicial del servicio facilitará al adjudicatario una primera toma de contacto en la cual podrá obtener
datos actuales sobre las características del proyecto. En colaboración directa con el GGANS de EJIE actuando
como facilitador y proveedor de toda la documentación e información que se requiera, el adjudicatario podrá
planificar y preparar la fase de transferencia, obtener información detallada del servicio, así como las
necesidades derivadas de gestión y organización que garanticen, en definitiva, el éxito de la prestación del
servicio para el que ha sido contratado.
Con objeto de disponer de una visión global sobre el estado inicial de las aplicaciones objeto del contrato, el
adjudicatario elaborará un informe resumen en el que se recojan los aspectos más relevantes del diagnóstico
realizado. El índice y contenido de dicho informe será propuesto por el adjudicatario, que deberá ser aprobado
por el GGANS de EJIE.
Salidas:
•
Informe de diagnóstico de situación actual
FASE 2: TRANSFERENCIA
En esta fase, el adjudicatario después de completar el acopio de todos los elementos necesarios para la
prestación del servicio iniciado en la fase anterior, deberá asegurarse el conocimiento detallado de todas las
aplicaciones que componen el objeto del presente pliego de bases técnicas.
Se elaborará y ejecutará un plan detallado de reuniones de transferencia del conocimiento con los
responsables funcionales y técnicos de EJIE, asegurando así el dominio detallado de la operativa de los
sistemas, y el de sus características técnicas.
Será responsabilidad del adjudicatario reinstalar en sus propias dependencias el conjunto de aplicaciones,
incluyendo ya no solo el código fuente, sino también el conjunto de artefactos adicionales que la conforman
(contenidos estáticos, la base de datos, etc.) proveyéndose así de la autonomía suficiente para realizar las
actividades de mantenimiento que le serán encomendadas. Deberá proveerse además de una conexión
Pliego de Bases Técnicas
19/55
simétrica con suficiente ancho de banda como para soportar el tráfico que se genere durante el tiempo de
resolución de las actividades de mantenimiento que le sean requeridas. Se contempla la opción de conexión
VPN, aunque no se descartan otras posibles alternativas que deberán ser valoradas.
El coste de las licencias necesarias para poder realizar las tareas de mantenimiento en sus propias
instalaciones correrá a cargo del adjudicatario.
Se iniciará también en esta fase la gestión del inventario de aplicaciones, así como la de los repositorios de
artefactos software, y de documentación.
Aplicando el modelo estandarizado de aseguramiento de la calidad del software de GV-EJIE, el adjudicatario
deberá elaborar un plan detallado que permita obtener un diagnóstico real de la calidad de cada una de las
aplicaciones objeto del contrato, así como la secuencia de actividades a realizar para aumentar
progresivamente la calidad de cada una de ellas (mantenimiento perfectivo). El plan deberá contemplar por lo
tanto:
•
•
•
•
•
El valor NAC (nivel de aseguramiento de la calidad) asociado a cada aplicación, y definido por el
responsable funcional de EJIE
Tipologías de pruebas a ejecutar para cada aplicación
Controles de calidad (SQA) a realizar
La aplicación (total o parcial) de la metodología de pruebas, incluyendo los entregables a obtener
Cálculo de indicadores estándar (de calidad de código estático, y de rendimiento)
Al tratarse de un servicio de mantenimiento y no de un nuevo desarrollo, se deberá acordar el alcance global
del plan propuesto, pudiendo por lo tanto prescindir por ejemplo de ciertas tipologías de pruebas cuando las
circunstancias así lo aconsejen. En cualquier caso la decisión final sobre el ámbito de aplicación, las
condiciones particulares, y la secuencia de ejecución recogidos en el plan será siempre potestad de EJIE.
Cabe recordar también que las bases tecnológicas sobre las que están construidas las aplicaciones objeto del
contrato son variadas, y por tanto el nivel de exigencia a aplicar respecto al modelo de aseguramiento de la
calidad (más orientado a sistemas J2EE) variará razonablemente en función de su base tecnológica.
Dentro del plazo temporal de esta fase, además de elaborar el plan de aseguramiento de la calidad detallado,
se deberán obtener los valores asociados a los indicadores de calidad de código estático, retrasando para
fases posteriores la ejecución de los controles de calidad (SQA), la definición y modelado de las tipologías de
pruebas, y el cálculo del resto de indicadores.
Estas actividades deberán realizarse haciendo uso del conjunto de herramientas homologadas en el entorno de
GV-EJIE para tal fin
Como en la fase anterior, el adjudicatario deberá documentar adecuadamente todas las actividades del
proceso de transferencia.
Salidas:
•
•
•
•
Informe de resultados de la fase de transferencia
Aplicaciones operativas en las instalaciones del adjudicatario
Plan de aseguramiento de la calidad
Indicadores de calidad de código estático
FASE 3: ESTABILIZACIÓN
Una vez adquiridos los conocimientos necesarios, y montadas las infraestructuras de soporte, el adjudicatario
podrá ejecutar las peticiones de trabajo que se le requieran por parte del GGANS de EJIE. No obstante, y con
el fin de garantizar que el servicio de mantenimiento se resolverá adecuadamente, se incluye un período de
Pliego de Bases Técnicas
20/55
estabilización y acompañamiento (voluntario, a decisión del adjudicatario) del personal técnico de EJIE que
permita realizar los ajustes finales, y consolide por fin los flujos de trabajo que se aplicarán en la fase de
prestación del servicio.
En esta fase el adjudicatario consolidará definitivamente la organización con la que proporcionará el servicio,
así como la asignación de recursos y confirmación de roles, tareas y responsabilidades, necesarios para la
gestión del servicio.
El plazo máximo de ejecución de estas tres primeras fases (diagnóstico, transferencia y estabilización)
será de 3 meses, y los servicios incluidos en ellas no serán facturables. Cualquier modificación a este
respecto deberá ser justificada por el adjudicatario y aprobada por EJIE.
Salidas:
•
•
Organización final del servicio
Flujos de trabajo consolidados
FASE4: PRESTACIÓN DEL SERVICIO
Se trata de la fase operativa del servicio. Una vez superada la fase de estabilización, el adjudicatario deberá
funcionar ya de manera autónoma, resolviendo adecuadamente y en los plazos marcados las peticiones de
trabajo que se le encomienden, gestionando los recursos dedicados, medición de los indicadores acordados,
realización de las reuniones de seguimiento, obtención de informes de actividad, etc., garantizando en definitiva
la calidad del servicio para el que ha sido contratado.
Como continuación al plan de aseguramiento de la calidad para las aplicaciones incluidas en el ámbito del
presente pliego de bases técnicas, cuya primera aproximación habrá sido ya ejecutada en la fase de
diagnóstico, el adjudicatario deberá ejecutar el resto de tareas pendientes, entre otras, los controles de calidad
(SQA), las tipologías de pruebas junto con su planes básicos de pruebas, y el cálculo de los indicadores de
rendimiento. Para esta actividad se establece un plazo máximo de 9 meses desde el inicio de la presente
fase.
El plan inicial aprobado podrá ser modificado al menos en el supuesto en el que durante la prestación del
servicio sea necesario actuar sobre una aplicación y todavía no hayan sido obtenidos sus niveles de calidad, lo
que obligará a priorizar las tareas asociadas a dicha aplicación. En este caso se deberá acordar con EJIE el
alcance final de las tareas a ejecutar.
Del mismo modo, el adjudicatario podrá adelantar voluntariamente la ejecución del resto de tareas impuestas
por el plan de aseguramiento de la calidad a cualquiera de las fases anteriores, pero en ningún caso podrá
superar el plazo máximo de finalización de la actividad más allá de los 9 meses desde el inicio de la presente
fase.
Todos los artefactos y documentación que se generen como resultado del plan de aseguramiento de la calidad
pasarán a ser propiedad de EJIE:
•
•
•
•
Planes de pruebas
Scripts de navegación
Pruebas unitarias, de integración, de sistema, de regresión, ...
Etc.
Estas actividades deberán realizarse haciendo uso del conjunto de herramientas homologadas en el entorno
de GV-EJIE para tal fin.
Puesto que EJIE está trabajando ya en la mejora del actual modelo de aseguramiento de la calidad
(procedimientos de gestión de la calidad, utilidades, integración de herramientas, etc.) en el momento en el que
éste esté disponible el adjudicatario deberá adaptarse al nuevo modelo.
Pliego de Bases Técnicas
21/55
Salidas:
•
•
•
Las propias de las actividades objeto de la contratación
Resultados del plan de aseguramiento de la calidad
Informes de control y seguimiento, indicadores, etc.
FASE 5: DEVOLUCIÓN
La fase de devolución asegurará que el adjudicatario pondrá a disposición de EJIE o de un tercero, de manera
ordenada, todos aquellos artefactos software, documentación, inventarios, repositorios, etc. que han sido
utilizados durante la prestación del servicio. Se garantizará así que EJIE o un tercero pueda asumir las mismas
actividades de mantenimiento en un tiempo suficiente.
Puesto que para las fases iniciales del servicio (diagnóstico, transferencia y estabilización) se definió un plazo
máximo de 3 meses, esta fase de devolución a EJIE o a un tercero se fija también en 3 meses, coincidiendo
por tanto con dichas fases iniciales para quien asuma entonces el servicio de mantenimiento. Se entiende
entonces que será tarea del adjudicatario colaborar activamente en este período de transición.
Para garantizar este objetivo, a lo largo del periodo que dure el contrato, se realizará un Plan de Devolución
que será revisado y aprobado progresivamente por el GGANS de EJIE.
Salidas:
•
3.2
Plan de devolución, realizado
Flujos de trabajo
3.2.1.
Peticiones de servicio
Flujo de peticiones de servicio
Tomando como referencia el proceso de mantenimiento (MSI) definido por ARINBIDE, el licitador podrá
incluir en su oferta una propuesta de flujo de peticiones de trabajo a aplicar durante la prestación del
Pliego de Bases Técnicas
22/55
servicio. En última instancia, el modelo final a utilizar deberá ser aprobado por EJIE. Se detalla a
continuación una posible aproximación para dicho flujo.
El cliente realiza una petición que es atendida por el Interlocutor Funcional de EJIE, o por el GGANS de
EJIE. Para el caso de errores o defectos de la aplicación (mantenimiento correctivo), la incidencia llegará
a través del CAU (Centro de atención a usuarios).
Una vez atendida y aceptada, la petición se registra y cataloga en la herramienta de gestión de
peticiones de servicio (Mantis).
El GGANS de EJIE estudiará y analizará la necesidad demandada, delegando en el responsable
funcional de EJIE la realización de la estimación del esfuerzo (horas-persona, plazo de ejecución, y coste
económico según tarifas del adjudicatario acordadas en el contrato) para resolver la petición.
El GGANS de EJIE completará la solicitud con toda aquella información que considere necesaria, y
asignará la orden de trabajo al GGANS del adjudicatario, quien a su vez distribuirá la petición (o
generará nuevas peticiones) a todos aquellos a quienes corresponda, indicando también en la
herramienta de gestión, el plazo de entrega estimado para su resolución.
Será responsabilidad del adjudicatario establecer el protocolo de actuación interno para las peticiones
que les sean requeridas.
Durante la resolución de la orden de trabajo, se realizan las actividades de desarrollo y de pruebas que
se estimen necesarias, y cuando el producto modificado ya se considere correcto, se realizará el
traspaso al entorno de EJIE siguiendo el flujo de entrega establecido (se plantea una posible
aproximación en el siguiente apartado del presente documento).
3.2.2.
Entrega
El modelo de referencia para realizar las entregas del código actualizado tras una solicitud de trabajo
seguirá las directrices marcadas por el documento de Estándares de desarrollo de sistemas software, de
obligado cumplimiento en el entorno de GV-EJIE.
El licitador deberá incluir en su oferta una propuesta de flujo de entregas a aplicar durante la
prestación del servicio. En última instancia, el modelo final a utilizar deberá ser aprobado por EJIE. Se
detalla a continuación una posible aproximación sobre dicho modelo.
Tanto el desarrollo del software como al menos el conjunto de pruebas unitarias se deberán realizar en
los PCs del desarrollador o en aquellos elementos (servidores físicos, máquinas virtuales) que el
adjudicatario del servicio considere en cada caso siempre y cuando se trabaje simulando el entorno real
de EJIE en cuanto a versiones de las diferentes plataformas contempladas.
El proveedor validará en sus propias instalaciones que el código generado es estable, que funciona
adecuadamente y que satisface las condiciones recogidas en la orden de trabajo solicitada. Una vez
validado, se realizará el traspaso a los entornos de desarrollo de EJIE. Toda entrega deberá ser
versionada y etiquetada (petición(es) de servicio que resuelve, resumen de modificaciones, etc.)
adecuadamente.
El adjudicatario deberá realizar además las tareas de compilación y despliegue del código en el servidor
de EJIE, así como cualquier otra acción que sea necesaria hasta que el cambio esté operativo en el
entorno de desarrollo de EJIE (ejecución de scripts de actualización de la base datos, modificación de
datos, cambios en los contenidos estáticos, etc.)
Pliego de Bases Técnicas
23/55
Este entono cumplirá las funciones de contexto de integración como paso previo a la implantación en el
entono de pruebas, pero nunca como entorno para el desarrollo.
Las tareas derivadas del plan de aseguramiento de la calidad deberán realizarse en el entorno de
desarrollo de EJIE (análisis estático del código, indicadores de rendimiento, pruebas de integración, de
regresión, etc.)
Traspaso del código actualizado
En general, el resto de artefactos y componentes que deban ser actualizados deberán seguir el mismo
modelo de entregas que el definido para el código. Se destaca la importancia de versionar y etiquetar
dichos complementos.
En el entorno de desarrollo el responsable funcional de EJIE deberá validar y aceptar los trabajos
realizados, y solo en este caso se podrá proponer su promoción a los siguientes entornos.
El GGANS de EJIE deberá asegurar que el detalle relativo a la solución aplicada para dar respuesta a la
petición de trabajo está perfectamente documentado en la herramienta de gestión de peticiones de
servicio (Mantis).
En función de la tipología de la solicitud de trabajo resuelta, el adjudicatario deberá actualizar además:
o
o
o
El inventario de aplicaciones. Se deberá modificar la ficha de aplicación, recogiendo al menos
la versión operativa actual en el entorno de desarrollo, así como la de sus artefactos y
componentes adicionales (contenidos estáticos, scripts de base de datos, etc.). También, y en
base al el modelo estándar de aseguramiento de la calidad, se deberá actualizar el estado
actual de la calidad del sistema (indicadores, resultados de pruebas, etc.)
Documentación. Todos aquellos documentos que hayan sido modificados (de diseño,
manuales de usuario, de explotación, etc.) o de nueva creación.
Documentación adicional para promocionar el cambio al resto de entornos.
Excepto la documentación necesaria para realizar el proceso de implantación del cambio (que se
generará previamente), estas actualizaciones deberán realizarse en un plazo máximo de 48 horas
desde el cierre de la solicitud de trabajo.
El adjudicatario deberá colaborar activamente con el GGANS en la implantación del cambio en el resto
de entornos, pruebas y producción.
La petición de trabajo se cerrará en el momento en que los cambios realizados hayan sido instalados
satisfactoriamente en el entorno de producción. Solo el responsable funcional de la aplicación de EJIE
podrá validar la aceptación final del cambio.
Pliego de Bases Técnicas
24/55
4
4.1
Configuración del Servicio
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, así como
• Las funciones de los mismos, y
• La relación nominal de los participantes, junto su correspondiente documento de currículo.
No obstante, se detalla a continuación una posible aproximación de modelo organizativo:
COMITÉ DIRECTOR ANS
Ostenta la máxima autoridad en el proyecto y representa a las organizaciones involucradas en el mismo, EJIE y
la empresa adjudicataria
A este comité se incorporarán las personas que en cada momento estime oportuno el propio comité,
principalmente de las áreas representadas en el proyecto.
Participantes:
• EJIE:
o Directora del área de proyectos y asistencia técnica
o Jefe de proyecto del grupo de asistencia técnica
• Adjudicatario:
o Director de Proyecto del adjudicatario en representación de la Dirección
o Responsable del Proyecto
Roles y responsabilidades:
• Liderar y apoyar la consecución de los objetivos fundamentales
• Resolver los conflictos o problemas que, por cualquier razón, no puedan hacerse desde el comité de
Seguimiento.
• Definir o aprobar los indicadores de control cuyo seguimiento se va a realizar
Pliego de Bases Técnicas
25/55
•
•
•
Evaluar y aprobar, en su caso, las posibles variaciones de alcance, plazos, coste y requerimientos que
pudiesen surgir
Asegurar la disponibilidad de los medios y recursos necesarios para la ejecución del proyecto
Seguimiento exhaustivo de la aplicación del modelo de mantenimiento de ANS, evaluando y aprobando
las mejoras a aplicar.
COMITÉ DE SEGUIMIENTO
Representa la máxima autoridad en relación a la operativa del proyecto, realizando un seguimiento del trabajo
(planificaciones y recursos), de las problemáticas surgidas, escalando los aspectos que se consideren que
sobrepasan los límites de actuación establecidos.
A este comité se incorporarán las personas que en cada momento estime oportuno el propio comité,
principalmente de las áreas representadas en el proyecto.
Participantes:
• EJIE:
o Jefe de proyecto del grupo de asistencia técnica
o GGANS
• Adjudicatario:
o Responsable del proyecto
o GGANS
o Representantes de los equipos de trabajo del adjudicatario
Roles y responsabilidades:
• Seguimiento permanentemente del servicio.
• Garantizar los recursos necesarios para asegurar el cumplimiento del ANS tanto en relación a los
indicadores como a la calidad del mismo.
• Definir los indicadores de control cuyo seguimiento se va a realizar
• Evaluar y aprobar, en su caso, las posibles variaciones de alcance, plazos, coste y requerimientos que
pudiesen surgir.
• Agilizar la toma de aquellas decisiones que, por su naturaleza, pudieran exceder de las competencias
del Equipo de Trabajo.
• Elevar al comité de dirección las decisiones o incidencias que consideren necesarias.
• Elaborar los Informes de progreso con el fin de informar del desarrollo del servicio
EQUIPO DE GESTIÓN ANS DE EJIE
Forman el equipo operativo de gestión del servicio ANS, siendo por lo tanto el punto de contacto entre EJIE y el
adjudicatario.
Participantes:
• Técnicos de gestión del servicio (GGANS)
Roles y responsabilidades:
• Recepción de peticiones de servicio, de los responsables funcionales de las aplicaciones, del usuario, o
del CAU.
• Diagnóstico de incidencias y problemas
• Estimación de esfuerzos
• Gestión y seguimiento de las peticiones de trabajo al adjudicatario.
• Implantación de las modificaciones realizadas
• Coordinación con los responsables funcionales de las aplicaciones
• Seguimiento y control de los indicadores de calidad del producto
• Seguimiento y control de indicadores de calidad del proceso
• Seguimiento y control del inventario, repositorios y documentación
Pliego de Bases Técnicas
26/55
RESPONSABLES FUNCIONALES DE APLICACIONES
Se refiere a los equipos de asistencia técnica de EJIE, cuya misión fundamental será la realización de los
análisis funcionales, así como de aquellas actividades excepcionales de desarrollo y mantenimiento de
aplicaciones que siendo objeto del contrato, no puedan ser realizadas por la empresa adjudicataria.
Participantes:
• Responsables funcionales de aplicaciones
• Personal de asistencia técnica.
Roles y responsabilidades:
• Realización de los análisis funcionales de las aplicaciones
• Apoyo funcional y técnico al GGANS
• Colaboración con el GGANS en la estimación de esfuerzos
• Coordinación con el GGANS en la planificación y aprobación de las tareas de mantenimiento
evolutivo/adaptativo
• Resolución de dudas funcionales a los equipos de trabajo del adjudicatario
• Aprobación final de las modificaciones realizadas por el adjudicatario
• Aprobación de la implantación de cambios
EQUIPO DE GESTIÓN ANS DEL ADJUDICATARIO
Será el punto de entrada al servicio de mantenimiento ofrecido por el adjudicatario.
Participantes:
• Responsables funcionales de aplicaciones
• Técnicos de gestión del servicio (GGANS)
Roles y responsabilidades:
• Recepción de peticiones de trabajo de los gestores de servicio ANS de EJIE
• Distribución de tareas a los equipos de trabajo que corresponda
• Definición del plazo de entrega de las soluciones a las peticiones de trabajo recibidas
• Gestión y seguimiento de las peticiones de trabajo.
• Coordinación con los gestores de servicios de ANS de EJIE en las tareas de implantación de las
modificaciones realizadas
• Seguimiento y control de los indicadores de calidad del producto
• Seguimiento, control y cálculo de los indicadores de calidad del proceso
• Seguimiento y control del inventario, repositorios y documentación
EQUIPOS DE TRABAJO DEL ADJUDICATARIO
Estará formado por perfiles con capacidad, experiencia, y conocimientos necesarios para el correcto
desempeño de su trabajo.
Participantes:
• Jefe de proyecto
• Consultor funcional
• Consultor técnico (arquitecto)
• Técnicos de sistemas
• Analista programador
• Programador
Roles y responsabilidades:
• Corrección de defectos del código
Pliego de Bases Técnicas
27/55
•
•
•
•
•
•
•
4.2
Generación de artefactos software (librerías, scripts de base de datos, etc.)
Actualización del inventario, de los repositorios, y de la documentación
Pruebas unitarias, de integración, de sistema, de regresión, etc.
Asegurar la calidad de los productos actualizados
Cálculo de indicadores de calidad del producto
Generación de la documentación requerida para la implantación del cambio
Colaboración con los gestores de servicios de ANS de EJIE en las tareas de implantación de las
modificaciones realizadas
Asignación de recursos a fases del proyecto
El licitador deberá incluir en su Documento de Propuesta Técnica, un desglose de horas y % de dedicación
total por perfil y fase del proyecto, siguiendo el siguiente modelo:
Descripción Perfil
Fase
Diagnóstico
Horas
%
Fase
Transferencia
Horas
%
Fase
Estabilización
Horas
%
Fase Prest.
del servicio
Horas %
Fase
Devolución
Horas
%
Total
Horas
Jefe de Proyecto
Consultor Funcional
Consultor Técnico
Técnico de Sistemas
Analista Programador
Programador
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.
(**) Se deberán ofertar los perfiles indicados en la tabla y no otros.
4.3
Equipo de Trabajo
El equipo de trabajo propuesto estará formado por personal técnico con categoría profesional y nivel de
especialización adecuados a las necesidades planteadas en cada momento, de acuerdo con las actividades
que se vayan desarrollando.
El licitador debe comprometerse, en caso de ser adjudicatario, a mantener el equipo, según lo establecido en el
Documento de Propuesta Técnica, y durante el periodo fijado en cada actividad específica.
4.3.1.
Certificaciones en PLATEA y Geremua
Con el fin de asegurar la capacitación técnica del personal involucrado en el desarrollo de los proyectos,
en el ámbito del uso de plataformas y sistemas corporativos, se establece como requisito la acreditación
de dichos conocimientos en base a Certificaciones de los técnicos propuestos por el licitador. La
expedición de dichas acreditaciones, así como la formación destinada a la consecución de las mismas se
lleva a cabo por el European Software Institute (ESI).
Pliego de Bases Técnicas
28/55
Se han establecido dos perfiles de Certificación (analista y desarrollador), para cada una de las
siguientes especialidades:
o Infraestructura de tramitación electrónica, PLATEA-Tramitación
o Infraestructura de presencia en internet, PLATEA-Internet
o Infraestructura de integración
o Framework J2EE, Geremua
En concreto, para el proyecto objeto del presente pliego, la empresa licitadora deberá presentar personal
certificado conforme al siguiente cuadro:
Especialidad
PLATEA-Tramitación
PLATEA-Internet
Integración
Geremua
Nº de certificaciones
Analista
Desarrollador
X
X
X
X
X
X
X
X
Fecha límite de
acreditación
XX/XX/XXXX
XX/XX/XXXX
XX/XX/XXXX
XX/XX/XXXX
Para los casos en caso de que las fechas límite de acreditación sean posteriores a la fecha de
adjudicación del contrato, la oferta del proveedor deberá recoger compromisos firmes y concretos de
cumplimiento de las acreditaciones del personal propuesto en caso de ser adjudicatario. Cualquier
incumplimiento de las fechas de preceptividad comprometidas en la oferta del adjudicatario, podrá
suponer la rescisión del contrato y ser tenido en cuenta a efectos de calificación de solvencia técnica
para siguientes procesos de contratación.
Se valorará también cualquier otro tipo de certificación relacionada con el ámbito tecnológico detallado
en el apartado de “Especificaciones técnicas” del presente pliego de bases técnicas.
4.3.2.
Veracidad de los datos
EJIE se reserva la facultad de solicitar, en cualquier momento, antes o después de la adjudicación y
durante el curso de los trabajos, de cualquier otro tipo de documento complementario, en orden a la
comprobación de cuantos datos haya ofrecido la empresa adjudicataria, tanto respecto a la misma, como
a los recursos de que disponga.
La falsedad en los mismos podrá implicar asumir penalizaciones, y en último término, podrá provocar la
resolución del contrato.
4.3.3.
Condicionante del equipo de trabajo ofertado
La falsedad en el nivel de conocimientos técnicos del personal ofertado, deducida del contraste entre lo
reflejado en el currículo y los conocimientos reales demostrados en la ejecución de los trabajos, podría
en último término, provocar la revisión de la adjudicación y en su caso la rescisión del pedido/contrato.
4.3.4.
Constitución inicial del equipo de trabajo
El equipo humano a incorporar tras la formalización del contrato para la ejecución de los trabajos deberá
estar formado por componentes relacionados en la oferta adjudicataria y consecuentemente valorados.
Pliego de Bases Técnicas
29/55
Si tras la adjudicación se observara que el equipo de proyecto no se corresponde con el Documento de
Propuesta Técnica objeto de la misma y:
•
•
Caso que el adjudicatario presente justificación escrita, detallada y suficiente, explicando el motivo
que suscita el cambio, se procederá a:
9
La presentación por el adjudicatario de posibles candidatos con un perfil de cualificación
técnica igual o superior al de la persona que se pretende sustituir.
9
Aceptación de alguno de los candidatos por parte de la Dirección del Proyecto de EJIE
Caso de que se demostrase que el cambio no se corresponde con causa justificada, de fuerza
mayor y no imputable al adjudicatario, EJIE se reserva el derecho no solo a la aprobación de la
persona o personas sustitutivas, sino incluso a la revisión de la adjudicación y en su caso la
rescisión del pedido/contrato, si este hecho fuera elemento determinante en la mencionada
adjudicación.
4.3.5.
Modificaciones en la composición del equipo de trabajo
La valoración final de la productividad y calidad de los trabajos de las personas que realizan los trabajos
objeto del presente pliego corresponde a la Dirección del Proyecto de 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, si existen razones justificadas que lo aconsejen.
Si el adjudicatario propusiera el cambio de una de las personas del equipo de trabajo, se deberá solicitar
por escrito con quince días de antelación, y requerirá de las siguientes condiciones:
•
Justificación escrita, detallada y suficiente, explicando el motivo que suscita el cambio.
•
Presentación de posibles candidatos con un perfil de cualificación técnica igual o superior al de la
persona que se pretende sustituir.
•
Aceptación de alguno de los candidatos por parte de la Dirección del Proyecto de 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 no serán facturables corriendo a cargo del adjudicatario.
4.3.6.
Jornada laboral y lugar de realización de los trabajos.
Los trabajos de desarrollo se realizarán normalmente en las dependencias del adjudicatario en cuyo
caso:
•
La jornada de trabajo estará de acuerdo a la establecida por el adjudicatario,
•
Los componentes del grupo de trabajo deberán estar en una única ubicación y desarrollarán su
labor con hardware y software propiedad del adjudicatario. Dicha ubicación deberá ser lo
suficientemente cercana a EJIE como para garantizar una presencia rápida en sus dependencias
ante cualquier eventualidad que pudiera surgir.
Las pruebas de integración, de carga, aceptación y la puesta a punto final 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:
Pliego de Bases Técnicas
30/55
•
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 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
El horario de atención telefónica, así como la atención a peticiones de mantenimiento correctivo se
ajustará a la jornada de trabajo establecida por EJIE.
Con objeto de garantizar la continuidad de los servicios críticos proporcionados por las aplicaciones
incluidas en el presente pliego de bases técnicas, el adjudicatario deberá facilitar un teléfono de
contacto 24x7 que permita activar, en caso necesario, el servicio de mantenimiento correctivo para
peticiones de prioridad muy urgente o urgente objeto del contrato.
Las necesidades excepcionales de ampliación del horario de disponibilidad de los entornos de EJIE, o de
sus servicios de soporte u operación, deberán ser acordados con antelación suficiente con el GGANS,
que será el responsable de realizar las peticiones que sean necesarias. En cualquier caso solo se
contemplarán las necesidades recogidas en el catálogo de servicios de EJIE.
4.3.7.
Currículo de los componentes del grupo de trabajo.
Se deberá adjuntar el currículo individual detallado de todos y cada uno de los componentes del grupo
de trabajo propuesto para la realización de las tareas y actividades de los trabajos objeto de
contratación, junto con el papel/perfil (conforme a los indicados en el cuado anterior) que asumen en la
realización descrita.
La no inclusión del currículo de alguno de los participantes, puede suponer la imposibilidad de una
adecuada evaluación del apartado de “Organización del Proyecto”, pudiendo el licitador no ser puntuado
por este concepto.
Datos del currículo:
•
Apellidos y Nombre,
•
Edad,
•
N.I.F., N.S.S. y justificación/certificación de alta en la empresa (certificado de la S. Social)
•
Conocimientos metodológicos y tecnológicos principales.
•
Formación Reglada: Centro, Titulación y Fechas (desde-hasta).
•
Formación no Reglada: Centro, Curso y Fecha (desde-hasta).
•
Certificaciones en PLATEA y/o Geremua: Descripción y Fecha.
•
Experiencia Acumulada: Total Años.
•
Experiencia profesional: Empresa, Puesto / Responsabilidades, Meses o Años, Fecha (desdehasta).
Pliego de Bases Técnicas
31/55
•
Conocimientos y Experiencia obtenida Proyectos: Proyecto, Puesto / Responsabilidades, Meses,
Fecha (desde-hasta), y principales tecnologías utilizadas, para al menos los principales o
correspondientes a experiencias similares.
Pliego de Bases Técnicas
32/55
5
Especificaciones Técnicas
5.1
Metodología de desarrollo, normativa y Guía de Estilo
La organización del trabajo y ejecución del proyecto estará basada en la Metodología de planificación y
desarrollo de sistemas de información ARINBIDE.
ARINBIDE 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
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 define las siguientes fases metodológicas:
• Gestión del proyecto (GPR)
• Análisis del Sistema de Información (ASI)
• Diseño del Sistema de Información (DSI)
• Construcción del Sistema de Información (CSI)
• Implantación y Aceptación del Sistema (IAS)
• Mantenimiento del Sistema de Información (MSI)
• Gestión de la configuración (GCO)
Información detallada sobre las fases y entregables de la metodología ARINBIDE, se encuentra en la página
web de EJIE http://www.ejie.net/documentacion.htm
En las distintas fases del proyecto, teniendo en cuenta la mencionada metodología ARINBIDE, y según el
alcance del mismo, la empresa adjudicataria deberá contemplar, entre otros, los siguientes elementos:
• Análisis del sistema. Debe incluir:
o El catálogo de requisitos y la relación de los módulos del sistema.
o Análisis de las aplicaciones, ASI (ERS)
o Especificación del Plan de Pruebas resultante de la fase Análisis
El adjudicatario partirá de los entregables resultantes de las actividades de Definición del Sistema (ASI 1) y de
la de Establecimiento de Requisitos (ASI 2).
•
Diseño del sistema. Lo realizará en su totalidad el adjudicatario y en sus dependencias. Debe incluir:
o Diseño de las aplicaciones, DSI.
o 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
•
Construcción del sistema.
o 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 Oficina para la Modernización de la Administración en lo
que respecta a estética, diseño y funcionalidades de las páginas Web.
o 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
o Asimismo, deberán respetarse las convenciones adoptadas para un desarrollo de aplicaciones
homogéneas recogidas en el Libro de Estilo del Departamento de Sanidad y Consumo
o El diseño del sistema tendrá en cuenta el nivel de accesibilidad AA (WAI-AA), para aquellos
módulos que sean accesibles desde Internet.
Pliego de Bases Técnicas
33/55
o
o
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 en ambos
idiomas: euskera y castellano.
•
Implantación en desarrollo.
o La empresa adjudicataria 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
o Los entregables de esta fase incluyen en la Especificación de Construcción del Sistema (CSI) y
el sistema implantado.
o Ejecución de las Pruebas de implantación, y Pruebas de Aceptación del Sistema, evaluando los
resultados
•
Implantación en entorno de test o preexplotación.
o La empresa adjudicataria 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, donde se realice el primer
test con los usuarios finales de los sistemas.
o En caso de considerarse necesario, se llevarán a cabo las Pruebas de Aceptación en este
entorno
•
Pruebas de carga y rendimiento:
o Que incluye 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.
•
Implantación en producción y puesta en marcha del sistema. Incluirá:
o Fuentes de la aplicación.
o BBDD: scripts y carga inicial de datos.
o Sistema implantado en entorno de pruebas de EJIE
o Informe de pruebas unitarias y de integración.
o Manual de instalación / Explotación.
o Manuales de Usuario y la Ayuda On-line deberán estar en ambos idiomas: euskera y
castellano.
o Formación a los usuarios y administradores del sistema.
o Sistema implantado en entorno de producción.
Para las fases de implantación y pruebas de aplicaciones J2EE en entorno de desarrollo, existe un Manual de
tareas de ant, donde se describe el conjunto de tareas disponibles y el uso que debe hacerse de ellas.
En todas las fases del proyecto, así mismo será de referencia el documento de Estándares de desarrollo de
sistemas software, que establece requisitos obligatorios y recomendaciones a seguir en todo el proceso de
ejecución del proyecto, en cuando a la elaboración de los productos y la entrega de los mismos a EJIE
Igualmente será de referencia el Documento de Estándares Tecnológicos de Gobierno Vasco, publicado en:
www.euskadi.net/informatika
5.2
Entorno Tecnológico
El entorno tecnológico de las aplicaciones objeto del contrato se adscribe a los definidos en los estándares del
Gobierno Vasco, y a los específicos del Departamento de Sanidad y Consumo.
Pliego de Bases Técnicas
34/55
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: PLATEAInternet. Gestionan la creación, publicación y mantenimiento de contenidos en los portales de internet
administrados por Gobierno Vasco, y su catalogación en ejes homogéneos que faciliten su búsqueda.
Facilita igualmente los mecanismos para la integración de las aplicaciones en la propia infraestructura
de portales.
Como plataforma de integración entre sistemas:
• La infraestructura de integración. Simplifica y estandariza los modelos de intercambio de datos y de
procesos entre aplicativos, proporcionando para ello las herramientas y sistemas necesarios para su
implementación en base a una plataforma tecnológica unificada, normalizada y compartida. Ofrece
soluciones corporativas para el intercambio síncrono de información (exposición de servicios por medio
de adaptadores), y el intercambio asíncrono (propagador-enrutador), así como la creación de procesos
orquestados.
Como referencia obligada respecto a los ámbitos mencionados, deberá considerarse el documento PLATEA–
Plataforma Tecnológica para la e-Administración.
El sistema final deberá utilizar el sistema de seguridad homologado en el entorno de Gobierno Vasco:
• XLNetS. Gestiona los procesos de autenticación y autorización de accesos a usuarios (y sistemas)
para aplicativos y recursos, desarrollados bajo distintas tecnologías.
Para los desarrollos basados en entorno tecnológico J2EE, en todas las fases de desarrollo del nuevo sistema
se deberá contemplar y utilizar el framework J2EE homologado en el entorno de Gobierno Vasco:
• Geremua. Capa software entre una aplicación y el software de base (sistema operativo, máquina
virtual, bases de datos, middleware) que ayuda a resolver problemáticas comunes a gran cantidad de
aplicaciones. Se consigue acelerar los tiempos de desarrollo y mejorar la calidad del software, e incluso
el rendimiento, pues también marca una tendencia arquitectural hacia las mejores prácticas de diseño y
desarrollo.
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
Pliego de Bases Técnicas
35/55
documentales – FSD, proporcionando además otras utilidades para la carga masiva de documentación,
e interfaces gráficas.
En el documento PBT-PLATEA-Anexos se anexa explicación detallada de los sistemas corporativos
involucrados en PLATEA.
Como solución corporativa de información de datos de localización:
• NORA. Sistema horizontal de gestión de datos de localización –dirección postal-, que proporciona
información actualizada y normalizada hasta nivel de portal. Ofrece diversas alternativas tecnológicas
de uso, y como principal valor añadido aporta el tratamiento de Altas Provisionales, solución que
permite a las aplicaciones asegurar la normalización de los datos de su negocio, y a su vez favorecer la
actualización continua de la información. Inluye además información geográfica. En el documento PBTAnexo NORA se detalla información de referencia acerca del sistema.
Para facilitar el tratamiento de pago telemático del ciudadano a la administración:
• Pasarela de pagos: Sistema que provee los servicios necesarios para gestionar peticiones de pago
generadas por la administración para el ciudadano, incluida la aplicación internet de pago electrónico
on-line u off-line. En el documento PBT-Anexo Pasarela de Pagos se detalla información de referencia
acerca del sistema.
Otros productos y soluciones corporativas existentes son los siguientes:
Gestión de procesos batch:
• K31/O75: Soluciones corporativas para la ejecución de procesos desasistidos
• CONTROL-M: Planificación de procesos batch
Generación de informes:
• Jreport. Existe un middleware corporativo (T43) para uso por las aplicaciones departamentales, con
tecnología J2EE.
• Reporting Services (Microsoft)
Business Intelligence:
• Oracle Discoverer
• Bitam
Sistemas de Información Geográfica:
• GIS Corporativo, basado en productos ESRI (ArcIMS, ARcSDE, ArcView)
Además de los sistemas horizontales especificados, el nuevo sistema, según sus necesidades, deberá utilizar
los módulos y servicios establecidos por el Plan de Informática y Telecomunicaciones del G.V. y especificados
en el documento de guía de estándares tecnológicos.
Las plataformas tecnológicas y productos comunes de base serán, entre otros:
•
Servidor web:
Apache Web Server 2 sobre Linux Red Hat Enterprise.
•
Servidor de integración:
BEA Weblogic Integration 8.1 sobre Linux Red Hat Enterprise
•
Base de datos:
Oracle 10g sobre HP-UX
SQL Server 2005
•
Seguridad:
XLNets y PKI Izenpe
Pliego de Bases Técnicas
36/55
•
Infraestructura para la Gestión de contenidos y portales (PLATEA-Internet):
Interwoven TeamSite 6.7
Open Deploy 6.1
Autonomy
•
Infraestructura para la gestión documental (dokusi):
Documentum
•
Gestión de versionado de aplicaciones
Subversion
•
Documentación y trabajo en grupo:
SharePoint Portal Server
Además, para el entorno tecnológico J2EE:
•
Servidor de aplicaciones:
BEA Weblogic Server 8.1 sobre Linux Red Hat Enterprise
BEA WebLogic Server 11g sobre Linux Red Hat Enterprise
•
Herramientas para desarrollo:
9
Framework J2EE:
Geremua
9
IDE (PC compatible con Windows XP SP1):
Eclipse, con plugin MyEclipse
Ant 1.5
9
Gestión de dependencias
Maven
•
Pruebas de rendimiento (pre-producción):
LoadRunner
Además, para el entorno tecnológico Microsoft .NET:
9
•
Servidor de aplicaciones:
IIS 6.0 sobre Windows 2003 Server
•
Herramientas para desarrollo:
IDE (PC compatible con Windows XP SP1):
Visual Studio 2005
En todos los casos, y según corresponda al entorno tecnológico a utilizar, se utilizarán igualmente las
Herramientas del ciclo de vida de las aplicaciones. En el documento PBT-Anexo Herramientas se relacionan
las herramientas homologadas.
Existe asimismo un conjunto de librerías software homologadas, 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 (Izenpe, FOP, POI, LinearBarCode, JFreeChart, IAIK,…)
5.3
Modelo de aseguramiento de la calidad
EJIE contempla la calidad en distintos ámbitos de aplicación, tanto calidad en los procesos como calidad en los
productos.
Pliego de Bases Técnicas
37/55
Para asegurar la calidad en el proceso de gestión del proyecto, durante le ejecución del mismo el
adjudicatario deberá contemplar y proveer la documentación que sea requerida en cumplimiento de la
metodología ARINBIDE.
Por otro lado, con el objetivo de asegurar además la calidad de los productos software obtenidos, será de
referencia obligatoria el modelo estándar de aseguramiento de la calidad definido para el contexto de GV-EJIE,
que a grandes rasgos consta de:
• Asignación del valor NAC (nivel de aseguramiento de la calidad) asociado al proyecto.
• Controles de calidad (SQA) a realizar durante el ciclo de vida de desarrollo del software.
• Tipologías de pruebas a ejecutar.
• La metodología de pruebas que permita certificar de manera más exhaustiva el cumplimiento de los
estándares de calidad definidos.
• Los indicadores estándar, las métricas y sus umbrales permitidos.
• El conjunto de herramientas que facilitan la aplicación de la metodología y la obtención de indicadores.
En este ámbito de definición de la calidad, será de referencia el documento de Estándares de calidad de
producto Software, así como la Metodología de Pruebas.
5.3.1.
Controles de calidad (SQA)
En función del NAC asignado, se han definido una serie de controles de calidad, cuya ejecución es
obligatoria o recomendada, tal y como se define en el documento de Estándares de calidad de producto
Software.
El adjudicatario deberá contemplar la ejecución de estos controles de calidad dentro del alcance del
proyecto objeto de contratación.
5.3.2.
Tipologías de pruebas
El modelo de aseguramiento de calidad establece que el cumplimiento del estándar está además
condicionado por el conjunto mínimo de tipologías de pruebas que se deberán realizar. El alcance de
éstas viene ya determinado por la propia metodología de desarrollo ARINBIDE. O si es de aplicación, de
manera complementaria, por la metodología de pruebas.
A la hora de realizar las pruebas, la estrategia a seguir deberá incluir obligatoriamente la realización de
pruebas unitarias, de integración, y de sistema, más la de aceptación si los cambios realizados deben
ser validados por el usuario. Estos cuatro tipos de pruebas deben realizarse independientemente del
NAC obtenido. Las de sistema, divididas en funcionales, y no funcionales (que incluyen las de
rendimiento) se deberán ejecutar según el nivel NAC asignado al proyecto.
5.3.3.
Metodología de pruebas
Dada la no existencia de un proyecto de Oficina Técnica de Calidad, paralelo al presente pliego de
contratación, el adjudicatario, además del cumplimiento de la metodología de desarrollo ARINBIDE,
deberá contemplar la ejecución de las tareas propias de la Metodología de Pruebas que se consideren
oportunas, como son:
o Checklist de verificación de ARINBIDE (CVA)
o Definición y gestión del plan de pruebas mediante la herramienta homologada a tal efecto (Ver
Anexo de herramientas)
o Realización del Informe Final de Pruebas (IFPB)
Pliego de Bases Técnicas
38/55
o
o
o
5.3.4.
Seguimiento y gestión de incidencias mediante la herramienta homologada a tal efecto (Ver
Anexo de herramientas)
Realización del informe final de incidencias (IIPB)
…
Indicadores
Aunque la propia Metodología de Pruebas ya define un conjunto completo de indicadores y sus umbrales
asociados, existe un conjunto básico de indicadores que toda aplicación a implantar en el entorno de GVEJIE deberá satisfacer.
En el entorno de desarrollo, para obtener los resultados de los indicadores para el proyecto se deberán
seguir las instrucciones marcadas en el documento Indicadores_NAC.Desarrollo, en el que se
especifican detalladamente los pasos a realizar y las herramientas a utilizar en cada momento.
El adjudicatario del presente contrato deberá contemplar la ejecución de las tareas necesarias para la
obtención de estos indicadores, dentro del alcance del proyecto objeto de contratación.
Igualmente, como parte del aseguramiento de la calidad, se ha definido para el entorno de pruebas (preproducción) el documento Indicadores_NAC.Pruebas. El adjudicatario del presente contrato deberá
suministrar toda la información y entregables que sean requeridos en este ámbito para la realización de
las pruebas.
5.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 PBT-Anexo Herramientas se detallan las herramientas homologadas.
Pliego de Bases Técnicas
39/55
6
Control y Seguimiento
El propósito de las tareas de control y seguimiento es el de proveer una visión objetiva del estado actual de la
prestación del servicio y determinar las posibles desviaciones a fin de aplicar las acciones correctoras que sean
necesarias. Es en este sentido en el cual llamamos seguimiento a la evaluación rutinaria del estado, en tanto
que llamamos control a la toma de los valores que definen el estado.
Los productos mínimos de esta práctica son los informes de seguimiento, un documento o artefacto, donde
anotamos los resultados de la evaluación de una iteración de control; de momento sin decir las correcciones a
tomar.
Una vez identificadas las desviaciones, es necesario decidir oportunamente las correcciones requeridas,
llevándolas a cabo en el momento en que sea necesario. Finalmente es importante que la corrección planteada
sea a su vez, objeto de seguimiento, lo que implica que la planificación debe ser actualizada para que refleje
las acciones que se han determinado necesarias para corregir la desviación.
A la hora de realizar las reuniones de seguimiento es conveniente calcular previamente las medidas o métricas
que aplicadas al servicio objeto de la contratación sirvan de indicador sobre el estado del mismo. Esto con el
objeto de obtener una evaluación lo más completa y objetiva posible de la prestación del servicio.
Así, bajo esta perspectiva, el licitador deberá describir en su Documento de Propuesta Técnica:
• El modelo de control y seguimiento a aplicar durante la prestación del servicio, incluyendo las
reuniones de seguimiento a celebrar, su objetivo, su periodicidad, los asistentes necesarios, los
controles que deben ser ejecutados, etc.
• Los informes de seguimiento que deberán obtenerse en cada fase del servicio, y para cada solicitud de
trabajo realizada. Se detallará su objetivo y al menos parcialmente, su contenido.
• Los indicadores de calidad del servicio a medir, y su criticidad asociada.
• Los métodos de aplicación de las posibles acciones correctoras
No obstante se detallan a continuación aproximaciones iniciales que puedan servir como marco de referencia.
6.1
Puntos de Control
Puesto que todos los flujos de trabajo que dan respuesta a las actividades objeto del presente pliego de bases
técnicas se basan en el uso de la herramienta de gestión de peticiones homologada (Mantis), los informes que
se proponen obtendrán la mayor parte de la información que precisan desde dicha herramienta.
Con el objetivo de verificar el cumplimiento del nivel de servicio comprometido y adoptar las medidas
correctoras necesarias se han de realizar las siguientes reuniones:
DE INICIO DEL PROYECTO
Participantes:
• EJIE:
o Grupo Gestión ANS de EJIE
o Representantes del grupo de asistencia técnica de EJIE
• Adjudicatario:
o Representantes del adjudicatario
Periodicidad:
• Al inicio del proyecto, en la fase de diagnóstico
Pliego de Bases Técnicas
40/55
Objetivos principales:
• Despejar las dudas existentes entre las partes interesadas al respecto de cualquier aspecto
relacionado con la prestación del servicio (modelo de operación, modelo de gestión, hito de control y
sus objetivos, plan inicial de proyecto, controles de calidad, otros que se consideren relevantes).
• Identificar todos los actores involucrados, asignándoles sus roles y responsabilidades
Salidas:
• Acta de la reunión
• Documento de definición del contexto, que reflejará las características iniciales del modelo de
prestación del servicio
DE CONTROL DE LA PRESTACIÓN DEL SERVICIO ANS
Participantes:
• EJIE:
o Grupo Gestión ANS de EJIE
o Representantes del grupo de asistencia técnica de EJIE
• Adjudicatario:
o Grupo Gestión ANS del adjudicatario
o Representantes del adjudicatario
Periodicidad:
• Trimestral
• A petición de cualquiera de los participantes cuando se considere oportuno
Objetivos principales:
• Asegurar que las actividades demandadas durante el trimestre anterior se han resuelto adecuadamente
en todos los casos
• Detectar posibles circunstancias que puedan comprometer la prestación del servicio
• Revisar y actualizar si procede el conjunto de métricas e indicadores de servicio
• Revisar los valores de las métricas asociadas a los indicadores de servicio
• Revisar los valores de las métricas asociadas a los indicadores de calidad del producto
• Cálculo de las penalizaciones a aplicar
• Modificaciones sobre el conjunto de aplicaciones incluidas en el contrato
Salidas:
• Acta de la reunión
• Informe de evolución de indicadores (con grado de cumplimiento y acumulados)
• Penalizaciones a aplicar (causas e importes)
• Informe con las incidencias detectadas durante las prestación del servicio y sus acciones de mejora
DE SEGUIMIENTO
Participantes:
• EJIE:
o Jefe de proyecto del grupo de asistencia
o Responsables funcionales de aplicaciones
o Grupo Gestión ANS de EJIE
• Adjudicatario:
o Responsable del Proyecto
o Grupo Gestión ANS del adjudicatario
Pliego de Bases Técnicas
41/55
o
Representantes de los equipos de trabajo del adjudicatario
Periodicidad:
• Mensual
• A petición de cualquiera de los participantes cuando se considere oportuno
Objetivos principales:
• Seguimiento detallado de las actividades desarrolladas en el período, y en curso
• Despejar las dudas existentes entre las partes interesadas al respecto de cualquier aspecto
relacionado con las solicitudes de trabajo desarrolladas en el período, y en curso
• Evaluar el estado de avance de la prestación del servicio, las incidencias ocurridas durante el periodo y
decidir sobre acciones de mejora a aplicar para un mejor cumplimiento de los objetivos finales
perseguidos
• Validar la efectividad de las acciones de mejora propuestas en el período anterior
• Asegurar que el estado de los artefactos software actualizados, de los repositorios, y de la
documentación se realiza adecuadamente
• Planificación de actividades para el siguiente período, de las tipologías especificadas en las líneas de
trabajo, y de las implantaciones de cambios
Salidas:
• Acta de la reunión
• Informe de progreso de las actividades realizadas en el período, para cada aplicación
• Informe de situación sobre el estado de actualización de los artefactos software, repositorios y
documentación
• Estadísticas sobre las peticiones de trabajo realizadas en el período (nº de peticiones, su tipología,
prioridad, tiempo de resolución, valores medios, etc.)
• Acciones de mejora a aplicar
• Planificación de actividades para el siguiente período
DE COMITÉ DIRECTOR
Participantes:
• EJIE:
o Directora del área de proyectos y asistencia técnica
o Jefe de proyecto del grupo de asistencia técnica
• Adjudicatario:
o Director de Proyecto del adjudicatario en representación de la Dirección
o Responsable del Proyecto
Periodicidad:
• A petición de cualquiera de los participantes cuando se considere oportuno
• A petición del comité de seguimiento
• Trimestral
Objetivos principales:
• Analizar y resolver problemas relacionados con cualquier aspecto relacionado con la prestación del
servicio, y que no pueda ser resuelto por el comité de seguimiento. Especialmente los relativos a
posibles variaciones de alcance, plazos, coste y requerimientos.
• Tratar en detalle los hechos relevantes surgidos en el periodo e identificadas en las reuniones de
seguimiento, evaluando el modelo de mantenimiento de ANS con el fin último de aplicar mejoras.
Salidas:
• Acta de la reunión
Pliego de Bases Técnicas
42/55
DE REVISIÓN DE CALIDAD
Participantes:
• EJIE:
o Jefe de proyecto del grupo de asistencia técnica
o Representante de Oficina de calidad y pruebas de EJIE (Grupo de consultoría de áreas de
conocimiento)
• Adjudicatario:
o Responsable del Proyecto
Periodicidad:
• Semestral
Objetivos principales:
• Verificar que los flujos de trabajo aprobados se cumplen.
• Revisar, y actualizar si procede, los indicadores de calidad del servicio definidos
• Proponer acciones de mejora
Salidas:
• Acta de la reunión
• Informe de situación de las revisiones realizadas
• Acciones de mejora propuestas
6.2
Indicadores de Nivel de Servicio
Se han establecido dos tipos de indicadores de nivel de servicio:
• Indicadores de Servicio
• Indicadores de Calidad
6.2.1.
Indicadores de Servicio
Que cubren cada uno de los elementos de servicio objeto de este pliego:
o Servicio de Atención a Consultas y Soporte Técnico de Desarrollo
o Servicio de Mantenimiento Correctivo (problemas), Mantenimiento Preventivo y Evolutivo a
pequeña escala
o Servicio de Mantenimiento Evolutivo a gran escala, y Mantenimiento Adaptativo
Para cada indicador se detallan una serie de campos:
o Tipo Consulta/Mantenimiento. Atributo que identifica el indicador
o Tiempos de Respuesta/Resolución. Límite temporal para el cumplimiento del indicador
o Penalización. El incumplimiento del indicador tiene penalización o no.
o Periodicidad. Frecuencia de cálculo del indicador
o Valor objetivo. Valor fijado como objetivo para el indicador
Un atributo de catalogación importante para las incidencias y los problemas es la urgencia o la criticidad
de los mismos (prioridad), que influye sobre los tiempos de resolución requeridos y los indicadores de
nivel de servicio asociados. Sus valores son:
Pliego de Bases Técnicas
43/55
Prioridad
Descripción
Muy Urgente
Incidencias que impactan gravemente sobre el negocio (perdida de servicio en un área
crítica para el departamento) o la imagen de EJIE. Requieren de una intervención
inmediata e ininterrumpida hasta su resolución definitiva.
Urgente
Incidencias que no impactan sobre el negocio o la imagen de EJIE pero que impiden la
ejecución normal de una o más partes de la aplicación objeto del Servicio o de otras con
las que se relaciona.
Afectan a aplicaciones definidas por EJIE como NO críticas.
Normal
Incidencias que no impactan sobre el negocio o la imagen de EJIE y no impiden el
funcionamiento normal de la aplicación objeto del Servicio o de otras con las que se
relaciona.
Afectan a aplicaciones definidas por EJIE como NO críticas.
Cualquier incidencia que afecte a una aplicación crítica será considerada inicialmente como Muy
Urgente. No obstante, y tras su revisión, podrá ser modificada por EJIE a prioridad Urgente o Normal.
A efectos del cálculo de indicadores, y por ende, de las penalizaciones asociadas, el cómputo de horas
se realizará en base al horario laboral de trabajo establecido, excepto para las peticiones de
mantenimiento correctivo de prioridad muy urgente, o urgente, aplicándose en este caso el horario
natural.
Se asumen las siguientes definiciones:
o Tiempo de Respuesta Æ Tiempo transcurrido desde el alta de la petición hasta que ésta se
acepta.
o Tiempo de resolución Æ Tiempo transcurrido desde que se acepta la petición hasta que ésta se
resuelve satisfactoriamente
o El cálculo del valor objetivo se aplicará sobre el total de peticiones dadas de alta en el período.
Pliego de Bases Técnicas
44/55
ATENCIÓN A CONSULTAS Y SOPORTE
Tipo Consulta
Tiempos de Respuesta/
Resolución (máximo)
Penalización
Periodicidad
Valor Objetivo
Muy urgente
Urgente
Normal
15 min / 1 hora
1 hora / 2 horas
2 horas / 4 horas.
NO
NO
NO
Mensual
Mensual
Mensual
>=95%
>=95%
>=85%
Penalización
Periodicidad
Valor Objetivo
SI
SI
Mensual
Mensual
>=95%
>=95%
SI
Mensual
>=95%
MANTENIMIENTO CORRECTIVO (PROBLEMAS)
Tipo Mantenimiento
Muy urgente
Urgente
Normal
Tiempos de Respuesta/
Resolución
15 min. / 8 horas
30 min. / 16 horas
1 hora / Desviación sobre
la planificación < 22%
MANTENIMIENTO ADAPTATIVO Y EVOLUTIVO A PEQUEÑA ESCALA
Tipo Mantenimiento
Desviación sobre
planificación
Penalización
Periodicidad
Valor Objetivo
Evolutivo pequeña escala
Adaptativo
Máximo 18%
Máximo 20%
SI
SI
Trimestral
Trimestral
>=95%
>=95%
MANTENIMIENTO EVOLUTIVO A GRAN ESCALA
Tipo Mantenimiento
Desviación sobre
planificación
Penalización
Periodicidad
Valor Objetivo
Evolutivo gran escala
Máximo 20%
SI
Trimestral
>=95%
6.2.2.
Indicadores de Calidad
Se han definido indicadores para cada uno de los elementos de calidad objeto de este pliego
o
o
o
o
Reducción del mantenimiento correctivo
Rechazos de peticiones de servicio por parte del proveedor
Peticiones reabiertas
Cumplimiento de indicadores de calidad del producto.
Para cada indicador se detallan una serie de campos:
o Descripción del indicador. Breve descripción del indicador de calidad
o Indicador alcanzado. El umbral que se ha de conseguir en el indicador
o Penalización. El incumplimiento del indicador tiene penalización o no.
o Periodicidad. Frecuencia de cálculo del indicador
Pliego de Bases Técnicas
45/55
Descripción del indicador
Umbral
Penalización
Periodicidad
Reducción Mantenimiento Correctivo
Rechazos de peticiones de servicio por parte
del proveedor
Número de peticiones reabiertas
Decremento en los niveles de calidad del
producto
Mín.: 5%
Máx.: 2%
NO
Anual
NO
Trimestral
Máx.: 5%
0%
NO
Trimestral
NO
Trimestral
Pliego de Bases Técnicas
46/55
7
7.1
Condiciones particulares
Modelo de facturación
En documento separado y siguiendo lo establecido en el modelo de Pliego/Hoja de Cláusulas Administrativas
se deberá incluir el importe Total de la Oferta Económica, con y sin I.V.A. Y opcionalmente, cualquier otro
desglose de estimación de esfuerzos que se considere relevante para la correcta evaluación del apartado
“Proposición económica” contemplado en la sección de Criterios de Valoración.
Se establece el siguiente modelo de facturación mensual:
Facturación base
Concepto fijo que se corresponde con una doceava parte del importe adjudicado como “presupuesto
base”.
Facturación por evolutivo/adaptativo
Concepto variable, cuyo importe se establecerá en función del trabajo realizado como “presupuesto
evolutivo/adaptativo”, descontando las penalizaciones a aplicar.
Podrán detallarse también en dicho documento, posibles prestaciones superiores a las solicitadas, ofertadas
por el licitador y debidamente argumentadas en cuanto al nivel de esfuerzo requerido, siempre y cuando EJIE
las considere como tales desde el punto de vista del proyecto y si así se especificase en el apartado de
“Prestaciones Superiores/Complementarias a las Exigidas” contemplado en la sección de Criterios de
Valoración.
En el precio ofertado se entenderán ya incluidos: las dietas, gastos de desplazamiento y/o cualquier otro gasto
necesario para la realización del servicio. Con independencia de lo aquí indicado será necesario incluir el
desglose de cualquier gasto o aspecto objeto del presente pliego si así fuera requerido de forma expresa en el
Pliego/Hoja de Cláusulas Administrativas.
7.2
Penalizaciones
En las reuniones de Control del Servicio, y en base a los informes de Nivel de Servicio, se comprobarán las
desviaciones resultantes, siendo objeto de penalizaciones en los términos que a continuación se establecen.
La suma de penalizaciones no superará en ningún caso el 10%.
Pliego de Bases Técnicas
47/55
MANTENIMIENTO CORRECTIVO Y ATENCIÓN A CONSULTAS Y SOPORTE
Tipo de Mantenimiento
Muy urgente
Urgente
Normal
Rango de desviación
De 1 al 5 %
Del 6 al 10 %
Superior al 10%
De 1 al 8 %
Del 9 al 15 %
Superior al 15%
De 1 al 10 %
Del 10 al 20 %
Superior al 20%
Penalización sobre el
fijo mensual
1%
2%
3%
1%
2%
3%
1%
2%
3%
MANTENIMIENTO EVOLUTIVO A PEQUEÑA ESCALA
Tipo de Mantenimiento
Evolutivo
Rango de desviación
De 1 al 5 %
Del 6 al 10 %
Superior al 10%
Penalización sobre el fijo
mensual
1%
2%
3%
MANTENIMIENTO EVOLUTIVO A GRAN ESCALA
Tipo Mantenimiento
Evolutivo
7.3
Rango de desviación
De 1 al 5 %
Del 6 al 10 %
Superior al 10%
Penalización sobre el
fijo mensual
1%
2%
3%
Criterios de valoración
Los criterios de adjudicación que servirán de base para la valoración de las propuestas, así como sus pesos de
ponderación se recogen a continuación. Para la evaluación de las propuestas se establece un criterio de
ponderación con una puntuación máxima de 100 puntos.
A continuación se detalla la puntuación y aspectos que se tendrán en cuenta para la adjudicación del trabajo:
Pliego de Bases Técnicas
48/55
Característica Objeto de valoración
•
Puntos
Conocimiento de las Áreas Funcionales
35
Proposición Económica del presupuesto base
20
Proposición Económica del presupuesto evolutivo/adaptativo
15
Planificación y Organización del proyecto.
10
Propuesta de Control y Seguimiento
10
Prestaciones Superiores/Complementarias a las Exigidas.
10
Proposición Económica del presupuesto base: Se valorará bajo la siguiente fórmula:
Total puntos proposición económica x Precio oferta más ventajosa (la de precio más bajo)
Precio oferta evaluada
•
7.4
Proposición económica del presupuesto evolutivo/adaptativo. Se calculará sobre el valor medio de las
tarifas de los distintos perfiles solicitados, y utilizando también la misma fórmula de valoración anterior.
Finalización del servicio
El proveedor se obliga, si lo solicita EJIE, a devolver el Control del Servicio en los siguientes supuestos:
• Una vez transcurrido el plazo establecido
• Por incumplimiento del Acuerdo de Nivel de Servicio
Para ello, EJIE comunicará al proveedor su intención con una antelación de un mes a la fecha de inicio de
devolución del control.
En caso de que finalizada la fase de estabilización, el proveedor no sigua adelante con la prestación del
servicio, se le penalizará con un 10% sobre el precio total del contrato.
Pliego de Bases Técnicas
49/55
8
Garantía y Confidencialidad
Las cláusulas relativas a la propiedad intelectual, garantía y confidencialidad de la información, así como el
resto de condiciones generales de contratación se encuentran disponibles en la web de EJIE (www.ejie.net) en
el apartado perfil de contratante.
8.1
Garantía
El período de garantía será como mínimo el tiempo que dure el contrato. No obstante los licitadores
especificarán, en su caso, el tiempo de garantía ofrecido superior al mínimo, así como el alcance de la misma.
El adjudicatario se compromete a resolver las desviaciones causadas por errores propios y no inducidas por
otras aplicaciones o intervenciones externas sin cargo alguno para EJIE, sin embargo, cualquier producto que
entregado por el adjudicatario, sea modificado por un tercero, perderá de inmediato su garantía.
Cuando los desarrollos de una aplicación se pasan al ANS están en garantía durante un período mínimo de 6
meses.
8.2
Confidencialidad
El proveedor se compromete a:
•
Tratar con absoluta confidencialidad todo el material y la información que reciba como
consecuencia de los trabajos realizados objeto de la adjudicación, durante el periodo de tiempo de
duración de la misma,
•
No utilizar la misma para otros fines que los recogidos en el presente Pliego de Condiciones
Técnicas.
•
No duplicar, copiar, revelar, ceder o vender total o parcialmente la información obtenida, en todo o
en parte, a terceros sin autorización escrita de EJIE,
•
Advertir a sus empleados de sus obligaciones respecto a la confidencialidad de la información,
velando por el cumplimiento de la misma,
•
Restringir la utilización de la información obtenida como consecuencia de los trabajos realizados
objeto del presente pliego de bases técnicas, exclusivamente para aquellos empleados que
tengan necesidad de conocerla y con la finalidad de realizar los trabajos expuestos.
•
Poner todos los medios a su alcance para conservar el carácter confidencial y reservado tanto de
la información y documentación recibida de EJIE, como de los resultados obtenidos del trabajo
realizado.
•
La devolución de toda la información, material y/ soportes informáticos obtenidos, así como a la
descarga de la misma de sus equipos informáticos o (si existieran), una vez finalizado el periodo
de contratación correspondiente.
Cualquier infracción en este sentido será calificada como grave y será causa de resolución del contrato, sin
perjuicio de las responsabilidades penales, o de otro tipo, en que se puedan incurrir.
8.3
Derechos y propiedad de los desarrollos y datos
Pliego de Bases Técnicas
50/55
Todos los derechos de propiedad intelectual y de ‘Copyright’ de cualquier producto o subproducto derivados de
los trabajos realizados bajo la correspondiente adjudicación serán propiedad exclusiva de EJIE, obligándose
las partes a otorgar el documento oportuno cuando éste sea necesario, para la debida constancia pública de
este hecho ante cualquier Organismo o Registro, tanto de la Comunidad Autónoma como de la Administración
Central del Estado Español.
Así mismo todo producto o subproducto derivada de la correspondiente contratación no podrá ser utilizado para
otros fines fuera del ámbito de la misma, sin el permiso expreso y por escrito de EJIE.
La empresa adjudicataria será responsable de daños y perjuicios que se deriven del incumplimiento de esta
obligación.
8.4
Protección de los datos
El proveedor quedará obligado al cumplimiento de lo dispuesto en la Ley Orgánica de Protección de Datos,
sobre protección de datos de carácter personal. En este sentido, deberá sujetarse a los preceptos de la Ley
Orgánica 15/1999, de 13 de diciembre, LOPD, y su Reglamento de Desarrollo, RD 1720/2007, de 21 de
diciembre.
Pliego de Bases Técnicas
51/55
9
Estructura y Formato de la Propuesta
El licitador sólo podrá presentar su propuesta contemplando una única alternativa.
9.1
Estructura normalizada y contenido de las propuestas.
La propuesta que se presente por el licitador deberá aportar la información que se requiere en todos sus
apartados y estar obligatoriamente estructurada de la siguiente forma:
Documento de Propuesta Técnica, incluyendo
•
Índice.
•
Presentación y Características Generales:
9
Identificación del pliego al que responde la propuesta.
9
Acatamiento con carácter general a las condiciones del pliego.
A partir de este punto, los siguientes apartados se particularizarán para cada una de las soluciones que
se oferten.
•
Descripción de la Solución 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.
•
Metodología y Entorno Tecnológico.
•
Planificación y Organización.
9
Se indicarán las principales fases/tareas del proyecto y el cronograma de trabajos.
9
Organización del equipo de proyecto, junto perfiles, funciones y responsabilidades.
9
Equipo de trabajo.
¾
Datos relativos de todos los componentes del equipo de trabajo, incluyendo el cuadro
de asignación de recursos a fases del proyecto.
¾
Composición del equipo de trabajo propuesto, ordenado por categorías profesionales.
¾
Currículo de cada uno de los componentes, de acuerdo a lo indicado en el apartado
Equipo de Trabajo y recogido en Anexo al Documento de Propuesta Técnica.
•
Procedimientos de Gestión, Control y Calidad de Proyectos
Se incluirá en este apartado la descripción de las medidas dispuestas por el licitador para asegurar
la calidad de los trabajos, medios humanos y materiales, aseguramiento de calidad, así como
aquellas otras que se prevé aplicar para vigilar y garantizar el adecuado cumplimiento del contrato.
•
Prestaciones superiores o complementarias a las exigidas, si las hubiera:
El adjudicatario podrá incluir en su propuesta cuantas prestaciones adicionales considere
oportunas para la mejora de su actuación, estas (salvo ampliaciones en la garantía) deberán ser
necesariamente valoradas tanto en cuanto al nivel de esfuerzo (horas por perfil) como
económicamente y de forma separada en los Documentos de Propuesta Técnica y
Propuesta/Oferta Económica
•
Garantía, Confidencialidad y Propiedad Intelectual.
Pliego de Bases Técnicas
52/55
(*) En ningún caso se deberá incluir información Económica en el Documento de Propuesta Técnica.
Documento de Propuesta/Oferta Económica, incluyendo:
•
Importe Total de la oferta Económica: con y sin I.V.A.
•
Relación completa de los costes contenidos en la propuesta, indicando:
9
Número de horas por persona y categoría/perfil.
9
Coste hora por categoría/perfil.
Siguiendo el modelo establecido.
•
9.2
Cualquier otro requisito establecido en el Pliego/Hoja de Cláusulas Administrativas.
Formato de la Propuesta.
El soporte físico de las propuestas deberá ser:
•
Papel, debidamente encuadernada, y
•
CD/DVD, en formato electrónico (.pdf).
9.3
Sobres y Elementos.
Todas las propuestas deberán entregarse en sobre o paquete debidamente cerrado, y
•
Con etiqueta indicando sobre el mismo:
9
Descripción/Título y
9 Referencia
Presentes en la carátula del presente Pliego.
•
Recogiendo en su interior:
9
Documento de Propuesta Técnica, siguiendo la estructura requerida en el apartado de
Estructura y Formato de la Propuesta, del presente documento.
9
Documento de Propuesta Económica siguiendo la estructura requerida en el apartado de
Presupuesto/Oferta económica, del presente documento y de lo indicado en el Pliego/Hoja de
Cláusulas Administrativas
9
Soporte Magnético con los documentos electrónicos correspondientes, rotulado sobre el
mismo: Descripción/Título y Referencia del Pliego.
Pliego de Bases Técnicas
53/55
Anexo I. Relación de aplicaciones
D08-RECIEN NACIDOS
G83-T.I.S.
J15-AGUAS DE CONSUMO.
K43-REGISTRO DE CANCER
K74-PRESTACIONES SANITARIAS
K74/R64-ORTOPROTESIS
L12-FARMACIA
L31-ITEMP
L33-EDOS
L45-REINTEGRO DE GASTOS
M42-LABORATORIOS
N60-SANCIONES
O22-ESKURA-TSE
O38-DOCENCIA
O39- REGISTRO DE ACTIVIDAD DE MATADEROS.
N60 - SANCIONES
O43-POLICIA SANITARIA MORTUORIA
O45-PERMISO DE TRAFICO Y ARMAS
P04-CONTRATACION SANITARIA
P15-ATENCION AL CLIENTE
P41-INSPECCIÓN DE CENTROS ALIMENTARIOS
P70-RECETA ELECTRONICA
P80-LEGIONELA
Q51-REGISTRO DE ACREDITACIONES DE FORMACION
Q71-VOLUNTADES ANTICIPADAS
Q86-REGISTRO DE DIABETES
Pliego de Bases Técnicas
54/55
Q97-SISTEMA INTEGRADO DE ASEGURAMIENTO
R27-REGISTRO DE CENTROS SANITARIOS
R85-OSANET
R69-TUBERCULOSIS
S29-INVESTIGACION COMISIONADA
S60-ORDENACION FARMACEUTICA
S61-ESTABLECIMIENTOS BIOCIDAS
S82-PUBLICACIONES DE OSTEBA
T75-GIS
U15-SIPCA
U90-SIFCO-FONDO COHESION
V15-VACUNAS
V19-PORTAL OSAKIDETZA
V45-SISTEMA DE DIFUSION SIDA
W40/O41-RED DE VIGILANCIA MICROBIOLOGICA
W51-AGUAS DE RECREO-PISCINAS
X31-Digitalización de ayudas y subvenciones a coste 0
Pliego de Bases Técnicas
55/55